野生项目新瓶如何和平改造老酒?
来源:IT168 更新时间:2012-04-15
 一个在建的信息系统要替代一个老的信息系统,应该如何处理?一种办法是将新的系统完全建成之后再进行系统初始化,初始化将提取老系统中的基础数据,按照新系统的格式进行补正和导入,在技术上应该是一种安全又妥当的做法。由于新系统在业务处理上有许多方法具有一定的创新性,迫切需要进行实践检验,自然项目周期也是比较长的,那感觉应该象造楼一样,一年多的项目周期之后才能进行交付,有点等不及。能不能边建设边应用呢?
应该有这样的办法!

    比如新的信息系统包含了销售管理、报价管理、产品管理、生产加工能力管理、品质管理、订单执行过程、运输过程以及结算等主体业务过程。可以在充分尊重业务连续性的前提下,在业务基础开发基本完成的时候,可以提取出可以形成闭环应用的小模块进行先实施。

    我想在这样的系统中,客户管理是可以形成一个阶段性的闭环的,对于一个建立了客户关系,就形成重复循环销售过程的B2B业务来说,客户管理的重点一般是三个方面:一是日常往来过程记录与情报提取,二是订单分析,三是投诉管理。订单分析部分需要等待整个业务过程贯通之后才能展开,投诉管理由于与具体的订单关联,如果要起到更实际的作用,也必须等到整个业务过程贯通之后才能实施,日常往来过程记录与情报提取却是可以结构化、又容易形成闭环的。它为主体业务过程提供环境支持,却不完全需要主体业务过程的数据为原料(如果需要,可以从老的系统中进行查询得到)。这样这个部分就可以开通运行了,当然它所涉及到的岗位与机构并不限于销售环节,还包含所有与客户有接触的岗位,都可以通过开放权限的办法进行信息输入、加工与分析。

    另外,报价模块也可以这样操作,它衔接了客户管理与主体业务过程。又是客制化产品管理的重要应用。在新的系统中,可以将新的产品管理逻辑迅速地进行应用性检验。我们将生产加工能力(包括设计、工艺等在内的企业活动也属于这个能力范畴)结构化基础数据与产品工艺结构化基础数据进行从容地录入,然后确定销售代表驱动客户新需求的产品化工作,内部通过协同机制对工、料、费的货币化,对合适工艺活动的选择与联结,对新的业务进来之后,企业未来的负荷变化、支撑能力的变化等等方面进行迅速评估。一般说来,这个过程所消耗的时间与“手递手”转化、呼应过程所消耗的时间相比较,可以减少80%。应该能够得到销售代表、销售管理者等岗位的支持。最主要是它是可以闭环的!报价工作完成后,过程数据作为客制化产品的数据指导后续业务,这个指导可以在老系统中体现一部分,也可以以离线支持的方式抵达工序现场。

     这些做到位之后,它们就成为新系统的基石,我们可以继续“挖掘”出新的具有闭环性质的应用来进行如法炮制,直到主体业务过程可以和平上线。

     这是不是就是“新瓶改造老酒”的意思呢?

    另外,新的应用数据如何准备,如何通过“内部人示范”进行业务逻辑教育与业务过程培训?

    什么叫“内部人示范”?在《野生项目笔记01》的最后我提到“新的应用数据如何准备,如何通过‘内部人示范’进行业务逻辑教育与业务过程培训?”这是非常具体的问题,当然不同的机构对于软件项目的实施方法是不一样的。记得几年前,与一个全国性公司的一个地市级公司的软件系统管理人员交流,他谈到软件实施公司(软件许可购买自软件公司,实施服务由另外一家公司承担)的实施办法,当时觉得那样做太费时间了,后来觉得相当有道理,而且会保障新系统的安全稳妥运行,尤其是业务逻辑、业务过程变化比较大的时候。

    他们的具体做法是:在基层(县级管理机构)选拔精通业务有计算机基础的人员到市里面统一进行“地图作业”,业务也是分好多块的,有财务开票,有加油作业,有物资管理等等。地图作业由软件实施公司的顾问主持,教授学员操作新的系统功能,非常细致,基本上是一个PPT,对应一套习题,然后在演示系统中进行练习。布置的作业有两种,一是同样的业务,目前处理与新系统处理的方法有什么不同?如何改进?有没有更好的方法?二是该业务所需要的基础数据收集,比如产品型号,职工资料等等。老师批改作业,同时启动下一轮的课堂教学。安排得非常紧凑。基本上几轮下来,具体业务模块的基础数据准备工作已经顺利完成,新的系统环境也熟悉到位,具体应用中可能遇到什么样的问题也比较清楚。最根本的是基于新业务立即的业务种子已经形成,他们由学员成为师资,可以为县属机构的同类业务的岗位人员展开培训了。

    据说,后面的实施工作比较顺利,因为由熟悉两边情况的人员主导。

    平台软件与商业软件不一样的是,应用功能设计中存在的问题经过评估和批准后,可以迅速得到修改。虽然一个单体企业从实施工作量上似乎不需要这个过程,但是从实施质量来看,还是非常值得引入这个过程的。其核心是“内部人”具有不一样的实施准备价值,实施方与应用方有了很好的合作管道,可以进行“就事论事”般的沟通,可以跳出一般的利益圈子,潜在的问题容易透明。当然,这个前提是业务功能已经根据需求做出来了,至少超过原型的精细程度。事实上等于有了一个共同雕琢的对象。

    当然我们清楚,这个过程中还有许多东西需要明确的,比如,需求必须进行结构性的变更,应该如何处理?