EPlan. Отчет об эксплуатации

В глобальном плане, с тех самых пор, как в далеком уже 2009 году я прошел базовый курс обучения Eplan Electric P8, внедрил это программное средство в процесс разработки схемотехнических решений на нашем предприятии, ничего не изменилось. Мы по прежнему рисуем схемы в EPlan.

С  того времени в самом продукте произошло много изменений (http://www.eplan-russia.ru/ru/kompanija/novosti/vse-novosti/), но мы их специально не отслеживали. Как работали с EPLAN Electric P8 2.1 SP1, так и работаем. И тому есть много причин, о которых, с учетом уже многолетнего опыта я и хочу поведать.

1)  Когда наша команда столкнулась с этой платформой первый раз, все были очарованы тем, что часть рутинных функций автоматизирована. Это казалось большим достижением. Повышение эффективности и все такое. Был запал и интерес, чуть-чуть поработали на демке, потом купили одну лицензионную копию. Я сходил на курсы, написал методичку для сотрудников, которым по роду деятельности надо было разрабатывать схемы. Стали работать. Сейчас, с учетом накопленного житейского опыта, я бы уже так не поступил… В смысле — не стал торопиться.

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

За время работы ко мне много раз приходили представители компаний, продвигающие тот или иной софт. И скажу, что многие из них предлагали программное обеспечение не хуже, а по каким-то параметрам и лучше, нежели EPlan. Но, увы, мы когда-то потратили приличные деньги — и менять что-либо (особенно в условиях не проходящего кризиса) стало поздно.

2) EPlan для нас остался узкоспециализированным программным продуктом, для которого была наработана база типовых схем и база элементов в виде Microsoft SQL Server. Теперь задача «что-либо разработать «с нуля»» уже практически не ставится. Используется шаблонный проект (которые уже на все случаи жизни), немного дорабатывается, меняется комплектация согласно ТЗ. Все! Выпускается документация. Работа с программным продуктом сведена к минимуму. Менять что-либо, даже для большего удобства сотрудников слишком затратно. Не то нынче время, чтобы проводить эксперименты. Работает, отлажено — и бог с ним. Еще раз подчеркну, EPlan используется только для разработки схем, ни для каких других задач нам его настроить не удалось.

3) С определенными для него задачами EPlan справляется, хотя иногда и выдает необъяснимые сюрпризы, как правило, в спецификациях. И некоторые полезные функции автоматизировать так и не удалось, например, маркировку проводников. Для нас это ручная операция, увы. Еще одна беда, которая иногда случается с нами — KKS. Кто в курсе, тот поймет.

4) Я сознательно не акцентирую внимание на тех самых задачах, с которыми EPlan справляется на «отлично». О них вам расскажет любой представитель компании-разработчика. А вот о проблемах и минусах применения им говорить, думаю, запрещено. Поэтому пройдемся по тем, критериям отбора, о которых я написал выше. Так что с ними?

а) Цена.

Без комментариев.

б) Оптимальное решение стоящих перед компанией задач.

У каждой организации задачи свои, повторюсь. Но надо думать и на перспективу. Пока у нас не было своего щитового производства, схем и эскизов щитов было достаточно. Полноценным строительным проектированием тоже тогда не занимались, работали с известными Заказчиками, которых предоставленная в pdf-версии документация устраивала. Пусть не по ГОСТ, зато в достаточном для эксплуатации объеме. Потом стало хуже… С эскизами, кстати, были проблемы. Мы потратили уйму времени, чтобы подвязать к базе габаритные размеры, макросы внешних видов для оборудования… но все работало в EPlan так криво и косо, что практика готовить чертежи в нем не прижилась. При значительном количестве элементов весь внешний вид шкафа подвисал и что-то скорректировать, добавить становилось все труднее. Почему так, выяснить не удалось. Спрашивали службу технической поддержки, цитирую:

Как итог — инженерам легче и быстрее было накидать чертежи в КОМПАСе или даже nanoCADе.

Появилось щитовое производство, потребовалась 3d модель ошиновки и мы логично стали делать ее в КОМПАСе, благо элементная база была уже частично подготовлена. Исполнители от EPlan в этом разрезе плевались, поэтому тогдашний ECabinet даже не рассматривали. Может субъективное и эмоциональное решение, но какое есть! Купили КОМПАС. Знаю, что теперь функции ECabinet входит в EPlan штатно, но опять же, тратить время на создание базы, чтобы посмотреть, как это все теперь работает, мы уже не будем.

в) Учебная литература.

