1-2-3, или Шпаргалка для построения системы комплексной автоматизации в проектной организации, работающей в области ПГС. Часть 1

Игорь Орельяна Урсуа

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

На правах сотрудников сапровской компании (крупнейшей в России и первой, которая более 10 лет назад занялась вопросами комплексной автоматизации проектирования) мы с коллегами решили написать серию статей, чтобы помочь руководителям служб ИТ и САПР, решающим проблемы внедрения.

О выборе поставщика

Если вы тот, кому руководство компании доверило развитие САПР, то должны понимать, что выбор поставщика — это вовсе не выбор того, кто предложит наименьшую цену. При выборе поставщика по минимальной цене вспомните, что скупой платит дважды, а скупой и недальновидный — всю жизнь!

На российском рынке немало компаний, иногда даже очень больших, которые громко кричат, что они суперские, что продают и продукты «Майкрософт», и антивирусы, и всякую всячину. Менеджеры этих компаний обещают неисчислимые и вечные блага. Но когда эти суперские парни замахиваются на святое — на САПР, то часто обнаруживается, что за громкими словами «комплексные решения», «учебный центр», «опыт внедрения», «служба поддержки» — коробки и только коробки. Что комплексные решения — это набор всех коробок, которые они продают. Что весь их опыт внедрения — не более чем опыт инсталляции программы на рабочих местах. Учебный центр в итоге оказывается одним­единственным преподавателем, подрабатывающим на полставки и слабо представляющим, как будет применяться то, чему он учит. А вся техподдержка — это девочка на телефоне, которая запишет вопрос и перешлет его разработчику. Остерегайтесь! Подобных контор сотни, если не тысячи!

Диаграмма осуществляемых работ

Обязательно убедитесь, что компания­поставщик специализируется на САПР, что у нее действительно есть опыт внедрения и учебные центры. Рекомендуем работать с компанией­интегратором, имеющей опыт поставки и внедрения САПР не менее четырех лет. Понятно, что, будучи сотрудником ГК «СиСофт», я рекомендую работать именно с нашей фирмой, но выбор в любом случае за вами.

Подсчитываем, что и сколько нужно

Предположим, что требуется автоматизировать процесс проектирования и вы — главный по САПР. При этом, как всегда и у всех, бюджет ограничен, желаний много, а кое­какой софт уже есть. Что делать?

Чтобы упростить жизнь ответственному за САПР, мы рекомендуем поэтапное внедрение с предварительным статистическим обследованием, разработанным в ЗАО «СиСофт».

При таком подходе весь процесс построения комплексной системы автоматизации разделяется на несколько этапов. Сначала потребности определяются исходя из необходимости автоматизировать деятельность инженера (программы для расчетов, конструирования и т.п.). Затем (или параллельно, если хватает ресурсов) организуется централизованное хранение электронных документов проекта. Для этого можно использовать систему TDMS в минимальной конфигурации. Далее формализуется электронный обмен заданиями (если применялась TDMS — просто расширяется конфигурация системы). Следом внедряется электронное прохождение внутренних согласований: инженер, главспец, начальник отдела, нормоконтроль, ГИП. Понятно, что развиваются и софт, и проектная организация, а это требует совершенствования и программ, и систем обеспечения (TDMS, NormaCS и т.д.).

Конечно же, существуют более правильные методы — например, внедрение комплексной автоматизации на основе процессной модели. Для этого сначала проводится процессное обследование, то есть строится детальная модель процессов предприятия как они есть. Потом формируется модель процессов как они будут. После получения модели «как будет» создаются переходные модели, в соответствии с ними перестраивается процесс проектного производства. Таким образом, шаг за шагом перестраивается работа всей проектной организации. Что касается программных комплексов, то они учитываются в моделях «как будет» и в переходных моделях. Если смотреть на такой метод издалека, то он кажется более правильным и (в теории) менее затратным, поскольку при внедрении новых технологий проектирования минимизируется количество ошибочных решений и приобретений. На практике подобный подход в чистом виде и в полном объеме применяется довольно редко — он чрезвычайно растянут во времени, а на начальном этапе еще и весьма дорог (требуются организация и содержание высококвалифицированной группы, моделирующей бизнес­процессы предприятия).

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

