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

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

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

Наклейки со штрих-кодированием могут быть предпочтительнее RFID-меток в ряде случаев благодаря более простой технологии и меньшей стоимости. Они не требуют сложной настройки оборудования для считывания, дешевле в приобретении и проще в использовании, особенно если речь идёт о небольших объемах или условиях, где не требуется высокая степень автоматизации. Штрих-коды также менее чувствительны к препятствиям, чем RFID-метки, и позволяют легко визуально контролировать правильность сканирования, что повышает их надежность в определенных сценариях применения.

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

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

Международная ассоциация менеджеров по управлению ИТ-активами (IAITAM) проводит анализ лицензионных соглашений, фиксируя распространенные условия и рекомендации в своей библиотеке IBPL. Также стандарт ISO 19770 регламентирует подходы к управлению активами ПО и включает рекомендации по соответствию лицензионным соглашениям.

Добавление показателя качества в методику EVM не решает основной проблемы оценки проектов, так как главная проблема связана с показателем SPI, который некорректно оценивает соблюдение сроков завершенных проектов. Даже имея информацию о качестве, мы не сможем получить объективную оценку соблюдения временных рамок, поскольку SPI по завершении проекта всё равно будет показывать значение 1, не отражая реального отставания в сроках выполнения. Таким образом, проблема не в отсутствии показателя качества, а в принципиальной недостаточности SPI как метрики для оценки сроков проекта.

В анализе дерева отказов (FTA) применяются следующие основные типы логических связей: «И» (AND) – событие происходит только при одновременном возникновении всех входящих событий; «ИЛИ» (OR) – событие происходит при возникновении хотя бы одного из входящих событий; «Исключающее ИЛИ» (XOR) – событие происходит при возникновении ровно одного из входящих событий; «НЕ» (NOT) – инверсия, событие происходит только если базовое событие не произошло. Правильное применение этих связей критически важно для точности анализа, так как неправильный выбор логической операции может существенно исказить оценку вероятности топ-события. Например, при использовании «ИЛИ» вместо «И» оценка вероятности будет завышена, так как предполагается, что достаточно одного из условий, а не всех сразу.

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