Основная цель использования данной нотации – моделирование сложных и крупных систем, в которых задействованы люди, машины, ресурсы, информационные системы и потоки данных. Модели помогают выявить требования и функции будущей системы. Основной принцип моделирования в нотации IDEF0 указывает, что между функциями, которые входят в различные подсистемы, должно быть как можно меньше связей. На одном уровне должно быть не больше 5 и не меньше 3 функций.
Главным элементом этой нотации является блок функции, который представляет собой прямоугольник с названием функции внутри.
Для связей между функциями используются стрелки, указывающие на направление потока информации или материалов. Также в IDEF0 присутствуют блоки управления, которые отображают условия или решения, влияющие на выполнение определенной функции.
IDEF0 может быть использована не только для моделирования бизнес-процессов, но и для анализа и проектирования систем. Эта нотация является универсальным инструментом для описания функциональных взаимодействий и структуры любой системы. Это приближает её к языку моделирования ИТ архитектур ArchiMate. Это будет рассмотрено позже.
Описание бизнес-процессов на платформе 1С
Описание и моделирование бизнес-процессов возможно и на платформе «1С: Предприятие». На практике эта возможность есть в большинстве типовых конфигураций.
Бизнес-процессы в «1С: Предприятие» – это прикладные объекты конфигурации. Они описывают бизнес-логику в карте маршрута и управляют жизненным циклом созданных бизнес-процессов от старта до завершения.
Бизнес-процессы в системе 1С: Предприятие
Бизнес-процесс связан с задачей, которая задает систему адресации и позволяет проектировать карты маршрута в соответствии со структурой, поддерживаемой в прикладном решении.
Благодаря автоматизации бизнес-процессов в коде «1С: Предприятие» система сама начинает следить за регламентом выполнения работ, тем самым исключается “человеческий фактор” и сокращается число ошибок. По мере продвижения бизнес-процесса по маршруту сотрудникам автоматически передается информация о результатах.
Нотация описания бизнес-процессов в «1С: Предприятие» разрабатывалась с учетом ГОСТ 19.003–80 «Схемы алгоритмов и программ. Обозначения условные графические» и использует интуитивно понятные элементы и обозначения. Это значит, что даже неподготовленный пользователь может прочитать и понять схемы.
Графическое отображение четко соотносится с текстовым описанием, и обратно. Код пишется на русском языке, хотя есть возможность использовать английский синтаксис, если разрабатывается ПО для зарубежных пользователей.
Основные элементы описания бизнес-процессов в «1С: Предприятие» включают в себя:
Процедуры и функции: это основные строительные блоки бизнес-процессов. Они отображаются в виде прямоугольников с указанием соответствующего имени.
Решения: эти элементы представлены ромбами и обозначают точки принятия решений в процессе. Здесь можно указать условия, по которым происходит разветвление или объединение потоков данных.
Ввод/вывод данных: эти элементы представлены параллелограммами и обозначают операции по получению или передаче информации из или в процесс.
Старт/финиш: эти элементы представлены специальными фигурами – пятиугольниками и обозначают начало и конец бизнес-процесса.
Описание бизнес-процессов на платформе «1С: Предприятие» может быть выполнено как в текстовом виде, так и с использованием графической нотации.
По факту «1С: Предприятие» является low-code системой. То есть можно не знать код, но создать конфигурацию для автоматизации тех или иных бизнес-процессов при помощи различных конструкторов. Но всё-таки вряд ли она будет жизнеспособной, если не вносить какие-то правки в код. Поэтому бизнес-аналитики, которые работают с «1С: Предприятие», всегда немного и системные аналитики: основы встроенного языка надо знать, чтобы понимать принципы работы системы.
Случай из практики
В нашей онлайн-академии CORS Academy довольно много курсов. Но когда-то я делал практически всё сам: искал авторов, записывал уроки, делал тесты и задания, и многое другое.
Но вот пришла пора масштабироваться, и я стал не справляться. У нас появились заместители, методисты, преподаватели, менеджеры. Все начали выполнять свои задачи. Однако я продолжал этим всем управлять сам. И, конечно, начал не успевать.
Поспрашивал у коллег, как они планируют процессы создания и продвижения курсов. Тишина. Или не хотят говорить, или так же, как я – «как получится».
Передо мной встала задача описать процесс создания и продвижения курсов.
Для этого есть масса инструментов.
Но все они очень разные.
«Ноу-код» не подходили, потому что всё-таки даже прорисовать процессы хотелось с большей детализацией, чем позволяли стандартные инструменты.
В итоге выбор пал на 1С: Битрикс. Потому что там можно не просто прорисовать процесс, но и сделать его запускаемым: задачи сотрудникам будут ставиться последовательно автоматом при завершении других задач.
Всё-таки пришлось немного поучиться: и там есть свой «лоу-код» язык, без него никак. Навыки программирования помогли. Даже не знаю, насколько легко было бы научиться без них. Но в итоге получились довольно удобные запускаемые процессы, автоматом раздающие задачи.
Инструмент оказался очень полезным.
Но более сложные процессы лучше запускать в 1С: Предприятие.
Задание из курса аналитика 1С от CORS Academy
1. Выберите любой понятный вам бизнес-процесс, который можно автоматизировать при помощи программных продуктов.
2. Опишите этот бизнес-процесс при помощи метода текстовой записи.
3. Опишите для этого процесса входы, выходы, управление и ресурсы.
4. Опишите, какие у этого процесса показатели экономичности, результативности и эффективности.
Нотация BPMN 2.0. Примеры
Суть нотации BPMN
BPMN, или Business Process Model and Notation, является стандартом для описания бизнес-процессов с помощью графических символов. Эта нотация позволяет представлять процессы в графическом виде, что значительно облегчает их анализ, выявление узких мест и оптимизацию. BPMN 2.0 – самая распространенная нотация для описания бизнес-процессов.
Обобщенный пример модели бизнес-процесса в BPMN 2.0
Нотация BPMN используется в бизнес-анализе для создания диаграмм процессов и моделирования бизнес-логики.
BPMN была создана, чтобы облегчить понимание процессов и коммуникацию между различными участниками проекта. Она позволяет выразить каждый этап процесса в виде блока с определенным набором свойств и связей между ними.
Использование нотации BPMN позволяет легко визуализировать и анализировать бизнес-процессы, выявлять узкие места и оптимизировать работу компании. Она также является стандартом, что облегчает совместную работу и обмен документацией между различными проектами и организациями.
Элементы нотации BPMN: События
События – элементы, которые обозначают, что нужно действовать только тогда, когда что-то произошло. Любой бизнес-процесс должен иметь хотя бы одно стартовое событие (начало) и минимум одно завершающее событие (конец).
События в нотации BPMN
Если в бизнес-процессе необходима пауза до выполнения определенного условия, удобно использовать события.
Элементы нотации BPMN: Действия
Действие – важнейший элемент нотации BPMN. Оно указывает, что конкретно надо сделать, поэтому необходимо описывать его в повелительном наклонении.
Действия в нотации BPMN
У действий обязательно должен быть хотя бы один входящий поток и хотя бы один исходящий. Несколько входящих потоков отрабатывается по логике «ИЛИ», а несколько исходящих – по логике «И», то есть все одновременно.
Не стоит путать действия с событиями: событие – это то, что произошло, а действие – то, что необходимо сделать в рамках данного бизнес-процесса.
Элементы нотации BPMN: Логические операторы (шлюзы)
Простой бизнес-процесс может состоять только из стартового события, цепочки действий и конечного события. Однако в реальном бизнесе таких процессов очень мало. Обычно в бизнес-процессах есть различные сценарии развития в зависимости от определенных условий.
Логические операторы в нотации BPMN
Логические операторы (или шлюзы) задают условия. Они используются как для разветвления одного потока управления на несколько, так и для объединения нескольких потоков в один.
Внимательно изучите различия между шлюзами исключающего ИЛИ и шлюзами И, иначе бизнес-процессы будут описаны неверно.
Элементы нотации BPMN: Роли
Роли определяют, кто (или какая команда) будет выполнять определенные последовательности действий.
Роли в нотации BPMN
Особенностью нотации BPMN является описание ролей в рамках дорожек, которые охватывают часть бизнес-процесса. Хотя в последнее время часто для обозначения ролей не применяют дорожки. Вместо них в действиях делают специальные пометки для указания роли, примерно как в нотации eEPC.
В отличие от дорожек, пулы объединяют целые бизнес-процессы, которые обязательно имеют стартовое и завершающее событие.
Другие элементы нотации BPMN
Есть и иные элементы в нотации BPMN 2.0.
Элемент «данные» говорит о том, какие данные нужно сохранить, а какие – считать. Например, когда нужно задокументировать результат действий в бумажном документе или в автоматизированной системе.
Транзакция – это набор логически связанных действий, который схож с подпроцессом, но требует завершения или отклонения действия. В транзакции может быть задано несколько вариантов выхода.
Элементы документации используются для внесения комментариев в описание бизнес-процессов, что помогает пояснить детали и улучшить понимание.
Документация, транзакции и данные в нотации BPMN
Почему так популярна нотация BPMN
Нотация BPMN является мощным инструментом для моделирования бизнес-процессов и управления ими. Однако, как и любой инструмент, она имеет свои преимущества и ограничения.
Главные преимущества нотации BPMN заключаются в её стандартизации и понятности. Стандартный набор символов и обозначений позволяет легко читать и создавать диаграммы процессов, а также быстро адаптироваться к новым проектам. Нотация описывает процессы языком, доступным всем участникам проекта: команде разработки и представителям заказчика.
Информация в графическом виде всегда доступнее для восприятия, чем сложный технический текст. Заказчику из схем понятно, как будет работать система, и можно внести коррективы еще на этапе обсуждения проекта. BPMN-диаграмма исключает возможность «двойного прочтения», улучшая коммуникацию как внутри компании, так и в процессе общения разработчика с заказчиком.
Особым удобством в BPMN является разделение ролей по дорожкам. Однако бывают ситуации, когда это мешает восприятию последовательности бизнес-процесса. В таких случаях удобнее проводить моделирование в нотации EPC.
Однако нотация BPMN не лишена и ограничений. В первую очередь, это сложность использования в случаях, когда необходима детализация процессов на микроуровне. Также стандартная нотация может быть неэффективной при работе с комплексными процессами или при изменении уже существующих моделей.
В целом же, использование нотации BPMN является полезным для бизнес-аналитиков при создании моделей бизнес-процессов. Наличие единого стандарта позволяет повысить эффективность коммуникации между участниками проекта и сократить время на разработку диаграмм.
Пример 1. Обработка заказа клиента
Возьмем пример описания бизнес-процесса обработки заказа клиента в нотации BPMN 2.0. Тут и далее приводим примеры работ учеников CORS Academy: сможете найти, что можно дополнительно оптимизировать в этих процессах?
Бизнес-процесс обработки заказа клиента, полученного с сайта
В модели есть четыре ответственных: менеджер по продажам, менеджер по закупкам, бухгалтер и кладовщик.
Рассмотрим действие: проверка наличия товара на складе.
Если товара нет, менеджер по закупкам проверяет возможность его закупки. Эти действия отражаются в бизнес-процессе.
Если товар закупить нельзя, процесс завершается, и менеджер сообщает покупателю о его отсутствии.
Если товар закупить можно, процесс продолжает менеджер по продажам. Он проверяет наличие клиента в базе. Если клиента нет, он создает нового клиента и заключает договор.
Если клиент есть в базе, менеджер выбирает его из списка и проверяет вид договора: предоплата или постоплата.
Если договор с предоплатой, менеджер проверяет поступление оплаты. Если оплата не поступила, он сообщает об этом бухгалтеру. Бухгалтер звонит клиенту, чтобы узнать, планируется ли оплата. Если оплата не планируется, бизнес-процесс завершается. Если всё в порядке, бухгалтер через определенное время (хорошо бы добавить событие) снова проверяет наличие оплаты.
Если оплата поступила, менеджер оформляет документацию, формирует счет-фактуру и создает команду кладовщику на отгрузку товара.
Можно ли этот бизнес-процесс оптимизировать? Да, конечно. Но об оптимизации поговорим далее. А пока следующий пример.
Пример 2. Оплата счета поставщика
Рассмотрим еще один пример бизнес-процесса, описанного в нотации BPMN 2.0.
Бизнес-процесс оплаты счета поставщика
В этом простом бизнес-процессе присутствует только одна роль – бухгалтер-операционист.
Стартовое событие запускает процесс, и бухгалтер сразу проверяет, согласована ли оплата. Если нет – процесс завершается.
Если оплата согласована, бухгалтер по определенным правилам устанавливает дату оплаты и сообщает её менеджеру.
При наступлении даты оплаты бухгалтер проверяет, есть ли достаточно денег для оплаты. Если нет – назначается новая дата.
Если денег достаточно, бухгалтер оформляет платежку, отправляет её в банк и оформляет списание с расчетного счета.
Можно ли этот бизнес-процесс оптимизировать? Конечно. Но об этом будем говорить дальше.
Пример 3. Набор персонала
И еще один пример: набор персонала.
Бизнес-процесс набора персонала
При возникновении потребности в персонале руководитель готовит требования к кандидату и отправляет запрос в службу персонала.
Служба персонала сперва ищет кандидата внутри компании. Если кандидата нет, проводится поиск вне компании и проверяются резюме до тех пор, пока кандидат не будет найден.
Когда кандидат найден, проводится беседа, а затем организовывается и проводится собеседование с руководителем.
Если кандидат подходит, он оформляется на работу. Если не подходит, возвращаемся к поиску.
Всем ли организациям подходит такой бизнес-процесс набора персонала? Конечно нет. Можно ли этот бизнес-процесс оптимизировать? Конечно да.
Но об этом поговорим далее.
Случай из практики
До запуска CORS Academy я успел проработать в крупных 1С: Франчайзи топ-менеджером. Приобрёл опыт распределения большого объёма задач на ограниченное количество специалистов с разной квалификацией.
В итоге я даже сделал специальный курс для партнёров 1С: Рарус «Повышение эффективности отделов внедрения», где подробно описал этот процесс. Курс и сейчас можно приобрести на площадках «Раруса».
Встречаемся мы как-то с другом в баре, выпить по кружечке пенного. А друг руководит сервисной IT-компанией. И он говорит:
– Слушай, у меня довольно большой объём заявок на Service Desk. Конечно же, есть автоматизация: всё как положено. Но всё равно проблемы присутствуют. И с качеством, и со скоростью исполнения. У тебя же есть опыт распределения заявок? Поделись.
Я всегда с удовольствием делюсь опытом:
– Да, были ситуации, когда на 50–70 специалистов надо было распределять заявки. При этом в пиковый период казалось, мы не справимся – их могло быть больше 100. А «удалёнки» тогда не было, к клиентам надо было выезжать. Но всё же справляться удавалось. И качеством клиенты были довольны.
– А как так удавалось? Какие факторы учитывали?
– Очень много факторов. Квалификация специалистов, их загрузка, наличие уникальных компетенций, опыт, пожелания заказчиков, срочность, объём работы и десятки других факторов. В общем, всё сложно, вон купи лучше мой курс да сам всему научишься.
Он настаивал:
– Да ты своими словами объясни, «на пальцах», я пойму! Нарисуй вот тут…
И даёт мне лист бумаги и ручку.
Ну что ж… Заказываю ещё кружечку пенного, раз такое дело, и начинаю рисовать.
Я человек эмоциональный, и схема получилась очень эмоциональной. Я говорил и что-то рисовал на бумаге: прямоугольники, стрелочки, спирали, зигзаги. В итоге друг многое понял, но на бумаге осталась совершенная «мазня», похожая на детские каракули.
Но друг этот листок бумаги забрал.
Каково же было моё удивление, когда через год, оказавшись в офисе у того друга, я увидел, что тот листок, размалёванный мной в баре, висит у него в кабинете в рамочке. Кто не знает, может подумать, что это какой-то ценный набросок из ранних работ Сальвадора Дали, который особо берегут. Но я-то вспомнил свою «мазню»:
– Господи, ты ЭТО вставил в рамку? Ты нормальный вообще? Там же ничего не понятно!
– Илья, кому-то может и не понятно, а мне понятно всё!
Мораль: иному и «мазня» – нотация.
Задание из курса аналитика 1С от CORS Academy
В этом задании вы на практике прочувствуете разницу между текстовым описанием бизнес-процесса и его графическим представлением.
1. Подумайте, как может выглядеть бизнес-процесс набора персонала в вашей организации. Если вы не работаете, то придумайте гипотетический процесс.
2. Опишите этот бизнес-процесс, используя нотацию BPMN 2.0.
Примечание: для моделирования бизнес-процесса в нотации BPMN вы можете воспользоваться любым доступным редактором или сервисом. Специализированные инструменты для этого мы изучим чуть позже.
Оптимизация бизнес-процессов
Цели оптимизации бизнес-процессов
Мы разобрались, как описывать и моделировать бизнес-процессы. Теперь нужно приступить к главному: научиться оптимизировать бизнес-процессы, делая их более экономичными, эффективными и результативными. Кроме оптимизации, существует понятие реинжиниринга бизнес-процессов. Постараемся разобраться с этими терминами.
Заказчики могут ожидать различные результаты от оптимизации бизнес-процессов. Вот основные из них:
• Повышение скорости работы с данными
• Сокращение ручных операций
• Обеспечение прозрачности компании для руководства
• Упорядочение и закрепление правил в системе
• Сокращение издержек на выполнение работ
• Повышение качества принятия решений
• Снижение ненужных затрат
• Увеличение рентабельности
Эти цели объединяют в себе как бизнес-цели, так и цели оптимизации и автоматизации бизнес-процессов.
Отличия оптимизации от реинжиниринга бизнес-процессов
Реинжиниринг бизнес-процессов – это поэтапные изменения в компании, направленные на совершенствование деятельности, измеряемые с точки зрения бизнес-процессов и их показателей.
Реинжиниринг бизнес-процессов
Цель реинжиниринга бизнес-процессов – улучшение показателей компании.
Реинжиниринг применяют в ситуациях, когда снижается рентабельность бизнеса. Причиной снижения не обязательно является плохая работа сотрудников; потеря прибыли может быть связана с неактуальностью продукта, возросшим уровнем конкуренции или износом оборудования.
Причины проведения реинжиниринга могут быть следующими:
• Компания проигрывает конкурентам
• Экономический кризис в целом и спад какой-то части рынка в частности
• Компания хочет выйти на новый уровень прибыли
• Реинжиниринг в рамках импортозамещения, когда компания стремится занять нишу, освободившуюся после ухода иностранных конкурентов
Обычно реинжиниринг воспринимают как полное обновление бизнес-процессов компании. Однако существует подход, согласно которому реинжиниринг может быть частичным, то есть оптимизацией, когда предприниматель меняет отдельные бизнес-процессы или направления деятельности компании.
Отличия реинжиниринга от оптимизации:
• Оптимизация предполагает постепенное, поэтапное улучшение показателей, тогда как реинжиниринг носит радикальный характер.
• При оптимизации совершенствование осуществляется на основании уже действующих процессов. В реинжиниринге бизнес-процессы внедряются с «чистого листа».
• Оптимизация реализуется на протяжении короткого периода, тогда как для реинжиниринга потребуется длительное время.
• При реинжиниринге новые процессы внедряются по направлению «сверху вниз», тогда как при оптимизации – наоборот.
• Оптимизация характеризуется узким охватом, тогда как реинжиниринг – широким.
• Реинжиниринг отличается повышенными рисками, тогда как оптимизация характеризуется умеренным риском.
Проблемы, требующие оптимизации бизнес-процессов
Вот какие проблемы, требующие оптимизации бизнес-процессов, мы рассмотрим:
• Нехватка элементов
• Лишние элементы
• Зацикливания
• Неверная последовательность
• Лишние повторы действий
• Непредусмотренные ситуации
• Перепутанные роли
• Неуниверсальность
• Бесцельные действия
Все эти проблемы ведут к остановке бизнес-процесса, его замедлению или принятию неверных решений, что ухудшает показатели деятельности предприятий. Задача бизнес-аналитика – выстроить процессы, близкие к идеальным. Поэтому подумаем, что можно изменить.
В качестве примера возьмем уже знакомый бизнес-процесс набора персонала. Заодно вы увидите, насколько разные могут быть, казалось бы, одинаковые бизнес-процессы в разных организациях. При этом в каждом примере можно оптимизировать бизнес-процесс не только в рамках описанной проблемы, но и найти другие пути оптимизации. Подумайте, какие!
Как обычно, все примеры бизнес-процессов составлены учениками CORS Academy. Пользовались ученики разными инструментами, поэтому само начертание несколько отличается.
Пример 1. Нужны события – оповещения
Оптимизация: добавляем события – оповещения.
Этот бизнес-процесс простой и понятный, но при переходе потока управления между дорожками обычно необходимы события – оповещения.
Часто бывает, что отдел персонала отклоняет заявку на поиск кандидата, но не оповещает об этом руководителя, который ищет кандидата. Также кандидату следует из вежливости сообщать, если он не принят.
В данной ситуации руководителя необходимо оповестить (например, по электронной почте), что необходимо провести собеседование. Руководитель, в свою очередь, должен сообщить в кадровую службу, если собеседование успешно пройдено.
Пример 2. Зацикливание
Оптимизация: предусматриваем условия для выхода из цикла