ワークフロー — リクエストから記録された結果まで

ワークフローは、Request → Prepare → Approve → Execute → Prove という意思決定サイクル全体を所有します。承認はプロセスの終わりではありません。これにより、次に設定されたアクションが開始され、その結果も記録する必要があります。作業項目は、ルート内での参加者の割り当てです。文書には正確な証拠が保存されます。タイムラインは、リクエスト、承認された決定、結果を結び付けます。

プロセスを完了する

1. 会社のワークスペースにサインインし、許可された開始アクションを開きます。
2. 利用可能なプロセスを選択します。サーバーによって提供される会社とオブジェクトのコンテキストを確認します。
3. 要求された事実と書類を提供し、一度提出してください。応答が遅い後に複製を作成するのではなく、開始されたプロセスに従ってください。
4. 割り当てられた参加者は、作業項目を開き、リクエストと証拠を確認し、許可された決定またはアクションを使用します。
5. 訂正が要求された場合、要求者は返送経路をたどり、修正された証拠を提出します。
6. 成功したビジネス アクションは、ワークフローの移行とともに記録されます。どちらの参加者も、スコープで許可されている結果を検査できます。

正確なアクション ラベルとルートは、選択したプロセスに属します。承認は、その後のすべてのステップがすでに成功しているという一般的な約束ではありません。

道が変わるとき

キャンセルはプロセスポリシーに従います。すでに適用されているビジネスアクションには、リンクされた補償プロセスが必要になる場合があります。再試行では、既存のプロセスとその許可された回復コマンドが使用されます。参加者、証拠、権限、容量、または依存関係が欠落していると、対処可能な障害として現れます。隠しボタンはアクセス制御メカニズムではありません。

会社、オブジェクト、または親の選択を変更すると、依存する選択が無効になる場合があります。送信する前に、再計算されたオプションを確認してください。許可されたオプションがない場合は、会社の管理者に割り当てまたは構成を修正するように依頼してください。

管理

Railbase Studio は、サポートされている企業プロセス構成を管理します。インストール作業は、別途認可されたシステム ワークフローを使用します。導入オペレータは、サーバーを管理するだけでは会社の決定権限を受け取りません。

最初の業務プロセスの受入確認

要求者アカウントとレビュー者アカウントを別々に使用します。送信、返却、再送信、決定、キャンセル、アクセスの拒否、および回復を確認します。役割、アクション、目に見える結果、持続的なビジネス成果を記録します。ページの読み込みが完了しただけでは、プロセスが機能していることは証明されません。