最佳实践 (BPM) - 队列

2006年3月29日
第4卷，第2期

最佳实践 BPM

在业务流程管理中，找到合适的工具套件仅仅是开始。

DEREK MIERS, ENIX

正如 BPM（业务流程管理）技术与传统的应用程序支持方法截然不同一样，BPM 开发的方法论也与传统的软件实施技术截然不同。以 CPI（持续流程改进）作为 BPM 的核心学科，驱动公司工作的模型不断演变。事实上，最近的研究表明，公司至少每季度对其基于 BPM 的应用程序进行微调（有时甚至每年八次）。关键在于，不存在“完成”的流程；需要多次迭代才能产生高效的解决方案。每个正在运行的基于 BPM 的流程都只是未来的起点。此外，由于有多个流程可以从 BPM 风格的自动化支持中受益，问题就变成了如何每年支持数十甚至数百个项目。

随着变化的间隔越来越短，公司需要开发有效的方法，以便足够快地完成业务优化周期。

图 1 描述了一种组织活动并确保项目步入正轨的方法。该方法论涉及许多较小的迭代，每个迭代都专注于特定主题，并在其中进行“回放”会议，BPM 团队、主题 matter 专家和业务经理在会议中交互式地验证新开发的功能。这种方法确保在整个过程中不会出现意外，同时提供根据需要进行更改的灵活性。在需求领域（发现和理解）、设计阶段、构建和测试等阶段都有迭代。此外，管理者需要监控流程并控制其运行方式。在重复周期之前，“分析和优化”阶段涉及业务分析师和经理对替代方案进行实验的几个额外迭代。

鉴于每年有四到五个业务优化周期，每个整体周期必须在三个月内完成。为了实现这一目标，有必要对活动的不同阶段进行时间框定。否则，总是存在花费更多时间的诱惑，这会鼓励范围蔓延并增加项目失败的风险。

流程发现与理解

每个组织都有不同的起点，因此需求也不同。有些组织已经定义了流程；另一些组织则发展不足。有些组织希望强调流程的自动化，而另一些组织则需要更好的可追溯性、可见性和绩效衡量。无论哪种方式，首要目标都是理解流程。组织不应开发一份 400 页的需求文档，其中详细规定了每个细节，而应专注于确定将带来最大价值的核心功能。

始终需要捕获现状流程。基本要求是能够跳出流程并充分理解它。关键的主角需要能够让他们彼此有效沟通的模型。其次，这些模型将构成支撑基线指标捕获的底层结构。收集参考指标以确保团队稍后能够证明绩效改进非常重要。

为了充分理解流程，有必要从多个不同的互补角度对流程进行高层次建模。使用一套互补的建模技术评估业务状况，可以使人们更好地理解流程的基本原理。此阶段的理想技术是

流程图，用于查看活动顺序，使用 BPMN（业务流程建模符号）。
角色活动图，用于关注角色互动以及各个参与者的期望行为。
对象状态转换网络模型，用于关注在流程中移动的事物如何改变状态。
能力模型，用于将流程视为一组可重用的业务组件。一个能力可能由其他能力组成，或者通过程序（BPMN 风格模型）来实现。

这里的重点是理解流程，而不是构建用于转换为代码或可执行流程定义的模型。这使得业务分析师和业务用户都能够跳出日常业务视图，以不同的方式看待流程。

如果能够适当访问主题 matter 专家，一个好的经验法则是，此阶段的活动应在一到两周内完成。尽管这听起来可能具有挑战性，但完全可行。诀窍是确保模型处于适当的高层次。团队应始终牢记建模的目的和目标受众。模型应足够详细，以推动理解和讨论，但其详细程度不应超过支持此目的的必要程度。

从设计到部署

全面的 BPM 套件对于支撑目标流程支持的应用程序是必要的。BPM 套件提供了一个可配置的平台，该平台执行程序模型，将工作交付给相关的员工或合作伙伴（甚至客户）。它确保了单个工作案例的可追溯性并保证了合规性。现代 BPM 套件包括集成的流程建模和业务规则环境、集成设施、复杂的用户界面功能和强大的分析功能。

在开发实际的 BPM 支持的应用程序本身时，BPM 团队会发现，如果他们对前一阶段提供的流程有深入的了解，则更容易获得清晰的认识。团队不应尝试定义最终功能的 80% 到 90%，而应从确定更适度的目标开始，即交付绝大部分价值的 20% 到 40% 左右。

