Использование API-функций Search на предприятии «Ростсельмаш»

Андрей Петров

Search как инструмент анализа бизнес-процессов

API-функции

Компания «Ростсельмаш» (г.Ростов-на-Дону) входит в пятерку крупнейших мировых производителей комбайнов и сельскохозяйственной техники. В ее ассортименте зерноуборочные модели комбайнов ACROS, VECTOR, «Нива-Эффект» и кормоуборочный комбайн DON 680М. Готовятся к выпуску новые модели зерноуборочного роторного комбайна РСМ-181 и кормоуборочного РСМ-1401.

Вся конструкторская документация (КД) на новые изделия разрабатывается в CAD-системе; КД, заимствованная с моделей, созданных до использования CAD-системы, также переведена в электронный вид (3D-модель плюс чертеж). Вся КД хранится в архивах Search и имеет определенные статусы. Изменения вносятся в нее с использованием извещений об изменении (ИИ) системы Search , при этом создаются версии документов. Согласование ИИ и КД производится с помощью модуля Workflow системы Search . Описанный режим работы существует на предприятии более 5 лет в полном объеме. Вся технологическая документация на новые изделия разрабатывается в комплексе TechCard. Параллельно идет работа по переводу в электронный вид технологических процессов (ТП), разработанных на бумаге.

Технологические планировки создаются в системе LCAD.

Системы Search, TechCard и LCAD являются разработками компании ИНТЕРМЕХ, с которой «Ростсельмаш» сотрудничает на протяжении уже шести лет.

Вся техническая документация (ТД) хранится в архивах Search и имеет определенные статусы.

Изменения в ТП вносятся только с использованием механизма извещений об изменении системы Search.

В полном объеме настроены:

• модуль автоматизированного расчета основных и вспомогательных материалов;
• модуль трудового нормирования;
• расчет норм расхода режущего инструмента.

Планируется настроить расчет ТЭР (энергозатрат).

Search как инструмент анализа бизнес-процессов

На наш взгляд, использование модуля workflow в системе Search обеспечивает более половины эффективного внедрения САПР на предприятии.

Программа составления отчетов движения документов позволяет анализировать узкие места в процедуре согласования. Как показала практика, настройка согласования КД, в частности извещений об изменении, с применением рекомендаций ЕСКД увеличивает время согласования. Путем анализа узких мест процесс согласования ИИ за 5 лет менялся более 15 раз. Линейная схема согласования (рис. 1) на принципиальных этапах (занимающих значительное время при согласовании) была преобразована в параллельную (рис. 2). Специальный механизм, который использован в данной схеме, позволяет сократить сроки согласования.

Многовариантность построения бизнес-процессов в Search

Рис. 1. Линейная схема согласования извещения об изменении

Рис. 2. Параллельная схема согласования

Если пять лет назад сроки согласования (между конструкторской и технологической службами) одного среднестатистического ИИ составляли 3-5 месяцев, то с использованием workflow Search — полтора месяца.

По этому критерию эффективность использования Search для предприятия составила 300%.

Все бизнес-процессы в Search настраиваются строго по регламентам (рис. 3), которые хранятся в архивах Search и изменяются только по ИИ, согласование производится по маршруту согласования в workflow.

Рис. 3. Фрагмент оформленного регламента

API-функции

Использование API-функций при работе с системой Search вывело на новый, более качественный уровень удовлетворение потребностей пользователей.

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

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

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

Рис. 4. Схема согласования технологической документации

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

Применение API-функций позволило:

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

Script 1 автоматически назначает согласующих лиц на последующих этапах согласования в зависимости от передела технологической обработки.

Script 2 рассылает документ только тем участникам согласования, которые не согласовали документ (то есть их подписи неактуальны).

Script 3 на коллекторе запоминает список актуальных и неактуальных подписей.

Возврат документа на редактирование производится по условию «Контроль подписи».

Используя модуль workflow системы Search и API-функции, можно решить любую на первый взгляд неразрешимую задачу автоматизации документооборота.

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

Рис. 5. Схема согласования заказа на печать документации

Данная программа интересна тем, что в ней используется несколько способов применения API в процессе согласования (рис. 5):

• Script в модуле workflow;
• автоматическое действие (вызов программы, разработанной в отделе САПР);
• плагин к модулю workflow.
• Функции, выполняемые программой:
• формирование заказа (в заказ можно включать как документы из архивов Search, так и файлы с диска);
• запуск процесса выполнения заказа с помощью модуля workflow;
• выполнение заказа;
• формирование отчетов по заказам.

Пользователь создает заказ (рис. 6) и присваивает ему обозначение. В заказ можно включить извещение, все документы по данному извещению, указать количество копий по каждому документу.

Рис. 6. Окно формирования заказа на печать

Заказ запускается по процессу согласования (см. рис. 5), создается бумажная версия заказа с перечнем документов (этап «Формирование документа»), а также отчет по заказу.

Исполнитель заказа, который печатает бумажные копии, в папке «Входящие» почты системы Search (рис. 7), отчитывается в выполнении заказа, причем делает это с помощью плагина «Проверка комплектности печати» (см. рис. 5).

Рис. 7. Окно отчета о выполнении заказа в системе Search

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

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

В настоящее время разрабатывается программа, которая будет осуществлять сбор информации об изделии по конструкторским и технологическим данным. Идея ее написания появилась неслучайно. В системе Search используется карточка изделия, в которой объект описывается как таковой — обозначение, наименование, масса, материал, из которого он изготовлен. В системе Techcard есть данные по расцеховочному маршруту, нормам времени на изготовление попередельно (по техпроцессу по виду обработки: сборка, сварка, мехобработка и т.д.). Возникла идея объединить данные об изделии.

Разрабатываемая программа будет востребована менеджерами, которые занимаются проектами в производственном процессе, так как она позволяет в одном месте узнать всё, что требуется для изготовления детали. Конечно, такую информацию можно получить стандартным набором в системе TechCard , однако отличительной особенностью данной программы является то, что запуск TechCard не требуется. Реализовать это можно с использованием API TechCard и Search .

Программа вызывается из системы Search при выборе объекта. Работает она по следующему алгоритму: по объекту ищется расцеховочный маршрут (РМ), далее по строке технологической операции РМ производится поиск технологических процессов, по найденным техпроцессам выбираются и группируются одинаковые данные.

Рис. 8. Окно сводных данных об изделии

Программа имеет три закладки (рис. 8):

• список основных материалов;
• список вспомогательных материалов;
• норма штучного времени.

Программа имеет настройки для сбора данных по цеху или по технологическим переделам.

Результаты можно сформировать в отчет или поместить во внешний файл (рис. 9).

Рис. 9. Отчет об изделии

Все данные, которые прописаны в техпроцессе, можно выводить в отчет.

Таким образом, открытый API-интерфейс, предоставляемый компанией ИНТЕРМЕХ в системах Search и TechCard, позволяет реализовать практически любую специфическую задачу в области документооборота и работы с составом изделия.

САПР и графика 8`2008