13

谈新IT背景下的CIO角色定位和知识体系构建(200829)

 3 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102z909.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

对于企业CIO岗位角色定位,在网上有很多的文章都谈到,自己博客在前面也谈到过CIO应该有的知识技能储备和在新IT架构下的角色转型升级,今天再结合新IT背景来谈下CIO角色定位。

首先我们还是简单总结下CIO应该具备的知识技能储备,要做好企业CIO不是一件容易的事情,往往需要 业务,技术和管理三方面的能力储备 ,体现的是一个综合能力,各方面都需要均衡而不要出现明显的短板,只有这样你才能够更好的胜任这个岗位。

  1. 业务储备: 企业核心价值链,包括研发,供应链,财务,市场营销核心业务线知识
  2. 技术储备: 信息技术知识的基础储备,包括IT基础设施,软件工程,ITIL运维和管控治理
  3. 管理储备: 最基础的是项目管理储备,更加重要的是对人的管理,管理机制建立

什么是新IT背景?

简单来说就是新的业务需求和目标下对IT新的要求,简单来说就是IT需要更加灵活,敏捷,能够快速的响应和支撑业务,同时能够更加高效,更加自动化以实现低成本运作。而我们谈到的微服务架构,DevOps等都是新IT背景下的支撑技术。

对于企业内的IT部门,特别是要意识到IT即服务的道理。

即使是对内部企业员工,IT部门支撑和提供的业务系统最终提供的还是IT服务能力,那我们评估的仍然是用户对IT服务提供本身的满意度,IT服务本身对业务的支撑和敏捷响应程度。

企业CIO需要不断思考的就是如何更好更加高效更加低成本的为企业提供各种IT服务能力。

让专业的人来做专业的事

对于传统企业来说,企业高层领导包括CIO往往更加强调购买服务器,购买软件或者自己开发软件来满足和支撑企业的业务。简单来说就是企业每年的IT预算花费出去了,企业内没有点IT服务器资产或软件留下来往往都感觉到心里是空唠唠的。

而在新IT背景下,IT即服务,资源和软件本身不是价值,只有它们提供的有价值的服务才最终产生价值。因此我们一定要转变思维,让专业的公司,专业的人来帮助企业提供专业化的服务能力。有好的IaaS服务提供商,有好的SaaS应用软件,我们要大胆去尝试,真正去践行软件即服务的思想。

你会发现在规模经济下,使用软件即服务模式,企业往往会有更少的试错成本,前期建设成本,后续管理和运维成本,在成本考量上反而也是最低的。特别是在当前IT人员本身人力成本越来越高的情况下。

业务驱动而非技术驱动

虽然我经常会谈到微服务架构,DevOps支撑过程,容器云PaaS平台等,但是我仍然要强调的是CIO思考意识里面一定是 业务目标驱动,而非新技术驱动 。不仅仅是企业的CIO,包括企业的研发项目经理,核心架构人员也要意识到业务驱动,而非技术驱动,技术是为业务服务的,不要为了技术而技术。

我们上任何一个新技术都需要想明白究竟带来哪些业务价值,否则就不要盲目上。

我们实施微服务架构和模块化也是同样的道理,这个本身是有明确的业务价值的,就是能够更加快速敏捷的响应业务变化。

比如一线业务部门计划推出一项新的业务,需要一个APP应用来支撑,在传统IT架构模式下我们可能需要2个月才能够上线这个小系统,但是新IT架构下你可能两周就能够快速上线。原来业务一个需要变更最快都要1个月完成,但是新IT架构下能够1到2周就能完成快速交付。

或者说我们在使用系统中遇到的问题,原来处理起来很慢,现在可以2小时内快速处理。我们原来使用的功能,原来觉得响应和性能都很差,现在新的版本使用起来速度很快等。

这些都是业务能够实际感受到的,就是新IT架构带来的业务价值。

真正为企业留下有价值的IT资产积累

一个企业的CIO需要思考在职的多年究竟为企业留下了什么?是一堆已经过时的服务器资源和已经难以维护无法扩展的IT系统,还是其它?企业每年投的IT预算除了支撑企业业务正常运行外,还能够留下哪些有价值的东西?

什么叫有价值的IT资产?

简单来说,有价值的IT资产本身一定是可以显性化沉淀下来的,帮助后人持续收益的资产。比如我们常说的一个好的软件研发过程,IT部门管理架构和管理体系设计,一套技术标准等。这些本身是有价值的。

而对于IT系统来说,这个IT系统本身是可以持续迭代升级的,是可扩展的,是容易运维的,那么这个IT系统本身就能够持续创造价值。其次,如果这个IT系统通过多年运行沉淀下来的数据还能够拿出来进一步做数据分析,辅助企业生产运营决策,那么这个价值就更大。

