Enterprises require complex IT systems to run their business. Huge sums are invested on very complex CRM, ERP and BI solutions. Typically, the decision is to use standard commercial software products to reduce cost and time required for the solution to be in production. Quite often then, the cost of the developments required to customize the solution to the client business needs is underestimated. This not only affects to the cost of the first deployment but also to future costs of changes and updates, triggered from both sides, that is, customer needs and the acquired software solution.
About the latter, quite often those solutions are very large and complex packages that solve much more than any single organization, no matter its size, will ever require and that at the same time have gaps in their functionalities that most companies must fill to accomplish their essential requirements (legal for example). Another important factor is that these packages are quite often not easy to integrate with requiring, by design, expert integration services in order to interface with other organizational systems. This unresolved complexity becomes an important pillar of the enterprise software vendor business model whose numbers depend either on the acquisition of additional modules to complement the solution or employing a professional services group who will be working on the customer premises to develop the software connector required to connect other systems. Being this the case, vendors don’t have any interest on addressing this complexity as their competitors follow the same scheme, a gentlemen’s agreement. Naturally, the more modules and custom software the more dependent the customer on the provider, the larger the maintenance to be paid yearly becomes.
And the result, for the customer is this:
He is completely tied to a software solution and every time a version migration is required, and they are required often, a significant effort is required so that customizations done on top of the suite require at least a regression testing round when not patching. No matter what, the customer has to pay for that.
But software vendors are not the only responsible for this situation, and to be fair, they are not the initiators of this vicious cycle. They just reacted to a customer position that along time has forced providers to increase the flexibility (and complexity) beyond any imaginable point. And what customer position is this? Let’s talk about it.
When designing a new Information System(IS), customers start with the idea that the IS must be a perfect reflection of the current processes and organization, just faster and automatic, that the company is running. The outcome of such a process is less than optimal it’s a highly effective engine that executes consistently all the inefficient workflows defined. If your business was a pipe that had a leak, after you added the IS (that you could see as a pump), you would be wasting liquid in every single transaction through the pipe.
The reasons for this mistaken bias, what we have is what we need (WWHIWWN), are diverse and require an independent analysis:
- Flexibility, software is more flexible than people so it becomes the easier target for absorbing any gaps.
- Complexity, related to the previous but in a different axis, large organizations are complex ecosystems and the different areas conforming it are quite often struggling not only to execute on the strategy but also to agree on changes that affect the power’s map. To workaround this issue, that often comes together with a lack of upper management support, concentrating integration changes on the software solution becomes the fastest way to start making progress… towards whatever the project is moving.
- Self-awareness, quite often the management is not aware of the small inefficiencies that clutter the daily operations of the company, the information doesn’t flow up the hierarchy. Other times, processes are executed invariably even when the factors that motivated some tweaks no longer exist. People, in their busyness (not a typo mistake), forget the “Why’s” and keep feeding and complicating their daily job and even feeling comfortable with this complexity. Sometimes this is a self-defensive strategy of their job, adding barriers to being replaced as owners of an obsolete but difficult to acquire knowledge. Other times it’s a passive acceptance process that reduces the autonomy and empowerment of the workers that don’t find any incentive on fighting back.
In general, few organizations, in relative numbers, keep focus on their processes, foster self-criticism among their employees as a direct path to optimize their performance in a comprehensive way and even actively sustain process innovation as a key competitive advantage support on an extense patent portfolio. Luckily, this is changing as methodologies as Six Sigma and Lean becoming more and more extended in companies of all sizes.
How should IS strategy be influenced to obtain the expected benefits? Such a process must start with a thorough review of the processes and existing systems. The more documentation about the existing workflows the easier will be to analyze them. The project must be considered a transformational change that will require the implication of all the areas in the organization, Human Resources for training people, Legal and Audit for compliance and regulations, … Appropriate metrics aligned with business KPI’s, when not the same, must be selected and baselines established to measure the impact and hopefully success of the initiative. Required support from senior management as well as tracking of all blocking issues and resistances is a key success factor. Overall, customization of software should be limited to a minimum based on the choice of a platform that provides the base functionality required. The gaps left should be carefully and humbly analyzed, better if done by the same people that daily runs those processes, and alternative simpler ways of getting the job done defined, and the new solution bought in by the employees.
You may say I am a dreamer when suggesting this approach but you should consider how many times you have seen the opposite situation. I refer to things like a clerk writing down a tracking number that appears in an screen of the application to enter it in a different screen, using ‘calc’ to sum up some amounts in any new form or personal data that must be introduced (and asked to the customer, even old customers) more than once in the same data-entry process. The conclusion is that even when changes to the processes are not easily accepted during the design phase at macro level, any remaining limitations at micro level after the solution is in production are accepted with little resistance, no matter if this is because of a real software limitation, a troublesome bug, poor design or analysis gap.
The advantages of this paradigm change are clear:
- Reduced TCO for the solution, as less custom developments are to be maintained.
- Reduced deployment time for new solutions and updates.
- Reduced learning curve for employees, both existing and new hires.
- Simplification of interoperability between company systems and also partners, customers and providers.