Точки взаимодействия с потребителем в путешествии заказчика определяются путем анализа этапов путешествия и сопоставления их с видами деятельности потоков создания ценности. Необходимо выделить те шаги, где происходит прямой контакт между потребителем и провайдером - это и будет полоса видимости. Проходя через этапы путешествия (Offer, Agree, Co-create и другие), потребитель взаимодействует с провайдером, и некоторые из этих взаимодействий приводят к запуску потоков. Для детального определения точек взаимодействия нужно проанализировать, на каких этапах путешествия происходит предъявление спроса потребителем и какие потоки при этом запускаются.

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

При создании сервисного предложения необходимо учитывать несколько аспектов ценности. Прежде всего, следует определить, какие элементы продукта или услуги наиболее важны для потребителя: это могут быть такие факторы, как цена, качество, надежность, простота использования, эмоциональная привлекательность и социальная значимость. Нужно также учитывать, что ценность оценивается на разных стадиях — до и после покупки, и может меняться со временем. Важно интегрировать в сервисное предложение не только товары (goods), но и доступ к ресурсам (access to resources), а также сервисные действия (service actions). Например, в кафе ценность формируется не только кофе как товара, но и атмосферой помещения, качеством обслуживания, возможностью провести время с друзьями.

Да, связи влияния в CMDB являются достаточными для расчёта TCO с некоторыми оговорками. Поскольку главная задача CMDB — определение влияния одних элементов на другие, эти связи отражают использование ресурсов, что непосредственно связано с распределением стоимости. Например, если сервер зависит от системы хранения данных и использует её ресурсы, то доля стоимости системы хранения может быть включена в TCO приложения, установленного на этом сервере. Это позволяет создать достаточно точную модель распределения затрат без необходимости введения специальных «экономических» связей в CMDB.

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

Важность способности объяснять сложные технические аспекты простым языком обусловлена необходимостью эффективной коммуникации между IT и бизнесом. Опытные разработчики (миддл и сеньор) должны уметь излагать смысл своей деятельности, трудности, с которыми они сталкиваются, и обосновывать выбор решений, потому что: 1) это помогает бизнесу понимать ценность и стоимость технических решений; 2) предотвращает накопление технического долга из-за непонимания логической структуры системы; 3) современное программирование становится более верхнеуровневым и близким к человекопонятному языку, поэтому это должно быть проще. В тексте прямо указано, что это «the must», особенно учитывая, что части технического долга возникают из-за несостыковок в логической продуманности системы.

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

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

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

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