Переход AMS и базовая оценка ландшафта
Иллюстративный сценарий использования, а не кейс клиента.
Приём приложений, которые создавали не мы: инвентаризация ландшафта, согласование объёма и уровней критичности, передача знаний и фиксация базового уровня сервиса до начала эксплуатации.
Проблема
Приложения работают, но люди, которые их понимали, ушли, или действующий вендор уходит. Документация неполная, доработки не задокументированы, и никто не может сказать, какие интеграции критичны. Поддержку нельзя улучшить, пока она сначала не понята.
Как это работает сегодня
Новая команда поддержки наследует очередь заявок и общий диск. Передача знаний происходит за несколько звонков с уходящей командой. Определения уровней критичности, часы обслуживания и пути эскалации берутся как данность из старого контракта. Первые месяцы уходят на повторное изучение ландшафта через инциденты.
Посмотрите сценарий
Иллюстративный рабочий процесс. С субтитрами.
Текстовая версия
- Приложения работают, но люди, которые их понимали, ушли. Документация неполная, доработки не описаны, и никто не может сказать, какие интеграции критичны.
- Мы составляем реестр приложений, согласуем объём и часы поддержки, документируем регламенты и пробелы, затем фиксируем начальный базовый уровень сервиса.
- Во время обследования в продуктивной среде ничего не меняется. Владелец утверждает определения до начала обслуживания, а выводы формируют бэклог улучшений, который приоритизирует владелец.
- Измеряем покрытие ландшафта и инциденты из-за неизвестных компонентов. Иллюстративный сценарий использования. Давайте обсудим ваш.
Предлагаемый рабочий процесс
- Составить реестр ландшафта: модули, интеграции, доработки, агенты и среды, в которых они работают, с данными, собранными из систем, а не по памяти
- Согласовать в письменном виде объём, определения уровней критичности, часы обслуживания и ответственность за эскалацию к вендору до приёма первой заявки
- Перенести знания в регламенты и утверждённую базу знаний, перечислив пробелы вместо того, чтобы скрывать их
- Провести базовую оценку сервиса: текущие объёмы инцидентов, время решения, частота релизов и известные риски
- Работать по согласованным определениям, фиксировать выводы и предлагать пункты улучшений, которые владелец приоритизирует
Где контроль остаётся за человеком
- Объём, уровни критичности, часы и ответственность за эскалацию утверждаются владельцем до начала обслуживания
- Во время обследования в продуктивную среду не вносится никаких изменений; выводы фиксируются, а не исправляются на месте
- Бэклог улучшений приоритизирует владелец, а не команда поддержки
Привязка к платформам указывает среды, в которых имеет смысл оценить эту идею. Фактическая реализация зависит от конфигурации, лицензий, API, данных и прав доступа. Преимущества описаны качественно; числовые утверждения требуют задокументированной базовой линии.