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

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

Ошибка восприятия канбана как простого списка задач заключается в том, что канбан – это не только визуализация задач, сложенных по статусам ("Надо сделать", "Делаем", "Сделано"), но и инструмент управления потоком работы. Настоящий канбан позволяет выявлять узкие места процесса, устанавливать ограничение на количество задач в работе одновременно (WIP limit) и организовывать вытягивающую систему производства, где следующий этап берёт задачу только после освобождения предыдущего этапа. Простое размещение задач на доске без соблюдения этих принципов не делает процесс настоящим канбаном.

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

Реактивная часть управления доступностью относится к учету и регистрации фактов и периодов недоступности услуги. Она включает мониторинг и измерение доступности через фиксацию инцидентов недоступности. Этот процесс позволяет отслеживать, когда и как долго услуга была недоступна, а также выявлять причины и последствия простоев. Особенно важно это при массовых инцидентах, которые имеют высокую вероятность стать инцидентами недоступности, так как они直接影响 точку потребления услуги и требуют коммуникации с пользователями.

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

Идеализированный вариант «Клиенты мечты» (высокая отзывчивость и высокая полезность) редко встречается в реальности, так как активные и конструктивные клиенты обычно слишком заняты личными делами, чтобы тратить время на детализацию отзывов. По оценкам, более 99,9% полезной обратной связи поступает в формате «Hard Candy» — кратких, но ценных замечаний. Идеальные клиенты, готовые подробно делиться опытом и предлагать решения, нехарактерны для массового сегмента, так как их вовлеченность требует значительных временных затрат, которых большинство потребителей не готовы выделить.

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

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

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