Experience in the organization of planning in mechanical engineering in relation to IT. Part 3

Experience in the organization of planning in mechanical engineering in relation to IT. Part 3

Comparison of planning organization in mechanical engineering with approaches during software development planning

Greetings to all Habra readers!

My name is Kostyantyn, I work in software development at the company “Avtomakon”. At the moment, I am working on a project for SmackVille.

We continue to consider the experience of automating planning and accounting in mechanical engineering and compare it with approaches to IT. You can familiarize yourself with the previous parts of the article by following the links: Part 1 and Part 2

Sooner or later, the growth of the enterprise causes organizational problems, the example of which I gave in previous articles. The manager, who used to be very successful in managing a small team, with the constant increase in the number of orders over time uses up his limit of possibilities. In the future, according to observations, the following steps are taken sequentially:

  1. Change of manager (without increasing the number).

  2. Another change of manager with a multiple increase in management personnel.

  3. Measures regarding the “struggle for the economy” that have been observed at neighboring enterprises: (for example, the organization of video surveillance, electronic attendance – accounting of working hours, automation of warehouse accounting, 5S…).

  4. Automation of production accounting, analysis of labor costs.

  5. Rationing, planning and accounting of labor costs.

  6. Capacity load planning.

This experience is related to single and small-scale production, when the labor costs of technological preparation of production can be compared with the labor costs of direct production. There were times when overhead costs were up to 700%. And maybe it was even considered the norm, but times change.

If the first 3 points (except warehouse accounting) have nothing to do with automation, then the work for the automatizer will continue to begin with warehouse accounting. At the first stages of automation, I especially remembered that almost every experienced programmer had “his” warehouse accounting program. With the advent of 1C, almost all the needs of “living space”, especially accounting, were closed. I would like to note that there was a time when, upon hearing that it was necessary to automate accounting, where 100+ accountants work, 1C representatives honestly admitted that 1C solutions are intended for automation of small businesses. Since then, the number of accountants has decreased significantly, and even now, 1C covers most of the accounting issues quite confidently. As for the automation of production, there are options.
When automation starts with accounting, essentially all automation becomes accounting/warehouse maintenance. This approach also has the right to life, but, as I already said, I was lucky enough to get into a department that had many years of experience in organizing production planning. If it was physically possible to plan and take into account the life cycle of RCD development, then starting with the appearance of technological preparation of production, most of the problems of planning taking into account production capacities were solved (at least a developed theory). Moreover, I have worked for many years with people who implemented the algorithms of the Calendar and Planning Standards even on the EU computer.

The main points that I think are worth highlighting:

  1. The structural composition and directive route map (DMK) were used as the basis of planning – a sequence of operations with an indication of norms, but without a detailed description of the technical process.

  2. The development of DMK was allocated to a separate stage of technological preparation of production and was carried out in priority order immediately after the appointment of materials and types of workpieces. As a rule, this was done by dedicated specialists with relevant experience.

  3. The compilation of directive route technology was necessarily accompanied by standardization. And that is why there was a rationing department.

  4. When calculating the duration of the production cycle, interoperational and intershop layoffs were taken into account.

As soon as we received the DMK with the norms, all other planning turned into an exciting game of raw data, algorithm settings and constant improvement of the programs with the gradual addition of new and new factors that are taken into account.

Unfortunately, this only works in theory. In fact, the capabilities of the automator are limited by the management approach.

The first thing that the automation of management starts with is the calculation of the actual time spent by a direct worker in the production of a particular part. The next stage is a long wait while the order is shipped. After an unbearable wait for the unloading of a large number of orders. The more, the more obvious. As a result – “counted and cried”. The fact exceeded the plan by 200-300%. Technologists write what is required for submission to the appropriate inspection, standardizers standardize by themselves, production works by itself. Each department has different tasks. There is nothing to complain about, they fulfill them. Of course, planning is far from over. In the best case, planning is carried out at the level: “on this product this month, we plan to spend N hours from XXX laid down in the contract.”

Then the matching of norms with the fact begins. The work is issued in accordance with the norms and the closing of time beyond the norm is possible only when the appropriate document is drawn up. If we do not take into account the conflict side of the issue, with the right approach, relatively quickly (within a few months/quarters), technologists begin to add to the TP those little things that they considered not important. Normatives begin to make less mistakes, and in the case of adequate norms, the executors are quite able to cope with it.

In fact, as a result of the introduction of para. 3 and 4 norms practically coincide with the fact that the economy of orders is brought to an adequate state.

There remains only one problem, which does not seem so significant against the background of the work done. But this is a very important problem:

We still don’t know how to meet the production DEADLINE.

Theoretically, since the appearance of DMK, modern hardware capabilities in IT allow building any models of the production cycle. At the same time, it is relatively easy to calculate both equipment loading and any other critical resources. Deviations from the approved schedule can be monitored at all stages. In the case of deviations, it is possible to immediately calculate the impact of shipment terms, which allows you to start or correct the schedule in advance, or to agree on new terms in advance.

Currently, working in a team of developers, I encounter a large number of words borrowed from the English language, for example, sprint, deadline, etc. At the same time, I have associations with very old and already partially forgotten concepts:

DeadLine – Critical path (on the product manufacturing schedule)

Store point – Planned labor intensity

Sprint – Shift-daily task (with the only difference that the sprint, as a rule, lasts a little longer)

Stop factor — Waiting for the manufacture of another part

Project — Product

Unit – Assembly unit

Form — A detail from a letter

Table — A detail from a circle

Project tree – Structural composition of the product

This list can be continued, when moving from IT concepts to production concepts, I find many similarities. At the same time, when I try to compare some concepts from production, which are necessary for building a planned model, gaps appear. One of the main examples is “Directive route map”.

As for the structural composition of the product (the project tree), it is formed automatically when writing the project in most JPs. Formally, it exists, but for full-fledged planning, the structural composition of the product must be ready at the initial stage of planning. In addition, complex services are rarely implemented within the project. So it turns out that the product is several different projects.

Separately, it is worth noting that in the production cycle of manufacturing, a lot of time/attention is devoted to the development of design documentation.

Among the relatively important details, I would like to note that when filling out most of the documents ESKD/ESTD the following fields are provided:

  • Developed

  • I checked

  • Confirmed

  • T. Kontr

  • N. Kontr

Working in IT, I observe the gradual emergence of standards. The amount of control is increasing. For a moment, I thought that I had already seen it somewhere. One gets the feeling that it is only a matter of time when, at the next round of development, the project will demand to do what has been done in other spheres of activity for a long time. It remains only to understand what the long-forgotten revolution in IT will be called this time.

I will try to list the milestones that gradually led to an increase in labor productivity at the time:

  • Transition from the manufactory to the factory method of production.

  • Emergence of specialized equipment/machines.

  • Standardization of documentation (metric system).

  • Standardization (fastening, tools…).

  • Unification of nodes and aggregates.

  • Automation of processing (PPU).

In addition to each of these stages, the division of labor (number of professions) increases. When a narrower specialization leads to the fact that a specialist, gradually improving his skills, later begins to perform the same work faster and/or better.

Related posts