世界で戦うための 事例1（その4） 情報基盤の構築（後編） BOMの活用法を詳細設計 團野 晃 ●O2 技術ディビジョン シニアコンサルタント 前 世界一」「売り上げ1.5倍」を目 討が必要になる。その中で、詳細な業 の違いである。ただし、各BOMに違 務ルール、情報基盤に求められる機 いがあるとはいっても、 営業から設計、 指すA社の業務改革プロジェクトにお 能やデータをきちんと定義する。具体 生産計画、手配、組み立て、出荷と流 ける実行フェーズの解説を開始した。 的にはまず、部門とプロセスの視点で れる全業務プロセスにおいて、互いに 具体的には、優先度が高い施策であ 詳細な業務フローを作成し、その中か 連携を取りながら整合性を保つこと る「情報基盤〔BOM（部品表） ・技術情 らBOMの種類（もしくは機能）ごとに が必要となる。 報〕 の構築と改革」である。前回は、 「案 関連する業務フローを抽出し、概略業 この基本的な考え方を明確にした 件BOM」 「設計BOM」 「製造BOM」 「出 務フローを幾つも作成する。これらが、 上で、BOMを活用する業務と、その 荷BOM」という4種類が必要であるこ 各BOMの活用シーンとなる。 他のシステムや業務ルールで行う業 とが明らかになった。今回は引き続き ここでは、 「データ」 「業務」 「組織」 「シ 務を切り分けながら活用方法を検討 情報基盤構築の実行フェーズとして、 ステム」の詳細要件を定義するが、そ した。例えば、案件BOMの活用を検 ①BOMの活用方法の決定、②主要属 れらの関係性を可視化するために、 「業 討する際に、以下のような討議をする 性と管理技術情報の整備、③活用方 務」と「実現方法（求められる機能と 場面があった。 法の検証、 の進め方を紹介する （図1） 。 業務ルール） 」 をまとめる （表1） 。 これで、 O2（筆者） 「案件BOMの活用では、 ど 検討の漏れもチェックできる 。 んな業務が想定されますか？」 BOMの種類によって何が異なるか A氏 （営業担当者） 「見積もり検討用に、 BOMの活用方法を決めるために といえば、つまるところ、各業務シーン 工程単位で基本売価を自動積算し、 は、全ての業務シーンを対象とした検 において活用/登録/管理すべき構成 過去の実績原価などを参考にして利 回（2011年8月号）から、 「 業界 ＊ 構成の推移を考える 基盤情報の活用に向けた業務・データ定義 実行計画 策定 深掘り 検討 改革変化点 （活用シーン） の整理 BOMの 活用単位の 決定 BOMの 生涯設計 BOMの 種類定義 活用方法 の決定 検証ポイント 定義 データによる検証 実案件データ の抽出 フォーム の定義 だんの・あきら：大手自動車部品メーカー、製造業向けコンサルティング会社を経てO2 （本社 東京） へ参画。量産機能部品の生産技術、3次元CADによる製品設計から生産工程までをカ バー。O2では、 その14年に及ぶ経験を生かしたコンサルティング活動に従事している。 活用方法の検証 詳細要件の定義 主要属性と 管理技術 情報の定義 システムの 選定と 要件の定義 図1●情報基盤 〔BOM （部品表） ・技術情報〕 の構築と改革に向け た基本ステップ 色付けした部分を今回は 解説する。 ▶O2 （http://www.o2o2.co.jp/） は、設計開発領域を中心としたエンジニアリング・チェーン を専門とするプロ集団。顧客企業の業務プロセス改革、高度な技術課題解決を総合支援。 SDM、3D-DPRMなど独自の方法論を持つ。 September 2011 NIKKEI MONOZUKURI 93 世界で戦うための 表1●業務と実現方法のマトリックス 業務 Lv1 Lv2 実現方法 求められる機能 （データ、活用方法含む） 情報基盤の機能 受注BOMの取り込み 受注BOMの取り込み 設計BOMの作成 構成展開の基本機能 業務ルール 情報基盤以外の機能 受注BOMの取り込みルール 3次元データ特有の注意点 構成展開後の運用ルール で、機能ユニットごとの仕様値の範囲 を明確にしたり、標準構成を取り決め たりして、顧客要求仕様と設計仕様、 流用元図の区分確認 流用元の確認ロジック — 流用元確認の仕組み 製品構成の間で変換とひも付けを行う ユニット構成の展開 ユニット詳細展開 — 詳細展開のルール 設計工数の管理 — — — — 設計時間の標準化 BOMの先行公開管理規定 図面配布ルール 電気部品の確定ルール ことが必要になってくる。 出図計画の作成 設計BOMの先出し 出図・確定処理 BOMの先行公開検討機能 電気BOMの確定方法 ストラクチャBOMの考え方 製造BOMの作成 BOMの変遷 製造BOMの履歴の持たせ方 製造BOM側の採番事例 素材などの構成展開 素材定義方法の検討 内外区分検討 内外作の検討 構成・品目リードタイム整備 製造BOM構成編集ケース 先行・まとめ手配 まとめ手配の考え方 生産計画の山積み 生産計画検討の方法 生産計画の山崩し 生産計画の確定 手配・製造指示 — — — — — — — — 生 産計画の山崩し 方法 — 生産計画確定方法 部品手配の実施手配BOMの 生 産 管 理・受 発 注 考え方 機能 内外作決定ルール 製造BOM構成の編集ルール 先行・まとめ手配ルール — — 生産計画確定・変更ルール — ただし、これを実現するには相当の 時間を要するため、 A社の改革プロジェ クトにおいては1年後に、 ある特定の商 品群から適用していくことになってい た。その前の段階として取り決めるべ き項目は「検討結果を管理活用できる 仕組みと、売価・原価の可視化の取り 組み」に限定するようにした。 一方、当面の営業場面を支援する 現実的な方法として、実際に生産され た加工機に対する代表的な設計仕様 益率をシミュレーションしたいです。将 A氏「ベテラン設計者や、技術的な営 情報管理の徹底と、その再利用を検 来的にはこのタイミングで、原価企画 業が可能な一部の人材の頭の中には 討した。 できるようにしたいと思っています」 ありますね。今は、 それらの人に聞く必 A氏「どのような情報があれば顧客要 O2「全ての工程が、過去の案件から 要があります。過去の検討結果が管 求に合った構成を探しやすいかを明 流用できるわけではないと思うのです 理されていないこともあって、属人的 確にすることは、それほど難しくありま が、 その場合はどうするのでしょうか？」 になっているのが現状です」 せん。過去に生産した加工機や流用 A氏「まず、製品の動作速度などの仕 営業における、提案型営業の実現 元として推奨する加工機の情報、工程 様を基に標準の構成を流用できるか と見積もり精度の向上には、2つの取り くくりの構成情報がしっかり管理され を検討し、 できない場合は基本構造だ 組みを行う必要がある。1つは、過去構 ていて、活用できる機能を情報基盤が けでも活用できるかを判断して、見積 成の流用による見積もり効率および見 保有していれば、次の案件のときに探 もりを行います。仕様から検索できる 積もり精度の向上だ。しかし、顧客要 す手間も省けます」 とよいのですが…」 求仕様に応えながら、社内での設計レ B氏（設計者） 「営業段階での見積もり O2「顧客要求仕様から構成を自動検 スと売り上げ拡大を実現するのは難し の根拠である仕様や議事録、構成の 索し、引き当てるためのルールはある い。過去の生産機種からは、顧客要求 流用元が分かるようなデータが可視 程度明確になっているのですか？ つま 仕様と製品構成の関係が妥当かどう 化・ひも付けされていると、問い合わ り、 どの仕様値が構成の流用可否判断 かを判断するための情報が、必ずしも せの手間などを減らすことができてう の定量指標になるかということですが」 読み取れるわけではないからだ。そこ れしいですね」 ＊ このマトリックスは、業務要件定義 （本フェーズ）後のシステム要件定義、定着に向けた詳 細業務ルール定義でも活用していくこととなる。 94 NIKKEI MONOZUKURI September 2011 過去10年、サプライチェーン管理（SCM）の改革によって、調達や製造、物流といった 目に見えるコストダウンが進んできました。しかし、製品ライフサイクルが短くなりグ ローバル競争が激化する中、 コストダウンだけの改革では企業内は疲弊するばかりです。 本コラム「エンジニアリング・チェーン改革」は、製品の価値を決める設計開発領域を 中心に抜本的な業務改革をどう実現するかを、事例ベースで解説します。 案件BOM 仕様値選択結果を 案件 ファイル 案件として保存する 加工機 こんな討議を、設計 BOM、製造 工程 BOM、出荷BOMでも行うことで、案 議事録 件BOMから設計BOMの構成推移と、 見積もり そのときの業務・データ要件、必要な 業務ルールを文書化した（図2） 。設計 仕様値 売価 区分 ユニットA TYPE-A 1万2000 流用 図2●案件BOMから設計BOMへの構成推移 設計BOMの作り込み手順は、①ユニット以下の構成 を展開する、②修正予定の部品を計画する、③手配可 能な部品を 「確定」 にする、④BOMを公開 （先出し） し、 製造BOMとの連携を開始する、 となる。 設計BOM ユニットB TYPE-B 1万3000 流用 加工機 ユニットC TYPE-C 1万5000 流用 BOMと製造BOMの連携においては、 加工機 時に設計BOMの先行公開を考慮した 新規 区分 ユニットB TYPE-B 1万5000 修正 工程 のと同じ考え方を活用。出荷BOMに 受注 指示書 おいては、設計指示の情報と出荷した 確定 区分 修正 未確定 部品1 修正 未確定 部品2 流用 確定 ユニットB ① 受注BOM 実行計画策定フェーズの深掘り検討 新規 区分 工程 成約した案件ファイルを 出力して、社内公開 仕様値 ② ③ 売価 子部品 構成 データ Bをベースに○○対応 現物が不一致となりがちな個別受注 特有の業務を考慮し、正しい情報が した活用方法とルールをブラッシュ 最適化検討を充実させることを狙って 蓄積される方法を取り決めた（図3） 。 アップするのだ。 いたが、その生産計画を基盤情報とど 簡易ツールでブラッシュアップ ただし、簡易ツールといっても、この こまで密な連携で立てるべきか否か 段階（実行フェーズ）で検証に使うの が意見として分かれていた。そこで、 次に我々は、BOM構成推移の考え は実際のデータだ。取り決めたルール 現場を巻き込んで、実際のデータを見 方と、活用方法を定義した。これと並 やひも付ける情報の提供のされ方を ながら討議することで、最終決定しよ 行して、深掘り検討でも利用した簡易 実務者が実際のデータで見ることで、 うとしていた。 ツールによる実務適用検証も行った。 より確実な要件を定義できる。 C氏（生産計画担当者） 「このツールの これらを通して、業務・データ・組織・ 生産計画ワークショップ（WS）にお ように全体の構成が見えれば、現在、 人の実現イメージを明らかにし、定義 いては、BOM活用により調達・生産の 個別で検討している加工工程の計画 設計BOM 製造BOM 出荷BOM 加工機 加工機 加工機 工程 ユニットB 部品1 ③ 部品2a 新規 区分 確定 区分 修正 未確定 ① 修正 未確定 ② 流用 確定 親品目 旧子品目 新子品目 旧個数 新個数 部品2a 1 修正 未確定 3/1 ̶ 3/1 ̶ 部品2 未確定 ② 流用 確定 3/1 部品2a 流用 3/8 部品1 変更データを自動生成 部品2 確定 区分 ユニットB 設計はBOMを直接編集（上書き） ユニットB 新規 区分 工程 1 設計変更指示書の必要記載事項 修正 確定 新規 区分 確定 区分 修正 確定 3/1 ̶ 部品1 修正 確定 3/1 6/7 3/8 部品2a 流用 確定 3/8 ̶ ̶ 部品1a 流用 確定 6/7 9/25 部品1a 流用 確定 9/25 ̶ 有効日 失効日 ③ 有効/失効日を自動セット 工程 ④ ユニットB ⑤ 有効日 失効日 試運転の結果、 部品1を変更 図3●製造BOMと出荷BOMの生成手順 設計BOMの初回公開時は、製造BOMで構成情報と属性情報を全て受け取る （①） 。その後、設計BOM側で新規区分や確定区分を更新した場合は、製造BOM側の情報も上 書き反映する （②） 。設計BOMで部品や個数が変更された場合は、 製造BOMでは構成履歴として反映する （③） 。一方の出荷BOMは、 加工機の出荷を機に最終姿で作成する （④） 。 さらに、試運転の結果などから出荷・設置後の改造を行った場合には、 出荷BOMに変更履歴を追加する （⑤） 。 September 2011 NIKKEI MONOZUKURI 95 世界で戦うための と負荷見積もりを立てる工程が短縮で らないことです。それが早期に分かっ き出して、別途検討することを1つの方 きる可能性がありますね」 て、流用の可否や、類似品と出図日程 法として提案した。素材品番の定義 O2「現在考えている情報基盤では、 が明らかになれば、現状の個別計画と ルールを新しく取り決めることで対応 標準リードタイムの情報による計画の 併せて材料の手配を先行で行えます」 するのだ。C氏も「それが良い」と賛同 山積みしか行わない予定ですが、 それ C氏によると、山崩しの機能が不要 し、 この方法を採用することになった。 で大丈夫ですか？ 実際の機械負荷見 な代わりに、部品手配の検討機能を付 このように、現場のメンバーを含め 積もりやリソース配分の検討は行えな 与したいという。複数の案件を横並び て検証し、知恵を出し合うことで、 より いのではないかと思うのですが…」 で見て、共通素材を適用できそうな部 効果のある運用の仕方が明らかにな C氏「それで十分です。それ以降は個 品を選び出したり、 在庫を引き当てたり、 る。情報基盤として持つべき機能、 ルー 別に立案した方が、急な変更時での 電気コードなどの素材を長さの指定で ルとして新たに追加しなくてはいけな 対応が早いですから。現状における 一括発注したりするような機能だ。 い項目に対する同意も得られる。 最大の問題点は、全体の構成が分か これに対しては、データを外部に書 表2●活用シーンごとの必要情報 属性 受注BOM 活用シーン 製造BOM 属性として 要/不要 顧客名称 機種 加工機 製品仕様（案件ＢＯＭ由来など） 受注番号 客先発注番号 コンフィグ識別番号（旧注文番号） 機械番号 設計・製造BOMの連携開始日 代表製番 稼働日 稼働条件 出荷日 履歴番号・管理日付 プロジェクトコード 加工機名（呼称） 予定設計時間 機械スピード 仕向け国 仕向け工場 納期 加工機サイズ 良品率 稼働率 加工機全長 消費電力（供給電力） 質量 作業者数 加工機原価 材料仕様 参照加工機 要 要 要 不要 不要 要 要 要 要 要 要 要 要 要 参照形式 外部参照、保持 外部参照、保持 外部参照、保持 外部参照、保持 外部参照、保持 外部参照、保持 外部参照、保持 外部参照、保持 BOMの活用方法とその検証が進 設計BOM 受注 受注 設計 設計 出図・ 仕様の 受注 BOMの BOMの BOMの 確定処理 明確化 取り込み 作成 先行公開 ○ ○ ○ ◎ ◎ ○ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ○ ○ ○ ◎ ◎ ◎ ◎ ○ ○ ◎ ○ ○ ○ ○ ◎ ○ ◎ ◎ ◎ ○ ○ ○ ○ ○ ◎ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ◎ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ◎：そのシーンで新規に作成する属性 ◯：そのシーンで活用、参照する属性 96 NIKKEI MONOZUKURI September 2011 主要属性と技術情報の定義 み、全体の業務フローが定義されると、 各業務において必要な情報がほぼ明 確になる。そこで、それらを主要属性・ 管理技術情報としてまとめ、どのよう に管理をしていくかを取り決める作業 に入った。この作業では、表2のような マトリックスを活用した。縦軸に必要 な属性情報、 横軸に活用シーンを並べ、 各属性情報がどのタイミングで必要と なるのかをマッピングしたものだ。 属性には、BOMの構成情報を新規 作成する際に生成されるものと、他シ ステムから継承して活用するものの2 通りがあり、後者の場合においては、 属性の更新をどう行うかをおのおの明 確にする必要がある（図4） 。 管理属性のまとめを行っていく上で は、以下のような討議が行われた。 O2「客先に納品した加工機を特定す 外部から属性を転記する場合 るための属性情報としては顧客名称、 機種、受注番号などがありますが、ど こでどう発行・管理されるのですか？」 外部 BOMに反映する マスター側 （初回連携） 個別値 属性編集 反映しない ２×３＝ 保持 ６通り マスター側へ戻さない BOM側 属性編集 D氏（システム管理者） 「現在は生産管 理システムで管理しています。今後も、 この方法は維持していきたいですね」 マスター側へ戻す 属性編集を認めない BOM ユニット 部品 他システムのマスター 属性項目 コード O2「では、 これらは現状のまま生産管 理システムで管理するとして、BOM側 からは外部参照させて、編集できない ようにするというのはどうでしょうか」 図4●属性の更新ルール 属性項目 部品 コード 属性を転記 外部の他システムのマスターからBOMに転記した属性 がある場合には、外部マスターとBOMの双方での属 性編集ルールを決めておく必要がある。 B氏「現在、納品済みの加工機を改造 あることも併せて取り決めた。 する場合には、過去の受注とひも付か 今回の取り組みでは、情報基盤の ない、別の受注番号が発番されていま 在り方や業務上での活用方法、必要 す。納品から長時間たった改造では前 な機能やシステムの機能範囲を明確に の番号が分からなかったり、改造が多 した。今後は、 システム選定とシステム 数回になると情報が散在して探す時 要件定義、導入へと移っていく。 間がかかったりしています。同じ機械 とかく業務改革というと、 システムの は1つの識別番号で管理したいです」 導入に話が向かいがちである。 しかし、 O2「その番号は新たに必要となる情 それだけでは何も解決しない。システ 報ですし、BOMで活用するだけです ムは面倒な業務を省力化したり、ある から、BOM側に追加することが望まし 一定のルールで統制をかけたりするの いですね」 には有効であるが、そもそもの運用基 このように、社内に散在している原 盤は業務プロセスとルールである。こ 価や部品の仕様など各種情報の発生 れまで4回にわたり説明してきたA社 箇所と、業務フロー上での活用・管理 の活動事例でも、業務プロセスの面か のタイミングを明らかにしていくことで、 らの見直しにかなり努力してきた。 個々の情報がどこで作られ、それをど 業務プロセスとルールがしっかりし う活用し、変化させるべきかをまとめら ていないままグローバル展開をすると、 れる。最も注意したのは「業務上活用 すぐに問題が顕在化する。そうなって すべき情報が、 2重管理にならないこと」 からでは遅いからこそ、早期の改革が である。情報基盤構築後も活用する情 必要なのである。グローバル市場で戦 報は変化していくことが想定されるた うための業務プロセス改革は今や待っ め、 システム的に柔軟な機能が必要で たなしである。 ◆◆当コラムは今号で終了します。◆◆ September 2011 NIKKEI MONOZUKURI 97
© Copyright 2024 Paperzz
