Japanese

Excerpt from TPiCS report No. 70.
■ The production for short-term delivery and schedule management.
　The production for short-term delivery is intended to have good response to customers’ needs and to promptly provide them with commercial products. We used to handle this by keeping inventory for products in olden days. But the life cycle for commercial products has shortened and we have faced a growing risk of inventory for products leading to dead stock. Or, we have started thinking about rather making production in response to customers’ needs for a wide range of reasons; for example, variation of commercial products has increased and we have to keep too much inventory if we respond only with inventory for products.
It is difficult, however, to change the principles of the manufacturing industry in Japan, who has single-mindedly been thinking that only the “mass production and cost reduction” was the most important problem to solve since the word of command of “prosperous country and strong army.” In addition, it is very difficult to have good response to customers’ needs with the system that was developed only for the “mass production and cost reduction.” 
　I explain it in the training workshop, too, that “to keep the schedule and to change it are inextricably associated with each other with razor-thin margin.”
If I may use big words, the “essence of management” is make rules, make them open to the public, and everybody keeps them. If they are bad, change them.
This applies not only to the management of general work but also to the production control.
The “rules” are the “production schedule” in the production control. Make the schedule, demonstrate it, and keep it. If the schedule needs to be changed, promptly change it and immediately notify whomever concerned of the changed schedule.” Being organized in words, it looks entirely obvious. So I think there’s nobody who disagrees with this thinking.
　When people are in the midst of it, however, they tend not to be able to make some sound judgment.
It may be because there’s a problem of “suitable time,” “degree,” or “extent.”
The standard of “perfectly suitable time” varies depending on the circumstances of the world. As the circumstances of the world gradually change in an analog way, it turns out that “the standard has become outdated before I know it.”
To achieve the production for short-term delivery is, for example, to “change the schedule for today and tomorrow, and to reflect it in the actual production.” The cycle to make the schedule must be short to that end. And you have to figure out the following in no time at all:   “Is the schedule to change going to be feasible or not? If there’s a problem in it, what could that be?”
That is, you need to “measure the feasibility using the computer.”
Since the f-MRP calculations of TPiCS not only calculate the required quantities but also perform a function to examine whether or not the current production schedule can handle new situations or what that could be if there’s a problem, and to report it (function to write the problem to the journal,) all you have to do is to enter your customers’ needs to the system and to execute the f-MRP calculations in TPiCS.
From this point on is the main issue of this report.
If the schedule in TPiCS has a bunch of malarkey, the calculation result will be meaningless no matter how brilliantly the system does the calculation.
When it come to this story, the discussion always ends in “That’s why we need to correctly register the masters,” and “Inventory in the system has to match the physical inventory, too.”
　If no masters or inventory is correct, the system is useless for sure. But that is not enough.
The entire production schedule used in the calculation has to be the same as the schedule you are going to actually implement. For example, what if you only enter the spots to be changed this time and leave the rest of it as it is, which is the schedule made at the beginning of the month. If the calculation is made based on the schedule you are not going to actually implement, the calculation result will be useless. Even if you received a report saying, “We can’t make production because we have shortage in parts,” after the calculation based on the production schedule in which something that is not going to be scheduled for production is included, it would be of no use. On the contrary, even if you were told that you have too many parts in the situation where the schedule based on which you are going to make production is not incorporated in the production schedule, it would be of no use, either.
Normally there’s the production schedule made yesterday, you only enter changes for today to it, and you have the system calculate it. In other words, the portion you didn’t enter changes to must always reflect the actual production, too. Since you don’t know where to change tomorrow, the entire schedule in the system must always reflect the actual production.
　Let me explain it using a little easier example to understand.
　For example, suppose somebody received a request from a parts maker who cried, “We can’t make the delivery for December 10 under such and such circumstances. Is it all right if we delay just the half of it by 3 days?” Since there are some purchases to replenish the standard inventory and there are some to lot-size in TPiCS, there are a lot of cases where it doesn’t matter that about the half of deliveries is behind schedule. The person who received the call properly looked at the data in TPiCS, confirmed there were no problems at all, and gave the OK. Then he wrote it down in his notebook in a proper fashion, but unfortunately he forgot to apply it to the data in TPiCS.
Afterwards, a product that used the part was added on December 12th, and the child part was required on December 11th.
But the delivery of it was scheduled on December 13th. If this went on, the additional production that should have been added to the schedule was impossible with the data remaining uncorrected in the system － that is, the entire quantity was scheduled to come in on December 10th.So there was no way to give him an alert message. If there was no alert message coming out, there was no way to take the necessary action, assuming that the additional production “was to be made without any problems.”
If you think about this problem, targeting the schedule a few months ahead － that is, the delivery date is far ahead, － it becomes less important. Even if there’s a problem in the schedule to be shown, it can be handled somehow since there’s enough time on the parts maker’s side. On the other hand, it can’t be done means “it can’t be done” in the case of the production for short-term delivery.
　When I told this story in the workshop we hold every month, a young man asked me, “Hearing that story, I feel like it’s contradictory to the story of “keeping the schedule” Mr. Ninomiya was telling about a while ago. How can I interpret it?”
That question is too difficult to answer over a short amount of time. So I said, “Good question,” and tried to look for words for the answer. “Never give up the schedule right away as you say, saying, ‘We can’t do it.’ In contrast, knowing that you can’t do it, it is no good not to apply it to the schedule, either. The best way to get an answer to this kind of question is to return to the starting point and think it over from scratch. What are we making production for? That’s for the customers to buy. It would be useless for them to not buy. We would only be producing industrial waste from factories. We make production to meet the customers’ needs. We keep the schedule for it. In case we can’t keep the schedule, we change the schedule. Our priority is like the above. To express this in a word, it’s going to be, ‘we are going to make customer-oriented production for sure, and we are going to make the schedule for that purpose.’”
　I call this “schedule management.” Managing the schedule itself, the schedule is intended to always become one with the actual production.
In the case of the production for short-term delivery, this becomes very important.
I would like to insert disclaimers here to avoid misunderstanding.
If you can get all the parts and materials in a shorter cycle or you can keep as much inventory as possible to handle all changes no matter how fast the production cycle is, the concept of “schedule management” is not important.

