Конструктивный форум бухгалтеров Казахстана

CRM. Часть 1. Клиенты и договора.

Курсаков С.А.

CRM (учет взаимоотношений с клиентами) – зачем это нужно.
Каждое более-менее успешное предприятие, работающее в рыночных условиях, со временем начинает понимать, что прибыль генерируется прежде всего сделками с клиентами, а значит, и на учет взаимоотношений с клиентами (обозначается термином CRM) нужно обратить самое пристальное внимание.
Как правило, учет клиентов в CRM начинается самым примитивным способом - с файлов Excel, Word, PDF, с различных таблиц, графиков, расчетов, электронных писем, логов мессенджеров, и других персонализированных источников информации. Все это хранится в компьютере менеджера, в произвольной личной форме, удобной и понятной только ему, анализируется тоже только им, и сложно и/или недоступно для остальных работников предприятия. В том числе и руководство предприятия лишено возможности понять внутренние процессы работы с клиентом, ход движения конкретной сделки/сделок, и чтобы получить какую-либо оперативную информацию, вынуждено «в ручном режиме» требовать ее каждый раз у конкретного менеджера.

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

Программные продукты CRM (ПП CRM).
Исследуя вопросы CRM, нельзя писать о них в каком-то абстрактном, совершенно общем плане, практически не держа в уме какой-либо конкретный программный продукт или группу программных продуктов. Вопрос только в том, направляет ли автор статьи ваше внимание к этому, и только к этому продукту (возможно, с целью его последующей продажи). Либо же автор старается подняться над специализированными вопросами конкретного продукта и конкретных «кнопочек» и «формочек» в нем, и желает сделать так, чтобы материал был интересен всем, в том числе и тем, кто не собирается и/или не покупает данный подразумеваемый программный продукт. Данная статья написана именно с позиций второго подхода и не преследует целей рекламы каких-либо конкретных ПП CRM.
Программные продукты CRM бывают нескольких основных типов с позиций их практического использования.
Первая, довольно большая группа – это программы CRM, функционирующие в отрыве от бухгалтерских программ, то есть «совершенно независимо от бухгалтерии». Зачем так нужно – это когда клиенты, операции, сделки не нуждаются в отражении в бухгалтерии (в разрезе каждого клиента). Это, например, розничные клиенты - покупатели супер- и гипермаркетов, или физические лица - клиенты банков. Как правило, в этом случае клиентам не нужна выдача счетов-фактур, не нужно вести в бухгалтерской базе учет операций отдельно по каждому клиенту. ПП CRM выполняет функции учета этих лиц (без наименования, по номеру дисконтной карты), рассылки им рекламы по почте, анализа продаж продуктов и услуг, сбора больших данных, инструмента проведения акций, и т.д.
Вторая группа ПП CRM, тоже довольно большая – те, что так или иначе взаимодействуют с бухгалтерией. Это либо внешние, отдельные от бухгалтерии ПП CRM, с каким-либо механизмом обмена и взаимодействия с бухгалтерией. Либо это ПП CRM, прямо и непосредственно встроенные «в бухгалтерию». Эти ПП CRM применяются в предприятиях, ведущих оптово-розничные продажи, когда операции всех клиенты ведутся и в бухгалтерии тоже, нужна выписка счетов на оплату, счетов-фактур, учет задолженности, разноска оплат и т.д.
Взаимодействие с бухгалтерией критически важно для второй группы ПП CRM. Нужно оперативно, буквально в течение дня, видеть оплаты клиента или поставщику, нужно быстро проводить акты сверки, и это зачастую быстро меняется в течение дня и совершенно нет времени на многочисленные утомительные синхронизации. Нет времени на тяжелые и утомительные «обмены между базами», во время которых невозможна работа в обеих контактирующих между собой базах. Нет времени на «разгребание» разнообразных коллизий и нестыковок, обнаруживающихся в процессе обмена. Полноценной работы трудно добиться без бухучета, в чисто «менеджерской», «торговой» программе, как бы «отдельной от бухгалтерии».
На взгляд автора, вторая группа ПП CRM гораздо полезнее, удобнее и практичнее. А уж если возможности учета клиентов встроены прямо в бухгалтерию без излишних трудоемких обменов между различными программами – этому вообще просто цены нет. К сожалению, на текущий момент возможности CRM в стыке с бухгалтерией в Республике Казахстан представляют собой скорее исключение, чем правило. Ежедневное одновременное использование учета клиентов CRM и бухгалтерского учета является скорее невиданной диковиной, чем постоянной практикой, и это очень редкое явление в Республике Казахстан.

