Управление инвестпроектами строительства ТЭС - Организационные формы реализации бизнес-процессов

1. Организационные формы реализации бизнес-процессов девелопмента проектов

Девелопмент проектов строительства ТЭС может осуществляться:

1. инициатором (бенефициаром);
2. застройщиком (заказчиком);
3. специализированной компанией, носящей название «девелоперской» или «проектно-инвестиционной»;
4. инжиниринговой компанией;
5. генерирующей компанией или компанией иного профиля.

О возможном совмещении функций разных субъектов строительной деятельности было упомянуто в главе 18. При этом следует понимать, что рассматриваемая деятельность требует высокой компетенции в сфере энергетики, строительства, ТЭК, земельных отношений, государственного регулирования экономики и т. д. Для эффективной работы в этой сфере необходимо дорогостоящее и сложное IT-обеспечение (см. главу 17).
В книге неоднократно подчеркивалась решающая роль инжиниринговой деятельности в предынвестиционной фазе проекта. Фактически любые бизнес-процессы, указанные в табл. 18.1, требуют в качестве исходных данных параметры технической и (или) финансово-экономической модели станции, что можно охарактеризовать как «пассивный» инжиниринг. Но кроме того практически на каждом шаге необходимы:

1. сбор и обработка информации для формальной или неформальной корректировки моделей;
2.  создание новых моделей различной природы;
3. аналитические исследования в связи с изменением окружения проекта;
4. составление актуальных отчетов с учетом изменившихся условий для внутрифирменных целей с указанием параметров моделей;
5. представление технических и экономических сведений в различные внешние структуры;
6. обоснование новых решений;
7. консультирование менеджмента, компании и партнеров по всем технологическим вопросам;
8. представление материалов для управления стоимостью проекта;
9. информационное обеспечение риск-менеджмента.

Это составляет предмет «активного» инжиниринга.
Таким образом, с системных позиций, принимая во внимание тесную интеграцию девелопмента и инжиниринга в проектах строительства ТЭС, целесообразно объединять эти предметные области в одной «инжиниринго-девелоперской», или «инженерно-управляющей» компании с доминирующей ролью инжиниринга. Опыт показывает, что такая интеграция оптимальна с точки зрения минимизации связей проектной команды и документооборота, позволяет гибко реагировать на постоянно меняющиеся внешние воздействия и успешно решать внутренние конфликты. Стоит также отметить, что управление проектами строительства и разработка сложной технической документации имеют много общего и реализуются на одинаковых принципах, с помощью одних и тех же программных средств. Кроме того, в наиболее общем виде бизнес такой компании — именно проекты. В дальнейшем будем называть компанию, о которой идет речь, просто инжиниринговой.
Решение задач по управлению проектами (в том числе программами и портфелями проектов) следует возложить на специальное подразделение в рамках инжиниринговой компании — проектный офис. Он должен обладать компетенцией в специфической сфере теории и практики — проектном менеджменте, и в более узком смысле — проектном менеджменте в строительстве ТЭС. Как будет показано ниже, в проектном офисе следует сосредоточить и управление любыми инжиниринговыми проектами (т. е. разработкой моделей ТЭС).
Рассмотрим вначале общую организационную проблематику управления проектами. В мировой практике существуют несколько типов организационных структур управления видами бизнеса вообще и управления проектами в частности.
Наиболее распространенный способ — функциональное разделение, когда работающие по сбыту объединяются в одну группу, конструкторы в другую, технологи в третью и т. д. Второй способ — это группировка людей по территориальному принципу: работа персонала с различными навыками координируется в одном месте. Такой принцип обычно используется, когда организация имеет отделения, географически удаленные от управляющей компании (головного офиса). Распространенными примерами здесь могут служить сети розничных магазинов или отделения национальных банков. Наконец, третий способ группировки работ — на основании производимого продукта, когда различные навыки и знания объединяются в организационные структуры для достижения общей цели.
На эти принципы накладывается степень централизации управления, что дает наиболее распространенные типы организационных структур, моделей управления — классическую иерархическую, дивизиональную, матричную.
Обычно исходят из того, что проект как форма уникальной (нерегулярной) деятельности может быть редким прецедентом в классической иерархической модели управления или тривиальным случаем в организации с матричной структурой, специально спроектированной для одновременного осуществления многих проектов, в том числе программ и портфелей проектов.
Если задать некоторую воображаемую шкалу по «степени проектности» организационной структуры, мы получим на крайних полюсах совершенно разную проблематику и феноменологию событий. Одно дело работать с персоналом, специально подготовленным к тому, чтобы трудиться на многих проектах практически всегда, другое — с персоналом, привыкшим работать в рамках регулярной деятельности.
Крайние полюса, однако, встречаются редко. В отечественной бизнес-культуре очень мало организаций, последовательно воплотивших у себя матричный способ организации. Чаще речь идет о некотором совмещении: часть проектной горизонтальной структуры накладывается поверх существующей вертикальной. При такой организации, например, затребованный специалист может в среднем 40 % своего времени работать над регулярными задачами, 60 % — над проектными. Зачастую именно такую «промежуточную» организационную структуру и называют «проектной системой управления», отграничивая ее, таким образом, от исходных прототипов организационной структуры — иерархической и матричной.
Соответственно, при формировании проектной группы ключевыми позициями являются:

