システム導入後の定着化を進める5手順

はじめに

新しいシステムを予定どおり公開し、説明会も開いた。それでも数週間後、現場では以前の表計算ファイルが使われ、同じ内容を二重に入力している。ログインはされているのに、肝心の業務は新しい仕組みに移っていない。そんなときに必要なのは、追加の操作研修だけではありません。

システムの定着とは、対象となる業務が新しい手順で無理なく進み、困りごとが見つかったときに改善できる状態です。この記事では、導入を担当する業務部門やDX推進担当者に向けて、現状の把握から改善の振り返りまでを5手順で整理します。説明用の例は架空の受注管理システムです。

定着しない原因は「使う人」だけにない

「使い方を覚えてもらえない」と感じると、担当者はまず研修回数を増やしたくなります。しかし、実際の障害は権限が不足している、例外時の処理が決まっていない、古い台帳も提出を求められるなど、操作以外にもあります。研修を増やす前に、どの業務の、どの場面で止まっているかを確かめましょう。

SCSKサービスウェアのシステム定着化サービスは、導入前後の業務プロセスの違いを把握し、実業務に即したマニュアルや教育、導入後の継続支援を組み合わせています。画面の機能説明だけでなく、業務の変化に合わせて支援する考え方が参考になります。

1. 対象業務と「使える状態」を決める

まず対象を絞ります。「全部門で新システムを使う」という目標では、どの作業が変わったのか確認できません。例えば受注業務なら、「受注の登録から承認までを、営業部の対象チームが新システムで行う」と範囲を決めます。問い合わせ対応や請求業務を含むかどうかも明示します。

次に、定着の判断に使う行動を具体化します。ログインしたかだけでなく、受注登録が完了したか、差し戻し後に正しい担当へ戻せたか、旧台帳との二重入力が残っていないかを確認します。月末だけ行う作業は、毎日の利用率だけでは評価できません。

記録する項目は次の程度から始められます。

• 対象となる業務・部門と利用者
• 新システムで行う作業と、当面残す旧手順
• いつまでに、どの状態を目指すか
• 結果を確認する責任者と確認方法
• 利用できないケースの報告先

目標値は導入前の作業量や利用頻度を踏まえて関係者で決めます。アクセス数だけを追うと、目的の業務が完了していないのに「定着した」と誤認するおそれがあります。

2. 現場の作業を観察し、止まる場所を分ける

次に、利用者へ「使っていますか」と聞くだけでなく、可能な範囲で実際の作業の流れを一緒に確認します。個人の能力を評価するためではなく、手順や環境の問題を見つけるためです。画面の見え方、参照する資料、判断に迷う場面を、利用者の許可を得て記録します。

架空の受注登録では、次のように原因を分けられます。

ログを使える場合も、誰が何回操作したかだけで個人を責めないようにします。取得できる情報の範囲と利用目的を社内ルールに照らして確認し、現場からの聞き取りと合わせて解釈しましょう。数字が低い理由は、利用者に対象業務が発生していないだけかもしれません。

3. 通常時と例外時の手順を一緒に整える

操作説明書は、ボタンの一覧からではなく、利用者が終えたい業務から作ります。「受注を登録する」「承認を差し戻す」のように目的を先に置き、開始条件、必要な情報、操作後の確認、次の担当者を記します。画面が更新されたときに誰が直すかも決めておきます。

例外は別途まとめます。顧客コードが見つからない場合、代理承認が必要な場合、通信障害で締切までに登録できない場合など、起きやすく影響の大きいものから選びます。未決定の例外を、担当者の経験だけで処理させないことが大切です。

新旧の切り替え時期、残すデータ、担当者の合意など、導入前後に決めることは移行計画書の作り方も参考にしてください。移行作業の完了と、現場の業務が新手順で回り続けることは別の確認項目です。

業務ルールや確認事項が複数の資料に散らばっているなら、まず現場の手順と未決事項を集め、合意した版を参照できるようにします。Kakusillは、会議の記録や既存資料をもとに業務の整理や仕様管理を進めるための選択肢です。ツールへ入れるだけで現場への説明や判断が自動的に終わるわけではありません。

4. 練習と相談先を実業務に合わせて用意する

研修では機能を順に説明するだけでなく、利用者の役割ごとに短い業務シナリオを用意します。営業担当なら新規受注の登録、承認者なら差し戻しと再承認、といった形です。実データを使うかどうかは、権限と情報管理のルールを確認して判断します。

説明会に出られない人や、入社・異動で後から使い始める人にも、最新版の手順へたどり着く経路が必要です。質問窓口には受付方法、回答できる時間、緊急時の連絡先を示します。各部門に相談役を置く場合は、その人だけに負担が集中しないよう、情報システム部門やベンダーへ引き継ぐ条件も決めましょう。

問い合わせは件数だけでなく内容を分類します。「操作説明」「権限」「不具合」「業務ルール未決定」を分けると、研修で解消すべきものと設定・仕様の変更が必要なものを区別できます。窓口の回答を手順書へ反映し、同じ質問が繰り返される背景を減らします。

5. 利用状況と業務成果を分けて見直す

導入直後は問い合わせが増えることもあります。件数が多いだけで失敗と判断せず、解決までの時間、同じ質問の再発、未解決の重要案件を見ます。利用状況と業務成果は分けて扱うと原因が見えやすくなります。

例えば、利用状況として「対象受注のうち新システムで登録された割合」、成果として「受付から承認までの時間」を追う方法があります。割合の分母は対象外の取引を除いて定義し、時間は導入前後で同じ範囲・計測方法にそろえます。目標と実績の差が出たら、部門や例外の違いを確認してから対策を選びます。

Microsoftの変更管理ガイドは、利用状況、サポート傾向、利用者の意見を見ながら案内や管理を調整する考え方を示しています。同資料はMicrosoft 365の変更を対象としたものですが、運用後の観察と改善を分けない姿勢は、ほかの業務システムでも参考になります。

改善会議では、困りごとごとに「対応内容・担当者・期限・完了の確認方法」を一行で残します。すぐに直せない場合も暫定手順と判断期限を示し、利用者へ状況を返します。要望を集めるだけで回答しない状態が続くと、相談窓口そのものが使われなくなります。

最初の一か月に確認したいこと

まず一つの部門と代表的な業務を選び、関係者と現在の手順を確認します。次に、止まる場所を観察して、権限・操作・業務ルール・不具合に分けます。解決策を担当者と期限に結び付け、一定期間後に同じ条件で振り返ります。

• 対象業務と対象外、旧手順の終了条件は決まっているか
• 利用者が困ったとき、相談先と回答期限を確認できるか
• 手順書に通常時だけでなく重要な例外も書かれているか
• ログイン数だけでなく、業務が完了したかを確認できるか
• 現場の声が、改善の判断と手順書の更新につながっているか

システムの定着は、導入担当者が一度説明して終える仕事ではありません。現場が使える手順を共有し、例外と相談先を決め、実際の利用から見直すことで、導入目的に近づけます。業務の進め方や未決事項を整理するところから始めたい場合は、Atsumellへ相談することもできます。