Software implementation is bitter but the fruit is sweet —

Joseph M. Abou Nader

Computers do what you tell them to do, not what you want them to do — Alexander Atanasov

IF you choose to purchase a software package rather than building one, please do not forget — you still need to do a feasibility analysis and then create a Requirements Definition Document. Again, and this is important — you must include the front-line staff who actually will use the system, and who actually interface with the customers and the transactions daily.

Let me pause here and remind MBA Forum readers that this is for the business manager — not necessarily for the Information Technology person. I say this because you may think that this is all technical stuff that you do not need to know. But that is the very reason why there is the MIS course in MBA programmes. IT is now so pervasive you cannot escape it. You don’t need to know all the nuts and bolts — but you definitely need to know enough to prevent you from sinking in the overwhelming IT tide!

For example — you need to know a little about this inconspicuous little guy called “data.” People tend to ignore it to their peril. Yet we typically do ignore it until we are ready to pull the “data” to make decisions. Then we start realising that the data is not “clean,” yet nobody was paying attention to the fact that the customer service officer was keying “999999999” when she could not bother to ask the customers for their TRN numbers. After all, the new-customer screen accepted it, and the transaction was “successfully” processed!

Ok — so let us get back to the issue with the software. Whether you build or buy the software, at the end of the process there must be installation. A critical part of this is what is called “data conversion,” and as the name suggests, is simply a case of converting the data that you have been using for your business (whether manual data, or electronic data), into the new system. Did I say “simply!?” Now — brace yourself, 10 to one you are going to have issues with the data conversion — possibly even some nightmares. Ask any IT veteran who can usually give you some colourful war stories about conversion messes and struggles.

Back to Mr Inconspicuous — data. Many times the data is messed up, or corrupt, or the media it is stored on has issues. By the way – when last has your IT department tried testing the restoring of backed-up data? Many times that is never done, until it is time to recover from a disaster — then when you reach for the backup… I heard a story once that based on where the backup tapes were being stored, every time they were carried past a certain location, the tapes were scrambled. Can you guess when they actually found out? Of course — you got it right, when there was a disaster and they reached for the backup tapes!

Software installation approaches

There are four possible approaches when you are to install software. You may do a parallel install, where you run the old system concurrently with the new system. The advantage is that typically you trust the processing and outputs of the old system, so you can determine whether the new system is behaving well by doing regular comparisons. The disadvantage, of course, is that you need two sets of resources for doing this double processing. When the new system is working to satisfaction, the old system is disbanded.

Another option typically used by organisations with multiple branches is the pilot. In this case they would run the entire system in typically a small branch first. Over the pilot period they would determine if the system was operating as expected. When this is successful the system would be rolled out to the other areas.

A third option is called the phased approach. This is where small parts of the system (called modules or features) are implemented and tested before implementing the other features on a “phased” basis.

Finally there is the cutover whereby the new system is fully installed and then immediately (cold turkey) the old system is totally abandoned. The risks of using this approach are obvious! But then, circumstances may very well dictate that this is the only option you have available based on your circumstances.

Implementing an ERP

Sometimes there is this phenomenon in organisations where, for example, the accounting department purchases their own system which defines a customer number as containing say 10 characters. Marketing does the same, purchasing their own software — which unfortunately defines customer number as seven numbers. Production also has its own software, and again with this different system, customer number starts with a letter, and then seven numbers. Clearly these three systems do not talk to each other! In other words, these different systems from different vendors are incompatible.

The solution to this is an enterprise system called the Enterprise Resource Planning System (ERP), typically built by Oracle, SAP, MICROSOFT and other big software vendors. These systems solve the issue outlined above, and many more — since one system integrates the entire enterprise. These are very expensive systems and on paper are the ideal solutions to enterprise software needs. Unfortunately, research shows that the failure rate for these systems is about 70 per cent! Why? I will outline below — please take careful note, you may benefit and save your organisation tons of cash!

When an information system is being built, it has to assume that a certain process is in place. Remember in a previous MBA Forum article I mentioned that before rushing to procure a software system, you should fix the process first? If not, you may just end up producing the errors faster! So ERP systems typically are built assuming processes that conform to “best practices”.

Now the processes of many organisations (worldwide) do not conform to these so-called best practices. It therefore means that before you implement an ERP system, there would need to be wide-scale and massive changes in your organisation processes. It means that the way your staff members work, how they do what they do, and the steps they would have to follow to get the work done would be significantly disrupted!

Unless these massive changes are properly managed, then there will be chaos, disaster, and ultimately, an unsuccessful implementation for your expensive ERP! In other words, to successfully implement an ERP, along with all the other required technical skills — you need a veteran change management expert!

Dr Kenroy Wedderburn is an MBA part-time lecturer. Send your e-mails to drkwedderburn@gmail.com.