Роман Ремизов

Системный аналитик ГК Юзтех

Спойлеры: дополнение к «здравствуй, мир!»

Здравствуйте, коллеги!

Меня зовут Ремизов Роман, я — системный аналитик ГК Юзтех. Я расскажу о частном опыте внедрения, кастомизации и сопровождения различных версий CRM-систем.

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

Статья поделена на две части. Вторая часть, содержащая примеры подходов, будет представлена через пару недель.

Фокусировка: почему именно заказы, а не вот это вот всё?

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

Про многообразие типов информационных систем написано много. Системы, выполняя свою функциональную нагрузку, часто отделяются друг от друга не столько направленностью автоматизируемых процессов, сколько зонами ответственности. Достаточно часто на практике встречается такая ситуация, при которой существенная часть функциональности одной профильной системы переносится в другую.

В моей практике подобная задача присутствовала. В 1С контуре была организована функциональность для обработки операторами контактного центра обращений, которую нужно было перенести в CRM систему версии Enterprise. Зачем? Чтобы организовать работу операторов согласно парадигме «одного окна» или, если точнее, «одной системы».

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

Кроме того, что из 1С были заимствованы или реплицированы необходимые для работы справочники, на front-сегменте CRM были продублированы все элементы управления с учетом их обязательности при заполнении документов второго порядка. Ведь любое обращение должно иметь сопутствующие действия и результаты обработки, часто выраженные в генерируемых документах.

Это существенно расширило жизненный цикл таких ключевых сущностей для CRM-систем, как заказ и клиент. Кроме того, были добавлены новые сущности, унаследованные от донора – 1С системы.

Стоит отметить, что в зону ответственности CRM-системы входят не только заказы и клиенты, но и все остальные сущности, связанные с этими двумя. Просто эта связь проявляется на разных этапах жизненного цикла и не всегда выглядит тривиальной.

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

Часто для определения пределов функциональности я использовал показатели продуктивности: Сколько заказов за определенный отрезок времени обрабатывает система на конкретном этапе жизненного цикла? Сколько клиентов торговой онлайн-площадки она обслуживает в день или в пиковые часы «черной пятницы»? Сколько времени сотрудники заказчика тратят на обработку одного заказа при его подтверждении, при отказе от него клиентом, при сборке заказа на складе, если не все позиции заказа имеются в наличии и частичная сборка требует отдельного подтверждения через звонок оператора клиенту? Какую выгоду получит заказчик, вложив в автоматизацию часть бюджета проекта, если цели автоматизации будут достигнуты?

А цели — это почти всегда натуральные выражения контрольных показателей:

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

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

Автоматизация в CRM-системах — это про увеличение пропускной способности, а также про исключение пресловутого человеческого фактора. Тем более для e-commerce, способность — это успешно выполненные заказы, поступившие от клиентов. И процент возврата по этим заказам, в идеальном мире, должен быть если не равен, то решительно стремиться к нулю.

Saas и Enterprise: о реальных различиях между версиями CRM

Да, когда разговор переходит в плоскость реального положения вещей, меркнут все идеалы, причем, как теоретических выкладок гениальных книг, так и технологических презентационных показателей. Кто, кому, а главное, для чего продал это решение? Вам знакома эта внутренняя риторика?

Вероятно, так происходит со всеми системами, но с CRM это чаще превращается в головную боль. Дело не в том, что системы чем-то плохи. Дело в том, что они убийственно нелепо подобраны под те задачи, которые должны решать. Импортозамещение? Что мешало с начала десятых это предусмотреть? В Agile тогда никто не верил? Его как такого, вроде как, и не было. И про Kanban знали далеко не все. 

Первое и самое главное отличие Saas версии CRM-системы от ее Enterprise аналога — бюджет проекта. Не секрет, что выбор Saas — выбор более типового решения. Он кажется дешевле, нежели «монстр из коробки», кажется меньше обязывает выполнять доработки. Имеет что-то, что уже работает «здесь и сейчас».

