世博会信息化需求的逻辑与策略.doc

上传人:吴起龙 文档编号:1593351 上传时间:2018-12-26 格式:DOC 页数:12 大小:21.35KB
返回 下载 相关 举报
世博会信息化需求的逻辑与策略.doc_第1页
第1页 / 共12页
世博会信息化需求的逻辑与策略.doc_第2页
第2页 / 共12页
世博会信息化需求的逻辑与策略.doc_第3页
第3页 / 共12页
亲,该文档总共12页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《世博会信息化需求的逻辑与策略.doc》由会员分享,可在线阅读,更多相关《世博会信息化需求的逻辑与策略.doc(12页珍藏版)》请在三一文库上搜索。

1、世博会信息化需求的逻辑与策略 在现代信息化技术条件下,需求管理已经不是一项一次性的简单劳动了。需求的定义不再是对企业规划的八股解释,也不是对业务流程的亦步亦趋;而是按照本身的逻辑进行的系统性创新。需求的开发需要想象力,需求管理需要策略。“最小化”是信息化过程一种需要全局观、系统思维的创新手段。最高境界是达到“以不变应万变”。 此外,信息通信领域的新技术、新的应用模式、新标准的出现,都可能带来对组织需求的重新思考,乃至推动企业创新。 世博会信息化情况回顾 为期184天的上海世博会成功落幕,期间没有出现重大信息安全事件,世博会信息化圆满实现了预期的“三个一流”,即一流的通信与信息服务;一流的信息化

2、运营管理支撑;一流的信息化应用展示,得到了各方面的一致好评,成为世博会的重要遗产之一。目前,世博会处在总结和遗产推广阶段。从专业管理角度深入审视世博会信息化建设和运行的逻辑,回顾建设历程,是我们科学地进行应用和遗产推广的基础。 世博会信息化成功的原因,可以概括为“布局合理”、“保障有力”、“支撑可靠”和“技术先进”四个方面。 “布局合理”,主要是指前期的总体规划和计划恰当定义了大系统的总目标、范围、原则和支撑条件,使世博会信息化有一个比较合理的布局; “保障有力”,指运营期的运营体系明确了信息化保障的责任机制、组织指挥机制、资源配合机制和应急响应机制,并在子系统层面进行了落实,使我们在各种不利

3、条件下保持了必要的就绪程度; “支撑可靠”,指运营管理的主要信息系统充分利用已有成熟经验和成果进行建设,在实施条件十分紧张的情况下尽量进行场外测试,在运行期持续跟踪和应对业务变化,充分调动后备资源进行运营保障,最终达到了较高水平的业务融合,取得了较好的应用支撑效果; “技术先进”,是指无线宽带、网络化应用、RFID和传感网等成熟技术的广泛使用,智能视频、TD-LTE等先进技术的示范性应用,新型多媒体、半导体照明、智能机器人、虚拟现实、定位导航等创新性技术的精彩展示,使得本届世博会成为人类进入信息社会的一个里程碑。 但是,总体的成功不等于全面的成功。世博会信息化包括46个大项目,涉及了来自全国逾

4、100家不同资质的分包商,投资逾10亿元。从专业角度、从子系统层面来看世博会信息化,也有一些不够科学、不够优化,乃至局部失败的地方。出现了“预约系统瘫痪”等一些标志性的信息化运营事件。 从专业管理角度,世博会信息化主要给组织方带来了多个方面的挑战,相应地也暴露了作为整个信息化工作基石的信息服务产业的弱点领域。例如: 需求管理相关的弱点:参建企业对需求的把控能力普遍偏弱,在面临世博会普遍存在的业务主体不到位、没有需求,以及需求持续变化的困难情况时,普遍缺乏需求开发的对策。部分信息系统需求定义偏离实际,导致使用程度不高,等等。 项目/项目群管理相关的弱点:一些组织方业务部门和参建企业对项目管理基本

5、规律和要求不掌握,导致一些项目在条件不具备时“硬上”;集成商对分包商“管不住”;不具备项目所需能力的分包商“勉为其难”,等等。 规划及系统架构相关的弱点:总体把控的信息化规划在与信息化项目的衔接上深度不够,未形成统一、清晰的技术架构(如网络架构、数据架构),并形成大范围共识;跨系统和跨团队的信息共享困难,集成低效;部分项目偏离规划初始目标和定位;在规划的执行上没有形成监督和回馈机制。 在以上的“不足”之中,其中需求相关的定义不当、管理失策,是造成局部失败的主要原因。本文结合世博会信息化实际案例,介绍现代信息化需求管理的逻辑与策略。 需求的逻辑 需求的层次与标准 需求是信息化项目的起点。信息化相

