Один вид управления работами — это регулярный процесс. У него есть свой результат, но есть и свои проблемы. Второй вид управления — индивидуальный проект, и инновационные работы обычно являются проектной деятельностью. Однако в реальной жизни они, как правило, переплетены воедино: проект представляет собой компонент регулярного процесса, и наоборот, регулярный процесс — это часть проекта. Тем не менее бывают ситуации, когда в силу характера нашей деятельности ни один из подходов — ни проектный, ни процессный — не может предоставить нам адекватных инструментов для управления ею. Эта тема обсуждалась на VI конференции «Стандарты в проектах современных информационных систем», организованной фондом ФОСТАС в октябре 2007 года.

Отличия проектов от процессов

Как метод управления регулярный процесс отличается от проекта, и подмена одного другим обычно приводит к плачевным результатам. Проект — это не повторяющаяся регламентная инструкция, а творческий процесс: написать для него четкую последовательность действий в виде регламента практически нереально. На VI конференции «Стандарты в проектах современных информационных систем», организованной фондом ФОСТАС, докладчики привели не один пример компаний, руководство которых считало, что абсолютно все действия сотрудников любого уровня можно представить как регулярные процессы и формализовать в виде регламентов и инструкций. В том числе и внедрение ИТ-системы. Точка зрения была весьма радикальной: по мнению таких руководителей достаточно подобрать грамотных специалистов, жестко регламентировать процедуру внедрения — и всё будет хорошо. При тиражировании информационной системы в регионах не предусматривалось ни согласования интересов филиалов, ни учета ресурсной ситуации и т. д.

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

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

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

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

Переплетение проектов и процессов

Однако несмотря на столь глубокие, некоторые даже считают, непреодолимые различия в проектах и процессах, реальная жизнь устроена интересным образом: они очень часто идут рука об руку. Если мы работаем в проектном подходе, то тогда процессы нередко используются как некоторый набор инструментов. А если в процессном — то проекты могут выступать в качестве элементов некоторых процессов. Более того, если существует некий процесс, то его изменение, привнесение инноваций в него, как правило, является проектом. А в современных рыночных условиях это происходит практически постоянно. Но в то же время и управление проектами происходит постоянно, т. е. компания на регулярной процессной основе осуществляет управление индивидуальными проектами.

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

Когда проект, а когда процесс

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

Поэтому встает очень важный вопрос: какие задачи должны решаться в рамках проектного подхода, а какие — в рамках процессного и как их разграничить. В реальной жизни грань между проектами и процессами очень шаткая. Каждая компания, которая внедряет методологию проектного управления, как правило, строит некую систему критериев, определяющих, что относить к проекту, а что нет. И, как правило, система критериев строится на основе оценки трудоемкости (или бюджета). Типичный показатель — трудоемкость: его расчёт по 20—30 человеко-дням — это текущая маленькая задача, по 50—70 — средняя, по 100—150 человеко-дням — задача крупная, но все-таки выполняемая в рамках регулярных процессов, пока еще не проект. Ну а если трудоемкость переваливает за 150 человеко-дней, то это уже определяется как проект.

Такая схема принятия решений проект/процесс очень распространена, причем и в западных компаниях, но ее недостатки очевидны. Виктор Галактионов приводит пример установки антивирусного ПО на клиентские места сотрудников в географически распределенной компании, имеющей несколько тысяч ПК. Понятно, что сделать это довольно трудно, и по показателю трудоемкости такую активность надо определять как проект. Но посмотрим с точки зрения рисков. Риски при этом практически нулевые — в 99,9% случаев установка будет проходить нормально. А ведь, как мы писали выше, без рисков нет проекта. Поэтому такую деятельность скорее имеет смысл определять как крупную, но все-таки регулярную задачу. Ее надо ставить на контроль, но не инициировать проект, а контролировать по простым метрикам регулярного процесса, скажем, на скольких ПК программа уже обновлена и сколько затрачено человеко-часов, и этого оказывается вполне достаточно. Вся мощь проектного управления здесь просто не нужна.. Есть и обратный пример — внесение изменений в некий процесс в ERP-системе. Изменения небольшие, задача маленькая, трудоемкость — пара дней работы двух программистов. Но при этом есть крупные риски: данное изменение требует разработки инструкций к бизнес-процессу, их согласования не только с его прямыми участниками, но и со смежными подразделениями, необходимо проанализировать, как это изменение повлияет на другие бизнес-процессы в ERP-системе и на систему в целом. И есть серьезный риск не уложиться в срок. Такую смешную по трудозатратам задачу логично инициировать именно как проект, создать рабочую группу, регулярно проводить заседания проектного комитета. На конференции один из выступавших сказал, что однажды ему пришлось даже не выпускать людей с заседания до тех пор, пока нужный регламент не был согласован. В рамках регулярных процессов это не получилось бы.

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

