В последнее время просматривается
тенденция у ведущих «отечественных» разработчиков к переходу от разработки
отдельных приложений к системам на единой платформе (фундаменте).
Из чего состоит типовой комплекс
ПО для КТПП:
·
Система управления данными об изделии (PDM, у
Аскона и Топ Систем – PLM)
·
Системы проектирования (для конструктора),
расчета и пр. для работы с 2D и 3D данными (CAD, CAE,
CAM …)
·
Система проектирования ТП (САПР ТП)
·
Справочники
Системы для работы с графическими
данными специально оставил одной строкой – объединение функционала расчетных и
других систем на платформе той или иной CAD вопрос давно решенный. И речь пойдет о тех, которые записаны каждая
отдельной позицией.
И так, Топ Системы - платформа T-FLEX
DocsLine. Уже давно отказались от отдельной САПР ТП (ТехноПро, если кто-то еще
помнит) и функционал проектирования ТП включили в PDM T-Flex Docs. По справочникам, правда, как-то не много
информации на сайте. Есть отдельные библиотеки для CAD'а, а в остальном непонятно.
Компания Appius достаточно удачно
дополнила линейку 1С своей разработкой для управления конструкторско-технологическими
данными (PDM+САПР ТП), а совсем недавно перевела и Инженерный справочник на эту
же платформу (давно пора).
С выходом IPS в это течение
влилась и компания Интермех – в новом поколении ПО единая платформа для всех
продуктов разработчика. Список продуктов большой и их объединение, несомненно,
хорошая новость.
Какие же плюсы несет такая
архитектура ПО? В первую очередь отсутствие на стыке систем модулей интеграции,
которые по-сути являются отдельными программными компонентами и требуют
недюжинных усилий по разработке и сопровождению, постоянной поддержке различных
сочетаний версий интегрируемых систем. И этот плюс для поставщика софта не
менее ценен (а может и более), чем для предприятий-пользователей. Из минусов
для пользователей можно отметить ограничение на использование ПО только для
выбранной платформы, от одного разработчика (для поставщика это уже плюс).
Возможность интегрировать «сторонние» системы под лозунгом «лучший в классе»,
конечно, остается, но тут уже о проблемах см. выше. Еще одним из минусов можно
назвать то, что интерфейс универсальных систем, как правило, уступает
специализированным. Но решается это разработкой специализированный интерфейсных
модулей, которые работают с единой структурой данных (тот же Техкард у
Интермеха, специализированный интерфейс для справочника материалов у Интермеха
и SDI Solution и пр.).
Так что в целом переход от
интегрируемых приложений к единой платформе штука положительная как для
компании-разработчика, так и для предприятий-пользователей.
Но из этой
тенденции пока выпадает самый ведущий отечественный разработчик – Аскон! "Самый ведущий" это без шуток - по объемам продаж и количеству комплексных проектов остальным еще долго догонять.
Сейчас есть Лоцман, Вертикаль,
корпоративные, но все-таки отдельные справочники… Но сдается что что-то и в
этом королевстве затевается. Гольфстрим уже на платформе Лоцмана. Информации о
нем пока немного, выход на осень, но уже давненько можно почитать вроде как
официальный буклет на сайте Центра САПР. Странно, что на официальном сайте
разработчика пока ни чего нет. «Развод» с коллективом разработчиков Вертикали
тоже стимулирует фантазии о будущем этого продукта. Вот узнать бы чего там со
справочниками? Ждем новостей!
Не всегда наличие одной "платформы" означает, что разные системы оперируют с одной и той же моделью данных. Очень часто "единая платформа" означает "единая база данных" + некоторые системные функции. Уверен на 99%, что 1C:PDM работает со своей моделью, а потом скидывает состав изделия в справочник номенклатуры 1С:УПП. Скорее всего и Гольфстрим забирает данные из Лоцмана в собственную структуру.
ОтветитьУдалитьДа они на одной базе, на одной платформе, используют одни и те же ф-ции API, но модели все равно разные. Один и тот же "Болт" живет в двух ипостасиях - в модели PDM и в модели MRPII.
По сути это та же самая интеграция, но облегченная за счет того, что разработчику не нужно знать API двух систем, достаточно одной "платформы".
По другому и быть не может. Когда делали платформу 1С, про конфигурирование, исполнения и извещения об изменениях в PDM ничего не знали. Когда делали Лоцман, Гольфстрим на горизонте не маячил.
Ух ты! Первый комментарий! Иду за пивом ;)
УдалитьА если по существу. Насколько я понимаю в случае с 1С, например, объекты в системе создаются при помощи единого конфигуратора, их можно связывать и т.д. и т.п. - что это если не единая модель? То как работают (взаимодействуют) различные конфигурации это уже вопрос второй. Но ни кто не мешает использовать единые справочники системы в разных решениях (на разных АРМ). И даже если сейчас это как-то не так, то время все расставит на свои места. Тут больше вопрос не в конкретных реализациях, а в тенденциях. У Топ Систем была САПР ТП от Вектора интегрированная с PDM, теперь все в одном флаконе. Интермех выпустил IPS и т.д. Для пользователей меньше проблем, для вендора - шире охват, больше денег. А интеграция, какая бы "безшовная" она не была - таит в себе много подводных камней. Очень много. И швы где-то все-таки есть.
2 коммент, тоже за мной.
Удалить>>- что это если не единая модель?
Пример, в PDM есть исполнения. Т.е. объектная модель спроектирована таким образом, чтобы можно было вести общий состав, но очень быстро можно было получить состав в контексте конкретного исполнения. Подобная специфика отражается на объектной модели.
У ERP другая специфика и другая модель. Да и справочники разные. в ERP смотрят на объекты с точки зрения логистики (закупается, производится), в PDM - с точки назначения. В PDM стандартные и прочие изделия (по спецификации), в ERP есть ПКИ и производимые изделия, и это не одно и тоже. Поэтому один и тот же объект в PDM живет в составе как СтИ, а в ERP как ПКИ. Но плюсы есть конечно - на одной платформе просто делается связь "одно и тоже" между этими объектами, а в случае интеграции необходимо их шифровать кодами, делать перекодировочные таблицы или запминать "чужие" идентификаторы, с ограничением целостности опять же проблема.
На мой взгляд, сегодня основной риск при интеграции, это организационный - трудно найти аналитика, разбирающегося и в ERP и в PDM, а также программиста, знающего API обеих систем. При "единой платформе" часть таких проблем снимается. Но предприятие уже не построит инфраструктуру по принципу "Лучшие в классе".
Ну модель не совсем "другая", атрибуты - да. Могут связи между объектами отличаться. Но данные в результате те же. Это подтверждается и тем, что при интеграции из САПР ТП в PDM, из PDM в ERP данные передаются в "похожие" атрибуты. В справочниках та же ситуация. В целом спорить не буду, всё где-то так. А на счет построить на "лучший в классе" так возражений не было. Только надо понимать кто отвечает за интеграцию, за тестирование интеграции при выходе новых версий ПО (не всегда синхронно), и кто за это платит. Много внедрений сейчас именно так и работает (на "интеграторах") даже от одного и того же разработчика :). Но со стороны предприятия главное сразу определить кто за что отвечает, в каком временном периоде и за какие деньги. Просто решение на одном "фундаменте" некоторых проблем лишено изначально...
Удалить