{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Работа в агентстве: как мы не внедрили CRM-систему

Когда я только пришел в агентство, я понятия не имел, что мой первый проект будет факапом такого масштаба. Наша команда сильно ошиблась, а агентство все еще возвращает клиенту деньги.

В этой статье я расскажу, как так получилось и что мы из этого вынесли.

Проект и задача

К нам обратился клиент, которому нужно было оцифровать бизнес-процессы, чтобы спроектировать и внедрить CRM-систему.

Клиент — компания по продаже и аренде звукового оборудования. Они уже давно на рынке и наработали хорошую базу благодаря своему сервису. Обращений становилось все больше, и отдел продаж не «вывозил» их количество. Руководство посчитало, что обработка заказов отнимает слишком много времени, и обратилось к нам в агентство, чтобы мы помогли все это автоматизировать.

Процессы стандартные: принять заявку, составить бриф, отправить КП, согласовать его, забронировать оборудование, провести счета и отгрузочные документы. В сумме два таких процесса: для аренды и для продажи.

Одно «НО» — все данные велись в бесконечном количестве «экселек». Под каждого клиента была заведена своя папка, в которой еще миллион папок и все это на отдельном сервере.

Три таблицы учета — по 5 вкладок с 1000 строк в каждой 😑

Забронированное оборудование отмечалось определенным цветом в огромной таблице заказов. В ней была строчка под каждую дату и столбец под каждую позицию ассортимента. Все это держалось на внешнем «расшаренном» сервере, к которому поочередно подключались менеджеры.

Оценка работ

Работа над таким проектом строится в три этапа: анализ, проектирование и внедрение.

На этапе анализа аккаунт-менеджер должен оценить масштаб проекта. Он вместе с командой считает количество часов, которое потребуется специалистам для следующего этапа — проектирования системы.

Ошибкой было то, что проект оценили неверно. Подумали, что объем стандартный и не углубились в процессы.

Итог: продали базовую услугу проектирования, которой было явно недостаточно для проекта такого масштаба.

Проектирование и главная ошибка

Моя работа начиналась на этом этапе. Я работал проджект-менеджером, но в этот проект меня позвали специалистом. Так получилось, что нужен был третий человек в команду, а опыта в CRM-маркетинге больше ни у кого не было.

У меня был базовый опыт проектирования CRM-систем. Базовый — это оцифровать бизнес-процесс и воссоздать его на основе коробочных решений. Например: автоматизировать бизнес-процесс на базе amoCRM или Bitrix24.

Как все начиналось

Чтобы спроектировать систему нужно понять, как происходят процессы в компании. Мы изучили таблицы, в которых ведется учет, посмотрели, как работают менеджеры, и пообщались с персоналом.

Схематично расписывали то, как новая сделка проходит воронку. Какие задачи ставятся менеджерам, на каких этапах подключаются интеграции, какие данные передаются в базу данных и так далее.

В результате создали карту с двумя главными процессами: продажа и аренда.

Скриншот карты в Miro. На карте: этапы воронки, авто-задачи, виджеты и интеграции, схемы смен ответственных, поля карточек сделок

Все этапы сделок решили вести в amoCRM. Там легко выстроить процессы и у нее есть много интеграций с другими сервисами.

Учет решили вести в «МоемСкладе» (CRM для товарного бизнеса). В ней можно сводить баланс товаров на складах, делать отгрузочные документы и проводить инвентаризацию. Под наши задачи система подходила, поэтому решили ее использовать.

Все шло неплохо, и клиент согласовывал варианты. Но мы понимали, что проект большой и «косяки» могут вылезти где угодно.

Что мы придумали

В процессах продажи и аренды было много позиций товаров. Нужно было уйти от «экселя» и не считать их количество руками.

Воронку «Продажа» — собрали в «амо», все было отлично. Менеджер мог легко провести сделку по воронке, выбрать нужные товары и отгрузить их со склада. Когда товары отгружались, они списывались со склада в «МоемСкладе», и вся отчетность сводилась. Супер.

Процесс аренды оказался сложнее. Сложность заключалась в интеграции amoCRM и «МоегоСклада». Мы подключили «МойСклад» для арендных товаров и поняли, что не знаем, как свести их отчетность.

Проблема возникала на этапе сделки, когда менеджер формировал КП и выбирал нужные товары со склада. Это происходило через виджет «МоегоСклада»: в нем были все товары и их остатки.

Так выглядел виджет «МоегоСклада» для бронирования внутри amoCRM

По задумке: нужно выбрать склад, отметить нужные товары и их количество. После этого формируется КП и отгружается товар.

Где мы пошли «не туда»

Чтобы вести отчетность по аренде, мы сделали возможность списывать товары на время и потом возвращать обратно на исходный склад. В реальности это так и происходило, но технически получись «костыли».

Фишка в том, что товары отдаются в аренду на время — их нужно списать на определенный промежуток и потом вернуть на склад обратно. Плюс еще отдельный процесс транспортировки: когда товары уже отсутствуют на складах, но еще не запущены в работу. В стандартном функционале «МоегоСклада» нет таких возможностей.

Мы придумали не лучший вариант автоматизации процесса возврата на склад. Но клиент нам доверял, у нас получилось это согласовать.

Чем закончилось проектирование

Услуга проектирования в стандартном формате не подразумевает подробного технического задания. Вся услуга — это набор решений, который выстроен в единую схему. Карта в Miro — это и есть проектирование.

Казалось бы, что тут такого. Нормально, когда сходу непонятен масштаб проекта. Техническое задание пишется под конкретное решение.

На проектировании мы это решение придумали. Но придумали плохо, и вот почему:

Наша основная ошибка: сначала продали, а потом стали думать, как реализовать. Полноценный бриф с клиентом нужно было проводить до оценки стоимости.

Мы посмотрели на огромную таблицу учета и смело заявили, что это можно реализовать в «МоемСкладе». С чего мы так решили? Думали: «ну вот приступим к внедрению и там будет все понятно». Конкретно не хватило опыта.

Никита Царев
, менеджер проекта

Внедрение и последствия

Отрицание, гнев, торг, депрессия, принятие

После проектирования написали тех. задание на 12 страниц. Разобрали по шагам всю логику процессов работы виджета для аренды.

Было очень сложно обосновывать клиенту наши решения. Получалась куча документов с ответами на вопросы и обсуждением решений.

Несмотря на все — мы тянули весь этот объем информации и хотели довести проект до конца.

Рассинхрон ожиданий

Сокол тысячелетия и кукурузник. Но самолет — это лучше чем пешком. Тут смотря с чем сравнивать

С самого начала проекта клиент верил, что можно сделать «космический корабль». Но мы не синхронизировали наши картины, когда осознали, что получится только «самолетик». Это отрицательно сказалось на процессе: на каждой из презентаций появлялись все новые функции, и клиент пытался их «продавливать».

Было очень много дополнительных решений, которые превращали CRM в ERP-систему. Мы не были к этому готовы, поэтому пришлось от большинства из них отказываться. Например, убрали функцию автоматического начисления скидки и функцию расчета маржинальности по каждой сделке.

После четырех трехчасовых встреч с «разборами полетов» приняли решение отказаться от дальнейшей работы.

Выводы

Недостаток профессионализма и плохая работа с ожиданиями убили наш проект. Клиент потерял время и нервы. Мы потеряли всё, хотя получили незаменимый опыт.

Основные ошибки

  • Плохой анализ: проводить полный бриф нужно до оценки и написания ТЗ. Работать по принципу «сначала продадим, потом разберемся» — неправильно.
  • Проектирование. Не нужно переходить на этот этап без проработанного брифа и тех.задания. Карта в Miro — это хорошо, но ТЗ нужно писать сразу.
  • Выбор системы. Если вы специалист только в одной-двух системах, то не надо предлагать их в каждом проекте.
  • Работа с ожиданиями. Если не знаешь, как реализовать ту или иную фичу, то лучше отказаться от неё или предложить клиенту других подрядчиков.

Тут хорошо подойдет цитата из статьи БЮРО про «ФФФ»:

Самая большая ошибка — предполагать, что проект пойдёт, как задумано. Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений.

Начиная движение, проект сталкивается с сопротивлением окружающей среды. Специалист забывает учесть сложный случай. Клиенту не нравится дизайн. Программистов тормозит проблема в реализации. Кто-то заболевает. У кого-то ломается компьютер. Можно перечислять возможные сюрпризы, но в каждом проекте будут свои.

Проект движется и колеблется вокруг идеальной линии, и, возможно, придёт в совсем другую точку Б’.

Иллюстрация про управление проектами и принцип «ФФФ» Источник: bureau.ru

Агентство: Serenity.

0
91 комментарий
Написать комментарий...
Сергей Михельсон

Основная ваша ошибка в том, что вы играетете бизнесменов, при этом не набив шишки в качестве подчиненных. Я бы на законодательном уровне запретил делать бизнес до 30 лет, если только это не какая то исключительная идея. Судя по описанию - задача простая была, просто вы попытались натянуть питона на слона, используя стандартные црмки, которые расчитаны на простые процессы. Проблемы бы не было если упростили процессы под стандартные крмки или разработали конфигурацию на 1с. Только там бюджеты другие и есть мнение, что эксель неплохо справляется со своими задачами.

И мой вам совет: не надо сидя с клиентом записывать его идет в мак бук. Пишите всё карандашем на листе бумаги.

Ответить
Развернуть ветку
Darya

«Я бы на законодательном уровне запретил делать бизнес до 30 лет, если только это не какая то исключительная идея.»
Что за глупость вы пишите? 

Ответить
Развернуть ветку
Сергей Михельсон

Почему глупость? Сейчас очень много молодых людей занимаются всякой ерундой, типа купи продай или внедри крм никогда этого не делая. Нет реального производства короче говоря. Представьте себе, сколько рабочей силы появятся на заводах и как взлетит экономика, когда молодые неопытные люди бубут набраться реального опыта. Бизнес станет сложнее и качественнее.

Ответить
Развернуть ветку
Darya

Не согласна с вами.
1. Возраст сам по себе ничего не означает
Есть успешные предприниматели моложе 30 лет и люди гораздо более «зрелого» возраста без достижений в жизни
Очевидно, что возраст в отрыве от личностных качеств, амбиций и тд - ничего не означает с точки зрения «готовности к бизнесу»
2. Работа на заводе не способствует получению необходимых для предпринимателя знаний, умений и навыков, не формирует необходимый опыт.
3.Существуют разные бизнес модели и «реальное производство» всего лишь одна из них. Не лучше и не хуже.

Ответить
Развернуть ветку
Сергей Михельсон

Поэтому у нас в стране в банковской сфере работает 400 тыс человек, а в автопроме 50, тогда как в германии в автопроме 500к, а в банках 40. Как думаете, от кого больше толку? Я не говорю обязательно про заводы, просто многие хозяева бизнеса делают его не имея реадьного опыта, а потом с удивлением обнаруживают, что проваливают проект и получают меньше хорошего инженера. Это не бизнес, а пустая трата времени  и варка в собственном соку.

Не очень понимаю, но как можно запустить производство не зная как его наладить, Вы не путаете с генеральным директром, которого нанимает владелец бизнеса, чтобы он строил процессы?

Ответить
Развернуть ветку
Bulat Ziganshin

в результате мы пользуемся отличными рос. банковскими приложениями и ездим на отличных немецких авто :)  а вы хотите наоборот? )))

Ответить
Развернуть ветку
SG

Мне кармы не хватает поставить лайк ) свалю жирный +

Ответить
Развернуть ветку
88 комментариев
Раскрывать всегда