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

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

Метрика результативности для ИТ-групп рассчитывается как отношение количества инцидентов, решённых данным участником процесса без повторной обработки, к общему количеству инцидентов с участием этой группы. Точная формула: KPI результативности = 1 — (M / N), где N — общее количество инцидентов, решённых за период с участием даной группы, а M — количество инцидентов, которые потребовали повторной обработки этой группой. Метрика нормирована в диапазоне от 0 до 1, где 1 означает идеальную результативность.

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

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

Участие в деловой игре Grab@Pizza развивает множество навыков: способность быстро принимать решения в условиях неопределённости, навыки коммуникации и взаимодействия между различными департаментами (особенно бизнеса и ИТ), понимание процессов ITSM и ITIL, умение приоритезировать задачи и обосновывать бизнес-ценность ИТ-инициатив, навыки управления кризисными ситуациями, лидерские качества и способность работать в команде. Также игра развивает умение анализировать ситуации, находить ошибки в текущих процессах и предлагать решения по их улучшению.

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

Стандарт ISO/IEC 20000:2011, раздел 8.1, предъявляет следующие требования к управлению значительными инцидентами: поставщик услуг должен документировать и согласовать с заказчиком определение значительного инцидента; значительные инциденты должны классифицироваться и обрабатываться в соответствии с документированной процедурой; информация о значительных инцидентах должна доводиться до топ-менеджмента; топ-менеджмент должен назначить ответственного за управление каждым значительным инцидентом; после восстановления согласованного уровня услуг должен быть проведен анализ инцидента с целью определения возможностей по улучшению. Эти требования направлены на обеспечение четкого и эффективного управления кризисными ситуациями, которые существенно влияют на бизнес-процессы заказчика.

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

В рамках IT4IT Reference Architecture концепция цепочки создания ценности (Value Chain), впервые предложенной Майклом Портером в 1985 году, является основой архитектуры. IT4IT представляет ИТ как цепочку создания ценности, где каждый этап добавляет определенную ценность к конечному продукту или услуге. Эта Value Chain в IT4IT состоит из четырех основных потоков: Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). Каждый из этих потоков представляет собой последовательность действий, которые преобразуют первоначальные потребности бизнеса в предоставляемые ИТ-услуги и поддерживают их эксплуатацию. Таким образом, IT4IT адаптирует классическую концепцию цепочки создания ценности применительно к ИТ, организовывая все ИТ-активности в последовательность, направленную на создание ценности для бизнеса.