English

TPiCSレポートNo.70から抜粋
■短納期生産と計画管理について
　短納期生産とは、顧客ニーズにレスポンス良く応え迅速に商品を提供することを目的とします。昔は製品在庫を持つことで対応していましたが、商品のライフサイクルが短くなり製品在庫が、死蔵在庫につながる危険が高くなりました。あるいは商品バリエーションが多くなり、製品在庫だけで対応するとあまりにも多くの在庫を抱えなければならなくなるなど、様々な理由により、むしろ顧客ニーズに対応して生産することを考えるようになってきました。
　しかし、「富国強兵」の号令以降、ひたすら「大量生産と原価低減」だけを最重要課題と考えてきた日本の製造業の根本思想を変えていくことは難しく、また「大量生産と原価低減」だけを意識して作られたシステムでは、顧客ニーズにレスポンス良く対応するのは非常に難しいことです。
　私は研修会でも「計画を守ることと計画を変えることは表裏一体、紙一重の差です」と説明しています。大げさな言葉を使えば「管理の神髄」は、ルールを作り、そのルールを誰もがすぐ分かるようにし、皆がルールを守る。そのルールが悪ければルールを変える、ということです。一般的な仕事の管理でも、生産管理でも同じです。
　生産管理の中で「ルール」は「生産計画」です。「計画を立て、計画を明示し、計画を守る。計画を変更する必要があれば計画を速やかに変更し、変更した計画を必要な人に直ぐに伝える」言葉にして整理すると全く当たり前の話になります。この考えに異論を唱える方は、まずいないと思います。
　しかし、その渦中に居ると正しい判断がなかなか出来なくなるものです。それは、“頃合い”“度合い”“程度”の問題があるからかもしれません。“正しい頃合い”の基準は、世の中の状況により変わります。その世の中の状況がアナログ的にジワーっと変わるので、「気がついたら時代遅れになっていた」ということになるわけです。

　短納期生産を実現するということは、例えば「今日、明日の計画変更を行い、実生産に反映させる」ということです。その為には、計画を立てるサイクルも短くならなくてはなりません。また、変更するべき計画が「実現可能か否か？ また問題があれば、それは何か？」を瞬時に把握しなければなりません。
　つまり「コンピュータを使って、その実現性を計る」ことが必要になります。
TPiCSのf-MRP計算は、単に必要数を計算するだけでなく、現在の生産計画で新しい状況に対応できるか否か、あるいは問題があればそれは何かを、ピックアップして報告する機能（問題点をジャーナルに印刷する機能）があるので、TPiCSの場合は、お客様のニーズをシステムに入力しf-MRP計算をしさえすればよいことになります。

　しかし、ここからが今回のレポートの本題です。
　もし、TPiCSに入っている計画がでたらめなら、システムがどんなに立派な計算をしてもその計算結果は意味のないものになります。この話になると、「だからマスターは、正しく登録しなければならない」「在庫も合っていなければならない」という議論で終わってしまいます。
　確かにマスターも在庫も正しくなければ使い物になりません。しかし、それだけで十分な訳ではありません。計算させる生産計画全体が、実際にやろうとしている計画と同じでなければなりません。

　例えば、今回変更になる箇所だけをインプットしても、他は月初めに立てた計画のままだとします。実際にやろうと思っていない計画をベースに計算しても、その計算結果は何の役にも立ちません。生産の予定で無いものが生産計画に含まれたまま計算して「部品が足らないので生産出来ません」と報告されても、逆に生産しようと思っている計画が織り込まれていない中で部品が余ると言われても、全く役に立ちません。
　通常は、昨日の生産計画があり、それに対し本日の変更点だけをインプットし、計算させます。ということは、インプットしない部分も常に実生産を反映したものでなければなりません。明日どこを変更するのか分からない訳ですからシステムに入っている全ての計画は常に実生産を反映していなければなりません。

