BPMS導入で終わらせないビジネスプロセス管理（BPM）

業務の自動化効果の最大化を狙い、自社の業務に対して広く、既存の業務フローを基にした可能な限りのシステム化を行った場合、個別に見ると品質（業務改善効果）が限られる一方で、稼働までの期間は長くなり、導入コストも大きくなりやすい。また、品質に起因して発生しやすいその後の改善において、業務横断的な対応が必要となることから変更コストも大きくなる。

自社のリソース参画が限定的であり、ベンダーに依存してBPMSが導入された場合、本来肝となる導入後のBPMもベンダー依存となる。その結果、本来の目的である現場主導での業務改善が機能せず、組織や個人としての業務改善能力が高まらない。また、システム導入効果を、本来は効果の一部である表面的な業務効率化の観点で定量的に測定・評価することとなり、費用対効果が十分出ないことが多い。

パッケージ製品の標準的な機能によるシステム化が難しい業務に対し、カスタマイズを積極的に活用した場合、BPMにおいて業務改善に着手する際に、再度カスタマイズの対応が必要となる。カスタマイズを重ねることはコストの観点で業務改善の障壁となると共に、ベンダー依存につながり得る。

BPMは、BPMS導入後、利用状況をモニタリングし更なる業務改善を継続的に行う、アジャイル的なアプローチを基本としている。そのため、ウォーターフォール的に、ある業務に対して要件を出し切ってからの実装や、複数業務の同時リリースを行うことは、時間を要し手戻りのリスクも大きくなることから注意が必要である。

一方、システム側に内製化チームがいてもアジャイル開発の前例がなく対応できない、業務側も要件承認のリードタームが長くプロダクトバックログ上の優先判断のスピードに対応できない、BPMS導入後に頻度の高い業務変更は現場負荷から望ましくないなど、アジャイル的な進め方ができないケースは多い。そのような環境下では、まずは複雑ではない代表的な1つの業務を選定し、ウォーターフォールで要件を詰めてから開発を行い、1つの業務でBPMをまず始めることが望ましい。その後、1つの業務整理を通じて合意した方針を、BPMS化のコンセプトとして明確にし、負荷が高く業務改善効果の高い業務を次のターゲットとしてBPMS化することが、手戻りの抑制や効果の刈り取りのバランスから、有効なアプローチになり得るだろう。

経験・知見のない状況から、自社主導でBPM実現・BPMS導入に取り組むことは難しい。まず、専門性のある外部のアドバイザーを活用し、BPMに取り組む目的や現在の課題、それらから導かれるありたい姿を整理するべきだろう。その結果、具体化されたBPMSの要件を満たすBPMSパッケージ製品の選定に入ることが望ましい。その際、従来のシステム導入であれば、対象業務と製品機能とのフィット＆ギャップに重きがおかれるが、BPMの実現を視野に入れれば、いかに現場主導で継続的に業務改善に取り組めそうな製品かという観点を重視すべきである。この選定においては、自らの取り組みとして主体的に製品評価できる責任者および経営目線での取り組み判断ができるオーナーの関与が必要である。

その後、製品ベンダーと共に導入を進めることが基本となるが、リソースやスキルの事情から、要件定義を含めた主な稼働がベンダーとなることはやむを得ない場合もある。ただし、この場合であっても、最低限の現場担当者は参画し、利用者目線を外さない地に足の着いた推進としたい。また、業務毎に縦割の文化があるようであれば、壁を超えた調整ができる権限を持った責任者が必要である。加えて、システム化スコープについては、現場の要望を参考とした、オーナーの明確な判断が重要である。これらキーマンについて、明確化・体制参画を最低限行った上でプロジェクトを推進したい。

BPMS導入後のモニタリング結果を踏まえて、業務改善を行うことがBPMの前提である。パッケージ製品において、それが標準機能内の変更であれば、ローコード/ノーコード開発として内製でも対応ができ、あるいはベンダーに変更依頼をしてもコストと所要期間は限定的であるが、カスタマイズであった場合はその限りではない。したがって、BPMを経ても同じ要件で変わらないと確信のある内容や、システム化対応しなければ著しく生産性が下がるなど、影響が明らかに大きい内容を除いて、BPMS導入初期は、業務の見直しと運用の工夫により標準機能内でのBPMS化を目指したい。BPMを進める中で、カスタマイズをしてでも対応すべきポイントを見極め、その後の管理方法も含めて慎重に判断していくことが有効である。