The Good, the Bad, and the Ugly Series – Part 3

Part 3: Secret Sauce Tasting Notes: How to approach a proprietary system critical to operations

It is one of the most overlooked aspects of deals: you have fine-tuned the valuation model but did not conduct sufficient diligence on the target’s applications environment to determine if it could support growth plans. Eighteen months into the holding period, the portfolio company requires a multimillion-dollar capital investment to replace its homegrown ERP system.

Ever been in this position before? If so, you aren’t the only one, it happens all too often. The good news is that the right IT diligence partner can help you identify this need before close and allow you to factor planned investment into the purchase price. In order for this to happen, your diligence partner will need deep technologists, programmers who have architected and built similar systems. There are numerous components to evaluate, such as:

  • Architecture: Is it multi-tiered or service oriented architecture? i.e., good. Or is the code tightly coupled with multiple architectures? i.e., bad.
  • Technology stack: Is the underlying technology built on modern databases, running on modern hardware? Or is the hardware more than 8-10 years old and out of support?
  • Development processes: How structured is the development methodology? Is the Target using tools to aid with development, test, and release management? Or is it a single resource managing all aspects of the development, testing, and new releases?
  • Performance/reliability/stability: Does the system have a good track record of uptime? Is the transactional capacity reviewed with respect to growth plans? Or is there limited visibility into how the system is performing today, and ability to support growth is an unknown?

Now let’s take a look at some examples to provide color on where proprietary systems rank on the good, bad, and ugly scale.

The good: A company built a core platform to support its supply chain finance business with significant transaction volumes. The platform was developed in house, with a rigorous software development lifecycle (SDLC) process and significant time spent planning and designing the system architecture. Indications of a solid system:

  • Tiered architecture with future scalability in mind during design
  • Organized, modern SDLC frameworks with appropriate segregation of duties
  • Significant and well organized testing (unit, integration, regression, performance) of each new release
  • Continual monitoring of platform performance for capacity planning
  • Regular evaluation of underlying technology, and investment before things start to break
  • Thorough documentation exists, and there is a defined process for collecting requests for enhancements, bugs/issues and new functionality
  • Runs on a modern technology stack

The proactive management and flexibility of their proprietary platform enabled the company to more efficiently onboard new customers and better capture upside from incremental revenue associated with new customer growth and the platform’s ability to scale.

 The bad: An insurance claims processor built a homegrown platform for claims adjudication and processing more than two decades ago.

  • Over time, creates multiple unique instances of the platform for larger customers, each with some variances in functionality
  • Different teams develop/manage unique versions/instances
  • Minimal documentation, and implementation of changes without following any consistent process
  • Aging technology stack, but may still be under support or is internally supported

Due to the lack of capacity planning, performance testing and minimal investment in underlying technology, the platform began to experience significant performance issues and outages. Given the lack of documentation and different teams supporting the platforms, it took many weeks to identify and remediate the root cause of the performance issues. As a result, one of the larger customers left and signed with another provider that it perceived to be more stable and reliable — causing a direct hit to revenue. Had diligence identified the lack of investment in the underlying technology, the buyer may have been able to address the issues prior to the outages and retained the customer.

 The ugly: A custom fabrication shop built their ERP system from scratch in a language the sole developer was familiar with, but skills in this programming language were extremely difficult to find.

  • Over time, adds functionality to meet the needs of the business, but releases are poorly managed, often results in bugs/issues being released into production due to a lack of adequate testing
  • Has core components of the platform that are a third party written and not held in escrow despite viability concerns of that third party
  • Underlying technology stack is more than 10 years old and out of support from the vendors
  • Minimal to no internal resources familiar with source code and architecture

While the system may have been architected fairly well, there were numerous risks and constraints on the ERP platform, giving it a very limited remaining useful life before starting to see serious signs of performance degradation and disruption to the business. The target’s leadership team touted the platform as a differentiator in the marketplace, representing potential goodwill value; however the reality was that the code would need to be re-factored in a modern programming language, significant hardware investments made to upgrade the technology stack, and additional resources hired to manage the effort while mitigating risk around the sole developer.

To account for these risks and potential investments prior to closing, it is critical that diligence resources understand the industry and business, investment thesis around growth projections, programming language used, support and monitoring processes, as well as the underlying technology stack. The result allows investment and operating partners to plan accordingly — from adjusting the valuation to developing a plan of attack. More importantly, sound IT diligence should provide answers to critical questions around scalability, flexibility of technology, and the company’s ability to quickly react to changes in the industry and customer trends. 

The final segment of the series will focus on, arguably the most important factor in deals, the people behind the company. We will delve into the clues and tell-tale signs that indicate potential issues.

The Good, the Bad, and the Ugly blog series is based on a chapter Matt Sondag, Keith Campbell, and I co-authored for The Operating Partner in Private Equity Volume 2 – providing valuable insight to private equity firms on how best to acquire value from an IT operating partner.

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons