BPMで非定型業務をスモールスタートで標準化する

　BPMはスモールスタートにしなければならない理由は２つあります。１つはBPMを理解できていない人がいる中で実施すると「作業の自動化」に気をとられ普通のシステム開発に変質してしまう（コラム：BPM導入が「いつの間にか普通のシステム開発」になる原因参照）ことです。もう一つは対象プロセスが完全に属人化されており定型化されていないという理由です。今回は、この２つめの理由に関して述べたいと思います。
　BPM入門セミナーを受講された方が「定型業務にしかBPMは適用できないのでは」というアンケートの回答をいただくことがあります。一方、非定型の業務をPDCAサイクルを回して「徐々に定型業務にしていく」ということを想像できる受講者もいます。多くは前者です。間違いではなく前者が容易に業務標準化、効率化ができるでしょう。しかし定型業務にしか適用できないというのは間違いです。それはPDCAサイクルを回して改善していくという視点が欠如しているからです。
　後者に関して具体例を挙げて説明をしていきたいと思います。

目次
１．非定型業務を徐々に定型化していくとは
２．改善する時間がないという常套句
３．まとめ

１．非定型業務を徐々に定型化していくとは

　下図は非定型業務です。何を作るのか、どのように作るのかは決まっていないフローの流れです。ここでは抽象的な業務と指示の流れだけが書いてあるだけです。リマインドメールに書かれている顧客仕様を読み取って課長が判断をして指示をしています。指示を受けてデザインをしてデザインが終われば制作してお客様に納品しているというだけです。指示はBPMSによって担当者に業務が自動で引き継がれます。

最初のタスク「業務内容を確認、指示する」画面はシンプルで顧客依頼事項が載っていて、それに対して課長が具体的なデザイン指示を出し、納期を決めているだけです。

　ありとあらゆる制作物は、この１つのプロセスで管理をしていたとしましょう（スモールスタート）。A制作物群に関しては納品後の原価データを見ると常に赤字だということがわかりました。それは課長もデザイン担当も制作担当も原価が売上に見合わないのではないかと気が付いていましたがフローの流れは一方通行ですので指示に従っていました。しかし赤字制作物を作ることを防止する改善すべきだということになりました。
　そこでA制作物群のプロセスは、下図のような変更しました。課長が最初に疑問を持った時、営業に「積算確認」を依頼する、営業は積算を確認し必要であれば顧客と調整をすることが書かれています。確認や顧客との調整後、課長に再度、指示をし直しをしてもらうフローを追加しました。デザイン担当者が「指示通りにデザインしていいのか」と疑問を持った場合も営業に積算確認の連絡をし同様のフローで管理することにしました。デザイン担当が原価に疑問を持たずに、そのまま制作担当に業務が流れた後、制作担当が疑問を持ったときは、課長に対して差し戻す流れを作りました。課長は、その報告を受けて営業に積算確認を依頼するか、報告内容を確認して問題がないと判断した場合は制作に戻るフローとしました。

というように、最初は非定形な業務のフローでしたが、A制作物群に関しては、もっと詳細な管理が必要ということで、やや定型化していきます。
このフローでの管理を一定期間運用後、戻りがあるプロセスデータを調査し、まとめるとA制作物群は営業担当が顧客との商談時や積算時に気をつけるべきポイントが見えてくるようになります。営業担当がA商品群の商談、積算時に制作プロセスで戻りが発生しない注意点が明確になった定型化されたプロセスを別に作って管理する改善を行うことを考えるでしょう。
　PDCAサイクルが回ることで、非定型の業務も定型化されプロセスの種類が徐々に増えて行く、というイメージがつかめたでしょうか。
「非定型業務はBPMで管理できない」「非定型業務は定型化できない」という決めつけをしないことです。

２．「改善する時間がない」という常套句

　まず、いろいろな考え方の人がいるので、それぞれの生き方を否定するつもりはありません。業務改善には通常業務の上に、業務負荷が一時的に増えます。「ただでも忙しいのに、業務改善なんかやっている時間がない」というのは、私が新入社員だった４０年前から耳にタコができる常套句です。これは逆で「業務改善をしていないから通常業務が忙しい」とも言えます。
　一時的に業務負荷が増えても業務改善を達成するというのは、経営陣も実務者も理解していなければ変革などあり得ないです。１９８０年代はこれを、今で言う「サービス残業」で行っていたと言えます。代表的な例はQCサークルであり、QCサークルは名目上「自主活動」とされていたので「残業や休日出勤手当を支払わない」という位置づけでした。（これは2007年に名古屋地裁で、トヨタ自動車のQCサークル活動が業務とみなされ、残業代の支払い義務が生じるという判決によって方向は変わりました。私は当たり前の判決だと思いました。）

