CIO的烦恼

    这两天，信息部总监kevin很是郁闷。

    作为企业的CIO，他从最初的信息化建设开始就参与其中，几年下来，大大小小的业务系统上线了不少，既减轻了各部门的工作压力又提高了工作效率，kevin领导的IT部也得到了公司领导和业务老大们的一致赞赏。

    但是，不知从何时开始，他们受欢迎的程度开始大不如前，甚至在众人眼中一下子从解救众人于水火的“英雄”变成了增加员工负担的“罪魁”，巨大的落差让kevin有苦难言，无处话凄凉。

    这不，连老板都在他汇报工作的时候语重心长的说——

    “IT部门这两年的工作成效大家都有目共睹，也为公司的发展作出了很大的贡献，但是最近好像你们部门的满意度有所降低呀，kevin你可不能自满啊，还是要向Simon在的时候那样脚踏实地的工作才行啊。。。”

    面对老板的恳切，kevin低头无语，自己的辛苦付出却换来这样的局面，明明自己比Simon更加努力，却被老板认为骄傲自满，真比窦娥的姐姐还冤啊。

    火山口的挑战

    说来话长，当初刚开始信息化建设时，kevin的顶头上司Simon，也就是当时的CIO并没有做过整体的IT规划。他关注更多的是网络建设和硬件支撑，至于软件的选型和实施，Simon则简单的认为只要花钱买回来用就是了，就算是比较复杂的系统，顶多也就是请来几位咨询顾问帮助实施，只要系统上线了，自己的任务也就完成了。

    Simon的做法在初期系统还比较少的时候的确很管用，kevin他们在Simon的带领下，迅速的让企业在IT上的投入初见成效，而他们只需要专注于硬件和网络维护，再加上定期的数据备份，以及在业务部门提出系统需求后帮助他们完成选型和实施，便轻而易举的赢得了其它部门很高的满意度。

    但是，随着企业的不断发展和应用系统的不断上线，越来越多的应用系统交织在一起，共同构成了业务流程的重要支撑。用户对应用系统的要求已经不再局限于“能用”和“不出错”了，已经上升到了“好用”、“易用”和“有价值”的高度。

    面对新的挑战，kevin在老领导离开后显得有些手足无措。

    由于初期缺乏整体规划而引起的系统之间的数据格式不兼容、接口连不上、软件和业务不能很好的结合等问题开始纷至沓来，比如，销售系统现有的流程不能适应新业务拓展的需要；店面的装修物料申请必须在店面管理和市场费用两个系统内分别重复录入；采购系统和库存系统中查询到的物料库存数据存在差异；服务系统的产品信息长期滞后于销售系统导致无法为顾客提供最新的技术支持。。。

    kevin不再是人见人爱的IT英雄，转而成了各部门的出气筒，面对汹涌而来的不满和抱怨，kevin带着手下马不停蹄的调整系统、同步数据、重做报表，想尽一切办法满足曾出不穷的变更和需求。但是毕竟巧妇难为，尽管他们竭尽全力，仍然有很多系统由于升级费用昂贵、公司不愿额外付费而升级无望，kevin和他的团队由于对软件的数据结构一无所知而无能为力。

    还有一些系统由于设计时考虑不周，限制了后续的变更和改进，或者是运行的平台和数据库不同而限制了不同系统之间的交互协作，使不同的应用系统成为所谓的“孤岛”，而且还是一座活动的“火山岛”，不知道什么时候就可能集中爆发。。。

    信息化之困

    企业的信息化建设缺乏整体的规划，常常遵循着First come,first serve的原则，哪个部门先提出需求，就先给哪个部门上系统。

    但是，由于业务部门关心的是自身的利益，提出的需求只涉及本部门所管辖的业务，很少会站在企业的角度去思考和设计整体的流程，以及与其他部门之间的协同配合。如果缺少一份完整的IT规划，企业在信息化过程中就很容易陷入条块分割的困境，规划上的局限将为后续的系统建设埋下隐患。

    举个例子，信息部门在为生产部门选择制造执行系统时只考虑了向前的兼容性，即MES系统与现有的库房系统的接口，却忽略了为后续系统留下灵活的接口，导致半年后上线的销售系统无法与其共享数据，造成了从销售订单到生产订单之间自动转换的障碍，以及销售系统与库存系统间库存数据实时联动的困难。

    总而言之，缺乏合理规划的信息化建设，越是后面上线的系统，越难以与现有系统实现数据共享和系统互通，先行者的一时偷懒，造成后来者的举步维艰，陷阱无处不在。

    此情此景，令CIO们大呼头痛，却又束手无策无可奈何。

    明明每个系统上线之前，都进行了深入细致的需求调研和系统选型，甚至不惜聘请顾问帮助系统实施，而且系统上线之后也确实顺畅的运行了一段时间，可见系统的功能是符合业务部门要求的。可每当CIO以为万事大吉一切OK了，麻烦却找上门来，不是业务需求变了要求变更系统，就是与其它系统配合不畅，要么就是有些问题开时没考虑到，等到应用了一段时间后才被发现。

    这些问题一个比一个重要，一个比一个紧急，又一个比一个棘手，这个时候的CIO们真恨不得自己有三头六臂七十二般变化才好，否则哪来那么多精力同时应付这么多问题？于是CIO只好想方设法的打补丁绕路走，先解决燃眉之急再说。

    在无数次焦头烂额之后，CIO终于坚定决心：若是日后再上新系统，一定要把需求分析做得细致再细致，深入再深入，严谨再严谨！可是，言犹在耳，类似的情况却一再的发生，不断的重演，屡杜不绝。

    追本溯源

    为何企业的信息化在开始的时候总是顺风顺水，到后来却困难重重呢？

    缺乏IT规划当然是原因之一。企业的信息系统在建设之前缺乏整体考量，尤其是对应用系统的建设更是缺乏连贯的建设规划，因而导致混乱。可是，毕竟还是有许多企业是作了规划的，甚至还有CIO把IT规划的实施路线图挂在办公室时刻提醒自己，却仍然避免不了行进到路线图后端时的举步为艰。

    这个问题讨论起来很复杂，每个企业的情况也各有不同，不可能一一点到，在这里试着从“系统思考”的角度来分析，看看到底根源何在。

    首先，“局限思考”限制了IT建设的视野。
