IT部門がリードするビジネストランスフォーメーションとは
ビジネストランスフォーメーション。日本語にすると「事業の構造改革」、「業務の抜本的改革」となりますが、このビジネストランスフォーメーションについて私が考えていることを今日は書きます。
常に最重要課題は、顧客のニーズ充足に対して自社がどう対応すべきか。そのためのビジネスプロセスに磨きをかけることです。その手段としてITを効果的に使うことが今日では特に重要になっています。ビジネスプロセスとIT、この2つが改革推進における両輪になりますので、変革プロジェクトにおいては同時に議論されます。
その上で、これらの両輪をつなぐいわば車軸のような役割をするのが組織であり、それをデザインする組織設計のあり方が、事業会社における変革プロジェクト成功において非常に重要な要素となります。どんなに優れた仕組みであっても、自社の組織設計思想に合わないものだと機能しません。組織設計において重要な要素が、「組織風土」と「人」の2つです。「組織風土」とは、何が賞賛されて何が批判されるか、といった行動規範を組織に醸成します。意思決定やコンセンサス形成のプロセスを醸成します。もう一つの「人」ですが、人は往々にして大きな変化を好みません。自分が長年かけて築き上げたスキル・ノウハウの価値が希薄化するような変革は特に好まれません。人は感情を持った動物です。「好き、嫌い」といった主観が支配する世界と、「善、悪」といった理性が支配する両極の世界の間で、常に揺れながらなんとなく雰囲気で意思決定をする情緒的な生き物です。ビジネスプロセス設計とIT設計はロジックが支配する世界です。何が最も効率的か、といった経済原理が支配する「神なき世界」です。ところが組織設計の世界は、あちこちにボスが存在する多神教、「神々の世界」です。変革プロジェクトにおいては、往々にしてこの神々が持っている裁量権という既得権益を大胆に変革するケースが多い。逆の言い方をすれば、こういった神々の持つ既得権益を放置もしくは容認した上での業務改革は、業務改革とは言えない代物である場合が多いでしょう。
高い志をもったメンバーによって構想された「プロセス+IT」が、既存の組織風土に合わず、本番稼働直前で組織風土に合うような「魔改造」を強要され、巨大なポンコツ(=金喰い虫)に変わり果ててしまうような事態、事業会社情報システム部門が直面する日常風景ではないでしょうか。多くの大企業がこのようにして累々と積み重なる屍によって巨大ピラミッド化したERPシステムを「基幹システム」として崇めている光景は滑稽ですらあります。
この組織設計の問題に対して、効果が実証されている「西洋薬」があります。その薬の名前は「チェンジマネジメント」。適当な日本語訳が見つからず、多くの人がこのまま日本語のように使っています。このチェンジマネジメントがなぜ日本人に理解できないかを考えると、ジョブディスクリプション(職務記述書)の問題に行き着きます。新しい「プロセス+IT」が、組織の権限や人々の業務手順を大きく書き換えます。だから、チェンジマネジメントとは、ジョブディスクリプションのAs-Isと、新しい「プロセス+IT」が変革するTo-Beとの差をしっかり掌握して、その変更(チェンジ)をうまくやる(マネージする)ために必要な取組です。ですので、チェンジマネジメントには多くの場合、ラインマネジメントだけではなく、人事部の参画も必要になります。日本企業の多くが、このジョブディスクリプションが明確でないため、もしくは存在しないため、新しい「プロセス+IT」が、一人ひとりの個人の責任と権限と業務手順をどのように変化させるのかを論理的に議論したり記述したりする「場」がない。この「場」が無いために、現象面から見れば、「新システムになって入力が増えて不便だ!生産性が下がった!」という現場意見によって新システムが全否定されるような不幸な状況をもたらします。議論の出口が「使い勝手が悪い」に帰結するところに日本の情報システム、ならびに、情報システム部門で働く人々の不幸があるのです。本来、ある担当者の職務内容に変化が起こり、その結果入力項目が増えるという事自体に何ら問題はないはずです。ジョブディスクリプションが変更され、業務内容が変更されるのです。ジョブディスクリプションの無い世界は、ここでも「神々が支配する世界」を作ります。それぞれの現場にいる担当者が神となってしまう不幸です。
このような環境下で、現場の不平不満を抑えながら、何とか新システムを導入定着する泥沼のような仕事に邁進する仲間達に私は心からエールを送りたい。As-IsとTo-Beのプロセスをパワポで描いて、パッケージシステムをカスタマイズという名の「魔改造」してお金をもらう人たちは気楽です。世の中ではこのような人たちでさえも「コンサル」と呼ぶようです。就職先としても人気だと最近聞きました。事業会社のエンジニアの本領は、現場に居並ぶ神々や各事業部門の責任者という神々を前にして、最終的に全員が納得して腹落ちするような形で、新しい「プロセス+IT」を「組織」に定着するところで発揮されます。私がコンサルでなく事業会社にこだわって働くのは、プロセスとITと組織という3つの課題をジャグリングして綺麗に形作る営みがとても難易度が高いため、誰もが容易に出来ることでもなく、それが下手なりにも30年以上続けると凡人の私でも職人になれ、そのような自分を非常に小さな存在ではありますが誇りに思うからです。
この記事が気に入ったらサポートをしてみませんか?