К вопросу о выборе решения для автоматизации управления проектной деятельностью

Дмитрий Садовников, Николай Ширяев

Как показала практика последних лет, внедрение автоматизированных систем управления проектной деятельностью (АСУ ПД) позволяет проектным организациям архитектурно­строительного профиля существенно сократить временные и финансовые затраты на выпуск проектной документации.

Особенно большой вы­игрыш дают системы, позволяющие автоматизировать все бизнес­процессы проектного производства, включая выдачу задания смежному подразделению (рис. 1) и формирование комплекта документации для передачи заказчику или для загрузки на портал государственных услуг Российской Федерации для прохождения государственной экспертизы проектной документации и результатов инженерных изысканий (рис. 2) и т.д.

Рис. 1. Шаблон бизнес-процесса «Выдача задания смежному подразделению» в Lotsia PDM PLUS

Рис. 2. Комплектация документации для государственной экспертизы

Современные АСУ ПД позволяют автоматизировать формирование структуры проекта с учетом требований Постановления № 87 Правительства РФ, охватывают весь цикл деятельности предприятия: от организации участия в конкурсах (тендерах) и автоматизации преддоговорной работы, включая полный цикл разработки проектной и рабочей документации, организацию взаимодействия с контрагентами и субподрядчиками и заканчивая экспертизой и авторским надзором.

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

Но при выборе АСУ ПД организации зачастую допускают ряд ошибок, которые могут привести к затягиванию времени внедрения, а то и к срыву внедрения системы.

Далее рассматриваются некоторые аспекты, влияющие на успешность внедрения АСУ ПД.

Постановка задачи внедрения системы

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

То есть в первую очередь выбор решения должен быть осознанным.

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

Помимо основных целей внедрения в ряде случаев могут быть определены дополнительные («попутные») цели, достигнуть которых позволяет внедрение АСУ ПД, например управление конкурсной документацией или документацией СМК [1], ведение реестра договоров (рис. 3), входящей и исходящей корреспонденции [2].

Рис. 3. Ведение реестра договоров

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

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

Разработка технического задания

Разработка технического задания на АСУ ПД —  это очень важный этап, без которого говорить о качественном внедрении практически невозможно. К сожалению, как показывает практика, большинство организаций на момент начала выбора системы не имеют не только технического задания на нее, но и минимальных технических требований.

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

Тем не менее, в соответствии с требованиями ГОСТ, техническое задание должно разрабатываться совместно представителями заказчика и исполнителя. Как же избежать противоречия?

Выход есть! Заказчику необходимо предварительно самостоятельно сформировать набор требований к внедряемой системе, и уже исходя из них начинать поиск подходящего решения. А затем активно участвовать в разработке техничес­кого задания.

Формирование рабочей группы внедрения

Для успешного внедрения системы жизненно важно, чтобы в формировании требований к ней принимали участие все заинтересованные стороны (представители всех подразделений, задействованных в автоматизируемых бизнес­процессах). Если это требование не будет учтено, то с большой долей вероятности внедренное решение окажется абсолютно неудобным для большого числа пользователей (характерный пример —  неудачные попытки заставить руководителей производственных подразделений использовать специализированные системы управления портфелями проектов, применяемые в плановых службах [3]).

Следовательно, для понимания того, представители каких подразделений должны быть включены в рабочую группу внедрения, необходимо описать бизнес­процессы предприятия

Описание бизнес­процессов

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

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

Рис. 4. Шаблон бизнес-процесса согласования проектной документации в Lotsia PDM PLUS

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

При документировании бизнес­процессов необходимо обязательно учесть используемое на каждом этапе программное обеспечение, а также требования по обмену данными (стандарты, протоколы, форматы и т.п.). Если в организации внедряется BIM, то нужно четко сформулировать все процедуры взаимодействия.

Также необходимо задокументировать используемые формы документов и (при наличии) интерфейсов.

