Система взаимоотношений участников проекта накладывает определенные требования к возможной организационной структуре проекта.
«Выделенная» организационная структура
Если основные механизмы управления и непосредственные источники основных ресурсов проекта находятся в рамках одной организации, то необходимо создавать внутрифирменную организационную структуру управления проектами, каким-либо образом согласуя при этом «материнскую» структуру (т.е. структуру, в рамках которой будет осуществляться проект) с новой, проектной структурой. При этом если планируемый проект представляется разовым для «материнской» организации, то возможны варианты «выделенной» (вынесенной за рамки «материнской» организации) проектной структуры (при этом степень «выделенности», естественно, может быть разная), а если предприятию приходится регулярно осуществлять различного рода проекты, то здесь требуется более глубокая интеграция «материнской» и проектной структур. Последний вариант организации проекта называется «управление по проектам» (management by project).
Урок 2 BPMN как определить участников процесса
Схематически «выделенная» организационная структура управления проектом изображена на рис. 5.2.1.
Такая «выделенная» организационная структура создается исключительно для одного проекта, после реализации которого она ликвидируется. Основными организационными ресурсами для такой структуры являются ресурсы «материнской» организации, которые на время проекта выделяются в структуру проекта и после его завершения возвращаются в «материнскую» структуру. Такой тип организационной структуры получил название «адхократической» (от лат. ad hoc — по случаю), так как они имеют разовое, ситуационное значение. Степень «выделенности» может быть разной — от отдельного, независимого предприятия, контролируемого только на высшем уровне, до структурного подразделения внутри организации, взаимодействующего с другими подразделениями «материнской» структуры.
«Управление по проектам»
В последнем случае «выделенная» организационная структура управления проектом может превратиться во внутреннюю, постоянно действующую структуру «управления по проектам». Для организаций, которые регулярно реализуют один или несколько проектов, характерна глубокая интеграция проектной и «материнской» структур, и говорить об их различии можно лишь условно. Схема «управления по проектам» изображена на рис. 5.2.2.
«Всеобщее управление проектами»
При такой схеме организационные структуры проекта и «материнской» организации составляют единое целое и управляются общей системой управления. Границы между проектной и «материнской» структурами при этом чрезвычайно размыты. Ресурсы для проекта и для прочей деятельности «материнской» организации могут быть общими и использоваться совместно. В случае если деятельность «материнской» организации полностью состоит из деятельности по управлению проектами, возникает организационная структура «всеобщего управления проектами», изображенная на рис. 5.2.3.
Вебинар Юлии Дмитриевой «Взаимодействие бизнеса и власти»
Описанные выше три типа организационных структур («выделенная», «управление по проектам» и «всеобщее управление проектами») применяются в следующих случаях:
• генеральным подрядчиком проекта является одна организация, которая берет на себя функции по управлению проектом и выполняет все либо основную часть работ по реализации проекта;
• заказчиком, генеральным подрядчиком и инвестором является одна организация (это так называемые «внутренние» проекты, которые реализуются одними структурными подразделениями для других подразделений одной и той же организации; например, в проекте создания новой продукции заказчиком может выступать отделение сбыта, генеральным подрядчиком — отделение производства и проектирования, а инвестором — отделение развития или предприятие в целом).
Рис. 5.2.1. Схема «выделенной» организационной структуры управления проектом
«Двойственная» (dual) организационная структура
В случае если в проекте участвуют две равнозначные с точки зрения управления проектом организации, возникает так называемая «двойственная» (dual) организационная структура управления проектом, схема которой изображена на рис. 5.2.4.
«Двойственная» организационная структура управления проектом характерна тем, что позволяет реализовать равноценное участие в системе управления двух организаций — участников проекта. Это может выражаться в создании объединенного комитета по управлению проектом, в котором представлены обе организации, в равноценном участии обоих участников в органах управления специально учрежденного для реализации проекта юридического лица (таких, как общее собрание акционеров, совет директоров, ревизионная комиссия, правление) или же в существовании двух руководителей проекта от обеих организаций, имеющих полномочия по совместному принятию решений (см. примеры).
Рис. 5.2.2. Схема организационной структуры «управления по проектам»
Рис. 5.2.3. Схема «всеобщего управления проектами»
Рис. 5.2.4. Схема «двойственной» организационной структуры управления проектом
«Двойственная» организационная структура применима в следующих случаях:
• заказчик и генеральный подрядчик проекта имеют одинаково большое значение в процессах принятия решения, протекающих в системе управления проектом, либо выполняют работы одинаковой важности;
• существуют два равнозначных инвестора или инициатора проекта, одинаково заинтересованных в результатах проекта и принимающих активное участие в реализации проекта.
«Сложные» организационные структуры
В случае участия в проекте более двух разных организаций, имеющих различные значимые функции в этом проекте, возможно, реализовать так называемые «сложные» организационные структуры управления проектами, имеющие три принципиальные разновидности:
• управление проектом реализует заказчик (рис. 5.2.5);
• управление проектом реализует генеральный подрядчик (рис.5.2.6);
• управление проектом реализует специализированная управляющая фирма (рис. 5.2.7).
В рамках схемы «управление — функция заказчика» заказчик может организовывать выполнение отдельных комплексов работ, к остальным привлекая другие подрядные организации. Организационная структура проекта при этом формируется заказчиком. Организационные ресурсы для управления проектом выделяются заказчиком и используются в ходе реализации проекта на постоянной основе. Ресурсы других организаций привлекаются временно.
В рамках схемы «управление — функция генерального подрядчика» заказчик передает функции управления генеральному подрядчику, оставляя за собой контроль отдельных промежуточных и конечных результатов. Генеральный подрядчик самостоятельно формирует организационную структуру управления проектом, выделяет постоянные ресурсы и реализует все функции по управлению проектом, при этом привлекая на временной основе подрядные организации и собственные подразделения для выполнения отдельных комплексов работ по проекту.
В рамках схемы «управление — функция управляющей фирмы» заказчик поручает функции по управлению проектом управляющей фирме, специализирующейся исключительно на управлении проектами. Управляющая фирма оставляет за собой самые важные функции управления проектом, разрабатывает организационную структуру управления проектом и реализует управление, при этом, не выполняя никаких работ по проекту и передавая их для реализации подрядным организациям. Такая схема может иметь следующую разновидность: управляющая фирма передает все работы по проекту генеральному подрядчику, который является ответственным исполнителем всех работ и может привлекать к выполнению отдельных комплексов работ субподрядные организации (рис. 5.2.8).
Таким образом, генеральному подрядчику передаются отдельные функции по управлению проектом, но доминацией в системе управления обладает управляющая фирма.
Приведенная в настоящем разделе классификация схем организационных структур отражает влияние системы взаимодействия участников проекта на систему управления проектом. Это описание подчеркивает «внешние» связи организационной структуры и системы управления самого проекта с его участниками. Поэтому такое описание носит здесь название «схем организационной структуры» в отличие от непосредственно самих «организационных структур», которые описываются с точки зрения внутреннего их содержания в следующем разделе.
Рис. 5.2.5. Схема организационной структуры управления проектом, при которой основные функции по управлению выполняет заказчик
Рис. 5.2.6. Схема организационной структуры проекта, при которой основные функции по управлению проектом выполняет генеральный подрядчик
Рис. 5.2.7. Схема организационной структуры проекта, при которой функции по управлению проектом реализует специализированная управляющая фирма
Схемы организационных структур по большей части реализуются при помощи соответствующих положений контрактов, заключаемых между участниками проекта (см. гл. 12).
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Что такое эффективное взаимодействие между отделами?
Когда дело доходит до офисных будней, на первый план выходит кросс-функциональное взаимодействие. Многие руководители уверены, что достаточно собрать под одним флагом настоящих профессионалов и процесс запустится сам собой. Увы, зачастую все оказывается куда сложнее.
Успех любой компании основан не только на блестящей стратегии, состоянии рынка и работе профессионалов высокого уровня. Когда дело доходит до офисных будней, на первый план выходит кросс-функциональное взаимодействие. Многие руководители уверены, что достаточно собрать под одним флагом настоящих профессионалов и процесс запустится сам собой.
Увы, зачастую все оказывается куда сложнее. Конфликты и недопонимание между функциями — то, чему подвержены даже профессионалы высочайшего уровня. Но ничуть не менее опасным может оказаться и простое безразличие: каждый делает свою работу, никого не трогает, значит, все в порядке. В Институте Тренинга мы называем такие ситуации конфликта интересов и безразличия «взаимным ослаблением». Давайте разберемся, как же должно выглядеть эффективное взаимодействие между отделами компании и что может ему воспрепятствовать!
Что такое эффективное взаимодействие между отделами
Без эффективного взаимодействия между отделами компании последняя не может работать на полную мощность. То и дело возникают задержки, информация передвигается по артериям бизнеса с опозданием, а компания начинает в целом работать менее эффективно, ведь там, где сотрудничество функций могло породить новую идею или достичь прорыва — тишина. Функции-то безразличны друг к другу.
В других статьях этого цикла мы уже писали о том, почему возникают подобные ситуации. Например о том, как наша природа призывает нас организовываться в группы и объявлять соседей «соперниками» мы писали в статье «Как проанализировать эффективность кросс-функционального взаимодействия подразделений?».
В Институте Тренинга мы делим все ситуации кросс-функционального взаимодействия на две категории: взаимное усиление и взаимное ослабление. Принцип таков: если функции в вашей компании не усиливают друг друга, то они друг друга ослабляют. Да, да, именно так!
Как часто встречается такая ситуация: сидят сотрудники в отделе закупок и каждый месяц обсуждают, как же их раздражает дурная привычка отдела продаж делать N, вместо S. И как им каждый месяц приходится это расхлебывать. А ведь проблему, скорее всего, можно было бы решить путем банальной кросс-функциональной коммуникации.
Достаточно лишь проявить инициативу и правильно построить диалог. Но самое страшное в этой ситуации то, что вы можете работать на посту руководителя в компании, которая десятилетиями копит подобные претензии сотрудников друг к другу и даже не знать об этом. В кросс-функциональном взаимодействии не существует нейтральной позиции.
Взаимное усиление — это позиция личной инициативы и сотрудничества, когда отделы хорошо информированы, понимают задачи друг друга, умеют коммуницировать и проявляют инициативу, начиная взаимодействие. Поэтому, мы и можем поставить знак равенства между эффективным взаимодействием между отделами и взаимным усилением. Первое прямо вытекает из второго. Но чтобы полностью разобраться в теме взаимодействия, необходимо погрузиться в детали. Далее мы разберем основные препятствия на пути взаимодействия и подробно поговорим о ключевых характеристиках, которые необходимы, чтобы его наладить.
Что препятствует взаимодействию между отделами организации
Сталкивались ли вы в своей профессиональной практике с ситуациями конфликтов между функциями? Например, когда один отдел винит другой в той или иной проблеме? Или когда между отделами то и дело возникают моменты напряженности и непонимания? Или один отдел мог бы существенно ускорить работу другого, но не делает этого, так как это не является частью официального регламента?
Зачастую, это примеры не практических проблем, а «коротких замыканий» в кросс-функциональном взаимодействии. а) Первая причина таких неполадок — это наша собственная психология. Человек — стадное животное и в любой ситуации мы склонны организовываться в группы.
В данном случае, роль групп выполняют функции: коллеги по отделу становятся символическим олицетворением «мы», а сотрудники других функций попадают в категорию «они». К ней мы начинаем относиться равнодушно и часто даже враждебно. б) Вторая причина — это банальный фактор непонимания происходящего.
Многие проблемы взаимодействия между отделами в компании можно было бы решить достаточной информированностью. Сотрудники должны хорошо понимать, чем занимаются их коллеги, какие цели перед ними стоят и как они зависят друг от друга.
Порой простое понимание ситуации в целом способно избавить нас от предрассудков, которые неизбежно возникают при недостаточной информированности. в) Третья причина оказывается несколько более сложной и абстрактной. Взаимодействию между отделами организации часто препятствует… пассивность сотрудников.
Кросс-функциональное взаимодействие подразумевает проявление инициативы со стороны всех участников. «Почему нельзя было просто спросить?», — говорили нам родители в детстве, но когда мы выросли, проблема не исчезла, а попросту перешла на другой уровень. Инициативное предложение помощи, вовремя начатый диалог, поддержка, совет, предложенные коллеге — все это предполагает, что один из участников взаимодействия делает первый шаг.
Но взаимодействия не будет, если никто этого шага не сделает. г) Четвертая причина — это неструктурированные взаимодействия между отделами. Этот пункт, хоть мы и вынесли его на четвертое место, является ничуть не менее важным, чем предыдущие три.
Во многих российских компаниях за отделами традиционно закрепляются только их функции — то, какие задачи сотрудники должны выполнять. При этом сама структура взаимодействия между отделами оказывается практически нерегламентированной. Ясно, что документы на оплату необходимо передать в бухгалтерию, но когда и как именно это сделать — выясняется путем проб и ошибок. Подобные ситуации приводят к тому, что большинство кросс-функциональных конфликтов решаются либо между руководителями, которым «жалуются» на соседей, либо взаимодействие между функциями существенно замедляется: сотрудники действуют неоптимальным образом и замедляют работу компании в целом. Чтобы избежать этого бизнесу необходима карта взаимодействия между отделами.
Карта взаимодействия между отделами
Карта взаимодействия между отделами — это документ, регламентирующий кросс-функциональное взаимодействие любого типа. Обычно в карту заносят как регулярные взаимодействия, так и потенциальные (событийные), которые происходят случайно, в связи с конкретной сложившейся ситуацией. Карта как бы фиксирует все действия, которые должен совершить сотрудник, столкнувшись с необходимостью обратиться к другому отделу. Глядя на нее, каждый человек в компании должен знать:
- кто за что отвечает;
- к кому обратиться со своим вопросом/просьбой;
- в какие сроки это удобнее всего сделать;
- какие кросс-функциональные взаимодействия существуют в компании в принципе.
К сожалению, карта не дает положительного эффекта в отрыве от других факторов: информированности, обучения, преодоления негативного влияния психологических механизмов, умения вести переговоры и так далее. Но компании, которая активно занялась «лечением» своих кросс-функциональных взаимодействий или уже достигла успеха на этом поприще она сослужит отличную службу.
Предлагая сотрудникам карту взаимодействий, вы избавляете их от страха неопределенности. Глядя на нее, они будут точно знать: к кому, как и когда обращаться с конкретным вопросом. Лучше иметь карту местности, чем блуждать по неизведанной земле в ожидании озарения, верно? В следующей статье «Как составить регламент взаимодействия между отделами» (https://docs. google. com/document/d/13uTHc_rWWqVWiTLuxs2s2rthmoO0a-l9kawqR4IZW7I/edit) мы подробнее поговорим о карте взаимодействий, разберем ее преимущества и, конечно, научимся составлять для своей компании.
Подводим итоги
Проблемы кросс-функционального взаимодействия имеют глубокие социальные и психологические корни. Сама природа человека как бы подталкивает его к тому, чтобы разграничивать группы, находить соперников и защищать «своих» в конфликтных ситуациях. Но это — повод для радости, а не для расстройства. Ведь когда понимаешь суть проблемы, то можешь легко приступить к ее решению.
На тренинге «Кросс-функциональное взаимодействие» мы поможем руководителям научиться нейтрализовывать механизмы группового фаворитизма, разрешать конфликтные ситуации, формировать глубоко информированную рабочую среду и выступать медиаторами в ходе кросс-функционального взаимодействия. Такой уровень подготовки позволит не только нейтрализовывать существующие конфликты и трансформировать рабочую среду, но и избавиться от знаменитой ситуации безразличия: «сам работаю и другим не мешаю». А о тренинге всегда можно узнать больше здесь.
Источник: training-institute.ru
Организация взаимодействия участников проекта
Успех проекта во многом зависит от эффективности вовлечения в процесс разработки всех заинтересованных сторон. Введение формализованных механизмов, учитывающих специфику процессов и особенности организации компании, позволяет оптимизировать организацию взаимодействия как между отделами, так и между сотрудниками внутри команд.
Каждый из нас хотя бы раз попадал в ситуацию, будучи приглашенным на некое проектное совещание, но с трудом понимая, зачем его сюда позвали. Вы безуспешно пытаетесь вникнуть в суть обсуждаемых проблем, но в результате просто тратите впустую свое и чужое время. Или, например, вы разработали дизайн продукта, но неожиданно оказывается, что документ надо было согласовать с кем-то еще, помимо непосредственного начальника. В результате принятие документа затягивается, что негативно отражается на сроках поставки продукта и, как следствие, на отношение заказчика к проекту. И наконец, представьте ситуацию, когда на момент поставки выясняется, что не было учтено важное требование, так как его заранее не согласовали с одним из представителей заказчика — а это снова аврал и срыв сроков.
Введение формализованных механизмов учета всей специфики взаимоотношений в проекте позволяет сделать работу эффективней, по крайне мере, так произошло в Санкт- Петербургском центре Motorola.
Механизмы вовлечения в работу
Заинтересованные стороны, участники (разработчики, акционеры и др.) проекта — это не только команда и заказчик, но и представители всех поддерживающих отделов (системные администраторы, группа качества, отдел логистики, бухгалтерия, отдел по работе с персоналом, тренинг), без своевременного привлечения которых реализация проекта ставится под угрозу. Для формализации процессов взаимодействия между всеми этими участниками можно использовать механизм — матрицу, определяющую минимально необходимый состав участников проекта, в той или иной роли задействованных в нем на протяжении всего жизненного цикла разработки.
На выходе каждого этапа проекта имеется рабочий продукт (work product) — документ, набор тестов или код, проходящий проверку качества, предусматривающую обзор/инспекцию, аудирование или тестирование. В таблице 1 приведена матрица для процедуры инспекции.
В столбцах расположены документы, в строках — список участников, а на пересечении указывается роль, которую выполняет конкретное лицо во время подготовки и проведения инспекции документа. Заглавная буква означает, что данное вовлечение обязательно, что обычно устанавливается на уровне процесса организации, но может быть определено во время адаптации процесса для конкретного проекта. Если же буква прописная, то это напоминание организатору инспекции о возможном привлечении конкретного человека: «И» — должен участвовать в проверке; «О» — должен одобрить готовый документ; «Инф» — должен быть оповещен о проходящей инспекции.
Такой же механизм применяется и для вовлечения заинтересованных сторон в различного рода собрания проектной команды с целью контроля изменений в проекте, определения статуса проекта и предотвращения проблем/дефектов.
Помимо матрицы мы используем «проверочные списки» (checklist), необходимые при передаче рабочего продукта с одного этапа на другой либо в процессе разработки документации или кода. В этих проверочных списках указаны участники, ответственные за их заполнение.
Механизмы в действии
Конкретные примеры применения механизма матрицы демонстрируют, каким образом с его помощью удается эффективно вовлекать участников проекта в различные виды активности.
Инспекции документов. Таблица 2 иллюстрирует пример вовлечения заинтересованных сторон к инспекциям двух различных документов: проектного плана и процедур системного тестирования.
Обзор плана должен быть проведен представителями нескольких подразделений — это один из важнейших документов проекта, потому что именно в нем указываются задачи и цели проекта; распределение ресурсов; используемые механизмы и процедуры разработки ПО; способы взаимодействия между подразделениями; оценки объема кода и трудозатрат. Процедуры системного тестирования — это технический документ, и его должны проверять команды разработки и тестирования.
Проектные собрания. Собрание, посвященное началу проекта, является первым мероприятием, на котором собираются все заинтересованные стороны проекта. Представители всех отделов участвуют в собрании или информируются о его проведении.
Здесь обсуждаются следующие вопросы: масштаб и длительность проекта; необходимые ресурсы для проекта (персонал, аппаратное и программное обеспечение); необходимость командировок; способы взаимодействия с заказчиком; вовлечение представителей отдела качества; необходимое обучение для персонала; возможность найма субподрядчиков; условия поставки; технологии; множество других аспектов, касающихся проекта. На этом этапе выявляются возможные проблемы и ставятся задачи. Именно из-за столь широкого перечня решаемых вопросов необходимо присутствие и оповещение представителей не только проекта и подразделения, но и смежных отделов. На собрании, посвященном вступлению проекта в фазу разработки, обсуждаются сугубо технические вопросы, поэтому нет необходимости привлекать к этому мероприятию такое же количество стейкхолдеров, как в предыдущем случае.
Проверочные списки. При передаче кода от разработчиков в отдел тестирования необходимо заполнить проверочный список, позволяющий проверить, что все необходимые отчеты по разработке продукта составлены; сопутствующая документация была проинспектирована; процедура хранения кода определена; связи между требованиями к продукту и тестами установлены; количество найденных дефектов не превышает нормы. В заполнении и подписании данного списка должны участвовать как сторона разработки кода, так и представитель тестовой команды. Перечень участников указан в проверочном списке, что позволяет передавать работу с одного этапа на другой.
Поставка продукта. На этапе поставки готового продукта заказчику необходимо разделять два вида поставок, промежуточную и конечную, на которых проходит проверка качества, но глубина проверки в этих случаях будет разной.
Очевидно, что для промежуточной поставки проверка будет менее масштабной, а некоторые проверки необходимы только для финальной поставки, — например, проверка пользовательской документации; проверка отчета по тестированию (имеется ввиду полное тестирование); валидация инсталляции продукта; проверка того, что вся проектная документация была доведена до конца. Глубина проверки и уровень ответственности влияют на количество вовлекаемых участников (Табл. 3). Для поставок мы используем процедуру инспекции и соответственно механизм матрицы для вовлечения всех заинтересованных сторон.
Перепланирование. Как бы тщательно и правильно мы ни спланировали проект, зачастую на ход работы могут влиять не зависящие от нас факторы: изменение требований заказчика, возникновение сложностей с аппаратным обеспечением или ПО, необходимым для разработки продукта, нехватка ресурсов и т.д.
Данные факторы могут повлиять на даты промежуточных поставок, а иногда и на дату финальной поставки, поэтому важно своевременно реагировать на подобного рода изменения. В таких случаях необходимо произвести перепланирование: минимальное, среднее и полное. Мы создали специальный проверочный список, с помощью которого лидер проекта определяет тип перепланирования.
Последовательно выбирая из заданного списка те области проекта, которые необходимо пересмотреть, мы получаем тип перепланирования, подходящий к данной ситуации. Результат вычисляется эмпирической формулой, которая учитывает как приоритеты факторов (областей изменений), так и их суммарное влияние. В примере из таблицы 4, выбирая «Да» напротив изменений в ресурсах команды разработки (именно этот аспект является в данном случае ключевым), мы получаем «Среднее» перепланирование. В то же время, если бы изменения касались только внутренних дат, не влияющих на дату конечной поставки (область 4), то перепланирование было бы «Минимальное». При этом результатом заполнения данного проверочного списка может стать «Полное» перепланирование в трех случаях: если мы выберем «Да» напротив всех областей, кроме первой; если определим изменения только в процессе разработки (область 1); если изменения затронут все области.
Следующим шагом является определение списка участников, которых необходимо привлечь к перепланированию данного типа (кто должен инспектировать изменения, кто ответствен за их одобрение). Здесь мы вновь возвращаемся к матрице, в которой по горизонтали указывается список участников, а по вертикали — виды перепланирования. На пересечении мы получаем «обязательное» или «необязательное» (в случае необходимости) вовлечение. В зависимости от типа перепланирования количество «обязательно» вовлекаемых участников меняется: для полного перепланирования — 7 человек, а для минимального — 3.
Механизмы матрицы и проверочного списка — часть организационного процесса по разработке ПО в Центре Motorola, они связаны с шаблонами большинства документов, поэтому влияние изменений процесса на механизмы тщательно отслеживается, что позволяет адаптироваться к любым изменениям. Оба механизма реализованы на базе Excel, что позволяет применять фильтры и связывать с базами данных.
Источник: www.osp.ru
