ビジネスモデリング。 主なアプローチ

この記事では、ビジネスモデリングの基本原則、この分野に適用されるアプローチ、およびモデリング言語と表記言語の作成に基づいて話をしたいと思います。



IDEF0を使用したモデリング（IDEF0表記と使用例の理解）、倉庫業務の整理とリードから取引までのクライアントとの連携（CRM実装。リード登録から取引成立まで。ケースと説明）、Bizagiシステムについて（ Bizagi説明、例）。 そしてどこでも、例と実用的な解決策を説明するときにビジネスプロセスの表記法を使用しました。



一方では、誰もビジネスモデルを明確に説明するためのスキームを使用することには疑問が生じます。 とても便利です。 一方、多くのビジネスマンや私の同僚でさえも、グラフィカルエディター（visio）やその他の便利なツールを使用して直感的なダイアグラムを簡単に描画できるため、ビジネスプロセスの開発に特別な表記と規則が必要な理由を疑問に思っています。



標準化が非常に重要である理由と、この場合にこのアプローチが適用される理由についてお話したいと思います。

主なアプローチ

今日、ビジネスモデルを開発するための多くの異なるツールがあります;それらは標準といくつかのプロプライエタリなものの両方の様々なモデリング言語を使用します。 ただし、これらはすべて、作業の原則に従って3つの主なアプローチで組み合わせることができます。

• 機能的;
• プロセス;
• メンタル（メンタルカードを使用）。

実際、もちろん、他のアプローチもあります。それらの多くは、モデリング言語と同じ方法です。 ただし、ほとんどの場合、これらのアプローチを組み合わせたハイブリッドソリューションです。 さらに、少なくとも西側ではすでに標準になっているのはプロセスモデルと機能モデルです。 そして、私たちとともに、彼らはより広く行き渡っています。 これらの主な分野について詳しく説明したいと思います。

機能モデリング

機能モデリングは、ビジネスを機能（lat。Functio-フルフィルメント、実行）、つまり「ブラックボックス」と見なします。 機能モデルでは、関数には時系列はなく、エントリポイントと出口ポイントのみがあります。 機能モデリングは、パフォーマンスの観点からビジネスモデルを検討するのに役立ちます。 モデリングするときは、入力にあるものと出力にあるものから始めます。



たとえば、ある会社がそのビジネスのために何らかのCRMシステムを開発しています。 機能的アプローチをモデリングに適用する場合、作業用に非常に選択された環境により、どこから始めればよいかがわかります。 エントリポイントは「顧客の入力またはリード」であり、出口ポイントは望ましい結果です。「忠実な顧客の購入と受け取り」、「通常の顧客の受け取り」、「潜在的な顧客に関する最大の情報の受け取り」など。



したがって、エントリポイントと目的の結果は、機能モデルで最初に知られており、一連のアクションが開発の対象となります。 同時に、機能モデルを「ブラックボックス」として使用することで、必要に応じて各段階を詳細に説明できます。 そして、シミュレーションのすべての作業は、目標を達成するための最適なソリューションを見つけることを目的としています。



機能モデルを使用して、アイデアやソリューションを紹介することもできます。 これは非常に便利です。なぜなら、デモンストレーション中に、一般から詳細に移動して、必要に応じて機能を分離および分解できるからです。 ただし、同時に機能を正確に分解し、1つの機能を複数に分割すると、プロセスの説明は表示されません。



プロセスの説明と機能モデルを混同する人もいます。 たとえば、Business Studioでは、関数はプロセスと呼ばれますが、これは完全に真実ではありません。 それでも、機能の説明とプロセスのアプローチは多少異なります。 個人的には、機能モデリングはIDEFO表記法で最適に実装されていると思います。 私自身はこのようなオプションに使用していますが、みんなにもお勧めします。



IDEF0表記法と使用例についての記事を読むと、IDEFOを使用するためのルールをより詳細に学習できます。

プロセスモデリング（ビジネスプロセスモデリング）

最も一般的なプロセスモデリング標準の1つとして、BPMN表記の観点からプロセスモデリングについて説明します。 しかし、多くのモデリング言語とさまざまなシステムがあることに完全に同意します。 そして、誰もが彼にとってより便利なものを使用できます。 しかし、それにもかかわらず、BPMNはすでにプロセスモデリングで確立された標準であるため、説明の基礎としてそれを取り上げます。



ビジネスモデルの観点からのプロセスは、開始と終了のある一連のイベントとアクションです。



これは、プロセスモデリングと機能モデリングの主な違いです。 機能モデリングでは、ビジネスモデルを入り口と出口（利用可能なリソースと望ましい結果）の観点から考慮します。 プロセスは、特定の境界内の一連のアクションに基づいています。BPMNの場合、イベントの開始と終了になります。



