ИТ-менеджмент можно условно разделить на управление ИТ-процессами и ИТ-проектами. Такое разделение не специфично для ИТ: те же правила и практики действуют в любой сфере деятельности.
В этой статье приводится обзор обеих областей, сравнение их целей и подходов и описывается взаимосвязь между ними – в применении к информа¬ционным технологиям.
Статья посвящена выходу в 2012 году русского издания всемирно известной сатирической книги Брайана Джонсона и Пола Вилкинсона Project managing ITSM from hell.
Зачем управлять проектами?
Народная мудростьЛюбую техническую проблему можно преодолеть, имея достаточно времени и денег.
Следствие: Вам всегда будет не хватать либо времени, либо денег.
Управление проектами, в современном смысле слова, началось в пятидесятых годах прошлого века, хотя корнями эта дисциплина уходит в век девятнадцатый. Потребность в умении управлять проектами возникла в деловой среде, осознавшей выгоды от упорядочивания работ и опасность несогласованных действий большого количества подразделений и специалистов. Космические программы NASA – одно из первых практических применений теории управления проектами в истории. Сегодня эти приёмы используются и военными, государственными и, конечно, коммерческими предприятиями.
Часто ключевую задачу управления проектами изображают в виде треугольника, иллюстpирующего совокупность трёх главных ограничений, влияющих на ход и успешность проекта, а также на восприятие результата заказчиком. Это время, стоимость и охват. Управленец обязан делать так, чтобы проект работал и достигал результата, оставаясь в рамках этих ограничений, чтобы обеспечить конечную удовлетворённость заказчика результатом.
Конечно, кроме этих, существует ряд других ограничений, в рамках которых приходится вести проект. Часто определяются дополнительные ограничения управления проектом:
- Качество, как отдельная от охвата проекта характеристика. Плановым качеством тоже можно частично жертвовать, чтобы соблюсти другие ограничения проекта. Управление качеством и контроль качества часто выполняются внепроектными ресурсами: ведь следует оценивать не только конечный продукт, и промежуточные результаты, но и сами проектные работы.
- Ресурсы, то есть активы, которые можно использовать в проекте, чтобы получить конечный результат. Примечательно именно противопоставление двух ограничений: стоимости и ресурсов. Некоторые ресурсы нельзя приобрести в готовом виде. Ярким примером такого типа ресурсов являются знания, а точнее – накопленное организацией умение управлять проектом. В ходе проекта следует применять имеющийся и получать новый опыт, а по окончании – анализировать и аккумулировать его для последующего использования.
- Риски, то есть те события, которые могут произойти в будущем и существенно повлиять на ход проекта. Влияния этих событий необходимо предсказывать и готовиться к их возможному наступлению.
Практика управления проектом направлена на результативное и рациональное управление данными ограничениями в ходе проектов.
Зачем управлять процессами?
Уникальность проектов служит преддверием процессной деятельности и направлена на создание тех самых ресурсов, которые впоследствии будут использоваться процессами.
Другой классический пример бизнес-процесса можно процитировать из широко известной работы отца1 экономической теории Адама Смита. Он описывал фабрику по производству булавок:
Действительно, агенты формализуют процессы, чтобы раз за разом стабильно получать одинаковые результаты, используя одинаковый набор ресурсов.
Процессом следует управлять на трёх базовых уровнях:
- Уровень экземпляра, на этом уровне предпринимаются корректирующие воздействия на каждый экземпляр результата
- Уровень архитектуры процесса: на этом уровне оцениваются результаты работы процесса за некоторое время и предпринимаются корректирующие воздействия на сам процесс. Для процесса следует определить следующие неотъемлемые характеристики:
- События, которые запускают процесс («Триггеры»)
- Данные и ресурсы, которые нужны для того чтобы деятельность в процессе выполнялась на входе в процесс и в каждый вид деятельности («Входы»)
- Данные и результаты, которые создаются в каждом виде деятельности и в процессе в целом («Выходы»)
- Описание видов деятельности и закрепление ответственности за исполнителями
- Параметры качества деятельности и результатов
- Стоимость, затрачиваемые ресурсы и время
- Инструменты измерения экземпляров процесса и накопления результатов
- Уровень результата: на этом уровне нужно управлять предоставлением и потреблением стабильных результатов процесса. Нужно чётко понимать, для чего этот результат нужен, и насколько важна стабильность его получения.
В общем случае, три уровня процесса управляются различными людьми, различными приёмами и на разных интервалах времени.
А вместе?
Как уже было сказано, менеджмент состоит из процессной и проектной части. А из изложенного выше видно, что граница между целями двух областей весьма тонка.
| Бизнес-процесс — это повторяемая совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. | Проект – это уникальная совокупность видов деятельности, имеющая начало и конец во времени, направленная на создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам, срокам, качеству и уровню риска. |
Некие входы, путем управления ограничениями, превращаются за несколько последовательных действий в результат. В том определении из стандарта только одно уточнение: уникальность.
А в глоссарии международного стандарта систем менеджмента качества ISO/IEC 9000-20052, проект вообще определяется как «уникальный» процесс!
Так в чем же управленческая разница?
Менеджеры проектов отвечают за создание результатов, действуя в рамках жёстких ограничений, описанных выше. Результатами этими, как ресурсами, будут пользоваться менеджеры процессов, чтобы поддерживать стабильную удовлетворенность заказчика (результаты проектов используются на уровне управления архитектурой процесса). Верно и следующее: потребность в новых ресурсах будет возникать в ходе совершенствования процессов, а значит, будут запускаться всё новые проекты, которые будут пользоваться, в частности, системно предоставляемыми процессными ресурсами и результатами.
Таким образом, проекты становятся частью процессного подхода к управлению.
Что в ИТ?
Brian Johnson, Paul WilkinsonЕсли же вас в самом деле поймают на бездействии, лучший способ реагирования – подготовить отчёт о нарушении, свалив в нем вину на одного из линейных менеджеров, сорвавшего вам выполнение плана несвоевременным выделением ресурсов.
Важно помнить, что процессными активами, формированием которых занимаются ИТ-проекты, являются не только инструменты (иначе говоря, средства автоматизации), но в первую очередь – исполнители (то есть ИТ-специалисты), а также принципы их взаимодействия и мотивации (capabilities, способности).
Рассуждая дальше, можно сказать, что те же квалифицированные исполнители, принципы их взаимодействия и мотивация могут быть использованы и в ходе других проектов, формирующих новые процессные активы.
Эта конструкция позволяет взглянуть на две обсуждаемые области менеджмента с точки зрения ресурсного конфликта.
Типичные ситуации:
- Процессные менеджеры не вовлечены в проекты, их требования к результату (возможно, отличные от требований заказчика) не учитываются. Поэтому сформированный в ходе проекта результат может не достичь требуемого уровня качества и не будет принят в эксплуатацию. Другой вариант: проект как бы продолжается и после ввода результата в эксплуатацию, а участники проекта начинают его поддержку «по-своему» и без оглядки на сложившиеся практики ИТ-процессов. В таком случае количество совершенно не связанных между собой ИТ-систем увеличивается с каждым проектом.
- Ресурсные конфликты. Как было сказано ранее, в проектах могут и должны быть задействованы сотрудники, ежедневно выполняющие деятельность в рамках процессов.
За рамками данной публикации остались ИТ-проекты, которые выполняются внешними организациями. В таких проектах эти два конфликта проявляются еще ярче.
Взаимодействие между процессами и проектами в организациях не всегда налажено, что приводит к трудностям и дополнительным рискам. Непонимание и отсутствие интерфейсов между этими областями вполне очевидно. В итоге подобные конфликты негативно сказываются на качестве ИТ-решений.
Задачей высшего звена ИТ-руководителей становится поиск общего языка между процессами и проектами, настройка обмена информацией, потоков ресурсов и активов между двумя крупными «лагерями» в ИТ. Увязывание целей, задач, планов и правил взаимодействия для этих областей, с тем, чтобы ИТ в целом приносило пользу заказчику – вопросы, рассматриваемые в новой для нас, но набирающей популярность дисциплине: IT Governance: корпоративное (или стратегическое управление информационными технологиями с тем, чтобы не вникая в детали, можно было быстро идентифицировать и устранять конфликты «лагерей».
Сноски
- Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations (1776)
- С российской локализацией стандарта ISO/IEC 9000 можно ознакомиться: http://protect.gost.ru/document.aspx?control=7&baseC=6&page=0&month=1&year=2009&search=9000&id=174284
- Управление ITSM-проектами от лукавого. Сборник вредных советов. Пол Вилкинсон, Брайан Джонсон
Автор: Константин Нарыжный.
