Наш телеграм канал
Будьте вкурсе новостей науки и IT
Как собрать требования к дашборду у технолога, который всегда занят

Бывало ли у вас так, что, приготовив потрясающе аппетитное блюдо, на дегустации вы обнаруживали, что что-то напутали с ингредиентами, например, пересолили рыбу? У меня бывало…

Я старший консультант по внедрению бизнес-приложений ИТ-компании КРОК, и это моя задача, чтобы как у плиты, так на рабочем месте, в наших проектах по внедрению озер данных и разработке BI-инструментов для производственных компаний все ингредиенты были на месте. А для этого нужно знать, на какой кухне ты готовишь.

Озера данных, наверное, не были бы так ценны и востребованы, если бы не позволяли «сдруживать» разнообразные стандартные производственные системы и аналитические решения. Для меня озеро - это база, платформа, если хотите, к которой прирастают аналитические решения (в моем случае - BI-дашборды), с которыми непосредственно работает конечный потребитель.

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

Если кратенько описывать, то дашборды, которые мы разрабатываем, можно обобщенно отнести к направлению мониторинга отклонений. Для чего они предназначены?

В любом производственном подразделении предприятия есть набор показателей. Для получения продукта заданного качества каждый из показателей не должен выходить за границы допустимых значений.

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

Дашборд помогает оператору – оператор точнее «чувствует» процесс – техрежим соблюдается – требуемое качество продукции и ее объем обеспечиваются = меньше аварий, брака, неплановых остановок = Оператор спокоен, начальник отделения доволен, Компания в восхищении.

Еще наши дашборды умеют мониторить качество данных. Для производства это означает, что дашборды подсказывают, какой датчик врет/шалит/совсЭм умер.

Если производство работает по ML-моделям, то мониторинг качества данных используется еще и для них. Так модель, считывая информацию о качестве данных, изменяет набор параметров, которые нужно учитывать для прогнозирования режима, или вовсе переходит на другую модель.

Другой пример. Оператор видит, что какой-то параметр техрежима вышел за допустимые границы, и одновременно видит, что по качеству данных проблем нет, значит причина реально в самом производственном процессе.

Или наоборот. Оператор видит, что какой-то параметр техрежима вышел за допустимые границы, и одновременно видит, что у этого же параметра проблемы по качеству, значит проблемы с высокой вероятностью в датчике.

В двух случаях он точно будет знать к кому бежать: к технологу или инженеру АСУТП. И шансы, что ситуация будет исправлена в сжатые сроки куда выше, чем без дашборда. В действительности, этот функционал, который в конечном итоге так важен технологам и операторам производства, для целого проекта всего лишь верхушка айсберга.

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

Конечный потребитель (оператор или технолог), разумеется, интересуется только верхушкой айсберга, нашим дашбордом с показателями. Он служит ему бесценным помощником в повседневной жизни, который может почувствовать неладное, когда все сигналы на мнемосхеме молчат.

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

Что же там скрыто под водой? Как собрать данные для дашбордов?

Мы в КРОК уже давно занимаемся задачами интеграции данных, построением аналитических решений. Внедряем как классические хранилища данных, так и многофункциональные платформенные решения - Озера данных. Кроме того, мы постарались свой опыт направить и в сторону продуктовой разработки - реализовали фреймворки на основе ПО с открытым исходным кодом, и теперь активно их применяем от проекта к проекту, что позволяет эффективно работать с данными, следовать принципам заложенной архитектуры, более рационально использовать проектные ресурсы и команды разработки.

Для производства очень актуальны решения потоковой обработки данных. Поскольку обычно требуется показывать высокую производительность, иметь понятную масштабируемость в зависимости от количества показателей производства в единицу времени, мы здесь обычно применяем стек Hadoop + Spark Streaming для регистрации и расчетов данных в режиме NRT, Greenplum и Clickhouse для построения витрин данных и доступа пользователей и аналитических приложений к данным. Все эти компоненты могут масштабироваться горизонтально, поэтому, если объемы данных возрастают с подключением дополнительных систем-источников, мы расширяем кластер и добиваемся нужных показателей производительности - обычно укладываемся в ~1 мин от получения данных до получения результатов расчетов.

