Часть 2. примеры интерфейсов
2015 год, 10-я конференция (видео в конце статьи)
Второе предприятие, о котором я хотел бы рассказать, — это корпорация «ВСМПО-АВИСМА». Здесь я постараюсь показать примеры интерфейсов: что они видят там, как работают.
«ВСМПО-АВИСМА» — это крупная металлургическая корпорация, которая является фактически мировым лидером по производству титана, первый поставщик титана для Airbus Industrie и второй — для компании Boeing.
В состав корпорации входят два завода, один из которых находится в городе Верхняя Салда, другой находится в городе Березники. Мы внедряли на заводе, который находится в Верхней Салде, и, собственно, до Березников пока дело пока не дошло.
На заводе в Верхней Салде около 15000 работающих, порядка 35 цехов, и самый большой цех — это порядка 4000—5000 человек. Понятно, что основное оборудование — это металлургическое, есть 4 специализированных ремонтных цеха, большое количество подрядчиков, которые являются отчасти дочерними структурами ВСМПО, ну и в целом где-то порядка 3000 человек ремонтного персонала.
Основные вехи проекта
02.2011 — Фаза 1. Начало работы над пилотным проектом
Разработка типовых бизнес-процессов.
03.2011 — Начало паспортизации объектов
Подготовка нормативно-справочной информации для пилотного цеха.
06.2011 — Запуск системы в работу на пилотном проекте
Обучение и запуск системы в работу на пилотном проекте:
планирование работ,
выполнение работ,
ведение журнала дефектов.
09.2011 — Завершение работ над пилотом
Сдача работ, подведение итогов, определение графика тиражирования.
10.2011 — Начало тиражирование решения
Выполнение работ по глубокой интеграции сметной программы А0 и Global-EAM.
05.2012 — Окончание тиражирования
Завершение подготовки НСИ и обучения пользователей.
06.2012 — Завершение основной фазы работ
Перевод проекта в режим поддержки.
Теперь давайте поговорим непосредственно о том, что за проект, как он развивался, и что в итоге там получили. Здесь как раз всё было «по классике», инициатором выступил технический директор, который вновь пришел на данную конкретную позицию, был новым человеком. Ну, видимо, отсюда и новый взгляд на устоявшиеся процессы. Первым делом они взялись за выбор системы и остановились на нашем решении.
Основные задачи
- Создание единой базы данных оборудования.
- Организация и контроль материально-технического обеспечения технического обслуживания и ремонтов оборудования.
- Повышение прозрачности выполнения ТОиР на предприятии.
- Получение различных отчетов по ТОиР оборудования и KPI.
- Повышение качества ТОиР оборудования.
- Уменьшение количества аварийных ремонтов.
- Сокращение простоев оборудования.
- Сетевое планирование капитальных ремонтов.
Вообще стояла задача понять, что происходит с ТОиР на предприятии, потому что оборудование постоянно отказывало, выходило из строя и так далее. Соответственно, делались какие-то разработки, инструменты для мониторинга результатов работы ремонтной службы. Ну и было активно начато, но потом в связи с изменением в руководящем составе в Верхней Салде практически свернуто, сетевое планирование капитальных ремонтов.
Сам проект начался в 2011 году, основная фаза работ заняла полтора года. За полтора года мы обучили не менее 500 человек, причём обучали мы конечных пользователей, т.е. это был фактически конвейер. Но для того, чтобы этот конвейер создать, был создан сначала пилотный проект — цех №03 (прессовый, трубо-профильный и сортопрокатный), начальник которого наиболее лояльно отнесся, сказав: «Ну ладно, давайте начнем с меня».
На октябрь 2015 года не менее 200 пользователей работает постоянно с системой, уже 150 000 объектов ремонта и, соответственно, 800000 работ.
Началось всё стандартно. Первое — это работа над бизнес-процессами и параллельно работа над паспортизацией оборудования. Дело в том, что наработки у предприятия в части паспортизации уже были, поэтому процесс фактически заключался в том, что мы эти данные перегружали из той системы, которая там была, и дальше уже с привлечением цеховых специалистов приводили в порядок, дополняли необходимыми данными. Этот процесс по пилотному проекту занял фактически три месяца, после чего система была запущена в опытно-промышленную эксплуатацию. Дальше где-то порядка двух-трех месяцев потребовалось для того, чтобы понять: да, в общем-то предприятие готово, ему это интересно, они готовы продолжать. Соответственно, был разработан график тиражирования и график обучения пользователей. Для полноценной работы системы, конечно, нужно, чтобы в цехах были соответствующие компьютеры, обученные пользователи и так далее. Естественно, мы столкнулись с тем, что далеко не все цеха были подключены, далеко не во всех цехах были оборудованы рабочие места и пользователи обладали элементарной компьютерной грамотностью. Был построен график, в рамках которого подключали цеха, организовали там рабочие места, организовывали обучение компьютерной грамотности, обучение GLOBAL. В целом обучение заняло достаточно длительный период.
Но спустя восемь месяцев с начала проекта непосредственно началось тиражирование системы на все цеха предприятия в соответствии с графиком. Это заняло почти полгода. После этого основная фаза работ была завершена, и предприятие было переведено уже в рамки поддержки, где находится и по сей день. Поскольку фактически на предприятии есть информационно-вычислительный центр, есть специалисты, которые прошли соответствующее обучение, поэтому часть работы они выполняют самостоятельно, часть согласовывают с нами, инструментарий это позволяет.
При этом собственно сама платформа позволяет и совмещать некие проектные наработки, и получать централизованное обновление из центра, потому что мы развиваем программный продукт.
Есть некая функциональная схема: оборудование, справочная информация (как правило, это чертежи, документы, спецификация, нормативы проведения работ), есть работа, есть мониторинг состояния (это осмотры, регистрация дефектов и отказов и их классификация и планирование работ по их устранению), мониторинг в части фиксации значений определённых контрольных параметров. Соответственно, есть модуль планирования регламентных работ, планирования работ нерегламентных, по отказам или по состоянию. Есть блок подготовки работ, назначения ответственных, выписка наряд-заданий, которые интегрированы со складом, склад там тоже наш. Но вначале мы интегрировались с той системой складской, которая была на предприятии. Есть отчеты, а также есть блок планирования сложных работ, работ по капитальному ремонту с использованием систем инструментов.
Рассмотрим это подробнее. Реестр оборудования. Слева — это структура всех объектов ремонта. Справа — те объекты ремонта, которые входят в данные элементы структуры. Т.е. здесь находятся, например, печи, всё технологическое оборудование (метрологическое, энергетическое оборудование и т.д.).
На каждый объект ведётся электронный паспорт либо карточка конкретного объекта, у которого есть разделы, щёлкая на них, можно получить всю исчерпывающую информацию об этом объекте. Первый раздел — это раздел характеристики, характеристики по большинству объектов занесены, по большому счету, они никаким образом не влияют на работу системы, нигде не используются, больше носят справочный характер, т.е. когда кому-то надо что-то найти, — он знает, где это можно сделать.
Для сложного большого оборудования были расписаны узлы, это фактически спецификация, к некоторым из этих узлов прикреплены чертежи, также расписаны определённые детали. Это сделано, во-первых, для удобства получения информации, во-вторых — отсюда же можно осуществлять заказ, т.е. оформление заказа на изготовление какой-то определённой детали либо на её приобретение, если это стандартное и покупное изделие.
Соответствующий раздел с дефектами (рис. 5). По дефектам есть информация о том, где, на каком объекте с уточненной информацией, а также более уточненное описание, которое вводит следующий сотрудник. Т.е., допустим, первичная информация вводится просто на основании телефонного звонка, потом пошёл кто-то более подробно посмотрел, ввёл более уточнённое описание, дальше — обязательно потребуется указать причину возникновения этого дефекта, при этом указать текстом и выбрать некую типовую причину из справочника, указать характер повреждения. А дальше у нас для этого есть соответствующие кубы настроенные в системе, есть полноценная EAM-система, которая позволяет использовать привычные инструменты сводных таблиц, вычислять многомерный анализ этой информации, черпать оттуда аналитику, делать соответствующие выводы.
Показан мониторинг на примере печи (рис. 6): здесь фиксируются, прикладываются результаты тепловизионного, термографического обследования печи и т.д. Прикладывается сам документ, все знают, где это можно найти, это используется как централизованное место хранения соответствующих документов.
Нормативы. Здесь планируют виды работ, периодичность их выполнения, а также, если на предприятии задана типовая карта (а на многие небольшие стандартные работы были разработаны типовые карты), она задается здесь и потом используется также для планирования потребностей материалов в запасных частях и в ресурсах.
График ППР — выглядит он вполне привычно: это оборудование, колонки, месяцы, вид работы и трудоёмкость на выполнение данной конкретной работы. Для графиков сделаны соответствующие печатные формы, графики рассчитываются цеховыми специалистами. Также цеховые специалисты осуществляют планирование работ на период (месяц, неделя). Для этого есть специализированный интерфейс оперативного планирования работ. Здесь мы видим перечень техработ, календарные даты, выделены выходные, продолжительные работы выделяются соответствующим образом, и также здесь видно работы, которые просрочены, работы, которые предстоит сделать в будущем, которые ещё не начаты, и работы, которые находятся в стадии фактического выполнения, т.е. по которым уже выданы наряд-задания, но не осуществлена приёмка работ.
Мастер за соответствующие периоды (день-два) видит уже перечень работ, которые не сделаны, и отсюда может сформировать наряды бригадам для выполнения этих работ. Само наряд-задание выглядит следующим образом: реквизиты, перечень операций, данные, связанные с учётом рабочего времени, с трудозатратами на выполнение этой работы, материалы.
Пооперационная трудоёмкость здесь не ведётся, но тот же «Никохим» ведёт её в полном объёме: на каждой операции, если есть норма, они ставят её. В данном случае ведётся учёт времени, сколько и какой конкретный человек отработал на данной конкретной работе. Есть плановая дата начала работы и фактическое время начала и окончания работы.
Если для работы создана типовая карта, то перечень операций автоматически переносится сюда, и работники отмечают те операции, которые выполнены, или, если что-то выполнено сверх этого, соответственно, фиксируют это.
Также здесь отмечается перечень материалов, которые были использованы в рамках конкретной работы. В электронном паспорте оборудования, помимо всех прочих разделов, есть основной раздел, связанный с работами, где можно посмотреть всю историю выполнения работ: кто выполнял, когда выполнял, что выполнял, какие запасные части, материалы были израсходованы, осуществляется анализ работ (на предмет того, что они выполнялись в срок, не в срок, просроченные работы и т.д.), оформляются акты переноса этих работ и т.д.
На предприятии пришли к пониманию того, что необходимо ввести инструмент, который позволит повысить качество выполнения работы, условно мы назвали его «чек-лист». Этот функционал реализован в системе, мы планируем в ближайшее время попытаться запустить на определённом виде оборудования.
Что он собой представляет? Первое: задается шаблон контроля качества, для которого выводится список того, что должно быть проверено, и для каждой позиции можно задать диапазон оценки: от уровня «да/нет» до «поставьте оценку». Это делается однократно, это называется шаблоном. Как только работа завершается, автоматически создаётся карта контроля качества и выдаётся задание. Его можно, во-первых, распечатать, чтобы поставить там. Но мы предлагаем и более продвинутый способ: эта часть реализована в мобильном приложении, т.е. мы предлагаем то, что подойдёт проверяющий и тут же откроет этот чек-лист на смартфоне либо планшете и занесёт эти результаты в базу.
В этой карте контроля качества, в том случае, если были замечания, нужно зафиксировать дату и согласовать дату их устранения, всеобщий перечень всех замечаний с датами доступен в виде самостоятельного отчёта, можно проверять, устранены ли они вовремя или не устранены, и можно создавать наряды на устранение этих замечаний.
По поводу KPI аналитики. В Global встроены инструменты бизнес-интеллидженс (BI), для многих вещей настроены многомерные кубы, которые позволяют выполнять анализ дефектов и отказов в различных измерениях (по цехам, по позициям, технологическим системам, по видам оборудования, по периодам, по причинам возникновения и т.д.), а затем выводить эту информацию в виде графика. Точно такие же кубы настроены для многомерного анализа затрат в различных разрезах: по работам, по трудоёмкости и т.д. Есть такие отчёты, на которые мы рекомендуем обращать внимание: например, ТОП-100 оборудования, которое имеет максимум внеплановых ремонтов и дефектов оборудования, — здесь надо принимать какие-то управленческие решения.
Процесс работы с дефектами организован следующим образом. Работу по закрытию дефекта (по его устранению) нельзя закрыть без того, чтобы не указать некие дополнительные аналитические признаки (характер повреждения, причины возникновения дефектов и т.д.), это заставляет людей думать, вводить эту информацию. Поскольку у нас теперь есть эта дополнительная аналитика, мы можем осуществлять анализ — сколько у нас, допустим, на однотипном оборудовании (поскольку оборудование классифицировано) дефектов, что чаще всего выходит из строя. Можно сделать отсюда какие-то определённые управленческие выводы: 1) либо там откровенно «косячат»; 2) либо там занимаются приписками часов; 3) либо там нужно изменять ремонтный цикл; 4) либо нужно изменять и приобретать другое оборудование.
Доступная аналитика
- Соотношение плановых/внеплановых работ во времени (по цехам, службам, видам оборудования, производствам).
- Доли плановых/внеплановых работ в общем объеме работ во времени (по цехам, службам, видам оборудования, производствам).
- Доли плановых работ в общем объеме работ, выполненных в срок во времени. (по цехам, службам, видам оборудования, производствам).
- Доли внеплановых операций в плановых работах во времени (по цехам, службам, видам оборудования, производствам).
- Количество и доля просроченных плановых работ.
- Количество и доля отказов и дефектов во времени (по цехам, службам, видам оборудования, производствам).
- Анализ простоев по единице оборудования, по цеху.
- ТОП-100 оборудования, имеющего внеплановые ремонты и дефекты.
- Многомерный анализ на основе OLAPтехнологии дефектов, причин и проявлений дефектов/отказов, стоимости работ по их устранению (по цехам, службам, видам оборудования, производствам).
- Многомерный анализ на основе OLAPтехнологии по затратам на ремонт.
- Интервалы между проявлениями дефектов.
- План-факт анализ выполнения графиков работ, графиков ППР.
На самом деле сложно отследить, пользуются аналитикой или не пользуются. Для того чтобы популяризировать эти инструменты, мы разработали соответствующий сервис, который сейчас планируем предлагать нашим клиентам: отправка отчетов по расписанию. Вам приходит файл pdf, в котором те отчеты, которые вас интересуют, т.е. вам не надо входить в систему, не надо ждать построения отчёта и т.п. Это очень удобно.
Данные системы могут анализироваться с использованием встроенных средств OLAP. Возможна настройка собственных вычисляемых показателей, управление разрезами анализа. Созданные настройки отчетов можно сохранять и публиковать для других пользователей.
Журнал Prostoev.NET № 4(13) 2017
Автор: Дмитрий Аникин, «Бизнес-технологии» (компания — разработчик системы Global-EAM)
