2015 год, 10-я конференция

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

---

Наша компания сравнительно молодая, около 8 лет, но мы занимаем ведущие позиции на IT-рынке Казахстана. Мы продуктовая компания, имеем собственную продуктовую линейку. У нас есть офисы в Астане, в Алмате, в Караганде, с прошлого года мы выходим на рынок Российской Федерации, и также у нас есть проекты в Европе.

Наш продукт, о котором я сегодня расскажу, это программное обеспечение Dynamics EAM. Из названия понятно, что эта система относится к системе управления активами предприятия. Система класса ЕАМ обычно есть в двух решениях: в составе комплексных ERP-систем и как отдельные ЕАМ-системы. Как показывает практика, те модули, которые входят в состав ERP-систем, имеют ограниченную функциональность и ограниченные возможности по развитию системы. Наша система является самостоятельной, но имеет опыт интеграции с популярными ERP-системами (SAP, «1C», «Фаворит»).

Система управления Dynamics EAM обеспечивает решение полного комплекса задач управления ТОРО:

1. Содержание и предоставление актуальной информации об объекте и его техническом состоянии.
2. Ведение электронного паспорта объекта с историей проведенных мероприятий в ТОРО.
3. Учет наработки оборудования и применение алгоритмов для прогнозирования и планирования необходимости проведения мероприятия ТОРО с оповещением.
4. Учет материалов и запасных частей и их своевременный закуп.
5. Повышение оперативности реагирования сотрудников за счет мобильных приложений.
6. Автоматизация расчета требуемого количества материала и квалификации сотрудников.
7. Планирование и контроль работ ТОРО на всех уровнях предприятия.
8. Учет рабочего времени ремонтных бригад.
9. Учет выполненных работ подрядными организациями.
10. Обмен сведениями с другими информационными системами предприятия для обеспечения актуальности информации и исключения необходимости ручного ввода данных.

Проект №1. НИОКР АСУ «Магистраль»

Первый проект, о котором мы хотели рассказать, это НИОКР АСУ «Магистраль». Он сейчас еще в работе. НИОКР — это научно-исследовательские опытно-конструкторские работы, то есть это комплекс работ. Заказчик — АО «НК «КТЖ» — наша национальная железнодорожная компания, то есть аналог РЖД, генеральным подрядчиком является «Транстелеком», и основной объект автоматизации — это дистанция пути и центральный аппарат соответственно. Их основная задача — это ремонт и техническое обслуживание объектов путевого хозяйства и искусственных сооружений: рельсы, шпалы, скрепления, земляные полотна, мосты, светофоры — то есть полностью железнодорожные пути.

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

Основные направления проекта

1. Диагностика для определения фактического состояния пути
   • дефектоскопия;
   • путеизмерение.
2. Бизнес-процессы управления ТОРО/ТОиР
   • аудит;
   • реинжиниринг.
3. Автоматизация управления ТОРО/ТОиР
   • внедрение системы автоматизации;
   • обеспечение информационного обмена между используемыми системами.

Одна из первых задач — это повышение уровня диагностики для определения фактического состояния объектов. В рамках проекта были поставлены новые средства диагностики. В частности, была создана уникальная разработка, совмещающая оба метода диагностики — дефектоскопию рельсов, которую делает компания «Радиоавионика» (Санкт-Петербург), и путеизмерение с помощью оборудования компании «Прогресс» (Москва), — совмещенный вагон дефектоскоп-путеизмеритель.

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

Помимо этого, естественно, используются и другие как мобильные, так и съемные средства диагностики.

Бизнес-процессы по ТОРО проходят три стадии: аудит, инжиниринг и автоматизацию. Почему была выбрана такая последовательность? Без диагностики бизнес-процессов невозможно выявить проблемные места, и при внедрении ТОРО автоматизируются неактуальные или неэффективные процессы. Без реинжиниринга бизнес-процессов система будет работать «по-старому», что не позволит добиться значительного увеличения эффективности работы предприятия в целом. Проблемы могут всплывать по ходу автоматизации, что затрудняет и затормаживает процесс самой автоматизации, т.к. приходится постоянно перенастраивать программу.

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

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

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

