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