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

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)

生産システムとは、どういう仕組みだろうか

法政大学の西岡教授といえば、現在、「つながる工場」のための緩やかな標準づくりで、日本版インダストリー4.0として注目を集めるコンソーシアム"Industrial Valuechain Initiative”(IVI)https://www.iv-i.org/を率いている方だ。その西岡教授は、日本機械学会の研究分科会報告の中で、世の中にあるシステムは、二種類に大別できる、という興味深いことを書いておられる。

「自動車や携帯電話など、人がその外側にいるシステムを第一種のシステムと呼び、人がシステムの内部にいて、その構成要素となっているものを第二種のシステムと呼ぶことにしましょう。はたらく作業者である“私”にとって、私は生産システムの一部であり、システムの内側にいます。これまで工学の世界では、第一種のシステムを多く手掛けてきました。その反面、第二種のシステムは、挙動が自然法則のみに依存せず、なかなか理論化で きません。」(http://www.jsme.or.jp/fad/sig/cm/N008_industrial_valuechain_initiative.pdf
P.3-4より、筆者が語順を一部改変して引用)

これは非常に卓見であると思う。わたしの知る限り、これまで、この二つのシステムを区別して論じた工学者はほとんどいなかった。第二種のシステムは、従来の科学法則のみに立脚したシステム工学だけでは、うまくいかない。より新しいアプローチが必要なのだ。

わたしは前回の記事で、「生産のマネジメントとは、生産の仕組み(システム)をつくり・活かし・進化させ、それによって働きがいを創出すること」だと書いた。では、『生産のシステム』とは、具体的には何をさすのか?

もちろん(くどいようだが)ここでいう「システム」とはコンピュータ・システムのことではない。人間をその要素として含む、第二種のシステムである。

そして(当たり前だが)生産システムは人工物である。どこからか造物主の手により忽然と現れた訳ではないし、自然に生じたものでもない。誰かが作ったものなのだ。作ったのは、一個人ではないかもしれない。繰り返し、多くの人の手で少しずつ進化し、改良されたかもしれない。だが、そこには人工物としての設計意図がなければいけない。

この『生産システム』、普通の言葉では「工場」に相当するといってもいい。ただし「工場」という語は、建物とか場所を意味する場合もあるし、あるいは企業組織内の一部門を意味する場合もある。また、購買とか生産技術とか受注センターは、本社にあったり工場から離れていたりすることもある。だから「工場」と、わたしのいう生産システムは、つねにイコールではない。

さて、人工物であるシステムを理解するには、その目的・機能・構造を見れば良い。目的とは、
(0) 最終的に何をめざし、何の役に立つのか、
ということだ。

システムの機能とは、具体的には以下の6点で代表される。
(1) 直接的に何をアウトプットするのか
(2) そのためのインプットは何か
(3) その動的特性はどうなっている(どうあってほしい)のか
(4) インプットや取り巻く環境とのインタフェースはどうなっているのか
(5) その制約条件は何か
(6) そして、その性能(目的関数)は何でどう測るのか

またシステムの構造とは、
(7) 何の要素から成り立っているのか
(8) 要素間はどのような形状(空間的配置)で接合し合っているのか
(9) 要素間はどのようなインタフェースでつなげられているのか
で表現できる。ちなみにシステムの構成要素もまたシステムである場合は、「サブシステム」と呼ばれる。

あるシステムが何か、という疑問は、上にあげた10個の質問に答えることで、ほぼ記述できる。

では、生産システムの目的に関する、質問(0)からいこう。生産システム自体の目的は、生産という行為を通じて、永続的に付加価値を生み出し続けることである。これを達成できなくなった場合、つまり付加価値を生めなくなったとき、あるいは付加価値は生むが一過性で、将来まで継続できないときは、その存在理由が疑われる。

生産システムの機能の根幹とは、「(1)需要情報というインプットを、(2)製品というモノ(あるいは製品に実現された付加価値)に変換してアウトプットすること」である。このことは、このサイトでもすでに何度か述べてきた。そのサイド・インプットとして、原料・部品 や、用役・副資材 などがある。
e0058447_22432239.jpg

(3)動的特性は、製品の種類や業態により、さまざまだ。それは一般に、「生産リードタイム」という言葉で代表される、需要変化への追尾特性をいう。(4)主要なインプット(需要情報)とのインタフェース方式によって、いわゆる「生産形態」が分類される。生産形態は教科書にある4種類、つまり
- ETO (Engineer to Order):受注設計生産
- MTO (Make to Order):繰返し受注生産
- ATO (Assemble to Order):受注組立生産
- MTS (Make to Stock):見込生産(「需要予測生産」ともよぶ)
および、
- 下請け型受注生産
の5つからなるが、複数製品でこれらが混在することもある。なお、最後の「下請け型受注生産」はわたしが名付けたもので、日本の部品製造業に多く見られる特殊形態だが、普通の教科書には載っていない(たぶん欧米には存在しない)ものだ。詳しくは「“JIT生産”を卒業するための本―トヨタの真似だけでは儲からない」第5章を見られたい。

生産システムの(5)制約条件として代表的なものは、「生産リソース」(つまり構成する人や製造機械類)を、すぐには増減できないことであろう。もちろん他に、資金的な制約もあるのが普通だし、それ以外にも労働基準法や環境規制などさまざまな法規制にしばられている。

