Apr 8, 2016
Ingrid is a senior SAP SD/MM/LE Functional Consultant with over 20 years’ experience in the industry. While the implementation time, cost and risk of a SAP project should be decreasing with the additional tools and knowledge we have, and while the quality of an implementation should be increasing, anecdotal evidence does not necessarily reflect that.
We asked Ingrid what we should look out for when implementing SAP as seen from the viewpoint of a functional consultant. Here are her thoughts that are especially applicable for a new implementation, a re-implementation or a sizeable project within an existing SAP landscape.
Client Preparedness
Complete a thorough questionnaire regarding client preparation before quoting a fixed price project. This could prevent cost overruns or future scope reductions. Questions could include:
- Are existing business processes documented in process flow diagrams?
- Will the most suitable business users be seconded to the project with their roles back-filled?
- Have the existing business requirements been documented against which the project deliverables will be compared?
Resources
- Ensure that SAP and business resources are physically located in the same area – the informal knowledge transfer and collaboration as a result of this are significant.
- Don’t outsource functional work – the degree of difficulty and potential lack of adequate collaboration can weigh heavily on the outcome of the project.
- If outsourcing technical work, take the time zone differences into account – a lot of time may be lost in the testing phase of a technological development when there are only a few hours of shared worktime.
- Provide an incentive to keep resources on the project until the required time post go-live – a lot of knowledge and momentum is lost if a valid resource departs prematurely.
Motivation and First Impressions
- Remember the importance of motivated resources – SAP is too tricky to implement successfully when consultants, SME’s or the business operate in a “survival mode”.
- Don’t underestimate the importance of first impressions regarding SAP and getting deliverables right the first time – this plays a significant role in positive change management.
Project Scope and Business Requirements
- Take care not to oversell a project – delivery is inevitably more complicated than the scope of what was sold (by an anecdotal average of 30-50%).
- Determine whether the project is a Best Practice project, a “vanilla” SAP project or “wish-list” project and manage the directives accordingly.
- Demonstrate the Best Practice processes in SAP to the business for a quick look-in, especially if the client is new to SAP or new to that SAP functionality – this prevents “light-bulb moments” occurring too late in the project.
- Ensure that business requirements are clearly documented in business speak – this input is used in design and testing and will eventually determine whether the project has been delivered successfully.
- If a project is fixed price, ensure that the blueprint document is written at an appropriate level of detail and that any changes are managed by an efficient and fair change request mechanism.
Solution Architect and Integration
- Don’t underestimate the value of a solution architect – this is the person who should manage process flows and integration discussions, assist in developing a pragmatic SAP solution, manage change requests and facilitate open communications at the functional level.
- Focus on integration points within SAP ERP, within SAP (e.g. BW, APO) and outside of SAP – these tend to be teething problems and where expectations are not met, or timeline slippages occur.
Business Processes
- Focus on business processes and business process documentation since these are central to business requirements gathering, blueprint documentation, configuration, testing (UT, SIT and UAT), training, authorisations, go-live support and continued ERP work.
- Consider that both end-to-end business processes (e.g. Third Party Sales Process) and functional business processes (e.g. Sales Order Processing) are required – the former for a focus on integration and the latter with a focus on detailed business requirements and configuration.
- Document process flows at a consistent level (that is, either end-to-end or functional) and ensures that process pointers link one process to another or cross-reference an operational process within an end-to-end process.
- Assign the ownership of all process flows to a solution architect or similar to ensure adequate process integration and consistency and that no “gaps” occur.
Documentation and Action Items
- Determine which documentation is required short-term (e.g. unit test scenarios for a technical enhancement) versus long-term (e.g. process flow diagrams) and invest the necessary energy appropriately.
- Don’t commit to documentation that is not sustainable – for every “create”, cater for approximately 3 “changes”.
- When documenting a new template, put it to the test with some more challenging content to ensure that it has been set up practically and efficiently.
- Don’t overcommit to documentation in the testing phase – it distracts from thoroughly testing a system.
- Run an action log (either individually or collectively as a team) and use the unique action log number to link emails and documents (Excel, Word, etc.) about the action item – this allows for efficient documentation and follow-up.
- Consider saving all emails with action log numbers in a centralised Outlook Data File so that the information can be accessed by all interested parties.
- Organise and maintain a folder structure so that it can be used effectively on an ongoing basis.
Data and Data Migration
- Identify the full set of master data that reflects required business variabilities – focus on setting up that master data correctly in SAP for Unit Test (UT) and System Integration Testing (SIT) purposes.
- Determine how master data will be transformed at the outset of the project and ensure that the relevant tools and resources are available to enable the correct transformation.
Technical and WRICEF’S
- Get professional buy-in before writing functional specifications – promising a SAP solution for which there is no cost or risk efficient technical solution is not ideal when there could be a technical alternative.
- Don’t let focus on WRICEF’s distract from the importance of configuration, master data setup and testing – SAP’s complexity should not be underestimated especially if a Best Practice solution is not implemented.
Quality
- Provide independent QA walkthrough sessions and track the health of the project accordingly.
- Don’t start and stop tasks sometimes under the auspices of multitasking or meeting short-term deliverables – the long term quality and deliverable suffers and jobs may take longer to complete.
Authorisations
- Don’t underestimate how poorly designed, built and tested authorisations can affect the success of a go-live – if a user cannot execute a task under business pressure, frustration and stress levels can quickly rise.
- Ensure that authorisations consist of roles that are transparent, simple and effective to add to or remove from a user.
Testing
- Assign quality functional and technical consultants to the project – the best and most comprehensive testing will only ever be the tip of the iceberg, and poor configuration settings or programming code can result in massive financial losses or support requirements for years to come.
Training
- Train according to business tasks – this can include business processes and SAP transactions, but it has to reflect “a day in the life of”. How many times has a significant amount of effort and money been invested in training only to find that SAP users are not able to operate the system efficiently for the first couple of months?
Go-Live
- Don’t celebrate go-live too early – actively bring forward “tricky” business and process functionality, including period ends, before the consultants leave.
In summary, SAP projects can be costly and time-consuming to implement and can place a significant risk on the business. By ensuring that the correct building blocks are in place and that the “vitals” are always being monitored, the chances of a successful implementation and a more favourable opinion of SAP projects are significantly increased.
