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

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

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

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

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

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

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

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

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

Измерение востребованности фичи только по статистическим показателям, таким как увеличение конверсии на 0,07% или количество пользователей, открывших меню и сразу закрывших его, может быть недостаточным, потому что такие абстрактные цифры не создают эмоциональной связи у разработчиков с результатом их работы. Для большинства разработчиков это просто бессмысленные числа, которые не мотивируют и не показывают реального влияния их труда. Вместо этого важно демонстрировать живые реакции пользователей: негативные или позитивные отзывы, появление новых запросов связанных с новой опцией, реакции на презентации продукта. Такой подход позволяет разработчикам понять, что их работа имеет значение и действительно влияет на пользовательский опыт, что значительно повышает их вовлеченность и мотивацию.