然而，流程只是开发和实施阶段需要工作的一个领域。有重点的努力对于确保与第三方应用程序的有效集成至关重要。同样，用户界面也需要特别关注，指标收集和为管理者提供的控制功能机制也需要特别关注。

团队不应尝试同时解决所有问题，而应在着手下一个方面之前，专注于开发的一个方面。他们可以为每个方面创建单独的工作子阶段

• 流程流。 在初始迭代中，目标是就将交付大部分价值的核心 20% 到 40% 的功能达成一致。尽管在查看现状模型时进行了相当多的建模工作，但这项工作完全是为了创建未来流程。尽管组织变更可能被视为部署问题，但将活动分配给组和角色的方式也很重要。

• 集成。 此子阶段直接关注从外部应用程序提取和更新信息/到外部应用程序的信息。与此子阶段相关的是流程数据的设计。同样，确保数据模型与现状模型分开开发，可以确保团队成员设计和支持必要的内容，而不是想当然地认为已经存在的内容是必要的。可交付成果应侧重于向用户社区证明必要的数据可以放置在默认用户界面上（即，不要尝试自定义用户界面）。

• 用户界面。 确保屏幕提供流程中涉及的各种角色所需的信息。

• 指标。 探索被认为必要的管理信息、如何收集这些数据、谁应该有权访问这些数据以及如何呈现这些数据。BPM 套件应捕获所有必要的信息，通常称为 KPI（关键绩效指标）。值得注意的是，用于跟踪流程效率和有效性的指标可能与用于维护流程状态的数据显着不同。

• 控制。 业务经理希望有一种方法来限制流程的性能，从而使他们能够控制流程执行。他们需要一些机制来帮助他们应对需求的峰值和低谷，或影响业务规则的应用方式。

重要的是要分离开发的这些部分，因为这将使团队中的专业资源能够集中精力。根据具体情况，这些子阶段的顺序可能会发生变化。例如，如果从第三方应用程序提取数据将带来最大的困难，那么此子阶段可能应该首先运行。当然，在许多项目中，各个子阶段可能会根据其特定专家和经理的反馈进行迭代。

此外，每个子阶段都允许团队向业务领域的主题 matter 专家和经理展示结果。在共享模型方法的支持下，这些交互式回放会议确保用户可以看到所请求的已实现功能。此外，由于输出是图形化的，因此参与者可以快速浏览自上次迭代以来所做的更改。

BPM 套件的功能应确保项目团队参与者可以从同一工具集、在同一上下文中直接访问所有相关事件、规则、用户界面、流程流、代码和分析。产品不应强迫应用程序开发人员和分析师切换工具或上下文来查看流程中正在发生的事情。

监控与控制

系统支持有效业务监控和控制的能力源于有效的设计和部署阶段。本节讨论交付的功能类型。有几个角度很重要，包括仪表板、警报和升级机制、控制回路以及人员管理。

• 仪表板风格的用户界面为经理和主管提供适当的指标。假设是，只要管理者能够充分了解系统中的工作，他们就会在必要时进行干预以加快工作项目的进度。当然，系统本身可以通过提供使管理者能够检查工作项目、重新分配该项目或直接与负责的员工进行交互的机制来帮助促进这一点。此外，系统可以直接提示各个用户，使其注意那些有超出任何里程碑或 SLA（服务级别协议）风险的工作项目。

• 监控和控制机制还应使适当授权的经理能够指导流程的整体运行。当大多数供应商谈论 BPM 和持续流程改进时，他们都在讨论更大、更全面的业务优化循环。他们未能理解二级优化循环的重要性，在二级优化循环中，具有适当资质的业务经理直接控制正在运行的流程。通常，这是一个设计问题。应用程序应具有内置功能，为管理者提供他们需要的控件，以限制业务绩效。（有关示例，请参阅 Pulte Mortgage 侧边栏。）

分析与优化

分析和优化通常是业务分析师或流程所有者的责任。这些人员以临时的方式寻找问题并为应用程序的下一个版本提出更改建议。他们正在查看整体业务流程、其历史绩效以及相关的业务数据，目的是找到提高绩效的方法。

当然，KBO 应该驱动绩效优化。对于大多数公司而言，向流程添加更多人员（资源）以提高绩效根本不是一种选择。最好的 BPM 产品提供了测试替代方案（而不仅仅是在瓶颈处添加资源）的机制。

模拟

