【日本の製造業・生産管理の立て直しの課題と改革の方向性】 最終回 フレームワーク化した生産管理を取り巻くシステム群

●生産管理がいまだ表計算の山に埋もれている日本の工場

日本の工場に行くと、システム化が非常に遅れている印象を受けます。優秀で勤勉な人に支えられてきたため、人に依存した生産管理になっているのです。
直接作業はIEのおかげで作業分析が行われ、標準化をした上で作業が設計されました。一方、生産管理に代表されるような間接業務は、自然発生的な仕事のまま、人が表計算ソフトを駆使して回しているような状況です。
また、実績収集も手書き帳票に記入後、手作業で集めて表計算に打ち込むといった有様です。集計も表計算ソフトで行われており、何枚ものシートを渡って再計算され、作っている本人しかわからないような複雑なシート構成になっています。
立派な設備は製造のために入っていますが、システムでは統合されておらず、島宇宙のように存在する設備に手入力で指示を出し、そこから表示される実績や製造条件、稼働状況は手書きで紙に写し取られ、表計算に入力されます。
稀にERPが使われていることもあります。古いホストで生産管理と称されるシステムが動いている場合もあります。しかし、データの入力は人力で行われており、帳票は紙で出力されていれば、高機能なシステムであっても単なる伝票・帳票発行マシンか、手入力された実績を蓄積する"箱"程度になっているのです。

システム統合=SI:System Integrateなどは夢、個別に存在するシステムをつないでいるのは紙と表計算ソフトと人間といった有様です。


●生産管理をシステム化するには明確な業務デザインとシステムへの橋渡しが必要

このようなご時世に至って、なぜこのような状況になっているのでしょう。原因はいろいろあり、そもそも日本人は仕事を定義しないのです。人だけあつめて、作業ベースで知恵を出せと言って業務を自然発生的に始めてしまいます。また、フレームワーク思考が弱いので、思い付きや現場の創意工夫でどんどん仕事を複雑化します。システムに関する理解が弱く、どう使うべきか明確な考えがありません。人が大切と言いながら、その貴重な人は属人化した作業に使われ、オペレーションレベルの仕事しかできず、生産管理を生産マネジメントとして考えられないためERPなど夢の夢なのです。
まず、私たちは、工場の仕事はどうあるべきかを考え、生産管理の業務を生産マネジメントと工程管理・製造管理を切り分けて定義しなければなりません。その上で、その業務をシステムで実現する時の要件定義と運用の在り方を、業務・システム両方に理解のある人が設計作業へ橋渡しをしなければならないのです。


それだけではありません。そうした業務の話だけではなく、工場のITを支えるシステムインフラの知識も必要なのです。設備の出す信号データをPLCに送り、MESを経由してERPに連携しなければなりません。機器間の通信、データ変換、ネットワークや通信プロトコルの整合や標準化、PLCの配置と統合、サーバーの配置とMES、ERP、BIといったシステムのインフラ上の統合ができなければなりません。
インフラの統合と各システムアプリケーションの統合ができなければ、IoTの実現など夢想にすぎません。そもそも、IoTだの、ビッグデータ・AIだのといったツールや流行りのコンセプトに飛びつく前に、業務デザインと整合したシステムインフラとアプリケーションの設計・構築が先なのです。



●SCM、ERP(MRP)、BI 、MES、WMS、LIMS、PLC、IoT端末、PIMS

生産管理を支えるシステム群は様々です。まず、生産マネジメントとしては、SCM、ERP(MRP)、BIがあります。既にこのコラムで書いてきた通り、生産マネジメントとしての業務デザインを経てから導入します。
また、今まであまり明確に書いてきていませんが、小日程計画システムであるスケジューラーが存在することがあります。通常、スケジューラーは工程・製造管理側の仕組みですが、スケジューラーがMRP機能を持っている場合もあり、資産管理上の重要な役割を持つことがあります。MRP、小日程計画、MESの連携は複雑で、ケースバイケースで紐解いていかなければなりません。
工程管理・製造管理を支えるシステムは、MES、WMS、LIMS、PLC、IoT端末、設備制御盤、PIMS:Plant Information Management Systemです。こうしたシステム群は連携してこそ意味があります。
製造指示と実績収集を行うMESは、資材管理のWMSと連携し、出庫指示や入出庫実績を把握します。MESは計量機器やPLCと結びつき、実績収集を行います。MESもWMSも上位システムとしてのERPと連携します。LIMS: Laboratory Information Management Systemは検査にもとづく品質情報を集めます。PLCはMESからの製造指示を設備の制御盤に連携する場合もありますし、ハンディターミナルがMESと作業指示、実績収集の連携を実現する場合もあります。
PLCはマザーとなるPLCと子となるPLCで階層化する場合もあります。PLCは設備制御盤やIoT端末と連携し、情報収集を行い、上位のMESにつなぎます。設備稼働状況などの設備情報は設備制御盤やIoT端末からPLCを経由してPIMSという一種の設備・稼働情報の統合データベースに渡されます。PIMS上での分析、あるいはBIへの連動によりBI側で工程状況の可視化を行います。


