Анна, здравствуйте! Спасибо за вопрос🙂 Только изучения документов обычно недостаточно на практике реальные процессы часто отличаются от того, что написано в регламентах 😊 Поэтому использую в своей работе “полный комплекс”: это и интервью с ключ.сотрудниками и руководителями и анализ документации(если она есть) параллельно выписываю вопросы и потом в 1 день задаю их. Например в производстве т.к. лучше них реальную картину никто не знает, дальше наблюдаю за выполнением процессов в реальной работе, и в конце рабочие сессии для валидации с участниками процесса.

Опыт научил что заказчик или владелец обычно не владеет всеми нюансами своего же производства( если говорим о крупных корпорациях) это ему чисто физически невозможно. Поэтому я всегда анализирую всё что есть, выслушиваю все пожелания и приоритет производство, руки и люди. Чем лучше пропишу им работу, тем проще им работать и давать лучший результат. Без них это никак не сделать🙂 нет, можно конечно… но пострадает качество, а это не нужно.

Да, согласна. Точно также делаю, еще согласую со всеми участниками, вношу правки, если есть замечания.

Да да, это обязательно

Я устраивался в штат на разные должности, непосредственно погружался во все тонкости процесса.

Анна, Мария - браво, коллеги 👏🙌😊 Искреннее уважение вам за профессионализм 🤝

Дмитрий, благодарю!

В данный момент у меня нет основной работы и привязки к компании предприятию и тд. Работаю сама на себя, параллельно ищу хорошее предложение в компании на основное трудоустройство. Сама себя под nda не заключаю😃 только в том случае, если заказчику это необходимо и важно(как проектная работа). Но сами понимаете, компании, масштабы, информации и запросы у всех разные, тут вам нужно посмотреть свой nda, посоветоваться с трудовым юристом и владельцем вашей компании😉😊 дерзайте, я в вас верю🙏

Дмитрий, спасибо за вопрос

По инструментам: работаю со всеми крупными фреймворками Sheer, Bizagi, Camunda и т.д выбор зависит от задачи. BPMN 2.0 потому что это исполняемый стандарт, который понимают движки автоматизации вроде Camunda. Это универсальный язык для всех: и для бизнеса, и для разработчиков, и для заказчиков. В отличие от UML, BPMN заточен именно под бизнес-процессы потоки работ, шлюзы, события, эскалации, а не под структуру системы. Плюс это ISO-стандарт, который легко масштабировать. Для этого кейса была важна автоматизация и прозрачность для всех участников процесса.

Дмитрий, а вы с чем больше работаете Aris UML или BPMN?

Когда-то давно я познакомился с UML, информации было немного, изучал его, поноавилась его живая логика, т.к. в ней на старте важную/главную роль играет субъект, bpmn только изучаю..

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

Этап реализации проекта в данной схеме это “Пилотное внедрение” и “Масштабирование” (блок финансового департамента), а также “Передача в эксплуатацию” (блок подразделений-получателей). То есть процесс охватывает полный цикл: от идеи до реальной эксплуатации инновации.

Про финансовый блок: это не проекты внутри финдепартамента. Финансовый департамент здесь выступает как координатор и контролёр инновационных проектов всей компании оценивает эффективность, согласовывает бюджеты, отслеживает KPI. Это их зона ответственности по управлению портфелем инноваций.

Подразделения-получатели -это те отделы, которые фактически внедряют и используют инновацию в своей работе. После того как пилот прошёл успешно и KPI достигнуты, проект передаётся им в эксплуатацию (это видно по стрелке “Проект успешно завершён” → “Передача в эксплуатацию”).

Логика такая: 1. Директорат утверждает идею 2. Проектная команда готовит проект 3. Финдепартамент контролирует бюджет и KPI на всех этапах 4. После успешного пилота и масштабирования → передача подразделениям-получателям 5. Они уже работают с инновацией в реале, а финдепартамент продолжает мониторинг KPI

То есть это сквозной процесс управления инновациями по всей компании, а не только внутри одного департамента. Важный момент: эта диаграмма часть из 3 взаимосвязанных процессов. Для полноты картины нужно показать все уровни детализации, но NDA договор с компанией, не позволяет опубликовать остальные процессы. Если интересно, готова обсудить детали в личных сообщениях.

