Особенности реального внедрения 1С:ТОИР

Часть 1. Учет объектов ремонта. Интеграция ТОИР с учетной системой. Планирование ремонтов.

В последнее время система ТОИР, позволяющая автоматизировать процессы, связанные с управлением ремонтами и обслуживанием оборудования, все чаще находит применение на производственных предприятиях различных отраслей.

ТОИР позволяет не только упорядочить работу ремонтных служб, сделать деятельность более прозрачной, но и минимизировать затраты на ремонты и обслуживание, уйти от аварийных ремонтов, сократить простои оборудования и, как следствие, повысить исполнимость производственных планов.

В данном материале специалисты департамента ERP-решений компании 1С:Апрель Софт поделятся опытом реального внедрения программы 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП (ТОИР). Внедрение проводилось в компании, оказывающей широкий спектр услуг предприятиям нефтедобывающего комплекса.  Основными видами деятельности являются: поисково-разведочное и эксплуатационное бурение нефтяных и газовых скважин, текущий и капитальный ремонт скважин, подбор рецептур, разработка и сопровождение буровых растворов, цементирование скважин, услуги по технологическому сопровождению наклонно-направленного бурения.

Какие же цели внедрения ставило руководство?

1. Снижение рисков выхода из строя оборудования по причине несвоевременного технического обслуживания и планово-предупредительного ремонта.

2. Получение актуальных данных о текущем состоянии объектов ремонта (ОР).

3. Автоматическое планирование графиков планово-предупредительных ремонтов (ППР) на основании имеющихся нормативов.

4. Получение возможности анализировать исполнимость Производственной программы на имеющемся оборудовании.

Что было сделано в ходе внедрения? Какие основные функциональные блоки были автоматизированы?

1. Учет объектов ремонта (По комплектации, По технологической позиции, По Местонахождению)

2. Планирование (Календарное, По наработке, Смешанное) ТО, текущих и капитальных ремонтов с учетом:

• Производственной программы (в том числе ее корректировок)
• Данных о фактической наработке оборудования

3. Контроль состояния оборудования и диспетчеризация

4. Проведение ремонтов (плановые/внеплановые)

• Создание наряд-заданий на основании графиков ППР
• Автоматизированное рабочее место (АРМ): фиксация данных об исполнителях, о текущем % выполнения ремонта, материальных затратах и запчастях, стоимости.

5. Интеграция ТОИР с учетной системой

В данной части мы более подробно рассмотрим решение задач функциональных блоков 1-3. А в следующей – оставшиеся задачи.

Итак, начнем с блока Учет объектов ТОИР.

На скриншоте ниже представлен один из главных объектов системы ТОИР – справочник Объекты ремонта. Количество объектов ремонта, с которыми работает Заказчик, достаточно велико. В проекте приняло участие 4 филиала, каждый из которых имеет от 10 до 30 укрупненных объектов обслуживания. Каждый укрупненный объект ремонта насчитывает от 500 до 1500 шт. составляющих объектов ремонта. Это серьезные цифры. Поэтому ещё на этапе проектирования было принято решение о разработке нового рабочего места (РМ) – Список объектов ремонта. Типовой функционал ввиду реализованного архитектурного подхода имеет значительные ограничения по производительности при обработке такого массива данных. Реализованное нами РМ сокращает длительность обработки одной операции от нескольких минут до нескольких секунд. Кроме того, в рамках выполнения данной задачи, была реализована ещё одна важная потребность: представление в режиме одного окна данных о занимаемой позиции ОР в разных структурах иерархии: По комплектации и По технологической позиции.

Структура иерархии позволяет один и тот же ОР классифицировать по различным сущностям. Наиболее распространенные и используемые на предприятии Заказчика – это структура По комплектации, которая позволяет получить информацию о том, какую позицию согласно паспорта оснащенности занимает тот или иной ОР, и структура По технологической позиции, которая позволяет получить информацию о том, какую функцию (технологическую позицию) занимает данный ОР. Для получения данных о положении ОР в разных структурах иерархии в типовой конфигурации необходимо было «переключиться» из одного режима (одной структуры) в другой. Для повышения эффективности работы пользователей мы реализовали возможность работы с данными в режиме одного окна.

В рамках проекта мы реализовали следующую структуру: 1-ый уровень – уровень укрупненного объекта обслуживания, 2-ой уровень – уровень тех. позиции (например, Буровой насос, как приведено на данном слайде), 3-ий и следующие уровни – уровни ОР и составных частей ОР. На скриншоте показано, что в буровой установке 14430 есть тех. позиция Буровой насос (данные согласно заведенной структуре по тех. позиции). К данной технологической позиции отнесены 3 объекта ремонта: 2 Электродвигателя и 1 Модернизация бурового насоса (данные согласно заведенной структуре по комплектации).  

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

