23/08/2012 Leave a comment
22/08/2012 1 Comment
Yesterday I reviewed a sparkling paper of academic research to an ERP failure in an SME. The authors used a interpretative narrative to unfold the complete project from its inception phase to the use phase. Believe or not, but the system is in use! The story has become all too familiar: over budget, over time, a lot of flaws and errors in the system, a troubled relationship with the ISV and a lot of painful scars in the own organization. I took the paper to contemplate on what could be an overall understanding of what is exactly the problem with ERP projects in SMEs. Of course one could say that there are abundant factors that lead or instigate a failure, but there is always a tendency to summarize and to be brief, meaningful and still be truthful.
To my believe and understanding the root cause of the failures lays within the relationship with the ISV or consultant and the inappropriate handling of risk. There is risk involved with an ERP implementation. If statistics say that more than 70% of these project either go over budget or go over time, than it should be wise to take that into account. This is an inconvenient truth. The ISV should confront his customer with that risk, instead of trying to hide this figure. But what does the CEO of the SME wants to hear? An inconvenient truth or a reassured lie? According to D. Kahneman people largely choose for certainty if chances of a lost are high. A reassured lie?
The risk involved with an outsourced ERP project goes over to the consultant or ISV (the agent). This transfer is done in a sphere of mutual trust which is very difficult to manage. I did a rather large research to trust and outsourced IS failures and my findings where that trust is paramount to the avoidance of a failure. Trust is a highly asymmetric construct: it is much easier to lose trust than to build up trust in a relationship. The agent will try to mitigate the risks of the outsourced contract just as the principal did. In his strive to reduce the intrinsic risks of an ERP project, the agent jeopardize easily the trust within his relation with the principal.
Let’s face it: It is not possible to transfer all risks involved with an ERP project to one party, the consultant or ISV. Why is this not possible? Because the main reason for ERP failures is the lack of commitment of top management. In SMEs this is a non transferable duty of the owner/manager. It make no sense to ignore that fact or to cover it up with formal controls and other governance mechanisms. When the cat’s away the mice will play!
So is it wise to conduct ERP projects in a traditional principal-agent setting? Maybe the key to the solution is a tripartite with a principal (the SME), the agent (the ISV) and the mediator (the project leader). The mediator should be an independent party that acts only in the interests of the project. The three parties should be independent to each other and all should sign a threefold contract. Maybe that could help to distribute the risks of the project and to avoid failure.
06/08/2012 Leave a comment
It looks like many ERP implementations have a lot of holes and do not cover all business processes in an automated way. Indeed, how can one otherwise explain the wide variety of business initiatives and new businesses that offer solutions in supplement to ERP to fill in the gaps?
Yesterday I read a white paper of a medium-sized software vendor offering a solution to automate the processes of accounts receivable (AR) and payable (AP) in organizations that have implemented an ERP system from a major vendor. One could expect that AR and AP are basic business processes that should be incorporated in an ERP system. Nope! There are several reasons why this gap-filling business is booming. Since business growth nowadays is mainly achieved by M&As, large companies are still struggling with implementing one standard ERP-template in all their affiliates. Time is not always on their side. The greatest common divider of their ERP-template is therefore very small leaving a lot of holes that cannot be covered in the system. These organizations do not manage to fully implement an end-to-end solution for their business processes. Processes AR and AP are considered as quite complex and at times very different over geographic locations, so there are left over to the gap-fillers.
Same goes for the accounting and bookkeeping systems in ERP. Nothing is more country specific as a tax system (e.g. VAT system). Several documents and even complete work flows are defined by governments and are sometimes surprisingly well automated by e-government initiatives, but not so well in the major ERP systems. This time it are the ERP-systems that are lagging behind. Again this leaves room for gap fillers. Therefore it is of no surprise that there is still a large number of independent software vendors selling their country specific accounting systems to organizations where large ERP vendors has once promised to cover the complete set of business processes.
Another example where gap fillers see opportunities is in the domain of business intelligence (BI). BI should be the pedal of an ERP system. Was the promise of ERP not to cover all operational processes and bring them onto a tactical level from which they should deliver information to the strategic level of the organization? It is therefore sad to see that precisely for BI there are a lot of separate products, largely based on open software, that must fill in the gaps.
There are in addition some problems related with ERP that gives extra fuel for the gap fillers. A common problem for many ERP implementations is the often poor performance in terms of response times. ERP systems are centralized systems but incorporate a broad spectrum of different software trunks, all having different operational requirements. This constitutes a system with a very heterogeneous nature. For example heavy duty transaction systems like order-entry systems often demand the largest portion of performance of the system, leaving no room for simultaneous running BI processes. Cloud computing does not always offers a solution here since the variation in demand for immediate performance does not change in a cloud setting. The only solution is therefore sometimes to uncouple the operational data from the centralized system to a separate system. The latter from which BI is operating.
And there is of course the ever present sword of Damocles over the ERP system in the shape of user rejection and resistance to the software. Not all users fully embrace the often complex ERP user interfaces and therefore tend to adopt ‘easier’ solutions.
The discussion inside or outside the ERP is most active in SMEs. Smaller organizations have tighter IT budgets and are therefore sometimes more demanding to ERP systems than large ones and are challenging the selling propositions of ERP vendors. Unfortunately this leads again to lots of IT failures due to unmatched selling promises!