案例 这个外部客户满意度调查流程是否有效
　　在我们一次对内部流程进行审计时，我们发现外部客户满意度调查流程的执行效果不够好。比如按照流程设计“当项目结束后7日内，对外部客户进行满意度回访”。但我们追查2006年全年记录，平均每月完成100个项目，但只有5 项做了外部客户满意度回访。更惊讶的是回访结果竟然被用来评估服务人员的绩效。
　　当我们提出这个流程存在的问题时，该流程的管理部门竟然这样答复“此项工作目前还不是很成熟，因为××等各种原因，目前只能做到5项左右的回访”、“本行业各公司外部客户满意度回访流程基本都是这样设计的”、“回访内容现在还比较笼统，所以基本上都是100%满意，不影响流程梳理要讲落地人都希望追求完美，这是值得鼓励的。但完美对于流程设计来讲却不一定总是好事。一些流程梳理项目在讨论流程线路设计时，虽然大家都明知设计的流程很难得到实施和贯彻，但基于正常逻辑判断和完美的期望，还是很难说服自己放弃，最后大家互相鼓励说“虽然这样实施起来的确有些难度，但工作的确一 般应该这样要求，先有后好吧。流程发布后先看看实施情况吧”。看似合乎逻辑的推理，但是一旦项目结束，是否真的还有人能持续关注流程实施情况？更可悲的是项目目标就是梳理出一个流程，而不是梳理出一个可执行的流程。结果项目组设计了一个理论上完美的流程，但最后却被实践抛弃。
　　这不是一个特例而是屡见不鲜。当然其中的原因是多方面的：一种可能是流程的确可操作性不够，这属于流程设计的问题；另外一种可能是流程的性质的确不属于那种可以自动融入日常工作中（如费用报销流程），而需要大量的引导和推动才能动起来的流程（比如流程优化建议管理流程，优化建议的处理机制有了，但如何让员工主动提建议呢），这属于项目组设定的目标没有包含搭建动力机制造成的。无论是哪种原因，设计的流程最终可以落地是流程梳理项目最基本的要求。
　　再次强调，流程绝对不是面子工程，更不是追求多方和谐的工具。
　　当然，你不能因此而降低流程设计的质量。我们曾经遇到过类似的案例，当我们发现流程没有得到执行时，流程所有者马上做的就是把流程文件调整到与实际运作一致。这绝对不是一个好主意。强调流程要落地的目的是让大家关注如何保证流程执行的问题，而不是强调流程制度要跟随实际运作调整，这有点颠倒两者的逻辑关系。