ビジネス プロセス モデリングの初心者向けガイド

ByKate Eby| 2016年11月11日(更新 2023年8月4日)

ビジネスの現在の状態とあるべき状態を視覚化するにはどうすればよいでしょうか?このような予測は難しいため、役立つツールがあるのは幸いです。ビジネス プロセス モデリングは、品質管理手段であり、現代のビジネス プロセス管理 (BPM) の一部です。この手段は、組織の現在のプロセスを、分析や改善のための公式な方法で描写します。この記事では、ビジネスとソフトウェア エンジニアリングという 2 つの異なる視点に焦点を当てます。どちらの分野でも、プロセスは最も重要です。ビジネス プロセス モデリングの基本的な仕組みに加えて、さまざまな手法、言語、その将来について見ていきます。その過程で、当社のモデリング専門家の意見も紹介します。

ビジネス プロセス モデリングを使用する理由

組織はプロセスを視覚的に文書化し、理解し、改善するためにビジネス プロセス モデリング (BP モデリング) を使用します。ビジネス プロセス管理 (BPM)の一部である BP モデリングは、何がベースラインか (つまり「現状の」ベースラインを) を詳細に示し、改善を取り入れて今後の状態 (つまり「将来の状態」) を決定するための組織的な手段として使用されてきています。製品やサービスのプロセスのアクティビティ、イベント、リソースが接続し合う状態をすべて視覚的に表すことで、効率性を向上します。BP モデリングは、多くの場合、プロセス マッピング、プロセス検出、プロセスシ ミュレーション、プロセス分析、プロセス改善の分野を組み合わせたものです。ビジネス プロセス リエンジニアリング (BPR)イベントでは、すでに使用されているプロセスを明らかにし、新しいプロセスを表現するために BP モデリングが使用されます。BP モデリングを使用するその他の理由は次のとおりです。

  • プロセスの視覚的モデルの作成 -Word ベースのドキュメントは、従業員がプロセスの実行方法を理解するには十分でないことがよくあります。視覚的な表現を使用して補強することで、包括的に描写できます。
  • 運用の調整 -どのような新しいビジネス戦略でも、変更を加えた後にプロセスの一貫性を維持するには、組織の総合的な戦略から外れないようにする方法を見極める必要があります。ボトルネックや非効率的な部分を特定し、プロセスの俊敏性を高めるために、分析も行われます。
  • プロセスのコミュニケーションの改善 -コミュニケーションは、あらゆるタスクの鍵となります。そのようなタスクとして、(以前は非公式の知識だった) 既存のプロセスの公式化、一貫したプロセスの作成、ビジネス ルールによる推測の排除、例外の処理、規制遵守の実現、ビジネス担当者の確保、新しいイニシアチブ (リーン シックス シグマなど) のサポートなどが挙げられます。
  • 業務効率の改善 -モデリング プロセスは、シミュレーションを可能にし、必要な改善を図式化することで、最適化を促進します。これにより、サイクル タイムが短縮され、リソースの使用状況が向上します。
  • 競争上の優位性の獲得 -プロセスが総合的に優れているのは、絶えず改良され、ビジネスの戦略と合致されている場合です。この効率性のおかげで、会社は競合他社よりも優位な立場に立つことができます。

ソフトウェア開発におけるビジネス プロセス モデリング

ソフトウェア開発はリスクの高い分野です。20 年前に Standish Group が発表した『CHAOS Report 1995』では、ソフトウェア プロジェクトの 90% は失敗に終わると記されています。現在その割合は低くなっているものの、依然としてやるべき仕事があることを表しています。同グループの2015 年のレポートでは、ソフトウェア開発プロジェクトの成功率はまだ 29% に過ぎませんでした。長年にわたるこのような数字を改善するために同グループが提案した推奨事項は、新しい傾向とともに浮沈してきましたが、そもそも要件を最終的に定義するのはエンドユーザーであるため、すべての関係者、特にエンドユーザーとコミュニケーションを図るという 1 つの重要な推奨事項は現在も維持されています。専門家は、ソフトウェアの要件を検証するために、プロジェクトの早い段階で、理解しやすい表記法を使用した明確なモデルを開発することを推奨しています。BP モデリングを使用すると、ソフトウェア エンジニアは関係者と交渉して、双方にとって何が最適かに基づき、構築が必要なシステムを決定できます。