生産システムの(6)目的関数(性能)については、すでに別のところで述べた(「システムとはいったい何を指すのか」http://brevis.exblog.jp/20878001/)。この話は奥が深いのでここでは詳述しない。

つぎは構造面だ。(7)構成要素(生産リソース)は以下のものから成り立っている:
- 働く人々(「組織」として構造化されている)
- ハードウェア(製造機械・物流設備・工具・金型・治具類)
- 建物(正確には、それによって作られる作業空間) →これは(8)空間的接合を主に決める

リソース間の(9)インタフェースでやりとりされる情報は、紙の伝票も電子データもあるが、これは指示系と実績系に分けられる(生産計画、製造実績など)。その中核には、「広義のBOMデータ」がある。広義のBOMとは、
- BOM(部品表)データ
- 品目データ
- 工順(工程表)データ
- 資源表
- BOQ(資源能力表)などなど
である。これらは、さらに、行き交う一過性のもの(トランザクション)と、繰り返し利用されるもの(マスタ)に分類される。とくにBOM・工順・BOQなどは、生産形態に応じて、マスタ化されている場合と、毎回、設計によってデベロップしていかなければならない場合がある。

わたしがこのような生産システムの全体像の認識にいたったのは、10年くらい前のことだったかと思う。キーポイントは、主要なインプットが「需要情報」であると気づいたことだった。というのは、わたしがエンジニアリング業界に入った頃は、いまだ高度成長期の工場観がずっと受け継がれていたからだ。それは、
「工場とは原材料をインプットとして、製品をアウトプットする仕組みである」
というものだった。今のわたしの認識との違いは、お分かりだろう。従来概念での主要なインプットは、「需要情報」ではなく「原材料」だったのだ。
e0058447_22505324.jpg

では、需要情報はどこにあるのか? もちろん、そんなものは、無くてもよかったのだ。高度成長期とは「モノは作れば売れる」時代だった。この時代の工場概念は、大量生産・薄利多売とワンセットだった。しかしバブル時代を経て、次第に世の中は成熟市場となり「モノあまり時代」になった。製品は必然的に多品種化し、気まぐれな顧客ニーズに合わせて生産しないと売れなくなった。つまり、主なインプットが交代したのだ。

こうした時代の変化にもかかわらず、生産システムの設計思想は、多くの企業で変わらぬままとなっている。そもそも、旧来の生産システム自体、誰かが意識してデザインしたものか、それとも、よその真似や「業界常識」でそうなったのか、よく分からぬ会社が少なくない。そして、海外に工場を建てるときも、無意識に「マザー工場」のあり方をコピーしていく。それでうまくいったら不思議である。

だから、「今こそエンジニアリング会社の出番です」、とはまあ、言うまい。ただせめて、工場のハードを更新したり建て増したりする際に、「生産システム」の設計の視点を、もっともってほしいと思う。わたしは工場見学が趣味の人間だが、あちこちで、あまりにも勿体ない事例を見てきた。もっとうまく設計し運用すれば、同じ費用でずっと付加価値の上がる工場になるのに、と感じるのだ。

それにしても(自分で書いていて思うのだが)、こんな抽象的な話、誰かの役に立つのだろうか? 生産管理のセミナーなどを聴きに来られる方は、ふつう、目の前の問題(ペイン)に悩む人ばかりだ。在庫過剰とか納期遅れとか。いや、赤字や売上不振など、もっと深刻な問題もあるはずだ。明日の米びつの心配が最優先だ、というのがふつうの感覚であろう。そんなとき、「生産システム」などという認識は、何かの役に立つのか?

それは、地球儀は何の役に立つのかという質問に似ている、と思う。地球儀は、町中で道に迷っている人に、直接は役に立たない。過去や未来をマクロに考えたい人に役立つだけだ。

あるいは、運転免許の講習に、自動車の構造説明なんて無用じゃないのか?という問いにも、似ている。ほとんどの受講者はきいていないし、きいても理解できないだろう。だが、考えてみてほしい。オイルは汚れ、タイヤの空気圧は低く、ラジエーターの水は足りないのに、ローギアのまま高速を走って、“この車は何で早く走らないんだろう?”と悩む運転手は、あなたの回りにいないだろうか? みな、毎日の運転でヘトヘトに忙しい。でも、その悩みは、すこしだけ「仕組み」の根本を理解することで、直せるのかもしれないのだ。

<関連エントリ>
 →「生産システム-その目的と機能は何か」 (2008-08-04)
 →「システムとはいったい何を指すのか」 (2013-08-01)
by Tomoichi_Sato | 2016-05-17 22:57 | サプライチェーン | Comments(0)

生産管理という仕事の目的は何か

以前、このサイトの読者の方から質問をいただいたことがある。「生産管理とはそもそもどういう仕事でしょうか?」という主旨だった。この方は製造現場から生産管理へ異動になった際に、仕事の全体像や目的をきちんと考えたく思い、本屋やネットを探して、わたしのサイトの「生産管理とはどういう仕事か」http://brevis.exblog.jp/7709373/ という記事にたどりついたのだそうだ。

上記の記事で、わたしは「生産管理とはあくまでサポーターであり雑用係といえる」と書いた。だが、この答えでは今ひとつ納得しきれない気持ちがあって、メールいただいたという次第だ。この記事は2008年4月、つまり今から8年も前に書いたものだが、いまだにそれなりのアクセス数がある。ということは、こうした問題を考えあぐねている人は、世の中にけっこう多いのだろう。

ただこの記事は、「サポーター、雑用係とはあんまりな言い方」というコメントも頂戴した。わたしは、プロジェクト・マネジメントの仕事は雑用の集積だ、などと考えている人間なので、『雑用』をムダだとか下層の仕事だという風には思っていない。むしろ一種の謙譲語として使っている。そうとらえることで、かえって仕事の本質、本来の目的が見えやすくなるのではないかと考えたのだ。だが、むろん雑用という言葉に引っかかり、ムッとされた方もいるだろう。自分の大切な仕事を雑用とは何だ、と。

でも、ちょっと考えてみてほしい。かりにあなたがジャズバンドのリーダーだったとする。仲間と一緒に音楽するのが純粋に楽しい。ところで、近々ライブを計画している。会場を手配し、曲目を決め、お知らせやチラシを作成して配り、必要ならゲストを呼んで、練習のためにスタジオも借りなければならないだろう。採算の心配もしなければならない。こうした面倒な仕事のほとんどは、リーダーであるあなたが采配する。そして、こうした仕事は、あなたや他のメンバーにとって、「雑用」に思える。なぜなら、あなた方にとって“本来の目的”は、楽器を演奏して音楽を楽しむことにあるのだから。

純粋に音楽を作ることにのみ心が向かう人にとって、それ以外の手配や環境作りは、雑用である。だから、バンドが成長し有名になったら、誰か「マネージャー」を雇って、そうした事は一切任してしまいたい。でもそれまではリーダーがまとめ、メンバーと分担して雑用を続けるしかない。ところで、雇われマネージャーにとって、会場手配や広報や会計などは、「本来の仕事」である。本人はもしかすると「雑用係です」と謙遜した言い方を、外部に向かってはするかもしれないが、その人自身にとっては、ちっとも雑用ではない。バンドに必要な、大事なことだからやっているのだ。

「製造部門」の仕事が音楽作りに相当するならば、いわゆる「生産管理部門」の業務は、雇われマネージャーの仕事に相当する。では、この雇われマネージャー、いいかえると生産管理の仕事の、目的・使命とは何なのか? それが今回の主題だ。

(ところで余談だが、最近、ノートルダム清心学園理事長でベストセラー『置かれた場所で咲きなさい』の著者・渡辺和子氏が講演の中で、
「この世の中に『雑用』というものはございません。わたし達が用を雑にしたとき、いい加減にしたとき、その用は『雑用』になります」
と発言されているのを知り、面白く思った。ちなみにこの方はカトリック修道会のシスターだが、この講演は鎌倉の禅宗の総本山の一つ円覚寺で行った夏期講座だったのが、また面白かった)

さて、生産マネジメントという仕事の目的は何か? この問題を考えるにあたって、まず言葉について整理しておきたい。わたしは「管理」と「マネジメント」という用語を、あえて区別して使っている。両者はイコールではない。日本語の「管理」に相当する英語は、Management、Control、Administrationの3つがあり、かなり別の領域をさしている。この英語の区別については以前も「マネジメントと管理はどこが違うか」http://brevis.exblog.jp/10625203/ に書いたのでここでは繰り返さない。

日本語の「管理」がまた、くせ者の言葉である。ビジネス社会で管理といえば、権限・権力・地位などを通常伴っている。ところが「生産管理」だけは、管理なのに地位・権力がない(まあ品質管理や在庫管理も同様だが)。もしも生産管理が“生産を管理すること”を意味するのならば、工場組織はピラミッドの一番下に製造部門がいて、その上に生産管理部門があり、そのトップはすなわち工場長である——ということになりそうだ。だが、そんな会社は見たことがない。

にもかかわらず、多くの会社では——ここが日本語および日本のビジネス文化の不思議なところだが——生産管理は「管理」だから“技術屋ではなく事務屋の仕事”とされ、しばしば文系の配属先となっている。そのことの是非はおくとしても、こうした事情がますます、問題を分かりにくくしている。だからここでは、あえて一番広義で、ハイレベルな(=抽象度の高い)言葉である「マネジメント」を使うことにする。一般に、問題を考える際には、より大きな視野から問題の位置づけをとらえる方が、局所的でおかしな習慣の枠にとらわれずにすむからだ。

で、そもそも生産のマネジメントの目的とは何なのか? わたしの答えは比較的シンプルである。それは、生産の『仕組み』(システム)を 、
1 生み出し 、
2 活かし 、
3 進化させる。 そして、
4 それによって働きがいを創出する
ことを使命としている。
e0058447_6542198.jpg

使命の中に「進化させる」ことが含まれているから、この使命は永続的で終わりがないことを示している。生産の仕組み(システム)とは、生産のための機械設備や、働く人々や、そのための空間(建屋)や、情報・データをやりとりする手順全てを含んでいる。なお、「システム」という言葉を使ったが、これはコンピュータとは直接関係がない。すべて紙と帳票で動かしていたって、それが『仕組み』である以上はシステムと呼べる。

いやいや、ちょっと待ってくれよ、と読者は思われるかもしれない。生産の仕組みを生み出す、つまり製造ラインを設計したり設置したりするのは、「生産技術部門」の仕事ではないか。“活かす”の部分の主役は、「製造部門」ではないか。だって彼らが製造機械を動かしているのだ。そして“進化させる”となると、たとえば「保全部門」「品質管理部門」の仕事もからむし、まして“働きがいの創出”なんて、経営者の仕事じゃないか!

そうかもしれない。だが、繰り返すが、上に述べたのは、もっとも広義でハイレベルな、『生産のマネジメント』のめざす目的、使命である。この中には、工場長がやるべきことから、現場の一担当者がやるべき事まで、すべて含まれている。そして個別の企業の生産技術・生産管理・資材購買・加工・製造・品管・保全・物流・・といった縦割り組織が、本当にこのような目的にふさわしい分業形態と目標設定になっているかどうかは、別問題である。

また、“活かす”という言葉にも注意してほしい。製造部門が機械を動かしているからといって、それを“活かし”ているとは、必ずしも言えない。もしかりにポルシェを町内の宅配便につかったら、ポルシェを動かしてはいるが、活かしていることになるだろうか? かりにもし製造部門が高機能な連続鋳造装置をフル稼働させて、その結果、使いもしない素材の在庫の山を築いたら、それは活かすことになるのか? それを生産管理部門が止める事の方が、活かすことになるのではないか。ある仕組みを、より価値の高い使い方に仕向けることこそ、“活かす”の意味なのである。

普通の工場における、いわゆる「生産管理部門」の中心的な仕事とは、計画・スケジュールの立案、作業の手配指示、進捗確認、そして問題発生時の対応などであろう。区別のため、これを狭義の「生産管理」と呼ぶことにする。ではなぜ、このような種類の仕事が必要なのか?

すべて一人でやる職人の工房には、「生産管理」はいらない。頑固親父が一人でやっている和菓子屋を想像してほしい。 材料の手配も、製造も、来客の注文さばきも、みな一人でやって、できている。

狭義の生産管理が要るのは、生産のスケールが大きくなって、分業が発生するためなのだ。一日に千人のお客が来る大店(おおだな)の御菓子司は、一人ではさばけない。売り子と作り手の分業、仕入れと仕込みと配達の分業、などが生じてくる。つまり店という「システム」になったのだ。かくして、販売(注文)と生産のすり合わせ 、製造と資材(購買)のすり合わせ、品質検査と出荷のすり合わせ・・・こうした調整が必要になる。 いいかえると、情報の交通整理である。こうした交通整理が、いわゆる狭義の生産管理の本質なのだ。

近代的な生産の仕組みにおいては、必ず「指示」と「報告」が行き合う。生産指示に対して、生産実績の報告が上がり、資材購買指示(発注)に対しては、納品書(納入報告)が上がる。こうした指示と報告情報のハブとして、全体の管制塔となること。それによって人や機械などの生産の仕組み・システムを「活かす」こと。 つまり、最小のインプットで最大の付加価値(スループット)を得られるようにすること。ただしそのことが労働条件の過酷化を招いて、「働きがいを創出する」障害とならないようにすること。効率の最大化だけに着目して、変化に適応し「進化する」ゆとりを無くさないようにすること。こうしたことが生産管理の仕事である。

これほどまでに大事な役割であるにもかかわらず、「生産管理」が余計な間接業務、事務作業だと思われているケースをときおり見かけるのは、なぜだろうか? たぶん、組織がどこかで目的意識や価値観を見失っているのだ。まるで売り子や配達の仕事をバカにして、「俺の菓子作りの腕があるからこの店があるんだ」とうそぶく職人のように。

まあ、世の中にはどんなに丁寧に説明しても、自分の抱えた仕事だけが偉くて、他はくだらぬと信じる手合いが一定数いる。彼らは自分がシステムの一員であることを知らない。大店全体がシステムとして機能し利益を出すから、職人も安心して腕をふるえるのである。システムでは、すべての要素がちゃんと機能して、はじめて全体が価値を生み出す。だから、要素間でどれが偉いの偉くないのという議論は、無意味なのだ。たとえどこかの要素(部門)が情報のハブとなり、そこが指示を出ししていても、それは「そうした役割」をおっているだけで、上下関係ではなない。たしかに生産管理は製造作業を直接する訳ではないから間接業務だが、大切な業務である。「大事な雑用」が、世の中にはあるのだ。

ものづくりをテーマとした展示会やサイトなどでも、取り上げられるテーマの中心は、製品の設計技術や、製造機械の生産技術・検査技術などであり、生産管理を真っ正面から取り上げたものは少ない。わたしは、このことを大変残念に思っている。それは生産管理が、生産システムの情報のハブである事を、多くの企業も技術者も認識していないことを示しているからだ。要素技術ばかりに熱中し、全体のシステムを見ないビジネス文化に、わたしは危惧を抱いている。ちょうど楽器をいじることのみに熱中し、それ以外はすべて「雑用」と貶めるジャズバンドのメンバー達のように。それは、「システムズ・アプローチ」の弱さを示しているのだろう。

最初の質問を寄せられた方には、こうお答えした:
「『そもそも生産管理とは何か』という問いを立てられたところがまず、素晴らしいと思います。“そもそも論”を考えようとする人は、少数です。100人中98人は、目の前の仕事や直接の成果だけを考えているのが現実です。これでどうして改善やら改革が可能でしょうか?
わたしのサイトは、『そもそも論』を自分の頭で考える人(=システムズ・アプローチの素質がある人)に役立つサイトを目指しています。」

そして、生産システムのマネジメント理解する糸口として、共著の「“JIT生産”を卒業するための本―トヨタの真似だけでは儲からない」をおすすめした。この本の第5章は、わたしが書いている。べつに(信じてもらえないかもしれないが)自著の宣伝のためにおすすめしたのではない。こういうアプローチで生産管理を論じた本が、滅多にないからなのだ。生産管理の仕事は、カンバン方式だとかMRPだとかのツール・手法の集合ではない。生産というシステム全体を見て舵取りをする、航海士やパイロットのように高度な技術専門職であることを、一人でも多くの人に知ってもらいたいからである。

<関連エントリ>
 →「生産管理とはどういう仕事か」(2008-04-09)
 →「マネジメントと管理はどこが違うか」(2009-07-15)
by Tomoichi_Sato | 2016-05-11 07:00 | サプライチェーン | Comments(0)

同じモノか、違うモノか? - マテリアルの同一性問題をめぐって

前回、「E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える」 を書いた後で、この分野の専門家の方々と少しやりとりがあり、わたしのつかったBOMという言葉に分かりにくい点があったかな、と気づかされた。そこで今回は補遺として、用語を明確にすることからはじめたい。

一般に、『BOM』という言葉は、三つの意味を持っている。それは「BOMデータ」「BOMデータベース」「BOMソフトウェア」だ。同じ一つの問題の、三つの側面といってもいい。

BOMデータとは、部品表(業界によっては「材料表」)の内容そのものである。データというのは、数字や文字の規格化・定型化された並びのことである。BOMデータとは、マテリアルの数量的な関係を示した一覧表で、たとえそれが手書きでも、Excelの表の形でも、きちんと業務でハンドリング可能な形になっていたら、BOMデータと呼べる。ただし、誰かの頭の中にあるだけで、形式化されていない状態では、まだデータとはいえない。(なお、データと情報の違いについては『ITって、何?』の「質問2: ITを理解している人を見分けるにはどうしたらいいの?」 を参照のこと)

BOMデータベース」とは、コンピュータの中に形式化されて保存されているデータを指す。データベースは、ご承知の通りマスタ・データと履歴(トランザクション)データに、さらに区分することもできる。BOMデータベースは、その両者の形態があり得る。

BOMソフトウェア」とは、主に上記BOMデータベースを処理する情報システムのことだ。製造業ではBOMはいろいろな業務に関係するから(設計・購買・製造・保守・原価など)、いろいろな業務系システムがBOMソフトウェアとなり得る。とくに、BOMデータベースの維持管理を主目的としたソフトウェアをつくる場合、それは「BOMプロセッサ」と呼んで区別することにしている。

このサイトでは今後、上記の三つを、可能な限り区別して使うことにする。たとえば前回「どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない」と書いた。これは、より正確には、次の意味である:
どんな製造業にもBOMデータはある。だがBOMデータをマネジメントしている会社は少ない。

たとえば、製品を自前で製造している会社なら、ふつうは必ずP-BOM(購買部品表)データをもっている。これがなければ部品材料を仕入れられないからだ。もしもその会社が、よくセットメーカーにあるように、部品は全て外部から購入し自社では最終組立・検査のみを行う業態の場合、
 P-BOMデータ=M-BOMデータ
でもある。自社内で加工・製造を行う業態の場合、工程ごとに展開されたM-BOMデータをもっているはずである。そうでなければ、各工程に製造指図書(製造オーダー)を発行できないからだ。ただし、その企業が構造型の「BOMデータベース」を持っているかどうかは不明だが。

また、設計機能のある会社なら、必ずE-BOMデータはある。それは組立図面の上のたんなる表かもしれないが、データではある。

(小うるさいことを書くようだが、念のために注釈。製造業の裾野は非常に幅広い。製品を自前で生産しないメーカーというのも存在する。製造を全て外部委託している会社だ。具体的には、一部の電子機械メーカー、開発型医薬品メーカー、そして多くのアパレルメーカーなど。出版社もこれに近い。また、自社で設計をしない製造業は、中小下請け部品メーカーに非常に多い。それから、化学・食品産業などではBOMという言葉はあまり使わず、「レシピ」概念がそのかわりにある。ただ、混乱を避けるため、わたしの話はデフォルトで「組立加工型・繰返し生産形態・生産管理中心」で書いている。日本ではそういう企業の裾野が一番広いからだ。読者諸賢は、ご自分の業種業態にあった形で翻案しながら、お読みいただきたい)

さて、BOMデータをきちんとマネージするためには、普通はBOMデータベースが必要だ。他方、上述のようにBOMソフトウェアは業務目的別に複数持つ場合もある。たとえば設計業務用ソフトと、生産管理用ソフトのように。もちろん両者が一つのソフトウェアで済むなら、それに越したことはない訳だが、現実にはなかなか難しい。そういう意味で、E-BOMソフトウェアとM-BOMソフトウェアが別々にあるケースは珍しくない。同一のBOMデータベースから、異なる表現形式としてE-BOMとM-BOMを取り出す例もあるだろうが、あるいは物理的に別々なDBかもしれない。

では、わたしが前回述べた、「E-BOMとM-BOMの乖離問題」とは何のことなのか? それは、データ内容の乖離の話である。設計部門と生産部門が維持・参照しているBOMデータの中身が、だんだんと食い違ってくる。それが社内で様々な問題を引き起こしているのである。たとえばユーザからクレームが入った。保守部門が対応すべくアクションを起こす。ところが調べてみると、設計図面とは別の部品が使われている。あるいは、工場内で部品の欠品が起きる。本社資材部門は正しく手配済みのはずだった。だが工場では当該部品とは別の部品を使用することが恒常化していた・・。こうした不便がいろいろと起こりうるのだ。

そしてBOMデータ内容の中心は、マテリアル・コードである。マテリアル・コードとは部品材料を特定するキー・コードのことで、会社によっては部品番号とか品目コードとよぶ場合もあるだろう。ある部品のマテリアル・コードは何か、その子部品のコードは何か、がBOMデータの中心部分である。BOMデータの乖離とは、同じ製品を構成するはずのマテリアル・コードが、設計部門と生産部門で次第に食い違っていく事態を意味する。甚だしい場合は、両者でまったく異なるコード体系をもっている。まあ、仮に異なるコード体系であっても、その間に1対1の対応関係があるなら、まだいい。その対応関係が次第にずれて1対NやN対Nになっていき、機械的な変換ができなくなるから、こまるのだ。

なぜそのような乖離が起きるのか? それは、異なる部門間で、ある品目が同一であるか、違うモノかで意見が異なってしまうからなのだ。

例を挙げよう。ここに、「岩手産の牛乳1ℓ瓶」と、「十勝産の牛乳2ℓパック」 があったとする。この両者は、同じモノなのか、違うモノなのか?

仮にあなたが、ある食品メーカーで、マテリアル・マスタの管理者だったとする。お好みなら、SAPのMMかなんかでもいい。そこにユーザから、上のような質問があった。どう判断するべきだろうか?

見た目に明らかに違う物品だから、別のコードで登録すべきだ、などと結論にジャンプしてはいけない。慎重なあなたは、ためしに、社内の関係者に質問してみることにした。

あなたの会社にはチーズ製造部門がある。そこの購買課に見解をたずねると、こう答えた。
「乳脂肪含有率が重要だ。産地が違えば区別が必要だ。いや、季節によっても品質は変動する」。
一方、あなたの会社はレストランもチェーン経営している。そこの仕入係の見解はこうだ:
「コップに注いでしまえば産地も容器も関係ない。要冷蔵かどうかだけが重要だ。」

片方は別のモノだと答え、もう一方は区別の必要はない、という。

二つのものが同一物かどうかは、会社によって違い、部署によっても違う。つまり、ものの見方によって違うのだ。そこには、第三者が客観的に決められる厳密な基準はない。では、『モノの見方』を規定するカギは何なのか?

こたえは単純だ。同一と見なせるかどうかは、「キーとなる属性」が同一かどうかで決まるのだ。キーとなる属性とは、業務上の要求仕様のことであり、マテリアルの使用目的によって決まる。チーズ製造部門にとってキーとなるのは乳脂肪含有率であり、レストランにとっては保管方法だった。だから、使用する企業・部署ごとに見方は変わるのである。どちらが正しい、どちらが間違っている、ではない。ただし、企業として統一したマスタを持つのなら、そこには基準が必要だ。そして、それは区分がむやみに増殖しないような基準であってほしい。

たとえば、「設計上は同じ仕様だが、サプライヤーが異なる物品」はどう扱うべきか? もしも製造組立でまったく互換性がある場合は、両者は同一のモノである。 でも、価格や納期が異なるとしたら? その場合、サプライヤーに依存する属性は、品目マスタではなく、「購買情報マスタ」に登録するのが定石なのだ( 「購買情報マスタ」は、マテリアル・コードと取引先コードを複合キーとするマスタである)。

あるいは、「設計上は同じ仕様だが、荷姿や入り数や保管方法が異なる物品」は?  その場合、物流側の情報システムで、SKU(Stock Keeping Unit)として区別するのが定石だ。

そのような形の工夫を重ねることで、マテリアル・マスタの品目数がずるずると膨張し、類似したデータが増えて1対N風の状態になることを防ぐことこそ、BOMデータをマネジメントする際の要諦なのである。

わたしの接してきた経験では、残念ながら多くの企業が、このような判断基準を社内的に確立していない。そもそも購買情報マスタだとかSKUだとかいうことさえ、理解されていない。こうした事情の背景には、部門同士の距離感があるのだろうと感じる。各部門がサイロのようになって、部門単位で最適化された業務フローを持ち、それに応じて情報システムを作ってしまう。結果として、本社設計部門の管理する部品マスタと、工場の製造部門のつかう品目マスタの対応関係が、乖離してくるのである。これを称して、E-BOMデータとM-BOMデータの乖離という。

これを防ぐためにはどうしたらよいか? 原因が単純である以上、解決法も単純だ。社内の複数部門を横断する「マテリアル・マネジメントのためのコミッティー」を形成し、そこで基本指針を定め、各種情報システムの要件にも口をはさむ。個別の事案の判定は、実務担当チームを任命してあたらせる。このようにすべきだろう。

拙著「BOM/部品表入門」では、社内の10以上の部門が横断的に集まるBOM検討ワークショップによばれた、外部アドバイザーの矢口先生が、各部門の担当者に順番に質問を発していくという形式で書いた。それは、上に述べたような問題意識があったからだ。マテリアル・マネジメントは、非常に多くの部門にまたがる課題である。だから、部門の垣根を越えて話し合う仕組みがどうしても必要なのだ。

単純だ。だが、難しい。単純なことほど実現の難しいのが、会社というものだろう。そしてそのために、マネジメントという機能が存在するのである。


<関連エントリ>
 →「E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える」(2016-02-21)
 →「『ITって、何?』質問2: ITを理解している人を見分けるにはどうしたらいいの?」 (2010-10-07)
by Tomoichi_Sato | 2016-02-28 15:56 | サプライチェーン | Comments(1)

E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える

拙著「BOM/部品表入門」(日本能率協会マネジメントセンター・刊)が、再び増刷になった。おかげさまで、累計8,900部である。本書は2005年1月の発刊だから、11年間にわたり現役のビジネス書ということになる。読者の皆様にあらためて感謝もうしあげたい。

ところで、この11年間、BOMをめぐる状況は変わったのだろうか?

正直に言うと、あまり大きくは進展していない印象である。相変わらず、いまだに多くの企業がBOMについて悩んでいる。いや、むしろ悩みは深まっているとさえ、いえよう。海外生産の進行やアジア市場への販売展開などで、サプライチェーンが海外まで確実に広がった。しかし、その現実にBOMの方がついていけていない。むしろBOMが、生産のグローバル展開の足かせにさえなっているようだ。

それだけではない。どうやら、BOMに関する基本的な認識さえ、まだあまり進んでいない気がする。たとえば、“ウチの会社にはまだ「BOM」がありません”、などと、かなりの大企業でも口にする。

BOMはBill of Material、すなわち部品表である。部品表のない製造業など、存在し得ない。部品表がなければ材料を調達できない。どうやって材料なしで製造するのか? 部品表がなければ材料費も計算できない。どうやって販売価格を見積もるのか?(個人営業の飲食店や職人の工房ならいざしらず)

こうした発言をきくと、世の中では、BOMを何か特殊なデータベースみたいなものだと、誤解しているらしい。BOMは製造業の中核データである。どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない。だから小著が11年間も現役で読まれ続けているのだろう。

かつてこのサイトで、「生産革新のためのBOM(部品表)再構築入門(2)」として、<設計部品表(E-BOM)と製造部品表(M-BOM)の乖離>問題をとりあげた。今回は、このテーマについて再度論じてみようと思う。これもひどく誤解の多いテーマだと感じるからだ。

乖離どころか、世の中には、「会社はE-BOMとM-BOMを二つ持つ必要がある」と信じ込んでいる人たちまでいる。「ウチの会社はいまM-BOMしかなくて、これからE-BOMを作らなくちゃなりません。」などとおっしゃる。冗談抜きで、きいて思わず頭がクラクラしてしまった。BOMが一つで済むなら、それで十分なのに。

上の記事では、設計部品表(E-BOM)と製造部品表(M-BOM)の乖離が生じる理由として、
(1)品目コードの不統一
(2)代替部品の使用
(3)副資材や包装材料の追加
(4)設計変更の発生と在庫切替タイミングの食い違い
の4つをあげた。このE-BOM, M-BOMの分断の背景には、設計部門(本社)と製造部門(工場)の組織的乖離が遠因にある。

もともと現代的なBOM概念、つまりストラクチャー(構造型)BOMの概念は1960年代にあらわれた。この概念はMRPという生産管理手法と一緒に確立された。つまり製造を強く意識したもの、今でいうM-BOMに相当するものである。

ではE-BOMの原型は、というと、機械組立図における材料表にさかのぼる。組立図には部品それぞれに引き出し線と、丸で囲った①②などの数字(俗に「風船」とよばれる)がついており、かつその図面の端っこに表が書いてあって、そこに①の品名と数量、②の品名と数量・・が並んでいる、あれである。製品を最終的に組み立てるにあたって、必要な部品の種類と名前と数量、位置を記した表だ。昔はB/Mと表記されることが多かった(今でもエンジ業界はB/Mとよんでいる)。これは親と子が一階層だけの、フラットなサマリー型が普通だ。

さて。会社組織では、誰が(どの部署が)BOMを登録、維持するのか? という問いが、しばしばついて回る。たとえば今、図のような製品があったとしよう。
(1) 製品SはアッシーXと部品A, Bとからなり
(2) アッシーXはサブアッシーYと部品Cからなる
(3) 部品Bは材料dを切削、研磨し表面加工したものである

e0058447_17582896.jpg

          <BOM(M-BOM)の全体像>

当然だれかが、製品S→アッシーX、アッシーX→サブアッシーY、部品B→材料d、という紐づけをBOMマスタに登録していかなければならない。なお、「アッシー」というのはAssemblyの略で、途中まで組み上がったアセンブリー(モジュール)のことを指す。

ところで当たり前だが、製造業では製品開発→量産準備→生産、という順序で仕事が進む。製品、アッシー、子部品は設計部門が図面を書く。製品やアッシーの組立図面には、品番の親子関係の表がついているだろう。つまりE-BOMが先に生まれる。製品S→アッシーX、アッシーX→サブアッシーY、はそれぞれ製品S・アッシーXの組立図に付随した「E-BOM」情報である。

別の言い方をすると、BOMの親子関係のうち、上位の階層は設計部門が定義する訳だ。

しかし、たとえば購入部品(汎用部品やボルト・ナット等)や、材料(たとえば丸棒)などは通常、図面は書かない。つまり、E-BOMの親子関係は途中で途切れてしまう。その先、外部購入品までの親子関係を定義するのは、工程設計を担当する部門(普通は生産技術)の仕事だろう。つまり、E-BOMは製造側の技術部門によって展開され、肉付けされることで、M-BOMとして完成するのだ。
e0058447_1805874.jpg


ところで、たとえば上記の例で材料dから部品Bまでは、切削→研磨→表面加工と複数の工程が必要だったとしよう。では、その間の中間状態の部品はすべてBOMに登録すべきなのか? 切削後段階の部品d'、切削研磨後の段階の部品D、そして切削・研磨・表面加工後の部品B、という風に。

答えはNOだ。

じつは、BOMに登録すべき品目には原則があるのだ。BOMに(いいかえればマテリアル・マスタに)登録するすべき品目とは、在庫管理の対象となるマテリアルである。

もしも、切削→研磨→表面加工がつねに一貫した工程なら、途中段階の品目登録は不要である。途中段階の品目は一時的に出現しても、すぐに次工程に消費されてしまうからだ。だが、材料dを切削→研磨した後、用途別にいろいろな表面加工で品種が別れたりする場合には、研磨後の中間部品Dをいったん保管したくなるだろう。ならば、中間部品DをBOMに登録するべきである。

こうした製造工程上の都合は、設計部門では分からないのが普通だ。だからBOMの定義も、生産技術や製造部門の判断になる。

業務系の情報システムでは、データの作成者がそのデータの登録者となり、オーナーシップをもって管理すべきだと一般に信じられている。この原則にしたがえば、BOMのマスタデータの登録作業は、複数部門によって分担されることになる。もっとも、情報源(作成者)と、マスタへの登録者を誰にすべきかは別問題という考え方もある。だから設計部門からのデータを生産技術部門が受けて、BOM全体の登録は生産技術がまとめて担当する、という取り決めだって可能ではある。

ただし、ここに一つの問題が生じる。多くの企業では、製品開発・設計部門が本社にあり、生産技術・製造部門が工場に所属する。場所が離れているのだ。両者は、別々の情報システムを使っていることが多い。サーバもデータベースも、物理的に別である。

こういうケースではどうしたらいいのか? E-BOMとM-BOMは統合不可能なのか?

答えは、単純だ。システムは物理的に別々でも良い。しかし、同じマテリアルは同じコードでよばれなければいけない。これが「BOM統合の原則」である。本社と工場が、同じモノを別々のコードでよんだり、モノの同一性について意見が分かれたりする状態があってはいけない。同じマテリアルの親も、同一でなければならない(そうでなければ構成管理の一貫性が崩れてしまう)。

このような形で、複数のシステム間のマスタデータ整合性が担保されているなら、BOMは統合されているといっていい。少なくとも、E-BOMとM-BOMの乖離問題は起きていない。

ちなみに設計用CADシステムの発達により、図面管理や構成管理など、設計用ツールにはPDM(Product Data Management)的機能が増えている。設計部門はその中で、「E-BOM」を管理維持したいと考えるだろう。部品共通化や設計情報の再利用などをはかりたい、とも望むだろう。それは当然である。しかし、E-BOMに登録される品目コードは全社共通のものを使うべし、が原則だ。

ただし、この話を推し進めていくと、異なる部門間で、モノの同一性について意見がくい違い、論争が生じるケースが出てくる。設計部門は、「これは内径X、外径Yの○○部品じゃないか」といい、製造部門は「いや、同じ形状の○○部品といっても、材質強度的に区別が必要なものが2種類あるんですよ」とか「仕入れ先が3社あって区別したいんです」とかいう要望が出てくる。この種の論争をどう解決するかが、じつはBOM統合にとって大切なのだ。だが、ちょっと長くなりすぎたので、この問題は項を改めて論じよう。


<関連エントリ>
 →「生産革新のためのBOM(部品表)再構築入門(2)」(2013-11-10)
by Tomoichi_Sato | 2016-02-21 18:12 | サプライチェーン | Comments(0)

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

3月に、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います(有料です)。

わたしは長年、エンジニアリング会社で国内外の工場・プラント作りに関わってきました。また、それなりに数多くの工場も見てきましたが、しばしば疑問を感じるケースがありました。「なぜ、こんな所に在庫を持つのだろう?」「ここを工夫すれば、もっと効率よく、かつ楽に仕事ができるはずなのに」「どうしていらないモノはたくさんあるのに、必要なモノは欠品しがちなのか?」

それは端的に言うと、生産活動の仕組み=『生産システム』の基本デザインに問題があるからです。生産活動のシステム・エンジニアリングが欠けているのです。むろん、ここで言うシステムとは、コンピュータのことではありません。情報系も一要素ですが、むしろ働く人々と、機械設備と、それを包む建築空間のことをいっています。その生産システムは、さらに自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば役に立たないのです。

このサイトに何年か前、「あなたの会社にトヨタ生産方式が向かない五つの理由」という記事を書いたのは、そうしたことを訴えたかったからです。さらに、これをふくらませた形で、中小企業診断士仲間との共著「“JIT生産”を卒業するための本」第5章に、生産システムの考え方を詳しく説明しました。この講演を引き受けたのは、これをより多くの方に直接、お伝えしたかったからです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理・原則に関する体系的な理解を重視しています。そのため、生産システムをより良く運用するにはどうしたらいいか、より上手に設計するためには何に留意したらいいを考える『システムズ・アプローチ』をとります。したがって業種分野については、わりと間口を広くとってお話しできる点が特徴です。年1回行っているこの講演も5回目になりますが、今年はさらにバージョンアップしてお届けするつもりです。

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

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

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

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

セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)
     http://www.j-techno.co.jp/seminar/ID54JQV6P41

