Four tips for starting an ERP project

Cross-posted from SYSPRO SmarterERP blog

There has been a post on the SYSPRO blog on how an ERP system can help a business, and also some suggestions on how to select an ERP solution. But if you have read some of the stories about ERP project problems you might wonder if it is worth the risk. The answer to this is twofold.

  1. The reports on ERP project failure mainly refer to large organizations implementing fairly large projects, and are not representative of projects undertaken by small- and mid-size businesses.
  2. It’s how you approach the implementation that is a significant determinant of success or failure.

So where and how do you start?

The lead up to an ERP project is a good time to consider Eli Goldratt’s Theory of Constraints Thinking Processes, which is a set of tools to help organizations identify what can be done to significantly improve any business system. By the time you start the project you should have dealt with the question “Why change?” Now you need to look at the other questions:

  • What to change?
  • What to change into?
  • How to cause the change?

A number of organizations might think that all they need to change is their business system, when in reality they will probably also change and streamline processes, and realign roles and responsibilities. Therefore I recommend the following steps.

1. Do a business process blueprint.

To answer those “what” questions you need to understand the processes that operate in the business. A process blueprint provides a graphical view of the way processes work, who is responsible for the processes, and the interaction between different roles.  It also helps by creating a view of the business that both IT and business can understand and discuss – a common, visually-based language. From the blueprint you can see more clearly what might need to change (e.g., in terms of streamlining processes), and with a decent blueprint tool you can try out different changes to see what might be most appropriate. The blueprint enables you to identify solution gaps and define integration points between IT solutions.

2. Check that the key project issues are covered

Evidence from many projects shows that there are four main factors that create project problems, and so mitigating them will improve the chances of project success.

Main causes of project problems How to mitigate them
Unclear objectives and poor focus Focus on strategy, involve stakeholders and define project teams responsibilities and accountability
Changes in project scope Ensure project team and all affected staff are aligned to work towards common project goals
Lack of appropriate skills Ensure appropriate skills are available
Unrealistic schedules and poor planning Have a good project manager

3. Plan the project in phases

The implementation project plan describes how the transition from current state to envisaged future state will occur – it addresses “how to cause the change?” Plan the project in phases and implement over time, for several reasons.

  • It’s easier to estimate and manage the budget for a smaller set of tasks than it would be for a ‘big bang’ type of approach
  • It restricts the impact of the change to a smaller number of people, which means disruptions to everyday work can be minimized
  • Showing rolled-out wins will keep people motivated

4. Make sure change management is included
Forrester-change management
The biggest cause of failure in IT projects is not software, it’s ‘wet-ware’ (people). Resistance to change can block even the most perfect plans, so building active consensus and buy-in is crucial. Forrester Research offers the following steps.

Lastly, although you may have undertaken a thorough business process analysis, and done the proper project planning, be prepared for unexpected complications that occur during roll-out. This is especially true for manufacturing businesses with complex processes, and where integration with other manufacturing applications is needed. If, however, you have done the upfront work, you will be in a position to handle these complexities without seriously impacting the project or the business.

What is your experience with starting an ERP project? Have you got any other tips to add?

Implementing ERP more effectively – Part 2

Part 2: Changing the system as business realities change

(cross-posted from SYSPRO Smarter ERP blog

Hands up all those who have started implementing an ERP system and not had to deal with changes as the project progresses. No one? I am not surprised. Has anyone gone live with an ERP project and never had any changes afterwards? The reality of any ERP project is that scope changes occur during the project, and after going live it is guaranteed that there will be more requirement changes.

In my previous blog, I discussed how integrated BPM (business process management) and ERP could provide a visual representation for designing and building an ERP, referring to my personal experience of having built a house. The second part of the story is about changing the plans when new ideas or new realities come up.
 
With my house we had extensive discussions with the architect during the design phase and we were confident that everything had been covered. But when we spoke to the builder he made additional suggestions and noticed some things that had not been considered. Using the blueprint drawings, we could decide on the changes needed, assess the effects on the building and the costs, and then make alterations to the drawing that everyone agreed with. It was a clear and understandable approach to taking on new ideas and changing plans even after everything had been agreed.
 
The same process happens in ERP implementations. Organizations often spend a good deal of time working on the design of the ERP application using skilled (and expensive) consultants to help them. This they believe will ensure they have got it right before the implementation starts. However, no matter how good the team, the fact is that issues can be over-looked, or valid change requests suddenly appear which had not been considered earlier.
 
In the past this was a problem because the ERP planning process assumed stability, and ERP systems were geared towards controlling data and automating processes. Flexibility and handling change were not priorities. Of course the world has changed and we now expect our software to be adaptable. For enterprise software, with its high level of inter-connected functionality and degree of complexity, this has been a challenge … until the advent of integrated BPM and ERP. With this integrated process toolset, new ideas and issues can be raised after planning is finished, and re-planning, review, approval and documentation can be managed more easily and clearly.

Integrated BPM-ERP

Integrated BPM-ERP

This concept of a model-driven ERP system is now possible using SYSPRO Process Modeling (SPM). Model-driven architecture has been around for 10 years, and is recognized as the most effective way to manage and optimize business processes, especially in a volatile environment. SPM helps in process management from high-level ‘Core Processes’, to actual ‘End-to-end’ processes, right down to activities and screens. For each level, this is integrated with the organizational structure, technology, data, and SYSPRO’s supported business processes.

This allows the organization to see how everything is inter-connected, and also to see how changing one element impacts on other areas of the model.

Hopefully the days of referring to ERP software as ‘monolithic’ are coming to an end. Changes to an ERP system should be expected and planned for because there are many aspects that can change. If you have been through more than one ERP implementation, particularly from the user perspective, what was your experience of making changes to the system? What would have made it easier?
 
In the next part of this blog series: Having the right approach and attitude to an ERP implementation.