Как выбрать партнера. Часть вторая: рациональный выбор — по пунктам

Что должна сделать компания, чтобы выбор системы, вендора и интегратора стал рациональным и взвешенным?
Подробно в 6 пунктах мы изложили опыт наших реальных конкурсов и опыт наших клиентов по формализованному выбору решения.

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

В самом начале необходимо определить, насколько запланированный проект отвечает стратегии компании. Внедрение CRM или Service Desk — это только часть работ по реализации стратегии, но важно, чтобы он ей соответствовал.

Приведем пример. Банк N до определенного времени занимался исключительно корпоративными клиентами. В определенный момент было принято решение нарастить количество “физиков”. Среди прочих инструментов для достижения этой цели была внедрена система для входящего и исходящего взаимодействия с такими клиентами, а также для сбора обратной связи от них. Само решение не увеличивало число клиентов-физлиц, но соответствовало такой стратегии.

Исходя из стратегии, заказчик формирует цели — как в примере выше, внедрить систему. А на пути к целям уже добавляются конкретные задачи. Например, какие процессы будут затронуты, описать интеграцию с другими системами, обучение персонала и другое.

Если есть понимание, куда и как идем — стратегия, цели и задачи — то можно формировать требования. И здесь мы рекомендуем руководствоваться технологией SMART. Или хотя бы попробовать это сделать.

Specific — конкретный. Вы должны точно определить результат, который хотите достичь.

Measurable — измеримый. Нужно установить конкретные критерии, по которым поймете, достигнута цель или нет.

Achievable — достижимый. Требования должны быть чуть ближе к реальности, чем розовые единороги или эликсир вечной молодости.

Relevant — значимый. Это соответствие общей стратегии компании. Например, если компания работает на сохранение своей доли на рынке и удержание клиентов, то целью внедрения CRM не может быть лавинообразное увеличение числа новых заказчиков.

Тime bound — ограниченный во времени. Все прекрасное рано или поздно заканчивается. Работа по внедрению СRM в том числе, и это тоже нужно отразить в требованиях. Причем важны не сроки, а конкретная дата, когда это должно быть сделано. Future Perfect Tense, короче.

Также у каждого требования необходимо прописать вес — условно, по 3-балльной системе. Максимальный уровень важности, средний и минимальный.

В процессе должны получиться категории требований:

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

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

3. Требования к партнеру. Опять же, ориентируемся на роль интегратора в проекте. Плюс — на соответствие его решения техническому заданию. Но для этот ТЗ еще нужно прописать. Поэтому…

Это ответ на вопрос: “Что нужно сделать, чтобы решить задачи и достичь целей?” Настроить, интегрировать, внедрить и т. п. Техзадание прописывать — это долго и мучительно. Если заказчик не может сам прописать ТЗ, мы можем сделать это сами либо порекомендуем обратиться к консультантам.

Как понять, что ТЗ составлено верно? Задайте себе вопрос, как вы будете проверять тот или иной пункт. Потому что когда вы внедрите систему, нужно будет как-то понять, правильно вы это сделали или нет. Например, как проверить, выполняется ли требование “удобный интерфейс”. Этот качественный показатель нужно перевести в количественный. Так, предложите пользователям поставить системе лайк или дизлайк. Если лайков будет, условно, 80% — то считаем такую систему удобной.

На основании ТЗ уже выбирают партнера-интегратора. Одно и то же ТЗ можно реализовать в совершенно по-разному. Будут отличаться сроки, стоимость, объемы доработок базовой платформы и т.д.

Здесь нужно определить следующее.

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

Степень соответствия требованиям — это основной критерий. Часто заказчики выбирают только по сроку и цене, потому что все остальное проверить очень сложно, нужно потратить много времени и обладать определенной квалификацией. Но зачем вам дешевое решение в короткие сроки, если это не помогает вам достичь вашей цели?

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

В критерии нужно включить именно то, что действительно важно и то, что можно оценить, чтобы сократить субъективное влияние на выбор.

Когда проделано все выше перечисленное — приступаем к запуску процедуры. Определяются лица, которые будут принимать решения. На основании критериев они формируют лонг-лист вендоров и партнеров. Если это крупная компания — предложения от сейлов сами поступают. Плюс — надо погуглить, посмотреть отраслевые порталы, а также — что используют конкуренты.

Этот список просматривают на соответствие требованиям и составляют уже шорт-лист. Идеально, если в нем останется один явный исполнитель. Но обычно это не так.

Лучшая практика, чтобы выбрать вендоров и интеграторов из шорт-листа, — это проведение адаптированных демо. По сути это концепция проекта на реальной выбранной платформе. Вам должно быть понятно, как будет решена задача. В мировой практике этот шаг называется Proof-of-Concept — доказательство концепции. В крупных проектах адаптация системы для демо может быть затратным мероприятием и в этом случае Заказчик, интегратор и вендор договариваются об условиях компенсации затрат.

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

Рациональный отбор, безусловно, необходим. Но в итоге все равно заказчик приходит к эмоциональному выбору. О нем — в следующей статье

Больше информации о технологиях, клиентском сервисе, автоматизации вы найдете на нашем сайте, в Telegram-канале и на нашей странице в Facebook