На скриншоте ниже представлена карточка объекта ремонта. Как видно, из карточки ОР доступны для ввода и редактирования и просмотра различные данные, а именно:

1. Данные по эксплуатации: Организация и Подразделение, которому принадлежит ОР, дата ввода в эксплуатацию, График работы, СПИ, Инвентарный №, Технологический №, Класс, Местоположение.

2. Данные об изготовителе: Изготовитель, № Паспорта, Заводской №.

3. Исполнители ремонта

4. Дополнительные данные, такие как данные о гарантии, признак того, что ОР не участвует в планировании (добавленный реквизит).

5. На отдельных закладках отображаются данные о показателях эксплуатации, нормативах планирования и пр. Более подробно рассмотрим в последующих блоках. 

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

При этом реализована функция автоматического изменения положения ОР в структуре по местоположению, если Родитель (Буровая установка), в которую перемещается ОР, имеет отличное от предыдущего местоположение. Это касается операции перемещения в структуре по комплектации.

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

Интеграция ТОИР с учетной системой.

Перед тем, как перейти к блоку Планирование ремонтов, рассмотрим, каким образом настроена интеграция ТОИР и учетной системы 1С:ERP Управление предприятием 2 (1С:ERP), поскольку эти две системы тесно связаны.

На нашем внедрении системы 1С:ERP и 1С:ТОИР КОРП функционируют как самостоятельные базы данных, между которыми настроен План обмена (через xml). Такое решение было принято потому, что обе системы на предприятии Заказчика значительно модифицированы и объединение данных систем могло привести как к снижению производительности, так и к возможным сложностям при обновлениях. Между системами 1С:ERP и 1С:ТОИР реализован обмен в части данных справочника Объекты ремонта. Первично данные по ОР заносятся в учетной системе при приобретении Объекта эксплуатации. На основании данных учетной системы в системе ТОИР автоматически создается новый ОР в специализированном положении: в том подразделении, в которое закуплен Объект, но без определения тех. позиции и положения в структуре по комплектации (на склад подразделения). После принятия к учету у Объекта появляется Инв.№ и доп. аналитика укрупненного объекта учета, к которому относится данный ОР. В этот момент средствами обмена в системе ТОИР ОР перемещается со склада (оборотного фонда) подразделения в оборотный фонд единицы учета. Далее ответственное лицо определяет новые ОР на занимаемую тех. позицию.

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

В системе 1С:ERP на предприятии Заказчика автоматизирована подсистема планирования производственного процесса, а также учет фактического выполнения производственной программы с отражением ключевых аналитик, таких как филиал, МВЗ, Проект, Технологическая операция.

Данные о производственной программе из учетной системы используются для загрузки в 1С:ТОИР КОРП план-графика ППР по отдельному виду ремонтов, который в последующем используется для анализа пересечений производственной программы с рассчитанными графиками ремонтов. На данном слайде приведен фрагмент отчета о Годовой производственной программе по одному укрупненному объекту обслуживания. Данный отчет демонстрирует временной интервал в пределах года, в котором объект обслуживания задействован на производстве, соответственно в эти временные интервалы не может производиться капитальный ремонт любого ОР и Текущий ремонт отдельных Объектов/Узлов ремонта.

Данные о производственной программе загружаются в документы типа План-график ППР автоматически в процессе обмена. При этом создано два отдельных узла в Плане обмена: для загрузки годовой производственной программы и для загрузки корректировок (месячный план). Регламентом предприятия предусмотрены определенные даты, в которые должны быть подготовлены данные по годовой производственной программе и по оперативному плану. Годовой план выгружается пользователем, а вот корректировки к оперативному плану загружаются в автоматическом режиме по настроенному расписанию.

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

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

Наработка выгружается ежедневно по настроенному расписанию. Данные о фактической наработке ОР отображаются непосредственно в карточке ОР.

В рамках интеграции двух систем на данном этапе автоматизации также реализовано автоматическое создание/оповещение о необходимости зафиксировать Выявленный дефект. Такая операция возникает в случае, если в процессе работы объекта эксплуатации произошла его полная или частичная остановка, что было зафиксировано в производственной подсистеме. В этом случае исполнитель должен зафиксировать выявленный дефект в системе ТОИР. В случае, если исполнитель по каким-то причинам не отразил дефект в ТОИР (забыл это сделать), при выгрузке суточного отчета система «проверит» был ли зафиксирован Дефект по данному объекту обслуживания и, если дефект не зафиксирован, то будет сгенерировано напоминание о необходимости выполнения данного действия. О назначении данного документа мы расскажем подробнее в блоке Выполнение ремонтов и ТО.

Планирование ремонтов

