Если автоматизированного то да в этом смысла никакого нет, а если автоматизируемого, то схема очень неплохо снижает риски непонимания всеми участникам бизнес процесса итог по моему 12 летнему опыту стейкхолдеры обычно не имеют понятия о собственном процессе что создает огромные риски недокументированных требований
Вы слишком много хотите от обычной схемы)) Я лично bpmn использую исключительно для согласования верхнеуровнего описания автоматизируемого процесса, а даже уже идёт все то что вы перечисляет имя этому BRD и Functional/System specification. Не знаю от чего у вас такой зуб на BPMN его плюс в его простоте, например тот же IDEF0 который мне лично нравится больше гораздо сложнее для восприятия не подготовленного человека, а BPMN понимают почти все. Ещё важно понимать что в каждом проекте я сам описываю используемые элементы и их описание.
В реальности несколько раз использовал ddg и честно говоря чего то ощутимо большего она не выдавала, а то что выдала был либо не релевантно либо откровенный левак, так что после примерно месяца использования я вернулся на гугл (вернее я юзал и то и другое, потом просто от ddg отказался).
Лет 10 уже занимаюсь профессионально аналитикой а она все новая нос для IT)) Отлично значит есть ещё области для роста)) Могу сказать что за 10 лет для себя определил очень простую формулировку зачем нужен аналитик - это снижение риска для заказчика. Причём на важно системный или бизнес, очень часто эта роль совмещена, но если объяснять просто, то бизнес аналитик это страховка для всех участников процесса, что результат будет достигнут, в конечном счёте когда доходит до вопроса почему это сделано так все смотрят документацию и описание требований, если их нет, то и разговора нет, заказчик не получил то что хотел, разработчик возможно и получил свои деньги но вместе с этим получил плохую репутацию. Вся эта ситуация даже с плохим аналитиком значительно мягче ибо есть требования плохие но есть и от них все и пляшет, плюс заказчик и разработчик могут списать плохие требования на аналитика. Другими словами аналитик это тот кто является гарантом того что в конечном счёте проект доползет до финиша и что договорённости достигнутые на берегу все ещё будут в силе. Бизнес соответственно с точки зрения бизнес требования, системный с точки зрения системных требований. Именно поэтому у хороших и высококвалифицированных аналитиков такая зарплата.
Если автоматизированного то да в этом смысла никакого нет, а если автоматизируемого, то схема очень неплохо снижает риски непонимания всеми участникам бизнес процесса итог по моему 12 летнему опыту стейкхолдеры обычно не имеют понятия о собственном процессе что создает огромные риски недокументированных требований
Вы слишком много хотите от обычной схемы)) Я лично bpmn использую исключительно для согласования верхнеуровнего описания автоматизируемого процесса, а даже уже идёт все то что вы перечисляет имя этому BRD и Functional/System specification. Не знаю от чего у вас такой зуб на BPMN его плюс в его простоте, например тот же IDEF0 который мне лично нравится больше гораздо сложнее для восприятия не подготовленного человека, а BPMN понимают почти все. Ещё важно понимать что в каждом проекте я сам описываю используемые элементы и их описание.
В реальности несколько раз использовал ddg и честно говоря чего то ощутимо большего она не выдавала, а то что выдала был либо не релевантно либо откровенный левак, так что после примерно месяца использования я вернулся на гугл (вернее я юзал и то и другое, потом просто от ddg отказался).
Лет 10 уже занимаюсь профессионально аналитикой а она все новая нос для IT)) Отлично значит есть ещё области для роста)) Могу сказать что за 10 лет для себя определил очень простую формулировку зачем нужен аналитик - это снижение риска для заказчика. Причём на важно системный или бизнес, очень часто эта роль совмещена, но если объяснять просто, то бизнес аналитик это страховка для всех участников процесса, что результат будет достигнут, в конечном счёте когда доходит до вопроса почему это сделано так все смотрят документацию и описание требований, если их нет, то и разговора нет, заказчик не получил то что хотел, разработчик возможно и получил свои деньги но вместе с этим получил плохую репутацию. Вся эта ситуация даже с плохим аналитиком значительно мягче ибо есть требования плохие но есть и от них все и пляшет, плюс заказчик и разработчик могут списать плохие требования на аналитика. Другими словами аналитик это тот кто является гарантом того что в конечном счёте проект доползет до финиша и что договорённости достигнутые на берегу все ещё будут в силе. Бизнес соответственно с точки зрения бизнес требования, системный с точки зрения системных требований. Именно поэтому у хороших и высококвалифицированных аналитиков такая зарплата.