トライアル方法

トライアルは短期間で効果的にテストを行う必要があります。

どのように行うのが効率的でしょうか？

私のオススメは、受入テストでやるような「シナリオテスト」です。

その全てのパターンをやる必要はなく「代表ケース」を1～2つやるだけでOKです。

例えば、本番システムから代表的な顧客を選んで、その顧客に関わる帳票コピーを準備します。その帳票の項目をトライアルシステムに入力し、同じ結果が得られるかの「再現テスト」を行います。

トライアル環境は、最低限の項目しか存在しないので「項目の有無」はそこまで気にする必要はありません。項目の追加や画面レイアウトの修正は、後でどうにでもなります。

一方で、トライアルでは、とりあえず最後まで処理できることが重要です。

「そもそも処理がない」「全く進められない」となると、そのパッケージが業務にフィットしない可能性が高くなります。すなわち、大幅なカスタマイズが必要となってしまう、ということです。

まずは業務フローの上から下まで流してみて「できる・できない」を記録し、各機能を客観的に評価していきます。
 

現場を巻き込む

ここで大事なのは「現場の人に触ってもらう」です。

シナリオテストを現場の人にやってもらいます。「このパターンができたら安心」というシナリオを現場に準備してもらって、それをトライアルでやってもらうのです。

そこで60点以上とれれば安心です。後の40点は実際に導入する時に「設定で対応する」「この部分はカスタマイズで対応する」と現場を説得することができるからです。

仮に80点以上になったら、もう「スクラッチでないとできない」という意見は影を潜め「パッケージがいい」と推進派になってくれます。そうしたらしめたもの。ほぼ成功が決まります。

逆に50点以下だった場合は・・・、パッケージ導入に暗雲が立ち込めます。

この場合は、スクラッチ開発の選択肢も含めて、再検討することが必要となります。

＊＊＊

↓関連記事↓
パッケージシステムをトライアルする3つの目的