Теперь перейдем непосредственно к задаче составления графиков ремонтов. Для расчета и фиксации планируемых ремонтов предназначен специальный документ План-график ППР. При планировании ремонтов используется следующий подход: Годовой План ремонтов, который составляется в конце года, предшествующего году планирования, и Оперативный (месячный) План ремонтов, который составляется до 26-го числа месяца, предшествующего месяцу планирования. Оперативный План ремонтов представляет собой корректировку к годовому Плану ремонтов на данный месяц.

План-график ППР составляется отдельно для каждого Сервиса по ключевой аналитике учета – МВЗ. Общий План ремонта по ключевой аналитике на заданный период представлен в системе в виде отчета (будет продемонстрирован отдельно).

Теперь давайте посмотрим на нормативную базу, которая используется при расчете план-графика ППР. На предприятии Заказчика используется календарное планирование, планирование по наработке, а также смешанное (в большинстве случаев).

Норматив планирования указываются для элемента справочника Типовые объекты ремонта (ТОР), при этом каждый ОР в системе отнесен к ТОРу (указывается в карточке ОР).

На скриншоте ниже приведен пример указания нормативов планирования ремонтов для ТОР Вертлюги. Как видите, он не один. Нормативы планирования задаются для конкретного вида ремонта.

Так в данном случае для вида ремонта Текущий ремонт Т1 указан способ планирования по значению параметра Наработка, равному 600 ч. Это значит, что при запуске процедуры планирования для ОР, отнесенных к ТОРу Вертлюги, будет анализироваться значение параметра Наработка и при достижении этого Параметра 600 ч, будет запланирован ремонт Т1. При этом при отсутствии данных о фактической наработке система анализирует значения Плановой наработки ОР (данные, загружаемые из производственной программы). Таким образом выполняется годовое планирование. При месячном (оперативном) планировании возможны корректировки, связанные с тем, что фактическая наработка ОР достигает значения параметра наработки, при котором должен быть проеден ремонт. Фактическая наработка имеет больший приоритет при планировании ремонтов, чем плановая.

Согласно заданным нормативам планирования, а также описанной выше процедуре планирования ППР, создаётся документ План-график ППР. Документ заполняется автоматически (скриншот ниже). В основном, используется заполнение план-графика ППР в фоновом режиме. В данном варианте процедура расчета/заполнения выполняется на сервере и не блокирует дальнейшую работу пользователя. Это очень важная и нужная возможность, поскольку процедура расчета достаточно ресурсоемкая и длительная по времени (связано в первую очередь с большим количеством учитываемых ОР).

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

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

При наведении курсором на строку диаграммы система позволяет получить расшифровку непосредственно до документа, которым был зафиксирован ремонт по данному ОР, при этом в документе «попадаем» именно в ту строку, которой был запланирован данный ремонт.

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

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

Итак, в данной части материала, мы рассмотрели такие темы, как Учет объектов ремонта, Интеграцию ТОИР с учетной системой и Планирование ремонтов. В следующей части поговорим о Контроле состояния оборудования и о Выполнении ТО и ремонтов.

Особенности реального внедрения 1С:ТОИР

Часть 2. Контроль состояния оборудования. Выполнение ТО и ремонтов

В данном материале специалисты компании 1С:Апрель Софт продолжают поделиться опытом успешного проекта на базе программы 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП (ТОИР). Напомним, что площадкой для внедрения послужила компания, предоставляющая предприятиям нефтедобывающей отрасли комплекс услуг, в том числе: поисково-разведочное и эксплуатационное бурение нефтяных и газовых скважин, текущий и капитальный ремонт скважин, подбор рецептур, разработка и сопровождение буровых растворов, цементирование скважин, услуги по технологическому сопровождению наклонно-направленного бурения.

В первой части статьи мы рассмотрели такие темы, как Учет объектов ремонта, Интеграцию ТОИР с учетной системой и Планирование ремонтов.

Далее мы параллельно расскажем о двух внедренных функциональных блоках: Контроль состояния оборудования и Выполнение ТО и ремонтов, т.к. для работы в данных подсистемах используется общее АРМ, разработанное нами в процессе внедрения.

Сначала представим спроектированную схему отдельно для Технического обслуживания (ТО) и отдельно для Ремонтов (текущих и капитальных).

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

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

Запланированные ремонты всех видов обрабатываются одним регламентным заданием, которое на основании запланированных ремонтов формирует документы определенного вида: для ТО – акты выполнения этапов работ, для ремонтов – Сметы (заявки на ремонт). Формирование данных документов происходит с учетом данных о горизонтах планирования, т.е. на какой период от даты запуска регламентного задания формировать данные документы. В системе создан регистр сведений Горизонты планирования, в котором в разрезе видов ремонта и ответственных служб указываются горизонты планирования в днях и какой тип документа создавать: Акт или Заявку.

