Ce document reprend les services d’Odoo Online, notre méthodologie d’implémentation de Success Pack et les pratiques les plus conseillées afin de commencer à utiliser notre produit.
1. The SPoC (Single Point of Contact) and the Consultant
Dans le cadre de votre projet, il est hautement recommandé de désigner et de maintenir des deux côtés (du vôtre et du nôtre) une seule et unique personne de contact (en anglais : Single Point of Contact ou SPoC), qui se chargera de votre projet et qui en sera responsable. Il/Elle aura également l’autorité en termes de prise de décision.
- Les consultants assurent l’implémentation du projet de A à Z : Du début à la fin du projet, il/elle assurera la cohérence globale de l’implémentation sur Odoo et partagera son expertise en termes de bonnes pratiques.
- Un seul et unique décisionnaire du côté du client (SPoC) : Il/Elle est responsable de transmettre ses connaissances de l’activité (coordinera des interventions des utilisateurs clés si nécessaire) et de la consistence de l’implémentation d’un point de vue business (prise de décision, ch
- Optimisation des réunions. Le Consultant Odoo n’est pas impliqué dans le processus de prise de décision d’un point de vue business et ne précise pas non plus les processus ou procédures internes à l’entreprise (sauf dans le cas d’une demande spécifique ou d’une exception). Les réunions de projet, qui prendront place une à deux fois par semaine, ont pour objectif de s’aligner sur les besoins de l’entreprise (SPoC) et de définir la manière dont ces besoins seront implémentés sur Odoo (Consultant).
- Train the Trainer approach: The Odoo consultant provides functional training to the SPoC so that he can pass on this knowledge to his collaborators. In order for this approach to be successful, it is necessary that the SPoC is also involved in its own rise in skills through self-learning via the Odoo documentation, The elearning platform and the testing of functionalities.
2. Project Scope
Afin de s’assurer que tous les intervenants impliqués suivent la même direction, il est nécessaire de définir et de faire évoluer la portée du projet tant que l’implémentation du projet se poursuit.
- A clear definition of the initial project scope: A clear definition of the initial needs is crucial to ensure the project is running smoothly. Indeed, when all the stakeholders share the same vision, the evolution of the needs and the resulting decision-making process are more simple and more clear.
- Phasing the project: Favoring an implementation in several coherent phases allowing regular production releases and an evolving takeover of Odoo by the end users have demonstrated its effectiveness over time. This approach also helps to identify gaps and apply corrective actions early in the implementation.
- Adopting standard features as a priority: Odoo offers a great environment to implement slight improvements (customizations) or more important ones (developments). Nevertheless, adoption of the standard solution will be preferred as often as possible in order to optimize project delivery times and provide the user with a long-term stability and fluid scalability of his new tool. Ideally, if an improvement of the software should still be realized, its implementation will be carried out after an experiment of the standard in production.
3. Managing expectations
L’écart entre la réalité d’une implémentation et les attentes des futurs utilisateurs est un facteur crucial. Trois aspects importants devraient être pris en compte dès le début du projet :
- Align with the project approach: Both a clear division of roles and responsibilities and a clear description of the operating modes (validation, problem-solving, etc.) are crucial to the success of an Odoo implementation. It is therefore strongly advised to take the necessary time at the beginning of the project to align with these topics and regularly check that this is still the case.
- Concentrez-vous sur la réussite du projet, et non pas sur la solution idéale : L’objectif principal du SPoC et du consultant est de mener à bien le projet qui leur est confié afin de trouver la solution la plus efficace pour répondre aux besoins exprimés. Cet objectif peut parfois aller à l’encontre de la vision que se fait l’utilisateur final d’une solution idéale. Dans ce cas, le SPoC et le consultant appliqueront la règle des 80-20 : se concentrer sur 80% des besoins exprimés et retirer les 20% restants des objectifs les plus défavorables en termes de rapport coût/bénéfice (ces proportions peuvent bien sûr changer au fil du temps). Par conséquent, si un allègement global est constaté, il sera jugé acceptable d’intégrer une manipulation plus chronophage.
- Specifications are always EXPLICIT: Gaps between what is expected and what is delivered are often a source of conflict in a project. In order to avoid being in this delicate situation, we recommend using several types of tools* :
- L’analyse des gaps : La comparaison entre la requête et les fonctionnalités standard proposées par Odoo permettra d’identifier le manque à combler par des développements/personnalisations ou des changements des processus opérationnels.
- L’Histoire de l’Utilisateur: Cette technique sépare clairement les responsabilités entre le SPoC, responsable d’expliquer le QUOI, le POURQUOI et le QUI, et le consultant qui fournira une réponse au COMMENT.
- La démonstration de faisabilité Une version simplifiée, un prototype de ce qui est attendu pour arriver à un accord sur les grandes lignes des changements attendus.
- La maquête : Dans la même idée que la démonstration de faisabilité, elle viendra s’aligner aux changements liés à l’interface.
To these tools will be added complete transparency on the possibilities and limitations of the software and/or its environment so that all project stakeholders have a clear idea of what can be expected/achieved in the project. We will, therefore, avoid basing our work on hypotheses without verifying its veracity beforehand.
Cette liste peut, évidemment, être complétée avec d’autres outils qui correspondraient plus adéquatement à la réalité des besoins de votre projet.
4. Communication Strategy
The purpose of the QuickStart methodology is to ensure quick ownership of the tool for end users. Effective communication is therefore crucial to the success of this approach. Its optimization will, therefore, lead us to follow those principles:
Sharing the project management documentation: The best way to ensure that all stakeholders in a project have the same level of knowledge is to provide direct access to the project’s tracking document (Project Organizer). This document will contain at least a list of tasks to be performed as part of the implementation for which the priority level and the manager are clearly defined.
The Project Organizer is a shared project tracking tool that allows both detailed tracking of ongoing tasks and the overall progress of the project.
- Report essential information: In order to minimize the documentation time to the essentials, we will follow the following good practices:
- Le compte-rendu des réunions sera limité aux décisions et aux validations;
- Les statut des projets ne seront définis que lorsqu’une étape importante sera franchie.
- Des sessions de formation sur la solution classique ou personnalisée seront organisées.
5. Customizations and Development
Odoo is a software known for its flexibility and its important evolution capacity. However, a significant amount of development contradicts a fast and sustainable implementation. This is the reason why it is recommended to:
- Develop only for a good reason: The decision to develop must always be taken when the cost-benefit ratio is positive (saving time on a daily basis, etc.). For example, it will be preferable to realize a significant development in order to reduce the time of a daily operation, rather than an operation to be performed only once a quarter. It is generally accepted that the closer the solution is to the standard, the lighter and more fluid the migration process, and the lower the maintenance costs for both parties. In addition, experience has shown us that 60% of initial development requests are dropped after a few weeks of using standard Odoo (see « Adopting the standard as a priority »).
- Remplacer, sans dupliquer : La décision de changer le logiciel de gestion a été prise pour une bonne raison. Dans ce contexte, le moment de la mise en œuvre est LE bon moment pour accepter et même être un initiateur de changement tant au niveau de la manière dont le logiciel sera utilisé qu’au niveau des processus d’affaires de l’entreprise.
6. Testing and Validation principles
Whether developments are made or not in the implementation, it is crucial to test and validate the correspondence of the solution with the operational needs of the company.
- Répartition des rôles : Dans ce contexte, le consultant sera chargé d’apporter une solution qui correspond aux spécifications définies et le SpoC devra tester et valider la solution livrée pour vérifier si elle répond aux exigences de la réalité opérationnelle.
Gestion des changements : Lorsqu’un changement doit être apporté à la solution, l’écart est causé par :
La différence entre le cahier des charges et la solution livrée. Cette modification est sous la responsabilité du consultant.
ou
- La différence entre les spécifications et les impératifs de la réalité opérationnelle. Cette modification est sous la responsabilité du SPoC.
7. Data Imports
Importing the history of transactional data is an important issue and must be answered appropriately to allow the project running smoothly. Indeed, this task can be time-consuming and, if its priority is not well defined, prevent production from happening in time. To do this as soon as possible, it will be decided :
- Not to import anything: It often happens that after reflection, importing data history is not considered necessary, these data being, moreover, kept outside Odoo and consolidated for later reporting.
- To import a limited amount of data before going into production: When the data history relates to information being processed (purchase orders, invoices, open projects, for example), the need to have this information available from the first day of use in production is real. In this case, the import will be made before the production launch.
- To import after production launch: When the data history needs to be integrated with Odoo mainly for reporting purposes, it is clear that these can be integrated into the software retrospectively. In this case, the production launch of the solution will precede the required imports.
8. Support
Lorsque votre projet est mis en production, nos équipes de support prennent vos questions ou problèmes techniques en charge.