見出し画像

IMUG 2022 第2回「業務プロセス改革分科会」Day2レポート

世界標準の業務記述法「BPMN」をハンズオンで学ぶ

NTTデータ イントラマートのユーザー会「IMUG」は12月7日、今年度の第2回「業務プロセス改革分科会」Day2を開催しました。11月25日のDay1では、公益社団法人企業情報化協会の横川省三氏(元日本BPM協会)を講師に招いてデジタル業務改革とBPM(Business Process Management)の基本を学びましたが、今回はその続編となるプログラムです。同じく横川氏の指導の下、世界標準の業務記述法である「BPMN」の特徴や基本的な表記の仕方を学ぶとともに、BPMNに対応した業務プロセスモデリングツールである当社の「IM-BPM プロセスデザイナ」を使い、ハンズオン形式で各参加者が実際に業務プロセスの記述にチャレンジしました。

BPMやBPMNにまだなじみが薄いという参加者も数多くいましたが、ハンズオンでは皆さんの積極的な姿勢が目立った印象です。Day1で横川氏は「業務プロセスのPDCAサイクルとも言えるBPMはDXの環境を整えるために有効な施策であり、BPMに取り組む上ではまず、多くの人に共有しやすいBPMNで業務フローを表現できるようになることが重要」と説きました。BPMやBPMNの重要性に納得した方が多かったこともあってか、今回は前回にも増して多くの質問が飛び交い、BPMNで業務フローを描くスキルを身につけるきっかけとして、この場を活用しようという貪欲さが伝わってきました。オンライン形式の分科会ではありながらも、インタラクティブで熱気のあるイベントになった第2回「業務プロセス改革分科会」Day2の模様をお届けします。

Day1のレポートはこちらからご覧いただけます。

IMUG FY2022 第2回「業務プロセス改革分科会」Day1レポート

企業や官公庁に浸透しつつあるBPMN

BPMNはBusiness Process Model and Notationの略で、横川氏によれば2000年代前半に欧州の金融業界から生まれた業務記述法です。現在は「ISO 19510」として国際標準化され、国際標準化団体のOMG(Object Management group)によって維持されています。

主な用途は二つで、一つは業務改善やシステム化のための業務要件定義の記述、そしてもう一つがBPMNで描いた業務フローを業務規程や業務マニュアルとして活用するというものです。

BPMに取り組むためにBPMNで業務を可視化する際には、前述した「IM-BPM プロセスデザイナ」のようなツールを使うのが一般的で、「近年、表記法の国際的な普及ツールの充実により国内の企業や官公庁にもBPMNは浸透しつつあります」と横川氏は説明。政府が進める地方自治体の業務プロセス・情報システムの標準化においても、業務プロセスはBPMNで記述するのが基本的な考え方になっているといいます。

BPMNの表記レベルには三つのレベルがある

ハンズオンに先立ち、横川氏はまず、BPMNの特徴をレクチャー。初めて触れた人でも、ある程度直感的に業務の流れが理解できるようになっているとして、BPMNに施されたさまざまな工夫を解説しました。

「作業の流れ、(顧客など)外部との連携の様子、(デジタルデータや紙の書類を含む)データの流れという3種類の線で業務フローを描き分けるルールとなっており、パッと見て流れが理解できるフロー図がつくりやすい。オペレーションを制御するさまざまな機能も図形で表現され、多様な業務を共通のルールの下で描くことができます。また、全体を俯瞰するレイヤーから業務の詳細を表す下位レイヤーまで、目的・視座に応じた段階的・階層的な整理・分析ができるようになっているのも特徴です」(横川氏)

ただし、具体的なBPMNの描き方については「段階が必要」だと指摘します。横川氏はDay1で、BPMNを使ってしっかり業務フローを描き上げれば、BPMS(Business Process Management System)というシステムに実装し、業務プロセスをデジタル化して管理できるようになり、それがDXを進める上での基盤にもなると指摘しましたが、「いきなりBPMSに実装できるようなフローを描こうとするのは現実的ではありません」と注意を促します。

BPMNを使った業務プロセス図の表記レベルには三つのレベルがあり、それを順番にこなすのがBPMで成果を出すために有効だというのが横川氏の見方です。最初のレベルは「記述モデル」で、記述対象の業務プロセスにおける作業の順序、条件判断、プロセス内外の役割分担と相互作用などをモデリングします。また、記述レベルは二つのフェーズに分かれます。業務設計者が現状を可視化して課題を抽出する「As-Is記述モデル」を経て、課題の解決策の検討や目指す姿の明確化、関係者の合意形成を盛り込んだ業務改革の基礎となる図面を「To-Be記述モデル」として作成します。

「顧客からのサポート依頼への対応」プロセスを例に

横川氏は、ソフトウェアメーカーが顧客からサポート依頼を受けてから対応を完了するまでのプロセスを例に、各表記レベルでどういったことに取り組むのかを説明しました。例示された具体的なプロセスは、以下のような一連の流れをBPMNで表現したものです。

例示されたBPMN業務フロー:出典 企業情報化協会「BPMNモデリングガイド

・顧客からサポート窓口にEメールでサポート依頼が送られる
〈内容が不具合の指摘・相談や機能面の質問であった場合〉
・技術チームに技術調査を依頼する
・技術チームは調査の結果をサポート窓口にフィードバックする
・窓口が顧客にその内容を回答して対応が完了する
〈内容が評価版ライセンスの利用申請であった場合〉
・窓口が営業チームにその情報を伝える
・営業チームは当該顧客が評価版ライセンスを利用可能かを顧客データベー
    スに照らして調査する
・利用可能であれば評価版ライセンスを提供する
・NGであればその旨を通知して対応を完了する

