Привет! В рамках нашего цикла постов про дашборды в СИБУРе и их практическую пользу для компании не смогли обойти стороной M2F – это обслуживание и ремонты, туда входит множество метрик из различных направлений бизнеса. Это могут быть метрики, которые показывают загруженность ремонтного персонала на предприятии или метрики затрат, например, «Поддержание основных фондов», а также имеется большой блок «Надежность».
В общем и целом, это широкий спектр метрик, выделенных в качестве наиболее приоритетных, с точки зрения влияния на бизнес. Анализ этих метрик помогает бизнесу наиболее эффективно управлять имеющимися ресурсами, а также «подсвечивать» проблемы в самом бизнес-процессе.
Чуть не забыл представиться! Меня зовут Миша Делендик, и я как раз отвечаю в СИБУРе за разработку дашбордов по сквозным процессам M2F. В этом материале подробнее расскажу о том, как мы анализируем различные части процесса, чтобы оборудование работало без, кхм, нештатных ситуаций.
Уровни дашбордов
В M2F выделен каскад дашбордов, сейчас там 6 уровней, начиная от Начальника ТОиР (техническое обслуживание и ремонты) на самих предприятиях и заканчивая курирующим Членом Правления, который отвечает за все направление, например, производство.
У нас реализовано и выведено в опытно-промышленную эксплуатацию (ОПЭ) 2 дашборда: “Начальник ТОИР” и “Руководитель СУОФ”. “Главный инженер” и “Менеджер процесса M2F” планируются к выводу.
В дашборде “Начальник ТОИР” мы выводим более узконаправленные метрики, которые завязаны именно на анализе эффективности выполнения работ на предприятиях: есть плановая и фактическая загрузка ремонтного персонала, есть метрика бэклог, срочные и сверхурочные работы.
Каскад устроен таким образом, что пользователь, находясь на каком-то одном дашборде, может кликнуть по оглавлению, расположенному слева от дашборда, и перейти на другой дашборд, который будет наследовать, выставленные на прошлом дашборде, фильтры. Подобная навигация сделана в первую очередь для удобства наших пользователей, чтобы им не приходилось тратить время на поиски другого, интересующего их дашборда из каскада. А наследование фильтров помогает не запутаться при таком переходе и смотреть аналогичный срез данных только по метрикам другого уровня.
В дашборде “Руководитель СУОФ” метрик в разы больше и они разбиты на логические блоки. Например, есть блок “Затраты”, куда попадают различные статьи затрат, в том числе и затраты на персонал. Отдельно выделена и численность персонала. Есть блок «Статистика по выполненным работам» и блок «Эффективность месячного планирования», который касается выполнения работ, планов по этим работам, отклонений и так далее.
Также у нас есть блоки с кросс-функциональными метриками, т.е. метриками, которые рассчитываются в рамках других сквозных процессов. Такие метрики мы забираем к себе на дашборд, иногда немного адаптируя под нашу специфику. Например, блок “Обеспечение МТР” включает в себя кросс-функциональные метрики из S2P, такие как: «Срочные закупки МТР» и «Своевременность поставки к остановочным ремонтам».
В M2F метрики очень разносторонние, они демонстрируют в целом все, что связано с обслуживанием, ремонтами и надежностью оборудования.
По дашборду Руководитель СУОФ, на текущий момент реализованы не все метрики, но большая часть выведена. Можно сказать, что это некий MVP с высокой степенью готовности, поэтому мы решили уже на этом этапе дать пользователям возможность «потрогать» дашборд и начать внедрять в свои рабочие процессы. На этом этапе один из важнейших «поинтов» — это обратная связь от пользователей, за счет которых мы формируем бэклог развития дашбордов.
Аудитория дашбордов
Дашборд “Начальник ТОИР” является самым посещаемым дашбордом в СИБУРе, месячная аудитория – порядка 650 пользователей, из них 450 целевых.
Как измеряем это показатель? Мы сформировали список подразделений, должностей и пользователей, которые должны по процессу в компании использовать какой-то конкретный дашборд каскада в своей повседневной работе. После этого начали отслеживать посещения каждым из этих пользователей и вывели эти посещения в количественном эквиваленте на другой дашборд, мы называем его «Дашборд приживаемости». На нем мы мониторим, во-первых, количество посетителей дашборда, как целевых, так и нецелевых, во-вторых, показатель приживаемости, т.е. отношение целевых пользователей, посетивших дашборд, к общему количеству целевых пользователей.
Что с эффективностью?
Приживаемость показывает, что дашборды востребованы, потому что 650 человек для дашборда – достаточно много. Люди заходят, пользуются, например, в еженедельных ритуалах. Дашборд находит свое применение и в подготовке к этим ритуалам, то есть ответственные за те или иные участки заблаговременно мониторят показатели в своей зоне ответственности, выявляют причины отклонений, в случае их наличия, а также вырабатывают корректирующие действия. Для поиска возможных причин у нас практически для каждой метрики есть детализированный дашборд, где есть более полная информация.
Например, предприятия выставляют нужные фильтры и могут провалиться в детальный дашборд, кликнув по наименованию метрики, в котором уровень детализации данных уже выше и в нем содержится информация, например, вплоть до табельного номера сотрудника или номера заказа. Благодаря этому пользователи могут отследить, на каком этапе и что пошло не так, почему, например, метрика попала в красную зону.
Но здесь есть и другая сторона медали, например, на этапе разработки и проработке методологии мы могли не учесть какие-то моменты, которые в последствии раскрываются при общении пользователя с дашбордом. И это вполне нормально. Пользователь иногда может правильнее интерпретировать полученную информацию, потому что каждый день «варится» в этих процессах и знает все «подводные камни» и исключения из правил. При поддержке наших пользователей мы пытаемся отлавливать такие моменты и вносить корректировки. Так дашборд развивается исходя из пользовательского опыта и внутренних изменений в компании, для нас дашбордизация сквозных процессов является продуктом.
Дашборд «Начальник ТОиР» был выведен в опытно-промышленную эксплуатацию в конце 2021 года, и во втором квартале 2022 мы реализовывали по нему более 14 доработок с точки зрения повышения качества расчета метрик и UI дашборда на основании фидбека от пользователей.
Влиять на формирование бэклога развития может не только фидбек от пользователей, но еще и изменения самих бизнес-процессов компании. Процессы тоже не стоят на месте, а при их изменении необходимо перестраивать и логику расчета витрин под дашбордом.
Обновления и поддержка
Касательно обновлений - какие-то критичные вещи мы берем в работу сразу, вне всякого приоритета, например, если происходят изменения в учетных системах, в частности, меняется логика заполнения каких-либо бизнес-сущностей или изменения затрагивают структуру объектов в системах-источниках. В большинстве случаев, конечно, мы заранее знаем о новых релизах и составе изменений, что позволяет своевременно запланировать эти работы в предстоящем спринте. Но всегда бывают исключения.
Все остальные, заранее проработанные задачи по улучшениям дашбордов, кладем в наш бэклог и реализовываем в рамках выставленных приоритетов. Так же стараемся распараллелить задачи развития, уже реализованной функциональности, и задачи по разработке новой.
Изменения выкатываем все по мере готовности.
Касательно поддержки – на текущий момент мы находимся на этапе ОПЭ, т.е. функцию поддержки выполняет команда разработки. Под поддержкой я сейчас подразумеваю поддержку пользователей.
Чтобы всем участникам этого процесса было понятно с кем и как коммуницировать, мы сделали на дашборде виджет в виде конвертика, клик по которому открывает шаблон письма в Outlook, и пользователь может расписать там свой вопрос или боль.
Далее это письмо уходит на общий почтовый ящик команды разработки, который ежедневно обрабатывается. Этот почтовый ящик, кстати, один из источников формирования нашего бэклога.
Немного про то, что под капотом
Раньше все данные собирались ручками, консолидировались в одном Excel-файле и там же считались метрики. Разумеется, на это уходила уйма времени и человеческих ресурсов.
Сейчас же мы имеем полностью автоматизированный сбор данных - выстроенные интеграции хранилища данных с большей частью внутренних систем, настроенные пайплайны обработки данных и все остальное, жизненно необходимое для автоматизации процесса работы с данными.
В качестве СУБД у нас Vertica, Airflow как оркестратор, а дашборды пилим в Tableau. Ну и, разумеется, git, Jira и Confluence – без них никуда.
Систем-источников в компании тоже уйма, но в нашем стриме это в основном SAP и различные его модули.
Порой проскакивают и небольшие ручные источники, по которым процесс загрузки в хранилище также автоматизирован.
Про юзабилити
Ранее я уже упомянул о переходах внутри каскада, детальных дашбордах, наследовании фильтров и «конвертике». Помимо этого, для каждого дашборда есть своя инструкция с описанием навигации по дашборду и его функционалу, которая так же, как и «конвертик», сделана в формате виджета на дашборде. Ещё из полезного — для каждой метрики у нас есть краткое описание прямо в тултипе, который раскрывается при наведении курсора на значение метрики. Сделано это для понимания того, зачем нужна эта метрика, что она показывает и как считается. Если этого описания пользователю будет недостаточно, то внизу также есть ссылка на детальное описание метрики, нажав на которую, мы попадаем на страницу в Confluence с детальным описанием по каждой метрике.
В перспективе планируем вывести еще индикаторы качества данных.
Если вам интересна эта тема, будет делиться информацией о доработках дашбордов и в будущем.