为了响应这种需求，大多数供应商都专注于提供模拟工具，用于比较不同的假设情景。模拟的核心是一种统计技术，它使用概率来预测平均活动持续时间、队列长度、资源利用率等。

然而，模拟的使用应该附带一些健康警告。当模拟用作测试假设的一种方式时，它是最有效的。例如，如果利率下降，导致抵押贷款申请增加，那么这对公司提供相同水平客户服务的能力有何影响？在什么情况下需要额外资源？但是，模拟模型非常难以构建，模型中的每个链接都需要仔细的统计检查。在侧边栏中的 Pulte Mortgage 示例中，这可能意味着检查利率与抵押贷款申请数量之间的敏感性。解决此问题需要收集历史数据来支持此测试。当今可用的最佳 BPM 模拟工具从正在运行的流程模型中提取此数据，以提供基线信息。这极大地改变了与模拟相关的成本/收益比。

优化

一流的 BPM 套件具有优化机制，可提供自动化支持，以帮助确定流程改进的最佳方法。这使模拟更进一步，解决了模拟的一些固有困难。系统不应将确定改进方案的任务留给分析师，而应帮助识别需要考虑的领域。此外，通常难以以对业务有意义的方式比较不同的模拟情景。

例如，业务经理通常最感兴趣的是评估特定产品或服务的有效性。仅仅知道所有贷款的平均周期时间是不够的；他们想知道巨额贷款的周期时间（因为他们知道巨额贷款的利润率最高）。或者他们希望按销售渠道评估特定的产品线或服务。

或者，他们可能希望分析一段时间内的绩效，将过去的一部分与当前结果进行比较，或展望未来。例如，经理们可能不想看过去六个月的平均值，而想将假日销售季与夏季销售季进行比较。他们可能更愿意将今天的生产业务量与三个月前或去年同期的业务状况进行比较。

提升团队的 BPM 能力

组织如何才能提高其持续 BPM 交付能力？显然，经验会随着时间的推移而增长。但是，应对本文开头概述的情况——组织需要每年支持数十个 BPM 项目——具有挑战性。公司应制定积极主动的战略，以管理和增长 BPM 团队的知识，捕获见解并开发有效的项目方法。

应对此挑战最常见的方法是开发 BPM COE（卓越中心）或流程管理办公室。其理念是，一组忠诚的个人专注于公司的流程，因为这些流程驱动着底线盈利能力和绩效。该团队可以支持整个业务部门的多个 BPM 项目，并在广泛的领域保持势头。他们通常负责开发流程开发和流程架构管理的通用原则、语言、框架和方法论。

然而，在早期阶段，COE 可能会带来不必要的开销，因为它通常具有比试点项目所需范围更广的范围。随着 BPM 计划开始满足更广泛组织的需求，COE 概念才开始发挥其自身优势。随着越来越多的项目，对协调和集成方法的需求增加。COE 为围绕 BPM 项目的知识和最佳实践开发提供了一个中央存储库。

结论

为了使公司最大限度地利用 BPM 计划，他们必须首先意识到 BPM 涉及一种不同的工作方式。2 BPM 应用程序开发的方法论与即使在最敏捷的编程环境中发现的方法论也截然不同。与传统的瀑布式实施——应用程序功能以大型单体块形式出现——不同，迭代和适应在开发生命周期的每个阶段都很普遍。应用程序更新不是以年和月为单位衡量时间线，而是在几周或几个月内推出。

从 BPM 技术角度来看，重要的是确定一种支持整个 BPM 生命周期、促进所涉及的各个人员之间交互以及识别流程趋势和优化选项的产品。除了技术组件外，供应商还应提供强大的开发和实施方法论，并由平台本身提供直接支持。技术和方法论组件是相互依存的。

流程发现与理解

最佳实践

确定受流程影响的每个业务领域的主题 matter 专家。通常，相关角色的人员会做出一些被证明是不正确的假设。
请记住，重点是理解。使用互补技术来帮助利益相关者跳出框框，以不同的方式看待事物。建议的技术并非唯一可用的技术。BPM 团队应测试不同的建模方法，并自行评估哪种方法最适合其公司和文化。寻找有助于挑战现状的方法。
对于复杂流程，为了确保范围处于正确的水平，请尝试问“为什么？”五次。当不再有明确的答案时，这表明范围的水平是合适的。例如：人力资源流程效率低下。为什么？新员工入职时间太长。为什么？人力资源信息系统、招聘人员和人力资源经理之间在候选人在流程中的位置上缺乏协调。为什么？我们无法跟踪期望的入职日期以及何时需要进行入职培训。为什么？我不知道。这种分析将有助于确定根本原因，确保范围既不太宽也不太窄，以至于业务收益微乎其微。
确保团队能够简洁而具体地陈述与业务领域相关的实际问题。如果无法做到这一点，则表明需要做更多的工作来确定真正的优先事项。
构建应用程序的短期、中期和长期愿景的路线图。确定在后续迭代中交付的功能块。在开发周期完成后重新调整路线图的范围。

