SAPプロジェクトは大変！
こんなイメージないでしょうか？
入って間もない人だと、今自分がどのフェーズのどのタスクをしているのか、分からない人もいます。
こんな人も、プロジェクト全体の進め方が分かると、次のフェーズを予測して今のタスクに取り組めるので、タスクの質も高まります！
この記事では、SAPプロジェクトの進め方を解説しますので、ぜひ全体感を持って仕事に取る組めるようになっていただければと思います。
SAPプロジェクトのフェーズ概要
SAPプロジェクトのフェーズは大きく８つのフェーズに分かれています。
| # | フェーズ | 説明 |
| 1 | 企画・構想 |
|
| 2 | 要件定義 |
|
| 3 | 設計 |
|
| 4 | 開発 |
|
| 5 | テスト |
|
| 6 | 移行 |
|
| 7 | トレーニング |
|
| 8 | 運用保守 |
|
なんとなくなレベルでイメージできたでしょうか？
じゃあそれぞれのフェーズで具体的に何をするの？ というところを説明していきます。
企画・構想
企画・構想フェーズでは、
- 何を目的にシステムを導入するか
- どこの拠点・事業部を対象にシステムを入れるか
- 将来会社のシステムをどうしていきたいか
ということを、まずはユーザ企業内部で検討します。
その後、各ベンダーに対して、RFI・RFPを送り、回答をもらいます。
- ※RFI（Request for Information）：ベンダーの持つ製品・サービスや実績などの情報をもらうことが目的
- ※RFP（Request for Proposal）：ベンダーからシステム構築の提案・見積をもらうことが目的
各ベンダーから出てきたRFP回答を比較し、自社に最適なベンダー・製品をユーザ企業にて選定します。
ここでSAPベンダーが選定されることにより、SAPプロジェクトがスタートします。
また基本的には、企画・構想フェーズはユーザ企業自身で実施するものですが、大規模プロジェクトだとユーザ企業内に経験者がほとんどおらず、何を決めていけばいいか分からないため、コンサルという形でベンダー企業がこの時点から入ることもあります。
（入るとしても、15年以上の経験豊富を持つシニアメンバーが入ることが多いです）
要件定義
現行業務をヒアリングし、SAPのプロセスにマッチするかどうかを確認していきます。
これを「Fit & Gap」と言います。
Gapとなったもの（現行業務ではSAPで実現できないこと）をどうしていくか、次の2択から検討していきます。
| 選択肢 | メリット | デメリット |
| 業務をSAPに合わせるか（業務改革） |
|
|
| SAPを業務に合わせるか（アドオン開発） |
|
|
要件定義の最後には、To-Be業務プロセスを完成させ、机上では業務が回ることを確認します。
（どこの業務をSAP標準・アドオン・マニュアル（オフラインなど）で対応するかを明確にしておきます。）
設計
要件定義フェーズでGap（業務とSAPが合わない）もので、業務を変えずにアドオン開発をするとなった機能の設計をしていきます。
アドオンはどこのSAPベンダでも以下5つに識別されます。
| 分類 | 説明 |
| インターフェース | SAPと周辺システムのデータ連携をするための機能 |
| レポート | 分析するための業務に必要なレポート（SAP標準レポートではまかなえないもの） |
| スマートフォーム（帳票） | 紙やPDFに出力する伝票などの帳票（発注伝票・製造指図など） |
| ユーザExit | データバリデーションやエラー処理など、SAP標準ではできないプログラム処理 |
| データ変換 | 移行時やデータインポート時に使うための機能 |
要件を把握しているSAPベンダメンバーが、機能概要レベルの基本設計をします。
しかし、設計フェーズあたりからSAPベンダのタスク負荷が高くなるため、新規メンバーが要件を内部引継ぎで教えてもらい、基本設計することもよくあります。
基本設計が終わり次第、詳細設計に入ります。
詳細設計では、どういったモジュールを使うか、メソッドを使うかなど、プログラム寄りの設計になります。
そのため、設計メンバー（要件定義メンバー）から開発メンバーに基本設計の説明をした後に、開発メンバーによって詳細設計が行われます。
開発
基本設計・詳細設計を基に、プログラム開発を行います。
小さいプロジェクトだと、詳細設計・開発をする人が同じこともありますが、大きいプロジェクトだと詳細設計と開発の担当を分けることもあります。
また、開発はできるだけコストを抑えたいため、契約社員を雇ったり、SAPベンダのオフショア拠点（中国・インド・ベトナム・フィリピンなど）にて開発をすることもよくあります。
テスト
テストは、ソフトウェア開発の「V字モデル」に沿って実施されます。
こんな図を見たことないでしょうか？
- 単体テストは、詳細設計をベースにテスト
- 結合テストは、基本設計をベースにテスト
- システムテストは、要件定義をベースにテスト
といった具合に、開発したアドオンが設計や要件定義を満たしているかをテストします。
テストをするためには、テストシナリオ/チェック項目作成・テストデータ準備を、事前に準備した上で、テストを行います。
テストシナリオやチェック項目は、設計者・要件定義者によって作成されますが、テスト自体は若手メンバーやオフショアメンバーにて実施することが多いです。
ここまでがSAPベンダ内部でのテストです。
システムテストまで終わると、ユーザ企業側による受入テストを行います。
受入テストでは、SAPを使って業務が回るかなどのチェックをします。
基本的にはユーザ側ですべて完結すべきタスクではありますが、SAPの操作方法・チェックしておいた方がいいポイントなどのQAは来ます。
移行
ここからは主流のフェーズからは離れますが、重要なフェーズです。
移行フェーズでは、次の２つの移行の準備をしていきます。
- データ移行
- 業務移行
【データ移行】
データ移行では、現行システムからSAPへのデータ移行を検討します。
移行では、現行データの用途確認、テーブル・項目マッピング（データ型・桁数なども含め）を１つずつしていく地味で大変な作業です。
現行データ用途確認では、SAPでいうとこういうステータスでデータを入れないといけない、などSAP全般の知識が必要となるため、幅広くSAPを知っている人が求められます。
（例：現行データの受注のAという状態は、SAPでいうと受注の与信ブロックの状態だ など）
また移行用のツールの開発もします。
現行システムからデータを抜くツール ＋ SAPにデータを入れるツール の2パターンです。
たった２つか、と思われるかもしれませんが、複数の現行システムが１つのSAPに集約されるようなプロジェクトであれば、各現行システムごとに検討をしていく必要があります。
項目マッピング・移行ツールが揃うと、移行トライアルを実施します。
いきなり本番移行で失敗するわけにはいけないので、トライアルを何回か実施し、移行の精度を高めていきます。
移行トライアル後は、エラー分析・対応策検討など、トライ＆エラーを繰り返し、本番移行に向かっていきます。
【業務移行】
移行でもう１つ重要なのが、「業務移行」です。
業務移行で検討するポイントは２つあります。
① 要件定義でGapとなったが、アドオン開発はせず、業務をシステムに合わせる業務改革をする と選択した業務プロセスが対象です。
② 帳票など、現行システムから出ているモノがSAPに変わるため、本番稼働日を境に、貼り替えが必要なものをどうやって実施していくかの検討をしていきます。
基本的には、ユーザが中心となって、どうやってSAPに業務を合わせられるかを検討していきますが、SAPベンダ側もSAPの仕組み・考え方を説明しながら、対応案を練っていきます。
そして、対応案ができたら、末端のエンドユーザまで、業務が変わるポイントを説明し、本番稼働に備えて準備をしていきます。
ユーザトレーニング
ユーザトレーニングでは、SAPの使い方をユーザにトレーニングをしていきます。
トレーニングの方法は、
- オンサイト
- マニュアルを配布
の2種類が考えられます。
エンドユーザまで、すべてをSAPベンダがトレーニングしていると工数もコストも高くなるので、ユーザ側のキーユーザにトレーニングをし、キーユーザからエンドユーザにトレーニングをすることもあります。
ユーザトレーニング時には、マニュアルも必要なので、事前に作成します。
作成もSAPベンダがする場合と、費用を抑えるためにキーユーザトレーニング後に、キーユーザにて作成するケースもあります。
運用保守
本番稼働をすると運用保守フェーズにはいります。
特に本番稼働直後は、
- システムエラー対応
- ユーザフォロー
の２つでタスクがいっぱいになります。
【システムエラー対応】
- 想定していないようなシステムの使い方をユーザがした
- システムテストでバグが潰しきれていなかった
- 想定以上の大量データが流れて、パフォーマンスが出ない
など、様々な要因でエラーが発生します。
業務は通常どおり回っているので、業務をできるだけ止めないようにエラー対応を１つ１つ即座にしていく必要があります。
【ユーザサポート】
ユーザトレーニングをしたとはいえ、実践で使ってみると分からないところも出てきます。
そんな場合に備えて、本番稼働後、数日はユーザのそばに待機し、いつでもサポートできるような体制を作ります。
サマリ
ここまででSAPプロジェクトのフェーズ概要・各フェーズの特徴をお話しました。
全体感を把握した上で、今やっているフェーズを見ると、次にどんなタスクが待っているのか ということが分かります。
次のタスクが見えると、今やっているタスクをどうこなせば次につながるのか という一歩マネージャに近づいた視点でプロジェクトを見ることができます。
プロジェクトマネージャはもちろん、チームリードも次のフェーズを見越して、常に仕事をしています。
全体感を把握できると、自分のタスクの意義も分かって、仕事が10倍楽しくなります。
せっかくSAPプロジェクトをやるのであれば、少しでも身になるプロジェクトにしたいものです。
そのためにも、プロジェクト全体感を把握して、仕事をすることをおすすめします。
