Аутсорсинг процессов управления ИТ

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

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

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

В качестве иллюстрации в книге приведены краткие характеристики почти 500 аутсорсинговых контрактов в сфере ИТ.

Значительно более широкий взгляд на аутсорсинг демонстрирует книга (Koulopoulos, 2006), где вводится понятие "умного" сорсинга как инновационного поведения, направленного на выявление и развитие ключевых компетенций и делегирования всех неключевых компетенций глобальным партнерам по всему миру. Цель такого поведения - максимизация интеллектуальных ресурсов организации за счет того, что "они не отвлекаются на выполнение несущественной работы, а организация не тратит ресурсы на преодоление своей слабости". Авторы показывают, что успешные решения об использовании аутсорсинга не были продиктованы экономическими соображениями. Целью таких решений было формирование и развитие компетенций, что предполагало изучение и фундаментальное улучшение (или создание новых) процессов организации, поскольку компетенции складываются из процессов, интеллектуальных ресурсов и человеческих ресурсов.

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

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

Выражение "выполнение процессов управления ИТ" здесь имеет широкий смысл: от выполнения экземпляра какого-то процесса в конкретном проекте до выполнения всех экземпляров целой группы процессов во всех проектах.

Таким образом, аутсорсинговый контракт (рис 18.1) должен помимо требований к выполнению процессов (например требований к эффективности, оперативности, результативности и т. п.) содержать следующие условия:

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

В то же время ряд аспектов организации ИТ-аутсорсинга остается за границами процессного подхода и не охватывается этим определением. Это, например, следующие темы:

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

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

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

Таким образом, аутсорсеру полностью или частично передаются:

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

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

Использование понятия аутсорсинга процессов управления ИТ хорошо описывает существующую практику. Например, в случае стратегического аутсорсинга, о котором говорилось выше, аутсорсеру на самом деле передаются все процессы управления ИТ (выстроенные, скажем, в соответствии с процессными моделями COBIT, Val IT, Risk IT). Если речь идет об управлении инфраструктурой, то, опять-таки, аутсорсеру передаются процессы управления инфраструктурными ресурсами, например процессы обновления, увеличения мощности, замены и т. п. Аутсорсинг приложенийДля обозначения этой деятельности часто используется аббревиатура SaaS - от англ. Software as a Service. , при котором они передаются внешней организацииТакая организация называется ASP - от англ. Application Service Provider. , подразумевает выполнение этой организацией процессов жизненного цикла приложений. Аналогично можно рассматривать такую деятельность, как предоставление услуг сети передачи данных, когда аутсорсер выполняет процессы предоставления услуг по передаче и процессы жизненного цикла сети. Таким образом, процессный взгляд обеспечивает определенное методическое единообразие при анализе деятельности аутсорсеров и позволяет воспользоваться всем накопленным процессным теоретическим багажом для применения ИТ-аутсорсинга на практике. Проще говоря, не бывает ИТ-аутсорсинга, который не включал бы требований к выполнению процессов; более того, именно способность выполнять процессы является тем, что принципиально отличает одного аутсорсера от другого.

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

В (Halvey J., 2005) рассматривается более общая задача аутсорсинга бизнес-процессовТам эта деятельность называется BPO - от англ. Business Process Outsourcing. . ИТ-аутсорсинг входит сюда как часть, обеспечивая передачу аутсорсеру обслуживания "ИТ-компонентов, поддерживающих бизнес-операции", например центра обработки данных или совокупности персональных компьютеров. На самом деле, как нетрудно видеть, речь здесь идет о передаче на аутсорсинг процессов управления избранными ИТ-ресурсами.

Выбор схемы аутсорсинга процессов

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

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

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

Пример организационных форм:

Примеры процессов позаимствуем из эталонной модели ГОСТ Р ИСО/15288:

В таблице 18.1 показано, как могла бы быть организована схема аутсорсинга в нашем примере.