А теперь давай рассмотрим процесс обработки (выполнения) запланированного ремонта или ТО. Мы будем рассказывать на примере ремонта, для ТО выделим отличия.

Итак, для работы с запланированными ТО и ремонтами разработано специальное АРМ «Техническое обслуживание и ремонт», форма АРМ представлена на скриншоте.

В АРМ «ТО и ремонт» обработка запланированных ремонтов первично выполняется инженером обслуживающего сервиса. Инженер видит все запланированные ремонты по своему сервису, а также удовлетворяющие условиям отбора, наложенным в области отборов АРМа. В АРМе работа ведется по одному выбранному заданию (активной строке заданий). Для того, чтобы начать работу с заданием, пользователь «берет В работу» задание, оно становится активным и для него доступны различные действия.

На этапе заявки инженер может уточнить перечень ремонтных работ, указать материальные затраты, необходимые для выполнения ремонта, трудовые затраты (какие трудовые ресурсы необходимы), инструменты и запчасти, а также Исполнителя работ.

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

Заполнив все данные по Заявке, инженер Сохраняет внесенные изменения. Далее должен быть указан статус Обеспечения по Заявке: Требует или Не требует обеспечения. На следующем этапе значение данного реквизита используется при обмене с учетной системой и используется в подсистеме Обеспечение производства. Значение статуса обеспечения из учетной системы возвращается в ТОИР (это следующий этап в части настройки обмена двух систем, на данный момент ещё не запущен).

Обеспеченная заявка на ремонт передается непосредственно на объект для выполнения. В системе в этот момент инженер Создает Наряд на ремонт, т.е. выдает задание распорядителю. До этого этапа Состояние задания принимало значение «Запланирован», после создания Наряда (нажатие на кнопку Создать наряд в верхней части АРМа) задание автоматически меняет состояние на «В работе». С такими заданиями (статус которых «в работе») инженер уже не работает, а только контролирует ежедневно выполнение данных ремонтов. С заданиями в статусе «В работе» работает распорядитель через данный АРМ (ему доступны только такие задания).

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

Ежедневно в конце дня распорядитель заносит данные по фактически выполненным ремонтным работам в систему. Факт выполнения (полного или частичного) ремонта в системе сопровождается созданием Акта выполнения этапов работ (нажатие на кнопку в панели действий АРМа). Состояние ремонта автоматически меняется на «Частично выполнен». На данном этапе распорядитель может проставлять процент выполнения ремонта (для возможности анализа состояния ремонта по ОР, если ремонт достаточно длительный по времени), а также указывать данные о гарантии, если она была предоставлена после выполнения ремонта подрядчиком.

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

Для того, чтобы полностью завершить ремонт по заявке, распорядитель нажимает кнопку Завершить, ремонт закрывается и уходит из области текущих ремонтов в АРМе.

Таким образом обрабатываются запланированные ремонты. Как видно из приведенного примера, набор действий по обработке заявки на ремонт используя разработанный АРМ – минимальный, при этом идет четкое распределение по должностям и ролям, как функциональных обязанностей, так и доступность определенной информации в системе (пользователи не делают и не видят «лишнего»).

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

При выполнении ТО, как правило, требуется зафиксировать значения контролируемых показателей. Это также выполняется через АРМ на отдельной закладке Измеряемые показатели. В дальнейшем значения измеряемых показателей могут быть использованы для принятия определенных решений по выполнению ремонта ОР.

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

В завершении покажем отчет План-факт по выполнению ремонтов.

Сложности в ходе внедрения и как их обошли

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

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

Зачастую на предприятиях нет карт ремонтов, перечень операций одного ремонта всегда разный. Здесь, как вариант, можно включить в карты ремонтов операции «с запасом» (то есть все возможные технологические операции) и в каждом конкретном ремонте исключать лишние операции.

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

Эффекты от внедрения новой системы

Основные работы по автоматизации завершились (на текущий момент идет постпроектное сопровождение). Основные эффекты, полученные от внедрения системы 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП:

1. Наличие достоверных данные о текущем состоянии всех ОР в одной базе

2. Автоматическое планирование графиков ППР на основании имеющихся нормативов и данных о фактической наработке

3. Производственная программа «без иллюзий»

4. Быстрое формирование управленческой отчетности

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

По данным различных исследований (Gartner, A.T.Kearney, ARC Advisory Group, SMRP) внедрение систем класса EAM (такой системой является 1С:ТОИР) окупается в среднем менее чем за 2 года

Выгоды от внедрения (По данным исследования консалтинговой группы A.T. Kearney (в исследовании участвовало 558 компаний):

Материал подготовлен специалистами ERP-Департамента 1С:Апрель Софт.