|
ERP Rules
Author: David Lane
Date: March 16th, 2005
Forget SAP! Forget PeopleSoft! Seriously forget Great Plains and Axapta! Turn your head away from J.D.Edwards or in fact any ERP solutions based on packages, as that way lies madness.
Imagine you are in the market for a car but you have only two options available: you can either buy an All Terrain vehicle or a Rolls-Royce. Unfortunately as part of your agreement with BMW, which owns Rolls-Royce, if you buy from them you are never allowed to buy any other type of car than a Rolls-Royce. The All Terrain issue is different, however, in that 1) You would save 80% on the cost, 2) There are multiple suppliers, 3) You can custom design your vehicle, taking the engine from one, the design from another, the wheels and trailer from a third and 4) you can add in your own modifications through using inexpensive and plentiful engineers. By the way, if you go the RR route, any modifications must either be done by BMW or through a very expensive elite cadre of specially trained RR engineers.
At some point through that analogy, it started to break down because it is difficult to find a non-captive market that accurately represents the competition between readily available inexpensive ERP and the monolithic ERP packages being touted by the mega corps.
Now, just for clarity, I am not saying that any of the companies mentioned are bad. Their packages are feature rich and well supported. What you need to remember, however, is that each of these companies wants to tie you into their product – for life. And while much of this is based on features and ease of use, quite a lot of it is based on making it hard to change.
What do I mean by ERP?
I guess some definition of terms is in order so that it is clear why I think that choosing an ERP route is not the same as selecting a word processing package.
First an official definition:
ERP or enterprise resource planning is an industry term for the software that helps business manage their working processes, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders.
Technically that may cover it but in practice ERP is not just a function of process. ERP is about making it easier for your company to do business and consequently it must cater for both management style and, most important, change.
Here is the biggie: ERP must positively contribute to Change Management.
Most companies are not static. They must constantly reinvent themselves to take advantage of new market conditions, new technology and new staff skills. Creating a static ERP system is going to tie your company to a method of doing business which will probably be outmoded before the system has been implemented. ERP systems must be able to adapt easily, quickly and without breaking the bank.
Enter the world of common sense ERP
Having said all this, utilising ERP is not that hard, nor is it only the provenance of larger companies who can presumably afford the cost, time and effort implementing such a system. ERP can be used by businesses of almost any size in a cost-effective and manageable way as long as you follow a few general guidelines or rules.
These ERP rules fit within and inform all the standard steps of any software implementation process. You can include them as constraints in your original specification or they can be part of your evaluation process when viewing supplier quotations and project plans.
1. Start Small
It is a truism that it is easier to manage smaller projects. Consequently if you have a large ERP requirement covering a number of interlinked areas in your company, break them down into quantifiable chunks. Each discrete entity should include at a minimum the following steps:
2. The Solution must be Technically Modular
Now, this does not mean commercially modular in which suppliers sub divide their products so they can sell multiple components to you. More often than not you find you have bought half a product that does not really work without the other ‘optional add-ons’.
A Technically modular solution means that each module does its job completely and without recourse to additional components. The aim here is very simple: Just because you have purchased one product from one company should not mean that when you want to expand the system, you have to purchase the expansion from the same company.
If multiple components are required for a system, such as maybe the case with User Management and the cross module bug/change reporting system, then the communication between modules must follow Rule 3.
3. Programmable Interfaces based on Open / Published Standards
Information will obviously pass from one module to another. Often this will be done through the database, which is covered by Rule 4, but sometimes information is passed directly in the form of state information. When modules communicate data directly, it must be done via an Open or Published method. Your technical documentation must specify exactly what information is being passed and can be passed. The aim here is to make sure that should you decide to change one component, you have both understanding and access to the information being passed.
You should also check that your supplier has not placed any restrictions on which information can be accessed and passed. If he has done so, it is another example of him trying to tie you to the product and restrict your options.
4. Separate Data from System
Data must be stored in a program independent easily readable form. In modern terms this really means that the data store must support SQL commands for updating and reading. Obviously you can use alternative methods if you wish but they must be standards based and widely supported. You should also make sure that:
- Your supplier has fully documented the data structures.
- Accessing the data with other tools does not invalidate your support.
5. Template Based Look & Feel
Have you noticed that Microsoft seem to have got it into their heads that you will not buy a new version of their OS unless the interface is a bit sexier? Their approach is more about marketing than it is about interface improvement but, as systems develop and new input methods gestate, systems will inevitably require interface re-design.
For this reason and in the same way that the program must be kept separate from the data, the interface should be separated from data and application. This approach, which is called three tier programming, allows any of the tiers to be changed independent of the other. The impact of this approach as applied to the interface is to allow you to present your applications in the most suitable way regardless of access method. You may, for example, need people with PDA’s to be able to access your system with a limited number of options. Clearly they will need a different interface to the one seen on a standard PC or from a WAP enabled phone.
Consequently it is important that your ERP solution, which is meant to mould to the way your business works, should maintain its look and feel in changeable templates. Ideally, the system should use structured templates that allow either screen specific or globally affecting changes to be made in a single place.
6. Extensible Through Programming
Systems naturally develop and grow. It is vital that you can extend your ERP solution either by:
- Purchasing additional components from your supplier
- Purchasing components from other third parties
- Develop new components in-house
In order to maintain this third option, it may be necessary to make changes to the components that you have and this requires that they support standard programming languages. Remember the more common the language, the more developers you will be able to find. It is preferred that you have a common language across all your modules but this is not always possible.
Where does this take us?
There are a lot of ways that businesses can protect themselves from being tied into expensive ERP developments but the essential idea governing the rules above is about keeping your options open and not being tied into someone else’s sales agenda.
In a market with only a few expensive developers, it becomes very expensive to tailor systems to your changing business requirements. Following the rules above removes this problem as your system will allow you to utilise the legion of open source designers and developers that are out there. Managing a development team will, of course, require tight management but again you should apply the rules I have described in your own developments just as you would for third parties.
David Lane is a Systems Analyst and Consultant who has over 20 years experience in I.T.
Periodically he likes to exercise a lateral perspective on the industry.
Previous Net Speak Articles:
February 16th, 2005: Why Microsoft Fears The Internet
January 16th, 2005: The Next Big Thing |
