Staff Blog
社員ブログ

【日経BizGate連載】GRIT! やり抜く変革マネジメント 第3回 ~変革の成否はビジネスプロセスにあり~

2017.09.15

弊社が日経BizGateに連載している【GRIT! やり抜く変革マネジメント】
変革プロジェクトによっては、数値目標は達成したものの、なぜか本質的な部分の変革は達成されていないケースが多く見れます。
本連載ではそのような「変革の失敗」がなぜ起こるのか?について考察したいと思います。

今回は、ビジネスプロセスの重要性についてお話しします。

*本記事は日経BizGateの許可を得て、全文を掲載しています。

----------------------------------------------------------------------------------------------------------------------------

「あなたの会社では日々の業務を、ビジネスプロセスにのっとって行っていますか?」この質問に胸を張って「はい」と答えられる社長さんはどれくらいいるでしょうか?「ビジネスプロセスにのっとっている」と答えた社長さんも、自分の会社でどのようなビジネスプロセスが定義されているのか、すぐ答えられるでしょうか?

私は、日本国内においては、会社が組織としてビジネスプロセスを定義し、現場担当者がその定義にのっとって業務を実施しているケースはかなり少ないと感じています。現場担当者に同じ質問を行うと「ビジネスプロセスはきちんと定義されています」と返答することがありますが、それはほとんどの場合、「現場担当者の頭の中に、属人的な仕事の手順が記憶されていること」を指しています。

変革プロジェクトの成否もビジネスプロセスが握っています。私が経験してきた大規模変革プロジェクトでは、業務を大幅に変更する必要がありましたが、現場担当者の頭の中にしかビジネスプロセスがない場合は、それをすべて明らかにするところからプロジェクトを始める必要がありました。そもそも、ビジネスプロセスの何を、どこを変更すべきなのか、現状がわからなければ変革プロジェクトを進めることはできません。 現場担当者の頭の中であっても、存在していれば、問題ないように思えるかもしれませんが、その状態はビジネス上のリスク以外の何ものでもありません。従業員が転職や退職などすれば、その人の頭の中にある仕事の手順は容易に会社から失われ、混乱が訪れます。

変化の激しい時代に、ビジネスプロセスを定義するのは無駄だという人はいます。顧客は短期間で入れ替わり取引条件も変わります。新製品を次々と出さないと売り上げは維持できませんが、製造や配送の手順は製品ごとに変わります。そのため、ビジネスプロセスは、現場担当者の頭の中にある状態が最も現実的だというのです。

しかし、私は「しょせんプロセス、されどプロセス」だと思います。理由はこれから説明しますが、ビジネスプロセス(および、その定義)は、ビジネス戦略を科学的に実現するために不可欠であり、あるべきビジネス戦略の実現を目指す変革プロジェクトにとっても同様に不可欠だからです。

ビジネスプロセスは会社による業務の定義


そもそも、ビジネスプロセスとは何でしょうか。ビジネスプロセスを簡単に言えば、業務で実施する活動の集まりです。例えば、法人向けのITシステムの営業では、「RFP(提案依頼)」→「提案」→「見積もり」→「契約」といった業務の流れがありますが、「提案」「見積もり」などの1つ1つをプロセスと呼びます。
また、ビジネスプロセスは「概要レベル」~「詳細レベル」まで、詳しさに応じて階層化されます。例えば「提案」というビジネスプロセスが「概要レベル」だとすれば、「提案」は、さらに「顧客の問題/課題設定」「ソリューション検討」「提案書作成」「提案書内部承認」といった「詳細レベル」のビジネスプロセスに分かれます(これは一例です。プロセスの定義や粒度は会社によって違うものです)。
本来、ビジネスプロセスは、会社にとって、あるべき姿のビジネスモデル(価値を創出する仕組み)や、そのオペレーティングモデル(組織のあり方)の実現を目指すべくビジネス戦略に沿って定義されるもので、そのビジネスプロセスにのっとって業務を行うことで、現場担当者は会社の価値創造へ貢献することができるという関係にあります。
その目的を達成するため、ビジネスプロセスは思慮深く定義されます。そして、現場担当者は、ビジネスプロセスに基づき的確に業務を実施するように教育される必要があります。またビジネスプロセスにオーナー(ビジネスプロセスオーナー)がアサインされ、担当したプロセスについては絶対の責任を持つことが大切です。

重要なのに軽視されるビジネスプロセス


