Разбор «ошибок» внедрения CRM. Часть 1
В основном мы пишем о работе с НКО. Это наша социальная ответственность и желание помочь в том числе и благотворительным организациям, которым, по сути, с ИТ-проектами сложно. Однако, компания АМИВЕО – коммерческая организация и мы работаем в сегменте малого и среднего бизнеса. Мы решили публиковать статьи и для бизнеса. А что бы они отличались от НКО – будем делать их в оранжевом цвете. Потому что мы любим клиента и ценим его время.
Неужели у бизнеса проблемы другие?! Нет, они похожи. Только выглядят они острее, потому что кейсы считаются в конкретных рублях, евро или долларах.
Интересную статью опубликовал ECM-journal «Почему 9 из 10 внедрений CRM заканчиваются провалом». О! Как много острых проблем вскрывается в этой статье!
Хотим разобраться с каждой из них и призываем к дискуссии всех, кто связан с ИТ проектами, внедрением, работой в CRM. Работаете вы в НКО или бизнес-сегменте, указывайте. Нам интересно!
Цитата: К нам обратилась компания, у которой уже была CRM. Сотрудники работали в системе, вроде все было нормально. Но руководство не увидело какого-либо ощутимого эффекта от её появления. «За что мы заплатили деньги?», — с этим вопросом они пришли к нам. В ходе аудита мы выяснили, что предыдущий интегратор настроил портал всего лишь на 20-25% от имеющихся возможностей тарифа.
Авторы статьи видят причину этого (и других схожих примеров) в отсутствии корректного технического задания. Как говорится, если нет ТЗ, то и результат ХЗ.
Хотим порассуждать о качественном ТЗ. Кто его способен написать? Во-первых, необходимо уточнить, что ТЗ, оно же техническое задание, делается на техническом языке и является руководством к действию для технических специалистов. Мы в своих проектах предпочитаем термин Бизнес-функциональные требования (БФТ). Этот документ пишется на языке бизнеса и для бизнес-заказчика, в нем простыми человеческими словами описывается что именно должна делать та или иная система. А уже по БФТ пишется ТЗ для разработчиков и внедренцев. По нашим правилам ТЗ является внутренним документом и не согласовывается с заказчиком. Приемка системы также осуществляется по БФТ, а не по ТЗ.
Во-вторых, хорошо, если в компании есть свое подразделение ИТ: архитектор, аналитики, техническая поддержка и прочие достойные люди. Однако, даже крупные корпорации передают эти функции на аутсорс – такова диктатура современной экономической ситуации. А у малого бизнеса (не говоря про НКО) таких специалистов в своей структуре нет, не было и не будет.
Вторая проблема – время и ресурсы. Если нет специалистов, а БФТ писать надо, сколько времени и какого качества будет этот документ? Более того, пока документ будет согласован, а потом по нему система разработана и внедрена, очень вероятно, что реальные процессы изменились, появились новые потребности, выявились пробелы в требованиях.
Водопадная модель производства перестала себя оправдывать даже на таком фундаментальном производстве, как банковское программное обеспечение. Нынче используют Agile в той или иной (иногда причудливой) форме, что позволяет гибко и быстро реагировать на потребности производства.
Но это присказка. Теперь по сути примера (портал настроен на 20-25% от возможностей). А почему есть предположение, что настраивать надо было на 80-100%? И что такое эти самые «сто процентов»?
Вот есть у заказчика свои процессы производства. Система их поддерживает, хранит и обрабатывает данные. А значит есть возможность для аналитики и принятия управленческих решений. Конечно, процессы нуждаются в реинжиниринге время от времени – никто не спорит. Но неужели вы хотите дать больше функций производству, не понимая, освоит ли их персонал, а справится ли с этими нововведениями само производство (нужно ли ему это, есть ли у него на это ресурсы и что будет выгодой по итогам внедрения)?
В приведенном примере руководство не видит смысла от внедрения системы. Может (рискнем предположить) недовольна оплатой лицензий и тарифов. А зачем система была внедрена? Какие задачи должна была решать. К каким целям вела организацию и заказчика?
Как с этим жить?!
Мы нашли решение. Для таких организаций Амивео разрабатывает стратегию цифровой трансформации и поддерживает ее реализацию. Т.е. мы стремимся избегать точечного внедрения системы (которая потом будет использоваться на 20% или стоять в замороженном состоянии), мы решаем проблемы глобально и комплексно.
Как мы это делаем?
Если говорить просто, мы автоматизируем повседневные процессы в компаниях за счет внедрения цифровых технологий. Наш опыт показывает, что многие сложные задачи можно решить простыми путями. Зачастую клиентам не нужно внедрять новую ИТ-систему, а достаточно настроить имеющуюся. Прежде чем добиться результата, совместно с клиентами мы проходим подготовительный путь:
• проводим аудит внутренних процессов организации;
• выявляем и согласуем цели и задачи цифровой трансформации;
• описываем и оптимизируем процессы;
• разрабатываем целевую ИТ-архитектуру;
• подбираем ИТ продукты, по возможности сохраняя те, что уже есть у заказчика.
Вместе с тем, мы умеем глубоко погрузиться в деятельность конкретной организации, изучить ситуацию изнутри и предложить действительно эффективные решения, доступные для некоммерческого сектора.
Проще говоря, мы поможем заказчику составить бизнес-функциональные требования, а ТЗ, разработку, управление командой разработки (к слову, это может быть ваш «привычный» разработчик), внедрение, обучение ключевых пользователей возьмем на себя.