Что должно войти в предпроектное обследование цифровой системы

Предпроектное обследование иногда воспринимают как несколько встреч перед оценкой проекта: заказчик рассказывает, что хочет получить, подрядчик задаёт вопросы, после чего появляется техническое задание и стоимость разработки.

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

До начала разработки нужно понять не только что компания хочет создать, но и в какой среде новая система будет работать: какие процессы она поддерживает, кто ей пользуется, откуда приходят данные, с какими системами предстоит интегрироваться, какие ограничения уже существуют и что произойдёт при изменении привычного процесса.

Именно на эти вопросы должно отвечать предпроектное обследование.

Сначала определить цель проекта

Формулировка «нам нужен новый личный кабинет» описывает решение, но не объясняет задачу.

Зачем он нужен? Чтобы снизить нагрузку на менеджеров? Перевести повторные заказы в самообслуживание? Дать дилерам доступ к персональным ценам и документам? Ускорить согласование заказов?

От ответа зависит состав будущей системы.

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

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

Разобрать процесс таким, какой он есть сейчас

Проектировать новую систему только по описанию желаемого интерфейса рискованно. Сначала полезно понять текущий процесс.

Допустим, компания хочет автоматизировать B2B-заказы. На словах схема выглядит просто:

клиент выбирает товары → оформляет заказ → заказ попадает в ERP.

Во время обследования может выясниться, что часть клиентов работает по персональным прайс-листам, некоторым нужен лимит отсрочки, крупные заказы согласует руководитель, наличие товара менеджер уточняет на нескольких складах, а отдельные категории вообще нельзя заказать без дополнительной проверки.

Если эти правила обнаружатся уже во время разработки, придётся менять и интерфейсы, и бизнес-логику, и интеграции. Поэтому стоит описать процесс as is: кто его запускает, какие шаги проходит задача, какие системы и документы используются, где принимаются решения и где возникает ручная работа.

Найти исключения, а не только основной сценарий

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

Что происходит, если товара нет на основном складе? Если клиент превысил кредитный лимит? Если заказ оформляет новый сотрудник контрагента? Если договор закончился? Если цена требует индивидуального согласования? Если ERP временно недоступна?

Такие случаи полезно собирать отдельно.

Иногда после их анализа выясняется, что «редкие исключения» занимают значительную часть работы сотрудников. Если автоматизировать только идеальный сценарий, новая система не избавит от ручных операций, ради сокращения которых проект и начинался.

Определить всех пользователей и их роли

«Клиент» или «менеджер» редко оказывается одной ролью.

В B2B-кабинете от одной организации могут работать закупщик, бухгалтер и руководитель. Один сотрудник формирует заказ, другой его подтверждает, третий скачивает документы. Менеджер компании видит своих клиентов, руководитель отдела — всех клиентов подразделения, администратор управляет доступами.

Поэтому во время обследования нужно определить:

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

Это влияет одновременно на интерфейс, бизнес-логику, модель данных и безопасность.

Провести инвентаризацию существующих систем

Новая цифровая система почти никогда не появляется в пустой инфраструктуре. Рядом уже работают 1С или ERP, CRM, складская система, документооборот, PIM, корпоративная авторизация, платёжные сервисы, службы доставки и собственные внутренние решения.

Поэтому предпроектное обследование должно отвечать на вопросы:

• Какие системы уже существуют?
• Какую роль выполняет каждая?
• Какие из них остаются?
• Какие должны быть заменены?
• С какими придётся интегрироваться?

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

Описать интеграционный контур

Одного списка систем недостаточно. Нужно понять, какие данные между ними перемещаются. Для каждого значимого потока определяют:

• источник и получателя;
• состав данных;
• направление обмена;
• источник истины;
• частоту обновления;
• допустимую задержку;
• примерный объём;
• критичность;
• поведение при ошибках.

Например, каталог может приходить из ERP, остатки — из WMS, маркетинговые описания редактироваться на сайте, а заказы передаваться обратно в ERP. Такой разбор позволяет заранее увидеть противоречия и зависимости, которые не видны на уровне требования «нужна интеграция с 1С». Подробно сам подход к этой части обследования можно вынести в отдельную карту интеграционного контура.

Понять, где находятся данные и какого они качества

Наличие данных ещё не означает, что их можно сразу использовать в новой системе. Одна и та же информация может храниться в нескольких местах. Справочники могут отличаться. В карточках товаров могут отсутствовать характеристики. У клиентов — дублироваться записи. В документах — использоваться разные форматы.

Поэтому стоит определить:

• какие данные нужны будущей системе;
• где они находятся сейчас;
• насколько они полны и актуальны;
• есть ли дубли и противоречия;
• какие справочники используются;
• кто отвечает за их качество;
• потребуется ли миграция или предварительная очистка.

Это особенно важно для проектов, где данные являются основой функциональности: e-commerce, B2B, аналитики, поиска и ИИ-систем. Иногда предпроектное обследование показывает, что начинать нужно не с разработки интерфейса, а с подготовки данных.

Зафиксировать функциональные требования

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

• каталог с персональным ассортиментом;
• поиск и фильтрация;
• оформление заказа;
• согласование заказа внутри компании клиента;
• отображение персональных цен;
• работа с несколькими юридическими лицами;
• история заказов;
• документы;
• уведомления;
• административные функции.

Важно не превращать этот список сразу в описание экранов. Требование «клиент должен видеть актуальный лимит задолженности» важнее предварительного решения разместить цифру в определённом блоке личного кабинета. Конкретный интерфейс ещё может измениться во время проектирования.

