パッケージシステムが
業務に合わないときの
判断表
合わない箇所をすべてカスタマイズすると、費用も保守も重くなります。反対に、何でもシステムへ合わせると、Excelへの転記や確認待ちが残ります。まず1つの不一致を5問で整理し、4つの対応のどれから調べるかを切り分けます。
合わない業務を整理する入力内容は送信されません。このブラウザ内だけで処理します。
先に結論
機能の数ではなく、合わない業務を1件ずつ分けます
パッケージのデモで「できる・できない」を数えるだけでは、導入後の手作業までは見えません。同じ「できない」でも、めったに起きない処理と、毎日の受注判断では扱いが違います。
「誰が、どの場面で、何を判断できず、今は何で補っているか」を1件だけ書きます。製品名や欲しい機能から始める必要はありません。
たとえば「特注品の納期を回答できない」なら、営業が生産担当へメールし、回答が来るまでExcelに「確認中」と書いている、と具体化します。ここまで書けると、設定不足なのか、別画面が必要なのか、そもそも業務をそろえられるのかを話し合えます。
所要時間 約5分
合わない業務を1つ、5問で整理します
結果は製品選定の結論ではありません。ベンダーや社内担当者へ、次に何を確認するかを絞るための下書きです。
整理結果
回答後に、確認する順番を表示します
5問で結論が出ない場合も、「未確認の条件」が次の打ち合わせ項目になります。
最初に調べる対応
この順番で確認
先に決めないこと
4つの対応
対応は、カスタマイズだけではありません
業務を標準へ寄せる
発生が少なく、顧客や売上への影響も小さい処理は、パッケージの標準手順へ変えられないかを先に見ます。昔からの手順をそのまま再現するための開発は避けます。
標準設定で吸収する
項目、権限、承認経路、通知、帳票など、製品が用意している設定で対応できる場合があります。「画面に見当たらない」と「製品に機能がない」を分けて確認します。
パッケージの外側で補う
受注や在庫の正本はパッケージへ残し、独自の確認画面、通知、計算、帳票だけを小さなアプリで補います。データを二重入力しない接続方法があるかが判断点です。
個別開発を比較する
取引条件や納期判断の中核が標準機能と違い、外部連携でも一貫して扱えないなら、部分的な個別開発や別システムを比較します。対象業務と残すデータを絞ってから見積もります。
記入例
「特注品の納期回答」で分けるとこうなります
- 困る場面
- 営業が特注品の納期をすぐ回答できない
- 今の補い方
- 生産担当へメールし、回答待ちをExcelへ記録
- 変えにくい理由
- 材料・設備・既受注の組み合わせで納期が変わる
まず、パッケージから品目・在庫・受注残を取り出せるかを確認します。取り出せるなら、納期確認だけを外側の画面で補う案を試せます。取り出せない、または納期計算が受注処理と一体なら、パッケージ本体の追加開発と部分的な別システムを比べます。
この例は説明用の架空ケースです。実在する顧客事例や導入効果を示すものではありません。