業務改革のキモ:本社は現場にどこまで関与すべきか?
デスクワークが多いせいか、時に首や肩がひどく凝ることがあり、マッサージに行くことがあります。
先日は、マッサージではなく整体に行ったのですが、そこで言われたのが、「日々のちょっとした姿勢のズレが、積もり積もって大きなひずみになり、痛みにつながる」ということです。
その時は、楽だからと選んでいたことも、積み重なると取り返しのつかないところまでひずんでしまいます。
これは、体に限らず、会社の組織でも同様のことが起こっています。
ある企業で経営支援をしていた時のことです。
この会社は、長らくの経営不振のため、会社の至るところでコストの切り詰めをしていました。
その波は、当然情報システム部門にまで及びます。
この会社の情報インフラは、基本的には自前主義を取っており、基盤となるである生産管理システムは自社の情報システム部門で作っていました。
しかし、コスト切り詰めは、人員の削減だけでなく、新規のIT投資も見合わされてしまい、古いシステムを修繕を繰り返し、だましだましして使い続けました。
ここで、この会社は現状を打開するために新規事業に始めます。
しかし、この新規事業は既存の事業とは全く生産方法が異なり、従来の情報システムでは十分に対応できない点が多くありました。
この状況に対して、この会社で何が起きたと思いますか?
既存のシステムでカバーしきれない処理をExcelやAccessといった業務アプリケーションのマクロ(自動化プログラム)をいくつも作成していったのです。
このプログラムは、リストラを免れた情報システム部門の社員が作ったものもありましたが、各部門でプログラムに詳しい社員が作成したもの方が多かったです。
この各部門で作られたプログラムは、情報システム部門があずかり知らないところで、当然のことながら仕様書や設計書もない状況でした。
このため、あるプログラムを修正しようとしても、その作成者がすでに退社している場合があり、そのプログラムには手をつけず、穴埋めをするプログラムをさらに追加していました。
結果的に、このような小プログラムが基幹システムの周辺に自然大量発生し、手がつけられない状態に陥りました。
私が支援した時の課題の一つに、情報システムの刷新がありました。
世の中に広まっている業務アプリケーションを導入しようとしても、「ガラパゴス」的に深化してしまった社内システムとの開きは大きく、システム導入にあたっても大幅な特殊対応(カスタム開発)が必要となりました。
その時々では、良かれと思って行われたことも、積み重なると大きなひずみになると言う一例です。
近頃、RPAの導入がブームになっています。
RPAとは、Robotic Process Automationの略で、認知技術を活用した業務の自動化で、特にホワイトカラーの業務の効率化・削減に大いに効果を発揮すると言われています。
また、RPAは従来のシステム開発のように大規模なプロジェクトは必要なく、各現場で試行錯誤しながら独自に導入が可能という点が売り文句となっています。
しかし、ここでも同様の現場が独自にRPAを導入すると、本社が管理している基幹システムに変更が起きた時にその対応も現場任せになってしまいます。
最悪の場合、基幹システムの変更とのズレが発生し、業務の停止などの危険性があります。
また、現場が勝手に導入を推進してしまうので、簡単に作れるという点から、本来的には不要なものまでが導入されてしまうこともあります。
このようなシステムは「野良ロボット」と呼ばれています。
いずれにしても、本社がどこまで現場の活動をコントロールするかが鍵になります。
BPR(ビジネス・プロセス・リエンジニアリング)の大家であるマイケル ハマーとジェイムズ チャンピーは、その共著の「リエンジニアリング革命」の中で、BPRが成功するために
も、本社と現場の間でのバランス(分権化と集中化のバランス)が重要になると言っています。