2021.02.08 ノウハウ

海外事業における業務デジタル化の勘所（第4回）プロジェクトの立ち上げと進め方－業務・システム刷新の実現に向けて

RFPの回答を基にソリューション及びベンダー選定が完了した後は、新システムの導入プロジェクトを実行するフェーズに移っていきます。本回ではプロジェクトの進め方や注意点についてお話していきます。

プロジェクトの体制づくりが最初のキーサクセスファクターに

プロジェクトを成功に導くためには、適切なプロジェクト体制を構築することが重要となります。社内プロジェクトにどのような人材を配置するべきかと質問されることがありますが、私からお伝えするアドバイスとしては、以下のようなロールを適材適所に配置することです。

a)意思決定者、b)管理・調整役、c)実務のプロ

一般的なプロジェクト体制を図１に示しました。意思決定力については、プロジェクトオーナーや各業務チームの責任者であるプロセスオーナーが持つべきケイパビリティとなります。管理・調整役はプロジェクトマネージャー（PM）、PMサポートなどプロジェクト管理チームが担う役割となります。特にプロジェクトマネージャーは各業務について精通している必要はありませんが、取りまとめや課題切り分け作業が得意で、各部門に顔が効く人材の起用が望ましいです。実務のプロについては、プロジェクトで発生する様々な実作業、例えばデータ準備や業務シミュレーションの実行を滞りなく進められるキーユーザーのロールに求められます。ここでいう実務には、データを正確に入力する、入力結果をチェックする、Excelなどのツールを使ってデータを作成し検証する、などが該当します。その他にもプロジェクトを運営していく上で、重要なロールは多々ありますが、ここでは割愛します。

S4_Pic1

図1：プロジェクト体制図の例

キックオフでプロジェクト目標の浸透と関係者のコミットメントの引き出しを

プロジェクト体制を決めた後は、プロジェクトの目標を各関係者に認知してもらい、彼らのコミットメントを得る必要があります。そのためにプロジェクトのキックオフ会議を実施します。キックオフ会議で提示されるプロジェクト目標は全社内関係者に浸透するよう、分かりやすくイメージ図を活用したものであることが望ましいでしょう。特に海外での導入プロジェクトとなれば、言葉での浸透は難しく、よりシンプルで視覚に訴えるメッセージが有効となります。また社内でプロジェクトの認知が広まるように、プロジェクトに名前を付けて周知することも効果的です。そして、各担当者のプロジェクトへのコミットメントを引き出すためにも、キックオフ会議上では各関係者に目標達成に向けた意気込みを発言してもらう事が大切になります。

キックオフ会議ではプロジェクトのタイムラインを共有し、マイルストーン毎の各部門の作業内容及び作業負荷について予め認識を共有しておくことが重要です。各部門でプロジェクトの活動時期に合わせて、人員の調整をしてもらう必要があるからです。例としてERPシステム導入プロジェクトのマイルストーンを図２で示しました。

ERPシステム導入プロジェクトのマイルストーン

図2：ERPシステム導入プロジェクトのマイルストーン

プロジェクト成功のキーとなるマイルストーンとは

筆者の経験から、プロジェクトの成否を左右する重要なマイルストーンを特に挙げるとすればFit&Gap(要件定義)、データ移行の２つであると考えます。本来は全てのプロジェクトマイルストーンそれぞれの重要性について記載したいところですが、今回は上述の２つに絞って記載したいと思います。なお、ここでの前提はパッケージシステムの導入とし、独自にシステムを開発するスクラッチ型プロジェクトは前提としていません。

（1） Fit＆Gap（要件定義）で適切なスコープのコントロールが重要

①　パッケージシステムの得手不得手を理解すること

Fit&Gapでユーザー側が理解しておくべきことは、世の中に出回っているパッケージシステムには得意分野と不得意分野があるという事です。一般的にパッケージシステムは業界でよく使われる機能群を搭載しており、標準的な業務フローへの対応がされています。多数の会社の業務要件を集約し、コア業務モデルを抽出することで、いわゆる業界のベストプラクティスというものを用意しているのです。そのため、世の中で定型の業務フローが確立されている業務エリアについてはパッケージのベストプラクティスが導入しやすくなります。一方で会社ごとに独特な要件が発生しやすい業務やイレギュラーパターンが多発する業務への適応はあまり得意としません。

例えばERPシステムでは、販売管理系、調達系、経理系などの業務は比較的パッケージシステムとの相性がよく、ギャップが少なく導入できます。一方で製造現場管理などの個別要件が多い業務への対応については、ギャップが多くなりやすく、運用をシステムに乗せることが困難になることが多々あります。製造工程や作業管理の方法、業務におけるイレギュラーパターンは会社や業種によって多種多様で、どこでも通用する標準のフローというのが確立しづらいのです。

