答案。

从历史角度来看，系统分析师使用手动方法——观察、访谈、分析现有文档。随着信息技术的发展，出现了一些标准（例如BPMN、IDEF0、EPC），这些标准结构化了对当前和未来过程建模的方法。

问题：选择方法通常因信息不完整、时间紧迫、领域复杂性和业务过程成熟度各异而复杂化。这一阶段的错误会导致需求描述不准确、重大返工以及对分析师角色的信任丧失。

解决方案：最佳方法是结合定量和定性方法：

• 通过观察分析文档和实际行为。
• 根据任务将过程形式化为BPMN或IDEF0符号。
• 对于“as-is”——收集执行者的反馈，举办研讨会。
• 对于“to-be”——与客户进行建模，提前记录预期结果和成功标准。
• 进行差距分析，识别缺口和风险。

关键特点：

• 同时应用多种技术。
• 记录事件和备选场景。
• 通过演示和短期迭代不断验证数据。

误导性问题。

可以始终使用BPMN描述所有流程，包括技术和复杂集成吗？

BPMN只适用于具有明确逻辑的业务过程或程序。技术性或深度集成的场景最好用序列图（UML）、架构图或专用符号描述。

仅与一个业务小组代表进行访谈就能获得当前流程的真实情况吗？

不，一个来源永远无法反映全貌。需要收集来自不同角色的版本：执行者、用户、IT服务、经理。这可以最小化错误风险并发现隐藏的过程结尾。

是否需要在设计IT解决方案之前，详细绘制“to-be”未来过程的每个业务操作？

不一定。过度详细会导致官僚主义和失去灵活性。只需协商关键场景、自动化点、所需角色和集成的变化，细节可在实施过程中迭代处理。

常见错误和反模式

• 仅基于理论描述流程，而不分析真实业务场景
• 忽视过程执行的隐性或隐秘路径
• 过度详细或过于笼统的框图

生活中的例子

负面案例： 分析师仅根据规定构建流程图，未分析日常绕行和执行者的“旁路”图。

优点：

• 文件迅速达成一致

缺点：

• 缺乏实际效用和对真实问题的理解
• IT解决方案在实际应用中表现不佳，需要调整

积极案例： 分析师进行了研讨会、访谈，形式化了现状和目标状态，展示了差异。包括了真实场景及其问题的示例，考虑了利益相关者的反馈。

优点：

• 深刻理解问题，透明的“to-be”过渡
• 最小化返工和回退

缺点：

• 需要更多时间和方法论准备