回答。

質問の背景:

ビジネスプロセスの自動化の初期段階では、顧客が重要なビジネスルールを完全に理解していないか、正式に文書化されていないルールの一部を見逃していることがしばしば明らかになりました。このようなルールが明確に記録されていないと、論理的なエラーや予測不可能な状況、ビジネスとIT間の争いを引き起こすことになります。

問題:

隠れたまたは暗黙のビジネスルールは特定が難しいです。それらは経験豊富な従業員だけが知っている場合があり、書類にのみ記録されているか、まったく文書化されていないこともあります。これはバグや対立のリスクを増大させ、製品のテストや導入を難しくします。

解決策:

システムアナリストは次のことを行います：

• キーユーザーや専門家とのインタビュー
• インシデントや不測の事態の分析
• 関連プロセスの規程、メッセージと通信のアーカイブの調査
• ケースモデリングとBPMN/UMLダイアグラムの作成を通じてギャップを特定

ルールを収集した後、アナリストはビジネスルールのテンプレート、意思決定マトリックス、状態と条件のダイアグラムを用いてそれらを形式化します。要求の変更に応じて文書を常に最新の状態に保ちます。

主な特徴:

• 特定されたルールの妥当性確認のための専門家の積極的な関与
• 説明のテンプレート形式（例：意思決定テーブル）の使用
• すべてのビジネスルールを顧客と調整し、承認を得る

おとりの質問。

顧客が初めに言及するすべてのルールが網羅的であると考えてよいか？

いいえ、多くの場合、重要な情報の一部が隠れていたり、自明だと考えられたりします。深堀り分析と追加の検討が必要です。

特定の従業員だけが知っているルールをプロジェクトに取り入れる必要があるか？

いいえ、それらのルールがビジネス側に承認され、戦略的目標と矛盾しない限り、取り入れる必要はありません。さもなければ矛盾の原因になる可能性があります。

ビジネスルールを技術文書に単に文書化するだけで十分か？

いいえ、専門家とのバリデート、例外の説明、表現の調整、テスト文書への導入も必要です。

一般的なミスとアンチパターン

• 見逃されたまたは誤解されたルールは再作業を引き起こす
• ユーザースクリプトに結びつけられていないビジネスルールの過度の技術的説明
• ビジネス顧客による文書の承認が欠如している

実生活の例

ネガティブケース: アナリストは顧客の口からビジネスルールを確認し、補足の質問やエキスパートユーザーからのフィードバックを取得せずに記録しました。生産環境では考慮されていない例外（特定の支払いケースなど）に直面しました。 プラス:

• 分析文書の迅速な準備 マイナス:
• 大量のバグ、緊急の再作業

ポジティブケース: アナリストはエキスパートユーザーとのセッションを行い、すべてのケースに対して意思決定テーブルを使用し、最終的な表現を複数のステークホルダーと同期しました。 プラス:

• シナリオの完全なカバー
• 導入時の対立の最小化 マイナス:
• 準備と調整に高い時間コスト