ほとんどの BP モデルは、既存のエンタープライズ アーキテクチャの一部として開発されています。これは、エンド ユーザーを代表することが開発中の目的であることを示しています。ただし、これらのモデルは、機能、行動、組織、情報など、さまざまな観点から開発されています。専門家は、プロセス設計でこれらの視点を組み合わせるのが最善の手法であることに同意しています。

  • 機能の観点から、どのプロセス要素が実行され、どの情報に関連性があるかが示されます。
  • 行動の (つまり動的な) 観点から、やり取りの順序とプロセス要素の実行方法が示されます。
  • 組織の観点から、プロセスの要素を誰がどこで実行するかが示されます。
  • 情報の観点から、生成または分析される情報の起源が示されます。

ソフトウェア ビジネス プロセス モデリングにおけるビジネス プロセス モデリング言語

既存のビジネス処理モデルの言語はすべて、科学的な伝統のさまざまな側面に由来しており、何らかの視点に合わせて構築されています。各言語には多くの共通点が存在しますが、ビジネス プロセス モデリング言語には 4 つの大きなカテゴリがあります。

  • 従来型プロセスモデリング言語:情報エンジニアリングの管理情報システム (MIS) の伝統から、これらの言語は熟知されることを意図しており、通常は公式ではありません。これらの言語には、IDEF、ペトリネット、EPC、役割アクティビティ図、REA、BPML が含まれます。
  • ワークフロー モデリング言語:これらのスクリプト言語は、ワークフロー管理システム (WfMS)のワークフローを説明するための言語です。これらの非常に公式な言語には、ワークフロー プロセス記述言語 (WPDL)、提案されたインターチェンジ フォーマット (PIF、PSL) が含まれます。
  • プロセス統合言語:これらの言語は企業間の統合を目的としており、プロセスのさまざまなレベルのセマンティクスを取得します。これらの言語には、RosettaNet、ebXML、BPEL4WS が含まれます。
  • オブジェクト指向言語:IT とドメインの双方の専門家によって熟知されることを意図したこれらの言語は、ソフトウェア ドメインを表します。ほとんどのオブジェクト指向モデリングでは、機能、行動、情報の視点が考慮されます。

ハフェッド・ミリ (Hafedh Mili) 氏らは、チームがモデリングにコア言語を使用し、他の言語からプロセスに合うさまざまな部分を使用することを推奨しています。この分野では、専門家は、タスクが言語さえも主導すべきであるということに同意しているようです。

ビジネス プロセス モデリング プロジェクトのアプローチ方法

BP モデリングのアプローチを選択することは、それを実行するのと同じくらい重要です。実際のタスクそのものに基づくアプローチは、万能ではありません。プロジェクトを実施する前に、いくつかの分類を行う必要があります。Biderによると、専門家は実際のビジネス プロセス、モデリング環境の特徴、モデルの用途という 3 つの要素を考慮する必要があります。これらの 3 つの要素は、ビジネス上の特定の考慮事項に分割される場合があります。

  • ビジネス プロセス -企業は、積極的な参加者と受動的な参加者、各自の業務目標の達成度、プロセスと環境がどれだけ密接に相互作用しているか、そしてプロセス フローの性質と整然さを考慮する必要があります。
  • モデリング環境の特徴 -モデリング環境では、企業は既存のプロセスの成熟度と、非常に公式な表記法を理解している人材がいるかどうかを考慮する必要があります。
  • モデルの用途 -企業は、モデルを設計する目的と、何を基盤にしてモデルを作成しているかを考慮する必要があります。たとえば、企業は現在のプロセスの改善を試みたり、分析やリエンジニアリングを行ったり、新しいコンピューター システムを構築したりする可能性があります。

BP モデリングには普遍的なアプローチがないため、専門家は固有のビジネス要素をすべて検討することを推奨しています。専門家の中には、ツールを選択する前にすべての情報を収集する公式なアプローチを推奨する人もいれば、過去に自分に役立っていた特定のツールを推奨する人もいます。当社の専門家 2 人の推奨事項は以下のとおりです。

Local Fame Ltdのマネージング ディレクターであるダニ・ペレバ (Dani Peleva) 氏は以下のように述べています。

