Experience in organizing planning in mechanical engineering in relation to IT. Part 3
We continue to consider the experience of automation of planning and accounting in mechanical engineering and compare it with approaches in IT. You can read the previous parts of the article by following the links: Part 1 and Part 2
Sooner or later, the growth of an enterprise causes organizational problems, an example of which I gave in previous articles. A manager who was previously very successful in managing a small team, with a constant increase in the number of orders, eventually uses up his limit of capabilities. In the future, according to observations, the following steps are taken sequentially:
Change of manager (without increasing the number).
Another change of leadership with a multiple increase in management personnel.
Activities to “fight for the economy”, which were observed at neighboring enterprises: (for example, the organization of video surveillance, electronic checkpoints – time tracking, automation of warehouse accounting, 5S …).
Automation of production accounting, labor cost analysis.
Rationing, planning and accounting of labor costs.
Capacity utilization planning.
This experience is associated with single and small-scale production, when the labor costs for technological preparation of production are comparable to the labor costs for direct production. There were times when up to 700% was allocated to overhead costs. And perhaps this was even considered the norm, but times change.
If the first 3 points (except for warehouse accounting) have nothing to do with automation, then the work for the automator begins with warehouse accounting and beyond. At the first stages of automation, what was especially memorable was that almost every experienced programmer had “his own” warehouse accounting program. With the advent of 1C, almost all the needs of “consumer goods” were closed, especially accounting. I note that there was a time when, having heard that it was necessary to automate the accounting department, where 100+ accountants work, 1C representatives honestly admitted that 1C solutions were intended for automation of relatively small enterprises. Since then, the number of accountants has decreased significantly, and even now 1C covers most accounting issues quite confidently. And in terms of production automation, there are options.
When automation begins with accounting, then essentially all automation turns into accounting/warehouse maintenance. This approach also has a right to life, but as I already said, at one time I was lucky to get into a department that had many years of experience in organizing production planning. If planning and taking into account the life cycle of design documentation development was not physically possible then, then from the moment of the advent of technological preparation of production, most of the planning problems taking into account production capacities were solved (at least the theory was worked out). Moreover, I worked for many years with people who implemented algorithms for calendar and planning standards on the ES computer.
Fundamental points that I think are worth highlighting:
As a basis for planning, the structural composition and directive route map (DMK) were used – a sequence of operations indicating standards, but without a detailed description of the technical process.
The development of DMK was allocated as a separate stage of technological preparation of production and was carried out as a priority immediately after the assignment of materials and types of workpieces. As a rule, this was done by dedicated specialists with relevant experience.
The preparation of directive route technology was necessarily accompanied by standardization. For this purpose there was a rationing department.
When calculating the duration of the production cycle, inter-operational and inter-shop delays were taken into account.
As soon as we received the DMC with standards, all other planning turned into an exciting game with initial data, algorithm settings and constant improvement of programs with the gradual addition of more and more new factors taken into account.
Unfortunately, this only works in theory. In practice, the automator's capabilities are limited by management's approach.
The first thing management automation begins with is counting the actual time spent by the direct worker on the manufacture of a particular part. The next stage is a long wait until the order is shipped. After a tedious wait for a large number of orders to be unloaded. The more, the more clearly. As a result, “they counted and shed tears.” The excess of fact over plan reached 200-300%. Technologists write what is needed for submission to the appropriate inspection, standard-setters set standards on their own, production works on its own. Each department has different tasks. There is nothing to complain about, they fulfill them. Of course, planning is still a long way off. In the best case, planning is carried out at the level: “we plan to spend N hours out of XXX, included in the contract, on this product this month.”
Next, the connection between norms and facts begins. The work is issued in accordance with the standards and closing time in excess of the standards is possible only when the appropriate document is drawn up. If we do not take into account the conflict side of the issue, then with the right approach, relatively quickly (within several months/quarters), technologists begin to add to the TP those little things that they considered not fundamental. Standard setters begin to make fewer mistakes, and performers, when adequate standards appear, cope with them quite well.
In practice, as a result of the introduction of pp. Standards 3 and 4 practically coincide with the fact that the order economy is brought to an adequate state.
There remains only one problem, which, given the work done, does not seem so significant. But this is a very fundamental problem:
We still don't know how to meet production deadlines.
In theory, since the advent of the DMK, modern hardware capabilities in IT make it possible to build any model of the production cycle. At the same time, it is relatively easy to calculate both the equipment load and any other critical resources. Deviations from the approved schedule can be controlled at absolutely all stages. If deviations occur, you can immediately calculate the impact on shipment deadlines, which allows you to start either correcting the schedule in advance or agreeing on new deadlines in advance.
Now, working in a development team, I come across a lot of words borrowed from the English language, for example, sprint, deadline, etc. At the same time, associations emerge with very old and already partially forgotten concepts:
DeadLine – Critical path (on the product manufacturing schedule)
Store point – Planned labor intensity
Sprint – A daily shift task (with the only difference being that a sprint usually lasts a little longer)
Stop factor – Waiting for another part to be manufactured
Project – Product
Unit – Assembly unit
Form — Sheet part
Table – Part from a circle
Project tree – Structural composition of the product
This list can be continued; when moving from IT concepts to production ones, I find many similarities. At the same time, when I try to compare some concepts from production that are necessary to build a planning model, gaps appear. One of the main examples is the “Directive Route Map”.
As for the structural composition of the product (project tree), when writing a project in most languages, it is generated automatically. Formally, it exists, but for full planning, the structural composition of the product must be ready at the initial planning stage. In addition, complex services are rarely implemented within the framework of a project. So it turns out that the product is several different projects.
Separately, it is worth noting that in the manufacturing production cycle, enormous time/attention is paid to the development of design documentation.
Of the relatively fundamental details, I would like to note that when filling out most of the documents ESKD/ESTD The following fields are provided:
Developed by
Checked
Approved
T.Cont.
N. Counter
Working in IT, I observe the gradual emergence of standards. The scope of control increases. At some point the thought comes that I’ve already seen this somewhere. One gets the feeling that it is only a matter of time – when, at the next stage of development, the project will require doing what has been done in other areas of activity for a long time. It remains only to understand what the long-forgotten revolution will be called in IT this time.
I’ll try to list the milestones that gradually led to an increase in labor productivity at one time:
The transition from manufacture to the factory method of production.
The emergence of specialized equipment/machines.
Standardization of documentation (metric system).
Standardization (fasteners, tools…).
Unification of components and assemblies.
Processing automation (CNC).
Additionally, at 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, over time begins to do the same work faster and/or better.
