How we digitized every step of production so that the factory knew exactly what to do, how and when to do it

How we digitized every step of production so that the factory knew exactly what to do, how and when to do it

A steelworker’s apprentice takes a sample of a chemical warehouse of metal at a furnace-bucket installation

Greetings from the Novolypetsk metallurgical plant! In a large project, the most valuable thing is data. In our case, technological production maps and parameters of all products and units: how and what we do, on what, for how long, and which parameters affect the result.

Production is a living system: new processes arise, existing ones change, units are rebuilt, and the code changes. We built the process so that when something starts to be produced, all relevant data is already in the system. Code and data do not lag behind, do not overtake, but go hand in hand.

We have two hyperbrains:

  1. Calendar scheduling plays client-side optimization. It knows what needs to be done and when to ship the order as quickly and on time as possible.
  2. Plotters try to put together an optimal hardware load from these conditions and maybe do something else that can be attached to the existing series. They are responsible for maximum production efficiency in the short horizon.

Both systems use a huge process routing module. All possible routes of all products are stored there, the production technology by aggregates — in general, the path with all the redistributions that the metal makes from entering the steelmaking plant to getting into the wagon that will go to the customer. For this module, we had to collect all production data, bring it to a single view, establish common data exchange protocols and agree with everyone that they will enter, store and use the data exactly as they say.

It took a year to digitize the factory from paper. A lot had to be reformatted so that it fit into the clear logic of tables and data. This was a major and very difficult challenge that grew into an ongoing process that continues to this day.

Metal sample

Why do you need a router?

In the top-level system of KPIG (calendar planning and scheduling), the following data is input:

  1. Sales positions, that is, what we want to do. Each position, upon entering the system, must receive slots on each unit where it will be produced, reserves of materials from warehouses, workers’ time, and so on. That is, a Gantt chart is created with who, on what and when will work with this order. For this, each order goes through the route generator and receives its own production route.
  2. From the route generator comes a lot of master data towards the planning system. These are knowledge tables, descriptions of warehouses, their storage levels (target and maximum), planning rules and restrictions. There is material (route and settings on it: performance, consumption, sequence of operations, allowed equipment, etc.) and its data.
  3. Separately, the equipment repair plan is sent to the entrance.
  4. Also at the entrance is a schedule of incoming supplies of materials that are needed as components. If the paint is not available to such a horizon within the calendar planning, then it is not possible to plan to cover it.
  5. Production quotas (these are strategic level commercial parameters).

That is, calendar planning checks not only that we can make an order in such and such a time, but directly chooses the method of production and “reserves” time and materials at all stages from smelting to shipment.

The router allows you to move from thoughts in the spirit of “the factory can produce an average of so many tons of products per month” to specific numbers of what can and cannot be done.

An example of a chain

Here’s a good example of a chain:

Here there are several ways to produce finished products, but the generator does not choose and does not offer options, but simply acts according to production constraints: the regulatory documentation specifies the priority path for obtaining products, and routing follows it, if possible.

In practice, chains look a little more complicated:

Here is one of the sections larger so that it is clearer what the blocks are here:


The routing system itself does not store the results, but simply checks to see if something can be done and tells other systems how and what it needs to do.

Naturally, the first steps of implementation were quite interesting. So, the user creates an order. Then he can get several types of errors: for example, that it cannot be done or, in principle, it is not clear how to do it. And the problems here are both on our side and on the user’s side. At first, ours often had holes in the regulatory documentation, when it was not clear how to produce this or that product. In this case, analysts came and figured out which piece of information and for which area was missing. And the user – when he could not enter exactly what needs to be done into the system.

In order for the generator to form a route, it needs to know what to do, and then it will take into account the technical documentation and production constraints. At some point, we even had to make an auxiliary system — the author of orders — so that the user could normally specify what he needed. Here is an example of an order before the author appears:

As you can see, there used to be a lot of freedom in notes: three mandatory fields and an entire essay in the notes field. It seems that the requirements are formalized, but not where we would like.

To minimize errors, all this should be spread over different input fields. This is how it looks formalized:

And here is another example. There was:

It became:

Before the advent of the router and the knowledge base of regulatory and reference information (NRI), instructions, guidelines, orders and other documents used different terms for the same things. We went through the entire production and managed to bring it all to a single sample, so that all systems have data about what is happening in an unambiguous form.

The bone grew flesh during the project.

But in the process of understanding how everything will work, new and new requirements appeared for the Research Institute, tables were developed based on the documentation, something was summarized, somewhere they came to the divisions and asked to structure and formalize the data, which was not on paper at all before that.

Fortunately, even when all the technical cards were on paper media, we structured them correctly: they had approximately the same structure, filling rules, and data storage type. This helped us to extend their format to all documents of this type and put it all in the NDI system.

Here is an example of a technical card of a node:

The formation of the NSI system and its filling are constantly in the process of work. In particular, large projects are now being connected to the system, which need to pull data on production routes: this year we are connecting several new units.

We need to create new data tables, add them to the algorithms and add rules.

NSI can be used as a search engine for regulatory documentation. Conventionally speaking, if you need a plate with the properties of metals, you come to NPI. If you need a route linked to the order, they come to the generator. This makes it very convenient to collect documentation during the development of new products: it is convenient to search for the availability of the appropriate technology.

Sometimes users drive the route generator into a dead end by placing orders with parameters we’ve never worked with. In this case, you need to refine the technology and only then take the job.

Standard products

Many technological routes do not require any special semi-finished product, but can use a standard one. This is something that we usually have a lot of in our order book.

Let’s take a rental with a polymer coating. It is usually made from galvanized rolled steel by painting. From the point of view of the order, it is important what kind of paint, surface texture, type of enamel, etc. But if we take a step back to semi-finished products, it turns out that 90% of these orders have a common route to galvanization. Just take a sheet and paint it. That is, for hundreds of types of finished products, the semi-finished product is the same. And it is logical to immediately “splash” all such orders into a short chain “from galvanized rolled steel to rolled steel with a polymer coating”, instead of creating hundreds and thousands of chains for each order. And then it will be enough to add only a few chains of production of galvanized rolled steel. This is the point of conversion to a standard product, and our generator knows how to optimize such points.

Routes are our everything

The route generator should work flawlessly. Its purpose is to provide routes. At the same time, it is necessary to accurately understand the requirements of customers and keep what is stored in the Research and Development Institute in an up-to-date state.

Conditionally, it is necessary to achieve an optimal combination of several parameters. First, the “construction” stage takes place, when several random starting conditions are set.

Then – “improvement”, when the selection and optimization of options continues. And then the route generator gives its routes to the planning system: calendar planning and scheduling.

Routes are the main story in the work of planning and production systems.

They help at the stage of accepting orders, saving us from unnecessary actions, and at the entrance they cut off what we really cannot do. And they exclude the human factor: if a person made a mistake, the system will tell him about it.

The operation of the generator is very important, because everything conditionally depends on it. Incorrect routes can lead to high risks of producing low-quality products. Or get a bad plan where our powers are not used properly.

Related posts