I had a demonstration earlier this year with an organization (that will go unnamed) that decided to build its own internal Spend Management applications, starting first with an application to span the traditional purchase to pay (P2P) footprint. They then planned to expand into sourcing, supplier management and other areas. Like many companies that get wrapped up in custom development, they likely had dozens of talented developers who were itching to get on a new project. As a result, someone in IT was likely able to convince purchasing and other stakeholders to let them go down their own path. Based on what I saw, they were able to create an application that reminded me of where Ariba was around 1997, or perhaps 1996. The foundation was solid, but was missing nearly all of the capabilities we take for granted in advanced deployments today, from supplier self-management of catalog content to line-item approval and routing capability in requisitions.
To be kind, what I watched and heard about was a valiant effort. Yet it was also one that I can’t begin to understand, given how far over a dozen off-the-shelf P2P packages have come in recent years (e.g., Ariba, Basware, Coupa, Verian, Proactis, SAP, Oracle, Ketera/Readen, B-Pack, Intenda, IValua, etc.). Still, despite my amazement that an internal development group would try to build a P2P application from scratch, the exercise does raise an important question: should we ever “make” anything anymore in the make/buy equation for Spend Management and supply chain software? In an environment where vendors are forcing users to get high on their cloud if they want to play in the latest sandboxes, perhaps there’s a more fundamental question we should ask ourselves before taking out the systems shovel and bucket. To wit, is there any place for custom development — and even extreme customization of third-party tools for that matter — in this P2P day and age?
I believe the short answer is absolutely not, at least on the broad modular level in P2P. The thought of building a one-off eProcurement or invoice automation capability is ludicrous, given the work involved and what’s available in the market. However, in the areas of sourcing, contract management and supplier management, someone may convince me after a few drinks that a custom developed deployment might make sense in extreme circumstances (e.g., if a company has an off-the-charts competence in business process management/workflow development or Sharepoint and intends to build the application around its capability to tie into existing highly complicated and unique custom systems it’s already built). Still, even this is a stretch — and a big one at that.
I personally believe that when it comes to customization and truly “making” your own application, that we should not think about modules, but rather different components of an application’s architecture. I can completely buy, for example, a customized one-off front-end UI for an eProcurement toolset to sit on top of an already customized version of SAP, Ariba, Oracle, etc. depending on circumstances such as future upgrade plans. Building your own capabilities may also make sense in the case of customized reporting and analytics as well (especially if an internal competency exists in this area).
I also think we should leave ourselves open to the prospect of what I’ll call extreme customization of off-the-shelf tools when it comes to tying together disparate application areas specific to unique company or industry environments (e.g., linking P2P and sourcing to inventory, asset management, demand/supply planning, etc.) And companies should also leave themselves open to SaaS products and software platforms that enable massive configuration without having to monkey around at the code level in a true customization. SAP Sourcing, Aravo, Intenda and IQNavigator are all examples of where this type of uber-configuration approach might make sense given the inherent flexibility of the underlying platform structures.
Still, if anyone in your IT organization comes to you with a bright idea to replace an application — or to develop a new one from scratch — with something of their own making, I’d approach the discussion with a degree of polite cynicism. While there may certainly be exceptions to the custom development rule, rolling your own module these days really is an odd and unnecessary thing to do. If your IT department has such creativity lurking in their bowels, I’d encourage them to try out for American Idol (or a foreign variant) on their own time. Or something. Let them show their creativity in front of a live studio audience — not you or other stakeholders responsible for key parts of the business.