申请免费试用、咨询电话：400-8352-114

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

第一次听说erp，是在五年前的大学课本上，第一次使用erp，是在大学毕业前实习时，在实验室里见到的北京和佳erp，真正的对erp有系统的学习、培训、使用和运用，是我们公司目前在用的全球知名的ifs的erp。25年年初，我们公司的erp财务模块项目启动，整个erp系统的实施，可以分为以下四个阶段：(一)接受培训、软件安装和熟悉软件阶段;(二)基础数据准备阶段;(三)初始上线阶段;(四)验收检验阶段。作为项目小组的一员，在第一阶段接受培训中，我们就遇到了实施过程的第一道坎：

首先是观念冲突：erp是一种先进的企业信息管理系统erp系统开发总结，它不仅仅是一套软件，这会与我们的传统观念产生很大的冲突。是对我们脑袋里固有观念的挑战。如果我们不对它多接触并认真学习的话，我们很难接受它。在我们财务模块，这点的表现尤为突出。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的大部分解决在单元开发期间。