В сентябре 2014-го руководство института СибГТУ «Сибгипробиосинтез» решило навести порядок в используемом программном обеспечении и тем самым повысить эффективность предприятия в целом. Модернизация коснулась всей ИТ-инфраструктуры института, и усовершенствование САПР было лишь одним из элементов этого масштабного проекта. Компания «ИнфоИндастри», в которой работает автор этих строк, участвовала в данном процессе как основной поставщик и интегратор по решениям САПР. Надеюсь, что статья эта поможет другим предприятиям избежать некоторых сделанных нами ошибок и не совершить собственных.

Проблемы заказчика

В институте работают сорок проектировщиков, коллектив в основном возрастной. До начала преобразований основным используемым ПО САПР была система AutoCAD, причем одновременно применялись разные версии — от 2007 до 2012, а лицензионная чистота на некоторых автоматизированных рабочих местах (АРМ) была весьма сомнительной. Такая же ситуация была и с системой проектной документации для строительства СПДС GraphiCS: разные версии, не на всех АРМ лицензионно чистый продукт. На части ПК был установлен бесплатный СПДС-модуль Autodesk.

Всё это приводило к массе издержек, среди которых наиболее существенными были следующие:

  • отсутствие единых настроек ПО;
  • отсутствие четкой структуры и правил ведения архива проектной документации;
  • отсутствие стандарта предприятия;
  • отсутствие плана развития САПР.

Такое состояние дел в целом является типичным для проектных организаций, и многие из них не считают необходимым что-то менять, предпочитая работать «как сложилось».

Выбор решения

Вариантов для изменения ситуации было немного. Первый из них — модернизировать существующую AutoCAD до актуальной версии и докупить не лицензированные ранее места. Преимущества данного решения состояли прежде всего в том, что AutoCAD – это высококачественный, стабильный, зарекомендовавший себя в работе инструмент. Кроме того, он уже хорошо известен, так что в случае его установки не потребуется переобучение сотрудников и не возникнет никаких проблем с переходом. Однако этот продукт очень дорог. Кроме того, в процессе модернизации ПО пришлось бы заменять оборудование для рабочих мест, потому что для новой версии программного продукта возрастают аппаратные требования.

Следующим вариантом выбора стал ZWCAD российской компании «ЗВСОФТ». Его преимуществом является невысокая стоимость при довольно сильных функциональных возможностях. Этот пакет совместим с форматом DWG (ODA), который использует AutoCAD. Вместе с тем имеют место существенные различия в интерфейсе и приемах работы. Серьезным ограничением было также отсутствие регионального представительства и прямого контакта с разработчиком.

И еще одна отечественная разработка — nanoCAD компании «Нанософт». Основными достоинствами этого продукта являются поддержка формата DWG (ODA), невысокая стоимость и наличие прямого контакта с разработчиком, а также присутствие официального дилера в Красноярске. Однако, как и в случае с ZWCAD, имеют место существенные различия в интерфейсе и приемах работы. Обнаружились и отдельные функции, требующие доработки.

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

Приступаем к внедрению

На самом первом этапе проекта мы с руководством института прежде всего организовали собрание полного состава всех проектных отделов. На этом собрании я как представитель вендора провел краткую презентацию продукта, а руководители подробно объяснили свои планы и мотивы действий. Все сотрудники должны максимально ясно представлять, что, зачем и почему происходит. Тогда же мы перечислили основные этапы перехода и ответили на вопросы, среди которых не обошлось и без пресловутого: «Как же мы теперь будем работать?!».

Второй этап – тестовая эксплуатация. Она проводилась для того, чтобы можно было еще до начала перехода снять некоторые вопросы и посмотреть, с какими трудностями придется столкнуться. Данный этап прошел из рук вон плохо. Несмотря на то что абсолютно всем сотрудникам объяснили, почему нужно работать в nanoCAD, делать этого почти никто не стал. Многие не поверили, что AutoCAD вообще исчезнет как инструмент работы.

Я считаю, что хороший результат в случае тестирования любого ПО – это как минимум четыре страницы с вопросами по итогам и ясное понимание как у руководства, так и у пользователей всех плюсов и минусов этого ПО.

Итак, если вы планируете тестирование продукта на предмет его применимости, сделайте следующее:

  • объясните всем сотрудникам цели установки демоверсии ПО;
  • требуйте развернутых письменных отчетов по тестированию;
  • выделяйте время для тестирования;
  • ставьте на период тестирования конкретные задачи для ПО и сотрудников.

Пользователям хотел бы посоветовать одно: применяйте тестируемое ПО насколько это возможно – только так вы сможете увидеть все его преимущества и недостатки.

Вполне ожидаемым оказалось, что базовым продуктом был выбран nanoCAD СПДС. Кроме того, институт приобрел ряд решений на базе nanoCAD. В качестве формы поставки выбрана «коробка» + подписка (для возможности обновления ПО). Лицензия сетевая, с привязкой к оборудованию.

