В середине октября в рамках проходящего в Томске молодежного форума U-NOVUS мы провели воркшоп, посвященный Data Science.
Томск в принципе заслуженно пользуется славой города ученых и студентов, все-таки 15 НИИ, 9 вузов и несколько бизнес-инкубаторов — это серьезно. Поэтому мы решили пригласить к участию как студентов, так и экспертов из различных компаний.
Кейс мы давали из жизни (читай — с производства), это была задача по продвинутой аналитике на нефтехимическом предприятии.
О том, как это было — под катом.
Длился воркшоп 3 дня, именно столько времени было у команд на то, чтобы решить наши задачи и показать, что созданное ими решение это то, что на самом деле поможет отрасли, или же просто будет нести в себе ряд полезных механик, которые можно будет применить на производстве цифровой химии в будущем.
Нужно было создать рабочий сценарий, в рамках которого осуществлялись бы разработка и внедрение системы проактивного мониторинга технологического оборудования, которое мы используем на производстве.
При этом важно было учитывать, что такое оборудование логично делить на несколько типов (по критичности), поэтому подходы к их управлению и мониторингу не должны быть одинаковыми, и какой-то единый скрипт здесь бы не сработал. Также надо было принять во внимание, что на предприятии используются простейшие системы визуализации уже собранных данных, которые тоже можно использовать. Плюс мы дали в нагрузку ряд факторов — влияние состояния оборудования на маржинальность продукции; периодичность плановых ремонтов; сценарии установки дополнительных стендов в тех случаях, если базовая система мониторинга уже есть, и прочее.
И мы сразу прописали ряд рамок и ограничений, которые надо обязательно учитывать, иначе получится, что решение-то ты сделал, а применить его не сможешь, потому что про какой-то из этих факторов забыл. Это помогает, потому что такое решение должно работать на живом производстве, а там в процессе может случиться множество разных вещей.
Среди подобных факторов были:
Обязательные компоненты системы: модуль, который находит в работе оборудования аномалии (что-то греется, а не должно, что-то болтается, а должно держаться, и подобное поведение), и модуль прогнозирования, который на основе уже собранных данных сможет подобную ситуацию предсказать.
На выходе хотелось получить подробное описание решения, которое позволит, учитывая все эти условия, внедрить систему проактивного мониторинга оборудования. Можно было включать алгоритмы машинного обучения, какие-либо готовые решения и фреймворки.
А совсем в идеале (и вот зачем в составе команд были люди из бизнеса) — отметить те бизнес-процессы, на которые повлияет внедрение такой системы; возможно, даже придется вводить новые бизнес-процессы для обеспечения работы решения.
Надо отдать должное командам — они показали себя отлично. Команды были довольно разношерстные, в рамках одной могли сразу трудиться и студенты, и программисты с аналитиками данных, и руководители направлений, и директора местных компаний. И подобный состав очень сильно влиял на полученные в результате решения, мы проверяли и сразу отмечали, что у кого-то большой упор сделан на архитектурную часть, кто-то поставил во главу угла взаимодействие с пользователями, кто-то решил, что главное — это планирование и соблюдение KPI. В общем, смотришь решение — и сразу представляешь, кто именно его придумывал.
Критерии оценки у нас были довольно простыми. Главное — это практическая применимость решения на наших предприятиях. Справились почти все, из 6 представленных решений нам совсем не подошли только 2 (хотя, при выборке из 6 это треть). Но там штука была в том, что ребята или недоработали само решение, не вдаваясь в детали, либо же решение не подходило для нефтехимической отрасли. Увы, так тоже бывает — и вроде решение само по себе неплохое, задачи решает, может быть, даже масштабируется, но вот конкретно у нас совсем не применить, стек не тот. Вообще.
Остальные 4 решения показали себя на отлично, мы решили, что ребята точно понимают, что делали и что будут делать, поэтому они теперь будут участвовать в наших проектах.
Николай Ксензик, руководитель центра цифровых технологий в Томске, СИБУР ИТ.
Томск в принципе заслуженно пользуется славой города ученых и студентов, все-таки 15 НИИ, 9 вузов и несколько бизнес-инкубаторов — это серьезно. Поэтому мы решили пригласить к участию как студентов, так и экспертов из различных компаний.
Кейс мы давали из жизни (читай — с производства), это была задача по продвинутой аналитике на нефтехимическом предприятии.
О том, как это было — под катом.
Длился воркшоп 3 дня, именно столько времени было у команд на то, чтобы решить наши задачи и показать, что созданное ими решение это то, что на самом деле поможет отрасли, или же просто будет нести в себе ряд полезных механик, которые можно будет применить на производстве цифровой химии в будущем.
Задача
Нужно было создать рабочий сценарий, в рамках которого осуществлялись бы разработка и внедрение системы проактивного мониторинга технологического оборудования, которое мы используем на производстве.
При этом важно было учитывать, что такое оборудование логично делить на несколько типов (по критичности), поэтому подходы к их управлению и мониторингу не должны быть одинаковыми, и какой-то единый скрипт здесь бы не сработал. Также надо было принять во внимание, что на предприятии используются простейшие системы визуализации уже собранных данных, которые тоже можно использовать. Плюс мы дали в нагрузку ряд факторов — влияние состояния оборудования на маржинальность продукции; периодичность плановых ремонтов; сценарии установки дополнительных стендов в тех случаях, если базовая система мониторинга уже есть, и прочее.
И мы сразу прописали ряд рамок и ограничений, которые надо обязательно учитывать, иначе получится, что решение-то ты сделал, а применить его не сможешь, потому что про какой-то из этих факторов забыл. Это помогает, потому что такое решение должно работать на живом производстве, а там в процессе может случиться множество разных вещей.
Среди подобных факторов были:
- Неудовлетворительное качество собираемых данных.
- Наличие в команде для создания такой системой мониторинга специалистов с разными экспертизами — программистов, технологов производства, людей, знакомых с оборудованием, а также экспертов в области математического моделирования.
- Нежелание персонала использовать новую систему (ну а как иначе-то).
- Полное отсутствие данных для решения задач (не считается какой-то параметр, нет датчика, который бы снимал информацию, прочее).
- Если какие-то данные и есть, с ними могут быть сложности — например, не все из них оцифрованы (а работать с ними надо), хранятся они в разных форматах, какие-то вообще в пару кликов не достать, и надо проходить пару кругов согласований.
Обязательные компоненты системы: модуль, который находит в работе оборудования аномалии (что-то греется, а не должно, что-то болтается, а должно держаться, и подобное поведение), и модуль прогнозирования, который на основе уже собранных данных сможет подобную ситуацию предсказать.
На выходе хотелось получить подробное описание решения, которое позволит, учитывая все эти условия, внедрить систему проактивного мониторинга оборудования. Можно было включать алгоритмы машинного обучения, какие-либо готовые решения и фреймворки.
А совсем в идеале (и вот зачем в составе команд были люди из бизнеса) — отметить те бизнес-процессы, на которые повлияет внедрение такой системы; возможно, даже придется вводить новые бизнес-процессы для обеспечения работы решения.
Итог
Надо отдать должное командам — они показали себя отлично. Команды были довольно разношерстные, в рамках одной могли сразу трудиться и студенты, и программисты с аналитиками данных, и руководители направлений, и директора местных компаний. И подобный состав очень сильно влиял на полученные в результате решения, мы проверяли и сразу отмечали, что у кого-то большой упор сделан на архитектурную часть, кто-то поставил во главу угла взаимодействие с пользователями, кто-то решил, что главное — это планирование и соблюдение KPI. В общем, смотришь решение — и сразу представляешь, кто именно его придумывал.
Критерии оценки у нас были довольно простыми. Главное — это практическая применимость решения на наших предприятиях. Справились почти все, из 6 представленных решений нам совсем не подошли только 2 (хотя, при выборке из 6 это треть). Но там штука была в том, что ребята или недоработали само решение, не вдаваясь в детали, либо же решение не подходило для нефтехимической отрасли. Увы, так тоже бывает — и вроде решение само по себе неплохое, задачи решает, может быть, даже масштабируется, но вот конкретно у нас совсем не применить, стек не тот. Вообще.
Остальные 4 решения показали себя на отлично, мы решили, что ребята точно понимают, что делали и что будут делать, поэтому они теперь будут участвовать в наших проектах.
Николай Ксензик, руководитель центра цифровых технологий в Томске, СИБУР ИТ.