人気ブログランキング |

BOMデータのマスタと履歴を区別する


どんな会社にも、従業員台帳というのがある。従業員の氏名・誰それ、その住所、生年月日、入社年度、職種といった情報が記されている台帳だ。同姓同名の場合もありうるから、普通は従業員番号も振られているはずである。
同じようにどんな会社にも、給与台帳と言うものがあるはずだ。従業員誰それに支払うべき月給はいくらいくら、といった金額が書いてある。

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから2019年8月には、誰それに給料をいくらいくら支払った、という履歴も、台帳に残しているはずだ。

月々支払うべき基準としての給与と、毎月実際に支払うべき金額のリスト。どんな会社もこの2つを持っている。

それだけではない。会社によっては、実際にいくら支払ったかの履歴を、さらに別に持っている場合もある。例えば手当の一部が外貨建てである場合は、給与計算をした日と、実際に支払う日では、換算レートが違ったりする。だから、支払おうと決めた金額と、実際に支払った金額に若干の差が出るのである。外貨建て以外にも、現物支給などがあると、やはり実際の支払額が変わりうる。

標準としての給与額。支払おうと決めた決済の金額。そして、実際に支払った金額。この3種類は別のデータだ。だからコンピュータでこのデータを管理したいときには、3種類の別々のテーブルに、記録することになるだろう。

ITエンジニアは、標準としての給与額を記載したケーブルを、「マスタデータ」と呼ぶ。そして月々の支払い金額を消した2種類のテーブルは、あまり聞き慣れない名前かもしれないが、「トランザクション・データ」と呼ぶ。

マスタデータとトランザクションデータの違いは何か? マスタデータは、基準値だから、一旦登録するとそう頻繁には変わらない。給与台帳を更新するのは普通、年に1回位だ。

トランザクションデータの目的は、取引履歴の記録であることが多い。したがって取引が発生するごとに、頻繁に追記される。そのかわり、一旦記録したデータは、基本的には更新されない(例外はあるが)。「取引」と言う言葉を使ったが、これは商取引の意味には限らない。社内的な指示や報告は、データのやり取りであって、データ論的には取引にあたる。

それでは、部品表(BOM)データは、マスタだろうか、トランザクションだろうか?

ある種の人々にとっては自明なこの問いが、しばしば別の人々にとっては混乱の元となる。今回はこの問題を考えてみたい。