«Клиенты» – основные объекты учета ПП CRM.
Под «клиентом» подразумевается покупатель, ответственность за работу с которым несет конкретный менеджер продаж нашей фирмы.
Первая и основная ошибка в области CRM – это попытка отделить «клиентов» (покупателей) от сущности «контрагенты», создавая искусственную фантомную сущность «клиенты» («покупатели»), которой на самом деле нет. Это происходит оттого, что работник ИТ («автоматизатор»), внимательно выслушивает работника продаж («менеджера»), потом ошибочно предполагает, что «менеджер» является экспертом в своей области, и выделяет в его словах категорию-сущность «клиент». И потом создает отдельный справочник «Клиенты», а далее начинаются проблемы.
Синхронизация этого нового справочника «Клиенты» с «Контрагентами» представляет собой постоянную проблему и головную боль. Далее, к тому же «клиент» может иногда временно выступать в других ролях – «заказчик», например, и что с этим делать? А затем возникают и следующие роли (о которых наш некомпетентный «эксперт» менеджер продаж умолчал или забыл) – «поставщик», «госорган», «посредник», «перевозчик», и так до бесконечности, и что же, на каждую роль создавать отдельную сущность-справочник с постоянной синхронизацией? Конечно же, нет.
Наилучшим решением, по мнению автора, будет отражение «Клиентов» прямо в справочнике «Контрагенты» (или «Лица») через подчиненные таблицы «Клиентская информация», без заведения отдельного справочника «Клиенты». В этом случае «клиент» будет преобладающей «ролью контрагента» (значение реквизита «Роль» типа «справочник»). Тогда и «поставщик» будет преобладающей ролью, и «перевозчик», и любые другие роли, далее возникающие по ходу жизни, так как список ролей расширяемый. Подробнее обо всем этом см. предыдущую статью автора «Лица – структура и детализация», где «Лица» можно считать синонимом «Контрагенты».

«Договора» (сделки, контракты, спецификации, приложения, заказы и т.д.) – тоже основные объекты ПП CRM.
Второй самой распространенной ошибкой «автоматизатора», излишне понадеявшегося на компетентность «эксперта-менеджера продаж», является необоснованное раздробление единой сущности «договор» на различные фантомные псевдосущности, например - «сделка», «контракт», «спецификация», «приложение», «торговое соглашение», «заказ» и т.д.
По мнению автора, все это просто разные «роли договора» (понимаемого в традиционном бухгалтерском смысле). И оперировать со всеми этими ролями договора следует по единым правилам. Но, если неосмотрительно поверить «эксперту- менеджеру продаж», и понаделать в программе всю эту кучу объектов как отдельные сущности, то далее можно столкнуться ровно с теми же проблемами, которые описаны выше (см. ситуацию с раздроблением единой сущности «контрагенты» / «лица» на фантомные псевдосущности «клиенты», «поставщики» и т.д.).
На самом деле, «сделка» – это тот же самый договор на уровне предварительного обсуждения и оформления.
«Контракт» – это уже подписанный договор.
«Спецификация» – перечень ТМЦ, поставляемых в данной поставке. Применяется тогда, когда при заключении рамочного контракта невозможно предвидеть конкретный перечень и количество ТМЦ, которые будут впоследствии поставлены.
«Приложение» – то же самое, что и спецификация.
«Заказом» обычно называют договор с покупателем, иногда на выполнение работ, услуг совместно с поставкой ТМЦ.
И таких ролей договора может быть довольно много, и лучше список этих ролей оставить открытым для добавления (только аккуратного) новых ролей договора на уровне пользователя. Подробнее об этом см. предыдущую статью автора «Структура договоров (сделок, контрактов), их учет в программах».
Таким образом, сведение всех этих «загадочных» терминов просто к разным «ролям договора» устраняет путаницу, делает ситуацию вокруг CRM понятной большинству бухгалтеров. Все эти «загадки» – это просто договора на разных стадиях и условиях их оформления, существования, закрытия. Стоит только рядовым бухгалтерам понять эту простую истину, как сразу в области CRM для них не останется ничего такого загадочного и непонятного, что якобы требует какого-либо отдельного от бухгалтерии учета и/или какой-либо отдельной от бухгалтерии программы.
Но и это еще не все. Иногда еще настойчиво продвигают идею раздробления «заказов» на - «потенциальные заказы», «предварительные заказы», «заказы в работе», «заявки», «планы» и т.д. Опять же, если понаделать на каждый вид заказа эти различные сущности – документы или справочники, то впоследствии будет немало проблем с их синхронизацией. На взгляд автора, эти псевдосущности фантомные, и это все просто «стадии договора/заказа/документа», понимаемого как реквизит «Стадии» типа справочник «Стадии документа/заказа/договора».

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

