企业软件开发erp，erp系统企业开发

企业软件开发erp，erp系统企业开发　　②ERP 流程或许先进 但现有流程不可能因为实施 ERP 而大概 太大的调整将导致上下衔接不顺。就这样 实施小组和业务部门讨论 协商 争论了个把月 结果是一大堆的二次开发需求摆在面前。然而 过度二次开发后的结果是:项目延期 开发的程序不稳定 容易出错。用了一段时间后 发现还不能满足业务流程的需要 于是再做修改。实际上 这样二次开发就会存在两大问题:第一是由于二次开发过多 系统变得越来越复杂 与最初期望的效果越来越远 最后猛然一看 系统已经完全"变味"了。第二 由于客户二次开发能力有限或者 系统柔性度较差 造成客户在这方面的投入很大但产生的效益甚微 后者也正是客户在二次开发中陷入窘境的主要原因。　　①目前使用 流程是经过实践检验的 只是需要更进一步完善;　　(2)不合理的管理制度造成的特殊流程需求 主要表现在客户想把现有的手工流程 手工作业一成不变的搬到ERP中去 其

　　作为一个开发项目来说 合适的开发工作量是很重要的。如果开发工作量过大 再加上没有相应的奖惩措施 那么就会无法调动开发团队的积极性 也就无法进行持续的二次开发 项目陷入困境也就是必然的事 情了。

　　看过电影《特洛伊》后，其中让我感受至深的是:古希腊神话中所向披靡的勇士阿喀琉斯最怕脚后 跟受伤 因为这是他的致命"命门"。其实 ERP 实施也有最怕触及到的致命"命门" 就是过度二次开发。作为ERP的二次开发 我知道的有这样的一个例子：一个客户上线ERP项目 这是客户有史以来最大的IT项目。经过大半年的实施 此ERP项目却陷于困境。原因是客户对 ERP实施二次开发的误解和随意性 使项目陷于前无进路 后无退路的局面。据有关数据统计表明 ERP实施最大的一个致命伤是过度二次开发。因为随意性的二次开发最后都会演变成一个对系统无休止的修改过程 最终会把客户和实施厂商都拖进泥潭难以自拔 而开发人员和实施顾问则会心力交瘁 痛苦不堪。客户固执己见是过度二次开发的导火线在做 ERP 实施顾问的第一天 上司告诉两条基本准则: 第一条准则是要坚持以客户真实需求为驱动力;第二条准则是作为实施顾问 一定要坚决不赞同客户进行太多的二次开发 发。因为过多的二次开发不仅会增加软件的不稳定性 还会延长项目实施周期 从而增加项目成本 故必须要用尽各种各样的办法把客户需求向 ERP 软件在已有的流程上走。这两个准则看起来相互矛盾 但在经过这个项目后 我才深刻地理解到它的本质含义。在这个项目中 客户固执地认为只有进行二次开发才能真正发挥它们个性化的流程潜力。但这却是一个很大的误区 客户的固执或偏见主要是表现在以下方面:

(1)不愿意改变现有的操作习惯一般来说 ERP软件产品为了具有较强的通用性 软件功能是比较标准 流程设置相对规范化。因为对于任何ERP软件来说 通用性是首要考虑的问题之一。但这个客户除了在业务流程等方面具有个性化需求外 还存在着一些不涉及业务流程的 由企业的特殊性而产生的操作习惯需求。客户是一个老国企 在界面习惯和操作习惯上提出了非常多的特殊要求 客户领导固执地认为一定要按他们的习惯进行二次开发 以满足他们原有的操作模式。例如 一般ERP 软件都会提供通用的单据格式 但这个客户却有自己习惯的一套单据格式。在 ERP实施时 客户第一个问题就是问能否按这个格式打印。其实 这是本末倒置的 只要该有的内容有了 没有必要一成不变地按原有的格式。也许 ERP 系统提供的格式更加合理 就算是二次开发 也许等格式修改好了 客户也许早就适应了这个新的格式。但这样的操作习惯问题在实施时是经常出现的 在与客户沟通这些无关痛痒的问题上常常让我费尽心力 舌根冒火才勉强说服客户同意先试用单据格式。结果不但造成项目延期

　　而且还把大家的注意力转移到无关的次要流程上 吃力不讨好现象时常发生。实际上 只有当碰到无法通过调节参数来完成 或者报表功能和格式真的是不适应时 才应该通过二次开发来实现。

　　(2)不合理的管理制度造成的特殊流程需求 主要表现在客户想把现有的手工流程 手工作业一成不变的搬到ERP中去 其实这是非常不正确的 这是换汤不换药的做法。当我与客户领导进行沟通时 分析 ERP现有的流程与客户原有的流程的优劣性比较时 客户用一句话把我顶回来了 就是他们一直都是这样做的 而且还做得不错。他们就是用这样的管理手段才得以发展到目前的规模 而且以后还打算一 用他们习惯的方式去管理 因此必须要进行二次开发以配合它们就算是看起来不合理的特 殊流程。