Но Saas представляет собой законченный продукт, со всеми вытекающими из этого последствиями. Это «средняя по больнице» функциональность, набор стандартных модулей, ограниченные возможности что-то изменить, так, как это нужно стейкхолдерам. Если вам не нравится ни один из сервисов телефонии, предусмотренных стандартными модулями, чтобы добиться желаемого, придется выполнить или, сказать точнее, выдержать уникальный квест на терпение и сообразительность.

Это как купить автомобиль, который делали в девяностые годы прошлого века, и современный пластиковый конструктор страны риса и до хун пао. Машину, которую делали для дороги, где с пробитым поддоном картера можно было проехать еще двести пятьдесят километров в поисках автосервиса, и нечто с колесами, которое собрали для того, чтобы обеспечить дилеру доходы на одном только техническом обслуживании.

Так получилось, что второе отличие обозначилось само собой. Да, Enterprise — это простор для творчества и, потенциально, лучше масштабируемая история. Но если брать два обозначенных отличия вместе, а не раздельно, как это любят делать субъективно настроенные критики CRM-систем, становится очевидно, что беда не в том, что Saas – «кирпич», а Enterprise – «глина», из которой можно «сделать все что душе угодно». Проблема в том, что те, кто выбирают Saas, часто не располагают четко выстроенной стратегией ее масштабирования. Потому что они коммерсанты, а не технари или аналитики. И, да, потому что коммуникации они выстраивают с такими же коммерсантами, которые продают им решения у вендора, в штате у которого они состоят.

«Мы понимаем, что нам нужна CRM-система. Что вы нам можете предложить?»

«Прекрасно! Вот, новенькая версия Enterprise. Непревзойденная функциональность. Хороший старт! Когда поймете, где нужно шире, — вернетесь к нам и мы дадим еще! Только внедрение, учитывая старую 1С, новую SAP и прочее, прочее, выйдет вот в эту сумму…»

«А она может выступать в роли хаба стоков? У нас медленная розница, пинг в 40 минут… Понимаете, мы — федеральная торговая сеть. У нас есть отделение в другой стране…»

«Тем более! Enterprise идеально подходит!»

«А вот если добавить микро-сервис пересчета корзины? Мульти-сайт, мобильное приложение, разнообразные программы лояльности очень вешают CMS, понимаете?»

«Великолепно! В этом случае Enterprise — это ваше спасение!»

«Сколько выйдет «под ключ». У нас бюджет на этот год уже утвержден…»

«Вот столько. «Под ключ» выйдет с хорошей скидкой».

«Ой, много. А если дешевле?»

«Можно дешевле. Есть Saas!»

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

Финал. Третье отличие одновременно является самым большим заблуждением в разговоре о CRM-системах. А суть его в том, что отличий, как таковых, нет. Если помните, мы уже говорили, что это не программы плохие, плохо то, как их подбирают для решения определенных задач.

Да, с Saas придется повозиться, например, если вам нужно собрать некую не типовую печатную форму в CRM и отправить ее в 1С. Да, Saas часто не обеспечена всеми известными сервисами. Да, Saas — это риск потерять CRM-систему, если вы не оплатите следующий период использования. И да, Saas – это зависимость от вендора. 

Saas: дикие наборы типовых триггеров

Ранее я обещал вернуться к идее включить клиентов в анализ ключевых сущностей. Какие манипуляции с клиентами мы можем оптимизировать и отдать на откуп автоматического выполнения процессов? Какие клиентские процессы интересно было бы автоматизировать?

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

Ценность наших клиентов для нас — это их лояльность. Что такое лояльный клиент? Здесь каждый приведет несколько своих определений и будет прав. Маркетолог скажет что-то на своем языке акций, ассортимента и кампаний. Владелец бизнеса представит себе товарооборот с капитализацией. Аналитик, скорее всего, количество и периодичность заказов, откуда эти заказы «падают», как оплачиваются и кем вручаются счастливому клиенту.

Клиент заказал товар или услугу, оплатил онлайн или указал оплату при вручении, на складе есть то, что хочет клиент, — все. На этом клиент для нас уснул. И спать он будет до того момента, пока ему не вручат то, за что он отдаст свои деньги в рамках рекламной кампании и товарооборота.

