ビジネスプロセス：すべての稼働状況。 第3章 一般的なBPM分類とBPMSの哲学

BPM「現状のまま」および「現状のまま」

私たちは、「BPMとは何か」、「ビジネスプロセス管理」とは何かを考え続けています。 パラドックス：彼について何十年も書かれています-本、記事、議論、それが何であるか-今日でも謎のままです。さらに、彼らが書くほど、それはより神秘的になります。



シリーズ「For Dummies」の本も、CBOKコヴナントも、ガートナーの魔方陣（BPM：BPA、BPMS、iBPMSなど）もありません。いくつかの「異なる」オプションがありました）-それぞれが彼だけが知っている素晴らしい神秘的なものを見ようとしています。



この章では、BPMに似たエンティティの分類オプションを提案しています。 「21世紀の錬金術」との情報戦争では、ビジネスプロセス管理、エンタープライズアーキテクチャ（EA）などの人気の神話を覆し続けています。 私たちは、通常の（日常的、ユビキタス、些細な）エンジニアリング分野としてのBPMの開発に向けて、次のステップを踏み出しています：プロセステクノロジー、「プロセステクノロジー」。







偵察



最初の章「ビジネスプロセス：すべてがどのように開始され、混乱するか」では 、マーケティングの目を通してBPMを見て、その重要な神話を示しました。 cnewsのページ（記事へのコメントを参照）で、トピック「BPM-EA-Alchemy」について議論しました。



第2章では、彼らは「カツレツからハエ」を分離しようとし、極端（頭と尻）を示しました：BPMはビジネス管理ではありません（BIZBOKs、BABOKsなどの「オペラ」からではなく） 「ITチップ」（SOA、ESB、およびその他の類似品）についてではありません。 BPMは自動化、つまりSWEBOKの制御下での古典的なプログラミング言語（「C」から「Java」）、BPMNに基づいた「newfangled」ツール、または「nothing」（「no code」）でさえありません。おそらくコーディングは不要です）。 bpmsoft.orgでの「レベル80錬金術師」との第2章の議論



「BPMに関するスマートブック」の半分がSOA、ESBなどに捧げられている場合、それらが社内にない場合、社内のBPMも不可能ですか？ または：BPMは（ほとんど）自動化されている会社に住んでいますか？ このトピックについては、書籍Business Process Managementの一部です。 プロジェクトを成功させるための実践ガイド



第2章ビジネスプロセス管理とは

特に、各サプライヤー、アナリスト、科学者、教師、ジャーナリスト、およびクライアントがそれぞれ独自の答えを持っているため、この質問は最初に答えなければなりません。

私たちの意見では、BPMはビジネスプロセスの分野における技術ツールやイニシアチブプロジェクトと同等ではないことをすぐに明確にしたいと思います。 私たちの経験は、自動化技術を使用しなくてもビジネスプロセスの大幅な改善が達成できることを示唆しています。



IBMからダミーへのメッセージ 。

ブルージャイアントは、IBM Limited Edition for DummiesのBusiness Process Managementでどのような啓示をしましたか？



はじめにと第1章：「BPMの幸せな所有者」、「BPMだけがあなたの組織を...に助けることができます」（より高く、より強く、より強く、など）...極度に大きく、などのスタイルで書かれています。 さらに、本の広告スタイルでは、子音の用語「BPM」を「IBM」に置き換えることは、セマンティックコンテンツ（より正確には、広告）を変更することなく、それ自体を示唆しています： 「これまでの章を読んだ場合、BPM（より正確には、IBM ）かっこいいです 。 」



実際、この章全体は「ビジネスプロセス：すべてがどのように起動され、混乱するか」に専念しました。 第1章。」 一言で言えば、「BPM for Dummies」を読んだ後、BPMが本当に必要なことはすべての「ダミー」に明らかになるはずです（これは「クール」です）が、彼らはこれを知る必要はありません（本では答えが見つかりませんでした）。 残りの章では同じことを繰り返しますが、もちろん、以下は「IBMが最も幅広いBPMソリューションを提供している」という「邪悪な」結論です。 当然のことながら、「正しいBPM」= IBM BPMです。 IBMには本当のBPMがないという秘密をお話しします。



新しいARISホストからダミーへのメッセージ。 BPMは販売する必要があるため、ベンダーだけでなく、売り手もダミーの本を作成します： BPMの基本

ダミーSoftware AGスペシャルエディション用



これらの「基本」では、すべてが収集されます：適応性のある柔軟なプロセス、リアルタイムでのエンドツーエンドプロセスの視覚化と管理（リアルタイムでのプロセスのオーケストレーションおよびコレオグラフィ、部門横断的な可視性）、「自動化-シミュレーション-最適化」、式による通信{人、情報、サービス、システム、プロセス}。

もちろん、継続的プロセス改善（CPI）、リアルタイム監視（BAM）、KPI-BSCなど、および最近BPMに縫い付けられたWYMIWYRとDMAICも忘れられていません。