Результат аудита

1. Описаны текущие бизнес-процессы «как есть».
2. Все участники проектной команды владеют необходимой информацией для следующего этапа.
3. Определены риски в текущих бизнес-процессах и их влияние на деятельность компании в целом.
4. Определены узкие места в деятельности.
5. Определены приоритетные бизнес-процессы для оптимизации и инжиниринга.
6. Определены направления для инжиниринга.

Результат реинжиниринга

1. Разработаны рекомендации по оптимизации бизнес-процессов.
2. Разработаны предложения по устранению рисков.
3. Описаны бизнес-процессы «как должно быть».
4. Описаны предложения по оснащению предприятия.
5. Описаны предложения по оптимизации зон ответственности.
6. Определена оценка эффективности для каждой инициативы.
7. Определен план задач для реализации разработанных инициатив.

Как уже было сказано, мы использовали инструмент ARIS. Было проанализировано 278 документов, составлено моделей на этапе аудита — около 640, на этапе реинжиниринга — 548 (меньше — потому что были выявлены процессы, которые уже неактуальны, или же процессы были оптимизированы, в связи с этим и количество моделей уменьшилось), более 90 предложений по доработке нормативно-правовых документов и более 80 рисков было выявлено и предложено решение по ним.

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

Ценности для каждого уровня организации по внедрению системы управления ТОРО/ТОиР

1. Уровень руководства (стратегия)
   • Контроль фактического расхода ресурсов;
   • Контроль фактических затрат (в стоимостном выражении);
   • Получение актуальной информации для управления.
2. Уровень служб, отделов, ОГМ, цеха
   • Мониторинг текущего состояния;
   • Планирование заказов и нарядов;
   • Контроль выполнения мероприятий ТОРО.
3. Уровень бухгалтерии
   • Списание материалов;
   • Расчет затрат на заказ-наряд.
4. Ремонтные бригады
   • Регистрация факта выполнения работ;
   • Регистрация фактически потраченных материалов.

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

Ключевые решения, которые были применены, — это интеграция с измерительно-диагностическим оборудованием, использование мобильных устройств, интеграция с ERP-системами, соответственно, автоматизация функции управления TOРO и создание ситуационного центра.

На нижнем уровне у нас идет измерительно-диагностическое оборудование, цель которого — снятие измерений и выявление дефектов. Эти дефекты и измерения в автоматическом режиме загружаются в нашу систему. Здесь уже выполняется их учет, планирование, контроль устранения. Расчет стоимости не производится, это делается в SAP. В качестве ERP-системы используется SAP, куда с нашей системы передаются данные, которые необходимы для расчета. Ситуационный центр показывает информацию о проводимых работах, о планируемых работах, о складских запасах, то есть всю необходимую информацию для принятия решения.

И в нашем Dynamics ЕАМ есть приложение для мобильных устройств, целью которых является получение нарядов на исполнение, ввод дефектов и оперативное планирование.

Из ERP-систем мы можем получать кадры, материалы по складскому учету и нормы расхода материалов. Передаем, соответственно, запланированные работы с потребностями, выполненные работы, затраченные материалы, используемое оборудование и рабочее время сотрудников.

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

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

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

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

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

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

Еще нужно упомянуть о таком понятии на железной дороге, как «окно». Если идет ремонт железнодорожного пути, то нужно обеспечить закрытие перегона, чтобы по этому участку пути не шел поезд. Это важно и для охраны труда. В системе есть реестр окон, для каждого объекта есть график эксплуатации, есть такое понятие, как плановые окна, есть такое понятие, как оперативные окна. Когда в системе планируется заказ и выбирается технологическая карта, а в технологической карте указано, что на эту работу должно быть обязательно выделено окно в размере, допустим, 2—3 часа, то система не пропустит этот заказ дальше в работу.

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

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

