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

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

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

Автор статьи считает, что громкие формулировки миссий могут вызывать скептицизм у сотрудников, потому что на практике реальная работа часто не соответствует грандиозным декларациям компании. Например, миссия Asana, которая «помогает человечеству процветать», кажется преувеличенной, если продукт компании представляет собой всего лишь менеджер задач. Когда слова не подкреплены реальными делами и достижениями, сотрудники начинают воспринимать подобные заявления как «высокопарную муть». Люди, наученные опытом и критическим мышлением, быстро научатся игнорировать такие формулировки. Таким образом, если компания стремится использовать миссию для мотивации сотрудников, важно, чтобы эта миссия была реалистичной и подкрепленной конкретными действиями.

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

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

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

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

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

Для эффективного планирования и во избежание накопления задолженностей рекомендуется запланировать уровень загрузки на 90-110%, а не на 150% или выше. При планировании работ на уровне 150% загрузки существует высокая вероятность, что вся запланированная работа не будет выполнена вовремя, что приведет к двум негативным последствиям: привыканию к переносам сроков как норме и накоплению снежного кома задолженностей и просрочек. Такой подход является тупиковым. Гораздо более продуктивным является принцип 'just-in-time', при котором планируется загрузка близкая к 100% с акцентом на точное исполнение запланированных работ. Такой метод требует дисциплины и, возможно, дополнительных усилий для формирования привычки к своевременному выполнению задач, но в долгосрочной перспективе приводит к росту исполнительской дисциплины, позволяет лучше анализировать деятельность и обосновывать потребность в дополнительных ресурсах при необходимости.