「BPMは幅広い分野です」と書かれている本の典型的な間違い。 BPMは、「狭く」、具体的で理解しやすい規律でなければなりません。 これだけが、実用的で普遍的に適用可能なエンジニアリング分野になります。 隣接するエリアを取り出して、BPMの「屋根裏部屋」と「セラー」を考え、明確なBPMスタックを作成します（ネットワークプロトコルに似ています）が、看板「幅広い規律」の下ですべてを混ぜ合わせる必要はありません。

それまでの間、「それを理解するにはBPMが多すぎます」（それを食べるには大きすぎます）が表示されます。



最初にBPMが「ビジネスインフラストラクチャ」であると述べた場合（これは事実です）、明らかにこれに従うべきであり、インフラストラクチャをビジネスエンティティと混合せず、BPM「BPMビジネスアーキテクチャ」で考慮されません。



3 BPMの一般的な分類



3.1 BPM分類に関する一般的な見解



BPMは、ビジネス変革を成功させるためのプロセスまたは管理戦略に集中できる単なる経営理念であると言う人もいれば、ドキュメント、開発、実装などの多面的な分野の一種であると言う人もいますが、普遍的な用語「管理の規律」の下で。 さらに他の人（アーティストはどうやら）は、これはSOAとWeb 2.0の隣にあるものであり、オーケストレーションと振り付けに言及したいと主張しています。



ほとんどの場合、BPMは「3人」で提示され、ビジネスプロセスは次のようになります。

-文書化および分析（設計および分析ツール）;

-シミュレーションおよびモデリング（シミュレーションエンジン）;

-デプロイおよび実行（実行エンジン）。

近くにはダッシュボード、リポジトリなどの「サーバント」があり、VIPボックスにはCPI、BSC-KPIなどがあります。



人気がありますが、BPMクラス（方向と関連ツール）のプロの「傾斜」ビューは、多数のよく知られたマーケティング用語のセットからカラー画像を示唆しています。

「単純で理解可能な」BPMではなく、複雑さの良い例が図に示されています。 3.1。 KPMGのBPMを見る

このようなBPMには、似たようなアーキテクチャとアイデアが数多くあります。明るく美しい画像（デザイナー向け-5人のプレゼンター）ですが、わかりにくいです。







図 3.1 KPMGからBPMを見る



図 図 3.2は、 www.what-is-bpm.comの写真を示しています。これは、BPMツールの分類に対するより理解しやすい（「芸術的」ではありませんが）アプローチを反映しています。







図 3.2 BPMの概要-what-is-bpm.comのツールキット



写真は次のようなものです（その本質をよりよく伝えるために、少し皮肉を込めて）：



1）理解から-プロセスの理解（「プロセスの認識」）。プロセスマッピング（プロセスマッピング）およびドキュメントツールでサポートされています。



2）プロセスを改善するために-分析（その後、分析なしの場合）およびシミュレーションモデリング（理解の文脈で「モデリング」=「ドキュメント」と混同しないでください）。



3）BPMSバージョンによる自動化/近代化（それらはほぼ同義語になりました）、SOAによる統合、および「適用されるハイブリッドと複合」の開発。



4）そして確かに-これはすべて「常に最適化」とリエンジニアリングであり、最適化と「根本的な再考」を繰り返します。 ループプロセスを継続的に-「永遠の」改善。 どうしてそんなに必要なのかわかりません-どうやらそのようなBPMには「提供するのを忘れた」「ブレーキ」はないようですが、多くの本ではこれが書かれています。

また、第4項と第2項の違いは何ですか？



ちょっとした追加：「小さなパーティー」（ワークグループ）にこれがすべて必要な場合は上記の「少しずつ」、そして「クール」なエンタープライズ全体の場合は「たくさん」（「スコープ」ベクトルは「スケール」を示します）さらに、（o）ryプロセスと何らかの種類の「プロセスの相互作用」（最上位の「バン」）のリポジトリが必要です。



3.2 BPMシステムの簡易分類



BPM領域の多様性を考えると、プロセスの説明に直接関係しないBPMコンポーネントの考慮から、改善（CPI）、最適化、明確に形式化されていないあらゆる種類の「管理」などを除外し、プロセスとその最も単純な説明のみに集中します分析（「ビジネスコンポーネント」なし）。

つまり このサイクルの第2章に示されている「プロセスレベル」、「プロセステクニック」の観点からのBPM。



3つの方向を区別します。

-基本的なBPMである「BPbase」は、以下に基づいています。

--BP、「BPdoc」および

--正式化されたエンティティの二次処理と分析、BPana;

-BPシミュレーション、「BPsim」。

-BP実行、「BPexe」。



