ERP導入方法論

2019.04.26 日本オラクル株式会社海老原善健

メニュー：

NetSuiteのみならずERPの導入に際して、導入の手順やその時に纏めるべき資料や作業内容などを「導入方法論」としてプロジェクトの方向を規定しているものがあります。

NetSuiteの導入方法論は「One Methodology」で、7つのフェーズで構成されています。

各フェーズではプロジェクトを推進するために必要なドキュメントの作成をする必要があります。NetSuiteのコンサルタントが顧客に提出してきたドキュメントのテンプレートを使うことにより作成効率と情報の網羅性が確保されています。フェーズにはタスクが設定されており、事前定義されたタスクを担当者が着実に実施していくことによりプロジェクトが進んできます。

今回は次のようなプロジェクトでの役割を規定しています。

ロール	一般的な役職（部門）	主なタスク
監督者	経営層 / 経営企画 / 管理部門	経営判断
プロジェクトマネージャ	プロジェクト推進責任者	プロジェクトを統括全体進捗管理変更履歴管理
プロジェクトメンバー	プロジェクト推進担当者	プロジェクトを推進タスク進捗管理変更履歴管理
部門担当者	部門長もしくはその代理	部門所見を統一、部門タスクを管理部門内担当者を管理
ユーザー	一般従業員	プロジェクトから割り当てられたタスクを実施
開発者 / 設定者	情報システム部門 / 導入業者	決定事項に基づいて設定を実施決定事項に基づいて開発などを実施

導入プロジェクトを考えるとき、最初に考えること

プロジェクトの開始から終了までの7フェーズとして定義しています。こちらは「プロジェクト開始」からのフェーズですから、プロジェクトを開始する前の段階があります。

どのようなパッケージを使って業務の改善を図っていくのか？導入をする際に自社リソースだけで行うのか、導入業者を使うのか？大まかな予算は？期間は？などのプロジェクトを開始するにあたっての骨子を考え、決定できる項目は決定して、文書化しておくことをお勧めします。

業者とともに導入プロジェクトを進める際には、製品の選択から導入プロセスまでをまとめたRFPを作成する必要があります。

RFPとは、情報システムの導入や業務委託を行うにあたり、発注先候補の事業者に具体的な提案を依頼する文書。 システムの目的や概要、要件や制約条件などが記述されているもの

ホームページのデザインの依頼などであれば依頼する内容がわかりやすいのですが、全社で使うERPに対するRFPを作成する場合にはその内容は多岐にわたり複雑になります。そのため、現在のシステムやプロセス、データを基本情報として作成することが多いのですが「現在のシステムをERPで再現すること」がゴールではありません。

現在のシステム、プロセスの情報を纏めて現状を把握して将来目指す理想像を提案してもらうRFPであることが重要です。RFPを纏めることはとても難しいように感じますが、難しいのではなくて情報が多岐にわたるため「手間がかかる」だけです。

一般的に纏めるべき内容を上げていきます。参考にしていただければと思います。

後述しますが、担当者の作業責任分掌の所在を定義する「作業範囲定義書」もRFPの一部として定義することもあります。

概要

RFP文書の目的
一般的な文書説明を記載します。ここが重要ではありませんので何でも構いません
システム導入に至った背景
なぜ導入プロジェクトを開始することにしたのかを記述、端的にまとめてください
導入をすることで解決したい問題
経営視点で見た「何を解決したいのか？」を記述します、詳細の業務を含めません
プロジェクトのゴール
問題すべてを解決することが重要ですが、ゴールを規定して着地点を示します。導入範囲が広い場合や時間の制約がある場合は複数段階のプロジェクトとして定義してもよいでしょう。重要なのは「これを実現したい」という項目を端的に挙げることです。導入自体がゴールではありません。
プロジェクトの範囲
社内システム全体の見直しであってもしっかり範囲を指定します（商談管理と見積、受注処理から請求回収まで　などと具体的に）社内の言葉と業者の言葉が違って齟齬がないようにシステム構成範囲を図式化すると理解が早いです　
会社情報組織図プロジェクト体制
プロジェクト範囲に対してどのような部署が関連し、全体像も一緒に説明します
現在のシステム構成
現在どのようなシステムで業務を行っているかを全体像で説明、更に「システム＋使用部門」のリストがあるとさらに理解しやすいパッケージなどではなく、手作りであればその概要説明が必要です。入力画面と帳票のイメージがあれば理解しやすい見積を依頼するためには情報が必要で、取扱商品数XXXX点、在庫数量XXXX点　などの情報を拠点ごとに年間の請求書発行数　XXX　年間の発注書 XXX取引会社数　顧客 XXX社　仕入先　XXXX　パートナー契約　XXXX　従業員　XXXXなどの情報を昨年の実績をもとに提示します。店舗数や拠点も記載してください。想定されるユーザー部門とその従業員数も記載します、ライセンスの見積にかかわります。取引の中で使っている伝票の種類も提示したほうがいいです。業務の流れはほとんどの会社で変わりがありませんが。複数の取引のやり方がある場合考慮すべき情報が増えます。請求書発行のプロセスが４つ（一般官公庁パートナー代理店）あり、それぞれ伝票が違うなど

