Как руководить отделом

5. Действие третье. Разграничиваем зоны ответственности

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

Э. де Боно

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

От того, какие бизнес-процессы создают ценность для клиента и обеспечивают эффективность работы сотрудников, будет зависеть структура отдела и принципы организации работы сотрудников.

Мы выделили два основных бизнес-процесса нашего отдела: «Создание идеи креативного контента» и «Планирование производства креативного контента», а также один вспомогательный бизнес-процесс – «Закрытие проекта».

Так как основной продукт нашего структурного подразделения создается в рамках отдельных проектов, то мы выделили как отдельный бизнес-процесс «Управление проектами по созданию креативного контента».

Методологически работа по описанию бизнес-процессов проходит в рамках сессии развития – собрания отдела, направленного на решение каких-либо организационных задач (о сессии развития см. в разделе «Определяем цели проведения собраний»).

Обращаем внимание читателя на то, что в данном кейсе мы не рассматриваем методологию описания и анализа бизнес-процессов. Мы также не ставили целью показать все возможные способы визуализации бизнес-процессов. Этой теме посвящены специальные кейсы и онлайн-курсы.^[3] В данном разделе мы предлагаем к рассмотрению способ визуализации, который был удобен для работы сотрудникам данного структурного подразделения компании.

Представим бизнес-процесс по созданию креативного контента в виде таблицы (Таблица 2).

Таблица 2. Бизнес-процесс «Создание идеи креативного контента»

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

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

Аналогично мы описали бизнес-процесс «Планирование производства креативного контента» (Таблица 3).

Таблица 3. Бизнес-процесс «Планирование производства креативного контента»

После планирования проекта команда приступает к его реализации. Фаза реализации проекта – это созидательный, креативный процесс, который не всегда можно формализовать. Тем не менее, творчеством в бизнес-организации необходимо управлять. Каждый проект нашего структурного подразделения является уникальным. Но каждый уникальный проект состоит из повторяющихся этапов: определения контрольных точек, составления карты рисков, приемки промежуточных результатов, подведения итогов проекта и т. д. Для того чтобы облегчить руководителю-стажеру работу по контролю за реализацией проектов, мы описали бизнес-процесс «Управление проектом». Имея перед глазами подобную «шпаргалку» (Таблица 4), руководителю отдела проще организовать свою работу таким образом, чтобы своевременно осуществить необходимые управленческие воздействия для получения гарантированного результата.

Таблица 4. Бизнес-процесс «Управление проектом»

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

Таблица 5. Бизнес-процесс «Закрытие проекта»

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

Затем мы разграничили зоны ответственности между сотрудниками отдела. Мы вынесли на бумажный носитель информацию о зонах ответственности. В результате у нас получилась таблица «Матрица ответственности структурного подразделения» (Таблица 6).

Таблица 6. Матрица ответственности структурного подразделения

Условные обозначения:

К – контролирует, управляет рисками.

О – организует работу, исполнителей, отвечает за результат.

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

Мы донесли до сотрудников отдела и регулярно закрепляли в ежедневном управленческом общении, что при возникновении сложной, спорной ситуации, для которой нет правила, инструкции, регламента либо которая имеет больше одного решения, действовать следует исходя из основополагающей ценности: «Клиент – это главный босс». Безусловно, тезис «Клиент – это главный босс» требует уточнения. Во-первых, не любой клиент, а наш, целевой. Во-вторых, клиентная ориентация должна быть уравновешена взаимной выгодой от сотрудничества.^[4] Кроме того, никто не отменяет традиционную иерархию в структуре управления, предполагающую подчинение сотрудников руководителю. Смысл нашего посыла сотрудникам о главенствующей роли клиента заключался в воспитании определенного отношения к клиенту. Результаты работы сотрудника, который искренне внутренне направлен на интересы клиента, как правило, превосходят итоги деятельности работника, который всего лишь демонстрирует подобное поведение.

Поэтому организационную структуру нашего отдела мы изобразили вот таким образом (рис. 3).

Рис. 3. Схема организационной структуры отдела

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

6. Действие четвертое. Внедряем методологию управления проектами

Чем меньше усилий приходится затрачивать организации для получения результатов, тем лучше она справляется со своей работой.

П. Друкер

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

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

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

Таблица 7. Стадии проекта и шаблоны необходимых документов

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

7. Действие пятое. Решаем проблему качества планирования

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

Г. Киссинджер

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

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

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

