Reasons for Creating the System and the General Concept
In my previous post, I mentioned some technical aspects “under the hood” of the solution being developed. Now, I would like to explain the reasons behind it and the overall concept driving this solution.
MES systems that I have had the opportunity to see in real-world conditions often fell into two categories in my mind: those “derived from ERP” and those “derived from SCADA.” This distinction inspired me to create my own tool.
Solutions that were extensions of ERP systems—often developed as an additional module for a large client—tended to link production operations so tightly with accounting processes that manufacturing felt more like bookkeeping. Basic functionalities such as searching by serial number or checking the current step for a given serial number were unavailable and required costly custom development. This strong integration meant that the workflow was dictated by financial order rather than product or production process requirements.
The second type of MES system, as I called it earlier, was SCADA-based. These had excellent machine connectivity and impressive visualization of machine processes but neglected manual operations performed by operators. They often lacked the ability to work with individual serialized products, focusing instead on large production batches of n units. Serial numbers were often randomly assigned from the batch, making traceability for a single product practically impossible.
The absence of these features—or the emphasis on aspects unrelated to the needs of a production process that requires precise tracking of every operation, even down to the tool used—motivated me to create the system presented here. The tool enables recording the production process for individual items processed sequentially at different workstations by different operators and tools, while also allowing simple integration with external machines.
Output data from the production process to the main accounting system (planned for version 0.9) will allow full export of information such as production costs (materials) and time, along with workstation load.
A key feature will be minimal requirements for external components (e.g., no need to connect to external APIs or cloud solutions)—the ideal state is 0%.
Currently, I assume the program will be available as Freeware, with installation and maintenance left to the user. The target database is PostgreSQL, and the operating system is Windows with the latest .NET.
The system currently consists of three programs:
I. Version for defining the production process
- Routes
- Material consumption
- Time
- Allowed tools
- Tool consumption
- Control limits for manual measurements
- Control limits for automated measurements
- Operation result (OK/NOK)
- Operating instructions
II. Production instance – the program deployed at production workstations where operations are actually performed.
III. Database structure installer – a simple program that creates the database structure used by programs I and II.