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

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

Flow Efficiency представляет собой отношение времени, потраченного на непосредственную работу над созданием ценности (Touch Time), к общему времени, которое задача провела в потоке (Time in Process). Это значение выражается в процентах. Touch Time — сумма всех промежутков времени, в течение которых работа над задачей активно выполнялась (без учета времени ожидания, нахождения в очередях и т.д.). Time in Process — общее время, в течение которого задача находилась в рассматриваемом состоянии системы, обычно совпадающее с Lead Time — периодом от момента начала работы до момента завершения.

Бизнес-услуга (или customer-facing service в терминах ITIL V3) - это услуга, которая непосредственно предоставляется заказчику и на которую заключается соглашение об уровне услуги (SLA). Это видимая для клиента услуга, с которой он непосредственно взаимодействует. Примером может служить комплексное ИТ-обеспечение процесса продаж или бухгалтерского учета, которое клиент заказывает и использует напрямую.

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

Предпроектное обследование экономически оправдано, так как оно позволяет снизить проектные риски и точно определить объем работы, что в итоге приводит к значительной экономии средств. В конкретном примере, приведенном в тексте, предварительная бюджетная оценка проекта сократилась в 4 раза после проведения обследования, при этом стоимость самого обследования составила всего 1,5% от суммы сэкономленных средств. Для консультационных проектов обследование считается экономически эффективным, если его стоимость не превышает 5-10% от общей стоимости проекта, особенно учитывая, что стандартные риски при неопределенной постановке задачи обычно начинаются от 10%.

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

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

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

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