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

Конструктивный форум бухгалтеров Казахстана
Текущее время: 23-09-2017, 10:30

Часовой пояс: UTC + 3 часа




Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 6 ] 
Автор Сообщение
СообщениеДобавлено: 06-04-2016, 05:02 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
CRM. Часть 2. События и контактные лица.
(продолжение)

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

Зачем нужна фиксация событий взаимоотношений с клиентами в ПО CRM.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06-04-2016, 05:03 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
Контактные лица клиентов.
Следующий важный момент в CRM заключается в обязательном учете (записи) контактных лиц клиентов. Для бухгалтера бывает сложно понять, зачем это нужно. Ведь для выписки документов клиенту необходимы координаты только его руководителя и главного бухгалтера.
Однако для реальной работы менеджеров продаж нужны как минимум координаты других менеджеров продаж клиента. А также завскладов, вице-президентов, кадровиков, начальников охраны и т.д. Причем управляемость всей этой информацией, разумеется, повышается, если она не лежит неизвестно где в неизвестно каком виде, а записана в базе данных в ожидаемом месте для других наших менеджеров. Тогда и передача клиентов ушедшего менеджера другому менеджеру становится рядовым, легко реализуемым событием. Повышается перекрестный контроль со стороны других менеджеров над информацией о контактных лицах, ведь раньше ее никто не видел, кроме одного менеджера-«владельца».

Структура учета контактных лиц.
Структура информации о контактных лицах клиента может приблизительно выглядеть так (в самом простом варианте):
- контактное лицо (наименование),
- телефон сотовый (рабочий, личный),
- телефон рабочий,
- телефон домашний,
- емайл рабочий,
- емайл личный, и т.д.
Более сложные варианты учета информации контактных лиц позволяют создавать и учитывать виды произвольной информации – например, создать новый вид контактной информации «памятные даты», или «дни рождения», и заполнить их значения, и т.д. Также, при необходимости еще более глубокой детализации учета контактных лиц клиента поле «контактное лицо» становится типом «сотрудник (физическое лицо)», для учета всех данных физлица – ИИН, РНН, даты рождения и других параметров, чтобы не создавать дублирующие реквизиты. Таким образом, во избежание дублирования, и чтобы не создавать справочник «Физические лица (в смысле не наши работники)» приходится вести глубокий учет контактных лиц клиента в нашем справочнике «Сотрудники». Одним из способов не брать этих «прочих контактных лиц» в начисление и расчет зарплаты является неприсвоение им «вида работника» (постоянный, временный и т.д.), даты приема на работу и обнуление их оклада. Однако самым лучшим решением хранения разных видов и типов физлиц в одной таблице (справочнике), похоже, является предлагаемый автором в более ранних статьях единый справочник физических, юридических и иных лиц - «Лица».


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06-04-2016, 05:03 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
Основные подходы к структуре базы данных для отражения событий.
Поскольку отражение событий в учете законодательно не регламентировано, то здесь все еще находится в процессе формирования. Тем забавней наблюдать картинки столкновения мнений, когда люди с упорством, достойным лучшего применения, доказывают, что именно вот так вот - это «правильно», в по-иному – нет. Просто раньше это «вот так» они где-то видели на другом месте, на другой работе, в другой программе и т.д. Но, если бы они увидели раньше в первый раз не «вот так», а «вот эдак», то считали бы правильным именно «вот эдак».
На самом деле похоже, есть всего 2 основных варианта отражения в учете событий, совсем разных по смыслу. Причем словечко-паразит «правильно», укоренившееся в казахстанском учете, здесь абсолютно неприменимо.

