How to Do Enterprise Tech Right
If organisational change is a crapshoot, technology change sits between Russian Roulette and an uncontrolled nuclear explosion, as we have sadly seen with the British Post Office Horizon system. I’ve never seen that level of disaster up close, but I have observed big differences between the few tech implementations that go well, and the many that not only fail to deliver promised benefits, but actively damage the organisation and its business, sometimes for decades.
Here are three ways to get large-scale tech implementations right:
?
1. Decide outcomes upfront
It sounds ridiculous, but the biggest and most common value-destroyer I’ve seen in enterprise tech implementation is a lack of clarity and congruence among senior stakeholders about what they want to be different about their business once they have gone through the tech transformation.
In other words, they don’t know why they’re doing it.
Enterprise tech changes are particularly susceptible to this kind of muddle. Tech is complex, unintuitive and, well, technical, so it’s easy for vendors to blind buyers with what Stephen Colbert might call science-iness. Very few senior execs have direct experience with tech, and often feel embarrassed to ask what might be stupid questions, so nod through inappropriate and wildly overpriced schemes. And tech advances so dramatically and unpredictably, it’s easy to get caught up in magical thinking rather deliberate interrogation of exactly how real-world software can enable the purpose, people and processes of your organisation.
But surely every organisation plans big tech projects thoroughly?
All say they do, but in practice too many wave through decisions then pantomime-plan and implement with tribes of consultants, colour-coded Risk Registers and GANTT charts, over-long and highly-scripted workshops, bewilderingly detailed slide decks, endless mission creep from software replacement to process reengineering to operating model redesign to complete organisational restructuring…all without nailing down exactly what kind of tech is actually needed, for which specific purposes.
It’s not unusual, in my experience, to discover midway through an implementation that more versions of the desired future-state have been shared by the ExCo than there are CXOs within that top team.
As with corporate purpose and values , deciding what kind of enterprise tech you need requires deep, consultative, cumulative and often exposing conversations at the highest level. Until you do that, it’s a waste of time and money doing anything else.
Are some outcomes better than others?
As with anything important in business, there are few inherently ridiculous outcomes to expect from enterprise tech – though I touch on a couple below – but it is very common for organisations to come up with incompatible wish-lists.
Wanting an ERP system to achieve substantial cost savings without fundamentally changing the structure of your organisation’s workforce (ie, jobs) is never going to work. Expecting CRM software by itself to transform the customer relationship is unrealistic. Rapid rollout of a new silo-busting “digitise the core” operating model without deep workforce engagement is wishful thinking to put it mildly. It’s these kind of problems, these kind of choices and implications, that serious, consultative planning will tease out – far better to find out before you’ve wasted several millions.
Lesson 1: take the time, money and effort to do serious strategizing upfront.
?
2. Stick with a plain vanilla system
Enterprise tech is the Ikea of business services, not David Linley Bespoke Furniture. Don’t expect anything beyond superficial customisation to be worth it.
By superficial customisation I mean setting up standard parameters and qualifiers for processes – pre-setting options & defaults rather than expecting users to re-invent the wheel each time they prepare an invoice or request a part. Also, adapt to fit local regulations at different sites, this should come as standard features in any system designed for multi-national enterprises. Do nothing more.
What about our unique processes & needs?
I’ve never met an organisation that doesn’t think itself uniquely special, and that clunky standard ERP or CRM processes don’t fit the way it needs to do things.
On the surface, fair point. No organisation naturally works in the ways demanded by any enterprise tech – approaches get tailored over time in ways that are a mix of culture and specific logic. Any enterprise tech is going to flatten those differences, require compromises from many if not all users. And enterprise tech is clunky: no system approaches the usability of consumer apps. If you’re expecting the ease of Amazon, you’re going to be disappointed and baffled.
Why then do I recommend vanilla implementation? Three reasons:
a) Customisation never delivers
Even if you hire tech implementers with outstanding programming skills, even if you pay what feels an extortionate premium for translating your probably muddled aspirations into a workable system amendment that does not throw off other functionality…even then you are going to be disappointed.
Mostly this will be because we all have unrealistic expectations of what customisation can achieve. As mentioned above, enterprise tech is never going to be as user-friendly as consumer apps. All software systems are standardised and inflexible compared to how people naturally work. The functionality and underlying structures and assumptions of tech systems are of necessity interconnected – you can’t just reinvent one element. And, very probably, you expect unrealistic returns on the enormous costs of even relatively minor system customisation.
Just don’t do it: in decades of working on and alongside enterprise tech implementations, I have never seen a major customisation that made the client happy.
领英推荐
b) Customisation is a nightmare process
Even if the waste of money and disappointing results don’t put you off, you still should not customise. Because the last thing you need while putting in new enterprise tech is an extra and far more complicated change process to manage.
Customisation breaks every rule of sound project management: costs are impossible to predict, timescales liable to change based on that most undisciplined of all human reactions: people’s satisfaction, and programme managers need expert clarification and negotiation abilities, as well as the usual technical skills & knowledge.
Do you really need that complication?
c) Customisation is inherently wrong
But above all, I advise against customisation because it undercuts the very benefits organisations hope to gain from enterprise technology: consistent best practice & business focus.
The risk to best practice is obvious: whether you want to cut costs or improve information quality, you need consistency and accuracy. Customisation risks introducing incompatibility, difference and other complications, not just in the processes involved but in the data those processes gather, manage and store. The result is too often unusable or unreliable data, as well as unpredictable variation and errors within core processes.
Damage to business focus is perhaps more unexpected, but in practice even more serious. Most of what enterprise tech does is back-end automation – getting employees the data and other resources or processes they need to enable them to do the most value-adding parts of their jobs – data analytics, customer interactions, problem-solving, innovation, management, etc. ?Customisation creates anomalies, and anomalies grab human attention and effort – our focus. We can only do creative and challenging work for a few hours a day, so it makes sense to spend those precious hours on work that makes the biggest difference.
If you read the above and still believe your core organisational processes require customisation, you are either practising a highly personalised craft or you have failed to understand some fundamentals about your business.
Lesson 2: customisation does you no favours
3. Implement with, not on, your people
The final success factor is the most important: get people to manage tech, not vice-versa.
As with strategic planning, every enterprise tech implementation claims to manage the people issues. If I had a bitcoin for every time I heard the phrases whipping up excitement, getting buy-in, embedding user discipline, or worst of all, we’ve got people issues covered on our Risk Register, I’d be very, very rich but I’d still be screaming the following home truths:
Five home truths about people and tech:
Ok, so what does work with people?
Plan together
Before you even start looking at enterprise technology systems, take the time and trouble to understand how your organisation works – how people create value, solve problems, collaborate to get stuff done. Get everyone talking about what works well, what could work better, what blocks or frustrates them. Map the processes and share the resulting maps and inputs widely, giving everyone the chance to comment and query.
Then talk to every part of your business in structured ways about enterprise tech and how it can help with workflows and record keeping, with asynchronous collaboration and handovers, with analytics and operational management. These discussions do three things: they up everyone’s knowledge of what tech can and can’t do, they provide useful pointers to what kind of system you need and who within different business units can take the lead in embedding it, and most importantly of all they bring everyone together in thinking and talking about the business, and how enterprise tech can help it do better – helping not only your tech rollout, but business more generally.
End result should be a realistic purpose and scope for your new enterprise tech, and a workforce already involved in getting the most from it.
Implement together
Once you have chosen a system, be honest about what it can and can’t do, what the implications will and won’t be – don’t oversell or mislead, have discussions, don’t give lectures. Use the Implementation Leaders you identified at the planning stage to feed back questions, challenges, tips and to act as your representatives throughout the business – and get out there yourself. The process of implementation should be iterative and consultative, driven as much as possible within the business, with the Programme Management Office acting as a catalyst and support, not a control room (that achieves surface compliance, while fuelling problems underneath).
When it comes to training people in the new system, if you’ve done your consultation and engagement properly, you’ll be able to give trainers a very specific brief about what works and what doesn’t for your people: sometimes all that’s needed is an online guide accompanied by regular Ask Anything seminars, sometimes more involved practical training in teams is helpful, do whatever works for you – this is not the time to worry about a few extra trainer hours. Fixing problems is always more expensive than getting it right first time.
Whatever you do, don’t get swept up in momentum-focused, performative approaches to training – not only are these approaches strikingly ineffective in helping people get the most from tech, plus they irritate and distract. And, as always in change, listen more than you talk and invest disproportionately in working with your people rather than in adapting the tech. People are ingenious and adaptive if they feel involved and valued – they can usually manage even the most awkward software if they understand its rationale and are encouraged and supported.
?
Is that it?
Of course there is a lot more to getting big tech projects right than three simple rules, but in my experience if you do those three things, everything else works out – partly because you’ve eliminated much of the busy-work, counter-productive initiatives and general boredom and frustration that we have come to think inevitable with enterprise tech.
Tech does not have to be a nightmare. If you do big tech projects right, you will be astounded at how they can benefit your business.