自1990年美国着名管理咨询公司Garter Group Inc.最早提出ERP的概念后，随着上世纪90年代互联网等技术的快速发展，国内外大量厂商纷纷进入这个领域，国际上涌现出SAP、ORACLE等一批知名的ERP开发商，国内则出现了用友、金蝶等一批ERP厂商。随着近年来管理理念与技术的发展，ERP系统已逐渐深入人心，大有成为现代企业管理必不可少的工具之势。
ERP应用系统是一个整合企业管理理念、业务流程、基础数据、人、财、物、计算机硬件和软件于一体的企业资源管理系统。作为一个承载和实施企业管理理念的重要企业信息化管理平台，ERP系统开发完成后，企业的各种信息流可在此系统中进行全面的管理和控制。ERP系统的效率将决定企业的效率。
ERP系统作为一个特殊的软件产品，在实施过程中必须与管理紧密结合，同时它又是一个庞大的信息系统，企业内部的各种数据、信息相互关联，纷繁复杂。因此，当前ERP的开发与应用依然存在很多问题。而如何解决这些问题，一直是众多软件企业和软件工程师不断探索和努力追求的目标。
当前ERP开发中普遍存在的问题
应该说，当前ERP系统的实施成功率是比较低的。据美国某权威机构统计并发布的相关报告显示，当前ERP的总体成功率依然不足30％。国内ERP的成功率可想而知。
探究ERP系统开发与应用成功率不高的原因，我们看到，除去管理咨询阶段的问题，在进入实施阶段后，则普遍存在以下三个问题：
一是企业的业务不断变化，ERP系统相对固化。在进行ERP业务咨询阶段，通过理顺企业的各种业务流程，将先进的管理理念落地。企业管理理念落地不是通过几次咨询就能完全细化的，因为管理是一个不断优化的过程。即使在系统上线以后，一个ERP系统也只能说是搭建了一个管理的框架，需要在日常管理中不断地进行系统完善——管理需求的不断变化促使ERP系统不断优化。而实际上，由于ERP系统相对固化，很难快速响应包括流程、数据、操作甚至结构上等各种管理需求的变化。
二是实施人员的开发效率问题。实施人员在进行ERP系统开发时，需要将复杂的管理进行梳理，反映到实际的软件中去，还要响应使用方人员的客户化需求。在技术上，既要完全掌握ERP开发平台的开发技能，还要有软件开发和设计的能力；既要掌握同类系统的业务和功能，又要有根据当前客户的具体需求，结合管理理念进行客户化开发的能力。
ERP系统开发的高要求导致对实施技术人员的高要求，同时也导致了客户自己的ERP自己做不了主，技术人员开发的模块不是客户所期望的。当实施人员发生变更时，将产生巨大的项目风险。同时，培养一个ERP实施人员的成本巨大，开发效率成为ERP项目开发的瓶颈。
三是ERP系统的敏捷性问题。ERP系统是一个庞大的软件系统，由于其模块多，流程多，数据多，因此其敏捷性都比较差。如何使用先进的软件开发模式和软件实施方法论，提高其敏捷性，使其能够匹配管理变更的需求和客户个性化的需求，一直以来都是一个难题。
敏捷性的问题是一个非常核心的问题，这跟各个ERP开发厂商所使用的开发平台和ERP系统设计有关。解决了敏捷性的问题，以上两个问题也将迎刃而解。
综上我们看到，在ERP开发过程中，对技术开发人员有着很高的要求，他们既肩负着将管理理念落地的重担，又要理解和掌握大量的实际业务，还要精通平台开发和软件技术，以应对客户化的需求。因此，从某种角度上来说，ERP开发技术人员每个人都需要有系统分析员的分析能力、高级程序员的开发能力、业务专家的业务理解和优化能力。
业界的应对策略
针对复杂的企业ERP系统开发，几乎所有ERP开发厂商都采用了“ERP开发平台+套件”的方式来实施ERP系统。ERP开发平台是ERP开发的工具，也是ERP系统的基础支撑。因此，每个ERP开发厂商都非常重视自己的ERP开发平台，在产品扩展性、稳定性上投入了大量的人力和物力。
通过开发平台来简化ERP系统的构建几乎是所有ERP开发厂商的统一模式。与此同时，各家厂商又各自在自己的ERP开发平台上开发出一系列的行业模块和行业应用套件，努力形成自己的标准化的产品。在实际开发和实施时，通过对标准化套件的改造和定制化，来完成ERP的实施。
事实上，项目实施技术人员大部分的工作就是在标准化和客户化之间寻找平衡。根据客户的实际需求，更改标准版的模块，最后形成一个客户化的版本。而影响这种实施模式的因素包括ERP开发平台的开发效率，标准化的套件是否具备广泛的通用性，产品的扩展能力及扩展代价，技术人员的个人能力及对技术的掌握程度；客户方对定制的需求等。
纵观ERP系统开发的整个过程，ERP开发平台对项目实施起着非常重要的作用。但事实上，95%以上的ERP开发平台，即使是技术开发人员也需要具备大量的专业知识，需要经过一个艰苦的培训和学习过程才能掌握，更不要说由客户方信息中心的IT开发人员来进行扩展和开发了。
如果有一种简单的ERP开发平台，ERP开发的技术人员和客户方的开发人员通过简单的培训就能使用该平台进行ERP开发，并且该平台能够满足复杂ERP应用开发和定制的要求，具有强大的扩展性和稳定性，这将引起ERP开发的一场变革。
据悉，国内着名平台厂商创恒信软件有限公司近期推出的F1-ERP开发平台，就是这样一款先进的ERP开发平台产品。它采用了先进的配置化开发模式，通过“配置”的方式来开发ERP系统，大大提高了软件开发的效率，成为软件开发的“推进器”。
全配置化开发模式解困ERP开发
所谓“配置化”，即将大量成熟而实用的应用构件/组件或模块进行高度封装，开发人员通过可视化的配置方式来开发各种应用。开发人员在进行软件开发过程中，绝大多数开发与应用无需特殊的编码，只需按照项目需求选择相应的组件或模块进行“拖拽式”配置，而捏合过程由系统自动完成。就像统一规格、统一标准的机器零部件，只需按要求简单的拼装即能成为完整的机械设备一样，因而大大提高了软件开发效率，降低了软件开发与应用的难度，并且应用可即时部署，大大缩短了应用开发的调试期。
据了解，创恒信近期推出的F1-ERP开发平台，是一款拥有自主核心技术的软件开发推进器和全配置化敏捷开发与集成整合平台。同时，F1又是一个应用整合的支撑系统，其统一用户管理系统、PORTAL门户管理系统、内容管理系统、工作流管理系统、报表管理系统和ESB企业服务总线完全能够支撑企业的所有整合需求，并且可以作为一个应用开发平台来扩展将来的业务应用。其主要特点和优势表现为：
一是采用SOA松耦合框架。面向服务体系结构，使ERP系统在开发过程中把精力集中于业务流程，而不必过分关注有关集成或应用程序底层实现问题，使企业应用摆脱面向技术解决方案的束缚，灵活的适应企业业务流程变化和发展的需要。
二是通过BPM实现端到端的流程管理。BPM系统提供一种跨越业务系统的业务流程，能够协调地计划、执行、控制、监控和改进业务流程。
三是配置化敏捷开发。长期以来，配置化的软件开发一直被认为是软件开发的终极手段。传统方式的软件开发是软件系统在业务建模完成后，根据原型进行编码实现。主要包括业务层、逻辑层、表现层，都是通过代码来进行实现。这种开发模式在大型ERP系统中已经完全无法适用，大型ERP系统使用功能点来计算，一般都在几千甚至上万个功能点，即使采用平台化的应用开发平台来实现，其工作量也非常巨大，最终可能导致系统无法控制。另外一种模式是在已经实现的系统基础上进行二次开发，这些现成的系统大多经过了检验，并且能够满足现有用户60%左右的功能，但是其开发模式还是需要通过最终编码完成。
通过编码方式来实现的业务系统往往缺乏敏捷性，特别是ERP系统需要应对企业复杂的业务需求，甚至可能出现某个模块只有20%的功能满足现有用户的需求，80%的功能需要定制。而大量的定制工作将导致系统的可维护性、可扩展性、成本、敏捷性等方面出现各种各样的问题，最终结果是难以扩展、难以维护。
解决这一难题的唯一出路是通过配置化的平台来实现各种应用开发。配置化的平台能够实现90%的应用开发无编码，对于需要编码的业务系统，也可以将系统的编码量压缩成传统方式的5%至10%。
配置化平台将彻底实现软件开发不依赖于开发人员，使开发效率提升一个数量级；配置化对开发人员要求低，开发成本低、维护成本低，能够快速实现应用变更和应用扩展，完全实现软件开发以业务为中心，而非以开发人员为中心。
四是集成整合平台。在进行ERP系统建设时，应该首选一个开放的平台来进行系统的集成整合工作，因为开放的平台能够为各个系统的整合提供一个整体支撑环境，更好地解决应用的集成等问题。通过用户整合，实现用户的统一管理和单点登陆功能；通过采用PORTAL技术，来整合内网中的异构系统，实现应用整合；采用SOA技术，通过ESB实现各种应用之间数据的共享和集成来实现数据整合和系统间信息资源的最大整合；通过可视化过程配置管理来实现流程整合和对业务管理能力的全面提升。
通过创恒信的F1-ERP开发平台，我们可以看出，配置化的ERP开发平台，采取的是行业业务专家主导的ERP开发模式，主要解决技术人员与敏捷开发的问题，由于开发效率高，能够快速适应项目变化和满足用户“随需而变”的需求，并能够快速地实现各种复杂应用开发和应用集成，因此较好地解决了当前仍然困扰软件业界的ERP开发的主要难题。
另据了解，创恒信的F1-ERP开发平台正式发布之前，即已在国电石嘴山发电有限公司等多家大型电力企业中得到了成功应用，经受了大型复杂应用实践的检验。而选择成熟而实用的商用软件平台，来开发ERP应用系统和满足用户的个性化需求，无疑已成为当前ERP主流软件厂商、系统集成商以及大中型企业用户的共识。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：配置化开发平台解困ERP开发
本文网址：http://www.toberp.com/html/consultation/10825916395.html
相关文章
