Process Improvement Plan (PIP) - это план совершенствования процессов. При внедрении ITSM этот план претерпевает существенные изменения и расширяется, становясь планом совершенствования услуг (Service Improvement Plan, SIP). Теперь изменения процессов оцениваются именно с позиции их влияния на качество предоставляемых услуг, а не только с точки зрения оптимизации внутренних процессов.

Управление доступностью и управление непрерывностью тесно связаны, так как оба процесса ориентированы на обеспечение бесперебойной работы ИТ-услуг. В некоторых стандартах, таких как ISO/IEC 20000, они объединены в один процесс. Это обусловлено тем, что оба процесса направлены на предотвращение сбоев и минимизацию их последствий. Управление доступностью фокусируется на обеспечении требуемого уровня доступности услуг, а управление непрерывностью — на восстановлении услуг после инцидентов, связанных с непредвиденными простоями.

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

Необходимость в CI/CD может быть не столь очевидной для команды, которая разрабатывает программное обеспечение для будущего релиза, MVP или первой версии, который запланирован на значительный срок вперед (например, через полгода-год). В таких случаях основная проблема заключается не в организации процесса доставки изменений, а в самом создании работоспособного продукта. До тех пор, пока нет боевой среды с реальными живыми пользователями, внедрение сложного конвейера развёртывания может оказаться преждевременным и отвлекающим от основных задач разработки. В этой ситуации ресурсы команды лучше направить на создание качественного продукта, а вопросы автоматизации процессов доставки и развертывания можно решать уже тогда, когда будет определенность с пользовательской аудиторией и необходимостью частых обновлений.

Три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают: 1. Авторы KPI спроектированного процесса часто слепо копируют рекомендации из "умных" книг (ITIL, COBIT и другие), не учитывая, что приведенные там метрики являются лишь примерами для иллюстрации, а не готовыми решениями, подходящими для конкретной организации. 2. При внедрении KPI часто игнорируется здравый смысл, когда стремятся измерить всё подряд и отвергают субъективные данные (например, опросы удовлетворенности пользователей), хотя некоторые аспекты управления можно и нужно оценивать через удовлетворенность. 3. KPI отдельных процессов проектируются изолированно, без учета их взаимосвязей и места в общей системе управления ИТ. Это создает фрагментарную картину вместо комплексной системы оценки деятельности ИТ-подразделения.

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

Затраты на ИТ-персонал составляют 40-60% операционных затрат, что делает их одной из самых значительных статей расходов. Учитывая, что операционные затраты в среднем составляют около 75% от общего бюджета ИТ, доля затрат на персонал в итоге достигает 30-45% всего ИТ-бюджета, что делает её критически важной для оптимизации.

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

Во втором разделе ITIL Practitioner Guidance описаны следующие руководящие принципы: сохранять фокус на ценности (Focus on Value), работать на людей (Design for Experience), отталкиваться от текущей ситуации (Start where you are), мыслить системно (Work holistically), двигаться небольшими шагами (Progress iteratively), работать «в полях» (Observe directly), быть открытым (Be transparent), вовлекать и работать совместно (Collaborate), упрощать (Keep it simple).

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