1. руководитель (менеджер) проекта;
2. специалист (исполнитель);
3. руководитель линейного (функционального) подразделения;
4. проектный офис;
5. спонсор (бенефициар) проекта.

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

1. руководитель (главный менеджер) проекта;
2. заместитель руководителя — технический директор проекта;
3. администратор проекта;
4. помощник администратора.

С учетом необходимости системного анализа проблем строительства энергоисточников в увязке с широким кругом смежных областей и применения средств системной инженерии уже на первом этапе проекта в группу следует включить системного аналитика, который может также входить и в состав других групп.
В состав команды проектов, характеризующихся повышенной экологической опасностью (например, строительство крупных станций на угольном топливе), должен входить эколог, отвечающий за экологический контроль принимаемых решений и взаимодействие с исполнительными органами государственной власти, местного самоуправления и надзорными инстанциями в процессе землеотвода, согласования топливного режима и т. д.
Офисная группа, созданная для девелопмента проекта, может иметь разное число сотрудников на разных этапах его развития. На стадии инвестиционного замысла (в особенности на этапе seed) проектом может заниматься только руководитель. Более того, он может отвечать за несколько проектов вплоть до этапов 3 и 4 (см. табл. 18.1). Необходимость расширения состава группы определяется каждый раз в зависимости от сложности проекта и перспектив его развития. В состав группы целесообразно уже на первом этапе включать специалиста по управлению стоимостью. Один или несколько специалистов в составе офиса должны обслуживать все развивающиеся проекты.
Одним из главных принципов девелопмента является постоянство состава проектной группы. Лучшие мировые и отечественные практики доказывают необходимость сквозного руководства и этапами предынвестиционной фазы, и непосредственно строительством и сдачей объекта в постоянную эксплуатацию одними и теми же ведущими менеджерами (руководителем и техническим директором).
Какие же требования предъявляются к компетенции участников проектной группы? Безусловно, руководить проектом строительства такого сложного системного объекта могут лишь специалисты, достаточно хорошо представляющие себе устройство и особенности эксплуатации станции. Поэтому главный менеджер и его заместитель — технический директор — должны иметь опыт работы в станционной энергетике. Кроме того, им необходимо хорошо представлять себе весь комплекс инфраструктурных вопросов, возникающих при создании энергоисточников. Хочется особо подчеркнуть, что они должны профессионально разбираться в экологии энергетики, а также в теории и практике проектного менеджмента.
Системный аналитик — это опытный технический специалист широкого профиля, компетентный в вопросах функционирования и развития ЭЭС, общих вопросах энергетики и рынков электроэнергии и мощности. Его роль заключается в обосновании необходимости осуществления проекта, участии в выборе ключевых параметров ТЭС, форм ее работы в ЕЭС России и на рынках энергии.
Администратор проекта должен иметь энергетическое образование и желательно специальное образование в сфере проектного менеджмента. Он должен свободно владеть навыками практической работы в принятой в компании информационной системе управления проектами (Primavera, Microsoft Project и др.) и уметь организовать работу в рамках установленных стандартов. Все остальные члены команды, формируемой в проектном офисе, должны иметь опыт управления проектами, работы в информационной системе и хорошо знать стандарты управления.
Взаимодействие проектной группы и технологических подразделений инжиниринговой компании должно осуществляться на основе месячных, квартальных и годовых планов, которые, безусловно, будут часто корректироваться при изменении внешнего окружения проекта. Данную особенность следует учитывать при разработке структуры и внутренних регламентов. В оперативном плане образцом организации инжиниринговых работ специализированными функциональными подразделениями может служить хорошо известная всем специалистам-проектировщикам система выдачи и контроля исполнения заданий, которыми до сих пор обмениваются специалисты разных отделов проектных институтов. При таком подходе руководитель проекта фактически играет роль ГИПа проектного института, что служит еще одним подтверждением целесообразности интеграции девелопмента инвестиционных проектов и инжиниринга в рамках одной компании.
Более того, как уже отмечалось, управление чисто инжиниринговыми проектами (в том числе создание проектной документации по объектам) принципиально не отличается от управления проектами строительства в предметной области, ведется теми же методами и средствами, включая IT-решения. Следовательно, проектный офис можно и нужно совместить с той структурой, к которой причислены ГИПы в традиционном понимании. Таким образом, все функции технологического управления бизнесом (проектами) интегрированной инжиниринговой компании сосредоточиваются в едином центре — проектном офисе, который играет особую роль среди других функциональных подразделений.