関心のある大勢の方のご来聴をお待ちしております。
by Tomoichi_Sato | 2016-01-27 23:51 | サプライチェーン | Comments(0)

すべての製造業は受注生産かつ見込生産である

そんなバカな、なんだこの記事のタイトルは? と疑った、そこの貴方。はい、このエントリは、そんな貴方のためのものです。そもそも生産形態は見込生産と受注生産に分けられ、受注生産はさらに個別受注・繰返受注・受注組立生産などのバリエーションに分類される、というのが生産管理の教科書に書いてある常識ではないか! と思った、意識の高い方。貴方のような方が、日本の製造業を支えておられると思います。というのも、わたし達の社会で製造業に携わっている人はざっと1000万人くらいいるはずですが、自社の生産形態が何であるか、それが自社の競争力にどうつながっているかさえ、考えてみたことのない方が大半だからです。

・・と、「ですます調」ではじめてしまったが、ここから先はいつもの「である調」に戻させていただく(笑)。ですます調も好きなんですけどね、まあ、他のエントリとのバランス関係上。

バランス感覚は、いつでも大切である。製造業のよって立つ『生産システム』は、巨大で複雑なシステムだ。それを何か極端な理念で強引に動かそうとすると、見えないところに歪みが生じる。そしてその歪みは、たいてい、「在庫増」とか「欠品」だとか、あるいは「労働安全の低下」「離職率」みたいな現象につながっていく。