Затем мы проанализировали, что еще может влиять на качество планирования, и перечислили все возможные риски проектов.

Ценное понятие:

Риск проекта – непредвиденное событие, которое может привести к недостижению запланированных показателей проекта.

Составленный нами перечень рисков мы проанализировали и сформировали на его основе карту рисков (Таблица 8).

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

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

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

Таблица 8. Карта рисков проектов

После того как мы проделали работу по созданию процедур для минимизации рисков, мы оценили каждый риск по 10-балльной системе по принципам «Вероятно/Маловероятно» и «Значимо/Малозначимо». Данные визуализировали в виде таблицы (Таблица 9). Это дало нам понимание того, как работать с теми или иными рисками.

Риски, которые попали в столбец «Вероятно и Значимо», требовали особого контроля, специальных процедур по недопущению или минимизации. Например, выход из строя оборудования (программного обеспечения, принтера и т. д.) вероятен и значим, так как может привести к увеличению сроков изготовления отдельных элементов креативного контента в связи с ремонтом или заменой оборудования. Однако данный риск можно минимизировать, заранее проведя профилактический осмотр и изыскав альтернативные возможности выполнения данного вида работ.

Риски, которые попали в столбец «Маловероятно, но Значимо», – это, как правило, риски, от которых мы не можем застраховаться (стихийные бедствия, природные и техногенные катаклизмы и т. д.). Подобного рода события мы выносим за рамки управляемых параметров.

К вероятным, но малозначимым рискам мы отнесли, например, такой риск, как вынужденное отсутствие одного из членов проектной команды по причинам личного характера (болезнь, семейные обстоятельства и т. д.). Логика подобной классификации заключается в том, что при планировании проекта мы учитываем этот риск и закладываем дополнительные расходы на привлечение специалиста для замены внезапно заболевшего или по иным причинам «вышедшего из строя» члена проектной команды. Таким образом, при высокой вероятности (людей нельзя запрограммировать, они могут болеть, у них могут случаться различные непредвиденные семейные обстоятельства) данный риск не является для нас фатальным. Срыв сроков по причине того, что кто-то из сотрудников не может выполнить порученную ему задачу, не является оправданием менеджера проекта. Управление не должно базироваться на незаменимых людях. Если проект правильно спланирован, необходимые контрольные точки зафиксированы, риски проработаны, вся необходимая для качественного выполнения работы документация в наличии, то провести замену одного специалиста на другого в большинстве случаев возможно без потерь.

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

Таблица 9. Оценка рисков по принципу «Значимость/Вероятность»

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

Совместно с руководителем-стажером мы приняли важное правило – при утверждении устава проекта обсуждать с каждым менеджером проекта, как именно будет выполняться та или иная задача. Это необходимо для того, чтобы контролировать не только результат, но и способ его достижения. Зная технологию выполнения задач, руководитель может своевременно скорректировать действия подчиненного и предложить или выработать совместно наиболее эффективный вариант. В нашем случае это было важно, поскольку срывы сроков проектов имели место даже у менеджеров с большим опытом работы. В дальнейшем при наведении порядка и укоренении принципов регулярного менеджмента процедуры контроля предполагалось изменить с учетом принципов ситуационного руководства. Об этом пойдет речь ниже.

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

Еще один инструмент управления для руководителя-стажера, который мы ввели в практику оперативного управления, – делегирование. Мы определили полномочия принятия решения в различных ситуациях. За основу мы взяли составленный нами перечень всех рисков и негативных ситуаций, которые могут «вмешаться» в нормальный ход реализации проектов. Затем мы разделили все ситуации на две группы: типовые и экстренные. К типовым мы отнесли ситуации, которые не требуют индивидуальных, нестандартных решений и находятся в зоне ответственности менеджера проекта. Кроме того, действия в некоторых типовых ситуациях, как правило, уже определены в «неприкосновенных» законодательных актах компании, например, в политике, процедурах, регламентах, правилах, инструкциях и т. д. Подобного рода типовые ситуации не предполагают вариативности, нужно просто действовать по установленному стандарту или нормативу. К экстренным мы отнесли ситуации, решение по которым может принять только руководитель отдела, так как подобного рода события требуют индивидуального подхода и/или особых полномочий.

В результате проведенного анализа у нас получился перечень типовых и экстренных ситуаций (Таблица 10).

Таблица 10. Перечень типовых и экстренных ситуаций

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