This question comes up repeatedly in our vendor evaluation and software selection consulting services. Clients read about failed ERP or CRM projects, for example. They hear the warnings of executives from such companies, telling them to spend more time up front understanding their business processes. They hear about companies that go live but don’t achieve the desired benefits. They vow to do better. They don’t just want to implement a new system. They want to implement best business practices.
These are good reactions. When it comes to enterprise systems, anything that heightens the fear of failure is a good thing. The more business leaders are focused on business processes, the better.
But, how should business leaders deal with their business processes when implementing a new system?
- Should they improve their processes before implementing the new system, so that the new system is not automating broken processes?
- Or, should they choose the new system first, so that they can redesign their business processes using the best business practices that are embodied in the new system?
The answer is a little bit of both: the two should be done in parallel. In fact, doing all of one before the other—whether process first, or system first—will result in failure.
Read the full post on the Strativa website:
Which Comes First, New Business Processes and New Systems?
2 comments:
From the perspective of an ERP designer -- the processes come first.
Sales / Support / Product Mgmt brings these processes changes to the chief designer (via a filtering process that depends on the size of the ERP vendor).
Many modern ERP systems are metadata driven making form changes quite easy (older systems are often hard coded and super hard to change).
For genuine new business processes not in any other ERP system, expect to co-develop this with a flexible ERP vendor.
However ERP vendor development often has a 12-24 month backlog to make architectural changes to support new business processes (despite what many vendors will tell you).
When buying a new system look for new ERP systems that provision customizing without changing core code that stops upgrading the standard system (these nextgen systems are just starting to emerge).
Clive, thanks for the thoughtful comment. Of course, from the side of the software developer, there is no chicken and egg question. Process design should come first. And certainly, the ability for users to configure ERP systems to fit their business processes is a huge step in matching systems to processes.
Nevertheless, from the buyer's side, the problem remains. I have yet to see a commercial ERP system that is so flexible that it doesn't matter what requirements the customer has, or how the customer has designed its processes. So, customers need to do system selection and process design in parallel.
The full post on the Strativa website has a fuller discussion.
Post a Comment