流程管理是以满足客户需求为目的的一系列活动。比如供应链流程包括：物流、配送、采购、客服、销售、制造和财务会计等等。而软件开发流程则包括：立项、需求分析、规划设计、代码编写、测试、部署、维护和质量保证等等（PMBOK里分布在启动、规划、执行、收尾和监控过程组当中）。

通常在实施流程管理的时候，譬如应用CMMI，ITIL等等，部分人认为只有完全符合了框架所规定的每一项建议和原则，才是成功的实施，而忽视了实施流程管理的目的是满足客户需求而不是为了实施而实施。流程管理并不是一种技术，而是一种艺术。

流程的制定并不在于形式，应该以目的为导向来设定。以目的为导向的意思是只要能实现目的，到底是人，还是系统，还是什么方法来达到目的都没有关系。对于不同的组织，个人，流程都应该是不同的，多余的流程是应该剔除的，而定好的流程也应该是随着环境的变化而具有一定的弹性。以软件开发为例：

一定要做详细设计吗？

HLD（High Level Design）以后，详细设计总是非常痛苦的，里面需要非常细节的类图，序列图甚至于部分的伪代码。工作量不亚于代码编写的过程。对于项目时间跟成本是个不小的Overhead。

实际上我们做详细设计的目的是什么？

1. 为了新手可以很快的开始代码编写的动作，而且不会跟设计的方向偏离，能够符合一定的规范。
2. 当日后维护人员接手的时候，可以根据文档很快的找到问题所在。
3. 随着时间的飞逝，源代码为什么要这样写很容易被遗忘，或者新成员根本就不知道。那么日后基于这个产品的延伸，就变得非常困难了。详细设计可以帮助团队快速进行学习。

基于这些目的，似乎详细设计是非常有必要的。但是当一个团队成长起来，每个人都具有3年以上的编码经验，对设计和规范的理解已经很到位，只要有指导性的需求加类图已经可以编码了，这个时候拖沓的序列图和伪代码就变得完全没有必要了。当团队成员的代码习惯非常好的时候，结构和注释都已经很容易被看懂。如果是基于Java的，根据注释可以自动生成Javadoc等文档，便于日后的学习。学习和维护人员就已经可以很方便的找到相应的API和需要的资料。那我们还需要花跟代码编写一样多的时间去做详细设计吗？

事实上，通过初期的详细设计，培养团队成员的编码习惯和规范意识才是最重要的。让他们明白良好的代码习惯，统一的规范，为整个公司、团队以及日后的工作所带来的好处。当团队已经成熟的时候，完全没有必要再进行详细的设计了。把类图放到HLD里面去，然后直接编码吧！

SOW是不是必须的？

SOW似乎是一个工作协议，包括了工作范围，人力资源，还有一些财务方面的信息。在项目中对签署的各方起到一定的约束作用。当出现什么问题的时候，可以很明确的追溯责任。但是SOW的目的在于追溯责任吗？我们当然不希望项目出现任何问题而要走到这一步。当项目相关的各个部门和各个公司都是初次合作，并不互相了解，那么这份SOW还是很有必要的。但是当两个团队，或者部门已经很熟悉，并且互相信任，大家都知道怎么配合才能令项目正常地进行，人员的ramp up和ramp down应该如何处理，对责任的分配也是有一些私下的默契，况且随后会有详细的项目计划，完全没有必要再签署什么SOW了。

缺陷修复流程是否能够精简？

一般的大公司都会有一套缺陷跟踪的流程或者系统，比如说Quality Center。各种角色包括测试，协调，开发团队等都会定义在里面。流程上当测试组发现缺陷，会首先给协调人员，然后再交给开发团队、环境维护或者BA等部门。修复缺陷后，交给验证，然后由协调人员在交回测试组重新测试。

我们在做缺陷修复的时候希望的是尽快高质量的完成工作。这样一个流程，协调人员就成了瓶颈。并且对协调人员的要求非常高，他需要知道缺陷应该属于开发的，还是环境维护的，还是需要BA确认的，然后才能交给正确的部门，要不然一来一回就得浪费不少时间。

在一个初次建立的合作，或者完全没有以往经验的项目里，一个熟悉系统的资深协调者是不可或缺的。然而当一个默契的合作团队中，特别是一个很小的团队很小的项目里面，测试，开发，BA和环境维护都已经是配合默契的部门了。测试组可以借鉴以往的经验，大致把缺陷分派下去，开发人员偶尔发现缺陷并不是代码所致，直接联系BA或者环境维护，确认问题所在。BA或环境维护将缺陷修复然后直接返回重新测试。这样就高效多了。而没有必要要死跟流程。

Billing System的反思

集团有个集中的Billing System，所有不同子公司和支持部门的Bill在每月底都会集中在这个系统里，然后按照协议的百分比发给相应的子公司和业务部门进行偿付。然而有的子公司，有自己的一套预算和Billing System。当子公司的系统和集团的系统没有办法顺利对接的时候就会出现问题了。还有的问题是产生于政治原因，比如外资公司由中国收取台湾的款项的时候，会遇到不少麻烦。怎么办呢？

1. 人手对接。人肉的方法总是可行的，因为人要比电脑聪明得多嘛。不过每个月为每个项目发出67张Bill，有的Bill只占项目费用的0.02%。对于财务人员来说，是一件非常痛苦的事情。而且还容易出错。
2. 通过中介。比如说子公司A的系统能够对接子公司B的系统，子公司B的系统能够顺利对接集团的系统。这样的可以解决问题。但是有可能需要跨国处理，会碰上一些法律法规的问题。而且子公司B需要提价来对冲因为额外的账面收入而带来的税收。这样也带来了成本的提升。
3. 修改目前子公司的系统接口。最快最可行。当然要另外立项，作为一个项目来做，会涉及到成本，收益的问题。
4. 由上至下统一所有子公司和部门的Billing System。这个就涉及到大范围的业务建模，Data Migration，所产生的影响可能要开几个项目集，项目组合来做了。而且Legacy System的替换也要非常小心，不小心导致整个子公司的财务运作受阻，损失就不是金钱而已了。

关注例外

要确保流程的正确执行，Audit是必不可少的。但是我们能够有多少人手去做详细的Audit呢？通常Audit的存在是一个威慑的作用，告诉大家，是不是Adhere流程，是有人看着的，别乱来。实际操作中，性价比最高的做法是用有限的人手去关注各种例外以及项目收尾时的总结了。