“When approaching a business process modeling task, I’d always break it through the prism of project management as it helps me get an idea of the objective of the system that needs engineering, the time the process needs to be completed for, as well as the resources available. Once you know what the requirements are, i.e. the purpose of the process is, what the deliverables are, the budget/resource constraints and so forth, it is a lot easier to approach the design/engineering stage.
When it comes to process engineering at Local Fame, we always have efficiency and effectiveness in mind - the most cost-effective, timely and optimized manner that a process can flow. For this purpose, I always approach the task from a few different angles - from the start of the process, as well as from the end of the process backwards. When you do not limit yourself with the direction of the process flow you can identify gaps and possible flaws in the strategy and implementation, as well as possible bottlenecks. Once I come up with a few different models I test those applying different scenarios in order to understand how sustainable those are in turbulent environment. This is when usually you sift through the best models and shortlist one or two successful ones.
Additionally, an intrinsic part of business process modelling for me is risk management, more specifically, identifying the potential flaws of the model and where and under what circumstances the model can fail. Identifying those weaknesses of the process helps you create contingency plans and backups, and as you often may find yourself, you get to optimize the process even further and scrap some of the chunks you initially considered essential, but later on realized you could go without. When thinking about risk management, however, one should know a risk could be both a positive and a negative, risk can create opportunities for the process to fail or get delayed, but also speed up and become more efficient, which again leads to the process optimisation and potential changes in the model. Tools I often use when doing business process modelling are Gliffy, Activiti Modeller, and Gantt charts.
To conclude, when modelling a process or re-engineering an existing one, I usually approach the task from a project management perspective analysing the requirements fully before moving to the design stage. After design stage, I test the model numerous times in different scenarios and if needed I return to different stages to optimise and tweak it further. Lastly, I always think about risk management and contingency to make sure that the process is resilient and sustainable.”

Ray McKenzie, Founder and Principal,Red Beach Advisors, recommends, “As a management and business consultant for small- to medium-sized companies, a primary duty of mine is to develop efficient and optimized process for every organization to be productive. I always start with examining the problem and finding out the history of the problem, the different parts of the problem, and the effect the problem has on the business. Understanding the problem and components are core pieces to developing an effective process model to improve. Start with the problem. Examine the parties involved. Understand the current performance and measurements. Define the performance improvement goals. Outline an efficient process which drives results and displays success.”

ワークフローとビジネス サービス指向アプローチ (BSOA)

一部の専門家は、ソフトウェア開発のための BP モデリングは、Web サービスが導入される前後でその可能性が変化していると考えます。Web の開発前は、プロセス開発の主なアプローチはワークフローでした。ワークフローのアプローチでは、ビジネス プロセスが事前に決定されます。最も適した言語は、ビジネス プロセス実行言語 (BPEL) とフロー定義言語 (FDL) です。ワークフローのアプローチは、現代の環境ではあまり柔軟性がないと批判されていました。

Web サービスの開発後、ソフトウェア開発のための BP モデリングのアプローチは注目度が増し、ビジネスサービス指向アプローチ (BSOA) として認識されるようになりました。プロセス モデリングは、ビジネス サービスの柔軟な構成要素を基盤とします。このアプローチは、ビルディング ブロックを使用することで、アーキテクチャの構築において、設計者が掲げる目標と要件に対処するようにカスタマイズできます。サービスは、データ開発やシンプルなサービス手順など、小さなタスクを実行します。全体的に見て、BSOA は、固定でき、定期的にアップグレードできる極めて再利用可能なシステムを作り出します。このアプローチはアジャイルであると評価されており、さまざまな形態の組織に適用できます。

ビジネス プロセスをモデル化するさまざまな方法

すべての標準言語と標準化された言語では、プロセス設計の創造性が浸出していると考える専門家もいます。代替のアプローチでは、その創造性の一部を取り戻すことができます。単体で使用できる手法や、より公式なアプローチを補完することさえ可能な手法の中で、最も普及しているものの一部を以下に示します。

  1. フローチャート手法
  2. データフロー図 -ヨードンの手法
  3. 役割アクティビティ図 (RAD)
  4. 役割相互作用図 (RID)
  5. ガント チャート
  6. 機能モデリングの統合化定義 (IDEF)
  7. カラーペトリネット (CPN)
  8. オブジェクト指向メソッド (OO)
  9. ワークフロー手法
  10. シミュレーション
  11. ビジネス プロセス モデリング表記法 (BPMN)
  12. UML アクティビティ図
  13. 変革プロセス モデル
  14. ストーリー テリング
  15. 階層型プロセス モデル
  16. 視覚化