BPdocのタスクは、プロセスを形式化することです（実際のプロセスのイメージを図形式で表示します）。 BPsim-動的プロセスモデルを通じてプロセスを「アニメーション化」するか、静的モデルにプロセス特性を反映します（説明や規制ではありません）。



BPexe-実行可能なプログラムコード、つまり 「プロセスをプログラムにします。」 「おとぎ話を実現する」BPexeを含む自動化（夢1）の「明るい夢」は、すべてのロジックが実行可能コードで「配線」され、コンピューターオペレーターのすべての作業（エグゼキューターのビジネスプロセスへの参加）がワンクリックで「大きな」赤いボタン。」







図 3.3 BPMシステムの簡易分類

元の品質で



分類は、次の「タンク」の例えで説明されています。

-BPdoc-図面または図面としてのタンクの画像。 スケッチまたはブラシストローク（印象派）によって作成されたスケッチの場合、遠くから（鳥瞰図、高レベルから）表示した場合にのみ理解できます。 作業図面の場合（つまり、作業に応じて）-一連の設計ドキュメント（AutoCADのタンク）として：すべてのサイズおよびセクション（プロセスセクション）、「プロセス回転」（プロセスを「ねじる」ことができます） ）など、3D（より正確にはn-次元、平面）のプロセス画像など これらは、プロセスの「設計文書」（ESKDの観点から）、「文書」のプロセス文書、製品の「プロセス」の作業ドラフト、プロセスの仕様などです。



-BPsim-リモートコントロールを備えた小型の戦車モデル：おもちゃのように見えますが、「プラスチックの弾丸で動き、撃ちます」。 このような戦車は実際の戦車と似ています。詳細はすべて同じ（複製）で、質量サイズのモデルを実行することもできますが、前面に送信することはできません（偽のターゲットとしてのみ）。 別の例は、World of Tanksやプロの空気/自動車/タンクシミュレーターのような「クールな物理学」を備えた玩具です。 また、すべてがほぼ本物に似ていますが、入力（高さ、速度）-架空（計算）および健康（実際のプロセス）は、「何かがうまくいかない場合」に害を及ぼすことはできません。



-BPexeはすでに3Dプリンター（BPMS）に読み込まれた図面（BPMN 2.0）から取得した実際のタンクです。 図面をダウンロードし、製品を印刷し（ランタイム環境でプロセスを公開）、「最前線に」（プログラムを産業環境に展開します）。 実際の戦車を印刷することはまだ将来（まだ遠くない）ですが、実際の小型武器はすでに印刷されています： 3Dプリントされた武器の進化



今日のBPMSとほぼ同じ：実行可能なBPMSで単純なものが作成（および実装）されますが、複雑なものは従来の技術（クラシックプログラミングシステム、既製のERP / ECMなど）を使用します。 最新のBPMSの機能はまだ非常に限られており、進歩はまだ止まっていない。



「BPMN」という用語は、「se one」とブルジョア「ke two」（1C＆K2）のアイコン（図）の元のセットを含む、他の「実行可能な」表記法に起因します。 原則として、BPMN 2.0規格の面から直接どれだけ取ったかは関係ありません。原則として、本質は同じです：「BPMS 3Dプリンターでのプロセスの印刷」（特定のプロセスブループリント）。



3.3「BPbase-Bpsim-Bpexe」の詳細



BPdocは、形式化されたプロセスのグラフィカル表現（グラフィカル表記によるモデリング）に基づいています。 ダイアグラムのプロセスは、通常、ワークフロー、ルール（分岐ロジック）、情報フロー（データフロー）およびドキュメント（docflow）の観点から表されます。



通常、BPdocツールは、ビジネスプロセスモデリング（BPM）ツールとして定義されています。 しかし、「モデリング」は「シミュレーション」ではないという理解では、つまり 「モデル」は、構成オブジェクトのオブジェクトの関係を備えたダイアグラムのようなもので、共通のリポジトリ（アーカイブ）に保存されます。 他のスキームと同様の接続性、オブジェクトのリファレンスブック（プロセスおよびその他のエンティティ）。



BPdocには以下が含まれません。

a）会社の規制フレームワーク全体、またはテキストによる規制のフルセット。 テキストおよびグラフィックの「プロセスインクルージョン」（プロセス規制）のみが暗示されています。

b）プロセスに直接関係しないエンタープライズアーキテクチャの構成（発音が怖い）の構造。



極端な場合、BPdocには「大規模な」プロセスマップがありますが、テキストによる説明なしに完全なプロセスの説明がどのように可能かはわかりません。 より正確には、BPdocは企業の運用モデルであり、プロセス（機能）、ポジション（役割）、ドキュメント（処理された情報）、およびツール（情報システム、IP）の関連記述を意味します。



原則として、これには組織構造とIPの詳細な説明は必要ありませんが、「軽量EPC」クラスのスキームに関係するオブジェクトの階層（階層参照）で十分です。 さまざまなEPC（プロセスのイベントチェーン）全体の「軽量EPC」では、「機能」と「イベント」に加えて、5〜6種類のオブジェクト（ロール、ドキュメント、情報システム）に制限されています。



