Here’s the deal: customization is everywhere in enterprise software, and most of it sucks. Sucks like a tattoo that looked good for one wild night in Vegas, sucks like that best friend you invited over for a weekend who’s still there a month later, sucks like that cute puppy you adopted who’s now using your house as an open-air toilet. It was a good idea once, maybe even great – but now it’s time to do something, and well, that turns out to be harder than it seems.
Looked cute, might delete later.
The historically rampant use of customizations is an important reason that massive cloud adoption, particularly in ERP, isn’t happening at the pace we would like. By we I mean vendors, partners, and analysts who split their time between wringing their hands about the lack of cloud adoption and being secretly relieved that the skill shortage in the cloud upgrade and migration market – and thereby the quality of those projects – isn’t further challenged by even more cloud sales growth with nowhere to go.
For the record, I’m not secretly relieved that cloud ERP isn’t selling the way some proponents would like. I’m publicly relieved: Right now there’s too many projects hitting too many walls and too many SIs selling the A team and delivering the B team. Enough overselling and under-delivering and pretty soon you’ll end up with an industry-wide NPS more akin to the likes of cell phone providers and ISPs. (Which, of course, is where enterprise software generally resides.)
Skill shortages aside, what to do with customizations in the move to the cloud is perhaps the number one issue in front of me as an analyst and advisor. And resolving this issue is neither easy nor necessarily going to make customers, vendors, and partners happy. At least not all three at the same time.
Yes, it’s scary out there on the road to the cloud….Bad tats and bad friends and bad puppies, oh my.
But first some history: Most All on-premise enterprise software was designed to be heavily modified – it’s easy to put SAP’s R/3 and ECC at the top of the list, but those products have plenty of company. Microsoft’s Dynamics ERP has its roots in Axapta, which made a huge deal about the flexibility of its object-oriented development environment. Baan ERP has a similar legacy – lots of fun ways to modify it – as did pretty much all the other legacy systems that Infor rolled up over the years. Oracle’s enterprise software was born from a SQL and applications tools mindset that practically dared customers to get in there and play with stored procedures. Etc. Etc.
Why was this concept so popular? Revenue and margins, of course. It certainly fit in well with service providers’ agenda to turn the enterprise software market into a lifelong sinecure by billing customers for expensive customization projects and then getting paid to maintain them ad infinitum. Who could resist the opportunity to sell razors and razor blades to a willing customer base? And it’s pretty easy to see that if the SIs were out building a massive sales channel out of the virtues of selling enterprise software shaving kits, the vendors, whose model also involved selling both razors and blades – aka licenses andmaintenance fees – were obviously, and eagerly, playing along. Lots of shaving being done all around.
And then there was that aforementioned “willing customer base,” a well-shaved one at that. Pity the poor IT department – caught between a razor blade and a strop – desperately trying to finesse the limits of what ERP and the like could do out of the box with the overwrought expectations of lines of business executives eager to… I think many were trying to simply do a better job by demanding more automation and swallowed a little too much ERP marketing Kool Aid thinking first generation ERP could do all that it was hyped to do. There were also plenty of early adopters in the LOBs who were looking at what the competition was doing and just defaulted to thinking they needed one of those three-letter-acronym applications too. “I’ll have what she’s having.”
And much shelfware ensued.
As did a ton of customizations. What better way to get LOB leadership on board than to promise them customizations that would do pretty much anything they wanted? Including emulate old green screen experiences and other bad practices, usually based primarily on whatever everyone was using before they were forced to move to a modern ERP system.
All too often forced was the operative modality: for decades the CIO, in cahoots with the CFO and others in the C-suite, foisted modern ERP systems on a lot of unwilling LOB users. So a lot of CIOs jumped on the customization bandwagon as a way to assuage a LOB leadership that was held hostage by IT decision-making. CIOs also used this new power to rebuild a fiefdom that, until the advent of modern ERP systems, was being crushed by a move to decentralize IT: Distributed computing was the dragon threatening to devour IT’s fortified castle, aka big data centers, and modern, monolithic ERP was the dragon-slayer.
And that, my dears, is how customizations became an all-you-can eat buffet for customer, SI, and vendor alike. So what if you got indigestion every time you filled your plate? At least no one went hungry. And while the myth emerged that CIO means “career is over,” when it came to these overwrought ERP projects, in reality a fair number of CIOs just moved on to the next job. And the next.
(Pausing for a musical interlude. Can’t decide whether Mack the Knife or Over the Rainbow is more fitting here. Depends on whether we’re chasing dreams or being chased by nightmares, I guess.)
So here we are in 2021 and this thing called cloud and this thing called fit-to-standard are now the law of the land. Cloud is where all modern functionality lives or will soon reside, so if you’re looking for innovation that’s where your company has to be. In contrast, on-premise is a graveyard of old processes and technologies, unsuitable for the modern transformational enterprise, or so the marketing pitches would like us to believe. Time to get moving.
Though that is itself another myth. Not all on-premise systems are graveyards unsuitable for transformational enterprises, and not all customizations are bad. Two myths, actually.
Meanwhile, fit-to-standard isn’t just an altruistic gift of tried and true best practices that have emerged fully-formed from the brows of selfless vendors. Fit-to-standard is, more importantly, how vendors make sure that cloud systems are as easy and cheap to maintain as possible. Remember, per user/per month licensing is effectively a fixed fee contract: the vendor has to make its margins regardless of how much each user actually makes use of the cloud system the vendors or its partners run, and that means keeping things as mean and lean as possible.
It’s like you’ve been given a car to speed around in, but someone else has to pay for the gas you use. So it’s in that person’s interest to keep your mpgs down, and if they have to put a governor on the throttle or restrict you from driving on the Autobahn, old school style they’re going to do it, because — profits. That’s the other side of fit-to-standard: it’s about a really good idea for the customer – standardizing business practices – that’s disguising a better idea if you’re the vendor – predictable costs and solid margins for whomever has to actually run those systems.
But there’s a little problem. Actually two problems, and they’re big. First, it’s not clear how many customizations a company has or even what they do or who owns them. As Josh’s 5th aphorism states:
Sometimes companies don’t just have skeletons in their closet they weren’t aware of, there are often entire closets they didn’t even know existed.
(I’m not making this up. I had a client who did an audit at a large healthcare provider and literally found a closet with power, ventilation, and a rack of servers with lights blinking merrily in the dark. No one in the IT department had ever seen it, and the process of figuring out what was going on mostly resembled a bunch of kids making their own bad Keystone Kops movie. Under the fearsome gaze of the HIPAA wall of shame.)
The second problem wreaks further havoc: it’s often really hard if not impossible to determine whether a fit-to-standard function in a cloud ERP app will actually do what the customized app did. Second problem adjunct: it’s even worse if you’re trying to make a decision about sunsetting a custom app based on a vendor’s promised fit-to-standard function, as documented in their product roadmap. When such guidance even exists, it’s usually not in sufficient detail to risk sunsetting an important customized process.
Which immediately fetches up a third problem: what do you do with an LOB user who depends on a custom app, has been given little to no clear guidance on what happens when the ERP system is moved to the cloud, and is now bursting veins in his head yelling about what a disaster moving to the cloud will be?
The answer is a three-part fugue – contrapuntally interwoven, interdependent, the whole is greater than the sum of the parts, etc. As it seems the marketing literature on cloud migrations usually skirts these issues, they definitely bear repeating.
Find the free-range customizations and identify the process owners, ideally before sending out an RFP. Not all customizations are actually owned or used by anyone, and these free-range customizations should be easy to toss. Chasing the rest of the chickens that are still laying eggs and assessing their actual usage levels is step one, and there are numerous tools and partners that can help with this. If it’s truly zero, easy-peasy. But a lot of customizations may be super-critical but used infrequently, such as to help close the quarter or produce some report to feed to a regulator in order to stop her from shutting down your factory for a regulatory violation – which of course happens never, right? Until it does, and if this particular customization wasn’t maintained or migrated correctly you can add the cost of restarting the factory to the total cost of that cloud upgrade. That’s before you get the cleaning bill from the bloody massacre that would ensue.
Bear in mind that a good percent of customizations is owned by IT, and of course they’ll know just what to do with them, right? Not necessarily. Which means those apps may need to undergo the same analysis as the ones owned by individual lines of business. Again, understanding how often and extensively they are used is essential, or you’ll be making a lot of enemies at a time when you’ll be needing a lot of friends.
Convene a pre-RFP fit-to-standard cage fight meeting. I really think waiting to start the process of engaging with users and LOB process owners about this issue after a contract has been awarded is singularly bad practice. It’s actually a bad practice to do anything that falls under the change management rubric after it’s too late for the victims changees to have input. Everyone needs to be presented with a justification for why the upgrade or migration is happening and what the potential impacts will be, and then you’ll need to create a plan for getting their input on how process innovation, renewal, and sunsetting decisions will be will look like after the project is over.
Going over these three possible outcomes is essential. Some customizations will continue on-premise for the foreseeable future, some will be migrated to a new cloud platform (and, through the magic of marketing nomenclature, become extensions instead of mere customizations), and some will be wholly replaced by new fit-to-standard processes. Importantly, be sure your users know these are moving targets that will continue moving after go-live. As stated above, it won’t necessarily be easy or obvious to ascertain what standard cloud processes can replace existing customizations – make sure everyone knows this up front.
Regardless, be prepared for grandstanding, much wailing and gnashing of teeth, and be sure to have everyone check their weapons at the door.
Work with a partner to sort through the options provided by the vendors on your short list. I personally think this is a process no customer should do unaided. As hard as it will be to know who owns what process internally, it will be even harder to understand which vendor can cover that process out-of-the-box in its new cloud product. Having an outsider who is theoretically immune to internal politics provide a more dispassionate analysis could be a big help in unraveling the impact of the pre-RFP fit-to-standard cage fight meeting I referred to earlier. There may be an opportunity to become a beta customer/dev partner for a process that’s on the roadmap, and if the opportunity presents itself, take it. That’s a great way to make sure your business users get what they need.
Like most solutions to bad tattoos, friends who have overstayed their welcome, or a cute but decidedly very bad dog, any real fix to the problem probably won’t yield a perfect solution. That’s the real issue with those legacy software and processes. A company’s customizations probably weren’t perfect to begin with, but over time users learned to live with them, if not genuinely love them. And learning to live with software is actually pretty much how we all survive the encroachment pervasiveness of technology in our lives.
Which brings us to the coda of this post, change management, and a final aphorism:
The majority of problems in the development and deployment of enterprise software are due to a failure to accurately set expectations, and then live up to them.
(This happens to be true for most of human conflict, but let’s not go there now.)
What is really needed in this continuous march towards our digital enterprise future, of which dealing with the interplay of customizations and competitive advantage is a core issue, is an extreme sensitivity to the need for as much transparency as possible. Vendors need to be open about what’s really possible, and not just what marketing wants to be possible or engineering says should be possible. SIs need to open about what’s possible, and, perhaps more importantly, what’s not possible, or the customer will be led once again down a path that usually ends up sending someone over a cliff. And customers need to acknowledge how hard it will be for vendors and SIs to do their part, which means the customer has to double-down on being as open as possible to what is good for the business as a whole, and not just what protects the internal politics of turf and budget and prerogative.
We used to think ERP would solve all our problems, then we customized to solve all our problems, and now we think the cloud would solve all our problems. Maybe it’s time to review the situation….
Leave a Reply