According to Bernard Lee, President ofCharlotte Search Engine Consultants, there are other ways to model your projects visually. He points out that, “As a lifelong entrepreneur who started my first business at 20, I am now 53 and am considered a ‘college dropout.’ It has always been about systems, automation, and measuring risks to achieve our stated goals. This has been true in my career as a wealth manager, a Healthcare IT executive, and now as the founder of a digital marketing agency that specializes in SEO. Yes, SEO is about metrics, analytics, and CTR (click-through rate). Nevertheless, I've found the creative aspects is what separates the pretenders from the achievers. We are Google partners so we believe in the usual success measurements, but get there differently. YouTube, Geo-Tagging, and unorthodox combinations of our client's digital properties consistently land multiple properties on page one for the most important keywords. The visual of multiple positions on page one always has an immediate impact on our client’s brand, traffic, and conversions while moving competitors to page two.”

プロセス マッピングとプロセス モデリングの違い

プロセスマッピングは,各部分を相互に接続して表現した,単一のエンティティである組織の概要レベルのレビューです。組織全体のビジネス プロセスの流れを再考察して、誰が何をし、どのようにプロセスが実行され、どのような基準でプロセスが評価されるかを明確にします。プロセス モデリングでは、専門家はビジネスと経済のベスト プラクティスを使用して、プロセスの効率性により重点を置きます。どちらもプロセスをグラフィカルに描写しますが、プロセス モデリングはサービスと結果を生み出す関係をより深く掘り下げます。


ソフトウェア プロセスのモデリングと評価のフレームワーク (FMESP)


標準化されたビジネス プロセスの開発が生み出した複雑な問題の 1 つは、その有効性を判断しなければならないという考えです。言い換えれば、ビジネス プロセスがどの程度成功しているかということです。FMESP は、ビジネス プロセスの概念モデル(何をして、何をしないか)を評価するための一連のメトリックとして提供されます。FMESP は、ソフトウェア プロセス モデルの構造的な複雑さを評価し、続いてアクティビティ、役割、作業成果物を評価します。このフレームワークは、モデルのメンテナンス性に関する客観的な情報を企業に提供することを目的としています。

優れたビジネス プロセス モデルの開発

専門家はどのように BP モデルを始めるのでしょうか。一般的なアプローチの 1 つは、問題の選択、手法の選択、問題の解決を推奨しています。シンプルにすることで、関連するすべてのものがモデルに含まれ、モデルに含まれるすべてのものに関連性があることが保証されます。
その他の専門的なヒントは次のとおりです。

  • 誰が人員に含まれるかを確実に把握する。タスク、人員、モデルの完成に必要な時間のリストを作成する。
  • プロセス モデルに役割が表示される順序で面接を実施する。
  • 文書化を徹底する。
  • すべての記号を再確認し、鍵があることを確認し、各ステップに従って、そのパスで後退するか、前進するかを確認する。
  • 望ましい結果を事前に把握する。
  • 開始点と終了点を把握する。
  • プロセスの一部であるドキュメントやフォームを事前に入手する。
  • 必要なときはいつでもテンプレートを使用する。

より良い世界のための理論である社会理論の振興財団 (FAST)の ASK MATT で共同創設者/アナリスト/コンサルタントを務めるスティーブ・ウォリス (Steve Wallis) 氏は次のように述べています。

“BPM is incredibly useful for showing ‘what goes on’’ within a business organization. However, it can also create a false sense of comfort. When the map says, ‘You are here’ we feel a sense of security. However, unless the map shows how to get from ‘here’ to ‘there’ it is not going to be very useful. More importantly for the ever-shifting world of business, a map needs to show multiple paths so that leaders can take advantage of new options when unanticipated problems arise (and you know they will). Research in this area suggests that models (maps) which are more complex and have more interconnections are more useful for understanding how organizational processes work, and how they might be changed when the need arises. What does NOT work is a simple, linear model such as:

画像ソース: スティーブ・ウォリス (Steve Wallis) 氏


