回答

歴史的に、システムアナリストはしばしば企業のビジネスプロセスの深い分析から仕事を始めていました。これにより、情報システムがどこでどのように組織の活動を自動化または最適化できるかを理解することができました。しかし、ビジネスプロセスの分析と技術的設計の境界がしばしば混ざり合うことがあります。

主な特徴:

• ビジネスプロセスの説明はITツールによる実装の詳細を考慮せずに、組織の活動をシステムとして特定し形式化することに焦点を当てています。
• 情報システムの設計は要件が形成された後に始まり、アーキテクチャ、インターフェース、統合、データフォーマットの検討を含みます。
• これらの段階を明確に分けることが重要です：最初にアナリストが「何をするか」を特定し、その後「どのようにするか」を考えます。

この問題の歴史

以前は、これらの段階の境界がより明確でした：ビジネスアナリストはプロセスのモデリングを担当し、システムアナリストは要件を技術的な仕様に変換していました。現代の実務では、タスクがしばしば混ざり合います。

問題

多くのアナリストは、プロセスの完全な分析を行う前にシステムの設計を始め、これが要件の誤った特定や過剰な技術的詳細に繋がります。

解決策

ビジネス分野の分析と設計を明確に分け、プロセスにはBPMNやEPCを使用し、設計にはUML、データフロー図（DFD）などを使用します。

騙しの質問。

ビジネスプロセスを分析することとシステムを設計すること、どちらが重要ですか？

どちらか一方を選ぶことはできません：プロセスの分析は正しい要件を導き出すために必要で、設計はそれらを実現するために必要です。これは連続した段階です。

同じ図をプロセスの説明とシステムの設計に使用できますか？

いいえ、BPMN/EPCはプロセスに適用され、UML/DFDは構造的またはオブジェクト指向の分析と設計に使用されます。

ビジネスプロセスをモデル化しなくてもよい場合はどのような時ですか？

プロジェクトが小さく、すでに文書や標準で完全に形式化されている場合のみです。ほとんどの場合、モデル化が必要です。

一般的なエラーとアンチパターン

• ビジネスの課題を理解しないまま、データスキーマに詳細に早期に移行する。
• プロセスの説明と技術的解決策を混同する。
• 最終ユーザーの利益を無視する。

実生活の例

ネガティブケース:
アナリストは、従業員がどのように働いているか、何が必要かを学ぶことなく、データベースとサービスのスキームをすぐに描き始めました。
利点: 迅速な実装で、すべてが第1バージョンに満足しました。
欠点: システムは実際の問題を解決せず、ユーザーは不満を持ち、改修が必要になりました。

ポジティブケース:
アナリストはまず従業員とのインタビューを行い、BPMNを構築し、その後APIとデータベースの設計に進みました。
利点: 要件が明確で、システムが実際のプロセスをカバーしています。
欠点: プロジェクトの開始が遅く、分析にかかるコストが高くなります。