すべてのプロセスは、タスクレベルで詳細までサブプロセスに分割（詳細）できます。 アクション、それ以上の詳細は不可能です。 プロセスは、特定の結果を得るために完了する必要がある一連のアクションです。 プロセスとしてのビジネスモデルでは、機能モデルとは対照的に、結果が明らかでない場合があることに注意してください。



プロセスモデリングと機能モデリングの根本的な違いは、プロセスモデリング中に、私たちが得たいものではなく、結果を得るために何をする必要があるか、つまり これまたはそのアクティビティの結果ではなく、アクション自体のシーケンス。



たとえば、BPWINまたはBusiness Studioでは、各機能を詳細化するプロセスで、機能的アプローチからプロセスアプローチへの移行があります。 すなわち 一般に、機能と望ましい結果の観点からモデルを検討します。各機能のソリューションに進むと、ここで明示的なプロセスアプローチが既に実践されています。 結果を達成するためのステップバイステップのアルゴリズム。



機能モデルに「ブラックボックス」、つまり「Accept Order」という機能があることを想像してください。 そして、分解するとき、私たちはすでにそれを機能としてではなくプロセスとして考えており、注文をとるときのアクションのシーケンスはすでにプロセスアプローチです。



別の非常に重要な違いがあります。 機能モデルは、設計のためだけに、どのシステムの実装にも使用できません。 プロセスアプローチを使用すると、実行可能モデルを作成できます。 プロセスアプローチに基づいてエンタープライズコラボレーションシステムを作成するための何らかの環境に後で変換できる一連のアクションの説明。

メンタルアプローチ（メンタルマップ）

メンタルモデルを作成するとき、スペシャリストはプロセスまたは機能のセットとしてではなく、関連する概念の特定のセットとしてモデリングにアプローチします。 わかりやすくするために、例を示します-「供給手順」の概念のメンタルマップ（図を参照）。



このバージョンのアプローチは、主に自分自身に適用されます。 自由形式の図を描くと、知識を構造化するのに役立ちます。つまり、受信した情報を自由形式で「ソート」します。 また、このようなメンタルマップは、プロセスまたは機能的アプローチの厳格なルールのフレームワーク内で、必要に応じて後で実装されるソリューションを見つけるのに役立ちます。



メンタルカードを使用して、現在の状況と問題を解決するためのオプションの両方を顧客に示すことができます。 メンタルマップは、使用できる方法を明確に示し、さまざまなアイデアを視覚的な形で示すのに役立ちます。



このようなメンタルマップを使用する利点は明らかです。

• 特別な言語を知る必要はありません。
• スキームを作成する場合、厳密なフレームワークと制限はありません。
• メンタルマップはほとんどの場合直感的です。
• このようなスキームの作成は簡単です。

このアプローチの欠点は、確立されたアプローチと標準化された方法論の欠如です。 機能およびプロセスの表記法に多少のばらつきがありますが、それでもモデリング言語の厳密なフレームワークによって制限されている場合、メンタルマップは任意の形式で作成されます。 また、作成のための特別なプログラムでさえ、モデリングプロセスの担当者をほとんど制限しません。 すなわち 特定のソフトウェア製品の一部としていくつかのルールが導入される場合がありますが、標準は存在しません。



その結果、モデルとそれに組み込まれたアイデアを理解するには、開発者（アナリスト）の存在とコメントが必要です。



もちろん、追加のコメントなしで読みやすく直感的なカードがあります。 しかし、標準が存在しない場合、この場合でも、著者が何か他のことを念頭に置いているか、スキームを十分に詳細に記述していない可能性が常にあります。 すなわち 異なる読書の可能性があります。 そして、ビジネスは哲学ではありません。 ビジネスプロセスを説明するための投機的で多様なアプローチのすべてにおいて、ここでは明確なソリューションが非常に重要です。

ビジネスモデリングの方法論と言語

非常に頻繁に、専門的な文献でさえ、人々がビジネス分析方法論とビジネスモデリング言語の記述の概念を混ぜると混乱が生じます。



方法論は、ビジネスモデルとその後の分析を記述するための原則と標準のシステムです。 ビジネスモデリングの言語は、ビジネスモデルを開発するためのツールにすぎません。



これは、プログラミング全般と特定のプログラミング言語の使用との比較を促します。 プログラミングには、アルゴリズムの構築、適切なプログラミング言語の選択、および特定の言語のフレームワークでのプログラムアルゴリズムの実装が含まれます。 そして、たとえば、C ++でのプログラミングは、特定のフレームワークに対して明確に制限された範囲のタスクのみが特定のフレームワークによって解決できるため、特定のフレームワークに対する意図的な制限です。この言語は特定の場合に最適です。 一般に、「プログラミング」と「特定の言語内でのプログラミング」の概念の違いは、そのような説明がなくても最も理解できると思います。