さて、在庫について考えてみたい。在庫とは何か。在庫にも、何か機能があるから、世の中に存在しているはずである。

かつてのアメリカの生産管理論では、在庫の主たる機能を分離(De-coupling)だとみた。在庫を挟んで機能が分離する。例えば、製品在庫を挟んで、製造と販売が機能分離する。あるいは原料在庫を挟んで、資材購買と部品加工が分離する。分離することによって、それぞれの機能が独立に動くことができるようになる。

そこで、工場の中の各工程を、複数の中間の在庫ポイントによって切り離し、それぞれの工程の効率化を追求する。また在庫のレベルについても、安全在庫と経済的ロットサイズの公式によって、最適化する。こうして、理想的な工場ができあがるはずである。

システムを個々の機能的要素に分解し、それぞれの要素を徹底的に効率化する。これはいかにもアメリカ的な、システムズ・アプローチである。そして全体は、スーパーマン的なリーダーが指示決定を行う。リーダーが全体を統合し、後の大勢の人間はリーダーに従うのだ。

複数置かれている在庫ポイントの中で、ちょうど顧客の注文に対応する工程が始まる出発点を、Customer-order decoupling point(略してCODP)と呼ぶ。それが完全な製品在庫だったら、見込生産(MTS)と呼ばれる。それがサブアッセンブリー化された中間部品であって、顧客の注文オーダーに応じて組み立てられ出荷されるならば、受注組立生産(ATO)と呼ばれる。

