Почему нельзя пропускать этап с описанием AS IS

Недавно на хабре столкнулась с мнением, что бывают случаи, когда описывать бизнес-процесс «as is» не нужно. 

Автор приводит примеры, что описывать может быть нечего и незачем, поэтому этап описания «как есть» можно опустить и смело переходить к следующему этапу - к описанию «to be». 

И это вредный совет.

Да, иногда можно не упарываться и опустить этап с построением схемы с соблюдением всех правил используемой нотации. 
Но уж точно нельзя совсем уж пропускать этап фиксации того, как бизнес-процесс выглядит на текущий момент.

Почему нельзя пропускать этап с описанием AS IS?

1️⃣Потому что весь смысл этого действия не в том, чтобы показать, какой бизнес-аналитик молодец, не зря его наняли, все понял и быстренько все разрулит, нарисовав картинку идеального будущего «to be».

Смысл этого действа состоит в том, чтобы беспристрастно зафиксировать текущее состояние и удостовериться у всех участников бизнес-процесса в том, что аналитик верно понял слабые места, проблемы процесса и вообще его суть. Это исходное состояние бизнес-процесса можно описать текстом, таблицей, простой схемой и т.д. (если требуется экономия времени и сил). А потом согласовать результат описания с другими участниками/владельцем бизнес-процесса.

Идеально, если будет возможность посчитать какие-то количественные показатели бп, чтобы потом была возможность сравнить картинку «to be» с исходными данными, и удостовериться, что не стало хуже. 

2️⃣И ещё возможна такая ситуация, что процесс будет зафиксирован «как есть», а проектирование «to be» будет отложено в долгий ящик. Т.к. процесс худо-бедно, но работает, и после фиксации процесса «as is» станет понятно, что не все так критично. А силы аналитика можно будет направить на более приоритетные задачи.

3️⃣Также не стоит забывать, что ничто не вечно под луной. Аналитика могут перекинуть на другой проект прям в середине внесения изменений в бизнес-процесс/он может сам уйти в другую компанию, не закончив претворение «to be» в жизнь и т.д. И если он ошибся, неверно понял участников бизнес-процесса, сделал свою работу плохо, то следующему аналитику придётся несладко.
И что придется новенькому делать на проекте в самом начале? Долго и упорно искать правду и восстанавливать картинку того, что было, что нужно изменить и что уже изменено. А это может быть настолько тяжело, что новенький долго не продержится, а проект станет совсем не конфеткой, даже если изначально это была интересная задача.
Сама сталкивалась с таким на практике, и очень хотелось передать привет тому, первому, который решил, что фиксировать «as is» незачем, а хранители знаний (участники бп) к тому моменту уже уволились.

Короче говоря, не пренебрегайте описанием «as is», пожалуйста.

Поделитесь своим мнением, вы всегда фиксируете исходное состояние бизнес-процессов?