📜 ⬆️ ⬇️

Resource management in product development in mechanical engineering

In my previous article, Kanban in the management of product development in mechanical engineering, I reviewed the experience of implementing a kanban system in project activities at a manufacturing enterprise. The system took root and underwent some evolutionary changes. This is a living, ongoing process. In this article I want to develop the theme of project management in terms of resources. I will give examples of optimizing the use of resources in my practice and show the correctness of the chosen approaches based on theoretical knowledge and practice of their use.


1. Prioritize and plan bottlenecks

If you look at our kanban board, where all the tasks are displayed, you can see that the line “Anton” is full of stickers (there are more than 20 tasks in the work). In fact, this means that in our system, the production in the person of Anton is a bottleneck. The tasks here are stuck. It is understandable - the manufacture of parts on the machine from a metal blank, and then the heat treatment of the part takes a little longer than the design of the part. The manufacture of parts may take from several hours to two weeks. In addition, we have a rule that serial production is more important than any design work. This causes problems when planning. But here, despite some level of uncertainty, a series of actions were taken.


')
Firstly, an analysis of production resources was carried out and the following were identified: management, work with hands, work with head. M (or management) is something that can be delegated to production staff. For example, to give the work to machine operators with CNC manufacturing parts. R (work with hands) - this is what Anton creates with his own hands. For example, welding rack, conducts tests for strength. G (head, head work) is work related to the creation of documents, files, diagrams, computer work.



Secondly, each task is assigned an alphanumeric number (01, 03, 50, etc.). The letter indicates the type of resource described above, the digit is the sequence number of the project in the project roadmap. The smaller the number, the more important the project. In the information system in the name of each production task this number is present. Therefore, you can sort tasks by priority in a couple of clicks. Thus, the rule was formulated: "The higher the task in the list, the more important it is."



Thirdly, at the weekly general meetings, the planning of production tasks takes place first, and then the remaining resources. This approach is justified by Goldratt's Theory of Constraints, which says that it is necessary to plan the work of the bottleneck, and to force the rest of the narrow places.

Fourth, the rule has been worked out: “Do not set tasks for production, if all the input data (technical process, design documentation, materials, blanks, standard products, tooling) are not enough”. It just keeps your nerves, as the performers on the production, who frantically search for components, and they simply have not brought, and the project manager, who once again does not need to explain the situation about the reasons for the delay components. Let the manager go gray alone, but save the nerves of production.

2. Create and maintain a task flow

In the IT field, there is such a thing as backlog of tasks. He is also present in our kanban board: the right column is next to the name of the resource.



It is not enough just to set tasks, it is important to understand that it is necessary to support their constant movement. When there are many tasks, they look like a crowd of people trying to crawl through one narrow door, but get stuck in it. The analysis carried out above makes it possible to understand the bandwidth of resources and create a more or less level queue of tasks, when exactly one task enters the door at a time. This approach is justified by the law of Little . It boils down to the fact that the shorter the queue, the faster the tasks in the queue are performed. This is intuitive, but not always performed by us. As a reminder, I made this rule on my working laptop.



In practice, this means that there should be exactly as many tasks in the work as the resource can perform in a certain period of time. For example, production tasks are set for a week. Production capacity: 9 tasks per week. Accordingly, at the same time in the work can not be more than 9 tasks. The remaining tasks remain in the backlog, waiting for queuing.

The tasks of the designer, technologist, technician, marketer, designer, supply (as they are ineligible) are becoming more transparent and planning takes place daily.
Creating and maintaining a task flow means the following: there should be fewer tasks, but they should be completed faster and replaced by other tasks more often.

3. Search for reserves of resources within the enterprise

I had to think about the search for resources within the enterprise and optimize resources when I discovered that Sergei, our technical writer, has about 30 tasks of varying levels of complexity to perform. This is not so surprising, since at the same time at different stages of development we have 16 projects. On the daily flyers, I just had to repel the onslaught of the marketer that Sergey was busy with anything but marketing tasks. In addition to being a technical writer, he was writing articles to the company's blog, developing operating instructions, SMM, and he was responsible for developing the product packaging instructions. With the fact that, in developing the packing instructions, Sergey worked, as we call it, a typewriter - he just put the information received from the packing area into one file. This monkey job wiped out the professional capabilities of our technician.