Работа по дополнительным продажам может существенно повысить средний чек, а молниеносная реакция при работе с возражением даст возможность не только сохранить, но и преумножить лояльность клиента. Абсолютно так, только речь, что все эти мероприятия реализуются в рамках либо уже оформленного, либо находящегося в процессе оформления заказа. Да, и работа с лидами тоже.

Я часто наблюдал торговые площадки, сутью которых были:

• Офис на три комнаты, в лучшем случае;

• Склад в промышленной зоне, совмещенный с офисом, в худшем случае

• Контактный центр, традиционно, аутсорс.

Реалии малого и среднего бизнеса, от них не уйти.

Для таких компаний выбирается Saas-версия CRM-системы несмотря на то, что в штате банально не хватает сотрудников, которые могли бы там полноценно работать. Нужно ли говорить об Enterprise, если она кажется роскошью?

Основными смежниками CRM являются:

• CMS, в лучшем случае это печально знакомый, но вполне рабочий и годный 1C:Битрикс;

• 1С:УТ в паре с 1С:WMS, не потому что склад большой, а потому что контур 1С настроен выдавать типовые отчеты владельцам бизнеса.

Сразу после подселения CRM становится очевидно, что нетиповые процессы чаще парируются доработками на стороне смежных с CRM систем. Так проще и дешевле. А еще, накопленным опытом, кастомизация CMS и 1С кажутся более понятными решениями, нежели попытки приручить Saas.

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

• Либо найма сотрудников, которые будут работать в CRM руками;

• Либо обучения «чужих» сотрудников, например, сотрудников контактного центра, который подключен аутсорс;

• Либо прагматичного, но не сильно экзотического решения, которое будет способен поддерживать любой штатный айтишник.

Триггеры.
Прагматично? Да.
Сильно экзотично? Кажется, что нет.
Решение способен поддерживать любой айтишник? Конечно! Даже многие не айтишники способны поддерживать и создавать целые наборы триггеров.
Минусы?

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

Saas: а не запилить ли нам свой, кастомный сервис?

Все, что не запрещено, все можно.

Однако скупой платит дважды, не умный платит трижды, склонный к субъективным решениям — постоянно.

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

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

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

Представим себе ритейлера, который осуществляет торговую деятельность в рамках франшизы нескольких производителей. Юридически, это разные фирмы. Их несколько, и они охватывают всю Европу. Оказывается, в мире, в целом, использование агрегаторов является неплохим решением, которое позволяет осуществить быстрый старт бизнеса. В моей практике, у владельца бизнеса этого ритейлера агрегаторы доставки были излюбленным решением.

Но у нас Saas, который не имеет в поставке модуля интеграции с приглянувшимся агрегатором. Ни с одним из тех, которые нравятся владельцу. Развивать 1С:УТ не позволяют следующие моменты:

• 1С:УТ не обладает необходимым ресурсом на развитие и поддержку;

• CMS имеет болезненную, накопленную годами экспериментов структуру и учитывает все промахи тех, кто дорабатывал 1С:УТ.

Если развивать 1С:УТ, придется учитывать и в CMS это развитие. Если конкретнее, самая большая проблема была с оплатами агрегатора доставки. И дело не в технической реализуемости, а в отчетности, которая, в том, числе, была заточена под международные нормативы.

То есть наилучшим решением напрашивается развитие CRM, учитывая, что вендор отечественный, и он рядом. Помните, мы говорили про третье отличие, которого нет? Вместо доработки самой CRM-системы, было решено написать свой кастомный модуль. Он же  кастомный сервис.

Хочется отметить, что первоначальная версия этого модуля потребовала около шестисот часов с аналитикой, а также вагон нервов и находчивости при проведении защиты решения и ПСИ. Зато после того, как эта версия модуля была введена в промышленную эксплуатацию и показала себя в деле, пути назад уже не было. Решение настолько пришлось по нраву топам ритейлера, что позже с его помощью была реализована интеграция с другими доставками. Кроме того, на базе одной из реплик модуля были развернуты механики автоматической обработки заказов и клиентов, а также менеджер нетиповой отчетности.

Речь идет о небольших и о не человекоподобных роботах.

