Введение для читателя Дзен:
Вы купили коробку с крутым конструктором. Первое, что вы делаете, — не хватаетесь за детали, а внимательно изучаете схему сборки. Этап «Определение» в методологии SmartBuild — это и есть создание той самой схемы. Но представьте, что у вас есть ИИ-помощник, который уже проанализировал тысячи успешных проектов, знает вашу отрасль и помогает нарисовать идеальный план, избегая тупиковых ветвей. Сегодня разберем, как работает этот этап и почему он экономит месяцы бюджета и нервов.
Глава 2: Этап «Определение» — Создаем навигационную карту проекта
Цель этапа «Определение» — не просто «начать проект». Цель — создать общее, разделяемое всеми понимание того, КУДА мы идем и ПОЧЕМУ. Это фундамент, на котором будет строиться все здание вашей новой цифровой системы. Пропустите этот этап или сделайте его спустя рукава — и трещины в фундаменте обязательно вылезут в виде срывов сроков, раздутого бюджета и недовольных пользователей.
Обзор этапа: Что мы делаем и зачем?
Ключевые цели:
· Достичь консенсуса: Получить четкое понимание бизнес-процессов, функций и информации, необходимых для достижения целей проекта. Объединить вокруг единого видения топ-менеджмент.
· Заложить основу для архитектуры: Разработать предварительную концептуальную архитектуру будущей системы — от бизнес-логики до серверов.
· Определить границы: Четко очертить, что ВХОДИТ в проект, а что останется за его рамками. Это спасет от «расползания» требований.
· Получить зеленый свет: Добиться утверждения руководством компании всей стратегии и плана для перехода к следующему этапу — детальному анализу.
Критические факторы успеха:
· Видимая и активная поддержка высшего руководства. Без этого проект обречен на сопротивление.
· Четкое определение бизнес-целей (метрик). Не «внедрить ERP», а «сократить цикл выполнения заказа с 5 дней до 1».
· Участие ключевых экспертов из бизнес-подразделений и IT. Они — носители реального знания.
Внимание используется ИИ!
*На этапе «Определение» формируется ключевой артефакт-веха — «Дорожная карта готовности проекта» (ОБ.070). Раньше ее создание занимало недели интервью и совещаний. С AIDM-Визардом процесс выглядит иначе:*
1. ИИ анализирует стратегические документы компании, отчеты и даже открытые данные по отрасли.
2. На основе шаблонов методологии SmartBuild и лучших практик, зашитых в его базу, он генерирует предварительный вариант карты, выделяя ключевые риски, точки принятия решений и зоны внимания.
3. Проектная группа и ключевые стейкхолдеры вносят правки через интерактивный интерфейс, а ИИ в реальном времени предлагает варианты согласования противоречивых правок, используя принцип компромисса.
*Так из 4-недельной задача «Дорожная карта» превращается в 5-дневный уточняющий спринт.*
Что на входе? Исходные данные для успеха
Чтобы начать, проектной группе нужны «исходники». Если их нет — их придется создавать. Вот основной список:
· Организационная структура компании. Без понимания, кто за что отвечает, двигаться нельзя.
· Стратегические документы: Видение компании, планы по реинжинирингу (BPR).
· Документы по существующим системам: Архитектура, конфигурации, процедуры управления.
· Ключевой артефакт: Утвержденный Устав проекта, подготовленный с помощью SmartBuild. Это ваш основной договор со спонсором.
Комментарий о соответствии TOGAF: Этап «Определение» в SmartBuild напрямую соответствует фазе «Архитектура видения» (Architecture Vision) в TOGAF. Артефакты, создаваемые здесь (видение процессов, предварительная архитектура), являются аналогами документов Vision и Architecture Vision в TOGAF, но представлены в более прикладном, ориентированном на внедрение ERP формате.
Ключевые артефакты (вехи) этапа
Именно эти артефакты знаменуют успешное завершение этапа и являются пропуском к следующему:
1. Высокоуровневые проекты процессов (БП.070): Не детальные инструкции, а схематичное описание КАК будет работать бизнес в будущем. Утверждается топ-менеджментом.
2. Базовый уровень текущего бизнеса (ОБТ.020): Честная «фотография» того, как все работает сейчас. Нужна, чтобы измерить прогресс.
3. Предварительная концептуальная архитектура (ТА.030): Эскиз будущей системы: какие модули «ЕРП-Мастера», как они связаны, какое «железо» и сети потребуются.
4. Обученная проектная группа (ОБ.050): Команда, которая уже прошла необходимое обучение и готова к работе. Это не формальность, а необходимость.
5. Дорожная карта готовности проекта (ОБ.070): Главный план по управлению изменениями в компании. Как мы будем готовить людей, коммуницировать и снимать сопротивление.
Подход и управление рисками: Как не наступить на грабли
Основные риски и как их нейтрализовать с помощью SmartBuild:
· Риск: Недостаточная приверженность изменениям со стороны менеджмента и пользователей.
o Решение SmartBuild: Уже на этапе определения запускается Коммуникационная кампания (ОБ.080). ИИ-модуль помогает сегментировать аудитории (топ-менеджеры, линейные руководители, пользователи) и генерировать персонализированные ключевые сообщения, отслеживая их достижения и вовлеченность.
· Риск: Размытые ожидания и недооценка объема работ.
o Решение SmartBuild: Использование предопределенных подходов (FastForward) внутри SmartBuild. AIDM-Визард анализирует критерии проекта (количество пользователей, сайтов, сложность процессов) и автоматически рекомендует оптимальный набор базовых и опциональных задач, сразу формируя реалистичный Технический план в Яндекс.Трекере.
· Риск: Архитектура рассматривается как чисто техническая задача, без учета бизнес-требований.
o Решение SmartBuild: Процессы Бизнес-требования (ОБТ) и Техническая архитектура (ТА) идут параллельно и взаимосвязаны. Артефакты из одного процесса являются входами для другого. AIDM-Визард следит за консистентностью: например, если в требованиях появилась необходимость в он-лайн анализа, он автоматически предлагает архитекторам рассмотреть опции встройки BI-модуля.
Практические советы: Как провести этап эффективно
· Не экономьте на планировании. Хороший план на этапе «Определение» — это 20-30% успеха всего проекта. Используйте шаблоны SmartBuild в Яндекс.Трекере.
· Соберите правильную команду. Вам нужны не только технари, но и сильные бизнес-аналитики с умением слушать и структурировать.
· Проводите воркшопы, а не бесконечные интервью. Совместная работа в группах по построению моделей процессов (например, в «Модуле 1C ERP: Описание процессов») дает гораздо лучший и быстрый результат.
- Воркшоп (от англ. workshop — «мастерская») — это интерактивный формат группового обучения или совместной работы, в котором основное внимание уделяется практической отработке навыков, обмену опытом и коллективному решению конкретных задач.
· Используйте прототипы. Создайте прототип будущей документации или дайте потренироваться на тестовом стенде. Это лучше тысячи слов.
Внимание используется ИИ!
*Типичная проблема этапа — сбор и анализ бизнес-требований (ОБТ.020). Традиционно это горы заметок, противоречивых пожеланий и потерянных деталей. AIDM-Визард меняет правила:*
1. Во время интервью или воркшопов система в реальном времени транскрибирует речь, выделяет сущности (термины, названия процессов, проблемы) и связывает их.
2. По итогу сессии лидеры групп получают автоматически сгенерированную карту требований, структурированную по шаблону SmartBuild, с выделенными противоречиями и «белыми пятнами».
3. Это позволяет сразу, на месте, уточнить и согласовать спорные моменты, а не растягивать процесс на недели.
Глава 3: Этап «Анализ операций» — Детализируем картину будущего
Если этап «Определение» дал нам общую схему конструктора, то «Анализ операций» — это детальная проработка каждого узла, проверка, подходят ли друг к другу детали, и составление списка недостающих элементов.
Обзор этапа: Глубже в детали
Цели:
· Детализировать до мелочей: Превратить высокоуровневые требования в конкретные, пошаговые сценарии работы пользователей.
· Сопоставить и выявить разрывы: Примерить эти сценарии к стандартному функционалу 1С ERP и найти места, где система «не дотягивает» (Gaps).
· Предложить решения: По каждому разрыву найти решение: изменить процесс, использовать обходной путь, создать небольшую доработку или заказать сложное расширение.
· Спроектировать архитектуру: Уточнить техническую архитектуру, основываясь на детальных требованиях к производительности и интеграциям.
Ключевой вопрос этапа: «Можем ли мы поддержать наш идеальный бизнес-процесс стандартными средствами системы, или нужны доработки?»
Ключевые артефакты-вехи этапа
1. Детальная модель будущих процессов (БП.080): Готовая, утвержденная схема работы «как будет». Основа для написания регламентов и скриптов тестирования.
2. Сценарии бизнес-требований (ОБТ.050): Конкретные истории: «Пользователь А в ситуации Б должен получить результат В». Это язык общения между бизнесом и IT.
3. Сопоставленные бизнес-требования (СБТ.030): Таблица, где каждое требование связано с конкретной функцией системы, ручным шагом или выявленным разрывом.
4. Утвержденные бизнес-решения (СБТ.090): ВАЖНЕЙШАЯ ВЕХА. Документ, в котором руководство компании поставило точку в споре «как делать». Он содержит все согласованные решения по разрывам и является техническим заданием для этапа проектирования.
Внимание используется ИИ!
*Артефакт «Утвержденные бизнес-решения» (СБТ.090) — это точка, где часто случаются задержки. Люди не могут договориться, решения теряются в почте. AIDM-Визард действует как интеллектуальный посредник и секретарь:*
· Он хранит всю историю обсуждений по каждому разрыву, автоматически предлагая наиболее популярные или компромиссные варианты на основе анализа схожих проектов.
· Формирует итоговую таблицу решений и организует их утверждение через систему электронных подписей или интеграцию с корпоративным порталом.
· После утверждения автоматически обновляет связанные артефакты — модель процессов, план проекта, смету доработок.
Практические советы для этапа анализа
· Соблюдайте «Правило 3-2-1»: На 3 часа исследования (интервью, анализ документов) должно приходиться 2 часа проектирования (совместное построение модели) и 1 час фиксации (оформление артефакта в шаблон SmartBuild).
· Работайте в смешанных командах. В одной комнате должны быть и бизнес-пользователь, знающий процесс, и консультант, знающий систему, и аналитик, владеющий методологией.
· Тестируйте решения на ходу. Не ждите этапа тестирования. Сразу после сопоставления требования попробуйте выполнить сценарий в предварительно настроенной тестовой среде (конференц-пилот). Это сразу выявляет нестыковки.
· Не бойтесь пересматривать. Анализ — итерационный процесс. Получив новую информацию, смело возвращайтесь и корректируйте модель процессов. Это нормально.
Комментарий о соответствии TOGAF: *Этап «Анализ операций» в SmartBuild перекликается с фазами «Информационные системы архитектура» (Information Systems Architectures) и «Архитектура данных» (Data Architecture) в TOGAF. Глубокое моделирование процессов (БП.080) и создание Информационной модели (СБТ.060) — это практическая реализация принципов TOGAF на уровне конкретного ERP-проекта.*
Что дальше? После того как все решения утверждены и артефакты-вехи подписаны, проект переходит в фазу «Проектирование решения», где идеи и прототипы превращаются в детальные технические спецификации — «чертежи» для программистов. Об этом — в следующей статье.