多くのPDM/PLMには生産ﾌｧｲﾙを保存する機能がある。A.dxfをｱｯﾌﾟﾛｰﾄﾞすれば、ｻｰﾊﾞｰにはA.dxfの記録が残る。しかし、その記録がﾌｧｲﾙﾊﾟｽ以上の情報を持たないなら、生産性、BOMの完全性、ﾌｧｲﾙ間の関連性への貢献はほぼｾﾞﾛである。
重要なのはﾌｧｲﾙの背後にあるﾃﾞｰﾀ源である。生産ﾌｧｲﾙは独立した対象ではない。図面は部品から生成され、PDF、DXFなどの平面出力は図面から生成され、3Dﾓﾃﾞﾙ出力も部品から生成される。作成日時や版更新日時だけを記録すると、追跡できているように見えるが、そのﾌｧｲﾙがどの物料に属し、なぜ存在し、どこから再生成すべきかを説明できない。
A.dxfの記録が実際に提供するもの
A.dxfをｻｰﾊﾞｰへ保存した直後の価値は、その場所を把握できることである。生産方式の判断、BOMの完全性、ﾌｧｲﾙ間の関連性には寄与しない。日時や版のﾌｨｰﾙﾄﾞは便利に見えるが、図面も3Dﾓﾃﾞﾙ出力も部品から更新されるなら、それらは結果の時刻を示すだけで、ﾃﾞｰﾀ関係そのものではない。
目的はﾌｧｲﾙを増やすことではない。一意なﾃﾞｰﾀ源から、その物料に対応する全生産ﾌｧｲﾙを取得できる状態を作ることである。
ﾌｧｲﾙ記録からﾃﾞｰﾀ源検索へ
設計ﾃﾞｰﾀ源に物料の固定ｺｰﾄﾞを保持し、検索ｺｰﾄﾞがそのｺｰﾄﾞを使ってA.dxfを取得する方式がある。ﾃﾞｰﾀ源はBOM表にあり、BOMが変われば検索結果も変わる。
全体で見れば、A.dxf、A.pdf、A.stp、A.sldprt、A.slddrwは同じ物料を表す。形式ごとに別のｸﾞﾛｰﾊﾞﾙ主ｷｰを作ると、現実の物料ではなく技術ﾌｧｲﾙを管理することになる。重複する主ｷｰを外すほど、構造は単純になる。
さらに重要になるのは、一意なﾃﾞｰﾀ源の変更を生産ﾌｧｲﾙ全体へ連動させることである。これが自動出力と下流配布の前提になる。
SWTDOの二重索引
SWTDOはこの処理を二重索引と呼ぶ。第一重索引はﾃﾞｰﾀ表の記録、第二重索引は記録を基にｺｰﾄﾞがﾌｧｲﾙを自動検索する仕組みである。記録が業務関係を表現し、ｺｰﾄﾞがその関係を実際のﾌｧｲﾙ結果へ変換する。
命名にはCode_Nameを使う。Codeはｸﾞﾛｰﾊﾞﾙ主ｷｰ、Nameは人が識別するための名称である。ｸﾞﾛｰﾊﾞﾙ主ｷｰが一意性を保証するため、通常の検索にVerは不要になる。版情報は履歴ｽﾅｯﾌﾟとして残せるが、主索引にはしない。
版管理の役割と限界
旧顧客の保守には履歴が必要である。10年前に販売したCQｼﾘﾝﾀﾞｰが何度も技術改善されていれば、交換部品を特定するために販売記録から当時の図面版をたどり、対応する全部品を探す必要がある。この販売時点は、巻き戻せるForkﾉｰﾄﾞとして扱える。
ただし、この場面と日常検索は同じではない。通常の生産ﾌｧｲﾙは一意なﾃﾞｰﾀ源とｸﾞﾛｰﾊﾞﾙ主ｷｰから取得する。契約、保守、旧ﾌﾟﾛｼﾞｪｸﾄのｽﾅｯﾌﾟだけが過去版を必要とする。例外を全体の主索引にすると、通常業務まで版管理のｺｽﾄを負う。
多体、多構成、板金展開図への命名拡張
第二重索引の規則は単純にできる。拡張子が違っても、ﾌｧｲﾙ名の本体を揃える。
Code_Name.sldprt → Code_Name.slddrw → Code_Name.dxfCode_Name.sldprt → Code_Name.stp
多体と多構成では、ﾌｧｲﾙとﾎｽﾄの関係を持たせる。板金には専用の展開図出力を追加するため、Code+実体名_Name.slddrwとする。区切りには+と_を使い、空白を使わない。英語圏と日本語環境の両方で安定し、ProdｼｽﾃﾑとWindowsｴｸｽﾌﾟﾛｰﾗｰでも並び順を揃えやすい。
並び順そのものにも価値がある。安定して並べられるなら、毎回複雑な検索ﾋﾞｭｰを構築する必要はない。ｻｰﾊﾞｰ上の固定orderは、複雑な検索画面より単純で扱いやすい。
最終成果は連動する生産ﾌｧｲﾙ群
設計がBOMを変更すれば、ｼｽﾃﾑはBOMから全生産ﾌｧｲﾙを取得し、配布できる。購買、組立、その他の下流部門は、必要な閲覧権限を得たうえでｸﾗｲｱﾝﾄから資料を取得できる。重要なのは別のﾌｧｲﾙ一覧を増やすことではなく、BOM、ﾌｧｲﾙ検索、権限、生産出力が同じﾃﾞｰﾀ関係を共有することである。