Экспертиза

Бизнес-анализ и системная аналитика

Перевожу потребности бизнеса в конкретные требования, архитектуру и план действий. Без потери смысла между бизнесом и IT.

Обсудить

Каждый провальный IT-проект начинается одинаково: бизнес объяснил, что ему нужно, разработчики поняли по-своему, а результат не устраивает никого.

Проблема почти никогда не в технологии. Проблема в том, что между бизнес-потребностью и технической реализацией нет моста. Нет человека, который одинаково хорошо понимает, как думает CFO и как работает API.

Я занимаюсь именно этим — нахожу, где бизнес теряет деньги или время, формализую это в архитектуру и требования, и убеждаюсь, что каждое техническое решение работает на бизнес-результат.

Целевая модель

Как это должно быть устроено

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

Типичные ошибки

Где компании обычно ошибаются

Требования собираются формально — чек-лист вместо понимания процессов

Аналитик не понимает бизнес-контекст и пишет ТЗ в вакууме

Нет AS IS — строят TO BE поверх непонятного

ТЗ написано, но никто не может по нему разрабатывать

Бизнес и IT говорят на разных языках, аналитик не может перевести

Требования меняются, но нет процесса управления изменениями

Подход

Что я в таких ситуациях делаю

Я начинаю с бизнес-задачи, а не с требований. Сначала понимаю, где бизнес теряет деньги или время. Потом документирую AS IS — как работает сейчас. Нахожу разрывы и узкие места. Проектирую TO BE — как должно быть. И только потом формализую в требования, которые можно реализовать.

Роль команды: Я проектирую модель и формулирую ключевые решения. Команда детализирует требования, готовит спецификации интеграций, прорабатывает edge cases и ведет работу с заказчиком по согласованию.

Результаты