Important Things to Consider in a Merger and Acquisition

When doing a M&A, many companies over focus on the balance sheets, and the potential balance sheet that could result from the merger/acquisition. For example, if the company being acquired has a product that could be sold to a large percentage of the current customer base at a pretty penny, if the customer base of the company being merged with would be very likely to acquire the current company’s product, if the combined offering would appeal to a large new customer base, and if the merger could take a considerable amount off of overhead (through facility, asset, and resource rationalization), a merger or acquisition is often give a thumbs up even if the M&A could be toxic. How so? Let’s discuss.

Culture. As pointed out in last Friday’s post on how Fraggles and Doozers Require a Delicate Balance to Co-Exist, if the cultures are opposite and the relationship not delicately balanced then one, or both, sides of the relationship are going to suffer. Badly. And despite one’s belief to the contrary, you can’t always Dance Your Cares Away.

Process. How do the two companies accomplish their daily operations? How defined and rigid are their processes and how much do they overlap? If one company has a practice of just handing out “suggested” budgets and buying what they want and another has a minimum two level approval just to buy a stapler (crazy, eh)? Trying to instill a heavy process-driven no-maverick culture on what has essentially been a wild, wild west is no easy feat, and might take longer, and cost significantly more, than one expects. Considerably.

Data. The number crunching M&A advisors continually underestimate the difficulty of doing systems integration. It doesn’t matter if all of the systems have file export capability, APIs, or even interfaces to third party connective middleware — it’s difficult. Why? In the majority of organizations, data is dirty. Very dirty — full of spelling and classification errors (including SKU/categorization, document ID, timestamp, etc.), duplicates, holes (key fields missing), and so on. And in order to integrate, harmonize, and normalize (down to a minimum number of) systems, the data has to harmonized and normalized so that it can be matched one to one (on common suppliers, products, locations, etc.). This is a significant data cleaning effort, that, in large organizations, can often take months, or even years, due to the huge volumes of data that have built up. The Finance geeks will usually take the word of a high priced consulting firm that will promise their ability to do the project in X months for Y dollars, but then realize when they dig in deep it will at least 3 times as long. This is a huge cost and a considerable delay to expected efficiency gains.

Platform. If the M&A is between two software companies, the purpose is usually to acquire a (semi-)complementary software technology that, when integrated, will provide the combined customer base with a bigger, more valuable (and to the combined company, more profitable) offering — but that’s not always as easy as both parties might expect. Generally speaking, software companies that create software for a living believe “it’s all just code, and we’re good at code, so integration will be no problem”, but that’s not always the case. If the two products are on (completely) different stacks; if one product requires a deep knowledge of complex mathematics, modelling, or data science and the other is just implementing a simple business process without a lot of complicated logic; or if one product requires deep domain expertise (such as insurance pricing in a complex regulatory market, aircraft engine reliability testing, etc.) and the other requires nothing more than a knowledge of modern UI elements, that is definitely not the case. And if the acquiring company is the one whose developers have never coded anything that requires deep mathematics or domain knowledge and the acquired company’s code requires world-class expertise to build, this is generally not an integration that’s going to go smooth, if it happens at all.

In other words, a successful M&A is not all about the numbers — it’s about the synergy, which usually has nothing to do with the numbers at all (but which will typically push the numbers up as soon as the two companies truly become one).

… And Trade Extensions is No More!

As of Thursday, one could look up a Form 8-K filing on the SEC site from May 3, 2017 that simply stated that Coupa had completed its acquisition of Trade Extensions, now called Coupa Advanced Sourcing for those of you on the ball (and watching TE profiles on LinkedIn for updates as well). SI expects you’ll see a formal press release early this week.

While SI completed its initial analysis shortly after announcement, it’s going to hold off publishing until after Coupa Inspire to see if Coupa inspiration changes the doctor‘s mind at Inspire. 🙂 # Look for a deep analysis the week of the 22nd.

(For speculators, you can check out SI’s historical writings on M&A in general and its posts on the importance of cultural conformity in partnerships and then balance these views with the simple fact that only one* acquisition of an optimization platform provider has succeeded in the Sourcing/Procurement space to date, and probably take a guess as to the doctor‘s current view. But it would be only a guess.)

*Tigris was swallowed by VerticalNet; CombineNet shrivelled in SciQuest, now Jaggaer; Mindflow was killed by Emptoris (which was in turn butchered by IBM, whose initial foray into optimization was so bad that they ended up giving it all away for free in COIN-OR) and the founders of Algorhythm subsumed their optimization capabilities into their rapid application development platform Applifire! Only the VerticalNet acquisition by BravoSolution was a success, and likely only because the BravoSolution model required keeping VerticalNet more-or-less in-tact as the US operation of the global BravoSolution organization (as there was essentially no US presence at the time).

#Or at least lets him focus in on one analysis in particular (as his analysis is actually a bifurcated analysis that depends on decisions and directions taken over the next year … will make for a very long blog series as is … )

Fraggles and Doozers Require a Delicate Balance to Co-Exist

Thirty-Four years ago Fraggle Rock debuted on TV. This masterpiece of the late Jim Henson featured a number of races including, but not limited to the Fraggles (that the show was named after) and the Doozers (that were critical to their survival).

