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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Наименование страницы со схемой должно соответствовать системе кодирования и названия процессов.

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

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

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

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

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

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

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

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