Цей документ підсумовує послуги Odoo Online, методологію впровадження наших пакетів послуг та найкращі практичні поради для початку роботи з нашим продуктом.
1. Єдина контактна особа та консультант
В контексті вашого проекту настійно рекомендуємо призначати та підтримувати з обох сторін (з вашої сторони та нашої) єдину контактну особу, яка візьме на себе відповідальність за проект. Він також повинен мати повноваження щодо прийняття рішень.
Консультант Odoo забезпечує реалізацію проекту від А до Я: від початку до кінця проекту він забезпечує загальну послідовність впровадження Odoo та ділиться своїм досвідом з точки зору належної практики.
Єдина контактна особа, яка приймає рішення зі сторони клієнта: він відповідає за передачу ділових знань (в разі потреби координує втручання ключових користувачів) та узгоджує виконання з точки зору бізнесу (прийняття рішень, управління змінами тощо).
Оптимізація зустрічей: консультант Odoo не бере участі у процесі прийняття рішень з точки зору бізнесу, а також не має чітких процесів та внутрішніх процедур компанії (крім конкретного запиту чи винятку). Зустрічі щодо проекту, які відбудуться раз або два на тижні, призначені для узгодження бізнес-потреб (єдина контактна особа) та визначення способу реалізації цих потреб в Odoo (консультант).
Підготовка до навчання: консультант Odoo надає функціональну підготовку для єдиної контактної особи, щоб вона могла передавати ці знання своїм співробітникам. Для того, щоби цей підхід був успішним, необхідно, щоби контактна особа також брала участь у власному підвищенні навичок шляхом самостійного навчання за допомогою документації Odoo, платформи електронного навчання та тестування функціональних можливостей.
2. Сфера застосування проекту
Аби переконатися, що всі зацікавлені сторони завжди узгоджують процеси між собою, необхідно визначати та вносити зміст проекту поки реалізується проект.
Чітке визначення початкового обсягу проекту: Чітке визначення початкових потреб має вирішальне значення для забезпечення безперебійного виконання проекту. Дійсно, коли всі зацікавлені сторони поділяють одне і те ж бачення, еволюцію потреб та процес прийняття рішень є більш простими та зрозумілішими.
Поступова реалізація проекту: Сприяння впровадженню на декількох узгоджених етапах, що дозволяють регулярно впроваджувати продукцію, та поступово охоплювати Odoo кінцевими споживачами, довели свою ефективність із часом. Цей підхід також допомагає виявити прогалини та застосовувати коригувальні дії на початку впровадження.
Прийняття стандартних функцій в якості пріоритету: Odoo пропонує чудове середовище для здійснення незначних удосконалень (налаштувань) або більш важливих (доробок). Тим не менше, прийняття стандартного рішення буде віддавати перевагу якомога частіше, щоб оптимізувати час доставки проекту та надавати користувачеві довгострокову стабільність та масштабність його нового інструмента. В ідеалі, якщо поліпшення програмного забезпечення все-таки має бути реалізоване, його впровадження буде здійснено після експерименту зі стандартним впровадженням.
3. Управління очікуваннями
Розрив між реальним впровадження та майбутніми очікуваннями користувачів є вирішальним чинником. З початку проекту необхідно враховувати три важливі аспекти:
Співпрацювати з підходом до проекту: Як чіткий розподіл ролей та відповідальності, так і чіткий опис режимів роботи (перевірка, вирішення проблем та ін.) мають вирішальне значення для успішного впровадження Odoo. Тому настійно рекомендуємо вживати необхідний час на початку проекту, щоби вирівнятися з цими темами, і регулярно перевіряти, чи усе ще так, як було заплановано.
Зосередьтеся на успіху проекту, а не на ідеальному рішенні: Головною метою єдиної контактної особи та консультанта є виконання завданого ними проекту, щоби забезпечити найефективніше рішення для задоволення виражених потреб. Ця мета іноді може суперечити баченню ідеального рішення клієнта. У такому випадку контактна особа та консультант застосовуватимуть правило 80-20: зосередитись на 80% виражених потреб та вилучити решту 20% найбільш невигідних цілей з точки зору співвідношення витрат і вигоди (ці відсотки, звичайно, можуть бути зміненими з часом). Тому, якщо глобальне рішення буде визначено, буде прийнято інтегрувати найбільш трудомістку маніпуляцію. Зміни в бізнес-процесах також можуть бути запропоновані для досягнення цієї ж мети.
Технічні характеристики завжди є ВИКЛЮЧНИМИ: прогалини між тим, що очікується і що доставляється, часто є джерелом конфлікту в проекті. Щоб уникнути перебування в цій делікатній ситуації, ми рекомендуємо використовувати кілька типів інструментів*:
GAP аналіз: порівняння запиту клієнта зі стандартними функціями, запропонованими компанією Odoo, дозволить визначити розрив, який повинен бути заповнений розробками/налаштуваннями або змінами бізнес-процесів.
Історія користувача: Ця методика чітко розмежовує обов'язки між контактною особою, відповідальним за роз'яснення ЩО, ЧОМУ та ХТО, та консультанта, який надасть відповідь на ЯК.
Proof of Concept (PoC) Cпрощена версія, прототип того, що очікується, узгоджується з основними лініями очікуваних змін.
Макет: у тій же ідеї, що й PoC, який буде відповідати змінам, пов'язаним з інтерфейсом.
До цих інструментів буде додано повну прозорість щодо можливостей та обмежень програмного забезпечення та його оточення, щоб усі зацікавлені сторони проекту могли чітко розуміти, що можна очікувати/досягти у проекті. Тому ми не будемо базувати нашу роботу на гіпотезах, не перевіряючи заздалегідь їх правдивість.
Цей список, звичайно, можна доповнити іншими інструментами, які би більш адекватно відповідали реаліям та потребам вашого проекту
4. Комунікаційна стратегія
Метою методології Швидкого старту є забезпечення швидкого володіння цим інструментом для кінцевих користувачів. Тому ефективне спілкування має вирішальне значення для успіху цього підходу. Тому його оптимізація приведе нас до таких принципів:
Спільне використання документації з управління проектами: Найкращий спосіб забезпечити усіх зацікавлених сторін проекту володінням однаковим рівнем знань, забезпечити прямий доступ до документу відстеження проекту (Організатор проекту). Цей документ міститиме, принаймні, список завдань, що будуть виконуватися як частина реалізації, для чого чітко визначений рівень пріоритету та менеджер. Організатор проекту - це інструмент відстеження проектів, який дозволяє як детальне відстеження поточних завдань, так і загальний прогрес проекту.
Зверніть увагу на важливу інформацію: щоб мінімізувати час документації до найважливіших вимог, ми дотримуємось наступних правильних практик:
Протоколи зустрічі будуть обмежені лише рішеннями та перевірками;
Статуси проекту визначаються лише тоді, коли досягнуто важливого етапу;
Будуть організовані навчальні курси по стандартному або індивідуальному рішенню.
5. Налаштування та розробка
Odoo - це програмне забезпечення, відоме своєю гнучкістю та важливою здатністю до еволюції. Однак значна частина розвитку суперечить швидкій та стабільній реалізації. Ось чому рекомендується:
Розвиватися лише з вагомих причин: рішення про розробку завжди повинно бути прийняте, коли співвідношення витрат і вигод є позитивним (економія часу на щоденній основі тощо). Наприклад, краще реалізувати значний розвиток, щоб скоротити час щоденної експлуатації, а не виконувати операцію лише один раз на квартал. Загальновизнано, що чим ближче рішення до стандарту, тим легше і більш плавно відбувається процес міграції, і чим нижчі витрати на обслуговування для обох сторін. Крім того, досвід показує нам, що 60% первинних запитів на розробку знищуються через кілька тижнів використання стандартного Odoo (див. "Прийняття стандарту як пріоритет").
Заміна без реплікації: є вагомі підстави для прийняття рішення про зміну програмного забезпечення для управління. У цьому контексті момент реалізації є правильним моментом прийняття і навіть є ініціатором зміни як з точки зору використання програмного забезпечення, так і на рівні бізнес-процесів компанії.
6. Тестування та принципи перевірки
Незалежно від того, чи були розробки чи ні, важливо перевірити відповідність рішення операційним потребам компанії.
Розподіл ролей: у цьому контексті консультант буде відповідати за надання рішення, що відповідає визначеним специфікаціям; контактна особа повинна буде протестувати та підтвердити, що рішення, яке постачається, відповідає вимогам операційної реальності.
Управління змінами: коли необхідно внести зміни до рішення, зазначений розрив обумовлений:
Різницею між специфікацією та доставленим рішенням - це виправлення, за яке відповідає консультант.
Різницею між специфікацією та вимогами операційної реальності - це зміна, на яку відповідає контактна особа.
7. Імпорт даних
Імпорт історії транзакційних даних є важливою проблемою, і відповідним чином потрібно відповісти на це, щоб забезпечити безперебійну роботу проекту. Дійсно, це завдання може зайняти багато часу, і, якщо його пріоритет не є чітко визначеним, запобігти впровадженню вчасно. Щоб зробити це якомога швидше, буде вирішено:
Не імпортувати нічого: Часто буває, що після відображення імпортування історії даних стає не необхідним, причому ці дані зберігаються поза межами Odoo і консолідуються для подальшої звітності.
Щоб імпортувати обмежену кількість даних перед початком впровадження: коли історія даних стосується оброблюваної інформації (наприклад, замовлення на купівлю, рахунки-фактури, відкриті проекти), необхідність мати цю інформацію з першого дня використання у впровадженні - це реально. У цьому випадку імпорт буде здійснюватися до початку запуску впровадження.
Імпорт після запуску впровадження: коли історія даних повинна бути інтегрована з Odoo, в основному для цілей звітування, то очевидно, що вони можуть бути інтегровані в програмне забезпечення ретроспективно. У цьому випадку запуск впровадження буде передувати необхідному імпорту.