Articles

A few days ago, if you’d asked me what ERP was, I would have said:

The letters stand for Enterprise Resource Planning, and its usually implemented by very large companies. Projects comprising many thousands of employees, involving many cross-enterprise functions, and thus a large number of stakeholders, all with differing expectations and objectives. Thus, a difficult project to manage.

And while I am a babe in the ERP woods, I’m an old enough hand at running large, complex software projects, to understand that the word difficult in this context, is an understatement.

That was a few days ago, though. In preparation for writing this article, I called a friend of mine who has been working in the ERP space for >20 years. I’ve known him for >40 years: we both used to work for DEC and left it together in 1980 to form a custom software house. It was in this venture where I learned how to successfully run a software project, and I’ll share the how with you in a moment.

But one thing my friend said about ERP projects, literally shocked me. He said that when setting the objectives for a new ERP project, the sponsors will be happy if the function’s actual performance remains the same as it was before the project, but is now able to scale to the size needed across the enterprise. In other words, they accepted ahead of time that it wouldn’t perform better, just that it would scale appropriately.

To a Continuous Process Improvements process bigot like me, I was disillusioned to say the least. Deming and Juran would be horrified by this low setting of the bar. If you’re going to tackle an expensive redo of something, do you really want to end up with “just” a more powerful (scalable) version of the same process? Would you not rather end up with a much better version of the process, and be able to scale it to the required size as well?

My friend agreed with me that it wasn’t ideal, but when I challenged him on the why’s of the lack of functional design across many factions and functions, he explained that managers in individual functions in a large enterprise, these days, had no knowledge of the other functions. He said that accountants understood spreadsheets, but not other forms of models, for example; that each functional department had its own objectives, often conflicting with others, and that they had no vested interest in wasting time fixing issues in other departments…

It’s clear to me, that if you can’t properly gather requirements for the project from all interested stakeholders, you are by definition going to deliver a system which will not meet all their needs. It begs the question of why bother with the project at all; when what you are doing is essentially putting the Red Queen in play: running faster and faster just to stand still. Sure, you will be able to handle more volume, indeed, perhaps even at the desired scaled up performance requirement. But wouldn’t you want to deliver the increased volume with fewer resources? Or at a faster rate, using the same resources, by improving efficiency?

So, I asked my friend if he remembered the projects we had worked on in the custom software house. Projects, for example, where we analyzed the requirements for an enterprise wide inventory, receivables, shipping and order processing system for Nestlé or Canron? Both large companies with thousands of people. And in each case, with almost every department and person in the company impacted by the new system.  Remember that these projects back in the 80s were radical redesigns of every function because we were applying automation with computers, to what had been manual processes. And during the years we did this, we delivered 94 of the 97 systems we built, on time and on budget, to a very happy set of users.

Impossible, you say with conviction!

No, not impossible, because:

• I was the analyst on every project, and was also the designer of the system’s functional specification, who was also the project manager of the resulting project, and who remained the single point of contact throughout the project, until we handed it over and completed training. One person who truly had all the answers in his head, all the time.
• I used a computer modelling app to capture user requirements. This being in the early 80s, I invented a Mac based modeler to allow me to draw data flow, process structure, and entity relationship models, and to lay out forms and reports, all using a central dictionary. This eliminated inconsistencies in attribute names and date types as each one was captured.
• The app had one huge advantage over where ERP project methodologies appear to be now: it was a universally understood language shared between the users (and yes, ALL of the users/stakeholders), the analysts and designers of the systems, and the technical teams implementing them. The models each had no more than 5 symbols. You could show one to a user and say something like, “This one is a flow of information like an order, for example, and it enters this process here (called Process One Order), and inside the process is a data store called Orders which looks like this… Within minutes, the order processing clerks would understand precisely what the model was showing them and they would start saying things like” “No, it doesn’t come to me directly, it goes first to Shirley who adds the customer number because she has to look it up in a ledger…
• The technical team implementing the system worked directly from these models, had access to all of the notes recorded on any extra steps involved in the function, and thus could code without interruption.
• And one more reason we were so efficient? The Mac based app had a design compiler which checked for inconsistencies across all the models, and then produced an object file of the design which could be transferred to a VAX/VMS system, and fed directly into the RDBMS of your choice. Say Oracle, Sybase or DB2, where it would generate the schema, stored procedures, triggers, and forms and reports.

All this meaning that once the analyst typed in the attribute names in a flow, no one ever typed them again; the dictionary simply filled them in when anyone started to type one. No misspellings, no wrong names or data types, and all of these parts of the system generated from the models directly. And yes, it even worked backwards; you could feed in these parts from the RDBMS and generate the models on the Mac, so that you could take an existing system and start enhancing it.

Yes, I do understand what my friend meant, about getting the various stakeholders to agree to talk about their objectives and discuss them with other stakeholders. I get that there are difficulties today, in bringing them all together to try to solve the broader implications. But the solution seems as obvious to me now as it did when I started doing this back in the 80s.

You, the people who after all run the projects which produce working ERP systems, you do have the power to organize and run the project the way you want to. You may have to play hardball at first, but my advice would be to do what I did. Just make it a rule, a law in your own ERP Land: If you want us to build your system, the only way we’ll take on the job is if you agree to kick the project off with a Joint Application Design session (a JAD session). Every stakeholder, in one session, headed by an analyst using a model to capture the system. For as many days as it takes!

Sure, you’ll get pushback, although with everyone working remotely now, fewer excuses about being available for an online session. And sure, people will complain about the lost time and wasted effort of sitting there listening to Fred in accounting explaining why Mary in receiving should be recording the arrival of some materials in a different way. But that’s exactly how you gain a leap in performance - when Mary suggests a better way for Fred to use the information, and perhaps, by so doing, eliminate a step in the process.

The advantage of modeling the system in a universally understood language, is that your users buy in to the project from the very beginning. They contribute to its design, they can and do visualize the flows of information; they literally see what each one contains and how it will be presented to them and used by them. And they see all this before a single line of code is written, when everything is still fluid and easily changed. They literally buy off on the proposed system before they use it. And when it’s delivered, it’s precisely what they expected, and the only changes they request are cosmetic. This is how you deliver on time and on budget!

So please tell me, all you expert ERM project leads - do you use models? Do you capture the requirements in a universal language understood by all stakeholders? Do you use JAD sessions to gather everyone’s requirements simultaneously, so that you can discuss and debate them, and then together design the right solution?

And if not, why not?

Have you joined the ERP Community yet?

Membership is free! 

JOIN HERE!