それが単純な部品材料で、顧客の注文と同時にそれらを加工し組み立て検査出荷するのであれば、繰返し受注生産(MTO)である。もしそのような在庫ポイントが社内になければ、それは受注設計生産(ETO)を行っているのである。このようにCODPの位置によって、その企業の生産形態を分類できるというわけだ。

さて、話は例によって、急に飛ぶ(いつもすみません)。

関東風の鰻の蒲焼きは、まず鰻をさばいて背側から二枚におろし、串を売って、白蒸しにする。その後で、こんどはタレにつけて炭火で焼く。所要時間はだいたい、30〜40分だ。だから関東でちゃんとした格式の鰻屋に入ったら、注文してから出てくるまで、かなり待たされる。お客の顔を見てから鰻を割く、というのが原則だからだ。完全なる注文生産である。客はその間、つまみで酒か何かを飲みながら、ゆっくり待つことになる。

しかし金と暇のある旦那衆はいざしらず、庶民の我々はもう少し、ご用とお急ぎの衆である。そこで格式よりも市場のボリュームゾーンのニーズを重視する町中の鰻屋さんは、もう少し略式の方法を生み出した。略式といっても、蒲焼きの作業の手順に変更はない。違いは、お客の注文をきいてから鰻をさばくのではなく、先にさばいて白蒸しにして置いておくのである。

