Готовность команды к работе в самоорганизующейся модели зависит от нескольких факторов: уровень компетенции каждого участника, способность принимать решения и брать на себя ответственность, навыки коммуникации и взаимодействия в команде. Команда должна быть способна самостоятельно ставить цели, распределять задачи и решать конфликты. Для проверки готовности может потребоваться переходный период, в течение которого команда будет постепенно освобождаться от традиционного управления. Важно, чтобы все участники разделяли общие ценности и понимали цели компании. Если команда не обладает достаточной степенью зрелости, переход может оказаться неэффективным и привести к снижению производительности.

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

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

Основные факторы, мешающие развитию клиентоориентированных компаний: спрос, превышающий предложение, отсутствие здоровой конкуренции, низкие ожидания клиентов и культурные особенности бизнеса. Владельцы компаний руководствуются принципом "пока карась жирный идёт", считая излишним тратить средства на улучшение обслуживания. Также отсутствует давление со стороны клиентов, так как у них мало альтернатив. Рынок не стимулирует инновации в сервисе, и компании фокусируются на решении базовых задач, игнорируя долгосрочные стратегии удержания клиентов через качественный сервис.

Небольшие улучшения отличаются от масштабных организационных изменений по нескольким ключевым признакам: 1) Масштаб воздействия - небольшие улучшения затрагивают отдельные процессы или небольшую группу сотрудников (например, добавление нового способа взаимодействия с Service Desk), тогда как масштабные изменения влияют на всю организацию или её существенную часть и часто серьёзно затрагивают внешних контрагентов. 2) Сложность реализации - небольшие улучшения, как правило, не очень сложно реализовать на практике, в то время как масштабные инициативы во многих случаях даются непросто. 3) Ресурсные требования - крупные изменения требуют задействования более половины ИТ-сотрудников и затрагивают сотрудников бизнес-подразделений, тогда как небольшие улучшения могут быть реализованы небольшой командой. 4) Уровень сопротивления - масштабные изменения сталкиваются с более сильным индивидуальным и системным сопротивлением, поскольку затрагивают больше людей и процессов. 5) Требования к руководству - небольшие улучшения могут быть успешно реализованы менеджерами, работающими по установленным процессам, тогда как масштабные преобразования требуют лидеров, способных работать в условиях неопределенности и риска.

Для явного выделения вклада процессов в повышение качества ИТ-услуг необходимо формулировать цели развития каждого процесса через его конкретное назначение. Например, для управления инцидентами цель формулируется как 'Что можно сделать, чтобы инциденты решались быстрее?', а для управления проблемами — как 'Что можно сделать, чтобы инцидентов стало меньше?'. Каждая формулировка должна соответствовать критерию SMART, быть измеримой и ориентированной на потребности клиентов. Важно, чтобы развитие процессов напрямую связывалось с их ролью в обеспечении качества ИТ-услуг через конкретные действия и результаты.

Для взаимодействия проектного офиса, разработчиков и эксплуатирующих подразделений необходимы следующие основные типы регламентирующих документов: 1) Документ, определяющий основные стадии создания новой автоматизированной системы (АС) или выполнения доработок, обычно называемый «Положение о разработке прикладного ПО». Он содержит описание состава работ, ответственных лиц, входных и выходных документов для каждой стадии. Важная особенность – вовлечение эксплуатирующих подразделений в определение требований и проектирование АС. 2) Документ, определяющий порядок приёмки новых АС в эксплуатацию, который может быть частью первого документа и обычно называется «Положение о внедрении информационных систем». Он включает определение порядка и охвата тестирования, подготовки тестовых сред, опытной эксплуатации и других аспектов. Может дополняться политиками релизов. 3) Документ, определяющий архитектурные и технологические стандарты, распространяющиеся на разработку новых решений. Включает определение допустимых языков и сред разработки, используемых платформ и СУБД, механизмов развёртывания, требований к интерфейсам, резервированию, мониторингу, журналированию и другим техническим аспектам. Эти документы образуют совокупный регламент управления изменениями и релизами в части разработки и внедрения прикладного программного обеспечения.

Запрос на получение информации о текущем статусе инцидента должен обрабатываться в процессе Управление инцидентами (Incident Management, INC). Этот процесс несёт ответственность за обеспечение прозрачности работы с инцидентами, включая коммуникацию информации о статусе инцидента. В ITIL Service Operation явно указано, что обеспечение прозрачности является частью задач процесса INC. В примере критических факторов успеха упомянут KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов», что подразумевает необходимость минимизации таких запросов за счёт качественной коммуникации в рамках INC. Хотя процесс Управления запросами на обслуживание (Request Fulfillment Management, RFF) может использоваться как канал передачи информации, основная ответственность за организацию коммуникации и прозрачность лежит на INC, поэтому именно этот процесс должен отрабатывать запросы о статусе инцидента.

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

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