Как измерить результат пилота мобильной платформы и обосновать масштабирование

Результат пилота мобильной платформы измеряют сравнением базовых, целевых и фактических показателей. Оценка охватывает эксплуатацию, безопасность, пользовательский опыт и экономику. Для масштабирования нужны данные о регистрациях, соблюдении политик, времени отзыва доступа, инцидентах, заявках в сервис-деск, трудозатратах администраторов, TCO и расчетном ROI. Пилот длительностью 4–8 недель обычно позволяет проверить эти показатели на ограниченной группе. При этом исходные значения нужно сохранить до запуска, а критерии решения о масштабировании (go/no-go) — согласовать с ИТ, ИБ и бизнесом.

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

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

Пилот оценивают по четырем категориям.

Связь с бизнес-целями должна быть прямой. Для сокращения времени подключения выездного сотрудника измеряют интервал от создания учетной записи до готовности устройства. Для контроля после увольнения используют другой показатель: время от события в IdM до подтвержденного отзыва доступа на устройстве.

Количество подключений — слабый показатель. Сто устройств могут пройти регистрацию, и половина из них останется без обязательных политик. Формально пилот выполнен, по существу — нет: данные не защищены, сценарии не работают, нагрузка на сервис-деск выросла. Поэтому измеряют не регистрации, а долю устройств с примененными политиками и число обращений на 100 пользователей.

До запуска пилота фиксируют границы мобильной платформы, состав устройств, пользовательские сценарии, интеграции, политики безопасности и модель управления. Иначе фактический результат не с чем сравнить.

Для пилота фиксируют:

На этапе аудита инфраструктуры проверяют каталоги пользователей, сертификаты, сетевые маршруты, прокси, правила многофакторной аутентификации (MFA), форматы журналов и регламенты заявок. От сложности схемы интеграций зависят задержки и устойчивость обмена.

MDM (Mobile Device Management) — это управление мобильными устройствами. Его выбирают, если основной объект контроля — конфигурация, состояние и удаленные действия на смартфонах, планшетах и терминалах.

EMM (Enterprise Mobility Management) — это управление корпоративной мобильностью. Модель подходит, когда помимо устройства необходимо контролировать приложения, данные и доступ в мобильных сценариях.

UEM (Unified Endpoint Management) — это унифицированное управление конечными устройствами. UEM применяют для общей модели управления мобильными устройствами, ноутбуками и рабочими станциями.

MDM строится от устройства к политике. EMM — от мобильного рабочего сценария к приложению и данным. UEM расширяет границы до всего парка конечных устройств. Модели различаются объектом управления. Выбирают ту, чьи границы совпадают с периметром пилота: более широкая модель не означает более зрелую.

Базовое значение — это исходный показатель за определенный период до пилота, измеренный из указанного источника данных. Для сопоставимости берут одинаковые периоды. Например, 4 недели до запуска и 4 недели работы пилотной группы после стабилизации настроек.

В пилотную группу входят сотрудники с разными устройствами, ролями и сетевыми условиями. Офис, удаленная работа, выездной персонал, склад или торговая точка. В состав включают ИТ, ИБ и сервис-деск.

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

Время отзыва доступа считают в двух вариантах. Медиана описывает обычную ситуацию. 95-й перцентиль фиксирует задержки в сложных случаях. Среднее искажает картину. Если десять отзывов заняли по 15 минут, а один — 20 часов, среднее составит около двух часов. Такая цифра не описывает ни типичный случай, ни худший: медиана останется 15 минут, а реальная задержка — 20 часов.

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

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

Соответствие политикам нельзя измерять только в последний день пилота. Нужны показатели динамики: время вне политики, ограничения доступа и число случаев ручного вмешательства.

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

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

Четыре KPI не допускают компромиссов: отзыв доступа, выполнение обязательных политик, журналирование административных действий и работа интеграций, от которых зависит доступ к корпоративным данным.

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

