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

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

Согласно статистическим расчетам, необходимое количество ответов для достижения заданной точности не зависит от размера генеральной совокупности при достаточно больших популяциях (более 1000 человек). Это связано с тем, что формула расчета доверительного интервала для среднего значения в основном зависит от стандартного отклонения и размера выборки, но не от общего числа элементов в популяции. Именно поэтому для 1000 и даже для 10000 пользователей достаточным остается выборка в 40-50 человек при пятибалльной шкале опроса.

В контексте процесса управления релизами релиз определяется по-разному в зависимости от организационной модели: если управление релизами осуществляется в подразделении разработки/сопровождения, то релиз представляет собой набор компонент, которые вместе тестируются и внедряются в продуктивную среду; если управление релизами функционирует в подразделении эксплуатации, то релиз определяется как набор изменений, которые вместе тестируются и внедряются в продуктивную среду. Общим является то, что релиз объединяет логически связанные изменения для совместного внедрения.

Эффективная работа с поставщиками услуг в рамках ITIL строится на четком определении ожиданий и метрик успеха. Сначала создайте каталог услуг, описывающий все услуги, предоставляемые как внутренними, так и внешними поставщиками, с четкими SLA и OLAs. Тщательно проработайте договоры с поставщиками, включив в них измеримые KPI и последствия за их невыполнение. Установите регулярные встречи с ключевыми поставщиками (не реже раза в месяц) для обсуждения выполнения SLA, выявления проблем и планирования улучшений. Создайте единую систему управления инцидентами, которая включает как внутренние, так и внешние поставщики, чтобы обеспечить сквозное отслеживание проблем. Внедрите процесс управления поставщиками (Supplier Management), который включает оценку, выбор, управление отношениями и выход из отношений. Обеспечьте прозрачность затрат поставщиков через регулярные финансовые отчеты и анализ стоимости услуг. Для критически важных поставщиков создайте совместные планы непрерывности бизнеса. Проводите регулярные аудиты поставщиков для проверки соответствия требованиям безопасности и качества. Внедрите систему оценки поставщиков на основе их вклада в бизнес-результаты компании, а не только технических показателей.

Для организаций с простыми сервисными моделями, где услуги основаны в первую очередь на деятельности персонала, а технологии играют второстепенную роль, полезными будут следующие процессы ITIL: управление уровнем услуг (SLA), управление инцидентами и управление знаниями. Эти процессы помогут организовать работу с клиентами, эффективно решать возникающие проблемы и систематизировать информацию, что улучшит качество предоставляемых услуг без необходимости внедрения сложных ИТ-структурированных процессов.

При внедрении системы категоризации инцидентов чаще всего допускаются следующие ошибки: создание слишком сложной схемы категоризации с множеством уровней и подкатегорий, что затрудняет ее использование; недостаточное обучение персонала работе с системой категоризации; отсутствие вовлечения一线 сотрудников в процесс разработки схемы; игнорирование необходимости регулярного обновления системы категоризации по мере изменения бизнес-требований; недостаточная документация правил категоризации; отсутствие интеграции с другими системами ITSM; попытка внедрить слишком много изменений одновременно без пилотного тестирования; отсутствие измерения эффективности системы категоризации через KPI; недостаточное внимание к автоматизации процесса категоризации; игнорирование обратной связи от пользователей системы. Эти ошибки могут значительно снизить эффективность системы категоризации и даже привести к ее непринятию сотрудниками.

Деловая игра 'Проект Феникс' демонстрирует, что кратное ускорение действительно возможно без смены персонала. На начальном этапе участники, работая как в обычных компаниях, показывают низкую эффективность: Time to Market составляет около 25 минут на задачу, а процент завершённых задач - 25-50%. К концу дня, после осознанного подхода к организации работы - правильной приоритизации задач, управлению потоком и внедрения ограничений на текущую работу - Time to Market снижается до 40 секунд - 1,5 минуты, а процент завершённых задач возрастает до 85-100%. Это подтверждает, что системные изменения в организации процессов, даже без изменения архитектуры и технологий (в рамках игры такие изменения невозможны), могут привести к ускорению в 15-25 раз.

Сложность сервисных отношений значительно влияет на определение состава заказчиков ИТ-услуг, так как в условиях Value network может возникнуть неоднозначность в определении, кто является истинным заказчиком. Например, когда одно подразделение отвечает за продажи продукта, а другое за бэк-офисные операции, но оба влияют на требования к ИТ-услуге, возникает вопрос о том, какой из них считать заказчиком. Это влияет на то, с кем заключать SLA, как распределять затраты и нести ответственность. Сложность может привести к необходимости либо выделять отдельных заказчиков для каждого аспекта услуги, либо определять основного заказчика, ответственного за взаимодействие с ИТ-подразделением, что требует четких внутренних договоренностей между бизнес-подразделениями. В результате, вместо простого определения заказчика в линейной цепочке, возникает сложная задача структурирования клиентских отношений в рамках Value network.

При формировании SLA с различными графиками работы групп рекомендуется сегментировать типы обращений по группам, которые их обрабатывают. Вместо попытки определить пересечение всех графиков (которое может быть очень узким или даже пустым в случае с разными часовыми поясами), можно разделить виды обращений: например, предоставление прав доступа обрабатывается одной группой по определенному графику, а решение проблем на рабочем месте пользователя – местной командой. Для каждого вида обращений тогда можно установить собственный календарь обработки. Также может потребоваться изменение графиков работы под необходимые бизнес-требования: введение дежурных служб, обеспечение удаленной поддержки или экстренной помощи.