人生がとても簡単で予測可能ならば、このようなモデルが機能しますが、残念ながらそうではありません。そのため、私たちはビジネス プロセス モデリングの少し異なるアプローチを求めていました。そのアプローチを戦略的ナレッジ マッピング (SKM) と呼び、モデリングの変換の側面に焦点を当てています。「表面」レベルで何が起こっているのか(研究が製造部門に情報を提供することなど)をモデル化するのではなく、相互に接続されたプロセスの全ステップでどのような変化が起こるかを確認することをクライアントに勧めています。研究と経験から、私たちは優れたモデルを開発するための 2 つの簡単な手法を開発しました。
まず、モデルの変換を理解するために、各ボックスを指す複数の矢印が必要です。たとえば、焼き菓子を作る場合、作るプロセスには原材料 (小麦粉、卵、砂糖、チョコレートなど)、調理機器や器具 (オーブン、ラック、ミキサーなど)、調理人 (ある程度の専門知識を持った人)が必要です。したがって、変換をよりよく理解するために、それらの「インプット」がそれぞれどのように組み合わさって、変化後の「アウトプット」を作り出すかを示すモデルを作成します。一部の人には分かりきったことに見えるかもしれません。しかし、隠れたインサイト (チョコレートのフィリングなど) があります。1 つの矢印だけが何かを指しているモデルの場合、追加の矢印がないことは、モデルに何かが不足していることを示しています。プロセスを管理するためのもう 1 つのパスが欠けているのです。
効果的なモデルを作成するための 2 つ目のヒントは、各矢印が「因果関係」を示していることを理解することです。これは、ビジネスの世界における「忘れられた知識」の貴重な一片です。因果関係とは、科学的理解の本質です。変換プロセスやビジネス プロセスを全般的に理解するには、「料理人が材料を混ぜてケーキを作る」という単純な表現では不十分です。優れたマネージャーは、より多くの原材料、調理機器や器具、専門知識があれば、売り物になる製品 (またはサービス) への変換が起こることを理解しています。また、そのプロセスを管理するために、それぞれの間に何らかのトレードオフがあるかもしれません(本当に優れた専門家は原材料を少し引き伸ばすことができるかもしれません)が、最終製品を作り出すには、それぞれの流れが必要です。原材料がなければ、私はコーヒーと一緒に焼き菓子を楽しむことはできないでしょう。」

ビジネス プロセス モデルリング表記法 (BPMN)

BPMNは、業界のオープン スタンダードとして、Business Process Management Initiative (BPMI) によって開発され、現在はObject Management Group (OMG)によって保守されています。ソフトウェア会社やコンサルティング会社は所有していません。フローチャートと同様に、プロセス モデルを作成するためのグラフィカルな表記法であり、業界全体で使用され、理解されています。多くのソフトウェア ツールがBPMNをサポートしています。ただし、形や記号の意味はツールから独立しており、詳細に定められています。BPMN は、エンタープライズ アーキテクチャのイニシアチブであるビジネス プロセス管理 (BPM) の中核的な部分です。現在使用されている BPMN のバージョンは v2.0 で、2011 年に最後に更新されました。専門家は、OMG の試験を経て BPMNv2.0の認定を受ける場合があります。また、OMG は、表記法がどのようにイベント、アクティビティ、フロー、データ、アーティファクトなどのグループに分割されるかを示したガイドも提供しています。各要素は、フロー オブジェクト、接続オブジェクト、スイムレーン、アーティファクトと呼ばれる 4 つの主要なグループに分類されます。

出典:OMG


BPMNには、テクニカル ユーザーやビジネス ユーザーが一般的な図式言語を理解できるかもしれないという意図があります。BPMN は、統一モデリング言語 (UML) から開発されたフローチャート手法に似た手法に基づいており、Web サービス内でエンタープライズ ビジネス サービスを定義するために使用される XML ベースの言語であるビジネス プロセス実行言語 (BPEL) に直接マッピングできます。

BPMNの批評


業界の意見は、BP モデリングでの BPMN の使用方法によって異なります。批判家は、BPMN は実際のプロセスにあまり近くない関係者にとって、必要以上に複雑で詳細だと主張しています。さらに、多くの記号を使用するため、ミスが発生しやすいというマイナス面が使用目的を上回っていると指摘します。
BPMNの支持者は、ほとんどの専門家は一握りの記号しか使用しないため、分かりにくい記号の知識は不要であると述べています。国際企業によっては、特に言語が異なる場合は、BPMN の一貫性が必要です。標準化された表記法を使用してプロセスを理解することは、難しいことではありません。