Требуется оценить интенсивность, продолжительность и критичность каждого ключевого бизнес­процесса: сколько пользователей и из каких подразделений в нем задействовано, сколько раз процесс повторяется в течение заданного срока, каков объем порождаемых процессом документов, как долго протекает процесс, какие последствия будет иметь задержка его выполнения или остановка? Можно ли разбить данный процесс на более простые и более контролируемые подпроцессы? Можно ли выполнять данный процесс в рамках пилотного проекта тестовой группой пользователей?

Отдельно необходимо зафиксировать информацию о правах доступа к данным на каждом этапе процесса и используемые схемы хранения данных (возможно, при внедрении АСУ ПД потребуется изменить схему их хранения).

Разработка перечня требований к АСУ ПД

Следующим шагом после документирования используемых в организации бизнес­процессов может стать формирование перечня требований к АСУ ПД. Этот перечень в дальнейшем может лечь в основу техничес­кого задания.

Наихудшим вариантом при разработке перечня требований к АСУ ПД будет бездумное копирование его из различных публикаций или предложений компаний —  разработчиков программного обеспечения. Перечень требований должен быть продуманным и опираться только на реальные потребности организации и поставленные цели.

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

При составлении требований необходимо учитывать ограничения, налагаемые инфраструктурой, и, при необходимости, предусмотреть ее модернизацию в рамках проекта внедрения АСУ ПД.

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

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

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

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

Определение планируемых этапов проекта

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

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

Такими этапами могут быть:

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

Здесь следует учесть, что особенно важным с точки зрения этапности является настройка системы. Очень важно выделить те задачи, которые должны быть реализованы в первую очередь, на первом этапе настройки. Важно понимать, что переходить к реализации последующих задач имеет смысл только после удачной опытной эксплуатации предыдущей задачи. Вот глубинный смысл этапности. Опытная эксплуатация обязательно покажет какие­то недоработки начальных фрагментов системы. Их доработка потянет за собой изменение последующих фрагментов. Это потребует изменения технического задания, перенастройки, а также дополнительных непродуктивных расходов. Так не лучше ли ограничиться на первом этапе небольшим и недорогостоящим фрагментом ради реального успеха? Таким образом, внедрение «небольшими перебежками» фактически оказывается более выгодным вариантом с точки зрения эффективности затрат времени и денег. А если внедрением занимается сторонняя организация, то при примерно равной стоимости долгосрочное сотрудничество принесет более качественный результат, чем разовая услуга.

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

Выбор поставщика решения

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

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

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

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

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

Задание ограничений пилотного проекта

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

Для правильного выбора ограничений для пилотного проекта следует ответить, как минимум, на следующие вопросы:

• На каких бизнес­процессах следует сфокусироваться в первую очередь?
• Каковы должны быть полученные результаты?
• Какие подразделения и в каком объеме должны принять участие в данных процессах?
• Каким образом и в каких единицах будет измеряться успешность проведения пилотного проекта?

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

Но если следовать приведенным выше рекомендациям, то с большой долей вероятности проект внедрения АСУ ПД будет успешно завершен в заданные сроки.

Список литературы:

1. Рижко Р.А. Система управления проектной деятельностью на базе Lotsia PDM PLUS в компании OLIMPS. Материалы международной конференции по PLM­2017, г.Москва / Рижко, Р.А. // [Электронный ресурс]: база данных. —  Режим доступа: http://www.plm­conference.com.
2. Кривущенко Е.В. Преимущества комплексного подхода при решении задач автоматизации бизнес­процессов. Материалы международной конференции по PLM­2017, г.Москва / Кривущенко, Е.В. // [Электронный ресурс]: база данных. —  Режим доступа: http://www.plm­conference.com.
3. Садовников Д.Л. Использование функций календарного планирования в Lotsia PDM PLUS / Садовников, Д.Л. // САПР и графика. 2015. № 10. С. 32­35. ISSN 1560­4640.