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

Для адаптации формулы FTR к расчёту в разрезе рабочих групп необходимо уточнить определение операнда Nj, заменив его суммой успешных решений (Cj) и возвратов на доработку (Sj). Формула принимает вид: FTR = (Nj - Sj) / Nj, где Nj = Cj + Sj. Также важно учитывать возвраты по каждой группе индивидуально, чтобы избежать искажения результатов из-за переназначения инцидентов между группами или повторных возвратов.

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

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

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

Для пересмотра процесса управления конфигурациями следует выполнить следующие шаги: 1) Определить, кто из заинтересованных сторон может получать ценность от информации о конфигурациях. 2) Поговорить с ними о их рабочих процессах и выяснить, какая информация будет для них полезна. 3) Наглядно продемонстрировать, как информация о конфигурациях может быть использована для создания ценности. 4) Пересмотреть политики управления конфигурациями с учётом этой информации. 5) Перепроектировать процесс, чтобы он фокусировался на создании ценности. 6) Убедиться, что CMDB соответствует своей цели. 7) Разработать программу обучения и коммуникации по вариантам использования CMDB. 8) Внедрить мониторинг и отчёты, основанные на реальном использовании системы.

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

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

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

Для распределения стоимости услуг по потребителям существуют несколько методов. Самый простой метод – пропорциональное распределение на основе количественных показателей потребления, таких как количество пользователей, объем обрабатываемых данных или время использования. Более сложный метод – Activity-Based Costing (ABC), который учитывает различные виды деятельности, необходимые для предоставления услуги, и распределяет издержки на основе реального потребления ресурсов. Также применяется метод распределения по ключевым показателям эффективности (KPI), когда стоимость распределяется в зависимости от важности услуги для достижения стратегических целей бизнеса. Выбор метода зависит от сложности ИТ-инфраструктуры, требований к точности расчетов и уровня зрелости бюджетного процесса в компании.