Глупые мысли об IT

Привет, народ!

Продолжаю свое краткое изложение мыслей об аутсорсинге :). Предыдущий пост – часть 1. Хочу сразу же сказать, отвечая на коментарий Жени Я., что я не против аутсорсинга. Аутсорсинг “работает”.  Только как и ко всему, к решению аутсорсить IT надо подходить с позиции здравого смысла. Все мы, замечаем это или нет, пользуемся услугами аутсорсеров. Например, наши друзья переезжали из квартиры в другое жилье. Вместо того, чтобы самим мучаться и вымывать квартиру для инспекции агенством, которое сдало им эту квартиру, они “за-аутсорсили” эту функцию женщине, которая этим занимается профессионально :) Смысл тратить свое время, мучаться до полуночи, если можно немного заплатить и кто-то за тебя сделает уборку, к тому же быстрее и лучше!? Или еще такой пример, не совсем корректный, но все же: я сам не обслуживаю нашу Тойоту. Весь сервис производится сервисным центром Тойоты. Думаю, мой бы сервис не сравнился по качеству с официальным центром Тойоты :) Пример не совсем корректный потому, что я сам никогда не занимался обслуживанием машины. Тут и аутсорсить было нечего, но можно сказать, что решение об аутсорсинге было принято сразу :)
Немножко определений терминов: когда я употребляю “бизнес”, “компания”, то я имею в виду организацию, которая собирается аутсорсить IT. “Аутсорсер” – это IT компания, которая предоставляет соответствующие услуги :)
Теперь позвольте мне выразить мое мнение, когда можно начинать задумываться об аутсорсинге:

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

Вот основные 4 пункта, если я не пропустил что-то еще. Теперь немножко подробнее о каждом утверждении:

Касательно п.1: как правильно заметил Сергей В., аутсорсить ключевые функции IT подобно самоубийству. Но это если только от IT зависит способность бизнеса функционировать и генерировать прибыль. Компания, которая полагается на IT для улучшения своей конкурентно-способности на рынке имеет меньше причин аутсорсить IT чем та организация, для которой IT – всего-лишь одна из немногих служб, так или иначе просто способствующих гладкому ходу бизнеса. Как склад. В первом случае мы имеем дело с компанией типа “Амазон”, хотя, не скрою, я могу быть и не прав в своей оценке. “Амазон” имеет прекрасную “площадку” для продажи бумажных и электронных книг; устройство для чтения книг, интегрированное с этим электронным магазином; “облачные” сервисы и т.д. Это то, что выделяет “Амазон” на рынке услуг и эти сервисы лично я бы никогла бы не аутсорсил. Хотя другие компоненты, например, производство “ридеров”, не могут быть произведены кроме как с помощью сторонних компаний. Теперь представим себе компанию, которая, к примеру, занимается продажей предметов искусства. Для нее IT – это всего-лишь вспомогательный механизм презентации основных товаров, способ связи с клиентами и прочее. Компания вполне может существовать, пользуясь стандартными IT сервисами со стандартной функциональностью и IT сервисы для нее не дают абсолютно никакого преимущества над конкурентами. Такая компания будет заинтересована в аутсорсинге IT и получения заранее оговоренных сервисов по фиксированной цене.

П.2. Очень важный с моей точки зрения. Состояние компаний в плане их развития и бизнеса можно описать приблизительно таким образом:

1. Динамичная компания, быстро растущая во многих направлениях. Структура компании постоянно меняется, меняются/могут менятся области бизнеса, нет жестких бизнес-процессов и т.п. IT департамент в такой компании скорее всего будет выглядеть подобным образом и будет состоять из группы инженеров/”эникейшиков”, которые будут на себе тянуть весь груз IT и пытаться удовлетворить постоянно меняющиеся требования бизнеса. Как результат – отсутствуют формализованные процессы, стандарты, политики и т.п.;
2. Компания, которая достигла определенной ступени развития; бизнес-процессы, структура компании и требования к IT более-менее сформулированы. IT департамент может начать внедрять ITIL для описания сервисов, соглашений об обслуживании и т.п. Но ITIL внедрена частично; стандарты, политики не полностью “покрывают” область IT; отсутствуют или описаны неполностью процессы взаимодействия IT и бизнеса; отсутствуют или описаны частично стратегия развития бизнеса и IT сервисов и т.д.;
3. “Зрелая” компания. Компания, в которой существует подробное описание бизнеса, функций, стратегии и т.д., т.е. архитектуры бизнеса. Департамент IT внедрил почти полностью ITIL, присутствует подробное описание архитектуры приложений, данных и систем (пример – TOGAF); Таким образом, бизнес имеет представление об IT, IT имеет представление о бизнесе и его задачах и старается выстроить свое развитие/стратегию в соответствии с требованиями/стратегией бизнеса.