組織のスタッフ（ロール）構造、一連の（ツリー）ツール、および受信/送信（プロセスへ/から）ドキュメントなしで最終プロセスを読む（記述する）のは非効率的です（情報価値がありません）。 例外は、分岐ロジックを示す図です。 したがって、要素「機能」の「結合」（「機能の環境」）と、単純な構造スキーム（少なくともIPの組織構造と構造スキーム）でのこれらの結合の要約が必要です。 詳細については、ARISプロジェクトの「モデリング契約」を参照してください。

上記の強調は、プロセスを修正するための表記法（EPCが主導）ですが、BPdocはクラス「実行可能」（BPMN）を含む他のすべてを使用します。



BPM「実行可能」（BPexe）には、少なくともデザイナー（アプリケーション開発モジュール）と「ランタイム環境」（エンジン、BPM-Engine）が含まれ、実際には一種のプログラミングシステムです。 つまり、ビジュアルプログラムデザイナによる「プログラミングなしのプログラミング」の指示（多くの場合、BPMSに多くのコードを追加する必要があります）。 このプロセスはBPMに関係しますが、BPM表記（BPMN）の形式のグラフィカル言語と、プロセス図および画面形式の「ソース」を備えたプログラミング環境により近いものです。 今日、BPMSベンダーはこれが「本当のBPM」であると確信していますが、これはBPMブランドの窃盗でした（「偽BPM」、図3.4を参照）。







図 3.4用語BPMの偽造



「new wave compiler」（BPMS、「graphics to code」）の開発者とセールスマンは、システムエンジニア（SE）からBPMブランドを選択し、見返りにBPAを投入しました。 ビジネスプロセス分析



置換は、「指を差し、手をかむ」というシナリオに従って実行されました。 BPMブランドから「コーダーのための慈悲」（SWE）への「降伏」（戦いなし）には、BPMの初期アイデアの妥協が伴いました。これは、ソフトウェアエンジニアリングでは不要または取るに足らない（厳密には勝者には独自の管理方法論および高レベルコンポーネントとして） EA "）。

これは、「現状のまま」対「現状のまま」という矛盾の文脈におけるBPMSの歴史と哲学に関する発言でした。



結果は、古典的なBPMの疑わしいベンチマークを伴う「偽のBPM」でした。 これまでのBPMNおよびその他の実行可能な表記法と同様のBPMN 2.0：



a）ビジネス分析には効果がない（BPAと比較して）、

b）ビジネスユーザーによるプログラミングに疑問がある。



多くの場合、「異常な」ソフトウェア開発ツール（「BPMS実行可能ファイル」）を使用した通常のプロセス自動化は、「成功したBPMプロジェクト」（「誰かの勝利」の栄誉）として位置付けられます。 すでに強調されています：BPMと自動化の間には直接のつながりはありません。 「実行可能なBPMS」の実装とそれを使用したプログラムの構築は「BPMタイプ」であり、CRM、ECM、ERPに組み込まれたBPMエディター（デザイナー）で同じまたは同じ表記法で同じプロセススキームを構築することはBPM実装とは見なされません。 なんで？ これは単なる組み込みBPMです。 ほとんどすべての最新のCRM、ECM、ERPには、少なくとも「BPMに似た」ワークフローコンストラクタがあります。 会社のビジネスプロセス：ECM、CRM、BPM-違いは何ですか？



BPMSデザイナーで構築され、BPMエンジンで実行される新しいアプリケーションの導入は、従来の自動化と大差ありません。 多くのビジュアルプログラミングシステムとプログラムデザイナー（Webサイトのマスターと子供向けのスクラッチを含む）があり、「プログラマー」はコードの1行（正式にはBPMS-「コードなし」）を見ることができません。



現代のBPexe（BPMS）の自動化の基本原則は、20年前の技術プロセス（BPexe-管理、管理プロセス）の自動化に使用されるSCADAシステムの類似物です。 ドキュメントの代わりに電気信号があり、「ライブパフォーマー」（役割）がバルブ（プロセス制御システムのアクチュエーター）またはセンサーであるという違いはありますが、同じビジュアルプログラムデザイナーです。



国内のTraceModeを含む今日の「長年の」SCADAの多くには、BPMSに似たビジュアルエディター（プログラミングを知らない「プログラマー」向け）、技術プロセスのフローチャート、ビジネスアクティビティモニタリング（BAM）がありました。制限時間（制御）および温度、圧力、速度、体積などの実際の値：



このシステムを使用すると、プロセスエンジニアに馴染みのある用語を使用する特別なグラフィックエディタをまったく使用せずに、複雑なプロセス制御システムを作成できます 。



どこかですでに似たようなことを聞​​きましたが、「ビジネス技術者」についてですか？会社のワークフロー（BPM）の視覚的なデザインは、プロセスの視覚的なデザイン（ACS TP）に似ています。



