Business models and mergers
At some stage in the growth of an information company, it may be necessary to grow by merger or acquisition.
Acquisitions can rapidly add to underlying business growth by virtue of scale. With the increasing scale of operations the fixed costs associated with shared services and overheads are spread across a larger base (providing of course that overhead costs don’t also balloon).
A larger merged company can operate with a bigger footprint, call on additional internal expertise and skills, and is by definition more resilient to economic cycles by being diversified across several industries. The newly acquired businesses provide additional opportunities for the cross-selling of products and services, thereby also improving the prospects for organic growth in the existing businesses.
Many real benefits can only be realised when the acquired business is complementary to the existing business and economies are leveraged by integrating and assimilating the business models into the new parent. In assessing potential merger or acquisition targets, factors such as size, financial health, assets (people and intellectual property), potential, etc are all considered.
I have learned that putting two waterlogged boats together does not necessarily result in an agile structure that floats.
When evaluating mergers or acquisitions, the business model of the acquired business needs to be considered in terms of its total strategic fit into the new entity.
Business models need to be complementary, or at a minimum need to be able to be managed consistently in one organisation. Disparate business models will consume management energy and bandwidth.
The business model of a software product company is different from an IT services company. The business models of a SAAS company are different from a software business that licenses on-premise software. Services business models differ as well. One model might be based on managed services, another on project execution and a third might be based on “body shopping” skills into a market needing specialised expertise.
When merging companies, business models can conflict with each other. Management practices, key performance indicators, accounting standards, management of the intellectual property can all differ substantially between the different business models. Are we measuring productivity in terms of hours billed, licenses sold, or annuity revenue growth?
Great care also needs to be taken when considering the structures that result from a merger. Several examples exist of product and service companies separating into separately managed entities, if not at a legal entity level; at least at a senior management portfolio level. That is why you see job titles such as VP Professional Services separate from VP Product Development. Rarely do you see disparate business models being managed effectively when combined. Leadership generally will prefer one or the other model, it is rare to find the balance needed.
What do you think?
What, if anything therefore materially differentiates the real business models of a software product from a body shop, a SAAS, or a services company? Is it actually possible to effectively operate these different business models in one organisation and how should the leadership structures be designed to optimise performance?
By Gavin Halse
You might also enjoy
An information business is one where you are compensated for sharing your expert knowledge and experience through various means such as consulting, training, coaching, writing, entertaining, etc. You are compensated by the hour. An online information business is the...
A business requirements specification is not the same as a value proposition. If you want to create a product for a defined market, as opposed to a customer, then you need to be able to articulate a value proposition for many customers, not just the bespoke...
There has never been a better time to become a software developer. I realise that not all my readers are geeks and this topic may not be relevant to you. So forgive me for a somewhat technical post, but I feel the subject is important to anyone in a technical career....