業務改善・DX|重点支援テーマ
システム導入・刷新の判断と推進
業務のどこを標準機能に合わせ、どこを作るのかを決められる状態にし、要件の確定から利用開始までの判断と推進を担います。ベンダーとの間に残っている判断を、発注者側の視点で整理します。
企業の状態
システム化の方針とプロジェクトが動いていても、業務とシステムのどちらを変えるかの判断が残ったまま進むことがあります。
要件定義を終えていても、業務手順や例外処理の判断が残っている
設計へ移る段階で、実際の手順や例外の扱いが確定していない。画面や機能を詰めるたびに、業務側への確認が戻ってくる。
標準機能に合わせるか、業務を変えるか、作るかが決められない
ギャップが見つかるたびに検討が止まる。どれを選ぶかの基準が定まっておらず、同じ論点が繰り返し議題に戻る。
投資の承認は得ているが、それが要件を判定する基準になっていない
効果を根拠に予算がついている。その効果に照らして個々の要件の可否を決める運営までは固まっていない。
稼働の日程は決まっているが、業務の切り替え方が決まっていない
テストと移行の計画はある。現場がいつ何をやめて何を始めるのかが定まっていない。
なぜ起きるか
業務の実態が、決められる粒度まで分解されていない
長く続いてきた業務ほど、手順は人と場面ごとに分かれています。この状態のまま機能の話に入ると、確認と持ち帰りが増えやすくなります。背景には、業務を手順・判断・例外へ書き分ける工程が計画に含まれていないことがあります。
判断の基準が、要件を決める場に持ち込まれていない
投資の根拠になった効果は、稟議の資料の中にあります。それが個々の要件の可否を判定できる形になっていないと、判断はその場の声の強さに寄りやすくなります。
発注者側で決めることと、ベンダー側で決めることの線が引かれていない
ベンダーは提示された要件に対して最適な形を設計します。発注者側で決めるべき業務の変更可否がその場に用意されていないと、判断待ちが積み上がりやすくなります。
Latentが整理すること
業務の分解と、システムに載せる範囲の切り分け
手順・判断・例外へ書き分け、どこまでをシステムで扱い、どこを業務側に残すかを決める
内製・外製と調達方針の判断材料
作る・買う・任せるの比較軸を整理し、RFI/RFPの形にする
標準機能/業務変更/追加開発の判定基準
ギャップごとに、何を根拠にどれを選ぶかをあらかじめ定め、発注者側で決める項目を明確にする
利用開始までの業務の切り替え方
誰が、いつ、どの手順をやめて何に置き換えるかを定める
支援プロセス
Latentは、要件の整理から利用開始まで、発注者側の推進主体として関係者との調整と判断の準備を担います。
Phase 1|業務の分解と対象範囲の確定
現行の手順・判断・例外を関係者へのヒアリングから書き出し、システムで扱う範囲と業務側に残す範囲を定めます。要件が固まりきっていない段階から着手できます。
Phase 2|調達と判定基準の設計
内製・外製の比較と調達の進め方を整理します。あわせて、標準機能で対応するか、業務を変えるか、追加開発するかを決める基準を定め、投資の根拠と結びつけます。
Phase 3|要件・設計の確定とベンダーとの判断接続
仕様を詰める場を運営し、ギャップごとの判定と変更の可否を進めます。決定が必要な論点は、選択肢と判断材料をそろえた状態で承認の場に上げます。
Phase 4|受入テストと業務移行
受入テストの計画と実施を支援し、利用開始までの業務の切り替えを設計・実行します。新しい手順が現場で回る状態にします。
成果物
- 業務フロー図(現行と、システム化後)
- システムで扱う範囲と、業務側に残す範囲の一覧
- 内製・外製の比較資料、RFI/RFP
- ギャップ一覧と、標準機能/業務変更/追加開発の判定結果
- 要件・設計の承認資料(判断の根拠を含む)
- 受入テスト計画と、業務移行・利用開始の手順
要件が固まりきっていない段階でも構いません。業務のどこを変え、どこをシステムに載せるかの整理からご相談ください。