ビジネスプロセスへの変更を導入するというトピックは、BPM専門家国際協会（ ABPMPロシア支部 ）のロシア支部にも届きました。この協会の会長であるBelaichuk氏による記事「How Change Management Begins」 。 より正確には、Belaichuk氏は彼のブログの読者と英語のリソースからの記事の翻訳を共有しました。
この記事は、ビジネスプロセスの変更の管理に関するものです。 主なアイデアは、「変更の管理をはるかに早く開始する必要があります。すでにBPIプロジェクトの最初の段階で、チャーターが開発されると、プロセスが識別され、モデル化されます」。 この記事の著者は、変更管理は体系的であるべきであることを明確にしており、組織の作業においては変更のみが永続的になる可能性があることを考慮しなければなりません。
さらに、この記事では、組織のプロセスの「確立された」作業に導入された変更の反復の各ターンで、組織で確実に発生する困難と、精神レベルでそれらに対処する方法について説明します。 「変化に直面している人々。」
国際協会のメンバーが正確にどのように BPM心理学者 申し訳ありませんが、BPM専門家はタスクを解決します。なぜなら、変更の実装に関連する問題を解決するための心理学的方法に加えて、残念ながらそうではない人が提案されたからです。
したがって、ビジネスプロセスの構造の変化に自発的または非自発的に直面する組織の従業員を慰めの代わりに提案し、ビジネスプロセスを混乱させないために、この状況に対するより技術的なアプローチを検討します。
アプローチの本質は次のとおりです。
実行中のインスタンスは、プロセスモデルの変更に自動的に適応します。
つまり、ビジネスプロセスのモデルに変更を加えるだけで十分です。その後、リラックスして、たとえば数年にわたってアクティブになる既存のインスタンスに新しい変更を組み込む方法について考える必要はありません。 結局のところ、彼らを完全に忘れるために彼らのライフサイクルの終わりを待つことには、欲求も機会もありません。
このアプローチを適応型ケース管理（ACM）と混同しないでください。
ACMは、これまでで最も柔軟なアプローチであり、起動された各インスタンスを個別に構成できます。
この記事のこのアプローチでは、定義済みのルールセットを備えた半構造化プロセスについて説明しますが、プロセス中に変更される可能性があります。
これらの変更は、変更を行う瞬間まで実行中のインスタンスにも自動的に適用されるため、特定の時間にグローバルなビジネスプロセスモデルの可用性が確保されます。
つまり、変更は新しいインスタンス（つまり、遅延変更）だけでなく、移行方法を使用するこのビジネスプロセスモデルのすべての実行中のインスタンス（つまり、緊急変更）にも適用されます。
出張者を返すプロセスをとる実例を考え、このプロセスのライフサイクルが10年であるという仮定を受け入れます（コピーの実行における緊急変更の利点をより明確に理解するため）。
バージョン1.0の「Return Travel」プロセスのモデル：
出張者の帰国申請書が記入された後、申請書はマネージャーによって処理されます。マネージャーは追加情報を直ちに承認、拒否、または要求できます。
決定に従って、プロセスの開始者に通知されます。 そして、出張の帰国または帰国の拒否の後、プロセスは終了します。
プロセスは開始され、特定の時点で、200ユーロを超える申請が部門長によって遡及的に承認されなければならないという通知が経営者から届くまで、それ自体の申請を静かに満たします。 つまり、この変更は、マネージャーによって送信された以前に起動されたアプリケーションにも適用されますが、経理部門は通常どおりこの点に達しておらず、旅行手当はまだ返却されていません。
これを行うには、必要な変更を考慮してプロセスの新しいバージョンが作成されます。この場合、別のUserTaskと1つのExclusiveGatewayを追加できます。
そして、プロセスの次のバージョンは次のようになります。
マネージャによるアプリケーションの承認後に新しいブランチが登場しました。 金額が200ユーロを超える場合、異なるアクセスレベルを持つ別の人の承認が必要です。
すべてがうまくいくようで、新しいプロセスモデルに従って新しいアプリケーションが起動されますが、疑問は残ります。すでに起動されたインスタンス、特にリターン額が200ユーロを超えるインスタンスについてはどうでしょうか。 ここでは、実行中のインスタンスのライフサイクルの終了は今後10年間には予想されず、モデル全体に分散した実行ステップを使用して、1,000を超える実行中のインスタンスで変更を行う必要があるという仮定も思い出します。
この場合、 最初の部分ですでに説明したように、プロセスの次のバージョンは、プロセスの隣接するバージョン間のトークンの「遷移」を示す、いわゆる「移行マップ」を介して前のバージョンに接続されます。
この例では、「移行マップ」は次のようになります。プロセスバージョン1.0で支払いが承認されたが、経理部門でまだ処理されていないアプリケーションは、「200ユーロ以上」の新しいブランチにリダイレクトされます。 金額が200ユーロを超える場合、当局による追加の承認が必要になります。 最初のバージョンと同様に、最大200ユーロの金額のアプリケーションは、追加の承認なしですぐにUserTaskの「払い戻し費用」に進みます。
トークンが任意のタイプのタスク間で移行するとき、またはユーザーがUserTaskの1つにアクセスすると、移行がアクティブになります。
この場合、ユーザーがUserTaskの「経費の払い戻し」を開こうとすると、実行中のインスタンスに適用する必要がある新しい要件が実装されます。 プロセス管理システム（CMS）は、プロセスの新しいバージョンが出現したことを判断し、「移行マップ」を調べます。 プロセスの名前、元のUserTaskの名前、およびプロセスの現在のインスタンスがどのバージョンで起動されたかを知るSOUPは、移行するプロセスのバージョンと、プロセスの新しいバージョンの要素の名前を決定します。
これらのパラメーターによると、バージョン間に「ジャンプ」があります。 ユーザーにとって、これは気付かれずに発生します。 プロセスの新しいバージョンでの移行後に、特定のユーザーが新しい要素へのアクセス権を持っていない場合、プロセスのバージョンが変更され、要求されたUserTaskが利用できないことを示す対応するメッセージが表示されます。
残りのタスクの移行は、構造的な変更なしで行われます。 同じタスクで、ただしプロセスの更新バージョンで既に。
要約すると、使用されるBPNM要素の数が増えると、プロセス自体の柔軟性が低下すると言えます。
この問題を解決し、プロセスの十分な柔軟性と適応性を提供するために、モデリングは2つの抽象レベルで行われます（ パート2 ）。 上位レベルでは、対象プロセスについて説明します。 下位レベルは技術的であり、上位レベルのサブプロセスを説明しています。
プロセスモデリングの黄金律：主題レベルを簡素化し、複雑なものをすべて技術レベルに移行します。
みなさんに、シンプルで理解しやすい、簡単なモデリングをお願いします！