これをAs-Is記述モデルとすると、例えば技術チームによる技術調査の結果をデータベースに蓄積し、それをサポート窓口で検索できるようにすれば、窓口で顧客対応を完結できる範囲が広がります。To-Be記述モデルにはそうしたアイデアを盛り込みますが、一方でTo-Be記述モデルを実行するには窓口の権限を拡大するなどのルール変更が伴いますし、BPMSによるシステム化を想定すると、より詳細な記述が必要になります。そこで次は社内の情報システム部門などを巻き込み、2番目の表記レベルである「分析モデル」の作成に取り組みます。

分析モデルを描く際には、To-Be記述モデルで発生した新たなアクティビティ(業務や作業)などについて「人が処理するのか、システムで処理するのか、人が処理するのであれば誰が担当するのか」「新たなアクティビティは他のプロセスで再利用可能なかたちで部品化できるか」などを検討します。横川氏は、業務部門とエンジニアが一緒に検討すると分析のレベルが上がる可能性があると強調します。

「ソフトウェアメーカーの顧客サポートの例でいえば、顧客との最初の接点を、窓口ではなくWebサイトにしてしまうというソリューションも現実的になります。顧客がログインしてFAQを見られたり、評価版ライセンス利用の申し込みができたりするようになれば、窓口の業務負荷を大幅に下げられるかもしれません。分析モデルの記述で大事なことは、業務プロセスの設計者とシステムへの実装技術者の合意をしっかり取っていくことです」

なお、改革・改善の対象となるあらゆる業務プロセスをシステム化すればいいわけではなく、To-Be記述モデルをそのまま業務マニュアル化すればいいものもあるとのことです。

業務フローを描く前に必要な準備も

システム化すべき業務プロセスについては、分析モデルを基に3番目のレベルである「実行モデル」を作成してBPMSに実装する流れになります。BPMN業務フローをBPMSで動かすことにより、担当者が作業をすべきタイミングで自動的に必要なUIがシステム上で立ち上がったり、しかるべきタイミングでタスクがリストに追加されたり、場合によってはRPAに必要な指示を出したり……。現状の業務プロセスをアプリ化して定義されたプロセスを実行するのはもちろんですが、実行状況を監視して改善ポイントを発見し、最適な業務プロセスへの改善を継続的に行う基盤となり得るのがBPMSの真の価値と言えるかもしれません。

横川氏も「プロセスのKPIをリアルタイムで可視化でき、閾値を超えたら、それを自動検知して業務管理者に通知するような仕組みも構築が可能。問題発生時の迅速な対応にもつなげられます。実績データに基づくパフォーマンス分析と改善策の検討ができるのはデジタルな基盤ならでは」と説明しました。

また、BPMNによる業務プロセスの可視化の前段におけるポイントも解説しています。横川氏は「顧客との接点で案件がスタートしてから、納品などで一旦それが終わる、といった案件の発生~完了までを誰がどのようにかか割るか、というあたりのプロセスがBPMNが最も役立つ」と説明。その上で、より上位である事業の定義などに関わる階層については、顧客やパートナーと自社の関係、社内の組織化の連携プロセスを整理し、改革のスコープやTo-Beを検討するための「業務フォーメーションマップ」をつくるべきで、さらにこれをベースにAs-Is業務の棚卸表を作成するまでが必要な準備だと指摘しました。

「業務棚卸表を事前につくっておくと、BPMNもスムーズに描けます。実際に業務を棚卸しすると、名前が付いていない業務が意外に多いことに気づきますし、そこに名前を付けることで業務を改めて定義して、必要な標準化なども進みます」

“質問部屋”も積極活用、熱を帯びた演習

1時間ほどの座学を経て、IM-BPM プロセスデザイナを使い実際にBPMNで業務フローを記述する演習に移ると、参加者の皆さんの熱気は一段と上がりました。今回、Webミーティングツール内に二つの“質問部屋”を用意し、「業務としての描き方が分からない」「プロセスデザイナの操作が分からない」という参加者の方々を支援する環境を用意しました。多くの参加者が初めての取り組みに悪戦苦闘しながらも、その質問部屋を活用したり、横川氏にダイレクトに質問したりして、BPMNによる業務記述法の習得に積極的に取り組んでいたのが印象的でした。

Day1、Day2の2日間にわたりプログラムに参加者の方々からは、今回の内容について、業務に役立つ手応えを感じてもらえたようです。いくつかコメントを紹介します。

「特に定型的な業務に対しては、BPMNで可視化して継続的な改善につなげるのが有効だと実感できました」

「BPMNで業務フローを描く前に、業務プロセスを階層で捉えて業務フォーメーションマップや業務棚卸表をつくることが重要という話には納得感がありました」

「システム開発の要件定義などで業務フローを描くことが多いのですが、粒度を顧客と共有しづらいという課題がありました。業務フォーメーションマップの作成からBPMNによる業務フローの記述までの一連の流れが、そうした課題の解決に役立ちそうだと感じました」

また、「IM-BPM プロセスデザイナを使いこなすにはどうしたらいいか」といった質問も演習中にいただきましたが、eラーニングを含めて複数の研修メニューを用意しておりますので、興味のある方はNTTデータ イントラマートまでお気軽にお問い合わせください。

業務プロセス改革分科会の年内のイベントはこれで終了ですが、来年以降も継続して、IMUGの参加企業のビジネスの成長に本質的に貢献できるプログラムを提供していきますので、ぜひご注目ください!

(IMUG事務局編集部)
 
--(お問い合わせ)
・イントラマートユーザ会(IMUG)個別説明会のお申し込みはコチラ
https://icotto.intra-mart.jp/imart/event/regist/8gcz9h9yfwcdzdx

・IMUGとは?
https://www.intra-mart.jp/service/imug.html

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!