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

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

Правила описания процессов, которые я здесь привожу, в первую очередь, предназначены для тех, кто не использует специализированное программное обеспечение. Если для описания процессов вы пользуетесь стандартными офисными программами наподобие 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 потерь — действия, которые существуют в бизнес-процессах организации, не создают ценности, но требуют денег.

Читать
Производительность и эффективность: что важнее?

… на мой вопрос, что для вас важнее, производительность или эффективность, я снова получил ответ: разве это не одно и то же? Нет. Производительность и эффективность это разные вещи и в этой стат...

Читать
Построение диаграммы SIPOC

Диаграмма SIPOC представляет собой высокоуровневое представление процесса. Диаграмма позволяет определить и компактно отобразить самое главное: поставщиков, входы, процессы, продукты и клиентов процес...

Читать
Анализ разрывов

Анализ разрывов - инструмент, который позволяет определить шаги, для повышения эффективности не только отдельных процессов, но и бизнеса в целом. Проще говоря, анализ разрывов позволяет понять, ...

Читать
Диаграммы и поиск потерь в бизнес-процессах

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

Читать
Процессный подход - 10 фундаментальных принципов

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

Читать
Регламент взаимодействия. Что нужно знать

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

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

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