工作分解结构(WBS)
如果你被指派负责一个大型工程，比如建造一个机场，你会有何感想?你可能会说:“我完全不懂建筑行业啊!”但如果你学的就是土木工程专业，而且做了很多年的工程师，是否就一定能够完成这个使命呢?未必，面对复杂工作时，专业知识背景是一方面，懂得项目管理的核心思想——工作分解结构(Work Breakdown Structure，WBS) 是另外一件事。WBS 提供了对需要复杂协同的项目进行有效工作分解的思维框架，下图是组织结构图形式的 WBS 简易模板，也可以表达为更专业的 PERT 图或甘特图。
WBS 最早被显性用于的项目就是一个极复杂的项目工程——阿波罗计划时代的 NASA，后来通过美国国防部系统被引入更多的使用领域中。到了 1987 年，美国项目管理协会发表了著名的 PMBOK(Project Management Body of Knowledge)，提供了 WBS 的实践标准， 并将其推广到更多的民用领域。
我们可以将 WBS 简单理解为一个任务的树状目录，把复杂项目按照某一个维度逐项分解，主任务可以分解为若干子任务，子任务还可以有自己的子任务。每个任务带有一些固定的信息，包括任务计划开始时间、完成时间，以及开启这个任务的前提条件是完成哪个任务。有了这些基本信息，我们就能够计算出这个复杂项目最快需要多长时间来完成。再进一步，我们也能够识别出那些进度敏感，一旦延误就会让整个项目延误的任务序列，这个序列被称为关键路径(Critical Path)。
下图是经典的项目管理软件 Microsoft Project 的主体界面，它显示了一个典型的项目中的 WBS 内容。粗体的任务名称实质是一个任务组，也就是 WBS 分解过程中的中间节点。右侧的图形就是甘特图， 它用色块呈现了一个计划任务的日程安排，并通过箭头链接表达了任务的前后关系。其中，呈现为红色的任务就是关键路径上的任务，它们一旦延期，整个项目就会超期。反之，蓝色的任务不在关键路径上，对它们的超期可以有一定的宽容度。
在项目管理领域的 WBS 有几个必须遵守的原则。
1)100%原则:WBS 需要根据项目总范畴包含 100%的内外部交付物，每一层分解的子任务也要 100%覆盖它的父级任务范畴;也就是说需要在同一个层次上列出所有的子项。例如，定制软件开发项目必须在第一层级覆盖需求评估、设计、开发、测试和交付 5 个完整的模块。
2)元素互斥:WBS 结构中各个元素是相互独立不交叉的。例如， 在同一个层次上不能同时有“采购盘子”和“采购餐具”两项，如果存在这样的交叉，将会给未来的任务和资源分配带来混乱，工期和成本的估算也不会准确。
3)围绕产出计划:在列举 WBS 工作包时，要按照期望的产出物计划，而不能只是规划行动事件，因为后者要么是事无巨细地堆叠，要么出现挂一漏万的疏忽。这是一个比较难以掌握的原则，因为我们本能上都习惯直接拆解工作。但流程项目的完成都是为了交付一个承诺，这个交付标准决定了我们从第一天开始的所有工作内容。再比如，为了策划一个婚礼，我们可以按部就班地依据习惯和他人的提醒列出 WBS，但是更好的出发点是考虑一个婚礼所要实现的事项:新人的纪念、家人的感恩、亲友的参与和记忆。从这三个产出出发，可以更加完整和有目标地列出所有有意义的具体工作。
4)要有合理的工作包(work package)大小:项目所细分的工作包并非越小越好，它的合理大小取决于多个因素。首先，它和项目成员的工作成熟度有关，经验丰富的成员组适合比较大块的工作包，让成员能够发挥自主性来围绕产出设计任务。过细的工作包会让成员感到被过度管理，而且需要花费过多的时间来更新任务状态。其次，工作包的大小还和管理沟通模式有关，对于案头协作的行业，按照 8~16 个小时(也就是 1~2 天)的体量确定工作包大小可以配合每日或者隔日的会商会议;对于外勤作业比较多的行业，按照更长时间完成的工作包大小可以适应每周会商的节奏。当然，工作包也不能大到无法进行分工，至少每个工作包都要有明确的负责人;如果是多人负责的一 类事务，则必须进一步细分。
复杂项目的 WBS 规划需要专业人员和经过项目管理训练的人员 配合，所以它是一种高价值的知识资产。比如一个机场或者地铁项目的 WBS 规划本身就是可以复制到其他同类项目中的。也有不少咨询公司依靠积累的 WBS 范例来提供行业咨询服务。
软件行业也在为 WBS 规划需求进行变革，过去，WBS 的规划依靠的是 MS Project 这样的项目计划软件，现在，在线协同软件已经发展得越来越强大，可以把复杂的项目规划和项目沟通整合在一起。 WBS 规划需求也是企业项目管理和协作过程中的焦点问题之一。
基于 WBS 思想的项目管理又被称为流程项目管理，它有明确的项目开始点和终结点。但是，企业中还有不少项目并没有这样的特征，它们往往延续很长的时间，周期性地完成一轮轮工作，比如互联网软件产品的迭代开发项目就无法设定明确的起点和终点。围绕这种特性的项目，企业界又发展出敏捷项目管理的模式。
敏捷项目管理
上面提到的 WBS 是一个典型的计划驱动的项目管理思想，强调的是边界明确、责任清晰、成本和进度可控。所以，也有人把这个模式称为“瀑布”模式，计划和执行就像瀑布一样，从上至下，直到落地结束。
到了 20 世纪 90 年代，软件行业的效率极客们发现这个模式有很大的弊病。首先，很多开发项目(尤其是软件产品)的计划过程很难明确边界，因为需要复杂的技能配合;责任清晰也很难在过早的计划阶段落实;更重要的是，一家软件公司的产品是没有开发的终点的，每个产品都希望能够分阶段长期发展下去，即使是一个版本的产品，也没有一个明显的开发结束的点，通常都要伴随长时间的缺陷修复和特性迭代。甚至在互联网软件时代，还出现了MVP(最小化产品) 的概念，极端地提出了一个项目的最早计划只应该覆盖两周到四周的工作时间。
2001 年，十几位软件工程师在美国犹他州的一个会议后发布了一个著名的《敏捷软件开发宣言》(简称《敏捷宣言》)。其中，Jeff Sutherland 成为敏捷项目管理的布道者。
这份宣言非常简明，全文如下。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观:
个体和互动 高于 流程和工具
可用的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
但我们更重视左项的价值。
敏捷项目管理的模板如下图所示，敏捷模式的原则包括，持续交付有价值的软件来使客户满意、为频繁的变更做好准备、通过高密度的沟通和协作提高开发质量。如果说敏捷项目也有 WBS 的影子的话， 那就是它强调的尺寸恰好的工作包——需要适合在两到四周内交付成果并开始得到反馈。工作包的出发点不是具体的事物，而是被称为 User Story 的用户需求描述。用户需求描述的大意是明确一个迭代周期会解决客户的哪些问题，然后到这个周期结束时来检验这些问题解决得怎么样，从而决定下一周期加入哪些新的 User Story，或者继续保持原有用户需求的迭代。
在过去十几年中，敏捷的概念已经走出了软件行业，因为很多企业发现，原来基于瀑布流的周全项目计划内容对于自己公司内部的变革项目来说是不必要的。企业内部具备足够的动力来面对变更的需要，从而保持灵活性，也让交付的结果更有意义。一个软件产品的开发是这样的，一个企业内部的质量改善项目也是这样的。我们可以看出敏捷项目管理结合了 PDCA 方法和 WBS 原则的思想核心。
其实，早在软件业推行敏捷项目管理理念之前，生产制造业已经在使用一个与之非常接近的管理工具，被称为“看板”(Kanban)。20 世纪 50 年代，丰田工程师大野耐一为了解决材料、生产和库存的衔接问题发明了这么一个简单的工具，后来被发展成丰田著名的精益生产和 JIT 库存生产方法。软件行业是非常善于学习的行业，所以工程师们本能地将其发展成电子化的工具来服务自己的管理需求。2011 年诞生的SaaS 产品 Trello 是第一个将看板作为产品核心的协作平台。今天，绝大多数的互联网协作软件都基于这个思想。
过去，企业应用的委托者和开发者习惯基于一个瀑布项目来协作。事先花费大量的精力来定义需求和讨价还价，一旦项目开始执行后，又缺失了紧密的沟通，通过这种合作模式开发出来的软件质量可想而知。这也难怪《敏捷宣言》中写道“客户合作高于合同谈判”。 今天，协作工具和模式的演变也推动了软件外包行业的变化。越来越多的需求者看到了敏捷项目管理的价值，不再将宝押在前期的周密计划上，而是和开发商一起，采用迭代优化的模式来保证开发出来的应用更符合用户的实际需求。按合同交付变成了持续交付。
敏捷软件开发模式所催生的软件化看板并不限于用在软件开发 上。当改变看板名称后，它可以被应用在企业运营的多个环节。比如，招聘员工的面试流程就可以基于面试和录用阶段建立看板，在它上面流动的就是候选人记录。新员工入职，也可以利用一个分日期的看板，直观地呈现一名新员工在加入公司以后的若干时间内需要经历哪些导览、培训和测试步骤。
WBS 原则和敏捷(Agile)模式都不是万金油，在不同的项目性质和目标下，不同的思想会占上风。一个接受 NASA 委托的航天工程， 如果只考虑敏捷，也是要付出巨大的财务和履约风险代价的;一个小型的软件产品公司如果迷信使用甘特图来绘制未来一年的产品开发计划，也是一定会遭遇惨痛损失的。
销售漏斗(Sales Pipeline)
接下来要介绍的其他几个管理方法和前面的有所不同，它们在信息化时代之前几乎不存在，它们是通过工具的设计和迭代一步步发展出来的，而且它们与企业的具体运营过程的关系更紧密。我们从关注度最高的销售漏斗开始。
销售管理方面的应用是企业应用中的热门领域，尤其在国内市场。要想打造一个有效的销售管理信息化体系，离不开清晰的销售管理理念和方法，否则，能够做的最多只是按需打造一些提高效率的工具。
销售管理方法的形成经历了漫长的过程。差不多一百年前，西方商人就创造出“线索卡片”这样的管理工具，用一张卡片记录潜在客户资料，并同时利用这张卡片记录销售转化的全过程。
这是一个非常直观的方法，但是在销售组织扩大、销售过程复杂度提高后，这个方法无法解决现代企业销售管理中的几个重要问题。
1)难以适应分工化的销售过程。复杂产品的销售通常不是一个人能够完成的，它可能需要销售工程师的参与。成交以后也不是业务关系的结束，而是客户服务和持续销售的开始，一个客户并不一定只有一次成交动作。线索和客户其实并非一一对应的关系。
2)难以通过数据分析有效地提高转化率。很久以前，销售人员就发现 B2B 销售和一部分的 B2C 销售并非从陌生人到成交客户的直接转化。销售的过程需要经历好几个不同的阶段:第一次见面→了解客户需求→识别需求和产品的关系→制订销售策略→给出方案→报价→讨价还价→促进成交，等等，销售不是一蹴而就的。在这么复杂的销售转化链条中，必然有的销售人员做得好，有的做得不够好。对于那些做的低于平均水平的销售人员来说，到底哪个环节存在盲点或者培训不足呢?大多数情况下，销售管理人员无法一眼看清楚。
3)虽然有了潜在客户的记录，但是还是无法基于这个信息预测未来一段时间可能的销售成果。
基于这些希望解决的问题，西方销售管理业界在个人电脑普及的早期——单机软件时代就发展出了销售漏斗管理思想和配套的工具。 早期的销售漏斗管理将客户、销售线索和成交机会分开管理，建立了 一家企业管理订单获得过程的基本数据结构。然后，再将成交机会进行阶段划分，不同企业和产品可以根据实际需要将一个典型客户从接 触到成交的全过程划分为 4~5 个阶段，阶段的名称可以自行定义。因为有了这个数据结构，我们就能够通过数据来分析不同阶段之间的转化率、不同销售人员和团队的转化率，以及在销售漏斗中流动的成交机会金额。通过简单的数学公式，销售系统就能够预测未来一段时间 的可能成交金额。比如销售漏斗中如果存在以下成交机会:
A 客户购买 X 产品，预计成交金额 100 000 元，目前在 阶段 1，成交概率为 20%
B 客户购买 Y 产品，预计成交金额 10 000 元，目前在 阶段 4，成交概率为 80%
加总以后，我们就可以得出累计的预测销售金额为 28 000 元。
在这个例子中，我们忽略了订单成交周期问题。如果漏斗中的成交机会数比较少，预测的精度就会比较低，但如果长期使用，就可以不断调整预测参数，让预测结果更准确。
有了这套方法和工具以后，销售管理就可以实现以下功能。
1)对销售过程进行结构化的记录和分析，能够通过计算预测销售成果，也能够通过数据记录得到大量有价值的销售情报。例如，如果交易失败，那么这些输单的主要对象和原因是什么?
2)能够有针对性地改进销售转化率，而不是笼统概括地提出改进目标。每一个销售阶段的转化都伴随着更加具体的方法、技巧和工具，并非每一位销售人员都能够完全掌握。有了中间过程的数据分析，我们就知道不同销售成员在不同阶段转化上存在的问题(他们的转化率肯定低于平均水平)。而且，如果进一步分析销售漏斗中的成交机会来源和大小，我们也能够知道销售人员是否能够有效地从现有客户中获得更多订单，找到的客户价值是否足够高，成交周期是否长于平均周期。
从 Salesforce 开始的销售管理自动化软件着眼的就是解决这些问题。到最近几年，销售自动化已经发展到可以帮助销售人员自动完成一些销售动作，或者在恰当的时间给出销售行为提醒，甚至依据积累的数据来自动分析成交机会的质量(机器学习在这个应用领域有很大作为)。
如果我们把销售漏斗向前延伸，获取客户的过程其实还包括整体性的市场营销、获得最基础的客户线索;如果向后延伸，获取客户的过程还包括为现有客户提供使用帮助、加深现有客户的使用程度、促成更多老客户订单。所以，销售管理应用还有营销自动化和客户支持两个“姐妹”，它们整合在一起就是比较完整的 CRM 解决方案。
有一些企业用户对销售漏斗方法中要求有效记录数据颇有成见。他们认为销售人员很难有动力录入客户信息和销售过程。这个问题要分两面看，一方面，CRM 解决方案是为了从整体上提高销售效率的，所以，无论数据采集有多么艰难，如果没有事实的解析，就不可能有针对性的优化方案，企业就永远只能依靠明星级销售人员，这在企业高速增长阶段是难以为继的。任何企业都应该有能力将普通销售人员训练为合格销售人员，这个能力正是 CRM 信息化所赋予的。另一方 面，采集销售过程信息的困难也未必是不可克服的。CRM 产品开发者都非常重视这个问题，他们有动力设计和开发出对销售人员更加友好的数据采集和记录方式，比如，现在大部分销售管理软件都能够和邮件、社交网络系统整合，不再需要销售人员重复记录沟通过程。
销售漏斗方法主要适用的是 B2B 商业模式企业，也包括一些成交过程复杂的 B2C 模式企业，如果你处于一般消费品和消费者服务行业，那么销售管理的模式是完全不同的，它对应的是企业的电子商务前端店面管理或者售点系统(POS)。
用户分群和营销自动化
在现代营销理念中，“在正确的时间向正确的人传递正确的信息” 是被广泛认同的原则。但这条原则在越来越复杂的营销环境中非常难以实施，其有效实施离不开信息化和自动化的助力。可以说，现代营销方法几乎完全都是在软件能力基础上逐步发展起来的。
在大众传媒时代，软件技术对于营销的帮助仅仅在于创作数字媒体内容。从 2000 年以后，大众营销模式在营销行为中的占比越来越低，今天绝大多数的营销投入都发生在社交媒体营销和数字化营销 上。营销活动不再是将单一的信息向大范围的受众传递，而是依据每 一个受众的特征和行为自动触发营销动作。这个过程几乎完全是自动 化的，所以，企业用户依然保持了对营销活动整体管理的感知，只是这个管理过程远比过去复杂。
很久以前，营销软件就意识到要将用户进行分群。它们通过分类或标签的方法把用户细分成很多群组。然后营销经理根据不同的目标 选择不同的群组传递不同的信息。但是，当业务在线化水平越来越高、用户行为越来复杂、需要评估的数据点越来越多以后，这种简单的基于标签的用户分群方式已经无法满足营销管理的要求。换句话说，营销应用的复杂性随它所管理的受众数据规模的扩大而大幅提高了。
因此，现代营销方法建立了更适应要求的“动态细分”概念，受众和用户不仅按照简单的标签进行分类，而且通过灵活度极高的检索条件创建出动态的细分组。例如“新顾客”这个概念，在传统的用户标引中是很难实现的，因为今天的新客户在下一个季度就不一定是新客户了，他们可能变成忠诚客户，也可能就此流失。而在动态细分理念下:
新客户 = 现有客户 ∩ 加入时间<90天 用户细分群成为了一个虚拟的分类空间，用户因为满足计算条件而流入这个空间，也会因为不再满足计算条件而离开这个空间。针对用户细分的条件不仅基于用户本身的个人属性，也可以是用户的行为组合，例如“去年冬天购买过 500 元以上羽绒服的顾客”。
而且，营销管理中的受众数据也不一定需要是实名的，在互联网广告环境下，用户只是一串代码，通过覆盖全网的广告网络，用户出现在任何网站和 App 上都有可能被追踪到(通过第三方的 DMP)，然后通过定向广告被触达。
有了这个强劲的计算引擎，营销管理者可以同时建立起成百上千 个自动营销活动，根据不同层面的营销目标展开营销行动。有的负责获取新客户，有的负责转化，有的负责提升用户使用量，还可以用在防范客户流失、用户教育、沉默客户唤醒等多种场景。
营销自动化也是 CRM 解决方案中的重要一环。结合 6.7 节所讲的销售漏斗管理，企业一方面需要通过营销力量不断获取有效的销售线索，另一方面需要在销售漏斗以外，不依靠销售员的个人努力而持续开展转化工作。这两个环节依赖的都是营销自动化运营。
在不同的细分市场里，解决营销自动化问题的具体方式有所不同。比如 B2B 企业往往建立自有的客户和潜在客户数据库，通过 E-mail、电话和短信展开营销接触;在消费品领域，客户数据管理可能表现为社交媒体管理，通过社交媒体内容触达顾客，比如微信公众号和微博运营;在电商领域，整个营销过程可能基于某一个生态内的设施和工具来完成，比如淘宝天猫和京东的商户后台等。无论哪一种业态，企业都有足够的动力来建立自己可以控制的客户数据库和营销系统。
企业资源计划(MRP/ERP)
ERP 是企业信息化中最频繁提到的一个概念，但它具体所指的范畴已经越来越模糊，甚至有人把整个企业的信息化系统都称为 ERP。 为了厘清概念，我们需要追溯一下 ERP 概念的来源。
最早的企业资源计划系统来自制造环节的原材料管理流程。20 世纪 60 年代，IBM 就在大型机上开发了 BOMP(Bill of Material Processor)系统，帮助制造行业准确衡量生产过程中的原材料成本， 后来，类似的应用系统开始通过个人电脑在不同规模的生产制造业中普及开来，并在应用范畴上逐步扩展到生产过程的更多要素管理，包 括材料的采购、存储，设备、工种和工时的计划。所以，这个时代的软件概念被称为 MRP(Material Requirement Planning)和后来的MRP-II(Manufacturing Resource Planning)。MRP 解决的问题简单概括起来就是帮助生产计划人员根据销售数据或者销售预测数据来做围绕生产的决策，减少浪费并提高整体生产产出。
到了 20 世纪 90 年代，生产类企业的经营活动信息化的程度越来越高，其他业务系统如果不能和生产制造系统整合就会带来信息断层，所以，Gartner 公司首次提出了 ERP(Enterprise Resource Planning) 的概念，它将企业信息化看作一个整体，通过 ERP 这个特殊门类覆盖了企业运营管理的方方面面。这也是为什么生产类企业把任何 IT 系统都称为 ERP 系统。虽然制造类企业 IT 更迭的门槛非常高，但在 2000 年以前，因为千年虫问题和欧元区的启动，欧美国家利用这个契机将几乎所有传统的 MRP 系统升级为了 ERP 系统。随后，因为中国的台商大量在中国大陆地区设厂，ERP 的概念和运用经验被带入中国大陆的制造领域。
在生产制造业的 ERP 系统中，围绕制造管理的模块依然是核心， 一般由下面这些基本模块组成。
• 主生产计划系统(MPS):确定每一个产品在每个周期的生产数量计划。它通常需要结合订单数据、存货数据和最低存货水平规则来运行。
• 维修保养(Maintenance):管理机器设备的维修申请和保养日 程。
• 产品生命周期管理(PLM):管理产品工程设计变更和对应的物料成本清单(BOM)。
• 采购管理(Procurement):管理供应商和成本物料的采购过程。
• 质量管理(Quality):管理生产质量改进点和处理结果。
除此以外，高级的 ERP 系统还包括其他更加细化和深入的模块， 例如车间作业管理、产能计划、存货管理、在制品管理、标准成本核算、批次管理。
ERP 系统是企业应用中最典型的门类，它对企业的价值非常明显，以至于中小型制造企业和按单生产的企业也不得不部署 ERP 系统，否则将面临难以控制的后果。但 ERP 系统也非常复杂，每一个软件模块的设计都是生产制造专有知识和数据库应用的结合，不了解制造过程的软件设计人员是很难设计出可用的 ERP 解决方案的。
ERP 的实质是一套整合的数据库和业务规则，这也是为什么大型 ERP 厂商也几乎都是商业数据库厂商，这样似乎可以让 ERP 解决方案更通用，利用一套产品来驱动所有制造企业。实际上也是这样，专业的 ERP 产品都是模块化的产品，而不是专用开发的定制软件。但是，制造业的流程差异又是如此巨大，比如生产机床的和生产服装的企业所需要的解决方案就有很大差异，因此，模块化的 ERP 解决方案需要为每个行业进行扩展和配置，产品模块的核心能力也因为需要 扩展到不同行业而不断延伸。而且，扩展和配置的过程并不是只到行业这个层级，具体部署到每个企业的时候，依然需要通过继续配置来满足企业之间的差异。所以，ERP 软件的主要实施成本花费在需求调研、配置、测试和培训员工的过程中。
最近几年，ERP 的概念开始回归狭义的生产制造管理领域。2013 年，Gartner 公司再次提出了“后现代 ERP”的概念，指出未来的企业 ERP 系统不应该强调一体化，而是应该根据企业自己的需要和市场的供给选择混合的模块化解决方案。这主要是因为生产制造管理以外的应用系统在云计算时代发生了很大的变化，它们的面貌已经和传统的基于定制实施的 ERP 软件很不一样。SaaS 软件产品开始在越来越多的品类中展现出竞争优势，比如基于看板(Kanban)的项目管理应用能够给制造业管理提供更敏捷的流程和透明的沟通机制，所以， 即使是制造业企业，也没有必要按照一套方案来部署所有的软件应用。企业可以将那些核心的模块保留在按需定制实施的范畴内，而通过开放接口来连接其他不同部署模式的业务系统。
上文节选自《现代企业应用设计指南》（作者/明道创始人任向晖），点击即可购买