彼得•圣吉提出的第一个组织的学习障碍即是局限思考。他认为，当组织中的人只专注于自身的职务之上，他们便不会对职务之外的任何结果有责任感。遇到问题时也只看得到与自己有关的部分，只从自己的利益出发采取措施，对此举可能对整个组织造成的影响毫不关心。而且，就算他们对结果感到失望，也察觉不出何以如此。

    这种现象在IT规划和信息系统建设中普遍存在。

    比如kevin的公司，销售部下面管理着遍布全国的门店，这些门店在新品上市或者节假日促销时要对店面进行特殊的装修和陈列，因而会向销售部申请一些装修用的物料。

    销售部在很早就建立了一套管理控制系统，把与店面相关的大事小情都纳入了这个系统，装修物料也不例外。而市场部自己也有一套费用管理系统，管理着公司的营销费用。本来两个部门各管一摊，井水不犯河水，可是突然有一天，财务部通知说所有的店面装修费用不再计入销售成本，改入营销费用。于是市场部的老大找到kevin，要求在原有的费用管理平台上增加一个装修物料的管理模块，供店面使用。

    新模块运行了几个月之后，店面人员开始抱怨连连，因为他们必须把同样的申请在两个系统里重复上报，硬生生的增加了一倍的工作量，虽然量不算大，但毕竟心存不满。

    kevin试图协调两个部门，但市场部坚持营销费用必须走市场部的系统，销售部则认为店面属他们直接管辖，必须通过店面系统申请，否则无效，双方僵持不下，问题悬而不决。为了息事宁人，kevin只好找到老板出面，强行要求店面人员必须在两个系统内同时提交物料申请，算是暂时平息了争端。

    但是时间一长，销售部开始抱怨kevin的系统增加了工作量，妨碍正常业务的开展；市场部则开始抱怨新开发的模块推行不下去，店面提报的申请不及时而且漏洞百出，可怜的kevin捞了个费力不讨好。

    这个例子其实很有普遍性，看似简单的一个小问题，单独看是一回事，同其它因素放到一起看就是另外一回事了。这就是所谓的“合成谬误”，对个体而言正确的事情，对总体而言却未必正确。

    从市场部的角度看，把营销费用集中管理并没有错，从销售部的角度看，对店面进行集中管理也没有错，两件分开看都正确的事，放到一起却引发了冲突，原因就是两个部门都陷入了“局限思考”的陷阱，只考虑自己的管理需要而忽略与其他部门之间的业务交叉，属于典型的“只见树木不见森林”的本位主义思想作怪。

    其次，“时间滞延”增加了预见问题的难度。