そして注文を受けたら、タレをつけて焼くだけにする。こうすると、発注から納品までのリードタイムは劇的に短縮されて、まあ10分以内になる。そのかわり、蒸してからしばらく置いておくため、若干だが鰻の風味と歯ごたえが損なわれる・・といわれている。わたしは目隠しをされて食べ比べたら、違いを言い当てる自信はない。が、分かる人もいるのだろう。

私はこの鰻屋の話が好きなので、在庫ポイントの説明によく使う。

ところで(また話は元に戻るのだが)、日本の製造業は在庫の極小化を目指した。工場内のあちこちから、中間在庫のストックを取り去った。と言う事は、つまり工程同士を直接つなげると言うことだ。すなわち工場内を、粗結合から密結合に変えるということだ。

密結合なシステムとは、湘南新宿ラインのようなものだと以前も書いた。どこか1カ所で障害が起きると、全体のラインが止まってしまう。すなわち、在庫削減とは、トラブルを表に出すという事とワンセットなのである。いや、むしろ「潜在的な問題点を顕在化して改善すること」が主目的だと言っていい。この目的を抜きにして、各工程の担当者がトラブルを表に出さないよう、何とか隠して押さえ込むようでは、在庫ゼロ目標はむしろ無意味である。

在庫削減が徹底化された工場では、それぞれの工程の担当者が、自律的に判断して動く必要がある。そこにスーパーリーダーは不要である。

