Не секрет что для успешного внедрения любой системы документооборота необходимо произвести несколько логичных шагов, в данном посте я опущу этапы исследования, начну с пилотного проекта. И постараюсь описать проблемы и способы решения оных, которые с уверенностью в 90% существуют на любом пост-советском «кондовом» предприятии.
Этапы внедрения системы
- Была сформирована рабочая группа, состоящая из конструктора, технолога, оператора архива ОТД и администратора системы;
- Был проведен анализ и оценка существующих бизнес-процессов и выделены основные типичные для предприятия бизнес-процессы по утверждению и сдаче документации;
- Проведен анализ рыночных предложений и выбор PDM-системы;
- Закупка малого количества лицензий, по количеству участников рабочей группы ( 6 лицензий Search, 3 лицензии AVS(система формирования спецификаций и вторичной документации), 1 лицензия Techcard (система работы с технологическими процессами)
- Был составлен план внедрения системы на реальном заказе «***», в качестве пилотного проекта;
- Произведена настройка бланков конструкторско-технологической документации;
- Создан и утвержден шаблон оформления документации в системе КОМПАС.
- Создана методика создания базы стандартных элементов;
- Создана методика ведения электронной картотеки документов ОТД;
- Создана методика ведения классификаторов ОТД;
- Создана и проверена эксплуатация создания спецификаций в PDM системе как с ручного ввода, так и в полуавтоматическом режиме, на основе имеющихся в базе документов и прочих изделий.
Проблемы
- Документация имеет огромную преемственность ( 70% конструкторско-технологической документации по пилотному проекту – заимствованная из другого изделия).
- Документы выполнены в разных версиях САПР системы Компас (система не поддерживает преемственность), с разными шаблонами оформления (Search параметрическая система и построена на принципах считывания атрибутов с листов САПР системы, атрибуты определяются в шаблонах), т.е. для загрузки документа в Search необходимо пересохранять каждый файл в текущую версию Компаса с применением новых стилей оформления. Т.к используются различные шаблоны, то часть важной информации теряется, необходимо перезаполнять соответствующие поля (Наименование, Обозначение, Разработал, Проверил, Н.контр, Первичная применяемость и т.д.)
- Зачастую многолистовые чертежи сохранены в разные файлы, но имеют одинаковые атрибуты. Для загрузки в систему необходимо собрать проект в 1 файл, иначе возникают ошибки, т.к. к на разных документах один децимальный номер.
- Не используется возможность «САПР Компас» «спецификация на листе», т.е., например, соединительные кабеля прописаны гладким текстом в таблице, созданной руками, соответственно интегратор Компас-Search не получает данных о изделии.
- Вторичные документы (спецификации, ведомости спецификаций, ведомость материалов) выполняются не автоматически, средствами САПР, а в различных, не приспособленных к этому программах (word, excel,TDD и тд), в случае, когда спецификация выпускается в системе Компас, то по факту выполняются это таблице, созданная средствами компаса, и заполняется вручную и не имеет связей с чертежом. Разработчики печатных плат, в свою очередь, выпускают перечни элементов на компас-форме «ведомость спецификаций» в табличном режиме, внося данные вручную. Что приводит к логическим разрывам связей с первичной документацией.
- Конструкторы и разработчики не вносят мелкие (зачастую оформительские, либо изменение номинала) изменения в проектируемые изделия, после выпуска извещений о корректировке, иными словами невозможно сказать насколько текущий электронный документ соответствует документу, находящемуся в ОТД.
- Проблемы заполнения спецификаций и перечня элементов:
- b) Библиотеки САПР P-CAD морально устарели и не соответствуют используемым на предприятии элементам, а так же они не содержат российских и советских элементов, принятых отраслевыми стандартами, в следствии чего разработчик вынужден создавать личные библиотеки элементов. Эти библиотеки между разработчиками никак не синхронизируются, что вызывает дублирование элементов, неверное истолкование элементов, а так же банальные ошибки, связанные с наименованием: допустим, «Конденсатор К-73-21б-500в 10А-0.1мкФ +- 10%» и Конденсатор К-73-21б-500в 10А-0.1мкФ +- 10%» при печати выглядят одинаково, но во втором случае в наименовании использованы английские символы. Т.е в базе создастся 2 элемента, и при автоматическом создании спецификаций и перечня покупных элементы не будут просуммированы.
8) Не существует единой системы разработки печатные платы и схем. Разработка выполняется в совершенно разных системах проектирования: cheemage, p-cad, orcad, visio, altium designer.
Как удалить Search — вредоносный поисковик (вирус) в браузере
Метаданные: Невидимая информация о файлах
9) В проектах, созданных в системе P-cad не заполнены элементарные, но необходимые атрибуты оформления (разработал… наименование, обозначение), эти параметры нанесены на лист текстом, основная надпись выполнена рисунком. Дополнительно необходимо заполнять design attributes, в меню file.
10) Система Search является параметрической системой, поэтому необходимо соблюдать правила заполнения атрибутов элементов, внесения на схему или печатную плату. Т.е. необходимо заполнять главные атрибуты элементов, из которых формируется полная запись в перечне элементов и спецификации, т.е.: наименование, тип, номинал, допуск, позиционное обозначение. Либо создать отдельный атрибут, например ПЭ3, в котором должно быть прописано полное наименование элемента. Во всех файлах, участвовавших в пилотном проекте «****» существовали следующие ошибки:
a) Атрибуты элементов на схеме (файлы *.sch) и печатной плате(*.pcb) и не заполнены
b) Атрибуты заполнены не полностью, например, проставлено только наименование «конденсатор», без номинала и остальных параметров.
c) Атрибуты от элемента к элементу различаются по составу и наименованию, например: для конденсатора С1 атрибут «description» содержит наименование, а для конденсатора С65 этому атрибуту соответствует поле «name».
d) Проблемы с качественным наполнением этих атрибутов:
i) Номинал указывается не по ГОСТу
ii) Номинал одинаковых элементов с разными обозначениями (мк и мкФ)
iii) Обозначение заполняется не полностью.
11) В ходе подготовки документов к загрузке выяснилось, что перечень элементов создается в отдельной программе – TDD, в которой неполные наименования, полученные из атрибутов системы P-CAD дополняются вручную пользователем. На основе исправленного файла формируется перечень элементов, который сдается в архив конструкторской документации в печатном виде. Утилита TDD позволяет пересохранять перечень элементов обратно, в файл проекта p-cad, чем самым приводя его к идеологически правильной форме, но этого не делается. Этот файл сохраняется рядом с файлами проектов.
12) Из п.10 вытекает новая проблема: при корректировке сданного в ОТД комплекта документов не исправляется файл TDD, следовательно не вносятся корректировки, а перечень элементов правится вручную.
13) На схемах разъемы обозначены как контактная площадка, а не групповой элемент или элемент из библиотеки, что порождает за собой массу элементов типа Х1… Хn в автоматически сгенерированном перечне элементов.
14) Имена файлов и наименования имеют «код», Search построен таким образом, что транслирует код в исполнение.
15) Altium Designer не имеет интегратора к системе Search, т.к. не существует открытого API. В подразделении 2070 совместно с разработчиками НТЦ-4. Ведется разработка обработки, позволяющей перегрузить данные в PDM систему.
16) Не существует единой библиотеки элементов систем разработки печатных плат.
17) Сданные в архив документы, не имеют электронных версий, либо поиск электронных версий затруднителен. Рабочие копии документации хранятся не структурированно, собрать все файлы по минимальной ячейке изделия – блоку не представляется возможным.
Иными словами, на данном этапе система находится на первом, практически на переходном 2 этапе из 3 возможных этапов внедрения:
1. Интеграция на уровне файлов. Подразумевает простейшие операции с данными: сохранить файл в PDM, открыть файл из-под ПДМ. В классификации систем автоматизации это даже не интеграция, а базовый функционал. При таком подходе PDM система заполняет свойства файла некоторой информацией из своих атрибутов, например: наименование документа, обозначение, разработчик, масса. Либо во внешней программе в стандартном интерфейсе используется появится кнопка- «сохранить в PDM», по нажатию на которую, открывает интерфейс PDM системы и у пользователя появляется возможность, в соответствии с правами его доступа и ролью в делопроизводстве, заполнить атрибуты карточки и поместить файл в каталог, соответствующий каталогу, текущей разработке.
2. Интеграция на уровне атрибутов. Под такой интеграцией понимается подход, при котором PDM система считывает атрибуты, находящиеся в файлах документов САПР систем. Разработчик в САПР имеет возможность создавать и заполнять любые согласованные с PDM системой атрибуты в своей модели / чертеже. Эти атрибуты располагаются в системной (отрытой области) файла и PDM система может их прочитать, создать внутри себя объекты и автоматически заполнить свои атрибуты. В этих атрибутах может содержаться как информация, относящаяся к основному штампу так и информация о применяемости, технологических замечаниях, материале детали, весе, и именах внешних ссылок ассоциированных файлов.
Пример: при загрузке в PDM систему 3D модели детали (набора файлов), система:
— обновит обозначение объекта-документа,
— заполнит атрибуты -наименование, разработал и.т.п,
— создаст объект – материал(или укажет на соответствие материала в БД) и укажет его обозначение/наименование если он был назначен на модель,
— заполнит атрибут объекта «деталь» значением атрибута «масса»
— сохранит файл и заполнит атрибуты «дата последнего изменения» и т.п.
3) Чтение электронной структуры изделия (ЭСИ). Иными словами полная интеграция PDM системы в различные САПР. Под таким подходом понимают получение состава, при этом подходе избегается ручной ввод объектов и заполнения атрибутов. ЭСИ содержится в 3D моделях сборки и в документе «спецификация», которые в свою очередь собираются из БД PDM системы, а спецификация напрямую связана с файлами документов.
Т.е. при загрузке документации PDM система читает ЭСИ (системные области файлов, созданных в САПР, где находится ссылки на документы, участвующие в сборке) после чего:
— создается иерархическую структуру изделия с имеющимися количествами деталей, стандартных и покупных изделий.
— далее по хранимым внутри файла ссылкам рекурсивно, для каждого элемента сборки:
-определяется тип объекта (деталь, сборочная единица, библиотечный элемент -крепеж),
-создается обозначение;
-заполняются атрибуты объекта;
-создаются объекты – «документы — 3Д модель детали», задается обозначение
— заполняются атрибуты документа
— сохраняется файл
Если обозначение входящего в сборку объекта системе известно (примененный), то система автоматически создаст ссылку «применяемость» и дополнит существующее дерево состава отсутствующими элементами из БД.
За плохое форматирование — отдельно прошу прощения, в следующем посте исправлюсь.
Источник: habr.com
Система документооборота и ведения архива
Еще буквально несколько лет назад явно ощущалась нехватка программ для создания пространственных моделей и рабочих чертежей изделий. Сегодня этот вопрос решен: на рынке САПР представлено большое количество графических пакетов как отечественного, так и иностранного производства. Однако, как только конструкторы и технологи начали плодить огромное количество документации, возникла проблема навигации в большом объеме электронных архивов графической и текстовой документации. После того как пользователи столкнулись с задачей ориентации среди различных версий, изменений и модификаций одного и того же изделия, стало очевидным, что начинать надо было не с модели и электронных рабочих чертежей, а с организации виртуальной среды обслуживания и контроля работы инженера со средствами САПР.
За рубежом существует немало программ, предназначенных для решения подобных задач, но все они не подходят для работы в наших условиях — требуется серьезная переработка, локализация и адаптация. Дело в том, что в России процесс работы с документацией, впрочем как и сам комплект рабочей документации, сильно отличается от западных.
Многих форм документов там просто нет, а некоторые технические вопросы, например проводки изменений, структура и оформление архива отличаются от принятых в России. В связи с этим многие разработчики начали активно заниматься созданием такого рода систем для удовлетворения спроса на нашем рынке. Требовалось решить задачу структурированного хранения комплектов электронных документов, поиска нужного документа или чертежа в соответствии с заданными ключами поиска, проводки изменений в архиве и сохранения при этом всех предыдущих вариантов. Помимо этого необходимо было решить проблему утверждения документов и проводок с помощью электронной подписи, технически реализовать процедуры быстрого просмотра выбранных документов и визуализации дерева проектов.
Однако, прежде чем начать разрабатывать новое программное обеспечение, неплохо было бы понять, что уже имеется. Оказывается, уже многие годы на рынке существует неплохая программа Search, разработанная Белорусской компанией ИНТЕРМЕХ. Программа решает задачи документооборота и ведения электронных архивов и на сегодняшний день является практически единственной законченной программой для решения подобных задач. С точки зрения пользователей система Search очень хорошо вписывается в сложившуюся на наших предприятиях методику работы с документами и проектами. Она значительно превосходит по своим функциональным возможностям недавно появившиеся отечественные и иностранные разработки для решения этого круга задач.
Ведение архива документов
Электронный архив программы Search представляет собой базу данных, в которой система хранит электронные документы, сопроводительную информацию и описание ключей поиска, необходимых для поиска, идентификации и выборки требуемых документов. С целью упорядочения документов в базе по их статусу (утвержден или не утвержден), типу (конструкторские или технологические и пр.) и другим признакам в Search предусмотрена модель единого электронного архива, включающего в себя все архивы различного назначения и статуса. Сами файлы документов хранятся централизованно на сервере, что обеспечивает авторизованный доступ к информации, облегчает процедуры резервного копирования и администрирования архива в целом.
Применяемая в Search уникальная технология сжатия файлов на клиентских ПЭВМ и передачи их на сервер в упакованном виде позволяет в несколько раз снизить трафик в сети, требования к установленному сетевому оборудованию, объемам и качеству аппаратных ресурсов как на сервере, так и на рабочих станциях пользователей. Файлы при этом запаковываются и хранятся в файловых шкафах в сжатом виде на рабочей станции.
Выбор способа сжатия зависит от скорости действующей сети и быстродействия рабочей станции, а также от наличия свободного места на жестком диске сервера. Существует несколько видов сжатия: быстрое, обычное и максимальное. После максимального сжатия файлы занимают в 1,4 раза меньше места, чем после быстрого сжатия, но на сжатие требуется в 2,5 раза больше времени. При максимальном сжатии чертежи сжимаются в 6 раз, текстовые файлы в 7 раз, документы, выполненные в программах Microsoft Word и Excel, — в 14 раз. Для процесса упаковки информации используется код, напоминающий код упаковки библиотек ZLIB.
Используемые в Search методы хранения информации позволяют снизить себестоимость хранения и обслуживания электронных документов. Например, для хранения 1 млн. сложных машиностроительных чертежей AutoCAD (при среднем размере файла 200 Кбайт) достаточно 50 Гбайт дискового пространства. В следующих версиях системы появится возможность хранения электронных документов непосредственно в библиотеках на магнитооптических накопителях с автоматической миграцией редко используемых документов на более медленные носители. Текущая версия Search позволяет использовать ленточные и магнитооптические накопители для хранения резервной копии базы данных.
Работа с документами и чертежами, входящими в состав изделия
Традиционно одной из основных функций PDM-системы является ведение состава изделий. Практически во всех системах данная процедура осуществляется с помощью интерфейса а-ля Windows Explorer. Это значит, что конструктор должен составлять проектируемое изделие из папок и документов, «воображая» при этом, что это редукторы, валы, винты и гайки. Насколько это удобно — вопрос спорный.
Однако разработчики этих систем не учли такого важного фактора, как применяемость изделий, в силу чего проектные связи в большинстве случаев нельзя представлять в виде дерева. Но это еще не самый большой минус — с получившимся ветвистым деревом на производство не пойдешь. Там нужен документ, выполненный в соответствии с нормами ЕСКД, то есть конструкторская спецификация.
Западные PDM-системы такой документ вообще игнорируют, для этого имеются свои стандарты (например, ВОМ, который рисуется на сборочном чертеже). В отечественных программах можно получить отчет, имеющий некоторое сходство с конструкторской спецификацией, но не учитывающий правила сортировки, простановки позиций, отличия в бланках групповых спецификаций и т.д. Кроме того, этот отчет нельзя сохранить в архиве в качестве документа, а ведь конструкторская спецификация является главным документом, определяющим состав выпускаемого изделия.
В Search ведение проектов организовано совершенно иначе. В состав системы входит редактор конструкторских спецификаций (рис. 1). Спецификации создаются и хранятся в системе точно так же, как и остальные документы. Конструктор оформляет спецификацию для сборочного узла, а система по ней строит проектные связи.
Если используется весь комплекс программ ИНТЕРМЕХ для автоматизации рабочего места конструктора, включающий в себя чертежную систему CADMECH, редактор текстовых документов AVS, базу данных справочных материалов IMBASE, то конструкторские спецификации генерируются автоматически в соответствии с разработанным сборочным чертежом изделия. Сами же чертежи и трехмерные модели создаются с помощью такого рабочего места конструктора гораздо быстрее, чем в так называемых тяжелых САПР, считающихся таковыми не потому, что многое умеют, а потому, что в них очень тяжело сделать что-нибудь не очень сложное.
Редактор спецификаций, входящий в состав комплекса, позволяет создавать как единичные спецификации, так и групповые формы А и Б, а также зеркальные спецификации. Можно настроить форму вывода спецификации в соответствии со стандартами конкретного предприятия, установить сложные правила сортировки и нумерации записей и т.д.
Кроме того, в спецификациях поддерживаются заменители: конструктор может записать, какие из позиций допускается заменять на другие, и эта информация будет учтена в будущем при получении состава изделия. По записям в спецификациях система Search ведет базу данных изделий предприятия, в которую попадают все сборочные узлы и детали (даже если на них еще не созданы конструкторские документы), а также стандартные и прочие изделия и материалы.
Сформировав такую базу, в дальнейшем при составлении спецификаций можно выбирать из нее записи и вставлять их в нужные разделы спецификации. В Search встроены очень мощные средства для просмотра состава и определения применяемости изделий. Во-первых, есть возможность просмотреть и распечатать информацию о составе и применяемости изделия в виде таблицы (рис. 2), а также экспортировать ее в большое количество форматов баз данных и электронных таблиц. Для групповых изделий можно получить список различий в исполнениях.
Одним из важнейших достоинств Search является возможность получить развернутый состав и применяемость изделия с учетом единиц измерения, что присуще только большим и дорогостоящим системам. Это позволяет службам снабжения предприятия получить полную информацию о потребности в комплектующих и материалах при производстве того или иного изделия. В программе Search предусмотрен режим графического представления структуры изделия в виде схемы, которая позволяет наглядно проследить связи между изделиями (рис. 3). В обоих режимах имеется возможность сделать невидимыми те или иные узлы, что упрощает чтение схемы, а также исключает из схемы изделия или детали узлов, которые поставляются на предприятие уже в собранном виде.
Разработанный конструкторский документ обязательно должен быть классифицирован — ему должны быть присвоены обозначение (децимальный номер) и наименование. Search предлагает механизм подключения любого используемого на предприятии классификатора. Немаловажно и то, что в базовую поставку системы уже включен иллюстрированный классификатор в соответствии с ЕСКД.
Процедура проводки изменений в документах
Очень важным в процессе работы с технической документацией является вопрос сопровождения документации на протяжении всего жизненного цикла выпускаемых предприятием изделий. Изменение конструкторских и технологических документов строго регламентировано стандартами, требует выпуска сопроводительных документов (извещений об изменениях), строгих процедур согласования всех изменений и зачастую занимает больше времени, чем разработка и выпуск самой документации.
В современных зарубежных и отечественных системах, предлагаемых компаниями «Аскон», «Топ Системы» и Autodesk, Inc., проблема обычно решается путем простой регистрации изменений, происходивших с тем или иным документом за время его существования. С помощью более мощных систем от компаний SAP и Unigraphics можно сохранить предыдущие версии измененных документов; это позволяет определить, что было изменено в той или иной версии документа. На практике определить, какой из сотни размеров на чертеже формата А0 был изменен, не сразу сможет даже специалист, разработавший этот чертеж. Автоматически зарегистрировать изменение конструкторской спецификации в таких системах вообще невозможно, поскольку спецификаций как документов там просто не существует.
В программе Search все изменения в утвержденных документах могут производиться на основании извещений об изменениях. В состав системы входит специализированный редактор для оформления извещения в полном соответствии с требованиями ЕСКД.
Поскольку на многих предприятиях безбумажная технология пока еще относится к технологиям будущего, существует необходимость вывода документов из электронного архива на бумажные носители. Search проводит изменения в бумажных копиях документов различными способами: автоматической заменой (перевыпуском) старой версии комплекта документации на новый и традиционными способами, то есть замещением мест изменений на новые, дописыванием изменений в существующие документы и т.д.
Электронная версия документа всегда соответствует последней его редакции и после утверждения извещения становится действующей. Для просмотра истории изменений в документе программа Search сохраняет его предыдущие версии в архиве и ведет список модификаций. Кроме того, Search позволяет выпускать предварительные извещения и предложения об изменениях.
Извещения могут выпускаться как на один, так и на несколько документов. Бланк извещения может быть отредактирован администратором системы с помощью редактора бланков. Редактор извещений (рис. 4) позволяет вставлять в извещения графические и текстовые фрагменты из документов, выполненных при помощи любых редакторов и текстовых процессоров. Для автоматизации процедуры согласования документов в Search имеется маршрутизатор документов.
Работа в сетях Intranet/Internet
Глобальные сети перестают быть чем-то недоступным, и все больше людей осознают преимущества, которые предоставляет предприятиям единое информационное пространство, объединяющее головные офисы, заводы, НИИ и другие компании, участвующие в общем научном или производственном проекте. Однако приложения, написанные для работы в локальных сетях, не всегда могут работать в глобальных сетях, поэтому еще два-три года назад большинство западных систем документооборота были снабжены модулями, позволяющими получать доступ к единому хранилищу документов предприятия из глобальных сетей. Отечественные разработчики, видимо, считают, что глобальные сети достаточно дороги для российских предприятий, поэтому очень мало отечественных систем документооборота имеют модули, обеспечивающие удаленный доступ к документам. Программа Search для этих целей имеет модуль Search Remote Client, позволяющий из Web-браузера получать доступ к документам, хранящимся в архивах Search, подключенных к Internet (рис. 5).
Использование Search Remote Client позволяет:
- получать доступ к документам с любого компьютера, подключенного к глобальной сети, независимо от его географического расположения;
- использовать для работы с документами любую аппаратную платформу и операционную систему с Web-браузером;
- публиковать описание выпускаемых на предприятии изделий прямо в Internet;
- снизить требования к аппаратной части ПК и сетевому оборудованию.
Search — комфорт и удобство в работе
При ведении архивов технической документации постоянно возникает необходимость быстрого просмотра их содержимого. Для этих целей Search оснащен системой SHOW, позволяющей просматривать чертежи, выполненные в AutoCAD и Mechanical Desktop в формате DWG, либо чертежи других CAD-систем в формате DXF (рис. 6). С помощью SHOW также можно просматривать файлы в форматах SLD, SLB, ВМР, WMF, EMF, ICO, JPG, GIF, TIF, PCX, TGA, FLI, FLC, IFF, PIC и PNG.
Программа обладает достаточно широким набором функций для просмотра и анализа чертежей:
- масштабирование, панорамирование, просмотр общего вида;
- просмотр чертежа по слоям;
- просмотр пространства листа и пространства модели;
- просмотр модели в тонированном виде;
- просмотр моделей, созданных в Mechanical Desktop;
- выбор и просмотр блоков чертежа.
Имеется также возможность нанесения на чертеж замечаний и исправлений в режиме red-line без изменения самого чертежа.
Анализируя эти и другие возможности программы Search, можно отметить, что эта отечественная разработка при сравнимых с иностранными системами возможностях стоит в 10 раз меньше. В связи с тем что программа имеет интуитивный интерфейс и повторяет уже сложившуюся на предприятиях систему работы с документацией, ее освоение не требует дополнительных затрат на обучение и дальнейшее сопровождение. Разработчик Search — компания ИНТЕРМЕХ — работает на рынке уже более 10 лет, постоянно совершенствует свою программу и ежегодно выпускает ее новую версию, расширяя возможности пользователей по работе с электронными документами. Стабильность разработчика программы, ее постоянное техническое совершенствование, простота освоения, разумная цена — все эти свойства Search, несомненно, являются очень привлекательными для пользователей. Поэтому в настоящий момент около 3 тыс. пользователей на более чем 170 предприятиях в России и СНГ отдали предпочтение программе Search и активно используют ее в работе и организации электронных архивов и документооборота.
«САПР и графика» 11’2000
- ведение архива
- навигация в архивах
- документооборот
Источник: sapr.ru
Search линейка Search/Techcard
Search — система корпоративного уровня, предназначенная для решения следующих задач:
- Управление данными об изделиях (в западной терминологии PDM — Product Data Management);
- Управление жизненным циклом изделия (PLM — Product Lifecycle Management);
- Ведение электронного архива технической документации (TDM — Technical Data Management);
- Управление документооборотом предприятия (Workflow);
- Управление проектами (Project Management).
Система Search построена в современной трехуровневой архитектуре клиент-сервер, в которой в качестве сервера базы данных может использоваться одна из СУБД промышленного класса — ORACLE, MS SQL Server или INTERBASE.
Возможность выбора СУБД и, соответственно, платформы для сервера базы данных обеспечивают необходимую производительность и масштабируемость системы для заданного количества пользователей — от архива рабочей группы, до архива крупного предприятия с сотнями одновременно работающих пользователей.
Что входит в состав Search
Search
cистема управления данными об изделиях, ведения архива технической документации и документооборота предприятия
IMShape
программа поиска 3D-моделей, основанная на сравнении геометрической формы
IMViewer
программа для просмотра, анализа и визуального взаимодействия с 3D-моделями, разработанными в различных CAD-системах
Showmini
программа для просмотра векторных и растровых графических форматов
Редактор шаблонов процессов
программа для создания и редактирования шаблонов и процессов документооборота
Редактор бланков
программа создания бланков для различных типов документов
По своим функциональным возможностям система ориентирована для использования на крупных, средних и малых предприятиях, предъявляющих высокие требования к электронному документообороту и ведению базы данных выпускаемых и используемых на предприятии изделий.
Благодаря многолетней успешной эксплуатации на сотнях предприятий, Search выгодно отличается от других западных и отечественных систем своего класса, прежде всего:
- комплексностью и тщательностью проработки решаемых задач;
- наиболее полным соответствием стандартам ЕСКД (без противоречия западным стандартам);
- адаптированностью системы для отечественных машиностроительных и приборостроительных предприятий;
- выгодным соотношением цена/качество.
Search + IMProject
Модуль управления проектами IMProject обеспечивает решение задач календарного планирования, координации и контроля коллективной работы по проекту с представлением сетевого плана-графика работ/задач в виде диаграммы Гантта.
IMProject не входит в стандартный комплект поставки Search и приобретается отдельно.
Search + IPS WebPortal
При помощи IPS WebPortal любой документ или объект, зарегестрированый в Search, может быть передан в базу данных удаленного предприятия или филиала.
Search API
Входящий в состав системы интерфейс прикладного программирования Search API позволяет получать доступ к любой информации, хранящейся в базе данных Search, из программ, написанных на любом языке программирования, умеющем работать с OLE/COM-функциями – Visual C, Visual Basic, Delphi и др.
Наличие API-интерфейса делает Search открытой системой и позволяет:
- разрабатывать собственные модули-расширения для реализации недостающих функций;
- интегрировать Search с используемой на предприятии системой АСУП/MRP/ERP и другими информационными системами.
Search + ERP / MRP / MRP II
На сегодняшний день имеется успешный опыт интеграции Search с такими системами ERP, как AXAPTA, Lipro, MAX, SAP, ИС-ПРО, 1С:Предприятие и другими. Реализована интеграция Search с системами АСУП предприятий. Для реализации механизма интеграции можно использовать встроенный API-интерфейс или универсальный формат обмена данными XML.
Республика Беларусь, 220004, Минск, ул. Короля, 51
+375 17 311-45-50, факс: +375 17 373-21-53
Отдел маркетинга:
+375 17 311-45-65, +375 17 311-45-66, +375 17 311-45-67
Отдел внедрения:
+375 17 311-45-81, +375 17 311-45-86
Техническая поддержка:
+375 17 373-21-43, +375 17 311-45-63, +375 17 311-45-68
Решения IPS
- TDM | PDM | PLM | Workflow
- Единая база НСИ
- Интеграция с CAD/ECAD системами
- Автоматизация конструкторского проектирования
- Автоматизация технологической подготовки производства
- Поиск и унификация 3D-моделей
- Интеграция с MES, ERP, MDC, MDA
- Территориально распределенная работа
Как работает IPS
Продукты IPS
- Преимущества IPS
- Модули IPS
- Архитектура IPS
Продукты Search/Techcard
Поддержка
- Обновить IPS
- Обновить Cadmech
- Обновить Search/Techcard
- Обучение
- Форум
Источник: intermech.ru