●PLM/PDM、BOMとコード統合とマスター統合システムの必要性

生産に関わるシステムとして代表的に登場するSCM、ERP(MRP)、BI 、MES、WMS、LIMS、PLC、IoT端末、PIMS以外にも、重要なサブシステム群があります。PLM:Product Lifecycle ManagementやPDM:Product Data Managementと呼ばれる品目情報や構成情報を扱うシステムは、ERPで使うBOMの源流になります。
工場が異なると、品目コードやサプライヤーコードが異なることがあり、全社を統合したシステム統合やデータ分析を阻害することがあります。コードを統合・統一したうえで、工場や拠点を跨いでマスターを一元的に管理するマスター統合システムが必要です。
残念なことに、積み上げ型でご都合主義的に業務やシステムを作ってきた日本企業にとって、コード統合は大きな制約になっています。データを標準化して、統合管理して分析してこなかったからです。つまり、マネジメントが最後にまとまった会計数字しか見ず、その先行指標となる実績を組織横断で継続的に見ることを怠って、問題が起きた時にもぐらたたき的に対処してきたつけでもあります。現場改善に依存したマネジメントと呼べない工程管理、作業管理しかしてこなかったつけです。
製造業として、生産をマネージし、工場を横断してマネージするためには、PLM/PDMとコード統合、マスター統合は必須なのです。


●ショップフロアの標準化とIndustory4.0の狙い

工場のシステムインフラも工場毎にご都合主義的に作られてきました。同じ企業なのに工場が違えば工場のネットワークインフラが違い、導入されているPLCも違い、通信プロトコルも違うといった有様です。
しかも、ほとんどのケースで本社のIT部門は工場のIT投資を統制していないため、標準化の動きはおきていません。工場も、工場ショップフロアのITを設備予算として扱い、ITは設備の付属機器のような扱いです。IoTなどと騒いでいますが、システムがまちまちで、つながるはずもないとこころにセンサーを入れようとするので、また人力で紙に書きとって表計算に入れて、などといったお寒い状況が頻出しています。
ドイツでIndustory4.0が喧伝されるのは、こうした工場の通信インフラ・ITインフラを標準化して、そのデファクトスタンダードを握ろうとしているからです。ERPで基幹システムアプリケーションでのデファクト化を果たしたドイツとしては、次は標準化しやすい対象として、工場の製造フロア・ショップフロアITのデファクトスタンダードを握ろうとしているわけです。
こうした認識なしに、「モノづくりだ」などという従来の古いフレームワークや、オペレーションレベルの視点でのIoTなどにヒト・モノ・カネを投じていては、立ち遅れていってしまいます。製造をマネジメントするために必要なインフラのひとつがショップフロアの標準化です。意思を持って、どの工場に行っても同じITインフラで製造設備が繋がり、データがスムーズに連携できる仕組みを急いで構築しなければなりません。


●工場ITを担うシステム統合管理機能の設置の必要性


生産マネジメントと工程管理・製造管理を統合して業務設計し、フレームワークを持ってシステム選定・設計・開発をしていかなければならないことは再三書いてきましたが、ここであらためて追加して、ショップフロアのIT標準化の話を加えました。工場のショップフロアのIT標準化なくしては、ムダな多重投資になり、IoTの実現の制約になってしまいます。
一方、設備投資の延長でIT投資を決めてきた工場のITを担うシステム統合管理機能の設置が必要になります。これだけITが進展しているのに、いまだにITの重要性を意識した動きができていません。工場をインテリジェント化し、可視化し、利益を生み出す実体としてマネージしていくのに、ITなくしては十分にできません。人力生産管理ではなく、ITを活用した自動化に舵を切らなければ、貴重な人というリソースがシステムの入力設備やデータ連携マシンのようになってしまいます。
製造業のIT部門は、工場のITを標準化し、統合し、投資や導入を管理、監督する機能を持つことが必要なのです。これから工場ITを担うシステム統合管理機能の設置は必須になります。


