Когда у меня на столе оказалась задача «выбрать TMS среди вендоров в Казахстане для маркетплейса», я сначала записал её обычным языком: чеклист с ИИ, переговоры с вендорами, анализ. На бумаге выглядело осмысленно. После разбора по FPF выяснилось, что я смотрел не на тот объект.
Этот пост — учебный разбор реальной рабочей задачи через рамку FPF. Мне он помог отделить методическую часть («как делать») от организационной («когда делать, кто делает, на какие ресурсы»). Делюсь, потому что собственные ошибки в применении понятий показывают эти понятия лучше учебных примеров.
Задача и её формулировка
Маркетплейс строит бесшовное информационное пространство в логистике. На стыках цепи теряются данные, нет 100% прозрачности движения грузов, нет юнит-экономики каждого отправления. Внедрение TMS должно эти проблемы закрыть. Моя локальная задача — выбрать вендора, чтобы разблокировать контрактование, ТЗ на интеграцию и старт проектной команды.
Сразу обнаружилась первая ловушка: задача выглядит «простой выбор из готового рынка», но цена ошибки на этом шаге в 5–20 раз дороже, чем ошибка на любом последующем этапе внедрения. Выбранный вендор фиксирует архитектурный потолок: какие цели достижимы из коробки, какие требуют доработок, а какие в принципе не закроются на этой платформе.
Главная ошибка: путаница с объектом внимания
В первом подходе я записал «объект внимания» как программный продукт и представители вендоров. Это типовая ошибка.
Объект внимания (альфа) — это предмет метода: то, на что направлено действие метода и чьи состояния отслеживаются, чтобы не потерять внимание в длинной цепочке операций. Альфа может быть как физическим объектом (системой), так и абстрактным (описанием, решением, знанием). Программный продукт сам по себе под действием моего метода не меняется: он каким был на рынке, таким и остаётся. Представители вендоров — контрагенты, не альфа.
Что реально трансформируется в моём методе выбора:
-
Знание о рынке TMS — от «нулевого» до «структурированного по критериям».
-
Чек-лист критериев — от «пусто» до «утверждённый инструмент оценки».
-
Список кандидатов — от «открытого множества» до «один финалист».
-
Решение о выборе — от «не принято» до «согласовано».
Программный продукт и вендоры — это окружение метода, а не альфа. Различение между «то, что я меняю» и «то, что меня окружает» оказалось практическим. Стоило записать четыре альфы, как стало видно, что у каждой свой набор характеристик и состояний. Раньше я смешивал «функционал, цену, документацию» (это про чек-лист) с «полнотой охвата, глубиной по каждому, актуальностью» (это про знание о рынке) — и характеристики путались.
Метод и переходы состояний
Метод выбора TMS у меня сложился как критериальный анализ из четырёх этапов. Опишу через переходы состояний альфы «Знание о рынке TMS».
| # | Состояние | Признак |
|---|---|---|
| S0 | Нулевое | Рынок не изучен |
| S1 | Поверхностное | Знаю имена, читал маркетинг |
| S2 | Структурированное | Есть матрица сравнения по чек-листу |
| S3 | Верифицированное | Данные подтверждены не только вендором |
| S4 | Применённое | Знание превращено в ранжированный список |
Переходы:
-
S0 → S1 — desk research. Сижу за ноутбуком, собираю с ИИ-агентом информацию из открытых источников. Дёшево, быстро, неполно. Зато сразу видно, кого вообще нет смысла рассматривать.
-
S1 → S2 — построение матрицы по чек-листу. Беру шаблонный чек-лист TMS (с ИИ-агентом) и адаптирую под бизнес-процессы маркетплейса. Заполняю «вендор × критерий».
-
S2 → S3 — верификация. Анкеты вендорам, демо, чтение технической документации. Здесь дешёвые источники истощены, начинаются дорогие.
-
S3 → S4 — сопоставление с ТЗ и ранжирование.
Принцип, который раньше для меня был неявным, а после разбора стал явным: дешёвые источники истощить раньше, чем подключать дорогие. Если идти к вендорам без desk research, потратишь часы на разговоры с теми, кто заведомо не подходит.
Критический путь и узкие места
Когда работы выложены последовательно с зависимостями, видно критический путь — самую длинную цепочку, которая определяет общий срок проекта.
У меня вышло так:
Брифинг (1д)
→ Чек-лист критериев (0.5д)
→ Ожидание ответов вендоров (5–7д)
→ Финализация матрицы (0.5д)
→ Ранжирование (0.5д)
→ Отчёт (0.5д)
→ Согласование с СРО (3д)
Узкие места видны сразу:
-
Ожидание ответов вендоров. Я тут вообще не работаю, я жду. Сократить можно только pre-warming-ом: предупредить вендора заранее.
-
Согласование с СРО. Зависит от слота в его календаре. Сократить можно только бронированием слота заранее, ещё на этапе брифинга, на дату через 2.5–3 недели.
Когда я добавил в схему свою параллельную загрузку (40% времени уходит на два других стрима — WMS и интеграцию СДЭК), картина изменилась. Короткие работы на финале — финализация матрицы, ранжирование, отчёт — при полной выделенности проекту заняли бы по полдня каждая. При 60%-й загрузке плюс переключение контекста между тремя стримами эти работы реально занимают по дню каждая. Это +2 рабочих дня к сроку, не из-за сложности задач, а из-за фрагментации внимания.
Вывод, который я не получил бы без FPF-разбора: я сам — узкое место на финале проекта. Не вендоры, не СРО, не директор по логистике. Если на одну неделю финала меня перевести на 80%+ TMS, проект сократится на 2–3 дня.
Что унесу с собой
-
Правильный выбор объекта внимания в задаче определяет всю дальнейшую работу.
-
Критический путь видно только когда работы выложены с зависимостями. Без зависимостей все работы выглядят одинаково срочными.
-
Свою параллельную загрузку надо учитывать в плане. Иначе скорость кажется реалистичной, а срок — нет.
На основе этого разбора сделал отдельный документ-план для согласования с СРО.
