Случалось ли с вами, что, приготовив потрясающе аппетитное блюдо, во время дегустации вы обнаружили, что что-то перепутали с ингредиентами, например, пересолили рыбу? Это произошло со мной.
Я старший консультант по внедрению бизнес-приложений в ИТ-компании КРОК, и моя задача — обеспечить наличие всех ингредиентов, как у плиты, так и на рабочем месте, в наших проектах по внедрению озер данных и разработке.
BI-инструменты для производственных компаний.
А для этого нужно знать, на какой кухне вы готовите.
Озера данных, вероятно, не были бы столь ценными и востребованными, если бы они не позволяли интегрировать множество стандартных производственных систем и аналитических решений.
Для меня озеро — это база, платформа, если хотите, к которой добавляются аналитические решения (в моем случае — BI-дашборды), с которыми напрямую работает конечный потребитель.
При создании BI-панелей для производственных подразделений мне важно обеспечить их бизнес-ценность не только для заказчика в глобальном смысле — какого-нибудь металлургического или нефтегазового гиганта, но, прежде всего, для рядового пользователя: если пользователь получает ценность от наших панелей, то Компания также получит Эффект. Если коротко, то информационные панели, которые мы разрабатываем, можно в общих чертах классифицировать как мониторинг отклонений.
Для чего они? Любое производственное подразделение предприятия имеет набор показателей.
Для получения продукта заданного качества каждый из показателей не должен выходить за пределы допустимых значений.
Наши BI-инструменты отслеживают и проверяют метрики, а также дают рекомендации операторам о необходимых действиях в случае нарушения режима.
Панель приборов помогает оператору - оператор точнее «чувствует» процесс - технический режим соблюдается - обеспечивается необходимое качество и объем продукции = меньше аварий, дефектов, незапланированных остановок = оператор спокоен, начальник отдела доволен, компания в восторге.
Наши информационные панели также позволяют отслеживать качество данных.
Для производства это означает, что дашборды сообщают вам, какой датчик врет/шалит/полностью сдох.
Если производство работает по моделям ML, то и для них используется мониторинг качества данных.
Поэтому модель, считывая информацию о качестве данных, меняет набор параметров, которые необходимо учитывать для прогнозирования режима, или даже переключается на другую модель.
Другой пример.
Оператор видит, что какой-то технический параметр вышел за допустимые пределы, и в то же время видит, что проблем с качеством данных нет, а значит, причина действительно кроется в самом производственном процессе.
Или наоборот. Оператор видит, что какой-то параметр технического режима вышел за допустимые пределы, и в то же время видит, что этот самый параметр имеет проблемы с качеством, а значит, с высокой вероятностью есть проблемы в датчике.
В двух случаях он будет точно знать, к кому бежать: к инженеру-технологу или к инженеру-технологу.
И шансы, что ситуация будет исправлена в короткие сроки, гораздо выше, чем без приборной панели.
На самом деле этот функционал, столь важный в конечном итоге для технологов и операторов производств, — лишь верхушка айсберга всего проекта.
Основные работы по проекту кипят в зоне, обычно скрытой от наблюдателя.
Под водой размер айсберга намного больше.
Здесь происходит работа по разработке озера данных, написанию талмуда документации, поиску решений по интеграции с внутренними системами заказчика, защите проекта перед комитетом по информационной безопасности и т.д. Конечного пользователя (оператора или технолога), конечно, интересует лишь верхушка айсберга, наш дашборд с индикаторами.
Он служит неоценимым помощником в повседневной жизни, который может почувствовать неладное, когда все сигналы мнемосхемы молчат. 
Менеджер проекта, как капитан корабля, отдает свою энергию завершению основной работы проекта.
Ведь, как известно, подводная часть айсберга особенно труднопреодолима для проекта, как для корабля.
Что скрыто под водой? Как собирать данные для дашбордов?
Мы в КРОК уже давно занимаемся проблемами интеграции данных и выстраиваем аналитические решения.Мы реализуем как классические хранилища данных, так и многофункциональные платформенные решения — Data Lakes. Кроме того, мы постарались направить свой опыт на разработку продуктов — мы реализовали фреймворки на базе открытого программного обеспечения и теперь активно используем их от проекта к проекту, что позволяет нам эффективно работать с данными, следовать принципам базовой архитектуры, и более рационально использовать ресурсы дизайна.
ресурсы и команды разработчиков.
Решения для потоковой обработки данных очень актуальны для производства.
Поскольку обычно требуется показывать высокую производительность и иметь четкую масштабируемость в зависимости от количества производственных показателей в единицу времени, здесь мы обычно используем стек Hadoop + Spark Streaming для записи и расчета данных в режиме NRT, Greenplum и Clickhouse для построения данных.
витрины, приложения для доступа пользователей и аналитических данных.
Все эти компоненты могут масштабироваться горизонтально, поэтому если объем данных увеличивается при подключении дополнительных исходных систем, мы расширяем кластер и достигаем требуемых показателей производительности — обычно в течение ~1 минуты от получения данных до получения результатов расчета.
Немного о самих расчетах.
В рамках фреймворка мы разработали модуль, позволяющий вести реестры показателей с формулами и граничными значениями в пользовательском режиме.
Таким образом, вы сможете настроить необходимые показатели, а движок фреймворка выполнит все необходимые расчеты на лету.
Это удобно как команде внедрения, так и операторам, работающим с платформой.
И хотя у нашей команды уже есть свой фреймворк, наработанный годами, каждый новый проект – это вызов.
Поэтому в условиях сжатых сроков и бюджетов вполне возможно, что узкая предметная область, для которой создается дашборд, может оказаться не досконально изученной.
Для проектов, плотно вплетенных в производственный процесс, это вполне реальная ситуация.
На это есть причины: 
Во-первых, производство всегда связано с высокой секретностью.
Для того, чтобы описание процессов было передано вам, вам необходимо подписать соглашение о неразглашении.
А затем докажите, что наше решение соответствует всем требованиям информационной безопасности.
Это требует много усилий и времени.
К тому же у носителей информации, технологов и операторов мало времени на общение: то ли у них плановый ремонт, то ли авария, то ли планерка.
Трудности перевода из промышленности в российские ИТ
Следующая причина связана именно со спецификой производства.Металлургия или добыча нефти и газа используют свою собственную терминологию.
Для человека из ИТ это не всегда понятно.
С моей точки зрения, с этими функциями можно справиться, используя модель предметной области.
Ведь видение картины в целом помогает создать именно тот продукт, который нужен потребителю.
Это похоже на создание дизайн-проекта здания.
Если не знать, для чего он нужен, сложно угадать, что хочет в нем видеть заказчик.
А в проекте моя задача как аналитика — обеспечить, чтобы команда проекта понимала логику сбора и обработки информации и формат ее представления в дашборде.
Как было бы логично подойти к созданию модели предметной области, т.е.
объекта, с которым непосредственно работает дашборд? Необходимо опросить технологов и проанализировать технологическую документацию.
По результатам составить описание процесса.
И на основе этого описания реализовать функционал дашборда.
Последовательность шагов по выявлению требований (теория) Но на деле в одном из проектов мы столкнулись с тем, что заказчик не поделился описанием и документацией до подписания NDA. Это требования безопасности.
Затем встречи с технологами несколько раз отменялись из-за непредвиденных ситуаций на производстве.
Последовательность шагов по выявлению требований (практика) В результате при внедрении пилотной версии дашборда подробные требования по мониторингу отклонений были собраны буквально за один шаг в виде Excel-анкеты.
Для каждого параметра указано допустимое минимальное, максимальное значение и рекомендации в случае превышения допустимых пределов.
Этот подход кажется вполне успешным.
Особенно если представить, что по данному подразделению таким образом собиралась информация по 180 параметрам в 5 технологических режимах по 5 производственным участкам подразделения.
В результате получается своеобразный лист, который в принципе невозможно обработать вручную.
Далее для передачи всей контентной информации были разработаны алгоритмы импорта анкеты в базу данных озера и сам BI-инструмент. 
В результате, если просто просмотреть такой документ, то в нем есть тег, или другими словами параметр, его название во внутренней исходной системе заказчика DWH_100500, у него даже есть более-менее понятное название, давление уровень бака.
Но извлечь описание модели предметной области из такой анкеты не удалось.
Почему это плохо? Это стало понятно, когда после нескольких раундов тестирования, в том числе с участием технологов, мы случайно наткнулись на ошибку при формировании рекомендаций.
Некоторые параметры должны были генерировать рекомендации, когда была нарушена только одна граница: минимум или максимум.
Но в анкете все это уместилось в одну колонку.
И стало понятно, как давать рекомендацию, когда каждая из границ, как минимальная, так и максимальная, нарушается одновременно.
Пример визуализации дашборда с рекомендациями для оператора Понятно, что в конечном итоге это частично неверная информация для заказчика.
Конечно, вряд ли это приведет к каким-либо последствиям.
Так как он призван в большей степени привлечь внимание оператора к нарушению технологического режима.
И он уже принимает решение о необходимых действиях на основе набора показателей и своих наблюдений.
Но наверняка такая ошибка может вызвать некоторое раздражение.
Эту неприятность мы исправим в ходе основной, уже не пилотной, части проекта.
Но по моему глубокому убеждению, если бы мы имели в руках наглядное описание техпроцесса, не в том виде, как оно описано в технологической документации с кучей сложных непонятных терминов и 300 страницами, а простым языком и желательно диаграмму (опять же, я помню, насколько проще готовить, когда в рецепте есть изображения пошаговых действий), то такую ошибку будет и труднее допустить, и легче отловить на ранних стадиях проектов, ибо Например, во время первого тестирования.
Например, вот так: 
Как мы решали эту проблему, работая над кейсами других подразделений этой компании? Слава Богу, у нас уже было соглашение о неразглашении! Изначально я встретился с технологами, и они дали общее описание процессов.
Это помогло найти необходимую информацию в технологической документации.
Затем по результатам таких встреч и прочтения регламента я составил первоначальные анкеты.
Указали название сайта, список параметров и их допустимый диапазон.
Что нам удалось найти в документации.
Далее такая анкета была отправлена технологам по почте.
А они, в свою очередь, дополняли и редактировали его, когда им было удобно.
Так как не все, что есть в технической документации, актуально.
Последовательность шагов по выявлению требований (мой счастливый вариант) Когда заполненная анкета была у нас на руках, мы снова встретились и обсудили собранную информацию.
И они сэкономили друг другу много времени и сил.
Большим преимуществом этого опросника является то, что он учитывает четкую последовательность разделов процесса один за другим.
В результате такие анкеты оказались вдвойне ценны.
Они не только давали представление о предметной области, но и служили основой для анкет для сбора подробной информации и последующей разработки кейсов по разработке моделей прогнозного машинного обучения.
Сейчас такой опросник перекочевал в другой проект. 
Можно сказать, что мы разработали свой подход, учитывая специфику работы с компаниями-производителями.
На мой взгляд, видение предметной области, которое обеспечивает данный подход, помогает достичь целевой функциональности дашборда, а значит и удовлетворенности оператора.
Модель предметной области = Вся картина И я надеюсь, что где-нибудь за обедом с правильно приготовленной рыбой этот оператор расскажет другу из другого цеха, как здорово пользоваться нашим дашбордом, и его друг придет к нам со своим «айсбергом».
Буду рад, если вы поделитесь своим видением/инструментами/подходами для построения модели домена клиента.
Как обнаружить его болезненность и выявить все особенности процесса? Теги: #Большие данные #Визуализация данных #Инженерия данных #информационная панель #большие данные #BI #система
-
Программа Мечты Начинающего Мастера Python
19 Oct, 24 -
Выпущен Jquery Ui 1.5 Rc1
19 Oct, 24 -
Последние Новости О Tut.by
19 Oct, 24 -
Почему Я Не Занимаюсь Криптографией
19 Oct, 24
