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