一方、ビジネスプロセスがきちんと定義されていない状態、またはビジネスプロセスが定義されていたとしても現場担当者がそのプロセスにのっとって業務を行うように教育されていない状態はビジネス上のリスクが大きいと言えます。例えば、上述したように変革時にすばやく対応できない恐れのある「変革リスク」、顧客との契約価格通りにソリューションを提供できない恐れなどの「顧客へのサービス提供リスク」、退職者・転職者に代わって業務をスムーズに対応できない恐れのある「後継者不在リスク」などです。
ここでは第2回でも触れた「変革リスク」を中心に説明しましょう。ご存知のように、業務とITが一体となった昨今、人事・財務、製造・販売・在庫管理といった業務の変革にERP(統合基幹業務システム)パッケージなどのITを活用するプロジェクトが増えています。しかし、単にITを導入すれば業務が変革され、組織にイノベーションを起こせると思っていらっしゃる方が少なくないようです。第2回の繰り返しになりますが、もちろんITは魔法の杖ではありません。
ITを活用した変革プロジェクトにコンサルタントとして参加したときに気になるのは、プロジェクト進捗管理などの会議体において、ビジネスプロセスの変更に関する報告がほとんど行われないことです。ほとんどは、ITの導入に関する報告であり、ITの準備がどれくらい進んだかといったものです。業務の現場担当者もその会議体に参加しているのですが、興味の対象がITの進捗に偏る傾向があります。
その場合、私は「IT導入」に関して準備しておかなければならないポイントを中心に、プロジェクトマネージャー、プロジェクトメンバーにインタビューをさせてもらい課題をまとめるようにしています。もちろんビジネスプロセスの変更に関する準備がどれぐらい進んでいるかということも対象です。
具体的には「危機感」「ビジョン・ゴール」「変革チーム体制」「変革スケジュール」「戦略的コミュニケーション」「レディネス(組織体制、役割と責任、人事制度、ビジネスプロセスなど、組織環境準備状況)」といった、変革に際して整えなければならないポイントを中心に、プロジェクトの影響を受ける方々に約50項目のインタビューをさせていただいています(これは変革プロジェクト実施中のお客様に「チェンジマネジメント診断」という形でサービスを提供させていただいています)。

診断結果は残念ながら一般に芳しくありません。不思議なことに、IT導入によって、自分の仕事がどのように変わるかということはみなさん気にされますが、これは自分のことですので、ある意味で当然でしょう。しかし、全体として会社の業務がどうなるのかについては関心の外になる傾向があります。

つまり、変革プロジェクトを行いながら、誰も現行のビジネスプロセスを分析していないし、変革後のあるべきビジネスプロセスについて誰も考えていない――といった不可解な状況になります。
ビジネスプロセスについての調査・検討が全くなされていないのは、「ITはしょせん道具なので、どうにかなる!なんとかなる!」という楽観もあるようですが、マイナスの影響がかなり大きいと言わざるを得ません。ERPのような基幹業務を大きく変革するITを導入する際には一般に業務の標準化が不可欠になります。これは業務担当者各自が頭の中に持っている業務手順を洗い出して、あるべき姿のビジネスプロセスを議論しないとどうにも進みません。

ビジネスプロセス定義の壁を乗り越える


では、変革プロジェクトで、ビジネスプロセスに関する検討が不十分であることに気がついたら、何をすべきでしょうか?ビジネスプロセスの検討を始めても、多くの会社が突き当たるのは、会社としてのビジネスプロセスが分からないという事態です。まずはその壁を乗り越える必要があります。
主な状況は次の3つです。
第一に、会社が公式に定義したビジネスプロセスがないことです。冒頭でお話ししたように、あえていうと、現場担当者の頭の中に属人的に存在していますが、属人的であるため、同じ業務を10人が担当しているとすれば、ビジネスプロセスが10通りあります。それらを洗い出すところからビジネスプロセスの定義を始めることになります。
第二に、どの担当者もご自身のビジネスプロセスに対して、「これが正しい!」と責任を持って言える権限がありません。つまり、それぞれのビジネスプロセスにオーナーがいないのです。どの担当者のビジネスプロセスを"正しい(標準)"とするのかを決定する権限を持つビジネスプロセスオーナーを決めて、会社としてのビジネスプロセスを定義する必要があります。
以上のような状況により、多くの変革プロジェクトでは、まず現在のビジネスプロセスをどう定義するのかという段階で非常に時間がかかり、プロジェクトが進まなくなりますが、辛抱強く乗り越えてください。
さらに第三に、協力会社へ業務をアウトソースしていて、社内の誰もその業務内容(ひいてはビジネスプロセス)を知らないという状況があります。
確かに一時期、コア業務に集中するため、やみくもにコア業務以外をアウトソーシングする変革が流行りました。コスト削減が主な目的ですが、その結果、現場担当者が不在になり、社内でその業務の中身が分かる人がいなくなるといったことが起きています。この場合、変革プロジェクトには、アウトソーシング先のベンダーにも参加してもらうようにします。場合によっては、プロジェクトに参加してもらうための新たな契約を締結しなければなりません。契約のためにプロジェクトが停滞しますし、プロジェクトの予算も増えますが、やむを得ません。心当たりのある方は、将来に備えたインソーシングの検討をお勧めします。
特に昨今では人的作業プロセスを自動化するソフトウエアソリューション「ロボティクス・プロセス・オートメーション(RPA)」を採り入れるといった流れもできてきています。その際にはビジネスプロセスなくして効果的な検討はできません。

