Подписывайтесь на наши каналы и паблики, оставайтесь на связи и получайте уведомления о последних статьях и новостях на нашем сайте.
Как выбрать партнера. Часть вторая: рациональный выбор — по пунктам
Продолжаем нашу серию статей о том, как выбрать партнера. В первой части мы уже рассказали, зачем вообще нужно выбирать систему, вендора и интегратора. Сейчас мы поделимся с вами, что должна сделать компания, чтобы выбор был рациональным и взвешенным.
Пункт 1. Стратегия
В самом начале необходимо определить, насколько запланированный проект отвечает стратегии компании. Внедрение CRM или Service Desk — это только часть работ по реализации стратегии, но важно, чтобы он ей соответствовал.
Приведем пример. Банк N до определенного времени занимался исключительно корпоративными клиентами. В определенный момент было принято решение нарастить количество “физиков”. Среди прочих инструментов для достижения этой цели была внедрена система для входящего и исходящего взаимодействия с такими клиентами, а также для сбора обратной связи от них. Само решение не увеличивало число клиентов-физлиц, но соответствовало такой стратегии.
Пункт 2. Цели и задачи
Исходя из стратегии, заказчик формирует цели — как в примере выше, внедрить систему. А на пути к целям уже добавляются конкретные задачи. Например, какие процессы будут затронуты, описать интеграцию с другими системами, обучение персонала и другое.
Пункт 3. Требования к системе и вендору
Если есть понимание, куда и как идем — стратегия, цели и задачи — то можно формировать требования. И здесь мы рекомендуем руководствоваться технологией SMART. Или хотя бы попробовать это сделать.
Specific — конкретный. Вы должны точно определить результат, который хотите достичь.
Measurable — измеримый. Нужно установить конкретные критерии, по которым поймете, достигнута цель или нет.
Achievable — достижимый. Требования должны быть чуть ближе к реальности, чем розовые единороги или эликсир вечной молодости.
Relevant — значимый. Это соответствие общей стратегии компании. Например, если компания работает на сохранение своей доли на рынке и удержание клиентов, то целью внедрения CRM не может быть лавинообразное увеличение числа новых заказчиков.
Тime bound — ограниченный во времени. Все прекрасное рано или поздно заканчивается. Работа по внедрению СRM в том числе, и это тоже нужно отразить в требованиях. Причем важны не сроки, а конкретная дата, когда это должно быть сделано. Future Perfect Tense, короче.
- Читайте также
Также у каждого требования необходимо прописать вес — условно, по 3-балльной системе. Максимальный уровень важности, средний и минимальный.
В процессе должны получиться категории требований:
- Бизнес-требования. Это требования всех стейкхолдеров к конечному результату проекта. На примере банка, который мы описывали выше, бизнес-требованиями будут: управление качеством клиентского сервиса. оценка работы клиентского сервиса и т.д.
- Требования к платформе и вендору. В требованиях к платформе важно прописать ее функционал. Например, здесь должен быть доступен каталог сервисов, возможность получения оценки от клиентов из чата. А также — как этот функционал реализуется. Например, есть ли он уже в коробке или его нужно дополнительно разрабатывать. Можно сделать такую сравнительную таблицу.
- Берем все наши требования (строчки). Каждое требование имеет вес, степень значимости / критичности (условно — 1, 2 и 3 звезды).
- По столбцам пишем предлагаемые решения.
- Чекаем каждое требование в предлагаемых системах. Методы проверки могут быть разные от «поверим на слово» до пилотного проекта, где исполнение требований реально проверить.
- Оцениваем степень соответствия требования и решения. Например, выставляем баллы, где 3 — есть в коробке, 2 — нужна настройка, 1 — нужна разработка.
- Умножаем степень соответствия на вес.
- Теперь суммируем все строчки по каждому предложению и сравниваем итоговые суммы.
Пример таблицы для выбора платформы
Есть еще и другие факторы, влияющие на выбор, такие как бюджет и сроки внедрения. Таким образом, мы понимаем, что функциональное соответствие у предлагаемой системы, например на втором месте, но бюджет и сроки лучше конкурентов. В этом случае можем выбрать именно эту технологию.
При формировании требований к вендору опираемся на его роль в проекте. Об этом, напомним, мы писали здесь.
3. Требования к партнеру. Опять же, ориентируемся на роль интегратора в проекте. Плюс — на соответствие его решения техническому заданию. Но для этот ТЗ еще нужно прописать. Поэтому…
Пункт 4. Техническое задание и выбор партнера.
Это ответ на вопрос: “Что нужно сделать, чтобы решить задачи и достичь целей?” Настроить, интегрировать, внедрить и т. п. Техзадание прописывать — это долго и мучительно. Если заказчик не может сам прописать ТЗ, мы можем сделать это сами либо порекомендуем обратиться к консультантам.
- Читайте также
Как понять, что ТЗ составлено верно? Задайте себе вопрос, как вы будете проверять тот или иной пункт. Потому что когда вы внедрите систему, нужно будет как-то понять, правильно вы это сделали или нет. Например, как проверить, выполняется ли требование “удобный интерфейс”. Этот качественный показатель нужно перевести в количественный. Так, предложите пользователям поставить системе лайк или дизлайк. Если лайков будет, условно, 80% — то считаем такую систему удобной.
На основании ТЗ уже выбирают партнера-интегратора. Одно и то же ТЗ можно реализовать в совершенно по-разному. Будут отличаться сроки, стоимость, объемы доработок базовой платформы и т.д.
Пункт 5. Критерии.
1. Степень соответствия требованиям:
— Функциональные требования для платформы;
— Соответствие решения от партнера техническому заданию.
2. Сроки.
3. Цена.
4. Наличие положительного или отрицательного опыта. Интересно, что раньше спрашивали об успешных кейсах, то сейчас все больше интересуются факапами.
5. Формальные критерии — оборот, количество сотрудников и т.п.
Поясним. Мы определяем критерии по которым производим выбор. В предыдущих пунктах мы определили требования к платформе и составили техническое задание. Ключевой критерий выбора это степень соответствия платформы и предлагаемого решения. В ходе переговоров мы должны убедиться, попросить показать в демо или в пилотном проекте подтвердить концепцию решения.
Степень соответствия требованиям — это основной критерий. Часто заказчики выбирают только по сроку и цене, потому что все остальное проверить очень сложно, нужно потратить много времени и обладать определенной квалификацией. Но зачем вам дешевое решение в короткие сроки, если это не помогает вам достичь вашей цели?
Далее могут быть вторичные критерии (здесь заказчики могут считать по другому, мы лишь делимся нашим опытом). Это опыт в других компаниях или отрасли и разного рода формализованные критерии в виде совокупного оборота или количества сертифицированных специалистов.
В критерии нужно включить именно то, что действительно важно и то, что можно оценить, чтобы сократить субъективное влияние на выбор.
Пункт 6. Запуск процедуры.
Когда проделано все выше перечисленное — приступаем к запуску процедуры. Определяются лица, которые будут принимать решения. На основании критериев они формируют лонг-лист вендоров и партнеров. Если это крупная компания — предложения от сейлов сами поступают. Плюс — надо погуглить, посмотреть отраслевые порталы, а также — что используют конкуренты.
Этот список просматривают на соответствие требованиям и составляют уже шорт-лист. Идеально, если в нем останется один явный исполнитель. Но обычно это не так.
Лучшая практика, чтобы выбрать вендоров и интеграторов из шорт-листа, — это проведение адаптированных демо. По сути это концепция проекта на реальной выбранной платформе. Вам должно быть понятно, как будет решена задача. В мировой практике этот шаг называется Proof-of-Concept — доказательство концепции. В крупных проектах адаптация системы для демо может быть затратным мероприятием и в этом случае Заказчик, интегратор и вендор договариваются об условиях компенсации затрат.
В некоторых случаях имеет смысл пойти дальше и реализовать уже полноценный проект с потенциальным интегратором и вендором. Это пилотный проект, который с одной стороны даст понимание, что все стороны могут эффективно работать друг с другом, а с другой стороны даст конечный результат, который заказчик может полноценно использовать и развивать дальше.
Рациональный отбор, безусловно, необходим. Но в итоге все равно заказчик приходит к эмоциональному выбору. О нем — в следующей статье
Подписывайтесь на наши каналы и паблики, оставайтесь на связи и получайте уведомления о последних статьях и новостях на нашем сайте.