　もう少しわかりやすい例で説明しましょう。
　例えば、部品メーカさんから「１２月１０日の納品分は、○○の事情で対応出来ないのです。半分だけでも３日遅らせてもらえないでしょうか」と泣きが入ったとします。TPiCSは基準在庫を補充するための発注があったり、ロットまとめした発注もありますから、半分くらいは遅れても問題がないことが沢山あります。その電話を受けた方は、ちゃんとTPiCSのデータを見て、問題ないことを確認してOKを出しました。そして自分のノートにもキチンと書き込みました。しかし残念ながらTPiCSのデータには反映しなかったとします。
　その後、その部品を使用する製品が１２月１２日に追加になりました。子部品は１２月１１日に必要です。
　しかし、部品は１２月１３日にしか入りません。このままでは追加分の生産は出来ないのですが、システムはデータが修正されないまま、つまり１２月１０日に全数入る計画のままなので、警告の出しようがありません。警告が出なければ、その追加計画は「問題なく作れる」と思ってしまい、必要な手を打つことは出来ません。
　この問題は、２ヶ月先３ヶ月先の計画をターゲットにして考える場合、つまり納期が長い場合は、重要性が薄くなります。示した計画に問題があっても部品メーカさん側に時間の余裕があるので、何とか対応することが出来ます。それに対し短納期の場合は、出来なければ“出来ない”ことになってしまいます。

　毎月開催している研修会でこのような説明をしたら、お若い方から「今の話を聞くと、先ほど二ノ宮さんが説明していた“計画を守る”という話と、矛盾するような気がします。どう理解したら良いのでしょうか？」という質問をいただきました。
　短時間で説明するのは難しい質問です。「良い質問ですね」と言って、言葉を探します。「仰るように“出来ない”と言ってすぐ計画をギブアップしては、いけません。今度は逆に出来ないことが分かっているのに計画に反映しないのもいけません。こういう問題を考える場合、答えを出す一番良い方法は、原点に返って考えることです。我々はなんのために生産するのか、それはお客様に買っていただく為に生産するのです。買っていただけなければ、何もなりません。工場から産業廃棄物になって出るだけです。顧客ニーズに応えて生産する。そのために計画を守る。しかし守れない場合は、計画を変える。優先順位はこの順です。これを一言で表すと“顧客本意の生産を本当にやろうと思う。やろうと思う計画にする”という事になります」

　これを私は「計画管理」と呼んでいます。計画自体を管理し、常に計画が実生産と一体になるようにします。
短納期生産の場合、これが非常に重要になってきます。

　誤解がないよう、ここで断り書きを入れます。どんなに速いサイクルで生産する場合でも、全ての部品や材料がそれ以上に短いサイクルで入手出来る あるいは全ての変化に対応出来る程の在庫を持てるなら「計画管理」の考え方は、重要ではありません。

■SCMオプションについて
　この計画管理の考え方を理解していただいたとします。しかしこれを速いサイクルの中で実現するのは、非常に難しい仕事です。
　顧客から毎日注文が入り、それを基に毎日所要量計算をし、発注します。多くの部品があり、多くの取引先があります。目が回る忙しさの中に部品メーカさんから「出来る出来ない」「遅らせて欲しい」という「泣き」が入ります。これをこなしていかなければ、真の短納期生産は実現出来ず、生き残っていけません。
　今回、私はTPiCS-X Ver3.1(2020年現在、最新はTPiCS-X Ver4.1)で、戦略型納期調整オプション(SCMオプション)を開発しました。この仕事を簡単に実現できるようにするためです。