ただしそれでも、最低箇所は在庫が必要になる点が存在する。それは、
 顧客の要求納期 < 供給可能なリードタイム
となる点だ。

先程の鰻屋のたとえを思い出してほしい。30分も40分も待っていられない気短な一般客に対して、新しい鰻屋は、白蒸しにした鰻をストックすることで対応した。いや、昔風の鰻屋だって、さすがに飯は炊いていたし、うなぎだって仕入れていた。そうでなければ40分以内には出すことができない。炊いたご飯や、生け簀の中のうなぎは、やはり在庫ポイントなのである。

元・日立製作所で、現・早稲田大学教授の光國光七郎氏は、これを「カップリング・ポイント」と命名した。カップリングとは連結点である。先程の米国のDe-coupling (分離)点とは意味が逆になる点に注意してほしい。カップリング・ポイントは一つの品目(部品)では1点だけ存在する。それ以外の部分は極力在庫をへらし、リーン生産にする。

カップリング・ポイントは、顧客の受注オーダーを受け取る点でもある(その意味ではCODPと同じだ)。図を見て欲しい。そこより下流側は確定受注に紐付いた生産になる。そして上流側は、需要予測に基づいた生産になる。つまり、すべての製造業は、上流側の見込み生産と、下流側の受注生産がカップリング・ポイントによって連結されているのである。
e0058447_23323977.gif

