Seems like every solution provider wants to solve all your problems. That’s why they exist. But what happens when a software company decides to solve those problems by “bolting on” another company’s software product rather than developing the necessary capabilities as part of their core product?
Other articles you might find helpful:
Usually they do that by purchasing other companies or products developed by other companies. So how does that then mesh up with the years spent building their own product to provide certain functions and solve certain problems? They’ve made a lot of decisions during those years about platform, methodology, interface, and so much more. Now they’ve added another product. It has different functions and solves different problems. Together they solve such a wide range of interrelated problems that it seems like marrying them together should create the perfect software, right?
Unfortunately that’s not usually how the story goes. They may “integrate” that other software into their user interface, but most often you’ll find that some of the functionality you were promised, and maybe even saw during the demo, is actually performed by another piece of software altogether. Depending on how the products are integrated you may not initially be aware that the solutions you’re paying for weren’t originally part of the same architecture, but it’s worth asking before you buy because there are some problems inherent to the standard approach of “bolting on” third party applications.
The first problem, although you may not notice it, is the increased cost in both time and money for the customization and initialization phase because you might actually be customizing and launching two, three, or even more different products. In the rare instances where the products are bolted together on the backend, you won’t always see that in the user interface. But, that’s ultimately what is happening behind the scenes.
What you will notice is that the way these products are forced to work together limits the configurations available to you or requires you to log in to multiple products in order to manage all of your documents. For instance, if you have documents coming in as paper, documents coming in via email, and documents coming in via EDI, your staff might have to remember three different processes (and log in to multiple software products) just to get these documents into the system. For most clients that means they will have spent millions of dollars and still will not have a single process that handles all documents regardless of format.
Another cost factor that can easily remain under the radar is higher maintenance fees. You’ll most likely be paying for upgrades on multiple products. Even if the fees are rolled into one maintenance fee, the costs are still passed on to you. Upgrades are simply a cost of doing business and not ROI generating investments, which is one of the reasons a SaaS application is so cost-effective – there is no software for you to upgrade.
However, the real pain point comes down the road. Technology changes and turnover happens. Usually, vendors will find it isn’t cost-effective to keep all of the employees of the company whose product they’ve just purchased. They may retain one or two developers and/or support team members who are experts on that product. So immediately you have attrition of knowledge base. And if those experts see the writing on the wall and move on because they don’t want their future to depend on the fate of a dying software product, or they retire, or they become unavailable for any reason, you have further loss of ability to support the product. New developers might know the platform, but they won’t know the specific software application and they aren’t likely to know accounting or AP best practices.
With all these changes being inevitable, it becomes more and more probable that you will lose efficiency and functionality as time goes by. If you’re seeing a demo today, it’s possible that the process looks relatively simple although using multiple platforms with multiple log-ins is never really simple and can pose a significant security risk. But how will your process have to change after one or more of the products have been through a few updates or has not been updated and has become obsolete? As time goes by the vendor will face the choice of whether to continue updating and maintaining that bolted-on product or to build those capabilities into their core product. If they choose to discontinue their support of that piece of software your staff will have another learning curve which costs you time and money.
DataServ has not needed to rely on third party software for the capabilities we provide. However, should the time ever come when we see an acquisition opportunity that will benefit our clients, we are committed to making sure that product is properly integrated and supported and to being transparent with our clients about why that product is being offered and what they can expect.
Regardless of which vendor you are considering partnering with for AP Automation software, part of your due diligence as you navigate the decision-making process is to learn the genesis of all of the capabilities you’re seeing in the demo. Is the solution you are considering a cohesive architecture or something that has been “Frankensteined” together to meet an immediate market need? Will it allow you to manage all your documents in a single system? Because you’re investing far too much to risk that any part of the solution you’re paying for will be ineffective or unavailable now or at any time in the future.