很多企业在变化管理上，都会成立一个变化委员会或者指派一位变化经理来从各个商业部门收集关于变化的想法和建议。然后变化要经过一个审批流程。获得通过的建议或者想法就会被执行。被否决的意见就会被扔进垃圾桶，只有在以后的什么时候才会有机会重头再来。所有的变化，无论是被批准的还是否决的，都会被记录在案，这样将来经理或者检查者就能够根据记录证明某一个想法已经获得了应有的重视。在一个良好的系统，被批准的变化日志就成为变化控制系统中变化的记录，理论上允许任何相关的部分进行访问。
这些在纸上的记录看起来都非常好。实际上，变化管理系统通常只有在变化周期的末端才起作用，它记录了谁做出的决定由谁来在哪些领域内执行。在应用开发过程中，这些权力落入一群开发人员和系统设计师之中。在系统中，系统管理员和系统工程师拥有变化的权力。如果是商业系统，每一个参与者都能够影响与自己相关的流程。
如果变化经理试图拒绝改变，他就会剥夺其他人的权力。如果决策已经做出了。变化经理可以批准执行，但是由于没有控制执行者的权力和足够的影响力，他们不能够阻止一个变化的发生。这就让很多变化经理沦为记录员，徒劳无功地跟踪着系统的每一个变化。
在很小的、简单的环境里可能会造成一些问题。每一个执行变化的人都理解这个系统里其他的选择。而在比较复杂的环境里，人们只了解自己的工作。只有非常老练的人才能够理解同自己相关环节的情况。
另一方面，变化经理应该对于商业系统（或者是应用、架构）有全面的理解和认识，还需要对商业结构有深刻的理解。LOCalHOST他能够看到变化在日常工作中的效果。他能够看到变化带来的更多的影响。换句话说，他应该有能力判断是否应该让某一变化发生，但是他缺乏使用这种能力的权力。
我知道起码有三家公司是it部门来扮演变化管理的角色，并负有实现变化的权力。这些企业投入大量人力、物力实施erp项目。他们也都经历了“erp阴影”，不过这是另外一个话题了。
变化管理
那么我们作为经理，如何才能够管理变化呢？这就要引用一句晦涩难懂的话了：今天是古老的历史。如果我们强迫我们的变化经理去在接受或者拒绝变化之间选择，我们就剥夺了他们有效管理变化的能力。
今天是我们所有过去历史结果的总和。每一次当我们扩展我们的影响力、发挥作用、或者使用权力，我们就做出了一点点改变，而这些改变将对未来产生影响。如果我们想要控制变化，那么我们就需要找到合适的地方使用我们的工具，来进行一些微小的变化，帮助使明天更美好。
对于变化管理，我建议我的客户关注错误的事情。在我所见过的变化管理系统中，有十分之九的系统既关注记录已经由执行者完成的变化，也注意赋予控制者足够的权力来进行变化决策。第一个方法是把它当作查看方式来管理：它能够告诉我们发生了什么但是却没有影响回报。第二条则经常在变化控制者和变化执行者之间造成怨恨（比如basis团队和app dev团队之间），除非变化经理具有丰富的实践经验。
如果我们把关注的焦点集中在变化领导上而不是管理上会怎样呢？变化管理如果更注重咨询而不是财务计算会怎样呢？我们认为会出现以下状况：
绝大部分变化经理都把大部分的时间用来记录已经发生的变化。但是如果他们能够同关键变化决策者一起工作（比如开发领导人、关键架构领导、业务部门项目领导）来走在前面呢？这些人通常对于在自己周围发生的变化有很大的影响力。如果变化经理能够通过沟通或者人格力量来建立一个影响力网络，他就能够在变化发生之前对他们产生影响，而不仅仅是事后进行记录。
当我们采用这个主意时，有些事情也就变得清晰起来。具备这些技能的人应该成为一个领导、管理者和技术专家。他必须使用特别强的沟通能力和在不同层面上对系统进行交互的能力。而且他要能够同关键影响人之间建立信任，这取决于他们的专业技能，还受到他和关键人物相互之间关系的影响。
为了将来的工作，我的客户意识到他必须赋予变化经理真正的否决权，就像在他的公司里其他一些人所拥有的那样。这个权力帮助建立影响力，推动咨询工作的顺利进行。如果谨慎使用这种权力，配合变化领导人就比和他对着干要好得多。如果随意使用而且不体谅对方的立场，那么那些领导们就会回到他们自己的方式中去，而且宣称他们这样做是“为了公司好”。
完全实现某种想法需要花费一些时间。它当中的一些元素已经存在于这个客户的公司里；他需要建立完成这项工作的其他一些部分。采用这种方法迫使他重新考虑目前的员工在变化管理里的角色。目前处于这个职位的人缺乏领导能力，无法采取一些更有效的方法。