MPM III - ERP for Blast Curtain Manufacturing

Explosion protection


The customer of this project is a very interesting person who owns a small company that designs and manufactures "blast curtains" - that is, curtains that protect people inside the house when a bomb explodes outside causing glass windows to blow into the room. The curtains they produce are designed to ensure safety and protection against flying glass which - under other circumstances - can be lethal for those who are inside the building.

The customer was looking for a seasoned ERP development company because their great proprietary technology required custom software to manage orders, inventory and collaboration with third-party manufacturers. This was where we came onboard and were tasked with building an ERP system for a small company.

The initial scope of this project was assessed by the architect Dmitry Kiriyenko. The entire development was performed by the lead engineer Eugene Maslov. Quality assurance was carried out by Alexey Lavrukhin.

Modules and functional areas

The MPM project was launched in two stages. The first stage covered customer relationship and calculations to provide clients with a quote. The second release was about the manufacturing process and outsourced tasks management. At the end of the two stages we had the following functional areas implemented:

  1. Customer relationship.
    • The system was to track all customers and their state.
  2. Project management.
    • A new project was created for a new or a returning customer.
    • The project contained settings that allowed to calculate a quote.
    • A company manager could create outsourced tasks required to manufacture the order. The outsourced tasks were included in the quotation.
  3. Price management.
    • There was an admin area with price settings required to generate the quotation.
  4. Order management.
    • Once a project was approved, it turned into an order. This way, an order was a state of the project.
    • At the same time, an ordered project required part of inventory to be written off of the stock.
    • In case some parts of the order were to be manufactured at third-party manufacturers, labels with specs were generated, printed and sent to the manufacturing companies.
  5. Inventory management.
    • The system allowed to manage stock inventory. A company manager was able to add inventory to the stock so that the system could write it off automatically.
    • The inventory was manufacturer-specific: every third-party was responsible for specific parts of the product and required its own inventory to be tracked.
  6. Manufacturing & task management.
    • After the project got to the "in process" state, it could be tracked along with its parts and outsourced tasks.
  7. Project versioning.
    • A project could go through multiple versions and change its cost and settings while a company manager was able to track those versions in every project.
  • ERP - list of projects
  • ERP - project page
  • ERP - inventory

At the end of the manufacturing cycle, the system got an end product ready to be packed according to its packaging settings. Eventually, the product was sent to the client and marked as closed.

Special aspects

The custom ERP system was developed on our traditional stack that included:

  • Ruby on Rails,
  • PostgreSQL,
  • Twitter Bootstrap,
  • jQuery.

The main challenge in this project was the procedure itself as it required close collaboration with the customer and understanding peculiarities of the workflow. Quote calculations were tricky and Eugene managed to make them flexible by implementing a kit of settings allowing to change some general aspects of calculations.

The manufacturing labels are also worth mentioning. The specs required PDF files with a special content to be generated. The content was aligned according to the Avery standards and included the information required to produce the right parts of the project.

The ERP system allowed for using two measurement systems - the metric system and the US standard system. The admin could use both depending on the client's geographic location or personal preferences.


The result was a ready-to-use system for a small company. Since accounting and planning were not requested, the MPM system appeared to be closer to the MRP II standard than to ERP. After the core functionality was implemented, the app went into production. It took three months to launch the two releases and the project owner started using the application.

The system has been in active use ever since. When the customer's in-house developers were ready to take on the project, we handed over the code to them. We still provide them with some occasional consultations.