自動化には副作用の制御が必要です
ワークフローは複数のシステムにまたがって変更を引き起こすことがあります。手順3が失敗した場合、最初の2つの手順で行われた変更を放置してはなりません。再試行、補償アクション、手動での確認をあらかじめ計画します。技術的なサービスアカウントには限定された権限のみを付与します。承認は実際の案件に紐づけ、事後の変更が古い承認のまま処理され続けないようにします。また、新しいプロセスバージョンには、すでに開始されている案件を扱うためのルールが必要です。
プロセス自動化
申請、承認、引き継ぎが、受信トレイの中に埋もれてしまってはいけません。貴社の業務フローを、デジタルフォーム、タスク、システムステップへと落とし込みます。例外処理、代理対応、エスカレーションも、通常の流れと同じように設計します。

OTOKO®へのご依頼内容
誰が申請でき、誰が決定を下し、問い合わせがあった場合には何が起きるのか。最速の流れだけでなく、却下、代理対応、期限切れ、中止についてもモデル化します。人による判断と、自動化可能な確認ステップは分離します。BPMNモデルは合意形成を支援できますが、それを実行可能な形でどう実装するかはプラットフォームによって異なります。既存のツールと新しいソリューションを、処理時間、統合の必要性、保守性の観点から比較します。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
ワークフローは複数のシステムにまたがって変更を引き起こすことがあります。手順3が失敗した場合、最初の2つの手順で行われた変更を放置してはなりません。再試行、補償アクション、手動での確認をあらかじめ計画します。技術的なサービスアカウントには限定された権限のみを付与します。承認は実際の案件に紐づけ、事後の変更が古い承認のまま処理され続けないようにします。また、新しいプロセスバージョンには、すでに開始されている案件を扱うためのルールが必要です。
検収では、業務担当者とともに通常のケースと選定した例外パターンを確認します。プロセスモデル、設定、未完了または失敗した案件への対応手順を引き渡します。指標は待ち時間とボトルネックを示しますが、成功した部分タスクを完全に完了したプロセスと混同することはありません。開始にあたっては、典型的な申請、承認ルール、関係するシステムの情報が必要です。

検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
最初の一歩の前に
プラットフォームによっては、設定だけで多くのことが可能です。ただし、インターフェース、エラーケース、安全な権限設定については、技術的な計画と検証が別途必要です。
これは明示的に定めます。従来のバージョンのまま完了させることも、制御された形で移行することも可能です。判断ルールが気づかれないまま切り替わることのないようにします。