企业、公司规模无论大小，都会涉及到“流程”二字，办什么事都要走流程。有了流程，感觉什么事都有章可循、有据可依了，但是流程在很多时候会让你感到无奈又可气可恨。流程管理复杂了，人不仅容易疲惫，办事效率更是容易大打折扣。本来复杂的事情，可以用简单的方法和清晰的流程去化解，但若将简单的事情复杂化、流程繁杂化，我想每个人都伤不起。下面我们看流程伤不起的几个案例：

一、时间等待伤不起
   
     当一个企业经过创业期进入迅猛发展阶段后，企业分支机构会不断增多，组织架构也会越来越复杂，在这个时候内部运营的规范性和高效日益提上日程，就会产生流程管理的需求。流程管理清晰明确了，对工作的影响效果是明显的，但是流程的环节太多，时间的等待，真的让人伤不起。
     公司有20台WEB前端服务器需要将原8G内存升至16G,需要采购40根4G内存条。首先小王根据应用组的需求开始写服务器增加内存方案，然后进入OA办公系统填报申请，选择各个环节的审批人(运维经理--技术总监助理--技术总监---行政部物资采购专员--行政部副经理---行政总监---财务部费用核算专员---财务总监助理---财务总监----总经理助理---总经理)，一圈转下来快则十天半月多则一个月。如果中间哪位领导出差了和休假了，那就继续等吧，我见过一个扩容技术方案等到批下来都半年了。好么，你还不能催，你要急，一句话等着你“正在流程中”；还有一回生产机房的某台服务器做网卡驱动升级，本来简单的几个操作就完事了。偏偏那天领导在场，还是按流程来吧。先是写文档报批，然后一个一个环节的打电话联系并确认，本来一个小时能完成的事，愣是耗了一天。

     说到财务报销流程，那等待的时间就更长了。一长串的审批签字，一系列的财务手续，费用拿到手时，那真的是“等的花儿都谢了”。工程师有的时候不愿加班、不喜欢打的、不喜欢半夜去“救火”，很多时候都是冗长繁琐的财务报销逼的，积极性也被无形挫伤了。

     过多的流程控制点，冗余的环节阻碍了上传下达的流畅性，降低了工作效率的同时，也磨灭了工程师的热情和积极性。除去流程中的冗余环节，让工作流程的各个环节得到精简，是优化工作程序、提高工作效率的第一步。

二、方案提报伤不起
 
    根据流程一般做故障处理的时候，工程师需要写技术方案文档，然后发内部OA办公系统进行报批。在流经各个环节时，如果审批人都是简单的两个字“同意”倒还比较幸运，比较顺利。可是有的时候，不知是哪个领导突然心血来潮，看了一下你的技术方案文档，在审批的时候说“这个方案”还可以“那样做”，那你的麻烦就来了。举个例子：一线运维报刚上线的ORACLE RAC集群(3节点)中的有一台服务器网络不稳定，PING的时候时断时续，领导批了个字说“请检查交换机和网线”，接下来你就得做测试证明交换机和网线没问题；又过了一个流程，接着审批的领导批了个字说“请检查RAC配置”，没办法你又得做RAC的测试和验证；再接着又一个流程，接下来的领导又批了个字“请对系统配置进行检查”，好么你又得对系统配置一通检查，证明它没问题。折腾来折腾去，你都要吐了。其实你问一下具体实施的工程师，最近对服务器做过什么修改和配置，你上去检查一番发现就是双网卡绑定配置有误，改一下RC.LOCAL中的ifenslave bond0 eth0 eth1就可以搞定了。但是前面一线运维报的问题，各级领导都批字了，你就要根据这些写详细技术解决方案，还不得不对领导提出的意见进行一一论证和说明，一个一个的邮件飘来飘去，这样一个问题来回几十封邮件让人崩溃，最后把方案完成提交、各级领导一致通过才终于算尘埃落地了。

  细节的问题，只有一线和实施的工程师最清楚，一个问题在提报前一定要先找具体负责的实施工程师最近做了什么，清楚问题的原因、明晰解决办法后再提报，否则一路流程下去等待你的是更多无谓的测试和验证。很多技术问题，让一线和具体负责人直接去解决，会更好更高效。这也是进一步优化工作程序、提高工作效率的办法。


三、重复沟通伤不起

    一个企业的组织架构越来越复杂时，很容易出现沟通不畅，有时候沟通不畅是人的原因，而另外一些时候，沟通不畅就是流程往复繁冗的问题。
   
    很多时候找到问题的根源，并不是什么难事。但是找到问题，不等于能够解决问题，更不等于已经解决了问题。举例来说，一个大公司的IT基础设施是采用分项外包的形式来实施运维的，比如AIX小机是神码的外包、存储是EMC的第三方外包、服务器是IBM、HP、DELL的技术外包、网络设备是第三方的外包、NBU备份是赛门铁克的第三方外包、集群\HA是第三方外包，这样公司感觉省了很多事，可以专注于自己的核心业务。可是出了故障呢？你就会遍尝重复沟通的绕舌之伤，因为每个第三方都只负责自己的那一块，多余的责任谁也不想负，你需要联合和平衡他们。比如你需要做AIX小机服务器的文件系统扩容，你需要联系EMC存储的第三方查看有无空闲的硬盘，然后让他们把空闲的磁盘做RAID、划分LUN映射到AIX小机；再然后联系神码外包对AIX小机做在线文件系统扩容，如果AIX小机是HA架构，为保证两边都能识别新扩容的文件系统还需联系集群\HA是第三方外包进行保障;再接着为确保文件系统的扩容没问题，夜间的备份能正常进行还需要联系网络第三方和NBU备份第三方进行测试和观察。如果你要找的各第三方都有熟悉项目的工程师在，都能约到进行相应的现场和远程技术支持，那么OK一切顺利。否则，你就需要跟各第三方去沟通，联系合适的人来完成这次扩容。沟通来沟通去，最后人齐来事完了，你的身心俱疲。

  如果一个公司的IT项目是由太多第三方构筑实施的，那么处理问题的过程就会在不同第三方公司和本公司的流程中往复，这种重复沟通的弊病是很难避免的。有人说，沟通也是一种成本，这话真的不假。那么IT项目全部自己来构筑实施呢，当然可以减少很多这样的沟通和协调环节。但是企业的不断发展，IT基础架构和扩展面临的问题很少是孤立的。前端服务器、缓存加速层、存储备份、网络安全、云计算、虚拟化以及和业务和应用等等看似不相关的领域，其实紧紧关联在一起。一旦某方面出现问题，一定会在其他方面表现出来。这正是企业问题的复杂性所在，要么彻底根治，要么必然复发。


  看来流程管理并不是万金油，很多时候也让人伤不起。流程和灵活性有很多时候也并不成正比，流程管理也是一种渐进规范和完善的准则，无论管理者还是员工，也只能共同在流程中完善流程，在受“伤”中继续前行。