Предпроектное обследование ИТ-проекта: что входит и что должно быть на выходе

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

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

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

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

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

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

• Цель и границы: какую проблему решает проект, какие процессы входят в разбор, что не рассматривается в текущем этапе.
• Текущие процессы: как работа выполняется сейчас, где появляются ручные действия, ожидания, ошибки, обходные решения и дублирование данных.
• Системы и владельцы: какие системы участвуют, кто отвечает за каждую из них, кто выдает доступы и подтверждает изменения.
• Данные и справочники: какие сущности, документы, статусы, поля и правила преобразования важны для будущего решения.
• Интеграции: какие API, файлы, очереди, ручные выгрузки или внешние сервисы уже есть и что нужно проверить отдельно.
• Роли и решения: кто пользуется системой, кто утверждает правила, кто принимает результат и кто будет сопровождать изменения.
• Ограничения и риски: безопасность, доступы, закупочные условия, сроки, критичность процессов, качество данных, зависимость от внешних систем и открытые вопросы.

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

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

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

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

Хороший результат не обещает абсолютной определенности. Он показывает, что уже можно оценивать, что нужно проверить отдельно, какие решения меняют сроки и бюджет, какие материалы понадобятся для ТЗ, discovery, ИТ-аудита, проектирования или старта ограниченного этапа работ.

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

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