Процессы и проекты – вместе ли?

Зачем управлять проектами?

Управление проектами, в современном смысле слова, началось в 50-х годах прошлого века, хотя корнями эта дисциплина уходит в ХIX век. Потребность в умении управлять проектами возникла в деловой среде, осознавшей выгоды от упорядочения работ и опасность несогласованных действий большого количества подразделений и специалистов. Космические программы NASA – одно из первых практических применений теории управления проектами в истории. Сегодня эти приемы используются военными, государственными и. конечно, коммерческими предприятиями.

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

УПРАВЛЕНИЕ ПРОЕКТОМ

Конечно, кроме этих, существует ряд других ограничений, в рамках которых приходится вести проект. Часто определяются дополнительные ограничения управления проектом.

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

• Ресурсы, то есть активы, которые можно использовать в проекте, чтобы получить конечный результат. Примечательно именно противопоставление двух ограничений: стоимости и ресурсов. Некоторые ресурсы нельзя приобрести в готовом виде. Ярким примером такого типа ресурсов являются знания, а точнее – накопленное организацией умение управлять проектом. В ходе проекта следует применять имеющийся и получать новый опыт, а по окончании – анализировать и аккумулировать его для последующего использования.

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

Практика управления проектом направлена на результативное и рациональное управление данными ограничениями в ходе проектов.

Зачем управлять процессами?

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

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

Другой классический пример бизнес-процесса можно процитировать из работы отца экономической теории Адама Смита (Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations, 1776). Он описывал фабрику по производству булавок:

«Один человек вытягивает металлический прут, второй его выпрямляет, третий режет на части, четвертый заостряет один конец, а пятый наносит на другой резьбу для головки; изготовление головки состоит из двух или трех отдельных операций: насадить – одно дело, отшлифовать – другое… Таким образом важная работа по изготовлению булавок делится примерно на 18 различных операций, которые на некоторых фабриках все выполняются разными руками, а на других один человек будет выполнять две или три из них».

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

Процессом следует управлять на трех базовых уровнях:

1. Уровень экземпляра, на этом уровне предпринимаются корректирующие воздействия на каждый экземпляр процесса

2. Уровень архитектуры процесса: на этом уровне оцениваются результаты работы процесса за некоторое время и предпринимаются корректирующие воздействия на сам процесс. Для процесса следует определить следующие неотъемлемые характеристики:

а) события, которые запускают процесс («Триггеры»);

б) данные и ресурсы, которые нужны для того, чтобы деятельность в процессе выполнялась, на входе в процесс и в каждый вид деятельности («Входы»);

в) данные и результаты, которые создаются в каждом виде деятельности и в процессе в целом («Выходы»);

г) описание видов деятельности и закрепление ответственности за исполнителями;

д) параметры качества деятельности и результатов;

е) стоимость, затрачиваемые ресурсы и время;

ж) инструменты измерения экземпляров процесса и накопления результатов.

3. Уровень результата: на этом уровне нужно управлять предоставлением и потреблением стабильных результатов процесса. Нужно четко понимать, для чего этот результат нужен и насколько важна стабильность его получения.

УПРАВЛЕНИЕ ПРОЦЕССОМ

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

А вместе?

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

Бизнес-процесс — это повторяемая совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. (http://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81)

Проект– это уникальная совокупность видов деятельности, имеющая начало и конец во времени, направленная на создание определенного, уникального продукта или услуги, при заданных ограничениях по ресурсам, срокам, качеству и уровню риска (ГОСТ Р ИСО 9000-2008. Системы менеджмента качества. Основные положения и словарь).

Некие входы, путем управления ограничениями, превращаются за несколько последовательных действий в результат. В определении из стандарта ГОСТ только одно уточнение — уникальность. А в глоссарии международного стандарта систем менеджмента качества ISO/IEC 9000-2005 проект вообще определяется как «уникальный» процесс!

Так в чем же управленческая разница?

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

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

Что в ИТ?

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

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

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

Эта конструкция позволяет взглянуть на две обсуждаемые области менеджмента с точки зрения ресурсного конфликта.

Типичные ситуации

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

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

Пример. Системный администратор постоянно поддерживает работоспособность своих систем: обновляет ПО, отслеживает производительность, управляет доступом. Его могут привлекать в проекты, например совершенствования ИТ-архитектуры или обучения новых команд технической поддержки пользователей. Вопрос рационального разделения времени данного сотрудника нетривиальный.

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

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

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

Константин Нарыжный (k.naryzhny@cleverics.ru) — тренер-консультант компании Cleverics