Визуализация угольных процессов – шаг 1

Предисловие: С наступающим днем Шахтера! Эта промышленность сейчас переживает не легкие времена и я в ней работаю.

В этой небольшой статье расскажу, как заменил Power BI (далее по тексту PBI) на импортозамещённое решение, чуть не написав заново свой BI с бэкджеком и графиками.

Немного о контексте.

В 2019 пришел трудиться в аналитики угольного предприятия. На базе системы навигации «АСК» создал с нуля новую систему диспетчеризации с адаптацией под подрядчиков угольных разрезов и оптимизации многих действий. В итоге внедрив решение диспетчеризации и аналитики на 19 угольных участках (больших и маленьких) разных предприятий, меня за хантила, маленькая, но очень перспективная угольная компания. И вот о том, как делая доступным визуализацию производственной информации в любом «утюге» я расскажу ниже.

В мое "распоряжение" попала компания с 3-я участками работ и 100 единиц Горнодобывающего оборудования (Самосвалы, Экскаваторы, Бульдозеры). Система навигации от компании «Союзтехноком», 1с:ЕРП + УАТ.

Так как из предыдущего опыта я не смог применить решения, которые я использовал, это было связано со сменой вендера навигационных(телематических) данных и не готовности УАТ предоставлять достоверные данные для автоматической отчетности. В результате чего стало необходимо освоить «СТК» и внедрить УАТ.

Те, кто работал с «СоюзТехноком» знают, что забрать данные из этой программы для аналитики ОООЧень сложно. Есть только один вменяемый путь, настроить заранее пред настроенные отчеты, что бы они по расписанию выгружались в какую-нибудь папочку Widows. Так как раньше не работал в PBI, пару месяцев изучал этот инструмент и выбирал те отчеты из навигации, которые дают максимум оперативной информации в разрезе каждой операции производства. Ну и само собой был выбран самый большой отчет с кучей информации – это Хронометраж.

Этот Хронометраж выгружался в ексель и данные в нем были скомпонованы как фарш из мясорубки. Куча объединённых ячеек и сырых данных.

С первой проблемой справился при помощи Power Qwery, со второй создания дополнительных вычисляемых полей и быстрых мер, которые говорили, берем ли данную операцию рейса для анализа объемов перевозки или экскавации и можем ли доверять этим данным.

На выходе получил неплохой отчет с кучей измерений, выводов и готовил систему подсказок и влияния на производственный результат.

Но случилось, то что случилось PBI ушел из нашей страны, и моя идея о доступности всех отчетов в телефоне, планшете и любом утюге всех участников производственного процесса ушла вместе с ней.

Не буду расписывать как я 2 месяца на Django писал сайт с ответами на вопросы жизни вселенной и всего такого так как это было долго, решение было не таким красивым, так как дизайнер из меня не очень.

Разработал один триггер: В зоне экскаватора.

Суть триггера – Фиксируется время прибытия в гео-зону или определённый радиус в метрах экскаватора, который грузил самосвал.

Цель триггера – определение реального продолжительности времени нахождения под экскаватором. А также оценка наличия или отсутствия профицита/дефицита самосвалов

Формула применение триггера – Превышение нормы времени ожидания погрузки = Интервал времени между срабатывания триггера и первой ложки погрузки – Норма времени установки под погрузку – норма ожидания погрузки (из модели производства)

Преимущества – автоматическая фиксация простоя (Ожидание погрузки) не взирая на действия самосвалистов и диспетчеров.

Не взирая на рыночную ситуацию с BPI и продолжая процесс до настраивания УАТа и бизнесс-процессов диспетчеризации, продолжал искать решение, которое будет способствовать повышению эффективности предприятия и снижению себестоимости через доступность на утюгах и визуализацию.

За время поиска решений я повидал многое. Видел кучу неадекватка со словами: дайте нам 100 тыс, мы вам построим пример отчета, и вы поймете, как это работает. В одну из сессий переговоров даже собрали каких-то 15 человек, которые что-то рассказывали, но не говорили суть и как их BI система умеет собирать данные. Только общие слова.

И как говорится, что дорога возникает под ногами идущего и после очередного закрытия месяца я всё-таки решил не платить, а сам грызть гранит науки и выбор пал на DataLens от Яндекса. Что бы максимально быстрой войти в контекст, обратился к сообществу в Telegramm и мне быстро и качественно помог @gennadymoscow за 2 сессии консультации я практически перешел от PBI к yDL.

Скажу сразу, что плохо в yDL:

1. Все обучалки по yDL, что я видел по аналитике продаж, яндекс.метрики и ничего про производство;

2. Не умеет соединять данные(таблички) между 2-х разных источников данных;

3. Не умеет и принципиально не будет собирать данные по API (ответ разрабов yDL).

Решить эту проблему можно при помощи озер данных, но мне бы для начала попробовать и без больших вложений.

Имея на руках доступ к SQL системы навигации «СТК» я схватился за голову и задавал себе вопрос: как это все обрабатывать?..

Основные проблемы:

1. Очень много таблиц;

2. Не понятно, как собирать нужные данные, из которых собирать отчеты;

3. Понятно, что Планирование (Плановые показатели) буду прикручивать синей изолентой.

Так как в основном отчете по хронометражу есть большая куча вычисляемых параметров, я чуть было не отчаялся и был практически готов написать на python транслятор данных из xls файлов в какую-нибудь SQL табличку на арендованных серверах, что бы все было доступно для yDL.

По общавшись техподдержкой убедил их провести следующую операцию:

1. Взять отчет хронометража;

2. Запускать его с определенными параметрами 1 раз в 15-30 минут;

3. По готовности отчета, обновлять данные в одной SQL табличке.

Несколько часов ожидания, и мне дали вожделенную мной табличку. И магия началась.

Рассказывать, как делать дашборды не вижу смысла, так как обучалок много и сообщество отзывчивое. Лишь подкачу камушек в идеологию yDL. После создания парочки дашбордов у меня скопилось столько чартов (диаграмм) в плоской папочке, что если их не именовать по всем правилам задания имен переменных в программировании, запутаться через некоторое время очень просто.

В итоге имеем дашборд с кучей графиков и табличек, которые в свою очередь все интерактивны. Дашборд доступен мобильно и на текущий момент имеет актуальную информацию каждые 15-30 минут, что более чем достаточно для оперативного управления производством. Производственники и руководство пользуется всем этим и быстро принимает решение опираясь на реальные данные.

Конечно еще предстоит прикрутить еще много табличек, и много данных, но как MVP версия работает идеально и достаточно быстро.

P.S. если интересно, буду продолжать.