Для сравнения фиксируют:

Сначала сравнивают одинаковые сценарии для одинаковых типов пользователей. Затем отдельно показывают исключения: устройства с устаревшей версией ОС, личные устройства сотрудников, пользователей с несколькими рабочими устройствами, площадки с нестабильными каналами связи и роли с расширенными правами доступа. Если во время пилота изменился процесс увольнения, сокращение времени отзыва нельзя относить только к мобильной платформе.

Контрольная группа полезна, если это допустимо по требованиям ИБ и организации работы. Одна группа проходит новый сценарий. Другая временно остается на старом. Разница в показателях помогает отделить результат мобильной платформы от обучения, сезонной нагрузки и изменений в сервис-деске.

Не все удается выразить в цифрах, поэтому ограничения измерения прямо называют в отчете.

TCO (Total Cost of Ownership) — это совокупная стоимость владения мобильной платформой за выбранный период, включая внедрение, лицензии, интеграции, эксплуатацию, ИБ и поддержку.

ROI (Return on Investment) — это отношение чистого финансового эффекта к TCO за один и тот же период. Чистый финансовый эффект равен подтвержденному финансовому эффекту за вычетом TCO.

Стоимость пилота зависит от состава работ, числа устройств, интеграций, требований ИБ и модели поставки. Ориентир формируется после диагностики.

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

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

Формула:

ROI = (подтвержденный финансовый эффект − TCO) / TCO × 100 %.

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

В России критерии пилота зависят от внутренних требований ИБ, правил обработки персональных и корпоративных данных, используемых ОС и архитектуры корпоративных систем. Эти условия ИБ и юридическая функция согласуют до подключения пилотной группы к обезличенным или тестовым данным.

В перечне проверяемой совместимости могут быть Astra Linux, РЕД ОС, Альт; Аврора (мобильная). Для каждой ОС фиксируют поддерживаемую версию, доступные политики, способ регистрации и ограничения по корпоративным приложениям.

Отдельно проверяют:

Для SIEM нужны идентификатор устройства, пользователь, время, результат применения политики и административное действие. Нужна также корреляция с событием доступа.

Go означает переход к масштабированию, no-go — остановку работ. Между ними есть третий исход — доработка: часть критериев выполнена, но для запуска нужно изменить настройки, интеграции или процессы. Пороги для каждого исхода согласовывают до начала пилота.

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

Типичная ошибка — единый итоговый балл. Пилот может набрать 90 баллов из 100 и остаться непригодным для масштабирования. Достаточно одного невыполненного обязательного критерия ИБ.

Владельца go/no-go фиксируют заранее. Обычно решение готовит совместная группа ИТ, ИБ, владельца бизнес-процесса и финансовой функции. Утверждает его руководитель, отвечающий за бюджет и риск.

Один набор измерений представляют в трех форматах. ИТ нужны технические детали. ИБ — доказательства соблюдения политик. Руководству — вывод о риске, бюджете и экономике.

В отчете нельзя смешивать факт и прогноз. Факт: «за 4 недели 48 из 50 участников завершили регистрацию». Прогноз: «при масштабе 5 000 устройств трудозатраты сократятся на 30 %». Для прогноза нужны формула, допущения и владелец расчета.

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

Достаточный набор включает регистрации, соответствие политикам, время отзыва доступа, инциденты, обращения в сервис-деск, трудозатраты администраторов, TCO и ROI. Для каждого показателя нужны база, цель, факт и источник данных.

Количество устройств подтверждает охват пилота, но не безопасность, работоспособность интеграций и стоимость сопровождения. Масштабирование обосновывают выполнением обязательных KPI, а не объемом регистраций.

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

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

Основанием служит выполнение заранее согласованных блокирующих критериев безопасности и интеграций, достижение целевых KPI эксплуатации и утвержденная модель TCO с понятными допущениями по ROI.