[原]IT价值评估

今天又有CIO朋友和我咨询IT项目价值定性定量评估的问题。这个问题关乎如何向老板申请IT项目立项、给老板讲明IT投资价值，也关乎IT项目验收、IT项目复盘总结分析、以及下一个IT项目的获得老板支持。这个问题也暗暗涉及到CIO的价值，如果IT说出不价值/感受不到显性价值，那CIO的价值又有几何，企业IT部门和CIO又怎能获得重视，CIO的职业发展阶梯就看不到希望。


我说这个问题需要体系性的分解才能获得答案。


一、业务痛点


我们不要因为自己身为IT岗，为了做事为了对得起这份工钱因而为了IT而做IT规划。要知道很多CIO都头疼明年IT规划要干些什么。


我们应该以理解公司战略、组织流程、业务痛点为起点，明确我们在企业总层面、在各业务线（产品研发/生产/营销/销售/服务）、企业各层（高层/中层/基层）到底有哪些业务痛点，这些业务痛点的层次和关联关系是什么，这些业务痛点的关键TOP 5是哪些，它们的引发根源是什么，如何由点串线成面的解决这些业务痛点，IT在其中能做什么支撑。


不要试图解决所有业务痛点，因为资源限制、因为时间限制我们无力解决，因为历史包袱限制我们也不可能推翻重来。企业是永续经营的，每个企业都有这样那样的问题，随着企业的不断向前走还会遇到更多的挑战和遗留问题，这个心态我们得有。所以我们只能打七寸打TOP5问题，让业务痛点聚焦、明确目标，这样我们可以在有限的时间有限的资源投入下有限的变革风险管控下得以解决问题。


二、解决方案


好解决的问题早就被人解决了、点上的问题也很容易被人解决掉，所以我们这些TOP 5的业务痛点需要解决方案才能解决掉。


一个业务痛点被引起，首先业务方面就需要做改进。可能过去的问题是因为组织/骨干就不支撑、人才就不配岗，这时候就需要重新梳理组织职责/组织重心，重新盘点人才重新进行人才归位重新进行骨干梯队组建；可能过去的问题是由于员工对业务背景不了解，所以对要解决的问题/解决的方法不认同、不清楚、不注重、没压力、没动力、不尽心（有人能做到尽责、有人连尽责都做不到、有人还怠工消耗资源、更有人起破坏负作用），这就需要重新梳理明确业务问题/目标/解决手段，还得进行有效的信息传递、沟通、跟进执行把控/检查；也可能过去的问题是由于高中基层职责不清晰、导向原则/要求规定不清晰不明确；也可能过去的问题是由于高中基层能力不足/动力不足、考核不合理/考核无导向原则、奖罚不给力不明确。


所以该业务部门需要调整、改进、提升的就让业务部门来主导进行，也立项，也明确项目业务痛点、项目目标、项目领导人、项目计划、项目监控组织、关键里程碑/关键成果/成果要求标准/成果责任人、项目验收。


对于IT擅长解决的业务痛点，那就由IT部门来再立一个IT项目，这个IT项目和上个业务项目是平行项目，都从属于一个完整解决方案。所以这个企业提升/变革的解决方案需要企业总体层面高层来领导、整合，而不应该由业务部门老大主导，也不应该由IT部门老大主导。所以说，企业变革/提升就是CEO一把手的职责。不要单纯认为是个IT项目，也不要认为IT有神奇能力可以解决业务问题（关于ERP优点、IT的优点我都曾经文章专门分析过，这些都是工具，只有用到合适场合才能发挥长处）。


但是大家也应该现实的知道，任何提升/变革都是有成本的，都是要投入资源的。所以企业要衡量好这样的TOP5 业务痛点，投入这么多，到底值不值？如果值，那就继续往下进展。什么叫值？那就是是否关注企业生死。如果说三年内不解决这个问题，企业自己耗死自己压死自己或者被竞争对手打死，或者企业业务会萎缩停滞，那这就需要干。但发现要三年解决这个问题需要耗干企业现在的资金、需要重塑现在企业的人，那...。


三、组织


这么吓人的TOP 5业务痛点，这么复杂的整合解决方案，这么多的人力/资金/时间投入，这么多的变革阻力/变革意识/变革传播沟通，这样的决策、把控就非一个CEO能够个人担当的了，就算企业的创始人老板都希望众人一起来慎重讨论、齐心合力出策、一起推进。所以必然需要组织。


这个组织需要在TOP 5 业务痛点决策确定、解决方案决策、执行过程把控/检查、解决方案执行完毕后验收/复盘分析都发挥作用。这个组织是一个立体的组织，需要高层/中层/基层骨干一起参加这个组织，分工配合。


四、验收标准


确定了业务痛点，也要立项了，那项目必然需要项目目标。首先要确定项目目标和业务痛点是否有着准确的对应关系。很多项目的失败或者没有发挥效果，就是定义项目目标的时候走歪路了，目标都错了，本来要攻A山头，现在你爬上B山头了，没用，吃再多苦死再多人，没用。所以项目目标、业务痛点的对应关系一定要经过组织来严格评审推敲。


有了针对性的项目目标，就需要对这些项目目标进行验收标准定义。这可是在项目立项时就要确定的，千万不能事情都做了，要项目收尾了才想起该怎么算终结。


定义验收标准，导向原则一定是要朝着业务痛点解决了没，而不要导向项目任务做完后该怎么衡量任务。很多人都犯了这个错，事都做了，但效果没有。没有效果，就是零，就是项目失败。


而验收标准，能定量的就定量，不能定量的就定性。定量的应该怎么算，这个计算公式要确定要审核决策，计算公式中的每个因子的范围要明确，不能对自己有利就算对自己不利就从范围中踢出去，这样的定量才能不至于弹性解读太大。


对于定性，关键是什么标准谁来定义，谁来验收。不同的定性指标，要找到最合适的定义人、验收人。不能一股脑都交给高层，不能一股脑都交给组织，那叫和稀泥。


五、验收方法


我们并不推荐一锤子定音买卖。很多企业变革/提升的失败就是开头很热闹：下军令状、做宣导做激励、领导鼓励讲话等等，过程中无声无息了，开会没人来/谁也不拍板/各扯各的皮，然后到项目结尾时来一帮人开个12小时会议扯淡假装进行一次拍板定音验收会，这都是自欺欺人。


我们推荐的是按阶段验收，但不要简单粗暴把阶段就定义为开头/中间/结尾，这又是糊弄人。要按关键事项/关键里程碑/关键成就来进行阶段性验收，每个阶段都有关键成果产出/关键成果责任人，都有阶段性验收标准，一个个阶段的进行验收、小回顾小复盘，这就和企业季度战略会议、半年度战略会议、年度战略会议的方式是一样的。


我在这里并没有给出大家常见的验收标准、验收指标，我也没有告诉大家如何显示IT价值、如何显性衡量IT价值，但大家可以根据这套方法实例化出自己的IT价值评价标准，只要我们的组织认同这样的价值标准、认同这样的投入产出，那我们就有价值。


咨询公司和软件公司可以协助、可以外来的和尚会念经、可以冲在前面开山、可以当作缓冲地带，但企业自己要为自己做主这个根自己要心里清楚。