6、关的各种理论和方法体系对此均有涉及。从这些理论对需求的定位可以看出需求的重要性。“需求”是一个认识论范畴的概念。沿着我们对需求的认识和实践的路径,可以把需求分为三个层次: “需要(Needs)”。这是最“原始”的需求,可以是对企业规划、决策、组织架构、流程等业务逻辑的原始描述,或者对信息化的期望等等。描述方式以自然语言为主。记载工具可以是会议或头脑风暴的手工记录、办公自动化工具所产生的电子文档等各种形式和格式的文件资料。 “需求(Requirements)”。这是在原始需求基础上通过一定的归纳、分析等认识活动,并以较为规范的方式描述的需求。需求的内容是有结构的,例如分析成用例模型、业务活动流程

7、、信息化业务流程等等。需求描述的形式是规范的,例如可以采用建模语言UML来描述绝大多数的需求,并支持需求开发的所有活动。 “规格(Specifications)”。这是在综合的可行性分析基础上达成的、最后可以用于信息化建设和实施的需求描述。规格在结构化需求的基础上,根据专业技术架构(如软件架构、网络架构)要求进行细化,并进行了技术选型和量化。 需求的过程和活动 需求管理包括需求开发、需求跟踪和变更控制两个平行的过程,并在整个信息化过程中不断循环、持续改进。简单示意如图所示。 需求的识别:根据企业目标、存在的问题、业务人员的意愿等输入条件,进行问题/目标分析,识别出需求项。 需求的描述:使用一定

8、的工具来逐项描述业务需求或技术需求;在企业架构下描述需求。不同的需求开发阶段可能侧重点不同。 需求的确认:经过初步描述或重构的需求需要在企业范围内获得广泛确认,并从业务、技术、经济等方面的经过可行性论证。 需求的验证:在信息化实施阶段,要对需求进行验证,以检验需求、项目计划、开发产品之间的一致性。 需求的跟踪与变更控制:持续对需求的开发、变更情况进行回溯。对需求的变更需要实行规范的、专门的管理。变更管理可以根据产品架构特性采取相应的策略,不一定是越严越好。一般情况下,对变更的控制包括变更的捕获、评估、决策、实施等活动。 需求是哪里来的 需求管理其实是一个迭代的、不断接近一个“好”的状态的复杂过

9、程,而且应该把需求管理放到企业架构开发和演变的语境下,结合企业业务创新、信息基础设施建设、信息资源建设等EA要素进行全程、全面管理。但我们可以简单归纳一下,“好”的需求是怎样得来的: 需求是沟通出来的 需求是根据业务逻辑、管理规律牵引和推演出来的 需求是综合各方约束论证出来的 需求是被技术“推”出来的 需求是循环迭代出来的,是逐步形式化、逐步细化、逐步量化出来的 “好”的需求是怎样的 怎样的需求算是一个“好”的需求,可以进行下一步的设计、开发或运营了呢? 按照比较传统的观念,通常我们会把需求分为“业务需求”和“信息化需求”或曰“技术需求”,以分化步骤、界定不同主体的责任。虽然这种分割有其局限性

10、,但我们还是可以比照描述一下什么是“好”的业务需求,什么是“好”的信息化需求。 理想的“业务需求”具有以下特点: 业务目标恰当 业务逻辑完整、符合管理规律,有现代技术条件下业务创新精神 对信息化支持手段有恰当期待,技术“融合性”好,以可持续发展和运营为工作目标。 理想的“信息化需求”有以下特点: 技术视图完整:网络、数据、应用、安全、主机、基础设施符合专业 方案量化合理,具有经济、运行可行性 总体架构清晰,EA融合性好,与组织规划一致 全面全程可行,可持续运营。 不论采用经典的方法还是现代的方法进行需求管理,“好”的需求定义都意味着这样一种相似的境界: 平衡、适度。好的需求虽然不一定达到“增一

11、分太肥,损一分太瘦”的境界,但也能通过EA框架下企业各个层面、各个不同角度的审视:在业务系统上具有逻辑上的完备性和一定的前瞻性;在技术上难度适中,时间、人力等资源上不存在大的风险;所需要的投资合理。 “吸入”式效应。好的需求可以实现一种对需求变化的“吸入”,即在经过一定的分析、架构设计并经过若干迭代后特别是当业务上进行了抽象、超前的设计,技术上采用了一些通用性设计手段后所定义出来的信息化系统具有一定的适应性,需求项目的新增和变更量会进入一个显著、稳定的下降通道,甚至给人一种“以不变应万变”的自信。 其实,在现代EA框架背景下,我们已经很难区分“业务需求”和“信息化需求”已经是“你中有我,我中有

12、你”了。我们反而可以以一致的、综合的判定标准来进行判断。 需求的策略 在实际项目运作中,指望业务主体提出完美的“业务需求”,然后由IT人员接力、按部就班地进行需求分析,往往是不现实的。信息化项目往往要面对一些困难情况。这时候,我们需要一些策略来保证项目的顺利进行。 世博会的需求管理几乎是各种困难场景的集大成者。我们以世博会的运营指挥信息系统为案例加以说明。 世博会的展期对信息化来说是一个不可移动的最后期限。作为支持世博园区“神经中枢”园区运营指挥中心运作的“运营指挥信息通信系统”,必须在2010年5月1日前可靠地就绪。考虑到必要的集成、测试、试运行等,“倒排”下来,容不得我们在需求定义上有过多

