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.


Implementing ERP more effectively

Part 2 of a series on enterprise information systems

Building a house on a solid foundation

This blog has been cross-posted on the SYSPRO corporate blog.

You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse fail, are appearing on many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.

Eric Kimberling’s Panorama Group identified this similarity at the same time I was building the house. The critical requirement for construction is the blueprint; the drawings of what the house will look like, what its parts will be and how it will be constructed.

The problem with projects, especially complex ones (like a house or an ERP project), is how to communicate the varied components, interactions, hierarchies and responsibilities to all parties concerned. You need a representation that will capture all these elements in a way that is clear and easy to understand, even if you are not a professional in the field. This will ensure that the various parties involved can achieve alignment in terms of common understanding of business needs and technology capabilities.

You also need a way for the plans to develop as your ideas and perspectives evolve. When you start planning a house you don’t go straight into the details. You may have some thoughts (even a vision), but you need guidance from an architect on what is possible, feasible and within budget. So you start with drawings that help you decide on the appearance of the house, then move into the technical and architectural details, and finally the construction and engineering specifications.

Until recently there was no easy way for ‘ERP novices’ to see the business in terms of how it would look after an ERP implementation. But now, with the integration of business process modeling (BPM) and ERP, those visual representations (the drawings) can be done. For an ERP implementation, the functional requirements and business processes are like the rooms and materials of a house, and a business process model is the equivalent of an architect’s drawings. The Business Process Modeling tool can be used in the same way that you start a house with some initial sketches. It allows you to view the business from a high level to make sure executives agree with the ‘look’ before going into more detail.

This graphical way of representing an ERP project can replace the mountains of design documents that were the staple of past ERP projects. This pile of paper used to be the main documentation a business had to describe its strategy, plans and processes. The sad fact was that only a few people ever probably read them, and even fewer understood them.

It’s about time that “the big freakin’ requirements document must die”. What is needed is one tool which can capture scope at different levels in one place, which provides traceability between business requirements and IT capabilities, and which uses better means of communication to illustrate than the common legal-style text of many project documents.

If you are an ERP implementer, how did you experience communicating via traditional project management tools? If you’ve experienced an ERP project as a business user in the past, what did you think of the project documents that you had to use?

At SYSPRO, we now provide a tool that can replace the big project document, which is graphical and shows how integrated BPM and ERP functions: SYSPRO Process Modeling (SPM). Analyst Brian Sommer described the combination as “A Key Mid-Market Need”. With SPM we believe that our customers will get more value, and have a far lower risk of problems in their ERP implementation projects.

In the next part of this series: changing the system as business realities change.