Kourosh Dini’s work “Workflow” has been my trusted companion book for the past days and weeks. It is not a book one should read voraciously. Rather, I like to go in and taste a small, esquisite bite of the deep knowledge it holds.
Today, I want to kick around some ideas about the following statement:
“But, for more complex organizational efforts, if we are not consciously attentive to creating space that allows us to develop our own structure, we may get caught up in repeatedly falling for external solutions—software, hardware, even methodologies—without ever creating a meaningful organizational structure to support our own intentions.”
I believe that most of you that have gone through a major system implementation such as an ERP implementation, or ever have been close to one, know how applicable this sentence is. I would like to examine this from two different perspectives, the user and the management, and then come back to Kourosh’s point.
Deciding to implement a new system, such as an ERP system, does not come about by accident. Organizations look towards ICT systems if they have a complex, interrelated management need or they anticipate having one in the future. The need may be the simple replacement of an older accounting system. An organization will then often take the opportunity to integrate part of the monitoring and reporting on its operational value chain in the system. It integrates for example its stock management system, or its human resources into the bigger system. If you have lived with lots of interdependencies between separate systems, you are excited by the promise of simplification inherent in an integrated system.
There is a catch, of course. There always is. The more integrated the system is, the more rigid it actually becomes. It is common knowledge among ERP consultants to avoid to many modifications in an ERP implementation. Yes, you need to configure the parameters of the system in order to make it usable for your environment. But apart from that, most consultants will avoid tweaking and additional configurations as much as possible. Because every little tweak increases the risk the entire thing breaks with the next update.
Management often wants the system. They have stars in their eyes because the vendor has promised heaven, earth and a couple of stars to boot. Management is often not ICT savvy enough to appreciate what is possible. Management wants the system for good reason. They have been confronted with to many irreconcilable reports from different divisions which should be reconcilable. They have received too much information about things they don’t care about, and lacked timely and accurate key information about very critical things. A well implemented ERP can resolve that … provided you adapt your organization to the functioning of the ERP.
The user’s position
To the first time ERP user, entry into the system feels like being handed a Swiss Army knive with 100 tools when all you need is a pen. He or she has a familiarity with the prior system, which they know and understand inside out. Smaller systems were often, over time, adapted and reconfigured to suit the needs of the individual user or group of users. Production knew how its systems worked and never had to worry about the impact of a certain transaction on the stock or the books. Those were separate systems. Nog longer in an ERP. The user is not necessarily a fan of the ERP. He or she wants a user friendly tool (for a certain definition of user friendly, which again is different for the production floor or for the accounting department) which is adapted or as adaptable as possible to his or her needs.
It’s clear by now that the position of the user and the position of management can easily be at odds.
Is a reconciliation possible?
That really depends on what the starting position was. If management sees the ERP as the solution to all of its problems, and believes the ERP choice process will replace the need to first develop a relevant internal structure that supports the prime intention of the organization, it is unlikely that management and the users will ever find common ground. Or, as Kourosh states:
“… we may get caught up in repeatedly falling for external solutions—software, hardware, even methodologies …”
Or, to use a term I believe Merlin Mann coined, the ultimate productivity porn is to purchase a system of many millions of euro’s or us dollars without it being able to solve your problem.
What would be relevant, and what I see more and more organizations do, is to execute a very detailed internal needs assessment first. If this is timely followed by the development of an organizational structure that is geared towards supporting our prime intentions, and if only then all possible solutions are analyzed for a close match to the needs, then and only then we stand a chance of reconciling management and user needs. I believe this may actually lead to a cost benefit analysis where the choice is not necessarily an ERP, or at least not a full ERP implementation. Much more likely is a concerted effort in a common platform of data interchange between the systems, linked to a performant data warehouse that fullfills any reporting needs in an efficient manner.
Micro and Macro
It’s interesting to see that these concepts hold for both our own support systems (at the micro level) and for larger organizations (the macro level.) I’ve visited the place Kourosh describes … I’ve bought the Moleskines, and the apps and applications. Eventually you are defined not by the choices you make, but rather by the choices you choose not to make … in order to keep your system relevant and performant. Key in that is that it is tweaked to your needs. Which is what I believe Kourosh was getting at.