воскресенье, 21 мая 2017 г.

CRM в стиле Agile в облаке Google. Почти бесплатно. Реально или нет?

До этого я создавал и запускал решения по автоматизации моего бизнеса в облаке Google, а потом публиковал их в блоге и рассказывал с какими проблемами столкнулся и как их решал. В этот раз я решил немного поменять последовательность и заранее поделиться некоторыми мыслями по автоматизации продаж и внедрению CRM.

Существует распространенное мнение, что для того, чтобы увеличить продажи достаточно купить CRM. Точно такое же мнение было и у моего компаньона. Он постоянно натыкался на рекламу разных CRM и предлагал их купить потому что всякий раз ему предлагались какие-то конкурентные преимущества: звонок в один клик, удобные отчеты по воронкам, интеграция с почтовым клиентом и так далее. Однако это заблуждение. Любая программа автоматизирует имеющийся бизнес-процесс. Как говорят на своем жаргоне интеграторы: “автоматизируя бардак получите автоматизированный бардак”. Каждый продукт, каждая компания имеет свои нюансы в продвижении, связанные с географией расположения и конкурентными преимуществами, которые невозможно учесть в коробочной версии программы. И звонок в один клик далеко не самое важное и не самое сложное. Поэтому в нашем бизнесе мы делаем иначе. Мы хотим управлять продажами и выстраиваем бизнес-процесс: сначала шлифуем его с помощью подручных средств, а потом уже выбираем инструмент для его автоматизации.

Но думать об автоматизации я начал уже сразу. Тайком от моего компаньона. Мысль была такая: прямо из подручных средств, используемых при шлифовке бизнес-процесса, скомбинировать будущую CRM как конструктор. Поясню свою мысль. Обычно для отчетов в качестве подручного средства используется MS Excel, для отправки счетов клиентам почтовый клиент, например, MS Outlook, в качестве товарной базы 1C, для хранения общих документов используются папки на сетевом диске. Потом после покупки  CRM это все как-то придется менять. Реестры переносить в базу данных, почту в почтовый клиент црмки, товарные движения синхронизировать между двумя базами, сетевое хранение документов наверняка вообще останется за пределами CRM. Это непростой процесс, который усугубляется переходом персонала на использование новой незнакомой программы.

В то же время все подручные средства есть в G Suite. Для реестров и отчетов Таблицы, почтовый клиент Gmail, хранение Google Drive, с товарной базой и так синхронизироваться. Помимо того, есть еще Контакты, Календарь, Карты, Задачи, Сайты и другие приложения, в том числе для смартфона. На период шлифовки бизнес-процесса перенос данных между ними осуществляется вручную (например, после отправки счета по почте надо внести в реестр отправленных счетов запись). Но зато впоследствии нам достаточно просто автоматизировать ручные операции по переносу данных на языке сценариев Google Apps Script (написать скрипт, который при отправке счета будет делать запись в Таблицу) и вот она готовая CRM. Полученная по технологии Agile.

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

Это мой первый проект по внедрению CRM. До этого я много внедрил и автоматизировал систем для управленческого учета. В них ядром системы является реестр хозяйственных операций с нужным набором аналитики. На базе такого реестра можно строить любую управленческую отчетность. Но самое главное, можно произвольным образом расширять и дополнять конфигурацию системы. При этом вопросов совместимости не возникает. Это достигается за счет изменения наборов и значений аналитик.

Аналогичной основой CRM должен стать реестр активностей (событий, встреч, звонков, счетов). К этому реестру и будут “цепляться” все остальные части CRM. Например, когда мы автоматизируем воронку с лендинга, получение лида с лендинга записываем в реестр как две активности: лид и звонок. Звонок — это обычная задача для менеджера, а лид — это событие. Когда выставляем счет (другая процедура бизнес-процесса) — записываем в реестр две активности: счет и звонок. Звонок — это опять же  просто задача, счет — событие. Когда мы начинаем автоматизировать ежедневную работу менеджера по продажам (третья процедура), то мы просто каждое утро выбираем из нашего реестра активностей его задачи (звонки лидам, звонки по счету, просто поручения). Когда мы начинаем анализ воронки продаж — вся статистика у нас есть опять же в реестре: количество лидов, количество счетов… Таким образом, разные процедуры нашего бизнес-процесса продаж будут включаться в контур автоматизации присоединяясь к реестру со своими активностями, или используя существующие.

С реализации реестра активностей я и начну подробный рассказ о конструировании CRM в стиле Agile в нашей компании. Ждите мой следующий блог.    

5 комментариев:

  1. С большим интересом прочитал ваш пост, спасибо, буду ждать продолжения, тема мне очент близка. Недавно даже описывал реализацию системы синхронизированной отчётности в своей компании с помощью гугл-табличек (https://habrahabr.ru/post/328820/)

    ОтветитьУдалить
  2. Кирилл, действительно тема очень интересная. Правда мне пришлось сталкиваться с разными объяснениями почему самопал лучше, а потом оказывалось, что CRM (особенно если оно чуть больше 1 млн. за пакетную версию на 5 пользователей) не такое уж зло. Законодательство, требования регуляторов и динамика развития комапании и сектора рынка очень сильно влияют на выбор программного обеспечения. Не исключаю возможности создания модульной системы на Apps Script в разрезе GSuite, но Таблицы не самый лучший выбор.

    ОтветитьУдалить
    Ответы
    1. Кто сказал Таблицы? Firebase. Но об этом в следующий раз...

      Удалить
    2. UrlFetch имеет небольшие квоты =/

      Удалить