У першій частині ми розповіли про наш довгий шлях пошуку ідеальної системи для управління діджитал агентством, який привів нас від численних CRM-систем до амбітного рішення впровадити ERP-систему Odoo. Ми були мотивовані її репутацією, широкою функціональністю та перспективою закрити всі наші потреби – від управління проєктами до фінансової звітності.
Проте, ми знали занадто мало про Odoo, а підрядник, який допомагав нам з налаштуваннями, знав надто мало про нас. Впровадження Odoo Community затягнулося на 24 місяці, обійшлося нам майже в $20K, але сьогодні поговоримо про найдорожчі помилки, зроблені нами на цьому шляху протягом перших 14 місяців.
З чого все почалося: модулі CRM та Проєкти – наші першочергові цілі
На старті проєкту автоматизації, наш фокус був чітко визначений. З-понад 80 активними проєктами, ми гостро відчували необхідність в зручному тасктрекері. Тому модуль “Проєкти” був нашим пріоритетом, адже він мав вирішити першочергові та критично важливі для нас завдання:
- Оптимізація постановки задач: налагодити зручну та зрозумілу постановку задач, з дедлайнами та відповідальними особами.
- Контроль та управління завантаженістю: зробити доступною інформацію щодо завантаженості команди у у розрізі дня, тижня, місяця, що дасть змогу планувати їхню роботу погодинно на подальші періоди.
- Централізоване збереження інформації: доступність та збереження інформації про кожен проєкт в одному місці.
- Фіксація часовитрат: можливість побачити кількість часу, витраченого спеціалістами на кожен проєкт та окремі задачі, що стало б запорукою справедливого білінгу.
- Визначення прибутковості проєктів: ключова мета – чітко бачити рентабельність кожного проєкту.
- Аналітика заробітку: визначати розмір заробітку по проєкту в місяць (ґрунтуючись на кількості затабельованих годин у проєкті та вартості години кожного окремого спеціаліста).
Зважаючи на вищезазначене, ми зробили висновок, що цілі щодо управління проєктами тісно перепліталися з наступним стратегічно важливим модулем – управлінським обліком.
Ми вже тоді розуміли, що кінцевою метою є зв’язати виконані роботи по проєктах з доходами та витратами по них, включаючи заробітну плату спеціалістів. Впровадження модулів CRM та управління проєктами стало фундаментом для майбутнього управлінського обліку.
Наш підрядник, з яким ми розпочали впровадження Odoo, окреслив початковий план проєкту, що включав:
- розгортання бази даних,
- внесення користувачів,
- поетапне налаштування та навчання по модулях CRM та Управління проєктами.
Нам здавалося, що ми маємо чіткий шлях.
Падіння: Ціна відсутності стратегічного бачення та опір команди
Попри наявність початкового плану, реальність впровадження Odoo Community виявилася значно складнішою та дорожчою, ніж ми уявляли. Головні виклики та “падіння” полягали у наступному:
По-перше, ми зіткнулися з недостатнім досвідом першого менеджера з боку підрядника. Він погоджувався на всі наші запити щодо кастомізації, не маючи достатнього стратегічного бачення ролі системи Odoo у діджитал агентства. Це критично, адже Odoo – це система, до якої потрібно певною мірою підлаштовуватися, а не навпаки. Звісно, її можна глибоко кастомізувати, але часто така “бездумна” кастомізація тягне за собою зміни, які через кілька місяців виливаються у величезні проблеми.
Яскравим прикладом стало налаштування шаблонів проєктів та табелювання. Для нас було важливо, щоб при виборі послуги менеджером з продажу (наприклад, SEO), система автоматично створювала проєкт за шаблоном з готовими стандартними задачами, розподіленими за віхами: віха проджекта (для задач проєкт-менеджера) та віха спеціаліста (для задач спеціаліста з цієї послуги). Якщо відбувався допродаж (наприклад, РРС), у цьому ж проєкті створювався додатковий пул задач з такими самими віхами, але для нової послуги.
Спочатку все виглядало зручно, але з часом виявилося, що всі задачі з усіх віх позначалися як задачі першої послуги (SEO). Це призвело до того, що табелювання спеціаліста з РРС падало в послугу SEO, що робило неможливим побачити, скільки часу витрачається командою окремо на послугу SEO і окремо на послугу РРС. Коли ми помітили цю проблему (через 6 місяців активної роботи), у нас накопичилося більше 7000 задач, які потрібно було вручну розсортувати за послугами.
Мало того, що розробка додаткового фільтру для відображення цих даних сама по собі коштувала грошей, ще потрібно було розробити спеціальний скрипт, який міг би ідентифікувати, до якої віхи віднести задачу. Усі неідентифіковані задачі, включаючи заархівовані, скасовані та вже виконані, потребували ручної обробки (сортування). Згодом ми зрозуміли, що нам потрібно не лише мати під кожну послугу конкретну віху (віха проджекта SEO, віха спеціаліста SEO, віха проджекта РРС, віха спеціаліста РРС, віха проджекта SMM, віха спеціаліста SMM…), а й присвоювати кожній задачі фільтр “послуга” та коректний “Елемент замовлення на продаж”. Останнє є критично важливим, оскільки саме це пов’язує задачу з комерційною пропозицією у модулі Продажі і згодом відображає часовитрати по цій задачі в управлінському обліку, що безпосередньо впливає на розподіл заробітної плати спеціалістів, які працювали по цьому проєкту. І це лише один із численних моментів, які виявилися через відсутність стратегічного бачення нашого проєкту з боку підрядника.
Окремим, і, мабуть, найбільш складним викликом, став опір команди. Перехід на Odoo Community виявився для співробітників значно складнішим, ніж ми очікували, особливо після відносно спрощеного інтерфейсу Worksection. Колектив робив усе можливе, щоб відмовитися від роботи в новій системі. Проте, ми змогли залучити команду завдяки низці цілеспрямованих кроків:
- Залучення керівників відділів: керівники були активно залучені до розробки детальних чеклистів задач, які лягли в основу віх для шаблонних проєктів. Це забезпечило їхню співучасть та розуміння важливості змін.
- Інтенсивне навчання: було проведено понад 12 навчань для всього колективу та окремих відділів, що дозволило краще зрозуміти функціонал Odoo та його переваги. Ми створили базу знань з відеоінструкціями, до яких команда може повернутися в будь-який момент.
- Ретельне налаштування рівнів доступу: це стало ще одним великим викликом, адже нам довелося понад 6 разів переналаштовувати різного роду доступи для різних ролей у компанії. Не всі спеціалісти повинні мати доступ до всіх функцій системи, і це спричинило труднощі, зокрема, з:
- Табелюванням часу: ми вимагали, щоб ніхто не міг редагувати табель іншого співробітника, а також не міг редагувати свій за попередній день. Це стимулювало людей бути пунктуальними, вчасно вносити свої часовитрати та описи до них, а також допомогло уникнути махінацій. Проте, ці налаштування дуже часто “злітали” – то через системні баги, то через некоректне впровадження на стороні підрядника.
- Доступом до редагування проєктів окремими уповноваженими особами.
- Доступом до продажів, рахунків та контактів спеціалістів: щоб ніхто, крім відповідальних осіб, не міг редагувати картки співробітників.
Особливий біль: Марні сподівання на Діаграму Ганта
Ще одним болючим викликом стало впровадження Діаграми Ганта. Ми щиро вірили, що Діаграма Ганта у своєму класичному розумінні допоможе нам контролювати навантаження спеціалістів, і менеджери зможуть миттєво ставити задачі на вільні слоти в графіку. Ми навіть придбали спеціальний модуль для нашої версії Community, але він, на жаль, так і не запрацював коректним чином. Модуль виявився надзвичайно складним у використанні, дати та години в ньому постійно “з’їжджали”, фільтр по спеціалісту не спрацьовував, а завантаження інтерфейсу тривало довго. Виявилося, що для версії Community цей функціонал є непопулярним, тому недопрацьованим, а у версії Enterprise він є стандартним і значно покращеним. Перехід на Enterprise на цьому етапі уже був фінансово не виправданим, тож від Діаграми Ганта в Odoo ми відмовилися. Він досі присутній у нашій системі, але ми ним не користуємося.
І досі у нас немає зручного місця в системі, де можна було б повноцінно побачити навантаження спеціаліста. Ми намагаємося працювати з фільтрацією задач по “Уповноваженому” в кожному конкретному проєкті та просимо всіх спеціалістів самостійно ставити собі дедлайни. Також ми навчилися ефективно працювати із вкладкою “Мої завдання”. Але все це повноцінно не замінить зручного, візуального відображення завантаженості спеціаліста, як це було, наприклад, у Worksection.
Приклад інтерфейсу Діаграми Ганта в Odoo Community.
Приклад організації вкладки “Мої завдання” в Odoo Community.
Це яскравий приклад того, як ми пристосувалися до системи, після того, як не змогли пристосувати її до нас. Якби нам хтось на початку сказав, що цей функціонал не підійде або буде працювати з такими обмеженнями, ми б не витратили зайві ресурси на впровадження цього модуля, спілкування з його розробниками з Індії та тестування “кривого” функціоналу.
Інші виклики Odoo Community для LuxSite Digital Agency
Крім ряду вище детально описаних проблем, ми зіткнулися з набором загальнопоширених викликів, які постають перед тими, хто обирає версію Odoo Community. Бачу сенс зазначити їх тут лише коротко для розуміння
- Непередбачувана складність кастомізації: Як відкрита та “безкоштовна” версія, Odoo Community вимагає значно більше часу та зусиль на адаптацію під наші унікальні процеси, ніж ми очікували. Кожна, на перший погляд, дрібниця вимагала розробки або складного налаштування.
- Відсутність “готових” рішень: На відміну від платних версій або інших CRM, тут не було багатьох функцій “з коробки”, які ми вважали стандартними. Це призводило до постійного усвідомлення, що “ось тут потрібно допиляти”, а це – додаткові витрати часу та грошей.
- Залежність від розробників: Практично кожен крок вимагав участі програмістів, що не тільки збільшувало бюджет, але й створювало “вузькі місця” у процесі впровадження.
- Проблеми з даними та міграцією: Перенесення даних з попередніх систем виявилося не тривіальним завданням. Незважаючи на попереднє очищення, виникали неточності та конфлікти, що потребувало додаткових годин роботи.
- Неочікувані “баги” та збої: Хоча Odoo є стабільною системою, версія Community, без належної підтримки та тестування інтеграцій, час від часу давала збої, що призводило до плутанини.
- “Роздування” бюджету: Кожен додатковий “допил”, кожна година розробника додавалася до кінцевої суми, яка дуже швидко перетнула позначку в $10K, не покривши ще й половини наших стратегічних цілей.
Успіх крізь випробування: Роль компетентного менеджера
За 2 роки роботи з підрядником ToDo нам було змінено чотирьох менеджерів. І лише останній нарешті зміг допомогти нам виправити більшість створених проблем та помилок. Компанія LuxSite Digital Agency та я особисто щиро вдячні Олесю Адаменку за його уважність, залученість, зацікавленість та високу компетентність. За його вміння організувати свою команду, зрозуміти та чітко пояснити розробникам наші потреби, ставити завдання та надавати нам зрозумілу звітність. За його відмінну пам’ять, приємну комунікацію та справжню клієнтоорієнтованість, які виявилися вирішальними для того, щоб вивести наш проєкт на шлях успіху.
Попри всі труднощі, ми все ж таки запустили та налаштували ефективну роботу ключових модулів “CRM” та “Проєкти”. Ми нарешті отримали централізоване сховище даних про клієнтів та проєкти, покращили управління завданнями та отримали базовий контроль завантаженості команди.
Наш досвід впровадження Odoo Community був дорогою школою. Ми отримали цінний урок про те, що “безкоштовна” система може бути дуже дорогою, якщо ви не враховуєте приховані витрати на розробку, підтримку та адаптацію, і найголовніше, якщо ваш підрядник не має глибокого розуміння та стратегічного бачення вашого проєкту.
Висловлюючи ці поради, я цілком і повністю розумію, що відповідальність за фінансові та часові втрати лежить в тому числі і на нашій стороні. Ми, як клієнт, на початку роботи, можливо, доклали недостатньо зусиль для окреслення рамок проєкту, не були повною мірою залучені в освоєння платформи Odoo та її функціоналу, недостатньо змогли донести до підрядника особливості роботи агентства діджитал маркетингу.
Для LuxSite ці 14 місяців стали періодом як розчарувань, так і усвідомлень. У наступній частині я обіцяю розповісти, як минули решта 10 місяців роботи, та чим завершилося втілення модулю Управлінський облік.
