Stop buying when software when you really need an I.P.A.

michael's picture

“Be careful what you ask for” is sage advice. When the noise of process dissatisfaction rises to the C-level, it is usually accompanied by the clamor for a new technology solution. One only needs to look at the Frankenstein of internal processes to know that:
1) we are not lacking in software;
2) the number of process work-arounds far exceeds the number of system integrations;
3) Excel and Outlook are much too often disconnected, mission-critical applications within a process.

None of this is good news when it is translated into operational expense and efficiency ratios.

The root cause is that processes have evolved over the years rather than being designed or reengineered. When the workload gets too great, it often manifests itself as a bottleneck so we go fix the bottleneck. We RFP for some new whiz-bang point solution widget to address the bottleneck and then bolt-on everything else around it. That’s why the average new account opening process takes over a dozen separate applications to complete. The bolts that connect these bolt-on applications and workarounds are rekeying the same information and verifying other people’s work. That’s why the average loan origination process requires the loan number and borrower name to be entered over 25 different times. Many of the bolt-ons are just for tracking the work in the pipeline. That’s why we have Excel-based application logs, processing logs, underwriting logs, closing logs, post-closing logs. We have enough logs to build a log cabin. It’s time to put a torch to that dead wood and build new, energy-efficient processes.

For starters, before the Widget A RFP is emailed to the vendors du jour, document the current process. A simple flowchart that captures all of the activities and handoffs will open your eyes to the way the work really happens. In addition to activities more ridiculous than that 30 Rock episode where the execs spend a day doing the jobs of the workers, it will also point to some really important process integration issues that can only be solved if:
a) the new Widget A replaces the functionality of both the old Widget A and Widget B, or
b) new Widget A seamlessly connects to Widget B.
If it does neither, then the new Widget A will come out of the box with a process work-around and zero process improvements will have been made. Unfortunately, this is often the case when new software is implemented. That integration feature is always in Phase 2 which never comes.

Second, if the current Widget A and Widget B are satisfactory except they don’t talk to each other, MAKE THEM TALK. It is exponentially cheaper and faster to integrate than it is to forklift. Today, all software is built on top of a database. Even if your vendor has convinced you otherwise, databases can communicate with each other without breaking each other.

Third, start somewhere. Even if we are in the RFP mood, we are not going to replace all of our software. Surely there are process integrations that it just makes sense to rent, buy, or build. For instance, if you use ExactBid’s RIMS appraisal management system and OnBase/Nautilus/Director, Agile Banking's ExactImport is an integrated process application (I.P.A.) that transfers documents between the two. Because if the documents have to get from RIMS into OnBase anyway, why not make that automated so it happens effortlessly 100% of the time?

For at its most basic, that’s what integration is. Automated communication between two systems.
Application integration is a key to having high-performing processes.
Homebrew you some I.P.A. today.
It’s not rocket science any more.