Rambler's Top100
Просмотреть марку >>
О нас
Учителя и авторитеты
Они просто сделали это
Статьи по разделам
Приятное с полезным
События. Фотоальбом.
Книги и полезные ссылки
Гостевая книга
Обратная связь
Партнеры журнала
Карта сайта
Поиск

TOP



Недетские игры или создание прототипа при проектировании CRM

Материал связан со страницами:

Дегрисионные методы изменений

Правда о CRM

Раздел Автоматизация

Константин Дудков

Введение

Константин ДудковПроцесс выбора и внедрения системы CRM для любой компании, не имеющей четко описанных бизнес-процессов (и, соответственно, ТЗ на автоматизацию) является трудоемким и рискованным делом, и лучше всего описывается фразой «пойди туда, не знаю куда, принеси то, не знаю что». Необходимость CRM все уже осознают, но что именно от нее ожидают формулируется достаточно туманно. При этом все эксперты и тематические публикации в один голос предупреждают о высоких рисках провала проекта по внедрению CRM (по разным данным успешны от 10% до 30% таких проектов) и призывают подходить к выбору ответственно и с большой осторожностью. С чего же начать?

Направо пойдешь — коня потеряешь...

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

Попытаемся сначала как-то разделить варианты решений. В холле одной из компаний я видел замечательный лозунг: «Мы можем сделать хорошо, быстро и качественно. Выбирайте любые два из трех». Рассмотрим различные стратегии выбора с этой точки зрения.

«Делаем все сами!». Система проектируется и создается «с нуля» на базе выбранной платформы или среды разработки. Как правило на предприятиях уже есть среда лоскутной автоматизации (это может быть 1С, php, или, например, Zope) все зависит от предпочтений имеющихся программистов или нанятых разработчиков. Получается дешево, относительно хорошо (за счет очень длительного периода доработки по дополнительным требованиям пользователей), но очень долго.

«Давайте купим хоть что-нибудь (покупаем запорожец) " Часто руководитель, уставший от долгих выборов и обсуждений, форсирует принятие решения, причем ориентируется в основном на цену. Мотивация простая: программа уже давно нужна, давайте пока купим дешевый вариант, а там будет видно. Быстро (дешевые решения продаются без внедрения, установил и работай), дешево, но плохо. Функций в программе мало, ведение клиентской базы для пользователей трудоемко, а выгоды неочевидны. Через месяц-другой после внедрения с программой работают все меньше, а потом и вовсе забрасывают. Причем, из-за ограниченного функционала компания практически никаких дополнительных знаний на тему «что нам нужно от системы» не получает. Живет такое решение недолго, хотя бывают и исключения: если компания у вас маленькая, а поставленные задачи строго ограничены (например, только ведение клиентской базы), то может и выжить.

«Покупаем мерседес» фирма у нас богатая, нам нужно только лучшее. Покупается дорогая известная система с внедрением. Тут все зависит от профессионализма команды, которая будет заниматься внедрением. Им предстоит описать бизнес-процессы, выяснить (иногда буквально под пытками) нужды каждого пользователя и его требования к интерфейсу, собрать все формы документов, которые должна порождать система и исходя из всего этого составить техническое задание на внедрение и технологию работы с системой. Если профессионализма, времени или чего-то еще для качественного проведения этой фазы им не хватит — жди беды. Система не приживется. Стратегия получается дорогая, очень хорошая (с учетом оговорок),относительно быстрая (4–8 месяцев).

Вариант данной стратегии — покупка CRM-модуля выбранной ERP-системы, с целью внедрить потом всю ERP. Имеет смысл, если вы a) точно будете внедрять ERP в обозримом будущем, б) точно знаете, какую ERP будете внедрять. Вы это знаете?

Играем в кубики

Итак, критерии. Тут мы, наконец, в плотную подходим к вопросу «а что нам все-таки нужно?».
В голове у каждого пользователя есть туманное представление о том, что он хочет от компьютера. В кратце — чтобы компьютер сам за него делал всю рутину. В процессе ознакомления с разными программами эти представления меняются, появляются некие шаблоны, этими программами навеянные. Если новая программа этим представлениям не соответствует, не уменьшает количество рутинных операций (а разбираться в возможностях программы или читать документацию — это тоже рутинная операция), пользователь программой недоволен. Если он еще и руководитель, понятно, во что это недовольство выливается. Перевести же эти представления пользователя в техническое задание на разработку — это искусство. У человека, который этим занимается должен быть соответствующий опыт и талант. В качестве примера попробуйте попросить знакомого художника нарисовать портрет вашего знакомого только по вашему устному описанию. Как вы думаете, похоже получится?

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

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

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

Однако следует четко ограничить область автоматизации, лучше хорошо сделать малое, чем заниматься написанием собственного аналога SAP R3™. При этом среда программирования должна позволять вносить изменения очень быстро, практически «на ходу», прямо при пользователях, и оперативно менять и дополнять структуру базы. В жертву при этом приносятся такие вещи, как быстродействие, ограничение по количеству пользователей, простота установки и поддержки и прочие не очень значительные на этапе прототипа параметры. Следует помнить, что делается именно прототип, который не предполагается использовать долго и в полной мере. Это своеобразное возведение макета дома в натуральную величину из фанеры и картона. Пусть такой макет простоит только до первых дождей, но именно в этом макете заказчик может походить, увидеть все изнутри, прикинуть, где какую мебель он будет ставить и что в какой комнате будет и высказать свои пожелания. И исполнитель прямо при нем может лишнее отрезать и где надо жвачкой подклеить. Качество не важно. Главное внешний вид прикинуть. А потом уже можно делать чертеж по полученному макету, сносить его и строить всерьез.

В случае же приглашения сразу специалистов по внедрению большого и серьезного продукта, ТЗ будет написано сразу с ваших слов, без макета. Да, писать его будут профессионалы с опытом работы, но на выходе получится только их трактовка ваших пожеланий. Проверить, насколько правильно было их восприятие, заказчику будет сложно. Уже потом, когда дом будет построен, и заказчик увидит, что в гостиную не влезает его любимый шкаф, перестроить будет можно. Но сколько будет стоить перестройка готового здания...

Кто же этот герой

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

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

Заключение

Рассмотрим все достоинства создания прототипа:

  • Создание прототипа позволяет сформулировать пожелания к системе разных групп пользователей и сформировать критерии выбора решения;

  • Прототип может быть использован в виде варианта технического задания по настройке будущей системы CRM ( «сделайте нам также» );

  • Прототип позволяет отработать механизм работы пользователей с CRM;

  • Прототип позволяет подготовить данные для переноса в будущую систему CRM — пользователи, работая с прототипом, занесут в него информацию о своих контрагентах, контактах с ними и продажах; в будущем эту информацию будет легко перенести в любую систему (поскольку структура базы прототипа будет вам хорошо известна), при использовании готового дешевого решения это не всегда так;
  • прототип позволяет подготовить почву для выделения бюджета на «нормальный» проект (увидев экономический эффект от работы прототипа руководства легче пойдет на выделение бюджета);
  • ... и все это за весьма небольшую сумму!

Высказаться 

 

 
Яндекс цитирования
Рейтинг@Mail.ru
 
Главная страница Написать письмо Поиск
 


© Е.Г. Маркушина, 2001