カテゴリ:サプライチェーン( 143 )

講演のお知らせ:「生産スケジューリングの基礎とリードタイム短縮のポイント」(6月27日)

お知らせです。6月に、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います(有料)。
わたしは長年、エンジニアリング会社で国内外の工場・プラント作りに関わってきました。また、それなりに数多くの工場も見てきましたが、疑問を感じるケースが少なくありませんでした。「なぜ、こんな所に在庫を持つのだろう?」「どうしていらないモノはたくさんあるのに、必要なモノは欠品しがちなのか?」「ここを工夫すれば、もっと効率よく、かつ楽に仕事ができるはずなのに」
そうした非効率が生じるのは、生産活動の仕組み=『生産システム』の基本デザインに問題があるからです。つまり、生産活動のシステム・エンジニアリングが欠けているのです。むろん、ここで言うシステムとは、コンピュータのことではありません。情報系も一要素ですが、むしろ働く人々と、機械設備と、物流と、それを包む建築空間のことをいっています。こうした基本的なことを抜きにして、ただ最近の流行である「スマート技術」を追いかけても、部分的な改善効果しか生まないのがつねです。
また生産システムは、自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば、役に立たないのです。
拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視しています。そのため、生産システムをより良く運用するにはどうしたらいいか、より上手に設計するためには何に留意したらいいを考える『システムズ・アプローチ』をとります。したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。年1回行っているこの講演も6回目になりますが、今年はさらにバージョンアップしてお届けするつもりです。

普通の現場改善コンサルタントや、ITベンダー系コンサルタント達の提言に、飽き足りない気持ちでおられる技術者の皆さんの、ヒントになればと思っています。

===================================
「生産スケジューリングの基礎とリードタイム短縮のポイント 〜演習付〜」(3月24日)

日時: 6月27日(水) 10:30~17:30
主催: 株式会社日本テクノセンター
会場: 株式会社日本テクノセンター研修室
     東京都新宿区西新宿2-7-1 小田急第一生命ビル22F
     (都営地下鉄大江戸線「都庁前」駅または丸ノ内線「西新宿」駅)

生産計画とスケジューリング、リードタイム短縮について、事例と演習を含めてお話しします。

セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)

===================================
関心のある大勢の方のご来聴をお待ちしております。

佐藤知一


by Tomoichi_Sato | 2018-04-15 23:56 | サプライチェーン | Comments(0)

「インテグレーター不在」という深い谷間

先日、ある技術系コンサルタントの方が来訪したので、最近の話題を聞いた。AI技術がこのところ注目を集めており、工場の製造現場でも、様々な取り組みを始めている。ただ、汎用的なAIのエンジンを、自分たちの仕事の用途に合わせて、テーラーメイドで開発するには、それなりの力量が要る。

そこで最近は、FA用途に向けた「アプリケーション特化型」のAIソフトが出てきた、という。特定の目的、例えば機械の振動のデータを蓄積分析して、異常の予兆を診断するといった、目的特化型のAIソフトが出てきているらしい。これが次のトレンドかな。なるほど、なかなか面白い。

ただ、ひとつ心配な点がありますね、とわたしは指摘した。そうしたアプリケーション特化型のAIソフトを売るベンダーと、工場でそれを使用したユーザとの間に、1つ問題となるギャップがある。それは、AIのソフトウェアパッケージと、工場側の具体的な制御システムないしMESとの、インテグレーションの仕事である。

その仕事を、自分たちだけでできるユーザが、果たして日本の工場でどれだけいるだろうか? かといって、2つのシステムを統合する難しい仕事を引き受けてくれる業者、すなわち製造現場に強いシステム・インテグレーターがいるかというと、世の中には決して多くない、という事情がある。

つまり、AIベンダーと製造現場のユーザーとの間に、「インテグレーター不在」という深い谷間があるのだ。

いや、話はAIのソフトウェアに限らない。MESのソフトを導入するにせよ、あるいはデジタル屋台のシステムを買ってきて、社内の3D-CADとつなげるにせよ、同様の困難がある。いや、それどころではない。例えば産業用ロボットを買ってきたり、あるいは気の利いた搬送システムや立体自動倉庫を買ってきて、自動化・省力化を図る場合だって、自社の製造ラインとのインテグレーションが必要になるのだ。こうした仕事はしばしば、生産技術を受け持つ機械エンジニアだけの手には余る。

もちろん、高価な機械を何台も買ってやるから、ついでにインテグレーション業務もしてくれ、と機械メーカーに要求することは可能だ。実際、有力な機械設備メーカーの中には、自社製品を買ってくれることを条件に、請け負ってくれる企業もある。ただ、そうした「つなぎ」の仕事は、しばしば、子会社や下請けにやらせたりするらしい。

逆に、いや、それはお客さんの仕事です、と突き放すメーカーもある。請ける・請けない、いずれの場合も、機械メーカーやパッケージソフト・ベンダーが、製造現場におけるインテグレーションの仕事自体を好んでいない点では、同じだ。

なぜか。儲からないからである。

『インテグレーション』とは何か。それは、それぞれ単独で完結した機能を持つ要素群を、上手に連結して、一体として働くようにすることである。

例えばパソコンのソフトに例えるならば、ワープロと表計算とのあいだで、クリップボードを経由したコピー&ペーストを可能にすることも、インテグレーションの一例だ。今日では、まるっきり当たり前のように思えるこの機能も、'90年代前半までMS-DOSやCPMといった旧世代のPC用OSを使っていたユーザにとっては、とても新鮮なものだった。当時の感覚では、Lotus 1-2-3で表を作成して、WordPerfectの文章の中に貼るなど、想像しにくい使い方だったのだ。

だからMacOSやウィンドウズが登場して、OSレベルでカット&ペーストをサポートし、複数のアプリケーション間でデータのやり取りを統合的に行えるようにした事は、ほとんど革命的な進歩だった。これがインテグレーションの価値なのだ。

あるいは、鉄道の世界でたとえるなら、インテグレーションとは「相互乗り入れ」がそれに該当する。私の勤務先は横浜の「みなとみらい」地区だが、実家は今は埼玉県所沢市にある。以前は、職場から実家まで帰るためには、渋谷と池袋で2回、乗り換えなければならなかった。そのたびごとに階段を上り下りし、行列に並んで席に座らなければいけない。

だから、西武池袋線と副都心線と東横線・みなとみらい線が相互乗り入れを開始し、みなとみらい駅のホームに小手指行き列車が到着した瞬間は、頭がクラクラするほどの衝撃があった。実際、乗り換えの不便が減ったし、所要時間も圧倒的に短くなった。これも、インテグレーションがユーザにもたらす価値だ。

周知の通り、システムにおける要素間のインタフェースには、密結合疎結合の2種類がある。製造現場の例で言えば、一貫生産ラインは密結合であり、工程間に在庫のスペースがあるのは、疎結合である。コンピュータなら、「ファイル渡し」は疎結合であり、APIの呼び出しなどは密結合だ。

高度なインテグレーションとは、サブシステム間を密結合・強連結にすることである。すなわち、一つの指示(インプット)で、複数の要素が連携協調して動作するようにすること。あるいは、モノやデータの受け渡しのある要素間では、処理量とタイミングを同期化することだ。

また、部分に異常が生じたら、全体が安全にスローダウンする、ないし、共通したアラームを発信するといった対応もいる。さらには、必要に応じて、個別要素を部分的に立ち上げたり、全体を止めずに切り離したりできる機能も必要だ。

したがって、構成要素数が多く、かつ高度にインテグレーションされたシステムには、主要な全要素をモニタリングする「情報のハブ」が、必然的に生まれてくる。そこが、全体のタイミングをとり、要素に適切な指示を出す。まあ、オーケストラの指揮者のようなものである。

e0058447_18223374.jpg
こうした「インテグラルなシステム」を作る仕事のプロが、インテグレーターである。

つまり、インテグレーターの仕事とは、システム構築=仕組みづくりである。だが、「システム」という、目に見えないものが理解できない人たちには、そもそもその価値が分からない。この人達には、目に見えやすいもの、たとえばロボットだとか、立体自動倉庫だとかAIソフトパッケージだとかいったものが、価値の中核に見える。インテグレーション作業はオマケだ、という訳である。

高価な機械を買ってくれる代償として、周辺のインテグレーション作業を請け負うメーカーは、ある意味、そうした理解ないし誤解を助長しているとも言える。もちろん、エンドユーザーを助けるという積極的な面もあるわけだが。

インテグレーションの仕事は、ユーザの個別性の高い要求(制約条件)に合致するよう、複数の要素を選んで組み合わせる能力を必要とする。つまり、「すり合わせ」型の業務である。工場のように、既存の機械や仕組みと組み合わせる場合、相手の状況に応じて作業量が変わるし、つながらないリスクもある。だから、本来は固定金額の見積にはなじまない仕事だ。

それなのに、たいていの顧客は、インテグレーション・サービスに要した人工(工数)分の費用しか、インテグレーターに払ってくれない。曖昧でリスクが大きいのに、である。だから、インテグレーションは儲からない商売だ、という事情が生まれる。

だったら、単体売りに徹する方が、商売として「堅い」「手切れが良い」ということになる。かくて、ウチは単体設備メーカーです、というスタンスを持った企業が栄えることになる。いいかえると、優秀な部品メーカーは多いが、全体システムの売り手はあまりいない、ということで、どこかの業界によく似た構図ができている。

工場系の生産システム・インテグレーターは、機械メーカーの下請けに位置せざるを得ない。だから、中小零細企業が多い、という話を良く聞く。そうなると、人材の確保や育成も課題だ。

それでも、信頼できるインテグレーターを、身近に抱えている企業なら、まだ良い。多くの場合は、ユーザが自分でインテグレーションするしかない。そこで、機械設備やIT系における、モノの受け渡しやデータ通信インタフェースの標準化、せめて共通化が望まれる。

いや、本当は、機械設備メーカーやITベンダーなどは、インテグレーションされることを前提に、自社製品を考える態度が必要なのだろう。だが、かつてIBMのOS/360開発のプロマネで、後に名著『人月の神話』を書いたBrooks Jr.によると、要素をインテグレーション可能な形にするには、単に作るだけに比べて、3倍の費用がかかる、という。

これはソフトウェアの場合の話で、機械設備の場合は、もう少し小さな数字になるだろうが、余計なコストがかかるのは事実だ。コストがかかれば、製品の価格に跳ね返る。価格競争にさらされるメーカーにとっては、ありがたくない話だろう。

では、どうしたら良いのか。要素技術のプロバイダーと、ユーザの間には、「インテグレーター不在」という深い谷間がある。ここうまくつながないと、ユーザが困るだけでなく、優れた技術を持つAIベンダー・機械メーカー等のベンチャー企業も、日本では育たないことになる。

もちろん、エンドユーザーである日本の製造業の、経営管理職の人たちが、インテグレーションの価値を認めて、それにきちんとお金を払うようになることが、理想型である。しかしそれは、百年河清を待つ、の類だろう。

わたしは、こうしたFA系のインテグレーターたちが、下請けや系列の地位から脱するためにも、せめて一個の独立した業界として認められ、その価値を世間に対してアピールしていくような方策が必要だろうと思う。そのためには、業界団体の結成も、ひとつの手段だろう。聞くところによれば、近々、経産省の旗振りで、「ロボット・インテグレーション協会」が設立されることになる見通しだと言う。これは良いニュースだ。

