Month: October 2014

The abbreviations in the title stand for Return On Investment (ROI) and Enterprise Resource Planning (ERP).

ERP systems are common the world over, and they are coming to housing (underway within three major Housing Associations at the time of writing. The Author is performing the ROI analysis within one of them).

ERP systems are computer applications through which major business processes operate. Their appeal is hard to resist. In principle, they bring to key business processes the benefits of automated work flows and tight process control. If, say, your purchasing process is slow and fraught with difficulty, an ERP system with its built in purchase to pay process should speed things up and make them more efficient. Other processes will benefit the same way.

Over the years the range of processes that ERP systems can accommodate has grown. There aren’t many businesses that couldn’t get an ERP system to fit what they do.

There is of course a ‘but’. The biggest relates to the price tag, and, crucially for housing, the challenges faced when attempting to realise the benefits promised.

Both are related to the quality of design of the future processes that will operate through the system. The better the design the easier it is to configure the system. The easier it is to configure the less it should cost.

But good design doesn’t come cheap. Each key process has to be thought through from scratch bearing in mind the opportunities presented for greater automation as well as potential new channels of communication with the customer.

One of the fundamental decisions that has to be made at the start of the Project is about the benefit to be realised. Is it to deliver cash savings based upon a lower headcount? Is it to deliver ‘cashable savings’ i.e. time freed to be either re-invested in doing something better or turned into cash? Do processes simply have to have greater capacity i.e. the ability to accommodate growth without incurring additional costs?

Once this is clear it is vital to then perform an ROI calculation.

This may not court popularity. It is much easier for all if the project is about delivering intangible benefits e.g. a redeployment of freed time towards better customer service, rather than the organisational change needed to yield real cash savings. It avoids the accountability that comes with quantified benefits targets.

But that accountability is exactly what ERP projects require. The issue is simple to describe but sometimes fiendishly tricky to resolve.

When ERP systems go live they are often fraught with difficulties. This is not the result of failure on anyone’s part. It is simply that much of what they are designed to do is ambitious, even aspirational, and they are doing things that haven’t been tried before within that organisation.

But businesses do not have the luxury of time to resolve these issues given that the operation of key processes is at stake. So local workarounds start to appear. They are supposed to be temporary, but because they allow the business to get back to normal, there is no longer the urgency to get the ERP system working properly. The technologists therefore drift away.

When businesses then grow, their ERP systems have the capacity to accommodate the growth without further cost being necessary. But the work-arounds that remain do not. It is not uncommon to find businesses that have invested in ERP systems but have a plethora of activities related to core processes that sit outside of it. This cost was never budgeted for, but with the technology under-performing, it is very hard to shift.

The point about the ROI calculation is that it promotes accountability for benefit delivery. At the start of an ERP development it may be a very approximate estimate as little is known about possible future process designs. But it improves as the project progresses and more information comes to light. The new information is provided by the owners of those processes who are both architects of the future ways of working and of the assumptions within the ROI models.

As ROI models grow in credibility and process owners become increasingly familiar with them they become effective vehicles for influencing business plans and setting budgets – budgets within which actual savings are realised or potential savings are identified and ring fenced to be available for ‘future-building’ activities.

And the point about those budgets is that they can only be delivered if the technology works properly. That, after all, is the premise upon which ROI models are built.

With an umbilical link to budgets in place, any shortfalls in ERP operation remain painfully visible because of the additional and unplanned costs incurred as a result. The technologists have to stay put because their work is obviously unfinished.

Why is this accountability so important in housing? It is because the money invested in an ERP system could pay for several hundred homes for people who are otherwise unable to put a roof over their heads.

This is the opportunity cost of an ERP system. The benefit needs to be such that those homes (plus some additional ones) can still be built, or activities of a similar value performed. If this benefit is not quantified financially, outcomes not measured in financial terms, and accountability for delivery fudged or completely missing, this is less likely to be the case. In which case the investment in the ERP system may have undermined rather than enhanced the social value that the Housing Association is there to deliver.

If ever there is any doubt about the delivery needed from a project such as an ERP development, imagine presenting the project to a room full of your customers. They will probably say that it is their money that is funding the enterprise. Imagine asking them whether or not the financial benefit should be established clearly in advance, whether the anticipated return should be measured along the way, and whether accountability for delivery should be put in place. I’m sure you can guess what they are likely to say.