В реальной жизни, конечно, бизнес и IT могут находиться на ступеньку выше или ниже. Т.е. Бизнес может достичь уровня 2, в то время как IT находится все еще на уровне 1. Не думаю, что возможны комбинации бизнес/IT 1-3 или 3-1, так как развитие IT определяется требованиями бизнеса.
Теперь предположим, что компания, находящаяся на уровне 1 или 2, попытается за-аутсорсить IT. Я думаю, попытка сделать это может провалиться или привести к неадекватному результату, сродни выстрелу в ногу :) Почему? Мне на ум приходят несколько причин:

1. Невозможность провести анализ объектов для аутсорсинга и возможных рисков для бизнеса, связанных со переносом IT сервисов и их поддержки. Т.е. непонятно, какими сервисами пользуются бизнес-пользователи; насколько IT интегрировано с бизнес-процессами: что будет, если мы “с корнем вырвем”, например, почту из зоны ответственности внутреннего IT и передадим аутсорсеру и т.д.;
2. Невозможность качественно и количественно оценить выгоду или ее отсутствие для аутсорсинга. Как можно оценить что-то, о чем и IT, и бизнес имеют крайне туманное представление!? Другими словами, полное отсутствие основы для анализа;
3. Проблемы интеграции с аутсорсером: процессы, стандарты, контроль качества, запрос ресурсов и т.д. Аутсорсер, если это хороший аутсорсер, имеет свои процессы и правила для взаимодействия с компаниями и их бизнесом, но для этого требуются “точки контакта” в виде аналогичных или близких процессов в компании, собирающейся аутсорсить IT. Если точек соприкосновения нет, то аутсорсер может “буксовать”, пытаясь управлять чужой средой, в результате бизнес так же будет страдать;
4. Риск, связанный с неспособностью удовлетворять потребности бизнеса, если компания изменит бизнес-стратегию, например, вдруг станет поставщиком IT услуг :);
5. Риск потерять важные знания о функционировании/поддержке IT сервисов, накопленные как знания в головах сотрудников, но не задокументированные для последующего использования кем-либо другим.

В случае с компанией уровня 2 ситуация может быть немножко лучше, если аутсорсер предпримет усилия по “подтаскиванию” компании до уровня 3.
Компания уровня 3 – идеальный случай для рассмотрения выгоды аутсорсинга. Если компания внедрила у себя ITIL, стандартизованные процессы выбора, внедрения и поддержки IT сервисов, обладает знанием в полном объеме о различных архитектурах (IT и бизнеса компании)  – то это позволит компании подготовить следующее:

1. Категоризацию IT сервисов, используемых бизнесом. Например, разнести сервисы по категориям “критичные для бизнеса”, “некритичные”, “вспомогательные”. Скажем, “критичные сервисы” – это такие сервисы, при проблемах с которыми компания не сможет вести бизнес, потеряет конкурентно-способность или понесет убытки;
2. Оценить вклад или важность каждого сервиса в прибыль компании – явно и косвенно;
3. Оценить с достаточной точностью стоимость предоставления сервисов  в пересчете на одного пользователя.

Имея на руках эти данные, можно с гораздо большей уверенности подойти, по крайней мере, к первому шагу итерации анализов возможности аутсорсинга. Можно будет “проиграть” различные сценарии: “что будет, если мы отдадим аутсорсеру вот это и это”.  Риски, упомянутые для компаний уровня 1 и 2 могут быть ликвидированы или последствия для бизнеса могуть быть “сглажены”.
Честно скажу: за все время своей трудовой деятельности я видел компании уровня 1 и 2, 3 – пока что еще не встречал. Может, это как “коммунизм” – идеальное состояние идеальной компании :) Например, ITIL позразумевает создание и поддержку в актуальном состоянии CMDB (если грубо, то CMDB – это база атрибутов о инфраструктуре, приложениях и других объектах, а так же описание связи между ними). Я этого “зверя” вообще не видел в “дикой природе” :) В одной из компаний, где я раньше работал, предпринималась попытка создания CMDB, но потом проект был тихо свернут из грандиозности задачи и стоимости внедрения.

