M&A: Confusion or Clarity?

There’s been a lot of M&A in the past few years, with companies like SciQuest, Selectica, Xchanging, etc. gobbling up a number of smaller companies with offerings that the acquirer believes could be used to make a full S2S (Source to Settle) suite, and with the recent investment announcements, including this week’s announcement of an 80M investment in Coupa (at a 1 Billion valuation, which the doctor still finds unbelievable), there is sure to be a return to the M&A frenzy of the late noughts that will likely equal, if not exceed, the scale (and occasional absurdity) of the APE Circus. (Which I hope will be accompanied by a return of the Sourcing Maniacs, but alas, the doctor has not heard from them since they told us they were on their way back from their African vacation on New Year’s day five years ago.)

But will it be worth it? First of all, many acquisitions end up being overvalued. (For example, the doctor believes CombineNet is still far in the red, and this can’t be helping SciQuest.) Secondly, many acquisitions have overlap in functionality and offering. Thirdly, many acquirees often use different platforms. Right now, .NET, true C++, Java, and Ruby on Rail frameworks are all quite likely in the space and many acquisition frenzies result in a the merged company having three or more platforms to deal with.

Since, for example, a Source to Pay offering is only valuable if there is more integration than a company could achieve on its own by acquiring separate sourcing and procurement, and, if necessary, contract management and spend analysis platforms, this last point presents a major headache for the newly merged companies. Simply defining the push-pull endpoints and automating the data transfer doesn’t add that much value. A third party integrator can do that. Value comes from real-time end-to-end visibility through the source to pay process for every invoice, shipment, purchase order, contract, supplier, etc.

And the functionality overlap presents another hurdle. Each customer that uses a platform will expect all of the functionality of that platform, so you can’t even consider killing a platform component until all of the functionality is in another platform component. Not only will this take development time and effort while the organization has to support two platforms, but considerable time will be required as bruised egos try to decide which is best to keep and which to discard if both “endpoint” modules appear to be equally valuable.

And then there is the balance of how far to take integration in the short term when sales are rapidly needed to justify the expenditure, pay for the overhead loss as reorganizations occur, and support new personnel to plan development of the next version which will, someday, integrate everything on one underlying stack.

Sometimes it’s quicker, easier, and more cost effective to be patient, just build everything in house from the ground up, and go to market with a truly integrated solution which offers end-to-end visibility because it takes top talent to pull off a successful technology integration. And, by definition, not every company will have top talent with enough expertise across the source-to-pay process to make the right decisions.

the doctor is sure there will be some great success stories in a few years, but there will also be some mega failures as well. And in the interim, we’ll likely have more confusion than clarity.

Any differing opinions?