А каким образом выполняется функциональное моделирование бизнес-процессов?

Вот BPMN2 мне здесь все понятно - четко и логично.

А как подступиться к функциональной нотации? Она какая-то, абстрактная чтоли.

Вот есть функции по иерархии

Управление предприятием
-АУП
-Закупки
--Управление складскими остатками
--Определение более выгодных поставщиков
-Производство
-Сбыт



В какой момент декомпозиция функций становится процессами, которые можно описать нотацией BPMN2?

Нет ли ошибке в постановке вопроса?

Может быть, функционального моделирования бизнес-процессов быть не может, а может быть только моделирование функций (иерархическое)?

(0) А цель-то какая?

для каждого блока попробуй построить укрупненную схему БП в нотации IDEF0 там есть очень важное свойство блока "управление", на основании этого свойства четко будет видна структура управления, по тому как тебе скорее всего нужно строить функциональную схему на основании схемы управления процессами.

И вот когда построишь IDEF0  уже можно будет делать декомпозицию каждого блока или опять в IDEF0 или в BPMN

(3) мне вообще IDEF0 не нравится, неадекватная она какая-то.

то ли перегруженная, то ли хз

(2) +1
(4) странно. Это почти одно и тоже. Только idef0 это давно используемая, а ваша, только только.

(0) Делается в той нотации, которую знает заказчик

Я делаю в свободной нотации используя 2-3 элемента

(0) Вигерс К., Битти Д. Разработка требований к программному обеспечению

Тут все есть

(7) IDEF0 - это всегда один элемент, куда проще я не знаю...

я почитаю (8) , просто мне IDEF0 еще с универа не нравится.

(9) Это и подразумевает недостаток, и не всегда нужны управление и ресурсы на схеме

(11) да в том его и прелесть, что управление и ресурсы нужны всегда, как только это люди понимают они начинают выделять вместо "действий" "процессы".

(10) ты просто не вникся идеей, она простая и по этому в нее сложно поверить и хочется попытаться все построить логически по аналогией с программой, а жизнь она простая до красоты...

Разумеется IDEF0 не для всего можно применять, но для описания БП - она чертовски хороша, одновременно и проста и эффективна

(12) вот тут и вопрос

IDEF0 вроде хороша для функционального моделирования

а как подступиться к этому функциональному моделированию, я еще не (8) прочитал

(12) я не занимаюсь оптимизацией орг структуры, а только описываю бп с точки зрения получения ключевой инфы, смысла в ветке управления или ресурсов, вообще никакой

(14) а почему? на этом этапе можно получить самый большой выхлоп по результативности.

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

(15) Все же зависит от целей и бюджетов

Если ты занялся оптимизацией орг структуры, тебе нужны не только диаграммы документов, но и диаграммы принятия решений, а еще лучше и допом добавить диаграммы стоимостей процессов, и сравнить их с текущей на предприятии СМК (системой менеджмента качества),

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

У меня был проект управления производственным предприятияем(50->100 человек, оборот с 100-> 200кк), годовой, и повверь, до этого этапа за год мы не дошли

Почитай консалтинговую литературу по реинжинирингу БП, и инжинирингу.

По моему опыту, я в реинжиниринг не верю

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

Но по опыту конса (20 лет работы на должностях директор, главных технолог), который занимался оптимизацией производств, больше года таких проектов ни один собственник не выдерживает, сколько бы ты бабок не принес

так что я для себя ответил, стоит ли заниматься расписыванием диаграмм принятия решения, или диаграмм управления ресурсами, или других диаграмм, которые в проекте принимать участия не будут

(20) собаку съели...

(21) хороших аналитиков для толкового описания фиг найдешь, сейчас в основном этим занимаются бывшие выпускники вузов, они шпарят по умным книжкам без привязки к реалиям. А такие описания БП  в 90% внедрений ведут к ОЧЕНЬ большим проблемам...

Всю эту шляпу надо поднимать основываясь на базовых прицепах swot анализа каждого процесса в целом и каждого этапа по отдельности....

(22) Акроним SWOT был впервые введён в 1963 году в Гарварде
IDEF0 как стандарт был разработан в 1981

Там как бы вышло еще много чего после 85 года

(15) Вы кто? Бизнес-консультант или внедренец ПО?

(0) Добрый день.
Вы не найдете ответов в гугле или здесь. Переход от языка архитектуры к языку процессов – живая практика, самый-самый фреш. Вне 1С это более развито и сейчас сильно хайпится. Но многие сразу идут в учителя, без практики. Пока больше воды, чем знаний.
Меня это тоже достало и есть чем поделиться. В планах цикл статей на инфостарте о том, как вообще внедрять ERP от архитектуры, спускаясь к функциям и документам. Думал закончить в этом году, но вряд ли. На проекте большая загрузка.

(25) на форуме есть хейтеры, это да. Но есть и люди, которые знают, что делиться знаниями - это не значит взрастить себе конкурентов :)

(26) А что это?

(25) Этому "фрешу" лет 20 уже, если не 30