企业ERP系统开发总结及建议

企业ERP系统开发总结及建议

作者：成晓旭

对于像我们这种规模的大型公司，自己建设、实施和维护满足公司特定管理要求的管理信息系统，是目前部分大型公司建设企业ERP的常见思路。比如：XXXX、XXXX、XXXX、XXXX等等知名企业。

其实：这种ERP系统建设方式，我本人并不看好和推荐：社会分工进一步精细化的今天，让更专业的团队去做更专业的事情是大势所趋。然而，既然公司采用这种方式建设自己的综合信息管理系统，本着把事情做好、让公司放心的原则，让来年更有效的为公司综合信息管理系统提供支撑，结团队一年来的开发、维护工作、提出几点浅见：

1、加强相似业务流程、管理模式的抽象与提炼，通过系统分析与设计、并编码实现成我们自己的基础架构源码库。下面用简单的源码统计工具，针对今年开发上线的新、旧两个版本的XX系统，进行代码行数统计分析情况：

通过重新开发系统基础架构，减少系统代码量，相信就能极大地降低系统后期的测试、调试、维护、升级的复杂度和工作量。

2、注重新建子系统、功能模块、业务构件、甚至是最简单的一个新单元、新类的重新分析、设计和实现。针对目前整个系统的在新运行情况和日常的维护工作量，我们不大可能有充足的人力和时间，来整体重新构建各个在线的子系统。但新业务需求的实现时有发生。既然是新增功能、新写代码，我们更有理由摒弃原来不太好的开发方式和思路，采用一些更专业、更成熟软件开发模式与架构，至少让新增的功能块从上线开始，就有较好的稳定性、较高的可复用度、较强的可扩展性。坚持这样，才能逐渐、逐渐地提升整个软件系统的内部质量特性、才能逐渐、逐渐地减少系统的维护工作量；否则，随着软件代码量的日益增加、系统功能的日益复杂、业务需求的频繁变化，已建系统对新需求变动的满足难度势必越来越大：“雪球效应”很可能发生在系统支撑小组，导致系统支撑小组最终很难再继续有效地支撑下去。

3、为支撑小组的软件开发、维护工作选择适合的软件开发方法论，并结合具体工作实践进行裁剪或增补。根据团队实际工作情况的引入更合适的软件开发方法，将极大改善开发团队的工作效率、提升交付软件产品的内外品质：已是不容质疑的事实。传统的软件开发方法、信息化软件开发方法、统一软件开发方法，都不太适合我们公司系统这种“应用需求变动频繁、支撑资源配置紧张”的现状。

建议采用敏捷软件开发方法的原则与模式：

1.准确把握公司生产管理及运营需求；

2,适度设计并保持设计的灵活性；

3.简单开发以满足当前需求；

4.频繁重构与迭代保持系统当初的设计原则；

5.测试驱动开发和加强单元测试从最底层开始确保系统的健壮性。

4、在公司系统的开发、维护、支撑过程中，建议一定要坚持系统建设初期的分析、设计、编码原则，至少最起码的基线原则必须坚持。进公司几个月来，听到、看到太多的、很好的原则在现实面前妥协的情况。表面上看，我们的妥协当时是缩短了开发时间、提高响应公司领导决策、或者财务、人力、总经办等部门经理的管理要求；其实，事后我们往往为违背这些原则付出了更大的代价。众所周知，任何项目系统的建设，在人力、时间、质量等方面都是受限制并且相互制约的。软件系统的经典的设计模式与原则也是人所共知的，最终软件产品的质量在很大程度上，就取决于开发团队在软件构建过程中，对原则的坚持力度与执行力度上。

6、加强系统测试、尤其是开发初期的单元测试。在系统开发、维护工作中，很多次发现这样的现象：运行很久的程序功能突然发生一个异常，通过跟踪代码，错误居然被定位很基本的指针保护或逻辑错误上，而这些错误极易在单元测试中被覆盖、发现和解决，相反，在系统后期的组件测试、集成测试、回归测试、系统测试阶段较难再现。这类问题还反应了我们原来的测试用例的代码覆盖率不高。

为新的一年能够更加有效地响应公司发展战略规范、支撑企业信息化战略的落地与实施，对支撑团队来年的系统工作提出几点要求，概况如下：

1.准确把握公司信息化的当前需求但不求全责备；

2.采用经典、成熟的设计原则与模式但不过渡设计；

3.尽量用简单的编码来实现当前功能；

4.通过频繁的重构来坚持期初的设计和实现原则；

5.维护和新增功能前尽可能先重构再重用、杜绝通过“代码复制”实现相似的系统功能；

6.加强单元测试，保证系统构件的可靠性与健壮性、将软件BUG的大部分解决在单元开发期间。

最后分享个人的以前做项目的经验：“用精巧、优雅的设计来应对需求的瞬息万变；用重构与迭代来维持良好的系统体系架构；注重单元测试保障系统内部、外部品质”。