时间滞延是指一个变数对另一变数的影响，需要一段时间才看得出来。未被察觉的时间滞延会引起不稳定与运作失调，特别是滞延的时间很长的时候；未经思考的积极行动常产生相反的结果，它会产生不稳定与振荡，使你无法很快趋近目标。

    这种现象增加了预见问题的难度，往往表现为过于激进的纠正措施和矫枉过正的结果偏差。

    比如在上面的例子中，市场部的新模块上线几个月后，重复录入的问题才爆发出来，这就是时间滞延的典型体现。这个现象使问题变得复杂，而且很难提前预知，kevin尽管按照市场部提出的需求做了调研，但由于没有预计到对店面人员工作量的影响，因而在问题发生的时候显得手足无措十分被动。

    因此，kevin在制定补救方案时，为了迅速见效，又采用了一种虽然立竿见影但是明显过激的做法——寻找高层支持，强迫店面人员重复录入物料申请。虽然这样的行政命令平息了两个部门间的争执，但矛盾依然存在，引发问题的根源并没有消除，kevin就像坐在火山口上，时刻面临火山爆发的危险。

    最后，“舍本逐末”降低了彻底解决问题的机会。
舍本逐末是指使用一项头痛医头的治标方式来处理问题，在短期内产生看起来正面而立即的效果。但是这种暂时消除症状的方式使用愈多，治本措施的使用就会愈少，一段时间之后，就会忘记对“根本解”的寻找，而导致对“症状解”的更大依赖。

    越是容易找到的解，越不是真正的杠杆解，在信息系统建设当中同样如此。

    比如kevin之前的领导Simon，就是因为考虑到编制一份目标明晰、符合公司战略的IT规划，必须投入大量的精力，开展细致的调查，多方征求意见，全面评估方案，这件事情做起来费时费力，而且短期内又很难见到效果，企业领导不愿意做这样大的投入，Simon也不愿吃力不讨好，于是浩大的信息化建设就在没有任何图纸的情况下，匆忙开工了。结果可想而知，看kevin现在的境遇就知道了。

    信息化刚开始时，由于系统少、用户少、时间滞延等原因，问题不会很快显现。企业的领导和CIO还会得意的以为：瞧，没有规划不是一样能干得好？于是，无论是企业的领导，还是从前的CIO，甚至是Kevin都这样肆无忌惮闭着眼睛往前走，直到问题像火山一样的突然爆发。

    破解之法

    针对上述的三个方面的原因，结合kevin所遇到的麻烦，我们分别提出如下的应对之策。

    对策一，全局考量，既见树木又见森林。

    破解局限思考的谜局。

    kevin在处理市场部提出的新需求时，只局限在市场部内部的流程设计，却忽略了与销售部之间的职能交叉，导致实际操作当中信息的重复录入和一线员工的工作量加大，最后不得不动用行政命令强制执行，虽然暂时平息了冲突，却为日后系统的稳定运行埋下了隐患。

    如何摆脱局限思考的限制呢？对kevin来说，形势已经十分严峻，Simon时期种下的祸根已经开始慢慢显现，这个时候，去抱怨前任的不负责任和缺乏远见已经毫无意义，而且企业的领导者也不会乐意看到一个只会抱怨束手无策的CIO。

    当务之急，kevin必须迅速掌握现有系统的实际情况，以前的缺失已是既成事实，无法改变，但后续还会有若干项目要上马，必须在对全局把握整体考量的前提下进行，不能再重复以前的老路了。

    首先，绘制企业的信息化地图。就像“知识地图”一样，把企业已经部署的、各个部门正在使用的系统进行彻底的清点，了解其主要功能、使用者、覆盖的流程、与其他系统的交互等基础信息，把陷入混乱的信息化建设理出一个头绪，这样kevin在开展工作时才能有的放矢。

    其次，提高需求评估的层次。业务部门由于自身的专长和关注不同，考虑问题难免会有这样或那样的局限，容易从自身的利益和方便出发提出信息化的需求。kevin在评估业务需求时应该注意跳出某个业务环节的局限，站在企业的高度去考虑系统的规划，不能再像以前一样，业务部门说什么kevin就做什么。

    再次，管理业务部门的需求。也许kevin对市场部的了解不如市场总监深入，但是谈到对销售、财务等业务的了解程度，kevin却有着自己的优势。面对业务部门的抱怨和不满，kevin应该充分利用自己对不同部门的业务流程的了解，从信息系统建设的整体规划方面提出自己的建议，说服业务部门顺从企业的整体利益，对各自部门的流程做出必要的调整，而不是依靠冷冰冰的行政命令来强制执行。

    对策二，谨慎推进，加强风险管理。

    舍弃急功近利的心智模式。

    “吞两颗阿司匹林，然后耐心地等。”我们都知道如果头痛需要服用阿司匹林，你不会每五分钟吃一颗阿司匹林，直到头痛消失为止，你会耐心地等候阿司匹林产生药效，因为你知道阿司匹林要迟延一段时间以后才产生作用。

    信息系统在实施过程中也有时间上的延迟情况。kevin在市场部的功能完成后就立即推广全面使用，而对工作量的影响事前估计不足，才引起店面人员的强烈反弹。所以，kevin在全面实施某个新系统或者新功能之前，应进行充分的内部测试和局部试运行，并对全面推进后可能存在的风险进行评估，制定应对措施。

    具体来讲，kevin可以在功能开发完成并通过内部测试后，先在离总部较近的几家店面进行试点，以便在向全国的店面推广使用之前及时发现问题。这样既可以避免由于考虑不周导致的潜在缺陷，也可以避免由于时间滞延导致的混乱影响面过大的弊端。

    对策三，耐心等待，寻找有效的“根本解”。

    建立共同愿景，屏除短期对策。

    最容易找到的解决方法，往往不会是最有效的解。在彼得•圣吉的理论中，只有找出有效的杠杆解，才能真正解决问题，尽管那可能意味着花费更多的时间、承受更多的压力，但如果屈从于容易见效的短期对策，长期而言，会产生愈来愈严重的后遗症，使问题更加恶化。

    无论是kevin还是他的前任Simon，他们都妥协于方便获取和短期效益的诱惑，而放弃了寻找长期有效的“根本解”。因为IT规划耗时耗力，为了尽快取得成效和争取老板的更大支持，Simon选择了在缺乏规划的条件下提前开始信息化建设；因为信息化现状复杂和难以把握，为了尽快满足市场部的业务需求，kevin选择了按照市场部的需要开发新模块；因为协调多个部门的流程优化十分困难，为了尽快平息争端和推进系统应用，kevin选择请老板颁布命令强制店面执行。

    以上种种，都是现实中放弃寻求“根本解”，屈从于“短期解”的例子。表面上看是kevin等人在现实的压力下，不得不采取了舍本逐末的方式来解决问题，实质上，是由于企业内部缺乏一个清晰明确的共同愿景，因而导致在压力下轻易放弃寻求“根本解”。

    这个问题依靠kevin的一己之力解决起来可能会有一些难度。因为，只有企业内部的所有部门都专注于同一个长期的、共同的目标，并为此不懈努力，才能够不被短期利益所惑，在出现危机的时候，坚持采取长期有效的解决方案。尽管它可能无法短期见效，尽管它可能损害某个部门的短期利益，但它可能是惟一持久见效的方式。只是，关于企业的共同愿景，并不是kevin一个人能够解决的，需要从领导到业务部门，以及一线员工的共同努力。

    风物长宜放眼量

    企业的信息化要想取得成功，必须对整个企业的应用系统建设有一个统一的、合理的、可靠的规划。因此，作为这个蓝图的制定者，CIO首先需要具备系统思考的能力，要从全局把握各个系统的建设顺序、相互协作和互联互通等问题，使它们成为一个有机的整体，在企业内顺畅的运转，为各个部门提供有效的服务。