わたしは、たまに頼まれて人前で生産管理の話をすることがあるが、そのときは必ず、このカップリング・ポイントの説明をする。さらに、自社のカップリング・ポイントの位置を、どこに置くべきか考える練習を入れることにしている。製造業のたいていの人は、そう問われて初めて、さて自社の在庫ポイントはどこにあるべきなのかを考え始める。そしてそれが、自社の競争力(納期は明らかに競争力の一因子だ)とどうつながっているについて、初めて頭を巡らすことになる。現実には多くの場合、まあまあ適切な位置にカップリングポイントがあるのだが、それでも成り行きで決まるのと、自分で意図して決めるのでは天と地ほども違う

特に光國氏の卓見は、輸送中の在庫も「有効在庫」にカウントしたことであろう。これはグローバルなSCMでは必須の条件である。前回までも述べたとおり、海外生産して輸送すると1ヶ月近くは船上に在庫を持つことになるからだ。ちなみに光國氏は、カップリング・ポイントより上流側では、小刻みな在庫補充生産をすることを推奨している。これには十分な理論的根拠があるのだが、それでも季節性の強い商品の場合等は、別の考慮が必要であろう。

さて、ここまでの話が理解できたら、ようやく受注生産における生産計画の手法論に入ることができる。

そもそも計画作業の基本とは、先々のことについては大ぶりな計画の線を引いてプッシュし、直近の変動に対してはプルで細かく調整する、である。これは、どんな計画でも共通だ。

では具体的に、どうするのか。

まず、工場におけるデリバリー設計(リードタイムの設計)を見直し、カップリング・ポイントを決める。すなわち、原材料から製品までの流れの途中に置く、主要な在庫ポイントである。鰻屋なら、さばいて串を打って蒸しておく。あるいは寿司屋なら、すし飯とネタの塊までを開店前に仕込んでおく段階までが、上流側だ。

上流側は需要予測に基づく見込生産になる。カップリング・ポイントにおく在庫品目ごとに、基準在庫水準、有効在庫量(未引当て数量)、そしてタイムフェンス以後の需要量(消費量)予測をする。

需用量(消費量)予測は二通りのやり方がある。一つは最終製品の需要予測から、BOMと部品展開によって計算する方法。これは論理的でまっとうなアプローチだが、精度の高い先行内示をもらえる場合か、最終製品の需要予測がかなりうまく立たないと計算できない(そしてたいがいは、受注生産なので予測はうまく立たない)。

もう一つのやり方は、その中間在庫品自体の、過去の消費実績から推定する方法である。こちらの方が、普通はやりやすい。とくにカップリング・ポイントが共通性の高い部品材料にある場合は、最終製品の細かな変動が互いに打ち消し合って、需要傾向が安定するので読みやすいのだ。

下流側はどう計画するか。これは確定受注オーダーで動かす訳だ。このとき、すでに原料・中間在庫は上流側計画によって十分供給されるから、欠品の心配のない状態になっているはずである。必要なのは要員・機械・治具金型などのリソース手配計画と、より目の細かい順序計画=スケジューリングである。

まとめると、受注生産企業における生産計画の主眼は、カップリング・ポイントの在庫量推移をはさみ、上流側は数量の計画、下流側が順序計画におかれることになる。

実際には、たいていの製品のBOMはA型になっているので、一製品に対してカップリング・ポイントは複数設定しなければならないことが多い。また工場は複数の製品を作っており、同一の工程に複数の品目が流れるため、同じ工程に需要予測生産と確定受注生産が混在してしまう可能性がある。そのときに何を優先し、どうコントロールするのか。そこが生産計画マンの腕の見せ所になるわけだ。

それだけではない。工場とは単に、「設計したとおりのモノを作るだけ」「営業が指示した数量や納期で作るだけ」のコストセンターである、という思想にしばられている企業はいまだに多い。しかし、低コスト・短納期のバランスから、「カップリング・ポイントをここに置く以上は、BOMの形はこうでなくてはならない」、という風に技術設計部門が考え、「競争力を強めるために、こういう注文の取り方をすべきだ」、という風に営業は考える。それこそが、本当に全体が統合された組織のあり方ではないか。

望むらくは、わたし達の社会の製造業全体で、ここで述べたような基本的な知識が誰にも共有され、その上で各社が、生産計画や生産システムのデザインに腕を競い合う、という状況になってほしいと思う。どこの部門が強いとか弱いとかではなく、受注から納品までの全体の競争力向上のために、どの部門も協力し合う、そういう良さを日本企業は本来、持っていたはずなのだから。

<関連エントリ>
 →「受注生産企業に生産計画は必要か?」 (2015-11-18)
 →「Pushで計画し、Pullで調整する」 (2014-02-24)
by Tomoichi_Sato | 2015-11-25 23:36 | サプライチェーン | Comments(2)