Система CRM — (сокр. от англ. Customer Relationship Management — управление взаимодействием с клиентами) — корпоративная информационная система, предназначенная для улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с клиентами, установления и улучшения бизнес-процедур на основе сохранённой информации и последующей оценке их эффективности (цитата с сайта Википедии, поиск на означенном сайте по слову «CRM» выдаст читателю краткое и понятное введение в проблему).

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

По сути, распространенные на рынке CRM-программы направлены на поддержку sales force automation — информационное обеспечение и автоматизацию продаж. Более того, наблюдавшаяся в последнее время некоторая дискредитация самого термина CRM (вследствие появления на Западе огромного количества программ для поддержки CRM), привела к появлению видоизмененного термина Customer Management, или Управление Клиентами. Собственно, ничего плохого в этом нет, но налицо явное смещение акцентов в сторону систематического манипулирования потребителем. Будем надеяться, что все это — во благо покупателя товаров и услуг.

Общие вопросы выбора и внедрения CRM

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

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

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

Три типа CRM

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

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

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

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

Структура учетной системы

• хранилище данных
• сервер СУБД
• система обмена данными между подразделениями
• система создания и хранения архивных копий данных
• ядро системы
• подсистема записи новых и измененных документов
• редактор настроек бизнес-логики системы
• функционал ведения справочников, в том числе
• база клиентов
• план счетов
• товарная номенклатура
• система защиты от несанкционированного доступа
• подсистема шифрования данных и паролей
• система настройки интерфейсов пользователя в зависимости от выданных прав доступа
• интерфейс администратора безопасности
• отчетная система
• печать документов
• редактор печатных форм
• печать реестров документов
• сложные расчеты (сложнее, чем примитивный список документов или оборотная ведомость)
• анализ накопленных данных (возможно, включая планирование)
• дополнительные функции
• электронная почта и мгновенные сообщения
• система управления поручениями
• кадровый и табельный учет

Функции, вынесенные в разряд дополнительных, можно без труда реализовать с помощью бесплатного, общеупотребительного софта. Но иметь их в системе есть смысл. Как только мы получаем возможность взглянуть на переписку и учет в разрезе справочника контрагентов, то бишь клиентов — мы получаем CRM. Бесплатно.

Картинка из жизни. Интересно это будет тем, кто занимается оперативным учетом. (А чем еще в сегодняшнем бизнесе стоит заниматься? Уж не моделированием ситуаций, наверное).

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

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

Каковы могут быть варианты решения?

Самый простой — протоколировать справочники цен. Плюс его в меньшем объеме данных — дополнительная информация по каждому документу не хранится. Минус — в сложности извлечения данных (в итоге требуется понять, какая скидка или наценка была в реальности сделана при каждой продаже, и свести эти данные для оценки эффективности работы сотрудников и подразделений).

Альтернативный вариант — записывать базовые цены в документ. Плюс в скорости получения информации о предоставленной скидке или установленной наценке. Минус неочевиден. На самом деле, документ может быть отредактирован, переоформлен, а базовые цены на момент редактирования — поменяться. Что хранить? Это вопрос.

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

Хуже того — по-хорошему надо бы реализовать протоколирование и того, и другого.

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

Это если нет концепции реализации версионности записей.

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

Я в задумчивости.

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

Открытость

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

Масштабируемость

Это требование понять легко. Оно задает направление исследований — а как поведет себя система при работе с базой, большей в пятьдесят раз? А с двадцатью филиалами вместо трех? А с сотней пользователей вместо пятнадцати? Ваш поставщик может показать такие инсталляции?

Скорость

Запомните единственный критерий оценки скорости работы информационной системы. Время отклика — не более секунды. Лучше — меньше. Это относится ко всем операциям в интерфейсе. Желательно в такие же временные рамки печатать документы. Однако, если вы хотите так же быстро считать отчеты, придется копать в сторону OLAP и искать много-много вечнозеленых президентов. Или считать сложные отчеты часами (почему бы и нет? компьютеру все равно работать)

Надежность

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

Адекватность

Система учета и управления должна быть адекватна бизнесу. Если вы отпускаете со склада две партии огнетушителей в неделю, система вам не нужна вообще. Обойдетесь бумажными бланками. Но мы не о таком. Если бизнес перестраивается, а система не успевает — она неадекватна. Но вопрос, реальна ли замена, и за какие деньги… Может, не стоит?

Впишите сами

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

Вносите дополнения!

Иногда эти требования приводят к параличу работы соответствующих отделов торговых компаний.

Давным-давно в одной далекой галактике потребовали вносить в счета-фактуры номера ГТД (таможенных деклараций то бишь). Хорошо, если система учета позволяла или даже предусматривала партионный учет. Еще лучше, если вы его вели, потому что в реальной практике мало кому все это было нужно. И мало какая доступная мелкому бизнесу система учета позволяла учесть товары по партиям в заранее неизвестных разрезах.

Как-то справились.

Нынешнее благое начинание предусматривает отправлять контрагенту счет-фактуру на аванс выданный. Так называется, видите ли, обыкновенная предоплата за товар… но!

В платежных документах вы никогда не найдете точного указания, за какой товар идет оплата. Но это полбеды. Можно вычислить сумму переплаты по договору (ваша система учета позволяет вести учет с одним юрлицом по нескольким договорам?) и напечатать счет-фактуру. Кстати, ваша система учета рассматривает счет-фактуру как отдельный документ, или как особый бланк печати документов определенного вида? (Вопрос не то чтобы такой уж концептуальный, но непростой).

А если потом какие-либо документы будут изменены? Или окажется, что прошла еще одна оплата на счет вашего филиала вчерашним числом и так далее и тому подобное?

Менять выданные документы?