What procedure should be followed to implement a production planning system?Return to List
Here is an example. Of course, this is not the only absolute way.
1. Organize the situation and challenges faced by the company and factory.
2. Investigate what a production scheduler is.
For that,
- Participate in experience seminars and introduction seminars
- Collect articles on implementation cases
- Gather information from books and web pages
- Try the evaluation version of the package
are some of the methods available.
3. Based on 1 and 2, create a proposal for the "ideal state" of the company and factory. Also, select the members of the implementation project.
4. Launch the implementation project.
Unify opinions on the situation, challenges, and ideal state, and define the project's purpose, goals, and a rough execution plan.
Also, clarify the roles, responsibilities, authority, and various procedures of the project and its members.
5. Draw up an operational plan.
Create a rough proposal on what kind of system to use, how to use it, who will be involved in what and how, and what roles they will play.
6. Clarify the requirements.
Identify the items necessary to realize the operational plan and clarify them as requirements.
Requirements are also called RFP (Request for Proposal).
Sometimes, consultants help in creating the RFP.
7. Decide on the means to realize the requirements.
Usually, proposals are made by system integrators, and one is selected from them. The package is also selected at this time.
In some cases, a prototype is created and evaluated to verify its validity. For this purpose, the production scheduler package can be rented for a specific period.
8. Build the system.
What should be realized and implemented includes:
- Creation of operational procedures and manuals
- Development of interfaces with existing systems
- Preparation of data necessary for the production scheduler
- Purchase, customization, and installation of the production scheduler
- Adjustment of scheduling rules
- Development of a work instruction system
- Development of a result collection system
- Preparation of infrastructure (PCs, servers, networks, mobile devices, etc.)
- System operation test
- User training
are included.
9. Conduct actual operation.
- Data maintenance
- Extraction and examination of issues
- System version upgrade
These continue indefinitely.
If you neglect operations, the system you painstakingly created will quickly gather dust. Conversely, it is important to design an operational method in advance that can be executed without strain.
What kind of data is needed to run a production scheduler?Return to List
In a word, "all information related to items and time" is required.
Specifically, as follows. Essentially, this is the same for any package.
1. Factory operation data
What machines and equipment are available, and when they operate
Who is working, and what are the working hours for each day
2. How to make the products
What processes each product goes through, and what materials and how much are used
In each process, what resources are used and how much time it takes (net operation time)
How much time is required between processes
3. Orders
Which products, how many, and by when
4. Current status
How far each operation has progressed
How much inventory is there for each item
5. Other operational constraints
Changeovers dependent on combinations before and after, transportation time, etc.
In the case of FLEXSCHE, there is a product called FLEXSCHE Editor for visually editing data. By following the introductory guide, you should be able to grasp the general idea. FLEXSCHE Editor Auto Demo
It's difficult to organize the data. Is there a good method?Return to List
Indeed, various data are required. When you think about this and that, it may seem overwhelming and daunting.
However, there is a trick.
1. Data accuracy
There is data that has a significant impact on the whole and data that does not. Focus on organizing data with a large impact, and for those that do not, a moderate level is sufficient.
For example, the accuracy of "required time for each process" is, surprisingly, acceptable at a moderate level initially.
This is because there is not a significant deviation between the data and reality. At most, it would be double or half.
Moreover, even if there is a deviation, there is a method to set efficiency for each resource and correct it collectively. This can bring the idle time in the process closer to reality, resulting in a reasonably accurate lead time for each order.
More important than that is the "available resources for each process."
It is common that the core system only has data on representative resources for each process, but in reality, work can be done with other resources as well.
If there are five other resources available, it makes a sixfold difference.
This is analogous to the relationship between "maximum speed on a highway and the number of lanes." Even if the speed of the car changes, it does not change up to twice, but the passage time changes significantly depending on whether there is one lane or six lanes.
Also, when issuing work instructions, plans that use unavailable resources are not allowed. In that sense, "available resources for each process" is important.
2. Start with what can be easily obtained
However, at first, you may not know what has a significant impact. Initially, prioritize ease of acquisition over accuracy.
If there is already usable data, of course, reuse it.
If there is no data, instead of trying to organize highly accurate data immediately, first prepare data within an easily manageable range.
Examine the schedule results, extract the parts with large deviations, and devise a method to improve the accuracy of those parts. Repeat this process to gradually improve accuracy.
3. Make it independent of the package
It is recommended that the data to be organized should be in an essential data format that depends on the factory, not on the scheduler.
This is because the scheduler is merely a means, and there is a possibility of changing it in the future. The scheduler itself may be able to achieve this with simple settings in future upgrades.
Also, before organizing, data is usually scattered in various places. When aggregating them, many people need to be involved. It is difficult to accurately convey the package's data format to those people at the time of organizing the data.
Therefore, it is better to make it in a format that can essentially represent the factory's information and prepare a converter to transform the data for the package.
However, in the case of small-scale factories, or if you are not familiar with data design, or if there is no data in the core system, it is one strategy to build data according to the scheduler's specific data model.
4. Make it an official task, not a side job
Organizing and maintaining data requires considerable effort and continues indefinitely even after operation.
Therefore, it is out of the question to have someone do it as a side job. The entire organization must recognize it as a very important task and ensure that it is not hindered.
As the production planning system implementation project progresses, the things you want to achieve keep expanding, which becomes troublesome. What should I do?Return to List
Except for critical issues such as system instability, it is usually better to achieve them in the "next step" (this is called "phased implementation").
This is because even a small function, when accumulated, increases the workload. Delaying the completion date makes it increasingly difficult to maintain morale, and the damage caused by delaying the timing of obtaining results should not be forgotten. Also, it is better to avoid troubling the system integrator as much as possible to maintain a Win & Win relationship ("Kindness is not for others").
Furthermore, forcing the system integrator to perform tasks not included in the initial contract may be illegal and problematic in terms of corporate governance.
However, if an essential item is discovered, it cannot be ignored. In that case, priorities are set.
Specifically, for each "thing you want to achieve," confirm whether it is truly necessary, when it is needed, who needs it, what effect it will have, what damage will occur if it is not there, and whether there are other means. Compare these and set priorities. Items with lower priority are postponed.
When advancing a project, various priority judgments are required. In advance, clarify the system, procedures, authority, and responsibility for that purpose. Setting rules before things happen will make things smoother later.
In meetings for the schedule planning system implementation project, opinions are not easily consolidated. What should I do?Return to List
It is quite a difficult problem.
A characteristic of introducing a production scheduler is that various departments are involved.
Moreover, it is not uncommon for relationships to not be very good before the introduction of a production scheduler.
For example, there are many cases where manufacturing and sales have directly opposing opinions, and the production planning staff is caught in the middle, suffering, and the introduction of a scheduler is necessary to resolve this.
What becomes important here is the mindset of "What is the purpose?" In other words, broaden your perspective, confirm the greater cause, and prevent fixation on trivial details.
The construction of a production planning system should be done "for the benefit of the company."
It is easy for conflicts of interest among departments to arise, but let's focus on "which option benefits the company more."
Discussions are not "a battle of winning and losing (debate)." They are "an endeavor to find better methods."
In many cases, even if things seem to be in conflict at a glance, by delving into "what is the purpose?" and analyzing in detail, you will find that they are not truly in conflict, and therefore, some method can be found.
For this reason, it is important to clarify and agree on the purpose of the project itself when launching an implementation project.
Moreover, there is an aspect of "it's easier to do than to worry." There are limits to what can be clarified through discussion alone. For items where it is permissible to try and change if it doesn't work, trying it out is also an option.
That said, it is also true that discussions among only internal members tend to become "Odawara Conference." Advice from experienced consultants or system integrators can be helpful.
In Japan, there still seems to be a strong tendency to be reluctant to spend on consulting in such situations, but considering the lost profits from extending the system completion into the future or failing and stalling, it is usually much cheaper.
However, the problem might be that it is difficult to know where excellent consultants are.
Even if it is difficult to know where excellent consultants are, in many cases, whether a consultant is excellent can be judged by "clarity" and "understandability." This is because consultants do not act themselves but provide guidance on what actions should be taken, so it is necessary to provide a perspective that allows the executor to easily grasp difficult problems. Explaining difficult problems in a difficult way can be done by ordinary people. Flaunting knowledge or experience is out of the question.
To discern this, it is recommended to repeatedly ask "why?" and "why?" This allows you to check how solid the basis of previous statements is. Even excellent consultants are not omniscient and omnipotent, so there may be times when they cannot answer immediately, but even in such cases, they should provide sincere answers, putting the customer first.
What are the key points for successfully implementing a production scheduler?Return to List
The answer to this question also serves as a summary of this entire Q&A.
1. Appropriate Production Scheduler Package
2. Package Utilization Technology
3. Implementation Structure and Approach
These are the three pillars for successful implementation.
[1. Appropriate Production Scheduler Package]
You might think "all production schedulers are the same," but in reality, they are not. Therefore, careful consideration is necessary when selecting one.
Choosing a package that does not fit what you want to do can lead to disastrous results.
If it ends in failure, of course, the cost of the package will be wasted, but that's not all.
The effort will be wasted.
If an appropriate package would have produced results, then compared to that, you are losing profits.
The trauma from accumulating failure experiences cannot be ignored either.
Perhaps it might be better to reselect the package once you realize it doesn't fit. The loss is that significant.
On the other hand, it is not uncommon to realize it doesn't fit only after the implementation project has progressed considerably and is just before full operation. The true value of a package may only be understood after deep usage.
To avoid failure, it is advisable to get help from someone familiar with the package or someone with extensive experience in implementing production schedulers.
Organize what you want to do and ask whether it can be done with that package and how to achieve it.
If you have accumulated implementation experience, you will have a sense of "this area seems suspicious." By checking how each package handles these areas, you should be able to significantly reduce the risk of selection mistakes.
Furthermore, it is common for "what you want to do" and "what should be done" to change even during the promotion of implementation.
This is because, at the start of the implementation, there is often not a clear understanding of what a production scheduler is, and as you progress, you get a clearer image, and only at that point do specific requests like "Oh, if that's the case, I want to achieve this" often emerge.
Also, it is not always possible to identify all operational rules and constraints from the beginning. Sometimes, things initially overlooked turn out to be important.
These are, in a sense, natural, and it is quite difficult to completely avoid them.
As a technique, to confirm what you really want to do and what should be done, and to confirm whether it can be realized with that package, there is a method of creating a prototype to get a feel for it.
In practical terms, creating prototypes in parallel with multiple packages before selection is quite a challenging task. However, at the very least, for the package that emerged as the most promising in the preliminary survey, a prototype should be created.
However, as a repeated point, it is still difficult to foresee everything before package selection.
Moreover, as the system actually operates and continues to be used, situations change, and new requests arise. Rather, it should be recognized that this is normal.
Therefore, when choosing a package, it is safe to choose a "broad-minded" package that can accommodate future requests that are not yet apparent at that time.
[2. Package Utilization Technology]
Even if a package has functions, whether you can use them well is another matter.
In fact, I once participated as a user in a user meeting of a certain production scheduler package (not FLEXSCHE). When I asked other participants about their operational status, I was surprised to hear many responses that it was not operational. When I asked those who said it was not operational in detail, it was about half and half between things that were indeed difficult with that package at the time and things that should be possible if used well.
During implementation, it is necessary to match the requirements of the real world with the functions of the package. In some cases, it is necessary to deeply understand various functions of the package and combine them. It is somewhat like solving a puzzle.
That said, there are tricks to everything. You will have to choose between working hard to find those tricks or getting help from someone who knows them.
However, finding the tricks to using the package on your own may actually be quite challenging. Usually, after experiencing several implementations, you start to get a vague understanding.
Therefore, unless you have someone in-house who can understand ten things from hearing one, it is recommended to get help from an experienced integrator. While it may be difficult to find the method on your own, it is relatively easy to understand something that someone else has found.
[3. Implementation Structure and Approach]
There is a survey result indicating that the success rate of system implementation projects is about 30%. There is also a report that it was 16% in the United States.
If you search the internet with the keywords "system construction project success rate," you will find various results. Please investigate it.
Furthermore, in the case of a production scheduler, there is the troublesome characteristic that many departments are involved. Even a quick list includes production management, manufacturing, sales, procurement, production technology, and the systems department, among others.
During the promotion of the project, those in charge will likely assert their opinions from their respective positions. Different roles lead to different perspectives. Compiling these opinions is quite a challenging task.
Moreover, during implementation, not only discussions but also various tasks requiring considerable effort, time, and labor are necessary. Performing these tasks while handling regular duties is challenging and requires understanding and support from those around. Without this, maintaining motivation becomes difficult, leading to project delays or stagnation.
Additionally, to achieve effectiveness with a production scheduler, it is necessary to change, to some extent, what has been done so far. Everyone naturally feels resistance to abandoning familiar practices. It is also natural to try to defend oneself if one feels their position is threatened.
In such cases, when opinions are not consolidated in discussions or tasks do not progress, it is necessary to reaffirm the original purpose, determine what is important, clarify priorities, convince each person in charge, and lead them to engage positively. Since many departments are involved, it is essential for someone in a position capable of convincing those department representatives to lead. It is a mistake to think that leaving it to a young newcomer who likes new things will suffice.
Moreover, the risk of failure in implementation is everywhere. However, if a rival company succeeds in implementation, you cannot simply abandon the dangerous scheduler implementation. You must find a way to succeed.
What risks are latent? What measures should be taken in advance to avoid them? Experience is crucial in this regard. Therefore, it is recommended to seek help from experienced integrators.
![[Three Pillars of Successful Production Scheduler Implementation]](img/three-mainstays.gif)