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

ИТ-менеджмент можно условно разделить на управление ИТ-процессами и ИТ-проектами. Такое разделение не специфично для ИТ: те же правила и практики действуют в любой сфере деятельности.

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

Статья посвящена выходу в 2012 году русского издания всемирно известной сатирической книги Брайана Джонсона и Пола Вилкинсона Project managing ITSM from hell.

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

Любую техническую проблему можно преодолеть, имея достаточно времени и денег.
Следствие: Вам всегда будет не хватать либо времени, либо денег.

Народная мудрость

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

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

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

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

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

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

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

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

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

Другой классический пример бизнес-процесса можно процитировать из широко известной работы отца1 экономической теории Адама Смита. Он описывал фабрику по производству булавок:

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

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

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

  1. Уровень экземпляра, на этом уровне предпринимаются корректирующие воздействия на каждый экземпляр результата
  2. Уровень архитектуры процесса: на этом уровне оцениваются результаты работы процесса за некоторое время и предпринимаются корректирующие воздействия на сам процесс. Для процесса следует определить следующие неотъемлемые характеристики:
    • События, которые запускают процесс («Триггеры»)
    • Данные и ресурсы, которые нужны для того чтобы деятельность в процессе выполнялась на входе в процесс и в каждый вид деятельности («Входы»)
    • Данные и результаты, которые создаются в каждом виде деятельности и в процессе в целом («Выходы»)
    • Описание видов деятельности и закрепление ответственности за исполнителями
    • Параметры качества деятельности и результатов
    • Стоимость, затрачиваемые ресурсы и время
    • Инструменты измерения экземпляров процесса и накопления результатов
  3. Уровень результата: на этом уровне нужно управлять предоставлением и потреблением стабильных результатов процесса. Нужно чётко понимать, для чего этот результат нужен, и насколько важна стабильность его получения.

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

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

А вместе?

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

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

Некие входы, путем управления ограничениями, превращаются за несколько последовательных действий в результат. В том определении из стандарта только одно уточнение: уникальность.

А в глоссарии международного стандарта систем менеджмента качества ISO/IEC 9000-20052, проект вообще определяется как «уникальный» процесс!

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

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

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

Что в ИТ?

«Вредный совет» менеджеру ИТ-проекта:

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

Brian Johnson, Paul Wilkinson

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

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

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

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

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

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

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

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

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

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


Сноски

  1. Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations (1776)
  2. С российской локализацией стандарта ISO/IEC 9000 можно ознакомиться: http://protect.gost.ru/document.aspx?control=7&baseC=6&page=0&month=1&year=2009&search=9000&id=174284
  3. Управление ITSM-проектами от лукавого. Сборник вредных советов. Пол Вилкинсон, Брайан Джонсон

Автор: Константин Нарыжный.

Константин Нарыжный

Менеджеры по работе с клиентами

Карина Усищева
Карина Усищева
Марина Колесникова
Марина Колесникова
Анжелла Шленская
Анжелла Шленская