Не поймите меня неправильно, я люблю заказчиков. Я больше 10 лет в CRM-индустрии, по определению, я очень люблю клиентов!

Но эти фразы…

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

Итак, 10 фраз или деструктивных желаний.

1. «Нам надо быстро, качественно и недорого»

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

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

2. «Вы разверните систему, нам срочно надо, а с требованиями разберемся по ходу»

«У конкурентов же уже все внедрено, а мы опять в отстающих, надо срочно что-то делать».

Срочно нужна CRM-система – это не цель. Должны быть четкие, измеримые цели и задачи. Начать внедрение до того, как выявлены и сформулированы основные требования – заведомо обреченная инициатива.

3. «А давайте внедрим сразу всё»

Комплексный проект – мероприятие рисковое в наше время. Конечно, существуют примеры успешных комплексных внедрений, что называется «под ключ». Но это, пожалуй, в прошлом.

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

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

4. «Вот вам требования – идите делайте»

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

Знакомая всем картинка аргументирует без слов.

5. «А документооборот на CRM можно сделать? А процессинг? А проекты вести?»

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

xRM – новая парадигма, платформа для творчества, тут все понятно. И ответ — действительно МОЖНО. Опытный консультант и хороший .net-разработчик вам на этой платформе все что угодно сделает. Но сможете ли вы потом поддерживать и развивать этого монстра – большой вопрос.

Вы же не пылесосите утюгом, используйте технологии по назначению.

С другой стороны, многие вендоры сейчас пошли по пути развития многофункциональных бизнес-платформ, в которых CRM, финансы, операционная деятельность и многое другое представлено отдельными блоками. А если говорить об оn-line технологиях – то сервисами, как, например, в Dynamics 365. По мере необходимости вы просто в нужное время подключаете и отключаете те или иные функции. А платите только за то, что используете.
Но сейчас не об этом.

6. «Устав проекта нам не нужен. Зачем этот лишний формализм?»

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

7. «ИТ-отдел и бизнес вовлекать во внедрение не будем, они так завалены текучкой. Пусть внешние консультанты придут и все сделают»

Тут я просто напишу, что ИТ и бизнес вовлекать нужно. Точка. Без них проекта не будет. Точка.

8. «Василий, ты такой молодец, а давай ты еще CRM-проектом будешь руководить?»

Очень важна роль руководителя проекта со стороны заказчика. Он обязательно должен обладать авторитетом и необходимыми полномочиями внутри компании, но это еще не все.

Руководить проектом это сложно и отнимает много времени, поэтому руководство проектом должно быть, если не единственной, то основной функцией сотрудника на время проекта.

9. «Нам не важен процесс, давайте вы сами»

«Ну вы же специалисты, да и задачи у нас типовые» и т.д. Ну что тут сказать, бывало и такое.

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

10. «Нам не нужно обучение пользователей. Пусть читают мануал»

Теоретически, почему бы и нет. Но, на практике, мануалы часто пишутся еще до сдачи системы в эксплуатацию, поэтому не исключены несоответствия, которые, кстати, и устраняются на этапе обучения.

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

Разумеется, это не все деструктивные идеи заказчиков, с которыми приходится или бороться, или мириться. В любом случае, лучше уже на старте выявить и оценить все возможные риски, и подумать – принимать их или отказаться сразу.

Успешных проектов!

Автор:

Источник