Элементарные правила описания процессов

Элементарные правила описания процессов

Правила описания процессов, которые я здесь привожу, в первую очередь, предназначены для тех, кто не использует специализированное программное обеспечение. Если для описания процессов вы пользуетесь стандартными офисными программами наподобие MS Office и MS Visio, то эта статья будет вам очень полезна.
Элементарные правила описания процессов

Элементарные правила описания процессов

1. Карта процессов верхнего уровня отражает не более 22 - 25 процессов, включающих в себя основные процессы, вспомогательные и процессы управления.

2. На карте верхнего уровня необходимо отображать взаимосвязи процессов. Взаимосвязь - это то, что производит один процесс и использует другой. Производитель - клиент. Таким образом, вы связываете основные процессы в цепочку добавленной ценности.

Элементарные правила описания процессов Основные процессов на карте верхнего уровня.jpg
Основные процессов на карте верхнего уровня

 3. Вспомогательные процессы, как правило, поставляют свои продукты во все остальные бизнес процессы. Например, процесс «Управление персоналом» поставляет свой продукт "персонал" во все остальные процессы. В таком случае укажите на карте факт выхода процесса, но не связывайте его с другими процессами. 

Элементарные правила описания процессов Отображение продуктов вспомогательных процессов.jpg
Отображение продуктов вспомогательных процессов

 4. Помимо прочего на карте процессов верхнего уровня должны быть отображены:

  • Продукты
  • Категории клиентов
  • Требования к продуктам

Элементарные правила описания процессов Отражение элементов карты процессов верхнего уровня.jpg
Отражение элементов карты процессов верхнего уровня

5. Расположение организационных единиц, которые участвуют в бизнес процессах на карте верхнего уровня, поможет в дальнейшем анализе.

Подробнее о подготовке карты процессов верхнего уровня:

6. Если вы не используете ПО для моделирования бизнес-процессов и намереваетесь в дальнейшем использовать распечатанные описания процессов, настоятельно рекомендую нумеровать / кодировать процессы. Это поможет не только в соединении уровней описания, но и облегчит поиск связей в документах.

Пример кодировки процессов

В нашей компании мы используем следующие принципы определения кода процесса:

  • Карта процессов верхнего уровня всегда имеет код А1.
  • Каждый бизнес процесс на карте верхнего уровня имеет свой номер и буквенное обозначение:
  • Основные процессы обозначаются буквой B (Business)
  • Вспомогательные процессы имеют букву C (Costs)
  • Процессы управления начинаются с буквы D(Driver)
  • После буквы идет порядковый номер процесса
  • Нумерация процессов сквозная, то есть не зависит от буквы процесса, нумерация идет по порядку. Так что набор процессов может быть таким: B2, B3, B4, C5, C6, D7 и т.д.
  • Подпроцессы следующего уровня используют многоуровневую нумерацию. Например, подпроцессы процесса B2 будут начинаться с B2.2, B2.3 и т.д.
  • После кода процесса всегда следует его название. Например, B2 Производство. А его подпроцесс «Настройка оборудования» будет иметь код B2.2

7. Понятие уровней. Уровень представляет из себя описание процесса в определенных рамках детализации. Если на первом уровне процесс описывается в виде одного блока и лишь основных входов и выходов, то чем ниже уровень описания, тем детальнее оно становится.

Элементарные правила описания процессов Уровни описания процессов.jpg
Уровни описания процессов

8. Деление процессов на уровни называется декомпозицией. Чем больше процесс декомпозирован, тем детальнее он описан. 

9. Жестких правил по декомпозиции процессов по уровням нет. Тем не менее мы в своей работе выделяем 3 уровня описания бизнес процессов. 

Основы бизнес-процессов - тезисы вебинара Уровни декомпозиции процессов.jpg
Уровни декомпозиции процессов

10. Разные уровни описания процесса размещаются на разных схемах. 1 схема = 1 лист описания. См. Правила моделирования бизнес- процессов 

11. Правила описания процессов говорят о том, что разные процессы могут иметь разное количество уровней описания. 

12. Если нас интересует содержание подпроцесса, а не его взаимодействия с другими, то это описание представляет из себя одну схему уровня. 

13. Тем не менее связи схемы на листе должны быть понятны. Должны быть обязательные пометки о том, к какому процессу и уровню относится данная схема. Частично эта проблема решается с помощью нумерации и кодификации, однако можно сделать еще удобнее. Для этого можно использовать отображение «пути» декомпозиции. Как это делается на интернет страницах.

Элементарные правила описания процессов Путь декомпозиции процесса в названии.jpg
Путь декомпозиции процесса в названии

 14. Если элемент на схеме ссылается на элемент на другой схеме (странице), необходимо указать номер и название объекта, на который ссылаются. Если есть возможность автоматически вставить номер страницы, на которой располагается элемент, то стоит такую ссылку сделать. Вручную же указывать номера страниц не стоит. Нумерация страниц может быть легко нарушена, и тогда ссылки окажутся бесполезными.