How did you manage to free up the resource?

The development of packing instructions was delegated to the warehouse staff. To do this, it was necessary to analyze the current business process of developing instructions, develop a new process, conduct employee training, implement and debug the process, make edits to typical project tasks. In total, all these manipulations took about two weeks to identify the problem and stabilize the process.

Let's look at the results:

- The number of tasks for projects at the technical writer was reduced to 4;
- freed up time for SMM and marketing;
- time for the development of packing instructions has been reduced several times due to the fact that people have become involved in them in the field. Here I was guided by the following Japanese production principle: “If you want to solve a problem, go to gemba [workplace], where this problem arose.” In other words, people who work according to instructions know better how this instruction should look. Therefore, the development of instructions began to take less time.

Thus, the need for routine monitoring of the task of developing packaging instructions has virtually disappeared - it is solved in the background and requires no more than 10–20 minutes of monitoring on a weekly basis. The question of packing fell out of the agenda of volatik.

4. Develop and implement regulations

As the Japanese say: “Whenever deviations appear in the current process, the following questions should be asked:“ Did this happen because we did not have a standard? Did it happen because we didn’t follow the standard? Was it because the standard was not adequate? ”(Gemba Kaizen: The Path to Cost Reduction and Quality Improvement; Masaaki Imai).

Losses in resources often arise from the fact that people do not know how to act correctly (there is no standard), violate the standard (do not follow the standard), or the standard is bad and needs to be revised.

In any case, the presence of a standard is always better than its absence. The standard is a tool for further improvement and dialogue between people within the enterprise.

In my practice, I repeatedly encounter the fact that the task is not being carried out or is delayed due to the fact that there is no understandable process of work. Therefore, in any incomprehensible situation, it is customary to develop business processes for even the most seemingly simple procedures.

At the moment, all processes, schemes are drawn in a regular excel document. In the future we plan to transfer all these processes to the bpm-system.



5. Follow the logical steps of the project.

Product development is often a process with unexpected turns, when the date of readiness of the working prototype is shifted to the right, or even completely postponed. And when dealing with technologically complex projects, the risks increase dramatically. Yes, risks are risks. But now let's talk about something else.

You always want to reduce the time before the product enters the market and begin to prepare for the exit in advance, when there is no working prototype yet. A lot of resources are spent: marketing materials are being prepared, components are purchased for a pilot batch, texts are written in a blog, posts are posted on instagram, and other things necessary for product exit are made. Now the prototype is almost ready, but ... The prototype did not pass the tests and we move a few steps back - to the development stage. It turns out that the resources involved in the launch of the product in the series, if not lost in vain, were used inefficiently. At this particular moment they could be used in other projects.

In a desire to bring the product to the market closer, the team and the company were idling. Therefore, we have developed a rule to follow the logical stages of the project. It is better to lose a little in time resources than in man hours and money. This is all the more easier to achieve when the customer is internal, like ours.

6. Consider tasks outside projects

Again, drawing analogies with the IT industry, I want to touch on the topic of product improvement. Improvements concern both consumer properties, and bringing to mind the things that are not visible to the consumer. Write about this aspect of me prompted a recent article on the Habré about technical debt .

I will give an example.

Technologist in our company appeared a little over a year ago. All new projects since then began to be worked out by him. However, there are many products that have been produced for several years, but the technological development of which has not been carried out. The same applies to the accounting of the production part in 1C: write-off of metal components, the movement of semi-finished products from processors and more.

Accordingly, in order to recycle old products, it is necessary to expend additional (and not small) resources. As we have calculated, this is work for several months. And we took it. Tasks for the processing of products are set in the same way as project tasks, put on a kanban board. This adds transparency in the use of resources. We made it a rule that only one project is being processed at a time.

Thus, we strive to ensure that any task should be taken into account.

The simple steps described above help to save resources, make project management convenient, and work more predictable. What is really proud of is that these rules are based on my own experience and are consistent with the experience of other teams.

Source: https://habr.com/ru/post/338418/


All Articles