РП Классики
В прошлый раз я коснулась вопроса метрик и того факта, что не всегда существующие метрики работают на главную цель. Так как мы со студентами анализируем все-таки не финансы компании, а финансы отдельного ИТ проекта, уточню: каждый отдельный проект должен быть рентабельным. Идеально, если один проект перетекает в другой, так что выручка и LTV, еще и растет год к году.
“Срезка” ИТ бюджетов 2025-2026 подняла вопрос рентабельности ИТ проектов. Увеличить платежи - отличная идея, но лишь в теории. Можно ли сократить затраты? Можно, но сразу оговорюсь: дальше будет всего лишь один конкретный пример, который может оказаться совершенно неактуальным для другого ИТ проекта.
Итак, посмотрим на рекомендации “Бережливого производства” применительно к ИТ проекту автоматизации сборки форм регуляторной отчетности ЦБРФ.
Первое бутылочное горло такого проекта - бесконечные согласования. Этот тип ИТ затрат по LEAN дает вклад в несколько типов потерь разом: ожидание, избыточная обработка, транспортировка, лишние запасы.
С одной стороны, ЦБРФ как будто бы все написал за аналитика, с другой - каждая кредитная организация уникальна по набору операций, бизнес процессу, инфраструктуре и своим АС, а с третьей - коллеги из отчетности с повышенной бдительностью относятся к тому, что они согласуют: ведь за их ошибки банку грозят более чем материальные и неотвратимые санкции.
Процесс аналитики изначально строился по классике: написали ФС - отправили на согласование - получили и обсудили правки - дописали ФС - отправили на согласование - и так в цикле.
Что быстро стало понятно: 1. Договорные ограничения в “3 итерации” - это не более чем теория, а на практике - сколько надо, столько и будет итераций, потому что цена ошибки в отчетности высока; 2. Время операционных сотрудников жестко привязано к отчетным периодам и если вы попали на период сдачи годовой, то коллеги и за квартал не посмотрят ваши документы; 3. Сроки конкретного проекта - жесткие и несдвигаемые. Причины сейчас неважны, важен сам факт. Срок - наше все. Если разработка ждет окончания согласований, ничего не будет сделано к сроку. Если разрабатывает до согласований, риски бесконечных переделок стремятся к 100%, а объемы переделок убьют рентабельность. 4. Неконтролируемый процесс согласования вызывает лютые простои всей команды, что тоже бьет по финансам.
Как решали? Расскажу в следующем посте. Пока выкладываю табличку “бережливого ИТ производства”.