IT系统本身是没有价值的,及时提供的IT服务有价值,事后形成的数据有价值。这也是在我博客很早的文章就提到的,企业CIO要有数据管理和数据运营意识的一个原因。

对于CIO工作重点的思考

在这里主要针对中大型企业有专门的IT部门和独立开发运维团队的情况,对于这种企业的CIO,核心的一些思考点在哪里,和常规软件企业又有哪些差异?

对于企业IT部门是成本中心,在开源节流上,利润中心的重要性和关注度还是远远高于成本中心,这也是很多企业IT部门往往不受重视的原因,CIO本身也没有太多的决策权,在本身没有太多独立开发能力时候更多仅仅是一个运维中心的角色。

那么对于一个大中型企业的CIO,核心的思考应该包括哪些内容?

将IT价值显性化表达

思考的重点首先还是IT价值的显性化,即如何让业务部门管理,执行各层人员感受到通过信息化规划,建设和实施,切实带来了工作效率的提升,业务价值能力的提升。业务上的一些流程优化,好的管理举措等如何能够通过IT系统更好的固化和高效执行。

对于IT价值的显性化最需要考虑的仍然是两大方面: 一个是成本降低,一个是业务敏捷性的增强。

这两点往往都很难完全量化评估,但是又不能全部定性分析。谈到提升就一定有比较,即IT类应用实施前后的比较,业务绩效的KPI通过分解后,有一部分即是IT系统所带来的贡献。

同时随着企业管理的精细化,更多管理需要业务运作数据来支撑,以方便进行业务分析和管控,而这些也是IT系统发挥价值的一个重点,业务管控分解的业务KPI和绩效分析,最终落到各个IT系统随时随地的采集数据并汇总,以提供业务分析之用。

企业的IT系统规划和建设,很容易犯的毛病就是盲目的照搬其它企业的最佳实践而忽视了自身的业务背景和管控需求,或者说在业务能力不足的时候上了大而全的IT系统,期待通过IT系统来倒退业务变革是相当不现实的做法。

将IT应用以服务方式提供,做好内部运营工作

其次,IT部门是一个服务部门,企业内的各个业务部门就是客户,那么IT建设的系统如何在内部做好运营以提升客户满意度就相当关键了。

对于运营本身包括两个方面的内容,其一是IT类系统在内部的推广和宣传,其二是IT系统内部的运维服务。即使是服务内部客户,IT部门建设的系统也应该像一个完整的产品样,需要考虑在内部如何策划和营销,如何解决系统刚开始实施一系列的问题,很多重要IT系统往往一开始是高层强制推,但是如果业务部门消极抵制也很难真正达到效果。

所以很多时候IT部门应该和业务管理部门在一个战线上,要借业务部门之力进行联合策划和产品推广。运维服务就更加重要了,内部的IT服务热线,问题管理和跟踪解决闭环,内部服务满意度评估等,唯一需要考虑的就是为内部客户提供真正高可用性的IT系统。

再次,对于信息化规划,我们一直在谈的重点就是业务驱动IT,通过IT建设来实现业务价值和能力提升,但是现实情况往往更多的还是业务和IT脱节,IT对整个业务价值链的支撑出现断点或问题。要么是业务人员不懂IT,要么是IT人员不熟悉业务,对于大中型企业的内部IT,一定要培养既熟悉业务,又熟悉IT的系统分析员或叫业务分析和建模人员。这类人员往往需要比业务人员更加熟悉端到端的业务,不一定要精通到每个业务细节,但是必须要能够更好的审视全局。

业务部门和IT部门人员都朝前走一步,包括形成跨部门的虚拟运作团队,成立专门的流程&IT部门,都可以较好的解决这个问题。而我们常说的基于EA企业架构的信息化规划,正好也是将业务和IT,流程和数据进一步很好的融合的表现。

提升IT国产能力成熟度

最后,作为内部的IT部门,自身的管理能力和团队成熟度提升就相当重要了,在这里面涉及到产品规划,CMMI,软件工程,IT项目管理,ITIL或Cobit等多方面的知识和方法体系。一个成熟的IT部门一定不是疲于奔命的应对业务需求,而是应该逐步形成按产品规划,版本研发和实施,部署运维,需求和问题管理等一整套的方法进行运转。

很多非IT类企业的信息化部门,往往较少接触到IPD或CMMI,IT项目管理等一整套的业界做法,而是自己闭门造车。而实际情况是IT管理发展到现在已经相当成熟,需要的是借鉴他人经验,再结合自身实际情况进行裁剪,逐步推荐内部IT管理和流程的规范化。

如何去搭建CIO的技术知识体系

从年初,我们开始今年的IT专业技能培训知识体系规划和培训工作开展。其中包括了类似沟通,写作,PPT制作呈现,个人知识管理等软技能方面,也包括了专业知识技能方面。

