{"id":13653,"url":"\/distributions\/13653\/click?bit=1&hash=fee89fe6174decc3f9a9e1cefc15dbde7d85d27279acdc112d63d4da4d5a0e3c","title":"\u0427\u0435\u043c\u043f\u0438\u043e\u043d\u0430\u0442 \u0434\u043b\u044f \u0438\u043d\u0432\u0435\u0441\u0442\u043e\u0440\u043e\u0432: \u043c\u043e\u0436\u043d\u043e \u0432\u044b\u0438\u0433\u0440\u0430\u0442\u044c \u0434\u043e 100 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e!","imageUuid":"8c1166aa-ed4d-5964-8fea-818410a466e6","isPaidAndBannersEnabled":false}
Карьера
OmniLine

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

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

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

Пункт 1. Стратегия

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

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

Пункт 2. Цели и задачи

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

Пункт 3. Требования к системе и вендору

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

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

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

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

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

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

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

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

  1. Бизнес-требования. Это требования всех стейкхолдеров к конечному результату проекта. На примере банка, который мы описывали выше, бизнес-требованиями будут: управление качеством клиентского сервиса. оценка работы клиентского сервиса и т.д.
  2. Требования к платформе и вендору. В требованиях к платформе важно прописать ее функционал. Например, здесь должен быть доступен каталог сервисов, возможность получения оценки от клиентов из чата. А также — как этот функционал реализуется. Например, есть ли он уже в коробке или его нужно дополнительно разрабатывать. Можно сделать такую сравнительную таблицу.
  • Берем все наши требования (строчки). Каждое требование имеет вес, степень значимости / критичности (условно — 1, 2 и 3 звезды).
  • По столбцам пишем предлагаемые решения.
  • Чекаем каждое требование в предлагаемых системах. Методы проверки могут быть разные от “поверим на слово” до пилотного проекта, где исполнение требований реально проверить.
  • Оцениваем степень соответствия требования и решения. Например, выставляем баллы, где 3 — есть в коробке, 2 — нужна настройка, 1 — нужна разработка.
  • Умножаем степень соответствия на вес.
  • Теперь суммируем все строчки по каждому предложению и сравниваем итоговые суммы.
Пример таблицы для выбора платформы

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

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

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

Пункт 4. Техническое задание и выбор партнера.

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

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

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

Пункт 5. Критерии.

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

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

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

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

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

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

Пункт 6. Запуск процедуры.

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

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

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

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

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

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

0
Комментарии
Читать все 0 комментариев
null