しかし「深い谷間」の問題は、ロボットという(先進的な見かけの)部分だけでは留まらないはずである。より広く、産業システムのエンジニアリング、ないし生産システム・インテグレーションの担い手が、求められているのだ。以前、政府の「ものづくり白書」には、『ラインビルダー』という言葉も紹介されていた。こうした業界の確立を助けるために、国の支援策も必要だろうし、標準的な契約や仕様のあり方も、議論される必要がある。

ドイツのIndustry 4.0の向こうをはって、日本は「ソサエティー 5.0」を目指すのだそうだ。"Connected Industries"というスローガンも、よく見かける。それが具体的に何を意味しているのか、わたしにはまだよくわからない。だが、少なくとも、インテグレーター不在と言う深い谷間を、埋めるための努力が必要だという事だけは、明らかだろう。



by Tomoichi_Sato | 2018-04-01 18:45 | サプライチェーン | Comments(0)

POPとは何か、MESとはどこが違うのか

工場見学が趣味である。いや、趣味というのは言い過ぎかも知れないが、とても好きなことは確かだ。昨年から思うところあって、いわゆる組立加工系の工場について、機会があれば業種を問わず見学して歩いている。国内外あわせてすでに1ダースを越えたから、平均すると一月に1ヶ所は訪問している勘定だ。むろん、工場の改善指導をしているプロのコンサルタント諸氏には及びもつかないが、まあそれなりに見ている方ではないか。

