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

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

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

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

Для определения нагрузки на ИТ-системы с помощью среднего чека сначала вычисляется количество сделок, необходимых для достижения плана продаж. Допустим, план продаж составляет 1440 млн рублей при среднем чеке в 10 тысяч рублей. Это означает, что в месяц нужно совершить около 12 000 сделок. Затем, учитывая выработку одного продавца (например, 20 сделок в день), можно определить количество пользователей, которые одновременно будут работать в ИТ-системах. Эта информация позволяет спрогнозировать поток запросов к ИТ-системам и объем обращений в сервисные службы поддержки, что критически важно для правильного планирования ИТ-инфраструктуры и поддержания ее высокой производительности.

В отчете менеджера процесса должны быть два обязательных раздела: первый — 'Что можно сделать для повышения эффективности процесса?', где формулируются предложения по улучшению, соответствующие целям процесса (например, сокращение времени устранения инцидентов). Второй раздел — 'Что уже сделано для повышения эффективности процесса в отчетном периоде и какие получены результаты?'. Эти разделы фокусируют внимание на конкретных действиях и их измеримых результатах, а не только на автоматизированных KPI.

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

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

Учет полосы видимости важен при анализе путешествия заказчика, потому что именно в этой зоне формируется клиентский и пользовательский опыт (CX/UX). Полоса видимости включает те виды деятельности потоков создания ценности, которые непосредственно взаимодействуют с потребителем. Хотя значительная часть работы провайдера может происходить "за кулисами" и быть не видна клиенту, именно точки контакта в полосе видимости определяют общее впечатление потребителя об услуге. Улучшая эти точки взаимодействия, провайдер может целенаправленно управлять клиентским опытом и повышать удовлетворенность клиентов, что критически важно для успешного предоставления услуг.

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