歴史的に、システムアナリストは手動の手法を使用してきました — 観察、インタビュー、既存文書の分析など。ITの発展に伴い、現在のプロセスと将来のプロセスのモデル化に対するアプローチを構造化する基準（例えば、BPMN、IDEF0、EPC）が登場しました。
問題：アプローチの選択は、不完全な情報、時間、専門領域の複雑さ、ビジネスプロセスの成熟度の違いによって複雑になることが多いです。この段階での誤りは、要件の誤った記述や大規模な再作業、アナリストの役割に対する信頼の喪失を引き起こします。
解決策：最適なアプローチは、定量的および定性的な手法を組み合わせることです：
主な特徴：
すべてのプロセス、技術プロセスや複雑な統合プロセスを含めて、BPMNを常に使用できますか？
BPMNは、明示的なロジックを持つビジネスプロセスや手順にのみ適しています。技術的なまたは深く統合されたシナリオは、シーケンス図（UML）、アーキテクチャダイアグラム、または専門的な記法を使用して説明するのが最適です。
ビジネスグループの1人の代表者とインタビューを行うだけで、現行プロセスの正確な状況を把握できますか？
いいえ、1つの情報源では全体の状況を反映することはありません。実行者、ユーザー、IT部門、マネージャーなど、異なる役割からのバージョンを集める必要があります。これにより、誤りのリスクを最小限に抑え、プロセスの隠れた結末を特定できます。
ITソリューションを設計する前に、将来のプロセス 'to-be' をすべてのビジネスオペレーションの詳細まで計画する必要がありますか？
必ずしもそうではありません。過度の詳細化は官僚主義と柔軟性の喪失を引き起こします。主要なシナリオ、自動化のポイント、必要な役割と統合の変更を合意するだけで十分であり、詳細は実施中のイテレーションで検討します。
ネガティブケース： アナリストは、ルールに基づいてプロセスマップを構築し、実行者のルーチンな迂回や「迂回」シナリオを分析しませんでした。
長所：
短所：
ポジティブケース： アナリストはワークショップを開催し、インタビューを行い、現在の状態と目標状態を形式化し、違いを示しました。実際のシナリオの例とその問題を含め、ステークホルダーのフィードバックを考慮しました。
長所：
短所：