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

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

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

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

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

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

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

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

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

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