скачать Гармонизация проектного и процессного подходов в деятельности современной ИТ-компании Ципес Григорий Львович, компания IBS, Москва, gtsipes@ibs.ru Товб Александр Самуилович, СОВНЕТ, Москва, atovb@yandex.ru Введение Сегодня распространены два основных взгляда на проекты в компании: проекты, как форма осуществления основной деятельности компании, и проекты, как эффективная форма реализации изменений в компании. Соответственно и компании можно разделить на проектно ориентированные, реализующие свою основную деятельность в форме коммерческих проектов, и не проектно ориентированные, если и использующие проекты, то в основном как инструмент внутреннего развития. Однако такое разделение является достаточно условным, поскольку, пытаясь повысить эффективность тех или иных операций, компания стихийно приходит к замене стационарных процессов проектами (к сожалению, часто, в суррогатных формах). И наоборот, пытаясь повысить эффективность реализации проектов, компания приходит к взгляду на проект как на типовой регулярно повторяющийся процесс, который может быть стандартизован, несмотря на уникальные цели и условия реализации. Таким образом, можно отметить следующие, на наш взгляд, неизбежные тенденции в деятельности самых разных компаний:
Однако процессный и проектный подходы предъявляют разные, часто противоположные требования к различным аспектам системы управления компанией, таким как организационная структура, учетная политика, персонал, система мотивации и т.д., что создает серьезные барьеры на пути эффективного управления проектами компании. Данный доклад посвящен анализу возможностей совмещения и практическим подходам к гармонизации процессного и проектного подхода в организации деятельности компании. ^ Прежде всего, убедимся в том, что сама постановка вопроса о реализации процессов в проектной форме не лишена смысла. Для этого рассмотрим классификацию бизнес-процессов, построенную на двух основаниях: возможность изменения продуктовой линейки компании и возможность настройки продуктов под требования потребителя (см. Рис. 1). В соответствии с этой классификации рассмотрим четыре основных группы процессов и проиллюстрируем на примерах возможности применения проектов при их исполнении. ![]() ^ Сегмент 1. Ограниченные возможности изменения продуктовой линейки и настройки продуктов. В этот сегмент мы помещаем компании, производящие продукт, ориентированный на удовлетворение неизменной, возникающей многократно потребности. Процессы выстраиваются в соответствии с технологией производства и являются уникальными для каждого бизнеса. Границы процессов в основном определяются положениями о подразделениях. Подобные процессы характерны для всех ИТ-служб в той части их обязанностей, которая относится к сопровождению и поддержке функционирования информационных систем (см. Рис. 2). Как правило, в рамках этих процессов решаются рутинные повторяющиеся задачи. Однако можно смело предположить, что осуществление сложного ремонта или обслуживание важного клиента вполне может потребовать изменения устоявшихся процедур, и тогда возникнет необходимость организации проекта. Критерием выбора формы (процессная или проектная) в этих случаях должна быть экономическая целесообразность. В расчет должны приниматься и возрастающие при применении проектного подхода затраты, и возможная упущенная выгода при срыве работ. ![]() Рис. 2. Бизнес-процессы сопровождения и поддержки ИТ Сегмент 2. Ограниченные возможности изменения продуктовой линейки и значительные возможности настройки продуктов В этот сегмент, прежде всего, попадают компании, производящие продукт, потребление которого носит растянутый во времени, возобновляемый характер. Эти компании стремятся как можно более полно удовлетворять требования конкретных клиентов, поэтому бизнес-процессы ориентированы на поддержание отношений с клиентом и носят сквозной характер. Структура процессов практически не зависит от вида бизнеса. Границы процессов определяются стадиями взаимоотношений с клиентами. На Рис. 3 подобные процессы проиллюстрированы на примере компании, предоставляющие услуги аутсорсинга в области ИТ. Здесь целесообразность применения проектного подхода, так же как и в предыдущем случае, связана с технической сложностью решаемой задачи и значимостью клиента. Во многих случаях и подготовка контракта, и его реализация, и последующая работа с запросами и претензиями существенно более эффективно может быть осуществлена в проектной форме (см. об этом подробнее в [1]). ![]() ^ Сегмент 3. Значительные возможности изменения продуктовой линейки и ограниченные возможности настройки продуктов. В этот сегмент попадают компании, оперативно реагирующие на изменения спроса и адаптирующие свою продуктовую линейку к реальным требованиям рынка в целом. Бизнес-процессы соответствуют жизненному циклу продукта, поэтому структура процессов не зависит от вида бизнеса. На Рис. 4 эти процессы проиллюстрированы на примере ИТ-компании, специализирующейся на производстве стандартного программного обеспечения. Применение проектного подхода может оказаться целесообразным для всех этапов жизненного цикла, связанных с разработкой и внедрением продукта (то есть, за исключением продаж и сопровождения, хотя, как мы указывали ранее, проектный подход может пригодиться, если в процессе сопровождения возникают серьезные инциденты). ![]() Рис. 4. Бизнес-процессы продуктового цикла Сегмент 4. Значительные возможности изменения продуктовой линейки и настройки продуктов. В этот сегмент попадают компании, ориентированные на создание уникального продукта для каждого клиента, как используя имеющуюся продуктовую линейку, так и дополняя и развивая ее. Бизнес-процессы соответствуют жизненному циклу создаваемого объекта (информационной системы, сооружения и т.д.). На Рис. 5 эти процессы проиллюстрированы на примере информационной системы. Как правило, эти компании являются проектно ориентированными, то есть, значительную часть своей деятельности осуществляют в проектной, а все этапы жизненного цикла объекта, за исключением эксплуатации объединяются в один или несколько проектов. ![]() ^ Все рассмотренные группы процессов представляются авторам достаточно универсальными1. Действительно, с точки зрения структуры процессов (и возможностей применения проектного подхода) процессы эксплуатации и сопровождения вполне можно заменить процессами таксопарка или гостиницы, ИТ аутсорсинга – процессами оператора связи или пенсионным фондом, разработчика стандартного программного обеспечения – процессами авиаперевозчика. ^ Представление проекта в виде совокупности процессов хорошо знакомо специалистам в области менеджмента проектов по международному стандарту PMBOKGuide PMI (см [2]). Однако, рамочный характер этого стандарта не позволяет выстроить процессы управления проектами на уровне компании с необходимой степенью детализации. Еще более сложно вписать эти процессы в контекст внутрикорпоративных отношений с учетом особенностей организационной структуры, принципов координации и субординации, правил делопроизводства и т.д. Единственный путь к представлению проекта как унифицированного процесса лежит через создание корпоративного стандарта управления проектами, включающего такие элементы как, регламенты и положения (включая принципы учета трудозатрат и мотивации), процедуры выполнения проектов, ролевые инструкции персонала проекта, шаблоны управленческих документов. Подробную информацию о принципах создания корпоративного стандарта управления проектами можно найти в [3]. Здесь же мы ограничимся лишь кратким описанием именно процессов, реализуемых при выполнении проектов и представляемых в стандарте в форме процедур. С точки зрения методологии управления проектами общее множество возможных процессов управления проектами может быть представлено в виде трехмерного пространства, изображенного на Рис. 6 (цитируется по [3]). ![]() ^ Каждая точка этого «пространства» представляет собой элементарный процесс управления. Например, “планирование рисков на стадии разработки системы” или “контроль качества проектирования системы“. Для удобства описания и исполнения процессы управления проектами должны быть сгруппированы по некоторым принципам и представлены в виде формализованных процедур. Возможны различные принципы группировки в соответствии с осями «пространства» процессов управления проектов:
Суть принципов формирования процедур управления проектами состоит в следующем (на примере «принципа ординаты»):
Возможны и комбинированные подходы. Например, в качестве основного принципа может применяться группировка процессов по фазам управления, а для ряда процессов, имеющих принципиальное значение, например, для становления культуры управления проектами, - группировка по функциям управления:
По отношению к процедурам управления проектами и к процедурам, описывающим исполнение процессов, не имеющих отношения к проектам, должны применяться единые правила поддержки и использования. Так, если в компании действует система менеджмента качества, процедуры управления проектами должны быть оформлены в соответствии с ее требованиями, механизмы их пересмотра должны быть строго регламентированы, а правильность исполнения должна подвергаться регулярному аудиту. ^ Одним из серьезных препятствий на пути внедрения проектного управления является неизбежно сопровождающий его передел сфер влияния в компании, как на среднем, так и на высшем уровне руководства. Раньше все было просто: функциональный руководитель отвечал за решение конкретных задач, он выстраивал соответствующие процессы и ставил людей на их выполнение. Теперь оказывается, что ту же самую задачу можно, в принципе, решать по-другому и, возможно, это будет эффективнее. Но при этом «права собственности» на часть процесса или на некоторые отдельные реализации процесса должны перейти к другим людям – от функциональных руководителей к руководителям проектов. Для того, чтобы подобные «передачи управления» не приводили к заметным политическим потрясениям в компании, должны быть определены формальные правила сосуществования процессной и проектной деятельности. Второй фактор, о котором необходимо помнить в связи с гармонизацией процессного и проектного подходов состоит в том, что для руководителя проекта велик соблазн организовать управление так, как удобно именно ему – задачи-то уникальны. Но если каждый руководитель будет действовать по этому принципу, в организации наступит хаос, особенно если учесть, необходимость параллельного существования в компании двух управленческих культур (процессной и проектной). Решение здесь, как отмечалось выше, заключается в создании корпоративного стандарта, определяющего набор процедур управления и единых правил их поддержки и использования, безотносительно к тому процессную или проектную деятельность они регламентируют. Исходя из этих соображений, мы видим три основных этапа, которые необходимо реализовать, чтобы обеспечить гармоничное сочетание процессной и проектной деятельности в компании. ^ Содержанием этапа является формальное описание организационно-функциональной структуры бизнес-процессов (реализуемые функции, исполнители). Возможно, в ходе формализации будет проведена определенная реструктуризация процесса – устранены избыточные или дублирующиеся функции, добавлены недостающие функции, перераспределена ответственность. Это особенно важно с учетом того, что результатом этапа станет базовый вариант процесса, который в последствие будет сравниваться с вариантами, появляющимися в результате более радикальных изменений. В ходе данного этапа должен быть также определен единый центр ответственности за процесс – владелец процесса. Именно это лицо (или группа лиц), ответственное за ход и результат всего процесса в целом, и будет впоследствии принимать решения о том, в какой именно форме выполнять конкретные реализации данного процесса. ^ Содержанием данного этапа является:
Для процессов, по которым существующая практика является неудовлетворительной, разрабатываются варианты их оптимизации на основе применения проектного подхода. Критериями оптимизации могут быть формальные ограничения процессов, такие как время исполнения, используемые ресурсы, качество результата и другие показатели, определяющие соответствие процессов бизнес-целями компании. Некоторые принципиальные моменты, связанные выполнением этого этапа, более подробно описаны в [4].
Наиболее серьезные изменения приходятся на область организационной структуры компании. Речь идет о создании постоянных (офис управления проектами) и временных (проектные команды) организационных единиц, которые вовлекаются или специально создаются для работы над проектами. Другими возможными последствиями, вытекающими из изменения организационной структуры, являются изменение системы бюджетирования компании, принципов подбора и мотивации персонала и т.д.
Решение о применении проектного подхода принимается, как мы упоминали выше, принимается владельцем процесса. Однако принятие этого решения и привлечение для исполнения проекта выделенного руководителя вовсе не снимает ответственности за процесс с его владельца. Именно он определяет методологию и технологию решения задачи, он же выделяет необходимых специалистов и, возможно, контролирует их работу с содержательной стороны. За руководителем проекта остаются вопросы оперативного управления. Однако объем делегируемых ему полномочий может варьироваться очень широко и зависит, как от специфики решаемых задач, так и от традиций корпоративной культуры. В принципе, во взаимоотношениях этих двух ключевых фигур регламентировать можно очень многое – разделение ответственности, правила «передачи управления» проектным командам, выделение ресурсов, решение спорных вопросов. Но не меньшее (если не большее) влияние на успех совмещения процессной и проектной деятельности оказывает дух сотрудничества, то, что регламентации поддается в очень малой степени. ^ Именно на этом этапе должен быть поставлен полноценный знак равенства между процессами и проектами. Проекты лишаются ореола исключительности, реализация проектов становится обыденным, рутинным делом. Процессы, возникающие в ходе исполнения проектов, структурируются и описываются в форме процедур. У этих процессов появляется свой владелец, отслеживающий их эффективность, правильность их исполнения, отвечающий за их развитие. В качестве владельца процессов управления проектами обычно выступает Офис управления проектами или иная, аналогичная по функциям служба компании (см. об этом подробнее в [3], [5]). Если такая специализированная структура в компании не создается, функции поддержания корпоративного стандарта управления проектами могут быть возложены на Службу качества. Выводы Для многих производственных задач, решаемых современными компаниями, невозможно заранее утверждать, какая форма решения этих задач окажется более эффективной – процессная или проектная. Если ситуации, когда нужно делать подобный выбор, из исключений становятся правилом, возникает необходимость, во-первых, формализовать процедуры принятия подобных решений и, во-вторых, обеспечить саму возможность одновременного существования обеих этих форм управления в компании. Первое достигается за счет
Второе достигается, прежде всего, за счет построения гибких организационных структур матричного типа, что в свою очередь сразу же предъявляет специальные требования и к системе бюджетирования, и к системе учета, и ко многим другим контурам управления в компании. Особую роль в гармонизации процессной и проектной деятельности компании может сыграть разработка корпоративного стандарта управления проектами с использованием методов и стандартов менеджмента качества. Именно с позиций менеджмента качества становятся наиболее очевидным, что процессы и проекты – это всего лишь две стороны одной медали Литература
1 Авторы не стремились к исчерпывающему охвату всех возможных видов процессов и сознательно ограничились рассмотрением только тех процессов, в которых реализуется основная деятельность компаний.
|