■ SCM Option
　I assume you were able to understand the concept of this option.
But it is a very hard job to achieve this in a fast cycle.
You receive orders from your customers every day, execute the MRP calculations every day based on them, and make purchases. There are a lot of parts and suppliers involved.A call comes in from a parts maker in the midst of extreme busyness and cries for help, “We can’t make it” and “We want it delayed.” If you don’t have a good command of this, you can’t achieve the true production for short-term delivery to survive.
I have developed the SCM Option in TPiCS-X Version 3.1 this time. It is to be able to simply achieve this job.
The SCM Option consists of the combination of the “host program” on the purchasing side and the “terminal program” on the receiving side (partners.)
　It performs the MRP calculations or the manufacturing number explosion in TPiCS-X to create the Order data for parts and materials. It passes the Order data to the database managed by the host program, and sends them as the “Order data” or the “Due Date Reply Request” to mail addresses of the partners via the host program.The terminal program at the partners automatically receives and imports them to the database for the terminal program.
The partners look at the received data to go through whether they can handle them or not, and send the due date replies back to the sender.  If the partners also use (purchase) TPiCS-X, they can import them to the Customer Order data and directly execute the MRP calculations.
Going through delivery dates itself is a difficult job to do. With TPiCS-X being used, however, it prints them as the journal from the f-MRP calculations if there are any parts that can’t satisfy the situation by even allocating the buffer by part in preparation for the fluctuation of customer orders. Going through a pile of workload and this journal, they send the due date replies (due date change request) back to the sender via the terminal program as required. E-mails with the due date replies are directly sent to the address of the purchasing company side, too.
The purchasing side automatically receives the due date replies sent from multiple partners one e-mail after another, and imports them to the database. 
Although they could send back the “Review Request” after looking at the screen of the host program and writing a comment in the remarks field for “unacceptable requests,” they become unable to decide whether or not they should accept the request when they have a great number of due date replies (change requests) from many partners. TPiCS will give them an answer to this, too.  It imports the due date replay data to the database of TPiCS-X at any rate.
Applying these change requests from the partners, they perform the MRP calculations based on day-to-day orders from their customers.
 If they could never get some parts, they would have to ask the customer to change the delivery date. Or, they would have to ask unreasonable things of the parts maker again if there’s room for their review. As a result of reviews and negotiations, the schedule for today is finally determined. This returns to the work explained at the beginning: creating the Order data, performing the final processing, and sending e-mails via the host program.
　It is “absolutely impossible” to perform the MRP calculations with due date change requests from parts makers being incorporated into them in the general MRP calculations. But f-MRP of TPiCS processes them in a quite natural flow. To begin with, since the f-MRP calculation logic assumes the mixture of “something where the schedule must not be changed” and “something where schedule change is possible,” such processing as this is possible.
On the other hand, as there’s no “magic calculation logic” in the schedule with the manufacturing numbers exploded like in f-MRP, it only relies on visual check. When the host program applies due date changes to the Order Balance data and if before and after processes are reversed because of the changes, you will immediately notice that re-adjustments of the schedule will be necessary since the changes are displayed in red in the Gantt chart.
The schedule re-adjustments can be done using the drag-and-drop functionality in the Gantt chart. Many other schedules get involved in these kinds of schedule re-adjustments. Failing to notify suppliers is scary here, too, but the SCM Option allows you to send due date changes to all suppliers involved by e-mail with just another some button clicks when the re-adjustments are finished.
When I myself really think about “serious about the production for short-term delivery” this time, even prepare the SCM Option, and organize anew a story of the actual system operation, I bewitchingly sing my own praises, re-discovering the magnificence of the logic of f-MRP (flexible-MRP) once again.

【Supplemental Explanation】
①  A TPiCS-X user who has the SCM Option installed is called the host user, and a program the host user uses is called the host program.
The system the suppliers use is called the terminal program, and the host user can distribute the terminal program to the suppliers free of charge.
② Both sides need to have the dedicated mail addresses.
③ The [Send] button on the screen of each system triggers the data transmission, and automatically sends the data. As for the receipt of the data, the program on each system automatically receives them from the mail server at the set time interval.
④ The user at the terminal program, when he buys TPiCS-X, can treat the due date reply request data as the “Customer Order data,” based on which he can perform the MRP calculations. And if he uses the SCM Option, he can send/receive due date reply requests and replied due dates to/from their grandchild makers.
⑤ When the program on each system receives the data, it automatically sends the data of notification of the receipt to the other independently of user’s operation.

※In TPiCS-X Version 3.1, the SCM option was called “strategic delivery date adjustment option”.