提案依頼内容

提案に盛り込んでほしい情報を記載します。提案に外せない情報もきっちりと明記してください

会社情報 / 担当部門情報
提案を行った会社の基本情報とその部門の情報
プロジェクト体制図
プロジェクトマネジメント方法
プロジェクト進捗管理方法
提案システム概要
提案システム構成
運用保守に関する提案
ユーザー教育に関する提案
納品物一覧 / ドキュメントのサンプル
概算費用
契約内容
導入に関する制約事項

参考資料

導入事例
製品カタログもしくは　参照できる資料のリスト

このような情報を受け取り、製品や業者の選定に入ります。

[RELATED_POSTS]

それぞれのフェーズの概要と関係者について

フェーズ	フェーズ概要	フェーズ参加者
開始	プロジェクト全体の全体像を確定します。対象導入範囲や時間軸、予算とその配分、マイルストーンとタスクの担当者をアサインします。また、導入対象範囲が確定した後、プロジェクトメンバーや従業員に対するトレーニング計画も策定します。	■監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 □ユーザー ■開発者 / 設定者
分析	業務要件の分析定義を実施します。現在のシステムの状況とビジネスプロセスを分析して、将来目指すシステムを最終確定します。分析フェーズの最終確定を目標として後続フェーズが進行します。後続フェーズでプロセス変更などがあった場合には分析フェーズに戻ることがあります。後続フェーズで変更が発生した場合の「戻りルール」の策定をすることもあります。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 □ユーザー ■開発者 / 設定者
設計	最終的な業務要件に適応するためのアプリケーションの機能範囲や設定範囲、および追加開発を行うための設計を行います。設計フェーズで策定した範囲での環境構築や追加開発が行われます。後続フェーズで設計の変更が必要になった場合、このフェーズで作成された仕様書を変更する必要があります。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 □ユーザー ■開発者 / 設定者
構築	業務要件に対応するために設計フェーズにて作成した仕様書に基づいて環境設定と追加開発を行います。構築フェーズにて作業を行う過程で更なる仕様の追加や仕様に不具合がある場合には「仕様を変更した後」に設定や開発をすることが理想です。システム導入後の追加開発や仕様変更、不具合の発生時に設計フェーズの仕様書を確認します。変更管理が重要です。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー □部門担当者 □ユーザー ■開発者 / 設定者
テスト	「分析フェーズ」で定義された実現要件が実装されているかを確認します。開発者や管理者のテストではシステムの「ロール（業務分掌）」や人事構成によって操作可能な機能や閲覧可能なデータが制限されています。実際の業務を行うようなシナリオでユーザーがテストをする「ユーザー受入テスト」を行います。結果をフィードバックして完成形に近づけます。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 ■ユーザー ■開発者 / 設定者
移行	「分析フェーズ」で定義された実現要件が実装されていることを確認後、新システムにて必要なデータを移行します。商品やサービスなどのアイテムデータ、顧客や仕入先、従業員データなどのマスターデータだけではなく、過去の取引や仕分けなどのデータも移行する必要があります。以前のシステムからデータを抽出、洗浄して新システムにインポートします。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 ■ユーザー ■開発者 / 設定者
最適化	関係者間で導入プロジェクトが完了したことを確認します。その後、分析フェーズで今回導入できなかった部分や見送った部分を新プロジェクトとして開始するかどうかを検討します。従業員からの機能改善や問い合わせなどの処理方法の確定と、プロジェクトメンバーから保守サポート担当者への引継ぎを完了することが必要です。	□監督者 ■プロジェクトマネージャ ■プロジェクトメンバー ■部門担当者 □ユーザー □開発者 / 設定者

プロジェクト担当や体制が確定すると、プロジェクト作業に突入します。

