COURTESY OF CAPITAL ONE FINANCIAL CORPORATION
One of the greatest problems of the business world today is the over-generalisation of success into contexts where that success is simply not transferable. We then compound that problem by stubbornly refusing to believe we have over-generalised and try to force that model where it just don’t fit.
Let’s look at a salient and virulent example: process based automation. Process based automation is the concept of (i) understanding the process, (ii) converting it into a workflow and then (iii) designing and developing machine-based automation (e.g. a software system) that ensures the process is undertaken quickly, consistently and verifiably. This is fantastic for manufacturing. Programming software to automate and accelerate highly repeated processes has delivered enormous productivity benefits. Indeed major software vendors, like SAP, grew up in chemical industries and other manufacturers, undertaking materials management, production planning and payroll: i.e. highly repeatable processes.
When we move over into other contexts we start to move further along a continuum from “frequently repeated processes” like manufacturing through to “goal driven” activities like an air crash investigation. It is very hard to automate an air crash investigation, because your initial findings will highly influence your subsequent activity. You might spend several days, weeks, months or even years simply looking for the “black box”. Most business contexts fall somewhere in between these two extremes.
And here’s the rub. Most software implementations today consist of the following: 1. Send the business analysts out to capture the processes (possibly to the BPMN standard), 2. Undertake a business process improvement (BPI, possibly using lean six sigma), 3. Convert this into user requirements, functional specifications -> configure the software, test and go live. Regardless of context we expect to get the kinds of results achieved when this approach was successfully deployed in manufacturing. But it doesn’t seem to work quite so spectacularly in office environments, especially where the work is investigatory rather than process oriented,
There is also an issue with how we implement IT projects. We don’t often capture when the current state process goes off track or when things that are infrequent, irregular or ad-hoc occur. What happens when the form is not filled in correctly or the payment is rejected? What happens at the end of year or each budget? What happens when an unscheduled event occurs, like a strike, an earthquake, tsunami or hurricane/cyclone? What happens when the board or a government regulator asks a question about something? Very rarely are these events or processes captured and, as a result, they are very often missed in the requirements for the new system.
Even worse, the legacy systems we are planning to decommission have often evolved to handle these unusual, irregularly repeated events. But our initiating business analyses will likely view these hard learnt modifications as inefficiencies to be six-sigma-ed into oblivion. Our shiny new system, cleansed of inefficiencies, is then totally unprepared for the stream of irregularities that come down the pipe post-go-live. It is then, months after go-live that we discover why the organization used to do that seemingly inefficient process that used to prepare for that irregular event (or even more likely, we suffer in naivete and just blame the new system).
This may not hurt if your business context has large quantities of highly repeated processes that benefit from the automation. However you are likely to get no or even negative outcomes if there isn’t. But we pretend that every business context is like manufacturing. We just implement ERPs and CRMs ad-nauseum everywhere: blue collar, white collar, private, public, manufacturing, service, profit, not-for-profit. But we are overgeneralizing, especially in our implementation process.
We can also see this in the public sector with its current focus on customer service. Inspired by the customer focus efforts of private sector customer-facing organisations like telecommunications, retail, and insurers, the public sector has become obsessed with improving “customer satisfaction”… as if all they do is provide services to individuals. But a key function of government is regulatory. Does anyone ask the convicted felon if they are satisfied with the service they received from the courts? How about the citizen who has just paid their speeding or parking fine. What about the one who has just been deemed unable to provide medical or construction services to the market and has been de-certified. Unlikely to be satisfied customers there.
These “services” are to the wider public and not to an individual “consumer”. Focusing purely on “customer service” is an over-generalisation of a model that was successful in another context. There is certainly always room for improvement in the way all ( specially public sector) organisations treat the citizens they are trying to deal with. But to believe that they should become myopically centered and focused upon the “customer” is a misreading of their raison d’être. Many government organisations are there for the general public service and not simply to service individual members of the public.
Perhaps a more important function for your IT systems is supporting decision making, ad-hoc investigation, what-if scenario modelling or possibly evidentiary record keeping. Perhaps process optimisation and customer focus is only a minor component of the activities of your business.
So, before launching head long into that multi-million dollar CRM or ERP implementation, check that your organization actually fits the context in which those solutions have proven successful in the past. And if you do need to implement a big process based system, ensure you capture all of the processes including the irregular, unusual, intermittent and error-correcting processes…business users don’t normally recall these in a workshop without significant prompting.
https://www.linkedin.com/pulse/over-generalisation-success-implications-system-jeffrey-popova-clark/