　　(3)ERP 软件确实无法满足的需求当然 有时客户确实存在着一些个性的业务流程需求 ERP系统是无法满足 毕竟 ERP是一个套装软件 而不是根据客户量身定制的。针对这种需求 即使通过各种各样的实施方法后 也没有找到更好的处理方式 就应该进行二次开发了。针对客户频繁的二次开发需求 我们把利弊向客户陈述清楚 并说明无数的事实证明过度的二次开发的案例最终是会失败的。而且许多开发需求已经超出ERP软件厂商应该负责的部份 需要额外签订二次开发合同和增加费用。最后 财大气粗的客户领导决定扩充原有的IT部门开发组 由客户自行进行二次开发。无节制过度二次开发的弊端 ERP 软件在实施的过程中总会遇到这样那样的问题 其中最让实施顾问头痛的是客户领导一时意气用事 好高骛远而造成的无节制的二次开发。这不但成本过高 而且越改越让ERP项目难以实施 陷入进退两难的困境。

　　(1)无节制二次开发 ERP系统容易走样客户老总在 ERP 实施前就为实施定了调:现有的业务流程不能大改 只能逐步优化。因此 作为实施顾问的我在与客户业务部门讨论解决方案前采取了如下应对策略: 培训客户尽快熟悉 ERP系统功能 劝说客户采用系统已有的相似功能 减少一些无谓的开发 系统没有的功能才考虑是否要开发。因为软件已经在数百家企业使用 管理思想是非常先进和合理的 的 而且大量二次开发不但会有开发的风险 延长了实施周期 还会对系统升级带来诸多不便。但客户坚持开发的理由是:

　　①目前使用 流程是经过实践检验的 只是需要更进一步完善;

　　②ERP 流程或许先进 但现有流程不可能因为实施 ERP 而大概 太大的调整将导致上下衔接不顺。就这样 实施小组和业务部门讨论 协商 争论了个把月 结果是一大堆的二次开发需求摆在面前。然而 过度二次开发后的结果是:项目延期 开发的程序不稳定 容易出错。用了一段时间后 发现还不能满足业务流程的需要 于是再做修改。实际上 这样二次开发就会存在两大问题:第一是由于二次开发过多 系统变得越来越复杂 与最初期望的效果越来越远 最后猛然一看 系统已经完全"变味"了。第二 由于客户二次开发能力有限或者 系统柔性度较差 造成客户在这方面的投入很大但产生的效益甚微 后者也正是客户在二次开发中陷入窘境的主要原因。

　　(2)开发工作量过大 项目容易陷入困境 在初步估算开发量后 客户深知开发任务的艰巨 于是要求软件厂商调派高级技术顾问作技术指导和支持。然而 由于客户自行组建的开发团队以前都未接触过 ERP 软件的开发 同时还要维护公司的其他系统 开发人员一直处于三心二意之中。因此 起步格外吃力。而且事情越发展下去越糟糕 由于客户开发人员在项目中多次被投诉进度慢 客户公司在例行 的加薪中就没有给开发人员加薪 这些令他们怒不可遏 本来开发就挺累的 而且累了公司还没有重视他们的价值。在后来的开发中 他们就没有象开始那么积极和负责了 整个项目开始陷入不正常之中。项目就在开发人员的三心二意中继续 本来确定的上线日期也因为项目需求的反复调整而一拖再拖。眼看再不上线 整个项目将要严重滞后 客户不得不强行上线。结果是项目上线后 业务部门在使用中逐渐暴露出了许多问题 不是今天这个报表运行出错 就是明天那个功能计算有误 整个项目实施团队被迫陷入救火当中 尽管开发人员对前期的开发程序进 进行了修修补补 但问题还是层出不穷 不时接到业务部门的抱怨和不满 整个企业迷漫了对 ERP 失败的看法 原来美好的愿望在现实中被击得粉碎。避免过度二次开发的策略和方法当客户提出需要大量二次开发时 如果实施顾问控制不善就非常容易会出现项目延期 开发的程序不稳定 或者需求反复更改。因此 实施顾问必须要尽量引导客户思路 避免客户陷入过度二次开发的怪圈。

　　这里和大家分享我总结的几点经验:

　　(1)应引导客户对二次开发的正确认识在观念认识上 实施顾问应要让客户清醒认识到 不应过多的强调自身的特点 ERP软件中的管理流程是从许多企业中提炼出来的 具有一定的先进性和合理性。许多用户的特殊之处都是由于流程自身的不合理产生的 应该通过 ERP 的实施 对企业进行业务流程优化或 重组 而不是一味修改软件以适应不合理的流程。

　　(2)严格遵守不随意修改核心代码 新功能应独立成模块 当需要二次开发时 应该要严格遵守不修改核心代码这一条基本原则。如果必须进行二 次开发 则应尽量使得二次开发做出的功能模块独立于原来的 ERP 系统。这样当 ERP 系统版本更新时 二次开发出来的模块无需修改或者只需较少的修改就可以应用于高版本的 ERP 系统。

　　(3)严格审核需求 不随意二次开发

　　二次开发的需求必须控制好 尽量不要在 ERP 系统的功能还没有充分了解是否满足客户需求之前就进行二次开发。因为用户的业务流程并不是一成不变的 ERP 软件中流程一般比 较抽象 大的方面与用户业务流程通常可以套上 细节部分就不应作过多的修改。例如 要明确这些原则:可做可不做的 坚决不做;某些无关痛痒的流程和界面的调整 也应该缓改或者不改。因为由于使用的不便等原因而对系统改这改那 很容易犯了拆东墙补西墙的错误 导致软件开发了客户却不能用或不愿用的尴尬局面。

　　(4)合适的开发工作量是重中之重作为一个开发项目来说 合适的开发工作量是很重要的。如果开发工作量过大 再加上没有相应的奖惩措施 那么就会无法调动开发团队的积极性 也就无法进行持续的二次开发 项目陷入困境也就是必然的事情了。