Мобильное приложение у нас реализовано для всех трех мобильных платформ, то есть это Android, iOS и Windows. Изначально была запланирована следующая функциональность: ввод обнаруженных дефектов, исполнение нарядов, ввод измерений, вторичный контроль дефектов, а в процессе эксплуатации мы выяснили, что на самом деле человек, который планирует устранение дефектов, находится на рабочем месте за компьютером только 20% своего времени, а 80% своего рабочего времени он находится где-то на объектах, то есть обходит участки, проверяет, как выполняют работы его ремонтные бригады. И поэтому было решено в мобильное приложение добавить функцию по мониторингу состояния объектов и по планированию работ на их устранение.

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

Также в системе ведутся полностью:

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

По плану, в 2015 году мы должны завершить пилотный проект, а с 2016 планируется внедрение по остальным предприятиям путевого хозяйства (их порядка 40 в Казахстане).

Проект №2. АСУ вагоноремонтного депо (АСУ ВРД)

Основной объект автоматизации — вагоноремонтное депо. Заказчик проекта — АО «Казтемiртранс» (АО «КТТ»).

Цели проекта

1. Предоставление центральному аппарату оперативной и архивной информации о деятельности ВРД посредством информационной системы (так как центральный аппарат находится в Астане, а ВРД
   распределены по территории Казахстана).
2. Организация сбора, накопления, хранения и анализа всех данных ремонтного процесса в единой базе данных.
3. Обеспечение автоматизированными рабочими местами все места зарождения технологической информации, снижение необходимости ведения бумажного документооборота.

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

Кратко опишу процесс. Существует общая система по СНГ — автоматизированная система оперативного управления перевозками (АСОУП), где учитываются все вагоны, хранятся паспорта по каждому вагону, в паспортах информация обо всех проведенных ремонтах, обо всех замененных, отремонтированных деталях.

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

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

И также вся информация о ремонте выгружается во внешнюю систему.

Схема работы АСУ ВРД

1. При поступлении вагона в ВРД автоматизированное создание ремонтного паспорта вагона и технологического процесса ремонта вагона.
2. При демонтаже узлов вагона автоматизированное создание ремонтного паспорта узлов и номерных деталей и тех.процессов ремонта узлов и деталей.
3. При осмотре узлов и деталей происходит фиксация кода неисправностей, согласно чему АСУ ВРД определяет необходимые для ремонта узла/детали тех. процесс, материалы, инструменты, кадры.
4. Происходит автоматическое формирование сменных заданий, требований на склад, нормативное время осуществления операций.
5. После осуществления тех. операции ответственный работник вводит со своего АРМ необходимые параметры операции, обновленные параметры узла, проставляет признак окончания операции.
6. АСУ ВРД осуществляет форматно-логический контроль вводимых данных, сверяет с допусками, полный логический контроль последовательности и полноты выполняемых операций.
7. АСУ ВРД на основании вводимых данных формирует всю полноту технологической документации: книги, журналы, задания, исполнение, отчеты, складские документы, кадровые документы, акты, справки.
8. АСУ ВРД в автоматическом режиме обменивается данными с АСОУП.

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

Также имеется реестр технологических карт, графики работ для них очень актуальны, так как на ВРД идет посменная работа, круглосуточно. Реализован складской учет — перечень складов, перечень материалов на складах, функции перемещения, поступления, списания, резервирования. Реализована интеграция с АБУ «Фаворит» по загрузке остатков на конец месяца. В автоматическом режиме не получилось сделать интеграцию, идет в полуавтоматическом.

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

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

Результаты проекта

1. Автоматизирован учет, контроль и мониторинг осуществляемых технологических процессов.
2. Автоматизация отчетных и печатных форм.
3. Повышение персональной ответственности сотрудников предприятия.
4. Предоставление пользователям и руководству актуальной информации для принятия решений.
5. Интеграция с диагностическим оборудованием и АБУ «Фаворит».

Сейчас планируются работы по тиражированию нашего решения — у данного предприятия есть еще три ВРД на территории Казахстана, причем будут учитываться собственные бизнес-процессы ВРД, которые работают только у них, соответственно, будет донастройка под их задачи.

---

Журнал Prostoev.NET № 4(13) 2017
Автор: Оксана Лагутик, ТОО «Dynamics Tehnologies», бизнес-аналитик