Отделить обязательное от желательного

На этапе обследования быстро появляется длинный список пожеланий. Если относиться ко всем одинаково, первая версия системы разрастается ещё до начала разработки. Поэтому требования полезно разделить хотя бы на несколько групп:

• без чего система не решает основную задачу;
• что желательно включить в первую версию;
• что можно перенести на следующие этапы;
• что пока остаётся гипотезой и требует дополнительной проверки.

Так появляется основа для определения MVP или очередности релизов. Приоритет должен зависеть не от того, кто громче попросил конкретную функцию, а от бизнес-цели, критичности процесса, зависимостей и стоимости реализации.

Собрать нефункциональные требования

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

К нефункциональным требованиям относятся, например:

• ожидаемая нагрузка;
• объём данных;
• требования к скорости;
• доступность;
• допустимый простой;
• резервное копирование;
• восстановление;
• требования безопасности;
• журналирование;
• мониторинг;
• масштабирование.

Фраза «система должна быть быстрой» почти бесполезна. Гораздо полезнее знать ожидаемое число пользователей, количество операций и допустимое время выполнения критичных сценариев. Без этих вводных невозможно обоснованно выбрать архитектуру.

Отдельно определить требования безопасности

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

Особенно важны:

• модель ролей и прав;
• способы авторизации;
• работа с персональными и коммерчески чувствительными данными;
• журналирование значимых действий;
• требования к хранению и передаче данных;
• ограничения на использование внешних сервисов;
• требования внутренней службы информационной безопасности.

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

Проверить инфраструктурные ограничения

Иногда у компании уже есть требования к размещению будущей системы. Например, она должна работать в существующем контуре, использовать определённую СУБД, размещаться на собственных серверах или в согласованном облаке. Могут существовать корпоративные стандарты по технологиям, резервному копированию и мониторингу.

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

Изучить существующую систему, если предстоит модернизация

Предпроектное обследование нового продукта и развитие существующего проекта немного отличаются. Если система уже работает, дополнительно нужно понять её текущее техническое состояние:

• архитектуру;
• технологии и версии;
• качество и структуру кода;
• базу данных;
• интеграции;
• инфраструктуру;
• накопленный технический долг;
• известные проблемы;
• документацию;
• процесс выпуска обновлений.

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

Понять организационные зависимости

Не все риски проекта находятся в коде. Для интеграции может понадобиться команда, которая поддерживает ERP. Доступ к данным согласует служба безопасности. Новые справочники должен подготовить отдел продаж. Контент для каталога — маркетинг. Если эти зависимости не учитывать, разработка может технически идти по плану и при этом месяцами ждать решений со стороны других участников.

Поэтому полезно определить:

• владельцев процессов;
• ответственных за системы и данные;
• участников согласования;
• внешних подрядчиков;
• необходимые доступы;
• решения, которые должен принять заказчик.

Это позволяет увидеть организационные блокеры до старта.

Зафиксировать неизвестные и риски

Хорошее предпроектное обследование не обязано дать ответ абсолютно на всё. Наоборот, один из его результатов — честный список вопросов, которые пока остаются открытыми.

Например, неизвестна производительность API старой ERP. Нет документации по одному из внутренних сервисов. Не определён алгоритм персонального ценообразования. Нужно проверить качество товарных данных.

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

Результат обследования — не обязательно одно большое ТЗ

Предпроектное обследование может закончиться комплектом документов разного уровня детализации. Состав зависит от проекта.

Для сложной цифровой системы полезный результат может включать:

Результат	Что фиксирует
Цели и границы проекта	Зачем создаётся система и что входит в проект
Карта процессов	Текущие и будущие бизнес-сценарии
Пользователи и роли	Кто работает с системой и какие имеет права
Функциональные требования	Что должна уметь система
Нефункциональные требования	Нагрузка, скорость, доступность, безопасность
Интеграционный контур	Системы, данные и направления обмена
Требования к данным	Источники, качество, миграция, справочники
Ограничения	Инфраструктурные, технологические и организационные условия
Приоритеты	Состав первой версии и последующих этапов
Риски и открытые вопросы	Что ещё нужно проверить или решить
Архитектурная концепция	Как система может быть устроена на верхнем уровне
Предварительная оценка	Сроки, этапы и порядок разработки

Для одного проекта часть пунктов поместится в несколько схем и таблиц. Для другого потребуется полноценный комплект аналитической документации. Ценность определяется не количеством страниц.

Когда обследование можно считать достаточным

Не тогда, когда описана каждая кнопка будущего интерфейса.

Перед началом проектирования и разработки должно быть достаточно информации, чтобы команда понимала:

• какую бизнес-задачу решает система;
• кто и как будет ей пользоваться;
• какие процессы она поддерживает;
• с какими системами взаимодействует;
• откуда получает данные;
• какие нагрузки и ограничения ожидаются;
• что входит в первую версию;
• какие существенные вопросы пока остаются открытыми.

Если на эти вопросы есть ответы, технические решения можно принимать осознанно.

Предпроектное обследование не устраняет изменения в ходе разработки. Новые детали всё равно появятся. Его задача другая — обнаружить наиболее дорогие неизвестные до того, как под них уже написан код.

В сложном цифровом проекте это не дополнительный этап ради документации, а способ уменьшить количество решений, которые иначе пришлось бы принимать уже во время разработки — обычно дороже и с меньшим выбором вариантов.