Более того, для определения грани проект/процесс отнюдь не достаточно оценки трудозатрат и рисков. Еще один интересный пример привела на конференции фонда ФОСТАС генеральный директор компании PSM Consulting Russia Марина Грашина. Одно крупное предприятие, топ-менеджмент которого сильно ориентирован на проекты, начав с внедрения управленческой системы, настолько расширило рамки работ, что проект разросся в глобальную реорганизацию всего холдинга, включая системы мотивации и BSC. В результате такого глобалистского подхода проект практически принял форму перманентного процесса, и когда наконец его закончили, это было трехкратное превышение сроков, двукратное преувеличение бюджета, не считая колоссальных потерь времени на всевозможных совещаниях, утверждениях, уточнениях, изменениях и т. д. и т. п. И хотя, по словам Марины Грашиной, рентабельность работы предприятия за это время существенно повысилась, в рамках парадигмы проектного управления крайне трудно такой проект считать успешным.

Но в чем проблема, если рентабельность работы предприятия повысилась и все довольны? Проблема — в стандартных инструментах проектного менеджмента. Значит, надо просто отбросить критерии эффективности, присущие проектному управлению, а за ним и часть его методов. Но при этом часть все-таки оставить — ведь этот «перманентный проект» надо как-то вести. Собственно именно к такому компромиссному выводу склоняются ряд экспертов, и это прямо прозвучало на конференции фонда ФОСТАС. То, что внедрение ИТ-системы всегда должно идти по проектному пути, — это классика. И такая точка зрения была безусловно верной десять лет назад, но сейчас дело уже обстоит не совсем так. Опыт работы одного из авторов в западных компаниях свидетельствует, что сегодня многие компании имеют настолько серьезные и детально проработанные регламентированные процессы внедрения ИТ-решений, организуемого при этом как проект, что сам собой возникает вопрос — а действительно ли это проектная деятельность, связанная с учетом рисков, специфических проблем, возникающих уже в ходе выполнения задачи, и т. д.? Если эта деятельность так хорошо систематизирована и все правила прописаны наперед, то имеем ли мы право называть ее проектом? «Современные решения, по какому пути управления идти при реализации ИТ-внедрений (проектному или процесс­ному), скорее всего будут основываться на балансе, равновесии и компромиссе подходов, — говорит Марина Грашина. — Именно таковы основные тенденции развития внутренней идеологии проектного менеджмента и систем управления проектами. В частности, как уже показывает сегодняшняя практика корпоративного управления, при принятии подобного рода решений мы, вероятно, начнем использовать какие-то системы, которые позволят нам взвешивать то или иное мероприятие и определять, насколько оно должно быть реализовано в виде тактических операционных задач, насколько — в виде проекта. Такого рода процесс взвешивания должен быть достаточно объективным. То есть должны учитываться не только бюджет, общие трудозатраты и риски, но и все другие необходимые факторы, представляющиеся значимыми основным заинтересованным в результате сторонам. Два года назад рабочая группа по разработке новых стандартов и компетенций в области управления проектами (GAPPS) предложила матрицу Кроуфорд-Ишекуры как инструмент, позволяющий оценивать степень интегральной сложности проекта. Сегодня мы немножко расширили область применимости этой матрицы и используем ее как инструмент, который в системе управления портфелем проектов позволяет разделить проекты разной степени стратегической значимости и отдельно выделить операционные задачи, то есть определяет основные требования к методологии управления, используемым инструментам, глубине проработки стандартных документов и т. д.» Заметим, что так называемая таблица факторов для оценивания ролей Кроуфорд-Ишекуры была разработана в 2005 году как инструмент для различения ролей проектных менеджеров уровней 1 и 2 в соответствии с новым стандартом компетентности для проектных менеджеров (A Performance Based Competency Standard for Project Managers). И тогда она никак не была связана с задачами разделения проектов и процессов. Ее использование в практике управления проектами только начинается, и авторам ничего не известно об использовании таблицы Кроуфорд-Ишекуры для разделения проектных и процессных задач. Важно отметить, что даже применяя какие-то инструменты, надо четко понимать, что в области выбора между процессным и проектным подходами вряд ли возможны какие-то общие стандартные советы. Такой выбор делается не на каком-то уровне абстракции, а только для конкретной ситуации и задачи. Ведь это решение может зависеть от массы факторов — отрасли, динамики развития, целей и показателей, которых хочет достичь компания, корпоративной культуры, личных характеристик и пристрастий ее менеджмента, внешних консультантов и т. д. и т. п.

