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

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

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

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

  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. Скрупулезно проверяйте изменения и названия в документе. Не должно быть такого, что в одном месте название объекта изменили, а в другом нет.

Таковы базовые правила описания процессов.

by Roman Zaytsev

8 comments

  1. Вероника says:

    Спасибо, Роман, как всегда — полезно. Мы сейчас занимаемся описание процессов в компании, где основной процесс — разработка изделия и производство под заказ клиента. Фактически бп начинается с заявки от клиента, далее уходит в отдел НИР, далее по циклу в производство, логистику и проч и потом опять возвращается на уровне сделки в продажи на оформление. Нам было очень важно увязать все в одну цепочку для настраивания бп в программе документооборот. В итоге — громоздкий процесс с подпроцессами. Что бы Вы порекомендовали для упрощения визуализации? Могли бы порекомендовать что-либо прочесть по подобным бп? Буду очень признательна.

    • Вероника здравствуйте.
      Вы абсолютно правильно связали основные процессы в единую цепочку добавленной стоимости. Она может быть простой, на каждом конкретном уровне, но вот в совокупности- процессов будет довольно много.
      Определить количество уровней и, как следствие, степень детализации каждого, задача не простая. И проблема здесь в том, что нет формальных правил для этого.
      Я бы посоветовал попробовать решить проблему, установив ограничение в количество подпроцессов на каждом уровне описания. Не более 5-7.
      Если вы подойдёте к проектированию с учетом ограничений, думаю проблема будет решена.
      Также можете прислать мне ваше описание. Таким образом я смогу дать конкретные рекомендации.

  2. Александр says:

    Роман, спасибо за практический материал! Уже давно хотел спросить: Вы никогда не пробовали проектировать коммуникации персонала между собой во время описания бизнес процессов для верификации и оптимизации событий на различных пулах и дорожках? Я не имею большой практики по описанию БП, но в ходе теоретических изысканий пришел к выводу, что от качества определения границ процессов зависит примерно 60% качества всех моделей и архитектуры БП в целом. Одной из возможных методик проектирования коммуникаций я вижу построение социальных сетей и их анализ. Скажите, исходя из Вашего опыта, целесообразно ли инвестировать в трудозатраты по данному направлению? Буду благодарен за ответ.

    • Александр здравствуйте.
      Анализ и проектирование коммуникаций в бизнес процессах, это обязательная часть при работе с ними. Правда это не совсем имеет отношение к тому, что мы понимаем под границами. Ну да ладно.
      Без эффективных коммуникаций процессы не работают. А значит ими нужно заниматься.
      На социальных связях заморачиваться не стоит. Они очень не устойчивы, быстро меняются и крайне вариативно влияют на процессы. Так что это не будет эффективной инвестицией.

Добавить комментарий

Ваш e-mail не будет опубликован.