13、的反复。而事实上,“运营指挥中心”是2009年4月底才开始筹备。这种建设时间紧、业务模糊、主题不到位的场景,恐怕是需求管理困难场景的极端了。 好在信息化团队凭借以往丰富的指挥系统建设和运营经验,在对世博会运营特点进行深入分析和广泛借鉴的基础上,在筹备组成立之际、运营指挥中心业务人员尚未到位之时,就拿出了初步功能需求定义,为项目确立了较为稳定的建设范围,主动、有效地应对了需求风险。此后随方案数易其稿,但其核心功能和架构定义从来没有变过。 “事件管理子系统”是其中最核心的软件子系统之一。对该子系统的定义借鉴了市场上和往届重大活动使用过的多种应急指挥类信息系统,体现了应急管理中事件管理(Incide

14、nt Management)的业务本质;在功能设计上,注重园区运营管理的常态性,将系统功能定位为“通用的沟通、记录功能平台”。事实证明,这种简单的功能设计抓住了业务最核心、最本质的需要,很容易被用户接受;同时对不断细化、调整的运营指挥业务几乎达到了“以不变应万变”的境界。事实证明,该软件系统投入运营后,使用率非常高,成为运营指挥中心日常工作不可或缺的沟通平台,同时也成为了整个世博会信息化中效益-投资比最高的系统。 “没有需求”怎么办? “没有需求”不是真的“没有”,而是责任主体对需求的认识没有到位。“没有需求”的风险是很可怕的。它可以直接导致立项失败。如果不顾客观规律“硬要”立项的话,需求的风

15、险就立即转化为时间、技术、经济、应用等其它的重大风险,“流产”几率非常大。 突破“没有需求”的对策无他,下定决心、主动探索而已。在现代企业环境下,信息化已经不是一个部门的事情了。由于一些“刚性”的规律,信息化团队往往对需求的迫切性认识更深刻。如果信息化团队能够从信息化角度切入,更前瞻、更系统地思索业务的本职和趋势,就不妨突破“业务”、“技术”藩篱,站在全局高度,主动承担需求开发的责任;并达成与业务主体的充分沟通,最终形成以需求为桥梁的、全企业在规划愿景、业务流程和技术方案上的共识。 如果确实所有人都限于条件发现不了需求所在、“看不清”需求,这时就应该坚持一种“最小化”的原则,在保持系统性的基础

16、上,运用原型化思想,以及抽象、通用化、数据导向、数据驱动等具体技巧,开发出经济的、具有自适应性的需求定义,并持续跟踪与改进。 说到“最小化”,世博会的信息化中有一个失败案例,即“预约系统”的开发。该系统在业务模式迟迟未定、开发时间明显不够的情况下,在项目方案的决策链中选择了“联网预约”、“全面覆盖各预约业务”、“票绑定预约”等一系列最大化决策,对项目范围(需求)进行了接近“最大化”的定义。这一最大化定义直接导致开发出来的系统测试不充分,可靠性差。结果在预展开始后数分钟内即告崩溃。虽经后来经过一段“头痛医头脚痛医脚”的艰苦改进,仍然问题频出,最后实际上被弃用。全因有手工方式的应急预案,才没有导致

17、预约业务的混乱。 “没有需求”还有一种变化情况,可以称作“没有主体”。其实也不见得真的“没有”,只是到位的时间会比较迟、超过了项目建设可以容忍的最迟开始时间而已。它比一般的“没有需求”相比风险更大。这种情况下,要求需求分析方态度更积极、主动,要有“舍我其谁”的精神;沟通要求更高更有技巧,要求以更大的努力将业务“推送”和“渗透”给真正的业务主体。这种情况下如果有一个有力的CIO制度,将更有利于需求达成。 需求频繁变化怎么办? 在IT实践中,“需求老变”几乎是一种常态。根据需求管理的方法论和实践经验,可以采取以下措施: 1) 给需求一个时间边界 2) 实行控制变更流程 3) 采用原型法,并且持续跟

18、踪需求 4) 在应用架构设计上运用一些提高通用性的技巧。 5) 实行“交钥匙”工程。要让用户来参与需求的改进。如果有工具来“配置”或“定制”需求,一定要尽早交给用户。 其中,“经典”的项目管理和信息系统工程理论强调的是第一、二种方法。这两条的立足点是增加需求提出方的变更成本,实际上隐含了一种“业务需求”与“信息化需求”各司其责的指导思想。通常情况下这两条是正确和够用的,但它们不太适用于世博会这种困难的需求场景。第三种方法是需求管理理论重点强调、并被广泛使用的方法,它对需求的场景有更高的宽容度。第四、五种强调的是应付变化和不确定性的技术手段。如果用技术手段达到足够的通用性,对需求的时间边界(第一条)和控制流程(第三条)的要求可以放开一些。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1