Our tendency to customize
As an IT and engineering consultant, I spend the majority of my time aligning technology with business objectives. As I watch companies grow, I notice more and more software is acquired and uniquely differentiating processes are introduced. As a consequence, traditional off-the-shelf software with its “standard functionality” intended for the masses no longer fits the bill for more innovative firms.
While a superficial build-versus-buy conversations may take place, most companies inevitably purchase astronomically expensive commercial solutions to meet ERP, CRM, and HR needs. They then proceed to heavily customize the solution on day-1, and herein lies the problem.
Unforeseen challenges
Customizing platforms you don’t own is a dicey affair for several reasons. First of all, one needs to ensure that changes are future-proofed against upgrades. In other words, your vendor (SAP, Oracle, SFDC, etc) will inevitably require you to upgrade, and your customizations need to be congruent with future vendor specs.
The second challenge pertains to integrations. Enterprise systems do not exist in a vacuum, but instead function in an ecosystem of interconnected applications. Making a change to a CPQ module may have downstream impacts in your contract lifecycle management solution. Altering core ERP data models may break financial analysis bolt-ons. This reverberating effect creates additional workload for all interconnected systems, and mustn’t be overlooked.
Finally, finding off-the-street expertise becomes harder when the system is no longer in a stock-configuration state. I’ve seen countless CRM consultants baffled at custom Salesforce configurations, and innumerable auditors perplexed by the complexity of bastardized financial systems. Bringing these people up to speed takes longer and costs more than onboarding folks into vanilla system deployments.
Many of these challenges may be expected with a home-grown solution. Yet one of the major selling points of a commercial solution is faster time to market and less overhead, right? So why do we insist on playing this worst-of-both worlds game? A scenario whereby we pay a premium for a platform that doesn’t meet our needs, then endure the hardships of high maintenance to ensure functional fit?
Finding a means of measure
Customization is usually a qualitative affair. That is to say, we either decide to do it or we don’t. We should instead be taking a quantitative approach to measuring both out-of-the-box functionality and the amount of customization needed to get us over the functional fit finish line. Without measuring the cost (monetary or pain) of customization, we enter into a commercial software relationship with our eyes wide shut; a hole which can be dug and dug with no agreeable depth in sight.
When we breach a certain point of customization, it likely makes more sense to choose an alternative, or a composite (best of breed) architecture. For some firms, a completely custom built solution is an option when the product is highly differentiating to the firm. For instance – Tesla apparently built its own ERP solution from the ground up; forgoing the pain of enterprise software altogether.
Whether you run IT at Tesla, Toyota, or Twitter: over-customizing expensive commercial solutions has quickly become a zero-sum game. And for IT leaders, the cost of customization needs to be quantified prior to signing a deal with your global software vendor.