По п.3: здесь неограниченное море возможностей :) Я думаю, в жизни любой компании наступает момент, когда она понимает, что КПД ее работы уменьшилось с течением времени. Здесь полезно будет провести “уборку в доме”:

1. Пересмотреть текущие проекты и заново оценить отдачу от них. Даже это простое действие позволит сэкономить огромные суммы, если, конечно, у начальства не будет “кишка тонка” остановить проекты, на которые или уже потрачены деньги, или эти проекты были разрекламированы бизнесу как нечто особенное, которое вмиг решит все проблемы. Я говорю из своего опыта о суммах с шестью нулями, потраченными на стороние решения, которые не могли быть внедрены из-за ряда недостатков или просто в них отсутствовала необходимость! Один раз по прямому указанию начальства были куплены лицензии на продукт, который никому был не нужен, но так как это было ц/у начальства, все старательно делали вид, что продукт используется (“висело” три сервера в виртуальных машинах с самым низким приоритетом :)). Самое обидное, что развитие системы, выполняющей те же функции, но не получившей одобрения “в верхах”, было приостановлено, несмотря на то, что она реально работала и использовалась. Это был еще косвенный убыток, который затормозил развитие данной функциональности на год. А потом уже это было неактульно. Или попытка внедрения продукта (identity management), который бы управлял службой каталогов, интегрировался с отделом кадров и делал бы все-все, разве что не танцевал. Три раза проект реанимировался и три раза умирал, потому что бизнесу обещали слишком много и просто не могли это внедрить в рамках бюджета и времени. Но каждый раз тратили сумму под миллион. Тупо. А в это время внутренняя система управления службой каталогов продолжала работать, выполняла свою цель, но ее разработку так же пришлось прекратить ибо “внедрим мы систему за мульйон и снизойдет на нас счастье”. У…лись!
   Еще одним примером такого подхода может служить требование для каждого проекта иметь определенный бюджет и внедрение проекта должно было происходить строго в рамках бюджета. Это была попытка бизнеса перевести IT типа на самоокупаемость, что ли… В результате тратились лишние деньги там, где это совершенно не надо было. Вместо лицензирования Windows Server для виртуализации на физический хост-сервер (Windows Server Datacenter Edition), каждый менеджер проектов предпочитал покупать стандартную серверную лицензию. Мало того, эта же история была с SQL. Все из-за того, что кто-то пожалел потратить n-ую сумму сразу, в результате ушло в несколько раз больше. И таких примеров я могу приводить бесконечное количество, к сожалению :(
2. “Перетрясти” штатное расписание, чтобы избавиться от “балласта”. В одной компании, где я работал, между мной, инженером, и бизнесом существовала раньше одна прослойка менеджеров проектов. Когда я уходил, цепочка состояла уже из трех человек. До директора компании было 2 уровня, когда уходил – даже не берусь сосчитать. Спрашивается: приносили ли эти все люди какую-то пользу? Наверное, приносили, но не соразмеримую с потерями на бюрократию, которые генерировали эти “раздутые” штаты;
3. Постараться снизить операционные расходы, повысив КПД работников. Например, аутсорсер может предложить дешевую рабочую силу, но очень часто это сопряжено с более низкой квалификацией работников. Внутренний отдел IT компании может продемонстрировать больщую отдачу в пересчете на сотрудника, внедрив решения, которые сводят на “нет” дешевизну рабочей силы аутсорсера. Например, внедрение системы управления персональными компьютерами вместе со виртуализацией приложений может существенно снизить операционные расходы на управление компьютерами. Или консолидация почтовых серверов. Или мигрирование физических серверов в виртуальную среду. Здесь, конечно, рассматривается идеальная ситуация. В реальной жизни бизнес может отказаться финансировать какой-то проект из-за достаточно больших первоначальных расходов, но это как раз и задача IT показать прямую и косвенную выгоду от внедрения подобных решений;
4. Постоянно демострировать улучшения пользовательской среды (user experience). Это человеческая природа – требовать постоянно чего-то нового. Пусть улучшения не будут глобальными, но тем не менее заметными пользователям. Это может быть обновление версий программ, или поддержка устройств, которые так нравятся бизнес-пользователям: всякие там телефоны или интернет планшеты. О том, насколько этот эффект недооценивается, я понял из своего опыта: никакие рассуждения о меньшей стоимости поддержки, лучшей доступности и т.п. для новой версии серверов Exchange не могли “пропихнуть” проект апгрейда с 2000 до 2007. Бизнесу было все “до одного места”. Но вот когда у начальства появились “я-телефоны” в количестве 10 штук, деньги магическим образом нашлись. Грустно, конечно, но такова жизнь;
5. И еще важный момент: уметь показать, какая доля расходов IT состоит из проектов, инициируемых бизнесом. Вполне может оказаться сюрпризом для бизнеса то, что расходы на работников и поддержание IT сервисов будут сравнимы с тратами на IT составляющую бизнес-проектов. В таком случае будет понятно, что нет пытаться смысла сократить расходы там, где их нет. Бизнесу тоже может потребоваться пройти через п. 1 и 2 :)
6. Еще один способ сократить расходы: использование стандартных или стандартизованных сервисов. Т.е. вместо предоставления пользователям сервисов в различными конфигурациями, предложить им на выбор два или три варианта, “повесить ценник” на них и тогда бизнес будет лучше понимать, сколько что стоит. Например: вместо предоставления удаленного доступа к приложениям через vpn и Citrix, можно просто оставить только Citrix. Меньше оборудования для поддержки, меньше лицензий – меньше затрат. Или вместо предоставления бизнес-пользователям лептопов HP, Dell, Sony, Apple и черт-знает кого, сделать так: на выбор два производителя – HP и Apple (я бы в корпоративной среде и даже бы Apple предлагал), из них по два варианта “железа”. Стоить поддержки всего этого пусть будет, например, 300 фунтов в год для HP/Win7 и 600 фунтов в год для Apple/MacOS X. Если хотите и Sony, и Dell, и NoName – пожалуйста, мы будет это делать, но это будет вам обходится 800 фунтов в год на лептоп. Расходы на это составляют: необходимость поддержки образов операционных систем для лептопов от разных производителей, обновление драйверов в этих образах, административная работа по контрактам поддержки с разными производителями и т.д. Когда сервис имеет ценовой эквивалент, бизнес это гораздо лучше понимает. Если не понимает, я всегда объяснял на примере электроэнергии. Электроэнергия дешевая, потому что параметры, с которыми она предоставляется потребителю, стандартные. Это 220 В, 50 Гц. Все! Если бы обычный бизнес выдвинул требования: хочу в этой комнате розетки 220 В, 50 Гц утром, но 1001.11 В, 300 Гц, 3000 А в обед и вечером 12 В, 10 Гц. А в другой комнате 999 В, 49 Гц все время. А в третьей… Можно было бы такое сделать? Можно! Но будет стоить такое электричество ну оооооочень дорого. Так и с IT сервисами – чем большего разнообразия хочет бизнес, тем дороже это будет обходится. Потом, если что, при “разборе полетов” типа “почему мы тратим на IT столько денег” можно будет указать, что IT “подстраивается” под требования бизнеса и если эти требования очень сложные, то и стоимость IT сервисов будет высокая.