ビジネスモデル開発言語とシステム設計言語の違い

ビジネスモデリング言語と外観が似ているシステム設計言語のファミリがあります。たとえば、UMS言語のファミリ全体であるAres Studiosなど、ITシステムの設計に使用されます。



これらの言語とビジネスプロセス開発の言語の主な違いは、その目的にあります。 ITシステムの設計言語が、ITシステムでの自動化、実装の可能性の観点からビジネスプロセスを考慮する場合、ビジネスモデリングの言語は、ITシステムと従業員の両方の運用、商品の移動など、ビジネスの観点からアクションのシーケンスを正確に考慮しますなど



したがって、システム設計言語には、部門、従業員、それらの間の相互作用、サプライヤーとの連携、顧客とのコミュニケーションなどを完全に記述するのに役立つ要素はありません。 この言語グループのツールは、自動化できるビジネスプロセスの自動化に役立ちます。 そして、他のすべては、たとえば、復号化のない「機能」として、舞台裏に残されます。



同時に、ビジネスプロセスの開発言語は、ビジネス自体の作業を可能な限り正確にカバーしますが、自動化とシステムアルゴリズムの特定のニュアンスを十分な詳細度で記述することは常に可能とは限りません。

ビジネスモデル開発の利点

それなのに、なぜ厳密な制限を課すビジネスモデリング言語を使用するのに、モデリング時に厳密に定義されたルールに従う必要があるのでしょうか？ 結局のところ、グラフィカル言語で、またはメンタルアプローチを使用して紙の上でも、いつでも「図を描く」ことができますが、モデリング言語を学ぶ必要はまったくありません。



実際、標準と規制は大きなプラスです。

1. モデリング言語は、最高品質の情報を伝えるのに役立ちます。 標準化により、認識が容易になります。
2. モデル開発の速度が大幅に向上します。 言語には、必要なすべてのツールとグラフィックブロックが既製の形式で含まれています。 独自の用語を「描く」必要はありません。 ツールキットはすでに準備ができており、そのフレームワークでの作業は大幅に加速されています。 もちろん、言語を学ぶ必要があります。 しかし、一度勉強すれば、毎回独自の表記法を考案して説明するよりもずっと速くなります。
3. 考えられるエラーの数が減ります。 システム自体の要素は、考えられる必要なアクションのリストをすでに「プロンプト」します。 また、実行可能モデルまたは非実行可能モデルを作成する場合でも、ルールの厳格なフレームワーク内で、実行環境でビジネスモデルの動作を常にチェックし、プログラミングのようにデバッグできます。

ビジネスモデルを実践する

個人的には、ビジネスモデリングを使用して、問題やボトルネックの特定、ビジネスの最適化と近代化などに関連する問題を解決する必要があると思います。 ビジネスコンサルタントとして、私はほとんどの場合、顧客と仕事をする際に会社またはその部門のモデルを構築します。 これにより、作業のすべての段階を明確に理解できるようになり、この問題で「ホワイトスポット」が回避されます。



さらに、ビジネスモデルの視覚的な図は、クライアントとやり取りするプロセスを支援します。 私のプロジェクトはしばしば複雑であり、プレーンテキストまたは話し言葉では理解するのに十分ではありませんが、視覚的なビジネスモデルを使用すると、クライアントが提案を読んで理解する時間を短縮し、この問題に関する理解の問題を実質的に排除します。 そして、数年前に私がまだ顧客によって混乱していたら、今では視覚的で便利なスキームなしで「言葉で」を記述するオプションはほとんど実践されていません。



また、作業のあらゆる段階の自動化またはプロジェクト指向のアプローチに基づく自動化されたビジネス管理システムの作成の場合、特定のモデリング言語で実行される高品質のビジネスモデルは、技術専門家向けの既製のガイドになります。



利便性、汎用性、知覚の容易さ-これらが、ますます多くのビジネスモデルが言葉による記述からビジネスモデリングに移行する理由です。 また、既製の言語を使用すると、モデルをすばやく操作し、ミスを回避し、問題なく変更を加えることができます。



また、現在、ビジネスおよびプロセスモデリングの分野での実際の経験だけでなく、ビジネスへのプロセスアプローチについての私自身のビジョンを詳細に説明する本とオンラインコースを出版する準備をしています。 誰もが新しい書籍、その他のニュースについての通知にサインアップすることができますリンク 。