The build vs. buy pendulum has swung and LNS Research is seeing fewer and fewer examples of the internal Enterprise Quality Management Software (EQMS) build. However, the homegrown approach still occasionally makes it through the appropriate decision gates, typically driven by a very strong internal IT team influence. In the world of homegrown EQMS there are two major types: point solutions and enterprise deployments, each with their own unique issues.
Point Solutions Have a Shelf Life
Many existing internally-built technology solutions for quality management systems (QMS) originate from tactical point solutions. These are built to address specific pain points and often originate from a single department, facility, or individual who took the matter into his or her own hands and recruited some technical assistance. The pain suffered is typically evident at multiple plants or facilities and the homegrown solution may or may not be capable of being expanded or duplicated to address the problem for more than one entity. It is not unusual to see a number of homegrown solutions across multiple sites for the same process – a process that would benefit from and should be harmonized. No matter how useful the point solution is, eventually it starts to creak because it can’t scale, doesn’t have the capability to configure for multiple stakeholder groups, and all the intellectual property in its design is in just a few people’s heads with very limited documentation. There’s also generally very limited reporting and the design and user interface is quirky/non-standard.
Enterprise Attempts Are Under Resourced
Blazing a trail in the absence of resource and/or budget to attempt to solve the organization’s quality issues is commendable and shows dedication and initiative, but it's not just from point solutions that internal builds grow; occasionally a more strategic decision is taken to solve the problem for the enterprise.
An example is the use of MS SharePoint or an intranet portal for a document library. Once again, in the absence of an alternative this approach can address a quality management process pain on a large scale. But here’s the problem: there are significant complexities relating to managing documents in the context of enterprise quality management, particularly in highly regulated domains like life sciences and aerospace & defense, and especially when compared to something like a leave request form or expenses policy.
Does taking this approach ever really work for multiple processes? And what about interoperating processes like training and competence linked to documents such as W.I.s and SOPs? Well, in short, the answer is kind of, or maybe in the short term, but not without a huge requirements, analysis, and design effort. Multiply this by 10 or 15 additional processes as well as the inherent interoperability demands, and now an accurate picture of what the organization should be viewing as the end-game is presented.
Two Critical Considerations for Internal Builds
No matter if your company is considering (or more likely living with) homegrown point or enterprise solutions; there are grave consequences to getting this decision wrong and there are two key reasons these approaches are such risky pursuits.
- Your organization has no blueprint for EQMS
Software vendors do have the blueprint – you don't. How difficult can it be though, if we understand the problems well, we understand our own business and processes explicitly, and we have (can leverage existing or purchase) tools for providing forms, workflows, notification, reports, etc.? The design of an EQMS has typically evolved with technology and industry best practices over the best part of at least 15-20 years. There are many vendors with specific expertise in manufacturing, for example and within manufacturing, specific verticals like automotive or life sciences. These vendors have built their platforms with regulatory demands, interoperability, integration, reporting, and analytics as well as core processes in mind. Beyond the feature level, user experience (UX) professionals analyze the finest detail of intuitive design to accelerate adoption and deliver simplicity of use.
The best vendors have product managers from industry with deep experience working in tandem with professional software product managers, analysts and developers full time – ALL OF THE TIME – to address the issues EQMS is designed to identify, manage and resolve. Providers have spent vast amounts of time marrying the challenges of enterprise quality management with technical and delivery solutions in minute detail. They talk to many existing and prospective users (at all levels) across multiple industries constantly. Typically their products have been through 20 or more major releases with huge investment made in tracking and maintaining a backlog of features and fixing a multitude of bugs. Every instance of software has bugs – fact. Vendors obsess about innovating in their niche or mainstream product area and engage ferociously with competition daily to stay ahead.
Consider the fact that despite being "in software development" the vendor community doesn't write its own tools for internal purposes like source control, development environments or release management software because others have mastered the processes and meet these demands for them. They stick to what they do best and aim to excel in it. Ironically they did write these tools in days gone by when solutions were not available, but these homegrown solutions were replaced for the same reasons an organization replaces its patchwork of enterprise quality management tools.
- An internal build = version 1.0 (testing, backlog etc. loss of personnel, ownership, innovation)
That’s right, even if we get everything absolutely spot on with the first delivery of the internal EQMS with regards to functional requirements, non-functional requirements, interoperability, integration, reporting, analytics and much more, it's just the beginning of the life of the solution – it is effectively an infant. Having learned everything about our needs, and made significant compromise along the way because that’s simply the nature of software development, there will be a hefty backlog of work to be done. The solution is now in the wild and will require maintenance and completion of the backlog as issues are discovered and change requests are made. Bug fixes will consume resources and water-tight processes must be maintained to keep all this in check.
A mature EQMS solution will be subject to hundreds of thousands of hours of testing. The product will conform to software development lifecycle (SDLC) best practices and performance and responsive design will be foundational values. At current rates, what one might pay for a modest team of analysts (x2), developers (x3) and testers (x2)--not to mention the sunk cost of professionals providing subject matter expertise rather than driving improvement--would eclipse the maintenance/subscription cost of EQMS for a mid-size deployment. A vendor will be maintaining at 5-10 (in some cases many more) times this headcount in addition to product management, support personnel, and professional services.
The release and maintenance cycle is the eternal fate of every software vendor globally. Roadmaps, both technical and feature based, often stretch out two or three years for them. They have to declare direction and work to it as closely (with agility) as possible to remain competitive. Their efforts are sustained as they aim for growth and stave off competition.
Internal builds make an assumption that the project has an end. It doesn't--it simply goes through phases. The reason for this is, like all the elements of quality management in our own organization, change and continuous improvement are constants that underpin the ability to excel and define markets. There simply is no end; this is a journey. And on it, we ideally need a partner that has deep understanding of our needs today and has a view as to what they will be in the future. This balanced with insight from beyond our four walls. Our focus should be on configuring, deploying, and extracting all the value the solution promises not to mention feeding back into the vendor improvements and changes to drive the platform forward.
Making the Right Decision
If your organization is considering an internal build but has not considered the above two realities; namely your roadmap may be wrong and the perceived destination may just be the start of the journey, stop and reconsider. There have been more than a few companies that have started down the homegrown journey just to revisit and choose a packaged solution years later.
