Практически каждый проект оптимизации или автоматизации начинается с фразы: «Сначала опишем, как есть, потом — как должно быть». Звучит логично. Но именно на этом этапе закладываются ошибки, из-за которых модель AS IS становится бесполезным документом, а проект — бюрократической имитацией. Разберу три ключевые ошибки и покажу, почему иногда необходим третий статус модели процессов.

Ошибка №1: Идеализированная AS IS — модель, которой не существует Самая распространённая и самая коварная ошибка — построение AS IS не по реальной работе, а по тому, как работа должна выполняться. Классический пример: аналитик опрашивает руководителя, тот рассказывает, как процесс описан в регламенте и должностных инструкциях. На выходе получается красивая схема без петель, без ручных обходов, без «а давай я тебе на почту скину». Руководитель искренне верит, что так и происходит — но он не знает, как на самом деле выполняют рутинные операции его подчинённые. Получается модель SHOULD-BE — «как должно бы быть». Она приукрашена, искажена и несёт ложную информацию. На её основе нельзя анализировать проблемы, потому что проблем в ней просто нет. Что делать: · Опрашивать исполнителей, а не только руководителей. Именно они знают, где ломается процесс. · Наблюдать за реальной работой: кто какие файлы пересылает, в каких системах дублирует ввод, где ставит «заглушки». · Фиксировать все отклонения от регламента — они и есть источник улучшений. AS IS — это не «как красиво», а «как больно». Чем честнее модель, тем полезнее она для анализа.

Ошибка №2: AS IS по регламентам — автоматизация несовершенных процессов Логика «возьмём регламент и опишем по нему» кажется экономией времени. На деле это приводит к тому, что в модель, а затем и в систему, переносятся все существующие ошибки и неэффективности. Если проектировать информационную систему без объективной картины текущего состояния, есть реальный риск «зашить» в неё существующие проблемы как «ингредиенты». Вместо улучшения получается автоматизация хаоса: система дублирует, а не заменяет несовершенный документооборот, и внедрение приводит лишь к дополнительным издержкам. Регламент описывает норму, а не факт. Реальность всегда сложнее: есть обходные пути, «временные» решения, которые живут годами, неформальные согласования по телефону. Всё это не попадает в регламент — и не попадает в модель, если строить её только по документу. Что делать: · Использовать регламенты как один из источников, а не как единственный. · Комбинировать: изучение документации + интервью с исполнителями + наблюдение. · Задавать вопрос не «как должно быть?», а «как вы делаете это сегодня?». Регламент без реальности — это карта без рельефа. По ней можно идти, пока не упрёшься в гору, которой на карте нет.

Ошибка №3: Слепое доверие BPMN для описания «Как есть» BPMN — мощная нотация. Но у неё есть особенность: она создана для исполняемых процессов в BPM-системах. Когда её применяют к реальным «эксельно-аутлуковым» процессам — а именно так выглядит большинство AS IS — элементы языка начинают искажать реальность. Модель становится малопригодной для анализа: она выглядит как «правильный» процесс, хотя в жизни там ручные передачи, дублирование данных, петли согласований. Аналитик получает схему, которую невозможно использовать для обоснования оптимизации. Что делать: · Для AS IS неавтоматизированных процессов использовать более простые нотации: блок-схемы, IDEF0, ARIS, или даже простые карты процессов. · BPMN оставить для TO-BE и для тех участков, которые действительно автоматизируются. · Не «натягивать» реальность на нотацию, а выбирать нотацию под реальность.

часть 1