その他の表記法と図

2012 年にクリスティーナ・ヴェネラ (Cristina Venera)氏は、BPMN と UML アクティビティ図 (UML AD) という 2 つの一般的な表記法言語を調査しました。専門家の意見や文献から、同氏は両方の言語が、BP モデリングに関心のある関係者にとって同じように理解しやすく、実際に似たような解決策を提供していることを発見しました。ただし、BPMN が (WS) BPEL にマッピングできるのに対し、UML AD は自動的に BPEL にマッピングできないという違いがありました。
その他の表記法には、イベント駆動型プロセス連鎖 (EPC)、ワークフロー図、マインドマップなどがあります。EPC は、よりハイレベルのビジネス プロセスに最もよく使用され、5 つの要素とルールで構成され、常にイベントで始まり、イベントで終わります。要素間には、図形のコネクタとして表される「OR」、「AND」、「XOR」というルールが存在します。

ワークフロー図は、ビジネスのすべての部分の段階と関係を示します。ワークフロー図には、合意された (標準的な) 記号一式はありません。1 つの組織のさまざまな場所で作成された複数のモデルを比較することは困難ですが、自由な創造が可能です。

マインドマップは、ここに記載されている中で最も制限の少ない手法です。通常は階層型ですが、必要であれば、パブのナプキンに手書きすることもできます。マインドマップは、単一概念の周辺の関係や連想を示す手段です。自由度が高く、最大限の創造が可能です。

出典:Jennifer Frith

ビジネス プロセス モデリング ソフトウェアに求めるべきもの

上述の専門家の意見や調査をすべて読むと、組織の永遠のニーズをすべて満たす単一のツールはないように見えます。ツールやツール一式に推奨される主な要件は、すばやく学べて安価なことです。BPMN のホームページには、BPMN に準拠した 74 のツールが記載されています。BPMN に準拠していることが要件であれば、選択肢はすでに絞り込まれています。そうでない場合は、ユーザーは自身の目的と要件、どのツールが要件を満たすか、最も重要な基準は何か、使用できそうなツールはどれかを特定する必要があります。その後で試します。適切なツールを見つけることは 1 つのプロセスかもしれませんが、後悔することはありません。

JCM Ltd (norbert.nogrady.bpralumni@gmail.com、Twitter: @kgordos) のマネージング ディレクター兼共同所有者であるノーバート・ノグラディ (Norbert Nogrady) 氏は次のように述べています。

“I started to reorganize organizational units more than 15 years ago. At the time, the number of available process modeling tools was very limited, much less their functionality. However, as time went by, I witnessed the evolution of such tools. In the beginning, I used large sheets, then Microsoft Word and Visio. However, I had a number of serious issues with these tools. The biggest problem is that BPR projects tend to be lengthy and thus overwhelming. The usual routine at the large corporations I worked for was (one of the following):

  1. 経営陣が、IT 要件を満たすビジネス プロセス管理 (ワークフロー) 用のツールを見つける任務を IT 部門に課しました。
  2. 管理職のリーダーたちは、BPR エンジニアと一緒に各自のプロセスを作成しました。
  3. プロセス図は、さまざまなツールを使用して作成されました。
  4. その後、プロセスは IT 部門に転送されたため、IT 部門はそのプロセスが自分たちの選択したワークフロー システムに適合するかどうかを評価できました。
  5. これらの作業を何度も繰り返した後 (ほとんどの場合、プロセスについて妥協する必要がありました)、IT 部門はプロセスをプログラミングしてワークフロー システムに組み込み始めました。
  6. プロセスは組織に実装されましたが、その多くはすぐに再設計する必要がありました。
  7. ある程度許容できる一連のビジネス プロセスが作成されるまで、2 ~ 6 のステップが長い間繰り返されました。

