(ZT):Compiere 实施方法

amoshuang

Compiere 被设计为支持快速上线。主要优势在于 Compiere 独特的技术特性 - “上线后的结构更改”（请参考“ 信息结构 ”），让您能在上线以后进行任何更改。这使得没有必要存在非常细致的分析和配置阶段，因为“ 如果您忘记了某些东西或设置错误了什么”那么重新实施不是一个好做法。在许多 ERP 项目实施过程中发现必须进行某个主要变更，又或者发现了某些遗漏，结果导致上线之前不得不重新实施，造成资金、人力、设备和时间的浪费。

因此，这里为快速和方便实施提供了一些指引。其中的大多数，实际上不仅应用于 Compiere 这一 ERP 的实施 - Compiere 不过使它更容易罢了。

技巧 1 ：尽量使用固定期限的实施合同，并坚持它。这可获得预定义交付（实施服务）的公开价格。

成功案例（Use Cases）

用例（Use Case）是一个业务过程，比如订单输入、收款、发货等。基本而言，它是您在业务开展中所做事情的清单。创建3种类别：

（1）紧迫 - 运营您的业务所必需的基本业务流程。

（2）便利 - 使业务流程更快、更容易、更有效。

（3）支持 - 帮助做出正确的决策、报表、分析...

有意思的是，在许多实施中，优先级似乎恰好被弄反了，这很令人吃惊。优先级（3）提供了更高的信息级别，所以常常是战略决策的催化剂，因而它们是重要的，但优先级（1）确保了您能够得以制定战略决策。软件供应商的售前活动通常完全聚焦于优先级（3）上，并且咨询公司也因此而繁荣 - 不过，请考虑优先级（3）中有多少是必须等到上线以后方能做出决策的。

这样说来，原型阶段应持续多长时间呢？这依赖于您的风险级别，至少优先级（1）的所有用例应当准确工作。在此基础上，您的感觉更好，主意自然妙，轻松确定下一步将完成的优先级（2）和（3）用例。

优先级（1）的用例工作正常时，您肯定无法进入负面的媒体报道标题了。

原型（Prototype）

每个产品都有它自己的方式去完成目标。如果您强制让 SAP 的行为像 Oracle Applications 那样，或者像您现存的实施那样 - 那么无疑就增大了失败的风险。Oracle、SAP、PeopleSoft 等商业应用系统实施的公开失败案例中，全都归入此类。通常，失败与产品无关，而是实施者及客户所持的不现实期待和呆板态度所导致。

因此，您如果要获得成功则需要一个操练场，以了解实现目标的最佳方式以及备选方式。如果您暂行规定此阶段，那么您的上线系统其实变成了您的原型。Compiere 不会介意这一点，并将精确地工作，然而您不过在系统中放入了一些测试数据而已。

技巧 2 ：所有的上线系统都包含一些“杂音”数据，因此不必尝试拥有一个100%干净的系统。如果在 Compiere 中无法删除这些“杂音”数据，那么可以隐藏它们（以满足一致性的要求）。

尽早引入全部用户

变更有时不会受到热烈的欢迎。许多项目集中于“超级用户”或“用户代表团”，限制了给正常运营带来的打扰。适度则没问题，但请尽早引用所有的用户。

原型阶段的结束通常是进行总体导入的好时机。此时人们可尽情使用或肆虐系统，而不会产生什么负面后果。您也可趁机获得非直接的确认，即覆盖了优先级（1）中的全部问题。

因此，请将您以及超级用户们的 Compiere 解决方案展示出来，甚至开一个 Party，让所有人都看看并试用您的杰作 - Compiere 系统原型。

迭代式开发

请习惯于循环：

设置较短时间内可完成的、较小的目标
让它工作
为下一次迭代总结经验
“ 大爆炸 ”方式 - 一切都同时开始工作 - 则使目标难以达到。

某些方面您可能第一次不能正确处理，所以小步骤产生的成功经过不断累积（即使遇到“事故”也可快速恢复），就可完成最终目标。

上线以后

既然业务运营已处于上线状态中，您就有了时间和知识可以开始调查，Compiere 在业务的策略方面能够怎样帮您。这使您得以更好地利用 Compiere，因为您已经对系统有了更多的理解。

技巧 3 ：为两个项目做出预算，一个是上线实施项目，另一个是上线6个月以后的项目，用以完全发挥 Compiere 的功能。

对于6个月后的项目，如果不考虑计划的详细程度，需要决定的是：早实施还是晚实施。用户不会再有变得惊慌的理由，“会议室驾驶仓”（或“Compiere 见面会”）可以为他们提供良好的培训基础。

Compiere 最大的优势这时就表现出来了：

