Не сочтите за спор. Но у меня есть представление о том, что такое бизнес-процессы, 4 года преподавал в ВШЭ по этой теме. И да, я ошибся, назвав BPMN методологией, а не нотацией, что вышло случайно. Пардон. Если я правильно понимаю, вы занимаетесь проектированием и анализом бизнес-процессов именно с помощью неё. У меня был опыт и проектирования и анализа, например, с помощью Comundа. Но, опять же, я не являюсь сторонником отдельных методов, нотаций или чего либо еще. Есть задача, есть способы их решения. Здесь был предложен один из. Кстати, может быть не вам, но другим читателям будет интересно изучить труды Anna Grandori https://openlibrary.org/authors/OL1071918A/Anna_Grandori – здесь очень полезно про структуру организаций и бизнес-процессы именно с точки зрения сетей взаимодействия.
Около 2 недель. 1 неделя у нас ушла на то, чтобы подобраться к данным, найти подходящий способ визуализации. 2 дня ушло на майнинг комментариев с помощью LLM, создание таблиц и остальное время – это визуализация + интерпретация. Я не аналитик, поэтому могу быть не точным в терминологии. По времени, если бы заранее знали подходящий вариант визуализации...тут несколько переменных: количество данных, которые нужно спарсить, структура данных + прогонка через LLM. На 18 000 сообщений, я выше упомянул, ушло +- 2 дня.
в нашем кейсе после проведения анализа мы: 1. Презентовали структуру процессов сотрудникам; 2. Указали кто является узким местом, предложили часть задач автоматизировать, что и было сделано.
На самом деле те данные, которые были получены, использовались процентов на 30. Потому что у нас есть данные по времени движения проектов по этапам, время упоминания сотрудников, время отклика и много чего еще. Можно построить динамическую карту по каждому проекту, чтобы увидеть временные задержки, связать из с процессами, а далее предложить способы оптимизации. Но это лишь пример.
p.s. Есть некоторые данные, которые в кейсе не были опубликованы. Например, последняя иллюстрация показывает "ожидания" к сотрудникам. Но мы так же разобрали проблемы, которые решаются в процессе коммуникаций и компоненты процессов.
Я постараюсь ответить на ваш вопрос, но не уверен, что это именно то, что вы ожидаете. И заранее прошу прощения, если выйдет занудно. Компания, о которой в материале идет речь, занимается проектным бизнесом. Основной процесс один – реализация проекта. Он начинается со входящего запроса, завершается закрытием проекта в системе учета. Проект может быть реализован очень быстро, а может быть очень сложным и комплексным – тогда его движение может занимать несколько лет. На каждом этапе у нас есть набор поддерживающих бизнес-процессов. Но компания не использует BPMN, а сторонник гибких методологий, например адаптивного кейс-менеджмента, где каждый проект – это кейс, этапы – постоянные константы процесса, а конкретные задачи на этапах – переменные. То есть, в компании поддерживающие процессы называют просто "задачами".
На разных этапах подключаются разные "круги" (опять же, нестандартная история, в компании нет отделов). Итого, по мере движения проекта от первого до последнего этапа, сотрудники ведут коммуникации по проекту в Кайтен. Например, на 1 этапе мы больше обсуждаем презентацию проекта, а в середине обсуждаем сроки поставок. Если взять все коммуникации по всем сотрудникам, соединить получателей и отправителей – получится карта процесса ведения проектов As is. Понимаю, что это не линкуется с BPMN или другими методологиями, но в нестандартной системе нестандартные подходы :))
После того как мы визуализировали данные с помощью Plotly, у нас появились данные об информационной нагрузке на каждого сотрудника (определяется диаметром вершины графа), а с помощью формулы центральности по степени мы уточнили веса сотрудников в системе.
В нашем случае это дало наглядное понимание кто из сотрудников является "узким местом" c точки зрения информационной нагрузки. Но информационная нагрузка = нагрузка на процесс. Представьте, что у нас есть поток, который прерывается, пока мы не решим определенную задачу. Чтобы её решить, отправляется запрос к сотруднику, который должен её выполнить. После выполнения поток продолжает движение. По диаметру вершины графа и по положению в системе графа можно определить, на кого оказывается наибольшее информационное давление и именно эти же люди выполняют ключевые задачи в общем потоке. Далее мы можем сделать практические выводы: 1. Снизить нагрузку на сотрудника, путем: а) автоматизировать определенные задачи; б)перераспределить обязанности.
Еще одно конкретное практическое применение: в статье я писал про руководителя, который ушел из компании (он руководил кругом обеспечения и закупок). Из сообщений, которые мы спарсили, мы определили какие задачи он замыкал. Чтобы работа не "встала", часть задач по такой же логике, как я описал выше, была автоматизирована, часть мы перераспределили по сотрудникам.
Спасибо за ваше мнение. Цель материала была не обосновать читателям где тонко, а показать подход к майнингу процессов и их визуализации через социальный граф. Декомпозировать отдельный процесс и разобрать где тонко и что делать – другая задача.
Вы знаете, это хороший опыт – писать статьи (я начинающий автор), получать обратную связь, принимать во внимание замечания для того, чтобы в следующий раз быть полезнее. Поэтому, спасибо за мнение. Подумаю над тем, как делать материалы более практичными.
Прикладная польза статьи в представлении инструмента для тех, кто о нем не слышал или для тех, кто его никогда не использовал. С моей точки зрения, это один из тех рекурсивных (применимых на разных уровнях деятельности), наглядных, математически точных (фактически это вероятностный граф) инструментов, которые очень легки в использовании для анализа причинно-следственных связей. Ну и логика "меняем действия со знака "-" на знак "+" тоже очень понятная. Это помогает уйти от субъективны х представлений "что нужно сделать" к более объективным.
Я ниже прикреплю несколько примеров диаграмм, построенных не мной, но моими студентами в ВШЭ. (Это практические кейсы, реальный бизнес). Сам я тоже использую этот инструмент, конечно. Не в ежедневной практике, но когда речь идет о каким-то системных изменениях – обязательно.
p.s. "Метод критического пути заодно приплели" – выше в комментарии развернул мысль про метод критического пути и его отношение к диаграмме.
Спасибо за комментарий. Думаю, что мне стоило чуть подробнее осветить причину, по которой я предложил использовать метод критического пути как способа приоритизации контрдействий. Прикрепляю иллюстрацию, которая, на мой взгляд, довольно наглядно реконструирует диаграмму Исикавы с точки зрения сетевой диаграммы, которую я и разместил в конце статьи. Конечно же, вы правы, чтобы быть максимально объективными, нужно все действия разбить на подзадачи, каждую оценить с точки зрения временных и других ресурсных затрат и далее с помощью, например, алгоритма Флойда — Уоршелла осуществить просчет. Но я лишь обозначил верхнеуровневый принцип. Люди могут навскидку прикинуть ресурсные затраты при выполнении действий и так же могут прикинуть влияние (мощность) действий. И исходя из этого уже принять решение.
Спасибо большое за комментарий. Вы правы: с точки зрения удобства заполнения, идеальным вариантом было бы расположение блоков слева направо. С другой стороны, расположение блоков обусловлено самой структурой экономических систем. Я для студентов ВШЭ показываю такую схему, которая, мне кажется, многое объясняет.
В центре (с какой стороны мы бы не посмотрели) у нас есть экономический агент, который перерабатывает ресурс. Ресурс где-то берется (у поставщика) и кем-то потребляется (клиентом). Поставщики находятся слева с процессной точки зрения, клиенты справа (вход и выход). Чисто теоретически, можно сделать реверс, глобально ничего не изменится (что тут поток, что там поток). Но тогда он будет не слева направо, что удобно для восприятия, а наоборот. В общем, структура фреймворка – это баланс между удобством заполнения и соответствия верхнеуровневой логике взаимодействия экономических агентов в экономических системах.
К слову говоря, существует такой метод визуализации и анализа процессов как Process Chain Network. Обратите внимание, в нем тоже в центре находится экономический агент, справа клиент и слева поставщик. Это логично.
Да, информацию внутри каждого из блоков можно еще глубже декомпозировать, проанализировать и после приоритизировать расположение. Это на следующую итерацию развития инструмента. Спасибо большое за рекомендацию!
И, кстати, насчет секты – я бы не был столько категоричным. Например, мы можем взять банк "Точка" или "ВкусВилл" – у них похожий подход.
Не сочтите за спор. Но у меня есть представление о том, что такое бизнес-процессы, 4 года преподавал в ВШЭ по этой теме. И да, я ошибся, назвав BPMN методологией, а не нотацией, что вышло случайно. Пардон. Если я правильно понимаю, вы занимаетесь проектированием и анализом бизнес-процессов именно с помощью неё. У меня был опыт и проектирования и анализа, например, с помощью Comundа. Но, опять же, я не являюсь сторонником отдельных методов, нотаций или чего либо еще. Есть задача, есть способы их решения. Здесь был предложен один из. Кстати, может быть не вам, но другим читателям будет интересно изучить труды Anna Grandori https://openlibrary.org/authors/OL1071918A/Anna_Grandori – здесь очень полезно про структуру организаций и бизнес-процессы именно с точки зрения сетей взаимодействия.
Спасибо на добром слове )
Около 2 недель. 1 неделя у нас ушла на то, чтобы подобраться к данным, найти подходящий способ визуализации. 2 дня ушло на майнинг комментариев с помощью LLM, создание таблиц и остальное время – это визуализация + интерпретация. Я не аналитик, поэтому могу быть не точным в терминологии. По времени, если бы заранее знали подходящий вариант визуализации...тут несколько переменных: количество данных, которые нужно спарсить, структура данных + прогонка через LLM. На 18 000 сообщений, я выше упомянул, ушло +- 2 дня.
в нашем кейсе после проведения анализа мы: 1. Презентовали структуру процессов сотрудникам; 2. Указали кто является узким местом, предложили часть задач автоматизировать, что и было сделано.
На самом деле те данные, которые были получены, использовались процентов на 30. Потому что у нас есть данные по времени движения проектов по этапам, время упоминания сотрудников, время отклика и много чего еще. Можно построить динамическую карту по каждому проекту, чтобы увидеть временные задержки, связать из с процессами, а далее предложить способы оптимизации. Но это лишь пример.
p.s. Есть некоторые данные, которые в кейсе не были опубликованы. Например, последняя иллюстрация показывает "ожидания" к сотрудникам. Но мы так же разобрали проблемы, которые решаются в процессе коммуникаций и компоненты процессов.
Я постараюсь ответить на ваш вопрос, но не уверен, что это именно то, что вы ожидаете. И заранее прошу прощения, если выйдет занудно. Компания, о которой в материале идет речь, занимается проектным бизнесом. Основной процесс один – реализация проекта. Он начинается со входящего запроса, завершается закрытием проекта в системе учета. Проект может быть реализован очень быстро, а может быть очень сложным и комплексным – тогда его движение может занимать несколько лет. На каждом этапе у нас есть набор поддерживающих бизнес-процессов. Но компания не использует BPMN, а сторонник гибких методологий, например адаптивного кейс-менеджмента, где каждый проект – это кейс, этапы – постоянные константы процесса, а конкретные задачи на этапах – переменные. То есть, в компании поддерживающие процессы называют просто "задачами".
На разных этапах подключаются разные "круги" (опять же, нестандартная история, в компании нет отделов). Итого, по мере движения проекта от первого до последнего этапа, сотрудники ведут коммуникации по проекту в Кайтен. Например, на 1 этапе мы больше обсуждаем презентацию проекта, а в середине обсуждаем сроки поставок. Если взять все коммуникации по всем сотрудникам, соединить получателей и отправителей – получится карта процесса ведения проектов As is. Понимаю, что это не линкуется с BPMN или другими методологиями, но в нестандартной системе нестандартные подходы :))
После того как мы визуализировали данные с помощью Plotly, у нас появились данные об информационной нагрузке на каждого сотрудника (определяется диаметром вершины графа), а с помощью формулы центральности по степени мы уточнили веса сотрудников в системе.
В нашем случае это дало наглядное понимание кто из сотрудников является "узким местом" c точки зрения информационной нагрузки. Но информационная нагрузка = нагрузка на процесс. Представьте, что у нас есть поток, который прерывается, пока мы не решим определенную задачу. Чтобы её решить, отправляется запрос к сотруднику, который должен её выполнить. После выполнения поток продолжает движение. По диаметру вершины графа и по положению в системе графа можно определить, на кого оказывается наибольшее информационное давление и именно эти же люди выполняют ключевые задачи в общем потоке. Далее мы можем сделать практические выводы: 1. Снизить нагрузку на сотрудника, путем: а) автоматизировать определенные задачи; б)перераспределить обязанности.
Еще одно конкретное практическое применение: в статье я писал про руководителя, который ушел из компании (он руководил кругом обеспечения и закупок). Из сообщений, которые мы спарсили, мы определили какие задачи он замыкал. Чтобы работа не "встала", часть задач по такой же логике, как я описал выше, была автоматизирована, часть мы перераспределили по сотрудникам.
Да. Но нужно вычленить получателей / отправителей, чтобы связать данные.
Спасибо за ваше мнение. Цель материала была не обосновать читателям где тонко, а показать подход к майнингу процессов и их визуализации через социальный граф. Декомпозировать отдельный процесс и разобрать где тонко и что делать – другая задача.
Причинно-следственная связь (причина → следствие) дождественна действенно-результативной связи (действие → результат).
Вы знаете, это хороший опыт – писать статьи (я начинающий автор), получать обратную связь, принимать во внимание замечания для того, чтобы в следующий раз быть полезнее. Поэтому, спасибо за мнение. Подумаю над тем, как делать материалы более практичными.
Прикладная польза статьи в представлении инструмента для тех, кто о нем не слышал или для тех, кто его никогда не использовал. С моей точки зрения, это один из тех рекурсивных (применимых на разных уровнях деятельности), наглядных, математически точных (фактически это вероятностный граф) инструментов, которые очень легки в использовании для анализа причинно-следственных связей. Ну и логика "меняем действия со знака "-" на знак "+" тоже очень понятная. Это помогает уйти от субъективны х представлений "что нужно сделать" к более объективным.
Я ниже прикреплю несколько примеров диаграмм, построенных не мной, но моими студентами в ВШЭ. (Это практические кейсы, реальный бизнес). Сам я тоже использую этот инструмент, конечно. Не в ежедневной практике, но когда речь идет о каким-то системных изменениях – обязательно.
p.s. "Метод критического пути заодно приплели" – выше в комментарии развернул мысль про метод критического пути и его отношение к диаграмме.
Спасибо за комментарий. Думаю, что мне стоило чуть подробнее осветить причину, по которой я предложил использовать метод критического пути как способа приоритизации контрдействий. Прикрепляю иллюстрацию, которая, на мой взгляд, довольно наглядно реконструирует диаграмму Исикавы с точки зрения сетевой диаграммы, которую я и разместил в конце статьи. Конечно же, вы правы, чтобы быть максимально объективными, нужно все действия разбить на подзадачи, каждую оценить с точки зрения временных и других ресурсных затрат и далее с помощью, например, алгоритма Флойда — Уоршелла осуществить просчет. Но я лишь обозначил верхнеуровневый принцип. Люди могут навскидку прикинуть ресурсные затраты при выполнении действий и так же могут прикинуть влияние (мощность) действий. И исходя из этого уже принять решение.
Спасибо большое за комментарий. Вы правы: с точки зрения удобства заполнения, идеальным вариантом было бы расположение блоков слева направо. С другой стороны, расположение блоков обусловлено самой структурой экономических систем. Я для студентов ВШЭ показываю такую схему, которая, мне кажется, многое объясняет.
В центре (с какой стороны мы бы не посмотрели) у нас есть экономический агент, который перерабатывает ресурс. Ресурс где-то берется (у поставщика) и кем-то потребляется (клиентом). Поставщики находятся слева с процессной точки зрения, клиенты справа (вход и выход). Чисто теоретически, можно сделать реверс, глобально ничего не изменится (что тут поток, что там поток). Но тогда он будет не слева направо, что удобно для восприятия, а наоборот. В общем, структура фреймворка – это баланс между удобством заполнения и соответствия верхнеуровневой логике взаимодействия экономических агентов в экономических системах.
К слову говоря, существует такой метод визуализации и анализа процессов как Process Chain Network. Обратите внимание, в нем тоже в центре находится экономический агент, справа клиент и слева поставщик. Это логично.
Спасибо большое!
Да, информацию внутри каждого из блоков можно еще глубже декомпозировать, проанализировать и после приоритизировать расположение. Это на следующую итерацию развития инструмента. Спасибо большое за рекомендацию!