Единая цепочка движения товара – поставщик, наша фирма и клиент.
Еще одна серьезная ошибка «автоматизаторов» и «экспертов продаж» - непонимание сквозного комплексного характера всех взаимоотношений на предприятии. Учет взаимоотношений только с клиентами (CRM) имеет мало смысла и почти никакой пользы, если он выполняется без взаимосвязи заказов от клиентов с приложениями и спецификациями для поставщиков (SCM), с планами закупок у поставщиков. Учет в ПП CRM только клиентов малопродуктивен и имеет смысл только там, где поставляемый нашей фирмой продукт обычно неограничен и/или не стоит задача взаимосвязи клиентских заказов с планами закупок у поставщиков (клиенты банков, клиенты розничных супер- и гипермаркетов). Однако такая ситуация «неограниченного предложения» бывает редко.

Особенности поведения различных групп лиц на предприятии.
На предприятии при внедрении готового ПП CRM или при его создании с нуля обычно существует несколько групп пользователей, интересы и поведение которых следует учитывать.
Первая группа – первый руководитель / руководители и главный бухгалтер. Без твердой и постоянной поддержки хотя бы одного из них проект внедрения ПП CRM заведомо обречен на неудачу. Почему – изложено ниже.
Группа заместителей главного бухгалтера и рядовых бухгалтеров может испытывать определенные неудобства из-за внедрения новой системы ПП CRM. Неудачно спроектированные системы ПП CRM могут требовать дублирования ввода договоров, оплат или постоянных взаимообменов данными (если ПП CRM реализована «отдельно от бухгалтерии»). Естественно, увеличение объема работы при том же размере оплаты труда никому не добавляет энтузиазма.
Следующая группа – это менеджеры продаж. Как показывает опыт, они относятся к внедрению ПП CRM как минимум настороженно. Если раньше, до ПП CRM, все данные по клиентам находились в виде разномастных файлов в единоличном распоряжении менеджера продаж, то теперь все они консолидируются, выносятся на свет божий, и становятся видны многие ошибки, вылезают застарелые проблемы, выявляются недоработки и т.д. Конечно, все это вызывает неприязнь к новой системе, ведь раньше вроде «все было хорошо». Дополнительно, с началом перехода на ПП CRM менеджеры продаж часто испытывают неуверенность в сохранении своих рабочих мест, ведь обычно любая автоматизация вызывает их сокращение.
Впрочем, обычно настроение менеджеров продаж со временем меняется. Они обнаруживают новые возможности, появившиеся у них с появлением нового ПП CRM. Например, они могут видеть клиентов другого менеджера, при увольнении другого менеджера вправе рассчитывать на его «осиротевших» клиентов, делать поиск потенциальных новых клиентов по базе куда-то пропавших «ничьих» или «разовых» клиентов, могут оставить на время отпуска своих клиентов менеджеру на подмену, и т.д.
Еще одна группа – менеджеры закупок. Вначале автоматизации они пребывают в благодушной уверенности, что их то это все не затронет. Однако, рано или поздно становится ясно, что без связки «клиенты – договоры с клиентами – наша фирма – поставщики – договоры с поставщиками» автоматизация только клиентов мало что дает. И тогда менеджеры закупок могут присоединиться к хору недовольных новой системой, ведь вся их доселе скрытая кухня тоже может оказаться на виду. Обычно первым шагом новой публичности становится «План закупок», который теперь виден в программе всем (естественно, имеющим на то права). А ведь ранее «план закупок» был чуть ли не сверхсекретной информацией, предоставляемой по особому требованию и то далеко не всем. Естественно, это влияло отрицательно на оптимизацию закупок и товарных запасов.
Группа отдельных работников с особыми полномочиями – кадровик, юрист, и т.д. – могут быть как сторонниками новой системы ПП CRM, так и ее противниками. Юрист может испытывать дискомфорт из-за «новой публичности» договоров (сделок, контрактов), которые ранее были скрыты на компьютере юриста и доступны только с его ведома.
Группа складских работников также может испытывать дискомфорт из-за усложнившихся требований к оформлению документов отгрузки. Если раньше в центр отношений с покупателями был поставлен «счет на оплату» как синоним «сделки», что не совсем правильно, то теперь «сделка» (контракт) приравнена к «договору», и нужно во всех документах это адекватным образом обозначать.

