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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы

1. Что такое аутсорсинг процессов управления ИТ?
2. Какова структура контракта при аутсорсинге процессов управления ИТ?
3. Как можно использовать модели процессов при построении схемы аутсорсинга?
4. Какую роль при аутсорсинге процессов играет оценка зрелости процессов?
5. Как процессный подход может помочь при оценке рисков аутсорсинга?

Заключение

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

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

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

1. Существуют ли признанные или лучшие практики для не рассмотренных в книге вспомогательных процессов ИТ-организаций, таких как управление знаниями, обучение ИТ-персонала и т. п.? Если да, то как выглядят соответствующие эталонные процессные модели?
2. Как выглядит общая для всех рассмотренных процессов система понятий? Какой уровень специальных знаний необходим для реализации процессов управления ИТ и решения возникающих управленческих задач? (Этот вопрос возник в связи с нарастающей за рубежом тенденцией назначать на позиции CIO людей без специального образования).
3. Как оценить соотношение затрат и выгод от улучшения процессов?
4. Как связана целесообразность внедрения эталонных моделей процессов управления ИТ с размерами компаний? Проще говоря, имеет ли смысл внедрять процессы управления ИТ в малых компаниях (которые могут тем не менее иметь большие обороты и прибыли)?

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