Еще раз о СУПе и кухне

Реплика на статью Сергея Никитенко «Ароматы кухни внедрения СУП»

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

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

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

Если трактовать СУП только как пакет программ, то с ее внедрением проблем как раз и не возникает. Кто-то получает только красивые графики, а кто-то ведет проекты. Подчеркну, что количественный перевес в пользу первой группы, даже значительный, вовсе не означает провала внедрения. Каждый получает то, что ожидал, — в меру своих действительных потребностей и готовности.

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

Действительно, если ответственные лица организации не понимают современных принципов проектного управления, то внедрение пакета календарного планирования мало чем им поможет. Хотя внедрен он будет, скорее всего, вполне успешно. Просто изначально им нужно было покупать другой продукт, например Project Management Body of Knowledge, или выписывать тренера по управлению проектами. Кстати, на курсах по управлению проектами топ-менеджеры нашей компании сидят в тех же классах, что и руководители проектов.

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

В подтверждение сказанного позволю себе еще раз сослаться на опыт компании, в которой я работаю. Если попытаться сформулировать принципы создания СУП одной фразой, то я бы сказал так: «Регламентация — сверху, автоматизация — снизу».

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

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

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