Особенности поведения внедренцев ПП CRM.
Если подходить к внедрению ПП CRM ответственно, то зачастую оно может затягиваться даже на несколько лет, несмотря на уверения поставщиков ПП о быстром и легком «блицкриге» за 2-3 месяца.
Причины такого затягивания изложены выше – сюрпризы с обнаружением критической важности работы единой цепочки «клиент – наша фирма - поставщик», неверно понятые сущности в самом ПП CRM, деструктивное поведение основных групп пользователей, непонимание единства бухгалтерской и торговой информации, выматывающие ежедневные синхронизации (если ПП CRM реализован «отдельно от бухгалтерии»), и т.д. И в большинстве случаев, а особенно когда ПП CRM реализован и приобретен в формате «отдельно от бухгалтерии», он превращается как бы в справочную базу клиентов, хоть раз работавших с нашей фирмой, используемую в основном для «спамовых» рассылок рекламных предложений, писем и акций клиентам, без реальной связи с ежедневно заключаемыми договорами, с динамкой оплат, отгрузок и планов закупок.
Также до сих пор существует ошибочное мнение, что якобы ПП CRM нужны только крупному и среднему бизнесу, а малый бизнес в силу своей незначительности якобы совсем в CRM не нуждается. Это совсем не так. Для малого и микробизнеса влияние грамотного управления клиентами значительно больше, чем для средних и больших гигантов. Как правило, «гигантам» ничего особенного не будет даже при большой потере 5-10 % клиентов, чего нельзя сказать о малом и микробизнесе. Для него каждый клиент и важен, и нужен. В малом бизнесе нельзя залить проблему работы с клиентами деньгами, просто наняв новых работников – это будет нерентабельно. Для малого бизнеса нужен именно ПП CRM, который будет современным, легким, простым, недорогим и комплексным. К сожалению, пока на горизонте такого предложения не видно. Продавцы ПО, услышал слово «CRM», почему-то воображают себе исключительно больших и денежных покупателей с тысячами клиентов, и сообразно этому ставят продажные цены на ПО. А уж если от ПО требуется комплексная связь CRM с планами закупок, то ценник становится просто непомерным, на уровне возможностей корпораций, имеющих отдельное офисное здание минимум в несколько этажей. А вот ПП CRM для МСБ ценой в 100 долларов – нету.

(продолжение следует)


Курсаков С.А.

Дата последнего редактирования – 6 декабря 2015 г.