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

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

Оценка успеха внутренних inhouse продуктов сложнее по нескольким причинам: во-первых, пользовательская база значительно уже, что затрудняет сбор репрезентативной обратной связи; во-вторых, между покупателем (спонсором) и непосредственным пользователем часто существует разрыв интересов и потребностей; в-третьих, цикл адаптации и внедрения продукта занимает значительное время (обычно 3+ месяцев); в-четвертых, отсутствует возможность многократного предложения продукта в случае неудачи; в-пятых, финансовая успешность продукта может не напрямую коррелировать с его функциональными характеристиками из-за дискретности продаж и специфики корпоративных решений. Также возникают сложности с получением данных об использовании продукта из-за организационных и технических ограничений внутри компании. Для объективной оценки успеха таких продуктов требуется создание отдельных каналов коммуникации с покупателем и пользователями, измерение TTV (Time-To-Value) - времени достижения ценности продуктом для заказчика, и учет специфики требований разных клиентов.

Владелец услуги (service owner) отвечает за сквозное управление конкретной ИТ-услугой, тогда как менеджер уровня услуг фокусируется на достижении и соблюдении договоренностей об уровне услуги между поставщиком и заказчиком. В ITILv3 есть таблица сравнения этих ролей (Table 6.8 Comparison of CSI manager, service level manager, service owner and business relationship manager roles), но эта таблица скорее порождает вопросы, чем дает четкие ответы о границах ответственности между этими ролями. На практике в большинстве организаций найти достаточно убедительный ответ на вопрос о проведении границы ответственности между этими ролями сложно.

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

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

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

При замене системы необходимо: 1) Составить перечень архивируемых системных ролей из старой системы и новых ролей из новой. 2) Создать таблицу соответствия 'старая-новая' роль для выявления аналогов. 3) Архивировать роли старой системы после перехода и обновить бизнес-роли (которые включали старые системные роли), заменив их на новые. 4) Назначить пользователям обновлённые бизнес-роли через новые записи доступа. Например, если в старой системе роль 'Кассир' соответствует новой роли 'Оператор кассы', бизнес-роль 'Финансовый сотрудник' будет перестроена под новый набор системных прав.

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

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