CRM
Стоимость ошибки, при переходе на новую CRM
За пять лет опыта с Saas-решением в компаниях, я натыкался на случаи, когда предприятия перерастают функционал систем с закрытым кодом. В таких ситуациях они всегда стараются найти альтернативу, и, чаще всего, конечной точкой оказывается платформенное решение: систему разрабатывают с нуля, или почти с нуля — под свои бизнес-процессы.
Однако почти всегда это происходит в таком цейтноте, что сотрудники просто не успевают адаптироваться, а впоследствии выясняется, что новая система была изначально неверно разработана, что ошибки были еще на этапе ТЗ. В результате, предприятие терпит неприятные потери, и чтобы не сойти с рельс окончательно — возвращаются к старой CRM.
В этой статье мы разберем основные ошибки при уходе от Saas-решений к разработке на платформе, а также способы, с помощью которых эти ошибки можно не допускать вообще.
С чего начинается проблема
Если бизнес имеет хороший потенциал к масштабированию, а работу начал с коробочной системы, то, считайте, проблемы уже начались. Впоследствии, с ростом числа процессов, информации и контрагентов — система просто не справится: данных будет слишком много, и тут начнется самое интересное.
*картинка*
Довольно очевидно, что заставить персонал использовать неудобную систему добровольно — практически невозможно. Причина неудобства далеко не только в интерфейсе, сложности структуры или в медленной скорости работы; по-настоящему неприятно работать там, где нельзя автоматизировать рутинные процессы. решать необходимые задачи и получать всю нужную информацию.
Поэтому, когда в системе не хватает функций — сотрудники начинают искать альтернативы, и со временем этого поиска они постепенно уходят во что-то другое, заполняя базу данных в CRM лишь для галочки. Если вам удастся обнаружить подобный бедлам вовремя — считайте, что повезло; обычно это сложно заметить, в то время как утечка денег компании при такой работе равна ежемесячному тарифу системы, которая играет роль списка задач с карточками клиентов.
Далее, когда проблема принята и четко обозначена, а также известны причины ее возникновения — предприятие встает перед выбором: подобрать ли другое Saas-решение, коробку на платформе, или разработать систему с нуля.
Что нанесет больший ущерб при уходе в новую систему
Пожалуй, самые бессмысленные затраты произойдут в результате перехода «из коробки в коробку». В целях экономии, некоторые компании могут найти альтернативу старой системе, но уже решающую все текущие задачи бизнеса.
На первый взгляд это выгодно, — не нужно тратить деньги на разработку, период адаптации персонала — минимальный, множество готовых решений и способов автоматизации (особенно, если это коробка под вашу нишу). Да, в целом все супер — однако нужно понимать, что если у вас не студия из нескольких фотографов — вы будете расти, и этот переход лишь отсрочит неизбежное повторение истории.
*картинка*
Как избежать этих расходов
Самый эффективный способ не слить бюджет на вечные перепрыгивания из системы в систему — это изначально размещать бизнес в полностью кастомизируемой системе. Однако, если вы уже напоролись на коробку и поместили свой бизнес туда — далее мы разберемся как и зачем из нее выбираться, а также рассмотрим платформы, на которых удобнее всего разрабатывать систему.
Важно понимать, что этот вариант, опять же, — актуален не для всех. Есть куча примеров того, когда бизнес не растет: например, какая-нибудь группа элитных дизайнеров, которые выполняют дорогие заказы и работают по сарафанному радио для очень и очень толстых заказчиков. Они не хотят расти, им комфортно быть маленькими — так они готовы существовать годами.
Но если ваша компания становится больше, — было бы неплохо вовремя сойти на платформу, потому что такая система будет развиваться вместе с вашим бизнесом, — а иначе вы получите тот же самый стеклянный потолок.
То же самое касается и разработки с полного нуля. Вы можете нанять группу разработчиков — но они могут уйти в более выгодный проект, отойти от дел. Таких примеров много, при разработке с нуля бывают организационные или архитектурные сложности — когда архитектура проекта была заложена изначально неправильно. Систему можно построить так, что в определенный момент она станет неразвиваемой.
Выходом из этих трудностей может стать правильный выбор платформы, определиться с чем действительно непросто.
На что смотреть, при выборе платформы
При выборе обращайте внимание на то, как сильно вы зависимы от разработчика. Если при использовании платформенного решения есть возможность для самостоятельной работы без каких-либо навыков программирования — то платформа «настоящая». То есть, важно то, насколько «отчуждаемая» сама платформа: вы взяли ее — и пошли работать.
Еще один критерий, по которому можно определить хорошую платформу — вы можете разрабатывать на ней систему просто наняв любого студента программистского факультета. В паре с бизнес-аналитиком или человеком, который запросто ориентируется во всех ваших бизнес-процессах — обычный студент может спокойно выполнять работу разработчиков вендора, которые, как правило, берут за час своей работы весомые деньги.
Еще один очень важный момент — это прототипирование. Возможность накидать быстрый прототип системы для тестирования, — это действительно круто. С помощью такого инструмента вы проверите свои гипотезы и будете точно знать, как сформулировать ТЗ без ошибок.
Очень кратко рассмотрим нескольких вендоров, которые так или иначе подходят по критериям выше:
Если вы берете, к примеру, «1С», — развивать систему вы сможете только силами сертифицированного программиста. Этот вариант подходит тем, кто не хочет рисковать качеством, и готов регулярно инвестировать средства в доработку системы и ее поддержку. Благо, что специалистов 1C на рынке огромное множество, поэтому настройка и обслуживание системы не может вызывать никаких проблем.
Про Terrasoft можно сказать, что в целом эта система — очень качественный конструктор с мощными возможностями настройки, что, пожалуй, одна из самых главных характеристик для платформы.
Неплохо реализован визуальный редактор у платформы «КлиК»: он позволяет сделать прототип для тестирования еще перед началом работы с системой. Степень настройки всех составляющих без программирования — крайне высокая, что тоже приятно, особенно для экономии средств на доработке системы под свой бизнес.
Как подготовить бизнес для перехода
1. Найти «идеолога»
С вашей стороны необходим человек, который может точно отразить текущие бизнес-процессы компании и формализовать их. Этот человек будет контролировать весь процесс разработки учитывая удобство пользователей, и постоянно сверяться с «картой» — направляя проект в нужную сторону.
2. Создать прототип
Даже те компании, которые пережили неэффективные коробочные системы не всегда могут сформулировать те или иные задачи к новой системе. В этом лежат риски, связанные с тем, что при создании нового CRM-проекта можно заложить ошибки заранее, уже на уровне ТЗ. Поэтому, важным пунктом тут будет отлаживание — то есть вам надо не просто выстроить пробную модель, но и испытать ее на практике. Если визуальный редактор платформы позволяет накидать первую рабочую версию — обязательно воспользуйтесь такой возможностью и поиграйтесь с прототипом вместе в бизнес-аналитиком. Это сократит множество ошибок в разработке, которые вы могли допустить.
3. Отделаться от вендора
Довольно спорный момент, который подойдет не во всех ситуациях, но поможет значительно сократить инвестиции в систему. Хитрость в том, что если вы используете по-настоящему адаптируемую платформу — для вас будет гораздо выгодней нанять фрилансера, и настроить систему своими силами отдельно от разработчиков вендора.
4. Подготовить сотрудников
Если бизнес вырос из системы — достаточно объяснить сотрудникам: «Ребята, мы выросли, давайте переходить на новую систему». При этом, используя платформу вы можете подготовить интерфейс системы таким образом, чтобы он был похож на старый — это снизит дискомфорт от перехода. Чем больше удобство пользователей — тем легче приживется система.
Заключение
Платформы позволяют бизнесу развиваться, потому что такая система развивается вместе с компанией которая ее использует. Любые изменения в бизнесе кладутся на платформу — вы изменяете систему именно с точки зрения удобства работы: аналитиков, тех кто вводит, тех кто принимает какие-либо решения.
Чтобы избежать основных потерь — нужно изначально внедрять платформу. Тут ключевой момент в том, чтобы это было с минимальным участием разработчиков. Да, конечно, можно использовать разработчика, это будет в какой-то степени удобно и здорово — но, снижение риска тут происходит в том случае, если вы можете развивать эту платформу самостоятельно, без каких-либо специальных знаний и разработчика — это ключ.
На рынке сейчас очень много платформ которые говорят: «Мы можем все, мы вам сделаем все, у нас платформа! То что нужно — мы вам все запрограммируем», однако истинная платформа — это только та система, которая может существовать, функционировать и развиваться силами клиента, дилера, — то есть без разработчика.