Комментарии 13
Ощущение, что делалось ради красивой картинки для презентации руководству. Всё то же самое сделал бы аналитик по бизнес-процессам, только в конце еще бы обосновал где и почему "тонко" и главное - что делать. И заняло бы это от силы пару недель, если он один.
Если в качестве массива данных копроративную электронную почту загрузить?
Пытаюсь понять практическое применение.
Можете привести любой реальный или потенциально исполняемый кейс улучшения бизнес-процессов на основании результатов этой работы?
Я постараюсь ответить на ваш вопрос, но не уверен, что это именно то, что вы ожидаете. И заранее прошу прощения, если выйдет занудно. Компания, о которой в материале идет речь, занимается проектным бизнесом. Основной процесс один – реализация проекта. Он начинается со входящего запроса, завершается закрытием проекта в системе учета. Проект может быть реализован очень быстро, а может быть очень сложным и комплексным – тогда его движение может занимать несколько лет. На каждом этапе у нас есть набор поддерживающих бизнес-процессов. Но компания не использует BPMN, а сторонник гибких методологий, например адаптивного кейс-менеджмента, где каждый проект – это кейс, этапы – постоянные константы процесса, а конкретные задачи на этапах – переменные. То есть, в компании поддерживающие процессы называют просто "задачами".
На разных этапах подключаются разные "круги" (опять же, нестандартная история, в компании нет отделов). Итого, по мере движения проекта от первого до последнего этапа, сотрудники ведут коммуникации по проекту в Кайтен. Например, на 1 этапе мы больше обсуждаем презентацию проекта, а в середине обсуждаем сроки поставок. Если взять все коммуникации по всем сотрудникам, соединить получателей и отправителей – получится карта процесса ведения проектов As is. Понимаю, что это не линкуется с BPMN или другими методологиями, но в нестандартной системе нестандартные подходы :))
После того как мы визуализировали данные с помощью Plotly, у нас появились данные об информационной нагрузке на каждого сотрудника (определяется диаметром вершины графа), а с помощью формулы центральности по степени мы уточнили веса сотрудников в системе.
В нашем случае это дало наглядное понимание кто из сотрудников является "узким местом" c точки зрения информационной нагрузки. Но информационная нагрузка = нагрузка на процесс. Представьте, что у нас есть поток, который прерывается, пока мы не решим определенную задачу. Чтобы её решить, отправляется запрос к сотруднику, который должен её выполнить. После выполнения поток продолжает движение. По диаметру вершины графа и по положению в системе графа можно определить, на кого оказывается наибольшее информационное давление и именно эти же люди выполняют ключевые задачи в общем потоке. Далее мы можем сделать практические выводы: 1. Снизить нагрузку на сотрудника, путем: а) автоматизировать определенные задачи; б)перераспределить обязанности.
Еще одно конкретное практическое применение: в статье я писал про руководителя, который ушел из компании (он руководил кругом обеспечения и закупок). Из сообщений, которые мы спарсили, мы определили какие задачи он замыкал. Чтобы работа не "встала", часть задач по такой же логике, как я описал выше, была автоматизирована, часть мы перераспределили по сотрудникам.
Кирилл, прошу меня простить, но то, что я прочитал и понял - это кошмар и ужас. Ваша компания по своему принципу работы напоминает секту. Переназвать устоявшиеся термины, смешать в кучу и назвать это "гибкими методологиями" - вот что получилось.
Бизнес не просто так пытается выстраивать бизнес-процессы. У вас же всё подменено даже не ролями, а конкретными личностями. Представляю, какие в этой каше дикие перегрузки испытывают сотрудники.
Нет желания дальше раскрывать сказанное - это очень долго. Для начала: BPMN - это не методология, это нотация. Если в вашей компании не понимают разницы, то дальше просто нет смысла в диалоге
Если что, есть методологии поиска узких мест. Но ими можно пользоваться, если есть понимание бизнес-процессов. И там анализируются разные составляющие бизнес-процессов. Количество коммуникаций между людьми - лишь один из них
Не сочтите за спор. Но у меня есть представление о том, что такое бизнес-процессы, 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. Есть некоторые данные, которые в кейсе не были опубликованы. Например, последняя иллюстрация показывает "ожидания" к сотрудникам. Но мы так же разобрали проблемы, которые решаются в процессе коммуникаций и компоненты процессов.
Кирилл, спасибо за то, что делитесь наработками, публикуя статью.
Мне очень интересно и полезно было почитать про такой способ анализа процессов. Это расширяет кругозор простых бизнес-аналитиков, не знакомых пока с методами выгрузки и анализа инфы из таск-трекеров.
Спасибо огромное за информацию!
Продолжайте ваши изыскания и эксперименты, жду новых статей, подписалась на вас.
Майнинг бизнес-процессов и визуализация данных с помощью Neo4j, Plotly и GPT