How Source-to-Pay Systems Evolve Over Time

Clients Shape Source to Pay Systems with Asks That Drive Development and M&A

You would think that selecting a source to pay system based on requirements coverage would be sufficient to make the best decision. However, I would argue that you should also understand how the system’s evolved over time before buying (development road map & acquisitions). Would you buy and old house before asking for the list of past renovations before buying?

An Old House's Previous Owners Have Shaped the House's Story

When you move in, the house is new for you, but it’s already gone through a lot. Since it’s initial construction, rooms has been used for different uses depending on the inhabitant’s requirements. They’ve also probably done renovations to satisfy specific needs or desires (sun room!). When you move in, regardless of your thoroughness during the inspection, you will find features you didn’t spot initially. Some of these will be a delightful surprise (there’s an ironing board in the kitchen cupboard!) and others will be a continuous bother, impossible to fix at a reasonable price (has this stair always squeaked as we walk by?).

When you seek to carry out renovations of your own, you might stumble upon a load bearing wall that prevents you from turning the kitchen and living room into "an open space". To do so, you would need to tear down the whole house and start over (but how will I achieve feng shui?!). That’s why if you want to mold the house to your needs, you must understand the house's evolution in addition to its current condition (easier said than done!). Can you get your hands on the initial blueprints? Does the city have any data on residents over the years and building permits they may have sought out? Can the current owners fill you in on the house’s stories? Now I hear you thinking: “What does this have to do with my system selection?”.

An Source to Pay System Vendor's Previous Clients Shaped the Structure of the System

A Source to Pay system is a software product which has usually been developed over multiple years by multidisciplinary teams with different backgrounds and levels of expertise. In most cases, it will also be a mix of multiple different systems acquired and melded together over time. Yes, when you "move in" you are getting a fresh new copy of the system but it’s a copy of an "old house" that’s evolved based on previous customer requirements and asks that the parent company is trying to satisfy. Solution modules were "renovated" with development and/or acquisitions of other solutions (sun room!). When you "move in" and implement the Source to Pay system, regardless of your thoroughness during the RFP process, you will find features you didn’t identify or consider during the process. Some of these features will be a delightful surprise (a whole standard set of connectors to another solution you just bought!) and others will be a continuous bother that are impossible to fix at a reasonable price (what do you mean there’s no API to extract this specific piece of data!?).

When you attempt developments of your own (renovations) in the Source to Pay system, you might find out that certain back-end code logic prevents you from implementing the desired change (but how will you achieve business feng shui?!). That’s why if you want to mold the system your needs (or at the very least understand what standards and rules you will need to bend to), you must understand the system's evolution in addition to its current condition (easier said than done!).

So how should you approach your Source-to-Pay software RFx? Let’s find out.

Subscribe to Premium to read the rest.