已改变的优先级，新的业务和市场开发，或者新的视角要求改变 Compiere 的设置。不久之后，您的用户将变得适应，并将更进一步地控制系统。

Compiere 允许从绝大多数情形下轻松恢复，因为它被设计为“ 自恢复 ”。

一切听起来不错。当然，使用软件支持服务，可以将问题的后果最小化。

切换上线

需要决定一个问题：是否并行运行。众所周知，并行运行意味着双倍的工作。因此，在您的“Compiere 见面会”中，要与您的用户商量，看看他们是否对系统切换感到适应。

技巧 4 ：“用户认为无需并行运行”是一个重要指标，如不考虑（项目经理做出）是否并行的决定。

真实系统

不要等到“一切”问题都解决。那样可能永远也解决不完。因此，在您删除了原型（的确如此！）以后，开始使用新的实施和真实数据。

在这个阶段中（记住，您挑选出了所有的紧迫问题），主要的挑战是从已有系统将数据迁移至Compiere中，并做必要的定制工作。

一个重要部分是小型但正式的“会议室驾驶仓”（您可在此模拟驾驶仓尝试 Compiere 飞车，无需系安全带）。在备份以后，您给予用户了解和尝试系统的机会。不要只计划一次“会议室驾驶仓”，完全可计划三次或更多，这依赖于实施的复杂性。这些“Compiere 见面会”不应过长，用来帮助传播消息和减轻转换带来的心理压力 。

“会议室驾驶仓”也是对您的备份与恢复过程的检验。

获取经验的另一途径是升级和打安装补丁。Compiere 使得它们很容易，通过这些设置可以获得经验。

背景

上面推荐的实施方法正变得越来越流行。基于 快速原型法 的方法论已经出现了较长时间。 XP （极度编程）是快速、安全交付新技术的方法论（软件开发流程）。只需用实施任务替代编码的部分，它就非常适用于应用软件实施项目。要了解关于 XP 的更多信息，请检查 Google 。

Rational 的重量级流程 Rational Unified Process（RUP）近来已从强烈反对 XP 转为拥抱它。现在，Rational 为 RUP 提供一个 XP 插件。

pshen

内容写得不错，就是翻译的有些地方有点拗口。

原型迭代的方式，如果能做到，确实比较理想，但是实际情况中，却又有点困难重重。
1, 一旦用户觉得他的工作，只是小白鼠时， 用户层会有比较大的阻力
2，尤其是当这个原型，和真实模型有比较大的距离的时候，来自用户的阻力会更大
3，对于系统的上线优先级来说，的确报表是最低优先级的，但真实情况是，有足够的报表才能用来分析系统的运行结果。
更重要的是，很多实施中，报表是阶段验收的重要依据，这样就导致了很多时候，报表被过分的重视了。
4，上线后修改系统，导致的Bug，严重的话，会失去用户/客户方的信任

pshen

加精， 欢迎大家讨论。

另外，转帖最好注明出处。

pshen

当然，我前面提到的都是，假设有实施方/客户方，两方构成的实施团队。
如果是客户自己实施（因为compiere是开源软件，这种情况是完全可能的），那一些情况就会不一样。

继续说关于甲方/乙方的这种模式，关于模型迭代的这种方式，我们建议的是一个折衷的方法，在早期有实施方扮演用户，进行模拟，随后，逐批加入用户。
这样阻力会小一点。

并且在模型迭代过程中，应该控制用户一旦泛滥的想象力。

[ 本帖最后由 pshen 于 2007-2-13 11:35 编辑 ]

vito_fh

这些不都是compiere中国站点上的么

pshen

倒是不知道是compiere-china那里来的。
不过从行文看，听明显的感觉是从英文翻译过来的。

可能是compiere官方网站或者国外的什么新闻网站上来的。

wjfonhand

原文应该是soap的。

这套实施方法论我个人很赞同，也是sap和oracle的做法。

按计划分步实施，先通用流程后特殊流程，软件支持管理持续改进，很好。

pshen

倒入用户的顺序是什么？


另外，如果是SAP/Oracle, 比较成熟，
其实compiere上线后，持续修改，就有风险。

pophu

支持一下！！

bathers

看过了

g0267

http://bbs.ERP100.com/thread-17805-1-1.html

coolrainy

这些不都是compiere中国站点上的么

qishunyong

恩，眼熟

vpjames

共享出来，让更多的看到

vpjames

从英文翻译过来的

hero9840

实施过程中！客户的需求持续变化是很麻烦！但是要适当的引导客户！避免不必要的麻烦！

hero9840

强力支持一下！

hero9840

感觉说的太大了!希望细化一下!

cash

怎么把Zoapieret提供的那个附件（商贸版）导入到compiere。谢谢