4DS OF OVERCOMING THE PREMATURE TECHNOLOGY FATIGUE

T he audit report is out. The findings are not looking good. But there is hope from the recommendations. Yes there has been revenue hemorrhage in the lending cycle due to inefficiency in the process and possibility of fraud. The audit report recommends a replacement of  the current lending system or improvement of controls around it to safeguard this leakage.

This is a relief for management and the board right?

Not quite right. The reality sinks when recommendations are turned into actionable steps. The big question being, “where do we find a system that can do what the auditor has recommended?” So the journey begins. If there is an IT department, the manager or head of that unit makes informal contacts with known vendors to gather information. He or she gets tons of documents to plough through which are cascaded to either an internal team that does analysis and design or a contracted consultant. Requirements are hurriedly put together while pressure mounts on the continual bleeding each day there is absence of a solution.

Out of box

Pressure reduces sourcing to a hurried single sourced process based on minimal initial work. The process becomes hugely dependent on what the solution offers out of the box. This approach hands the software implementer the initiative to dictate the discussions about sourcing, implementation and support. The components to be licensed and why become decisions that the implementer almost unilaterally makes. Any room for negotiation is left only where the client threatens to consider other offers, though at this point of sourcing, it is rather too late to exercise options. When it comes to implementation, decisions about how the system should be configured are based on how the system has been developed rather than how the enterprise does business. Where there are gaps, the out-of box functionality wins because of the time constraints of implementation and high costs of customization that are tabled by the implementer. After months of meetings, configuring, customizing, trainings, testing, cleaning of data and finally migration, the system is declared ready for use. Day one comes and a loan officer attempts to create a loan offer from the system and discovers he or she cannot find the right loan product or the calculations are all wrong. A call is made to the technical department (which has become a habitation for the software implementer’s technical team). That triggers the new operating model for the next couple of months. No transaction can subsequently be posted successfully in the system until a call is made to the technical department to oversee the process.

 Frustration

The question still lingers: “Have we solved the problem raised in our audit report?” No one can quickly or authoritatively determine this answer. However, there is general consensus that not only has the problem not been solved, but a new one has been created. Why would a solution to our problem compound our problems? The result is frustration from senior management and board. You can bet how management and the board would review IT in the next board meeting. It doesn’t work. The vendors speak jargon. They complicate our lives. We are better off with our manual processes that we are familiar with and can manage the bleeding our own way. Bleeding in a manual process becomes acceptable in the face of compounded complexity. Technology becomes a source of fatigue rather than an enabler of transformation. Bleeding hurdles become acceptable compared to this new monster called an IT system that doesn’t work.

Fine print

Let’s trace our steps back to the starting point. The fine print in the audit report said, “it is recommended that an IT solution to fix the revenue leakage in the lending business should be found”. That line vaguely spells, ‘WHAT’ (IT solution) and ‘WHY’ (stop revenue loss) it should be done. It doesn’t provide details of why and what and neither does it spell the how. I suppose that is where the rain starts beating the client. “How”, you may ask? Loosely defined “what” (a system), non-existent or vague “why” (to seal revenue leaks or because auditors said so) and poorly executed “how” (call a vendor for demo and let’s negotiate pricing) is the beginning of failure. So what should a client do to ensure they adequately answer the questions, ‘what’, ‘why’, ‘how’ and ‘when’ in a succinct way that enables transformation rather than stifling

it? Abraham Lincoln is quoted to have said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”. The problem with hasty sourcing and rush for solutions is attempting to cut down a tree with a blunt axe. More effort is used which leads to fatigue and waste of time without any tangible output. Sharpening the axe is the process of answering those questions before any vendor is spoken to or any deployment is done.  I would recommend these 4Ds in the path towards finding the right solution;

1. Define:- Get a deeper understanding of the problem (what). What does revenue leakage mean? Is it quantifiable per day, annually? Which parts of the process are the weakest and contribute to the most leakage? Who / which unit is responsible for processes? Are there specific patterns in the leak (eg. certain types of products or customers?)
2. Design:-Having narrowed down to the specific what and why, then determine the strategic options to fix the problem. Is the problem fixable by a tweak of existing processes and systems? If not, to what extent does existing capabilities help stem the problem? If that extent is to be adopted what would be the benefit / loss? What extent would a complete rebuild of process / systems deliver transformation? What would be the initial and progressive transformation investment?
3. Develop:- Upon agreement on the most suitable approach to fix the defined “what”, the next step would be to develop the “how”. This is the detail steps of how exactly the problem would be fixed. If it is a tweak of process / system, which process would be tweaked, when, what would be the impact to those who use it? Which communication channels would be used and why. What would be the process of managing the transition and options to revert back to the old process should such tweaks fail to meet objectives.
4. Deploy:-The next step is the actual cutting of the tree. If the choice was a tweak of existing system or processes, the plan should be set in motion as documented in step 3. If it is a complete change of systems / process, then the sourcing process sets in motion with a clear calendar and activities of what pre-sourcing, sourcing and postsourcing activities should be done by who and when. The software implementer fits in the program of the client not the other way round. This process may not at the onset guarantee a 100% fix of the problem but it definitely guarantees a 100% control and execution of the sourcing process which increases the likelihood of getting the right solution that would ultimately enable transformation. It is therefore important to give planning for sourcing of technology solutions adequate time and attention because that process can make or break an enterprise