Build vs Buy Software Series #2: Seven Critical Questions - What Should We Build?

Second article of a blog series: Build vs Buy Software

The first blog post in this series – “Three Critical Strategy Questions” – reviewed some fundamental questions that any company that is considering building an enterprise-scale MES (Manufacturing Execution System) should answer for themselves before embarking on this difficult journey. These considerations include, among others:

• Am I a Software Company or a Products Company (or What Do I Do for a Living)?
• Am I Prepared to Invest in Software Company Infrastructure?
• What is the Relative ROI of Build or Buy?

Let’s assume that your team has done a thorough assessment of your company strategy and has decided to take the process to the next step—that you’re ready to consider building (rather than buying) your own solution. Now, you have to decide what to build—what the end product should look like. Let’s take a look at a framework that can guide you in making those decisions.

Question #1: What functionality do you need?

Mapping out all your current processes, is a valuable opportunity to streamline and optimize your digital infrastructure. This exercise is highly beneficial for operations teams, as it ensures that routes, bills, operating instructions and their associated costs are all up to date. For product structuring, you can apply the traditional industrial engineering approach, using models like the MESA and ISA95 as guidelines. However, be mindful of a few significant cautions:

• Do you suffer from process myopia, and if so, how can you avoid it? Even though you may have a deep understanding of your internal operations, MES vendors have the advantage of working with your competitors AND manufacturers from various industries. They may bring valuable insights that can benefit you. Additionally, the processes you lay out today, must be adaptable to future needs.
• Are you building for a single location or multiple sites with varying needs? A functional analyst can be very helpful in both, listing and prioritizing functionality for each location.
• Avoid ending up with “paper-on-glass” as the final product. Sure, there’s added value in eliminating paper-based processes, but there’s even greater value in achieving automation and integration. When those processes change or evolve, how will you implement these changes and, how will you manage change overall?

Question #2: Which regulatory, industry or customer standards do you need to meet and prove compliance with?

Proving compliance with any regulatory standards, whether to official inspectors or customers, often involves verifying the final product’s design and build. Ensuring compliance with installation, operational or production qualification differs from meeting software design requirements. Additionally, what traceability, compliance, audit, and/or batch reporting requirements will each stakeholder need? Lastly, how will you manage these software delivery tasks?

Question #3: What integrations are critical, important, nice-to-have?

MES doesn’t live on an island. If it does, you’re missing out on significant opportunities for added value, and on the transformative potential of Industry 4.0. At the very least, integration with your ERP system is essential, but you should also consider integrations with other critical systems, such as WMS, QMS, CAD, PLM, ALM, etc. Not taking these integrations into account, can result in “data silos”, which can (and often do) hinder enterprise-wide value creation and complicate system implementation. To avoid these pitfalls, you will need a “common data model”. This approach prevents the problem of non-integrated point solutions that impact many operations teams, today. While MES may seem more extensive in scope and sophistication, its effectiveness relies on seamless communication with other critical systems.

Furthermore, the underlying data model must also consider the various data types you’ll need to manage. For example, MES data is “transactional” – details on orders, materials, production activities and employees involved. Incorporating IoT data adds another layer of complexity, and your data model has to be flexible enough to support various data types.

Question #4: How are you thinking about architecture and deployment strategy today and in the future?

This may require a bit of crystal ball, as your needs today and tomorrow may well be different. This leads to another significant set of decisions. For example:

• What kind of latency can operations tolerate for what kinds of data/transactions? For example, they may depend on alarms/alerts at the machine level which is different than making sure that work orders drop in a timely fashion.
• What kind of system resilience does each of those data/transaction types need?
• ?How does this affect the choice of where and how the system will be deployed—on-premises, in a hybrid setup, or on the cloud? Which databases are most suitable for what types of data, and how will you align them for more complex analyses?
• Will you use a virtual machine or container-based structure, and how does that impact multi-site management?
• What kind of security do you need, and how does that impact all the considerations, above?

Question #5: What scale issues will you need to address in product design?

Scale comes in several “flavors”: degree of flexibility needed, number of locations, amount of data being generated, latency on transmission and analytics—and designing in the capability to manage differences among operations. Once you have discussed these considerations with all the stakeholders, what changes do you need to accommodate over time?

Question #6: What underlying components are you relying on?

Your development team will NOT want to build everything from scratch. There are significant out-of-the-box components that will make system construction more straight-forward. Examples of these include anything from databases, communication protocols, middleware, and the software development kits (SDKs) that enable their integration. Some considerations about using components from 3rd parties:

• How future-proof are they in meeting your evolving needs, and how stable are they as suppliers?
• How good is the documentation you’ll need today and for any future development?
• ?How will you handle future upgrades or changes required by these components, and how might these impact the overall system? How will you validate their performance with your other components AND other systems?
• Are there any validation concerns for the MES system from having used that component?

Question #7: Who will manage and execute maintenance activities?

As the creator, you now own all the QA functions, including software functional and deployment testing, along with future forward migration and deployment. Remember that you’ll have to verify MES performance on your designed network, along with understanding the impact of any network/hardware changes. Additionally, any support issues that arise with software suppliers will need to be managed internally. This requires not only a software development team, but also full QA, deployment and support functions.

We strive to offer an objective point-of-view on this topic and hope you find it helpful. We would also like to recommend exploring the “MES Buyer’s Guide: Why, How, and What”, authored by Julie Fraser, VP, Tech-Clarity. Julie is a renowned expert on this topic, having advised industry consortia involved in establishing MES standards worldwide. You can access the guide through here.

Stay tuned for the next installment in this series where we delve into the major cost categories involved in your build vs buy decision. We’d love to hear your thoughts on this topic and are happy to explore any other subjects that interest you.