ビジネスプロセスは「個別プロセス」の集合体ではない


さあ、上記のような状況に突き当たりながら、壁を乗り越え、なんとか現状のビジネスプロセスを把握できたとしましょう。そして、ITの導入によって、どのようにビジネスプロセスが変わるのか(変えるべきなのか)もわかったとします。つまり、あるべき姿の業務を実現する新しいビジネスプロセスを定義しました。
そこで次に突き当たる壁は、それらの新しいビジネスプロセスは、会社全体の視点でまとめられていないため、全体の整合性がとれていないことです。例えば、1カ所変更すればあっちも変える、あっちを変えればそっちも変えるというように、変更を繰り返すケースが当てはまります。こうなると、もう最終決定とは言えません。
それでもやっと新しいビジネスプロセスを最終決定できたと思ったら、業務処理ボリュームの把握がまだで、どのビジネスプロセスをどこの組織がどういう責任で実施するのか、そのためにどんな社員が必要なのかが定義できていないなどのために、新しいビジネスプロセスにのっとった業務が回らないという問題に出会うかもしれません。
このように、ビジネスプロセスを定義するということは、仕事の進め方を定義するだけでなく、そこに発生する業務ボリュームなど、いろいろな側面から検討して定義する必要があります。
ビジネスプロセスを定義したあとも、安心してはいけません。可能な範囲で文書化していつでも参照できるようにします。ビジネスプロセスを定義して文書を作成した一部の人だけが知っているというだけで、現場に展開されて活用されていないケースも多いのです。非常にもったいないことです。

ビジネスプロセスもマネジメントする


こんなに苦労して決めるビジネスプロセスですが、永遠に守り続けるものではないのもまた事実です。「ビジネスプロセスマネジメント(BPM)」という言葉を聞いたことがあるでしょうか?おおまかにいうと、企業の活動をビジネスプロセスの視点でとらえ、継続的に改善を続けることです。
まだ国内では馴染みがないかもしれませんが、BPMを正しく実施すれば、継続的に変革を進め、継続的にビジネス環境の変化を吸収し続けていくことができます。つまり会社が外部環境の変化に対して"アジャイル(俊敏に対応できる状態)"でいられるのです。
この記事をここまで読まれた方はもうおわかりでしょう。BPMでは会社のビジネス戦略に即したビジネスモデルが必要です。そしてビジネスモデルを現場担当者が確実に実行するためのオペレーティングモデル、ビジネスプロセスが必要です。ビジネスプロセスオーナーをアサインし、現場への教育、プロセスの評価と継続的改善などを実施していきます。これはビジネスプロセスを定義して、その視点で変革プロジェクトを日々、実行しようという発想です。
ここでも最後に決め手となるのは、社長さんの熱い「想い」です。「想い」をもとにビジョンや戦略ができており、ビジネスプロセスにまで結びついたものになっていれば、「想い」が現場に展開されているはずなのです。プロセスオーナーはその「想い」が詰まったビジネスプロセスを現場に教育して変革を継続していく責任者です。
以上のように見ると、ビジネスプロセスは、まさに会社の強さを決める手段です。さあ、「想い」の詰まったビジネスプロセスを定義し、今一度、現場へ持っていきましょう!

出展:日経BizGate 2017年9月15日掲載記事

 

 

Our Business

Contact