海外拠点ERP導入プロジェクトにおけるテンプレートアプローチと品質・リスク管理

2022年2月に「海外拠点ERP導入におけるテンプレートアプローチの課題」というテーマでニュースレターをお届けしたが、ERP導入プロジェクトにおいて時間軸としては比較的上流の議論が中心だったため、今回は「テンプレート展開のその後」に焦点を当てて、プロジェクト管理上の留意点、特に東南アジアで留意すべき点を考察することとする。

● ERP導入プロジェクトの工程定義および取り上げる対象となる工程

ERP導入プロジェクトとは、「新しいERPシステムやプロセスの導入に伴う一連の工程」であり、主要工程を時系列に沿って並べると、テンプレート作成⇒テンプレート展開による業務整理⇒独自要件に基づく開発⇒テスト実行⇒ユーザ教育という流れになる。それぞれの工程の定義は下記の通り。

1. テンプレート作成: 基本的なフレームワークや標準的な設定を含んだテンプレートの作成
2. テンプレート展開による業務整理: テンプレートを使用して、現行の業務プロセスを整理。システムやプロセスの要件に基づき、業務フローを再構築し、最適化を図る
3. 独自要件に基づく開発: テンプレートに独自要件を組み込み、システムやプロセスを開発・再定義。独自要件は、特定のビジネスニーズや業界の規制に基づく。
4. テスト実行: 開発後のシステムをプロセスに沿ってテスト。シナリオに基づいてテストスクリプトを作成し、動作・品質確認を実施。
5. ユーザ教育: システムやプロセスのユーザに対する教育。ユーザは新しいシステムやプロセスの使い方や利点について学ぶことで、導入後のスムーズな業務運営に寄与。

冒頭に言及の通り、本稿では前回記事で取り上げた1・2に続く3から5までの工程とそれらを取り巻く課題・リスク、更には「品質・リスク管理」という、往々にしてプロジェクトにおいて十分な対応が講じづらい視点について取り上げる。

● 該当工程における課題・リスク

前項で言及したERP導入プロジェクトの3工程には、それぞれ以下のような課題が見受けられる。

① ビジネスプロセス・オペレーションの十分な理解とその困難性：“独自要件に基づく開発“工程で見られる課題。ビジネスプロセスの把握が困難であるがゆえに、要件が不明確になったり、認識のずれが生じたりすることで、後続工程での追加開発のリスクが高まる。

② テストスクリプト作成・更新の難航：“テスト実行”工程においては、テストスクリプトの作成が第一歩となるが、システムやプロセスの複雑さや仕様変更の頻発により、その第一歩すら困難となることも珍しくない。また、テストカバレッジや効率性の観点から、十分なテストケースが作成されず、再テストのリスクが高まる。

③ 関連各所とのコンフリクト：“ユーザ教育”工程で見られる課題。ビジネスオペレーションを十分に理解できていないメンバーが参画している場合や、社内チームメンバーのコミットメントが低い場合、エンドユーザと社内チームメンバーとの板挟みという事象が往々にして発生する。また、部署の異なるエンドユーザの理解度やスキルレベルに合わせた教育を行うことは困難であり、システム稼働後や新プロセスへの移行後の手厚いフォローアップが必要になるリスクが高まる。

● 品質・リスク管理観点でのソリューション

上記課題で触れたリスクを最小限のものとするために、品質担保とリスク管理が非常に重要である。以下筆者の経験も交えて、どのようなソリューションが考えられるかについて述べたい。

①のビジネスプロセス・オペレーションの十分な理解とその困難性については、要件定義段階での文書化およびプロトタイプ・デモンストレーションを含んだワークショップを実施することで要件への理解を深めることが対応策のひとつとしてあげられる。往々にして、新しいシステム導入は現場の拒否反応を招きやすい。デモンストレーションをたたきとして対話・議論を深め、システムを導入する側とシステムを受け入れる側の心理的な距離を縮め、お互いが歩み寄ることで、その後のプロジェクト運営において負荷の少ないコミュニケーションのもととなる信頼関係の土台が築ける。特に東南アジア地域においては、各国固有の法規制・税制に基づいたビジネスプロセスやオペレーションの検討が重要であるため、現場を理解するメンバーとの討議を経て、業務知見を深めることは極めて重要である。余談ながら、システムの見た目（＝インターフェース）へも現場のユーザは拒否感を抱きがちなので、早々にインターフェースに触れる機会を設ける良い機会にもなる。

②のテストスクリプト作成・更新の難航については、深い業界知見を有する第三者によるスクリプトレビューを実施することで十分性を担保した上で、可能な限りテスト実行を自動化し、テスターによるぶれを回避することが薦められる。特にテストのレビュー経験をお持ちの方には想像しやすいと思うが、テスト実行後の証跡確認作業は、テスターによる作業手法や証跡の取り方が違うことで、往々にしてハードワークになりやすい。東南アジアではシステム導入の経験が少ないケースも多く（基幹システムの導入等について数年～十年単位の期間が空くケースも散見される）、そもそもシステム導入の経験や、前回導入時の経験を持つメンバーがいないことも珍しくない。結果、本来気を配るべきテストスクリプトを徐々に実のあるものに育てていく活動以上に、まずは証跡確保等の基本作業の手法を徹底させることが目的になってしまうケースも多い。このため、テスターの作業を自動録画・システム上で再現する機能も増えつつあるので、スクリプトレビューは思い切って第三者機関の知恵を借りる、などの他の打ち手と合わせて、ぜひテスト実行工程で活用されたい。

③の関連各所とのコンフリクトについては、事前に課題となりそうな重点個所について小規模な教育リハーサルを実施し、フィードバックを踏まえたカリキュラム設計を行うことで、各々後々のリスクを最小限に抑えることができると考える。スモールスタート後の横展開はまずはキーパーソンとの関係性を築く作業に他ならず、妥当性の高いフィードバックも受けやすいので、後々の横展開において他のユーザからの疑問や要望にも、自信をもって対応できるようになるというメリットがある。しかし、人材の流動性が高い国がある一方で、長期にわたる業務の属人化も経営課題として顕在化することの多い東南アジア地域においては、同じ部署内であっても他のメンバーのタスクへの理解が十分でない、あるいは理解度に相当なばらつきがあるケースも散見される。このため、筆者個人の経験では、ユーザ教育の前段となる小規模な会議体において、同じ部署内での他メンバーのタスク理解が相互に促進される場面によく遭遇したため、前述のとおり教育リハーサルは非常に効果的であると考える。また、このような会議体を踏まえてのユーザ教育は、関連各所のメンバー間にとどまらず、部署内での関係性構築にも資するものであり、その後のスムーズで省エネルギーな他ユーザとの会話につながるため、推奨したい。

一方で、上記に挙げたソリューションと同様に、妥当性のある品質管理とリスク管理手法の確立と遂行の徹底も非常に重要である。PDCAサイクルの回らないシステム導入プロジェクトにおいては、往々にして残課題が山積され、プロジェクト期間の無意味な延長を招く。特に社内プロジェクトとしてシステムやプロセスを導入すると、このような事態が発生する。総額としてのコスト抑制と、有意義な導入作業実施のためにも、第三者機関の活用も視野に入れた品質・リスク管理はプロジェクト管理の肝である。