シミュレーターBPM（BPsim）-ほとんどの場合、BPdoc（本物のBPの規制）とBPexe（本物のプログラム、つまり自動化されたBPおよびBPMNなどで文書化された）の間の一種の中間カテゴリーです。シミュレータを使用すると、プロセスのダイナミクスを「感じる」ことができ（動的モデリング）、プロセスの「単純化された」インスタンスを実行できます。



残念ながら、BPsimとBPdocには「シミュレーション」という用語が使用され（シミュレーション-シミュレーションとして）、「ビジネスプロセス」のモデリングは「実際の」BPA-BPMS（ARISシミュレーション、PBexe）とユニバーサル（クラシック）モデリングシステム。モデリングは、BPMコミュニティによって認識されるグラフィカルな表記、および「認識されない」または一般的に、グラフィカル言語（GPSS：Business Process

Simulation BPmon など）を含む非グラフィカルな抽象化によって可能です。



3.4 BPMSの人気の理由、または「人類の偉大な目標への道」：プログラマなしでプログラムを作成する

BPdoc、BPsim、BPexeを使用してプロセスを記述する場合、キーワードは「プロセスの図表」です。プロセスは、正方形やロシア語の力だけで説明することはできませんが、プロセスの説明は文字によるプロセス規制です。

プロセスやイベントを形式化するための特別な言語があり、特にシミュレーションシステムでは一般的ですが、アナリスト、方法論者、およびその他の「ビジネスからのビジネスロジックの修正者および外科医」ではなく、プログラマ向けに発明される可能性が高くなります。たとえば、ビジネスプロセス実行言語（BPEL）など、一部の言語には名前に「ビジネスプロセス」という言葉が含まれていますが。



これは、「最大の」BPM表記にも適用されます。頭字語BPMNは、ビジネスプロセス実行言語としてではなく、「ビジネスパーソンが理解できない

」、つまり「ビジネスパーソンが理解できない」と解釈される可能性が高くなります（Jim Sinur ）

長年の間、欲求（夢番号2）は消えていません-BPMの専門家が「正方形と円を描く」ことなく、参加者が直接プロセスをシミュレートする簡単な方法を見つけること（この方法で構築されたプロセス）。したがって、BPMS形式（BPexe）に対する強い欲求（希望）です。

残念ながら、これは夢のままですが、たとえばBPMNが始まったのはこの考えに基づいていたため、定期的に記憶されています。しかし、BPMNは、ビジネスユーザー（直観的な基準）および「トップ」レベルでアルゴリズムを修正および分析するために同じEPCに多くを失い、当初設定された目標を達成しませんでした。



読みにくいBPMNは、記述されたプロセスの強制された高レベルの詳細にも影響されます。EPCをテキスト規制に詳細に送信できる場合、実行可能なBPMNの場合、「すべてを持ち歩く」必要があります。

次のラウンドは、「新しい現代のBPMチャレンジ」によって行われます。S-BPMは、次のムーア（ドイツの教授）の「被験者指向のBPM」パラダイムです。



もう1つの神話は、BPMSが使用されるため、出力は「効率と最適性の積」であるというものです。 Shaitan-BPMSプロセス設計者にとっては、「効果的なプロセス」を即座に作成し（明らかに、ハイパー認知分析のステルスライブラリを介して）、BPMSランタイムはプロセスのビジネスロジックを最適かつ「オンザフライ」にします。



« » , , « ». , () , - (-). , «» , (, ) , , « » : ()



さらに、ITサービス（ユーザー自身によるボタンによる「製品」への「公開」）に参加することなく、受信したプログラム（実行）の作業を保証したいという要望があります。ご覧のように、この概念の実装はまだ理想とはほど遠いですが、「プログラミングなしのプログラミング」という このかなり古い方向で進歩を否定することはできません。



上記の願望は「トレンド」に含まれています：BPMS、「ローコード」、ノーコード」（プログラム実際には、すべてはよりシンプルです：「個人的なものは何もない、ただのマーケティング」。たとえば、彼らは私たちを「本当のBPMS」のランクに受け入れません。例えば、BPMN-はサポートされていません。表記法を「ローコード」と呼びます（「one se」と「two ke」を含む）。または、「open」にしたいマーケティング市場（実際には同じ）スニーカー«code.net»で、最初の「ジャンプ」。

同じ「1つのフォーム」（1forma.ru）は、BPMSとワークフロークラスの制御システムの両方として位置付けられ、「ローコード」を拒否することはありません。



多くの場合、販売は次のように行われ

ます。-この素晴らしい子犬を購入してください！ （ソフト）

-そして、どのサイズに成長しますか？

-大きな犬が必要ですか？え？もちろん、子犬は成長して巨大な犬になります！ （BPMS）

