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

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

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

Уровень Business Capacity Management определяется как управление мощностью на уровне бизнес-процессов. Этот подпроцесс используется, когда ИТ-услуга ассоциируется с поддержкой конкретных бизнес-процессов (например, кредитование, закрытие операционного дня, продажи). Он включает прогнозирование нагрузок на основе бизнес-требований, трансляцию этих требований в системные и ресурсные ограничения. Business Capacity Management необходим только в том случае, если услуги определены на уровне бизнеса, и не требуется, если услуги ограничены на уровне систем или ресурсов.

RASCI-матрица - это расширение классической RACI-матрицы, где к стандартным ролям добавлено дополнительное значение S (Supports). Стандартные значения в RACI расшифровываются как: R (Responsible) - непосредственный исполнитель задачи, A (Accountable) - ответственный за конечный результат, C (Consulted) - те, кого нужно проконсультировать в процессе выполнения задачи, I (Informed) - те, кого нужно информировать о результатах. В RASCI добавляется S (Supports), что означает участников, которые поддерживают выполнение задачи и вносят вклад в результат, но не несут ответственности за процесс или конечный результат. Это позволяет более точно распределить роли, особенно когда в задаче участвует большое количество людей, и четко разделить тех, кто организует работу, и тех, кто просто оказывает поддержку в процессе выполнения.

Несмотря на недостатки при оценке сроков, метод EVM остаётся полезным при управлении проектами благодаря показателю Cost Performance Index (CPI), который эффективно оценивает соответствие проекта бюджету. CPI позволяет отслеживать соотношение запланированной стоимости выполненных работ к фактическим затратам, что помогает менеджерам проекта выявлять проблемы с финансовым контролем на ранних этапах. Метод EVM также предоставляет комплексную систему оценки текущего состояния проекта по стоимости и выполненным работам, что делает его ценным инструментом для текущего мониторинга проекта.

Основное отличие между использованием метрик EVM для текущих и завершённых проектов заключается в том, что при анализе текущих проектов SPI (Schedule Performance Index) адекватно отображает отставание от графика, но для завершённых проектов этот показатель становится равным единице, независимо от реальных задержек, так как весь объём работ к этому моменту уже выполнен. В то же время, показатель CPI (Cost Performance Index) остаётся полезным на всех этапах проекта, поскольку он корректно отражает соотношение стоимости работ и фактических затрат, как в процессе выполнения, так и после завершения проекта.

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

Автор считает, что должен существовать промежуточный уровень между USM и eSCM-SP, потому что USM слишком простой, а eSCM-SP слишком сложный для практического применения. Автор видит потребность в подходе, который будет близок по сложности к eTOM, но с возможностью обобщения на различные виды услуг, а не только телекоммуникационные. Такой промежуточный уровень должен сохранить простоту понимания USM, иметь достаточную детализацию, чтобы быть практически полезным, и не быть перегруженным сложностью eSCM-SP, что сделало бы его малоприменимым для многих организаций.

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