調査と設計で確定する内容
対象作業、除外事項、入出力、数量、発注側の回答担当をまとめます。資料の受渡し方法とアクセスを準備し、通常処理だけでなく不足資料や期限超過時の動作も手順書に含めます。
試行の結果を受入判定へつなぐ
有償試行のサンプルと費用を合意し、重要な誤り、処理時間、保留理由を測ります。合格・修正後再確認・中止の条件を事前に決め、検証していない繁忙量や例外まで対応可能と扱わないようにします。
切替日と終了条件も設計
本運用前に担当窓口、報告頻度、変更承認の流れを確認します。稼働中案件の移行やデータ返却、権限停止の手順も合意します。相談時には希望開始日だけでなく、社内承認と環境準備に必要な期間を共有してください。
開始前のゲートを入力、出力、責任者で定める
導入は資料を送った時点で本番開始とせず、準備完了を段階ごとに確認します。各ゲートには必要な入力、完成させる出力、確認する責任者、次へ進める条件を置きます。資料や権限が不足したまま処理を始めると、試行が何を検証したか不明になるためです。
サンプルは通常例、資料不足、重複、版違い、承認が必要な例を含めます。匿名化しても実際のレイアウトや難しさが分かる形にし、情報の共有と試行利用に必要な権限を確認します。必要な日本語力と日本時間・ベトナム時間の連携条件も、この段階で評価対象へ入れます。
四つの導入ゲートを通す具体例
以下は架空の申請入力業務を使った導入例です。件数や日程を実績として示すものではありません。発注側の業務責任者が正とする項目と検収を承認し、システム管理者がアクセスを確認し、委託先が手順と納品を準備する役割分担です。
試行で基準を満たさない場合は、本番へ自動的に移さず、原因、修正担当、再試行の範囲を決めます。承認経路の遅れと入力の誤りを別に扱い、手順の版が変わったなら再確認するサンプルも指定します。ゲートの承認記録が次工程の入力になります。
| ゲート | 入力 → 必要な出力 | 確認責任者と進行条件 |
|---|---|---|
| 範囲確定 | サンプル・現行作業 → 対象工程と除外事項 | 発注側業務責任者が処理単位を承認 |
| 作業準備 | 項目定義・許可権限 → SOPと納品形式 | 業務・システム責任者が手順とアクセスを確認 |
| 試行検収 | 代表的な対象一式 → データ・不備一覧・測定結果 | 発注側検収者が品質と残課題を判定 |
| 本番移行 | 試行の承認・修正記録 → 運用計画と連絡経路 | 双方の責任者が範囲、体制、開始条件を合意 |
試行の採点表とSLAの時計を一緒に確認する
試行の採点表には、重要項目の正確さ、全体の誤り、取込可能性、例外の根拠、原票への追跡、発注側の確認工数を含めます。各項目の合格条件と確認方法は試行前に合意します。平均値だけで重要な誤りを隠さず、未解決例外が残る場合の移行可否も責任者が判断します。
SLAは、必要資料がそろって受付した時点を開始、承認待ちなど合意した条件を停止、回答と資料がそろった時点を再開、検収対象を渡した時点を終了とするなど、イベントで定義します。これは設計例です。実際には通知の記録、営業日、締切、再処理時の時計も合意し、顧客が待った総経過時間を併せて残します。
本番の変更と終了時の受渡しまで設計する
運用後の新しい帳票、追加チャネル、言語変更、件数増は、既存手順のまま受けられるかを評価します。影響するSOP、QA、要員、アクセス、費用を確認し、変更前の承認を取る経路を用意します。問題が出たときの連絡窓口と、旧手順へ戻す条件も定めます。
終了時には完成データ、手順書の有効版、用語集、承認履歴、未完了キュー、次の担当と必要操作を返却します。エクスポート形式、引継ぎ確認、アカウント停止、作業用データの保持・削除条件を事前に決めます。未完了を無理に閉じるのではなく、引受先が状態を理解して受領した記録を残します。