Clarity in MES selection #2

But how do you arrive at a clear MES selection?

We already discussed the most important questions regarding your goals and framework conditions in the last blog post. If you haven’t read it yet, you can catch up [here].

In the second part, we will now focus on your requirements. We will look at the following topics more closely:

• Technical requirements

• Non-technical requirements

• Integration into your production and IT landscape

• Requirements for the MES vendor

In this blog post, we will cover the first two points. Let’s get started!

Clarity on Your Functional Technical Requirements

Even at this stage, it’s important to keep your project goals and framework conditions in mind.

To get an overview and understand the scope, it’s helpful to refer to standards such as VDI 5600 (Sheets 1-8) or overview models like the Manufacturing Enterprise Solutions Association (MESA) Model.

This gives you a good starting point to evaluate an MES based on its functional scope without getting lost in details.

However, alongside the overview, always return to your project goals, as these determine the technical priorities.

Example:

Suppose your goal is to improve production logistics.

The question then becomes: what exactly does this mean for the technical requirements to be specified? Look at your “production logistics” process. What specifically should be improved? Where should automated notifications be generated? Which processes need traceability? Who should be informed, when, and by what trigger?

Without going into all the details, clear technical requirements start to emerge:

• Master data: products, inventory, supplier materials, raw materials including batch information, status information, etc.

• Connection to your ERP system for synchronizing orders, inventory management, product management, etc. – also consider whether master data can be imported from the ERP

• Tracking: product traceability, tracking all types of inventory movements, batch changes, etc.

• Traceability of inventory, including third-party storage

• Quality of goods receipt inspection

• Automated notifications, e.g., for deviations detected during goods receipt inspection

• Test plans for different products or subcomponents

• Workflow branching for remeasurement, rework, returns, etc.

• Automated postings or notifications that trigger logistics actions

This is not a complete list. You will see that by analyzing your processes closely, you naturally arrive at the technical requirements that matter most to you. Perform this analysis for all critical processes!

Additional examples of functional technical requirements:

• Workflows (branching, rework, optional steps), workflow editor

• WIP (“Work in Progress”) management

• WIP display, setting holds, WIP tracking, history

• Material tracking (material history, location, containers, batches, etc.)

• Experiments and measurement results

• Bills of materials

• Binning/classification

• Consumables tracking

• Container management

• Contamination risk management

• Preventive maintenance (PM) management

• Dispatching (machine sequence control)

• Sampling – adjust measurement intensity by product

• OCAPs (Out of Control Action Plans) – handling deviations

• Label printing (e.g., shipping labels with individual information)

• Central recipe management

• Reporting

• Other topics, e.g., Statistical Process Control (SPC)

If you’ve split your goals into multiple phases, the same can apply to technical features: you may not need to license them all from the start, or their priority can be reduced temporarily.

Remember: clear points of reference are essential for making an MES decision. Distinguishing between important, less important, or optional technical requirements can provide such reference points.

Clarity on Your Non-Technical Requirements

In addition to technical requirements, non-technical requirements are crucial.

These may include:

• MES architecture

• Scalability of the solution

• Security (cloud, database, access solutions)

• Performance (extremely important!)

• MES maintenance concept (product cycles, support for older versions, etc.)

• Support concept (SLA) of the MES vendor

• MES monitoring concept

Again, your focus and requirements arise from your goals and framework conditions.

Example: migration and integration requirements
How deeply must the MES integrate into your IT landscape? Good modularization, modeling capabilities, or an elegant messaging structure can simplify integration or migration. A future-oriented, open architecture ensures your solution remains expandable in the years to come.

Also, clarify any IT requirements or regulations that must be considered. As mentioned in the first part, it’s wise to have an interdisciplinary MES selection team—IT should be involved from the start.

Example: MES Architecture

• Client-server concept? Support for virtual servers?

• Message-based? Cloud-based or on-premise?

• GUI concept: fat client, thin client, browser-based?

• Multi-language support?

• Database used – affects licensing and IT capabilities for hosting and maintenance

• Operating system and handling of OS patches

• Scalability: how easily can the solution be expanded?

• Expected system performance: number of simultaneous users, transactions, response times

• System must handle not only human interaction but also ERP, reporting, measurement systems, machine and sensor data – requires sufficient processing power and network speed

• Load distribution concept

A solid architecture forms the foundation for an expandable, scalable, and open solution—essential for the future. Treat technical discussions not just as a requirement but as an opportunity to explore innovative concepts.

Example: Performance

Take the time to define your performance expectations clearly in the requirements specification.

It’s far easier to discuss later whether a transaction should take 2 seconds or 5 seconds than to say “it should be fast.” Clearly define what “fast” means, e.g., “click a button – response within 2 seconds.”

This provides the vendor with concrete guidance for system sizing and allows easy verification of performance.

Define:

• GUI interaction response times

• System query speed

• Processing speed for integration transactions (e.g., ERP order data)

• Processing speed for machine data and transactions

• Measurement data processing speed

• Report generation speed

The principle applies to all non-technical requirements: the clearer you are from the start, the fewer surprises during the project.

Performance is often overlooked early in MES selection because focus is on functional requirements. Later, you may find that certain performance goals cannot be fully achieved due to network speeds, security checks, or database access methods. Clear expectations make it easier to balance these limitations and reach transparent compromises.

As mentioned at the start of this article, the following topics will be covered in the next blog post:

• Integration into your production and IT landscape

• Your requirements for the MES vendor

• Practical tips and recommendations

Stay tuned!

Clarity for You!

Do you have concrete questions about technical or non-technical MES requirements? Want to know how to approach these topics and what to consider?

Are you wondering if digitalizing your production makes sense and what it means for you?

I’m happy to answer your questions in a free online strategy session!

Simply click the blue button below this blog post. I look forward to speaking with you!