SAP ERPの導入プロジェクトでは、SAP ERPが持つ数多くの機能の活用に目を向けがちだ。筆者がこれまで見てきたRFP（Request For Proposal、提案依頼書）でも、ページの大部分が機能面での提案を求めることに割かれている。だが、SAP ERPの標準機能の充足度や、標準で対応できない業務についてのアドオン開発の有無が、プロジェクトの成否を分けてきたのだろうか。

　システム導入ではシステムが安定して稼働するまでにさまざまな課題を克服していく必要がある。もちろんシステムの品質を高めること（機能の充足度の向上や不具合の解消など）はその重要な部分だが、迷走したプロジェクトの多くでは、システムの品質以前にシステム導入の基本方針が定まっていないことが多い。

　将来起こり得る問題を全て予期して対応方針を決めておければよいのだが、多くの問題はプロジェクト固有に発生する問題であり、問題が起こる前に対応方針を決めておくことは難しいのが現実である。ではどのようにすればこれらの問題を解決できるのだろうか。

　それはシステム導入を始めるに当たって、以下に示す7つの基本原則（セブンプリンシプル）を明確にしておくことである。これらの基本原則を明確にしておくことで、プロジェクト期間中に発生する多くの迷走を避けることができる。

開発方針

　「開発方針」は、アドオン開発についてどのような目的・内容の追加開発ならば開発を認めるのか、その判断は情報システム部門、プロジェクト責任者、あるいは特定の会議体のいずれで行うのか、またその際の費用負担は誰が負うのかといった方針を定めることである。例えば「各国の法規制対応については、標準で対応できない場合に限り追加開発を認める。また、画面・帳票については、複数事業部あるいは2カ国以上で共通化できる場合のみ追加開発を認める。これらの開発費用は本社がその費用を負担する」などがある。

　筆者の経験では、グローバル企業の多くが画面、帳票について英語に統一し、各国固有の言語への対応は請求書、納品書などの顧客との接点が生ずるものに限っている場合が多い。筆者がかかわったあるグローバル企業のSAP ERP導入では、中国、韓国の拠点が英語の画面・帳票を利用すると言っているのに対し、日本だけが日本語化しないと業務ができないと主張したために、日本のスタッフの能力に対して本社から疑問を持たれたことがある。例外を作ると歯止めがきかなくなるため、開発の可否判断基準は明快で公正にしておくべきだろう。その他、海外拠点や販売拠点へのSAP ERPの導入に際しては、取引先とのインタフェースや各拠点固有のシステムとのインタフェースの開発を、本社責任で判断するのか、各拠点で判断させるのかを明確にしておくことが重要だ。

ソーシング方針

　「ソーシング方針」は、導入および運用期間において必要な人材をどこまで外部から調達するのか、あるいは社内の人材で賄うのかといった方針を定めることである。例えば「システム稼働後の運用は情報システム部門自身で行う。そのため、開発・導入では外部業者を活用するが、SAP ERPの設定およびアドオン開発、システムテスト、運用テストについては情報システム部門のメンバーが参画し、実際の作業を行うようにする。また、稼働後の2カ月間で外部業者から情報システム部門のメンバーに引き継ぎを実施する」などがある。

　社内で運用する場合は運用ルールや運用ツールは統一すべきであり、ハードウェアやOS、データベース管理システム（DBMS）なども社内で運用しているシステムに合わせるべきだろう。逆に運用を外部委託するのであれば、導入に係るコストや運用コストを下げる提案をさせ、ハードウェアやOS、DBMS、運用ツールの選択は委託先に任せる方が良いだろう。

テスト方針

　「テスト方針」は、導入までに何のテストを行うのか、それぞれのテストの準備や実施は誰が責任を持って行うのかといった方針を定めることである。例えば「開発業者は単体テスト完了時点で納品し、情報システム部門が受け入れ検収を行う。システムテストとユーザーテストは情報システム部門と開発業者が共同で実施するが、システムテストのテスト条件の洗い出しとテストシナリオの作成は開発業者が行い、ユーザーテストは情報システム部門が行う。また、これらのテストに必要なデータの準備は情報システム部門で行い、準備するデータの形式の指定や受け取ったデータのSAP ERPへの登録は開発業者が行う」などがある。

　SAP ERPではデータ登録の順番とSAP ERPの設定との依存関係が強く、SAP ERPの知識がないと品目マスターや部品表／レシピ（BOM）のデータを準備することさえ難しい。プロジェクト開始後に開発業者からシステムテストのデータ作成を依頼されるケースもあるが、十分な情報が提供されないと、用意したデータが全くSAP ERPに登録できないこともある。このような場合、テストが実施できずに遅延した責任が開発業者との間で曖昧になることもあるため、特に注意する必要がある。

イテレーション方針

