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

В разделе «о чем просим / что требуем» должно быть четко и конкретно указано действие, которое требуется от получателя. Примеры формулировок: «Прошу Вас содействовать / довести до сведения персонала / назначить ответственных / согласовать расходы на…», «Инициировать проект не позднее …», «Начать работы с …». Если вы что-то требуете, важно ссылаться на соответствующее основание из предыдущего раздела (например, приказ или решения встречи), которое подтверждает ваши полномочия в постановке таких требований. Также желательно указать конкретные сроки выполнения задачи. Четкое формулирование запроса и наличие ссылок на нормативные документы или решения значительно увеличивают вероятность получения нужного ответа в требуемые сроки.

Активация аварийного плана восстановления (disaster recovery plan) необходима, если инцидент продолжается дольше установленного срока без признаков решения. Ответственность за принятие решения об активации плана лежит на менеджере major-инцидента. Этот специалист должен знать правила и процедуры запуска плана аварийного восстановления, чтобы оперативно перейти к следующему уровню реагирования при необходимости, сокращая время простоя критически важных сервисов.

До перехода в консалтинг, когда автор работал на стороне заказчика, рабочая загрузка составляла примерно 70-80% — времени хватало на выполнение всех задач, и даже оставалось время на изучение новых технологий и управленческих методик. После перехода в консалтинг уровень рабочей загрузки вырос до 120-130%, в пиковые периоды достигая 160%. Это привело к тому, что возник острый вопрос о том, как всё успеть, и потребовало поиска решений в области управления временем и повышения личной эффективности.

В контексте управления уровнем ИТ-услуг процесс SLM (Service Level Management) соответствует циклу PDCA (Plan-Do-Check-Act). Этот процесс ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранение несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Таким образом, SLM обеспечивает постоянное улучшение качества ИТ-услуг через планомерное выявление и устранение недостатков.

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

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

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

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

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