Другой пример: если внедряется система Smart Plant, PLANT­4D или что­то похожее, то процесс проектирования перестраивается под требования именно этой системы. Иначе она будет работать совсем не так, как задумано разработчиком, или не будет работать вовсе.

К сожалению, не всем и не всегда доступен самый правильный путь, когда производится процессный анализ того, как и с чем работают сотрудники, а по результатам разрабатывается новая модель производственных (проектных) процессов, определяющая, кто и как будет работать. Поэтому вернемся к ситуациям более простым: есть проблема, ее нужно решить побыстрее и с хорошим соотношением «цена/качество».

Конечно, при таком раскладе, когда нужно побыстрее, не стоит обращаться в отделы с вопросами вроде: «Тут шеф денег на САПР выделяет! Что ты хочешь, чтобы тебе купили?» Подобные действия крайне вредны для комплексной автоматизации: если покупать всё, что просят инженеры, получится «софтовый зоопарк», а это приведет к значительному удорожанию его содержания, почти наверняка исключит трехмерное проектирование и крайне затруднит взаимодействие между отделами.

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

Общий порядок обследования выглядит так:

1. Составляем список задач, решаемых каждым проектным отделом.

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

3. Соотносим с каждой задачей комплект софта, необходимый для ее решения.

4. Рассчитываем потребность в софте и определяем приоритеты автоматизации.

Давайте рассмотрим пример расчета для отдела изысканий проектной организации, проектирующей обустройство нефтегазовых месторождений¹.

В табл. 1 представлен список сотрудников, перечислены все работы, выполняемые отделом, и указана занятость сотрудников на тех или иных работах.

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

Таблица 1

Таблица 2

Таблица 3

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

Исходя из того, что программный комплекс нужен сотруднику постоянно, количество лицензий каждого ПО определяется путем сложения всех потребностей в работах, где это ПО встречается. Таким образом, получаем расчетные потребности в лицензиях (табл. 3).

Наряду с вычислением количества лицензий специалисты «СиСофт» всегда строят диаграммы работ, которые наглядно и понятно показывают, какие работы, исходя из трудозатрат проектировщиков, следует автоматизировать в первую очередь.

На диаграмме² видно, что наиболее трудоемкими оказываются работы по проектированию разбивочного плана, плана организации рельефа и плана земляных масс. Она же показывает, что комплект AutoCAD Civil 3D + GeoniCS охватывает порядка 80% всего объема работ отдела. Значит, прежде всего следует приобретать именно этот комплект, а остальное, в случае дефицита бюджета, можно перенести на следующий этап.

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

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

Узкое место метода — вопросы совместимости программ и проблема влияния внедряемого ПО на реорганизацию производства. Из­за того, что все программы имеют собственные требования к исходным данным, не всегда совпадающие с требованиями «ручного» проектирования, возможно появление сложностей. Чтобы избежать их и гарантировать правильность подсчета лицензий (это особенно важно для проектных коллективов, где трудится больше 40­60 проектировщиков), рекомендую заказать расчет у разработчиков метода или у их авторизованных представителей. Статистический анализ потребностей в САПР стоит весьма умеренных денег (от 100 до 300 тыс. руб.) и зависит от количества специальностей. Вы получите унифицированный список софта и количество каждого наименования, при этом список будет привязан к каждому проектировщику. Кроме того, будут профессионально сформированы (с учетом всех тонкостей и с привязкой к вашей организации) план приобретения софта, графики обучения работе с программами, расчет инвестиций на 1, 2 и 3 года (как правило, расчет ведется до 3 лет) и некоторая дополнительная весьма полезная информация.

В следующей статье цикла читайте о том, как обосновать инвестиции в САПР.

1 Несмотря на то что в таблицах представлены реальные показатели одной из организаций, для которой эксперты «СиСофт» проводили статистическое обследование, все имена и фамилии вымышлены, любые совпадения случайны и не имеют отношения к реальным людям.

2 Представлена диаграмма из статистического обследования, выполненного специалистами «СиСофт». Названия некоторых программных продуктов, зафиксированные в этом документе и на тот момент актуальные (Autodesk Civil 3D, PLATEIA), сейчас уже претерпели изменения. Autodesk Civil 3D переименован в AutoCAD Civil 3D, подругому пишется и название программы Plateia.

САПР и графика 3`2010