方法論、スキルの問題

　Oracle EBS案件はパッケージを活用した開発だが、その基盤ではハードウェアやソフトウェアの進化、多様化に追従するため、旧来のスクラッチ開発の方法論を採用している企業が当時は多かった。パッケージを活用した開発では現行調査、要件分析・定義の方法論を確立させる必要があるが、企業によっては部分的にしかその方法論が浸透していない。そのため運用の改善に遅れが出たのである。

非機能要件の未達

　プロジェクト後半やカットオーバー直前・直後での性能問題の発生については、非機能要件が関係する。ハードウェア、ソフトウェア個別のトラブルシューティングやチューニングを実施できるテクニカル人材は数多くいるが、データやシステム構成、プロジェクト期間、予算などのプロジェクト特性を踏まえながら、ERPシステムのサイジングや性能試験の計画を検討し、さらにプロジェクト全体のプロジェクトマネジャーと調整し、それを全体計画に落とし込むという非機能要件をまとめることができる人材は、多くはなかった。

　このような人材には、Oracle EBSの導入経験だけでなく、テスト方法論、品質／リスク管理、見積もり手法など、広範囲な知識と経験が求められる。またコンピュータアーキテクチャやデータベース、データ通信、アプリケーション開発などさまざまなスキルと経験も必要だ。Oracle EBSの大規模案件はそう多くなく、経験豊富なベテラン人材を探すのは意外に難しいという側面もあった。

Oracle EBSに取り組む3つのユーザータイプ

　それでは次に2010年前後から2011年までのOracle EBSプロジェクトの傾向・動向を説明する。2000～2010年までと比較すると、日本国内の経済状況やERP市場の成熟の影響からか、Oracle EBSに限らず、大規模案件や新規システムの案件数は減っている。

　特に製造業では、業務改革を伴うケースや、新しいビジネス、業務に伴う本当の意味での新規システム開発が先送りや見送りになるケースが目立っている。逆に足元の現行システムでは、システムが足かせ（保守切れや最新ハード、ソフトとの相互接続不可など）になり、システム統合化を進める障壁になっている。

　企業はコスト削減のため、現行システムの機能や帳票削減、内製化など地道な活動を行っている状況だ。運用保守についてもギリギリの予算で行っている。運用保守費用削減のため、ベンダー変更を検討している顧客も多いが、リスクが大きくて踏み出せず、ジレンマを感じているのが実態だろう。

　そのような全体状況の中でも、Oracle EBSによる新規システム開発やバージョンアップに積極的に取り組んでいるユーザー企業もいる。そのユーザーのタイプは3つに分けられる。1つは「新規ビジネス型」で、グローバルSCMを実現するためOracle EBSによる新規プロジェクトを開始するケースだ。もう1つは「垂直拡張型」で、IFRS（国際財務報告基準、国際会計基準）対応や、組織変更対応（グループ会社や支社、工場の廃止や統合）を実現するために、バージョンアップを行うケースだ。3つ目は「水平拡張型」。全体の運用保守コスト削減のため、周辺システムとの統合も視野にバージョンアップを実施するケースだ。

Oracle EBSプロジェクトに求められる変化

　全てのシステム開発で、深さの違いはあれ、ビジネスの成熟、コスト削減の要請とITの進化（ハードウェア高速化、クラウドコンピューティングの進展など）を要因に、システムの共用、統合が当たり前になっている。その中で、部門別の縦割りシステムから脱却し、全体最適を実現するためには、「どのシステムから手を付けるか（優先度）」「どのようなアプローチで統合するか」などの戦略が重要となる。具体的には、最終的な青写真を描いた上で、効率性や技術力を調査・加味しながら、合理的な戦略に落とし込んでいく必要がある。

　全体最適を実現するためには、企業内のシステム全体の理解が欠かせない。初期のデザイン次第によって、運用保守の最終的な品質やコスト削減効果が大きく左右されるからだ。Oracle EBSを軸に全体最適の検討を進めていく場合には、これを担当するテクニカルマネジャーやコンサルタントには、Oracle EBSのハイレベルな知識、経験はもちろんのこと、企業内に稼働している数多くのハード、ソフトウェアに関する知識や利用経験、異なる運用要件のシステムを統合するための多くの運用経験が必要になるだろう。

　このような状況を考えると、今後のOracle EBSプロジェクトで考えるべき重要テーマは、運用保守コストの削減、環境変化（IFRSなど）対応を低コストで実現させられるバージョンアップ方法などが挙がるだろう。次回は、Oracle EBSのアーキテクチャについて解説する。