-ああ、違う？小さな小さな犬が必要ですか？だからあなたは私たちを誤解しました：私たちの子犬はもう成長しません-それは同じままです（「ローコード」と「コードなし」）！ただ私たちからそれを購入してください！



ローコードシステムの主要な機能は、目的の関数を関数ライブラリからドラッグアンドドロップしてアプリケーションを作成し、ビジュアルコンフィギュレーターを使用してコーディングすることなくアプリケーションロジックを構築することです。



現代のBPMSは「ヒューマノイド開発者」（非プログラマー）にはあまり馴染みがありませんが、他のプログラミングシステム（Cから始まる）と同様に、多くのコードを必要とし、「単なるカオス」から「自動化されたカオス」を作ります。後者はさらに危険です。



会社のビジネス部門の方法論者向けの「コード作成」システム（「コードなし」を含む）、言語、表記法、およびその他の抽象化（ビジネス、プロセス、および生活全般を説明する言語を含む）がありました。つまりITサービスやプログラマ向けのツールではなく、通常の「juzverej」向けのツール。後者は、これらの表記法と抽象化に関するプロセスを少なくとも簡単に読み取る必要があります。これは、「ビジネスユーザー」（非技術ユーザー）自身によって「ビジネス言語での正式化」と呼ばれることもあります。

表記法と抽象化は、実用的で標準的で、プログラマーでない人（子供）でも理解できるものでなければなりませんが、実際のプロセスに適したモデル（記述）の構築を許可します。



「子供向けのプログラミング」の方向が同様に発展していることは興味深いです。たとえば、Scratch



BPexe（BPMN、「低コード」など）で8〜10歳の子供にプログラミングを教えた経験。 BPexeが少なくともモデリング、実装（プログラムの実際の実装）、およびその展開の段階をサポートしている場合、「exe」（実行）の下のモデル-実際、常に実際のプロセスと自動化されたプロセスに適しています。BPMSリーダーレビュー



BPana、プロセス分析-創造性の「幅広い」方向。些細な分析の例は、データベースクエリです。そのようなプロセス（オブジェクト）はいくつ、どこで発生しますか、またはどのプロセスで「A」ユニットまたは「B」ドキュメントが関係しますか？ちなみに、Visioなどの描画クラスシステムで多くの要求を行うこともできます（オブジェクトはそこでも使用され、検索システムも使用されます）。プロセスデータを含むExcelファイルまたはAccessファイルがVisioのプロセス図に添付されている場合、簡単な分析機能「クール」なBPMと比較できます。 BPAおよびBPMS（確立された分類）。

いずれにしても、BPanaは「セカンダリ」であり、「プライマリ」を必要とします-BPdoc。同時に、プロセスマップ（BPdoc）を注意深く見れば、既に「分析」（BPana）が暗示されているため、この線は任意である場合があります。



3.5森林、木、葉



プロセスの粒度は異なります。少なくとも：トップレベルで詳細。 BPexeクラスのスキーム（モデル）はすべて詳細です。それ以外の場合、プログラムは動作しません。これは「定義による」です。なぜなら、 -"exe" = "実行"。

しかし、詳細は常に良いとは言えません。「森は木の後ろに見えない」ため、BPdocは2つのタスク（カテゴリ）に分割できます。「森」（「大きなセル」、鳥瞰図でのプロセス）十分に詳細な「プロセス-木」ですが、原則として、BPexe（BPMN）ほど詳細ではありません。各ナットは形式化されます（そうでない場合は起動しません）。 BPMNを使用すると、「葉」（ナッツ）だけでなく、「木」も記述できますが、「森」は記述できません。



一方、詳細（詳細プロセス-EPCの「ツリー」およびBPMNの「葉」）の背後では、企業（フォレスト）のプロセスランドスケープ全体の全体像が失われています。一方、すべての「プロセス-木」（「葉」は言うまでもなく）を記述することは、少なくとも概略的には、小さな森でもすべての木をスケッチするのと同じくらい困難です。

このトピックでは、プロセスマップと地理的マップの類似性があります。ビジネスプロセスの詳細な説明は、良いのか悪いのか。



大企業のビジネスプロセスの完全な説明は、ユートピアです。いずれにせよ、ビジネスプロセスを記述するための最新のテクノロジーを通じて：複数ページのテキスト規制の形で、正方形と円（モデル、表記法）の形で。

最初のケースでは、マルチボリュームのTalmudsにはリンクと明確なスケーリングがありません（高レベルから「電子メールによる通知の送信」まで）。

第二に、EPCスキーム（BPMN、UMLなど）は、非常に長い時間、多くの製図工（ビジネスモデラー/ファッションデザイナー）によって描かれなければならず、とにかく「現状のまま」を保証するものではありません（記事のタイトルの写真を参照） ）



すべてのプロセスがBPMS（PBexe）を使用して自動化され、BPMNにプロセス図（モデル）の完全なセットがある場合でも、「画像」全体を理解する（「フォレスト」を表示する）には、一般化、拡大、体系化などが必要になります