而对于专业技能方面的知识体系结构,感觉企业CIO也可以作为一个参考借鉴。

对于专业技能培训,按照当前通用的分法,仍然是分为业务,技术,管理和三个方面的内容。对于团队成员来说分岗位角色不同应该分开组织进行培训,但是三者之间本身又相互又融合。比如做业务的人员,本身也应该对技术基础知识有所了解,而业务和技术人员本身又应该了解通用的项目管理,流程管理等方面。

按照CMMI的知识体系可以看到,分为了支撑过程域,软件工程和技术域,项目管理域,按照公司单个产品线本身又分为了售前,需求,项目经理,技术开发,测试,实施等不同的岗位角色。因此对于专业技能培训必须是结合公司实际的产品线和岗位角色情况来组织和安排。

管理和过程类培训

这个是偏通用的专业技能,这里面的重点实际是两个,一个是IT项目管理,一个是流程管理,这两个是基础的基础,你可以看到实际你工作的开展协同基本都会用到这两方面的知识。然后再到具体过程域来说,增加软件工程或CMMI的知识体系培训内容。即:

1. IT项目管理培训

2. 流程管理和流程分析方法培训

3. 软件工程基础培训

4. CMMI基础培训

5. Scrum敏捷研发管理和敏捷开发方法培训

业务基础知识培训

对于业务基础知识来说,对于类似我们做SOA平台类产品来说,更多的并不需要对和细致的业务做了解,仅仅是围绕企业的核心价值链,对核心业务有所了解即可。那么企业的核心价值链和支撑业务有哪些?简单来说即包括了供应链管理,生产,研发,市场营销,财务,人力资源等。因此我们的培训可以围绕这些展开。

1. 企业价值链管理和核心企业端到端流程介绍

2. ERP基础知识和核心业务模块介绍

3. 供应链管理和业务介绍

4. 研发生命周期管理和核心业务介绍

5. 生产管理和智能制造

6. 财务域核心知识和业务介绍

7. 市场和客户管理管理核心业务知识介绍

8. 人力资源管理

技术和研发类知识培训

对于技术和研发类培训,实际上我们看到整个思路很清晰,即围绕软件研发生命周期展开即可,当然还需要对该生命周期进行扩展,在前期增加售前方案内容,在后续增加运维方面内容。

1. 产品规划和高效产品研发

2. 软件生命周期管理

2.1 需求分析和需求开发方法培训(交互设计,易用性)

2.2 软件架构设计

2.3 数据库设计

2.4 概要设计和详细设计基础

2.5 标准开发框架和开发方法培训

2.6 编码规范培训

2.7 测试方法和流程,测试工具培训

2.8 技术类问题分析和排查

3. 新知识和技术

3.1 微服务类培训(基础,开发框架,主流技术,网关,熔断,安全,服务链监控)

3.2 DevOps基础知识培训

3.3 容器和PaaS技术培训

3.4 核心技术类中间件培训(缓存,消息,元原生相关技术中间件,前端技术等)

4. 运维类培训

4.1 Linux日常操作和运维

4.2 数据库和中间件运维

4.3 运维工具和运维自动化

4.4 ITIL运维流程和体系

IT规划和咨询类培训

对于IT规划和咨询我单独列一类出来,主要还是这部分相对独立,同时涉及到业务和技术,管理多方面的内容,包括也涉及到我前面提到的大量软技能的内容,要做好IT咨询本身不容易。

对于IT规划知识体系,我原来做过整理,参考本文贴图,参考业界IT规划的参考模型和框架,结合IT规划方法论和实施,重新整理了IT规划知识体系。对于横轴主要考虑IT规划的方法论和步骤,具体包括了参考模型,调研阶段,差异分析和匹配,目标架构,实施策略和管控治理六个方面的内容;对于纵轴包括了IT基础设施,业务基础设施,业务流程,数据,技术体系,应用系统,集成架构七个方面的内容。

横向包括了IT规划和咨询项目的完整阶段和流程。纵向包括了完整的IT规划和企业架构应该包括了内容。对于原有zachman框架的匹配分析为,去掉了时间和动机,增加了业务流程,技术和集成三个维度。对于zachman横向原来分为目标/范围、业务模型、系统模型、技术模型、详细表达、运行功能。其中将技术模型转化为横向,并增加了实施策略和管控机制。

1. 流程管理和ARIS建模

2. 企业架构规划(可以围绕Togaf框架展开)

2.1 业务架构和流程建模

2.2 数据架构

2.3 应用架构

2.4 技术架构(技术架构,运维架构)

2.5 组合规划和实施演进

3. 业务基础(供应链,财务,研发,生产制造,市场营销,人力资源)

4. 技术基础(云计算,SOA,微服务,中台,ITIL,CMMI,软件工程等)

5. 工具基础(咨询工具箱,分析方法等)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK