＜前略＞
早速の御回答ありがとうございました。
＜中略＞
マスターＢＯＭの考え方が少し解りました。「製品別ＢＯＭのバージョン管理」の話ですが部品単位の変更管理をしっかり行えば製品別には不要ということですね。
しつこい様ですが、ＢＯＭを全く理解していないのでさらに教えて下さい。プログラムのＯＳバージョンのように最終成果物（一番上の親）の変更管理はＢＯＭの世界では一般的に行わないのですか。例えば製品コードＡ００１に対するＢＯＭコード（例えばＡ００１−００１）みたいなものは不要ですか。
＜後略＞
当然、製品の固有名詞にあたる、コード番号は、あらゆる生産を管理してゆく上で必要です。
しかしご質問の枝番が要るか否かは、それぞれの製造業が定義するモデルチェンジの定義や、製品コードに持たす意味合い、さらには、ＢＯＭを用いた生産形態で大きく変わってくると思います。
私が一般的に定義するモデルチェンジは、量産出図と言う形で、新しいＢＯＭとともに複数のAssy、サブAssy、部品などが一斉に変更される形態を指します。
一般的に言われる、マイナーチェンジ、年度モデル、フルモデルチェンジがこれにあてはまります。また、種機種をベースに開発されるバリエーション製品もこの範疇に入ります。
一方必要に応じてその都度行われる設計変更は、例えその部品の互換性が途絶えてしまう設計変更でも、都度行われる限りは、製品モデルとしては、同一のモデルというとらえ方をしております。
そして前者の場合には、その都度新しいＢＯＭを作成（モデルチェンジ前のＢＯＭを編集して用いる場合でも）し、後者の場合には、既存のマスターＢＯＭを設計変更処理により変更を加える（当然旧品処置や補給部品の号機管理も含め）と言う考え方です。
ですからマイナーチェンジであろうと全くの新製品であろうと、その扱いに、原則区別はないと言う考え方です。
ご質問は、この新しく作成されるＢＯＭテーブルの名称を、Ａ００１−００１と言う風に付ける必要があるか否かという趣旨だと思いますが、全てがマスターＢＯＭで管理される”ものづくり”を行う上では、特に必須ではありません。
＊＊＊さんの会社で、Ａ００１−００１がＡ００１−０００のマイナーチェンジ機種であること、さらにＡ００１−ｂ０１がＡ００１−００１の派生機種である事を、コード番号で関係者に知らせようと言う目的をお持ちでしたら、ご質問のようなコード体系を持つことは否ではなく、所定のルールを作成して運用すればよい事だと言えるでしょう。
しかしＲＤＢでは、マイナーチェンジの系譜や派生製品の相関は、別テーブルで管理すれば済むことですので、あえて一生懸命コードを工夫して、コード番号を付けなくても良いと思います。
ところで、＊＊＊さんの会社では何の為に何を狙って、新しいＢＯＭを構築しようとしているのですか？ 直近、５年後、１０年後、２０年後の貴社の生産形態を、どの様に持って行きたいのかを、まず示して頂いてからのご質問でないと、的確なお答えが叶いません。
余談ですが、私が関わるケースでは、新しいＢＯＭが作成出図される開発案件は、仮にその変更内容が少なくても、全て開発計画に載せて、ＦＳ、ＤＲ０の関門を通過することを求めております。