　SCMオプションは、発注する側の「ホストプログラム」と受注側（協力会社側）の「ターミナルプログラム（無料）」の組み合わせで構成されます。
　TPiCSで所要量計算あるいは製番展開して部品や材料の注文データ(計画明細データ)を作ります。注文データをホストプログラムが管理するデータベースに渡し、ホストプログラム経由で協力会社さんのメールアドレスへ「注文データ」あるいは「納期回答依頼」として送信します。協力会社さんのターミナルプログラムは自動受信し、ターミナルプログラムのデータベースへ読み込みます。
　協力会社さんは、受信したデータを見て、対応の可否を検討し納期回答します。協力会社さんもTPiCS-Xを使えば（購入すれば）、それを受注データとして取り込むことが出来るので、そのまま所要量計算することが出来ます。
　納期検討自体難しい仕事ですが、TPiCSを使えば、f-MRP計算により、受注変動に備えた部品ごとのバッファを引当てても対応出来ない部品があれば、ジャーナルとして印刷されます。作業量山積みと、このジャーナルを見て検討し、必要に応じターミナルプログラム経由で納期回答（納期変更願い）をします。納期回答の返信も、発注側の会社のアドレスへ直接メール送信します。
　発注側は、複数の協力会社さんから次々送られてくる納期回答を自動受信し、データベースへ読み込みます。
　ホストプログラムの画面を見て“受け入れられない依頼”は備考欄にコメントを書き入れ「再検討依頼」で返信することも可能ですが、多数の協力会社さんから大量の納期回答（変更依頼）があると、その依頼が受け入れられるものか否かを判断出来なくなってしまいます。これもTPiCSに答えがあります。とにかく納期回答データをTPiCSのデータベースに取り込んでしまいます。
　この協力会社さんからの変更願いを反映しながら、お客様からの日々の受注を基に所要量計算を行います。
　計算の結果、もし変更願いの納期では間に合わないならジャーナルとして教えてくれます。部品が絶対入手出来ないのであれば、お客様に納期の変更をお願いしなければなりません。あるいは再検討する余地があるなら部品メーカさんにもう一度無理を頼みます。検討と交渉の結果、本日の計画を決定します。ここで最初に説明した作業に戻ります。計画明細作成で注文データを作り、ホストプログラム経由でメール送信します。

　通常のMRP計算では、部品メーカさんからの納期変更願いを織り込んで所要量計算をすることは“絶対不可能”ですが、TPiCSのf-MRPは、全く自然な流れの中で処理してしまいます。そもそもf-MRPの計算ロジックでは、「計画を変えてはいけないもの」と「変えられるもの」が混在した中で計算するため、このような処理が可能なのです。
　それに対し製番展開された計画にはf-MRPのような「魔法の計算」ロジックがありませんから、目視チェックになってしまいます。ホストプログラムのなかで、TPiCSの計画明細データへ反映すると、納期を変更したことにより、もし前後の工程と逆転するような場合は、ガントチャートで赤色表示されるので、日程の再調整が必要なことが直ぐ分かります。
　日程調整はそのガントチャートのドラッグ＆ドロップで行うことが出来ます。このような場合の日程調整は、沢山の計画が巻き添えになってしまうものです。その連絡漏れがまた恐いのですが、SCMオプションの場合は、調整が終了したら、また幾つかのボタンクリックするだけで、影響を受けた全てのサプライヤーさんへ納期変更のメールを送ることが出来ます。

　今回「本気でやる短納期生産」を自分でも本気で考え、オプションまで用意し、実運用のストーリーをあらためて整理してみると、f-MRP（フレキシブル-MRP）のロジックのすばらしさを またまた再発見し、ウットリ自画自賛してしまいます。

【補足説明】
①SCMオプションを持ったTPiCSユーザーをホストユーザー、ホストユーザーが使用するプログラムをホストプログラムと呼びます。
サプライヤーさんが使うシステムはターミナルプログラムと呼び、ターミナルプログラムはホストユーザーがサプライヤーさんへ無料で配布することが出来ます。
②双方に、専用のメールアドレスが必要です。
③データの送信は、それぞれのシステム画面の［送信］ボタンで行い自動送信します。受信もそれぞれのプログラムが、設定された時間間隔でメールサーバから自動受信します。
④ターミナルプログラムのユーザーもTPiCSを購入すると、納期回答依頼のデータを「受注データ」として扱い、それを元に所要量計算することが出来ます。そしてそのユーザーがSCMオプションもご使用になると、孫メーカさんと納期回答依頼と回答納期を授受できます。
⑤それぞれのプログラムはデータを受信すると、ユーザーの操作とは無関係に、受信したことを連絡するデータを自動的に返信します。

※TPiCS- Ver3.1では、SCMオプションは「戦略型納期調整オプション」という名称でした。