Вариант 1 – стройный и логичный, однако тяжелый, сложный и трудоемкий в практической реализации.
Если коротко, то этот вариант заключается в триаде «Задачи – Расписания - События». Поясним подробнее.
«Задачи» - это таблица (или справочник, регистр) для отражения оперативных, текущих, перспективных, стратегических и т.п. задач. «Задачи» менеджер продаж может намечать себе сам, либо менеджеру может ставить задачи начальник отдела. Либо более высокое руководство может ставить «задачи» начальникам отделов, а они в свою очередь могут переназначать эти «задачи» рядовым менеджерам продаж. Словом, вариантов составления и возникновения «задач» много. Выглядят «задачи» примерно так:
«Задача 5. Позвонить клиенту ТОО «Альфа» и выяснить, когда оплатят долг».
«Задача 56. Увеличить продажи на 10 % за 2016 год».
«Задача 321. Менеджерам изучить теорию мотивации», и т.д.
Подробный состав предполагаемых полей (реквизитов) таблицы «Задачи» здесь приводить мы не будем. Желающие легко могут набросать их сами.
Таблица «Расписания» - это следующая по иерархии таблица за «Задачами». Все работники (менеджеры продаж, руководители отделов, и более высокое руководство) могут составлять себе «расписания» на день, неделю, месяц, квартал, год и т.д. Либо «расписания» могут спускаться сверху (хотя бы частично). «Расписания» состоят из задач, например, таких:
«Расписание менеджера на 29.12.2015 -
Задача 5 – 10-00.
Задача 34 – в течение дня.
Задача 67. – в течение дня» и т.д.
Подробный состав предполагаемых полей (реквизитов) таблицы «Расписания» здесь приводить мы также не будем. Также опускаем описание задачи слияния расписаний различных периодов на текущий день, неделю, задачу обнаружения слишком сильной загруженности задачами, задачу перенесения задач, выставление приоритетов задач и т. д. и т.п.
И последнее звено этой триады – «События». Событие может состоять из пункта «расписания», либо «задачи», не включенной в расписание, но возникшей по ходу дня, либо быть спонтанным, незапланированным, возникшим по ходу жизни.
То есть «события» могут возникать в соответствии с намеченными расписаниями, либо это могут быть внеплановые «события». Также «расписания» могут не выполняться, или не успевать выполняться. «Задачи» могут оказаться на практике значительно сложнее, чем ранее планировалось при их включении в «расписание», могут требовать значительно больше времени на выполнение. Также «задачи» могут порождать дочерние (связанные) подзадачи, могут вскрываться дополнительные пункты, требующие более раннего выполнения, согласования и т.д. Одним словом, красивое и логичное теоретическое построение на практике требует колоссальных ежедневных усилий, причем от всех работников, для своей реализации, обработки, постоянного перепланирования и поддержания внутреннего порядка. И поэтому, скорее всего, этот вариант с триадой «Задачи-Расписания-События» на практике не будет реально работать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06-04-2016, 05:04 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
Вариант 2 – нелогичный, зато короткий и легкий, и на практике наиболее легко реализуемый.
Более легким и удобным вариантом учета событий является таблица (или справочник, регистр) вида «Ежедневный журнал работы с клиентами». Рассмотрим примерный состав его полей (реквизитов) подробнее.
- Дата начала действия – если событие одномоментное, то здесь записана дата, когда оно произошло
- Дата окончания действия – если событие длящееся, то здесь записана дата, когда оно закончилось. Это очень удобно, становится возможным фиксировать интервальные многодневные события, а не только кратковременные. Становятся видны еще длящиеся (еще незавершенные) события (с пустой датой окончания).
- Последнее изменение – в случае многократной записи информации о данном событии в этом поле записано, кто и когда в последний раз вносил (корректировал) информацию, например, «31.10.2015\Ахметов А.К.». Это позволяет без трудоемкого обращения к логам изменений таблиц (справочников, регистров) быстро понять, кто последний изменял информацию, где искать концы.
- Вид учетных данных – может иметь такие разновидности, как, например, «факт (учет)», «предварительный заказ», «потенциальный заказ», «план», «отчет», «заявка» и другие. Благодаря этому реквизиту-разделителю информации становится возможным учитывать, например, плановые будущие события (без заведения отдельных таблиц «Задачи» и «Расписания») и в дальнейшем учитывать их выполнение или невыполнение. Можно учитывать предзаказы, заявки и другую разнокалиберную плановую информацию, без заведения отдельных документов вида «план», «предзаказ», «заявка», что очень удобно. Список видов учетных данных расширяемый со стороны пользователя.
- Вид ежедневной работы – может иметь такие разновидности, как, например, «выдан прайс», «выставлен счет на оплату», «звонок-напоминание», «знакомство» и т.д. Список видов ежедневной работы расширяем со стороны пользователя.
- Документ – если событие ежедневной работы связано с конкретным документом.
- Лицо откуда – от какого лица исходит событие – от клиента, поставщика, посредника и т.д.
- Лицо куда – куда направлено событие, к какому другому внешнему лицу – клиенту, поставщику, посреднику и т.д.
- Лицо для кого – заполняется, если данное событие с лицом откуда или куда, но происходит в интересах какого-либо третьего клиента, для кого-то, для его заказа и т.д.
- Лицо с кем – здесь обычно записывается менеджер, работник, который работает с данным событием.
- Контактные данные лица – с каким конкретно лицом происходит контактирование при этом событии, например, менеджер Жакенов из ТОО «Бейбарыс».
- Договор, субдоговор, состав договора – договорная информация, в связи с которой происходит данное событие.
- Каталог актива, актив, прочие данные актива, субактив – информация об активе \ активах, в связи с которым происходит данное событие.
- Подробности 1, подробности 2 – если для отражения информации о событии недостает полей (реквизитов), то для детализации информации используются эти поля.
- Примечание.
Таким образом, предлагаемая форма «Ежедневного журнала работы с клиентами» проста, понятна, содержит в себе все необходимые графы, совмещает плановую и фактическую информацию, легка в управлении, анализе, поддержке и заполнении. Можно с уверенностью прогнозировать, что именно такая или подобная ей форма в ближайшие годы станет основной в работе с клиентами в ПО CRM. Переход к «ежедневному журналу» облегчается тем, что он похож на обычный регистрационный бумажный журнал, уже давно применяемый для учета различных фактов в разных сферах учета.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06-04-2016, 05:05 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
Прочие данные клиентов в ПП CRM.
С течением времени система ПП CRM развивается. Возникают факты, информация и знания, которые не укладываются в принятую схему данных. Что делать в этом случае? При этом на первый взгляд эти новые факты, знания, информация могут казаться очень даже важными, заинтересованные лица могут настойчиво считать эту новую информацию критической и обязательной не только к внесению в базу, а даже к показу на главных лицевых страницах.
По мнению автора, в таких случаях нужно попробовать завести данную новую информацию как «прочие данные клиента» и в течение некоторого времени помониторить ее накопление, использование и статистику. И тогда станет понятно, нужно ли выводить данную новую информацию в отдельное поле (реквизит) таблицы (справочника, регистра) отдельно, либо же ограничиться ее эпизодической записью в «прочие данные».
Пример. При работе по внедрению ПП CRM у менеджеров возникла идея, подсмотренная где-то у других организаций, записывать в базу «памятные даты фирмы-клиента», «памятные даты контактного лица», «дни рождения контактных лиц», «знаменательные даты», «хобби контактного лица», и т.д. Казалось, что это все очень важно, очень нужно, что это ключевые особенности клиентской информации, без которых совершенно невозможно обойтись. Тем не менее было принято решение пока посмотреть нужность этой информации и записывать ее временно как «прочую информацию клиента».
По результатам полугода работы по статистике базы данных вида «прочей информации = памятные даты» было всего пару строк, да и те только, которые и были заведены изначально как демонстрационные для показа учета этой возможности. Таким образом, реальная потребность в учете этой информации была приблизительно равна нулю. А что было бы, если бы сразу же не восприняли бы эту идею критически и понаделали бы в базе данных ненужных полей, да выпятили бы эту информацию прямо на лицевые страницы?
Приблизительная структура таблицы (справочника, регистра) для учета «прочей клиентской информации» приведена ниже.
- Дата начала действия. Если «прочая информация» не интервальная, то в этом поле записана дата занесения информации.
- Дата окончания действия. Если «прочая информация» интервальная (длящаяся) то в этом поле записана дата окончания интервала события, информации.
- Вид прочих данных. Выбирается из таблицы «Виды прочих данных приложения». Может иметь такие значения, например, как «памятная дата», «хобби», «цвет», «размер», «марка», «фасон», «как добраться», «образование», «специальность», «работа», «рекомендация», «аттестация». Из образцов данных видно, что таблица «видов прочих данных приложения» предназначена для учета прочих данных лиц, активов, и других объектов приложения.
- Значение. Значение прочих данных, может выглядеть как «красный», «45», «12.10.2015», «высшее», «аттестован 05.10.2015» и т.д.
- Примечание.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06-04-2016, 05:07 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 636
Откуда: Астана
Сегментация доступности данных клиентов в ПП CRM.
В отличие от бухгалтерской информации, клиентские данные нужно сегментировать специальным образом, то есть настраивать их доступность.
Например, данные таблицы событий желательно держать доступными для редактирования в течение 10-30 дней. Потом, по истечении этого «срока доступности», их нужно автоматически делать закрытыми (недоступными для редактирования), независимо от общей даты запрета редактирования всей базы данных, вообще для всех пользователей, чтобы менеджеры и их начальники отделов не могли редактировать события и «подгонять» их под завершение месяца.
Отдельный правила касаются клиентов. При заведении нового клиента его поле «менеджер» пустое, и любой менеджер может присвоить этого клиента себе, то есть заполнить это поле собою. Это же касается и какого-либо старого клиента, но с очищенным, пустым полем «менеджер».
Однако после того, как клиенту назначен менеджер, данные этого клиента может редактировать только его менеджер, либо специальный сотрудник (назовем его «арбитр»), который может редактировать данные всех клиентов, независимо от их принадлежности или нет какому-нибудь менеджеру. Остальные менеджеры могут видеть и читать данные этого клиента (адрес, телефон, данные продаж), но не могут их менять, пока данный клиент закреплен за другим менеджером. Если этого не сделать, то менеджеры будут постоянно «переписывать» чужих клиентов на себя, и масса их усилий будет уходить на «охрану» своих клиентов от «посягательств» других менеджеров. Таким образом, менять поле «менеджер» для «рабочего» клиента может только сам менеджер либо «арбитр».
Как видно, политики доступности данных CRM существенно отличаются от обычного порядка запрета и разрешения редактирования документов в бухгалтерском учете.

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


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

Дата последнего редактирования – 5 января 2016 г.

Статья была впервые опубликована в журнале "Бухгалтер+Компьютер".


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 6 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения

Найти:
Перейти:  
РейСРёРЅРі@Mail.ru
Создать форум

cron
Powered by Forumenko © 2006–2014
Русская поддержка phpBB