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

Статистика за 4 недели июня показала, что в настоящее время 65% поездов прибывают точно вовремя (согласно старому определению), а 92% поездов прибывают с 5-минутным отклонением от графика следования. Это означает, что подавляющее большинство поездов уже следуют относительно точно по расписанию, но с введением новых стандартов точность будет измеряться по каждому остановочному пункту, что создает дополнительные сложности для операторов.

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

Сравнение уровня зрелости с принципом суперпозиции квантовой системы обусловлено тем, что процесс в COBIT может одновременно проявлять признаки разных уровней зрелости, подобно тому как квантовая система может находиться в нескольких состояниях одновременно. Это подчеркивает невозможность четкого, дискретного определения уровня зрелости процесса, поскольку он может частично соответствовать уровням 2, 3 и 4 одновременно. Этот подход напоминает квантовую неопределенность, где система не принимает одно определенное состояние, пока не будет произведено измерение.

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

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

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

В методике с динамическими весами при фиксированном MS = 50% (при N=10), интегральная оценка изменяется следующим образом: при провале одного направления (один KPI=0%) интегральная оценка равна 50%; если провалено два направления, интегральная оценка становится равной 31%; при трех проваленных направлениях оценка снижается до 21%. Это демонстрирует, что даже после первого провала продолжение работы в оставшихся областях остается экономически обоснованным, поскольку каждый последующий провал приводит к дальнейшему снижению общей оценки, но не делает ее полностью бессмысленной, как в случае с произведением KPI.

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

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