Чем BA спасает бизнес от дорогих разработок
Самая дорогая ошибка в автоматизации - не баг
Самая дорогая ошибка - автоматизировать не ту проблему.
Не тот процесс. Не ту функцию. Не того владельца.
А потом дорого переделывать уже не код, а управленческую ошибку.
Поэтому сильный BA нужен бизнесу не для схем и не для “сбора требований”.
Он нужен, чтобы компания не сжигала CAPEX, человеко-месяцы разработки и ресурс внимания менеджмента на то, что вообще не надо было делать.
Я видел это очень предметно.
У одной функции копился backlog на десятки задач - примерно на пару человеко-лет разработки. Приоритет у блока всегда был средний, поэтому все это годами ехало вправо. Бизнес жил с ручным трудом, ждал автоматизации и был уверен, что проблема в нехватке разработки.
Но главная потеря была не только в этом.
Пока эти задачи висели, у компании были заморожены деньги, решения и управленческий фокус. Команда обсуждала не то. Менеджмент держал в голове не те ограничения. Реальные улучшения не двигались, потому что весь контур жил с ложным ощущением: “нам срочно нужна разработка”.
Когда в контур зашел сильный BA, картина оказалась неприятной, но полезной:
- около 60% задач убрали вообще;
- еще около 30% закрыли без доработки текущей системы: через другой инструмент, изменение процесса и нормальную управленческую логику;
- и только остаток реально ушел в разработку и частично в аутсорс.
То есть BA не просто “почистил backlog”.
Он разморозил деньги, убрал ложную срочность и вернул компании фокус на то, что действительно влияет на результат.
То же самое часто происходит с отчетностью.
Бизнес просит отчет. Разработка делает. Потом выясняется, что нужен другой. Потом третий. Потом четвертый.
200 часов здесь сгорают легко.
Но проблема обычно не в самом отчете. Проблема в том, что бизнес часто пытается заказать форму ответа, не разобравшись в самом управленческом вопросе.
Каким рычагом хотим управлять? Какое решение будем принимать по этим цифрам? Что изменится в деньгах, сроках, запасах, SLA или марже после появления этого отчета?
Сильный BA в этот момент работает не как “сборщик требований”. Он работает как внутренний консультант по управлению.
Иногда после нормального разговора отчет действительно нужен. Иногда нужен другой. А иногда выясняется, что нужен не отчет вообще, а другое правило, другой процесс или другая ответственность.
Для CEO BA - это не про документы.
Это про быстрый и дешевый способ понять, во что компания сейчас собирается вложить деньги: в реальную проблему или в цифровизацию симптомов.
Хороший BA после разговора обычно оставляет меньше требований, меньше шума и меньше иллюзий.
Но именно поэтому у бизнеса остается больше денег, больше фокуса и больше шансов получить нужный результат.
Без такого фильтра компания очень быстро начинает автоматизировать хаос.
А автоматизация хаоса - это один из самых дорогих способов масштабировать убытки.
Если у вас backlog растет быстрее результата, а бизнес годами ждет автоматизацию, которая потом не дает эффекта, - проблема, скорее всего, не в количестве разработчиков, а во входе в разработку.
Узнаете свою ситуацию?