　「イテレーション方針」は、開発の一部に反復（イテレーション）型開発を適用する場合には、それぞれの反復は何を目標に行うかの方針を定めることである。このようなケースは少ないが「企業合併に伴うシステム統合であるため、業務の共通化と両社のコンセンサスを重視し、要件定義から設計はウォーターフォール型ではなく、中心的な業務から順にプロトタイプを始めて、数回のセッションを通じて合意形成をしていくアプローチを取る。だが、開発以降はウォーターフォール型で進める」などもある。

　筆者の知るあるプロジェクトでは要件定義と設計の反復アプローチに3年以上を費やしていた。要件定義と設計の反復を実施するたびに、重要な機能の要件漏れが見つかり、次の反復でまた新たな要件が出るという状況に陥っていたためである。システム開発の日程は何度も見直され、稼働予定日は数回延期された。4年目には、要件定義と設計の反復、システムテストを並行して実施しながら稼働日を迎えることになった。システムは稼働直後から障害が続いた。

　反復型開発は、プロジェクトの生産性を向上させ、業務要件とシステム機能との差異を減らすことができる有効な開発アプローチである。ただし、イテレーション方針で各反復の目標を明確にし、やみくもに反復を繰り返さないようにしなければならない。

パイロット方針

　「パイロット方針」は、開発の一部にパイロットアプローチを適用する場合には、何を目的にどこに適用するかの方針を定めることである。例えば、「営業改革の実施に当たり、営業部門の強い抵抗に配慮して一部の営業拠点に先行導入する。これによって改革の効果を検証し、営業部全体の賛同を得るアプローチを取る。この目標を達成するため、営業改革のパイロット拠点は、営業成績が振るわない拠点から選定する」などがある。

　パイロットアプローチを適用することはプロジェクト全体の期間が長くなることや、システム導入による効果が創出される時期が遅くなることから、決して望ましいことではない。しかしながら、適用が望ましいと判断して実施する場合には、パイロットを実施する目的、パイロット対象の選定基準を明確にし、期待している効果が実際に得られるか十分に検証すべきである。仮にパイロット対象で期待していた効果が得られなくとも、仮説を見直す機会が与えられたものと考え、最終的に大きな成果を生むための先行投資と捉えるべきだろう。

　パイロットアプローチは全てのプロジェクトが採用するものではないが、パイロットアプローチを取るか、取らないかについては、その理由とともに明確にしておくべきであろう。

調達方針

　「調達方針」は、プロジェクトで調達するハードウェア、ソフトウェア、開発業者の調達について、集中化するのか、個別の判断で調達するのかの方針を定めることである。例えば「SAP ERPを稼働させるハードウェアやOS、SAP ERPのライセンスについては、ボリュームディスカウントによる値引きが期待できることから、本社で一括して調達を行う」などがある。

　また技術的な観点から「仮想化によるハードウェアの集約を目指し、できる限り既存システムと同じベンダーのハードウェアとOSの組み合わせで調達する」というのも1つの見識だろう。開発業者についても「既存システムとの接続テストや改修を考慮して、現行ベンダーを選定する」という場合や、「海外拠点への展開を予定しているため、海外に強いベンダーを選定する」こともある。

　調達方針を明確にしないままで具体的な選定作業に臨むと、判断基準が価格のみになり、結果として望ましい調達とならない場合がある。調達の際のベンダー選定は調達部門が行う企業も多いので、調達方針を明確にしておくだけでなく、情報システム部門と調達部門の間で、その目的について十分に合意しておくことが大切である。

移行／展開方針

　「移行／展開方針」は、システム切り替えと展開をビックバンアプローチで行うか、あるいは段階的に行うかの方針を定めることである。例えば、企業合併など直前までシステムを接続したテストが行えない場合には、「システム改修は、取引先に関係する部分のみにとどめ、合併時のシステム切替を最小限に絞る。残りのシステムについては、翌年に一括して切り替えを行う」などがある。

　1000万件以上の契約を管理する顧客管理システムの移行を検討していたある企業は、地域別にシステム切り替えをするアプローチと、法人顧客と個人顧客の2回に分けてシステム切り替えを行うアプローチの2通りを検討していた。コストと期間だけで見れば、ビックバンアプローチが費用、期間共に最小となることが多い。しかし、移行データが多いなどの理由で、業務停止可能な時間内に全体のシステム切り替えを行えない場合や、離れた場所でのシステム切り替えといった地理的な制約がある場合、合併等で時間的な制約がある場合では、段階的な切り替え、展開を採用することで業務への影響やシステム切り替えに伴うリスクを抑えることができる。

　ここまで見てきたように、プロジェクトの目的と、7つの基本方針の定義や共有は、日々のプロジェクト管理や要件定義の品質と同じかそれ以上に、プロジェクトの成否を大きく左右する重要なものである。