Ага... То есть фин блок - это по сути внутренний заказчик по тестированию (пилот) и подтверждению (масштабирование) инновационных идей. Так? А кто в таком случае является исполнителем (конкретно руками делает) пилота и масштабирования? И почему проектная команда участвует в процессе только вначале, но не занимается пилотом и пр.? Какова её роль? PS. Что до NDA, тут все понятно, без вопросов 😀

Константин по финблоку:да, верно, но с уточнением они не просто тестируют, а оценивают экономическую эффективность инноваций (ROI, бюджет, KPI). Это их функция как внутреннего заказчика Кто исполнитель пилота и масштабирования: на схеме это явно не выделено (в целях конфиденциальности), но обычно это инициатор инновации (автор идеи) вместе с подразделением-получателем. Финдепартамент только контролирует процесс и принятие решений, но не реализует технически. Проектная команда: её роль подготовка проекта к запуску (формирование команды, планирование сроков и бюджета, KPI). После того как проект передан на пилот, проектная команда уходит дальше работают исполнители и получатели под контролем финдепартамента. Это стандартная европейская практика: проектная команда создаёт условия для запуска, а не реализует операционную часть

Теперь все понял, спасибо 👍 И ещё чисто технический вопрос: почему гейты так необычно выглядят? Логика работы процесса понятна, но очень непривычно для меня отрисована 🤔 Я все больше как на картинке привык. Есть какая-то причина в таком подходе?

Константин, супер вопрос, спасибо😊 Вы правы, шлюзы (гейты) на моей схеме выглядят нестандартно. Причина в инструменте моделирования и уровне детализации. На вашей схеме классический XOR-шлюз (эксклюзивное ИЛИ) в "развернутом" виде: ромб с крестиком и подписанными исходящими потоками. Это более "академический" вариант, который чаще используют для простых примеров. В моей схеме я использовала компактное отображение шлюзов это когда несколько условий выхода показаны без дополнительных линий, а с прямой подписью на стрелках ("Да", "Нет", "Критично" и т.д.). Это делается для: а) Экономии места процесс сложный, с множеством ветвлений, и если каждый шлюз рисовать "развернуто", схема станет громоздкой и нечитаемой. б) Для удобства чтения когда условий много, компактный стиль позволяет быстрее отследить логику процесса, не "бегая" глазами по всей диаграмме. в) Инструмента-я работала в среде, которая по умолчанию использует такой стиль отображения (похоже на нотацию Camunda или Bizagi в компактном режиме). Суть от этого не меняется: это всё тот же XOR-шлюз (эксклюзивное ИЛИ) выбирается только один путь из возможных в зависимости от условия. Просто визуальное отображение другое.

Если вам удобнее классический стиль при экспорте из большинства инструментов можно переключиться на "развернутый" вид. Главное чтобы схема была понятна всем участникам процесса. А дальше дело вкуса и полёта фантазии🙃😄

Спасибо 👍 Соглашусь, что для удобства такой вариант вполне подходит

Анастасия, благодарю за такие содержательные вопросы☺️

Инструменты: работаю во многих программах Bizagi,Sheer и т.д, когда планируется автоматизация. Но инструмент вторичен: сначала изучаю текущее состояние процесса, провожу рабочие встречи с участниками, и только потом перехожу к моделированию. Касаемо обработки исключений: всегда предусматриваю потоки обработки отклонений, маршруты эскалации и шлюзы принятия решений. В этом процессе, например, есть четкие сценарии для ситуаций “целевые показатели не достигнуты”, “требуется доработка” или “проект отправляется в архив”. Дополнительно создаю матрицу ответственности и матрицу эскалации чтобы команда могла самостоятельно принимать решения в нестандартных ситуациях(но тут уже зависит от пожелания владельца/заказчика)

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

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

Анастасия, а вы с какой стороны работаете с процессами больше аналитика или внедрение? Если интересно, с радостью пообщаюсь лично всегда ценю профессиональный диалог с коллегами 💬

Красота и результат наше всё😁