谈IT规划的思考逻辑

标签: 随笔文章 | 发表时间:2012-01-24 09:50 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
对于IT规划,涉及到业务,流程,数据,信息技术,基础设施多方面的内容,涉及到业务驱动IT,涉及到业务架构和应用架构,涉及到从规划咨询到实施落地的全过程。IT规划之难度不在于IT本身,而在于流程,不在于技术本身,而在于业务。

IT规划所涉及到的大的方面包括了流程管理和分析,咨询方法论,信息化架构,技术架构,应用系统分析和设计,项目管理和实施。从企业战略到业务目标,从业务目标到应用蓝图,从应用蓝图到分阶段实施落地,任何一步骤的稍微脱节将导致规划内容的无法落地,再完美的规划和架构,如果脱离企业业务目标和实际,不能带来企业业务价值的提升,那么一切都只是废纸。

对于IT规划的一般逻辑,和前面谈到过的咨询的一般逻辑是类似的,其仍然是包括了现状分析,目标提出,差距分析,蓝图规划,实施规划几个关键步骤。现状分析包括了业务现状和IT现状,根据企业战略提出业务目标和发展规划,分析现状和目标之间的差距提出和整理问题集,根据差距和问题给出蓝图规划,根据目标和问题分解到的子目标和子问题多维度评估和确定优先级,确定后续的实施计划。这就是IT规划的一般逻辑。

整个IT规划始终围绕业务和IT两条主线,业务包括了业务流程,业务数据,岗位组织和角色,业务管控体系;而IT包括了应用架构体系,数据架构和模型,技术架构和平台,基础设施建设。业务驱动IT,端到端业务流程最终落地到应用系统的功能上,业务数据最终沉淀到数据库中的数据模型,我们谈SOA重点也是业务驱动IT,业务和IT走向融合,业务架构和应用架构本身就为一体,特别是业务组件的提出;而数据架构本身从传统的概念模型,逻辑模型,物理模型本身就是业务数据和信息数据的融合和统一。

现状分析

现状分析顺序是从业务过渡到IT,业务现状分析本身重点又在于业务流程和业务数据上,如果说从顶向下逐层分解的方法,则可以参考价值链分析方法,业务可以参考针对各个业务域的一些标准业务参考架构和模型,如供应链的scor模型,电信的etom模型,研发领域的IPD和PACE方法,CMMI成熟度模型,项目管理知识体系,营销和客户关系管理模型,财务域标准模型等。现状分析我们期望的还是从顶向下,找到关键的几个端到端流程为主线进行逐层分解,先抛开业务部门的隔离,IT系统的约束,进行跨业务域的流程分析和梳理。在流程分析和梳理的过程中进一步分析子流程和活动,业务组件和数据,跨业务域的协同和交互等一系列问题。

IT现状包括了现有的IT应用系统现状和功能架构,IT基础设施架构现状,IT系统本身现在对业务现状的一个支撑情况分析等。一开始的现状分析无必要立刻过渡到数据,但是现状分析必须要理清楚的就是业务和IT的关系,IT对业务的支撑度。现状分析的目的是提出后续业务目标和IT系统规划建设目标,这样的目标才能够真正为业务服务,体现业务价值。

差距和目标

现状分析的目的是提出目标,而目标的提出本身又包括了两个方面的内容,一个是直接提出的业务目标和IT建设目标,其次是通过差距进一步细化目标和有针对性的目标。特别是IT系统目标的提出,必须进行差距分析,因为IT建设重点就是支持业务目标,那么所有现有的IT建设和应用架构中无法支撑的部分都是差距,IT规划建设就是要解决这些差距。

企业和业务战略首先落地到具体的业务目标,通过IT和业务目标的匹配和差异分析,将业务目标进一步细化到IT建设目标,这是由企业战略到IT目标逐步细化,使IT规划目标真正具备可操作性的过程。在传统的方法中我们通过业务架构和应用架构的匹配和映射,在SOA方法中我们通过业务组件图的热映射,我们也可以进行IT应用和功能对流程的映射,这些都是发现差距和解决差距。

通过差距分析得出的目标已经是多个子目标,是一个目标群,正如我们面临的问题是一个问题群一样,多个子目标的分阶段,分步骤实现最终才可能完成一个大的业务目标。目标分解,问题分解,目标和问题映射最终形成一个完整的解决方案。这也是为何我们说在大的IT规划中一定会涉及到组合管理,项目群管理方面的内容,目标分解到子目标,子目标最终落实到具体的项目,通过项目规划和建设的方式推动实现。

规划蓝图

对于IT规划的蓝图包括了业务蓝图和信息蓝图,包括了业务架构,信息架构,应用架构,技术架构,集成架构和IT基础设施架构多方面的内容。特别要注意的就是IT规划蓝图包括了业务架构,而且业务和IT密不可分。所有蓝图都自顶向下,逐层分解,相互融合和协同。业务架构重点是在流程,而信息架构的重点是在数据,这两个架构都偏业务层面。而对于IT方面架构则包括了应用架构,应用集成架构,技术架构和IT基础设施架构。应用架构在最上层,而集成和技术架构在平台层,IT基础架构在基础设施和物理资源层。从现有的云和集中化趋势来看,更加需要考虑基础设施和平台层得集中化建设,上层的应用架构重点都要集中在应用和功能层面,体现业务组件化和能力化,体现组件本身的独立性和可集成性。