上記から明らかなように、この方法での BPR は容易ではなく、非常に多くの時間とリソースが消費されます。また私は、各部門は IT 部門と一緒に反復する代わりに、各自のプロセスを作成する必要があることをすぐに実感しました。そうすれば、多くのプロセスの妥協を避けることができたはずです。加えて、作成したプロセスをプログラミングしてワークフロー システムに組み込むのに本当に長い時間がかかりました。どちらの問題も非常に私を困らせたため、ついに私は、ありきたりの IT 要件を満たし、自分の BPR アクティビティを完全にサポートするソリューションを探し始めました。」


いくつもの製品を試しては失敗した後に、ノーバート (Nogrady) 氏はようやく自分に合ったソリューションを見つけました。ソリューションを見つけることができた経験から、同氏は、グラフィック インターフェイスを備えた統合型のプロセスおよびワークフロー エディタ ツールを搭載したワークフロー システムを探すことを提案しています。そのようなワークフロー システムがあれば、プロセスのプログラミングをなくすことができます。利点は、プロセスをグラフィック ワークフロー エディタで作成したら、ボタンを 1 回クリックするだけで、ワークフロー システムですぐに実行できる点です。したがって、すべての部門はプログラミングを行うことなく、各自のビジネス プロセスを作成できます。このやり方で進めると、ワークフローに妥協がほとんど、またはまったくなく、そして何よりも、多くの時間とリソースをこの方法で節約できます。最後に、優れたソリューションを使用すれば、プロセスのテストに必要な時間と労力がはるかに少なくなります。この方法では、プロセスに何らかの改善の余地がある場合、部門の誰でも提案を行うことができ、部門のリーダーがそれを承認したら、変更済みのプロセスを数時間後にワークフロー システムで実行できるはずです。

ビジネス プロセス モデリングの未来

今後の BP モデリングにとって重要な懸念事項の 1 つに、モデリング アプローチをいかに標準化できるかという課題があります。多くの企業がよりアジャイルなプラットフォームに移行していますが、BP モデリングが必ずしもアジャイル プロセスと連携するとは限りません。ナンシー・アレクソポロウ (Nancy Alexopoulou)氏の最近の調査によると、モデリング アプローチは、一部の種類のプロセスでのみアジャイルと見なされる可能性があります。

また、Elements.cloudの創設者兼 CEO で、Digital Businessのコラムニストでもあるイアン・ゴッツ (Ian Gotts) 氏は次のように述べています。「BP モデリングの分野には大きな問題があります。BPM、自動化、ワークフロー ソフトウェア ベンダーが BPM を乗っ取ったため、BPM の B (ビジネス) が消えてしまいました。モデリングは、IT のための IT によるワークフローの定義を意味するようになりました。しかし、プロセスの視覚化 (ビジネス プロセス モデリング) は、エンド ユーザーにとって価値があります。エンド ユーザーは、ビジネス プロセス図を使用して、作業の進め方について合意します。そうすれば、舞台裏にある IT の視点が得られます。とは言え、BPMN 表記法を万人のモデルとして使用しようとしても、実現は困難です。非常に多くの記号が使用され、複雑そうに見えるため、ビジネスユーザーはすぐに関心を失い、なぜこのようなことをしているのだろうと思い始めます。」

“There is a notation - Universal Process Notation (UPN) - that works for business people, that has been very successful. It is outlined in Chapter two of the e-book,Analysis, Automation & Adoption for #AwesomeAdmins.The first principle that is relevant here is that we are not building a huge flowchart, but a hierarchical process map, where every diagram is easier to follow. For example, at a bank, there may be 10,000 diagrams for all of the processes, but they are organized in a hierarchy so no diagram is overwhelming. Second, the notation is a simple model using an activity box or step with inputs and output, resources identified (or swimlanes), and hyperlinks to supporting information. This process map is useful for end users, but it is also valuable for compliance, IT, and management where metrics can be viewed in the context of a process. Using this approach is valuable for app vendors to improve adoption. An end-to-end process can make sense of the detailed flow of apps.”

ビジネス プロセス モデリングの追加リソース

BP モデリングに関する詳細情報と、貴社への導入方法についてご興味がある場合は、以下の追加リソースをお役立てください。


書籍と電子書籍

ホワイトペーパー

ソフトウェア

その他の図

Smartsheet がビジネス プロセスの改善にどのように役立つか

ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。

作業遂行に Smartsheet がフォーチュン 100 社の 90% 以上から信頼されている理由をご覧ください。

Smartsheet を無料で試す Get a Free Smartsheet Demo