Процесс as is и to be в чем разница
Оптимизация бизнес-процессов предприятия
В этой статье речь пойдёт об оптимизации бизнес-процессов предприятия, их описании и моделировании.
До определённого уровня развития компания вполне может обойтись без «регламентированной системы деятельности». Трудно в общем случае ответить на вопрос «когда пора оптимизировать бизнес-процессы предприятия?», однако, нет сомнения, что этот момент приближают
Итак, если в определённый момент развития вы обнаружили, что
имеет смысл заняться оптимизацией бизнес-процессов предприятия. Отметим, что в ряде случаев работу по изменению бизнес-процессов целесообразно провести, не дожидаясь указанных симптомов, например, в случае существенного изменения структуры управления или при внедрении новой информационной системы.
Вопросам моделирования, описания и оптимизации бизнес-процессов предприятия посвящено много полезных материалов. В этой статье, не претендуя на методологическую новизну, я хочу высказаться по некоторым аспектам практической реализации этой работы. И начнём мы с
1. Выбора инструмента графического описания бизнес-процессов
Почему-то этому вопросу придают огромное, если не решающее значение. Выскажу крамольную мысль: программное обеспечение (ПО) описания и оптимизации бизнес-процессов предприятия имеет значение только в том случае, если разработка проводится с целью дальнейшего внедрения бизнес-процессов в информационную систему. Но современные ИС имеют собственные средства описания бизнес-процессов, поэтому само по себе обсуждение ПО оптимизации бизнес-процессов предприятия потеряло смысл.
Вместе с тем, при обсуждении этого вопроса иногда забывают, что описания бизнес-процессов нужны не для разработчиков, а для сотрудников предприятия, и важнейшим критерием выбора инструмента описания бизнес-процессов является его доступность для персонала предприятия как на этапах согласования и оптимизации бизнес-процессов, так и на этапах исполнения и модернизации.
2. Модели «AS IS» и «TO BE» оптимизации бизнес-процессов
Традиционная схема оптимизации бизнес-процессов предприятия предполагает описание на первом этапе действующих процедур (модель бизнес-процессов «AS IS») с последующей оптимизацией до модели «TO BE» («как должно быть»). Иногда заказчикам работы по оптимизации бизнес-процессов не понятно, зачем нужен первый этап. Они ожидают, что исполнители принесут на предприятие готовые «типовые» бизнес-процессы, а разработку модели «AS IS» воспринимают, как попытку «накрутить» трудоёмкость.
Хочется предостеречь от такого подхода. Методика внедрения системы бизнес-процессов, не опирающейся на действующие процедуры предприятия, называется не оптимизацией бизнес-процессов, а реинжинирингом. Разница примерно такая же, как между терапией и хирургией, а к скальпелю обычно обращаются тогда, когда другого выхода нет. Подумайте об этом в момент принятия решения.
Описание «AS IS» позволяет выяснить существующие противоречия и провести первичную оптимизацию бизнес-процессов. Для этого модель «AS IS» должна быть обсуждена со всеми участниками бизнес-процессов и согласована с ними «под роспись».
3. Оптимизация бизнес-процессов предприятия
«Оптимизировать» нечто можно только по определённым критериям. Оптимизировать бизнес-процесс можно по критериям стоимости, продолжительности, количества транзакций и т.д. Понятно, что эти критерии являются «внешними» по отношению к бизнес-процессу, появляются из более общего контура управления предприятием. Давайте подумаем, из какого?
4. Внедрение оптимизированных бизнес-процессов
На этот случай хочется поделиться способом внедрения бизнес-процессов, названной нами «методикой контрольных карт», которая заключается в следующем. По всем бизнес-процессам составляются списки контрольных точек (контрольные карты), в которых мы будем контролировать соблюдение бизнес-процессов. Удобными контрольными точками являются моменты передачи документов, информации между сотрудниками. В этом случае «контролёром» может быть сотрудник, которому информация должна быть передана. Пример контрольной карты представлен на рис. 1
Рис. 1 Пример контрольной карты бизнес-процессов
Контрольная карта исполнения бизнес-процесса отчёта по авансам
1. Отчёт не был предоставлен в течение 2-х дней
Форматы контрольных карт передаются участникам бизнес-процесса. «Контролёры» обязаны фиксировать в картах факты
Карты собирает руководитель внедрения бизнес-процессов, анализирует их, обсуждает с участниками процедуры. Возможными последствиями могут являться:
5. Модернизация бизнес-процессов
Жизнь не стоит на месте, поэтому рано или поздно разработанные на предприятии бизнес-процессы опять потребуют оптимизации. Чтобы бизнес-процессы, с одной стороны, соответствовали реальности, а с другой стороны, не мешали нормальному развитию компании, их нужно своевременно модернизировать, согласовывая новые редакции с участниками и доводя изменения до всех заинтересованных лиц.
Тогда система бизнес-процессов предприятия станет реальным инструментом повышения эффективности бизнеса на процедурном уровне.
Как заказать наши услуги
В соответствии со ст. 1274 ГК РФ при публикации материала сайта в Интернете, указание авторства и индексируемая ссылка на источник публикации обязательны.
197183, Санкт-Петербург, Представительство в Москве
Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE)
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — 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 стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
Хочу все знать: бизнес-анализ. Часть 2
Анализ и описание процессов
Следующим пунктом бизнес-анализа является описание бизнес процессов. На этом этапе, обычно, рисуют, так называемые диаграммы бизнес-процессов «As is». И вот тут-то всех и поджидают проблемы, что называется, на ровном месте. Самая большая проблема в том, что за деревьями не видно леса. Так же, как и при описании бизнес-целей, зачастую народ увлекается описанием того, как все работает прямо сейчас. При этом редко кто задается целью разобраться, а насколько текущие процессы вообще соответствуют тому, как все должно быть? Все наверняка знают одно из правил автоматизации: «автоматизируя бардак — мы получаем автоматизированный бардак, и ничего более». Так вот, чтобы не строить очередной «скайнет», который всех уничтожит, необходимо понять — «а как же все вообще должно функционировать?». И это очень интересная задача.
Конечно, далеко не все бизнес-аналитики в состоянии с ходу накидать бизнес-процессы, как все должно происходить в каждом конкретном случае. Но тут никаких тайн нет. Для решения этой задачи, надо просто позвать риск-аналитика, если он есть, ну или немного ознакомиться с профильной литературой и чуточку подумать. Это не сложно, честно.
Так вот, не будет далеко уходить от нашего прекрасного примера с почтой, и рассмотрим «простейший» процесс — «услуга доставки бандеролей». Для тех, кто знает кухню почты, сразу предупреждаю, что дальше описывается упрощенный пример в «рафинированном виде», то, каким его может увидеть бизнес-аналитик, или даже менеджер. Подробностей в стиле «привязки к существующей инфраструктуре» и прочих «исторически сложившихся условий» тут не будет. По сути, все эти детали рассматриваться уже на третьем этапе работ бизнес-аналитика, который в данной статье не рассматривается. Более того, на данном этапе нам вообще не нужны технические детали и даже скажу больше, от них надо всячески уходить, иначе мы просто затрудним себе задачу. Подробности и детали, как и описание процессов «As Is» — нужны, важны и используются именно в части анализа процессов и последующих предложений, рекомендаций и прочего
Итак, у нас есть цель – доставка ценностей от заказчика – получателю. У нас есть вариант достижения этой цели:
Продолжаем. Нам необходимо гарантировать удовлетворение потребности. Просто потребности, без учета затрат, объемов и прочего. Можно сказать, что если заинтересованные лица воспользовались этой услугой и остались довольны результатом, значит — мы успешно достигли цели. То есть, нам надо просто понять, а почему эти самые лица могут быть недовольными? Вариантов немного: ожидаемые события не случились, или случились не так, как ожидалось. В нашем конкретном случае имеем куст вариантов с уточняющими вопросами:
Итак, мы уже знаем о нашем процессе кое-что, но как все это сделать доступным и понятным для любого человека, без прочтения «… дцати» страниц текста? Ответ известен всем – надо просто нарисовать. И, как обычно, нас поджидает другой «сюрприз». Большинство используемых методологий графического отображения бизнес-процессов рекомендуют на диаграммах отображать именно технические детали (BPMN, UML, EPC и др.). В этом нет ничего плохого и на этапе анализа и подготовки рекомендаций диаграммы «As Is» и «To Be» именно такими и должны быть. Но когда мы описываем непосредственно сам процесс, его логику и правила, эти детали, как песок пустыни, покрывают любые сокровища. В результате, мало кто в состоянии сразу оценить корректность или ошибочность самих процессов или их понимание бизнес-аналитиком.
Вот мы плавно и подошли к вопросу изобретения очередного «велосипеда». Да, мы не будем мудрствовать лукаво, а просто применим «самопальную» нотацию для описания логики бизнес-процесса. Поскольку эта диаграмма рассчитана на неподготовленных пользователей (менеджеров, аналитиков, разработчиков) то использование какой-либо хитрой нотации будет скорее во вред.
Мой вариант такой диаграммы я называю «Сафед-диаграмма», от таджикского/персидского «сафед»- ясный, чистый, белый. По сути, Сафед-диаграммы содержат консолидированную и обобщенную информацию о логике процессе, что упрощает понимание. Сами диаграммы я «рисовал» в Excel, так что никаких магических инструментов так же не требуется. И еще небольшое пояснение, я не привожу ни текстового описания процесса, но то, почему указаны те или иные особенности и детали, ни даже пояснений к используемой нотации. На данном этапе моя цель – показать, насколько диаграмма-схема может быть понятной даже без прочтения текстового описания и без приведения расшифровки к используемой нотации.
Итак, отображение логики процесса «указания услуги доставки бандероли» будет выглядеть примерно как на рисунках ниже (я разбил сам процесс на 3 части, чтобы было удобно его рассматривать):
Часть 1 (крупнее): 
Часть 2 (крупнее):
Часть 3 (крупнее):
И дополнительные схемы — движение и источники данных для процесса (крупнее):
Как можете видеть, на диаграммах явно указано, кто и что делает, откуда берет или где фиксирует данные, кто отвечает за их (данных) актуальность и заполнение. Хоть сейчас составляй должностные инструкции. Более того, видно, какие должностные обязанности можно совместись. Одним словом, мы прозрели и явно видим, что должно происходить.
При этом у схемы процесса есть места вокруг самой диаграммы, где мы вольны добавлять произвольные пояснения и детали (в моем случае я добавил пару рассшифровок и коментарии к этапам). При необходимости, можно добавить и «второй слой» для замечаний, и дать возможность заинтересованным лицам вносить свои вопросы, комментарии и/или замечания к отдельным шагам процесса.
Если просмотреть приведенную схему процесса с небольшой толикой внимания, то сразу видны и упущения и недостатки. Для примера,
Итак, очень известная в России компания, про которую слышал каждый. И снова процесс внедрения системы для автоматизации продаж.
Представители компании каждый раз с гордостью заявляли, что в компании все процессы не только описаны, но и промоделированы в ARIS. Это не считая «полного Kaizen» во всем. При этом, к сожалению, предоставить описание процессов так и не смогли, в рузультате в спешке провели экспресс «бизнес-анализ», качество которого было ужасным.
И вот, уже на этапе внедрения системы, со всевозможными подписанными высокими сторонами планами, схемами, описаниями, готовлю команду заказчика, которая будет внедрять, поддерживать, эксплуатировать систему на головном предприятии и у дистрибьюторов. И снова чудеса случаются с «рекомендованным ассортиментом». На этот раз, из примерно 20 позиций (единых для всех), около половины отсутствуют в рабочей информационной системе. То есть, в Axapta у заказчика нет товарных позиций, которые пару месяцев назад, подписаны Генеральным Директором, как ключевые, для продаж в течение года.
Начинаем разбираться, Менеджер Проектов (ПМ) со стороны Заказчика, Генеральный, начальник Коммерческого отдела – не могут внятно сказать, откуда вообще этот список был взят. Как понимаете, в описанных бизнес-процессах, ни сам приказ, ни то, как он формируется, даже не упомянуты. На выписе, в бухгалтерии (там сидят на 1С) — этих позиций нет. На следующий день, первую половину дня все участники представления находят поводы на проблему «забить» (планерка, совещание, встреча, митинг, звонок, обед). Своими силами нашли некоторые позиции, отдаленно напоминающие те, что в приказе. Все равно порядка 5ти из них – не имеют даже отдаленных аналогов. После обеда, ставлю всех на уши, перерыли все, что только могли – нет товара такого и точка. Ни IT, ни выписка, ни бухгалтерия не сдаются, и молчат как партизаны на допросе в гестапо. И тут, после повторенного множества раз вопроса «а как эти данные в итоге появляются в системе, и кто за это отвечает» одна из девушек неуверенно предлагает, «а почему бы вам не спросить в отделе НСИ?». Говорить про то, что в схеме отделов и департаментов компании, которая приводится в отчете бизнес-аналитика, данный отдел отсутствовал – думаю, нет надобности.
На следующий день, с утра наведываюсь на задворки компании, и на второй же фразе начальник отдела спрашивает «а кто тебе дал эти товары? Мы их уже 3 года как не производим»? Занавес.
В итоге, проект первоначально запустили вообще без функционала «рекомендованных товаров», поскольку внутри компании решили все же разобраться, а как вообще они этот список формируют, и кто за что отвечает. В компании, которая гордилась полным описанием и моделированием всех бизнес-процессов.
При наличии, хотя бы, диаграммы зависимости данных, мы не потеряли бы два дня на элементарную задачу поиска источника информации. В идеале, подобной ситуации вообще не должно было случиться.
В итоге, взглянув на Сафед-диаграммы, менеджер, или другой специалист сразу видит всю необходимую ему информацию по процессу. Более того, часто будут заметны недостатки текущего процесса, его описания или же того, что предлагает бизнес-аналитик. С другой стороны, при изменении технических средств, которые мы или заказчик применяет в рамках процесса (внутренняя система электронного документооборота, физические носители данных и т.д.) сама диаграмма процесса не меняется. И это, с моей точки зрения, достаточно большой плюс, поскольку мы описываем логику процесса, а не его реализацию. Более того, в дальнейшем, при сравнении рекомендаций, всегда можно оценить, не менялась ли логика процесса, все ли связи, взаимодействия, оповещения и проверки были реализованы.
В принципе, нечто похожее можно изобразить и в рамках BPMN, EPC и UML. Однако рекомендации для этих нотаций больше ориентированы на описание конкретных реализаций процессов, а не на их логику. Я надеюсь, что все понимают, что идея в том и состоит, чтобы применять подобные Сафед-диаграммы как дополнение, как отправную точку для анализа процессов «As Is» и «To Be», а не как замену этих диаграмм.
Резюмируя все вышесказанное, основные проблемы у нас не в средствах (типах диаграмм, классификации требований и т.д. и т.п.), а в неполном понимании тех задач, которые стоят перед бизнес-анализом. В результате, вместо анализа бизнес-процессов (как мы выяснили ранее — шагов, необходимых для минимизации рисков не достижения бизнес-цели, и/или уменьшения издержек для ее достижения) коллеги занимаются анализом и документированием либо технологических процессов, либо должностных обязанностей сотрудников. В редких случаях, дополняя все это описанием документооборота.
У меня все. Надеюсь, кто-то найдет для себя что-нибудь полезное.
Всем удачи и успехов.
1. Песик и «бардак на почте» — отсюда и отсюда, соответственно.
2. Диаграмки — личное творчество.
Описание бизнес-процессов «Как есть» (AS IS) и «Как должно быть» (TO BE)
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — 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 стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
Источник: Блог компании Системный интегратор Тринион