Мы собирались начать автоматизацию закупок с одного завода: провести пилот, отладить решение и потом тиражировать его на остальные предприятия. План выглядел профессионально и безопасно — пока директор по закупкам не оценил пересечение процессов четырёх заводов в диапазоне 40–60% в зависимости от площадки и участка процесса. Это был не формальный расчёт, а суждение человека, который видел закупочную работу всех предприятий. Его хватило, чтобы увидеть риск: один завод не был уменьшенной копией остальных. Выбрав его пилотом, мы могли сначала автоматизировать значительную часть локальной специфики, а затем переделывать решение при каждом тиражировании.
TL;DR
Пилот на одной площадке не гарантирует маленький MVP: локально критичные требования пилота могут раздуть продукт, а значимую вариативность других площадок — остаться незамеченной. Карта первой реализации помогает отделить общее ядро, обязательную вариативность и локальные сценарии. Обследование для этой задачи можно останавливать, когда новые интервью уже не способны изменить решение о составе первой реализации.
Серия
Это седьмая статья серии о том, что должно быть определено до фиксации проектных обязательств. Начало серии — «Автоматизировать бардак нельзя навести порядок: где у ИТ должно быть право вето». Предыдущая статья — «Вы выбираете не решение. Вы выбираете его будущие проблемы».
Я и сейчас не считаю исходную идею пилота ошибочной. Один завод действительно уменьшал количество пользователей, данных и организационных участников запуска. Если бы площадки были достаточно похожи, такой подход мог сработать.
Но задача проекта была корпоративной. Нужно было получить общий закупочный процесс для четырёх предприятий: консолидировать потребность, сформировать общий пул закупок, работать с общими категориями и поставщиками. Отдельной задачей было привести к общему контуру нормативно‑справочную информацию, прежде всего номенклатуру. При различиях между предприятиями вопрос «на каком заводе проще начать?» оказался слишком узким. Сначала нужно было понять, что должно войти в первый законченный результат, если он должен работать сразу на всех четырёх предприятиях.
Дальше под MVP я буду понимать такую первую реализацию: минимальную по объёму, но законченную по бизнес‑смыслу. Пользователь должен иметь возможность пройти значимый сквозной сценарий от начала до конца (end‑to‑end). Набор отдельных технических компонентов под это определение не подходит.
Увидеть различия, которые способны изменить решение
Мы начали с отдельных интервью на каждом из четырёх предприятий. Если сразу собрать всех за одним столом, разговор легко уходит в обсуждение того, «как должно быть правильно», хотя ещё непонятно, где процессы действительно совпадают, а где одинаковыми словами называют разную работу.
По каждому заводу мы собирали только то, что могло повлиять на общий закупочный процесс и первую реализацию: ход процесса, категории и номенклатуру, документы, существенные особенности, функциональные разрывы и кандидатов в них. Результаты попадали в реестр функциональных разрывов — позже именно из него и других проектных материалов можно было брать спорные элементы для Карты первой реализации.
Полностью описывать закупочную деятельность каждого предприятия мы не собирались. Нас интересовали различия, способные повлиять на состав первой реализации. Если особенность не меняла общий процесс, не требовала поддержки в корпоративном решении и могла остаться локальной, углубляться в неё на этом этапе не было смысла. Четыре предприятия расширяли поле зрения, но не превращались в четыре полноценных предпроектных обследования.
После интервью мы сопоставили результаты. Стали видны общие участки процесса, локальные практики и расхождения, по которым решения ещё не было. Последняя группа была самой важной: там пилот на одном заводе мог либо протащить локальную особенность в корпоративный продукт, либо скрыть различие, которое общий процесс обязан поддерживать. На совместные встречи мы вынесли только такие вопросы.
Когда обязательное для завода становится лишним для первой реализации
Хороший пример — номенклатура. Для выбранного пилотного завода естественным было бы требование работать со всеми материалами и закупочными категориями, которыми он пользуется. Значительная часть такого набора была бы для предприятия критичной: без неё пилот не покрывал бы существенную часть реальной работы.
Сопоставление четырёх предприятий дало другую картину. Значительная часть номенклатуры использовалась несколькими заводами и относилась к общему контуру. В первую реализацию попало 30–40 тысяч позиций, которые требовалось нормализовать. Одновременно выявился слой номенклатуры, специфичной только для отдельных предприятий. Такие позиции решили пока оставить локальными. Если впоследствии позиция становилась нужна другим заводам, её отдельно нормализовали и распространяли как корпоративную.
На одном из предприятий использовалась номенклатура, связанная со специфической обработкой металла. Она тянула дополнительные характеристики и управляющие данные, влияла на закупочную документацию и фактически создавала отдельную ветвь процесса. Для пилота на этом заводе всё это пришлось бы включить в первую версию. Для общего решения четырёх предприятий такой необходимости не было.
Здесь различие между приоритетом и принадлежностью к первой реализации стало практическим. Требование может быть критичным для подразделения и при этом не требоваться первому корпоративному результату.
Не всякую локальную специфику можно оставить за бортом
Другой пример не позволил превратить предыдущую логику в правило «всё локальное откладываем».
На предприятиях формировались технические задания на закупку. Это документ закупочного процесса, а не техническое задание на информационную систему. Предприятия находились в разных странах, поэтому на содержание и оформление документа влияли различия законодательства и локальных нормативных актов. Требования отличались от площадки к площадке.
Оставить эту специфику на следующий этап уже не получалось. Первая реализация должна была работать на всех четырёх предприятиях, следовательно, общий процесс обязан был корректно формировать необходимые документы на каждой площадке. Локальными оставались конкретные правила, а способность системы поддерживать их вариативность становилась корпоративным требованием.
Со специфической номенклатурой можно было отложить отдельный локальный сценарий. Здесь это остановило бы сквозной процесс на части предприятий. Простое пересечение требований четырёх заводов тоже не давало правильного MVP.
Совместные встречи: закрыть расхождения, а не собрать новые требования
После отдельных интервью у нас остались конкретные расхождения, мешавшие определить состав первой реализации. Их и вынесли на совместные встречи представителей заводов. Повторно обследовать площадки или заново собирать пожелания пользователей не требовалось.
Проектная команда готовила варианты и показывала последствия. Где‑то локальную особенность можно было сохранить без изменений в общем решении, где‑то требовалась поддержка нескольких вариантов процесса, а часть требований можно было отложить. По отдельным вопросам договориться с первой попытки не удавалось, и обсуждение переносилось на следующую встречу. Смысл встреч — закрывать неопределённости, которые мешали принять решение по конкретному требованию.
Здесь важна граница ответственности. Команда могла выявить противоречие, предложить варианты и показать влияние каждого из них на решение. Выбирать за бизнес, какое правило должно действовать дальше, она не должна. Если различие меняло будущую работу предприятий, решение принималось вместе с представителями бизнеса.
После этих встреч мы уже могли различать общее ядро, обязательную вариативность и локальные сценарии. С этим составом первая реализация и пошла сразу на четыре предприятия.
Карта первой реализации
Обычного списка требований с приоритетами для таких решений недостаточно: он показывает важность, но не всегда показывает, к какому контуру относится требование. Я использую для этого Карту первой реализации. Это не обязательно отдельный документ — в небольшом проекте достаточно дополнительных полей в backlog или рабочей таблицы. Важен сам набор вопросов.
В карте семь блоков:
Бизнес‑результат. Что должно измениться после первой реализации, для кого, где начинается и заканчивается сквозной сценарий, по какому признаку он считается законченным.
Граница анализа. Какие площадки, подразделения, страны или группы пользователей необходимо увидеть, чтобы не пропустить вариативность, способную изменить решение.
Кандидаты. Требования, функциональные разрывы и другие элементы, для которых нужно решить судьбу в первой реализации: где они возникают, зачем нужны и что произойдёт без них.
Тип требования. Общее ядро; обязательная вариативность общего процесса; локальный сценарий; отложенный кандидат на обобщение.
Проверочные вопросы. Перестанет ли без этого работать общий сквозной процесс? Требование нужно всему контуру или отдельной площадке? Сможет ли площадка участвовать в общем процессе без автоматизации локального сценария? Можно ли отложить его без дорогой переделки выбранного решения?
Решение. В первую реализацию; поддержать вариативность; оставить локально; отложить; вернуть на анализ.
Условие пересмотра. Какое событие должно заставить открыть решение снова.
Последний блок особенно полезен для всего, что осталось за пределами первой реализации. «Не сейчас» не должно незаметно превращаться в «никогда».
Карта не передаёт проектной команде право решать за бизнес. Она помогает вынести на обсуждение конкретный предмет решения, зависимости и последствия.
Как это выглядело бы на нашем кейсе
В том проекте документа с названием «Карта первой реализации» не было. Это инструмент, который я формулирую сейчас на основе подобных ситуаций. Если реконструировать небольшой фрагмент по четырём заводам, получится так:
Кандидат | Тип | Решение | Обоснование / условие пересмотра |
|---|---|---|---|
Общая номенклатура | Общее ядро | В первую реализацию | Нужна для консолидации общей потребности |
Номенклатура специфической обработки металла | Локальный сценарий | Оставить локально | Пересмотреть, если понадобится другим предприятиям |
Варианты технического задания на закупку | Обязательная вариативность | Поддержать вариативность | Без неё процесс не работает на части площадок |
Два требования могут быть одинаково критичными для конкретного предприятия и при этом получить разные решения в корпоративном продукте. Поэтому в карту имеет смысл выносить прежде всего спорные элементы, где ошибка между «общее», «вариативное», «локальное» и «пока не нужно» заметно меняет объём или жизнеспособность первой реализации.
Приоритет и принадлежность к первой реализации — разные решения
Карта не конкурирует с MoSCoW, WSJF или обычной приоритизацией backlog. MoSCoW использует категории Must / Should / Could / Won’t для определения приоритетов в выбранном горизонте поставки; WSJF помогает выстраивать экономическую последовательность работ. У этих инструментов другая задача.
В нашем кейсе до приоритизации нужно было определить, к какому контуру относится требование. Отсюда рабочая формула: Must одного подразделения и Must продукта — разные Must.
Карта добавляет к приоритизации ещё один вопрос: для кого это необходимо и что случится с первым законченным результатом, если этого пока не будет?
Где чаще всего ошибаются
В центральном кейсе проявились три ошибки, которые легко допустить при выборе первой реализации. Первая — принять административную границу за продуктовую: завод удобен как объект запуска, но это ещё не делает его репрезентативным. Вторая — перенести критичность требований пилотной площадки на весь продукт. Третья — взять только пересечение требований всех подразделений и потерять обязательную вариативность общего процесса.
В других проектах встречаются ещё две типовые ошибки. Иногда команда заранее автоматизирует все известные локальные исключения, чтобы «потом не переделывать», хотя часть из них можно безопасно отложить. Другая крайность — резать MVP по техническим компонентам: сначала справочники, потом интеграции, затем интерфейсы. Проект поставляет части системы, но законченного бизнес‑сценария у пользователя всё ещё нет.
Есть и ловушка на стороне анализа: изучение различий между площадками само превращается в самостоятельную деятельность.
Когда уже хватит обследовать
Расширение анализа легко довести до абсурда. У сложной организации всегда найдутся новые исключения, дополнительные группы пользователей и детали процесса, которые можно изучать дальше. Поэтому у обследования должен быть тот же критерий, что и у любого другого проектного действия: какое решение оно помогает принять.
Вот три вопроса, которыми я бы проверял необходимость следующего раунда:
Видим ли мы основные варианты процесса, способные изменить состав первой реализации?
Остались ли расхождения, по которым пока нельзя решить: включить, поддержать вариативность, оставить локально или отложить?
Может ли следующее интервью или дополнительный анализ реально изменить одно из этих решений?
Если ответ на третий вопрос уже «скорее нет», обследование для этой задачи можно останавливать. Это не означает, что бизнес изучен раз и навсегда. Позже понадобится детализация требований, проработка отдельных функций или анализ следующей очереди — уже перед другими решениями.
В проекте четырёх заводов первый слой интервью расширил поле зрения и не дал провести границу MVP по одной площадке. Второй слой закрыл конкретные расхождения, которые мешали эту границу провести. После этого продолжать интервью ради более полного описания предприятий было бы работой ради работы. Но и противоположный принцип «разберёмся по ходу» опасен, если неизвестная вариативность способна изменить архитектуру или бизнес‑смысл первой реализации.
Что можно сделать с текущим MVP уже завтра
Не обязательно заново обследовать организацию или перестраивать весь backlog. Возьмите несколько самых крупных, дорогих или спорных требований текущего MVP — особенно те, про которые чаще всего говорят «без этого нельзя запускаться» — и задайте по каждому шесть вопросов:
Какой бизнес‑результат первой реализации оно обеспечивает?
Кому оно необходимо: всему целевому контуру или отдельной площадке, подразделению, стране, группе пользователей?
Это общее правило, обязательная вариативность общего процесса или локальный сценарий?
Если локальное требование не реализовать сейчас, сможет ли площадка участвовать в общем процессе?
Можно ли отложить требование без дорогой переделки выбранного решения?
Какое событие должно вернуть исключённое требование в рассмотрение?
Если на один из вопросов нет согласованного ответа, скорее всего, проблема уже не в приоритете требования, а в том, как проведена граница первой реализации. Иногда такая проверка сокращает MVP, иногда возвращает в него функцию, которую слишком рано признали локальной. Оба результата нормальны.
И отдельно — проверьте сам пилот. Почему выбранная площадка позволяет проверить гипотезу, ради которой он проводится? Аргументы «там проще договориться», «там сильный руководитель» или «там меньше пользователей» полезны для организации запуска, но ничего не говорят о репрезентативности процесса.
Что мы на самом деле уменьшали
Мы начинали с одного завода, потому что хотели уменьшить риск запуска. После сравнения четырёх предприятий стало ясно: правильный размер первой реализации определяется не количеством площадок, а составом общего результата.
В первую реализацию вошли общее ядро и вариативность, без которой процесс не работал бы на целевом контуре. Часть локальных сценариев осталась за его пределами. Поэтому запуск сразу на четырёх заводах не означал «сделать всё для всех».
Из этого не следует правило «всегда обследуйте все филиалы». Иногда одной площадки достаточно, вариативность уже известна или пилот проверяет узкую технологическую гипотезу. Критерий другой: понимаем ли мы процесс достаточно, чтобы отличить общее правило от обязательной вариативности и локального исключения.
Когда граница первой реализации определена, возникает следующий вопрос: достаточно ли оснований, чтобы фиксировать объём, бюджет, архитектуру и обязательную дату? Это вопрос допуска к реализации — ему и будет посвящена следующая статья.