ただし、社外のリソースと共にプロジェクトを進める際には、作業範囲を定義する最終的な作業範囲定義書(SOW: Statement of Work）を考えておく必要があります。

-SOWとは、複数の主体が共同で進める事業業務プロジェクトなどにおいて、そのプロジェクトの目標や、成果物の定義や仕様、スケジュール、作業工程、作業内容、各主体の役割、分担、権限などを定義した文書。

SOWは導入プロジェクトのゴールに対して、どのような作業内容を誰が行うかを明文化するものです。制約条件や依存関係、作業プロセスやそれに対するリスク、責任の所在と権限、承認ルートや作業受入基準、業績判断基準などが盛り込まれます。プロジェクトメンバー全員、つまり社内リソースと社外リソースのすべてに対して設定することもありますが、少なくとも社外メンバーに対して同意のもとで策定する必要があります。一方的に作成しても同意がなければ意味がありません。

プロジェクトでは意図しなかった変更やトラブルがつきものですが、それに対して対処する担当者を同意のものとで任命しておくことにより、初期対応の時間が短縮され大幅なプロジェクトの遅延が発生する可能性が少なくなります。

作業範囲を曖昧にすることは避けて担当者設定する際に「やること」だけではなく、「やらないこと」も定義してください。責任の所在を明らかにするためです。もし、プロジェクトの中で発生したタスクに対して担当者が明記されていなかった場合、プロジェクト内で合議の上で担当者を確定して「作業範囲定義書」に追加して承認する必要があります。

[SMART_CONTENT]

開始フェーズ

開始フェーズ
担当者	■監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	■部門担当者	□ユーザー	■開発者 / 設定者
タスク詳細
プロジェクトを組織します導入プロジェクトの目的、プロジェクトの対象範囲、チーム構成とタスク担当を定義します目的とゴール、プロジェクトを推進するための主要なマイルストーン、成果物を定義しますスコープの定義はプロジェクトの円滑な運営と推進のために重要な項目です工数、予算、リソースが定義したスコープに見合ったものであるかを検討しますプロジェクトチームを組織して、要員を配置します「システム側」の要員と「業務側」の要員を参加させる必要がありますプロジェクトを円滑に進めるために導入対象の製品トレーニングに参加する導入業者と共同で導入する場合、どのような業務分担を行うのかを明確にする必要があります作業範囲定義書（SOW: Statement of Works）を作成します
フェーズのために準備するもの		フェーズのアウトプット
プロジェクト開始のための検討資料プロジェクトの前提条件を纏めた資料プロジェクトの要員計画 NetSuiteの要員トレーニング計画		プロジェクトチャートプロジェクトメンバーの選定と配置完了概要レベルのタイムラインとスコープ定義作業範囲定義書 NetSuite研修の受講（プロジェクト関係者）

phase-start

分析フェーズ

分析フェーズ
担当者	□監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	■部門担当者	□ユーザー	■開発者 / 設定者
タスク詳細
NetSuiteで実現する導入対象範囲と業務要件を文書化します参考資料として、NetSuiteが標準的な業務プロセスフローサンプルを参照することができます現行プロセスを参考にして、将来NetSuiteで実現したいプロセスを定義します業務要件定義書（BRD - Business Requirements Document ）業務要件定義書は、NetSuite アプリケーションの機能での実装範囲及び業務要件とのギャップの概要を記述した⽂書です。新業務プロセスの概要システムの設定内容（コンフィグレーション、カスタマイゼーション箇所）の概要プロジェクトの⻘写真（ブループリント)として、後続のフェーズで利⽤プロセス関連ギャップ分析データ関連ギャップ分析（移⾏、マスタ整備等）業務要件定義書には、ユーザー側と導入担当会社側での同意をして同意のサインを行います。業務要件定義書にサインされたものが確定仕様書です。業務要件定義書を基準にデータ移行計画や他システムとのインテグレーション計画、後続のフェーズで策定すべき文書が作られます。 BRD 策定時点で、導入プロセスのユーザー側、導入担当会社側で同意した「作業範囲定」の変更が発生した場合にはコスト面、期間面の見直しが必要になる場合があります。
フェーズのために準備するもの/過程で作るもの		フェーズのアウトプット
作業範囲定義遺書ビジネスプロセスマッピング表業務プロセスフロープロジェクトメンバーから導入担当者への質問表新業務プロセスフロー質問表に対する回答他システムとのインテグレーション計画社内への展開計画ユーザートレーニングガイドラインプロジェクトステータス報告用テンプレート		新業務のプロセスフロー（確定済）社内公開用質問の回答業務要件定義書（確定済）データ移行計画（確定済）インテグレーション計画（確定済）プロジェクトプラン（確定済）

pase-analyze

設計フェーズ

