Зачем нужна интеграция EPLAN и ERP?

Хочу поговорить об интеграции платформы EPLAN с ERP системами с точки зрения организации такой интеграции. Эта заметка начнёт серию публикаций о роли Платформы EPLAN в IT-ландшафте предприятия и будет первой. Вторую посвятим техническим деталям и требованиям к интерфейсу визави — ERP.

Идея поговорить об интеграции именно в таком формате возникла в силу того, что формат подачи этой темы до сего момента был чересчур сфокусирован на деталях и незаслуженно игнорировались вопросы среди которых: «Что собственно хотелось бы получить от такой интеграции?», «Какие сложности ждут на пути?», «Что будет неочевидными выгодами?»

Итак, какие ассоциации у Вас возникают когда у Вас возникает идея «подружить» EPLAN c ERP системой? Наверное одной из первых будет ассоциация «Как передать информацию для закупки комплектующих в 1С?». Из чего следует, что хотя 1С, во-первых, не является единственным российским разработчиком ПО класса бизнес информатика, а во-вторых, 1С не всегда равно ERP, все же распространенность продуктов этой компании делает своё дело и придает смысл отожествлению 1С = «ERP любого производителя». К тому же много из изложенного будет справедливо и для ERP и для иных производителей. Поэтому в тексте ради лаконичности прошу мне разрешить такое допущение.

Наверняка, сейчас у вас закупка комплектующих через 1С работает на основе какой-то имеющейся и постоянно пополняемой номенклатуры компонентов, и как-то решен вопрос ее пополнения — либо вручную, либо в какой-то мере автоматизировано. Например, через промежуточный файл формата xml или Excel. Таким образом, существуют две независимые базы данных комплектующих и как минимум договоренность между конструктором и логистом как логисту опознавать (идентифицировать) отдельные карточки комплектующих. И зачастую договоренность заключается в сравнении какого либо человекочитаемого поля карточки, например поля «Наименование» = «Лампа индикаторная светодиодная красная 220 В, SE028963525» Эта практика имеет изъян, который заключается в том, такое поле обычно не имеет ограничений и правил ввода (маски) символов. Это ведет к возможности создать в базе данных две карточки никак не отличимых друг от друга комплектующих. Можно конечно договориться о таких ограничениях, но тогда получим второй изъян – отсутствие свободы в описании элемента, а они, что естественно принадлежат различным инженерным дисциплинам и описать, например, насос и контроллер одним шаблоном нереально. Поэтому выходом из ситуации выглядит переход на машиночитаемый идентификатор элемента и вот на такой идентификатор уже применить ограничения и маску.

Для таких целей база данных изделий платформы EPLAN имеет специально для этого предназначенное поле «ERP номер». В самом минималистическом случае это поле может быть единственным общим полем БД изделий платформы EPLAN и БД НСИ 1С. То есть, все специфичные для конструктора свойства элементов «живут» только в БД платформы EPLAN, напротив, специфичные для закупочных и логистических процедур в БД НСИ 1С. Требуется только организовать процедуру, обеспечивающую поддержание идентичного состава элементов в БД EPLAN и БД НСИ 1С.

Таким образом, мы создадим предпосылку к решению задачи передачи спецификации закупаемых комплектующих – синхронизировать БД платформы EPLAN и 1С. Такая синхронизация нужна для того, чтобы 1С могла однозначно опознать (идентифицировать) элемент по его «ERP номеру» внутри передаваемого перечня (спецификации). Далее останется только сформировать пакет данных, содержащий как минимум идентификатор элемента с количественной характеристикой, понятной на стороне 1С в виде отношения «идентификатор элемента, количество». Технические детали формирования пакета данных, его состава, типа транспорта планирую осветить во второй части. И так подведем некоторый итог. Мы поняли, что необходимо сделать для передачи перечня комплектующих. Но остаются еще некоторые важные аспекты.

Суть вопроса в том, какая из систем будет играть роль главной EPLAN или 1С? То есть, где будут изначально появляться новые элементы? Описанная выше процедура передачи данных предполагает, что в платформе EPLAN. То есть EPLAN играет роль инициирующей стороны. Но обратная ситуация также может иметь право на жизнь. Например, когда компания хочет иметь ограничительный перечень комплектующих и организационную процедуру его поддерживающую – создание новых элементов на основе заявки с утверждением ответственным специалистом. В этом случае пакет данных должен поменять направление и идти по маршруту 1C —> EPLAN. Это один из вопросов, на которые нужно дать себе ответ перед тем, как приступить к реализации.

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

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

Одним из частых вопросов наших заказчиков, применяющих EPLAN всегда был вопрос: “Есть ли возможность подсказать инженеру какие элементы или уже есть на складе или могут быть поставлены в разумные сроки с целью использовать именно их в проекте?” Да, реализация такой интеграции между ПО EPLAN может помочь в этом случае. Для этого лишь нужно так настроить объём передаваемой информации из НСИ 1С в БД изделий EPLAN чтобы, например, поля “Доступность на складе” и “Наличие на складе местного поставщика” были созданы для элемента в БД изделий EPLAN и обновлялись с заданной периодичностью из НСИ 1С. Тогда, пользуюсь широкими возможностями фильтрации и сортировки пользователь EPLAN мог бы быстро находить и применять такие комплектующие.

Можно пойти дальше и задуматься об автоматизации резервирования уже примененных в текущем проекте комплектующих для исключения превышения лимита доступных комплектующих, если идёт параллельная работа над несколькими проектами. Для этого можно создать процедуру, которая будет в непрерывном режиме поддерживать промежуточную, то есть актуальную в конкретный момент времени, спецификацию актуальной же и на стороне 1С. То есть, например, поле “Доступность на складе” будет отражать актуальный остаток с учетом резервов, выданных в адрес конкурирующих проектов.

Поскольку Платформа EPLAN имеет инструменты для конфигурирования выпускаемых проектов и продуктов EPLAN Preplanning и EPLAN Cogineer, то может возникнуть задача предварительной, например, на этапе технико-коммерческого предложения оценки стоимости комплектующих. Соответственно для такой оценки в БД EPLAN не хватает наличия цен комплектующих, актуальных на момент выставления предложения, хотя и такое поле в БД EPLAN предусмотрено. В этом случает потребуется всего лишь включить в пакет передаваемых данных из 1С в EPLAN поле “Цена”. А уже “движок” генерации отчетных документов Платформы EPLAN замечательно справится с формированием и визуальным оформлением предложения.

Тема практически зеркальна предыдущей. В этом случае речь наоборот идет о том, что некоторые документы, такие как таблицы с данными о комплектующих сложной и не поддающейся без привлечения EPLAN API реализацией проще реализовать средствами 1С. Например, документ Спецификация оборудования изделий и материалов по СПДС, где есть довольно запутанная и своеобразная группировка изделий по их классификации на «Приборы», «Комплексы», «Сборочные единицы» и т.д. Так же мне встречались в практике примеры, где компоненты собраны в некие комплекты и принцип этих комплектов неведом проектировщику, а связан с сугубо логистическими аспектами. Причем эта классификация никак не участвует в собственно процессе создания проекта EPLAN. В таком случае имеет смысл реализовать логику генерации документа на стороне 1С.

Надеюсь, что раскрыл тему в достаточном объёме. Буду рад если пробудил интерес к вопросу, а может быть навёл на какие-то продуктивные идеи. За кадром остались технические подробности настройки EPLAN. Надеюсь на вдохновение сделать продолжение.