Российские CRM системы

Федоров А.А.

Во-первых, сразу хочу заметить, что я не являюсь работником какой-либо из представленных ниже компаний и отношусь скорее к группе подготовленных пользователей, имеющих опыт работы с компьютером (в том числе опыт программирования на Assembler, Pascal {Delphi}, C++ {C++ Builder}, Perl, PHP и т.д.) более 10 лет. То, что будет идти дальше, это исключительно мое собственное мнение, возможно не всегда верное (но я об этом не знаю ;-). Посему, всячески приветствуются дополнения и поправки к данному тексту. Цель документа - предостеречь российских законопослушных компаний от ошибок.

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

Интерфейс

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

Пожалуй, пятерку за реализацию интерфейса я бы не поставил никому (для сомневающихся, загляните на сайт http://hsi.psychology.ru/, там можно почерпнуть немало полезной информации). Самое удивительное, что все программы разрабатывались с помощью визуальных средств разработки, посему здесь-то, казалось бы, сложностей быть не должно. Это же не ковыряние с MFC.

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

Клиент коммуникатор

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

Интересен подход к заполнению справочников. Так, например, чтобы в справочнике физических лиц заполнить поле пол, необходимо нажать на соответствующую кнопочку и из появившейся в новой форме таблицы выбрать два пункта: "Мужской" или "Женский". Видимо разработчики предполагали, что может появиться "Средний" или ещё какой другой, поэтому решили подстраховать себя для поддержания масштабируемости. На мой взгляд, логичнее было бы использовать традиционный компонент DBLookupComboBox. Оно как-то проще с ним работать. (Как заметил представитель разработчика, в новой версии этот недочет учтен, однако последнюю версию мне посмотреть не довелось). То же самое замечание остается, скажем, и при связывании "Контрагента" (или попросту "Клиента") с куратором. Какие стратегические идеи бродили в голове разработчиков при выборе такого подхода понять трудно.

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

Можно привести еще ряд примеров "дружелюбности" интерфейса КК, но, по-моему, достаточно.

Sales Expert

Поделитесь этой записью или добавьте в закладки