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