Ну и наконец – п.4. Компании необходимо понимать, что аутсорсинг – это не только когда IT “прогибается” под бизнес, но и бизнесу может быть прийдется чем-то поступиться. Особенно это касается привычек управления проектами. В одной моей бывшей компании для менеджеров проектов было настоящим шоком то, что они уже не могли требовать от инженеров что-либо делать “на лету”, а им надо было проходить через формальную процедуру резервирования времени инженеров и “окно” для этого было две недели! Раньше инженеры были согласны и поработать во внеурочное время, лишь бы успешно закончить проект, то сейчас уже никто не “горит” на работе. “Утром деньги – вечером стулья” :)
В книге Талеба “Черный лебедь”, которую я уже упоминал в первой части, я встретил выражение, которое как нельзя лучше подходит к аутсорсингу: “К любому продукту применимо три атрибута: быстро, качественно и дешево. Но вы заказать продукт и выбрать можете только два из этих атрибутов”. Бизнесу прийдется смириться, что если компания хочет иметь дешевую IT, то это будет или “быстро”, или “качественно”. Но никак не все вместе. Так что тут аутсорсер и компания должны провести долгие часы вместе, обговаривая условия и ожидания друг от друга.

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

Ну вот и все, надеюсь вы дочитали до конца :) Засим раскланиваюсь,
Рустам.