陷阱

如果人们着手捕获流程中的所有潜在路径、所有异常或所有潜在活动，则在此阶段的活动中可能会出现问题。这是“分析瘫痪”的根本原因。以 IT 为中心的分析师错误地认为，成功的道路始于填充多维建模存储库。从短期来看，它可能会扼杀 BPM 项目，因为它会分散人们对证明 BPM 方法对业务有效性的关键要求的注意力。
创建“最终”需求规范是在浪费时间。文档本身是平面的。事实上，在 BPM 项目中，最终需求规范的整个概念变得无关紧要。

从设计到部署

最佳实践

确保为业务领导层和 BPM 团队之间的持续和正在进行的协作提供全面的设施。
确保最终用户意识到这不是“一劳永逸”的系统交付。他们需要理解团队会回来进行未来的迭代，这样他们就不会试图将每个细节都塞进初始版本中。可能有必要制作一份功能路线图，其中未来阶段的活动与尚未实现的功能领域相关联。这将有助于 BPM 团队和最终用户专注于此开发阶段的交付。
与其尝试转换在初始阶段（流程发现和理解）开发的现状模型，不如在 BPM 套件内部构建一组新模型。这有助于专注于此阶段的期望功能。它消除了在发现和理解阶段弯曲规则的诱惑（通过尝试在模型中放入太多细节）。它还将有助于确保应用程序利用 BPM 套件的功能和设施。
在第一次迭代中锁定未来流程定义可能具有挑战性。即使当用户知道计划进行进一步迭代时，他们也会推动不太重要的功能。准确把握业务真正关心的是什么通常很困难。将流程的“快乐路径”的识别与异常处理分开。在流程流循环的初始迭代中，捕获和支持快乐路径可能就足够了。随后的迭代可以捕获主要异常，而将更复杂的异常留给应用程序的另一个版本。
对异常进行编目和加权，以帮助识别最重要的异常。从其影响（当异常发生时对业务的影响）、其频率以及今天是否可检测到异常等方面来查看每个异常。严重的异常可能每年只发生两次。或者相反，频繁发生的异常可能对业务几乎没有影响。
将实例流（系统中的所有案例）的管理与单个案例的管理分开。
团队最好在 BPM 实施过程中对指标进行基本重新评估。探索如何将与业务相关的数据（例如客户或产品信息）与有关周期时间、资源利用率等的信息集成在一起。在评估 KPI 时，请确保它们支持公司底层的 KBO（关键业务目标）。此外，请注意确保这些措施将加强该计划试图鼓励的行为。
在展示任何特定方面的已完成功能时，请确保研讨会包括比已经参与的经理和主题 matter 专家更广泛的群体。这有助于消除错误，识别下一个迭代的附加功能，并鼓励在应用程序发布到生产环境时得到广泛接受。
考虑流程的数据和文档实施细节。它们通常是为了保持流程协调而发明的机制，而不是流程的本质。寻找在没有该协调机制的情况下实现流程真正目标的方法。删除它们可能会极大地提高生产率和/或降低成本。
在集成第三方应用程序时，请花时间首先将它们包装在 Web 服务中，以使流程模型与后端系统中的任何更改隔离（反之亦然）。
请记住，数据的使用和理解都是迭代发展的。这可能对流程和集成机制的设计产生根本性的影响。
确保每个受系统影响的主要角色都有一位主题 matter 专家可用。这在流程流和用户界面领域尤其重要。跨项目共享专业资源。
在选择 BPM 套件时，请确定一个整体环境，该环境在不同视图之间提供语义一致性，因为参与者共享同一组模型和配置数据。这最大限度地减少了沟通不畅的机会并降低了开发成本。

陷阱

请记住，流程在设计和开发过程中不可避免地会发生变化，因为细节会被揭示出来。这些发现可能发生在开发过程中的任何时候。根据项目约定的范围评估每个发现。如果提议的更改具有巨大的影响，则将其确定为稍后迭代开发。过分强调试图定义流程理想状态的价值很低。
在设计和部署流程时，很容易将重点放在流程的编排上。确保对流程失败点给予同等的关注。评估每个故障的严重程度、发生频率以及当前检测控制措施。

