Production planning in 1C:ERP alone remains paper-based until the shop floor sends back actuals. ERP plans by month, while a machine breaks down today; material is written off by standard, not by what was actually used. As a result, two numbers critical to the plant diverge: output plan and cost. Below is an open breakdown (not a KT.Team case, but a review of public sources) of how this is solved with 1C:ERP + MES + PDM/PLM through a service bus, leaving the 1C core untouched.
What the business gets
The MES↔ERP link delivers measurable results, not just 'transparency in general'. According to an analysis of the metallurgical sector, MES integration with ERP increases OEE by 10-20%, reduces defects by 15-25%, cuts work in progress by about 20%, and speeds up reporting by 5-10x (it.severstal.com}. For finance, this means one thing: planning is based on actual capacity, not theoretical norms, and cost is closed using verified shop-floor data.
Role split: ERP, MES, PDM
The architecture follows the levels of the international ISA-95 / IEC 62264 standard. The plant does not invent its own hierarchy - it uses a mature industry standard.
- Level 4 - 1C:ERP. Top-level planning: orders, resource needs, target due dates, financial close, and cost calculation.
- Level 3 - MES (for example, 1C:MES "Operational Production Management"). Operation-level scheduling, dispatching, batch traceability, quality control, and data collection from work centers.
- Engineering data - 1C:PDM/PLM 4. The bill of materials and routing sheets live in PDM and are fed into the resource specifications that MES later uses for planning.
The key principle is that data flows both ways. From ERP to MES go 'information about the enterprise structure, product master data, incoming orders and production stages' for planning; back from MES to ERP go 'planning results and completed production operations for calculating product cost' (solutions.1c.ru).
How exchange works: standards instead of custom APIs
The rule here is read before you write: ready-made formats are used instead of custom integration.
- EnterpriseData. Typical 1C exchange mechanism: data is packaged into standardized XML with automatic delivery acknowledgements, without building a custom API (gigansk.ru).
- B2MML (Business-to-Manufacturing Markup Language). XML implementation of ISA-95 for exchanging orders, specifications, and resource consumption reports between ERP and MES (symestic.com).
- OPC UA - for connecting MES to equipment at levels 1-2.
Specific data flows:
- ERP → MES: item master and resource specifications, production orders with target due dates, production stages as planning units.
- MES → ERP: stage completion statuses, release documents and production reports, actual material write-offs, and output data for payroll calculation (gigansk.ru).
Why ESB, not point-to-point
Direct connection (COM/web service) works when there are only two databases. But once multiple shop-floor MES, WMS, and PLM databases appear, point-to-point integrations turn into a web of links that cannot be maintained or handed off to another team.
The solution is to place a service bus at the center (ESB, in the 1C ecosystem - 1C:ESB). The logic is simple: 'ERP sends the order once to the bus; the bus itself decides which shop floor (which MES database) it belongs to, based on routing' (gigansk.ru}. That is loose coupling and replaceability: each system can be swapped out or handed to another contractor without rewriting the others.
Planning microservices alongside the core
The most valuable architectural decision is not to modify the 1C core for complex scheduling algorithms. Heavy logic (APS optimization of work-center load, rescheduling after breakdowns, scenario calculation) is moved into a separate planning microservice that listens to events from the bus and returns the finished schedule back to MES/ERP. The 1C core remains standard - it can be updated normally, while the business logic lives alongside it and evolves independently. This removes the classic pain of manufacturing implementations: a hardened configuration that is scary to update because of a pile of custom changes.
Impact on two processes
Planning. The schedule is built not on normative capacity, but on the actual load of work centers: MES returns real stage statuses, downtime, and output. The plan stops 'lying' by the second day of the month.
Cost. ERP closes the period based on actual material write-offs and actual output from MES, not on standards. Financial results become a management tool, not an approximate after-the-fact estimate.
Conclusion: what changes in the business process
The business process plan -> production -> actuals -> cost turns from an open loop into a closed one. ERP stops being the only source of the plan and the only place for custom work: top-level planning stays in ERP, operational planning in MES, engineering data in PDM, heavy algorithms in microservices, and exchange flows through ESB using ISA-95/EnterpriseData/B2MML standards. The result is planning based on actual capacity and cost based on real consumption, while the 1C core is not forked and can be updated normally, and any part of the loop can be handed to another team without rewriting the whole.