設計フェーズ
担当者	□監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	■部門担当者	□ユーザー	■開発者 / 設定者
タスク詳細
業務要件を満たすためのアプリケーションの設定、追加開発およびインテグレーション計画の設計を行いますアプリケーション設定、追加開発の要件定義アプリケーションに必要な追加フィールドの特定、不必要なフィールドの特定追加マスターデータ、選択リストなどの特定と項目の確認　自動化や計算、自動処理を行うためのスクリプトの概要承認に使うワークフロー、後続処理を自動化するためのワークフローの特定会社の業務習慣に沿った部門場所などの確認会社の会計習慣に沿った勘定科目や支払条件などの確認請求書や見積書など業務に必要な伝票の確認トレーニング計画の作成トレーニングの内容種別の定義トレーニング用の資料トレーニングスケジュールの策定講師を選任
フェーズのために準備するもの/過程で作るもの		フェーズのアウトプット
業務要件定義書デザインドキュメント変更依頼書（後続のフェースからの差し戻しの場合）機能要求仕様書（テンプレート）拡張機能仕様書（テンプレート）インテグレーション計画トレーニングガイドライン		ソリューションデザインドキュメント（承認済）機能要求仕様書（承認済）拡張機能仕様書（承認済）インテグレーションフィールドマッピングトレーニング計画

phase-design

構築フェーズ

構築フェーズ
担当者	□監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	□部門担当者	□ユーザー	■開発者 / 設定者
タスク詳細
業務要件を満たすためのアプリケーションの設定、追加開発およびインテグレーションを実装パラメータ設定 (例)業務要件定義書で定義した販売プロセスを実現するために各種パラメータを設定カスタマイズ (例)標準画面に業務要件や追加機能要件に応じて項目の追加やフォーム変更などの追加設定開発 (例)アプリケーションに標準で実装されていない業務ロジックを実現するためのコーディングを追加 (例)標準の伝票に業務に必要な項目を実装、若しくは新規に伝票を開発インテグレーション (例)システムと他システムとの連携を実現するプログラムを実装データ移行設計一部の前システムデータを移行し、移行手順を確認エンドユーザートレーニングの準備開発済みの画面や帳票のイメージを使ってトレーニングコンテンツを作成
フェーズのために準備するもの/過程で作るもの		フェーズのアウトプット
業務要件定義書プロジェクトプラン機能要件定義書機能要求仕様書インテグレーションフィールドマッピングデータ移行計画 CSVマッピングツールトレーニング計画トレーニングガイドライン		議事録プロジェクトの議題管理表スクリプトの開発ソースコードインテグレーション開発ソースコードアップロード済みのテストデータデータ移行フィールドマッピング定義トレーニングマテリアルトレーニングアジェンダ

phase-develop

テストフェーズ

テストフェーズ
担当者	□監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	■部門担当者	■ユーザー	■開発者 / 設定者
タスク詳細
テスト（UAT: User Adoption Test）の実施アプリケーションの設定や追加開発などが完了後、業務要件に適応しているかを最終確認するための受入テストの計画と実行を実施します。システム担当者およびエンドユーザーとテスト計画を作成受入テストは総合的なテストケースおよび様々な角度から実装した機能やパフォーマンスに対して評価できるように計画しますシステム担当およびエンドユーザーによるテストの実施管理者や開発者のテストではプログラム上の確認は行われているが、ユーザーが実施することによりユーザーが使用しているロール（Role: システムの使用権原）や人事組織の情報が反映されて正確なテストが可能
フェーズのために準備するもの/過程で作るもの		フェーズのアウトプット
業務要件定義書機能要件定義書機能要求仕様書ソリューションデザインドキュメント受入テスト計画		受入テスト計画受入テスト実施

phase-test

移行フェーズ

移行フェーズ
担当者	■監督者	■プロジェクトマネージャ	■プロジェクトメンバー
担当者	■部門担当者	■ユーザー	■開発者 / 設定者
タスク詳細
エンドユーザートレーニング実施（ユーザー受入テスト終了後）エンドユーザートレーニングは、エンドユーザーの業務担当領域を考慮の上それぞれに必要な内容を実施します本稼働よりもずっと早くトレーニングを実施すると、エンドユーザーは主要ポイントを忘れてしまう可能性があるとともに、直前の変更が反映されていない可能性もありますアプリケーションへのデータ移行実施移行対象データを抽出加工し、データ移行用のフォーマットで対象データを作成しますデータ移行を実施し、前システムから新システムに移行されたデータが、正しく移行されたかを確認しますアプリケーション本番稼働最終準備
フェーズのために準備するもの		フェーズのアウトプット
業務要件定義書トレーニング計画機能要求仕様書ソリューションデザインドキュメントトレーニングアジェンダデータ移行計画データ移行フィールドマッピング定義インポートアシスタントアップロード済データ		エンドユーザートレーニングの実施データアップロードの完了アプリケーション設定完了ダッシュボード設定