Основные проблемы внедрения систем управления проектными данными

Дмитрий Садовников, Виктор Афанасьев

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

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

Это серьезная ошибка! Систему должен выбирать узкий круг сотрудников (рабочая группа) по заранее составленным требованиям. Основная цель рабочей группы — провести подробный анализ предлагаемых систем на предмет удовлетворения запросов, после чего выбрать систему и, возможно, сформулировать требования по ее доработке (адаптации). Нужен именно анализ систем, не осмотр кнопочек, а детальное изучение возможностей настройки интерфейса и функциональности для конечного пользователя. Такой анализ требует, как минимум, времени на его проведение и некоторой квалификации, в том числе в ИT­области. Да, можно и даже, наверное, нужно собрать будущих пользователей, посвятить их в предстоящий проект внедрения, представить им рабочую группу и попросить не оставаться равнодушными и принять участие в составлении требований к системе. Но просматривать и выбирать систему должны не массы, а сотрудники из числа рабочей группы. В рабочую группу должны входить один­два сотрудника, хорошо знающие предметную область, сотрудники ИТ­подразделения, которым предстоит внедрять и обслуживать систему, и кто­то из руководства — как направляющая и руководящая сила. Если систему выбирают массы, то вместо изучения предлагаемых систем «выборы» превращаются в громкое обсуждение внутренних вопросов. Одни кричат: «Нет, вы показываете совсем не то, потому что у нас­то всё по­другому!»; другие кричат наоборот: «Всё правильно!» Остается только стоять в стороне с полуулыбкой и ждать, когда все эти жаркие междусобойные споры — рутинные и хорошо известные моменты в работе внедренца — нет, не окончатся, а на какое­то время утихнут. Тогда можно будет что­то еще продемонстрировать или ответить на заданный кем­то действительно важный вопрос! Это на самом деле так и повторяется практически в каждой организации.

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

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

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

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

Но автоматизация до нижнего уровня — это, на самом деле, свет в конце длинного туннеля. Это не начальная точка, а конечная!

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

Какие же участки проектного производства могут выступить в роли «подопытных кроликов» в процессе автоматизации? Универсальный ответ — электронный защищенный архив как средство управления интеллектуальной собственностью проектной организации. Задача и простая, и в то же время не очень. Простая для понимания, поскольку архивы в том или ином виде есть у всех, а у многих есть и электронные хранилища файлов. Не очень простая с точки зрения организационной: если традиционный архив устроен всем известно как, то при организации электронного архива следует учитывать перспективу. Что это значит? Простой пример. Сотрудник архива регистрирует в электронном виде комплекты документов (тома, книги…), при этом вырисовывается практически линейная структура документации: папка проекта (стадии проектирования), в ней длинный список карточек комплектов документов. Разделы, подразделы, части, площадки, объекты проектирования — всё это нивелируется до уровня поля карточки. В данном случае это естественно, поскольку сотрудник архива структуру проекта и не видит. Есть у него состав проекта — по нему он данные и вводит. Но в реальной жизни состав проектной и структуру рабочей документации определяет ГИП. Сотрудники производственных подразделений при работе в среде системы управления проектными данными должны видеть — вот мой раздел, вот мой объект, вот моя марка. И именно сюда я должен положить свои документы. Соответственно кто­то эту структуру должен ввести в систему (а впоследствии дать сотруднику права доступа). Это должен сделать либо ГИП, либо сотрудник архива. И в том и в другом случае для этих сотрудников возникают новые обязанности. Но ГИП в любом случае разрабатывает структуру, так что ему и карты в руки. Нужно просто переориентировать его на новую среду работы. При этом доступ к проекту получают и архив и подразделения. Архив в готовую структуру вводит карточки комплектов документов и документы, подразделения пока только пользуются поиском. Впоследствии проектировщики сами будут наполнять проект электронными документами. В небольших или очень хорошо организованных проектных организациях проектировщики могут сразу же наполнять проект электронными документами.

В помощь ГИПу Lotsia PDM Plus предлагает различные удобные инструменты, позволяющие управлять составом проекта. Как минимум, это возможности использования шаблонов, наследования данных и исключения повторного ввода одних и тех же данных. Применение шаблонов для проектной документации естественным образом диктуется необходимостью соблюдения «Положения о составе разделов проектной документации и требованиях к их содержанию», утвержденного Постановлением Правительства РФ от 16 февраля 2008 г. № 87. Но здесь важен тот момент, что в зависимости от объема проекта допускается дробление разделов проекта на подразделы и части. В больших проектах это дробление достаточно масштабно и может меняться до момента выпуска документации. Управлять составом проекта как обычно: с помощью текстового редактора, путем добавления или удаления строк таблицы, копирования и вставки фрагментов текста — можно, но это неприменимо в условиях коллективной работы в системе управления проектными данными. Поэтому в Lotsia PDM Plus в дополнение к возможностям шаблонирования используются возможности более глубокой детализации с наследованием данных. Текущий древовидный состав проекта можно просмотреть и в привычной, табличной форме, а также распечатать как готовый документ.

Выделение виртуальных папок «Графическая часть» и «Текстовая часть» в составе разделов проектной документации не является необходимым. Некоторые пользователи Lotsia PDM Plus так делают, но это не всегда обоснованно, поскольку все документы в Lotsia PDM Plus имеют разный тип и в дереве состава проекта сразу видна комплектация раздела (подраздела, части, книги, тома…). Лишний уровень папок в дереве может уменьшить степень удобства его визуального восприятия.

Для рабочей документации структура проекта в Lotsia PDM Plus обычно повторяет физическую структуру проектируемого объекта: площадка — объект — подобъект (впрочем, количество уровней неограниченно и легко настраивается администратором программы, без программирования). На каждом уровне свои формы, в которых отображается информация о площадке, объекте, подобъекте соответственно. Далее следует уровень марок, а в марках уже чертежи. Просто и понятно. А главное — привычно!

Непривычно на первых порах будет сотрудникам архива. Вместо обычного ввода данных в линейные списки придется вносить документы в соответствующие места электронной структуры проекта. Но после небольшого обучения этот вопрос должен быстро решиться.

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

Субподрядные работы — тоже весьма специфический момент. Кто­то отдает работы на субподряд, а кто­то нет. Надо учесть? Надо.

Множество заказов проектные организации получают, участвуя в конкурсах и тендерах. Учет предложений, выставленных для участия в конкурсе в качестве преддоговорных документов, кому­то необходим, а кто­то считает, что в систему вообще не следует вводить информацию, пока не подписан договор с заказчиком. Это еще один нюанс, который нужно учесть. Тем не менее организация электронного хранилища типовых тендерных документов — это реальная задача, реализация которой приносит пользу.

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

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

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

Таким образом, мы призываем при выборе и внедрении системы управления проектными данными руководствоваться следующим:

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

САПР и графика 2`2012