主页
 > 研究与报告 > TEC博客 > 你应该修改应用产品?

你应该修改应用产品?

作者: Olin Thompson
发布于: 七月 15 2013

你应该修改应用产品

它会很好,如果关闭的,现成的应用程序的产品将满足每个企业的每一个业务需求。然而,SCM,ERP,CRM,BI或任何其他类别的应用产品,这是不是事情是这样的。许多企业发现,一些需求得不到满足,他们不能忍受一个普通版本的产品。如果这是你的情况,你应该修改的方案来满足这些需求?值得增益疼痛?

的修改是什么?修改任何代码写入到应用程序执行不同的供应商打算从什么。它可以处理内编写代码程序由供应商发货,或者它可能涉及这些程序外部的代码。有时,修改包括将新字段添加到数据库中。

做“化妆品修改”计数?在这些变化的屏幕,报告或工作流,不会影响该产品的数据库中的逻辑或。如果这些化妆品的改变意味着你必须做一些工作要重做或测试化妆品的变化,当到达一个新的版本,同样的问题 - 他们算作修改

要避免修改

让我们开始讨论一个基本的想法:要避免修改。修改意味着供应商的支持可能会更加困难,甚至没有价值。修改意味着接受从供应商的新版本,将更加困难,在时间和成本两个方面。修改意味着该系统更容易出错。修改的意思是你的长期拥有成本将会更高。修改应加以避免。

寻找在财务方面的修改是在寻找一个问题的法律责任。这是没有责任的类型,结束了该公司的资产负债表上。然而,它是一种责任,就像真实。修改决定今天将不得不在未来花费的时间和金钱。定义多大责任和思考它,如果它是在资产负债表有助于管理这些重要的决定。

许多实现具有绝对没有修改政策开始!这是伟大的,如果它可以坚持。然而,这些都是实现一小部分。绝对的政策结束了,只有少数例外。绝对政策的结果仍然是非常积极的,它最大限度地减少了最终的修改的数目和复杂性作出升。

为什么修改

那么,为什么

的企业会考虑修改应用程序的产品?答案是,有时它必须。但是,为什么它必须是黑色和白色。什么是绝对的“必须具备”为一体的企业不会甚至可以考虑在另一个。需要进行修改的决定,可能会导致各种类型的是什么,我们怎么能优先考虑他们?

有些业务流程或公约是行业惯例。这些过程或公约是在该行业企业的经营方式,而不是有能力,跟着他们就意味着不能够开展业务。这些业务流程或公约的关键任务。

的如果你发现自己面临着这种类型的问题,这是可能的,你没有选择正确的应用产品。如果供应商的“焦点”上的产业类型是一个网站或小册子之外的东西,他们应该提供的标准功能,处理与行业惯例。但是,如果你发现你选定的应用程序的产品不能满足您的行业特定需求 - 修改超过合理的,这是势在必行的。这种类型的修改之前必须完成的应用程序可以实现。

需要修改的另一个原因是当有一个独特的业务流程对您的业务,因此不提供的应用产品。在这种情况下,你需要考虑这种独特的工艺是对您的业务有多么重要。

如果

的过程中为您提供了一个战略优势,那么它可能是值得的痛苦修改保持优势。这不是一个低层次的决策:它涉及具有竞争力的策略。修改与长期成本具有竞争力的优势的值必须进行评估。这些过程的一些关键任务和许多作为市场的重要优势。通常情况下,这种类型的修改必须完成之前,应用程序可以实现。

如果一个进程的

的“只是我们做事的方式”,然后该值可以被质疑。大多数应用程序包的组合,与许多不同的企业从工作中获得的最佳实践。这是罕见的唯一的一家公司比那些在标准应用软件包提供真正有价值的过程。通常情况下,这些类型的情况下成为最困难的决定。一些强大的用户或用户组坚持认为,需要修改。一个成功的方法来处理这​​个问题,是不是说“不”,而是说“以后”。

的一项战略,是实现标准的产品,并推迟所有非关键修改后几个月一段线日期将导致许多这些“只是我们做事的方式”修改脱落列表中。用户将开始使用的标准包中可用的工具和经过几个月的使用,什么是重要的是他们将有改变。如果经过几个月的使用,这些需求仍然存在,也许他们的业务至关重要。

如何修改

的,一旦作出决定,修改应用程序包,它是如何进行的改装套件所有权的长期成本产生重大影响。有好的,坏的和丑陋的做法。

一个好方法:只要有可能,应修改外部供应商的代码或数据库。用户退出使用,API等或前或后处理方案的实施隔离修改的影响。利用数据库​​提供的字段由供应商(用户定义的字段)或标记以及文件也可以被视为外部修改。到达一个新的版本时,外部的修改仍必须进行测试,但相对较低的成本和风险。条款的修改,如果它们必须存在,这种​​做法是一个很好的

个不错的办法:如果外部的做法被证明是不可行的,那么一定做供应商的代码或数据库内。如果仅限于修改中加入一个代码块供应商的计划接受一个新的版本,努力成为一个代码添加到新版本和测试。添加一个代码块是不是很好,这是不好的,但有时这是不可避免的。

一个丑陋的方法:丑陋的修改世界实际上是改变供应商的代码或文件。class=articleText>的在一般情况下,应用程序的产品是非常复杂的。他们必须满足许多不同的业务需求,因此有复杂的逻辑判断程序是如何在一个特定的企业或实施运作。

什么一个程序,如何做,会影响其他程序的工作方式。这种复杂性会导致高风险的任何改变代码。当到达一个新的版本,重新申请变更,可能会需要什么样的供应商已经做的程序的完整分析。这可能意味着一种新的方式改变代码来获得相同的结果。这意味着非常广泛的测试,不只是有问题的程序,但也为整个系统。改变供应商的代码是丑陋的。

总结 - 有你的眼睛睁得大大的

的修改坏?答案是肯定的。修改是有道理的,有时答案是。决策过程应着眼于商业利益与长期负债作出修改。绝对没有修改政策是工作的出发点,但业务需求往往建立该规则的例外情况。使你的眼睛睁得大大的例外。开放的业务需求和开放的长期拥有成本。

作者简介

奥林·汤普森的主要过程ERP合作伙伴。他拥有超过25年的经验,在软件行业中为执行相关流程工业ERP,SCP过去17,和电子商务相关分部。奥林已经被称为“过程ERP的父亲。”他是一个频繁的作者和一个屡获殊荣的主题演讲获得价值从ERP,SCP,电子商务和行业技术的影响。

可以达到

他Olin@ProcessERP.com

 
comments powered by Disqus