一般的に、稼働後のERPシステムに求められる要件は以下の3つである。

• 運用性――業務ユーザー、システム運用者がシステムを効率的に運用できること
• 保守性――業務変更に伴う、影響分析・修正作業が確実にできること
• 信頼性――システムの安定稼働が実現でき、障害発生時に速やかに復旧できること

　信頼性についてはハードウェア、運用ツールなど、インフラ的な側面が大きい。本稿では、特に業務設計およびシステム設計で手を打つことが可能な運用性と保守性の観点で起こりがちな問題を解説する。

運用性でよくある課題：エラー対応

　SAP ERPシステムの運用でよく課題となるのはエラーへの対応だ。以下は多くの企業のシステム運用現場が抱える課題といえるだろう。

• バッチ処理でエラーが発生しても重要な障害につながらないワーニングエラーのため放置されてしまう
• アドオン機能のエラーメッセージがシステム上の技術的な表現でユーザーがそれを理解できない。業務上でのアクションにつながらずに対応が遅れる

　いずれの場合も、エラーが起こった際に、誰が何を見てどうアクションを取るかが決まっていない状態でSAP ERPが設計・開発されていることが原因である。例えば、客先からのファクシミリによる発注に対して、商品を製造・出荷し、現場では業務が終了した後にアドオンプログラム上で受注・出荷を登録するようなプロセスがある。

　この場合に考えられるのは、アドオンプログラム上で受注ができても、在庫不足で出荷できないケースだ。アドオンプログラムが在庫不足を検知し、通知しても、それが単なるワーニングエラーではユーザーが気付かないことが考えられる。結果的に出荷の業務を手作業でリカバリするという煩雑な運用が後から必要になってしまう。

　このような事態を避けるには実運用において各部門がどのような役割分担の下でエラー対応を行っていくのかを設計段階で決める必要がある。エラーメッセージ出力の仕様やリカバリを考慮したプログラムの作りも、エラー対応の役割分担を意識したものでなければならない。

保守性においてよくある課題：影響分析と改修のしづらさ

　SAP ERPの保守についても各社で共通する課題がある。多くは影響分析と改修に関連する。以下の項目がその典型だ。

• 設計書に書かれていない仕様がSAP ERPに盛り込まれている。当初はなかった仕様が、開発者と業務担当者だけで情報がやりとりされて結果的にSAP ERPで実現される。しかし、設計書には反映されていない
• 大規模プロジェクトに複数のベンダーが参画し、プログラムが各社のスキル依存で作成されてしまう。そのため変更を行う場合にソースコード解読に時間がかかる。また変更すべき箇所の抽出が困難になる

　SAP ERPはプログラム開発を行うワークベンチツールの使い勝手が良く、簡単にプログラムを作成可能だ。そのためスパイラル型開発モデルのようなアプローチでも、頻繁な仕様変更に対して、その場しのぎのソースコード変更ができ、結果的に可読性が悪くなるケースがよくある。また、設計書に仕様が反映されていないと影響分析もできなくなってしまう。

　これは、設計で決めるべきポイントを押さえないまま「もう間に合わないから」という理由で、設計書への反映を後回しにして開発に入ってしまい、結局は設計書に反映されないことが原因だ。当初の開発者以外の人が運用フェーズで改修を行うことを意識した設計になっていないことも原因になる。

　このような問題を防ぐためには、

• 設計標準で定義した一定の設計要件を満たすまでは、設計作業を切り上げない
• 仕様変更に際しては必ず設計文書の変更を行ってから開発に反映する
• 設計標準で、オンラインバッチ、ファイル、データベース、画面入出力の処理設計パターンを決めておき、個別プログラムの設計の際にそのパターンを用いて設計を行う

などが重要である。各プログラムを標準化したパターンに当てはめることで、品質が安定し、改修しやすいプログラムを実現できる。

　SAP ERP導入では、プロジェクト進捗が厳しくなると、システムをスケジュール通り、予算通りにカットオーバーさせること自体が目的となり、エラー設計や設計標準を軽視しがちだ。だが、これまで説明したポイントを押さえて開発することが、安定的な稼働と将来的な拡張性、運用を見据えた設計を行う上で重要といえるだろう。