Проекты и процессы

Мария Суханова

В связи с возрастающим объемом и сложностью работ по созданию и развитию ИС предприятий перед ИТ-директорами встают серьезные проблемы в области управления. Какую управленческую форму следует использовать для того или иного вида деятельности -- проектную или процессную? Неправильный выбор может крайне отрицательно сказаться на эффективности бизнеса. Взаимодействию этих двух форм управления на V конференции "Стандарты в проектах современных информационных систем" была посвящена специальная секция.

Сближение проектов и процессов

Работа компании с внешними заказчиками может строиться различно, но если она, с одной стороны, нормально функционирует, а с другой -- развивается, в ее внутренней деятельности так или иначе должно найтись место и процессам, и проектам. Аналогичным образом складывается ситуация и в ИТ-департаменте. Но как сделать правильный выбор в применении той или иной формы управления? С одной стороны, все просто: если перед нами стоит относительно несложная типовая задача, которая носит повторяющийся характер и про которую мы понимаем, как ее решать, то нужно организовать процесс, если же мы, наоборот, получили нечто совершенно новое и не похожее на то, с чем имели дело раньше, -- то начинать проект. Однако на практике граница между массовым и индивидуальным, стандартным и уникальным то и дело оказывается размытой. В этом и заключался основной тезис доклада Григория Ципеса, главного консультанта IBS, и Александра Товба, вице-президента СОВНЕТ. По их мнению в ряде (а может быть, даже в большинстве) случаев по бизнес-задаче невозможно заранее предсказать, какая форма управления окажется более эффективной при ее решении.

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

Возможен и обратный переход: большое количество аналогичных проектов имеет смысл стандартизировать и таким образом "перевести" в процессы -- правда, особого рода. Более того, само управление проектами стандартизовано как совокупность совершенно определенных процессов. Как заметил Сергей Гузик, руководитель рабочей группы ISACA.ru, в стандарте CobiT управление проектами рассматривается как отдельный процесс, обладающий способностью порождать другие процессы.
Генеральный директор компании PSM Consulting Марина Грашина отметила, что размывание границы между задачами, предполагающими ту или иную форму управления, -- не что иное, как следствие общей тенденции, которая просматривается в эволюции любых методологий, разработанных для близких областей деятельности. У каждого подхода по мере совершенствования расширяется сфера применения, а эти сферы все сильнее пересекаются. Инструменты, заложенные в "пересекающихся" методологиях, часто дублируют друг друга, так что практики затрудняются с выбором. Ситуация с процессным и проектным управлением соответствует общей картине: к примеру, средства стратегического планирования и контроля разрабатываются и для процессов (BSC), и для проектов (portfolio management). Однако специалисты-консультанты, как правило, являются убежденными сторонниками какого-то одного из двух подходов и только его умеют применять, поэтому увязать процессы и проекты оказывается сложно.

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

От процесса к проекту

Как компании (и ИТ-директору) добиться того, чтобы в ее деятельности везде применялась наиболее эффективная форма управления -- там, где необходимо, проектная, а в остальных случаях процессная? Очевидно, что процессы, особенно требующие повышенного внимания, необходимо переводить в проектную форму, а иногда нужен и обратный переход. Как осуществлять всё это?
Замену утративших адекватность процессов на проекты Григорий Ципес и Александр Товб предлагают проводить в три этапа. Прежде всего следует понять, какие процессы используются в компании, формально их описать и, если удастся, оптимизировать еще на уровне процессов -- может быть, это позволит сохранить их. Каждому процессу должен быть назначен владелец, который отвечает за его производительность, -- он и примет решение о том, следует ли в данном случае заменять процессное управление проектным. Далее надо разработать механизм реализации процесса в проектной форме с учетом соотношения времени и качества, а вслед за ним -- унифицированный механизм выполнения проектов, состоящий, естественно, из процессов.

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

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

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

Продвигаясь по пути стандартизации, компании сталкиваются с третьей проблемой: иногда у них оказывается слишком много -- два, три, а то и четыре -- независимых стандартов (общего профиля, отраслевой, отдельный стандарт управления проектами и т. д.). Как следствие деятельность сотрудников чрезмерно бюрократизируется, и в результате они начинают работать не на повышение, а на снижение эффективности. "У некоторых компаний, хотя это, конечно, довольно тяжелый случай, до 30% времени сотрудников уходит на заполнение разного рода бюрократических документов; таких затрат требует поддержание систем управления качеством", -- заметила Марина Грашина. В этих случаях необходимо грамотное объединение стандартов (в том числе для процессов и проектов).
Наконец, четвертая проблема: интеграции процессов и проектов непосредственно в деятельности предприятия мешает то, что они не связаны друг с другом в стратегическом плане. Процесс разработки стратегии компании существует сам по себе, а процесс управления портфелем проектов -- сам по себе, для них не существует единых механизмов контроля, планирования и оценки. Подгонка выбора проектов из портфеля под стратегические приоритеты невозможна просто потому, что "логика мышления находится в двух не пересекающихся плоскостях".

***
Тем не менее некоторые положительные сдвиги в этой области есть. Компании уже начинают вырабатывать критерии для разделения проектного и процессного подходов, причем применительно как к своей внешней, так и к внутренней деятельности. Формализуются бизнес-процессы, описываются бизнес-роли и упорядочивается распределение ответственности в управлении не только отдельными проектами, но и их портфелем, а также компанией в целом, постепенно снижается дублирование функций разными подразделениями. В таком же направлении развиваются и стандарты. Так, одним из главных, на взгляд Сергея Гузика, новшеств недавно выпущенной редакции CobiT 4.0 стало то, что для каждого процесса в стандарте теперь четко заданы входы, выходы и прописаны матрицы ответственности. "Для любого процесса вы можете собрать рабочую группу и каждому сказать, за что он должен отвечать и что делать в соответствии с CobiT, какой документ готовить, каких коллег информировать и т. д.", -- поясняет он. Тем не менее еще только предстоит создать некоторое единое понятийное и нормативное поле (а еще лучше -- единый стандарт), в котором будут учтены как отраслевые стандарты, так и стандарты управления процессами и проектами.