蓝图规划一般是一个远期规划,至少覆盖5年,远期展望10年,虽然知道后续变化可能性很大,但是仍然需要做较为全面的蓝图规划,规划如果都不能展望的更远,那么建设和实施必然受到太多的局限性和约束。如果是单纯的业务流程优化咨询项目,那么业务架构和信息架构这套内容仍然适合,只是IT规划建设方面提及和细化度减弱而已。

业务架构+信息架构完全可以理解为全公司IT建设和架构规划中的高端业务建模,在这个层面基本还过渡不到细化的具体业务系统。业务架构和信息架构最终要落地到应用架构中,业务架构体现到具体的业务组件和功能,而信息架构落地到具体的数据模型和数据库设计。如果再落地到具体的系统分析和设计,即演进到应用系统中的高端架构设计,包括用例模型和逻辑模型,用例模型体现业务和流程,逻辑模型体现信息和数据。

应用架构中包括了集成架构,集成架构本身又包括了业务集成和数据的集成,包括集成接口关系和集成逻辑模型等方面的内容。正是由于大企业的IT系统建设必须分为治之,衍生了多个业务系统,那么多系统间的数据集成和业务协同等大问题就必须在集成架构规划中进行分析和考虑。

应用架构下层转化到信息架构中的纯技术层面,技术架构规划一般出来的较晚,也需要规划人员有较资深的IT技术背景,否则很难提炼公用性的技术,技术规划属于IT平台层规划的事情,目的是通过后续技术和技术平台的建设更好的支撑业务系统建设,加强复用和平台化。

实施计划

可以将IT规划中的实施计划直接影响到IT规划的落地性,影响到IT建设投资是否真正体现业务价值,为业务目标的达成服务。实施计划重点方法论仍然回归到前面谈到的组合管理和项目群管理。目标有优先级,可以从成本投入,建设容易度,对业务价值实现的贡献,推广实施难度等多个方面来评估需要建设的内容的优先级。前面没有谈到过预算,但是到了实施计划一定要考虑到预算和成本投入。

实施计划按照组合管理的目标来说,就是要用最少的IT资源投入创造最大的业务价值和效率。实施规划涉及到决策,在这里是结构化决策,组合最优化决策,最终目标通过规划推动实际的IT应用系统建设和实施,通过系统的建设和实施又推动业务的完善和成熟。

我们要建设哪些IT系统,这些IT系统如何分阶段建设,这些IT系统如何来支撑业务流程的完善,IT系统建设本身又是否有先后依赖关系,如何多个业务系统之间更好的协同上线。系统建设过程中如何加强项目管理和管控,如何推进系统的建设,如何减少重复建设,减少不必要的资源投入都必须要考虑到。

IT系统的建设又涉及到具体的IT建设项目立项,预算又最终分解到各个业务项目和IT系统建设项目,根据IT建设项目规划又进一步细化技术规划和IT人力资源投入规划,并完善和建设IT管控体系,系统推广实施体系,系统运维体系等。

相关 [it 规划 思考] 推荐:

谈IT规划的思考逻辑

- - 人月神话的BLOG
对于IT规划,涉及到业务,流程,数据,信息技术,基础设施多方面的内容,涉及到业务驱动IT,涉及到业务架构和应用架构,涉及到从规划咨询到实施落地的全过程. IT规划之难度不在于IT本身,而在于流程,不在于技术本身,而在于业务. IT规划所涉及到的大的方面包括了流程管理和分析,咨询方法论,信息化架构,技术架构,应用系统分析和设计,项目管理和实施.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

MongoDB容量规划

- gOODiDEA - NoSQLFan
上周在公司做了一个NoSQL和MongoDB相关的技术分享,会后有同事问及MongoDB对内存需求的问题,做了简单回复. 今天就写篇文章对MongoDB容量规划做一个比较详细的总结. 首先我们要问一个很傻的问题:存储是什么. 存储就是用来装数据的东西,它需要满足以下两点基本需求:. 基于这两点,我们需要问的问题就是,这个存储能够存多少数据,能够提供多高的写入速度,能够提供多高的读取速度.

IPv6地址规划方法

- Power - cnBeta.COM
今年初ICANN和APNIC的IPv4地址池全部耗尽,亚太地区成为全球首个无法满足IPv4需求的地区. 伴随着我国互联网产业的高速增长以及未来三网 融合和物联网的发展,当前我国掌握的IPv4地址资源远无法满足高速增长的用户需求,我国将成为全球最早受地址匮乏影响的国家之一.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

表单设计的思考

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
我们几乎每天都会接触形形色色的表单,登录账号、填写信息以获取服务、发布内容等. 然而填写表单的过程往往不是特别愉悦的,我们需要消耗时间输入信息,点击提交,可能还需要等待审核;尤其是碰到较为复杂、流程长的表单,如果用户体验较差,很容易让人产生挫败感,在中途选择放弃. 那么,如何提高用户填写表单的效率,防止他们出错或中途流失,提升愉悦度及转化率呢.