MES 配置前需做出的七项制造决策

By Sri Harsha Chakrapani, Process Engineer

A manufacturing execution system (MES) can digitize pharmaceutical manufacturing workflows, capture manufacturing information, and enforce defined process steps. What it cannot do is decide what an ambiguous manufacturing process was supposed to be.

That distinction becomes important during implementation. Configuration workshops can expose questions that existed long before the software arrived: What should happen when equipment is unavailable? Which system owns a material attribute? What happens when a batch cannot follow its normal sequence? Which electronic records require specific controls? Who makes the decision when manufacturing, quality, engineering, automation/IT, and validation requirements conflict?

If teams wait until configuration to answer these questions, they are trying to define the manufacturing process while simultaneously digitizing it. Before detailed MES configuration begins, teams should challenge seven areas.

1. Is The Process Ready To Digitize?

Start with the manufacturing process, not the software.

A master batch record (MBR) can function in a paper environment while still relying on knowledge that is not explicitly written into the record. Experienced operators may understand what a brief instruction means. Supervisors may know which equipment alternatives are acceptable. Quality may know when additional review is expected.

Knowledge that works as an unwritten convention on the manufacturing floor must be made explicit before it can reliably become MES logic.

Walk through the process from material dispensing through batch completion. Review the sequence, material requirements, equipment dependencies, calculations, process parameters, sampling points, hold times, approvals, and operator decisions.

Could two qualified people reasonably interpret this instruction differently? If they could, clarify the manufacturing intent before configuring the workflow. The point is not to remove operator judgment. It is to make clear where judgment is expected and where the process itself is still ambiguous.

The practical output should be a sufficiently mature process flow and MBR in which important instructions, decisions, parameters, and dependencies can be translated into system requirements.

2. What Happens Outside The Normal Workflow?

Process maps naturally focus on the expected sequence: Step A → Step B → Step C → batch complete. Manufacturing does not always follow that path.

Equipment can become unavailable. A material scan can fail. An operator may need to repeat an activity. A parameter may move outside an expected range. A sample may require additional evaluation. An interface may fail. A batch may need to be placed on hold.

Ask: What could prevent the batch from proceeding normally, and what should happen next?

Consider a material dispensing workflow. The normal sequence might be: Production order received → material identified → status verified → quantity dispensed → transaction recorded.

Now challenge it. What happens if the scanned material does not match the requirement? What happens if its status is inappropriate? What happens if the scale or interface becomes unavailable after dispensing begins? Can the operator repeat the transaction? If so, how does the system prevent duplicate recording?

The answer will vary by site, process, procedure, and risk. But the team should decide it before testing exposes the gap.

This is not a universal regulatory template. It is a practical design tool for exposing unresolved manufacturing decisions before configuration.

3. Which System Owns The Data?

MES rarely operates alone. A manufacturing environment may exchange information among enterprise resource planning (ERP), MES, warehouse systems, laboratory information management systems (LIMS), quality management systems (QMS), historians, automation platforms, and equipment controls.

In addition to asking, What information needs to move between these systems?, teams should also ask: Which system is authoritative for that information?

Consider a production order created in ERP and transferred to MES for execution. Defining the interface as “ERP sends the production order to MES” is not enough.

What happens if MES does not receive it? What happens if the same order arrives twice? What happens if critical information is missing? What happens if MES completes an operation but cannot send the expected information back? Should manufacturing continue, stop, retry, or initiate a controlled recovery process?

For each critical data element or transaction, document: Source → authoritative owner → receiving system → transfer direction → timing → failure response.

An interface is not fully understood until the team understands both the successful transaction and what should happen when the transaction fails.

4. What Must The Electronic Record Demonstrate?

Digitizing a batch record should not simply mean recreating a paper form on a screen.

Start with the purpose of the record. For each important manufacturing activity, determine what information must be captured, who may perform the activity, whether review or approval is required, what gives the record context, and how corrections or changes should be managed.

For FDA-regulated records, 21 CFR Part 11 should be considered together with the underlying predicate rules. The FDA describes predicate rules as the underlying requirements contained in the Federal Food, Drug, and Cosmetic Act, Public Health Service Act, and FDA regulations other than Part 11.¹ The FDA recommends that organizations determine, based on those predicate rules, whether specific electronic records are Part 11 records and document those decisions.¹

For an MES team, this distinction is practical. A record required under a predicate rule and maintained electronically in place of paper can fall within Part 11. The FDA also explains that an electronic record maintained alongside paper may fall within Part 11 when the organization relies on the electronic record to perform regulated activities.¹

