- 目次
- “個別最適”の弊害
- “個別最適”により引き起こされるIT視点の課題
- “個別最適”になる背景
- プロセスオーナーという役割
- 業務フローを書くことの効果
- ビジネスアナリストという役割
- まとめ
本コラムでは企業の業務プロセスの全体最適化というテーマに絞り、BPM（ビジネスプロセスマネージメント）という概念をご紹介したいと思います。BPMという用語は巷ではいろいろな解釈で使われていますが、ここでは思いっきり広義に捉え、「現状業務プロセスを理解し、調整の必要があればその都度更新し、（企業の全体最適化のために）継続的に管理してゆくこと、そのための仕掛け」と定義します。BPMがなぜ企業の業務プロセスの全体最適化に必要となるのか、という事をできるだけ分かり易く解説できればと思います。
まず、全体最適とはどのような状態のことを指すのでしょう。どんな企業でも製品やサービスをお客様に届け、その対価を得ることでビジネスを成り立たせています。この製品やサービスを準備してお客様の元へ届け、お金をいただくまでの一連の業務、これをEnd to Endプロセスと呼ぶことにします（お客様を起点とする頭からお尻までのプロセスです）。このEnd to Endプロセスにはいろいろな組織が関わり合いバトンを受け渡しながら業務が進んでゆきます。お客様に最高の付加価値を届けようとする心意気はみな同じだと思いますが、時にこれらの組織間では利害がぶつかります。
例えば製造業を例にとってみると、企画部門はできるだけイノベーティブな製品を世に送り出そうとするため、時に自社技術の限界スレスレの企画を打ち出します。この企画に対し、設計部門は実現可能性、採算性、環境問題等の観点で、製造部門は量産化の観点で、営業部門は売上見通しやお客様への納期の観点から意見を戦わせる必要が出てきます。コモディティ商品を製造・販売する企業では、在庫の問題も必ず発生します。事業部は在庫が余って損をすることを避けたい一方で、営業部は品切れを嫌って在庫をたくさん持っておきたい、といったような対立です。また、経理や調達といった事業を横断してある特定の機能やサービスを提供する部署から見ると、事業部A、B、C・・・がみなそれぞれ別々の要求をしてくることにより、共通化をしたくてもできない、といったジレンマもあります。
全体最適とは、このような社内の組織間の対立を全体の視点で天秤にかけ、お客様にとって何が最善か？と考えながら調整した結果の事を指します。声の大きい組織の意見が優先されるような状態は全体最適とは言えません。
“個別最適”の弊害
全体最適の対極にある状態が個別最適と呼ばれます。全体最適を考える人がいない状態と言い換えても良いでしょう。そうすると人々はとにかく自分の組織のミッションのためだけに働き始めます。自分達の論理を外に押し付けようとしてしまう訳です。その結果、次のような課題にぶつかってしまいます。
・お客様ニーズの変化に素早い対応がしにくい
・売上や利益の不振に対し責任所在がたらい回しになり効果的な手が打ちにくい
・部門間の対立構造が深刻化し調整会議にやたらと時間がかかる
・情報がバラバラに管理されるようになり、プロセスが非効率になる
“個別最適”により引き起こされるIT視点の課題
SAP等のERPパッケージが世に普及し、これを業務標準化の道具として展開しようとした企業はたくさんありますが、個別最適のままでパッケージソフトを導入しようとしても、業務の手続きは組織毎に成熟し、既存システムはそれにあわせて使い勝手よく作られていますので、業務ユーザーの視点からは改善どころか、改悪と捉えられてしまいます。さらに、結局は全ての業務領域をERPに置き換えることができないため、既存システムとのインターフェースが膨大な数になります。組織毎にコードやマスタの意味も異なり、企業としてのデータ集計には複雑な変換機能が必要になります。
個別最適を良しとする文化のままでは、現場が強く、ITの活用は組織内の省力化に偏ります。できだけ速く・安くという欲求がありますので、NotesやMS-Access等の手軽なローカルツールやデータベースが組織毎にたくさん作られ、情報が散在してゆきます。これらは往々にして基幹システムとは連動されないので、手作業による情報連携という仕事が増えてゆきます。設計部門では製品毎にCADやPLMツールがバラバラに導入されるといった事も良く見かけます。安いOpen Source技術に走り、セキュリティ問題やパフォーマンス障害をおこすといった例もあります。昨今ではその手軽さからクラウドの業務アプリが採用される傾向にありますが、これを組織毎にやってしまうと、クラウドとクラウド間、クラウドとオンプレ間を結局は手入力でつなぐことになります。
“個別最適”になる背景
個々の組織の部門長さんに会社全体のことを考えるハートがない訳ではないと思います。やっている暇がないのです。私も小さな組織の長ですが、まず自部署の事を考えざるを得ません。組織としての売上向上とコストやリスクの低減は当然のKPIですが、余裕を持って達成できるなんてことは滅多にありません。結局は優先順位が「全体最適を考える」に巡ってこないのです。ではどうしたら良いか。組織をまたいで全体最適化を専門に考える事をミッションとする役割が必要になります。縦割り組織を上にたどってゆくと、それができそうなのは社長になってしまいそうですね。そう、会社の規模が小さい頃はまさに社長がその役割を担っています。しかし大企業ともなるとさすがにお忙し過ぎてそれも無理になります。
プロセスオーナーという役割
全体最適化が高度に進んでいる欧米の企業にはプロセスオーナー制度というものがあります。お忙しい社長に成り代わり、企業の業務プロセスがどうあるべきか、ということを設計し、その運用状況に責任を持つ人のことを指します。プロセスオーナーには所属する部署に応じて二種類のタイプがあります。よく縦軸と横軸と呼ぶことがあります。縦軸とは事業をEnd to Endで見ている組織、すなわち事業部です。一方の横軸とは事業を横断して共有の機能やサービスを提供する組織、経理や調達や営業の支援部（バックオフィス）等を指します。縦軸、横軸のそれぞれに一人のプロセスオーナーを立てる、というのがプロセスオーナー制度です。
縦軸のプロセスオーナーはお客様を起点とし、製品やサービスの企画、設計、製造、販売、物流、そしてお客様へ製品やサービスを届けて代金を回収するまでのEnd to Endプロセスによる価値を如何に最大化するか、ということがミッションです。一方の横軸プロセスオーナーは各事業に提供する機能やサービスをできるだけ標準化し、品質向上とコスト削減を狙います。両者は牽制関係になります。縦軸プロセスオーナーが自分のサプライチェーンをピカピカに最適化しようとすると横軸プロセスオーナーが標準化したサービスでは満足できないケースがあるからです。ですがその悩みはもともと規模の小さかった頃は社長がトレードオフを考えながらさばいてきたものと同じ悩みです。今、社長の代わりとなってその任につくプロセスオーナーは、その利害得失を調整することこそが仕事です。欧米では組織長になる前の幹部候補生達がプロセスオーナーをやります。幹部になるための登竜門という位置づけです。
図1：縦軸と横軸
さて、利害得失を調整すると簡単に書きましたが、実際どこに課題があり、どうしなければならないのかを利害関係者間で共通認識を持ちながら議論するという事は意外と難題です。お互いにお互いの業務を知らないからです。そこで業務プロセスを可視化する、というニーズが自然に起こります。毎度空中戦をやっていては疲れてしまいますから。業務フローというのはITシステムの導入のためにベンダーが書くものだと思っている方も多いかもしれませんが、違います。そのスタンスで書かれた業務フローは何かに偏っていますし、そもそも上で述べたように、経営者の意思を反映して全体最適を考えられた結果ではありません。そんなものを「業務要件」として捉えて作ったシステムがうまくゆくはずがありません。
業務フローを書くことの効果
少し余談になりますが、業務フローを書くことの効果について、触れておきたいと思います。例えば、同じ役割を担い、同じ程度の期間で、同じような成果を出してくれるAさんとBさんがいたとすると、きっとこの二人の業務のやり方は違います。Aさんが自分のやり方をベースにして業務フローを描き、Bさんに見せれば、Bさんはその違いに気づきます。自分の方が優れていると思う部分もあれば、なるほど！と見習いたくなる部分もあるでしょう。Bさんの方が優れている部分をその業務フローに反映すれば、今までになかった、より優れた業務のやり方が生まれます。これが本質的な業務フローの威力です。話を組織間、事業間、拠点間の業務の違いに置き換えるとさらに威力が増します。
ビジネスアナリストという役割
話を元に戻します。プロセスオーナーは互いの牽制関係を合理的に調整するために、業務フローを必要とする、と書きました。しかしプロセスオーナーは業務部門側の方々。当たり前ですが日々業務をやっており、業務フローを書いたりする暇はなかなかありません。これを助けてあげられる最も適役の部署がIT部門です。 昨今、IT部門の中にビジネスアナリストという役割（職種）を設ける企業が徐々に増え始めています。この人達は業務部門側の要求とIT部門側の戦略・方針を整合化する、言ってみればビジネスとITの調整役です。従来の役割で言えば上級SEに近く、実際上級SEだった方がビジネスアナリストにシフトするケースは多いと思います。しかしSEというと個別のITプロジェクトの上流を担うイメージが強いですが、ビジネスアナリストは個々のプロジェクト内で活躍するだけではなく、プロジェクト間を股にかけた調整や、プロジェクトが発足する前の企画段階で業務サイドと会話をすることが主務となります。
図2：ビジネスアナリストという役割
ビジネスアナリストにとってプロセスオーナー達のレビューを受け承認を得た業務フローは宝物です。業務要件を具体的に理解しやすくなりますし、後になってそうではなかったと言われるリスクを回避できるからです。このような業務フローをITの設計・開発に活用することで、ITプロジェクトにおける設計・開発の手戻りを防止したり、受入テストの質を高めたり、運用の属人化を防止したりと、業務フローはITシステムの企画・設計・開発・運用のライフサイクルの生産性向上と品質向上に役立ちますが、この話はまた別の機会にそのテーマに絞ってご紹介したいと思います。
まとめ
さて、ここまで企業が業務の全体最適化にチャレンジするためには、まず縦軸・横軸の業務の利害得失を調整するプロセスオーナーという役割が必要、その調整事に必須となるものが業務フローです、と述べました。しかし、業務部門には業務フローをメンテする暇がないので、彼らに代わって業務フローを作成・維持メンテし、IT戦略と整合性を取りながらITの設計に落とし込むビジネスアナリストという役割をIT部門内に設置することがトレンドです、というのが本コラムの要旨になります。このような大きな”仕掛け”を確立させること自体がBPMです。業務プロセスをマネージメントするための”仕掛け”です（フローの書き方、維持管理の仕方、そのためにはどんなBPMツールを使ったら良いか、等はその後の手段の話です）。
一足飛びに企業の全体最適化に至るなんていう事は夢の話ですが、それを仕事とする人がいないことには一歩も近づくことはできません。こういう話をすると、人がいない、スキルが足りない、効果を出さないと役割・制度など作れないといったご意見を必ず頂きますが、おっしゃる通りで、これらの課題をBPMの先行事例を参考にしながら、ひとつひとつ潰してゆく事以外に、近道はないのではないかと思います。
コメント
投稿にはログインしてください