ビジネスプロセス （BP）の自動化について多くのことが書かれています 。 文献やインターネットでは、ビジネスプロセス管理（BPM）とワークフロー管理システム（WMS）を使用して日常の日常的なプロセスを自動化する利点について詳しく説明されています。
この記事の目的は、「自動化」という言葉が何を意味するのかをさらに検討し、プロセスモデルの要件の増加がシステム自体の複雑さの増加にどうしてつながるのか、およびその対処方法を検討することです。
記事の冒頭で、BPの変化に対する耐性の程度に応じたBPの分類の理論的基礎に焦点を当て、BPのモデリングの技術的側面に触れます。
記事の途中で、「複雑さ」と「複雑さ」という響きの概念を使用しますが、意味の意味は異なりますが、システムが複雑な理由を説明します。
記事の最後に、適応型BPモデリングの例を使用して、複雑性との闘いの具体例を示します。
したがって、何が問題なのかを完全に明確にするために、変化に対する抵抗の程度に応じてBPを分類します。
図1：変更に対するBPの回復力の程度 [source Vos 1997、S. 40]
図1は、構造化プロセスが従来のWMSとBPMによって効果的にサポートされているのに対し、半構造化プロセスとコラボレーションプロセスにはより柔軟なITソリューションが必要であることを示しています。
理解すべき主なことは、リストされたクラスのそれぞれが、BPのモデリングに独自のアプローチを使用する必要があるということです。 レンチでネジをねじることはできず、ドライバーでナットを締めてみてください。
次に、BPのモデリングで最も一般的な技術的概念、つまり、 ナットとネジを締めるためのツールは、ボックスで利用可能です。
図2：技術的概念[ソースAalst ua 2005、S。158]
混乱を避けるために、各概念の基本的な考え方を説明します。
-EAI-バスの原理に基づいたシステム。 システムは、他のサービスにアクセスするためにのみバスに接続する必要があります。
-SOAは、OASIS標準に準拠したインターフェースを持つサービスです。 これにより、サービス間の通信が簡単になります。
- ケース管理またはアダプティブケース管理（ACM） -予測不可能なシナリオをサポートします。 これらのシステムは、繰り返しのないユニークなビジネスシナリオに効果的です。
- アドホックワークフロー -ワークフローをオンザフライで変更する機能が組み込まれているモデルのプロセス（既に実行中のプロセスのインスタンスにも）。
- グループウェア -共通の問題を解決するために一緒に働く人々の間の相互作用をサポートするソフトウェア。
現在、ビジネスプロセスの種類と考えられる技術的アプローチのアイデアがあれば、特定のタイプのビジネスプロセスに適したソリューションを見つけるのは簡単です（ドライバーはまだネジ用で、キーはナットに適しています）。
カテゴリとツールは多かれ少なかれ理解されているため、外部要因に対処する必要があります。 彼らはすべてを正しく行ったようです-ドライバーでネジを締め、レンチでナットを締めますが、何かがまだ「きつく」なります。 たぶん、ネジをコンクリートにねじ込むか、ドライバーのスクロールをします。
一部のプロセスが簡単で、他のプロセスのモデル化と実装が難しいのはなぜですか
「...プロセスにはさまざまな要件があるため、プロセスの機能に対する要件が増えると、その複雑さも増大します。」
まず、「 complex 」（Eng。Complicated; German。Kompliziert、Kompliziertheit）と「 Complexity 」（Eng。Complex; German。Komplex、Komplexität）の2つの概念を分離する必要があります。 非常に多くの場合、これらの2つの用語は同じものと解釈されますが、それらには意味上の大きな違いがあります。
システムは「 複雑 」です。システムを小さなコンポーネントに分割したり、逆に小さなコンポーネントからシステムを組み立てたりするのが難しいが、システムの最終的な機能は予測可能です。
システムが複雑な例：車の個々のコンポーネントにより、路上での挙動を予測できます（最高速度、タキシング感度など）。 原則として、複雑さを技術的に可能な単純なコンポーネントに区切る戦術について話します。
「 複雑さ 」の概念は、既知のコンポーネントでは最終結果が予測できない場合のシステムの状態です。
「複雑さ」の例は、フットボールまたはオーケストラです。 サッカーでは、プレーヤーと戦術のすべての既知のパラメーターを使用して、ゲームの結果を予測することは不可能です。 オーケストラのように、結果は多くの外部コンポーネントにも依存します。 したがって、たとえば、オーケストラの音はミュージシャンのスコアやスキルに直接依存せず、室内音響、音の電気増幅、観客自体、さらには視覚などの要素がここに追加されます。
言い換えれば：
システム（ビジネス、プロジェクト-コンテキストに依存しない）が複雑さを引き起こす場合、それを克服するには、新しい知識を理解する必要があります（再考、受け入れ、観測点の変更、自分自身の変更）。
システム（ビジネス、プロジェクト-コンテキストに依存しない）が複雑な場合、既存の知識を使って努力する必要があります。
上記から、プロジェクトマネージャーの興味深い言葉遣いは次のとおりです。
システムの複雑化により複雑なシステムになり、その後の技術的に可能な小さなコンポーネントへの分解。
しかし、これはこの記事の別のトピックです。 メイントピックに戻り、新しい知識を考慮に入れて、ビジネスプロセスモデルの自動化における複雑さの困難なタスクへの変換を開始します。
考えた後、暗黙的な構造のPSUモデルに焦点を当て、新しい要件に応じてPSUモデルをいつでも変更できるようにします。
この項目は、PSUの寿命がBPモデルのリリース期間である場合に重要です。 つまり、BPインスタンスを再起動することなく、このビジネスプロセスの進化をオンザフライでサポートする機会があります。
このようなBPモデルの例は、銀行でローンを返済するプロセスです。 多くの場合、ローンの返済期間はそれぞれ約10〜30年であり、BPの実行中のインスタンスの平均寿命は数十年です。 この期間中は、変更を避けることはできません。よく考え抜かれたPSUでさえ、今後数年間、この場合は数十年間、すべての外部要因を考慮することはできません。
図によると 2アドホックワークフローの原則を使用します。 この原則は、初期PSUモデルが既知であり、実行中のすべてのPSUインスタンスと後続のすべてのPSUインスタンスに後続の変更が適用されるタスクに適しています。
アドホックプロセスに提示される進化の基本的なルールを定式化します。
- BPインスタンスは常に最新バージョンでのみ起動し、古いバージョンのBPを実行することはできません（これにより、プロセスがデッドロック状態になるのを防ぎます）。
- 同じPSUの複数のバージョンが並行して存在する可能性
- 新しいバージョンへの移行を禁止することができます。そのため、当局は最初のワークフローを完了することができます。
これで、BPモデルを変更する構造例に進むことができます。 BPモデルを変更するときの2つの最も一般的なシナリオは次のとおりです。
- モデルに新しいタスクを追加する
- モデルから既存のタスクを削除する
新しいタスクを追加する
タスク3をPSUモデルに追加する必要があります。
モデルに新しいタスクを埋め込む原理を次の図に示します。 この場合、バージョン1のトークンはバージョン2の対応するタスクに移動されます。BPの2番目のバージョンでは、タスク1のトークンはブランチに分類され、その後標準のBP実行シナリオに従います。 タスク2の後、前のバージョンのPSUと同様に、プロセスは終了します。
点線は、BPバージョン間のトークンの移動を示しています。
既存のタスクの削除
PSUモデルからタスク2を削除する必要があります。 アンインストールは3つのステップで行われ、バージョン2は中間、最終バージョンはバージョン3です。
ステップ1：トークンはバージョン1からバージョン2に移動されます。2番目のバージョンでは、タスク2は新しい権限で使用できなくなりました。 バージョン1から起動され、既にタスク2の実行を開始しているインスタンスは、その実行を終了します。
ステップ2：バージョン2では、バージョン1のインスタンスが開始されなくなり、バージョン1からタスク2へのトークンのフローが停止するため、タスク2は徐々に停止します（BP進化の2番目のルール）。
ステップ3：タスク2の完全な「枯れ」後、バージョン3が追加されます。これは、タスク2なしですでに最終的なものであり、確実に必要なくなりました。
（破線は、BPバージョン間のトークンの移動を示します）。
この記事では、BPモデルの変更を伴う「複雑さ」から、適応型BPをオンザフライでモデリングする困難なタスクへの移行について検討しました。
ビジネスプロセスの変更に関する2つの主要なシナリオも検討されました。これらのシナリオは、現在のプロトタイプの例で実証されますが、次のパートで説明します。
著者がBPモデルへの変更を実装する際の技術的な問題について説明しているsshikovの記事「 BPMについて知りたいが、尋ねるのが怖かったすべて 」も役立つ可能性があります。
時間があれば、コメント、追加、記事のアイデアに対する批判に答えようとします。
ご清聴ありがとうございました！