Pulte Mortgage 案例研究

Pulte Mortgage 的人员着手改变客户服务模式，方法是变得积极主动，并在客户期望完成任务之前完成任务。然而，由于看不到流程的指标，经理们发现很难发现改进的机会。通过实施自动化案例跟踪应用程序，他们可以确定可以改进服务的领域。只有在收集流程指标后，才有可能确定需求。

例如，由于更好地了解了流程，经理们可以监控将案例推进到报价点所需的小时数。随着等待批准的队列中案例数量的增加，经理们意识到他们可以通过降低信用评分阈值（系统自动接受抵押贷款申请）来影响流程的整体绩效。随着他们缩短周期时间，财务风险将会上升。这并不意味着经理们有兴趣实时重新配置业务规则。相反，作为经理仪表板用户界面的一部分，滑块控制机制实现了这种控制。

然而，这是一个业务判断，需要在更高的风险与更快的客户响应以及更多的业务之间进行权衡。随着经理们开始了解这些决策的动态，他们随后可以开始将这种增强的理解嵌入到更动态的业务规则集中，这些规则集支持该决策（甚至建议自动信用评分批准的水平）。

监控与控制

最佳实践

与 LOB（业务线）经理合作，探讨他们将如何应对需求的特定峰值和低谷。制定是否有可能为他们提供机制以在这种情况下影响资源部署和吞吐量。
确保为组织的每个级别创建适当的仪表板——从高管（其仪表板可能包含多个流程）到员工（他们希望“记录”自己的生产力）。
特别重要的是要关注团队的需求以及团队内部人员的管理。专注于确定有多少工作正在进行中，以及团队今天、明天、本周或本月底必须完成哪些工作。这可以更好地了解他们的集体努力可以实现什么以及他们在哪里遇到困难。

陷阱

对于请求的每份报告，评估信息是否可操作——BPM 套件是否可以直接采取行动？将其视为阅读新闻和制造新闻之间的区别。否则，很容易最终得到很多“那又怎样”的数据点，而错失重大机遇。

分析与优化

最佳实践

流程模型就像比基尼。它们揭示的内容具有暗示性，但它们隐藏的内容至关重要（套用 Aaron Levenstein 谈论统计数据的话）。在 BPMS 环境中，所有与流程相关的信息都应通过图形表示形式访问。确保产品允许从同一工具、在同一上下文中直接访问所有事件、规则、用户界面屏幕、流程和分析。最佳实践是拥有一个整体环境。这使每个人在沟通时都保持一致，从而避免了所谓的“电话游戏”（无论我们最终如何描述它）。
除了分析活动持续时间和资源利用率外，最好查看路径：识别遵循流程“快乐路径”的工作百分比与花费在异常或复杂审批上的百分比。
BPM 套件应提供机制来剖析和切片绩效信息，将历史流程绩效数据与应用程序领域的 LOB 数据联系起来。BPM 套件本身应包括优化功能，这些功能可以发现趋势并提出潜在的改进方案，从而识别业务规则和流程逻辑的更改。寻找在与流程建模环境相同的图表中查看此优化数据的能力。

陷阱

模拟本身不是目的。它是众多诊断工具之一。不要依赖任何一条信息或一个工具来得出 100% 准确的结论。流程是多维的，“真相”也是如此。使用多种分析技术来隔离影响流程支持其 KPI 能力的最关键因素，并因此支撑公司的 KBO。
避免本质上是确定性的模拟模型——旨在向管理层证明对某些拟议变更的积极回报。此类模型通常反映建模者的议程，而不是现实。它们通常会掩盖假设而不是浮出水面。

提升团队的 BPM 能力

最佳实践

