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

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

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

Для определения владельца сквозного процесса необходимо проанализировать обязательные обязанности этой роли по каждому пункту из выбранного источника (например, ITIL), затем оценить степень критичности каждой обязанности для конкретной организации и процесса, используя, например, десятибалльную шкалу. Где 10 баллов означает, что процесс без выполнения этой обязанности 'не выживет' или уже вызывает проблемы. Полученный приоритизированный список требований покажет, какие полномочия и возможности должны быть у владельца процесса в данной организации. Важно учитывать, что для разных процессов и организаций эти требования могут существенно отличаться в зависимости от критичности процесса, уровня сложности, организационной структуры и культурных особенностей. Например, в организациях, только начинающих внедрять процессный подход, владельец часто должен обладать широкими полномочиями, охватывающими все задействованные подразделения.

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

Момент объявления инцидента значительным определяется на основании заранее согласованного и задокументированного определения, утвержденного поставщиком услуг совместно с заказчиком. Любой участник процесса (сотрудник аварийной службы или подразделения поддержки) может объявить инцидент значительным, если ситуация соответствует заранее определенным критериям. После объявления значительного инцидента должна быть активирована специальная процедура, включающая уведомление топ-менеджмента, назначение ответственного лица, организацию совместной работы команд и внедрение специальных мер реагирования. Даже если некоторые службы не видят признаков значительного инцидента, они обязаны следовать установленной процедуре реагирования.

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

Преимущества микросервисной архитектуры включают гибкость и независимость компонентов, что позволяет отдельным командам разрабатывать, тестировать и развертывать сервисы независимо друг от друга. Это ускоряет циклы разработки и позволяет быстрее внедрять новые функции. Микросервисы обеспечивают лучшую отказоустойчивость, поскольку сбой одного сервиса не приводит к остановке всей системы. Архитектура поддерживает использование разных технологических стеков для разных сервисов, что позволяет применять оптимальные решения для конкретных задач. Кроме того, микросервисный подход облегчает масштабирование отдельных компонентов, что повышает общую производительность системы при росте нагрузки на определенные функции.

Проблемы при расчете Flow Efficiency в ИТ-процессах включают несколько аспектов: 1) Сложность определения Time in Process, так как необходимо учитывать только рабочее время, а не календарное, особенно когда члены команды работают по разным графикам или в разных часовых поясах. 2) Невозможность точно измерить Touch Time из-за частых переключений между задачами, перерывов и других видов деятельности во время рабочего дня. 3) Проблема учета времени при совместной работе нескольких исполнителей над одной задачей. 4) Неточность расчета при использовании стандартных инструментов вроде Jira, которые фиксируют изменения статусов задач, но не отражают детальное время непосредственной работы.

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