不同场景的引入策略差异：替换旧产品、SOA环境、事件驱动架构、战略驱动

[[成功采用过程的通用模式POC试点灯塔规模化四阶段]]描述的是通用模式，但具体细节要因组织现状和引入的主要驱动因素而调整。更换现有工作流产品：组织已经理解流程自动化概念、团队已有建模经验，整个过程会更轻松，但要警惕不同人对流程自动化理解不一致带来的争论，还需要专门证明”迁移到新工具”（而非”要不要用流程自动化”）的合理性，并调查旧工具问题的真正根源——有时问题不在工具本身，而在于错误的使用方式（用来解决错误的问题、建立了奇怪的架构模式），这种情况下要避免新工具重蹈覆辙，可能需要人们重新学习工作方式、承认过去的错误。在SOA环境中引入：如果公司对现有SOA架构基本满意并打算继续维护，不必为了用流程自动化而切换到微服务，但要警惕过于集中式的流程自动化方案，即便它运行良好也很符合组织文化。在事件驱动架构中引入：如果公司已经采用事件驱动微服务、正面临服务数量难以管理和大量涌现行为的困扰，采用路径可以完全不同——可以先从纯粹获取可见性入手，创建一个流程模型只追踪事件、不主动做任何操作（不推动、只记录），这样就能用上工作流引擎完整的工具链（监控、SLA检查、停滞实例排查、历史数据大规模分析）而无需大改；这个”追踪模型”可以成为引入更多编排的第一步，比如先只监控端到端超时（14天通知用户延迟但继续等，21天放弃并取消订单），再逐步演化为真正接管订单履约职责的流程，例如先从编排支付开始、删掉这部分对应的事件链——很多现代化项目的开端正是这种从遗留系统”追踪流程”起步、逐步移除底层连接并被编排取代的路径。推动流程自动化的战略举措（如数字化转型项目）：这类项目自带预算，是引入流程自动化的好机会，但同样要遵循从小事做起、从满足具体业务需求做起的原则，否则很容易沦为DontDoItAtHome那样的结局——作者甚至见过很多成功项目刻意避免进入战略计划的视野，就是为了避免被这类计划的节奏和干扰打乱正常推进。