Managing Successful Erp Projects
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Managing Successful Erp Projects as PDF for free.
More details
- Words: 7,405
- Pages: 19
ERP Projects
A guide to successful implementations Version 1.0 Craig Scollick & Ed Estaugh 24 June 2005
2005 Charteris plc
CONTENTS CONTENTS
2
1.
INTRODUCTION
3
2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
SOME COMMON PROBLEMS Confusion over the project approach Inadequate business process mapping Inability to track configuration progress for the ERP system Customisations Data Migration Overruns in the build phase Silo based teams lose sight of the “end to end” solution Ongoing system maintenance costs higher than forecast Changing Requirements over the lifecycle
4 4 4 5 5 5 6 6 6 6
3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17
AN APPROACH TO SUCCESSFUL DELIVERY Approach and discipline Planning and Execution Attitude Identifying Critical Business Processes Suitably experienced functional staff with the correct attitude Effective cross team communication Combined customer/supplier teams Conference Room Pilots (CRPs) Issue or Observation tracking Effective and pragmatic risk management Configuration Customisation Testing Fallback or contingency planning The point of no return The first months post launch Stress Management and ERP projects
7 7 7 8 8 10 10 11 11 12 13 14 16 17 19 19 19 20
4.
CONCLUSIONS
22
24 June 2005 Version 1.0
A guide to successful implementations
Page 2 of 19
1.
INTRODUCTION
ERP implementation projects are notorious for financial and/or timescale overruns. This paper aims to identify common reasons why overruns occur and makes practical suggestions as to how organisations can ensure their approach maximises the probability of success within the necessary time and budget constraints. There is a common myth that an ERP project is somehow different from other types of IT project. This is not the case. If the implementation is approached in a structured manner, using an agreed approach, employing suitably experienced staff, utilising appropriate management metrics with supplier and customer working in a spirit of cooperation it is highly likely to succeed. If any of these high level factors are not in place then the probability of success will decrease. The following statements are often used by both suppliers and customers during ERP implementations: ♦ “They said it would be out of the box with minimal customisation but it wasn’t…” ♦ “We thought it was going really well until the half way through the customisations …” ♦ “We just couldn’t seem to get what we wanted…” ♦ “They kept changing their mind about what they wanted…” ♦ “We finally realised we were not going to complete the project next month…” ♦ ”It is the Supplier’s / Customer’s / Product’s fault…”. ERP implementations can be complex and challenging but there is no reason why these statements need to be heard. Typically they are a product of a misalignment between the supplier and customer expectations. Some of this misalignment may be due to inexperience, the incorrect approach or the use of inappropriate or inaccurate metrics to visibly track progress. Fundamental to a successful ERP implementation is mutual respect and trust between the supplier and the customer. When problems, or misalignments occur, and they often do, there must be a willingness to work jointly through the issues to a successful resolution regardless of who might be responsible. Many projects lose direction and enter into destructive blame cycles which at best slow progress and at worst may lead to litigation. Ideally a joint supplier and client implementation team should be used which has embedded within it key business representatives. These business secondees ought to help in developing the bridges between the project and the business to ensure that the ultimate goal of a successful implementation is met. Based on our experiences of ERP implementations, this paper highlights some of the common pitfalls which can occur during an implementation and aims to provide ways to increase the visibility of real progress and minimise the often painful situations when expectations are not met.
24 June 2005 Version 1.0
A guide to successful implementations
Page 3 of 19
2.
SOME COMMON PROBLEMS
This section outlines the some of the common situations which are faced during the implementation of an ERP solution which have a detrimental effect on progress and the success of the implementation.
2.1
Confusion over the project approach
On receiving the approval to proceed on an ERP project it is not uncommon for a supplier to move directly from the commercial proposal to detailed timescale planning, omitting to document or explain to the client the proposed approach or method which will be adopted on the project. These guiding principles are central to the successful management of the project but are often missed due to the perception that a detailed Gantt chart will be the cornerstone of effective project management throughout the project. Where there is no explicitly documented approach to the project: ♦ Project reporting structure will often be unclear which may lead to confusion in terms of reporting lines and escalation procedures. The consequence of this action will at best be a decrease in project efficiency and at worst inappropriate escalation of issues. ♦ Roles and responsibilities are not defined and as a result it is much more difficult for project team members to understand their remit and how they are able to support others across the project. A consequence of this is that individual team members may focus on what they think is important rather than the most appropriate area for the benefit of the overall project. ♦ The stages of the project including objectives, inputs and outputs will be unclear and as such there cannot be a consistent one team approach to ensuring the key deliverables are focused on. Often this can result in delays to sign off of deliverables or project stages ♦ The risk and issue management strategy may not be understood by all team members. As a result, risks and issues might not be raised in the most appropriate way or in a timely manner. The symptoms of an unclear project approach can manifest themselves in many ways but commonly they lead to frustration or confusion about roles both from the supplier and customer, which is detrimental to a “one team - one goal” project philosophy. This can also lead to a misalignment of expectations between client and supplier, resulting in lack of trust and co-operation.
2.2
Inadequate business process mapping
If no business process mapping is carried out, no baseline will be created against which to measure progress and to understand the required configuration and customisations. Without an agreed baseline to aim for there will be lack of focus around when the implementation is complete, invariably leading to project overruns. Documenting the business processes also enables the CRPs and testing to be focused and effective. In addition, without documenting the business processes which will need to be in place when the ERP solution moves into production, it is extremely difficult for the business to understand and adequately prepare for the business changes associated with the new solution. This lack of understanding can prove major barrier in preparing for Go-Live and being able to successfully utilise the system.
2.3
Inability to track configuration progress for the ERP system
This is a very common problem in many ERP projects. This situation arises if no one has identified what the end point of the system configuration needs to be. Key to identifying the “end point” is a need to have carried out business process mapping and identified the critical business flows through these processes. This activity will drive out the key “end to end” configuration requirements to satisfy the business needs. The inability to accurately track completion will invariably lead to overruns or confusion as to when the when the solution will actually be ready for testing or indeed be complete.
24 June 2005 Version 1.0
A guide to successful implementations
Page 4 of 19
2.4
Customisations
Customisations can be a complex dimension of an ERP solution as invariably the configuration and customisation will be interdependent. It is often the case that the consultancy resources focusing on the configuration and the technical resources focusing on the customisations work independently. As a result, modifications to the configuration to suit the business process can cause the failure of customisations. The project approach may be one of minimal customisation. If this is the case then the need for any customisation should be reviewed at key stages of the design phase. If customisations are to be minimised or the project has timescale or effort constraints then careful consideration should be given to adapting the business process towards the product rather than the product modified to suit the business process. In functionally rich ERP solutions the need for additional customisations should be carefully assessed. Often the requirement to customise may be driven from functionality from a legacy system which is redundant in the ERP solution. The real reason for a customisation should always be assessed and alternatives sought. Often the implementation of a complex customisation may either complicate future upgrades or potentially jeopardise support arrangements with the ERP product supplier.
2.5
Data Migration
An ERP solution implementation typically involves migrating business data from existing legacy systems and possibly paper based sources. This element of the project is often underestimated in terms of complexity and effort and unfortunately often only begins at a stage when the project is nearing the testing phases. Further, often the reason to focus on the migration at this stage is ensuring the business users have some “real” data to test against the solution. Pushing the data migration to later in the project can cause a period of frenetic activity as the team attempt to “shoe-horn” in the required business data. This invariably leads to the quality of data being compromised or other resources being diverted from other activities, causing delays in other areas. The results of this flurry of activity and the insertion of data errors or task delays can be a lack of trust from the business or unwillingness to use the new solution even if functionally correct.
2.6
Overruns in the build phase
Overruns in the build phases are very common in ERP projects and are intrinsically linked to the ability to track progress effectively. If there is no way to measure when a sub-system or critical process will be complete, or indeed correct, then the project is in real danger of overrunning as there is no way to measure when the end has been reached. Similarly if progress is not adequately tracked throughout the build phase then it is extremely difficult to make accurate judgements about strategies to bring the build phase back within required timescales or to make adjustments in phase plans. The identification of the key or critical business flows though the business processes combined with regular evaluations of progress provide the opportunity to track and validate the solution as it is being built.
2.7
Silo based teams lose sight of the “end to end” solution
It is not uncommon to have tens of staff working on the configuration for an ERP solution divided into specific business area based teams. With a project team invariably being driven hard towards tight deadlines is all too easy for members of the configuration teams to become focussed only on the contents of their own particular business area silo. A silo based focus will inevitably result in integration issues between the various business streams (for example, how an invoice gets created from a customer order) or the interrelation of customisations with configuration. This may cause significant downstream issues when the end to end solution is tested during CRPs or testing.
24 June 2005 Version 1.0
A guide to successful implementations
Page 5 of 19
2.8
Ongoing system maintenance costs higher than forecast
Even if the ERP project has been tightly managed in terms of scope it is still possible that the level of effort required for supporting the system in production use will be far greater than the original forecast. The only way to address this is to have regular production support reviews as the solution is designed and developed and compare these with the original estimates.
2.9
Changing Requirements over the lifecycle
ERP implementations can be lengthy processes and as a result the requirements from the business may change during the project lifecycle. As a result the project must be able to adapt appropriately to these changes but retain integrity of the design and build. If the business processes and associated requirements are not documented and baselined, the impact of any subsequent change in requirements will be hard to assess and may lead to unexpected delays or knock on effects in other areas of the project.
24 June 2005 Version 1.0
A guide to successful implementations
Page 6 of 19
3.
AN APPROACH TO SUCCESSFUL DELIVERY
This section focuses on the key elements which must be addressed in the successful delivery of an ERP project.
3.1
Approach and discipline
To ensure that the project approach is maintained it is important that a project quality plan or method document is produced. This document should explain to both the supplier and the customer what the principles of the approach are and how they will be implemented across the project. Dependent upon the size of the project this could vary from a short visual presentation, for small projects, which documents the phases of the project to a more substantial document with phases, objectives, product descriptions etc. The most important element of this document and the one which is most often forgotten about is the summary section which describes the underlying principles or main tenets of the project approach. This should be no longer than one or two paragraphs and be the guiding principle for the rest of the approach. For example:
“Due to financial and time constraints the fundamental tenet of the approach is to implement the ERP system with no customisations and minimal configuration” In this example, in a situation where the product operates one way and the business process requires another, the default approach should be to attempt to modify the business process to suit the product and not the product to the process. Of course, their may be situations when the product will need to be specially configured or customised but with an agreed approach in place everyone will be aware that this is an exception. The implications and any options to address this exception would need to be thoroughly investigated as it would invariably lead to an increase in time or effort.
3.2
Planning and Execution
All too often projects are started without proper consideration given to the supporting documentation required in addition to project Gantt chart. This documentation needs to contain an explanation of the project phases, milestones, dependencies, etc. This documentation is vital as it indicates the thinking behind the Gantt chart, should further explain the objectives of each phase and who will be responsible for the various milestones and dependencies. This supporting documentation leads to a far clearer understanding of the project between supplier and customer than would have been achieved only a Gantt were produced. Frequently a customer will ask for a fully resourced Gantt chart with hundreds of tasks stretching out over the lifetime of the project in the first days after kick off. This is an unrealistic expectation and does not allow the Project Manager thinking time to discuss, document and agree the best approach with the project team and their customer. Dependent upon project size it is likely to take several weeks to refine the Gantt chart from the commercial proposal to reflect reality and to provide the supporting documentation discussed above. By far the best approach after baselining the Gantt chart and supporting documentation is to operate a rolling 12 week window of detail within a phase where all resources, milestones and dependencies are tracked in detail. Beyond the 12 week window there will be a greater degree of uncertainty. None the less a schedule is required to provide a high level indication of activities to enable effective management of resources, milestones and dependencies. As the end of a phase or suitable planning milestone the detailed plan can be produced for the coming 12 weeks then beyond this at a higher level. This approach avoids the often massive overhead in maintaining detailed plans which address the entire project from early in the lifecycle and allows a rolling window of detail to be the focus of the planning team. A useful approach in the forward management of dependencies is to maintain a dependency log and use it as a management and communication tool.
24 June 2005 Version 1.0
A guide to successful implementations
Page 7 of 19
3.3
Attitude
Even with a documented project plan and method document in place it is all too easy for the project to turn into an “us and them” situation between the supplier and customer. This can quickly degenerate further into a blame culture which detracts from making progress and can be hugely wasteful in terms of management and technical time. This type of culture is often driven from, or can be exacerbated by, the commercial agreement between supplier and customer. The likelihood of a blame culture will be especially increased if the supplier is working to a fixed price contract. Having a no surprises policy as an integral part of the project method or approach is an effective mechanism to reduce the likelihood of problems arising in this area. Additionally a recognition that problems will occur and will need to be resolved jointly is critical to avoiding failure and at the worst case litigation. No matter how hard both supplier and customer focus on co-operative working there will undoubtedly be difficult issues which need to be faced during the project lifecycle. The aim is to have a successful project and that this will occasionally require both supplier and customer to be flexible enough to change their approach or view. In the end however, there is no replacement for effective team working between supplier and customer. This approach must be fostered at all levels within the project and actively communicated by Senior Management from both supplier and customer. Further, it is important to explicitly focus on finding the most appropriate strategy to improve effective team work and the development of trust between all parties.
3.4
Identifying Critical Business Processes
Often the business process mapping for the ERP project has been carried out and configuration and customisation work commences without a clear understanding of what the critical business processes actually are. This can lead to focus being put into lower priority areas and the need for the areas which have not been covered being addressed later in the project when their may not be time to focus on them properly. If the output of the business process mapping exercise is considered the “blue print” to the solution then the critical business processes within them represent the foundations on top of which the solution is built. The specific assessment of the critical business processes will obviously be dependent on the business sector and key drivers within the individual organisation. As an example the criteria to select the critical business processes may include: ♦ What are the high volume business processes? ♦ What are the major revenue generating processes? ♦ What are the processes which have the greatest impact on customer satisfaction? ♦ What are the areas which generate the highest profit? Once identified these critical business processes can be used as metrics against which to measure progress. The following table illustrates critical business processes using some generic selection criteria: Business Process Order taking Sales Invoicing Purchasing
24 June 2005 Version 1.0
Volume
aaa aaa aaa aa
Revenue
Customer Impact
Profit
aaa aaa
aaa
aaa aa A guide to successful implementations
Page 8 of 19
After applying the critical criteria against all of the business processes, a path through the total business processes will be identified and this will highlight the first processes to build and monitor. These critical business processes indicate the priority of the “end to end” solution. As these critical business processes are completed the other lower priority business processes can be addressed in the knowledge that the “end to end” solution will not be compromised. This way the solution is built “bottom up” and the risk of an incomplete solution being built in core areas of importance is reduced. Critical business processes will invariably cross over many business functions. A useful visual tool is to create a critical business process map. The path of the critical business processes through all of the end to end business flows is indicated by the bold line in the diagram below.
The critical business processes will indicate the focus for any Conference Room Pilots and subsequently acceptance of the system.
3.5
Suitably experienced functional staff with the correct attitude
It seems obvious to state that suitably qualified functional staff to configure the system are required on an ERP implementation but this must be combined with a positive “can do” attitude and excellent communication skills to increase the likelihood of success. The combination of technical and personal skills is required as it will be rare to have one member of the team who will have intimate knowledge of all of the modules which require configuration. To build the necessary configuration the members of the configuration team will therefore have to investigate, confer, discuss and complete the work based not only on their personal knowledge but also that of other team members. For a customer it is not always possible to identify when functional staff do not have the correct experience until it is too late and the project begins to overrun. One mechanism to mitigate this risk is to employ metrics based on the critical business flows which will demonstrate completeness of the solution. Very quickly these metrics combined with Conference Room Pilots will indicate the completeness of the solution and the abilities, or otherwise, of the functional team members. Ideally, a substantial proportion of the team should possess overlapping skills areas, addressing business, functional and technical perspectives.
3.6
Effective cross team communication
When the pressure is on the team to deliver it is all too easy for team members to develop a silo mentality. This may mean that the progress in their particular area of the project (e.g. Financials) looks good but does not allow the solution to be completed in an “end to end” manner.
24 June 2005 Version 1.0
A guide to successful implementations
Page 9 of 19
The Configuration Manager must meet regularly with their specific work stream leads to ensure progress is being made on the “end to end” solution in a cohesive manner. This is key as the configuration in one area of the systems will invariably be dependant upon the configuration in other system areas. Weekly progress reviews involving the Configuration Manager and Customisation Manager are key to address all the areas which may impact completeness of the solution. This also minimises any potential for disconnect between the configuration and customisation teams.
3.7
Combined customer/supplier teams
One of the ways to minimise the “us and them” mentality between customer and supplier is to have a team consisting of members from both the customer and supplier. Although it can involve considerable management effort from both the supplier and the customer the benefits of having business secondees on a project far outweigh any overheads. The benefits include: ♦ Expedites the ramp up of business knowledge within the customer’s business ♦ Provides detailed knowledge of any existing legacy systems ♦ Allows complementary business and implementation skills to be combined effectively ♦ Increases confidence in the business community ♦ De-risks the acceptance process as business members are in the team ♦ Allows a mechanism for succession planning and handover When planning to use resources from the customer it is important that an appropriate mechanism is in place to manage their business as usual commitments. This ensures that the resources seconded to the project are not impacted by continual requests to support business as usual. Business resources should be given a clear terms of reference which identifies what is expected of them, specific reporting lines within the project and how they should operate across the project.
3.8
Conference Room Pilots (CRPs)
CRPs are key to progressively validating the design, configuration and customisation activities and are used to demonstrate increased functionality within the solution throughout the build phase. The approach of a CRP can range from the project team presenting areas of the system to representatives from the business, in a theatre style arrangement, through to the business representatives actually performing job roles on the system, carrying out specific activities in a simulated environment. Each CRP should demonstrate an increase in functionality towards completeness of the “end to end” solution. By the final CRP a full “end to end” solution should be available for validation. For projects which have approached the implementation in a progressive manner it should only be a short step from the last CRP to final acceptance of the system. The diagram below shows how to introduce specific elements of functionality within a business process (for example, Customer Order through delivery to invoicing) and then introduce additional elements through the CRP process until the full end to end process is demonstrated in the final CRP. CRP1
CRP2
1
CRP3
1 2
1 2
2
3
3 4
5
5
7
7
4 5 6
First demonstrated in this CRP 24 June 2005 Version 1.0
7
First demonstrated in a previous CRP
A guide to successful implementations
Page 10 of 19
3.9
Issue or Observation tracking
In any ERP project there will be issues, observations or defects which must be tracked for effective management of the project. These items can easily derail a project if not managed properly and reviewed on a regular basis. For a medium sized ERP project it is likely that they may reach into the thousands but with appropriate prioritisation, categorisation and regular review this is easily manageable. The key assessment criteria in terms of managing issues are: ♦ How many have been opened? ♦ Which project categories are the issues in? ♦ What priorities do they have? ♦ What is the impact of fixing (or not fixing) these issues on work in progress? ♦ Are they being progressed – what is the status of the corresponding actions? ♦ How many have been closed? ♦ What is the closure rate? The diagram below presents a simple management metric of issues raised (in this case across all issue categories) by status over time. Simple reporting such as this can easily be extracted from issue tracking tools and give a very clear picture of key performance indicators.
1000 900 800 700 600 500 400 300 200 100 0
Total Resolved / Closed
07/05/2004 14/05/2004 21/05/2004 28/05/2004 04/06/2004 11/06/2004 18/06/2004 25/06/2004 02/07/2004 09/07/2004 16/07/2004 23/07/2004 30/07/2004 06/08/2004 13/08/2004 20/08/2004 27/08/2004 03/09/2004 10/09/2004 17/09/2004 24/09/2004 01/10/2004 08/10/2004 15/10/2004 22/10/2004 29/10/2004
Total
All - Total by Week and Status
Week
3.10
Effective and pragmatic risk management
Effective risk management is fundamental to the success of any project, or indeed any business venture. Ironically risk registers are often created at the start of the project and then become quickly obsolete and unchanged. Risk registers should be living documents throughout the project lifecycle and are a core mechanism to avoiding deviations from acceptable quality, costs, or timescale standards. It is the responsibility of all project team members to identify to the Project Manager (or Team Lead) any risks which may occur so that they can be managed centrally. Each risk should be categorised in terms of its likelihood (how likely is the risk to occur) and its consequence (what is the impact on the project/business if the risk does occur). Each risk should be managed by the risk owner and strategies to reduce the likelihood or consequence of the risk should be investigated, reviewed and agreed on. A simple matrix can by used to visually represent each risk and their relative position on the risk scale, as shown below:
24 June 2005 Version 1.0
A guide to successful implementations
Page 11 of 19
High Low
3
4
1
2
Low
High
The key to managing risks effectively, is to continually take a pragmatic approach and balance the risk likelihood/consequence mapping and the phases of the project lifecycle. High likelihood risks clearly need to be managed but bear in mind this high likelihood may be very far down the project lifecycle and as such might not actually require the immediate attention that a lower risk category may require. Regular review meetings with managers and stakeholders where decisions can be made relating to the management of risks are pivotal for managing risks effectively. There is all too often a blinkered view in ERP projects that everything will happen exactly according to the Gantt chart and that no risks will occur. This can cause major impact to the success of the project. Many risks identified will be manageable within the governance processes of the project. Occasionally, however, high risk items may be highlighted which are not under the control of the project.
3.11
Configuration
The most common method for evaluate completeness of the configuration is to measure modules configured in each of the business areas (e.g. Customer Service, Operations and Finance) and report back on a weekly basis. For a project that requires a relatively simple configuration and utilises a small team, this can be extremely effective for measuring progress. When the team becomes larger and the target configuration more complex this measurement technique can prove to be less effective.
24 June 2005 Version 1.0
A guide to successful implementations
Page 12 of 19
The diagram below presents a simple view for tracking configuration progress by module over time: 70
Total number of modules
60 50 40
Forecast completion Actual completion
30
Total number of modules
20
Apr-06
Mar-06
Jan-06
Feb-06
Dec-05
Oct-05
Nov-05
Sep-05
Jul-05
Aug-05
Jun-05
Apr-05
May-05
Mar-05
Jan-05
0
Feb-05
10
Unfortunately when the functional team size grows to the point where sub-teams are required, it becomes more of a challenge to retain a common view of the “end to end” solution. With functional sub-teams focussed on separate work streams the best configuration measure is to use completeness of the critical business flows. Once these are completed variants on these paths can then be introduced until the system is complete. The diagram below presents a view of tracking configuration progress by critical business process over time: 100 90 80
% Complete
70 60
Business flow 1
50
Business flow 2
40
Business flow 3
30 20 10
ar -0 6 M
Ja n06
N ov -0 5
Se p05
Ju l-0 5
05 ay M
ar -0 5 M
Ja n05
0
Using the critical business flows and a series of CRPs clarity in project progress can be realised.
24 June 2005 Version 1.0
A guide to successful implementations
Page 13 of 19
3.12
Customisation
In an ERP project the easiest component to track should be the completion of customisations. In addition to the use of a Gantt chart with milestones an orthogonal view should be sought which provides both the supplier and customer with a view of progress through the elements involved in the overall customisation activities. This could include: ♦ Functional Specifications complete ♦ Technical Specifications complete ♦ Build complete (which may be decomposed to include unit testing) ♦ Testing of build complete (which will be further expanded into full integration testing at later phases in the project) A simple tracking view for measuring customisations is illustrated in the following diagram: Customisation Testing 80
80
70
70
Complete or approved
60 50 40 30 20 10
60 50 40 30 20 10
Plan
Actual/Forecast
Actual/Forecast
01/10/2004
03/09/2004
20/08/2004
06/08/2004
23/07/2004
09/07/2004
Plan
Total
Customisation 1 2 3 4 5 6 7 8 9 10 11 12
25/06/2004
11/06/2004
28/05/2004
14/05/2004
01/10/2004
0
17/09/2004
03/09/2004
20/08/2004
06/08/2004
23/07/2004
09/07/2004
25/06/2004
11/06/2004
28/05/2004
14/05/2004
0
17/09/2004
Complete or approved
Functional Specifications
Total
FS Approved
TS Build Test Not Required Not Required Not Required Complete Complete Complete Not Started Complete
Complete
Started
Complete
Started
Not Started
Approved Approved
Not Started
Not Started Not Required Not Required Not Required Approved Complete Started
Approved
Approved
Started
Approved
Approved
Complete
Started
Approved
Approved
Approved
Approved
Approved Approved Approved
Not Required Not Required Complete
Complete
Not Required Not Required
Not Started
Started Not Started Started
A key area to monitor with any customisation is the level of interdependency with configuration activities. Typically with ERP solution customisations there is a two way relationship with configuration: ♦ Customisations may be dependent on specific configuration activities being performed on the system in order to function correctly and changes to this configuration may impact on whether the customisation will continue to function ♦ Configuration activities may require customisations to be in place in order to complete the configuration The key is to monitor customisations and configurations in relation to each other and ensure any interdependent activities can be completed in a timely manner.
24 June 2005 Version 1.0
A guide to successful implementations
Page 14 of 19
3.13
Testing
The testing of an ERP system needs to be planned from the outset. The main components to be tested will be driven by the requirements and business process mapping. Ultimately the success and suitability of the solution is driven by the translation of the business processes into the functionality which will be provided by the ERP system. As soon as the business processes are baselined and the critical processes identified the method or approach to testing should be focused on in detail. The testing needs can then be progressively validated through execution of the CRPs and ultimately Acceptance Testing. The following diagram illustrates the relationship between all of the business processes, the critical business flows, their steps and the necessary test cases. It can be extremely beneficial to construct test cases which address any risks associated with the critical business flows. Custome r Service Processe s
Operations Processes
Finance Processe s
N
Customer Service Processes
Operation s Processes
Finance Processes
N
Test step 1 Test step 2 Test step 3 Test step 4 Test step 5
24 June 2005 Version 1.0
A guide to successful implementations
Expected Outcome 1 Expected Outcome 2 Expected Outcome 3 Expected Outcome 4 Expected Outcome 5
Page 15 of 19
3.14
Fallback or contingency planning
Whatever the size of ERP project a fallback or contingency plan will be required which provides options should any key component of the new solution be late or absent. Contingency plan should first be developed on completion of the business process mapping and the high level design. At this point it will be clear where the key elements of the solution are located and what would be required at a high level for a successful launch should they not be available. The contingency plan should then be revisited after each CRP where input from the business will highlight or provide additional operational information regarding the importance of various elements of the solution. Having progressively refined and actively maintained a contingency plan will make it easier for all or any aspects of the plan to be introduced should it be needed. The most likely case will be the need for a contingency area where there has been a delay in the completion of a particular aspect of the solution but a launch date must be maintained.
3.15
The point of no return
Regardless of integrity of the approach, the metrics used or the best or practice there will come a point close to the end of the ERP development when the 90% complete syndrome is reached. The completeness of the solution seems to stick at 90% (or less) and can’t seem to get any further. This usually happens when a board committed launch date may have already been moved (possibly more than once) and one more move would mean a loss of credibility for the supplier and for the customer and more than likely involve a substantial increase in funding. This “point of no return” is reached by many ERP projects. Committing to a launch date with the system being incomplete in some areas can introduce excessive risk to an implementation but, if the areas are well understood, it can surprisingly inject momentum to drive the project team and the business towards success. If the incomplete areas are understood then the risks can be mitigated to some extent by maintaining a longer presence of the on-site team post Go Live.
3.16
The first months post launch
Be under no illusion - the first months post launch for an ERP project will be hectic. It falls on both supplier and customer to remain calm and work through the problems which occur. Even with the best change management activities in place there will still be cultural and technical problems to resolve. It is absolutely key that the project team and management from the supplier and customer present a “combined front” and common willingness to address the issues which may arise in a non confrontational manner. It will be hard work and may be emotionally draining but with a commitment from all sides challenges are surmountable. The implementation of a new ERP solution will be a large change for the users as typically they will have been using the existing legacy systems for some time. To manage this change effectively, the likely fluctuations in morale for the users need to be considered and indeed explained to them during early training sessions to enable all parties to act appropriately. The level of resistance to change and wish for the “old system” to remain will vary from user to user and can be addressed over time. This must be closely monitored by the project team and quickly addressed to avoid wider reductions in morale across the user community. Regular reminders of the business benefit to both the user community and the management stakeholders will assist in the transition to the new ERP solution.
24 June 2005 Version 1.0
A guide to successful implementations
Page 16 of 19
The likely fluctuations in morale of the user community are illustrated in the following diagram. System Go Live
Performing
Morale
Excitement Real Learning
Realisation Shock
Acceptance Fear Doubt
Time
Critical to project success is ensuring the business resources are adequately prepared before the go-live and appropriately supported post go-live. Expectation must be clearly managed within the organisation in terms of what will be achieved during this go-live period. Often organisations expect the benefits of the new system to be realised on the first day and often forget that for the users some time will be needed to “bed in” the system and potential new working practices.
3.17
Stress Management and ERP projects
All projects have their own levels of stress. The challenge for the supplier and customer is to aspire to a situation where the project team and the business are challenged just enough. The level of stress the team is working under has a direct relationship with both individual and team productivity. As shown in the diagram below, if the team are not effectively challenged, a “Rust Out” situation will occur, where the team are not productive due to a lack of challenge. Similarly, if the level of stress imposed on the team if too high, productivity will reduce as the team will be unable to complete all the required activities either to the desired level of quality or in the appropriate time frame and a “Burn Out” situation will occur. In both these cases the likelihood of absenteeism due to recurring illness may increase and have a direct impact on productivity. The optimal situation is reached with an appropriate level of challenge imposed on the team and individuals to ensure “Peak Productivity” is reached and maintained.
Peak Productivity
Rust Out
Burn Out Stress Level
24 June 2005 Version 1.0
A guide to successful implementations
Page 17 of 19
It is well worth discussing stress management within the project and for individuals to consider their own coping strategies. It is especially worth highlighting that everyone handles stress differently and may have completely different ways of coping with it. As such the project must be responsive to the needs of the individual and ensure they have the appropriate level of both challenge and support required.
24 June 2005 Version 1.0
A guide to successful implementations
Page 18 of 19
4.
CONCLUSIONS
ERP projects are notoriously difficult to manage to time and /or budget. The reasons for this are many but they can be categorised into several key areas: ♦ Approach and discipline – If the intention is to implement the core ERP product with minimal configuration and customisation then this approach must be adhered to. As a result the business processes may have to be “bent” to suit the product rather than bending the product to the business. In the event that unplanned customisations are identified the need for these must be considered carefully and if a customisation is contrary to the approach an appropriate cost/benefit exercise undertaken and a detailed impact analysis presented to the management team. ♦ Comprehensive design and testing in areas which are non standard – The design and test must be focused on any areas which need to be specially customised or require an unusual configuration. Areas which have been modified will almost always require more effort to get right than were originally estimated. Create specific workshops to refine the design in these areas and use trial and error with the ERP product until the design and its implications are fully understood. ERP products are so functionally rich that it will be unusual if one or even several members of the implementation team will understand all the subtleties of the product when it is being modified. ♦ Iterations and compliance – In developing an ERP solution, even one with minimal customisations and standard configuration it is worth recognising that it will require several iterations to arrive at the most appropriate solution for the business. Neither the supplier nor the customer should expect it all to be perfect first time. Understanding this and working with the project team to focus on building from a minimally compliant solution which addresses most business cases is far better than trying to satisfy every case from the outset. This approach also mitigates against the risk of one area stopping the entire project. ♦ Conference Room Pilots – These are key in both validating the solution and ensuring business buy in. A plan to run three CRPs usually strikes the correct balance between completing build work and the need to remove business personnel for the validation of progress. Any more will become an excessive intrusion into the business and actually be detrimental to progress. ♦ Metrics and tracking – This is often a hard to get right on an ERP project. This paper has discussed some options in this area but the priority must be on tracking the completion of critical business processes. ♦ Contingency or fallback planning – Even on the best managed ERP projects the unexpected will happen which may have a serious impact on the project timeline. A contingency or fallback plan ought to be created as early as is feasible, kept current and be ready for execution as required. ♦ Expectations in the first month after go live – The first months post go-live will be hectic and prone for heightened emotion. There needs to be an awareness and sensitivity from all sides and a that there will be a common will to succeed and that this success may require unexpected and perhaps manual workarounds in the early days post go live. ♦ Ongoing maintenance – Unless reviewed at key design points on the project it is highly likely that the ongoing maintenance effort estimates will be higher than originally envisaged. The area of post live support must therefore be reviewed at the end of the design stage and at the end of each of the CRPs to ensure that it is still aligned with expectations. It is unfortunately very easy to allow the design to become more complicated and the level of on-going support not properly understood until after the system has gone live.
24 June 2005 Version 1.0
A guide to successful implementations
Page 19 of 19
A guide to successful implementations Version 1.0 Craig Scollick & Ed Estaugh 24 June 2005
2005 Charteris plc
CONTENTS CONTENTS
2
1.
INTRODUCTION
3
2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
SOME COMMON PROBLEMS Confusion over the project approach Inadequate business process mapping Inability to track configuration progress for the ERP system Customisations Data Migration Overruns in the build phase Silo based teams lose sight of the “end to end” solution Ongoing system maintenance costs higher than forecast Changing Requirements over the lifecycle
4 4 4 5 5 5 6 6 6 6
3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17
AN APPROACH TO SUCCESSFUL DELIVERY Approach and discipline Planning and Execution Attitude Identifying Critical Business Processes Suitably experienced functional staff with the correct attitude Effective cross team communication Combined customer/supplier teams Conference Room Pilots (CRPs) Issue or Observation tracking Effective and pragmatic risk management Configuration Customisation Testing Fallback or contingency planning The point of no return The first months post launch Stress Management and ERP projects
7 7 7 8 8 10 10 11 11 12 13 14 16 17 19 19 19 20
4.
CONCLUSIONS
22
24 June 2005 Version 1.0
A guide to successful implementations
Page 2 of 19
1.
INTRODUCTION
ERP implementation projects are notorious for financial and/or timescale overruns. This paper aims to identify common reasons why overruns occur and makes practical suggestions as to how organisations can ensure their approach maximises the probability of success within the necessary time and budget constraints. There is a common myth that an ERP project is somehow different from other types of IT project. This is not the case. If the implementation is approached in a structured manner, using an agreed approach, employing suitably experienced staff, utilising appropriate management metrics with supplier and customer working in a spirit of cooperation it is highly likely to succeed. If any of these high level factors are not in place then the probability of success will decrease. The following statements are often used by both suppliers and customers during ERP implementations: ♦ “They said it would be out of the box with minimal customisation but it wasn’t…” ♦ “We thought it was going really well until the half way through the customisations …” ♦ “We just couldn’t seem to get what we wanted…” ♦ “They kept changing their mind about what they wanted…” ♦ “We finally realised we were not going to complete the project next month…” ♦ ”It is the Supplier’s / Customer’s / Product’s fault…”. ERP implementations can be complex and challenging but there is no reason why these statements need to be heard. Typically they are a product of a misalignment between the supplier and customer expectations. Some of this misalignment may be due to inexperience, the incorrect approach or the use of inappropriate or inaccurate metrics to visibly track progress. Fundamental to a successful ERP implementation is mutual respect and trust between the supplier and the customer. When problems, or misalignments occur, and they often do, there must be a willingness to work jointly through the issues to a successful resolution regardless of who might be responsible. Many projects lose direction and enter into destructive blame cycles which at best slow progress and at worst may lead to litigation. Ideally a joint supplier and client implementation team should be used which has embedded within it key business representatives. These business secondees ought to help in developing the bridges between the project and the business to ensure that the ultimate goal of a successful implementation is met. Based on our experiences of ERP implementations, this paper highlights some of the common pitfalls which can occur during an implementation and aims to provide ways to increase the visibility of real progress and minimise the often painful situations when expectations are not met.
24 June 2005 Version 1.0
A guide to successful implementations
Page 3 of 19
2.
SOME COMMON PROBLEMS
This section outlines the some of the common situations which are faced during the implementation of an ERP solution which have a detrimental effect on progress and the success of the implementation.
2.1
Confusion over the project approach
On receiving the approval to proceed on an ERP project it is not uncommon for a supplier to move directly from the commercial proposal to detailed timescale planning, omitting to document or explain to the client the proposed approach or method which will be adopted on the project. These guiding principles are central to the successful management of the project but are often missed due to the perception that a detailed Gantt chart will be the cornerstone of effective project management throughout the project. Where there is no explicitly documented approach to the project: ♦ Project reporting structure will often be unclear which may lead to confusion in terms of reporting lines and escalation procedures. The consequence of this action will at best be a decrease in project efficiency and at worst inappropriate escalation of issues. ♦ Roles and responsibilities are not defined and as a result it is much more difficult for project team members to understand their remit and how they are able to support others across the project. A consequence of this is that individual team members may focus on what they think is important rather than the most appropriate area for the benefit of the overall project. ♦ The stages of the project including objectives, inputs and outputs will be unclear and as such there cannot be a consistent one team approach to ensuring the key deliverables are focused on. Often this can result in delays to sign off of deliverables or project stages ♦ The risk and issue management strategy may not be understood by all team members. As a result, risks and issues might not be raised in the most appropriate way or in a timely manner. The symptoms of an unclear project approach can manifest themselves in many ways but commonly they lead to frustration or confusion about roles both from the supplier and customer, which is detrimental to a “one team - one goal” project philosophy. This can also lead to a misalignment of expectations between client and supplier, resulting in lack of trust and co-operation.
2.2
Inadequate business process mapping
If no business process mapping is carried out, no baseline will be created against which to measure progress and to understand the required configuration and customisations. Without an agreed baseline to aim for there will be lack of focus around when the implementation is complete, invariably leading to project overruns. Documenting the business processes also enables the CRPs and testing to be focused and effective. In addition, without documenting the business processes which will need to be in place when the ERP solution moves into production, it is extremely difficult for the business to understand and adequately prepare for the business changes associated with the new solution. This lack of understanding can prove major barrier in preparing for Go-Live and being able to successfully utilise the system.
2.3
Inability to track configuration progress for the ERP system
This is a very common problem in many ERP projects. This situation arises if no one has identified what the end point of the system configuration needs to be. Key to identifying the “end point” is a need to have carried out business process mapping and identified the critical business flows through these processes. This activity will drive out the key “end to end” configuration requirements to satisfy the business needs. The inability to accurately track completion will invariably lead to overruns or confusion as to when the when the solution will actually be ready for testing or indeed be complete.
24 June 2005 Version 1.0
A guide to successful implementations
Page 4 of 19
2.4
Customisations
Customisations can be a complex dimension of an ERP solution as invariably the configuration and customisation will be interdependent. It is often the case that the consultancy resources focusing on the configuration and the technical resources focusing on the customisations work independently. As a result, modifications to the configuration to suit the business process can cause the failure of customisations. The project approach may be one of minimal customisation. If this is the case then the need for any customisation should be reviewed at key stages of the design phase. If customisations are to be minimised or the project has timescale or effort constraints then careful consideration should be given to adapting the business process towards the product rather than the product modified to suit the business process. In functionally rich ERP solutions the need for additional customisations should be carefully assessed. Often the requirement to customise may be driven from functionality from a legacy system which is redundant in the ERP solution. The real reason for a customisation should always be assessed and alternatives sought. Often the implementation of a complex customisation may either complicate future upgrades or potentially jeopardise support arrangements with the ERP product supplier.
2.5
Data Migration
An ERP solution implementation typically involves migrating business data from existing legacy systems and possibly paper based sources. This element of the project is often underestimated in terms of complexity and effort and unfortunately often only begins at a stage when the project is nearing the testing phases. Further, often the reason to focus on the migration at this stage is ensuring the business users have some “real” data to test against the solution. Pushing the data migration to later in the project can cause a period of frenetic activity as the team attempt to “shoe-horn” in the required business data. This invariably leads to the quality of data being compromised or other resources being diverted from other activities, causing delays in other areas. The results of this flurry of activity and the insertion of data errors or task delays can be a lack of trust from the business or unwillingness to use the new solution even if functionally correct.
2.6
Overruns in the build phase
Overruns in the build phases are very common in ERP projects and are intrinsically linked to the ability to track progress effectively. If there is no way to measure when a sub-system or critical process will be complete, or indeed correct, then the project is in real danger of overrunning as there is no way to measure when the end has been reached. Similarly if progress is not adequately tracked throughout the build phase then it is extremely difficult to make accurate judgements about strategies to bring the build phase back within required timescales or to make adjustments in phase plans. The identification of the key or critical business flows though the business processes combined with regular evaluations of progress provide the opportunity to track and validate the solution as it is being built.
2.7
Silo based teams lose sight of the “end to end” solution
It is not uncommon to have tens of staff working on the configuration for an ERP solution divided into specific business area based teams. With a project team invariably being driven hard towards tight deadlines is all too easy for members of the configuration teams to become focussed only on the contents of their own particular business area silo. A silo based focus will inevitably result in integration issues between the various business streams (for example, how an invoice gets created from a customer order) or the interrelation of customisations with configuration. This may cause significant downstream issues when the end to end solution is tested during CRPs or testing.
24 June 2005 Version 1.0
A guide to successful implementations
Page 5 of 19
2.8
Ongoing system maintenance costs higher than forecast
Even if the ERP project has been tightly managed in terms of scope it is still possible that the level of effort required for supporting the system in production use will be far greater than the original forecast. The only way to address this is to have regular production support reviews as the solution is designed and developed and compare these with the original estimates.
2.9
Changing Requirements over the lifecycle
ERP implementations can be lengthy processes and as a result the requirements from the business may change during the project lifecycle. As a result the project must be able to adapt appropriately to these changes but retain integrity of the design and build. If the business processes and associated requirements are not documented and baselined, the impact of any subsequent change in requirements will be hard to assess and may lead to unexpected delays or knock on effects in other areas of the project.
24 June 2005 Version 1.0
A guide to successful implementations
Page 6 of 19
3.
AN APPROACH TO SUCCESSFUL DELIVERY
This section focuses on the key elements which must be addressed in the successful delivery of an ERP project.
3.1
Approach and discipline
To ensure that the project approach is maintained it is important that a project quality plan or method document is produced. This document should explain to both the supplier and the customer what the principles of the approach are and how they will be implemented across the project. Dependent upon the size of the project this could vary from a short visual presentation, for small projects, which documents the phases of the project to a more substantial document with phases, objectives, product descriptions etc. The most important element of this document and the one which is most often forgotten about is the summary section which describes the underlying principles or main tenets of the project approach. This should be no longer than one or two paragraphs and be the guiding principle for the rest of the approach. For example:
“Due to financial and time constraints the fundamental tenet of the approach is to implement the ERP system with no customisations and minimal configuration” In this example, in a situation where the product operates one way and the business process requires another, the default approach should be to attempt to modify the business process to suit the product and not the product to the process. Of course, their may be situations when the product will need to be specially configured or customised but with an agreed approach in place everyone will be aware that this is an exception. The implications and any options to address this exception would need to be thoroughly investigated as it would invariably lead to an increase in time or effort.
3.2
Planning and Execution
All too often projects are started without proper consideration given to the supporting documentation required in addition to project Gantt chart. This documentation needs to contain an explanation of the project phases, milestones, dependencies, etc. This documentation is vital as it indicates the thinking behind the Gantt chart, should further explain the objectives of each phase and who will be responsible for the various milestones and dependencies. This supporting documentation leads to a far clearer understanding of the project between supplier and customer than would have been achieved only a Gantt were produced. Frequently a customer will ask for a fully resourced Gantt chart with hundreds of tasks stretching out over the lifetime of the project in the first days after kick off. This is an unrealistic expectation and does not allow the Project Manager thinking time to discuss, document and agree the best approach with the project team and their customer. Dependent upon project size it is likely to take several weeks to refine the Gantt chart from the commercial proposal to reflect reality and to provide the supporting documentation discussed above. By far the best approach after baselining the Gantt chart and supporting documentation is to operate a rolling 12 week window of detail within a phase where all resources, milestones and dependencies are tracked in detail. Beyond the 12 week window there will be a greater degree of uncertainty. None the less a schedule is required to provide a high level indication of activities to enable effective management of resources, milestones and dependencies. As the end of a phase or suitable planning milestone the detailed plan can be produced for the coming 12 weeks then beyond this at a higher level. This approach avoids the often massive overhead in maintaining detailed plans which address the entire project from early in the lifecycle and allows a rolling window of detail to be the focus of the planning team. A useful approach in the forward management of dependencies is to maintain a dependency log and use it as a management and communication tool.
24 June 2005 Version 1.0
A guide to successful implementations
Page 7 of 19
3.3
Attitude
Even with a documented project plan and method document in place it is all too easy for the project to turn into an “us and them” situation between the supplier and customer. This can quickly degenerate further into a blame culture which detracts from making progress and can be hugely wasteful in terms of management and technical time. This type of culture is often driven from, or can be exacerbated by, the commercial agreement between supplier and customer. The likelihood of a blame culture will be especially increased if the supplier is working to a fixed price contract. Having a no surprises policy as an integral part of the project method or approach is an effective mechanism to reduce the likelihood of problems arising in this area. Additionally a recognition that problems will occur and will need to be resolved jointly is critical to avoiding failure and at the worst case litigation. No matter how hard both supplier and customer focus on co-operative working there will undoubtedly be difficult issues which need to be faced during the project lifecycle. The aim is to have a successful project and that this will occasionally require both supplier and customer to be flexible enough to change their approach or view. In the end however, there is no replacement for effective team working between supplier and customer. This approach must be fostered at all levels within the project and actively communicated by Senior Management from both supplier and customer. Further, it is important to explicitly focus on finding the most appropriate strategy to improve effective team work and the development of trust between all parties.
3.4
Identifying Critical Business Processes
Often the business process mapping for the ERP project has been carried out and configuration and customisation work commences without a clear understanding of what the critical business processes actually are. This can lead to focus being put into lower priority areas and the need for the areas which have not been covered being addressed later in the project when their may not be time to focus on them properly. If the output of the business process mapping exercise is considered the “blue print” to the solution then the critical business processes within them represent the foundations on top of which the solution is built. The specific assessment of the critical business processes will obviously be dependent on the business sector and key drivers within the individual organisation. As an example the criteria to select the critical business processes may include: ♦ What are the high volume business processes? ♦ What are the major revenue generating processes? ♦ What are the processes which have the greatest impact on customer satisfaction? ♦ What are the areas which generate the highest profit? Once identified these critical business processes can be used as metrics against which to measure progress. The following table illustrates critical business processes using some generic selection criteria: Business Process Order taking Sales Invoicing Purchasing
24 June 2005 Version 1.0
Volume
aaa aaa aaa aa
Revenue
Customer Impact
Profit
aaa aaa
aaa
aaa aa A guide to successful implementations
Page 8 of 19
After applying the critical criteria against all of the business processes, a path through the total business processes will be identified and this will highlight the first processes to build and monitor. These critical business processes indicate the priority of the “end to end” solution. As these critical business processes are completed the other lower priority business processes can be addressed in the knowledge that the “end to end” solution will not be compromised. This way the solution is built “bottom up” and the risk of an incomplete solution being built in core areas of importance is reduced. Critical business processes will invariably cross over many business functions. A useful visual tool is to create a critical business process map. The path of the critical business processes through all of the end to end business flows is indicated by the bold line in the diagram below.
The critical business processes will indicate the focus for any Conference Room Pilots and subsequently acceptance of the system.
3.5
Suitably experienced functional staff with the correct attitude
It seems obvious to state that suitably qualified functional staff to configure the system are required on an ERP implementation but this must be combined with a positive “can do” attitude and excellent communication skills to increase the likelihood of success. The combination of technical and personal skills is required as it will be rare to have one member of the team who will have intimate knowledge of all of the modules which require configuration. To build the necessary configuration the members of the configuration team will therefore have to investigate, confer, discuss and complete the work based not only on their personal knowledge but also that of other team members. For a customer it is not always possible to identify when functional staff do not have the correct experience until it is too late and the project begins to overrun. One mechanism to mitigate this risk is to employ metrics based on the critical business flows which will demonstrate completeness of the solution. Very quickly these metrics combined with Conference Room Pilots will indicate the completeness of the solution and the abilities, or otherwise, of the functional team members. Ideally, a substantial proportion of the team should possess overlapping skills areas, addressing business, functional and technical perspectives.
3.6
Effective cross team communication
When the pressure is on the team to deliver it is all too easy for team members to develop a silo mentality. This may mean that the progress in their particular area of the project (e.g. Financials) looks good but does not allow the solution to be completed in an “end to end” manner.
24 June 2005 Version 1.0
A guide to successful implementations
Page 9 of 19
The Configuration Manager must meet regularly with their specific work stream leads to ensure progress is being made on the “end to end” solution in a cohesive manner. This is key as the configuration in one area of the systems will invariably be dependant upon the configuration in other system areas. Weekly progress reviews involving the Configuration Manager and Customisation Manager are key to address all the areas which may impact completeness of the solution. This also minimises any potential for disconnect between the configuration and customisation teams.
3.7
Combined customer/supplier teams
One of the ways to minimise the “us and them” mentality between customer and supplier is to have a team consisting of members from both the customer and supplier. Although it can involve considerable management effort from both the supplier and the customer the benefits of having business secondees on a project far outweigh any overheads. The benefits include: ♦ Expedites the ramp up of business knowledge within the customer’s business ♦ Provides detailed knowledge of any existing legacy systems ♦ Allows complementary business and implementation skills to be combined effectively ♦ Increases confidence in the business community ♦ De-risks the acceptance process as business members are in the team ♦ Allows a mechanism for succession planning and handover When planning to use resources from the customer it is important that an appropriate mechanism is in place to manage their business as usual commitments. This ensures that the resources seconded to the project are not impacted by continual requests to support business as usual. Business resources should be given a clear terms of reference which identifies what is expected of them, specific reporting lines within the project and how they should operate across the project.
3.8
Conference Room Pilots (CRPs)
CRPs are key to progressively validating the design, configuration and customisation activities and are used to demonstrate increased functionality within the solution throughout the build phase. The approach of a CRP can range from the project team presenting areas of the system to representatives from the business, in a theatre style arrangement, through to the business representatives actually performing job roles on the system, carrying out specific activities in a simulated environment. Each CRP should demonstrate an increase in functionality towards completeness of the “end to end” solution. By the final CRP a full “end to end” solution should be available for validation. For projects which have approached the implementation in a progressive manner it should only be a short step from the last CRP to final acceptance of the system. The diagram below shows how to introduce specific elements of functionality within a business process (for example, Customer Order through delivery to invoicing) and then introduce additional elements through the CRP process until the full end to end process is demonstrated in the final CRP. CRP1
CRP2
1
CRP3
1 2
1 2
2
3
3 4
5
5
7
7
4 5 6
First demonstrated in this CRP 24 June 2005 Version 1.0
7
First demonstrated in a previous CRP
A guide to successful implementations
Page 10 of 19
3.9
Issue or Observation tracking
In any ERP project there will be issues, observations or defects which must be tracked for effective management of the project. These items can easily derail a project if not managed properly and reviewed on a regular basis. For a medium sized ERP project it is likely that they may reach into the thousands but with appropriate prioritisation, categorisation and regular review this is easily manageable. The key assessment criteria in terms of managing issues are: ♦ How many have been opened? ♦ Which project categories are the issues in? ♦ What priorities do they have? ♦ What is the impact of fixing (or not fixing) these issues on work in progress? ♦ Are they being progressed – what is the status of the corresponding actions? ♦ How many have been closed? ♦ What is the closure rate? The diagram below presents a simple management metric of issues raised (in this case across all issue categories) by status over time. Simple reporting such as this can easily be extracted from issue tracking tools and give a very clear picture of key performance indicators.
1000 900 800 700 600 500 400 300 200 100 0
Total Resolved / Closed
07/05/2004 14/05/2004 21/05/2004 28/05/2004 04/06/2004 11/06/2004 18/06/2004 25/06/2004 02/07/2004 09/07/2004 16/07/2004 23/07/2004 30/07/2004 06/08/2004 13/08/2004 20/08/2004 27/08/2004 03/09/2004 10/09/2004 17/09/2004 24/09/2004 01/10/2004 08/10/2004 15/10/2004 22/10/2004 29/10/2004
Total
All - Total by Week and Status
Week
3.10
Effective and pragmatic risk management
Effective risk management is fundamental to the success of any project, or indeed any business venture. Ironically risk registers are often created at the start of the project and then become quickly obsolete and unchanged. Risk registers should be living documents throughout the project lifecycle and are a core mechanism to avoiding deviations from acceptable quality, costs, or timescale standards. It is the responsibility of all project team members to identify to the Project Manager (or Team Lead) any risks which may occur so that they can be managed centrally. Each risk should be categorised in terms of its likelihood (how likely is the risk to occur) and its consequence (what is the impact on the project/business if the risk does occur). Each risk should be managed by the risk owner and strategies to reduce the likelihood or consequence of the risk should be investigated, reviewed and agreed on. A simple matrix can by used to visually represent each risk and their relative position on the risk scale, as shown below:
24 June 2005 Version 1.0
A guide to successful implementations
Page 11 of 19
High Low
3
4
1
2
Low
High
The key to managing risks effectively, is to continually take a pragmatic approach and balance the risk likelihood/consequence mapping and the phases of the project lifecycle. High likelihood risks clearly need to be managed but bear in mind this high likelihood may be very far down the project lifecycle and as such might not actually require the immediate attention that a lower risk category may require. Regular review meetings with managers and stakeholders where decisions can be made relating to the management of risks are pivotal for managing risks effectively. There is all too often a blinkered view in ERP projects that everything will happen exactly according to the Gantt chart and that no risks will occur. This can cause major impact to the success of the project. Many risks identified will be manageable within the governance processes of the project. Occasionally, however, high risk items may be highlighted which are not under the control of the project.
3.11
Configuration
The most common method for evaluate completeness of the configuration is to measure modules configured in each of the business areas (e.g. Customer Service, Operations and Finance) and report back on a weekly basis. For a project that requires a relatively simple configuration and utilises a small team, this can be extremely effective for measuring progress. When the team becomes larger and the target configuration more complex this measurement technique can prove to be less effective.
24 June 2005 Version 1.0
A guide to successful implementations
Page 12 of 19
The diagram below presents a simple view for tracking configuration progress by module over time: 70
Total number of modules
60 50 40
Forecast completion Actual completion
30
Total number of modules
20
Apr-06
Mar-06
Jan-06
Feb-06
Dec-05
Oct-05
Nov-05
Sep-05
Jul-05
Aug-05
Jun-05
Apr-05
May-05
Mar-05
Jan-05
0
Feb-05
10
Unfortunately when the functional team size grows to the point where sub-teams are required, it becomes more of a challenge to retain a common view of the “end to end” solution. With functional sub-teams focussed on separate work streams the best configuration measure is to use completeness of the critical business flows. Once these are completed variants on these paths can then be introduced until the system is complete. The diagram below presents a view of tracking configuration progress by critical business process over time: 100 90 80
% Complete
70 60
Business flow 1
50
Business flow 2
40
Business flow 3
30 20 10
ar -0 6 M
Ja n06
N ov -0 5
Se p05
Ju l-0 5
05 ay M
ar -0 5 M
Ja n05
0
Using the critical business flows and a series of CRPs clarity in project progress can be realised.
24 June 2005 Version 1.0
A guide to successful implementations
Page 13 of 19
3.12
Customisation
In an ERP project the easiest component to track should be the completion of customisations. In addition to the use of a Gantt chart with milestones an orthogonal view should be sought which provides both the supplier and customer with a view of progress through the elements involved in the overall customisation activities. This could include: ♦ Functional Specifications complete ♦ Technical Specifications complete ♦ Build complete (which may be decomposed to include unit testing) ♦ Testing of build complete (which will be further expanded into full integration testing at later phases in the project) A simple tracking view for measuring customisations is illustrated in the following diagram: Customisation Testing 80
80
70
70
Complete or approved
60 50 40 30 20 10
60 50 40 30 20 10
Plan
Actual/Forecast
Actual/Forecast
01/10/2004
03/09/2004
20/08/2004
06/08/2004
23/07/2004
09/07/2004
Plan
Total
Customisation 1 2 3 4 5 6 7 8 9 10 11 12
25/06/2004
11/06/2004
28/05/2004
14/05/2004
01/10/2004
0
17/09/2004
03/09/2004
20/08/2004
06/08/2004
23/07/2004
09/07/2004
25/06/2004
11/06/2004
28/05/2004
14/05/2004
0
17/09/2004
Complete or approved
Functional Specifications
Total
FS Approved
TS Build Test Not Required Not Required Not Required Complete Complete Complete Not Started Complete
Complete
Started
Complete
Started
Not Started
Approved Approved
Not Started
Not Started Not Required Not Required Not Required Approved Complete Started
Approved
Approved
Started
Approved
Approved
Complete
Started
Approved
Approved
Approved
Approved
Approved Approved Approved
Not Required Not Required Complete
Complete
Not Required Not Required
Not Started
Started Not Started Started
A key area to monitor with any customisation is the level of interdependency with configuration activities. Typically with ERP solution customisations there is a two way relationship with configuration: ♦ Customisations may be dependent on specific configuration activities being performed on the system in order to function correctly and changes to this configuration may impact on whether the customisation will continue to function ♦ Configuration activities may require customisations to be in place in order to complete the configuration The key is to monitor customisations and configurations in relation to each other and ensure any interdependent activities can be completed in a timely manner.
24 June 2005 Version 1.0
A guide to successful implementations
Page 14 of 19
3.13
Testing
The testing of an ERP system needs to be planned from the outset. The main components to be tested will be driven by the requirements and business process mapping. Ultimately the success and suitability of the solution is driven by the translation of the business processes into the functionality which will be provided by the ERP system. As soon as the business processes are baselined and the critical processes identified the method or approach to testing should be focused on in detail. The testing needs can then be progressively validated through execution of the CRPs and ultimately Acceptance Testing. The following diagram illustrates the relationship between all of the business processes, the critical business flows, their steps and the necessary test cases. It can be extremely beneficial to construct test cases which address any risks associated with the critical business flows. Custome r Service Processe s
Operations Processes
Finance Processe s
N
Customer Service Processes
Operation s Processes
Finance Processes
N
Test step 1 Test step 2 Test step 3 Test step 4 Test step 5
24 June 2005 Version 1.0
A guide to successful implementations
Expected Outcome 1 Expected Outcome 2 Expected Outcome 3 Expected Outcome 4 Expected Outcome 5
Page 15 of 19
3.14
Fallback or contingency planning
Whatever the size of ERP project a fallback or contingency plan will be required which provides options should any key component of the new solution be late or absent. Contingency plan should first be developed on completion of the business process mapping and the high level design. At this point it will be clear where the key elements of the solution are located and what would be required at a high level for a successful launch should they not be available. The contingency plan should then be revisited after each CRP where input from the business will highlight or provide additional operational information regarding the importance of various elements of the solution. Having progressively refined and actively maintained a contingency plan will make it easier for all or any aspects of the plan to be introduced should it be needed. The most likely case will be the need for a contingency area where there has been a delay in the completion of a particular aspect of the solution but a launch date must be maintained.
3.15
The point of no return
Regardless of integrity of the approach, the metrics used or the best or practice there will come a point close to the end of the ERP development when the 90% complete syndrome is reached. The completeness of the solution seems to stick at 90% (or less) and can’t seem to get any further. This usually happens when a board committed launch date may have already been moved (possibly more than once) and one more move would mean a loss of credibility for the supplier and for the customer and more than likely involve a substantial increase in funding. This “point of no return” is reached by many ERP projects. Committing to a launch date with the system being incomplete in some areas can introduce excessive risk to an implementation but, if the areas are well understood, it can surprisingly inject momentum to drive the project team and the business towards success. If the incomplete areas are understood then the risks can be mitigated to some extent by maintaining a longer presence of the on-site team post Go Live.
3.16
The first months post launch
Be under no illusion - the first months post launch for an ERP project will be hectic. It falls on both supplier and customer to remain calm and work through the problems which occur. Even with the best change management activities in place there will still be cultural and technical problems to resolve. It is absolutely key that the project team and management from the supplier and customer present a “combined front” and common willingness to address the issues which may arise in a non confrontational manner. It will be hard work and may be emotionally draining but with a commitment from all sides challenges are surmountable. The implementation of a new ERP solution will be a large change for the users as typically they will have been using the existing legacy systems for some time. To manage this change effectively, the likely fluctuations in morale for the users need to be considered and indeed explained to them during early training sessions to enable all parties to act appropriately. The level of resistance to change and wish for the “old system” to remain will vary from user to user and can be addressed over time. This must be closely monitored by the project team and quickly addressed to avoid wider reductions in morale across the user community. Regular reminders of the business benefit to both the user community and the management stakeholders will assist in the transition to the new ERP solution.
24 June 2005 Version 1.0
A guide to successful implementations
Page 16 of 19
The likely fluctuations in morale of the user community are illustrated in the following diagram. System Go Live
Performing
Morale
Excitement Real Learning
Realisation Shock
Acceptance Fear Doubt
Time
Critical to project success is ensuring the business resources are adequately prepared before the go-live and appropriately supported post go-live. Expectation must be clearly managed within the organisation in terms of what will be achieved during this go-live period. Often organisations expect the benefits of the new system to be realised on the first day and often forget that for the users some time will be needed to “bed in” the system and potential new working practices.
3.17
Stress Management and ERP projects
All projects have their own levels of stress. The challenge for the supplier and customer is to aspire to a situation where the project team and the business are challenged just enough. The level of stress the team is working under has a direct relationship with both individual and team productivity. As shown in the diagram below, if the team are not effectively challenged, a “Rust Out” situation will occur, where the team are not productive due to a lack of challenge. Similarly, if the level of stress imposed on the team if too high, productivity will reduce as the team will be unable to complete all the required activities either to the desired level of quality or in the appropriate time frame and a “Burn Out” situation will occur. In both these cases the likelihood of absenteeism due to recurring illness may increase and have a direct impact on productivity. The optimal situation is reached with an appropriate level of challenge imposed on the team and individuals to ensure “Peak Productivity” is reached and maintained.
Peak Productivity
Rust Out
Burn Out Stress Level
24 June 2005 Version 1.0
A guide to successful implementations
Page 17 of 19
It is well worth discussing stress management within the project and for individuals to consider their own coping strategies. It is especially worth highlighting that everyone handles stress differently and may have completely different ways of coping with it. As such the project must be responsive to the needs of the individual and ensure they have the appropriate level of both challenge and support required.
24 June 2005 Version 1.0
A guide to successful implementations
Page 18 of 19
4.
CONCLUSIONS
ERP projects are notoriously difficult to manage to time and /or budget. The reasons for this are many but they can be categorised into several key areas: ♦ Approach and discipline – If the intention is to implement the core ERP product with minimal configuration and customisation then this approach must be adhered to. As a result the business processes may have to be “bent” to suit the product rather than bending the product to the business. In the event that unplanned customisations are identified the need for these must be considered carefully and if a customisation is contrary to the approach an appropriate cost/benefit exercise undertaken and a detailed impact analysis presented to the management team. ♦ Comprehensive design and testing in areas which are non standard – The design and test must be focused on any areas which need to be specially customised or require an unusual configuration. Areas which have been modified will almost always require more effort to get right than were originally estimated. Create specific workshops to refine the design in these areas and use trial and error with the ERP product until the design and its implications are fully understood. ERP products are so functionally rich that it will be unusual if one or even several members of the implementation team will understand all the subtleties of the product when it is being modified. ♦ Iterations and compliance – In developing an ERP solution, even one with minimal customisations and standard configuration it is worth recognising that it will require several iterations to arrive at the most appropriate solution for the business. Neither the supplier nor the customer should expect it all to be perfect first time. Understanding this and working with the project team to focus on building from a minimally compliant solution which addresses most business cases is far better than trying to satisfy every case from the outset. This approach also mitigates against the risk of one area stopping the entire project. ♦ Conference Room Pilots – These are key in both validating the solution and ensuring business buy in. A plan to run three CRPs usually strikes the correct balance between completing build work and the need to remove business personnel for the validation of progress. Any more will become an excessive intrusion into the business and actually be detrimental to progress. ♦ Metrics and tracking – This is often a hard to get right on an ERP project. This paper has discussed some options in this area but the priority must be on tracking the completion of critical business processes. ♦ Contingency or fallback planning – Even on the best managed ERP projects the unexpected will happen which may have a serious impact on the project timeline. A contingency or fallback plan ought to be created as early as is feasible, kept current and be ready for execution as required. ♦ Expectations in the first month after go live – The first months post go-live will be hectic and prone for heightened emotion. There needs to be an awareness and sensitivity from all sides and a that there will be a common will to succeed and that this success may require unexpected and perhaps manual workarounds in the early days post go live. ♦ Ongoing maintenance – Unless reviewed at key design points on the project it is highly likely that the ongoing maintenance effort estimates will be higher than originally envisaged. The area of post live support must therefore be reviewed at the end of the design stage and at the end of each of the CRPs to ensure that it is still aligned with expectations. It is unfortunately very easy to allow the design to become more complicated and the level of on-going support not properly understood until after the system has gone live.
24 June 2005 Version 1.0
A guide to successful implementations
Page 19 of 19
Related Documents
Managing Successful Erp Projects
November 2019 14
Managing Small It Projects
October 2019 17
Managing Projects With Nmake
May 2020 5
10 Keys To Successful Software Projects
May 2020 4
Managing Successful Conference Room Pilots V1
November 2019 12
Erp
May 2020 35More Documents from ""
Business Change Portfolio Management
November 2019 25
Business Agility Through Your It Service - Infrastructure Ion
November 2019 21
Security Issues Associated With The .net Gac And Code Signing
November 2019 14
Deserializing Individual Elements In Xml Documents
November 2019 7
Eight Challenges In Data Integration
November 2019 14