Немного о самих расчетах. В составе фреймворка мы разработали модуль, который позволяет вести в пользовательском режиме реестры показателей с формулами и пограничными значениями. Таким образом, можно настроить необходимые показатели, и движок фреймворка выполнит на лету все необходимые расчеты. Это удобно как для команды внедрения, так и для операторов, работающих с платформой.

И хотя наша команда уже имеет свой наработанный годами фреймворк, каждый новый проект это challenge…

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

Для проектов, плотно вплетающихся в производственный процесс, это вполне реалистичная ситуация. Для этого есть свои причины:

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

Кроме того, носители информации, технологи и операторы, не особо располагают временем для общения: то у них плановые ремонты, то авария, то планерка…

Трудности перевода с отраслевого на русский айтишный

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

Это похоже на создание дизайн-проекта здания. Если вы не знаете, для чего оно нужно, сложно угадать, что хочет видеть в нем заказчик. И в проекте это моя задача как аналитика обеспечить, чтобы проектная команда понимала логику сбора и обработки информации и формат ее представления в дашборде.

Как было бы логично подойти к созданию модели предметной области, т.е. того объекта, с которым непосредственно работает дашборд? Нужно опросить технологов и проанализировать документацию по процессу. По результатам составить описание процесса. И уже с опорой на это описание реализовывать функционал дашборда.

Последовательность шагов по выявлению требований (теория)
Последовательность шагов по выявлению требований (теория)

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

Последовательность шагов по выявлению требований (практика)
Последовательность шагов по выявлению требований (практика)

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

Подход кажется вполне удачным. Особенно, если представить, что для этого подразделения таким образом собиралась информация для 180 параметров в 5 технологических режимах для 5 производственных участков подразделения. Получилась эдакая простыня, которую вручную в общем-то не обработаешь.

Дальше для переноса всей содержательной информации были разработаны алгоритмы импорта анкеты в БД озера и собственно BI- инструмент.

В итоге, если просто, глазами пробежаться по такому документу, то вот в нем тег, или другими словами, параметр, его имя во внутренней системе-источнике заказчика DWH_100500, у него есть даже более или менее понятное название, уровень напорного бака. Но вытащить описание модели предметной области из такой анкеты не получилось.

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

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

Пример визуализации дашборда с рекомендациями для оператора
Пример визуализации дашборда с рекомендациями для оператора

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

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

Например, так:

Как мы решили эту проблему при проработке кейсов для других подразделений этой компании? Слава Богу, у нас уже был NDA!

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

В них указывались наименование участка, перечень параметров и их допустимый диапазон. То, что удалось найти в документации. Дальше такая анкетка отправлялась технологам по почте. И они в свою очередь, ее дополняли и редактировали, когда им это было удобно. Так как не все, что есть в техдокументации, актуально.

Последовательность шагов по выявлению требований (мой счастливый вариант)
Последовательность шагов по выявлению требований (мой счастливый вариант)

Когда на руках была уже заполненная анкета, мы еще раз встречались и проговаривали собранную информацию. И экономили кучу времени и сил друг друга.

Большим преимуществом этой анкетки является то, что она учитывает четкую последовательность участков процесса друг за другом. В итоге такие анкеты оказались ценны вдвойне. Они давали не только представление о предметной области, но и послужили основой для анкет сбора детальной информации и последующей проработки кейсов по разработке прогнозных моделей машинного обучения. Теперь уже такая анкета перекочевала в проект в другой проект.

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

Модель предметной области = Целостная картинка
Модель предметной области = Целостная картинка

И я надеюсь, что где-то за обедом с правильно приготовленной рыбкой, этот оператор расскажет товарищу из другого цеха, как здорово использовать наш дашборд, и его товарищ придет к нам со своим «айсбергом».

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