自社業務フローでの運用方法の検証が必要

パッケージシステムの機能を「熟知」し、パッケージが用意している業種別の標準業務フローも「熟知」して、使い方を検証することが導入成功のカギと言えます。

パッケージシステムの優位性を「落とし穴」にするな

パッケージシステムの導入プロセスは、オーダー開発と比較すると下記のような違いがあります。

パッケージシステムの場合、プログラムを開発する必要がないため、導入してすぐ「プログラムの検証(試しに使ってみる)」に入れるという優位点があります。この優位点を生かして、しっかり検証作業を進めればよいのですが……。

しかし、「テストする時間がたっぷりある」ということが優位点でなくなるケースがあります。生産管理システム導入部門の中心は、社内でも一番忙しい部署といわれる生産管理部門や購買部門のことが多いので、忙しくてなかなか時間がとれず、検証が十分にできないことが多々あるのです。

プログラム検証の場合、「進捗状況が見えにくい」という問題点もあります。

例えばオーダー開発の要求定義の場合は、SIerとの間で仕様書のやり取りが常に発生して、どこまで終わっているか進捗状況が見える形になります。しかし、検証作業の進度や深さは、なかなか目に見えないものです。また、導入側中心の作業となるため、担当者任せになることが多く、後回しになっていてもわからないことが多いのです。ここに「落とし穴」あります。

チームで徹底的に検証して、運用マニュアルを作成しよう

それでは、十分に検証されていないとどうなるでしょうか。

次のステップである併行稼働がなかなか乗り越えられない、本稼働しても業務がイレギュラーな処理で止まってしまう、などという困ったことが起こります。そうならないためにも、プログラムの運用検証は担当者まかせにせず、チームで対応することをお勧めします。また、検証した業務フローは運用マニュアルとして残すことが非常に大切です。

一般的に、操作マニュアルはSIerが作ってくれますが、実務に添った運用マニュアルは導入側が作成するものです。この作業は、社内の業務フローのルールを見える化したり、整理する絶好のチャンスです。例えば、「担当者がやめてしまって運用が引き継がれず、使われなくなる」「運用がわからなくて亜流の運用ができてしまう」というリスクを未然に防ぐことになる非常に大切なプロセスなのです。

しかし、運用マニュアルの作成は非常に時間がかかります。とても、一人での対応では難しく、この点でも組織的な対応が必要であると思います。大切なプログラム検証、チームでしっかり取り組んでいますか。