Третий тип управления

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

Интересный пример привел на конференции президент Фонда ФОСТАС и директор аналитического бюро «Группа 24» Евгений Зиндер. В процессе поддержки и развития ИТ-систем возникает много мелких работ по их модификации, по созданию отчетов. Каждая из них — фактически мини-проект, и для их выполнения проектная культура очень важна. Однако, во-первых, обычные механизмы проектного управления несут с собой слишком много накладных расходов, которые в случае маленьких проектов не оправданны. А во-вторых, подобных мелких работ такое количество, что эти мини-проекты фактически превращаются в регулярный процесс. Поэтому уже в течение некоторого времени обсуждается так называемое «легкое» управление проектами (project management light). Его идея — привнесение прежде всего не «бюрократических» инструментов планирования и администрирования, а базовой проектной культуры, причем для всех участников работ начиная с исполнителей. А применение инструментов проектного планирования и администрирования стоит вводить уже на этой базе, причем делать это самыми минимальными шагами, что позволяет обойтись без заметного увеличения накладных расходов. Все это в разных формах существует в жизни — на практике многие компании примерно так и поступают. Однако, есть все основания считать, что этот подход достоин развития и отдельной методики.

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

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

Обратим внимание на очень важный момент: говорить о третьем типе управления имеет смысл именно в ситуации большой неопределенности, вызванной очень высокой изменчивостью внешних условий или большими рисками других видов. Если и проект, и процесс в общем представляют собой цепочки действий, обязательно заканчивающихся неким конечным набором результатов, который мы можем предугадать, то третий тип управления имеет дело с ситуациями, где неопределенность значительно выше, — мы не знаем, какие могут быть результаты. Как управлять такой деятельностью? Ведь от простого механического объединения и переплетения процессных и проектных подходов сущность проблемы не изменится — неопределенность не станет меньше. Таким образом, именно здесь имеет смысл искать третий тип управления. Условно его можно назвать так: управление в ситуации очень высокой степени изменчивости условий и больших рисков других видов.

«Деятельность в условиях высочайшей неопределенности, в условиях, когда очень высока степень изменчивости внешней среды, не укладывается ни в рамки процессного, ни в рамки проектного управления, — резюмирует Евгений Зиндер. — Это особый третий вид деятельности. Причем важно, что изменчивость внешней среды не просто высока, а выше, чем скорость принятия решений в процедурах проектного управления. Пока проджект-менеджеры будут решать, как провести изменение и завершить проект, ситуация успеет еще раз измениться. В этих условиях управление рисками строится совершенно по-другому, причем оно ложится не только на руководителей. Управление риском и, что важно, сам риск «размазаны» по всем участникам, включая исполнителей. Речь идет не о какой-либо «новой волне» управления проектами, работать с такими ситуациями в рамках управления проектами уже нельзя. Это управление условно «третьего типа», так как хорошего названия ему пока еще не придумали. Однако примерами такой деятельности давно служат военные операции разных масштабов». Как сказал на конференции Александр Райков, председатель совета директоров ОАО «Исследование глобальный сетей “GLOWERS”», если взять все уставы и инструкции всех солдат, сержантов и т.д., то все равно увидим, что нигде не написано, как взять «высоту 2405», особенно, если эта высота на другой стороне реки, а реку еще надо форсировать.

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