ＩＴ領域で様々な情報を提供することで知られる某社から送られてきたパンフレットを眺めていたら、次のような記事がありました。ある会社で業務改革のプロジェクトが発足したものの、基幹系システムのブラッシュアップを主張する現場とＲＰＡを進めたいリーダとの意見の衝突が起きたそうです。
どの様な目的で業務改革プロジェクトを発足させた背景が分かりませんが、現場担当者は基幹系システムの手直しを、リーダはＲＰＡを進めたいとのこと。この２人、業務改革をこの様な捉え方をしているのかと思います。そもそも、業務改革は必ずしも情報システム（ＩＴ化）を前提とはしていないことに気が付かなければなりません。今日はこれをネタにして業務改革を取り上げます。
改めて言うまもでありませんが、業務改善と業務改革を取り違えている場合が散見されます。業務改革、改善を仕事としているこの私も違いを理解していないのではないかと指摘されてしまったことがあります。指摘した方はゼネコンのＣＩＯ経験者ですが、自ら汗をかき、泥をかぶってやったことがなく、机上から指示をする典型的な口先介入タイプ。能書きを語ることしかできないこの種の評論家的輩と改善改革の意味合い論争に時間を使っている暇はないので、テキトーに聞き流しましたが『アンタには言われたくない』の典型でした。それはともかく、誤解のないよう定義を以下に。
改善と改革の言葉の意味が分れば当たり前のことですが、前者は今の仕事のやり方の延長線上、後者はまったく別の路線です。改善なのに、本人は改革のつもりが改善だったりすることもあるかも知れませんが、素人や机上の空論を戦わす評論家的コンサルタントならともかく、泥かぶって実践で腕を磨き、成果を上げてきた経歴の持ち主が主導している場合にはあり得ないでしょう。
細かな違いをくどくどという方もいますが、業務改革はＢＰＲと一緒だと思って構いません。いずれも過去にとらわれないパラダイムシフトが必要です。私は業務改革の前に意識改革と言っていますが、上から下まで意識改革できていないと仕事の流れを変える改革はできません。問答無用な上意下達では下がついてこないし、下が頑張っても上の意識が変わっていなければ実効ある改革はおぼつきません。長年に亘ってしみつき、空気や水のようになっている仕事の仕方、流れを変えるのは容易ではありませんが、作業効率向上、人時生産性の向上を図るには必須です。中央青山監査法人（当時）の資料を紹介しましょう。
業務改革･･･業務を再定義し機能を明確にすることから始めます。次にその機能を満たすためには何が必要なのか（情報）を洗い出します。この時、重要なのは当該業務が全社の業務のどの部分に当たるのか、且つその業務と関連する業務、関連するシステムは何かを把握しておくことです。もちろん、これら業務間でやり取りされる情報も把握します。
従前の仕事の仕方をリセットして業務を再定義することで、重複のない仕事の仕方になります。その結果、組織の生産性が向上することになり、業務改革の成果を実感できるようになります。ここまでやってから、システムに載せる必要があれば当該業務をシステムに載せるための作業（仕様、設計、開発、テスト、運用）に入ります。すなわち、業務改善、改革したからと言ってシステム化が必須とは限らないことに注意が必要です。冒頭に掲げた業務改善プロジェクトで現場担当者とリーダのやりたいことが対立したことを称して、両者とも業務改革の意味を理解していないと言ったのはそういうことです。二人とも、業務改善・改革＝システムをいじることと理解していました。思考の範囲が狭いというか本質を理解していないということです。
※質問はosugisama@gmail.comにどうぞ！
※リブログを除き、本ブログの無断転載、流用を禁じます。