さらに、すでに述べたように、BPMN形式の元の「作業プロセス」（非常に詳細なプロセス）は、事業単位のほとんどの従業員には理解されません。一般に、BPbaseは、森林と樹木の記述と分析の両方における科学です。また、BPbaseの主な表記はBPMNではなく、EPC（以前のIDEF）です。インターネットには、EPCとBPMNの多くの比較があります。



一般に、「フォレスト」-高レベルプロセス-の記述が非常に簡単（VAD、EPC、BPMNではない）で、そのような作業の価値が最も高い場合、詳細なものは「ツリー」（EPC、BPMN-「実行」ではなく、 「イラスト」）は、これらのスキームが指示（規制）のテキストを複製（しなければならない）ためだけである場合、すでに価値の低い（BPAタスクで）膨大な量の作業です。



BPMNタイプの実行可能な表記法を使用して「直接実行のプロセス」を記述することは、基本操作、つまりより詳細な説明を必要としないものすべてコンパイラは既にそれらをコードに変換できます。 「ダム」コンパイラーが回路を動作中のコードにシフトできる場合、これは明確な詳細の「フィニッシュ」です（マシンの限界、人は停止するのが難しい場合があり、繰り返して無限にドリルダウンする準備ができています）。



外側では、モデリングプロセスBPdoc（EPC）とBPexe（BPMN）には多くの共通点があります。視覚的な違いはほとんどなく、ほぼ同じ正方形と円です。これにより、多くの点で、促進された用語「BPM」を（平文で-盗むために）借りることができました。 BPexeは同じ問題を部分的に解決します-プロセスを文書化します（結果は図3.3の「二次」BPdocです）が、根本的に異なる目的と「独自の哲学」を持っています。

最初に、管理プロセスがほぼどのように機能するかを人に示す必要があります（「一般」、および多くの詳細については、規制のテキストを参照してください。したがって、「多くの問題」があります）。

2つ目は、コンパイラに明確な指示を与えることです（グラフィックイメージを使用する場合でも）「何をすべきか」（およびコードにのみ多くの詳細が残っています）。



時間が経つにつれて、BPexe（BPMS）とBPdoc（BPA）の間の線は徐々に消えていきます。おそらく、「個人」向けの別のクラスのシステム：「ITの世界からの恐ろしい言葉」をまったく知らないビジネスアナリストにとって、まだ「プログラマー」である現代のBPexeからは目立つでしょう。つまり、BPexeはプログラマ（ITサービス）ではなく、ビジネススペシャリストの標準ツールになります。

BPdocが同じ運命を待っていることを願っています。プロセス図を描く「ファッションデザイナー」（またはEPCコンサルタントを雇う）のスタッフは必要ありません。また、プロセスモデルは通常の規制から、場合によっては「見えないように」生成されます。



非常に遠い将来：自動的に-プロセス自体から、類推により：衛星画像（企業プロセスの「航空写真」）またはネットワーク検出（OpenView Network Node Managerなど）の地形図。少なくとも、コンサルタントについてよく知られているたとえ話（「羊の群れの近くにヘリコプターが着地する...」）のように、NASA衛星を介した羊のような企業プロセスの数を数える方法を学びます。



プロセスの形式化（BPdoc）にはさまざまなタスクがあります。グラフィカルな形式での個々の操作の些細な規制から、エンタープライズプロセスアーキテクチャの構築までです。 BPdocは、正式なプロセスの後続の自動化のために実行される場合があります。は、ビジネスプロセス自動化の最初の段階です（「BPA」と混同しないでください（「A」=分析）。強調されているように、プロセスの説明は、それが「自動化されたプロセス」であるか手動であるか、および「自動化されるかどうか」に関係なく、単独で存在します。



EPC（IDEFなど）で準備された「スキームによる自動化」（BPdoc）では、このアプローチは、自動化スキームがすでに実行可能なBPMN表記などで既に開発されている「1石で2羽のワンショット」（PBexe）のアプローチとは反対です。 .e。 「実行」。後者（BPMN）を支持するBPA（EPC）またはBPE（BP実行）の選択は、一見しただけでは明らかではありません。「ビジネス」（ITの外部の専門家）が実行可能な表記（BPMNなど）を認識することの難しさ、テクノロジー自体の欠陥（BPMSツール）。



BP-BP（ビジネスプロセス-ベストプラクティス）-これらはBPM CBOKなどの本ではなく、実用的なテンプレートとプロトタイプ（複製の例、詳細な説明を含む典型的なプロセスセットを含む）、特定の領域からの参照モデル、プロセス分類子（たとえば、 APQC PCFプロセス分類フレームワーク）など一般的に、これは、投機のパイプラインではなく、商品（サービス）の効率的な生産を構築する（すべき）基盤です。これは、BPMの未来（忘れられていた過去）についての別のグローバルディスカッショントピックです：グローバルBPM。



