HR Vendors Growing By Acquisition

I recently read Brian Sommer’s blog, “Observations from the HR Technology Show” and found his observation that “lots of vendors found fault with competitors that have grown by acquisition” pretty interesting.  Of course you have to take those vendor’s observations with a grain of salt; they’re talking about their competitors after all.  But a couple of aspects of this topic struck me.

First, the argument is that when companies cobble together product and customer bases they can’t possibly achieve as perfect an integrated product set as a company that built them all under one roof.  While this might be somewhat true, and certainly there’s ample supporting evidence in quite a few enterprise software vendors out there (not naming names, sorry, but you can all take a few guesses I’m sure), what’s often overlooked is that the vendor with the “one roof” approach doesn’t necessarily ensure a fully integrated and consistent product set either.  I’ve seen plenty of product suites developed by a single vendor that lack both integration and a uniform UI, and on the other hand I’ve seen products developed by different vendors that are amazingly well integrated and uniform in their user experience (usually as the result of a core SDK that one of the vendors shared with the others, or that multiple vendors used in common).

The other thing that struck me about this topic was the reasons companies acquire other companies: namely to either expand their customer base (company A acquires smaller competitor B), or to broaden or enhance their offering (company A acquires complimentor B).  Is there a difference in the resulting product set’s integration and UI?  That’s a rhetorical question, as the answer is obviously yes, at least in the short term.  In a variant of the 1st type of acquisition (competitor – I say variant because when Microsoft went on this buying spree, they didn’t own any ERP applications), Microsoft acquired 4 ERP applications (Great Plains, Solomon, Navision, and Axapta) and continues to maintain 4 distinct products, code bases, and customer bases.  Competitive acquisitions inherently meld divergent products that were intended to do basically the exact same thing, and there may be little incentive for the buyer (Microsoft, in this case) to assimilate the products into one.  Complimentory acquisitions at least have the opportunity for better assimilation as the products don’t directly overlap in functionality; if they were developed with modern web technologies, giving the products a consistent UI may be a relatively simple matter of matching up the style sheets (integration–true integration, I should say–may be a bit more challenging).

The bottom line is that buyers must evaluate their vendors from the perspective of their functional needs.  If a cobbled-together product set best matches requirements and objectives, what difference does it make if it’s cobbled together through acquisitions?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s