本文档总结了 Odoo Online 的服务、我们的成功包实施方法以及开始使用我们产品的最佳做法。
1. The SPoC (Single Point of Contact) and the Consultant
在您的项目范围内，强烈建议指定和维护双方（您和我们）[唯一的联系人]谁将负责并承担项目责任。在决策方面，他还必须拥有[权力]。
- [Odoo 顾问确保项目从 A 到 Z*的实施：从项目开始到结束，他确保 Odoo 实施的总体一致性，并分享他在良好做法方面的专业知识。
- [客户方面唯一的决策者（SPoC）]：他负责业务知识的传递（必要时协调关键用户的干预）和从业务角度（决策、变革）实施的一致性管理等）
- [会议优化]：Odoo 顾问不参与从业务角度决策过程，也不参与精确的流程和公司的内部程序（除非有具体要求或例外情况）。每周举行一次或两次项目会议，旨在根据业务需求 （SPoC） 进行调整，并定义在 Odoo（顾问）中实现这些需求的方式。
- [培训培训师方法]：Odoo 顾问向 SPoC 提供职能培训，以便他可以将这些知识传授给他的协作者。为了使这种方法取得成功，SPoC 还必须通过”Odoo 文档 <http://www.odoo.com/documentation/user/10.0/index.html>`__、”电子学习平台 ” 参与自身技能提升。<https://odoo.thinkific.com/courses/odoo-functional>`和功能测试。
2. Project Scope
为了确保所有相关利益干系人始终保持一致，只要项目实施进行，就有必要定义并使项目范围不断发展。
- [对初始项目范围的明确定义]：对初始需求的明确定义对于确保项目顺利运行至关重要。事实上，当所有利益攸关方都有着相同的愿景时，需求的演变和由此产生的决策过程就更加简单和明确。
- [逐步实施项目]：赞成在几个连贯的阶段实施，允许定期生产发布，最终用户不断接管Odoo，这证明了其随着时间的推移的有效性。这种方法还有助于识别差距，并在实施初期采取纠正措施。
- [优先采用标准功能]：Odoo 提供了一个实施轻微改进（定制）或更重要的改进（开发）的绝佳环境。不过，为了优化项目交付时间，为用户提供其新工具的长期稳定性和可伸缩性，将尽可能频繁地采用标准解决方案。理想情况下，如果软件的改进仍然应该实现，其实现将在生产标准试验后进行。
3. Managing expectations
实施的现实与未来用户的期望之间的差距是一个关键因素。从项目开始，就必须考虑到三个重要方面：
- [与项目方法保持一致]：明确划分角色和责任，明确描述操作模式（验证、解决问题等）对于 Odoo 实施的成功至关重要。因此，强烈建议在项目开始时花一些时间与这些主题保持一致，并定期检查情况是否仍然如此。
- [专注于项目的成功，而不是理想的解决方案]：SPoC和顾问的主要目标是执行委托给他们的项目，以便提供最有效的解决方案，以满足表达的需求。这一目标有时与最终用户的理想解决方案愿景相冲突。在这种情况下，SPoC 和顾问将适用 80-20 规则：关注 80% 的表达需求，并找出成本/收益比率方面最不利目标的其余 20%（这些比例当然会随时间而变化）。因此，如果注意到全球救济，将更耗时的操纵纳入一个比较耗时的操纵将被认为是可以接受的。为了追求同样的目标，也可以提议改变业务流程。
- [规范总是 EXPLICIT]：预期内容与交付内容之间的差距通常是项目中冲突的根源。为了避免出现这种微妙情况，我们建议使用几种类型的工具* ：
- [GAP 分析]：将请求与 Odoo 提出的标准功能进行比较，将有可能确定由开发/定制或业务流程变化填补的空白。
- The User Story: This technique clearly separates the responsibilities between the SPoC, responsible for explaining the WHAT, the WHY and the WHO, and the Consultant who will provide a response to the HOW.
- 概念证明简化版本，<https://en.wikipedia.org/wiki/Proof_of_concept>`__ 是预期对预期变化的主要行达成一致的内容的原型。
- [模型]：在与概念证明相同的理念中，它将与与界面相关的更改保持一致。
在这些工具中，将完全透明地了解软件和/或其环境的可能性和局限性，以便所有项目利益相关者清楚地了解项目中可以预期/实现的内容。因此，我们将避免在事先核实其真实性的情况下，以假设为基础开展工作。
[当然，这个列表可以由其他工具完成，这些工具可以更充分地满足项目的现实和需求]
4. Communication Strategy
快速入门方法的目的是确保最终用户快速拥有该工具。因此，有效的沟通对于这种方法的成功至关重要。因此，它的优化将引导我们遵循以下原则：
[共享项目管理文档]：确保项目中的所有利益相关者都具有相同的知识水平的最佳方法是提供对项目跟踪文档的直接访问（项目管理器）。本文档将至少包含一个任务列表，作为明确定义优先级和管理器的实现的一部分。
项目管理器是一个共享的项目跟踪工具，允许详细跟踪正在进行的任务和项目的总体进度。
- [报告基本信息]：为了将文档时间缩短到要点，我们将遵循以下良好做法：
- 会议记录将限于决策和验证;
- 只有在达到重要流程时，才会建立项目状态;
- 将组织关于标准或定制解决方案的培训课程。
5. Customizations and Development
Odoo 是一种以灵活性和重要进化能力而闻名的软件。然而，大量的发展与快速和可持续的实施相矛盾。因此，建议：
- [开发只有一个很好的理由]：在成本效益比为正时（每天节省时间等），必须始终做出开发决策。例如，最好实现重大开发，以减少日常操作的时间，而不是每季度只执行一次操作。人们普遍认为，解决方案越接近标准，迁移过程越轻越流畅，双方的维护成本就越低。此外，经验告诉我们，在使用标准 Odoo 数周后，60% 的初始开发请求被丢弃（请参阅”将标准作为优先级采用”）。
- [替换，无需复制]：有一个很好的理由决定更改管理软件已经作出。在此背景下，实施时机是接受甚至改变软件使用方式和公司业务流程层面的变革时机。
6. Testing and Validation principles
无论在实施中是否取得了发展，测试和验证解决方案与公司运营需求的对应关系都至关重要。
- [角色分配]：在这种情况下，顾问将负责提供与规定规格相符的解决方案;SPoC 必须测试和验证交付的解决方案是否符合操作现实的要求。
[变更管理]：当需要对解决方案进行更改时，注意到的差距是由以下原因造成的：
规范与交付解决方案之间的区别 - 这是顾问负责的更正
[或]
- 规范与操作现实的必要性之间的区别 - 这是 SPoC 的责任。
7. Data Imports
导入事务数据历史记录是一个重要问题，必须适当地回答，以使项目顺利运行。事实上，这项任务可能非常耗时，如果其优先级没有很好地定义，则防止生产及时发生。为此尽快完成，将视其为：
- [不导入任何内容]：通常情况下，在反射后，导入数据历史记录被认为没有必要，这些数据被保存在 Odoo 之外并合并，以便以后报告。
- [在投入生产之前导入有限数量的数据]：当数据历史记录与正在处理的信息相关时（例如，采购订单、发票、未结项目），需要从使用的第一天起提供此信息。生产是真实的。在这种情况下，将在生产启动之前进行导入。
- [在生产启动后导入]：当数据历史记录需要与 Odoo 集成，主要用于报告目的时，很明显，这些数据可以追溯性地集成到软件中。在这种情况下，解决方案的生产启动将先于所需的导入。