TO-BE - это ещё не решение
У целевой модели есть одно уязвимое место: она ещё не столкнулась с реальностью.
Поэтому на ней всё обычно выглядит убедительно. Согласование занимает один день, данные автоматически переходят между системами, а лишние шаги и дублирование исчезают.
Если поставить рядом AS-IS и TO-BE, выбор очевиден. Слева - накопившиеся обходные пути и ручные операции. Справа - порядок, скорость и вполне объяснимое желание поскорее всё это внедрить.
Но между двумя моделями находится компания, которая не меняется вместе со стрелками на схеме.
Руководитель должен начать согласовывать документы быстрее, хотя его загрузка осталась прежней. Сотруднику передают новую ответственность, не освобождая от старых задач. Системы должны обмениваться информацией автоматически, хотя исходные данные по-прежнему заполняются как придётся.
На целевой модели эти детали легко потерять. Там уже живут люди с нужными полномочиями, работают настроенные системы и соблюдаются договорённости, которых пока не существует.
Получается не будущий процесс, а будущая компания. Причём сразу в финальной версии.
Само по себе это не проблема. TO-BE для того и создаётся, чтобы показать другую логику работы. Вопрос появляется позже: какие условия должны измениться, чтобы эта логика выдержала встречу с обычным рабочим понедельником.
Можно убрать из модели лишнее согласование. Но если у сотрудника не появилось право принимать решение, согласование вернётся - возможно, уже в переписке или личных сообщениях.
Можно удалить ручную таблицу. Но если основная система не решает задачу, сотрудники заведут новую. Обычно с названием вроде «Рабочая_финал_точно».
Можно передать ответственность команде. Но без полномочий это будет прежняя зависимость от руководителя, только с более современными названиями ролей.
Поэтому TO-BE полезнее воспринимать не как готовое решение, а как гипотезу.
Если изменить роли, правила, загрузку и инструменты, процесс сможет работать иначе. Пока эти изменения не произошли, перед нами только модель - пусть и очень убедительная.
Иногда после такого взгляда схема становится сложнее. В ней появляются переходные этапы, ограничения и решения, которые нельзя внедрить одним движением. Выглядит скромнее, зато меньше напоминает идеальную компанию, нарисованную поверх существующей.
Качество целевого процесса определяется уже не количеством удалённых блоков, а тем, насколько точно понятны условия, на которых держится новая логика.
AS-IS объясняет, почему система работает именно так. Хороший TO-BE показывает, что должно измениться, чтобы она действительно смогла работать иначе.
Ещё больше обо мне | sergey-suslov.ru
· 27.07
To-Be or Not To-Be... Я лично на практике понял, что и глубинный анализ As-Is/To-Be, 1000 диаграмм (от Ганта до UML Class) бесполезны пока не прозвучит главный вопрос "А зачем это вообще нужно, вот что это решит и решит ли?".
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 27.07
Так без ответа на этот вопрос и в проект заходить не стОит
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.07
Есть кейсы где такой вопрос никто не задавал)))
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.07
А не задавал кто кому? Вы на какой стороне были? Заказчика или подрядчика?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 28.07
Я выступал в роли сторонего аудитора системы (нанятый учередителями, так как было подозрение что что-то идет не так), по итогу выяснилось что заказчик не сказал, подрядчик не спросил, деньги сгорели.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён