金蝶erp与易飞erp区别_文化问题：敏捷和ERP第三部分

金蝶erp与易飞erp区别

我在关于敏捷和ERP的第二篇文章中提出了在ERP环境中进行软件开发时遇到的一些文化问题，这次我想更仔细地研究两种文化之间的差异。

许多文化问题都围绕着这样一个事实，即ERP倾向于在企业IT环境中发生，并且由于企业IT对于开发软件而言是更具挑战性的地方，因此ERP系统将遇到“通常的”企业IT问题。

但是，ERP系统似乎更容易出现文化问题。

我已经说过ERP系统是整体的，而且我还暗示了它们本质上是分层的。 在某种程度上，这是一个历史遗留，它们来自像这样编写系统的Cobol大型机世界。

如果您了解康韦定律，那么我要说的很明显：组织开发，抱歉，配置ERP系统本身就是层次结构和整体的。 很难将人力资源开发与物流开发分开。

这实际上是反向康威定律（有时称为Yawnoc）的一个很好的例子： 组织是系统体系结构的副本 。

当组织购买ERP系统时，他们购买的是大型的，整体的，分层的系统，高级管理人员所需的投资（财务和个人投资）意味着同构力量很强。 因此，参与该系统的组织将成为该系统的副本-反向的Conway。

（从好的方面来说，由于这些系统旨在使用基于昨天的范例的技术来满足昨天的需求，因此应该有机会破坏这种模型-但这是另一天的话题。）

让我们来谈谈一些细节...

从字面上看，第一个问题使您开箱即用。

ERP系统是作为不需要编程的应用程序出售和销售的，它仅需要配置 。 注意不要用这个词： 配置 ，甚至不要定制 ，当然也不要编程 。 这是非常复杂的营销。

ERP系统花费数百万美元来购买和操作它们。 购买这种系统的技术人员很少。 销售人员故意谈论这种系统的配置（无需编程），以便对买方说：“您不需要任何讨厌的（昂贵的）程序员。”

相反，他们提出了安装SAP的想法，转到工具菜单，选择选项，选择右侧选项卡，单击框，然后…等等！ —系统已配置。 好的，它是一个大型系统，因此需要“大量”配置，但是您明白了。

不是这样

ERP系统所需的那种配置比任何ERP销售商都认可的更类似于编程。 它可能不是Java开发人员可以识别的那种编程，但是它是在另一种范式中进行编程。

有时它是基于表的编程-一种谓词Prolog规则系统。

有时它有很多参数-考虑.ini或XML文件，但可能采用一些街机语法。

有时，实际上是很多指向和单击。

有时这是实际的编码，通常使用系统唯一的语言，SAP使用类似于Cobol的语言称为ABAP，而Microsoft Dynamics使用Frankenstein版本的C ++称为X ++。

还要注意，由于我所知道的几乎每个ERP系统实际上都是由不同公司在不同时间制造的多种不同产品的组装，并被当前供应商粉碎在一起，因此您很可能会在内部找到所有这些方法和多种语言。

面对ERP系统时，要克服的第一个大问题就是说服人们进行编程。 或者更确切地说，这里需要采用适用于大型编程工作的那种规则和思维。

因为总是有测试人员，所以可以证明需要编程。 如果配置确实很简单，则无需测试。 由于始终对ERP系统进行测试，因此所谓的“配置”显然不仅仅是工具和选项，因此请单击 。 显然，两个不同的“配置”可能以意想不到的方式相互作用。

由于ERP系统强调业务功能并拒绝编程，因此它们声称可以由从业人员（例如会计师，人力资源专业人员，物流专家）进行配置。 等等。确实，您可能需要具备配置它的领域技能，但是您还需要技术技能。

因此，进行“配置”的人员不会将自己视为程序员。 他们很少有编程背景，诸如凝聚力，耦合，关注点分离，接口等概念对他们来说是陌生的，并且如果将依赖倒置，倒置它们也不会知道依赖性反转，或者其他任何模式。

这些人并不是愚蠢的，实际上他们是各自领域的专家。 而是因为他们不相信自己是程序员，所以他们对软件工程概念几乎没有兴趣。 而且由于他们的教育是在专家领域（物流，会计，人力资源等）中进行的，所以他们从未在学校学习过这些概念。

不幸的是，当您对一个大型系统进行编程时，拥有软件工程知识确实会有所帮助–这就是为什么该学科应运而生的原因。

更糟糕的是，由于供应商鼓励“不需要编程”的概念，因此ERP系统内部的编程系统也缺乏现代的软件工程概念。 请记住：ABAP是Cobol，Cobol不是现代语言。

像Cobol一样，ABAP和X ++之类的ERP语言具有“商业导向”，并且缺乏工程学所需的习惯用法。 在一个ERP实施方案上，我开始感觉到整个过程只是基于类固醇的Visual Basic –以及VB6！ 这样的语言已经完成，因此您可以（理论上）做所有事情，但有些事情很难做。

ERP文化也带来其他问题。

没有用于ERP的开源。 从来没有人晚上回家写过ABAP来获得GNU许可。 结果，现代软件工程师所期望的那种工具不存在。

虽然存在ABAP-Unit和X ++ Unit，但它们不如JUnit广泛或可用。

您也不会发现充满ABAP或X ++问题和答案的Stackoverflow 。 当然，对于Python来说，只有很少但只有一部分。 公平地讲，ABAP或X ++程序员的数量仅是Python，C＃或Java程序员的一小部分，因此尽管存在一些公共资源，但数量很少。

许多ERP“开发人员”为系统集成商服务（CapGemini，埃森哲和无数小型商店）。 他们为员工收取高额费用，并采用非常灵活的人员编制方法。 例如，与我一起工作的一个团队的SAP HR“顾问”有两个星期的假期。 咨询公司派了另一位顾问来填补她离开的两个星期。 我很难相信替身顾问可以在那个时候为客户做任何有用的事情，但是到那里他们可以为系统集成商付费。

这样做的副作用是顾问的需求量很大，他们可能会同时处理多个客户项目，而且他们可以在国际范围内流动，并且经常获得飞行常客积分。

这有一些非常实际的局限性，这些人可能不会将100％的顶空投入到客户身上，因此要尽早或定期召开站立会议很难，这可能取决于希思罗机场的交通拥堵。

而且由于他们为他人工作，因此客户和咨询公司可能无法就谁为任何敏捷培训或讲习班付费而达成共识。 我发现自己为客户人员举办了敏捷研讨会，但由于他们为供应商而工作，因此ERP顾问被排除在外。 即使客户直接雇用员工，或者客户和供应商同意，ERP顾问也可能会拒绝学习敏捷，尤其是技术方面的考虑，因为他们不认为自己是技术方面的！

当ERP顾问参与进来就像退后10或15年时，所有“旧的”论点都会出现：“我们如何在2周内做某事？”，“我们必须设计整体”，“业务必须解决”其要求”等。

在下一部分中，我们将讨论坏消息，技术...

翻译自: https://www.javacodegeeks.com/2016/09/culture-problems-agile-erp-part-3.html

金蝶erp与易飞erp区别