　過去、QCサークル以外でも、間接部門は改善目標の達成のために残業、休日出勤手当が支払われなくても働いていたという事実があります。今ではすぐに「ブラック企業」だというような話になりますが「仕事の経済学」（小池和男,1991）では、社内における「長期の競争」という説明がされていました。「仕事の経済学」は日本企業の特徴を実証検証した評価の高い書籍です。これに対して数多く数理経済学での論理的な検証がされており、終身雇用から成り立つ日本型経営システムが「戦後という特殊な環境でのみ成り立つシステム」ではなく「一定の経済合理性」があるとされました。すなわち、過去を単純に否定すべきではありません。

　長時間残業が良いことだとは思いません。しかしながら先に述べたように「何かを変える」には、どうしても一時期には業務負荷が増えます。
それをまったくゼロで何かを変えるということも不可能です。「自分は苦労しないで、誰かにやってもらう」と全員が考えていると、結局、誰も何もしないまま３０年が過ぎてしまったと思います（そんなことはない企業、組織も、当然あると思います）。

　かつての日本型経営システムにおいて経営者や管理者は（コラム：BPMと日本型経営システム参照）

・直接的な管理をほとんど行わない。
・組織間、セクター間の調整業務が中心である。
・意識の中心は部下が働きやすい環境づくりである。
・各現場の労働者の自主性を重んじて全体の効率化を高める。　

でした。この考え方に立ち戻ると
　
　社内の業務改善をコンサル会社やシステム会社に多額の費用をかけて「丸投げ」するものの、得られたものが「実現できない提案」と旧来からの「作業の自動化」でしかないのであれば、その費用を社内の人材に使うべきでしょう。
　それを今は「リスキリング」と言っているのかもしれませんが、実務者に、ただPowerAppsやPowerAutoｍateなどのローコード、ノーコード開発ツールの研修を受けさせても、改善を実践するための時間がなければ意味がありません。同様にBPMにおいてもBPMNの記述方法やBPMSの実装方法の研修を受けるだけでは意味がないです。

　実践するための時間を作るために、経営者は実務者の通常業務の負荷を一時的に少なくし「自主性を重んじて全体の効率化」を進めるために「働きやすい環境づくり」をする必要があるでしょう。
下図は、そんなイメージを表しています。

　これを全社的に一気に進めようとすると、これも大変な労力（説得や準備）が必要な話になります。すなわち少しづつ実施して徐々に展開すること、スモールスタートです。

３．まとめ

　BPM入門セミナーでもお話しをしていますが「BPMは長期の活動」であり短期間で何かを一気に解決する手法ではありません。ITシステムの導入プロジェクトのように１年、２年などという期間で終わらせるものではないです。もしBPMの導入がITシステムのプロジェクトのような形になっていたら、BPMNを使っても、BPMSを使っても、それはBPMでは無くなっている可能性が高いです。（コラム：BPM導入が「いつの間にか普通のシステム開発」になる原因参照）実装されているプロセスのレーンは恐らく１つでしょう。
　日本において、この長期の視点での活動が失われました。形骸化しているISO9000シリーズのようなものは継続認証を続けているだけで、名目上はマネジメントシステムであるはずが、マネジメントとしては何の役にも立たず入札資格を得る、取引基準を満たすためのコストでしかないでしょう。そうでないのであればISO認証を維持している製造業の品質不正問題が、なぜ次々と発生しているのか、ということになります。
　経営陣が変わるたびに方針が変わる。というのは昔からありました。経営陣が変わっても変わらないものもありました。しかし今は、変えてはならない受け継がれて来た良き伝統や手法を捨ててしまったことで会社の風土、モラルが低下し、逆に捨てるべき慣行（今まで通り）に縛られているような気がします。
　人材が流動化しているのは事実ですが、終身雇用制度が無くなっている訳ではありません。無くなっていない今は「いかに生かすのか」ということを考えるべきだと思います。BPMはその一翼を担いたいと思います。

関連ページ