Разумеется, как организационные формы, так и модель процессов ГОСТ Р ИСО/МЭК 15288 могут быть заменены на другие. Например, ИТ-деятельность организации в целом может быть распределена между ИТ-организациями ее дочерних компаний. При этом может существовать несколько бизнес-единиц, отвечающих за выполнение процессов: бизнес-единица, отвечающая за разработку ИС, бизнес-единица, отвечающая за управление ИТ-инфраструктурой, бизнес-единица, отвечающая за глобальную сеть передачи данных и предоставление соответствующих услуг. Некоторые бизнес-единицы могут также работать и на свободном рынке.

Приведенная таблица иллюстрирует три важных соображения.

Во-первых, использование точно описанной модели процессов при описании аутсорсинговой схемы позволяет чётко определить границы полномочий и ответственности ее участников. Отметим, что в этой схеме существует участник, отвечающий за организацию процессов и управление схемой. Это ИТ-организация, владеющая процессами "Управление средой предприятия" и "Управление процессами жизненного цикла". Согласно ГОСТ Р ИСО/МЭК 15288, целью первого из них является "определение и проведение политики и процедур, необходимых для функционирования организации в соответствии с положениями настоящего стандарта".

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

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

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

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

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

Цели аутсорсинга процессов и выбор аутсорсера

Принятие процессной точки зрения позволяет по-новому взглянуть на вопрос о целях и мотивах ИТ-аутсорсинга.

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

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

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

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

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

ГОСТ Р ИСО/МЭК 12207:

ГОСТ Р ИСО/МЭК-15288:

COBIT:

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

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

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

В части 8 Отчета SPICE (см. "Лекция 8. Практическое использование CMM. Проект SPICE") специально рассматривается задача оценки развитости процессов поставщика продуктов или услуг для оценки рисков при выборе поставщика. Предлагаемый в Отчете подход применим как в случае привлечения единственного внешнего поставщика, так и в случае выбора генподрядчика.

Упрощенно задача решается в три шага:

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

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

Риски, связанные с аутсорсингом процессов

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

Пример 1. Организация-заказчик не располагает собственными развитыми процессами, необходимыми для управления аутсорсером, например процессами обеспечения качества, процессами управления изменениями, процессами управления проектами и т. п. На практике это приводит к следующим последствиям:

Пример 2. Организация-заказчик не может адекватно оценить собственный уровень развитости процессов, и выбирает аутсорсера с более высоким, чем необходимо, уровнем развитости. В результате использования аутсорсинга для решения конкретных задач (например выполнения ИТ-проекта / ИТ-программы или организации управления ИТ-услугами) повышение уровня развитости отдельных процессов организации происходит нескоординированно. Это противоречит плановому подходу, представленному на рис. 11, когда сначала разрабатывается план согласованного улучшения процессов, затем проводится оценка, затем план уточняется и т. д. В отсутствие такого плана возникают дисбалансы развитости процессов, когда корпоративные процессы отстают в развитости от "арендованных" процессов управления ИТ. То, что эти дисбалансы могут оказаться опасными, показывает следующий пример (в (OGC, 2007a) похожая ситуация называется "Золотой пони").

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

Приведенные примеры показывают, насколько важно адекватно оценивать риски, связанные с процессами, при подготовке к ИТ-аутсорсингу.

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

Применительно к аутсорсингу процессов управления ИТ этот перечень будет выглядеть следующим образом:

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

Краткие итоги

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

Вопросы

Заключение

Я надеюсь, что мне удалось показать фундаментальную роль процессов при анализе деятельности ИТ-организаций и отчасти ИТ-бизнеса. Процессный взгляд на организацию управления ИТ оказался полезным не только в теории, где он объединяет множество разных моделей и методик, но и на практике. Потенциал процессного подхода еще не раскрыт полностью, и потребуются значительные теоретические усилия, прежде чем в области управления ИТ возникнут свои фундаментальные концепции и стандарты, аналогичные, например, концепциям MRPII, SCM, CRM и другим.

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

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

Я был бы признателен всем, кто знает (или думает, что знает) ответы на эти вопросы и готов поделиться своими соображениями на этот счет.