業務管理システム選定時のポイント（８）オンプレ版ERP導入時・運用保守段階でのよくある課題と対応策

「クラウドERP導入時・運用保守段階でのよくある課題と対応策」にて、クラウドERP導入時や運用保守にてよくある課題などについて紹介しました。今回は、オンプレ（オンプレミス）版ERPについて紹介していきます。

オンプレ版ERP導入時・運用保守段階の主な課題

オンプレ版ERP導入時・運用保守段階には、主に次のような課題があげられます。

[導入時]

(1)システムに求める要件が曖昧である

(2)システムの導入方針が決まっていない

[運用保守時]

(3)運用保守段階におけるシステム担当者がいない

(4)システム担当者が変更となる場合において後任の担当者に引継ぎがなされない

これらについて個別に対応策を見ていきましょう。

[導入時]

(1)システムに求める要件を明確にしておく必要がある

オンプレ版ERP導入時、自社の業務を理解した上でシステムに求める要件(機能)を明確にしておく必要があります。システムに求める要件が曖昧なままシステム導入を決定し要件定義を開始すると以下のリスクがあります。

要件定義開始後に曖昧にしていた要件を明確化する作業を実施した場合、仕様を決定するのに想定以上の時間がかかり、要件定義/基本設計の期間が延長(及び費用負担が増加)する
要件定義/基本設計の期間延長に伴い全体の導入スケジュールが見直しとなる
想定以上のカスタマイズが発生し、一部妥協したシステムを導入せざるを得なくなる

上記の様な事態を避ける為には以下の様な対策を実施しておく必要があります。

自社の業務フロー図を作成しシステムに求める要件を明確化する

事前に自社の業務フロー図を作成しておくことで、各業務において必要な機能が浮き彫りになり、ベンダーや現場担当者との情報共有がしやすくなります。

IT業界などでは「As-Is」「To-Be」といった単語が用いられることもありますが、現行の業務フロー（As-Is）と理想の業務フロー（To-Be）を可視化することによって、新システムに求める機能を明確にすることができます。

また、新システムに求める機能を一覧化し提案ベンダーへ提供することで、標準機能での対応可否、カスタマイズにおける対応可否、代替案の運用方法などの提案をスムーズに受けられます。

システムをトライアル（試用）する

システムに求める要件を明確にして、システムベンダーから提案を受けると同時にトライアルにて検証作業を実施することもシステム導入時には有効です。現状の業務管理が新システムで運用するとどのように変わるのか、という検証作業をしておくことで、ベンダーに提示した要件の過不足を確認・把握することができ、また導入後のイメージをより明確に掴むことができます。

システムに求める要件を一覧化する作業自体が難しいといった場合、ベンダーにデモンストレーションなどを依頼し、そのときの質疑応答の内容を纏めることで要件化する方法もあります。この場合においてもトライアルでの検証は実施し新システムに求める要件に漏れがないか、導入後運用ができそうか、等々の確認をしておくことは重要です。

上述の対応により提案段階の内容をもとに要件定義/基本設計を進められるため、要件が曖昧なままシステム導入(要件定義を開始)する場合に比べて、要件定義/基本設計後の仕様の乖離を抑える事が可能となります。

「自社だけでは要件がなかなか纏められない」という場合は、要件定義前にプレ要件定義をベンダーと実施し、システム導入におけるスコープ、課題や要件(大枠)、スケジュールなどを明確にして、要件定義時に実施する内容を決定するといった対応をするということも有効です。

(2)システムの導入方針を決める

クラウドERPでは基本的に標準機能での導入となる為、必然的にシステムに業務を合わせるといった方針となりますが、オンプレ版ERPにおいてはそうはいきません。

オンプレ版ERPではカスタマイズも選択肢の内の1つとなる為、予め導入方針を定めておく必要があります。

導入方針が決まっていないと要件定義/基本設計時に仕様を固める際にブレが生じて打合せがスムーズに進まなくなってしまいます。

対策としては以下の通り予めシステム導入の方針を決めて進めることが重要です。

システムの導入方針のパターン

システムの導入方針としてはおおよそ以下の通りです。

カスタマイズは極力せず、標準機能で導入する(システムに業務を合わせる)
優先順位が高い、機能として必須となるもののみカスタマイズを実施する
優先順位が低く必須ではない機能は標準機能の範囲もしくは運用でカバーする
優先順位に関係なく業務で必要な機能はカスタマイズしてでも導入する

導入方針を決めることで、要件定義/基本設計時に発生する課題への対応内容をよりスムーズに決めることが可能となります。

[運用保守時]

(3)運用保守時のシステム担当者を設定する

導入時はプロジェクトメンバー(専任メンバー)がアサインを確保しシステム導入プロジェクトを進めることが多いですが、導入後にプロジェクトメンバーを解散するケースがあります。

プロジェクトメンバーを解散し、運用保守時のシステム担当者を決めずに運用を進めていると、いざ「システムとしてこうなっていないと業務が回らない」という事態が発生した場合に「どう対応するか」を検討する人がおらず業務に支障が出てしまいます。

このような場合、急遽別の担当者が対応することになり、残業の発生や検討における疲労が発生するという課題があります。

このような事態を防ぐ対策としては以下の通りです。

運用保守時のシステム担当者、対応方法を決定する

①専任のシステム担当者をアサインする（決定権があり社内を纏められる方だと望ましい）

②専任のシステム担当者をアサインすることが難しい場合は、兼任担当者でも良いのである程度決定権があり社内を纏められる方を担当としてアサインしておく

③それでも難しい場合は、システム運用における課題が発生した際の業務フローを決めておく

但し、③についてはいざ急遽対応しないといけない事態が発生した際に業務フロー通り進められるか、という懸念もあるので、①か②で検討することをおすすめします。①や②のように予めシステム担当者をアサインしておくことで緊急時の対応の他、通常業務時においても何かしら課題が発生した際、「どう対応するか」というのを都度決めながら業務を運用することができるようになります。

(4)システム担当者変更時の引継ぎを実施する

次にシステム担当者は設定されているが、異動や退職などにより引継ぎがなされないまま後任の方がシステム担当者となるというケースがあります。

引継ぎされないことにより、機能の仕様や運用が把握できないまま利用者からの問い合わせへの対応や課題への対応をすることとなってしまい、良く分からないままベンダーへ問合せをすることで明確な回答を得られず、問題解決に時間を要することがあります。ベンダー側も機能や仕様の問い合わせは保守の範囲で対応しますが、課題解決という観点でみると解決までに時間を要してしまいます。

引継ぎを受けてシステムを理解するには時間と手間がかかり、特に兼任の方などは通常業務の合間にそこまでできないということもあると思いますが、業務だけでなくシステムの引継ぎも実施しておくと、課題発生時の対応をスムーズに行うことができます。