Ответ вслух Middle AS-IS, TO-BE и BPMN обновлено

AS-IS: всегда ли нужен

Вопрос

Всегда ли нужно моделировать AS-IS? Как вы решаете, насколько подробно его описывать?

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

AS-IS нужен в большинстве проектов улучшения: без него непонятно, что именно плохо, и нечем доказать, что стало лучше. Описываю, как работа идёт на самом деле, а расхождение с регламентом записываю как находку.

Что должно прозвучать в ответе

  • AS-IS нужен, чтобы найти проблемы и получить базовую линию

  • Описывать реальность, а не регламент

  • Глубина по цели: достаточно, чтобы увидеть проблемы и измерить

  • Когда можно сократить: процесса нет или он заведомо меняется целиком

  • Даже при сокращении собираю ключевые метрики «до»

Что могут спросить следом

  • Как быть, если каждый сотрудник делает процесс по-своему?
  • Где брать цифры для AS-IS?

Разбор

AS-IS нужен в большинстве проектов улучшения: без него непонятно, что именно плохо, и нечем доказать, что стало лучше. Описываю, как работа идёт на самом деле, а расхождение с регламентом записываю как находку. Глубину выбираю по цели: если задача сократить срок, мне важны шаги, ожидания и передачи между ролями, а не каждый клик. Подробно рисовать процесс, который всё равно заменяем целиком, дорого, тогда ограничиваюсь обзорной схемой. Если процесса нет, например новый продукт, AS-IS пропускаю, но собираю то, с чем будем сравнивать: как клиенты решают задачу сейчас. Если каждый делает по-своему, рисую основной вариант и отмечаю варианты отдельно: сама вариативность часто и есть проблема.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.