Типовая демонстрация подрядчика легко превращается в презентацию возможностей: красивые дашборды, список технологий, схема команды и несколько кейсов. Все это полезно, но почти не показывает, как сервис поведет себя при реальном критичном инциденте, когда причина неизвестна, затронуто несколько систем и времени на согласования мало.
Проверять лучше не интерфейс и не скорость ответа продавца, а способ работы команды. Для этого кандидатам дают одинаковые сценарии и просят показать, какие шаги они выполнят, какие данные запросят, кто будет владельцем результата и какие рабочие артефакты появятся по ходу сервиса.
Демонстрация должна показать полный цикл управления сервисом: получение сигнала, оценку бизнес-влияния, диагностику, подключение экспертов, межкомандную координацию, фиксацию знаний и последующее улучшение. Умение быстро открыть тикет или показать панель мониторинга — только часть процесса.
Полезно заранее определить критерии оценки и одинаково применять их к кандидатам. Тогда харизма команды и качество презентации не подменят проверку прозрачности, глубины диагностики и способности отвечать за сквозной результат.
Сценарии должны отражать реальный ландшафт заказчика, но не раскрывать лишние конфиденциальные данные. Достаточно описать бизнес-влияние, несколько зависимых систем и ограничения. Причину лучше не сообщать заранее — важно увидеть, как команда строит диагностику.
Для нескольких подрядчиков набор сценариев должен быть одинаковым. Тогда сравнивается процесс, а не удачность конкретного примера, подготовленного кандидатом.
Сценарий 1. Критичный инцидент в бизнес-сервисе
Попросите пройти путь от первого сигнала до восстановления: кто принимает обращение, как определяется приоритет, кто становится владельцем, когда запускается оперативная конференция, как информируется бизнес. После восстановления важен разбор: как фиксируется причина и кто отвечает за действия по предотвращению повтора.
Сильный сигнал — команда сразу уточняет бизнес-контекст и предлагает структуру коммуникации. Слабый — начинает с обсуждения внутренних очередей и пытается определить виновный компонент до назначения владельца инцидента.
Сценарий 2. Сбой на стыке нескольких систем и подрядчиков
Смоделируйте ситуацию, когда ERP работает, но отгрузка остановлена из-за неизвестной ошибки между приложением, интеграционной шиной и WMS. Посмотрите, кто координирует диагностику и как команда действует, если другая сторона не подтверждает свою ответственность.
Зрелая модель не отправляет заказчика между исполнителями. Один координатор удерживает статус, собирает данные, подключает участников и ведет задачу до восстановления бизнес-процесса.
Сценарий 3. Проактивное обнаружение проблемы
Попросите показать, как сигнал мониторинга превращается в действие до обращения пользователя. Важно увидеть пороги, фильтрацию шума, связь события с бизнес-сервисом и решение о приоритете. Красивый график доступности сам по себе ничего не доказывает.
Хороший пример содержит последующее действие: проверку очереди, перезапуск процесса по регламенту, эскалацию или создание проблемы для устранения причины. Проактивность — это не количество алертов, а управляемая реакция.
Сценарий 4. Повторяющийся инцидент и управление проблемами
Дайте несколько похожих обращений и спросите, в какой момент команда перестанет закрывать их как независимые. Должна появиться отдельная проблема, гипотеза первопричины, известный обход, владелец долгосрочного исправления и связь с инцидентами.
Если подрядчик оценивает качество только количеством закрытых тикетов, повторяемость может оставаться выгодной статистически. Управление проблемами показывает, способен ли сервис снижать будущую нагрузку.
Сценарий 5. Изменение и релиз
Попросите пройти изменение, которое затрагивает несколько систем. Кто оценивает влияние, какие тесты обязательны, как проверяется окно бизнеса, кто согласует выпуск и что происходит при отклонении. Отдельно спросите о плане отката и постконтроле.
Важно увидеть связь изменений с инцидентами. Если после релиза возникает проблема, команда должна быстро определить, какие изменения могли повлиять на сервис, и использовать эту информацию в диагностике.
Сценарий 6. Передача и использование знаний
Попросите найти инструкцию по конкретной операции и показать ее владельца, историю обновлений и связь с системой или обращением. Еще лучше — объяснить, как новый сотрудник доказывает, что может выполнить процедуру самостоятельно.
Сильная база знаний встроена в работу. Если команда демонстрирует только количество статей или красивое дерево разделов, это не подтверждает воспроизводимость.
Сценарий 7. Сервисная отчетность
Попросите показать обезличенный регулярный отчет. В нем должны быть не только SLA и количество обращений, но и повторные проблемы, очередь изменений, риски, проактивные действия, состояние знаний и решения, требующие участия заказчика.
Отчет должен отвечать на вопрос «что изменится после этой встречи». Если он только фиксирует прошлые цифры, сервис не использует аналитику как инструмент управления.
На вопросы о сервисе должны отвечать люди, которые будут его строить или вести: сервис-менеджер, технический эксперт, руководитель линии или приложения. Для сценариев доступа и данных может понадобиться представитель ИБ. Участие продаж полезно, но не должно заменять рабочую команду.
Если все ответы дает один презентационный спикер, попросите переключить обсуждение на конкретные операционные роли. Это помогает понять глубину команды и согласованность подходов.
Подойдут обезличенные отчеты, матрицы ответственности, шаблон разбора критичного инцидента, карточка проблемы, операционная инструкция, схема эскалации и пример календаря изменений. Не нужно требовать конфиденциальные данные других клиентов — достаточно структуры и связей между материалами.
Дополнительно полезно посмотреть проекты IBS, но кейс не заменяет демонстрацию процесса. Проект показывает опыт, а сценарий — способность применить подход к вашей ситуации.
Для каждого сценария заранее задайте критерии: понимание бизнес-влияния, прозрачность владельца, логика диагностики, управление стыками, качество эскалации, использование знаний, контроль изменений и наличие проверяемого результата. Оценка может быть качественной — важно единообразие.
После демонстрации фиксируйте не только балл, но и доказательство: какой документ показан, какое решение предложено, какой вопрос остался без ответа. Это снижает влияние общего впечатления и помогает сравнивать кандидатов спустя несколько дней.
Настораживает фокус только на тикетах и инструментах, отсутствие межсистемного сценария, неясный владелец критичного инцидента, невозможность показать пример рабочей отчетности, отсутствие практики разбора причин и знаний. Еще один сигнал — обещание «мы все берем на себя» без описания границ и роли заказчика.
Сильная команда спокойно говорит об ограничениях и показывает, как управляет ими. Сопровождение систем не должно выглядеть как магия — чем прозрачнее процесс, тем легче проверить реальную зрелость.
Чтобы сравнение было полезным, заказчику стоит заранее выбрать несколько ситуаций из собственного опыта: повторяющийся инцидент, сбой между системами, рискованный релиз, проблема знаний. Необязательно раскрывать реальные названия и цифры — достаточно сохранить структуру зависимости и бизнес-влияние. Тогда подрядчик отвечает на задачу, близкую к будущей работе.
К каждому сценарию заранее определите, что хотите проверить. Для одного это может быть владение критичным инцидентом, для другого — логика эскалации, для третьего — умение отделить симптом от первопричины. Такая подготовка делает демонстрацию короче и лишает кандидатов возможности выбирать только удобные примеры.
Сразу после встречи полезно зафиксировать наблюдения, пока детали не потерялись: какие роли участвовали, какие артефакты показаны, где команда быстро поняла контекст, а где потребовались подсказки. Затем оценки нескольких кандидатов сводятся в одну таблицу по заранее заданным критериям.
Если по важному сценарию осталась неопределенность, лучше запросить короткую дополнительную сессию, чем компенсировать пробел общим впечатлением. Предварительный отбор должен уменьшать неизвестность перед коммерческими переговорами, а не просто ранжировать презентации.
| Сценарий | Что попросить показать | Доказательство | Сильный сигнал | Красный флаг | Оценка |
|---|---|---|---|---|---|
| Критичный инцидент | Путь от сигнала до восстановления | Протокол + отчет | Есть единый владелец | Перевод между очередями | 1-5 |
| Повторная проблема | Работу с первопричиной | Карточка проблемы | Есть корректирующее действие | Только закрытие тикетов | 1-5 |
| Изменение | Оценку риска и откат | План изменения | Есть постконтроль | Нет плана отката | 1-5 |
Демонстрацию стоит строить вокруг сценариев из собственного ИТ-ландшафта и одинаковых критериев для всех кандидатов. Если нужно подготовить такие сценарии и шкалу оценки, обсудить сервисную модель с IBS можно до формирования финального списка подрядчиков.