Почему CRM не работает?

Повсеместные успехи внедрения CRM уже привели к тому, что фраза в духе "Ваш звонок (письмо, мнение, вопрос...) очень важны для нас" превратилась в символ формального отношения к потребителям. Как же случилось, что чем больше компании концентрируются на "качественном" обслуживании своих клиентов, тем больше самими клиентами это воспринимается как способ отгородиться от них.
Причина столь же банальна, сколь и распространена. Сначала клиент сталкивается с какой-либо проблемой организации. Проблемы иногда бывают у кого угодно - идеальных компаний не существует. Потребители не капризные монстры - они с пониманием относятся к накладкам. Но только если не чувствуют, что таким образом проявляется политика компании по отношению к ним. И когда они пытаются разобраться с возникшей проблемой (а они, так или иначе, это делают), то тут и наступает момент истины. Чем больше компания верит, что ключ - в качественных коммуникациях с потребителями, тем меньше кто-либо помнит о том, что есть реальная проблема, которую нужно решать. Точнее, о том, что это нужно делать постоянно. Даже самые лучшие продавцы и сотрудники службы поддержки не могут улучшить ситуацию. На самом деле они только ухудшают ее. Это все равно, что снимать синдромы, позволяя развиться причине заболевания. Ведь запросы клиентов являются наиболее плодотворным способом улучшить бизнес. Конечно, если работать с ними, а не над тем, чтобы смягчить или скрывать их.
Покупатель говорит: "Хочу расплатиться кредиткой" и хороший продавец вежливо объясняет почему именно сейчас не получится этого сделать. Клиент платит наличными - вопрос закрыт. Никто и не посчитал сколько таких "удовлетворенных" покупателей не вернулось.
Покупатель хочет воспользоваться своей скидкой и хороший продавец очень корректно объясняет с какими именно условиями дисконтной программы не познакомился покупатель и почему он должен заплатить полную сумму. Возразить нечего - покупатель платит по полной и пытается забыть ситуацию. А заодно и владельца дисконтной программы. Но конфликта нет. Прецедентов может быть тысячи, но никто и не задумается о том, что с дисконтной программой что-то не то.
Клиент не нашел того, что искал, но хороший продавец продал ему "полноценную" замену. Продавец настолько хороший, что клиент даже не нашел возможности высказался о том, что не считает замену вполне адекватной. Просто принял для себя решение в следующий раз изменить процедуру покупки и не начинать с привычной торговой точки. Но конфликта нет, а продавец даже поощрен.
Таких примеров - бесконечно множество. Это не недоработки системы - это именно то, как система работает. И качественно внедренный CRM последовательно укрепляет такое положение вещей.
Это выглядит парадоксально: теоретически CRM может собирать всю необходимую информацию, на основании которой можно строить отчеты, использование которых могло бы существенно изменить ситуацию к лучшему. На практике этого не бывает за очень редкими исключениями. Причина проста: между "может" и "делает" - огромная пропасть. У компании обычно не хватает сил, чтобы полноценно реализовать базовые возможности подхода, не говоря о "дополнительных" возможностях.
Именно эта "дополнительность" - читай "необязательность" - делает CRM ориентированным на достижение локальных оптимумов. Уничтожая возможность оптимизации работы компании в целом. В итоге компания может терять лучших клиентов (т.е. деньги) при фантастических показателях работы с ними.
К счастью, ситуацию исправить не так уж сложно. Главное осознать, что компания работает как единый организм и невозможно выделить самые важные элементы. Не потому что "важно все", а потому что "самое важное" слишком сильно зависит от чего-то еще. Отношения с клиентами крайне важны, но обеспечить их эффективность невозможно, если рассматривать их изолировано. Любая связь в цепочке, связанной с запросом клиента имеет ровно такое же значение, как и непосредственная его обработка. И самый логичный способ обеспечить это - работать с ними точно также, как и с клиентскими запросами.
Рассмотрим это не упрощенном примере. Клиент делает заказ через call-центр. Его заказ требует допоставки от поставщика, комплектации с собственного склада и доставки клиенту.
Все участники пользуются одним и тем же программным обеспечением и единым call-центром. После принятия заказа происходят следующие шаги:
Бронируются нужные позиции на собственном складе (что является сокращенной формой заказа для внутренних операций) и автоматически формируется заказ на поставщика от имени склада. Заказанный поставщику товар находиться в той же брони, хотя его еще нет на складе.
Поставщик поставляет заказанный товар, который получает такой же статус как остальные забронированные товары, что автоматически ставит задачу на передачу укомплектованного заказа на доставку.
Выполняется доставка, которая закрывает данный заказ.
Таким образом, можно рассматривать весь процесс как цепочку с равнозначными звеньями: Заказчик - Call-центр - Склад - Поставщик - Склад - Доставка - Заказчик. Формально, цепочка замыкается в двух местах. Но реально - это однонаправленный процесс, в котором все участники выступают в двух разных качествах, и некоторые делают это дважды. Для любой связи участник слева это постановщик задачи, справа - исполнитель. Даже заказчик, замыкая цепочку, превращается в исполнителя. Он ДОЛЖЕН принять и оплатить свой заказ. Также, как при поставке товара склад ДОЛЖЕН принять его.
При грамотно спроектированных и отлаженных цепочках все просто и потому работает как часы. Собственно эффективность процессов при такой схеме и сводиться, прежде всего, к качеству проектирования и отладки цепочек. Идеальная цепочка построена так, что каждое ее звено имеет такую же производительность и надежность, что и другие в этой цепочке. При этом под звеном следует понимать не все задействованное структурное подразделение, а тот объем ресурсов, который выделен на поддержку именно этой цепочки.
Такой подход позволяет легко анализировать статистику для каждой отдельно цепочки, выявляя проблемные места. И гораздо проще бороться с ними, т.к. проблема не размазана по функциональной единице, а имеет четкую локализацию по ресурсам и по ситуации. В нашем примере, работа склада состоит из четырех разных активностей: прием заказа от Call-центра, заказ Поставщику, прием товара от Поставщика и передача полного заказа Доставке. Выполнение последнего действия (хотя оно самое сложное) может происходить блестяще, а вот с приемом от Поставщика иногда случаются накладки (например, Поставщик мог привезти в то время, в которое склад не работает из-за разных режимов работы). Но накладка на любом из шагов ведет к сбою в работе всей цепочки. К счастью, в рамках рассмотрения конкретной цепочки сразу видно на каком именно шаге возникла проблема.
Благодаря этому, XRM-подход так эффективен. Он позволяет пронизать организацию структурными связями, основанными на бизнес-процессах, а не на формальной иерархии. Это позволяет перейти от концентрации на локальных оптимумов к интегральной оптимизации. А это большая разница.