那么，担负起这个“系统思考”重任的，为什么是CIO而不是其他业务部门的领导者呢？大概有这样几个原因决定了CIO才是最适合这一任务的角色。

    首先，由于CIO负责的是所有业务部门的应用系统建设，因而有机会接触到多个部门的业务内容，对内部业务的全面了解可以说无人能及，而系统思考正需要将问题放到企业的大环境中考虑，因此，CIO更适合这一角色。

    其次，CIO领导的是技术部门，一般企业都会将其作为内部服务部门来看，不象其他业务部门肩负着各种任务和目标，因此少了许多局部利益的限制，少了许多本位思想的局限，更容易从全局的角度思考问题。

    最后，CIO的技术背景有助于掌握系统分析的方法。系统分析本身源自“系统动力学”原理，属于自然科学和社会科学的交叉学科，而扎实的理工科基础更有利于掌握这一方法。

    因此，CIO作为“系统思考”最恰当的人选，应当自觉的在IT规划中使用“系统思考”的方法，动态的考虑各个应用系统在企业整体环境中的作用和局限，从长期发展的角度来规划信息系统的建设路线图，避免因急功近利的思想导致混乱，避免对局部利益的追求引起矛盾，避免因不负责任的态度引发风险。 
 
    背景介绍

    系统思考是彼得•圣吉在《第五项修炼》中最为推崇的一项修炼，是“看见整体”的一项修炼。提倡用整体的眼光看问题，不只看到问题的现象，还要看到问题所在的整个系统。可以帮助我们探究隐藏在它背后的系统结构运作的巨大力量。

    时间滞延是构成系统语言第三个基本元件（另外两个是不断增强的回馈和反复调节的回馈）。时间滞延是在一个变数对另一变数的影响，需要一段时间才看得出的情形下发生的。未被察觉的时间滞延会引起不稳定与运作失调，特别是滞延的时间很长的时候，未经思考而采取的积极行动常会产生与预期相反的结果，产生不稳定与振荡，使你无法很快趋近目标。

    “舍本逐末”是彼得•圣吉提出的系统基模之一。该结构通常有三个线索可循：第一，有个长期逐渐恶化的问题，虽然偶尔它似乎暂时好转；第二，系统整体的“健康”渐渐恶化；第三，无助感与日俱增。最初人们开始感到沾沾自喜，以为他们已经解决了问题，但是最后觉得好像自己是被害者。

    系统基模揭示在管理复杂现象背后的单纯之美，当我们学会辨识更多的基模，在面对困难的挑战时，就可看出更多隐藏的杠杆解（杠杆解是指最省力的解），并能更有系统地将其说明给别人了解。

    系统观点的最大功用是统合跨越所有领域的知识。系统基模的目的是重新调整我们的认知，以使我们更能看出结构的运作，和看到结构中的杠杆点。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。