工場見学に行ったら、何を見るべきかについては、すでに記事も書いた(「超入門:上手な工場見学の見方・歩き方https://brevis.exblog.jp/21898734/ 2014-04-16)。とくに製造現場を歩いているときは、できるかぎり、現品票を見ることにしている。

現品票とは何か。それは、工場の中を行き来している部品・材料などの現品に添付されて回っている紙の帳票のことである。なお、機械加工系では、加工対象の物品のことを「ワーク」Workとも呼ぶ。英語のworkは仕事・作業の意味が強いが、仕掛品のことをWork in Process(略称WIP)と呼んだりもする。そこで以後、この記事の中では、現品とか物品という代わりに、ワークということにする。現品票とは、工場内でワークに添付されている紙の帳票のことである。

ワークはそれぞれが個別だから、現品票もそれに1対1でついている必要がある。ただしワークが小さな部品である場合や、ロット単位でずっと流れていく場合は、複数個のワークに1現品票のこともある。ただ、その際は、複数個のワークが、通い箱や台車などに入っていて、物理的にワンセットで動かなければならない。そうしないと、ワークと現品票の対応関係が崩れてしまうからだ。

現品票とは、ワークについて「これは何か」を示す名札のようなものだ。小学校の新入生につける名札と思えばいい。高井戸小学校・1年4組・佐藤知一、という風に(たしか1年のときは4組だったと思う・・違っているかも知れないが)。現品票には、少なくともそのワークの品目コード・品名が表示される。

そして、通常は、そのワークが使用される『製造オーダー』の番号と付帯情報も示される。もっとも、日本では生産関係の用語に統一がないため、企業によっては製造オーダーではなく「製番」「製造指図番号」と呼んだりする。付帯情報とは、製造作業の納期、必要数量、製作図面の番号、どの最終製品に使われるか、どの工程(作業区)で使用されるか、等々だ。ちなみに、トヨタ生産方式で使われる「かんばん」も現品票の一種である。

工場内には多種多様なワークが流れている。それに対して、一対一で現品票を発行し添付するのは、手間とコストがかかる。ただ、それをやらないと、目の前のモノが何なのか、本来どこに置くべきか、いつまでに使用されるのか、等々が、「良く知っている担当者」以外の人には分からなくなってしまう。だから、すべてのワークに現品票がついているかを見ると、その工場のマネジメント・レベルがすぐ判断できる。

そして、現品票にバーコードがついているかどうかも、大事なポイントだ。

現品票には、人間に必要な情報は印字してある。では、バーコードは何に使うのか? 答えは、POPに使うのだ。

POPとはPoint of Production、すなわち「生産時点情報管理」の略称だ。ふつうは、それを支えるITシステムのことを指す。流通業界、たとえばコンビニでは、お客が買い物をすると、レジで商品のバーコードをスキャンして、品目・数量を確認し、金額を計算する。この時点で、購入情報はレジを通して吸い上げられる。この仕組みをPOS(Point of Sales)=「販売時点情報管理」という。そしてバーコードリーダと通信機能のついているレジを、「POSレジ」と呼ぶ。

POSシステムが表れる前は、商店は、一日が終わって棚の残量をチェックするまで、販売数量を知る方法がなかった。その時点で翌日の仕入れ数量を決めるのでは、遅すぎる。だからPOSという概念が現れた。

同じように、従来多くの工場では、一日が終わって作業者が「製造日報」を記入するまでは、何がどれだけできたのか、把握する方法がなかった。これでは、短納期化した注文に追いつくことが難しい。そこで、流通業界を真似る形で、POPシステムを導入する工場が現れるようになったのだ。

POPシステムでは、現場の作業者が新しいワークに対する作業に着手するとき、現品票のバーコードをスキャンする。また、作業が完了したときも同様に、スキャンする。これによって、作業区単位(ないし機械単位)に、どのワークを、いつ着手/完了したかを、システムがリアルタイムに把握する。

POPの目的は、大きく三つある。一つめは、個別オーダーの進捗把握である。受注生産では通常、個別の注文(オーダー)ごとに、納期と数量が決まっている。生産管理担当者は、製品単位の「生産オーダー」を、部品展開(工程展開)して、各部品ごとの「製造オーダー」に展開する。この時点で、各工程ごとの数量と期限が決まる。そして、これを製造現場に指図として送る(これを「差し立て」ないし「ディスパッチング」とよぶ)。と同時に、それぞれの部品に対して「現品票」を発行し、現品に添付させるのである。

したがってPOPシステムを利用して、予定した製造作業の期限に対し、きちんと完了の信号があがってきているかをチェックすれば、進捗状況が把握でき、遅れがある場合は検知できる。現品がどの作業区にあるかについて、ラフな所在管理もできる。

二番目の目的は、作業時間の計測である。着手・完了時刻を取得している訳だから、作業時間を計算するのはたやすいし、従来の日報に比べて、正確だ。作業時間が分かると、賃率をかけることで、個別オーダーのコストの集計・管理ができるようになる。すると、オーダー単位の利益が計算できるし、また次の見積にも基礎データとして役に立つ。

三番目の目的は、生産性の把握だ。こちらも作業時間の計測が基礎になるが、さらに機械単位ないし作業者単位に、どれだけの生産数量ができたかを集計し、生産性を比べることができる。もしも標準工数が決まっているのならば、作業区別の負荷と余力も推算することができる、という訳だ。

POPシステムの概念は決して新しいものではない。図は、わたしが1992年に、中小企業診断士の受験参考書のために描いた、手書きの図(笑)である。日刊工業新聞社「工程管理ハンドブック」を参考に作図した。今から26年も前の話なので、「ホスト・コンピュータ」などと書いてある。今ならPCサーバとかエッジサーバと書くところだろう。
e0058447_13494289.jpg

ちなみに、POPに隣接する概念として、SOPおよびデジタル屋台の支援システムがある。SOP(Standard Operating Procedure=標準作業指示書)とは、適正な作業を行い品質を保つ目的で定める、作業の詳細な手順指示である。これは医薬品製造や食品製造などの分野で広く用いられる。これを電子化し、現場の作業者に端末経由で示し、それにしたがって確認記録を入力することで、製造作業をガイダンスする仕組みを、この分野ではよく用いている。とくに医薬品はGMP(Good Manufacturing Practice)の法的要請があり、適正な作業記録が義務づけられるからだ。

デジタル屋台とは、組立工程における一種のセル生産の仕組みである。ちょうど屋台のように、作業台を一人1台ずつ与え、台の周囲に部品供給用の引き出しやラックを置く。そして、作業台にはモニターを設置して、作業者に対して組立作業をワンステップずつ、3D的に図解して示すのである。とくに組立の部品点数が非常に多いケースや、個別受注で組立手順が毎回少しずつ違うケースに有効である。

さらに、作業者が部品棚から正しい部品を正しい個数取り出したか、とか、適正なトルクでネジを締めたか、といった点までセンサーでモニタリングすることも行われる。現在、静岡大学客員教授の関伸一氏が、2000年代にローランドディージー社で見事なデジタル屋台システムを作り上げ、広く知られるようになった。この事例では、作業者一人ひとりの生産性を測定し、自分の能力アップを実感できる仕組みにして、作業者のモチベーション向上に大いに貢献したという。

SOPもデジタル屋台も、必ずしも現品票とバーコードを活用するとは限らないが、作業時間を計測しているので、いろいろと付加的な機能を持てる点で共通している。

このようにメリットの大きいシステムであるにもかかわらず、日本の全ての工場に常識的に普及しているかというと、決してそうでもない(だから毎回、工場見学のたびに現品票とバーコードをチェックしているのである)。技術的には、25年前から存在し、ある意味、もう枯れた技術である。なのに、なぜ普及しないのかについては、ここではあまり深入りしないが、大きく3つの要因がある。一つめが、こうした製造現場のIT化投資に関する経営側の無理解、二つめが現場作業者のもの言わぬ抵抗、三つめは生産管理(とくに生産計画)担当部門の力量不足である。(さらに4番目をつけ加えるなら、現場に強いITエンジニア不足もあるが)

ところで、この1〜2年ほど、少し潮目が変わったかな、という感じを受けている。IoT技術の進展と、スマート化・AIブームなどの影響で、再び製造現場のIT化の遅れが問題視されるようになった。今回は特に、深刻な人手不足問題が追い打ちをかけている。自動化を進めないと、受注をさばききれない、という状況があちこちに生じたのだ。その結果、たとえばわたし自身も、MES(Manufacturing Execution System=製造実行システム)に関する問合せを受けるようになってきた。MESの話題なんて、この15年間、特定業界以外の人はほとんど誰も口にしなかったのに。

MESが何かについては、別に解説記事も書いた(「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ 2017-08-19)ので、ここでは繰り返さない。ただ、POPとMESの関係だけは整理しておこう。簡単に言うと、POPとはMESの第一歩である。

そもそも、組立加工系の工場におけるMESの機能要素は、7種類くらいに分けることができる(世間的にはMESA Internationalの「11機能」を列挙するのが通例だが、あれはプロセス系も混ざり込んで分かりにくいので、自分流に整理し直した)

(1) 詳細な工程(作業)展開と指示発行(SOP含む)
(2) 機械設備の高度な連携制御(DNC含む)
(3) 製造プロセスのモニタリング
 →これは、機械・人の状態監視と、ワークの所在・数量・移動の把握に、さらに区分できる
(4) 製造オーダーのトラッキング
 →これも、進捗と完了予測、そしてトレーサビリティ機能に区分できる
(5) 品質と製造パフォーマンスの計測
 →すなわち、品質・リードタイム・生産性の計測と分析である
(6) 製造資源の維持・保守
(7) 製造技術情報(製作図面・BOMを含む)の共有・検索

逆に、MESでは通常、対象外となる機能もある。すなわち、
(8) 通常の制御系機能
(9) 調達・コスト管理機能

POPは、上の機能リストで言うと、(1)と(3)を部分的にカバーしている。つまり、MESのサブセットという訳だ。もちろん、別に上の機能全てをカバーしなければ、MESと呼んではいけない、というつもりはないし、工場によって必要な機能のセットは異なるだろう。そこはもちろん、IT化の手間と効果、そしてコストの見合いで決めるべき事柄だ。一般に、対象業務の規模が大きくなり、コントロールすべき物事の数が増えたら、IT化の効果が出やすい。

さらにいうなら、市販の生産管理システム・パッケージや、ERPパッケージにも、ある程度POP的な機能が実装されている場合が多い。現代では、選択肢はいろいろあるのだ。ただ、生産管理やERPが、どちらかというとコスト管理目的に傾斜しがちであるのに対し、単体のPOPやMESは、製造プロセスの円滑なマネジメントが主目的であるという違いはある。それに応じて、現場に要求される作業も微妙に変わってくるだろう。

わたしの個人的な意見としては、最初から製造現場に細かなコスト管理の仕組みを持ち込むよりも、まずは製造が遅滞や不良なく円滑に進むことを、優先すべきではないかと思っている。ここは異論のあるところかもしれないが、もしも納期遅延や生産性に悩んでいるのなら、単体のPOP構築からはじめてみるのが、賢い選択ではないだろうか。

<関連エントリ>
 →「超入門:上手な工場見学の見方・歩き方https://brevis.exblog.jp/21898734/ (2014-04-16)
 →「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 https://brevis.exblog.jp/25991822/ (2017-08-19)

by Tomoichi_Sato | 2018-03-21 14:56 | サプライチェーン | Comments(1)

お知らせ:納期遵守のための1日セミナーを開催します(11月18日・大阪)

来る11月18日(土)に、大阪府工業協会で納期遵守をテーマとした1日セミナー(有償)を行います。主に受注生産型の工場における、納期遵守のための生産計画と統制(コントロール)について、製造業の実務家向けに、理論・事例と演習を含めてお話しします。3年前からはじめた本シリーズも、今回で5回目の開催になります。

人手不足が深刻化している昨今、多くの企業が納期問題に直面しています。しかし、だからといって生産性の向上はそう簡単ではないし、高価な最新鋭機械を導入すれば解決する問題でもありません。生産リードタイムは、生産システム全体のパフォーマンスで決まるからです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門 (図解でわかる生産の実務)」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視します。そのため、生産活動の仕組み全般を『システム』としてとらえ、その生産システムをより良く運用するにはどうしたらいいか、また仕組みをより上手に設計するためには何に留意したらいいか、を考える『システムズ・アプローチ』をとります(もちろん、ここでいうシステムとはコンピュータのことではありません)。

したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。普通の現場改善コンサルタントの講義に、飽き足りない気持ちでおられる技術者の皆さんのヒントになればと思っています。関心のある方のご来聴をお待ちしております。


<記>

日時: 2017年11月18日(土) 9:30-16:30

テーマ: 「納期遅れを起こさない 生産統制のポイント
     ~ 工程管理担当者の実務能力の強化 ~」

主催: 公益財団法人 大阪府工業協会

会場: 大阪府工業協会研修室
     大阪市中央区本町 2-6-12 サンマリオン NBFタワー4F
     (市営地下鉄御堂筋線「本町」駅9番出口より徒歩4分)

セミナー詳細: 下記のPDFファイルをご参照ください(「受講申込書」も兼ねています)


by Tomoichi_Sato | 2017-10-15 22:15 | サプライチェーン | Comments(0)

IoT時代のMESをもう一度考え直す 〜 (3) MESの未来像とは


最近、ある工場を見学に行った。ここでは仮にX社と呼ぼう。中堅の機械メーカーで、精密な加工技術を要する製品(というか、より大きな機械に組み合わせて使うモジュール的部品)を作っている。顧客の個別仕様要求が多く、生産形態としては受注設計生産に属する。

組立工程の現場のチーフ格の人から、話を聞いた。ここの現場では、一種の「デジタル屋台」というべき方式を採用している。ちょうどラーメンの屋台のように、一人に一台の作業用のラックが与えられ、目の前の端末には組立工程の作業指示が1ステップずつ、3D的図面に表示される。

X社が作っているのは小さな製品で、組立にはネジ止めを多用する。ネジ止め作業では屋台(ラック)に付属する電動ドライバーから、トルクなどの情報を自動的に取って、作業を自動的にチェックし、ミスを防止している。他企業でも見たことがあるが、優れたやり方だ。

ラックのサイドに部品入れの抽斗が並んでいて、部品はそこから手で取り出して、とりつける。取り出すべき抽斗の位置も、自動的に表示される。そこまではいいのだが、使うのは小さなネジなので、どうしても取り出すのにイラついたり、あるいはサイズや本数を間違えて取ってしまうことがある。

そこでこのチーフ格の人は、何か解決策はないものかと考えた。そしてある日、100円ショップから、色付きストローを何本か買ってきた。ストローの先端を、ちょっと丸める。そしてストローの逆側からネジを何本か入れてみた。こうすると、ストローの中でネジが数珠つなぎになり、ストローの先端からは、ネジの先っぽが顔を出す。一本引っ張って取り出せば、次のネジがまた顔を出す。

かくてワンアクションで、確実にネジを1本取ることができるようになった。ネジの種類に応じて、ストローの色をかえれば、取り間違えも防止できる。見事な知恵である。これ以外に他の現場でも、いろいろ創意工夫を聞いて、X社の職場の志気の高さに感心した。

それにしてもX社は、多品種 小ロットの受注設計生産がメインである。このデジタル屋台の作業指示の3D的画面は、誰がどのように作っているのだろうか? 3D-CADで設計しているから、というのは答えの半分でしかない。繰返し性の高い量産工場なら、3Dモデルから、工程設計者が細かく作業展開して、指示データを作っておくことができる。しかし小ロット個別受注で、そんな手間がかけられるのか?

X社の秘密は、設計の標準化と、コンフィギュレータの利用にあった。設計については、徹底した標準化を進め、製品各部分のサイズや材質については、パラメータ化している。また、共通部分と、個別にカスタムで変えるべき部分についても切り分けられているようであった。その上で、見積と受注段階で、コンフィギュレータを使う。コンフィギュレータというのは、製品の顧客要望の仕様を入力すると、適切な部品やパラメータの組み合わせを自動的に検索・計算してくれるソフトウェアのことである。

これによって受注時に、基本的な設計BOM(E-BOM)が自動的に選定されており、また価格も見積もられる仕組みだ。その設計BOMと付帯情報は、3D-CADに組み込まれたロジックにより製造BOM(M-BOM)に自動展開され、さらに別のソフトにより、デジタル屋台の作業指示画面が生成される。

製造現場の作業者に対して、ステップ・バイ・ステップで標準作業の指示を与える機能は、典型的なMESの機能である。医薬品分野のMESでは、「SOP(標準作業指示)」機能と呼ばれる。組立の分野では、紹介したような組立図の画面表示がよく行われる。作業の着手と完了時に、ワークに付随するバーコードやRFIDを読み取って、誰がどの部品をいつ・どれだけの時間をかけて製造したかをモニタリングする「POP(製造時点情報管理)」と並んで、MESの基本機能と言っていい。かなり制御層に近いので、前回記事の言い方を借りれば”Lower MES"ということになるが。

ところで、作業指示をステップ単位で表示するためには、MESが対象製品の製造部品表(M-BOM)と、作業工程表(BOP=Bill of Process)のデータを知っていなければならない。ご存じの通り、部品表(BOM)と作業表(BOP)は、製品設計からスタートする情報の流れ、すなわち製品の『エンジニアリング・チェーン』の中で生成される。つまり、MESという仕組みは、企業のエンジニアリング・チェーンときちんとデータ・レベルで結合されていないと役に立たない、ということになる。

そして製品のエンジニアリング・チェーンというものは、納入先顧客数が増え、製品の品種数が増えるほど手間暇がかかるようになり、部品点数や個別仕様が増えるほど、設計変更の可能性が増える性質を持っている。少品種・大量見込生産の高度成長期に比べ、個別受注設計・小ロット生産が主体の今日は、エンジニアリング・チェーンとMESのスムーズな結合・連携は、はるかに重要かつ難しいといえるだろう。多くの企業では、生産技術部や製造部の技術者達が人手で対応して、つないでいるのが現実だ。

エンジニアリング・チェーンからBOMやBOPデータを受け取ることと並んで、MESにとって大事なのは、生産オーダーの情報を上位系から受け取ることである。どのオーダーは、どの顧客向けで、どんな数量と納期になっているのか。これが分からないと、各工程における優先順位やスケジューリングができないことになる。製造工程のスケジューラは、前回も紹介した通り、MESのもう一つの重要な機能である。こうした納期・顧客・数量のデータは、サプライチェーン関係の仕組みから入ってくる。MESの3層モデルが示すところである。

エンジニアリング・チェーンとサプライチェーン。MESがつながる相手は、これだけで十分だろうか。いや、まだある。

IoT技術が進展しつつある今日、MESの普及を阻害してきた現場の機械・制御系とのやりとりが可能になり、稼働監視や複数機械の連携制御、そして予防保全などが新たな期待となっている。それはつまり、MESが設備情報のマスタ・リストを持たねばならないことを意味する。工場の機械設備等のBOM構成・能力やプロファイルなどのマスタデータはどこから来るか。それは、設備に関するもう一つのエンジニアリング・チェーンからくる。多くの企業では、生産技術部門や保全部門などが主導し、工務部門や調達部門もかかわる業務の流れである。

他には? MESが現場作業者に指示を出し、制御系やPOPなどから工程実績をとれるようになると、次には工程別や個人別の生産性に目がいくと思う。「デジタル屋台」などはそれに非常に適した仕組みである。作業ステップごとに、組立作業時間の実績が分かる。こうなると、自分の目標値や自己ベストや職場のチャンピオンの時間との比較も可能になる。こうした生産性比較は、上手に使えば個人のモチベーションアップにつながる(もちろん、下手な使い方をすれば、単に全員を「競争馬の疲弊」に追い込むことにもなり得るが)。

ともあれ、こうなるとMESは人事や労務管理プロセスから、作業者のマスタ・データを受け取り、あるいは能力・実績を送り返す必要が出てくる。

まだある。製造現場には、顧客サイドからのフィードバックが入ってくることがある。主に品質に関する情報だ。顧客サービス部門が起点で、製造部門にまず入り、そこから設計をさかのぼって製品企画部門に至る、製品改善のチェーンである。5月にフィンランドで開催されたMPD 2017で、たまたまご一緒したIVIのエバンジェリストである富士通の高鹿初子さんは、これを「顧客サービスから製品企画に持ち帰るフィールド・プロセス」と呼ばれていた。よい言葉だと思うから、借りることにしよう。

MESには、フィールド・プロセスから来る品質に関するクレームや提案を、製品ロットやシリアル番号とともにインプットする機能も必要だ。

結局、それはMESが情報のハブになる、ということだ。これが、IoT技術の進展と共に、MESに起きる一つめの変化なのだ。従来のMES機能モデルでは、本社の上位系から計画情報を受け取り、実績情報を返す、と書いてきた。前々回で、わたしは「8の字モデル」をご紹介したが、そのバリエーションだ。ISA-95はもっと複雑だが、資材・スケジューリング・在庫といったSCM系情報が中心で、品質・保全系がサブに見える。だが今後は、MESは製造業における情報のハブとしての機能を、強化する必要があるだろう。もっと分かりやすくいえば、外部とのインタフェースがもっと増えるだろう。同時に、マスタデータの同期をどう図るかという、運用設計上いささか面倒な点も考慮しなければなるまい。
e0058447_23262108.jpg
もちろん、こうした機能の全てを皆がいつも必要とする訳ではない。また、MESパッケージがこれら機能全てを備えるべきだとも思わない。製造現場のニーズは多様であり、個別目的にフィットしたパッケージやモジュールを選んで組み合わせて使う、という風になっていくのではないか。それはプロセス産業で一足先に実現している姿だ。

さて、冒頭のX社の事例を見学しながら、わたしは10年近く前にかかわった別の企業のことを思い出していた。そこをY社と呼ぼう。Y社も個別性の高い多品種少量・受注生産形態の、機械のメーカーだった。受注の半分以上が、設計工程のある受注設計生産だったと思う。

Y社を思い出したのは、そこもやはり受注に当たってコンフィギュレータを活用していたからだ。かなり早い段階から自社開発していたと聞く。営業部門は引合いの段階からコンフィギュレータを使って型式選定や見積を行い、受注後は、自動的に標準製作部分と、追加設計の必要な部分に分けてE-BOMが出力される。部品の発注手配も、そこから行われる。設計部門が設計作業をおえてE-BOMを完成登録すると、システムが自動的にM-BOMに展開していく。なかなかすぐれた仕組みだった。

Y社の元々の構想では、M-BOMと図面情報から、工作機械(NCマシン)の加工プログラムまでつなげて、生産性を高めるはずだった。だが、Y社の製品は、部品点数や材料のバリエーションが非常に多く、またサイズも最初のX社の製品よりずっと大きい。結果として、マテリアル・マネジメントがいくつかの理由で混乱して、部品在庫が沢山あるはずなのに、欠品による納期遅れが多発していた。エンジニアリング・チェーンから自動的に製造管理の仕組みにつなげるアドバンテージを、生かし切れていなかった。何より、個別オーダーの納期管理の責任が、いくつかの部門間に分散されていた。

わたしは、社内に「受注コントロールセンター」的な機能を作って、納期管理を徹底させることを提案した。ちょうど空港の管制センターが、入ってくる飛行機に次々に指示を出して、限りある滑走路やゲートを割り当てていくように、個別のオーダーの指示とモニタリングを集中化するのだ。かなりの受注オーダーをさばくY社の業態には、こうした機能が必要に思われたのだ。だがそのためには、情報システム関係にもかなりの改変が必要になる。結局その提案は受け入れられずに終わった。

冒頭のX社は、PCベースの工場スケジューラを導入して、この問題を乗りこえようとしておられた。まだ工場の全工程まではカバーし切れていない様子だったが、その方向性はとても正しい。標準形はあれども個別性の高い要求使用を受けた受注生産を、マス・カスタマイゼーションと呼ぶ。そう。ドイツIndustry 4.0がターゲットにしている生産形態である。マス・カスタマイゼーションでは、製造全体をカバーするような、中央管制システムのような仕組みが必要なのだ。

そして、まさにIoT技術の進展が、それを次第に可能にしてくれている。これまで、現場の手作業やアナログ機械の状態監視ができなかった。また工場内を動く部品やワークの、所在や流れを追いかけることも困難だった。IoTのおかげで、そうした要求は、(コストのハードルはあれども)指呼の間に入ってきたのだ。Lower MESという言葉が出てきたように、MESが制御層と直接やりとりする界面がずっと広がった。今後は、MESと制御システムとのつながりはもっとシームレスになっていくだろう。そして工場全体の流れや動きがリアルタイム的に分かるようになるだろう。

MESの分野に起きる、もう一つの大きな変化とは何か。それは、MESと制御システムがより一体化して、工場全体の「中央管制システム」のような仕組みが生まれることである。従来からプロセス・プラントには中央制御室があり、そこから工場全体を監視し指示を出すことができた。ディスクリート系工場も、いずれ、似たような中央管制システムを持つようになるだろう。これがわたしの二番目の予想である。

もっとも、こうした予想に対しては、「欧米流トップダウン式の中央制御の仕組みは、日本のボトムアップな現場力を損なう」という反論があり得よう。読者はどう思われるだろうか?

でも考えてみてほしい。空港には管制塔がある。では、航空機の世界はトップダウンだろうか。飛行機の機長は、ただ上から言われたことをやるだけのロボットのような存在だろうか? そうではあるまい。たぶん、そういう意見は、中央に情報のハブを持つ仕組みと、軍隊式の命令服従型の組織構造を、なんとなくごっちゃにしている。冒頭のX社は、中央管制システムの実現に相当近い位置にいる。だが、現場の人はものすごく独自な知恵を出して、さらなる改善を続けているではないか。誰かがオーダーの最初から最後までを追いかけていることと、現場の創意工夫とは、まったく矛盾しないのだ。

わたしはむしろ、中央管制システムの実現に対して、もっと別の心配をもっている。それは、誰がこのような制御とITにまたがったシステムの構想を描き、設計をリードし、実装と運用の面倒を見るのだろうか、という問題だ。よほどの大企業だったら、工場にも情報システム部門があるだろう。だが普通の企業では、情シス部門は本社にいて、製造現場の泥臭いことには手を出したがらない。多くの工場では、生産技術や製造部の、「ちょっとパソコンに詳しい若手」が、片手間にその任に当たることになっているのだ。だがこんな大きな仕事、片手間でできるだろうか?

製造現場にIoT技術が広がる現在こそ、わたしは経営層に、こうした生産情報系への関心を持ってほしいと切望する。「ウチの現場力は外国に負けない」と自負されるのは結構だ。だがその現場力は、きちんとモノと情報が交通整理された工場ではじめて十分発揮できるのだ。

昨今、ものづくりの競争力のコアは製品開発にある、製造は単なる力仕事だ、といった通念がメディアで流布しているように思う。冗談言わないでくれ、というのがエンジニアリング会社で働くわたしの率直な実感だ。経営者はもっと製造現場を見て、そこで働く人達の悩みを理解してほしい。せめて聞く耳を持ってほしいと思うのだ。

それを怠ったら何が起きるかって? いうまでもない。ここに書いたこと、これまで3回にわたって縷々説明してきたことは、すべて日本にも外国にも共通した話なのだ。放っておけば、必ずや頭の良い外国人達が、情報のハブとしてのMESと、MESによる中央管制システムの仕組みを、実現していくだろう。それが第4次産業革命のコア技術となるのだ。いや、そればかりか彼らは例によって、勝手に標準規格を作って、押しつけてくるかもしれない。そして日本はまた、その動きを後追いすることになりかねまい。

そういう受け身の状態を、わたしはこれ以上見たくない。だから、こうした予測や議論を共有したくて、記事に書いているのである。まあこんなサイトに書いたからといって、経営層の人が見る気遣いはあるまい。しかし、読者の中には心ある技術者の方がいて、こうした意見を含め上申されるかもしれない。わたしはいろいろと足りない人間だが、言葉を連ねる能力だけは、多少あると思っている。

多くのエンジニアは、寡黙である。寡黙なるが故に、力量があっても理解されない。せめてわたしは、声なき技術者にかわって、言挙げし続けようと思っている次第である。


<関連エントリ>
 →「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 http://brevis.exblog.jp/25991822/ (2017-08-19)
 →「IoT時代のMESをもう一度考え直す 〜 (2) MESの機能と階層を理解する」 http://brevis.exblog.jp/26007261/ (2017-08-27)
 →「部品表と工程表」 http://brevis.exblog.jp/25634844/ (2017-03-22)

by Tomoichi_Sato | 2017-09-04 23:28 | サプライチェーン | Comments(0)

IoT時代のMESをもう一度考え直す 〜 (2) MESの機能と階層を理解する


前回の記事(http://brevis.exblog.jp/25991822/)で、IoT技術の発達はMES(Manufacturing Execution System=製造実行システム)にどのような影響を及ぼすかを考えたい、と書いた。MESの概念が提唱されてから、すでに20年がたつ。その間、限られた一部の業界を除くと、MES自体はあまり大きく広まらなかった。そのボトルネックが、製造現場の機器や人との通信インタフェースにあったことも、前回書いたとおりだ。

そもそも、MESとは何か。どのような機能を持つITシステムなのか。これをきちんとおさえないことには、IoT技術のインパクトも論じられない。MESの持つべき機能については、MESA Internationalが早くから「MESの11機能」を定義していた。「MES入門」の中村実氏の解説を元に列挙すると、次のようになる。(なお、日本語だけだと誤解されかねない部分があるので、元の英語も併記した)

(1) 生産資源の配分と監視 Resource Allocation & Status
 生産資源の監視・管理、資源の配分と予約、資材や設備の監視・管理、などを行う。なおここで生産資源とは、人・機械・治具・金型など、それがないと製造ができないが、材料と違い製造後にも残って他の仕事に使えるものをいう。

(2) 作業のスケジューリング Operations/Detailed Scheduling
 スケジューリングの策定、ロットの発番とリリース、実績の把握に基づくスケジュールの修正。この部分だけを見ると、いわゆる工場スケジューラの機能である。

(3) 差立て・製造指示 Dispatching Production Units
 差立て(ディスパッチ)、製造指示の発行、ロット(現品)管理、現場作業員に対する作業のガイダンスを行う。このうち、製造指示書の発行と差立ては、中堅以上の工場ではどこでもほぼIT化されていると思う。

(4) 仕様・文書管理 Document Control
 仕様・工場モデルの設定・管理(BOM、SOPを含む)、製造記録の管理、ペーパーレス・オペレーションなどを行う。なおSOPとはStandard Operating Procedureの略で、「標準業務手順書」のことである。医薬・食品など品質管理を厳密に求められる分野で重視される。

(5) データ収集 Data Collection Acquisition
 作業報告・POP、データ収集・蓄積などを行う。日本の現場では、作業報告はおおくは日報の形で記録され、翌日上がってくるのが普通だろう。POPとはPoint of Productionの略で、流通業界でPOS(Point of Sales)システムとよばれるものの製造現場版だ。つまり、作業の着手と完了時に、指示書のバーコードをスキャンして、どこの誰が何をいつやったか、リアルタイムに収集する仕組みである。
 他方、「データ収集」(Data Aquisition)と英語で言う場合は、制御系のDCS/PLCなどからタイムスタンプ付きデータを、リアルタイムに自動的に転送してくる仕組みを普通いう。

(6) 作業者管理 Labor Management
 作業者管理・セキュリティ管理などを行う。といっても勤怠管理や現場のゲート・コントロールなどは普通、別に仕組みがあるはずだろう。

(7) 製品品質管理 Quality Management
 統計的品質管理、品質情報の蓄積と管理、品質分析・解析の支援、顧客サービスの向上などを行う。

(8) プロセス管理(工程品質管理) Process Management
 通常のプロセス制御、高度なプロセス制御(工程間制御、フィードフォワード、モデル予測制御など)、例外状況のアラートなどを行う。

(9) 設備の保守・保全管理 Maintenance Management
 保守・保全管理を行う。なお、この部分だけに特化したCMMS(Computerized Maintenance Management System)というパッケージのソフトウェアも存在する。

(10) 製品の追跡と製品体系の管理 Product Tracking & Genealogy

(11) 実績分析 Performance Analysis
 レポート作成、分析作業支援、進捗管理、出荷予測を行う。

・・以上だが、読んでいて、なんだか分かりにくいと思うのはわたしだけだろうか? たとえば、通常のプロセス制御(フィードバック制御など)が、なぜ (8) Process Management機能の一部なのだろうか。これは制御層の仕事ではないのか? また、トレーサビリティ関連の機能が(3)(7)(10)に分散しているように見えるのはなぜだろうか。どうも今ひとつ、自分の頭の中ですわりがわるいのである。

そこで調べてみると、じつはMESの機能モデルはこれだけではないことがわかる。

たとえば、ISA-95 (IEC/ISO 62264)という標準規格がある。ISA-95は、ビジネス(経営)ドメインと製造ドメインとのインタフェース仕様を定めたもので、その中には以下の12の生産関連機能が書かれている(番号はわたしが勝手にふった整理番号である)。

ビジネスドメイン:
 1 オーダ処理、
 2 製品原価管理、
 3 製品出荷管理、
 4 マーケティングと販売、
 5 研究開発および生産技術、
 6 調達、
製造ドメイン:
 7 生産コントロール
両者の境界線にまたがる機能:
 8 生産スケジューリング、
 9 製品在庫管理、
 10 品質保証、
 11 保全管理、
 12 資材およびエネルギー管理

ビジネスドメインと製造ドメインにまたがる機能がMESの役割と考えると、スケジューリング、在庫、品質、保全、資材・エネルギーの5(6?)種ということになる。ただこれらは「お仕事の機能」であって、IT機能モジュールという意味ではないので注意。

ほかに、あまり知られていないが、日本発の標準化を目指した製造科学技術センター(MSTC)の「オープンMES」の9機能というのがある。

1 製造指示管理、
2 工程管理、
3 設備管理、
4 資材管理、
5 搬送管理、
6 製品仕様管理、
7 スケジュール管理、
8 工程仕様管理、
9 保守管理

ISA-95と比較すると、搬送管理や工程仕様管理が入っている点が目をひく。こちらはさらに、製造現場に立脚したモデルという感じを受ける。ただオープンMES自体は、実証目的で試験的実装まで行われたが、技術的及びマーケティング的理由で、現実には広まらなかった。

ところで、ARC Advisory Group(米国の製造業系ITの調査コンサルティング会社)のつい最近の調査レポート:
ISA-95 Integration Standards: Evolution, Revolution or Irrelevance
を読んでいたら、興味深いことが書いてあった。著者はIoT技術の普及進展と共に、MESがいかに影響を受けるかを論じていて、とくにISA-95規格が「進化するのか変革されるのか、それとも無関係なのか」と問うている。その中に小さな図が一つはいっていて、例の3層モデル風の絵が描かれているのだが、そこではMESをさらに

 - Upper MES
 - Lower MES

に分けているのだ。Lower MESは、制御層に一部食い込んでいる(ISA-95はパーデュー大学が開発した機能階層モデルを採用しているので、「制御層」という言い方はしないが)。上位MESと下位MES? 似たような表現を、別の制御ベンダー資料でも見たことがあった。
e0058447_16341478.png

いったい、Lower MESとは何か。それは制御層の機能を抱え込んでいるか、切れているのか? これは、上記MESA Internationalの(8) プロセス管理 Process Managementで感じた違和感にも通じている。そもそも、本社機能と現場をつなぐのがMESシステムではなかったのか。だったら現場の機械を動かす制御が、どうしてMESの一部なのか。

こういうヘンテコな現象がMESの機能モデルで生じるのは、じつは理由があるのだ。それは、上述のアメリカ発の標準体系が、ディスクリート系とプロセス系の両方を取り込んだ結果なのである。彼らは抽象化と汎用化を強く志向する人達なので、どんな製造業にも当てはまるモデルを求めたのだろう。だが、それが混乱の元だった。両方をそれなりに見てきたわたしの意見では、プロセス系と組立加工(ディスクリート)系は、制御層の構造がものすごく違っているのである。

簡単に言うと、プロセス産業では、制御レベルで工場(製造ライン)全体が統合されている。プラントにはDCSというシステムが中央制御室にあって、そこから工場内の全てのできごとが監視でき、また主要な機器・バルブなどを操作できるようになっている。

ところが、ディスクリート系では制御が機械単位で行われているのが普通だ。現場に製造機械がある。それのモーションを制御するPLCは、機側盤の形ですぐ横についていて、オペレーターはそのパネルから操作するのが普通だ。搬送機器なども同様である。だが、工場レベルではバラバラだった。前回書いたように、建物の一歩外に出ると、中の機械が動いているか止まっているのかさえ分からないのである。

これではこまるから、複雑な機械作業の連動が必要な半導体や液晶や医薬品工場では、MESが発達したのだ。MESが各機械・設備を統括し、連動して工程間制御の指示を出す。だからMESの中に制御的な機能が入ってくるのである(いわゆるLower MES)。これはプロセス系MESではほとんど不要なことだった。

現場センサーの接続についても、状況はまったく異なっている。プロセス系では、現場の圧力計のトランスミッターと、中央制御室のDCSのメーカーが違っていても、つながってあたり前である。通信がつながるかどうかの心配なんて、誰もしない。もう何十年も前からそうなのだ。だがディスクリート系では、長らく、つながること自体が技術力の証だった。「つながる工場」といったって、つながり度が全然違うのである。

だから制御システム業界では、プロセス系をPA(Process Automation)、ディスクリート系をFA(Factory Automation)と呼び、社内的に区別してきた。技術の考え方がまったく違うからだ。

プロセス系とディスクリート系は、製造における仕様や品質管理の思想も違う。このことは、強調しておいた方が良い。ディスクリート系では、モノに属性がある。また、モノに(やろうと思えば)シリアル番号をふれる。それが当たり前だと、皆、思っているだろう。なぜなら、扱うモノが個体で、混合しないからだ。

だが、プロセス系では、モノではなく、ライン(配管内の流れ)に属性がある、と考える。なぜなら扱うのが流体や粉体で、任意の比率で混合するからだ。そして混合比率も性状も、経時的・連続的に変化する。ただしプロセス系といっても、連続生産でなくバッチ生産の場合は、品質的に均質と言える範囲をロットと定義して管理する必要があるが。

ともあれ、無理に木に竹を接ぐと奇妙なモデルが生まれる。これが、「システム・モデラーが天職」を自称するわたしの、MES標準化活動に関するいささかゴーマンな主張である。もちろん、プロセス系とディスクリート系の境界領域は存在する。わたしのいう「切替型連続生産」業種で、上流はプロセス、下流はディスクリートになる。こういった領域ではモデリングにも細心の注意が必要だと、わたしも思う。

それで、主題はIoT時代のMESの将来であった。わたし自身は、プロセス系のMESについて、すでに「MES入門」「MES活用最前線」でいろいろ書いてきたので、この記事ではあえてディスクリート系のMESについて論じよう。IoT技術が現場とのつながり方を速く広くしてくれたことで、MESはどうなるのか。MESとは工場の製造管理者(工場のホワイトカラー層)を助ける仕組みである、というのがわたしの前提である。一部の欧米人は、本社が直接、MESで製造現場を指示統制できれば製造管理者など不要になると空想しているかもしれないが、わたしはそうは考えない。

その前提の上で、わたしはMESに二つの変化を予想している。だが、今回も問題整理で長くなりすぎてしまったようだ。変化の方向性については、稿を改めて、次回書く。


<関連エントリ>
 →「IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの」 http://brevis.exblog.jp/25991822/ (2017-08-19)
 →「工場計画論(6) ディスクリートとプロセス--製造業の分類学」 http://brevis.exblog.jp/12850087/ (2010-06-23)



by Tomoichi_Sato | 2017-08-27 12:54 | サプライチェーン | Comments(0)

IoT時代のMESをもう一度考え直す 〜 (1) MES普及を妨げたもの

2000年に、中村実氏ら何人かと共著で『MES入門―ERP、SCMの世界と生産現場を結ぶ情報システム』を上梓した。わたしが担当したのは第3章「MESを中核とした垂直統合 -プロセス産業のケース-」というセクションだ。製造業、それも製造現場の情報システム化という地味なテーマの本だったが、一応、それなりの評価を得た。類書が少なかったせいもあるだろう。いまでも、あの本を読みましたよ、という方から声をかけられたりする。

ここで一応、MESとは何かについて、おさらいをしておこう。何年か前に、その名も「MESとは何か」という記事も書いたが、MESとはManufacturing Execution Systemの略で、日本語では「製造実行システム」とも訳される。だが、普通は「製造管理システム」とよんだり、あるいは略称のままMES(メス)ということも多い(ただし英語ではエム・イー・エスとスペルアウトして読むのが正式である)。

製造業のことを良く知らない人は、MESと「生産管理システム」とをよく混乱しがちだが、別のものだ。生産管理システムは全社レベルで、製品別の生産・在庫・出荷などを計画し、部品材料の調達を決め、実績を集計する。さらに原価や収益を計算したりする。だからお金に関わる人達、つまり経営者や営業部門や会計部門も、そのアウトプットを見たりする。だがこうした人達がMESの画面をのぞき込むことは、まずない。

MESの概念は、1993年に、米国の製造業向け調査コンサル企業であるAMR Research社が提唱した、3層モデルに端を発する。AMRは、製造業の機能を、
・主に本社が担当する「計画層」、
・主に工場が担当する「実行層」、
・機械等が働く「制御層」、
の3レベルにモデル化した。しかし最上位の「計画層」という言葉は分かりにくいので、「ビジネス層」と読み替えても良いと思う。ここを担うITシステムはERPである。また最下層の制御レベルで動くのは、たとえばPLCやDCSなどのシステムである。

AMRはその上で、ビジネス層(ERP)からの計画・要求を、現場の機器・制御層(PLCなど)レベルにつなぐ中間層の機能が、IT的な<ミッシング・リンク>(失われた環)になっていると指摘した。そしてこの部分を担うシステムを、Manufacturing Execution System = MESとよんだのである。

わたしは90年代の半ばから、海外プロジェクトでプロセス産業におけるERPとMES層の仕事に、従事してきた。その経験を元に上述の『MES入門』第3章を書いたのだが、その中で「8の字モデル」という概念を提案した。これはAMR Researchの3層モデルを元にしつつ、意味的には換骨奪胎したものだ。AMRは米国流トップダウンの経営思想で、本社の要求を現場に落とし込む、つなぎ機能としてMESをとらえた。だが、実際の現場を見てきたわたしには、MESはオートメーションにおけるミッシング・リンクというよりも、製造管理者の仕事を助ける道具である、という主体的な位置づけの方がふさわしいと思えた。ちなみに製造管理者とは、工場の製造部門のホワイトカラー層のことである。
e0058447_00072182.jpg
「MES入門」第3章より

さて、わたし達はさらに前述の本の姉妹版として、2004年に『図解 MES活用最前線―実践事例でわかるMES(製造実行システム)導入のポイント』という本を上梓する。この中で、かなり幅広い業種・企業から、MESによる製造現場情報化の事例を集めて紹介した。

この本には、自動車会社のALC(アセンブリー・ライン・コントロール)システム、フォークリフト製造会社の工場全体をカバーする本格的MES、そして、今や製品に内蔵したIoTシステムで有名になった建設機械メーカーのMESなど、さまざまな事例が図解付きで紹介されている。なお最後の建機メーカーのMESは、現場への指示中心でPOP的だが、現場ユーザが音声でシステムに指示を出すという点でかなりユニークな事例である。ただ、あいにく出版元の工業調査会自体がすでにないため、どちらの本も今やかなり入手困難だ。

さて、それから10年以上の歳月がたった。では、MESに関わるものごとは、どれほど進展したのか? 

工場にMESがあることが当然であり、MESが製造のほぼ全域をカバーしている、という業種は、2004年の刊行時点では、
  • 半導体工場、その応用として一部の液晶関連工場
  • 石油・化学工場
  • 医薬品工場
  • 自動車組立工場(アセンブリー・ライン)
などであった。それ以外は、製造の情報化について、部分的なトライアルが行われている、一種の事例集であった。

その事態は、2017年の今も、あまり変わっていないように思える(少なくとも日本では)。たしかに17年間でMESソフトウェア情報や、ベンダーの勢力地図は変わった。海外ITベンダーからは、今や、より統合的な(そして高価な)MESパッケージが販売されている。ただし、日本ではあまり売れていないらしい。

こうした新しい仕組みの普及度については、ざっくり三種類に分類できると思う。

(1) 一番上に来るのは、『必須レベル』である。
「それがない工場は考えられない、それがないと製造の仕事が回らない」というくらい、仕事に組み入れられている。たとえば会社のITならば、会計システムだろう。今どき、そろばんと電卓で経理している企業はもう、ない。あるいは車にたとえるなら、オートマチック・トランスミッションか。今どき、新車の98%はAT車で、マニュアル車は例外に近い。

(2) 二番目は、『普及レベル』だ。
「普通はある。ただし、なくてもなんとか仕事は回せる」がこのレベルである。車でいえば、カーナビだろうか。製造業ならば、販売管理(受注管理)システムだ。これがないと、受注番号(製番)を起こせないし、出荷遅れや請求漏れも生じかねない。あるいは設計系ならば、CADシステムだろうか(ただし、3D-CADとなるとあやしいが)。

(3) 三番目は『オプションレベル』だ。
「先進的な工場にはある。あると仕事に優位性や効率性が出る」という種類のものである。口さがない人からは、趣味だとか、好きものだとかよばれかねない。車なら自動ブレーキ、さらには夢の自動運転か。
そして、明らかにMESはまだ、このレベルにいる。

だが、なぜMESは普及しないのか?

一昨年のこと、わたしが所属する「ものづくりAPS推進機構」の委員会で、ある会話に衝撃を受けた。それは、多くの製造現場で使っている自動化された工作機械、NC(数値制御)やMC(マシニングセンタ)に関することだった。こうした高価な自動機を制御するPLCの外部通信インタフェースは、いまだにRS-232Cが主流だというのだ。RS-232C! それって、1980年代に、パソコン通信で使っていた低速のシリアル通信規格ではないか。

いや、その場にいた某大手PLCメーカの人は、「RS-232Cがついていればいい方です。旧いマシンのPLCになると、外部I/Fすらついていませんから」というのだ。だから複雑な加工のどこまで進んだかを、リアルタイムでモニタリングできない。進捗管理はある意味、ショップ・フロア・コントロールの柱だが、それができるようになっていないのだ。まあ、メーカー側ももう少し高機能なNC用I/Fは開発して出している。だがそれもPLCメーカーごとに規格が違う。

その場の話では、ドイツではこうしたI/Fは標準化が進んでいて、どこの工作機械メーカーをもってきても、すぐにつないでリアルタイムに機械の状態を監視できるということだった。わたしはしばらくディスクリート系(組立加工系)の仕事から遠ざかっていたので、日本でこうした状況が続いていることに驚いた。

しかし、NCマシンの切削状態監視どころではない。多くの組立加工系の工場では、工場出入口の扉を後ろ手に閉めて、建物の一歩外に出ると、中の機械が動いているか止まっているのかさえ、分からないのである。最近見た、日本の製造業をリードする自動車産業のTier-1サプライヤーでさえ、いまだにそうなのだ。

ただ、それでこまらなかったのは、カンバン方式に代表されるトヨタ生産システム(TPS)を実現しているためである。トラブルがあっても、「アンドン」で見える化し、現場で近くにいる人がすぐ問題解決するのが、TPSの思想である。だから建物の外から機械の稼働をリモートで監視する必要はない。NCマシンの通信I/Fが古いシリアル通信のままなのも、そういう思想が理由なのだろう。加工プログラムだけNCに送れればいい。加工中に問題が起きたら、現場の多能工がトラブルを解決する。

それは、現場の技能員が優秀ならば可能なやり方である。だからトヨタは「ものづくりは人づくり」と主張し続けているのだろう。だが、「それはトヨタ系だからできること」と、知り合いの中小企業経営者はいう。彼の会社では、現場の人にとてもそんな能力は期待できない。だから、「問題が起きたら俺を呼べ」と、つね日ごろいっているそうだ。

それにしても、現場カイゼンの得意なJITコンサルタント流のIT不要論をきいていると、まるで「熟練のドライバーなら、マニュアルミッション車を上手に運転できるし、地図も頭に入っている」という主張を聞いているようだ。なるほど、たしかに熟達の人ならば、ATやカーナビ的なシステムは不要だろう。だが、「その熟練の技、どうやって海外展開するんですか?」 と聞きたくなる。

いや、その前に、「どうやって後輩に伝えるんですか?」といいたい。・・だいたい今どき、工場に好きこのんで働きに来てくれる、優秀な若者ってどれだけいるの? 夏暑く冬寒い、外気開放の鉄骨スレートの建物の、油煙舞い立つ職場に、誰が来たがるのか。これからの工場というのは、むしろ、見学した人がみな、「ぜひここで働きたい」と思う環境でなければいけないのではないか。そう思うのだ。

いや、つい話がそれた。

製造管理に話題を戻すと、いくら現場が優秀でも、一つの現場だけでは解決しきれない問題、判断しがたい指示変更はいくらでもあるはずだ。複数工程にまたがる変更や、負荷のアンバランスなどである。そして週単位・月単位での、品質や生産性や労働安全の傾向などもそうだ。わたしの言い方でいうと、現場の個別問題は「技術的問題」である。他方、いわゆる「パフォーマンス問題」をこそ、製造管理者は発見し、解決しなければならない。

以前からMESが当たり前に導入されてきた、半導体、液晶、石油・化学、医薬品に共通することは何か。それは、製造エリアがクリーン度を要求される、あるいは危険物質を扱い防爆が必要など、現場作業に人手をかけにくいことだ。結果として、機械設備リッチな工場になる。製造のみならず搬送を含めて、広範囲に自動化される。

こういう工場は、機械との通信I/Fを含めてMESを入れやすい。むしろMESがないと工場が動かない。最初からMESの存在を前提に、工場レイアウトも設計される。だから、「製造現場を後からスマート化する」発想では、そもそもないのだ。ただ、自動車工場の最終組立ライン用ALCシステムはやや例外で、人による組み付け作業が中心になっている。しかし多数の部品と指示からなる複雑な製造システムであることは、共通である。

結局、MES普及のボトルネックはビジネス層とのつながりではなく、制御層・製造現場との接続だった。

ではなぜ、現場の機器・制御層とつなげなかったのか?。ひとつには工場の既存設備の問題があるだろう。機械制御用PLCのI/Fが乏しいばかりか、PLCを持たない単純機械や、手作業もかなり介在する。

またIT技術的な問題もある。工場内の適切な通信プロトコル標準がまだ存在しない。ネットワーク一つとっても、まだベンダー間のバトル状態である。それにセキュリティ対策の懸念もある。

そして、規制や商習慣の問題もある。電気・空調・消防系設備のシステムは、いわゆるビル・マネジメント・システム(BMS)とよばれる領域であり、製造系システムとは別業界で、共通I/Fもない。また仮に製造機械が外部からネットワークでつながったとしても、機械メーカーが外部からの制御を歓迎しない、などがあげられる。

かくして製造管理者と現場との間には、壁ないし岩盤があったのだ。そして、だからこそここに、IoT技術登場のインパクトがある。ようやく、センサーやSCADAを介して、機器やデバイスレベルのデータをとれるようになったのだ。

では、それはどのようなインパクトなのか? 長くなってきたので、続きは次回書こう。


<関連エントリ>
 →「MESとは何か」http://brevis.exblog.jp/14886701/ (2011-06-02)


by Tomoichi_Sato | 2017-08-19 23:57 | サプライチェーン | Comments(0)

工程表と部品表 - 個別受注生産における主従の逆転


若い頃、『システム・モデラー』という職種を目指したい、と言ったら、上司から「そんな職種はない」と言われたという話は、以前書いた。(「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/ 2013-08-01)。それで、その後わたしは「プロジェクト・アナリスト」を名乗るようになり、今では名刺に、勤務先の「チーフ戦略アナリスト」である、と書いている。

だが、今でもわたしはモデリングの仕事が好きだ。データ・モデリングとは、世界の概念的スケッチである。言葉と簡単な図を使って、世界のあり方を切り取って分析する仕事は、何より楽しい、と思う。モデリングという仕事は、技術とアートの中間地点にある、とも言われる。科学的論理性だけでは、良いモデルを作るには足りない。モデルとは近似であり、見切りだからだ。モデルは必ずしも事物の厳密・正確な再現ではない。英語で、"Models are all wrong. But, they are useful.”という言葉をきいたことがあるが、金言だと思う。モデルはすべて、正しくない。だが、有用なのだ。

さて、前回(http://brevis.exblog.jp/25634844/)は『部品表』と『工程表』という概念について、簡単なイントロ的解説を書いた。ところで、前回の記述は、じつは繰返し性の高い生産形態での話だった。つまり、見込生産(MTS)とか繰返し受注生産(MTO)の場合なのだ。

(なお、若干話がずれるが、生産形態の分類を表す用語については、日本語の慣用句よりも英語の用語の方が本質を突いているので好きである。見込生産は英語でMake to Stock = MTSとなる。「在庫してストックするために作る」形態なのである。繰返し受注生産はMake to Order = MTOで、これは「注文に応じて作る」やり方だ。このように、何に対して製造するか・製造の結果が何になるか、が英語での表現では、より明快だ)

さて今回は、ETOの場合について書いてみたい。ETOとは、Engineer to Orderの略だ。Engineerという単語は、ここでは「技術者」という名詞ではなく、「設計すること」という動詞で使っている(ちょうど”Engineering”という動名詞の言葉があるように)。ETOは日本語では、「個別受注生産」あるいは「一品受注生産」「受注設計生産」などとも呼ぶ。

ETOという生産形態の本質は、製造の前に設計作業が必須となることだ。このような生産形態は、意外と多い。たとえば造船。航空機。大型の産業機械(たとえば圧縮機や工作機械など)。あるいは金型。いろいろある。わたし達プラント・エンジニアリング会社が購入する資機材の大部分も、ETOの形態で生産される。そしてIT業界でSIerが行う受託型のシステム開発も、受注後に設計が必要になる点では、ETOの一種だと見ることもできる。

わたしの見るところ、日本の製造業には、このETO形態をとっている企業がかなり多い。好むと好まざるとに関わらず、いや、それが企業自身で自覚して選んだ結果なのかどうかも分からないが、とにかく、広く見受けられる。統計的根拠までは示せないが、英米や中国などより、ずっと比率が高いのではないかと思う。

その理由は、日本における顧客(買い手)側のあり方に起因している、というのがわたしの推測だ。日本の顧客(B2Bで、顧客が企業の場合)は、なぜかメーカー標準品を買うことを潔しとせず、必ず自分好みの個別仕様を付け加えたがる傾向がある。たとえば生産財を買う場合、それが自社の生産ラインにぴったり最適化され、面倒が少ないようにしたい。そのため、いろいろ個別で特殊な注文がつく訳だ。そういう風に細かな注文をつけること自体が、エンジニアとしてのプライド、ないし存在意義とさえ思っているらしい(実際にはその分、標準品よりコストが上がっている可能性が高いのだが、会計部門への説明能力の高いこともエンジニアの能力の一部である^^;)。顧客から個別注文を受け取った企業の技術者は、自分のサプライヤーに振り向いて、同じように個別仕様を要求する。かくして、日本ではETOに対応しない企業は生き残れなくなっていく。

ところで、いろいろな生産形態のうちで、生産管理の一番難しいものが、このETOなのである。だから日本の製造業は、全体として、わざわざ一番難しい生産形態を、みんなして選んで、お互いに生産性の低さに苦しんでいるとも言える。

ETOは、なぜ難しいのか? ETOの特徴は、受注時点で部品表(BOM)が固まっていないことにある。まあ受注時点でも、たいていの場合、大きな骨格くらいは見えている。そうでなければ、そもそも金額さえ見積れないからだ。

しかし、細部は設計してみないと決まらない。当然、設計後に、部材を注文することになる。注文してはじめて、部材は工場に入ってくる。部材がなければ、製造はできない。当たり前だろうって? その通りだ。だが、製造のスケジュールという観点から見ると、ETOとそれ以外では、大きな違いがあるのだ。

前回の図を思い出してほしい。複数の子部品が組み合わさって、一つの製品ないし親部品ができあがる。それを作るために、工順がある。いいかえると、部品の親子関係に対応して、一つの工順がある(厳密には『代替工順』というものも存在しうるが、今その話には深入りしない)。工順は複数の作業からなっていて、それぞれの作業に、製造資源(人や機械)が結びつく。こういう構造だ。

ここで、ちょっと図を見てほしい。ここに掲げたのは、渡辺幸三氏が「CONCEPTWARE/生産管理」の名前で公開している、生産管理システムのデータモデル図の一部だ(http://dbc.in.coocan.jp)。渡辺氏は、今日のIT業界のレベルアップと生産性向上をめざして、あえてこうした本格的で実線的な業務系システムのデータモデルを公開しておられる。
e0058447_22074045.jpg
E-R図を見慣れた方ならば、これを見るだけでわたしの言いたいことはお分かりいただけると思うが、念のために説明しておこう。なお渡辺氏の用語はわたしのとは少し違っているため、対応関係を示しておく。左が渡辺氏のモデル上の用語で、右がわたしの用語である。

(1) 工程→工順、 (2) 作業場→作業区(ワークセンター)、 (3) 製造品工程明細→作業、 (4) 製造品材料明細→部品表、 (5) 品目→マテリアル(品目)

この図を見ると、(5)「品目」レコードに対して、複数の(4)「製造品材料明細」レコードがぶら下がっている(渡辺氏の図法では、「∈」は1:Nの関係を示す)。これは、一つの親部品が、複数の子部品から組立・加工されて作られる「親子関係」を示している。そして、(5)「品目」レコードに対し、(3)製造工程明細が、やはり複数ぶらさがっている。つまりここでは、品目が主であり、工順・作業が従であることが表されているのだ。(細部に興味がある方はダウンロードして、全体をご覧になることをおすすめする。非常に勉強になると思う)

そして製造リードタイム(渡辺氏の図ではLead Timeの頭文字をとってLTと略されている)は、個別の作業に結びついており、作業を積み上げて、工順の、そして全体の生産スケジュールができあがるのだ。

言いかえるなら、設計が完了して、すべてのマテリアルと部品表が決まらない限り、製造コストやスケジュールが確定しない、ということになる。コスト(原価)については、もはや受注時点ですでに販売価格が決まっているのだから、今さら泣いても笑ってもどうにもならない。だがスケジュールは問題だ。工場では複数の品目や注文が流れており、スケジュールの相互調整によっては、他の品目の納期に影響してしまう。

MTS(見込生産)やETO(繰返し受注生産)ならば、事前にBOMが確定しているから、「標準納期」とか「標準リードタイム」といったものを設定することができる。だがETOは、受注時点で全体のスケジュールが見えないのだ。ということは、受注時点で、本当に納期を確約できるかどうかも、分からない訳だ。おまけに、現場の人や機械の事前手配も、難しいと言うことになってしまう。

それがどうした。ものづくり現場は、部品と図面がなければ動けないのだ。だったら設計が全部終わった時点で、製造のスケジュール計画を立てればいいではないか、と思う人もいるかもしれない。だが、そうはいかないのだ。競争環境下では、そんなにのんびりした納期を顧客は与えてくれない。だから、部品表が確定した部分から、順次作り始めなければ、ふつう間に合わなくなるのだ。かくして、設計作業と、部品調達と、製造作業が、並行して進むことになる。本来は順番に進むはずの仕事が、入れ子になったり逆転したりして進むのだ。設計部品表(E-BOM)と製造部品表(M-BOM)が別々に管理されている企業の場合、話はさらに混乱してくる。

米国生まれの生産管理手法であるMRPが、日本でなかなか受け入れられ普及しなかった理由の一つが、ここにある。MRPは、大量繰返し生産マインドの強い米国で、'60年代に生まれた手法である。MRPでは、計画時点に、製品のBOMデータが存在していることを前提している。だが個別仕様が好きで短納期を要求したがる顧客だらけのわが国では、なかなか使い物にならない。

では、どうしたらいいのか?

ここで実は、発想の転換が必要となる。それは、「品目」→「作業」という主従関係の逆転である。

「作業」と、その集合である「工順」を、視点の中心におく。そして工順のインプットとアウトプットとして、子部品・親部品をとらえる。前回の図を、もう一度見直してみてほしい。

今、ここで問題としたいのは、製造スケジュールである。つまり個別作業にかかる正味時間、工順に与えるべきリードタイムだ。そして、それは、同じような親部品を製造する作業では、子部品の細部が多少異なっても、ほぼ同じだと見ることができる。え? 六角の部品の加工と、円形の部品の加工では作業が違うだろうって? たしかに厳密には違う。だが、生産スケジュールはモデルであり、一種の近似であることを思いだしてほしい。何秒単位の厳密な数字を議論しても仕方ないし、そんな精度は必要ないのだ。現場が必要とするのは、現場が混乱しないですむようなざっくりした精度の、しかしある程度は信頼しうる予測なのだ。

個別作業の所要時間見積のために、ここで登場するのが「パラメトリック見積法」である。これは、作業対象が持つ、なんらかの代表的なパラメーターを用いて、作業時間(つまりコストを)推計する方法だ。そして、この仕事のために、BOQ = Bill of Quantityという概念が、BOMのかわりに登場する。Quantityはパラメーターの数字である。グラムとか、mmとか、リットルとか、何の単位でもよい。それが作業の量(Quantity)を適切に示してくれたら、それで良いのだ。あとは割り当てる製造資源と、その生産性指標とから、作業時間を推算することができる。製造コストも、推算できる。

詳細な設計作業が十分に完了していなくても、基本設計段階(ないし受注前の見積設計段階)で、製品を構成するサブ・モジュールや共通部品等のBOQを洗い出し、リスト化しておく。そうすれば、これを元に、製造スケジュールをあらかじめ立てられる。これが、プロジェクト的なETO=受注設計生産のやり方なのである。詳細のBOMは、設計のあとでできてくれば良い。

もともとBOQという用語・概念は、100年ほど前に英国の建設業界で生まれた概念だ。そして、エンジニアリング業界に流れ込んできた。わたし達の業界では、このBOQ(しばしばBQとも略す)が、プロジェクト・スケジューリングの中心的なデータになるのである。わたし達にとって、作業(プロジェクト用語ではActivity)が主であって、そのインプット・アウトプットとなる品目(マテリアル)は従である。作業が先にあり、品目は段階的詳細化の結果として、後から決まってくる。このような世界観で、エンジ会社はプロジェクト・マネジメントを行っている。

そしてエンジニアリング・プロジェクトは、まさに巨大な「受注設計生産」そのものなのである。基本設計の外部仕様を元に、詳細設計を起こし、資機材を世界中のサプライヤーから調達し、プラントの現場に運んで、据付組立作業(「建設」)を行う。我々もまた、組立加工産業なのだ。

そしてもう一度最初の話に戻ると、システム・モデリングの面白い点は、こうしたデータモデル上の主従の逆転、アクロバティックな視点の転換が、ときに必要となることにある。必要なだけではなく、とても有効でもある。もちろん、そのためには、ある種のスキルがいる。ものごとを俯瞰して見る、一種マネジメント的なスキルが。そういう訓練の場をエンジニアのために作ろうと、わたしはこのところずっと研究部会の仲間達と活動しているのである。どうか期待していてほしい。


<関連エントリ>
 →「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/(2013-08-01)
 →「部品表と工程表」 http://brevis.exblog.jp/25634844/ (2017-03-22)

by Tomoichi_Sato | 2017-03-31 22:10 | サプライチェーン | Comments(0)

部品表と工程表

今年の初め頃だったが、ある集まりを手伝うことになった。中高校生くらいの若い子達が20人くらい集まるので、彼らに昼食を出す。わたしと連れ合いはその食事作りのお手伝い、という受け持ちになった。わたし以外は全員、年配の女性達だ。集会場所の横にはそれなりのキッチン設備があり、食器もそろっているので、そこに集合となった。前日までのメールでは、シチューを作ると聞いていたのだが、当日集まっていたら、なぜかメニューはカレーと野菜スープに変更になっていた。ともあれ、食材もそろって、さあ調理と言うことになった。

ところで、この調理の進め方がなかなか見物だった。わたしは男なので、食器洗いその他の力仕事に回り、実際の調理は女性達が受け持つ。皆、何十年と料理をしてこられた方ばかりだ。ただ、わたしも一応、料理の心得はあるので、どんなプロセスで進むかは理解している。まず材料を洗い、切り、大鍋に適時投入して、煮て味付けをする。そのかたわらご飯を炊いて、織機を用意する。それだけのことなのだが、現場は大騒ぎだった。

まず、この集団には、采配をふるうリーダーがいない。2、3人、それなりにリーダー格というか、まあ仕切り屋のタイプの人はいる。だが回りの人たちも黙っていない。みな、料理については一家言ある女性ばかりだ。だからどの材料をどれくらい使うか、どう切っていつ鍋に投入するか、味付けには何をどれくらい入れるか、まあ実に喧々がくがく、議論が続く。議論だけでなく、彼女たちはしゃべりながら実際に手が動き、勝手にやってしまう。もうどうなることやら、ホントに昼食時間までに間に合うのか、などハラハラして見ていたが、幸いというかカレーも野菜スープもなんとかそれなりに出来上がって、腹を空かせたティーンエイジャー達の胃袋にあっという間に飲み込まれた。

この集まりはまあ、ボランティア集団のようなものである。こういう集団では、会社のような上司・部下関係が無いし、指示=命令原理も働かない。誰か図抜けたリーダーがいればその人の判断と采配で、皆が一応動くだろう。だが、そういう人もいなかった。それでも何とかなったのは、女性達の調理のスキルもあるが、一つにはカレーとスープという料理が、材料にも味つけにもある程度幅があっても、まとまりやすい料理だったからだろう。

それにしても、同じこの仕事を、わたしの勤務先の同僚達がやったらどうなるだろう、と想像してみた。ボランティアの組織だ。賛同者が集まり、業務命令系統はとくにない。でも、きっと、自然にこうなるだろう:
(1) まず、料理は何を何人前作るか相談の上、決める。
(2) 必要な食材のリストを作る。食材の種類と、数量と。必要ならば、スペックつき(たとえば豚肉ならば「バラ肉」とか)で。
(3) 調理の手順のリストを作る。それに必要な調理器具もリスト化する。
(4) 食材調達の担当者を決めて、買い物を任せる。
(5) その間に、調理器具と食器の準備をする。必要な食器を集めて洗い、並べる。
(6) 食材が来たら、これも分担して洗い、カット、下ごしらえをする。
(7) 調理をする。この作業にはやはり、多少はスキルのある経験者をあてる。
(8) たぶん何人かで味見をして、OKとなれば盛りつけ、配膳作業をする。

たぶんこうしたことが、なかば自然に進むだろう。なぜなら、これはエンジ会社が普段やっている、エンジニアリングの仕事そのものだからだ。誰かがリーダー役を引き受けるだろう。あるいは長老が、誰か若手を指名してリーダー役にするかもしれない。皆、そのリーダーの采配と交通整理に従う。難しい問題が起きたら、皆で相談して解決する。それでも迷ったら、リーダーの責任で打ち手を決断する。これがたぶん、わたし達のスタイルだ。もちろん、調理の腕前は熟練の女性達にはかなうまい。でも、何とか必要なものを必要なタイミングに必要な量だけ、届けられると思う。

とくに大事なことは、最初に大まかな計画を立て、必要な材料や道具や手順のリストを作ること。これがないと、全体の仕事量も、作業の分担も、そして納期も見通せないからだ。

わたしの勤務先が特別だというつもりはない。たぶん大方の会社は、少なくとも製造業なら、こういう風に仕事を進めると思う。ものづくり企業に共通なDNAというのがあるとしたら、その一つは、最初にいろいろなリストを作ることにあるだろう。リストなんか作らなくても、あの女性達のように、ものは作れる。だが、仕事の見通しは、格段に落ちるだろう。

必要なリストは何だろうか? あるいは、もっと抽象化して問題を捉えるなら、生産という仕事に必須な基準情報は何なのか。

それは大きく、「もの」(=マテリアル)に関する情報と、「製造作業」に関する情報とに分かれる。「もの」に関する情報は、まず、どういう品目(材料・製品を含む)があって、それはどういった使用・属性を持つか、というリストになる。これは通常のIT用語で言うと『マテリアル・マスタ』(品目マスタ)と呼ばれる。ついで、ある製品は、どのような部品・材料から成っていて、どれだけの数量を要するのか、という製品構成に関する情報が必要だ。これが『部品表』(BOM = Bill of Material)データである。ただしBOMがマスタとしてITシステムの中に整備されているかどうかは、その企業・生産形態に依存する。

では、製造作業に関する情報はどうか。これはまず、製造に使う機械・設備の情報と、具体的な作業の情報に分かれる。前者は、機械リストとか、会社によっては作業区(ワークセンター)マスタと呼ばれる。もう少し進んだ形では設備構成マスタというデータ形式になる。設備構成マスタとなると、その中に階層構造が表現されて、たとえば作業区1の圧縮機Aには、補機として潤滑油ポンプA1がある、といった事情がわかるようになっている。つまり一種の、機械設備に関する部品表みたいなものである。かなり保守業務のレベルの高い企業では、こうしたマスタが必要とされる。

後者の、具体的な作業の情報については、特定の製品・品番ごとに、(通常は複数の)製造作業が生じる。つまり、各作業に必要な機械・設備は何で、その順序はどうで、各作業条件は何で、(もしあれば)マニュアルや作業標準はどれで、といった属性が並ぶ作業マスタがいる訳だ。これは基準情報である。ただし、個別の作業指示が出される場合は、それぞれの作業にIDをふり、これに着手・完了のタイミングを指定し、さらに必要な機械・設備などをアサインしたリストを作ることになる。これは、しばしば『工程表』と呼ばれる。英語でBOP(Bill of Process)と呼ぶこともある。

以上をまとめると、生産という仕事に関する基準情報は大きく4種類に分けられる:

マテリアルに関する情報
・マテリアルの属性情報 → マテリアル・マスタ(品目マスタ)
・マテリアルの構成情報 → 部品表(BOM)
製造方法に関する情報
・機械・設備の構成情報 → 作業区マスタ、ないし設備構成マスタ
・製造作業の属性情報  → 作業マスタ、あるいはその具体型としての工程表(BOP)

なお、ここで注意しておきたいことがある。それは「情報」と「データ」の区別だ。これについては以前、『ITって、何?』というシリーズで長々と述べたことがあるから詳しくは繰り返さないが、
・「情報」とは人間に意味をもたらすもので、基本的には不定形
・「データ」は定型化された記号の並びで、機械的処理に適する
という区別がある。今日はA社の業績ニュースが流れて株価が上がりました、が情報。各社の株価が定型化されて並んでいる株式欄が、データ。情報を定型化して機械で処理したり、データを読み取って人間に意味を提示するのが、IT(情報技術)である。上に述べた基準情報の例でいえば、人間は情報だけあればいい。ただ、量が増えたときには、紙に記録してリスト化したり、さらにコンピュータの中に収めてマスタ・データ化する方がベターだ。

もう一点。上の説明では、『工程』という言葉をあえて使わぬように説明した(「工程表」は別として)。これは、工程という用語が業種・会社によってかなりいろいろな意味に使われているためだ。大きく分けても、工程をプロセス=作業群の意味で使うケースと、ワークセンター=作業区の意味で使うケースがある。それらをごっちゃにしているケースだって、少なくない。工程表という用語だって、それなりにブレがある。

本当はこうした用語類は、わが国の生産管理の発展のためには、共通化した方が良い。しかし、抽象化・標準化への希求がかなり弱いわたし達の社会では、それぞれの業界や特定の大企業が勝手に作った方言を、グループや系列会社に押しつける例が、よく見受けられる。業界を横断して工場づくりの仕事をしている我々エンジニアリング会社にとっては、まことに不便な状況である。本来だったらアカデミアの学者が先導して、こうした状況を改善すべきなのだろうが、あいにくその動きも薄い。

そこでわたしは、せめてこのサイト内では整合性のある用語を使うように心がけており、とくに多義語である「工程」は極力使わないようにしている次第だ。かわりに、わたしは製造業務のプロセスを呼ぶときは『工順』(英語でRouting)と呼ぶようにしている。わたしの考える製造という仕事のプロセスの構造を、図に示すと次のようになる。
e0058447_12531915.jpg
図 製造という仕事のプロセスの構造

もっとも「工順」という言葉だって、作業の集合を指す場合と、単に一連作業の中の連番(数字)だけを指す場合があるから、曖昧性は残るのだが、「工程」よりは誤解が少ないだろうと考えて、こうしている。

なお、図の中には「リソース」(Resource=製造資源)という言葉が出てくる。これは、作業の間は占有するが、作業した後でも別の作業に再利用できるようなものを指す用語だ。具体的には、作業する人・機械設備・治工具・金型などが含まれる。つまり、機械とか作業者とかよりも、1レベル抽象度を上げた用語である。このリソースのリストのことを、「資源表」(BOR = Bill of Resource)と呼ぶこともある。

かくして、製造業には、大きく言っても4〜5種類の基準情報が必要であり、それをきちんと整備・保守していく仕事が生じることになる。こうした仕事は全て、「間接業務」=直接お金を生まない仕事である。だから、しばしば日陰の仕事、縁の下の力持ち的な業務とみなされ、不況の時は優先度が下げられたりもする。そして、そういう態度自体が、生産性の低下をもたらし、さらに不況を加速するというダウン・スパイラルが生じる。これは、企業の持つ思考と行動の習慣=OSがバグっている状態だ。

なぜ企業には基準情報が必要なのか? それは、情報・データを再利用可能な状態に保つためだ。さらにいえば、仕事を予見・計画可能な状態に保つために必要なのである。冒頭に紹介したように、たまに集まるおばさま達の集団なら、基準情報など無くても、なんとか料理はできる。いや、それこそ、「ちょっとカレーの味が薄いみたいだから、ここにある和風だしを入れちゃいましょ。」などという、臨機応変な小技(大技?)を繰り出すことだって、できたりする。だが、これを仕事にして食堂を開くなら、もう一歩上を目指す必要がある。きちんと計画できて、繰り返し可能な仕事の状態にするべきなのだ。部品表と工程表は、そのための武器なのである。


(本記事を書くきっかけとなったのは、OpenLearning(https://open.netlearning.co.jp)が提供する「応用情報学」講義シリーズの中の、京都情報大学院・上田治文教授による「企業経営の情報学」Wee 2・Lesson 3「工場のIT化の核 部品表のコンセプト」を見たことである。わたしの用語・見解とはいろいろ異なっているが、4種類のマスタの整理など、いろいろと学ぶべき良いヒントをいただいたことを記しておきたい)






by Tomoichi_Sato | 2017-03-22 12:56 | サプライチェーン | Comments(0)

お知らせ:納期遵守のための1日セミナー(11月25日・大阪)

来る11月25日(土)に、大阪府工業協会で納期遵守をテーマとした1日セミナー(有償)を行います。一昨年からはじめたセミナーもバージョンアップを重ね、今回で4回目の開催となります。

主に受注生産型の工場における納期遵守のための生産計画と統制(コントロール)について、製造業の実務家向けに、理論・事例と演習を含めてお話しします。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門 (図解でわかる生産の実務)」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視します。そのため、生産活動の仕組み全般を『システム』としてとらえ、その生産システムをより良く運用するにはどうしたらいいか、また仕組みをより上手に設計するためには何に留意したらいいか、を考える『システムズ・アプローチ』をとります(もちろん、ここでいうシステムとはコンピュータのことではありません)。

したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。普通の現場改善コンサルタントの講義に、飽き足りない気持ちでおられる技術者の皆さんのヒントになればと思っています。関心のある方のご来聴をお待ちしております。


<記>

日時: 2016年11月25日(金) 10:00-17:00

テーマ: 「納期遅れを起こさない 生産統制のポイント
     ~ 工程管理担当者の実務能力の強化 ~」

主催: 公益財団法人 大阪府工業協会

会場: 大阪府工業協会研修室
     大阪市中央区本町 4-2-5 本町セントラルビル
     (市営地下鉄御堂筋線「本町」駅8番出口すぐ)

セミナー詳細: 下記のPDFファイルをご参照ください(「受講申込書」も兼ねています)

by Tomoichi_Sato | 2016-10-27 22:41 | サプライチェーン | Comments(0)