「生産とは、設計情報をモノ(媒体)に転写する活動である」、という言い方がある。ちょうど、生物の細胞の中で、DNAに書かれた遺伝情報が、分裂増殖のたびに転写され、新しい細胞が作られていくように。これは、元は東大のものづくり研究で著名な、藤本教授の発言である(たとえば、「ものづくり経営の今後」https://www.panasonic.com/jp/corporate/technology-design/ptj/pdf/v5503/p0202.pdf参照)。

そして、製造業にとってDNAにあたる「設計情報」の、中核にあるのがBOMデータだ。

である以上、BOMデータは製品の「あるべき姿」を示す基準であって、そうそう頻繁に変更されるものではない。だから、マスタデータに他ならない・・こう考える人が多いだろう。

果たして、そうだろうか?

ためしに、個別受注生産(受注設計生産)の場合を考えてみてほしい。造船だとか、産業機械だとか、宇宙ロケットといった、もの作りの分野だ。金型とか鉄骨建材なども、この部類に入る。こうした業種では、正式に受注してから、詳細な設計作業が始まる。顧客の要求する仕様は、毎回、個別だから、それに合わせて、機能や構造や制御方式を考え、決めていく。当然ながら個別受注生産では、受注時点でBOMが確定しておらず、設計が進むにつれてBOMが出来上がっていく

このような業種のBOMは、マスタデータだろうか。もちろん、この設計情報が、工場でモノに転写され製品と化していく訳だから、一種の「基準情報」であることは間違いない。しかし、このBOMをデータベースに登録するとして、これはマスタだろうか。

マスタデータの条件は、頻繁に内容が更新されない事、だった。さて、この条件はどうか。いったん設計が確定し、出図されたら、そう簡単には変更されるべきではないし、変更されたら皆が困る。購買部門は注文したものを変更しなければならないし、製造部門は作りかけたものを手直ししなければならない。うん。だから、変更は少ないはず、と。

実際にこの業種に従事する人がここを読んだら、苦笑いするだろう。そんなことはない、現実には、ありがたくない変更が次から次に起こって、そこから発生する問題をどうボクメツするかが、生産管理の仕事の中心にあるのだ、と。

この事情は、ITエンジニアの読者の方には、受託開発のSIの仕事に類似している、といえば分かっていただけるだろう。SIプロジェクトでは、個別の要件に従って、毎回、要件定義と基本設計を行う。だが、上流工程で固まったはずの仕様が、しばしば実装テスト段階になっても変更を余儀なくされ、それとの闘いが仕事の後半戦の中心になるのだ。SIerの人達に、あなた方の設計図(たとえばモジュール構成図)は、マスタデータですか、と問うたら、どういう答えが返ってくるだろうか。

それに、上記の説明では、まるでBOMデータが設計の完了とともに、一気にワンセット出力されてくるようなイメージで書いた。しかし、現実はそうではないのだ。個別受注生産ではしばしば、コアとなる長納期部品があって、その周囲の部分から先に設計を固めていく。そして中核部分のBOMデータから順次、アウトプットされていく。そうしないと、購買手配が間に合わないからだ。

ある部分はすでに調達が走っているのに、別の部分はまだ設計作業を続けている。そういう並進フェーズがしばらく続く。その間は、BOMデータは順次、追加されていく。既存部分の変更も起きる。

しかも、こうした業種では、部品・材料自体、毎回、個別仕様で購買することが多い。さすがに汎用の材料を使う部分もあるが(とくにケーブルやパイプ・継手など)、こちらは長さ・個数など数量が、毎回、まちまちである。

したがって、こうした個別受注生産の業種では、BOMデータはマスタとして登録しがたいことが分かる。この分野のBOMデータは、購買や製造部門に対する指示であって、いわばトランザクションデータなのである。

しかも個別受注生産では、製造段階で思わぬ問題が生じ(主に設計変更に起因する)、その対応のために、最初の設計図とは違う形で、製造がおこなわれることも、しばしばある。そこで、出荷納品時に、あらためて設計図や設計情報を更新することも多い。これを「As-built」データと呼ぶ。世の中は「As-Is」と「To-Be」の2種類のモデルで割り切れる、と信じている類の人には、驚きだろうが。

As-builtのBOMデータは、「こう作りました」という製造実績を記録する履歴データ=トランザクションである。これは、「こう作ってほしい」という設計のBOMデータと対になっている。個別受注生産の業種では、基本的に、
「製造指示のBOMデータ」
「製造実績のBOMデータ」
の2種類のトランザクション・データが存在し、もしもITシステムでデータベース化する際には、この2種類のテーブルを構築する必要がある。

では、マスタデータはないのか? BOMのマスタデータは、ない。毎回異なるのだから。毎日違う人を雇って、実働時間に合わせて日給を支払う、日雇い労働の会社に、給与台帳など存在しないのと同じだ。

ただし、個別受注生産の業種でも、品目マスタ(部品材料マスタ)は作れるし、作るべきだとわたしは考えている。それは、調達業務や原価(=見積)業務のコントロール水準を向上するために、役に立つからだ。もちろん、設計基準情報の共有・再利用という面でも、省力化に利するだろう。

しかし現実には、たとえそれなりの大企業であっても、品目マスタを持っていないケースを、しばしば見かける。毎回、個別仕様でまちまちの部品・材料の数量表を作って、調達やコスト見積を追いかけていくが、出荷して仕事が終わったら、誰かの机の中にファイルされて朽ちていく。データの使い捨てである。余談だが、個別性に生きるこの業界では、データの再利用とか、標準化の意識が低いように感じられる。過去の設計結果(履歴)のコピペで、もう十分「省力化」ができてると思っていたりする。

・・以上のような話を読んでも、「それは特殊な業界の話だろ」と思う読者は多いかもしれない。日本の製造業の花形は、自動車と家電、その周辺業界だ。こうした業界では、あらかじめきちんと設計された製品を、繰り返し量産していく。だからBOMデータはまさにDNAであり、マスタであるはずだ。一部の特殊な業種の病的な事例を挙げても、参考になるのか、と。

たしかに、繰返し生産型の工場では、ふつう、BOMデータはマスタとして保持している。それを元に、資材購買の手配や、部品在庫からのピッキングや、各工程への製造オーダーが発行される。個別の数量やタイミングは、需要(受注数)と在庫や進捗に応じて変わるだろうが、本来、製品が必要とする部品材料の員数は、不変である。

そしてBOMマスタは、設計に変更生じた時にのみ、更新される。設計は、何らかの仕様に変更が生じた時(ふつうは製品開発に伴って)に起きるだけのはずだ。これが正常なBOMデータの姿である、と。そう思われるかもしれない。

では、お伺いしたい。貴方が新品の自動車を買うとき、いろいろなオプションを指定し注文しなかっただろうか。新しいPCをネットで注文した時、ストレージやCPUやメモリを選ばなかっただろうか。これはすべて、個別仕様ではないか?

そう。個別仕様だ。だが、そのために、自動車メーカーやPCメーカーが、いちいち設計図を起こすようなことはしない。塗装の色もエアバッグもミッション部分も、すべて標準モジュール化され、組立て段階で選んで組みつければ良いようになっている。これを受注組立生産(ATO=Assemble to Order)による「マス・カスタマイゼーション」と呼び、先進的な業界の姿である、と。きっと新進気鋭のコンサルタントなら、そう反論するだろうなあ。

それで、個別仕様への対応を、オプションとモジュール構成で実現するATOの工場では、BOMデータはどうなっているのか。オーダー番号ABC0987の、佐藤氏の注文したPCは、どの部品とどの部品を組み合わせて作るのか。当然ながら受注システムから製造システムに対して、オーダー番号に紐づいて、データが受け渡される。内容は、使用すべき部品のリストである。これは、BOMのトランザクションそのものではないか。

見込生産・繰返し型受注生産で量産型なら、たしかに生産活動はBOMマスタの単純な転写と言っていい。しかしATO(受注組立生産)では、明らかに、個別のBOM指示が必要で、その履歴はトランザクションデータになる。(ついでに言うと、ATOでは、月度生産計画や部品調達計画のために、モジュラー型BOMも必要になるのだが、この話をすると長くなるので、興味がある方は拙著『BOM/部品表入門』 第8章を参照してほしい)

そして、さらに言うならば、単純な繰返し型の生産形態は、今日の日本では少なくなった。単純な量産は、海外に出てしまって、日本国内に生き残っている工場の多くは、個別仕様だとか、試作品だとか小ロット特級品だとか、ちょっと厄介な仕事に対応することで稼いでいる。

そして、個別仕様を受け入れ始めるやいなや、必要とされるBOMデータは、マスタに登録されている標準品からずれていく。それを、個別のオーダーに紐づけて、記録していく必要が生じる。だから、BOMはマスタ以外に、製造オーダーに紐づくトランザクションデータも、持っておかねばならない。

BOMがマスタであるべき、という一種の思い込みは、現在の構造型BOMが、MRPという生産管理方式と一緒に生まれたことから生じているらしい。だが、本家欧米のMRPさえ、個別仕様に対応せざるを得なくなってきているし、実際、SAPの生産管理モジュールでさえ、ずいぶん以前(R/3の時代)から、生産オーダーにBOMを添付して発行する機能を持っていたと記憶する。

それだけではない。実際には、生産オーダーを受け取った製造現場側が、さまざまな理由から、その通り作れずに、部品材料を変更することがある。よくあるのは、サプライヤーの変更に伴い、部品材料が変わってしまうとか、部品のストック切れを待って、新しい仕様の部品に切り替えていくとかいった状況である。ほかにも、リソース(生産資源)の変更(加工機械を変える、など)もありうるし、工順の変更(外注に出す、など)もある。

こうしたことは、すべて、指示されたBOMデータからの変更であり、実績として別途、記録しておく必要がある。そうしないと、出荷後に品質問題が見つかったり、保守サービスの要求をもらった際に、実際に何と何でどう作っていたかを、追えなくなってしまうからである。

かくして、いわゆる繰返し受注生産型の業種であっても、結局、
・設計の姿としてのBOMのマスタデータ
・製造指示としてのBOMの履歴(トランザクション)データ
・製造実績としてのBOMの履歴(トランザクション)データ
3種類のBOMデータベースが必要になる訳である。

e0058447_23170544.jpg
そして、これこそが、いわゆる「E-BOMとM-BOMの乖離問題」を防ぐ、予防線の一つなのだ。E-BOM/M-BOMの乖離が生じる原因はいくつかあるが、その重要な一つが、設計図と、実際の製造にズレが生じることにある。ズレの原因は、上述のように、個別仕様への対応の場合もあれば、部品在庫の都合もあるし、様々だ。だが、ズレが生じるのが、現実だ。その現実を、BOMマスタ一つだと、救いきれなくなる。

だから、BOMデータベースには、原則として、3種類が必要になる、と最初から考えてDB設計する方がいい。これは、落ち着いて考えれば当たり前の話であって、だからわたしは『BOM/部品表入門』の冒頭、プロローグにこの図を入れたのである。

だが、BOMデータのマスタとトランザクションの区別(併用)という考え方は、未だに必ずしも普及していないようだ。つい最近も、ある大手IT企業の資料の中に、「E-BOMとM-BOMの乖離問題は、見込生産や繰返し受注生産に起きやすい。個別受注生産ではこの問題は生じない」という見解が書いてあって、驚いた。わたしの誤解かもしれないけれど、この会社は、E-BOM/M-BOM問題と、マスタ/トランザクションの区別を、なんだか一緒くたに論じているのではないかと思えたのである。

こうした議論の混乱が生じる一因は、マスタデータというものが、「再利用可能なデータの格納場所である」という理解が不足していることにもあるのではないか。マスタデータは、単に更新頻度が少ないデータの置き場所ではないのだ。データを「再利用可能」な姿にブラッシュアップして、それを皆が共有し参照できるようにするため、台帳としてのマスタを作るのである。

マネジメントとは、PDCAサイクルを回すことだけではない。個別性の高い仕事を、繰り返し可能にし、再利用可能にし、標準化することもマネジメントなのだ。もちろん、そのためのデータのマネジメントだって含まれる。

マネジメントとは、結果(製品)だけ出せば良いのではない。仕事を個人に依存しない、インパーソナルな仕組みに作り上げることである。仕事を、個人の知識や経験値に依存した、属人的なものに留める段階にとどまっているならば、その組織は、いつまでたっても、新しい能力を共有することができないだろう。

では、製品種別が増え、個別仕様が増え、受注設計生産を余儀なくされている現代の製造業にとって、BOMデータのマネジメントはどうあるべきか。それを考えるための有償セミナーを、12月にもう一度、アンコールで実施することになった。長い記事の最後に、宣伝めいた終わり方で恐縮だが、もしこの主題に関心がおありになる方がいたら、下記のURLをのぞいて、ご検討いただきたい。

2019年12月17日(火) 10:30 ~ 17:30
BOM/部品表の基礎と効果的な活用ノウハウ

もちろん、佐藤の考え方には賛成できない、反論を述べたい、という方も大歓迎である(笑)。ちゃんと議論して、わたし達の社会の製造業のレベルアップに、ぜひ一緒に寄与しようではないか。


<関連エントリ>
 →「E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える」 https://brevis.exblog.jp/24157732/ (2016-02-21)
 →「オプションが多数ある製品のBOMは、どう構成すべきか」 https://brevis.exblog.jp/21404200/ (2013-12-02)


by Tomoichi_Sato | 2019-08-28 23:24 | サプライチェーン | Comments(0)
<< スマート工場時代の製造部品表(... ミニレビュー:ポータブル・オル... >>