ＢＰＭの理解を阻害する業務フローとシステムに関する固定概念
今年に入ってから、表題にあるような固定概念を中々解消できない。解消できないことに苦しんでいるお客様が沢山いると感じます。過去の固定概念から抜け出せない方々、とくに上層部にそういった方が多いということかと思います。
私と同世代（私は１９６１年生まれです。同世代とは前後５年程度と考えてください）の方々はボーダーラインの世代だと思っています。「ワープロ、パソコン、基幹システムの端末は机の上には無く、壁際の専用ラックに並べられており、必要なときに専門の人達が壁際に移動して使うものであり普通の人が使うものではない。」という概念が崩れ始めていたころでした。その概念が崩れて「こちら側に来た人」と「こちら側に来なかった人」の両方がいるという意味でのボーダーラインです。また業務改善経験があるかないか、という意味でもボーダーラインと言えます。
いろいろなお客様の話を聞いていると、問題は「こちら側に来なかった人」と「この３０年間で業務改善を経験してこなかった人」が上層部におり、ＢＰＭ、業務改善の「足かせ」になってはいないかという懸念を抱きます。世の中が「ＤＸ，ＤＸ」って叫んでいるので「ＤＸ部門を作る」ということで満足し、結局は「上手なプレゼンに乗せられてＩＴツールに飛びつく」、結果としてシステムが乱立する、多額のお金をかけてツールを導入し開発しても現場には受け入れられず使われない。というようなことが起こっていると感じます。
抜け出せない固定概念とは、以下の４つにまとめられると思います。
①「業務フローは補足資料」
②「業務フローは描くだけで改善が達成できる」
③「システムは作業の自動化を実現するもの」
④「業務フローはシステムで作業の自動化できるところを探すためのもの」
①と②、③と④の括りで述べてみたいと思います。
１．業務フローの役割
①「業務フローは補足資料」②「業務フローは描くだけで改善が達成できる」
ＩＴシステムの要件定義書において業務フローの役割は補足資料だと言えるでしょう（ＩＳＯの○○マニュアルにおいても補足資料であると思います）。このイメージを持ったままの人が多いと思われます。その場合、ＢＰＭＮで描く理由は「業務フローの描き方を統一させたいから」というだけです。前回までのコラムで総務省のサイトから公開されている業務フローが「ＢＰＭＮもどき」になってしまう理由はそこにあります。「ＢＰＭＮもどき」の図は補足資料なので、本文の文章を読まないと結局は業務内容が理解できないという結果になっています。「統一」と言っていますが何が統一できているのか疑問です。
次に「業務フローを描くだけで改善ができる」という商売をされている方々がいます。それだけで業務改善ができているのであればＤＸなどという言葉は必要無かったでしょう。残念ながら業務フローを描くだけで改善が実現できるというのは「改善ゴッコ」の領域から出ておらず、絵に描いた餅でしかないと思われます。「改善研修」の中では活発な議論ができて改善している気分になり、疑似的であっても普段の業務では味わえない達成感を得るのだと思います。そういった経験を持っている人は「業務フローを描くと改善できる」という妄想を持つことになるのでしょう。
しかしながら、あるべき姿の業務フローを描いてもフロー通りに業務を行っていない。業務フローを守って業務を行っているかという確認する術もない（プロセスマイニング・ツールはＩＴシステムを使ってない業務は分析できない）。何等かの問題が発覚してから間違ったやり方をしていたということが後から発覚する。というのが現実ではないでしょうか。現在、自動車メーカーや製薬会社など業界に関わらずマスコミをにぎわす「○○不正問題」が象徴的です。それぞれの会社はＩＳＯの認証を取得し維持されていると思います。形式では現実の業務を正しく維持できないということを立証しているようなものだと思います。または上層部が強く、具体的な指示を出せば解決することでもありません（「ＢＰＭと日本型経営システム」参照）。ＢＰＭというマネジメント手法がなければ、この問題は「永遠の課題」であったでしょう。
２．「作業の自動化」できるところを探す
③「システムは作業の自動化をするもの」
④「業務フローはシステムで作業の自動化できるところを探すためのもの」
システムは「作業の自動化」をするものだという固定概念を持っている人が本当に多いです。基幹システムなどで行われている「作業の自動化」は、各業務、各部門で共通で使える部分しか作ることができないです。「各業務、各部門の個別の要望」に応えて作ろうとすると莫大な費用と時間がかかることになるからです。費用対効果という問題も発生します。ＣＲＭやＳＦＡなどを導入している場合も同じです。結局、共通的に使う部分しか導入できず、使う人にとってはメリットを見出すことができないものができてしまいます。使う側にとってメリットのないＩＴツールは結局「使われない」という結果を生みます。
「システムは作業の自動化をするもの」という概念に囚われているとＢＰＭを理解することは困難です。この考えから抜け出せない人は「業務フローは作業の自動化ができるところを探すために描く」ということを言われます。ＲＰＡが大流行していたときも我々にそういった依頼が来ました。「その目的であればＢＰＭＮで描く必要はありません。」とお断りをしていました。もし受けてしまっていると「自動化ができない『人が行う作業、業務』まで、なぜ詳細に業務フローに描くのか」「現在、基幹システムで行っていることまで、なぜ描くのか」というお客様の疑問に答えられなくなるためです。「ＢＰＭＮはＢＰＭＳに実装しＢＰＭを行うために作られた業務フローですので」と言っても理解していただけるはずがないからです。（関連コラム「あなたが描いているのはＢＰＭＮ図ではありません」参照）
３．まとめ
ＢＰＭＮ図は何のために描くかは、関連ぺージ、コラムを読んでいただければと思いますが、主に「業務を標準化して業務の受渡しを自動化する。」ために描きます。言い換えればＢＰＭＳを使って、あるべき姿の業務フロー通りに業務を行うためにＢＰＭＮ図を描くということになります。すなわちＢＰＭＳの画面だけを見て業務を行えば、業務を効率良く、間違いなく実行できるということを目指すことです。そのレベルは様々であり、単なる「動く業務マニュアル」かもしれません。基幹システムなど他のシステムとの自動連携がされているかもしれません。他システム間連携のために使われることもあるでしょう。それには正解はありませんし、どれが完成という姿もありません。「改善は永遠」だからです。
ＢＰＭＳの主な機能は「業務の標準化」です（ＢＰＭの改善ステップの５です。現在はプロトタイプという言葉を使ってしまっていますがプロトタイプではありません。ここだけで業務の標準化改善が実現します）。ＢＰＭＳには「作業の自動化」のためのローコード開発機能（ＢＰＭの改善ステップの６）も含まれていますが、それを中心に考えるとＢＰＭＳとローコード開発ツールとの違いが理解できない原因となるでしょう。以下の図で説明していますが「業務の受渡の自動化」とは何かは次回のコラムで説明したいと思います。（画像をクリックすると拡大されます。）
ＢＰＭがメーカー出身者（私も含めて）、メーカーの方々に「理解しやすい」「受入れやすい」のは、製造現場の作業の標準化と自動化の関係と似ているからです。作業を標準化して実行し、その後、実績データを分析をして課題を見つけ「作業方法を変えて改善する」「治具や省力化・自動化設備を導入して改善する」ということに似ているということです。決して省力化・自動化設備の導入をすることだけが作業改善ではない、ということを理解できるからだと思います。
ここに書かれていることだけでは誤解が生じることもあると思います。詳細なＢＰＭに関する解説、事例を知る、議論をして疑問を解消するために、是非「BPM入門 基礎知識＋事例セミナー」を受講していただければと思います。
