Аннотация
Почему так популярно мнение, что обязательно нужно создавать нотации AS IS? Истоки этого спорного утверждения. Почему нотации Как есть нужны далеко не всегда. В каких случаях их действительно важно создавать и применять, а когда проще обойтись без них.
Оглавление
Содержание
Наглядный пример перехода диаграммы AS IS в TO BE
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — “как есть”), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).
Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.
Описывать нечего
Если в компании не проводилась ранее оптимизация бизнес-процессов, а это обычная ситуация, нет каких-то четких инструкций, то каждый из сотрудников будет работать по-своему.
Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.
Например, процесс согласования счета даже в одной организации может выполняться очень по-разному. Кто-то сначала пойдет к начальнику отдела, а кто-то направится сразу в бухгалтерию подписывать счет.
Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами: – Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом. – Другой сначала позвонит, все уточнит. – Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.
Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают “кто как привык”. В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.
Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.
Описывать незачем
Еще один важный аспект, с которым я столкнулся на практике. О том, что в компании что-то делают неправильно, все и так давно догадываются. Иначе бы вас, как специалиста, не пригласили. И от вас не ждут описания существующих проблем, они часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант придет, осмотрится, опросит людей, после чего выдаст рекомендации, как надо делать, чтобы решить существующие проблемы. Т.е. людям не нужны нотации «Как есть». Им сразу хочется увидеть «Как должно быть».
Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой точки зрения. Большой объем работы повышает ее стоимость. Но нужно ли это заказчику? Он и сам знает, что компания как-то работает, потому что бизнес приносит прибыль и т. д. Вас он нанимает не для того, чтобы за их деньги вы им поясняли, какую схему работы они сами организовали. Им хочется увидеть от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.
Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.
Есть вопросы по моделям AS IS TO BE? Напишите мне или позвоните по телефону +7(495)320-50-40 и я отвечу на ваши вопросы.
Написать
Пример использования нотации AS IS и TO BE
Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Далее они должны сдавать полученную партию и документы охране.
- Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
- Охрана выдает разрешение.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор
многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в
Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — 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-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
Источник: Блог компании Системный интегратор Тринион
Оптимизация бизнес-процессов предприятия
Автор: Кручинецкий Сергей Михайлович, руководитель компании «Питер-Консалт», ksm@piter-consult.ru
В этой статье речь пойдёт об оптимизации бизнес-процессов предприятия, их описании и моделировании.
Несколько лет тому назад автор этой
статьи работал в крупной торговой компании, владелец которой придавал огромное
значение стратегическому планированию, но не придавал значения оптимизации нижнего уровня управления — бизнес-процессов предприятия.
Маркетинговая стратегия предприятия была расписана в лучших традициях. И мероприятия соответствующие были запланированы, и ресурсы выделены.
Но как только речь заходила о налаживании скучных, регулярных процедур
управления, оптимизации бизнес-процессов
предприятия, собственник, а за ним и ряд ведущих менеджеров теряли всякий интерес,
предпочитая заниматься более «высокими материями». На мой взгляд, банкротство
компании, случившееся лет через 5 после нашего расставания, было закономерным
явлением.
Начнём разговор об оптимизации с
определения бизнес-процессов, так как существуют разные трактовки этого термина. Мы будем
понимать под бизнес-процессами «систему
последовательных, целенаправленных и регламентированных
видов деятельности, в которой посредством управляющего воздействия и с помощью
ресурсов входы процесса преобразуются в выходы — результаты процесса». С
учётом этого определения устное предание
о правилах входной приёмки на складе бизнес-процессом не является («не
регламентирован»), а наличие инструкции
по работе с ксероксом ещё не доказывает высокий уровень оптимизации бизнес-процессов («нет системы»).
До определённого уровня развития компания вполне может обойтись без
«регламентированной системы деятельности». Трудно в общем случае ответить на
вопрос «когда пора оптимизировать бизнес-процессы предприятия?», однако, нет сомнения, что
этот момент приближают
- рост количества персонала,
- рост количества уровней управления,
- рост количества подразделений,
- территориальная разобщённость
подразделений, - отсутствие или неразвитость единой
информационной системы.
Итак, если в определённый момент развития вы обнаружили, что
- решения
в компании принимаются не позволительно медленно, - решения
реализуются медленно и не качественно, - периодически выясняется, что те или иные аспекты
деятельности предприятия остались без контроля, - среди сотрудников растёт психологическое
напряжение, связанное с неурегулированностью прав,
обязанностей, ответственности, - выполнение элементарных рабочих
операций требует непозволительно много времени, сил, телефонных звонков,
согласований, служебных записок,
имеет смысл заняться оптимизацией бизнес-процессов предприятия.
Отметим, что в ряде случаев работу по изменению бизнес-процессов целесообразно провести, не дожидаясь
указанных симптомов, например, в случае существенного изменения структуры управления
или при внедрении новой информационной системы.
Вопросам моделирования, описания и оптимизации
бизнес-процессов предприятия посвящено много полезных материалов. В этой статье, не
претендуя на методологическую новизну, я хочу высказаться по некоторым аспектам
практической реализации этой работы.
И начнём мы с
1. Выбора
инструмента графического описания бизнес-процессов
Почему-то этому вопросу придают
огромное, если не решающее значение. Выскажу крамольную мысль: программное
обеспечение (ПО) описания и оптимизации бизнес-процессов предприятия имеет значение только в том случае,
если разработка проводится с целью дальнейшего внедрения бизнес-процессов в информационную систему. Но современные
ИС имеют собственные средства описания бизнес-процессов, поэтому само по себе обсуждение ПО оптимизации бизнес-процессов предприятия потеряло смысл.
Вместе с тем, при обсуждении этого
вопроса иногда забывают, что описания бизнес-процессов нужны не для разработчиков, а для
сотрудников предприятия, и важнейшим критерием выбора инструмента описания бизнес-процессов является его
доступность для персонала предприятия как на этапах согласования и оптимизации бизнес-процессов, так и на
этапах исполнения и модернизации.
Автор имеет успешный опыт внедрения
бизнес-процессов, прорисованных в графическом редакторе MS Word и
печальный опыт наблюдения полной неразберихи на предприятии с бизнес-процессами, описанными в самой современной программе. Так что при выборе инструмента решаете сами —
«вам ехать или шашечки?».
2. Модели
«AS IS» и «TO BE» оптимизации бизнес-процессов
Традиционная схема оптимизации бизнес-процессов предприятия предполагает описание на первом этапе действующих процедур (модель бизнес-процессов «AS IS») с
последующей оптимизацией до модели «TO BE» («как должно быть»). Иногда заказчикам работы по
оптимизации бизнес-процессов не понятно, зачем нужен первый этап. Они ожидают,
что исполнители принесут на предприятие готовые «типовые» бизнес-процессы, а
разработку модели «AS
IS» воспринимают, как попытку «накрутить»
трудоёмкость.
Хочется предостеречь от такого
подхода. Методика внедрения системы бизнес-процессов, не опирающейся на
действующие процедуры предприятия, называется не оптимизацией бизнес-процессов, а реинжинирингом. Разница примерно такая же, как между терапией и
хирургией, а к скальпелю обычно обращаются тогда, когда другого выхода нет.
Подумайте об этом в момент принятия решения.
Описание «AS IS» позволяет выяснить существующие противоречия и
провести первичную оптимизацию бизнес-процессов.
Для этого модель «AS
IS» должна быть обсуждена со всеми участниками бизнес-процессов и
согласована с ними «под роспись».
3. Оптимизация бизнес-процессов предприятия
«Оптимизировать» нечто можно только
по определённым критериям.
Оптимизировать бизнес-процесс можно по критериям стоимости, продолжительности,
количества транзакций и т.д. Понятно, что эти критерии являются «внешними» по
отношению к бизнес-процессу, появляются из более
общего контура управления предприятием. Давайте подумаем, из какого?
Предположим, мы оптимизируем
бизнес-процесс обслуживания клиента в магазине. Нам придётся выбрать критерий
оптимизации — качество или стоимость. Если наш магазин — элитный бутик, то мы
остановимся на первом критерии, если дискаунтер, то на втором. Таким образом,
мы уже выбрали критерий оптимизации
бизнес-процессов предприятия, определяя стратегию
и позиционирование нашего магазина.
Именно так, с помощью показателей оптимизации, процедурный уровень системы управления (бизнес-процессы) подчиняется более высокому уровню — стратегии.
4. Внедрение оптимизированных бизнес-процессов
Вероятно, внедрение — это самый
сложный этап работы с бизнес-процессами. Внедрение проходит гораздо успешнее,
если поддержано информационной системой
предприятия. Однако, такая возможность существует не всегда и не в полном объёме.
На этот случай хочется поделиться
способом внедрения бизнес-процессов, названной нами «методикой контрольных карт», которая заключается в следующем. По
всем бизнес-процессам составляются списки контрольных точек (контрольные карты), в которых мы
будем контролировать соблюдение бизнес-процессов. Удобными контрольными точками являются
моменты передачи документов, информации между сотрудниками. В этом случае
«контролёром» может быть сотрудник, которому информация должна быть передана. Пример контрольной карты представлен на рис. 1
Рис. 1 Пример контрольной карты
бизнес-процессов
|
Контрольная карта исполнения бизнес-процесса отчёта по авансам |
|||||
| N | Возможное нарушение бизнес-процесса | Контролёр | Исполнитель | Дата | Комментарий |
| 1 |
Отчёт не был передан вовремя или в полном объёме |
Кассир |
Иванов ИИ |
||
|
Список 1. Отчёт не был предоставлен в |
16.02.06 |
Отчёт по авансу за командировку 13-14.02.06 |
|||
|
2. Отсутствовали необходимые документы |
17.02.06 | Отсутствовал ж/д билет | |||
| 2 |
Заказанные деньги не были выплачены вовремя |
Иванов ИИ |
Кассир |
||
|
Список отклонений ………………………………………………………….. |
……… | …………………….. |
Форматы контрольных карт передаются
участникам бизнес-процесса. «Контролёры» обязаны фиксировать в картах факты
-
Не
предоставления информации, -
Предоставления
информации с опозданием, -
Предоставления
неполной или искажённой информации и т.д.
Карты собирает руководитель внедрения
бизнес-процессов, анализирует их, обсуждает с участниками процедуры. Возможными последствиями могут
являться:
-
разъяснительная
беседа с участниками бизнес-процесса, -
изменение бизнес-процесса,
если выяснится, что он был построен неверно, -
передача
результатов анализа руководителю нарушителя бизнес-процесса для принятия решения о
наказании.
5.
Модернизация бизнес-процессов
Жизнь не стоит на месте, поэтому рано или поздно
разработанные на предприятии бизнес-процессы опять потребуют оптимизации.
Чтобы бизнес-процессы, с одной стороны, соответствовали реальности, а с другой стороны, не
мешали нормальному развитию компании, их нужно своевременно модернизировать,
согласовывая новые редакции с участниками и доводя изменения до всех
заинтересованных лиц.
Тогда система бизнес-процессов предприятия станет реальным инструментом повышения эффективности
бизнеса на процедурном уровне.
На нашем сайте можно ознакомиться с примерами разработанных нами описаний бизнес-процессов, отзывами наших заказчиков, а также с процедурой заказа работы по совершенствованию бизнес-процессов. Узнайте как оптимизировать расходы на эту работу посмотрев видеопост 
«Стоимость оптимизации бизнес-процессов» на нашем канале Youtube.
Если вы хотите узнать о возможностях такой экономии для вашего предприятия, заполните этот вопросник для подготовки коммерческого предложения на оптимизацию бизнес-процессов, и мы пришлём вам КП с ценой и планом выполнения этой работы.
Всем привет! Поговорим об одном из hard skills хорошего аналитика: умение моделировать бизнес-процессы. В статье расскажу о трех вещах: зачем нужны процессы, как их описывать, свой опыт работы. Погнали!
Disclaimer: Описанный текст является моим личным мнением, основанным на собственном опыте и навыках (Я — старший бизнес-аналитик в команде разработки крупной российской компании)
Часть 1. Откуда берется бизнес-процесс? Модель AS IS/TO BE.
Утро. Ничего не предвещало беды, бизнес-аналитик занимался техдолгом, и вдруг он: новый проект. Заказчик прибегает с большими глазами и требует: нужен раздел в системе, который будет делать «А», потому что без этого невозможно жить. Проект начинают обсуждать, выделяют основные боли, и задают заказчику вопрос: а что ты хочешь в итоге?
Заказчик обычно отвечает: ну, у меня сотрудники работают вот так, а я хочу вот так «Б», сделайте мне в системе интерфейс с логикой, как я прошу.
То, что описал заказчик( «А» и «Б») — это модель AS IS/TO BE. Он пришел с описанием, как есть сейчас и как он хочет, чтобы было.
На самом деле все, что вам сказал заказчик — это AS IS — модель «как есть», модель текущего состояния.
Свойства AS IS модели:
Обычно уже существующий процесс (иногда костыльный, иногда неполный), который нужно улучшить: через ПО, людей, аналитику и другое. Через модель AS IS/TO BE можно выявить узкие места, которые затем улучшатся.
На этом этапе сбора информации аналитику следует описывать строго то, как работает сейчас, а не идеализированное представление заказчика. И до того момента, как вы не выясните всю информацию полностью, не бегите разрабатывать новые кнопки в вашей системе.
Лайфхак: чтобы с головой не окунаться в моделирование, сначала запишите текстом весь существующий процесс, потом согласуйте видение с заказчиком и можно идти дальше.
ЧАВО: А что, если существующего процесса нет? И он новый?
Ответ: Все, с чем приходит заказчик: с процессом в голове или с процессом на бумажке — это все AS IS, даже если он клянется вам, что это TO BE (как должно работать) .
Процесс AS IS описали и начинаем брейнштормить дальше. То, что мы описали в рамках грумингов с командой, заказчиком и обретшее здравый смысл — это процесс «как должно быть».
Свойства TO BE модели:
Улучшенная модель AS IS. Отображает те функции, которые помогут разработать целевое решение для проекта.
На этапе TO BE модели можно решить, посредством чего будет выполнен проект: иногда разработка — слишком дорогое удовольствие для задачи, которая не окупится.
Модель TO BE тоже можно описать словами, предварительно согласовать с заказчиком до того, как приступать к моделированию.
Итог: описали модель «как есть«, описали модель »как должно быть» и рассказали заказчику. Ему понравилось: начинаем моделировать.
P. S. Текстом описывать необязательно, обычно я это делаю в условиях сжатых сроков, так получается быстрее. Если моделировать, а потом вносить каждые правки и переделывать, может уйти один-два спринта, в условиях проекта на месяц-два — это непозволительная роскошь.
При этом я настоятельно рекомендую фиксировать все процессы в вашем проекте/продукте, даже если кажется, что это ерунда, а вы пишете требования для разработки — на самом деле это конечно не так.
Польза процессов:
Они хотя бы есть на бумаге. Никто не вспоминает, как это вообще работает, от чего улучшали. Это помогает при разработке новых функциональностей, в том числе экономит время: вам не надо каждый раз на новых встречах вспоминать, с чего все начиналось.
Пример из жизни:
В начале моей работы в компании мы делали интеграционный проект с смежными командами и когда уже проект был сделан, через месяц-два к нам пришли сотрудники компании, которые сказали, что все фигня. Информация приходит неполная. Долго разбирались, что не так: оказалось в начале проекта не собрали бизнес-процесс и мы не знали о большом блоке, который вел один человек в Excel несколько лет. Он уволился, спросил: кому-то может данные передать, все забили, доступ к файлу пропал, а мы потеряли важную часть процесса. В итоге потом смежная команда получила огромный проект на доработку, а все потому, что мы изначально не узнали, как работает процесс. Да, процессы — вещь сложная, иногда противная, но «Сила в правде. У кого правда, тот и сильнее(AS IS процесс)»:) )
Часть 2. Средства моделирования процессов.
Визуализировать бизнес-процесс можно через три основных способа:
— текстовый (часть 1)
— табличный (вход-выход)
— графический (через нотации моделирования процессов)
Я использую все три в разных случаях.
Текстовое описание помогает описать процесс быстро (если это не рассказ объемом с «Война и Мир»), графическое — просто, понятно и удобно как для заказчика, так и для команды разработки. Табличное я использую для описания функциональных требований для команды разработки, в рамках этой статьи касаться его не буду.
Какую нотацию выбрать? Какие бывают?
Основных три: IDEF0, EPC, BPMN. В своей работе я использую нотацию BPMN 2.0.
Любая нотация — это просто язык моделирования со своими особенностями. Ему можно научиться, если понимать основную логику описания процессов.
Часть 3. Моделирование.
Один из вариантов описания процесса такой:
1. Кто участник процесса.
Определите участников вашего процесса: это может быть человек и система, несколько людей и несколько систем и прочее.
2. Как подробно описываем.
Определите, верхнеуровнево или низкоуровнево вы описываете процесс: верхнеуровневое описание обычно включает в себя подпроцессы нижнего уровня.
Например: процесс модуля планирования с заведением, согласованием и пересогласованием планов — верхнеуровневый процесс. Механика отправки Email-уведомлений участнику процесса согласования — процесс нижнего уровня.
3. Где начало и конец?
Определите, что является началом вашего процесса, что вы хотите получить в завершении.
4. Прямой сценарий.
Опишите прямую последовательность действий из пункта А в пункт Б и зафиксируйте их на процессе.
5. Другие сценарии.
Определите, какие сценарии еще есть в вашем процессе, которые ведут к завершению процесса (негативный кейс) , альтернативные сценарии.
6. Фиксируем все на бумаге.
Пара статей на эту тему:
Бонус для тех, кто дочитал до конца: пример объема верхнеуровнего TO BE процесса с моей работы. На сбор информации AS IS и моделирование TO BE (в формате встречи и текстовой записи) ушло 4 рабочих часа и 5 человек: два представителя заказчика и три представителя команды. На моделирование ушло 4 рабочих часа (делала я одна) .
Всем спасибо!