APPROACH / BUSINESS TRANSFORMATION
06
Transformation
業務変革は、解く順番を決めると動き出す
課題を並べ替えるのではなく、解く順番を決める。現場の事実から出発し、
小さく試し、体制に落とし込むまでの進め方を紹介します。
01
PROBLEM
変革が止まるのは、計画のせいとは限らない
業務変革の相談を受けるとき、多くの場合すでに課題は書き出されています。それでも前に進まない。理由は三つに集約されます。
一つは、課題が現場の実態とずれていること。二つ目は、担当と権限が曖昧なこと。三つ目は、日々の業務に追われ、検討の時間が確保されないことです。
Dexallは、この三つを順に解きます。最初に事実を集め、次に解く順番を決め、最後に推進の設計を行います。立派な計画書を作ることより、翌週から動く状態をつくることを優先します。
02
APPROACH
取り組みは、四つの層で設計する
- 01
業務の事実を書き出す
ヒアリングではなく、実際の手順と使用中の資料を確認します。例外処理の発生頻度まで記録します。
- 02
手戻りと待ちの構造を特定する
どこで情報が止まるか、誰の承認待ちが発生するかを可視化します。
- 03
変革テーマを一つに絞る
同時に複数を動かすと現場が疲弊します。最初の対象を決め、そこに資源を寄せます。
- 04
推進の設計を行う
意思決定の場、確認の頻度、役割分担を決め、進捗が止まらない形にします。
03
IMPLEMENTATION
実装は、現場の確認と同時に進める
01
試行範囲を決める
一部のチーム、一部の業務に限定して始めます。
02
現場と一緒に作る
画面・帳票・手順書を、使う人と確認しながら詰めます。
03
数字で確認する
処理時間、待ち時間、手戻り件数で変化を確認します。
04
範囲を広げる
効果と負荷を確認してから、対象を広げます。
変革の成否は、導入時に決まるのではなく、導入後に誰が面倒を見るかで決まります。DEXALL / APPROACH NOTE
04
ADOPTION
定着は、運用の設計で決まる
新しい手順が定着しない原因は、多くの場合、例外時の対応が決まっていないことです。通常フローだけを設計しても、現場は例外に直面します。
Dexallは、例外処理、エスカレーションの経路、記録の残し方までを設計に含めます。加えて、運用を担う担当者を決め、改善要望の取り込み経路を用意します。
- 例外時の判断基準を明文化する
- 運用責任者と、改善要望の窓口を決める
- 定期的に効果を確認する場を設ける
05
FIT
このアプローチが向くケース
- 改善の施策が複数あるが、優先順位が決まらない
- 部署をまたぐ業務で、責任範囲が曖昧になっている
- 過去の施策が現場に定着せず、手作業に戻ってしまった
CONTACT
変革の設計から、一緒に始めます
現状の業務と、止まっている理由をお聞きします。