Поставка и оформление ПО прошли в штатном режиме за две недели. Еще около двух недель заняли согласования настроек. В итоге мы пришли к следующей схеме:

  • сервер сетевых лицензий – один на все продукты nanoCAD;
  • один общий сервер базы данных для всех продуктов, использующих базы элементов/деталей на SQL (nanoCAD СПДС, nanoCAD «Механика» и др.). Не-SQL-базы (Microsoft Access) были установлены на локальные ПК (nanoCAD «Электро»);
  • один общий DWT-шаблон;
  • дополнительная папка шрифтов на сервере. Туда в дальнейшем сложили все «экзотические» шрифты.

Развертывание осуществлялось с помощью Microsoft Active Directory по предварительно настроенному нами дистрибутиву. Его настройка заняла некоторое время и во многом производилась при помощи разработчика nanoCAD. Оказалось, что у nanoCAD нет собственной системы развертывания, как у AutoCAD.

Но установка заняла полчаса. Под единичные продукты дистрибутивы не адаптировали, установили вручную.

Недоработки развертывания обнаружились потом. Так, системные настройки интерфейса хранились по умолчанию в каталоге Program Files, который у всех пользователей защищен от изменений. Каталог автосохранения файлов, назначенный по умолчанию, тоже оказался закрытым для редактирования. Эти настройки также пишлось менять вручную.

AutoCAD на данном этапе не деинсталлировали, и люди работали как раньше.

Переходим на новое решение

После установки еще раз провели собрание коллектива, на котором было объявлено, что, во-первых, через два месяца AutoCAD будет полностью удален с ПК, а во-вторых, nanoCAD установлен и готов к эксплуатации. Настоятельно рекомендовалось начинать работать в нем.

Отдельно был разъяснен порядок «конвертации» файлового архива. Он организовывался по сути заново, с несколько иной логикой и другими принципами, нежели раньше. Прежде чем попасть в новый архив, файл чертежа проходил все возможные стадии очистки и сохранялся в формате DXF, а затем открывался при помощи AutoCAD и сохранялся в DWG-формате. После этого открывался в nanoCAD и пройдя все проверки сохранялся уже окончательно.

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

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

К обучению мы приступили практически сразу после установки ПО. Сформировали группы по пятнадцать человек, на каждую было отведено по два часа в неделю – в определенный день и в заранее назначенное время. Основная задача первого этапа обучения – научить работать в nanoCAD СПДС как минимум с такой же производительностью, что и в AutoCAD. В данном случае усовершенствованные возможности AutoCAD, такие как динамические блоки, подшивки, внешние ссылки/совместная работа, аннотативность, практически не использовались, поэтому задача за короткое время выйти на прежнюю скорость работы была вполне реальной.

Сложнее всего оказалось ответить на вопрос, чему именно учить. Процесс работы и в nanoCAD, и в AutoCAD практически одинаков, рабочие инструменты тоже в большинстве случаев одни и те же. Поэтому, хотя я и подготовил стандартную программу обучения, менять ее приходилось по ходу событий. Это было обусловлено еще и тем, что у обучаемых разный уровень владения AutoCAD да и компьютерной грамотности вообще. В итоге кому-то изучаемая тема более чем понятна, а кому-то надо было объяснять и объяснять. Причем в разных группах по-разному. Так что для подобного обучения нужно либо проводить детальное тестирование на знание используемого ПО, да и на предмет компьютерной грамотности как таковой, и на его основе формировать группы, либо смириться с «разноуровневостью» аудитории.

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

К началу лета 2015 года основной курс обучения «платформа + СПДС» пройден, дальше планируется разбираться с решениями для вертикальных рынков, начав с nanoCAD «Электро».

В марте 2015 года вновь начатые проекты уже разрабатывались в nanoCAD, а AutoCAD был удален с рабочих мест проектировщиков. Реакция на это событие была довольно разной, от адекватного понимания необходимости изменений до нечасто встречавшегося, но кардинального неприятия нового ПО. Здесь нужна внятная и четко выраженная позиция руководства. Ворчуны и недовольные найдутся в любом коллективе, и задача начальства адекватно на это реагировать. Если уж вы, уважаемые руководители, решились переходить на другое ПО, то нужно строго следовать плану и доходчиво, но весьма жестко объяснять это сотрудникам. В начале активной работы с новым ПО интеграторы и разработчики вынуждены отвечать за всё — от действительных недоработок ПО до проблем, вообще никак с этим ПО не связанных.

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

Детальную статистику по вопросам я не подводил, но традиционно они подразделялись на три группы – примерно в равных долях:

  • проблемы, возникающие в ходе переноса унаследованных данных;
  • отсутствие некоторых функций (и вообще «хочу всё как было»). Например, в самом начале не было привязки со смещением и поворота видовых экранов. В nanoCAD 7 эти функции уже появились, а вот фильтра слоев по имени нет и сейчас;
  • трудности с восприятием нового ПО и технологические ошибки в работе проектировщиков (эти проблемы решались в ходе обучения и индивидуальных консультаций).

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