Enterprise, любовь и роботы: Бендер с планеты Шелезяка

Enterprise. Как же она великолепна в своей гибкости по сравнению с Saas! Это нечто с первого взгляда, что пройдет только тогда, когда закончится онбординг. «Коробка» терпит все. В этом ее колоссальное преимущество перед «облаком», и в этом же ее ахиллесова пята.

Я видел «коробки» CRM, которые можно было сравнить только со старой, дышащей последними вздохами 1С:Предприятие самой древней версии, которая приходит на ум. Ее не обновляют, потому что апгрейд будет стоить ровно столько, сколько стоила ее кастомизация и весь многолетний срок сопровождения. Никто из стейкхолдеров, авторов этого чудовища, уже не доступен для связи, — у многих новая работа и благополучные семьи. Эксперименты изменили систему до неузнаваемости, а в результате получился монстр («павук» — проектный жаргонизм, прим. автора), который можно смело называть SkyNet и в ужасе ожидать следующего пятничного деплоя.

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

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

Помните, мы говорили о зонах ответственности систем? Иногда жители зоопарка поглощают целые сегменты друг друга. Enterprise — хищник в руках умельца, не иначе.

Под роботов обычно пишется своя таблица настроек, в которой определяются объекты, условия и ограничения срабатывания. Также в этой таблице указываются действия, которые должен выполнить робот, чтобы добиться ожидаемого результата. Это все есть у Битрикс24, скажете вы. Есть, но кроме работы с лидами, клиентами и заказами, предел возможной функциональности робота, развернутого в Enterprise трудно представить.

Помните про третье отличие «коробки» от Saas? Тут стоит отметить, что Saas с развернутым кастомным модулем все же ограничена своей поставкой. То, чего в Saas нет, туда не прокинешь. Да, можно использовать кастомный модуль для реализации любых задумок и даже получится слегка сконфигурировать front-сегмент, но из «коробки» может получиться все, что нужно даже самому креативному логисту или шальному бухгалтеру.

Я уже рассказывал про обращения и документацию. Да, внедрение Enterprise стоит дороже, чем внедрение Saas. И если ее измучить импульсивной кастомизацией, она явно будет дорогой на этапе сопровождения. Однако, если вы имеете дело с Enterprise, то нет необходимости переносить не типовую для Saas функциональность на другие системы зоопарка. Иногда отказаться от доработки старушки 1C или CMS Magento гораздо лучше, чем выбирать между разработкой кастомных сервисов «облака» или наблюдения за ним, как за «священной коровой».

Если без операций никуда, то резать лучше Enterprise и точка. Чем крупнее бизнес, тем ближе вы к Enterprise. Не потому, что ваш бизнес крупный, а потому что такой бизнес чаще пользуется не типовыми процессами, которые требуют отражения в функциональности продуктивной версии CRM.

У крупного бизнеса я чаще встречал свои контактные центры. Вероятно, удача была на моей стороне, но то, что я видел, обладало явно высокой культурой клиентского сервиса. То есть у сотрудников и их руководителей был опыт, — то, чего не заменишь ни одним роботом. Эти люди точно знали, чего они хотят, где есть сегменты в которых целесообразно применение механик автоматизации и чего с системами лучше не делать, даже если за идеи по развитию платят премии.

У крупных ритейлеров чаще встречаются свои складские ресурсы и своя служба доставки. Да, они также пользуются аутсорсом, но отгружаются с хабов и терминалов. Да, они также выходят в сети и маркетплейсы, но реже экономят на кладовщиках и логистах. Они позволяют себе вкладываться в персонал, и не пытаются перекладывать ответственность своих систем на системы агрегаторов.

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

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

Заключение и выводы

Не бывает плохих версий CRM-систем. Бывает преобладание между субъективными и объективными решениями.

Нет отличий в перспективности кастомизации между версиями CRM-систем. Существуют разные подходы к автоматизации производственных процессов.

Нет существенных ограничений в функциональности между Saas- и Enterprise-версией CRM. Есть ритейл, который обладает стратегией автоматизации своих процессов, и есть его противоположность.

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