Элементарные правила описания процессов Ссылки на другие процессы по системе кодирования.jpg
Ссылки на другие процессы по системе кодирования

15. Наименование страницы со схемой должно соответствовать системе кодирования и названия процессов. 16. Уровни заголовков страниц со схемами процесса должны соответствовать уровням описания. В таком случае с помощью функции оглавления вы сможете сразу создать структуру описания - удобную для ориентации и поиска информации.

Элементарные правила описания процессов Структура документа на основании заголовков.jpg
Структура документа на основании заголовков

 17. Если есть возможность делать активные ссылки внутри документов, чтобы при нажатии на нее происходил переход на указанное место, то это желательно сделать. Это экономит время и удобно. 

18. В документе со схемами и описаниями обязательно должен быть раздел с расшифровкой терминов и значков схем процессов. 

19. В общем мы рекомендуем следующую структуру документов по описанию процессов:

Элементарные правила описания процессов Рекомендуемая структура документации.jpg
Рекомендуемая структура документации

 20. Соотношение схем и текстового описания. Схема должна быть составлена таким образом, чтобы текстового пояснения требовалось по минимуму. Однако не всегда можно избежать текста, а порой дополнять просто необходимо. В таком случае используйте принцип сносок. Т.е. если к элементу на диаграмме есть некое текстовое пояснение дальше, то необходимо указать номер сноски. Схема и текстовые пояснения должны быть на разных листах. 

Элементарные правила описания процессов Указание номера текстовои сноски на диаграмме.jpg
Указание номера текстовои сноски на диаграмме

 21. Схема должна быть составлена таким образом, чтобы она могла разместиться на одном листе А4 и быть достаточно удобной для прочтения в таком размере. Если схема получается слишком большой, разбивайте процесс на большее количество подпроцессов. 

22. Обязательно ведите историю изменений документа. История должна быть неотъемлемой частью документа. 

23. Скрупулезно проверяйте изменения и названия в документе. Не должно быть такого, что в одном месте название объекта изменили, а в другом нет. Таковы базовые правила описания процессов.

Статьи по теме
Что такое аудит системы менеджмента качества

Аудит системы менеджмента качества – проверка соответствия бизнес-системы, процессов или функций, на соответствие определенным требованиям. Требования может задавать стандарт, например из семейства ИС...

Читать
7 правил декомпозиции процессов

Декомпозиция процессов - вопрос, по которому довольно сложно найти конкретные рекомендации и правила. Мы сформулировали 7 правил декомпозиции бизнес-процессов на основании практики управления бизнес-п...

Читать
Что такое система менеджмента качества?

Качество – тоже объект управления. Обеспечить качество процессов, работ, продуктов и услуг, призвана система менеджмента качества. И сегодня мы кратко расскажем о том, что это такое и с чего стоит нач...

Читать
Как устранить узкое место в бизнес-системе?

Узкое место - это процесс, который ограничивает производительность всей бизнес-системы. Поиск и устранение узких мест – одна из важнейших задач для руководителей любого уровня. В данной статье мы расс...

Читать
Стандартные операционные процедуры. Руководство по разработке

Стандартные операционные процедуры (СОП) – неотъемлемый элемент системного управления бизнес-процессами. На первый взгляд разработка СОП может показаться сложной, но все не так уж и сложно.

Читать
Как вовлечь сотрудников в улучшение бизнес-процессов

Невозможно системно заниматься оптимизацией бизнес-процессов, если не знать, как вовлечь сотрудников в данный процесс. Но как это сделать? Как подтолкнуть на разработку идей? Как разбудить активность?...

Читать
Оптимизация рабочего процесса: полное руководство

Оптимизация рабочего процесса – приведение его к такому состоянию, когда процесс производит качественный продукт с наименьшими издержками. Любой процесс оптимизации можно свести к шести ключевым этапа...

Читать
Зачем и как описывать бизнес-процессы?

Есть процессы более сложные, есть более простые. В любом случае, вам может потребоваться их описать. Поэтому важно понимать: зачем и как описывать бизнес-процессы.

Читать
Как устранить потери и улучшить процессы

Первое, что необходимо сделать, чтобы улучшить процессы — устранить потери. Некоторые потери можно устранить относительно просто. Другие потребуют серьёзных организационных и процессных изменений.

Читать
Комментарии
Комментировать

Данный сайт использует cookie-файлы, а также собирает данные об IP-адресе и местоположении с целью предоставления наиболее корректной информации по Вашему запросу. Продолжая использовать данный ресурс, Вы автоматически соглашаетесь с использованием данных технологий.