それでは、これまで私が経験したERPパッケージの組織変更対応パターン例を示しておこう。

① システム的に組織変更対応を行わない。業績管理は手作業で対応する。

② 組織変更の対象とならない大きな単位で、組織設定を行う。

③ システムではなく、手作業によって組織変更対応を行う。

④ 組織変更の対象とならない、実組織より小さな組織構造をERPに設定する（対応工数と効果のバランスが良好な推奨パターン）。

⑤ 伝票生成時に、マスタの最新の組織コードを付加するようアドオン開発を行う（マスタ更新のみですむため、システム開発工数負荷は低い）。

⑥ データを外部システムにコピーし、外部システムで業績管理を行う。

⑦ ERP内に業績管理のためのシステムを別途アドオン開発する。

⑧ ERPの標準アプリケーションを使用して、変更対象の組織コードを更新する（一部制限あり）。

⑨ ERPの標準アプリケーションを使用して、変更対象の組織コードが入ったデータをいったん取消し、その後、新組織コードでデータの生成を行う。

⑩ ERPの標準アプリケーションを使用して、変更対象の組織コードが入ったデータの相殺データを生成した後、新たに新組織コードでデータの生成を行う。

そうだね。今回は説明しないが、それぞれのパターンごとにメリット・デメリットがあり、それを踏まえて対応をしていく必要がある。もちろん、これらのパターンでは対応できないという判断になることもありうる。その際には、コード設計まで戻って再考することになる。いずれにしても、スクラッチ開発と同様に考えてプロジェクトを進めていくと失敗するリスクがある。設計の初期段階から、組織変更対応についても留意して進めていくことが大きなポイントかな。

コードとマスタの標準化/統合化のところでも話をしたけれども、これらの設計を行うにあたって、個々の利害関係者がバラバラに検討してもなかなかなかできるものではないかな。だから、責任を持つ組織や担当者を明確にし、利害関係者のコンフリクトを解消しながら、全体最適で設計してシステムを構築していくようにしたい。組織変更対応はコードに大きく影響するところがあるので、コード設計の主管チームに組織変更対応の役割を兼任してもらうというのもひとつの方法だね。