论文部分内容阅读
一直有媒体在报道，中国的建筑物平均寿命只有30年，而国外有的地方的建筑物寿命则在百年以上。让我印象最深刻的是青岛这个城市的市政建设，据说100年前德租界内的地下管道系统至今还在使用。回到ERP领域，企业信息化的历史在中国已经30多年，如果拿一个人来说，这算得上是三十而立了，但对于信息化领域来说，许多CIO面临着诸多烦恼，其中之一就是5年或者是10年以前上线的系统（我们也称之为历史系统）现在该如何持续应用。
也许是IT行业发展太快，许多企业在应用ERP系统时并没有想过这个系统用了5年或是10年以后应该如何处理。曾经有些企业的IT经理持这样的观点：一个系统的生命周期也就是3到5年，到了5年以后就需要考虑更换了。
历史系统能扔进垃圾堆吗
再看看我们身边的实例。有许多IT经理其实都在做项目经理职责范围内的工作，不停地选型和督促系统上线，上线工作总是没完没了，而这类企业的系统寿命往往不超过5年。企业真的需要在应用系统上进行如此巨大的重复投资吗？现在的软件厂商具备持续服务的能力，软件系统的平台也足够健壮，软件系统在不断适应企业的发展与变化要求。企业难道不能提前做好系统生命周期管理的规划工作吗？当然，这种抱怨只在规划新系统时起作用，历史系统该如何处理？
凡是做技术的人都知道，技术有“后发优势”，也就是越晚开发的系统，越有可能使用较新的技术，而往往这一类的系统越能符合业务要求，对于当前的复杂商业环境有更好的适应能力。但对于5到10年的老系统，是否需要进行重视审视呢？如上面所说，将10年以上的系统直接送进垃圾堆，重新做一套系统代替原来的系统，如果问题这么简单就好了。我们假设一个场景：超过2000个用户，超过50个人的团队在维护，超过1.5T的历史数据，涉及到了企业所有的核心业务环节，支撑着企业一年50亿元的销售额——这样的一套系统你敢说直接送它进垃圾堆吗？
这个时候就需要CIO们非凡的IT规划能力了，首先应该对现有的系统进行评估，结合企业当前的业务现状、未来的发展规划，重新为这套系统规划出合理的生命周期。也许这套系统真的不适用了，也许这套系统在进行充分保养的情况下还可以用上5到10年，这取决于很多复杂因素。但有一点是可以肯定的，在没有完善的后备计划情况下，立即停用这套系统的后果将是灾难性的。
分情况处理老系统的模块
经过充分保养后可再用5到10年的历史系统，我们该如何保养？这时，我们可以考虑采用一些现代化的技术对历史系统进行改造，需要思考如下几个问题：
识别出历史系统可以被保留的部分，预计使用周期还有多长；有一些系统因为上线之后缺乏足够的保养与维护，也没有进行太多的升级改造，可能会在业务层面制约着企业发展，这时就需要对其价值进行重新评估了。
历史系统被保留的部分，是否可以使用一些新技术进行改造（甚至算不上是新技术的技术），如CS的软件架构或是Web Services 技术，当然如果能用上SOA等技术要看机遇了。历史系统能够被保留，最大的原因就是其在业务层面仍旧能够发挥巨大作用，能够支撑业务的发展，而不是制约业务的进展。只是这一类的系统由于历史的技术限定而无法再使用，所以需要考虑进行系统架构的升级。如果这时升级，新平台采用什么样的软件架构？这时往往受限于软件供应商，如果软件供应商已经停止了对于历史系统的升级支持，此时你就不得不忍痛割爱更换系统了。
哪些系统需要采用新系统替代？如果要用新系统的话多久可以投入使用？同时还需要考虑新系统如何与旧系统进行整合，这都需要提前考虑清楚。
新系统上线的风险也需要充分考虑，因为这还涉及到新系统中如何装入老数据的问题，如果这个问题解决不好，意味着企业的核心资产——数据与信息会被新旧系统割裂，很有可能得不偿失。
如果我们要基于新的业务需求对原有的系统进行改造，首先要弄清楚几个问题：
该历史系统的供应商是否还存在？有许多历史系统很有可能已经找不到原有的供应商了，而没有供应商的系统很可能意味着没有代码，没有开发文档，也自然就没有进行再次改造升级的可能了。当然，从这个角度来说，选择一个专注而且能够持续经营的软件系统供应商有多重要了。如果该软件厂商已经不存在，或者对于老系统停止持续的升级改造，这时就需要重新选择一家合适的软件供应商了，而这个时候就不能称之为系统升级了，而是重新构建ERP系统了。如果要重新构建一套ERP系统，往往对于企业伤筋动骨，代价巨大，这时也需要谨慎评估。
该软件供应商是否推出了后续版本的产品？如果该软件商在持续经营，我们则要关注其是否对产品进行持续的升级与改造，如果有新版本的产品，就可能能够满足许多业务上的需求，而不需要另起炉灶单独定制了。当然，如果评估确定新版本产品符合企业当前或者是未来一段时间的业务需求，则可以考虑直接采用新版本产品进行需求实现了。
需要升级全线产品还只是部分模块？企业有许多业务流程可能发生了巨大变化，但也有许多业务单元是相对稳定的（如财务流程），这时我们就需要考虑是全线升级ERP，还只是部分模块的升级了。如果只是部分模块的升级，随之而来需要考虑的问题是：ERP软件供应商能够支持不同版本模块之间的集成吗？如：销售模块采用的是2.0版本，而财务模块还只是1.0版本，关键是这两个版本还要相互兼容，确保模块之间畅通无阻。当然进行系统集成的最大风险还在于软件系统的底层平台是否能够共存，包括业务主数据是否能够相互畅通，如果不能实现模块之间的集成的话，那就只有采用升级这个方法了。
ERP升级的两大策略
ERP升级有两种不同的策略：一种是在现有版本功能上进行二次开发，直接实现企业的业务需求。这种方式适用于新业务需求，所投入的工作量不大，而且原有版本系统已经做了足够多的个性化开发，且新版本功能中不包括这些功能。这种模式的缺点是系统越来越朝着个性化开发的方向走，与软件供应商的标准版本相差越来越大，系统的应用生命周期可能不会太长。另一种方式是先升级到全新的ERP版本，然后集中把原来做过的个性化功能在新系统上实现。这种方式的好处是与软件供应商的版本基本保持一致，还存在着未来再次升级的可能。当然这样做也存在问题，就是历史数据如何迁移和个性化功能重复开发的问题。不管如何，CIO们必须从这两种策略中做出选择，否则就只能眼看着ERP系统步入衰老期。如同汽车保养一般，购买了一辆豪华跑车之后，司机——企业CIO需要思考如何将ERP这辆跑车调校到最佳状态，并通过长期保养确保其一直处于优良状态，为企业提供经久不衰的、舒适的“乘车”服务。
对于ERP软件供应商来说，如果能够帮助客户做好ERP系统的全生命周期管理，能够伴随着客户的业务发展提供不断深入的咨询与软件交付服务，那么这家ERP软件供应商将会随着其客户一并实现“基业常青”。也是基于这个背景，国内外许多优秀的ERP软件厂商都提出了“向服务转型”的战略目标，这也如同汽车厂商除了卖汽车之外，更应该着眼于如何将4S店的客户服务做好，毕竟持续服务才能永续经营之道。
链接
生命周期管理
所谓产品生命周期管理（Product Life-Cycle Management，PLM），就是指从人们对产品的需求开始，到产品淘汰报废的全部生命历程。PLM是一种先进的企业信息化思想，它让人们思考在激烈的市场竞争中，如何用最有效的方式和手段来为企业增加收入和降低成本。
一套高效、完善的PLM解決方案能让企业建立详细、直观和可行的数字化产品信息；及早综合各个参与者的信息，从而发现和解决关键问题；对交付生产、更改控制和配置管理等关键过程进行控制，并使之自动化。
也许是IT行业发展太快，许多企业在应用ERP系统时并没有想过这个系统用了5年或是10年以后应该如何处理。曾经有些企业的IT经理持这样的观点：一个系统的生命周期也就是3到5年，到了5年以后就需要考虑更换了。
历史系统能扔进垃圾堆吗
再看看我们身边的实例。有许多IT经理其实都在做项目经理职责范围内的工作，不停地选型和督促系统上线，上线工作总是没完没了，而这类企业的系统寿命往往不超过5年。企业真的需要在应用系统上进行如此巨大的重复投资吗？现在的软件厂商具备持续服务的能力，软件系统的平台也足够健壮，软件系统在不断适应企业的发展与变化要求。企业难道不能提前做好系统生命周期管理的规划工作吗？当然，这种抱怨只在规划新系统时起作用，历史系统该如何处理？
凡是做技术的人都知道，技术有“后发优势”，也就是越晚开发的系统，越有可能使用较新的技术，而往往这一类的系统越能符合业务要求，对于当前的复杂商业环境有更好的适应能力。但对于5到10年的老系统，是否需要进行重视审视呢？如上面所说，将10年以上的系统直接送进垃圾堆，重新做一套系统代替原来的系统，如果问题这么简单就好了。我们假设一个场景：超过2000个用户，超过50个人的团队在维护，超过1.5T的历史数据，涉及到了企业所有的核心业务环节，支撑着企业一年50亿元的销售额——这样的一套系统你敢说直接送它进垃圾堆吗？
这个时候就需要CIO们非凡的IT规划能力了，首先应该对现有的系统进行评估，结合企业当前的业务现状、未来的发展规划，重新为这套系统规划出合理的生命周期。也许这套系统真的不适用了，也许这套系统在进行充分保养的情况下还可以用上5到10年，这取决于很多复杂因素。但有一点是可以肯定的，在没有完善的后备计划情况下，立即停用这套系统的后果将是灾难性的。
分情况处理老系统的模块
经过充分保养后可再用5到10年的历史系统，我们该如何保养？这时，我们可以考虑采用一些现代化的技术对历史系统进行改造，需要思考如下几个问题：
识别出历史系统可以被保留的部分，预计使用周期还有多长；有一些系统因为上线之后缺乏足够的保养与维护，也没有进行太多的升级改造，可能会在业务层面制约着企业发展，这时就需要对其价值进行重新评估了。
历史系统被保留的部分，是否可以使用一些新技术进行改造（甚至算不上是新技术的技术），如CS的软件架构或是Web Services 技术，当然如果能用上SOA等技术要看机遇了。历史系统能够被保留，最大的原因就是其在业务层面仍旧能够发挥巨大作用，能够支撑业务的发展，而不是制约业务的进展。只是这一类的系统由于历史的技术限定而无法再使用，所以需要考虑进行系统架构的升级。如果这时升级，新平台采用什么样的软件架构？这时往往受限于软件供应商，如果软件供应商已经停止了对于历史系统的升级支持，此时你就不得不忍痛割爱更换系统了。
哪些系统需要采用新系统替代？如果要用新系统的话多久可以投入使用？同时还需要考虑新系统如何与旧系统进行整合，这都需要提前考虑清楚。
新系统上线的风险也需要充分考虑，因为这还涉及到新系统中如何装入老数据的问题，如果这个问题解决不好，意味着企业的核心资产——数据与信息会被新旧系统割裂，很有可能得不偿失。
如果我们要基于新的业务需求对原有的系统进行改造，首先要弄清楚几个问题：
该历史系统的供应商是否还存在？有许多历史系统很有可能已经找不到原有的供应商了，而没有供应商的系统很可能意味着没有代码，没有开发文档，也自然就没有进行再次改造升级的可能了。当然，从这个角度来说，选择一个专注而且能够持续经营的软件系统供应商有多重要了。如果该软件厂商已经不存在，或者对于老系统停止持续的升级改造，这时就需要重新选择一家合适的软件供应商了，而这个时候就不能称之为系统升级了，而是重新构建ERP系统了。如果要重新构建一套ERP系统，往往对于企业伤筋动骨，代价巨大，这时也需要谨慎评估。
该软件供应商是否推出了后续版本的产品？如果该软件商在持续经营，我们则要关注其是否对产品进行持续的升级与改造，如果有新版本的产品，就可能能够满足许多业务上的需求，而不需要另起炉灶单独定制了。当然，如果评估确定新版本产品符合企业当前或者是未来一段时间的业务需求，则可以考虑直接采用新版本产品进行需求实现了。
需要升级全线产品还只是部分模块？企业有许多业务流程可能发生了巨大变化，但也有许多业务单元是相对稳定的（如财务流程），这时我们就需要考虑是全线升级ERP，还只是部分模块的升级了。如果只是部分模块的升级，随之而来需要考虑的问题是：ERP软件供应商能够支持不同版本模块之间的集成吗？如：销售模块采用的是2.0版本，而财务模块还只是1.0版本，关键是这两个版本还要相互兼容，确保模块之间畅通无阻。当然进行系统集成的最大风险还在于软件系统的底层平台是否能够共存，包括业务主数据是否能够相互畅通，如果不能实现模块之间的集成的话，那就只有采用升级这个方法了。
ERP升级的两大策略
ERP升级有两种不同的策略：一种是在现有版本功能上进行二次开发，直接实现企业的业务需求。这种方式适用于新业务需求，所投入的工作量不大，而且原有版本系统已经做了足够多的个性化开发，且新版本功能中不包括这些功能。这种模式的缺点是系统越来越朝着个性化开发的方向走，与软件供应商的标准版本相差越来越大，系统的应用生命周期可能不会太长。另一种方式是先升级到全新的ERP版本，然后集中把原来做过的个性化功能在新系统上实现。这种方式的好处是与软件供应商的版本基本保持一致，还存在着未来再次升级的可能。当然这样做也存在问题，就是历史数据如何迁移和个性化功能重复开发的问题。不管如何，CIO们必须从这两种策略中做出选择，否则就只能眼看着ERP系统步入衰老期。如同汽车保养一般，购买了一辆豪华跑车之后，司机——企业CIO需要思考如何将ERP这辆跑车调校到最佳状态，并通过长期保养确保其一直处于优良状态，为企业提供经久不衰的、舒适的“乘车”服务。
对于ERP软件供应商来说，如果能够帮助客户做好ERP系统的全生命周期管理，能够伴随着客户的业务发展提供不断深入的咨询与软件交付服务，那么这家ERP软件供应商将会随着其客户一并实现“基业常青”。也是基于这个背景，国内外许多优秀的ERP软件厂商都提出了“向服务转型”的战略目标，这也如同汽车厂商除了卖汽车之外，更应该着眼于如何将4S店的客户服务做好，毕竟持续服务才能永续经营之道。
链接
生命周期管理
所谓产品生命周期管理（Product Life-Cycle Management，PLM），就是指从人们对产品的需求开始，到产品淘汰报废的全部生命历程。PLM是一种先进的企业信息化思想，它让人们思考在激烈的市场竞争中，如何用最有效的方式和手段来为企业增加收入和降低成本。
一套高效、完善的PLM解決方案能让企业建立详细、直观和可行的数字化产品信息；及早综合各个参与者的信息，从而发现和解决关键问题；对交付生产、更改控制和配置管理等关键过程进行控制，并使之自动化。