Системная и бизнес‑аналитика

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

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

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

Решение просто автоматизировать текущую деятельность в существующем формате часто бывает ошибочным, так как автоматизация бардака создаёт автоматизированный бардак. Чем лучше проработаны цели и прояснены требования к проекту, тем лучше будут его результаты.

Полученные требования должны быть проанализированы на рациональность, полноту и непротиворечивость. Затем требования оцениваются по бизнес‑значимости, дополняются и конкретизируются, а конфликтующие требования перерабатываются до реализуемого вида.

Очень важно понимать все существующие проектные ограничения, иначе можно спроектировать решение, неподходящее для бизнеса по критическим параметрам. Нужно понимать границы минимально жизнеспособного продукта (MVP), осознавать рамки экономической целесообразности проекта и имеющиеся ограничения по срокам внедрения, а также знать про законодательные требования и иные существенные ограничения.

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

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