2020年2月16日 (日) 04:20にPirotoによる

2020-02-16T04:20:55Z

差分を表示

2020年2月15日 (土) 08:33にPirotoによる

2020-02-15T08:33:13Z

2020年2月15日 (土) 08:29にPirotoによる

2020-02-15T08:29:37Z

2020年2月15日 (土) 08:17にPirotoによる

2020-02-15T08:17:22Z

2020年2月15日 (土) 08:00にPirotoによる

2020-02-15T08:00:04Z

Piroto: ページの作成:「==統合化部品表== [生産管理][部品表] {{amazon|4820743996}} ===品番体系=== ====品番==== =====異なったモノを区別===== =====同じモノ…」

2020-02-15T07:29:41Z

ページの作成:「==統合化部品表== [生産管理][部品表] {{amazon|4820743996}} ===品番体系=== ====品番==== =====異なったモノを区別===== =====同じモノ…」

新規ページ

==統合化部品表==
[生産管理][部品表]

{{amazon|4820743996}}
===品番体系===
====品番====
=====異なったモノを区別=====
=====同じモノを同一視=====
====1物1品番が原則====
=====2つのモノを同じと見るか違うと見るかは立場により異なる=====
=====自動車業界=====
*品質に違いがあれば別モノ
=====互換性があれば同じモノと考えることも多い=====
=====スペックを表しているのか、モノそのものを表しているのか=====
*トレーサビリティ
====日本の製造業で多い====
=====基本部分(○○○○○-○○○○○)、補助部分(○○)=====
*補助部分は互換性がある設計変更(マイナー設計変更)の追番として利用される
**改訂符号と呼ぶ場合もある
**設計変更により番号が増えていく
一番大きな番号が最新
**基本部分が同じなら互換性が保たれる
基本部分のみがわかればよい業務も多くある
**構成マスターでは親品番、子品番をそれぞれ基本部分だけにして管理
補助部分が変わるだけの設計変更は構成マスターに影響しない
ある品番に設計変更があると、親品番へ、その親品番へと設計変更の影響が伝播する
構成マスターが基本部分だけで構成されていると、設計変更の親品番への影響が途中で止まるというメリットがある
補助部分だけが異なる2つの品番が併存しえない
補助部分が改訂される設計変更では、部品表内に現れる基本部分の同じすべての品番が、新しい補助部分を持つ品番に変わる
補助部分を使うと品番履歴を管理できる
*○○○○○-○○○○○-○○
===統合化部品表===
====保持する情報の範囲====
=====部品表保持情報=====
*製品情報
**仕様と製品番号(モデル番号、型式番号)との対応
*部品情報
**品番に関連した情報
*工程情報
**部品から製品を作る過程で必要になる部品や中間品の移動(ルーティング)と加工方法に関する情報
*設計変更情報
**部品や製品がどのように変更されたかの履歴情報
====製品情報====
=====部品=====
*1物1品番の原則
**品番が決まるとどの部品かを特定できる
=====製品=====
*製品番号から製品をユニークに特定できる場合も多い
*自動車
**モデル名や型式番号だけでは製品はユニークに決まらない
**オプションを指定してはじめてユニークに製品が決まる
=====部品表で重要=====
*グループとしての製品管理(モデルや型式)ではなく、個別の製品
*製品がユニークに定まらないとその製品を構成する部品を決められない
*製品情報管理で厄介なのは、「1物1品番」のように製品をユニークに特定する番号管理がされていない場合
=====型式=====
*仕様項目値
**スペックの許される組み合わせ
**スペックの制約条件
*仕様項目値の組み合わせを標準的に用意したものが型式
*製品情報は許される「型式+オプション」の組み合わせ
====部品情報====
=====品番でユニークに識別=====
*生産に必要な基本情報
=====品番マスター=====
=====構成マスター=====
====工程情報====
=====工場の現場作業者が何をすればいいかを指示する=====
=====ルーティング情報=====
*部品や中間品がどのように動くか
=====加工情報=====
*どのような加工をするかを指示
====部品表によるモデル化====
=====加工工程のモデル化=====
*加工工程
**入力部品→加工→出力部品
**加工工程が複数の部品で共有される場合の製造プロセスモデルは、多項モデルでかのうになる
===統合化部品表誕生の背景===
====社会的背景====
=====部品表の増殖=====
*ありとあらゆる設計変更をすべてのデータベースに反映させるのはほとんど不可能
=====昔は手配のためのデータベースだった=====
*現在では、世界中の拠点をつなぐコミュニケーションのインフラ
*設計と生産部門のコミュニケーション手段
====技術的背景====
=====部分最適=====
*20世紀までの製造業ソリューション
**MRP、PDM、PLM、スケジューラー、CPC、PIMなど
**設計と生産の間に溝
バッチでつなぐのにとてつもないオーバーヘッド
データ増大によるオーバーヘッドの増大
リードタイム縮まらず
=====全体最適=====
*統合化部品表
**全体最適で統合化されたデータベースから部分最適なソリューションを派生
**部分最適の業務を保証
**コンピュータリソースの高性能化と低価格化、インターネットの普及
===統合化部品表とは===
====初期====
=====統合化されたデータをビューで共有=====
====進化====
=====部品表データとルーティングデータ(工程、物量、受給)の統合=====
=====グローバル化=====
=====多言語化=====
=====2項モデルから多項モデルへの進化=====
=====プライベートとパブリックの空間管理=====
====トヨタSMS====
=====21世紀初頭=====
=====グローバルに部品表を共有し統合化した世界初の大規模事例=====
=====2000億円規模=====
*部品表の再構築と並行してほぼすべての業務システムも再構築する
====目的別部品表====
=====目的別部品表をビューでまとめ統合化したように見せる=====
*肝心の設計変更の部門間での共有や情報の同期が取れない
=====デメリット=====
*工数が等比級数的に大きくなる
*データ不整合の組織的な温床
*パフォーマンス劣化、グローバル化へのネック
*バッチでデータの整合性を取るのでリアルタイム性を損なう
====時間と空間の概念====
=====統合化部品表は部分最適の業務を保証しながら全体最適=====
*空間の概念
**各部門専用のデータをフィルタリングするビューから、統合化したデータベースを共有
**現在の技術でビューでフィルタリングが可能となった
部門ビュー別のファントムの設定という新しい概念
ビューでインデントを自由にコントロール
.設計からみると10レベルあった部品表が購買ではフラットに見えるなど
.一見階層の異なる部品表を共有化可能になる
*時間の概念
**ドキュメント、図面、部品を時系列で管理
====部品表とルーティングの統合====
=====ルーティングデータ=====
*工程データ、需給ルートデータ、物流データ
*従来部品表とは別のデータベースで管理されてきた
*本来なら一体化して管理すべき
**この統合を行ったのが統合化部品表
**Bill of Materials から　Bill of Manufacuring へ
=====データモデルパターン=====
*ツリー構造のモデル
*ツリー構造とリスト構造の組み合わせ
**多項モデルを応用して表現される
=====2項モデルから多項モデルへの進化=====
*2項モデル
**親子関係
*多項モデル
**2項モデルに、製番（作番）の概念を導入
**第3、4のキーを送出して新しいリレーションを従来の部品表へアドオン
===異なる部品表の統合方法===
====種類====
=====設計部品表と製造部品表=====
=====製品の雛形部品表と個別製品部品表=====
=====製品の雛形部品表とスーバー部品表=====
====製造業の受注タイプ====
=====タイプ1 設計が完了し生産準備が終わった後で受注=====
*量産品
=====タイプ2 受注後注文に合わせた詳細設計があり、それに基づき生産=====
*重工業で扱う製品(飛行機、列車、大型タービン)
=====タイプ3 販売用に在庫を用意し受注があると在庫を引き当て=====
*大量生産品(家電製品など)
====設計部品表と製造部品表の統合====
=====員数を分解するケース=====
*設計と生産で構成を分ける
**マークを保持する列を使って管理
**生産の都合で追加された構成情報(生産専用マーク付)
**設計で使用するが生産で使用しない構成情報(設計専用構成情報マーク)
=====製造品番が発生するケース=====
*設計が決めた親子関係の中間に現れる
*手配の単位となる
*所要量計算の対象となる
=====構成が変わるケース=====
*親子関係が変わるなど
*生産ビューには設計ビューで現れる品番はすべて現れる
=====設計変更の扱い=====
*設計と生産でビューが異なる場合、気をつけなければならない
*設計変更は設計ビューで発生
**生産ビューへ正しく反映されるべき
**設計専用構成情報のマークがある構成に対しては注意が必要
対応する生産専用構成情報や製造品番が存在するということ
正しく反映されるようにアクション
.設計者が生産専用構成情報をみて必要な変更を設計変更として指示
.生産専用構成情報や製造品番を追加した生産担当者と連絡をとって設計変更を正しく反映する
設計変更処理をどうするかが最大のポイント
=====海外拠点での現地生産化=====
*海外拠点で現地生産化する場合の部品表
**設計部品表と製造部品表の統合で課題となる
**設計が決めた品番が現地化される際に変わることがありうる(現調品)
**設計品番と現調品の対応を管理する必要がある
対応が取れていれば、海外拠点を指定すると海外拠点用部品表を自動的に生成できる
製造品番、品番と現地化品番との対応
構成情報
設計専用、生産専用マーク(海外拠点の場合拠点名)
=====ひな型(モデル)部品表と個別部品表の統合=====
*タイプ1(量産品自動車など)
**個別自動車の1台1台の部品表を指すのではなく、ひな型(モデル) の部品表をさす
**個別部品表という考え方は無かった
*タイプ2 (重工業など)
**各製品1台ごとに部品表を持つという管理
**個別部品表
個別製品ごとに生産管理が必要
同じものでも号機(シリアル・ナンバー)が異なる
.生産日程が異なる
.部品の納入日も異なる
号機が異なっても設計は同一
.統合することにより、確実な設変反映
.個別部品表のみでは、設変の反映を手作業で実施する必要
**ひな型(モデル)部品表を持つという考え方は無かった
**個別の生産管理情報を保持する場合、「個別部品表」という概念を導入
個別部品表は、ひな型部品表をコピーして作成
個別情報は、品番ではなく、構成に持たせる
=====ひな型(モデル)部品表とスーパー部品表の統合=====
*タイプ3 (大量生産)
**製品ライフサイクルが非常に短い
**スーパー部品表
ひな型部品表を生む出す元の部品表(メタ部品表)
.パソコンなど
.構成要素は既に決まっている
===部品表再構築に必要となる事項===
====部品表プロジェクトの3フェーズ====
=====企画=====
*基本構想と実行計画
**仕事の仕方の変化まで含む
=====開発=====
*システム開発と現行システムからの移行
=====定着=====
*新しい仕事の仕方を定着させる
====企画フェーズ====
=====3ステップ=====
*企画立案ステップ
**企業トップの説得
トップの強力なリーダーシップが必要
経営戦略と部品表との関係
全体最適の立場からの部品表の必要性
将来ビジョン
*基本構想策定ステップ
**システムの青写真
**新しい仕事の仕方を規定
関係する主な部署から担当者が参画
**部品表プロジェクトの範囲(スコープ)
プロジェクト対象範囲
関連アプリケーション・システム
**部品表と業務の基本設計
現状を正しく把握
現行システムの課題
現行業務の課題
**基本設計の目標/狙い
**方針の策定
*実行計画策定ステップ
**開発フェーズ移行で必要なサブプロジェクトを定義
====開発フェーズ====
====定着フェーズ====
=====一度に全面的に仕事の仕方を切り替えるのでなく徐々に切り替えていく=====
=====新業務でスムースに仕事が行えるようになる=====
=====部品表のデータ精度が確保されていることを確認する=====
=====切り替え中は新旧両方の仕事が混在する=====
*オーバーヘッドが発生
=====旧業務が新業務へ切り替わるごとにデータ移行が必要=====
===統合化部品表で必要になる新業務===
====データ入力の役割と部門権限====
=====品番に関連した情報は部品表で集中管理=====
=====中心データベース=====
*品番マスター
*構成マスター
*統合化部品表では、設計部門以外が提供する情報も保持される
**データ入力部門は設計部門だけでなく多岐にわたる
誤って情報を変更してしまうリスク
情報の発生現入力ポリシー
.新情報はなるべく早く部品表へ反映される必要
.情報は発生源で入力するポリシーを持つことが大切
役割(ロール)による権限管理
.情報発生源でデータ入力者が提供する情報はあらかじめわかっている
.データ入力者がやってよいことの権限を限定
.部品表のデータ項目ごとに入力責任はどのロールを持つ人が行うかを決定
====データ精度維持とデータ整合性ルール====
=====データ構造上必須チェック=====
*参照制約
**構成情報に現れる品番は品番データベースに存在しなければならない
*親子無限ループ
**親から子をたどるとき途中に親品番が現れてはならない
**間違った入力をすると発生する
*データ更新をトリガーとして、ストアドなどを活用しチェック
=====ガベージコレクション=====
*不要になった品目のデータや構成のデータを論理的、物理的に消去
*供給していない部品
*何十年も前に製造中止となった製品
*パターン
**物理消去
エラーデータエントリ
**現在使用しないが、保守部品として使用したい
**不具合や製造中止で使用することがなくなった
===生産管理のための統合化部品表の役割===
====試作、生産準備のための統合化部品表====
=====メーカーがモジュール化によるコストダウンをはかる=====
*今までは単純に部品を納ていた
*いくつかの部品をアセンブリしてモジュール化したものを納めることが増えてきている
*部品メーカーが部品表によるアセンブリが必要に
=====試作=====
*出図して試作する場合
**設計部門が直接さみだれ方式に発注することが多い
図面中心主義
特に部品表は持たない
手作業によるオペレーション
*設計～手配～試作～生準のリードタイム
**短くなる製品ライフサイクルにとってボトルネック
*試作の工程は個別受注生産
**管理方法は製番生産と同様

@@ 1行目: / 1行目: @@
 ==統合化部品表==
- | [[生産管理]] | [[部品表]]
+[[生産管理]] | [[部品表]] |
 {{amazon|4820743996}}

@@ 1行目: / 1行目: @@
 ==統合化部品表==
-[[生産管理]][[部品表]]
+ | [[生産管理]] | [[部品表]]
 {{amazon|4820743996}}