题目:IT规划,哪些企业的份内事
和“IT规划”培训主题相关:
题目:IT规划,哪些企业的份内事
作者:王玉荣(AMT-企业资源管理研究中心 专家顾问,luna.wang@AMTeam.org) 一次,和山东一家企业的信息主管交流,他和我谈起他们企业的这样一段经历,他们曾经邀
请一家管理咨询公司提供“IT规划”服务,管理咨询公司“进场-调研-制作
-高层
”之后,就结束了现场的工作,“IT规划”的咨询告一段落。 过了一段时间之后,企业信息部门偶然想查阅一下当时的IT规划报告,却发现无论如何找不到那个报告文件了,只好专门和那家咨询公司联系,请他们把文件再MAIL过来一次。
有点“业内笑谈”的意思。但我理解,这位信息主管谈这段逸事,不是仅仅自嘲自己企业的
文档管理很不严谨,背后,应该有他更多的无奈。我问他,当时这份IT规划的咨询报告进行了高层汇报,那么,高层领导中有多少人理解IT规划报告的主要内容、并进一步推动落
实了呢?他的回答是,哪里能走到落实,在听取汇报之前甚至包括之后,能把报告差不多看
上一遍的领导,都是屈指可数的。
结合这件事情,我们提出一个问题:IT规划,究竟是谁的规划?IT规划,是否就是意味着向咨询公司购买一份建议报告?
答案应该是否定的,我们说:ITIT 第一句话,IT规划是企业的内生需求,也就是说,IT规划不应该是一种外力加给的,只有
当企业自身深刻认识到IT规划的缺失所带来的一系列问题和后果,并继而从内在生发出对
信息化建设进行统筹规划的需求的时候,那么,IT规划才可能成功,IT规划所涉及的信息化建设的目标、范围、进度、里程碑等等内容,才会不再如上面例子中的只存在于咨询顾问
的报告上、只是在高层汇报时昙花一现,而是真正进入到相关领导的头脑思考中,真正成为
一个要被执行的“规划”,真正去指导信息化建设工作的开展。至于IT规划的缺失所带来的一系列问题和后果,已经有了不少文章探讨这个主题,本文不再详细展开。 关于第二句话,值得深入探讨一下。我们知道,“计划”是一项基本管理职能,企业里有采
购计划、销售计划,围绕“计划”这一管理职能可以开展各项管理工作,这已经为人所熟知。
“规划”也是“计划”的一种,只不过是一种站在更高层次、更加宏观的管理职能,那么,
在我们企业的信息化部门或者战略规划部门,是否在部门职责定义中已经明确了这项职能:
“IT规划”呢?
也许有规定,但未必真正开展。
企业里熟悉可能是财务预算管理的常规工作,比如,每年10月份,各部门草拟来年预算,财务部门综合汇总以后,返还各部门修订(实务中这里有个讨价还价的反复),反馈上来以
后,再次汇总报企业决策层批准,一月份批复、开始执行,来年的财务管理各项工作受到预
算的制约,可以每月比较预算和实际发生的差异,年底总结一年的预算执行情况,开展一个
新的循环。
而IT规划也应该作为信息化管理工作的基本职能,写在相应负责部门(具体可能是战略规
划部门、IT部门,有的企业建立了专门的IT规划部门)的部门职责当中,成为企业的常规
工作。比如,我们把这个负责部门成为A部门,那么,在一个规划周期的起点,A部门征求其他相关各部门意见,草拟规划,与其他部门交流、征求反馈意见(实务中这里有个“管
理语言”与“IT语言”在这里不断碰撞、沟通的过程),根据意见修订以后,汇总报企业
决策层批准,批复后在企业内广泛宣传,推动达成企业各方面对信息化建设的共识,这个规
划周期内的信息化建设工作受到规划的指导和制约,规划周期的中间可以以一定频率对规划
进行必要的、适当的修订调整,到了规划周期的末尾,总结规划的执行情况,开展一个新的
循环。
咨询公司在这其中又发挥什么样的作用呢?可以和A部门一起启动并开展IT规划工作,帮助A部门自己建立起IT规划的能力,推动企业这个循环的形成,在每个规划周期和中间修
订点,为企业自己制定的IT规划出具专业参谋意见,而不是:越殂代疱、代替企业做出每
一次的规划。
那么,一个规划周期的长短是多少呢?由于企业的IT规划应该服从于企业总体战略规划,
为企业总体战略规划服务,所以,如果企业的战略规划周期为5年,如国内不少企业开展的“十五规划”,IT规划的规划周期就以短于5年为宜。同时,一个比较复杂的IT项目建设往往要跨年度,而IT规划中可能包含多个IT项目,所以,IT规划的规划周期就以不短于2年为宜。结合到企业所在行业的具体特质,有的行业信息化应用日新月异,有的行业信息
化建设速度比较缓慢,我们说,企业的IT规划周期因具体企业的不同而不同,一般以2-4年为宜,中间可以每年进行适当的修订调整(ROLLING)。 还可以深入下去,哪些企业更应该把IT规划作为一项常规工作来开展呢?就象预算管理的
循环一样,企业在最初期的阶段,钱少人少管理简单,没有预算管理循环也没有太大的问题,
而当企业发展到一定规模,再没有预算管理循环、没有一个好的预算管理循环,则一定会给
企业发展带来阻碍。所以,我们提出的问题是,哪些企业更应该把IT规划作为份内事呢?
具体地,这个问题的回答,可以从IT规划成熟度模型进行
,细致分析不同成熟度的划
分、在不同的成熟度层次信息化各项工作的比重等,还可以从CIO的职责结构进行分析,细致探讨不同行业、企业不同发展阶段的CIO的工作分配比例以及IT规划在其中的比重。
本文概括地来回答这个问题,如果一个企业符合以下三个特征,那么我们认为,该企业有较
高的必要性,建立IT规划常规工作循环:
第一,企业战略规划循环已经基本建立,信息化对推动企业战略实现、业务发展的作用已经
得到企业领导班子的基本认同;
第二,企业有信息化建设的专门部门和专门队伍;
第三,企业已经建立了一些基础平台和局部应用,开始准备在跨部门应用上进行投资,并希
望从该投资中获得收益。
这三个特征分别从“战略”、“组织”、“技术”的角度切入,我们可以具体说明一下。 第一个特征,战略的角度。IT规划说到底是要解决一个IT战略指引的问题,而IT战略又和企业战略、业务战略密切相关,企业战略的指向给出了IT战略的朝向,所以,一个基本建
立了企业战略规划循环的企业,企业战略比较明晰,企业领导班子有一定的战略规划和推动
执行能力,这就为IT战略的明晰并落实执行提供了基础条件。这里有一点提示大家注意,
IT战略作为子战略,更多的不是企业战略中的“一块”而是“一层”,也就是说,IT战略不能和营销战略、渠道战略等割裂独立开来,而是和这些子战略有机融合,是这些子战略得
以实现的重要支撑层面。
第二个特征,组织的角度。企业信息化建设需要有专门部门和队伍,而不是零散地、靠某个
个人在开展,这样,就为企业自主IT规划能力的形成提供了组织保证。 第三个特征,技术的角度。企业IT建设还处于本地化应用、局部业务范围应用的时候,IT规划的作用还没有完全凸现,企业自身也处于“在游泳中学游泳”的阶段,而企业IT建设到了全局业务应用的时候,IT规划的作用就凸现出来,IT规划的缺失将引发一系列问题,
如管理与IT的脱节、信息孤岛、集成泥潭等。
我们再从IT规划所包含的内容来看,也很好的呼应了这三个特征。一个好的IT规划,应该战略上有感召力,和企业战略规划有效结合;一个好的IT规划,应该组织上有可操作性,
对IT治理结构的建立完善、IT组织资源的更有效配置做出安排,明确该规划周期内各项重
点工作,明确计划要求和里程碑,制定投资预算,从而落实资源保障,使得该规划工作内提
出的工作目标有可行性;一个好的IT规划,应该和业务息息相关,对企业业务发展给出有
利支撑,IT规划的内容包括了对关键业务的关键作用点分析等。
所以,企业应该建立正确的认识,IT规划是企业的份内事,企业当满足上述“战略、组织、
技术”的三项特征的时候,应该考虑是否把IT规划作为常规工作循环开始建立,从而把企
业的信息化建设推进到一个更高的“战略、组织、技术”层次和水平。
和“IT建设的项目管理”培训主题相关:
题目:谁应该承担项目失败的责任?
作者:王玉荣(AMT-企业资源管理研究中心 高级顾问,luna.wang@AMTeam.org) 在我们这个行业,做过一段管理咨询与IT服务实务的人,往往都会觉得实践是鲜活的,经
典管理理论中的东西用不上,或者说不好用。而当在实务中碰到各种烦恼的问题而不得其解
的时候,回归经典却可以是一条有效的途径。
近来由于看到很多管理咨询项目成败的讨论,引发我的一些思考,于是,想到对系统工程领
域做了一些研究,和这个领域的专家进行了一些专门的沟通,结果发现,颇有借鉴意义。 系统工程领域也是博大精深,在对系统的概念、系统工程学科、系统工程方法论、各种系统
建模和分析技术等有所了解以后,可以发现,由于各种管理咨询与IT服务项目也符合“系统”的定义,而且是属于“大规模复杂系统”,所以系统工程中的一些原则和方法也是适用
于管理咨询与IT服务的各种项目。
比如,系统工程中谈到一点:
大家都知道麦肯锡和实达纷争,各家咨询公司在项目里有时也被客户“提示”:“这个项目
关键在你们,咨询公司最后是要负责任的。”
而系统工程的经典理论里,是这样阐述:
在系统工程中,涉及到以下几种人员:(为阅读方便,我们用
来叙述)
决策者 能够采取行动去调配资源以改变系统的内容。承担风险和成当然是“企业一把手”
败的责任。 了 提出问题者 对某种态势感到不安,领悟到现状和目标不适应,或模糊地可以是售前阶段企业
感到事情可以做得更好些,但往往不能明确表达那种不安的的参与决策者,也可
心情和设想,也说不清应采取的解决方法。可能不是决策者 以是售后阶段企业的
业务主管 委托人 接受决策者的旨意,委托他人从事某项系统分析工作,起到企业方项目经理
决策人和系统工程人员之间的中间人作用。有时可能决策者
就是委托人
系统工程是专业人员,应处于不涉及自身利益、没有偏见的位置,在咨询顾问,一定程度(分析)人回答委托人、决策者的问题时,既不用说“同意”,也不必上也包括企业方的项员 说“不同意”,只需说“知道了” 。了解决策人和委托人目小组。从左栏可见,
的目标及其对问题的理解和对系统分析的期望。提供各种分咨询顾问既需要了解
析信息、观点和建议,为决策者提供判断的参考和依据。不决策者的意见,也需
对决策后果负责。有经验的系统工程人员往往建立了这样的要了解委托人的意
心理准备,即决策者和委托人一开始实际上并不明确他们自见,他们的意见也可
己的目标究竟是什么。 能是不一致,这时候
就需要咨询顾问进行
有效的沟通与协调。
“决策者对成败负责,系统工程人员不对决策后果负责”,这是经典给我们的观点。有道理
吗?
结合实践来看,特别是结合中国咨询市场的成熟度来看,不完全对、也不完全错。这里面,
既有服务契约关系的考虑,又有客户与咨询机构双方诚信的考虑。更何况,国际咨询行业过
往通行的“不按成功取酬”的惯例,也不是在100%的应用,有些咨询机构已经开始提供伴
随着连带责任的契约服务。
实践在不断发展,也有各种不同的争议,不管怎样,借助以上的经典理论,为我们更好的理
解、做好IT建设的项目管理提供了帮助。
结合IT建设项目的实践,我们还发现了这样的现象,在一个项目进行的过程中,咨询顾问
总是希望与客户在最短的时间内就达成共识,但偏偏事与愿违,咨询顾问有时候苦恼:“客
户怎么好象是反反复复、粘粘乎乎的”,比如,开始提需求的时候和顾问表达了三点意见,
顾问开始做
以后又告诉顾问两点详细说明,看到顾问的方案以后,客户好象受了启发,
一下子又冒出了五点六点的需求要顾问实现。
所以,我们在这里想继续挖掘一个问题: 还是可以借助系统工程的原理来分析。系统工程的经典理论认为,系统分析过程的典型行为
可以概括为下图所示的逻辑结构。
图1 系统分析过程的逻辑结构
它包括5个行动环节:(1)阐明问题;(2)谋划备选方案;(3)预测未来环境;(4)建模和估计后果;(5)比较备选方案。
整个过程可以归纳成三个阶段:
, 阐明问题阶段:其工作结果是提出目标,确定评价指标和约束条件; , 分析研究阶段:提出各种备选方案并预计一旦实施后可能产生的后果; , 评价比较阶段:将各方案的评价比较结果提供给决策者,作判断抉择的依据。 下面一句话就能呼应我们开始提出的“反复”问题了:
(注意图中的几种必要的信息反馈回路,您如果感兴趣的话,可以结合图中的每一个箭头思考一
下,这个箭头对应于一个管理咨询或者IT服务项目中的什么)。 所以呢,出现这样的情况就不奇怪了:决策者在弄清方案的后果以前,往往难以有把握地提
出某项目标;在发现某些后果后有可能增加约束条件,筛选备选方案,调整方案的政策参数
等。
因此,系统分析过程中的一个重要因素就是分析人员和决策者之间的沟通与对话。不断对话
其实意味着决策者考虑了问题的各个方案,自我感觉亲自参与了分析过程,容易接纳分析结
论,不至于因为出乎意料而拒绝。
因此,反复是正常的,关键在于,如何在反复中推进项目的良性发展。