Как невозможно в промышленности без чертежа создать изделие, так невозможно без описания проектировать процесс. Описание — это «чертеж» процесса, создав который, вы получаете возможность изменять его в требуемую сторону, а значит, управлять им. Для составления описания бизнес-процесса, в первую очередь, необходимо определить его элементы. Таковыми являются:
• функции (операции, действия);
• события (в некоторых методиках используется термин «состояния»);
• ресурсы, среди которых, отдельно выделяют две группы: о исполнители — роли, сотрудники, должности, подразделения о информационные ресурсы — документы, файлы, архивы и другие носители информации;
• продукты и услуги
- 1.2.1. Функции (операции, действия)
- 1.2.2. События
- 1.2.3. Ресурсы
- 1.2.4. Исполнители
- 1.2.5. Информационные ресурсы
- 1.2.6. Продукты и услуги
- 1.2.7. Потоки
- 1.2.8. Уровни описания процессов (декомпозиция)
- Методы структурирования бизнес процессов
- Структуризация целей проекта
- Определение показателей для измерения степени достижения целей
- Описание бизнес-процессов организации
- Анализ бизнес-процессов
- Как описать бизнес процесс
- 1. Описать цель описания бизнес процесса
- 2. Описать цели бизнес процесса
- 3. Поговорить с руководством отделов, которые работают в бизнес процессе
- 4. Поговорить с сотрудниками
- 5. Выявить наиболее важные задачи в бизнес-процессе
- 6. Выявить начало и конец процесса
- 7. Составить список задач с условиями
- 8. Сделать первый вариант бизнес процесса
- 9. Обсудить детали с руководством и с ключевыми сотрудниками
- 10. Представить финальный вариант
- 11. Подготовить текстовое описание бизнес процесса
- Правила описания бизнес-процесса
- Описываем бизнес-процессы организации
- Группы бизнес-процессов
- Описание и анализ БП
- Как реализуется описание БП
- Технологии, которые используются для описания БП:
- Алгоритм действий при моделировании:
- 📽️ Видео
1.2.1. Функции (операции, действия)
Функция — сложное понятие, наиболее часто используемое при обозначении границ ответственности сотрудников. Так как функция — набор действий, это позволяет нам рассматривать процесс как частный случай функции.
С другой стороны, процесс может включать в себя действия, являющиеся функциями. В данной методике эти понятия рассматриваются совместно. И иногда используются как синонимы.
Например, процесс работы с клиентом — последовательность действий, а функция работа с клиентом, закрепленная за отделом продаж — это крут обязанностей. В данном случае эти понятия совпадают.
Функция (формальное определение) — это предметно-ориентированное задание или действие, выполняемое над объектом, в результате которого достигается одна или несколько целей, стоящих перед компанией
Возможны три варианта структурирования функций на предприятии
• по объекту — объектно-ориентированный;
• по процессу — процессно-ориентированный;
• по операциям — операционно-ориентированный
Объектно-ориентированный подход заключается в том, что выделяются все функции, которые воздействуют на один и тот же объект, например, «заказ» (см. Рис. 4).
При процессно-ориентированном подходе выделяются все функции, задействованные в процессе, например, «обработка заказа» (см. Рис. 5).
При операционно-ориентированной структуре функций внимание сосредотачивается на виде операций, например, «корректировка».
1.2.2. События
Понятие «событие» уже приводилось при описании внешних границ процесса. Оно означает приобретение определенного статуса объектом, связанным с бизнес-процессом. Кроме определения границ процесса, события используются и в самом процессе для обозначения ветвлений (вариантов).
Например, при выполнении функции «Проверка наличия товара на складе» может быть два результата: «Товар есть в наличии» либо «Товара нет в наличии». В данном случае это и будет событиями, показывающими направление течения процесса. Если «Товар есть в наличии», то далее может следовать отгрузка.
Если «Товара нет в наличии», то клиент) сообщается о невозможности выполнить заказ и просьба перенести его на другой период.
В комплексных информационных системах чаще используется понятие «состояние)). Состояние и событие всегда связаны с каким либо объектом. В случае события «Товар есть на складе» некий объект (товар) находится в состоянии наличия. В дальнейшем описание состояний объектов помогает составлять требования к информационной системе.
1.2.3. Ресурсы
Ресурсы — потребляемые в процессе предметы труда и используемые в процессе средства труда.
В качестве предметов труда в процессе могут выступать сырье, материалы, комплектующие и т.п., а в качестве средств труда — машины, инструменты, оборудование. Также к ресурсам относят труд, информацию, знания и т.д. В данной методике трудовые и информационные ресурсы (в связи с их особыми свойствами) будут рассматриваться отдельно.
1.2.4. Исполнители
Исполнители (участники процесса) — сотрудники, выполняющие в процессе определенные обязанности (действия), включая внешних (не входящих в штат компании, например, консультанты, аудиторы и т.д.). Существуют следующие типы участников процесса:
• организационные звенья — структурные подразделения — отделы, и т. д.;
• должности — различные должности из штатного расписания компании, например: Менеджер по продажам, Логистик, Товаровед, Начальник цеха №1;
• сотрудники — персоналии, работники компании (ФИО), например, Иванов Иван Иванович;
• роли — обособленные группы обязанностей, которые может исполнять сотрудник в процессе, обладая при этом и определенными правами. Роли могут в частном случае совпадать с должностью — как по функционалу, так и по названию. Например: Гл. бухгалтер, Системный администратор.
https://www.youtube.com/watch?v=wbHuUdGXuUc
Организационные звенья могут использоваться при наиболее общем описании бизнес-процессов всего предприятия или для описания функционала организации.
При описании бизнес-процессов рекомендуется использовать должности и роли в качестве исполнителей операций.
Использование ролей практически аналогично должностям. Различие заключается в том, что одна должность может исполнять несколько ролей. Например, в небольшой организации Финансовый директор может исполнять функции и финансиста и гл. бухгалтера.
Или программист может являться еще и системным администратором. В этих случаях указывается, что данная должность подразумевает в организации несколько ролей, и в процессах используются обозначения ролей.
Кроме этого, при внедрении информационных систем каждый работающий с системой получает определенную роль, характеризующуюся правами доступа:
• Администратор
• Пользователь
• Финансовый директор (в данном случае не должность, а роль в системе, определяющая права на доступ к информации и права использования отчетов и других инструментов).
Необходимость использования тех или иных участников, например, ролей, определяется целями описания бизнес-процесса, а через них — необходимым уровнем детализации.
Роли необходимы для описания действий сотрудников на уровне работы с информационной системой, а отделы на уровне анализа распределения функций по организации. При описании бизнес-процессов организации в основном используют должности.
Только в крайнем случае используются сотрудники (т.е. ФИО), так как это показывает зависимость выполнения бизнес-процесса от личности исполнителя.
Сотрудники принимают различное участие в процессе. Можно выделить следующие типы участия в процессе.
• Исполняет (executive) — непосредственно участвует в выполнении действия, причем, если есть несколько исполнителей, то подразумевается, что они взаимозаменяемы и каждый может выполнить действие самостоятельно.
• Утверждает результат — обычно руководящие должности.
• Вносит вклад в (contributes to) — непосредственно участвует в исполнении, но, в отличие от исполнения (executive), предполагается обязательное участие всех исполнителей.
При отсутствии одного из них функция не выполняется, так как исполнители не взаимозаменяемы.
Например, для переноса холодильника нужны два грузчика: оба выполняют одну и ту же функцию, но один не сможет выполнить эту функцию без другого.
• Отвечает за ИТ обеспечение — например, системный администратор.
• Консультирует такой тип связи присутствует при участии внешних консультантов.
• и др.
Каждый вид участия должен правильно отражаться в процессе соответствующим обозначением либо описываться в примечаниях к схемам.
1.2.5. Информационные ресурсы
Информационные ресурсы представляют совокупность всех данных, имеющихся на предприятии. Информация является ключевой составляющей для управления бизнес-процессами. При описании процесса, определяется информация, используемая процессом и выдаваемая в качестве результата. Существует также справочная информация.
Информацию можно классифицировать по следующим признакам: место возникновения, стадия обработки, способ отображения, стабильность, функция управления . Различные классификации информации необходимы при анализе информационных потоков.
Например, определение мест возникновения информации является основой организации безбумажного документооборота с вводом информации в местах ее возникновения.
А для определения мест возникновения нужно разделить информацию на внешнюю и внутреннюю, чтобы учитывать поступление внешней информации и предусмотреть ее введение в систему.
В процессах используются обычно обозначения различных документов и файлов.
При описании процессов для целей автоматизации необходимо учитывать носитель информации и детализировать документы до уровня полей.
Поля используются в качестве места для ввода данных в программе, которые могут изменяться. Например, «Заказ» — это текстовый документ, содержащий поле «Наименование клиента» длиной до 128 символов.
https://www.youtube.com/watch?v=5XeOwzoeaaM
При более укрупненном описании достаточно будет ограничиться документом «Заказ». В таком случае функция «Ввод заказа» будет выполняться без указания, какие именно данные вводятся в систему. При этом большинство средств описания бизнес-процессов позволяют в дальнейшем детализировать это описание при необходимости.
1.2.6. Продукты и услуги
Продукты и услуги являются результатом, создаваемым в ходе выполнения процесса и соответствующим требованиям клиентов процесса. Это не обязательно продукция компании. Для внутреннего процесса результатом может быть документ, предоставляемый начальству.
Например, результатом процесса планирования продаж является «План продаж» компании в натуральном и денежном выражении.
К этому плану руководство компании и служба производства, являющиеся клиентами процесса, предъявляют определенные требования в виде формата предоставления, сроков, и т.п.
1.2.7. Потоки
Представляя однородные элементы процесса в последовательности, получаем потоки.
• Функциональный поток — описывает последовательность выполняемых работ и может характеризоваться стоимостью и длительностью.
• Информационный поток — показывает перемещение таких объектов как бумажные документы, файлы, записи баз данных и т.д.
• Организационный поток — последовательность исполнителей процесса в порядке выполняемых работ.
• Поток ресурсов — раскрывает движение всех ресурсов в процессе. В литературе также встречается поток входов/выходов, показывающий ресурсы, используемые и потребляемые процессом, а также производимые продукты/услуги.
Потоки необходимы для анализа отдельных аспектов бизнес-процесса. Например, для анализа загрузки сотрудников лучше использовать организационный поток, чем процесс в целом.
1.2.8. Уровни описания процессов (декомпозиция)
Декомпозиция — прием, позволяющий представить сложную систему в виде нескольких более простых взаимосвязанных, вложенных систем.
Такая форма представления позволяет анализировать процесс, не перегружая представление элементами, излишними для решения текущей задачи. Глубина декомпозиции определяется целями моделирования и, таким образом, задает степень детализации описания процесса.
По аналогии с планированием можно проводить моделирование и описание бизнес- процессов «сверху-вниз» и «снизу — вверх».
В случае моделирования «сверх) — вниз» описываются все процессы системы начиная с верхнего уровня, т. е. сначала рассматривается все предприятие в виде комплекса взаимосвязанных функций, а затем раскрываются отдельные функции в виде взаимосвязанных бизнес-процессов.
При моделировании «снизу — вверх» выбирается один процесс (например, «Обработка заказа»), затем производится его описание и дальнейшая оптимизация под поставленные цели.
Часто в этом случае описания системы предприятия в целом не происходит, а описывается только часть системы, взаимодействующая с описываемым процессом.
В дальнейшем такая работа может быть продолжена путем включения других процессов в работу по бизнес-инжинирингу.
Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.
Описание системы бизнес-процессов предприятия «сверху — вниз» требует больших затрат ресурсов. При такой работе, как правило, ломаются устоявшиеся стереотипы, и часто результаты сложно внедрить без серьезного изменения существующей системы. Необходима детальная, предварительная проработка системы «миссии — стратегии — цели» компании.
При подходе «снизу- вверх» проще создать команду и добиться улучшений за небольшой срок, но эти улучшения будут носить локальный характер. Для такой работы достаточно проработки целей проекта по инжинирингу.
Решения в пользу этого подхода принимаются с учетом более низких затрат и возможности испытать эффективность новой технологии без большого риска для компании в целом.
В дальнейшем обученную команду сотрудников можно использовать для распространения опыта проекта на всю остальную компанию. Данная методика описывает именно такой подход к бизнес-инжинирингу.
Что же представляет собой многоуровневое моделирование бизнес-процессов? Функция (одно действие) процесса может представлять собой отдельный процесс и раскрываться уровнем ниже в виде отдельного процесса состоящего из нескольких операций .
https://www.youtube.com/watch?v=17IVgtYXxW8
Таким образом, повышая детализацию описания бизнес-процессов, можно сформировать структурную «вложенность» бизнес-процессов. Подобная структура является процессной моделью предприятия и должна содержать описание бизнес-процессов, определяя их взаимосвязи.
Уровень детализации описания отдельного бизнес-процесса диктуется необходимостью обеспечить качество понимания бизнес-процесса.
Если какой-либо шаг процесса при данном уровне детализации остается непонятным, детализацию описания повышают.
Если данного уровня детализации достаточно для однозначного понимания бизнес-процесса (определяющего удобство и эффективность работы с ним), то повышать детализацию не требуется (в целях экономии ресурсов).
Видео:7 базовых методов анализа бизнес-процессовСкачать
Методы структурирования бизнес процессов
В качестве целей описания бизнес-процессов обычно выбирается одна или несколько целей из перечня наиболее часто решаемых задач.
2
Структуризация целей проекта
Структуризация проекта описания, анализа и реорганизации бизнес-процессов состоит из следующих шагов, см. рисунок.
На первом этапе руководитель формулирует в произвольной форме цели проекта, сроки выполнения проекта и возможный объем выделяемых на этот проект ресурсов. Руководитель проекта как представитель рабочей группы проводит совещание с руководителем организации для предварительного формулирования целей. Результатом первого этапа является перечень целей, определенных руководителем организации.
На втором этапе руководитель проекта ставит задачу рабочей группе детализировать перечень целей. Основная задача рабочей группы на этом этапе — добиться предельно конкретных целей, достижение которых может быть выражено количественными показателями.
На третьем этапе разработки целей проекта проводят согласование детальной структуры целей с руководителем организации. Его задача на этом этапе состоит в установлении приоритетов по достижению детализированных целей.
Разработка ТЗ существенно облегчает задачу по выполнению проекта.Она зависит от применяемой методологии и программного обеспечения.
Утвержденное ТЗ является обязательным к исполнению рабочей группой.
Структуризация целей может быть проведена в формате сбалансированной системы показателей (пример ССП).
3
Определение показателей для измерения степени достижения целей
Для каждой сформулированной цели должен быть сформулирован один или несколько ключевых показателей эффективности (KPI), позволяющих установить плановое и мониторить фактические значения. Пример KPI приведен здесь.
4
Описание бизнес-процессов организации
Основные шаги:
- Определить внешних клиентов организации и входы/выходы для организации в целом. Одним из примеров представления результатов могут служить графические схемы в нотации IDEF0, уровень А0 (пример).
- Составить перечень основных бизнес-процессов организации, формирующих внешние выходы. Перечень основных процессов, как правило, является отражением цепочки добавленной ценности.
- Параллельно с п.2, составить полный перечень бизнес-процессов верхнего уровня (включая вспомогательные процессы и процессы управления и развития. Правило для классификации процессов приведено здесь). Модель бизнес-процессов может быть разработана в различных нотациях, например, также в IDEF0, как это предполагается в системе бизнес-моделирования Business Studio (пример бизнес-процессов верхнего уровня), либо в расширенной нотации, как это рекомендуется в системе Бизнес-Инженер (пример сети бизнес-процессов верхнего уровня). На данном этапе становится доступным формирование первых внутренних нормативных документов организации. Например, из системы бизнес-моделирования возможна выгрузка автоматически формируемого регламента бизнес-процесса верхнего уровня — пример.
- Провести ранжирование бизнес-процессов с целью выбора приоритетных для улучшения бизнес-процессов.
- Описать каждый из приоритетных бизнес-процессов на нижнем уровне.
- Построить организационную структуру организации и распределить ответственных по каждому из выделенных бизнес-процессов. В результате строится матрица распределения ответственности, позволяющая определить наличие провалов и дублирования ответственности.
- В зависимости от конечной цели описания проводится детальное описание выбранных процессов в WFD. В частности, при необходимости автоматизации процесса (в состоянии «как есть») может проводиться описание процесса в нотации BPMN. Реализации такого описания можно посмотреть здесь. При необходимости формирования пакета внутренней нормативной документации и/или подготовки организации к сертификации СМК выбор нотации определяется соглашением по моделированию. Часто при описании процессов на нижнем уровне применяется нотация EPC. Примеры образцов внутренней нормативной документации, выгружаемых из систем бизнес-моделирования, приведены здесь.
5
Анализ бизнес-процессов
Виды методик анализа бизнес-процессов:
- Качественный анализ процесса
- качественный анализ процесса на основе субъективных оценок:
Наименование оценки | оценки |
SWOT-анализ процесса | выявление сильных и слабых сторон процесса, возможностей для его улучшения и угроз ухудшения |
анализ проблем процесса | выявление проблемных областей на графической схеме процесса (по протяженности процесса, ветвям процессам, переходам из одной зоны ответственности в другую и т.п.) |
ранжирование процессов | распределение процессов по уровням важности, проблемности, барьерам для изменения |
- визуальный качественный анализ графических схем процесса:
- анализ входов/выходов;
- анализ функций;
- анализ ресурсов (персонала, оборудования, программного обеспечения);
- анализ состояния процесса по отношению к требованиям:
- анализ состояния процесса по отношению к типовым требованиям (стандартам СМК ISO, а также требованиям PDCA);
- анализ состояния процесса по отношению к нормативным актам;
- Количественный анализ процесса
- измерение и анализ показателей:
- анализ показателей эффективности процесса;
- анализ показателей процесса;
- анализ удовлетворенности клиентов процесса;
- сравнительный анализ процессов;
- имитационное моделирование процесса и функционально-стоимостной анализ;
- АВС-анализ процесса.
Видео:Моделирование бизнес-процессов | Naked BPMСкачать
Как описать бизнес процесс
Существует два диаметрально противоположных подхода к началу описания бизнес-процесса. Некоторые учебники рекомендуют сначала описать все текстом, пошагово, и только потом переходить к графике. Другие советуют сразу моделировать графическую нотацию, а потом описывать ее текстом по мере необходимости.
Я считаю, что начинать с текста – это путь в никуда. Потому что вы таким образом получаете на первом этапе много текстовой информации, в которой даже самому можно запутаться. Кстати, это происходит не так редко, как может показаться. Тем более, ваши заказчики будут долго и с трудом разбираться, что вы им хотите донести.
Другое дело – графическая нотация, где наглядно видно, какое действие выполняется на каждом этапе, где находится «условная вилка» и т.д. В этом случае любые ошибки и недочеты становятся очень заметны.
Я рекомендую такую последовательность действий:
- Цель описания бизнес процесса
- Цели бизнес процесса
- Поговорить с руководством в отделах которые работают в бизнес процессе
- Поговорить с сотрудниками
- Выявить наиболее важные задачи бизнес процессе
- сделать первый вариант бизнес процесса
- Выявить начало и конец процесса, начало должно быть только одно, финалов много.
- Составить список задач с условиями
- Обсудить детали с руководством и с ключевыми сотрудниками
- представить финальный вариант
- Подготовить текстовое описание бизнес процесса
Такой подход экономит время и вам, и заказчику. И что еще важнее, гарантирует взаимопонимание. Но давайте разберемся шаг за шагом, с чего начинать и как действовать.
1. Описать цель описания бизнес процесса
Цель описания бизнес процесса ни в коем случае не надо путать с целью самого бизнес-процесса. Это разные этапы работы.
https://www.youtube.com/watch?v=trllIrXFrEg
Цель описания бизнес-процесса – это задача, которая стоит перед вами. Например, это может быть автоматизация процесса продажи, автоматизация приема заявки, процесса управления снабжением и т.д.
Также целью описания может быть не автоматизация, а реинжиниринг или, говоря проще, оптимизация бизнес-процесса. В этом случае вам сначала понадобиться сделать описание «как есть», и только потом его оптимизировать.
Примеры подобных задач: «Оптимизация процесса бизнес-контроля» или «Реинжиниринг процесса планирования».
Т.е. первый этап – это четкое понимание, а еще лучше, сразу краткое текстовое описание того, зачем вы вообще выполняете эту работу.
2. Описать цели бизнес процесса
Теперь необходимо четко обозначить цели самого бизнес-процесса. Т.е. те финальные результаты, к которым необходимо прийти.
Напоминаю, что в отличие от технологического процесса у бизнес-процесса может быть несколько финалов. Но их число всегда ограничено, и все их необходимо перечислить.
Очень важно, чтобы бизнес-процесс начинался и завершался так, как было запланировано. По сути, таким образом, мы обозначаем точку «выхода», т.е. то, что мы обязательно должны получить в том или ином случае.
Например, процесс продажи или обслуживания клиента может иметь два очевидных финала:
- Сделка завершена успешно.
- Сделка проиграна (клиент отказался от сотрудничества).
Оба эти финала должны быть запланированы заранее. Причем, в случае проигранной сделки, обязательно нужно заранее определить, в каких случаях может возникнуть такой вариант выхода из бизнес-процесса, ведь заказчик может отказаться от сделки на разных этапах и по разным причинам. Здесь очень важно определить оптимальные варианты выхода из сделки.
Почему так важно четко определить цели бизнес процесса? Очень важно в любом процессе на выходе получить максимум информации о том, как он проходил, где и на каком этапе завершился, где и по каким причинам он сорвался, или, наоборот, что сделали, чтобы процесс прошел успешно.
3. Поговорить с руководством отделов, которые работают в бизнес процессе
Теперь, когда поставлены все необходимые цели, пришло время обсудить нюансы работы с руководителями отделов, которые будут учувствовать в бизнес-процессе.
Важно понимать, что где бы и с кем вы ни работали, вы всегда будете сталкиваться с определенной иерархией внутри организации. Скорей всего, первый этап переговоров у вас будет происходить на уровне руководства.
Но дальше вам необходим контакт с подразделениями, которые задействованы в бизнес-процессе. Нужно выявить тех сотрудников, которые будут учувствовать в нем непосредственно.
Для этого вам понадобится общение с руководителями этих подразделений.
Важно понимать что иногда вам не нужно будет говорить с каждым с кем запланировано, кто нибудь из руководства может вам рассказать и за себя и за других людей. Соблюдайте меру, не будьте роботом.
4. Поговорить с сотрудниками
Далее, уже с согласия и, возможно, при участии этих руководителей, имеет смысл пообщаться с лучшими сотрудниками. Я их называю обычно «звезды». Это те люди, которые в текущих условиях выполняют свою работу наиболее эффективно. Информация от них поможет вам понять, как составить бизнес-процесс наилучшим образом.
Список звезд вы должны получить от руководства отделов, это может быть один или несколько человек.
5. Выявить наиболее важные задачи в бизнес-процессе
На основе собранных интервью сотрудников и руководства подразделений нужно определить наиболее важные и значимые задачи.
Здесь важно понимать, что каждый сотрудник считает свою работу – самой важной. Почти все уверены, что именно качество их работы лежит в основе результатов коллег и других подразделений. С психологической точки зрения это вполне понятно, более того, разумный руководитель даже стимулирует такое отношение к своей работе у подчиненных.
Но вам важно понять, что действительно значимо с точки зрения бизнес-процесса, а что – нет. Иначе, если вы будете записывать каждое мелкое действие каждого сотрудника, вы сами «заблудитесь» в собственных заметках или переплетениях графической нотации, перегруженной лишними подробностями.
https://www.youtube.com/watch?v=49IZwmznNQg
Скорей всего, вам совсем не нужно знать, когда по правилам сотрудник перезагружает компьютер или какой из бланков он использует для оформления делового письма, а какой – для коммерческого предложения. В случае необходимости такие мелкие подробности можно будет уточнить потом, например, для программиста, который будет создавать форму делового письма.
Учитесь выявлять важное и отсекать ненужное. Что именно на самом деле важно, в каждой организации и в каждой ситуации индивидуально. Вы – специалист, и вы должны уметь выявлять то, что действительно требуется для моделирования бизнес-процесса. При этом вы будете исходить из контекста, из поставленной задачи, из ресурса финансового и временного и т.д.
Очень важно понимать что на самом деле вы всегда сможете добавить что то, даже если вы убрали это ранее. Ведь при обсуждении вам скорее всего укажут на вашу недоработку тот кого вы до этого интрвьюировали.
6. Выявить начало и конец процесса
Вы уже определяли цели процесса, теперь, после общения с сотрудниками компании-заказчика, их можно и даже нужно уточнить. Кроме того, на этом этапе нужно четко обозначить начало процесса, с учетом всех входящих данных.
Помните: финалов у бизнес-процесса может быть несколько, начало – всегда одно. В принципе в пункте 2 вы уже описали финалы, но важно понимать что на данном этапе вы пишете конкретно где и сколько будет финалов.
7. Составить список задач с условиями
Определите основные задачи, которые должны быть решены для достижения результата. Вы уже представляете, как работают сотрудники компании. Опыт и знания позволяют вам понять, как они должны работать, например, после внедрения автоматизации. И вы можете определить «ключевые моменты».
Например, в процессе продажи это может быть получение контактных данных у лида, чтобы иметь возможность вести с ним переговоры. Далее, согласование цены или ассортимента и т.д.
Условия или развилки — это места в в вашем описании бизнес процесса где действия процесс будет делиться в зависимости от условия. Обычно условия могут быть “или” или “и”. В зависимости от нотации количество видов развилок может варьироваться.
8. Сделать первый вариант бизнес процесса
Пришло время заняться созданием самого бизнес-процесса. Я обычно называю первый вариант черновым, но, тем не менее, показываю заказчикам. Именно в качестве черновика.
Необходимо уметь донести до своих клиентов, что это такое и зачем вы им показываете «черновик». Они должны понимать, что вы – специалист в своем деле, но не в особенностях работы их бизнеса.
И только совместная работа над бизнес-процессом поможет добиться наилучшего результата.
Потому вы составляете «черновой» вариант бизнес-процесса, а они его изучают, скорей всего, на уровне руководителей тех самых подразделений, которые будут по этой схеме работать. И вносят свои пожелания и уточнения.
На своем опыте я также понял, что оптимальное решение – разослать черновой вариант бизнес-процесса заранее всем заинтересованным лицам, например, за 1-2 дня до дня встречи или онлайн-конференции.
Графические нотации читаются просто, они понятны интуитивно даже не специалистам, особенно, если составлены грамотно. Нужно стараться делать ваши нотации как можно более понятными.
Впрочем, при необходимости вы можете составить краткое пояснение для каких-то сложных или особо важных этапов.
Дайте людям время на изучение бизнес-процесса. Пусть они составят свои вопросы и уточнения заранее. Конечно, никто не гарантирует, что они найдут время и прочитают нотацию заранее. Но все же старайтесь сделать так, чтобы заинтересованные люди успели ознакомиться с вашим «черновиком», и, что еще важнее, смогли понять, что именно вы предлагаете.
9. Обсудить детали с руководством и с ключевыми сотрудниками
Далее следует этап обсуждения. Здесь важно, с одной стороны, внимательно прислушиваться к мнению руководителей подразделений и самих сотрудников, учитывать нюансы, которые вы могли не совсем верно понять при первом интервью.
Но также помните, что эксперт в этом случае – вы. Именно вы знаете, как лучше. А потому везде, где сотрудники компании будут стремиться вернуть процесс на «привычные рельсы», а они будут это делать с высокой вероятностью, проявляйте твердость.
Они хорошо знают «как есть», а вы – «как должно быть».
10. Представить финальный вариант
Черновых вариантов может быть более одного, особенно, если бизнес-процесс сложный и специфический. Но в любом случае, этот процесс согласования не может продолжаться бесконечно. Лучше всего, если заказчик будет понимать заранее, что вы готовы дорабатывать 1,2 или 3 раза. Но не более. Тогда и обсуждение будет максимально конструктивным.
https://www.youtube.com/watch?v=3CGxOGA63YI
После согласований вы создаете финальный вариант графической нотации.
11. Подготовить текстовое описание бизнес процесса
Текстовое описание бизнес-процесса следует готовить после всех согласований. Подробно описывать имеет смысл только финальный вариант. Здесь уже вы готовите текстовое описание как документ, прилагаете к нему план работ и т.д. На основании графической нотации и этого описания вы в дальнейшем будете работать.
Правила описания бизнес-процесса
Выше я много сказал о творческом подходе, о возможностях включения условий и вариантов действий в описании бизнес-процессов.
В результате может показаться, что любое описание действий человека «на работе» можно считать описанием бизнес-процесса.
На самом деле, существуют строгие рамки и правила, которые определяют, можно ли назвать перечень действий описанием бизнес-процесса (в графической или текстовой форме) или нет:
- Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
- Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» — если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
- Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.
Видео:Моделирование бизнес процессов: гайд от начала до концаСкачать
Описываем бизнес-процессы организации
Под бизнес-процессом (БП) понимают группу видов деятельности организации (мероприятия и задачи), которые направлены на создание определенного продукта или услуги.
Проводя анализ, особенно в месте соприкосновения двух или нескольких подразделений занятых в одном бизнес-процессе, можно легко устранить различные издержки и барьеры и построить процессоориентированное предприятие или организацию.
БП принято рассматривать, деля их на подпроцессы и составляя детализированные карты. Иерархическая схема совокупности БП называется деревом бизнес-процессов. Она отражает простую схему взаимосвязей всех БП в их совокупности.
Существуют общие и детализированные модели БП. На верхнем (общем) уровне обычно приводится перечень операций по реализации продукта, проводимых отделами компании, в более детализированном варианте более полно раскрываются ключевые стадии и схемы со всеми аспектами.
Группы бизнес-процессов
Выделяют основные, вспомогательные и процессы управления – это главные группы БП. Как выполняемый единожды уникальный процесс отдельно выделяется БП развития. Направленность БП основной группы:
- производство ценных для потребителя продуктов (услуг);
- формирование добавленной стоимости;
- наполнение продукта ценными с точки зрения клиента качествами;
- оценка прибыли
Основные БП имеют клиентоориентированную направленность, так как результаты их направлены на конечного пользователя. Поддерживающие (вспомогательные) БП связаны с бизнесом на более тесных началах, они обеспечивают:
- создание продуктов для внутренних сфер бизнеса;
- поддержание функций компании, ее инфраструктурной составляющей
Процессы управления координируют всю совокупность БП (основные, поддерживающие, БП развития).
БП развития направлены на долгосрочную перспективу в получении прибыли, а также улучшение деятельность компании в будущем (не обеспечивают организацию процессов, происходящих в данный момент).
Представленная классификация не является окончательной. БП в каждой компании зависят от ее конкретных отличительных особенностей.
https://www.youtube.com/watch?v=MgOPRUSeNz4
Описание основных БП для производственно-торговой компании (пример):
- маркетинговые процессы;
- проектирование, разработка продукта или услуги;
- производство конечного продукта;
- логистические процессы (сбыт, доставка, снабжение);
- управление продажами и обслуживанием
Поддерживающие БП:
- финансовый контроль;
- управление службами и персоналом;
- экологические процессы (процессы защиты окружающей среды);
- управление связями предприятия;
- сопровождение систем и их проектирование;
- инфраструктурное управление
К управленческим БП для данной модели можно отнести все процессы, связанные со сбором информации, планированием и регулированием деятельности, процессы анализа и контроля всего управленческого цикла.
БП развития – совершенствование деятельности, своего рода бизнес-инжиниринг.
Описание и анализ БП
Описание БП позволяет определить место каждого сотрудника в компании, провести нужные изменения в ее деятельности на основании анализа: улучшить информационную систему, изменить управление рисками, провести сертификацию и т.д.
Оно позволяет сделать организацию более понятной для руководства, позволяет найти избыток как финансовых и прочих ресурсов.
Персонал по понятным причинам обычно не заинтересован в прозрачности, как и достоверности в описании БП – это осложняет получение фактической информации, например, о распределении обязанностей.
Визуализация модели.
Модель обычно отображают в виде схем, таблиц с описаниями, либо сочетание графика и текстового описания (нотация) и т.п. Степень детализации объекта, полнота описания, зависят от конкретного применения данной модели.
Задачей любого из этих способов будет описание БП по принципу: «действие-функция». У каждого БП есть свой исполнитель – это тоже нужно указывать. Им будет являться подразделение либо определенная должность.
«Входы» — это материальные, информационные и финансовые, а «выходы» представляются в виде перечня продуктов либо услуг.
Результатом действия исполнителя будет являться «выход», действия также могут объединяться по принципу логической связи между собой, тогда «входы» и результаты должны быть согласованы между ними. Связь «входа» и «выхода» обеспечивается деятельностью, направленной на достижение результата при переходе между ними.
Как реализуется описание БП
Как уже было указано выше, можно выделить графические, текстовые и табличные способы реализации модели. Несмотря на свои преимущества и недостатки все они находят применение, так как каждый из них соответствует целям, которые ставятся перед таким описанием.
1. Текстовое описание.
Главный плюс такой формы – это отсутствие точных стандартов и возможность гибкого описания фактически любого процесса или его нюанса. Организация может использовать любую текстовую форму отчетности, а также структурировать собранную информацию на свое усмотрение. Недостатки:
- последовательное восприятие текстовой информации;
- на основании текстового представления сложно провести анализ деятельности предприятия;
- отсутствие формальности и описательных стандартов (как плюс, так и минус в зависимости от случая);
- тяжесть восприятия и сопоставления больших объемов текста
2. Табличная форма. Подходит для описания последовательных процессов. Может применяться в качестве переходной к графической реализации в качестве базы данных.
3. Графическое описание в виде моделей и диаграмм.
Если необходимо описать, как происходит регламентирование на этапах БП: кто исполнитель, как происходит реализация, какая последовательность и документация участвует – то уместно применить алгоритмический способ описания работ в виде блок-схемы.
Следующий вариант – представление процесса как потока из объектов. Он применим и удобен для описания отдельных задач и тех подразделений в организации, которые работают по принципу «вход-выход», позволяя непосредственно отслеживать, что происходит между этими двумя составляющими. Потоками «входа» и «выхода» будут являться информация, материальные поставки, документация.
Технологии, которые используются для описания БП:
1. IDEF — принята за стандарт практически повсеместно. Integration Definition for Function Modeling –технология моделирования функционала. Поддерживается следующим программным обеспечением – BPWIN, MS Visio и пр. Это совокупность методов моделирования позволяет детализировать БП всех уровней, представляя их как в одном блоке, так и в отдельных схемах.
2. Технологии моделирования используют унифицированный язык моделирования (UML). Он позволяет описывать БП непосредственно на языке понятном компьютерным программам, является средством автоматизации. Поддерживается ведущими разработчиками ПО, основным инструментом для реализации является программное средство Rational Rose от IBM.
3. Диаграммы еЕРС (extended Event-Process Chain). Благодаря им, есть возможность отобразить последовательность операций, участников, используемые ресурсы, отображая состояние на текущий момент времени.
4. Технология ARIS (Architecture of Integrated Information Systems) используется как встроенный инструмент в одну из крупнейших систем автоматизации – SAP R/3.
Моделирование БП – это совокупность деятельности, направленной на создание модели организации, подразумевающее описание всех объектов (информационных, материальных и т.п.) и процессов, роли подразделений и отдельных должностей и связей между ними.
Составление моделей – это основной метод инжиниринга БП и их реорганизации, позволяющий также использовать методологии непрерывного их улучшения, позволяющий переосмыслить и улучшить эффективность всех видов деятельности в организации или предприятии.
Алгоритм действий при моделировании:
1. Определение целей для описания БП. Подготовка к моделированию, выбор модели. Так как модель составляется для непосредственно практического использования, то цели такого описания должны согласовываться с будущими перспективами. Описанию подлежат все бизнес-процессы – основные, вспомогательные (поддерживающие), управленческие, развития.
2. Описания всего окружения БП, а именно указание всех процессов с которыми он связан на «входе» и «выходе», включая все ресурсы на этих этапах.
3. Описание функционального содержания БП. Подразумевает описание всех зон ответственности для каждого из подразделений или должности в организации.
4. Описание БП потоков и их структуры. Определяется целями, которое оно преследует. Если необходимо улучшить информационную систему, тогда описываются потоки информации, документооборот и т.п., если цель распределить правильно финансы – тогда финансовый поток и БП в них.
5. Построение, в зависимости от предпочтений и целей, текстовой, графической модели либо диаграммы.
6. Составление последовательности действий в БП. Определение последовательности исполняемых функций, условий исполнения, а также параметров, которые определяют именно такой алгоритм.
https://www.youtube.com/watch?v=VW88MgEfWec
При нужном подходе внедрение такого типа управления не отнимает много ресурсов как временных, так и материальных. Главное это убедиться в необходимости проведения такой реорганизации в пределах конкретной компании.
📽️ Видео
Описание бизнес-процессов "как есть" и "как надо"Скачать
Схема бизнес процесса Как нарисовать схему процесса в BPMN за 2 минуты?Скачать
Суть процессного управления | Naked BPMСкачать
Оргсхема в современном бизнесе. Основы организационной структуры предприятия простыми словамиСкачать
Современные нотации описания бизнес-процессовСкачать
Анатомия бизнес-процесса. Основные термины | Naked BPMСкачать
Как правильно описать бизнес-процесс?Скачать
Процессное управление простыми словами или понятно про бизнес-процессСкачать
Как с помощью CRM автоматизировать маркетинг в крупных Retail компаниях: теория и практикаСкачать
Стандарт производства как описать бизнес процессы на производствеСкачать
Улучшение бизнес-процессов методом организации точек контроляСкачать
От Младенчества к Бирюзовым организациям. Спиральная динамика и уровни зрелости процессов.Скачать
АВТОМАТИЗАЦИЯ БИЗНЕС ПРОЦЕССОВ. Какие процессы автоматизировать? 9 Шагов. Система управленияСкачать
Построение системы управления бизнес процессами крупного предприятия / ВебинарСкачать
«Внедрение системы управления бизнес-процессами: с чего начать?»Скачать
Как описать простой бизнес-процесс. ПримерСкачать
ELMA управление бизнес-процессами. BPMСкачать