信息化的模式之痛

信息化的模式之痛信息“孤岛”、“两张皮”，是众多信息化建设项目挥之不去的尴尬。此种尴尬背后，隐含着信息化建设的模式之痛。信息化是一个过程，把信息化简单地当作“系统建设”项目，忽略了信息化的“能力建设”，昀终导致的是开发的“会战模式”，和运维服务的“救火模式”。在企业IT应用中，“两张皮”现象几乎成为伴随“孤岛”而存在的顽症。会计核算、成本管理、物资采购、生产计划，这些独立运行的子系统，数据口径不一致，数据库类型不统一，无法共享和交换信息，迫使信息系统与业务系统之间，似乎总有一条无法逾越的“鸿沟”，让IT与业务的关系成了令人头痛的“两张皮”。在“孤岛”随处可见，“两张皮”随时存在的情况下，出现了一些致力于解决这些难题的“新药方”，比如整合数据资源的“商务智能（BI）”；通过定义不同系统之间的数据交换标准，跨越平台集成应用系统的“企业应用集成（EAI）”；利用XML技术，以企业门户网站（EIP）为核心，建立企业内容聚合平台；使用中间件技术，建立整合异构计算环境的企业应用支撑平台。然而，这些新概念、新模式，在实践中是否会演变为企业信息化中“新的开发项目”？这会不会造成新的、更高级的“孤岛”？会不会形成新的“两张皮”？这样的问题并非杞人忧天。许多企业在“无休止的信息系统建设”、“没完没了的更新换代、升级扩容”面前，陷入困惑之中。困惑的核心，就是伴随着“孤岛”和“两张皮”的，是值得深思的开发与运维服务的模式问题。开发的“会战模式”信息化项目的开发模式，有不同的研究角度，比如侧重软件开发方法的软件工程角度，这里有列入国家标准（GB8566、GB8567等）的结构化软件开发规范，有兴盛于20世纪70年代的“原型化方法”，有注重软件过程组织和用例（UseCase）的UML建模与开发方法。此外，信息化项目的开发模式，近几年又多了一个研究角度，就是“IT项目管理”这个领域以项目管理知识体系框架为蓝本，结合软件项目的特点，有一套“以工程观点为基准，以质量、工期、成本控制为核心”的项目管理方法。但这些研究角度，都没有跳出“个别项目”的巢臼。企业信息化是一个“过程”。企业信息系统不是一个可以“一揽子完成的项目”；也不是一个可以“一蹴而就的工程”。企业信息化建设牵涉到系统建设之外的内容：企业发展战略的制定与执行；企业组织机构、运营机制随竞争环境的调整与变革；企业核心业务，或者叫关键业务的整合与重组；企业竞争环境的变化；企业业务流程的变更；企业资源的重新分配……但是，真实的企业信息化过程，往往狭义地局限在“系统建设”的定位上，将信息化缩减成为一个开发项目、一个系统建设项目，甚至在开发的组织、资源的投入、规划与实施过程中，采取“人海战术、会战模式”。“人海战术、会战模式”的突出特点是，开发的规划和组织者将信息化问题，缩减为一个技术问题、一个建设项目问题。这首先从根本上就背离了信息化是“企业组织形态、业务流程、企业竞争能力演化的有机过程”的基本要义。运维服务的“救火模式”“会战模式”从一开始就埋下了“孤岛”和“两张皮”的“祸根”。将信息系统作为开发项目，仅仅解决了信息化的有形的部分――系统建设。信息化无形的部分，即“能力建设”没有包含――也不可能包含在“系统开发项目”的规划报告中。而“能力建设”恰恰是信息化价值中昀重要的内容。所谓“能力建设”，即组织的信息化程度，在IT与企业战略、业务流程、管理机制上达到高度融合之后，企业所拥有的“信息化竞争力”。“会战模式”带来的一个直接后果，就是运维服务的“救火模式”。由于系统开发是基于技术导向的所谓“整体解决方案”的，这个开发就没有充分考虑企业的信息化中必须蕴涵的战略、业务、管理的实际需求。换个说法就是，按照技术导向所做的信息系统，仅仅解决了“模仿手工作业处理”的问题。“救火模式”让企业信息化从业人员疲于应付、心力憔悴。他们的主要精力被迫放在了无休止的“补丁”、“重复开发”、“推倒重来”的恶性循环中。用一位从事系统开发10年以上的软件工程师的话说，“系统开发永远是‘面多了加水，水多了加面’的游戏。”信息化在某些地区和企业里，被看作“建设项目”，这里有很大的误区。早期的IT应用，常常被归结为技术问题。所以厂商有大量的所谓“全面解决方案”，企业也组建项目团队，用软件工程、项目管理的诸多办法，解决信息化的“系统建设”问题。大约5年以前，也就是ERP盛行天下的时期，信息化有了新的说辞，如“软件所凝结着的是先进的管理思想与方法”。大量借“先进管理思想与方法”的方法论、软件体系，层出不穷。这些无论技术导向的“工程观点”，与管理软件导向的“管理观点”，都有一个共同的特点，就是把信息化看作“系统建设”问题，而忽视了“能力建设”问题。系统建设与能力建设“系统建设”有这样一个假设，就是企业信息化的未来状态，是一个可以通过“技术的”、“软件的”、“工程的”、“实施的”、“咨询的”诸多IT专业技术过程达到。这是一个未经证实的假设。原因很简单，大量的项目延期了，超过预算了，面目全非了，不了了之了，甚至完全失败了。“能力建设”则将信息化与企业战略、管理与业务的高度融合，作为衡量成败的尺度和评估价值的砝码。能力，指的不是IT产品的技术参数、信息系统的性能指标，也不是IT厂商所说的“高XX性”。能力，对企业而言，就是绩效（Performance）与价值（Value）。信息化能不能提升企业的产品质量、服务水准、生产率、客户满意度、员工满意度，是衡量企业信息化能力建设的关键。在这个意义下，信息化的“模式”就成为核心的问题。到底什么样的“模式”，可以产生积极的投资回报，可以提升企业的能力，是一个值得深入探讨的问题。不是“上线”，是“在线”ERP有一个术语叫“上线”。大意是说系统开发完毕，初始数据准备就绪，工序条理到位之后，让系统正式切入实际业务流程，在实际流程中运行校验的过程。上线成功，则意味着这个信息化项目大功告成――“这几乎是令人窒息的等待”，一位ERP项目经理说。有许多项目经理承认，上线成功“要看怎么说”。言下之意是说，尺度之宽严大有讲究。即便不说这些可能存在的解释上的偏差，就拿“需求”来说，项目之初和项目收尾的时候，就一定不同。既然这样，为什么不从“模式”上思考问题呢？为什么ERP一定是一个“上线”工程，而不是一个“在线过程”呢？上线，事实上意味着“离线”。依靠“需求分析”得来的系统开发模型，实际上是活生生的企业过程的一种“抽象的假设”。这个“假设”与真实的系统之间的“间隙”；以及真实的系统无法剔除的“动态变异因素”，使得任何“模型”都是静态的、不完整的模型。上线的做法，是典型的“系统建设思维”，而没有考虑“能力建设”的内容。能力，是一个成长的过程，它需要“在线”，它只能“在线”。信息化的“牛角尖”早期机器人设计有一个梦想，就是用数学方法构造出完备的机器人的行为模式，然后“把它造出来不就行了”。技术的乐观主义不能代替复杂的现实。用静态的、复杂的数学方程，不可能构造出真实机器人行为模式的方程式。20世纪70年代的科学家开始探索另外的路子，他们发现“仿真”、“模拟”、“专家系统”、“模式识别”的方法，是建造好的机器人的有效办法。这种办法克服了以往注重建立数学模型的缺陷。这条路子的核心，将人们关注的焦点，投向了机器人的“能力”。科学家们纠正了自己陶醉于“纯粹数学模型”的偏狭思维。因为机器人的“好坏”，是靠机器人所展现的能力来体现的，而不在于构造了多么精巧的数学模型。既然“无所不在的世界”对企业家是真实的，那么信息化就不可能是一个又一个项目的总和，更不是一个“需求膨胀带来开发膨胀”的“尝试过程”。错把“系统建设”当成“能力建设”，可能是信息化的“牛角尖”。在一些企业的信息系统建设项目中，常常可以看到这样的“牛角尖”：用系统选型、系统构成、数据标准、技术路线，作为信息化建设的整体规划，忽视了“IT对组织行为、业务流程、管理模式、经营思想”的重大影响。这种“牛角尖”现象，可能在一定程度上说明了一些企业，还没有搞清楚信息化的“化”字，应该怎么写。