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