Jul 25, 2006 0
What should an ERP software/tool possess?
The question that I ask myself today is not what particular features/functions an ERP must possess but what kind of experience must users as well as firms experience with an ERP software/tool? So, I decided to draw up a list of things that ERP software/tools must deliver in three broad experiential areas:
1. Understanding – A concept level requirement. Here the idea is that the assumptions, methodology of planning/calculation should be visible and easily understood by a firm’s management and/or users. This would mean that there are no black boxes that accomplish magical things or some dark art embedded within. From the competition aspect (i.e. with other ERP vendors), this throws open the inner workings of the system. Therefore, it will have to be tempered a bit – grey boxes that nevertheless explain in a simple manner what is being accomplished.
2. Adaptation & Implementation – Should a firm adapt its business processes to an ERP software or should an ERP software be adapted to a businesses processes? That is the basic question that underlies this area of Adaptation. Along with that arises the need for an ERP software to model the business process as it is or in a desired reengineered state. A frequent issues that I have observed is absurdly long implementation plans and projects which increases the risk of failures.
3. Operation & Continuous Improvement – An ERP system might be the backbone of an organization but it cannot be the system that only a backbone specialist only can contend with or change at a moments notice. The very notion of continuous improvement implies that any user should be able to change/improve the functioning or scope of an ERP system.
Now, admittedly, this is a rough cut of what I see an ERP must accomplish in order to be successful. From that broad classification of user experience, some ideas fall out as first cut rules that an innovator might follow:
1. Implementation of the ERP system must be in a timeframe of months (even weeks) rather than years.
2. IT departments must be minimally involved in the setup and roll out of the ERP system.
3. Black boxes must be kept to a minimum if not eliminated entirely
4. Don’t get stuck into thinking that ERP systems should be modular, especially along the lines of defined functional areas. Other forms of organization such as inheritance (OOP) and value chains might offer alternative ways of organizing features.
5. Meta modules and inherited modules must be available. A frequent thought that I have is that when people from different functional areas communicate, they’re abstracting what they think is happening in areas outside their expertise in order to understand those activities. I am thinking out loud here whether that is the nature of communication between functional areas as well.
6. Upgrades to the ERP system should be radically modified. I can’t think of a way to achieve this because the underlying philosophy of the system might change but the architecture initially outlined must consider both ongoing operations as well as future operations along the three broad areas above (Understanding, Adaptation & Implementation and Operation & Continuous Improvement)
7. Dashboards. Dashboards look cool. Other than that, it might very well be an information dissemination service to all members of the firm rather than decision makers.
8. Leverage open cooperation between ERP adopters and implementors across different industries and allow them to collaborate on process development, insights, measurement and continuous improvement ideas. In fact, allow them to exchange and adapt business ideas through the system.
That’s an attempt at a first list. Some of the above might seem outrageous and wishful thinking but if you’re going to set goals, they might as well as be as far out as possible. Next step – features.
Categorized as: ERP_, Tools_
Tags: ERP, ERP Tools, ERP Software, ERP Innovation