Экзамен CIMA Dip PM, который автор сдала с первой попытки на 71%, оказался не просто историей про сертификат. Для русскоязычной IT-аудитории здесь важнее другое: CIMA в IT помогает не столько аккуратно сводить цифры, сколько принимать решения в условиях дефицита ресурсов, риска и постоянно меняющихся вводных.
Об этом пишет Habr / Карьера в колонке руководителя проектов в IT и эксперта по финансовому учёту Ольги Гродской. Автор пришла к обучению с сильной базой: бухгалтерский и управленческий учёт, МСФО, бюджетирование, автоматизация затрат. Но в процессе подготовки всплыло знакомое многим менеджерам в технологиях ограничение: опыт хорошо учит считать прошлое, а вот экономику будущих решений объясняет куда хуже.
Почему CIMA оказалась ближе IT-руководителю
Выбор между ACCA и CIMA автор объясняет прагматично. ACCA чаще связывают с карьерой профессионального бухгалтера, а CIMA оказалась ближе к роли руководителя, операционного менеджера и владельца бизнеса.
Экзамен включал четыре крупных блока: учёт затрат, бюджетирование, краткосрочные управленческие решения, риск и неопределённость. Подготовка заняла около двух с половиной месяцев: одно занятие в неделю, практические задания между ними, неравномерная нагрузка и ставка не столько на учебник, сколько на список тем, банк задач и разбор формулировок. Отдельно помогал ИИ, но не как генератор ответов, а как инструмент для объяснения сложных тем и проверки логики решения.
Самым сложным навыком оказалась не арифметика. По словам автора, основные ловушки прятались в формулировках вроде «укажите неверное утверждение», где легко среагировать на знакомый вариант и промахнуться. Но главный вывод лежит не в плоскости экзаменационной техники. CIMA показала, что привычные финансовые блоки работают не как набор формул, а как способ иначе смотреть на продуктовые, проектные и операционные задачи.
Учёт затрат и ограничения команды
Первое сильное наблюдение касается учёта затрат. В инженерных и IT-проектах стоимость заказа часто считают по привычной схеме: к базе добавляют проценты, наценки, резервы и накладные расходы. На бумаге всё выглядит аккуратно, но экономический смысл такого расчёта бывает сомнительным.
Маржинальный подход заставляет задавать другие вопросы: какие расходы реально появятся из-за нового заказа, какие затраты компания понесёт в любом случае, есть ли свободная мощность, какой вклад заказ даст в покрытие постоянных расходов и нет ли для тех же ресурсов более выгодной альтернативы. Для IT-бизнеса разница принципиальная. Вопрос «какую прибыльность должен показать проект» звучит солидно, но часто сводится к механическому пересчёту сметы. Вопрос «станет ли компании лучше, если этот проект взять» уже ближе к управленческой экономике.
Вторая идея связана с теорией ограничений. Обычно её объясняют на примере завода и станков, но в IT она работает не хуже. Узким местом команды нередко становится не весь отдел, а конкретный человек: ведущий архитектор, главный инженер или редкий доменный эксперт, через которого проходит финальная проверка решений. Такой специалист дорогой, перегруженный и плохо масштабируется.
Вместо попытки срочно найти «второго такого же» автор предлагает защищать время дефицитного эксперта. В эту схему можно встроить ИИ для предварительной проверки исходных данных, контроля комплектности документации, поиска противоречий между разделами, первичной оценки качества и подготовки вопросов для экспертного разбора. ИИ здесь не заменяет ответственного специалиста. Он просто отсекает рутину, чтобы редкий ресурс тратился на действительно сложные и дорогие задачи.
Бюджетные отклонения и ошибка невозвратных затрат
Третий блок связан с отклонениями от бюджета. Формально все знают, что отклонения бывают разными, но на практике их часто складывают в одну корзину. Курс помог автору чётче разделить плановые и операционные причины: одно дело, когда результат ухудшился из-за внешней среды, и совсем другое, когда компания сама закупила дороже, потратила больше ресурсов или не дотянула до плановой производительности.
Для IT-менеджмента это чувствительная тема. Стоит смешать рыночные факторы с внутренними ошибками, и компания либо накажет менеджера, который хорошо отработал кризис, либо спишет собственные промахи на «сложный рынок». Отсюда и практический разворот к анализу чувствительности, сценарному прогнозированию и стресс-тестам. Не просто «что будет со сметой при изменении сроков», а «какой параметр процесса даёт наибольший эффект».
В проектах, где ИИ помогает готовить документацию, таким параметром может быть скорость проверки, число итераций согласования или доля типовых разделов, которые можно частично автоматизировать. Для продуктовых и проектных команд такой сдвиг полезен: он заставляет не пересчитывать проблему бесконечно, а искать переменную, на которую действительно стоит влиять.
Ещё одно важное открытие автора — тема релевантных затрат. Команды часто продолжают проект, функцию или направление не потому, что они остаются выгодными, а потому, что в них уже слишком много вложили: денег, времени, репутации и нервов. Ошибка невозвратных затрат хорошо знакома любому, кто тянул неудачную интеграцию, слабый продуктовый эксперимент или бесконечный внутренний проект «ещё один квартал». Экономика решений требует отсечь уже понесённые потери как не относящиеся к выбору и смотреть только на будущие затраты и эффекты.
Значение для рынка
Для русскоязычных IT-команд здесь полезен очень практичный вывод: хороший расчёт и хорошее управленческое решение — не одно и то же. Рынок уже перегружен отчётностью, автоматизацией и AI-инструментами, но дефицит остаётся в другом — в умении отличать красивую таблицу от полезного вывода. Для интеграторов, продуктовых команд, внутренних центров разработки и сервисных компаний это прямой сигнал: считать нужно не только факт, но и альтернативу, ограничение и цену следующего шага.
Оригинал: Habr / Карьера.
Следующий логичный шаг для таких команд — переносить эту логику из учебных задач в бюджетирование проектов, планирование загрузки и оценку AI-автоматизации.