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

Федоров А.А.

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

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

Интерфейс

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

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

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

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

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

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

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

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

Sales Expert

В программе интерфейс статический, реализован в виде набора стандартных форм. Настраивать интерфейс нельзя, хотя есть возможность добавления текстовых полей (вер. 1.4), Концепция универсального пользовательского интерфейса имеет свои плюсы и минусы. С одной стороны, если бизнес-логика, реализованная в SE адекватна вашему предприятию, то у системного администратора исчезают проблемы, связанные с адаптацией (и это проблемная вещь для Клиент Коммуникатора). С другой стороны, если все же бизнес-логика отличается, то использовать программу становиться неудобно. Например, это может выражаться в ненужных для большинства предприятий интерфейсных элементов, перегружающих рабочее пространство. Кроме того, формирование статических форм неудобно, т.к. разработчики SE практически "заперли" себя на этом интерфейсе. Добавление новых полей (хотя бы тех же текстовых) приходится "не к месту". Например, вам понадобилось сделать поле "Абонентский ящик". Вы добавляете текстовое поле с таким наименованием, но появляется оно не в блоке адреса, а где-то там снизу. При этом ухудшается удобство использования программы. Если же вы надумаете добавить много тектовых полей, то разбираться в них будет крайне тяжело. В этом смысле идеальным можно назвать подход ACT!, где интерфейс настраивается. К сожалению, ACT! не является клиент-серверной программой.