作为第一步，最好与其他组织进行基准测试练习。该小组不仅应向规模和文化相似的组织学习，还应与对如何组织 BPM 计划持有根本不同观点的公司比较方法。
通过评估不同的方法来提高团队的流程敏锐度。花时间权衡这些不同的方法（尤其是对于流程和业务建模）。不要为所有情况寻找单一方法，而应评估哪种技术最适合不同类型的场景。这种类型的活动必然涉及引入外部专家来教育和促进讨论
采用迭代开发方法论，并辅以适当的技术。线性应用程序开发方法论根本无法扩展以处理大量的项目。它们也无法提供在快速发展的业务环境中生存所需的敏捷性。
鉴于开发和实施方法从根本上不同，至关重要的是要证明该方法的有效性和有效性。寻找一个范围小、范围紧凑的项目，使团队能够培养技能和经验。该项目应具有相对较低的复杂性和明确的业务收益。
在整个过程中与业务用户分享高层次的愿景。帮助他们理解迭代方法，即快速连续地发布多个版本。否则，他们会认为发布之间的时间是无限的，并会在第一个版本中要求过多的功能。这会使情况变得不必要地复杂。与业务用户分享迭代构建版本，让他们更适应整体方法。
流程负责人、业务负责人、卓越中心和各个 BPM 项目团队之间的关系需要仔细考虑。全面且尽早地解决治理问题。确定流程负责人，以便在应用程序投入生产后对其进行维护/支持。就变更程序、对资源可用性的期望等达成一致。
随着时间的推移，提升公司 BPM 能力的最重要机制是 BAR（行动前回顾）和 AAR（行动后回顾）。对于每个项目，重点关注计划、准备、执行和回顾的短周期。对于每个项目、阶段和子阶段，计划与用户社区的互动。为每个可交付成果设定目标，并向团队简要介绍，以确保他们完全理解其基本原理。对整个项目以及每个阶段和子阶段进行正式的 BAR 和 AAR。由于必要性，子阶段的 BAR-AAR 周期将相对简短。鼓励所有团队成员做笔记并参与这些会议。1

参考文献

有关 BAR 和 AAR 的更多信息，请参阅 Darling, M., Parry, C., 和 Moore, J. 2005. Learning in the thick of it. Harvard Business Review (七月-八月)。
本文是继一篇探讨 BPM 项目成功的最佳实践的相关文章之后撰写的（可在 www.enix.co.uk 免费获取）。它提供了关于如何制定 BPM 项目蓝图的建议，定义了九个关键阶段，并提出了可以支持每个阶段的技术。

DEREK MIERS ([email protected]) 是一位独立的行业分析师和技术战略家。他曾担任过各种咨询职务，包括促进围绕 BPM 倡议的董事会级别对话、建立有效的 BPM 项目和专业知识中心，以及帮助客户开发利用业务流程战略的新业务模式。客户包括金融服务公司、制药公司、电信供应商、商业企业、产品供应商和政府组织。

最初发表于 Queue 杂志第 4 卷第 2 期—
在数字图书馆中评论这篇文章

更多相关文章

Mark A. Overton - IDAR 图
UML 是表示面向对象设计的 фактический 标准。它在记录设计方面做得很好，但它有一个严重的问题：它的图表没有传达人类需要知道的内容，使得它们难以理解。这就是为什么大多数软件开发人员仅在被迫时才使用 UML 的原因。人们从控制层级的角度理解组织，例如公司。当面对人员或对象的组织时，通常第一个问题是“谁在控制这一切？” 令人惊讶的是，UML 没有一个对象控制另一个对象的概念。因此，在每种类型的 UML 图中，没有对象看起来比其邻居具有更大或更小的控制权。

Eric Bouwers, Joost Visser, Arie Van Deursen - 衡量所得
软件度量 - 有用的工具还是浪费时间？对于每位珍视软件系统这些数学抽象的开发人员来说，都有一位开发人员认为软件度量只是为了让项目经理保持忙碌而发明的。软件度量可以是帮助实现目标的非常强大的工具，但正确使用它们非常重要，因为它们也可能使项目团队失去动力并将开发引导到错误的方向。

Duncan Johnston-Watt - 在新管理之下
在竞争日益激烈的全球环境中，企业面临着降低运营成本的巨大压力。与此同时，他们必须具备敏捷性，以应对动荡的市场带来的商机。

James Champy - 人员与流程
当 Mike Hammer 和我在 1992 年出版《企业再造工程》时，我们理解到真正的业务流程变革将对人们产生的影响。我说“真正的”流程变革，是因为管理者使用“再造工程”一词来描述任何和所有的企业变革计划。一位被误导的高管告诉我，他的公司不知道如何进行真正的再造工程；因此，它只是缩减了大型部门和业务部门的规模，并期望留下的人能够弄清楚如何完成他们的工作。可悲的是，这就是一些公司仍然实践流程再设计的方式：让人们过度劳累和士气低落，而客户则体验到糟糕的服务和低劣的质量。