もう少し具体的な例を使って説明しますと、製造現場における中間品の工程間移動の実績及び中間在庫を全てシステムで確認するという要件があったとします。製造工程では、工程飛ばし、工程戻り、製造ロットの分割あるいは統合、副産物品の発生、途中工程での受け入れ、など様々なパターンが発生し得るものです。こういったパターンを全てERPシステムで対応させようとすると、様々な業務ロジック、データ種類を持たせることになります。一般的なERPシステムでは、イレギュラーパターンへの対応には限界があり、全て対応できるようにするためにはカスタマイズが必要になる場合が多いです。しかし、あまり複雑なカスタマイズを入れてしまうと、将来業務要件が変わった際の変更の柔軟性を失うことになり、効果的なシステム施策になりません。

②　データ入力業務の複雑化を避けること

また、現場データを管理するためには日々発生するデータの入力やチェック方法を考えなければなりません。システムが導入されれば、勝手にデータが収集され、分析のために活用できるというものではありません。日々のトランザクション量が多く、かつ複雑な業務領域についてシステム化しようとする場合、入力作業やデータのチェック作業にかかる工数というものも増加します（入力・チェック業務を完全にオートメーション化するケースを除きます）。統制の効きやすい日本国内で入力・チェックの作業の徹底を行うことは可能かもしれませんが、海外でのオペレーションとなると複雑すぎるシステム運用は定着せず、結局Excelによるデータ管理や紙運用をした方が現場に浸透しやすいのです。

以上のような導入パッケージシステムの得意分野、不得意分野を理解した上で、業務要件への対応を考えること、複雑な業務を無理にシステム化しないようスコープのコントロールすることが、初期段階における成功のキーになります。

（2）データ移行の設計・検証がプロジェクトの成否を左右する

プロジェクト失敗の原因で多いのが、新システムに移行したデータの質が悪いことによる問題です。データ移行には、マスターデータの移行とトランザクションデータの移行の２種類があります。どちらも非常に重要なものですが、ここではマスターデータについて触れたいと思います。

①　まず始めにコード体系とデータ項目の設計を

マスターデータとは、商品情報や得意先情報など、一度設定したら繰り返し使用されるもので、システム運用の基礎データとなるものです。マスターデータを新システムに移行するにあたっては、1)データ上のコード体系を定義、2)マスターデータ項目の定義、といった前段階作業が必要になります

コード体系の定義は、システムの運用後の情報の識別し易さや、使い易さに影響する作業です。例えば、商品コードには、担当者がどの商品かが分かるように、サイズ、カラー、材質などの情報をコードで表現することが重要になります。他には在庫の保管場所コードがどの場所を表しているか分かるようコード体系を工夫するという例もあります。また、勘定科目コードなどはグローバルで体系の標準化がなされる事が多く、本社IT・経理とコード規則を確認しておく必要があります。コード体系に関するルールを明確に定義せずに運用が始まると、後で非常に使いづらいシステムとなってしまうので注意が必要です。新しいシステムをしっかりと運用に乗せるためにも、プロジェクトの早い段階で体系作りを徹底しましょう。

マスターデータ項目の定義は日々発生するトランザクションデータの分析方法を設計する作業になります。例えば、製品の販売トランザクションデータから売上や収益を分析するための軸として、製品グループ別、生産工場別、仕向け先別などを設定することがあります。これらは販売で使用される商品マスタやオーダー情報そのものの付属情報として定義されます。このように分析軸を設定し、そこで使われるデータの設計をすることは、経営判断に必要な情報を整備する事に他なりません。またこのような分析軸の設計はグローバルで標準化し統一するという本社要件も考慮する必要があります。ひとたび運用が始まってしまえば、大量の業務トランザクションデータが貯まっていくことになりますが、分析軸の設計を間違えると貯まったデータがうまく活用できなかったり、海外拠点ごとに不統一な分析軸が取られ、拠点横断的にデータを見るのが困難になるのです。

②　データ精度を上げるための業務シミュレーション

マスターデータの移行における成功のキーは業務シミュレーションを上手に活用し、しっかりとデータの検証することです。作成されたマスターデータを実システム環境に登録し、本番業務を見据えて業務シミュレーションを行う事で、当初設定したデータ要件が実現されているかどうか検証できます。また実システムでデータを動かすことで、マスターデータの精度が本番運用に耐えうるものかどうか評価することも可能なのです。マスターデータを十分に検証するためにも、早めにコード定義とデータ項目の定義作業に着手し、ステークホルダーたちをシミュレーション作業に巻き込んでデータ検証作業を行いましょう。

本話ではプロジェクトの立ち上げと進め方についてお話ししました。海外事業体においてはリソースに限りがあり、プロジェクト体制の構築は特に難易度が高いかもしれません。しかし、変革を確実に成し遂げるためには、プロジェクト目標への共感を醸成し、ローカルメンバーの強力な関与を引き出すことが重要です。これにより、各マイルストーンにおけるプロジェクトの作業品質を高めることに繋がるのです。

第5回「現代のビジネス変革を牽引するデジタルトランスフォーメーションとは？」へ続く

第1回目から読む場合はこちら