3.6関連概念



BPdoc、BPsim、BPexeの場合、多くの用語「プロセス[X]」、ここでX =

-モデル/リポジトリ＆デザイン/ドキュメンテーション（何らかの方法でプロセスを形式化し、どこかに配置する必要があります）。プロセスが将来のために開発されている（あるべき）か、既存のプロセスが（あるがままに）文書化されていることはそれほど重要ではありません。シリーズのプロセス理解と呼ばれることもあります-「プロセスを知る」（「クライアントを知る」と比較）;

-ポータル/パブリッシャー（プロセスの公開、コラボレーション、「プロセスの共有」など）。



BPdocの場合、階層マップまたはグラフィックで表現されるプロセスマップ/プロセスマッピングがよく使用されます。さらに、プロセスマップは、特定のメトリックが適用される「プロセスの基盤」として使用できます。 VAMデータを素材に適用すると、「プロセスカード」の背景にインジケーターのモザイクが表示されます。関連する名前は、プロセスダッシュボード、BIダッシュボード、プロセス測定などです。



BPana-多くのビジネスプロセス\パフォーマンスの改善、すべての「最も継続的な」改善とリエンジニアリングだけで「結合」できます。しかし、これはすでに「純粋なBPM」の範囲を超えています。



3.7船外の「純粋なBPM」



「槍を打ち破らない」ために：「それはBPMかどうか」、BPMextra（臨時、「臨時」）を別のカテゴリとして分離し、「純粋なBPM」（図3.3を参照）とBPexeの理解に入らないすべてを「マージ」します。

申請者の最初のセットは、「BPMのハイプサイクル」（「欺curve曲線

」）からの用語（ファッショナブルな「チップ」）の大部分であり、

2つ目は、IT（「テール」） -integrations」は、ビジネスプロセス管理システムの統合に焦点を当てたタイプ統合中心のBPM



BPextraカテゴリには、「戦略」（ビジネス戦略）、「管理管理」（「管理」、ガバナンス管理、プロセスガバナンス）、「追跡戦略」に関連するすべてのBPM環境が含まれます。ビジネスプロセスを含むビジネス開発の目標」、「管理するための企業ルール」。このサイクルの第2章の用語によると、これは「ビジネスアセトン」（BPM蒸留プロセスの「ヘッド」）です。



BPMからすべての「最も」進歩的なものをすべて取り込んでBPMとして受け入れることはできません。それをBPextraに含めることができます。カイゼン、総合品質管理（TQM、QMS）、リーンの「最も」リーンな製造、「オールシグマ」（シックスシグマ7シグマ、つまり+リーン）、およびビジネスプロセスの改善を含む、企業の特定のビジネスプロセスの文書化、規制、および標準化に基づいていない、普遍的な改善のためのその他の「完全な」技術。

「変革」、「改善」（最先端の「改善」）、「トヨタ」などの方法論の分類ビジネスプロセス管理（BPM）手法 。



プログレッシブおよび「like BPM」は、「most-most」と混合されています。

-ビジネス主導の開発。これは、ビジネスの要件を直接満たすITソリューションを開発する方法論です（明らかに、BDDの外部で作成された他のすべてのプログラムはこれを満たさないため、役に立たない）。



-x_BOK、特に「x」に切望されている「ビジネス」という単語が含まれる場合：

--BIZBOK（ビジネスアーキテクチャの知識体系のガイド）

BPMとEAの両方から多くのものがあることに注意してください。

--REBOK（Requirements Engineering Body of Knowledge）、要件エンジニアリング、同じビジネス戦略、ビジネスケース、ビジネスルール、ビジネスプロセスなどがあります。）

--BABOK iiba.ru/category/babok（ビジネス分析知識体系）、これも要件エンジニアリングですが、「要件を特定するための」ビジネス分析として位置付けられています）、ちなみに、BPMセクションを含む指定されたサイトのまともなライブラリ。



-サービス指向モデリング+「x」、ここで

「x」=「およびアーキテクチャ」、次にこれはSOMA、

「x」=「フレームワーク」、SOMF、サービス指向分析および設計（SOAD）、Service-指向モデリングサブオントロジー（SOMsO）およびもちろんBPMサブオントロジー（BPMsO）など、「Service-Oriented Computing ICSOC / ServiceWave 2009 Workshops」;



-そして、多くの、多くの類似したもの：時には、あらゆるテクノロジーが「多面的」（多面的）BPMの下にもたらされるように思われます。BPextra（「BPMのような」）にEAの世界から「建築写真」を割り当て、他のすべてはBPMに「正確で類似」していますが、それは「純粋なBPM」（Natural BPM）には含まれていません。BPextra自体をもう一度クリーンアップし、BPMレイヤーレイヤーの外側に既に表示されています。



あなた、

bipiem