信息化进程导致大量存量系统。大家都愿意投入全新的系统。
随着中国社会信息化的进程，包括政府、企事业单位、社会机构等信息化发展程度已经今非昔比了，过去如果哪个人有台电脑，有个笔记本，有个手机，那都是很自豪的事情，现在已经属于普遍现象了，所以不论是个人还是集体组织，信息化的基础设施都比过去完备了许多，这也是信息化进程的一部分，或者说是信息化进程的土壤。目前，社会上存在大量过去开发出来的并一直在用且要一直用下去的信息系统，就如同房地产，随着城市化的进程，房子被建的越来越多，那随着时间推移，存量房就越来越多，除了建新房子，以前建的房子也不能拆掉吧，拆迁这种情况也是发生在局部，是符合城市化进程的，以前的房子建好了要接着住，只是要安排必要的措施例如维修等使其具有持续性，要出新，要重铺地下管道等等，目的是要把老房子老小区更加适应当前和未来的发展状态，这个意思和信息建设是有一定相似之处的。过去的信息建设成果不能扔掉，还要接着利用，随着信息系统的“城市化进程”，部分信息系统要被废弃、推翻、搁置等，但这也只是局部的一部分，还是有很大一部分需要延用下去。然而，人都是喜新厌旧的，但是现实情况却不总是提供新的给你，老的你还得投入呀。一个软件的开发，往往1-2个月就完成，而他的销售，实施，升级周期长达4-8年。但每个老板好像都认为已经开发完毕，修修补补都是小功能，所以一个老系统维护一个人员就可以了，殊不知白纸好画画，要在别人的画上再能点睛成龙就难上加难了。老系统的改造升级中可能也涵盖局部的新研内容，需要考虑的和处理的工作比完全新研的可能还要更加的复杂，那需要继续延用的信息系统该如何延续呢，怎样着手才更可能把项目做成功呢。
前期进行顶层设计，
硬件软件改造升级统一考虑，
老特性复用和新研相结合考虑，
原系统团队成员和新成员相互配合工作，
研发和运维模式先行设计，
新老系统的运行切割规划设计，
改造升级的代际规划，
技术和市场一并规划。
人都是有路径依赖的，他原来所处环境和他所具备的能力除了能够帮他，也能成为他的枷锁，所谓总是存在能力陷阱的，人们习惯于一直所处的环境，一直容易定位于之前的角色，这些因素可能会导致一个人考虑问题会从单一或少数角度来处理，我们所说的话，所写的文字都是基于自己的已有认知，都是在做自己认知范围内的事情，那么多听听多看看其他人认知的事情，有助于拓展自己的认知范围。这是通理，放在各行各业都有意义。放到信息系统建设这个行业里，做软件的人想不到硬件的事，搞技术的想不到市场的事情，搞生产的看不到做研发的，等等这些情况都是很常见和很正常的。我们现在可以一起来看下如何针对老系统的升级改造可能需要涉及哪些方面。
前期进行顶层设计
人们做事都可能具有冲动性和激情，尤其是年轻人，信息化行业的年轻人也居多，做事有干劲有闯进，来了个项目，就想立马开干，程序员就想立刻敲代码，产品需求人员就像赶紧画原型，各角色人员都迫不及待的投入到角色中开干，这可能是普遍现象。凡事预则立不预则废，是一个普遍法则，放在各行各业均有适用性。了解过PMP的都知道做项目有多少过程域，有多少领域管理，这其实就涉及到了顶层的规划设计，对范围怎么管做多少事情你得有个大概的想法吧，风险有哪些程度怎么样你心里要有点数吧，哪些干系人是需要重点关注的需要考虑到吧，你自己打算或者公司给你多少预算你得规划吧，等等这些范围、质量、成本、干系人等等各方面的事情在事前需要进行必要的工作，即使不是很正式的处理，必要的工作你考虑到了并且提前着手了总是有好处的，不管过程中是否存在变更，变更多少，前期的工作是重要且必要的，否则就是脚踩西瓜皮滑倒哪里算哪里，遇到了再说。这多少有盲目的成分，除了极少数无法预规划，主要是摸着石头过河的事，大多情况你是需要谋划章法的。关于如何做信息化项目的模式或者方法论都有很多，结合中小企业的模式，一般需要进行必要的裁剪，留一些最主要的内容加以规划设计。结合项目的类型，老系统的升级改造也是区分是公司的自研产品，还是为客户定制交付的项目，或者是二者的结合物，都需要进行各过程域的规划。就拿成本来举例，做个项目准备花多少钱或需要花多少钱，要做个测算，华为的Charter立项书中一般也是包含投资评估内容的，投入多少产出多少，投入的就算是成本了。假设公司已经批了预算，这笔钱有了，例如是100万，怎么花需要有个初步规划，否则过程中做成本控制时没有参照依据，成本是否超支了不好控制。硬件和软件的投入比例是多少，当然业界这没有标准，得看行业和项目类别，是更侧重硬件还是更侧重软件。项目实施分为几个阶段，每个阶段成本投入的比例大体有个切分，这样方便按照各子阶段细化成本控制，例如划分为前期阶段、需求阶段、设计阶段、研发阶段、生产阶段、实施阶段、运维阶段等等，根据自己公司的实际情况和项目的实际模式来划分，每个公司划分的阶段都不太一样，有的阶段需要再细化有的阶段就合并了，有的阶段就不存在，你觉得哪个阶段需要的投入的更多就多预留以下，如果能再预留一些储备以备不时之需也是极好的。对于信息化的项目主要的成本可能在于人力成本，用什么样能力等级的员工，各能力等级的员工数量比例是多少，他们投入的周期是多久。老系统升级改造在这些方面可以参考原来的情况，如果原来还有这些历史资料作为参考的话，之前做的项目的成本投资是如何做的，可以寻求前人的帮助，老系统的升级改造不一定是同一拨来做。所有的项目成功与否跟人都都是有关系的，其中有一类人是很重要的，也是容易被忽视的，就是高层，包括甲乙双方的高层，尤其是在项目的前期阶段，在规划设计阶段，要多倾听他们的意见，请他们做指示，即使没有具体的指示，有方向性的指示也有利于把握项目的大方向不要跑偏了，在做顶层设计时能让他们参与进来，后来被否定的风险就小一些，怎么请他们参与，参与模式是什么，关键里程碑邀请他们评审，还是周期例会参与，要在前期设计好。
综上所述，基本要考虑到主要的过程域进行规划设计，包括整体管理、范围管理、成本管理、质量管理、人力资源及干系人管理（尤其是高层）、进度管理等，其他方面例如采购管理，如果主要涉及了则要考虑，不涉及的话问题也不大。
硬件软件改造升级统一考虑。
有的系统尤其是集成类系统都会有终端，传感器等硬件结合软件共同形成一个整体的系统，老系统改造升级可能涉及方方面面，可能包括硬件性能指标方面的升级，例如硬件精度、自然环境适应度、外观、内部嵌入式程序等等，其次还可能涵盖与软件系统的对接适配的改造，软件系统的升级需要硬件的配合支持，给硬件提出相应的支持要求，当然硬件的改造升级首先得符合某些国标地标之类的通用标准。如果软件端开发为了扩展硬件接入渠道，会做软件的接口升级，从而适应多种硬件接入。硬件来源如果是从外部采购，那原来的硬件供应商可能就要满足软件单位的要求，该供应商就要结合软硬件两端的接口或规范，共同规划并实施改造升级工作，这又可能涉及到采购或市场相关工作，需要在项目前期的规划阶段考虑到位。硬件改造升级的过程中，仍要相互配合进行调试测试，实际投产运行之后，需要安排硬件的包装及安装实施工作，零部件的更换维修工作，问题的跟踪处理。
技术和市场一并规划。
所有的技术都是为市场服务的，技术一般不能孤立存在于商业中。所有的利润、现金流等都通过市场渠道进行输入输出。技术通过实现市场渠道进入的需求，解决痛点从而实现商业价值。技术需要带有一定的前瞻性，另外也不可玩弄技术，技术控是需要付出代价的，当然也有例外的情况，如果技术的研究本身就是为未来技术的升级，以更好的促进使用该技术的机构或个人更容易更好的实现他们本身的商业价值，那么这些技术的研究工作是通过他们来实现商业价值，这类技术控是有必要的。另外的情况，技术的选型需要考虑到能适应市场多久的发展，是一年、三年、五年，可能不一定能规划的很清楚，但你得考虑到，否则未来仍要为此而付出代价。
基于角色或岗位职责不同可能导致市场考虑不周：
不同的角色考虑的事情自然不同，程序员考虑的是如何写代码实现需求，测试人员考虑质量把控，需求人员考虑范围工作，老系统的改造升级工作的负责人需要考虑更加全面，除了前面提到包括人员、时间、成本、范围、质量等各项目领域的事情，其中可能会涉及到市场方面工作，例如人员不够的时候可能需要外包人员，需要配合调测的硬件可能需要采购，部分技术工作可能需要分包等，这些内容涉及到公司的采购流程或市场流程，需要在事前做好规划工作，这些工作可能不一定是该项目的负责人具体负责的，但他仍要推动相关人员进行市场或商务工作。市场或商务工作和技术工作应该是双轨并行的，这些工作往往是容易被忽视的，特别是容易被技术型的负责人所忽视，如果未能及时关注可能会导致后期的时间风险。
有效结合市场反响进行技术实现
进行老系统的改造升级需要考虑到原有系统在市场中的反响，收集使用过程中存在的问题，评估在市场中的生命周期，基于这些情况再来分析老系统的改造升级的重点放在哪里，是原有的特性不能完全满足市场需求，需要增加新的特性来增强市场竞争力，还是老系统存在问题过多影响使用，需要进行维护解决故障，还是性能不能满足需要进行软硬件技术改造升级。诸如此类的情况，需要具体情况具体分析。
老特性复用和新研特性相结合考虑。
老系统的改造升级和新系统的研发是有所区别的，新系统的研发工作可能更多的考虑向未来的兼容性，老系统的改造升级除了考虑向未来兼容，也要考虑向过去兼容。谈这个问题，可能涉及到进行老系统的改造升级的初衷目的是什么，是市场发生了变化，原有的业务逻辑或业务模式已经无法适应当前或未来了，还是原有的技术落伍了无法继续支持系统服役了，还是为了争取未来的市场增加竞争力等等，原因可能不止一种，如果老系统的业务逻辑可能仍然是正确和适用的，那么完全舍弃原来的特性，全部新研可能也算一种浪费。那么如果要复用，如何复用，如何相结合可能需要考虑的事情。
老特性的业务逻辑、业务模块整体做迁移甚至原封不动使用原来的代码嵌到改造的系统中，也可以把原有的业务逻辑做出服务提供api供改造的系统使用，这样就直接复用了原来的业务逻辑，尤其对较为复杂的且相对稳定的业务系统适宜采取这种方式。另外针对软件技术方面，原有成熟的技术组件可以照搬复用，有些技术组件是不受具体业务限制的，是通用类型的组件，有些根据业务定制的技术组件，这块的特性复用可能会涉及到改造才能复用。
原系统团队成员和新成员相互配合工作
一个改造升级的项目建议既要使用原来的人员也要补充新团队成员。主要是基于三个方面的考虑，第一是充分利用原有人员的业务熟悉度，第二是利用新成员的思维和技术模式，第三是一个项目的新老人员的承接性延续性。
先来说第一点为什么要充分利用原有人员的业务熟悉度，不论是在什么行业领域的信息系统，都是要在掌握业务的基础上通过技术手段进行落地实现，技术也是为业务服务的，如果全用新成员或者不了解业务的人员参与，必定会加大项目成功风险以及项目成本，另外还有一个风险就是，新参加的人员心里会有不安定的因素，可能会认为都没有懂业务的技术人员参与，他们的心里可能会没底，虽然在业务这块可能有产品人员或需求人员做传递和把关，但如果有研发技术人员在业务这块参与，上手会更快，工作量的评估或需求传递等工作会更有效率。为什么很多公司招人都喜欢招聘类似行业经验的人，不需要花太多时间熟悉业务上手快直接能干活是很重要的因素。其次就是充分利用新成员的思维和技术模式，原来的人可能在公司很长一段时间了对老系统也比较熟悉，使用的也是原来的一套技术，对原来做项目的模式都比较熟悉，人都有这样的特点，都惯于按照自己熟悉的模式做事，如果在老系统的改造升级方面想做一点创新的话，可以趁着新成员还没有被同化，思维比较活跃，从其他公司或从其他项目组过来后还可以带来新的思想，如果老系统的改造升级需要更换技术，这方面新成员可以起到带头作用。
第三是一个项目的新老人员的承接性延续性，这一点其实对长生命周期的项目比如公司成熟产品是尤其重要的。铁打的营盘流水的兵这个说法也适用于一个产品一个项目，这个活一直做下去，但是人员是流动的，有人进来有人出去，对一个项目来说如何避免断层的出现，和公司整体的人力资源管理有异曲同工之处，都会有选用育留的问题，这是个大课题，详细的情况咱们可以在人力资源或团队建设的相关章节细聊。另外对新老成员的比例也没有个固定的标准，也要看你老系统改造这个项目的规模和周期，如果你对老系统的整体不做大的改动，只做新增补功能和外围的升级，原有人员的比例可以低一些，如果是老系统做颠覆性的改造升级，那么对业务和技术都要有把控的人，原来人员可以稍多用一些。当然如果存在一些空降的领导或轮岗调配的负责人在主导工作，那么新老成员的利用情况是另当别论的，因为这可能涉及到领导者用人顺不顺手或者把控度的问题，甚至存在有意培养心腹亲信的情况。
研发和运维模式先行设计
这节以后再写。
新老系统的运行切割规划设计
这个问题可复杂可简单。要根据每个公司或者每个项目的规模来看。一般来讲，老系统改造升级需要进行新老系统的运行切割的规划设计，最基本要做个初步规划。底层的数据存储是最基本需要考虑的，数据结构变更后新老兼容、接口升级的新老兼容这类的兼容性在实施过程中就在考虑了，如果原来的老系统和改造升级后是两套数据库，尤其是数据库的类型变更成另外一种了，例如从Oracle变更成MySQL，这种情况两套数据库类型的标准和适配需要设计，不要出现数据转储的问题，原来数据库中的数据（包括非结构化的数据）是迁移备份出去还是需要转储到改造后的数据库中迁移备份是一次性的批量操作还是分阶段操作需要考虑到位。
处于过程中尚未结束的业务数据，例如一个请假单处于流程中尚未完成，这个时候在新老切割，这种情况如何处理，当然你可以规定必须把所有流程走完，不能存在过程中的数据再进行切割，这个要看具体业务情况和客户或用户的接受度。
如果存在硬件终端的集成类的信息化系统进行切割可能会复杂一些，新系统要适配兼容老终端，这种情况下，你可以允许新老系统同步运行一段时间，老终端依然对接老系统，新安装的终端硬件对接新的软件系统，新老终端硬件和新老软件后台双规并行，在数据存储方面进行整合在一套系统中，直到老的终端硬件‘寿终正寝’自然结束。也有可能你把所有的老终端硬件全部拆除更换成新的硬件终端，这样一刀切会暴力简单些。也有可能新老终端硬件同时存在于市场中，软件后台系统升级成一套，那么老终端硬件数据传到软件后台软件，数据传输的路由（路径）需要定向到新升级的软件系统，你可以修改传输路由的定向路径，或者你干脆把市场上的终端硬件的IP及端口号全部更换指向新的软件系统。还有一种相对单纯一些，老系统的改造升级是在原来的基础上进行操作，物理上还是一个系统，这样切割会相对简单一些，因为在实施的过程中，就是一直兼容的，否则不好进行下去，这样都可能不一定存在明显的切割边界。当然这样的改造升级可能也存在一定的弊病，例如老系统原来存在的陈疾无法完全去除。
改造升级的代际规划
很多做信息化的人可能存在追求完美的倾向，想着把所有东西一次性的做完，但往往受限于人力，时间，市场等因素，决定了你这次只能做一定范围内的事情，不能把所有的想到的事情都做完。在合适的时间做合适的事情，是一种能力和定力。比如，现有的信息系统是2.0版本，本次准备改造升级成3.0，那么当前考虑的内容很多，哪些是需要放到3.0范围内的，哪些是当前3.0未考虑周全但需要进一步补充的。如果有一部分是放到未来的4.0，5.0等等。还有种情况你可能需要为了适应市场，要迭代匹配市场，有的想法很好，但市场尚不成熟，那做在本次3.0范围内可能就过早了，有的想法可能放在市场已经过时了，那再做进去就没有多大意义了。所以对于一个信息系统而言可能要规划每隔两年、三年、N年要做一次改造升级，做一次换血，去除陈疾，增强健壮性、拓展市场，为客户及用户提供持续的价值。