By contrast, information does not automatically become a Part 11 record merely because MES stores it electronically. That gives project teams a better starting question than: Is this data in MES?

Ask instead: Why does this record exist, what requirement applies to it, and how will the organization rely on it?

For example, an electronic manufacturing record used as the regulated batch record has a very different purpose from a temporary system performance metric displayed only for technical monitoring. That distinction helps the team apply controls based on intended use and risk rather than treating every MES data element the same way.

The FDA also recommends a justified and documented risk assessment when determining computerized system validation activities, considering potential effects on product quality and safety and record integrity.¹

5. Who Makes Cross-Functional Decisions?

MES sits at the intersection of several functions.

Manufacturing understands execution. Quality owns important quality and compliance decisions. Engineering understands equipment and process requirements. Automation and IT understand technical architecture. Validation or computer system assurance functions evaluate whether the implemented solution is fit for its intended use. Those functions will not always prefer the same solution.

The project slows down when no one knows who has authority to close the decision. Before detailed configuration, establish decision rights for recurring questions:

• Manufacturing process: Who owns the intended workflow?
• Quality and GMP records: Who has approval authority?
• Technical architecture: Who owns the system decision?
• Exceptions: Who determines when additional review or escalation is required?
• Requirement conflicts: Who has authority to close or escalate the issue?

This does not require a complicated governance model. A simple matrix showing the decision, accountable owner, contributors, and escalation path is often enough. Otherwise, the same unresolved question can move from requirements to configuration and finally show up again during testing.

6. Can Every Important Requirement Be Verified?

Consider this requirement: The system shall support material dispensing.

It sounds reasonable. It is also difficult to verify. Does “support” mean identify the material? Verify status? Check quantity against a tolerance? Capture a barcode? Prevent selection of an inappropriate material? Record an operator action?

A useful requirement describes the intended manufacturing or quality outcome clearly enough that someone can determine whether the configured solution satisfies it. Ask: How would we objectively demonstrate that this works?

If the team cannot describe what successful verification would look like, the requirement may still be too ambiguous. This does not mean turning user requirements into detailed configuration instructions.

The requirement should define what the manufacturing process needs. Detailed design should determine how the system will provide it. Verification should then demonstrate that the implemented solution satisfies the intended requirement. This separation of requirements, design, configuration, verification, and operation is consistent with the life cycle approach described in ISPE’s GAMP MES guidance.² When those pieces stay connected, testing is less likely to become the first time the team asks what a requirement actually means.

7. Are We Actually Ready To Configure?

The previous questions can be combined into a focused readiness review.

Before detailed configuration, bring together the functions that will design, operate, support, and verify the process.

For project purposes, teams can classify each area as:

• Ready: Sufficient information exists to configure.
• Ready with actions: Configuration can proceed, but identified issues require closure.
• Not ready: A significant unresolved decision prevents reliable configuration of the affected process.
• This classification is a project management tool, not an FDA or ISPE requirement.

For unresolved items, document the issue, owner, expected resolution, and configuration activities affected by the open decision.

Configuration Should Translate Decisions

No readiness assessment will answer every question before an MES implementation begins. Configuration itself will expose details requiring refinement.

The team does not need every detail solved before configuration. It does need the fundamental manufacturing decisions settled early enough that they do not become late project surprises.

Before configuration starts, the team should know the intended process, the important exception paths, who owns critical data and decisions, what the electronic records need to demonstrate, and how the requirements will be verified.

Before configuration begins, the final question should therefore be simple: Do we understand this manufacturing process well enough to tell MES what we want it to do?

If the answer is yes, the team can use configuration for what it is meant to do: translate manufacturing intent into the system. If the answer is no, another configuration workshop may simply uncover a manufacturing decision that still needs an owner and an answer.

References:

1. U.S. Food and Drug Administration. Part 11, Electronic Records; Electronic Signatures — Scope and Application: Guidance for Industry. September 2003.
2. International Society for Pharmaceutical Engineering. GAMP® Good Practice Guide: Manufacturing Execution Systems — A Strategic and Program Management Approach. February 2010.

About The Author:

Sri Harsha Chakrapani is a pharmaceutical process engineering and validation professional with experience in oral solid dosage and API manufacturing. His work has included process validation, cleaning validation, continued process verification, technology transfer, process troubleshooting, quality risk management, and digital manufacturing initiatives. His technical interests include life cycle validation, manufacturing systems, and the practical use of manufacturing data to maintain processes in a state of control.