基幹システム統合で、業務と周辺システムの接続をどう整理するか｜支援実績
基幹システムの中では正しく動いている。周辺システムも、それぞれの担当範囲では問題がない。
それでも、データを受け渡す場面になると、処理順、コード、マスタ、データ形式、利用部門ごとの運用差が表に出ることがあります。統合後に同じ画面を使うようになっても、入力する人、確定させるタイミング、エラー時に相談する相手まで揃うとは限りません。
基幹システム統合では、ERP本体の設定や改修だけでは済まない仕事があります。
業務ごとの違いを整理し、周辺システムとの接続条件を決める。テストや移行を経て、統合後の運用へ渡していく。そこまで見ておかなければ、本番後に確認すべきことが運用側へ残ってしまいます。
ディーシステムは、複数の業務システムが関わる基幹システム統合において、業務フローの差異確認、フィット＆ギャップ、要件整理、データ連携・I/F構築、周辺システムとの接続確認、テスト・移行準備、運用保守への引継ぎを支援してきました。
ここでは、基幹システム統合を進める際に、どのような整理が必要になるのかを、支援範囲に沿ってご紹介します。
基幹システム統合で、最初に見るべき業務とデータの流れ
統合の計画では、早い段階で改修対象や連携対象を決める必要があります。見積もりを作り、ベンダーへ依頼し、テストや移行の予定を引くためです。
ただ、対象システムを決める前に、業務とデータの流れを見なければならない場合があります。
同じ業務名で呼ばれていても、実際の進め方が違うことがあります。ある部門では、入力したデータを別の担当者が確認してから基幹システムへ渡している。別の部門では、周辺システムで処理を完了させた後にデータが連携されている。同じ項目名でも、入力する目的や利用する部門が異なることもあります。
こうした違いを見ないまま、「どのシステムを残すか」「どのデータを連携するか」だけを決めると、設計が進んだ後で前提が戻ってきます。
そのデータは、その時点では確定していない。
同じコードでも、部門ごとに違う意味で使われている。
連携先に必要な項目が、元の業務では作られていない。
統合では、システムごとの機能を並べるだけでは不十分です。業務の中でデータがいつ作られ、誰が使い、どこで確定するのか。そこを見ながら、改修対象や連携条件を決めていく必要があります。
同じ業務名でも、同じ処理とは限らない
ディーシステムでは、既存の業務フローとシステムを確認し、統合後の運用に合わせてフィット＆ギャップを整理します。
フィット＆ギャップでは、既存のやり方が統合後の業務やシステムに合うかを見ます。ただ、「合う」「合わない」を一覧にするだけでは、改修の条件は決まりません。
たとえば、片方の部門では使われている区分が、もう片方には存在しない場合があります。その違いが、業務上必要なルールなのか、過去の設定が残っているだけなのか、基幹システムへ渡すために必要な情報なのかで、対応は変わります。
業務側で揃えるべきことまで、すべてシステム改修で吸収しようとすると、例外処理が増えていきます。統合後にその理由を説明できる人がいなければ、次の改修で同じ検討を繰り返すことになります。
一方で、コード変換やデータ加工で扱える差異まで利用部門の手作業に任せれば、日々の処理が複雑になります。担当者ごとの対応差が生まれ、後から修正や確認が必要になることもあります。
差異を見つけたときは、業務側で決める内容と、システム側で吸収する内容を分けて考えます。
誰が入力するのか。
誰が内容を確認するのか。
いつ値を確定させるのか。
どの値を変換し、どの値をそのまま渡すのか。
エラー時に、どの担当がどこまで対応するのか。
項目対応表だけでは、こうした前提までは見えません。業務とシステムの双方を見ながら条件を整理することで、後工程での手戻りを減らしていきます。
I/Fの仕様は、項目定義だけでは決まらない
基幹システムと周辺システムをつなぐときは、項目の定義やファイル形式といった目に見える部分に意識が向きがちです。
ただ、その前に一度立ち止まり、データがどこで作られているのか、誰が内容を見ているのか、どのタイミングで確定するのかを確認しておく必要があります。
周辺システムに値が入っていても、そのまま基幹システムに渡せるとは限りません。
まだ承認が終わっていない。参照するマスタが更新されていない。別の処理が終わっていないため、必要な項目がそろっていない。こうした状態で連携してしまうと、あとからデータを直したり差し戻したりする手間が発生します。
データの作成元、確定の条件、参照するマスタ、連携後に起こり得る例外が見えていなければ、連携仕様は決められません。
エラーが起きた場合も、I/Fだけを見て原因が分かるとは限りません。上流側の処理が止まっているのか、マスタ設定に差があるのか、業務側の作業が完了していないのか、変換条件が統合後のルールに合っていないのか。複数の条件が重なることがあります。
ディーシステムでは、業務部門の要望をそのまま技術仕様へ置き換えるのではなく、データの流れと利用条件を確認します。そのうえで、基幹システム側・周辺システム側の担当者が判断できる粒度まで要件をまとめていきます。
対象外にした周辺システムも、後工程で影響する
基幹システムの統合では、いきなり全部を切り替えるのではなく、段階的に進めることがよくあります。一度に変えてしまうと現場への影響が大きくなるため、少しずつ移行していく方が現実的なケースも多いからです。
ただし、今回の対象から外したシステムであっても、基幹システムとどこかでつながっていることは少なくありません。
コード体系や参照するマスタ、連携する項目やデータ形式、変換ルールや連携のタイミングが変わると、後から改修するシステムにも影響します。
対象外だからといって、今回の検討から完全に切り離せるとは限りません。
後続の改修を始めたときに、すでに決めた仕様と合わないことが分かれば、周辺システムだけで吸収できるのか、基幹システム側の設定も見直すのかを再度検討する必要があります。関係者が増えるほど、設計判断を戻す負荷も大きくなります。
そこで、段階移行では、対象外のシステムについても接続点を見ておきます。
どのデータを受け渡しているか。
統合後のマスタをどのように参照するか。
変換処理はどこにあるか。
次の改修で影響を受ける条件は何か。
すべてを先に改修する必要はありません。ただ、後続で見るべき場所を残しておかなければ、対象外にした仕事が、後から大きな確認事項として戻ってきます。
テストで見つかった前提を、運用に残せているか
テストでは、仕様書に書かれていない業務上・運用上の前提が出てきます。
テストデータの作り方、処理の順番、マスタの状態、他システムとの連携タイミング、利用部門側の準備。画面上では正しく動いていても、実際の業務で使う条件がそろっていなければ、本番移行後に問題になります。
本番移行の準備では、作業手順に加えて、監視、関係者への連絡、利用部門への案内、復旧後に見るべき情報まで決めておきます。
技術作業だけを計画しても、想定外の通知や連携不具合が起きたときに、誰がどの順番で動くかが決まっていなければ、対応が遅れます。
障害対応でも、復旧と再発防止は分けて扱います。
まずは業務を止めないように復旧を優先する。そのうえで、何が原因だったのかを確認し、恒久的な対応が必要なものを見極める。必要に応じて、運用手順や監視の設定、連携条件にも反映していきます。
対応の経緯が個人の記憶やメールだけに残っていると、同じようなトラブルが起きたときに、また一から調べ直すことになります。
運用保守へ引き継ぐ際には、操作手順だけでは十分ではありません。
どのデータや処理が基幹システムに影響するのか。異常が起きたときには、まずどこを確認するのか。業務部門へは何を確認し、ベンダーへ調査を依頼する際にはどの情報を渡すのか。
過去に注意が必要だった条件も含めて、運用側に残しておく必要があります。
こうした情報を渡すことで、運用担当者は次に何を見るべきかを考え始められます。運用で見つかった前提漏れや例外対応は、次の改修や段階移行の検討にも戻していきます。
基幹システム統合では、検討段階、設計段階、移行段階、運用引継ぎのそれぞれで、整理すべき論点が変わります。
すでに統合方針が決まっている場合でも、連携仕様、周辺システムへの影響、テスト条件、運用保守への引継ぎで確認事項が残ることがあります。方針検討の段階であれば、業務差異やデータの流れを確認し、どこから検討すべきかを明確にすることも必要です。
ディーシステムが支援できる範囲
ディーシステムでは、プロジェクトの状況に応じて、次のような支援を行っています。
・業務差異の把握、業務フローの整理
・フィット＆ギャップ、要件整理
・データの出所、マスタ、確定条件、処理順の整理
・基幹システムと周辺システムのデータ連携・I/F整理
・複数ベンダーが関わる改修プロジェクトでの確認事項整理
・段階移行における後続システムへの影響確認
・テスト・本番移行準備での確認事項整理
・障害原因の整理、運用保守への引継ぎ支援
統合方針がすでに決まっている場合は、連携仕様の整理や後続システムへの影響確認といった、具体的な実行フェーズからご支援に入ることが可能です。
一方で、方針検討の段階からでもご相談いただけます。業務差異やデータの流れを確認し、どこを改修対象とするか、どのような確認が必要かを明確にするところから伴走します。
支援内容は、貴社の体制や既存ベンダーとの役割分担、対象業務、統合の進め方に応じて柔軟に設計します。すでに役割が定まっているプロジェクトでは、その範囲に合わせて参画し、検討段階であれば論点整理から体制づくりまで一貫してご支援します。
ディーシステムのプロジェクト実績
ディーシステムでは、製薬ヘルプデスク、基幹システム統合、情報システム部支援、クラウド移行後の運用など、顧客現場で担ってきた役割と、支援によって生まれた変化を紹介しています。
ほかのプロジェクト実績は、こちらの案内記事からご覧いただけます。
▶ ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち
基幹システム統合の進め方を整理したい方へ
ERP・基幹システムの統合では、システムの改修範囲だけでなく、業務差異、データの流れ、周辺システムとの接続条件、テスト、本番移行、運用保守への引継ぎまで整理する必要があります。
統合方針を検討している段階では、どの業務やシステムから確認すべきかを整理します。
すでに設計や移行準備が進んでいる場合は、連携仕様、マスタやコードの違い、後続システムへの影響、テスト条件、運用側に残すべき情報など、実行段階で残っている論点からご支援できます。
ディーシステムでは、貴社の体制、既存ベンダーとの役割分担、対象業務、プロジェクトの進行状況に応じて支援範囲を設計します。
基幹システム統合で、業務と周辺システムの接続条件や確認事項を整理したい方は、ご相談ください。
【基幹システム統合について相談する】
次に読む記事
ERP導入後には、どのような仕事が続くのか
基幹システムは、統合や導入が完了すれば終わりではありません。
問い合わせ対応、障害調査、データ確認、権限管理、定例作業、改善対応など、安定して使い続けるための運用保守が続きます。
ERP運用保守で行う8つの業務を紹介します。
ディーシステムのほかの支援実績を見る
ディーシステムでは、基幹システム統合のほか、製薬ヘルプデスクのナレッジ整備、情報システム部門の運用支援、複数ベンダーの管理、システム導入支援などにも関わっています。
顧客現場でどのような課題を受け取り、どのような役割を担ってきたのかを、プロジェクト実績から紹介します。
システムを変更する前に、なぜ構成を確認するのか
影響を抑えてシステムを変更するには、対象機能だけを見るのでは不十分です。
処理経路、既存コード、実データ、周辺機能との関係を確認し、当初案より影響の小さい改修方法を選ぶまでの過程を紹介します。
