Back office systems are built and implemented to facilitate business processes—yet all too often the reverse becomes true. Dmitry Mnushkin explains how to avoid costly, time-consuming yet unnecessary complications around such systems.
It’s a cliché in the IT departments of companies big and small that systems are meant to facilitate business processes. It’s taken as gospel that the company does what it has to do and systems are bent into shape to handle it. The disturbing reality is that the more complex and integrated the system, the more it forces the business to adapt to its shortcomings.
Let’s say you are running an insurance company. Business is taking off, lots of customers are signing up, money is coming in the door and the poor folks in your back office start screaming that they can’t keep up with the paperwork. You call your IT manager over and tell them ‘we need a system!’. A project to build The System gets kicked off with lots of business analysis, interviews of users and big expectations for productivity gains.
Two years later The System has been up and running for some time. It is producing great looking reports and has made people’s lives easier to the point that other departments in the company have taken notice. They want The System to integrate into the accounting package and the Customer Relationship Management package and feed the Rating Agency Reports module and send statistics to the Enterprise Risk Management System. The dedicated project team is thrilled at all this interest in their creation and wastes no time fulfilling these requests.
“Something that starts out solving a whole bunch of problems turns into a monster that can easily hold a company back from moving quickly on new business opportunities.”
Another two years goes by and the system that grew out of the needs of an overwhelmed back office is now well and truly integrated into the corporation. What started out as a technological monolith has become strangely organic, morphing and adapting to its surroundings, no longer entirely predictable. Tendrils have wriggled their way into every department in the building. The IT guys swear the thing has a pulse. And it does. It is now effectively the beating heart of the company.
Sometime later what drove the business model so well for the past several years stops working. New entrants have clued in to the opportunity and flooded the market with cheap capital. Your business is getting squeezed and you realise something has to change. You get together with your department heads and plot out a new strategy to weather the storm. It’s bold, it’s market leading, but when it comes time to implement the IT manager drops a bomb. It will take 12 months to modify the system so it can accept the new type of business.
This scenario should be familiar to everyone who’s been around in a company with more than a dozen employees for a few years. Something that starts out solving a whole bunch of problems turns into a monster that can easily hold a company back from moving quickly on new business opportunities. Everyone had the best intentions and gave the best insights they could at the time the system was first designed but still we are left flat-footed.
Build in flexibility
This scenario can be avoided but requires strong focus and a commitment to a long-term plan. The first step is to build as much flexibility as possible into a new system from the beginning. It will increase the cost and time taken to deliver initially but a sound design can extend the life of a core system by two- or threefold.
The second aspect to consider is how the new system will integrate with the rest of the corporate environment. Resist the urge for complex integration in order to exchange information. Acknowledge that complexity is the enemy of understanding and keep other systems at arm’s length. Imagine your system is a petrol station—don’t build a fuel hose with an attachment that fits only the accounting car. Build a standard-size fuel hose and make all the other cars adapt to it. That way if you ever open up a new petrol station, you know all the old cars can use it so long as you have the same hose.
Consider also that every system must eventually be replaced. No matter how well you build it, the business, the corporate environment and technology will eventually change so much that modification will become more expensive than a full rewrite. Anticipate this need and start planning system succession before circumstances force your hand. It should be quite possible to build a system that lasts 10 to 12 years before replacement.
There are many other things to watch but my final piece of advice is to make your developers keep good system documentation. It’s a pain and they will scream and shout but just ignore them. It’s for their own good! Imagine having to dig up a street without knowing what pipes are supposed to be under it. Knowing where you’ve been and why you went there will save time, money and help bring your systems to heel.
Dmitry Mnushkin is the president of Treefrog Consulting, a Bermuda-based consultancy specialising in custom risk portfolio management systems and tools for the reinsurance, cat bond and ILS space. He can be contacted at: firstname.lastname@example.org
business systems, Treefrog Consulting, Dmitry Mnushkin, insurance