Расширены возможности работы с произвольными заданиями
В системе 1С:ТОИР 2 КОРП можно управлять ремонтами и обслуживанием оборудования, назначая исполнителям различные задачи. Например, в 1С:ТОИР поступает информация о выявленном дефекте. Мастер цеха создает на основании дефекта «Смету ремонта (Заявку на ремонт)» и назначает бригаде слесарей-ремонтников задачу (наряд) по устранению дефекта. После чего бригада устраняет дефект и фиксирует результат актом выполненных работ.
Получается следующая цепочка задач, которая отражает бизнес-процесс: выявленный дефект — заявка на ремонт — наряд на выполнение ремонта — акт выполненных работ.
Однако кроме выявленных дефектов основанием для формирования наряда ремонтной бригаде могут быть и произвольные задания. И этот бизнес-процесс несколько отличается от описанного выше: ответственный назначает исполнителю произвольное задание, тот выполняет его, фиксирует результаты, а ответственный потом проверяет, всё ли было выполнено верно.
В 1С:ТОИР 2 КОРП и раньше можно было работать с произвольными заданиями. Например, такой механизм применялся при анализе коренных причин дефектов: в качестве задания здесь выступало «Корректирующее мероприятие» по устранению первопричины поломки. Кроме того, задания можно было создавать на основании таких документов, как «Смета ремонта (Заявка на ремонт)», «Акт о выполнении этапа работ» и др.
Как это работает? Например, в день перед плановым ремонтом мастер дневной смены создает «Заявку на ремонт» и на ее основании формирует задание для ночной смены. В задании он указывает о необходимости проведения подготовительных работ, которые требуются для утреннего ремонта (например, отключить станок от электропитания, слить технические жидкости). Ночная смена видит назначенное задание и выполняет его. Утром мастер дневной смены проверяет результат: станок отключен от электропитания, технические жидкости слиты. Таким образом, дневная смена приступает к ремонту, к которому уже всё готово.
Назначать задания стало удобнее
Начиная с релиза 2.0.44.1 можно назначать задания в том числе и на основании документа «Состояния объектов ремонта», а видеть назначенное задание после его выполнения — в связанных документах по ТОиР.
Таким образом, теперь, если в дневную смену перестает работать рейсмусовый станок, диспетчер фиксирует его остановку — оформляет документ «Состояния объекта ремонта» и прямо на его основании оформляет произвольное задание для дежурной диагностической бригады. Цель задания (например) — выяснить причины остановки и зафиксировать результат для дальнейшего анализа мастером цеха состояния оборудования. После выполнения задания оно сохраняется в связанных документах по ТОиР.
Включение произвольного задания в бизнес-процесс позволяет расширить цепочку сопровождающих документов по ремонту, сделать ее более прозрачной, информативной и полезной.
Упростилась работа с типовыми объектами ремонта
При изменении типа объекта в «Типовом объекте ремонта» или «Объекте ремонта» добавлена возможность изменить тип объекта у всего списка объектов ремонта, входящего в типовой объект, или у типового объекта ремонта, которому принадлежит объект ремонта. Объясним в деталях.
Когда в системе появились функциональные места, пользователи получили возможность выбирать для типовых и обычных объектов ремонта тип объекта. Типов всего два: единица оборудования (привычные объекты ремонта) и функциональное место (виртуальный информационный объект, который связывает между собой единицы оборудования, которые совместно выполняют одну технологическую операцию или влияют на нее).
Типовые объекты ремонта создаются в системе, чтобы сэкономить время на ввод основных данных по схожим объектам ремонта. В типовой объект пользователь добавляет общие (для нескольких объектов ремонта) показатели эксплуатации, нормативы планирования, паспортные характеристики и четко указывает те объекты ремонта, которые будут соответствовать данному типовому объекту. При этом данные, заполненные в типовом объекте ремонта, автоматически распространяются на каждый объект ремонта в его составе. Согласитесь, удобно.
Мы решили пойти дальше по пути упрощения работы пользователей. Если раньше, когда характеристики объекта ремонта отличались от характеристик типового объекта, система просто выдавала информационное сообщение, после чего пользователю надо было перейти в карточку типового объекта ремонта и изменить его характеристики либо же удалить объект ремонта из состава типового. Теперь же 1С:ТОИР предлагает выполнить нужные действия автоматически во всплывающем окне. Вам нужно лишь сделать выбор: изменить тип типового объекта и входящих в его состав объектов ремонта или же очистить типовой у данного объекта. Остальное система сделает за вас.
В печатную форму паспорта объекта ремонта добавлен список запчастей
Карточка (или паспорт) объекта ремонта содержит основную информацию о нем — это данные по эксплуатации, информация о заводе-изготовителе, паспортные характеристики, контролируемые показатели, история ремонтов и пр.
Помимо этого, в системе есть опция «Учет запчастей», которая позволяет вести в карточке объекта ремонта учет установленных на нем запчастей. Например, на объекте ремонта «Погрузчик CHANGLIN ZLM30-5» установлены запчасти: фильтр топливный и фильтр воздушный.
Как известно, в работе с информационной системой часто требуется вывести печатную форму того или иного документа. Паспорт объекта ремонта не составляет исключение. И если ранее в печатной форме паспорта объекта ремонта не выводилась информации по запчастям, то в новом релизе мы решили это исправить и расширили печатную форму. Теперь в ней есть все данные по запчастям, установленным на том или ином оборудовании.
Проверка рецидивных дефектов стала выполняться быстрее
Ну и, наконец, продолжая работу над повышением производительности системы, мы «восстановили справедливость» в отношения скорости проверки рецидивных дефектов.
Во время тестирования производительности, мы заметили, что документ «Выявленный дефект» проводится более 10 секунд, если он оформлен на 10 и более отказавших объектов ремонта, а также при наличии в системе более 200 тысяч зарегистрированных документов. Ключевым фактором замедления, конечно же, было большое количество документов в системе.
Чтобы сократить ожидание пользователей, мы оптимизировали запрос проверки рецидивных дефектов. Теперь для проведения документа «Выявленные дефекты» требуется всего около 2 секунд.