●ビジネスモデルの違い、パイプライン管理や統計予測との連動、AI・ビッグデータ


最後の方で補足的に書きますが、ビジネスモデルの違いによる工場側システムとビジネスモデルに適応したシステムの業務・連携も必須になります。B2Bでは、商談管理としてSFA:Sales Force Automationが導入され、商談のステージを管理するパイプライン管理と連動した購買や生産との連動が必須になります。B2Cでは、需要予測を生産計画やSCMに連動します。その際、統計予測を使うのか、人的予測を使うのか、顧客の内示やカンバンを使うのか、といった連携を考えなければなりません。
また、収取した実績データをAIやビッグデータで活用するシーンもまもなく来るでしょう。残念ながら、今のところ言葉先行で実態がついてきません。今後きちんと目的やモデル、設計ができるようになれば、AIやビッグデータも使える場面も来るかもしれません。今のところ、AIやビッグデータは目的もないまま、なにができるのかといった幼稚な疑問から始まっていますが、AIやビッグデータに限らず、目的を明確にして必要な要件を定義するといった、王道のシステム導入の流れに乗せないと、また過去と同じようなツール先行の失敗になるでしょう。


●手順を追った生産マネジメントシステムの導入方法


結局、システム導入は王道の進め方をしなければならないのです。AIやビッグデータに限らず、生産管理システムも工場のショップフロアのITインフラも、手順を追った導入をしなければなりません。
その手順は単純です。目的・目標の定義、あるべき姿の特定、あるべき業務の設計をした後に、システム機能の抽出と複数アプリケーションへの業務機能配置とシステムアーキテクチャの検討、パッケージの選定を通じて、普通の要件定義、設計、開発、テスト、定着化へと流していきます。同時に、不足している業務機能を設置していきます。(蛇足になりますが、驚くなかれ、一部の製造業では生産管理を統括する部門がないことがあるのです)
こうした王道のステップを踏まず、おかしな導入方法論に踊らされている企業も多いのですが、まずは、王道を押さえたうえでの、導入アプローチのバリエーション(たとえば、アジャイル開発とかPOC(:Proof of Concept=開発すべき概念の試験的証明))の正否と採用可否を検討しなければなりません。
また、自社内のプロジェクトリーダーとメンバーはエースを選ばなければなりません。外部コンサルやITベンダーもよくよく"人"を見極めなければなりません。同時に、採用するアプリケーションシステムも、適合性、コスト、クセ、アプリベンダーの制約や利害もきちんと把握して選ばなければなりません。

売れているからとか、他社はやっているとか、今はこれです、といったセールストークでシステム導入やアプリケーション選定を決めてはいけません。地味に、王道の進め方で、業務改革、業務構築、システム構築をした方が、結果的に先に目的地に着くのです。
流行に飛びつき、名前が売れているからと実態が怪しいコンサルやシステム、ITベンダーに依存し、多額の金額を取られて失敗した例は累々と転がっています。システム導入は簡単ではありません。仕事は複雑化し、全体を理解する人もいなくなりました。これからはよくよく注意して、優秀な"人"をつかまえたら離さず、内外のエースでチームを組んでシステム導入をしていかなければならない、という難しい時代になってきたのです。

第十一回 原価管理と一体化した生産マネジメントの構築 はこちら

【ライタープロフィール】

石川 和幸

経営コンサルタント

早稲田大学政治経済学部政治学科卒、筑波大学大学院経営学修士。能率協会コンサルティング、アンダーセン・コンサルティング(現、アクセンチュア)、日本総合研究所などを経て、サステナビリティ・コンサルティングを設立。専門は、ビジネスモデル構想、SCM構築・導入、ERP構築・導入、アウトソーシング導入、管理指標導入、プロジェクトマネジメントなど。 著書に『図解 SCMのすべてがわかる本』『図解 生産管理のすべてがわかる本』『在庫マネジメントの基本』(以上、日本実業出版社)、『思考のボトルネックを解除しよう!』、『見える化仕事術』(ディスカヴァー・トゥエンティワン)、『なぜ日本の製造業はもうからないのか』(東洋経済新報社)、『エンジニアが学ぶ物流システムの「知識」と「技術」』(翔泳社)、『アウトソーシングの正しい導入マニュアル』『図解 工場のしくみが面白いほどわかる本』(中経出版)など多数。

お気軽にご相談ください