The Fraggles (mainly Gobo, Mokey, Webley, Boober, and Red) are small anthropomorphic creatures, typically 18 inches tall with fur-tuft tipped tales, that generally live a carefree life playing, exploring, and enjoying themselves. With their 30 minute work-week, they enjoy their bohemian life-style to the max and are generally worry free as they can subsist mainly on radishes (which grow plentiful) and Doozer sticks (that the Doozers use to build their constructions).

The Doozers are pudgy, green ant-like creatures that stand about 4 inches tall and that live an industrious lifestyle dedicated to work and progress. They spend their days (and the waking part of their nights) busily constructing all shapes and sizes of scaffolds and buildings throughout Fraggle Rock from their Doozer sticks, which are made from processed radishes (and taste like candy to Fraggles).

This gives the Doozers a steady stream of work as the Fraggles love Doozer sticks and tend to eat the constructions on a daily basis, given the Doozers constant space to rebuild.

This is generally the only interaction between the two species, and in Fraggle Rock it makes both groups happy as Doozers like their work to be enjoyed and Fraggles love enjoying the work (by eating it). But this only works because there is a delicate balance between the two races.

Consider what would happen if there were not enough Fraggles relative to the Doozer population. The Doozers would build and build until they ran out of space. Then they would be unhappy as they could not build any more. They would eventually go into a bleak depression, as they need to build creatively to be happy, and some might even become suicidal. Either way, it would be devastating to the Doozer population.

Now consider what would happen if there were too many Fraggles. They’d eat the Doozer’s constructions faster than those poor little Doozer’s could build. The Doozers, who would initially be pleased at the standing ovation, would build harder and faster until they literally collapsed. Then, without the food supply they are used to, the Fraggles, who’d have to resort to a single food source (ground-up radishes), would become very unhappy as this would not only be boring, but they’d have to work a lot more making the food (which would substantially cut into their bohemian lifestyle).

Lesson? Don’t forget to take culture into account in your relationships. If the partner you intend to select has a substantially different, almost opposite, culture, even though opposites attract, if the relationship isn’t delicately balanced, at least one side will wither away. Keep this in mind as you start thinking about that new IT partner (which is on your mind after our three-part series this week that asked should I stay or should I go?)

Box Nation

… most of what America is now is just boxes going back and forth …
Stewie, Family Guy, Season 15, Episode 18

Seth MacFarlane is extremely insightful when he chooses to be. We not only have boxes on pallets in containers going back and forth between countries but we have boxes in trucks going back and forth between local warehouses, stores, postal outlets, and consumer residences … it’s a boxes in, boxes out society. And it doesn’t matter how much we optimize the boxes coming in if the boxes going out still cost too much.

The point is, you don’t just optimize the inbound supply chain if the outbound supply chain consists of lots of small deliveries that will considerably eat up the savings you worked so hard to generate. In order to keep costs down, you have to optimize these little boxes as well.

This means that you not only need to optimize:

  • packaging costs
  • (outbound) distribution costs
  • insurance costs

But you shouldn’t do separate sourcing events, because packaging is used inbound and outbound. Plus, distribution inbound and outbound uses trucks … and while inbound might typically use big trucks and outbound might typically use small trucks, not only is the situation sometimes reversed, but the same carriers often have big trucks and little trucks and the more volume you can source, the better the deal you can get.

And then there is insurance. While the insurance inbound will likely be of the supply chain variety, and insurance outbound will likely be small carrier insurance / goods insurance, it doesn’t mean that both policies can’t be sourced from the same provider, and that you can’t get a better deal simultaneous sourcing.

In other words, if you really want to save money and achieve sourcing success in Box Nation, you have to consider all the boxes, not just the inbound ones. And if you want to be successful, use optimization. Check the archives (linked) for more info.

OEM Software Maintenance: Should I Stay or Should I Go? Part III

After working your way through Torey’s 2-part series, you have probably figured out that it’s a tough decision. It all comes down to ROI, which is a two part calculation. The first part is what does it cost to stay, and what does it cost to go:

This calculation requires filling out the following table at the very least and getting a good feel for total cost outlay either way:

Provider 3rd Party
Annual Maintenance Cost Usually % of License Often Fixed Amount
Estimated LifeSpan Annual Maintenance Cost * (Years-1) Usually fixed amount, sometimes lower for longer lifespans
Required 3rd Party Software Upgrades Extra Provider Costs Extra Third Party Costs
Forced Provider Upgrades Provider Costs 3rd Party Costs
Extra Training Costs if not included if not included
Extra Customization Costs if not included if not in base support
Grand Total $$$ $$$

If the third party cost is significantly less (at least 20%, preferably more, because there are always unknowns and gotchas and switching costs), then you consider switching. But only if there is also value.

Cost alone should not be a consideration. What sort of value will the new vendor bring with them? Will they bring best-in-class processes? Do they have any needed industry and category expertise? Do they consistently out-perform the vendor in areas of inefficiency in the organization? If they don’t also bring value, the savings will be limited compared to what is expected. But if they bring added value, then it’s a totally different story, and one that needs to be read.