CUSTOMIZATIONS AND CONFIGURATIONS IN PROCUREMENT SOFTWARE

With yet another summer of superhero action movies upon us, I find myself imagining a world where you could customize and configure your anatomy to make yourself bigger, faster, and stronger. Perhaps make yourself resistant to injury. One can wonder about the complexity of fine-tuning and redesigning human anatomy so that it remains eternally strong, but imagine how that would impact us emotionally and psychologically. Would it be for better or worse? Could it be that having the means to customize and reconfigure ourselves might just be too much work and not worth the effort? What if it didn’t go as planned and became counterproductive, or life threatening?

Let’s peek into the sourcing and procurement technology world for a bit. As we all strive for technological excellence, we should always consider incremental volume of customizations and configurations that would be needed to suit every single requirement. Coding software to support multiple customizations without fully assessing its impact on performance, stability and credibility, would mean risking the software’s utility. Many individual customizations and configurations may be reasonable requirements on a case-by-case basis, but the challenge of maintaining and supporting them could lead to an unmanageable product.

Highly customized and overly-configured systems are expensive to maintain and support, and there is always an impact on other dependent functions, basic functionality, stability and support. Customizations can be good, but only if they can deliver more in the way of benefit than they cost in maintenance and disruption.

The kind of customizations and configurations procurement organizations look for vary greatly. They are dependent on business requirements and often on the particular opinions and perspectives of the senior stakeholders in the business.

Custom attributes, validations, rules, configurations, enhancements, all require impact analysis, performance testing, functional testing, and planned release.

One of the major areas of impact can be on interfaces to third-party systems. If customizing software will impact such interfaces, and that impact has not been thought through, the entire system — from a functional perspective — could be compromised. If that happens, the cost side of the cost/benefit equation suddenly gets much heavier.

Before we take on any highly specific configurations, we always ask (ourselves and our customers), is this really required? How does this change help? Is it a viable solution to a real problem?

This last question is the key. Is there, in fact, an easier solution to the problem in hand than customizing the software, potentially beyond the limit of its utility?

A mature organizational approach would be to understand the cost of software failing to deliver what it should and to weigh that against the perceived benefits.

Perhaps, instead of providing “hot fixes” to a heavily customized tool — an approach which is ultimately not sustainable — forward-thinking organizations should look to provide a best-in-class solution comprising a combination of people, processes and software that delivers the desired results.

In the road to the perfect software “solution,” the people and process are too often forgotten, and yet people using software are — almost by definition — 100 percent more effective than software on its own.

Best-in-class does not mean every possible nuance, process and task hard-baked into a customized software system. It means that the combined efforts of people, using flexible technology, can define — and redefine — processes to achieve the results they seek. In a rapidly changing world, that flexibility is key and is one thing you cannot customize.