Если вы занимаетесь бизнес анализом или являетесь бизнес-аналитиком, вы скорее всего сталкивались с требованием описать бизнес процесс в формате AS IS. Что это такое и практический пример использования подхода вы найдете в этой статье.
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — “как есть”), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).
Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.
Описывать нечего
Если в компании не проводилась ранее оптимизация бизнес-процессов, а это обычная ситуация, нет каких-то четких инструкций, то каждый из сотрудников будет работать по-своему.
Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.
Например, процесс согласования счета даже в одной организации может выполняться очень по-разному. Кто-то сначала пойдет к начальнику отдела, а кто-то направится сразу в бухгалтерию подписывать счет.
Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:
– Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
– Другой сначала позвонит, все уточнит.
– Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.
Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают “кто как привык”. В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.
Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.
Описывать незачем
Еще один важный аспект, с которым я столкнулся на практике. О том, что в компании что-то делают неправильно, все и так давно догадываются. Иначе бы вас, как специалиста, не пригласили. И от вас не ждут описания существующих проблем, они часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант придет, осмотрится, опросит людей, после чего выдаст рекомендации, как надо делать, чтобы решить существующие проблемы. Т.е. людям не нужны нотации «Как есть». Им сразу хочется увидеть «Как должно быть».
Зачем создают нотации AS IS?
Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой точки зрения. Большой объем работы повышает ее стоимость. Но нужно ли это заказчику? Он и сам знает, что компания как-то работает, потому что бизнес приносит прибыль и т. д. Вас он нанимает не для того, чтобы за их деньги вы им поясняли, какую схему работы они сами организовали. Им хочется увидеть от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.
Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.
Пример использования нотации AS IS и TO BE
Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
Выполняют выпуск хлеба.
Далее они должны сдавать полученную партию и документы охране.
Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
Охрана выдает разрешение.
Цех выпечки передает партию товара на склад.
Склад принимает товар.
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
Выполняют выпуск хлеба.
Цех выпечки передает партию товара на склад.
Склад принимает товар.
Комментарии (11)
Elpi
10.01.2022 11:53+1Я не бизнес-аналитик и на полноту анализа не претендую. Это лишь субъективные заметки в стиле "адвокат дьявола".
Я полагаю, что перед нами пример высокомерного и пренебрежительного отношения компьютерщика к реально работающим людям. В целом, к тому, что было до тебя. Обычно такие люди уверены, что жизнь на планете началась лишь после их рождения.
-
Публикация написана в стиле пролетарского гимна "Интернационал", цитирую официальный перевод с французского А.Я. Коца:
Вставай, проклятьем заклеймённый,
Весь мир голодных и рабов!
Кипит наш разум возмущённый
И смертный бой вести готов.
Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим —
Кто был ничем, тот станет всем.
Обратите внимание на две фразы: а) весь мир ... мы разрушим; б) кипит наш разум возмущенный. Как это по нашему! Оно у нас всегда "кипит". И мы замечательно рушим, но значительно хуже создаем.
Автор пишет, цитирую: "Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают “кто как привык”. В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего." Удачно, что в статье рассматривается хлебокомбинат. И наглядно видно, что - хотя хлеб выпекают уже тысячи лет - никакого "как есть", по мнению автора нету. Хлеб как-то есть - а вот процесса его выпечки ну нету!!
Автор исходит из необходимости за вымороченные деньги навязать заказчику собственное "видение". Плевать, что там у него было до него. Забыть как страшный сон. "Мы пойдем другим путем!" (с)
Я бы полагал, что имеющийся процесс заслуживает внимания хотя бы потому, что у заказчика нашлись деньги, чтобы пригласить нашего аналитика. Если хлеб на выходе имеется - то бизнес-процесс есть.
Главное. Бездумное "революционное" разрушение имеющегося - это любимая забава младых "ррр-р-революционеров". Они же всегда знают, как лучше.
Есть практическое правило - "работает - не трогай!" Если хочешь сделать иначе, что-то свое - отойди на свободное место и сделай. Не ломай того, что не ты делал!!!
Если руководство предприятия нашло финансы и силы привлечь аналитика для анализа ситуации и повышения эффективности на действующем производстве - это вовсе не означает, что они дураки и все нужно поломать. Возможно, квалифицированный консультант осознал бы, что помочь можно руководителям. Осознать, как обстоит дело в настоящий момент, взглянуть на ситуацию с другого ракурса и, возможно, предложить внести некоторые изменения, которые уже работающую схему сделают лучше. Создать что-то работающее крайне сложно. А вот сломать - ну просто раз плюнуть...
Совет автору
Посмотрите старый фильм "Собственное мнение" (https://www.kinopoisk.ru/film/43895/)
Gold_fish
10.01.2022 12:17+3AS-IS нужен для выявления проблематики и слабых мест, для понимания консультантом специфики бизнеса, для общения с заказчиком на одном языке, для определения этапности внедрения изменений. Без AS-IS TO-BE выходит полностью оторванным от реальности и воплощен не будет никогда. Ниодна работающая организация не пойдет на принцип "сломать все".
Буквально недавно пришлось работать с такими гореконсультантами. Компания имеет свои огромные специфики навязанные законодательством и рынком. AS-IS был абсолютно не проработан, на его основании вывален TO-BE который просто проигноррировал все специфики. Результат - отчет просто ушел в корзину из-за своей неадекватности.
kaiu
10.01.2022 12:48Может и всё нормально, но! Любое решение надо проверять на его историю, в данном случае понять почему было именно так, а не иначе, для чего грабли в этом коде или законодательстве? Скорее всего выясниться, что была договоренность с цехом выпуска и складом, а излешек продавался налево, а так как охрана должна за все отвечать, то сделано было вот такое посредническое участие, чтобы не договаривались. Конечно, с наличием технических устройств контроля и тд, все это может и и не нужно...а может и нужно, все равно руководитель примет решение на изменение бизнес-процесса. Так что описывайте аналитики историю почему было так, а не потому что это сейчас не эффективно, и что мы потеряем.. или это и так дублируется.. и что получаем.
Lauva
10.01.2022 13:18Я, понял о чем эта статья. Но мне не понятно, на том примере, который вы описали, чем вы сильно ускорили процесс? Я понимаю, что если Вы не написали в статье, то остальное можно опустить. Но по идее, функция охраны просто переместилась на последний этап - выезд со склада отправляемой продукции. Скорее всего конечно пересчитывать они не будут товар. Но документы отправки проверить обязаны. Иначе я вообще не понимаю функцию охраны на данном предприятии.
SergeyT-hh
10.01.2022 18:26+1AS IS почти всегда нужен. Даже если процессы не описаны и не формализованы они все равно существуют и если позвали аналитика, значит владелец задумался об их нормализации. Если так, то AS IS не обязательно описывать слишком детально, но вы их все равно получите при сборе информации и нужно будет разобраться почему так и проработать наиболее оптимальный вариант. Соответственно нужно обсудить с владельцем и это удобнее делать визуально, чем на пальцах.
Ну а в более зрелых компаниях, особенно если осуществляется оптимизация с использованием функционально-стоимостного анализа, без AS IS не обойтись, т.к. не с чем будет сравнивать TO BE.
surVrus
10.01.2022 23:19-1As-Is обычно нужен для определения вовсе не того, как есть. То как есть - обычно не важно. Обычно важно определить элементы автоматизируемой системы и связи между ними. То есть кто и как выполняет какие роли, какие можно выделить объекты, как именно связаны абстрактные объекты с конкретными в физическом мире.
Кажется, что бизнес-процессы в разных фирмах разные. Но с определенной точки зрения, обычно все они вполне укладываются в одну модель. Общая архитектура такой модели GERAM (ISO 15704).
Далее, ISO/IEC 15288. Подробное описание процессов. Все бизнес-процессы и все технические процессы.
Потом все интегрируется по IEC 62264. Ну а для периодического производства (тот же хлебокомбинат) Описание моделей процессов периодических IEC 61512.
Там описаны действительно все возможные варианты процессов, которые отработаны и используются в "лучших практиках". Мне пока не удалось найти в обследуемых предприятиях хоть чего-то нового, чего бы не было в указанных выше моделях (это по результатам более 10 проектов). Обычно если выкинуть или исказить часть элементов бизнес-процессов из этих стандартов, то получается текущее состояние конкретного предприятия.
Ну или иногда процессы описанные в стандарте совсем иные, чем на реальном предприятии. Тоже ничего страшного, обычно процессы из стандартов намного совершеннее, чем те, которые есть. Сначала трудно понять, потом "как же это здорово, мы да такого не додумались!". Но да, надо серьезно менять подход к продукции. Пример: есть мастер-рецептура для хлеба. Она привязана к оборудованию, к конкретным условиям производства. В ней указаны допустимые пределы количества каждого компонента. И всегда, каждый раз есть отдельная рецептура конкретной партии (рецептура партии). В ней указано реальное количество использованных компонентов. Рецептура партии создается копированием мастер-рецептуры и потом редактируется при производстве. Планирование и закупки, калькуляция себестоимости ведутся по мастер-рецептуре. А вот учет компонентов, фактическая себестоимость - по рецептурам партий. Тогда нет проблем учета разницы расхода материалов в каждой партии. И еще куча "плюшек". И да, мастер-рецептуру видит технолог, а рецептуру партии - мастер смены.
Еще есть отдельные виды рецептур для разработки нового продукта, без привязки к оборудованию, для лаборатории. И все эти разные виды рецептур связаны друг с другом, все это прекрасно живет и позволяет и быстро разрабатывать новый продук, и быстро вносить изменения, и прекрасно управлять качеством продукции.
С другой стороны, зачем что-то придумывать, если все равно почти все нормальные системы автоматизации построены именно по этим стандартам. И не надо инструкции придумывать, берем куски из стандартов и адаптируем.
Есть и самое важное НО! Там логика совсем иная, ее сложно понять. Но когда поймешь - то сделать потом конкретные регламенты и инструкции - быстро и просто. И да, эти стандарты нужны для инженеров и специалистов высокой квалификации. Обычные рабочие в них все равно ничего не понимают, но это и не надо. Для них все адаптируется в виде комиксов и рисунков. Так лучше всего обычно.
AzIdeaL
10.01.2022 23:43-1Прочол и тех, и других: добавить нечаво...
Хотя... Вобью гвоздь в ворота (новые - для баранофф)), шоб не переливали из пустого в поржнее: AsIs - это ВХОД в Чорный-пречорныйЯсчик (далее, ЧЯ), представляющий ФункциональнуюМодель (далее, ФМ); ToBe - это ВЫХОД из ЧЯ, внутри которого идёт преобразование входного говна в выходную сказку))).
ЗЫ: что есть ФМ, в народе именуемый крабом, надеюсь, найдёте в литературе)
beskov
11.01.2022 12:32вы кажется путаете должностные инструкции и рабочие инструкции
должностная инструкция описывает, ЧТО должна делать должность
рабочая — КАК
Tannikk
12.01.2022 10:10As is нужен, так как результат реинжиниринга зависит от вовлечения участников процесса в анализ и редизайн, а для этого они все должны одинаково понимать "как есть", каковы цели, как измеряем, где находимся и каковы проблемы.
Все это основа конструктивной диалога. Вопрос, что не надо как есть описывать в мелких деталях, и на этом именно надо экономить.
Таким образом, как есть нужен в первую очередь команде, а не консультанту. Заказчику он тоже будет нужен, чтобы понимать предложенные изменения.
chercheur
"Надо ли описывать AS IS" - с этим холиваром я впервые столкнулся лет 20 назад ещё. Всё зависит от целей проекта: для чего на самом деле мы процессы описываем. Чаще всего на выходе действительно нужно "TO BE", которое на самом деле представляет собой оптимизированный AS IS - как в примере в статье