システムを入れる前に、部屋を片付ける｜業務整理で本当に難しいのは、「手放す」と決めること
「新しいシステムを入れれば、もっと効率的になる」
そう考えて、システム刷新を始める。
ところが、いざ導入してみると、思ったほど仕事は減らない。
画面は新しくなった。Excelも減った。それなのに、入力項目は多い。承認も多い。例外処理も多い。
なぜでしょうか。
原因は、新しいシステムそのものではないかもしれません。
古い業務のやり方を、そのまま新しいシステムへ引っ越してしまった。
そこに問題があることがあります。
散らかった部屋に、収納を増やしても片付かない
散らかった部屋に、新しい収納棚を買ってくる。
床に置かれていたものを全部棚に入れれば、確かに床はきれいになります。
しかし、使っていないもの、壊れているもの、なぜ持っているのか分からないものまで、きれいに収納されただけかもしれません。
収納は増えました。
しかし、片付いたわけではありません。
システム導入も、これとよく似ています。
現在の業務をそのまま新しいシステムに載せれば、それまで人間が処理していた複雑さが、画面、項目、ワークフロー、マスター、権限設定としてシステムの中に固定されていきます。
- 昔からある承認
- 誰が使っているのか分からない帳票
- 念のため続けている確認作業
- 旧システムの都合で始まった二重入力
それらをすべて新しいシステムへ持ち込めば、出来上がるのは、
「電子化された、今までの仕事」
です。
では、不要な業務をなくせばいい。
話は簡単に見えます。
しかし、実際の業務整理が難しいのは、ここからです。
なぜ、誰も「やめよう」と言わないのか
例えば、ある帳票があります。
毎月作成していますが、最近はほとんど使われていません。
そこで担当者に聞きます。
「この帳票、今も必要ですか？」
少し考えて、
「ほとんど見ていません」
と答える。
では、
「なくしても大丈夫ですか？」
と聞く。
すると、
「……何かあったときに困るので、残しておいた方がいいと思います」
となる。
これは珍しい話ではありません。
合理性だけを考えれば、ほとんど使われていない帳票は廃止候補です。
しかし、担当者からすると事情が違います。
帳票を今までどおり作り続けて問題が起きても、
「従来どおり運用していました」
と言えます。
一方、自分の判断で帳票を廃止し、その後で何か問題が起きれば、
「なぜ、なくしたのか」
と問われます。
続ける責任より、やめる責任の方が重い。
これが、業務がなかなか減らない理由の一つです。
承認も同じです。
「この承認は必要ですか？」
と聞けば、多くの場合「必要です」と返ってきます。
それは、現場が変化を嫌っているからとは限りません。
承認を一つ減らした結果、ミスや不正が起きたとき、そのリスクを担当者個人では引き受けられないからです。
だから、
「この業務、本当に必要ですか？」と現場に聞くだけでは、業務はなかなか減りません。
業務を変えるということは、作業を減らすことだけではありません。
その作業によって抑えていたリスクを、これからどう扱うのかを決めることでもあります。
業務を「守る・活かす・手放す」に分ける
だからといって、現在の業務をすべて疑い、できるだけ減らせばよいわけでもありません。
非効率に見えても、残すべき仕事はあります。
そこで、現在の業務を大きく三つに分けて考えてみます。
| 分類 | 判断基準 | 典型例 |
|---|---|---|
| 守る | 外すことのできない制約か | 法令、契約、内部統制、セキュリティ上の要件 |
| 活かす | 自社の価値や競争力につながっているか | 独自の顧客対応、商品・サービス固有の業務 |
| 手放す | 今も続ける合理的な理由があるか | 旧システムの制約、二重入力、形骸化した帳票や確認作業 |
例えば、顧客からの注文に対して、人が一本ずつ電話で確認している業務があったとします。
効率だけを考えれば、自動化したくなります。
しかし、その電話で顧客の細かな要望を聞き取り、それが他社との差別化になっているのであれば、単なる「無駄な手作業」とは言えません。
それは、「活かす」業務かもしれません。
一方、
「前のシステムではデータを連携できなかったので、Excelへ一度出して再入力している」
のであれば、新しいシステムでも残す理由はほとんどありません。
これは、「手放す」候補です。
そして法令や契約によって必要な確認であれば、効率が悪く見えても簡単には外せません。
これは、「守る」業務です。
業務整理とは、すべてを効率化することではありません。
何を守り、何を自社の強みとして活かし、何をこの機会に手放すのかを決めることです。
「手放す判断」を、現場に丸投げしない
問題は、「手放す」候補が見つかった後です。
例えば、すべての受注について部長承認を行っている会社があったとします。
現場へ、
「この承認、なくしていいですか？」
と聞くだけでは、なかなか「はい」とは言えません。
そこで、問いを変えます。
そもそも、この承認は何を防ぐためにあるのか。
仮に、
「金額間違いを防ぐため」
だったとします。
次に確認します。
- どのくらいの頻度で間違いが起きているのか
- どの程度の金額なら問題になるのか
- すべての受注で同じリスクがあるのか
- システムによるチェックで代替できないのか
例えば調べた結果、
- 通常価格の商品では、ほとんど金額間違いが起きていない
- 値引率が一定以上の場合にミスが集中している
- 高額案件では、誤入力した場合の影響が大きい
と分かったとします。
そうであれば、
全件を部長承認する
以外にも、
- 一定金額以上だけ承認する
- 値引率が一定以上の場合だけ承認する
- 通常価格との差異をシステムでチェックする
といった選択肢が出てきます。
ここまで材料が揃えば、初めて、
「どこまでのリスクを会社として許容するか」
という意思決定ができます。
これは、担当者個人に、
「承認をなくして大丈夫ですよね？」
と判断させる話ではありません。
承認を減らすことで生じるリスクと、承認を続けることで生じるコストを並べ、プロジェクトオーナーや経営が判断する。
業務を手放すとは、単に仕事を減らすことではありません。
その仕事が担っていたリスクを、会社としてどう引き受けるかを決めることです。
「今あるものは全部残して、効率化してください」
この意思決定をしないままシステム導入を始めると、よくある状況が生まれます。
- 営業部：「この帳票は必要です」
- 経理部：「この承認は残してください」
- 物流部：「このExcelも使えないと困ります」
- 情報システム部：「できるだけ標準機能でお願いします」
- 経営：「せっかく刷新するんだから、業務も効率化してほしい」
一つひとつは、もっともな要求です。
しかし、全部を合わせると、
「今あるものは全部残して、今までとは違う、もっと効率的なシステムにしてください」
という発注になります。
ベンダーにとって、かなり難しい注文です。
現在の業務をすべて要件として持ち込めば、カスタマイズは増えます。画面は複雑になります。例外処理も増えます。
そして完成したころには、
「新しくなったけれど、あまり仕事は変わっていない」
となる。
システムが悪かったとは限りません。
変えないと決めたものが多すぎただけかもしれません。
決めるのは発注側。でも、決められる状態は作れる
では、業務整理はすべて自社だけで行うべきなのでしょうか。
そういうことではありません。
外部の専門家が、
「この承認は不要です」
「この帳票は廃止してください」
と会社の代わりに決めることはできません。
しかし、会社が判断できる状態を作ることはできます。
例えば、
- 「なぜ、この業務が必要なのか」
- 「年間何件行われているのか」
- 「どの程度の工数がかかっているのか」
- 「なくした場合、どのようなリスクがあるのか」
- 「そのリスクを別の方法で抑えられないか」
を整理する。
さらに、営業、経理、物流、情報システムなど、部門ごとに異なる意見を並べ、
どこが事実の違いで、どこが利害の違いで、どこからが会社としての判断なのか
を切り分ける。
ここに、第三者が入る意味があります。
外部の役割は、「正解」を持ち込むことではありません。
まして、業務フローをきれいに描くだけでもありません。
社内だけでは動かなくなった議論を整理し、会社が判断できる材料を作ること。
そのうえで、
何を守るのか。
何を活かすのか。
何を手放すのか。
最後に決めるのは、発注側です。
システムを選ぶのは、その後です。
システムを決める前の、業務整理からご支援します
「現行業務をどこまで残すべきか判断できない」
「各部門に聞くと、すべて『必要』と言われてしまう」
「業務を変えたいが、どこまで変えてよいのか社内で決められない」
オーシャン・アンド・パートナーズでは、システムやベンダーを選ぶ前の段階から、現状業務の整理、課題の構造化、部門間の論点整理、あるべき業務の検討、システム化範囲の整理まで、発注側の立場で支援しています。
私たちが「この業務は捨てるべきです」と代わりに決めるわけではありません。
なぜ必要なのか。
なくすと何が起きるのか。
別の方法はないのか。
判断材料を整理し、発注側が決められる状態をつくります。
システムの話を始める前に、まず今の業務を「守る・活かす・手放す」に分けるところから、ご相談いただけます。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