На этапе 2010-2011 годов полный провал политики компании-разработчика. Сначала было только дорогостоящее обучение в офисе компании, потом вышла одна книга (покупали в офисе и тоже за весьма дорого). В комплекте с продуктом, конечно, имелись обзор «Начало работы» и справочная система на русском языке. Начать работать можно, но функционал освоить в полной мере не получится. О справке вообще можно говорить бесконечно долго — удивительная штука! Вроде описано все, но при этом так, что разобраться без знания основ (то есть без предварительного обучения) ну никак! Очень много времени ушло сначала на самостоятельное освоение программы, потом после обучения (пошел потому, что было чувство, что половину функций так в полной мере запустить не удалось, хотя читали всем отделом методички и на немецком — сервер поднимали по ним) — на написание методичек. После выхода книги и запуска технической поддержки стало легче. Сейчас ситуацией не интересовался, уже не нужно.

г) Наличие квалифицированных пользователей на рынке труда.

На первом этапе тоже картина была печальная. Так, чтобы взять сотрудника и посадить работать, ну никак. EPlan долго был экзотикой. В последние годы ситуация изменилась. Регулярно встречаются резюме кандидатов, работавших в EPlan. Но, конечно, не так часто, как в AutoCAD и КОМПАС. И еще! Как мы стали выпускать проектную (рабочую) документацию для строительства, от нас постоянно требуют электронные комплекты документации в редактируемой форме AutoCAD. Экспортировать страницы из проекта EPlan в файлы dwg возможно, вопрос цены. Скажу так, времени и усилий это занимает достаточно. Я имею в виду нормальный экспорт, чтобы можно было с документами работать, читать, редактировать. Ладно, один раз пройти процедуру конвертации допустимо. Так при любом изменении документации — все по новой. А в уже сконвертированных файлах редактировать потом не вариант, оригиналы-то в EPlan, да и ошибок можно допустить больше…  Геморрой, одним словом.

д) Полнота технической поддержки.

Сейчас вопросом не интересовался, а ранее за доступ к телу эксперта требовалось платить. Сопровождение на год стоило денег не самых маленьких. Качество среднее. Отвечали оперативно, но ответы бывали иногда мутными, проблему не решали. Ну тут, наверное, как у всех.

е) Востребованность формата данных.
По сути уже написано. За все время работы с различными компаниями в России только два раза у нас приняли документацию в формате EPlan. И один раз на заводе «Фольксваген» в Калуге.

ж) Возможность реализовать дополнительные функции.

Что я имею в виду?

Ну вот были у нас две интересные идеи.

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

→ Но и более приземленная идея потерпела крах. Хотели хотя бы проекты АСУТП компоновать в проекте EPlan. Там ведь много документов: текстовые, схемы и планы CAD, рисунки — все в разных форматах. Казалось бы, создал структуру в менеджере проекта, добавляй файлы, удобно… и тут сразу из ниоткуда возникают проблемы с поддержанием актуальной версии составляющих проект документов. Изменения в них вносятся постоянно, разными исполнителями, отследить невозможно. Обновляются в проекте не всегда! Там поди разберись, заменили ли файлы в самом проекте, все мамой клянутся, что так и делали, но получилась какая-то ерунда. Но даже это вопрос больше организационный. Пронумеровать автоматически внешние файлы нельзя — все вручную. И самое печальное, не сделать из этого массива данных единого файла pdf для Заказчика. Внес два изменения, заново и вручную все компоную. Ерунда получается. При объеме даже в пару десятков проектных файлов — ну его к черту. Легче просто в папке одной все держать и там работать, пусть без структуры.

→ Расчет кабельной продукции. Не знаю, как сейчас, но раньше представители EPlan хвастались, что сделали макрос, автоматом считающий длину кабеля в зависимости от масштаба на графическом документе. В стандартный комплект программы это, естественно, не включалось. А реализовать самим… ну система EPlan настолько закрытая система, что написать макрос самостоятельно…

з) Адаптация к требованиям ГОСТ.

Больная тема для любого иностранного программного продукта.

Есть рамки по ГОСТ, можно доделать библиотеку символов, шаблоны разные. Есть отчеты, не все, которые нужны, но есть. Какие-то из них можно довести до ума, какие-то нет. По хорошему надо держать отдельного человека, который будет всем этим заниматься. Базы поддерживать актуальные, стандарты обновлять, внедрять, рассылать, исправлять… Но дорого это.

После того, как мы ушли из уютного мира проверенных Заказчиков, много раз сталкивались с тем, что схемы, разработанные в EPlane не устраивают конечного пользователя. Им надо все кондово, как в Советском Союзе. Чтобы на каждой строчки спецификации была одна строка текста, например. Поди такого добейся от буржуйского продукта…

Как-то так.

Далее, при наличии времени буду адаптировать и выложу некоторые материалы моих методичек.