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

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

Достаточно долго не писал в этот блог, в основном увлекался постами в персональный :) Да и не было ничего особенного, о чем хотелось бы написать. Так… “текучка” и рутина.
Но недавно мне пришлось провести четыре дня в процессе начального перехода от одного аутсорсера к нам. Аутсорсер, которого мы заменяем – очень уважаемая компания, её имя всем известно. Не буду его называть, но оно у всех на слуху. Так к чему это я: по идее, переход от одного поставщика  IT услуг к другому должен быть сравнительно безболезненным. Как в магазине: сегодня молоко вам привозил один поставщик, завтра – другой. Многие видят подобную гибкость как одну из причин, почему  IT сервисы должны быть за-аутсорсены. Но это в теории. На практике же выглядит всё по другому. Есть аутсорсеры, которые не стараются усложнить жизнь своему “коллеге” и переход происходит сравнительно безболезненно. В моем случае это было “слегка” не так: предыдущая IT компания заявила, что методы безопасности, применяемые к серверам клиента, являются интеллектуальной собственностью компании, поэтому нам не разрешается выполнить миграцию физических серверов в виртуальную среду. Никакие доводы о том, что клиент заплатил деньги за услуги и является собственником своих данных, приложений и платформы не возымели никакого действия! Отказ нам помогать со стороны предыдущего аутсорсера мотивирован очень тонко: они не отказываются предоставлять информацию, доступ к инфраструктуре и т.п., но легкой миграции не получится из-за какой-то эфемерной “интеллектуальной собственности”. Вряд ли компания, которую обслуживал этот аутсорсер, могла даже подумать о таком повороте событий.
Как вы думаете, кому не повезло в этом случае? :) Явно не предыдущему поставщику IT услуг – они свою прибыль уже получили. Даже не мы, новый аутсорсер: отказ в p-2-v миграции означает растягивание миграции по времени, более спокойный переход, клиент будет более лоялен к возможным проблемам после миграции и плюс это дополнительные деньги – коммерческое предложение делалось с учетом определенных условий. Если эти условия не соблюдаются – все необходимые действия по миграции оформляются как проект или набор проектов с соответствующими атрибутами в плане бюджета, ресурсов и т.п. Проигравшим может оказаться клиент, кто будет за это всё платить.
Вывод из этой истории очень простой: прежде чем “впускать” аутсорсера, подумайте, как вы будете его “выпускать” и заранее подстрахуйтесь на случай отказа аутсорсера выполнять какие-либо разумные требования.

Засим раскланиваюсь,
Рустам.

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

Недавно разговаривал со своими бывшими коллегами, которые в данный момент работают на аутсорсера (но не того, на которого работаю я). Они высказали интересное мнение, почему некоторые компании вполне довольны аутсорсингом, даже не смотря на упавшее качество IT услуг. Всё очень просто: деньги. Дешевле. По крайней мере, им так это кажется.
Очень часто аутсорсер не знает полностью сложность систем, которые он обслуживает. Пусть это верно в какой-то степени, но я готов поспорить, что невозможно знать всё абсолютно в уже существующей IT инфраструктуре, особенно если не вы её разворачивали. Что происходит: клиент просит оценить стоимость работы, которая выглядит достаточно просто, если не знать “подводных камней”. Аутсорсер предоставляет смету работ, скажем, 8 человеко-часов и клиент радостно её подписывает. Всё, после этого любая работа сверх этих заявленных 8-ми часов идет за счет аутсорсера! Даже если это займет месяц. Т.е. экономия для клиента происходит за счет того, что аутсорсер вынужден за свой счет проводить кое-какие работы.
С другой стороны, аутсорсер обладает огромной возможностью “надуть” клиента: выставить “раздутый” счет за какую-либо работу. Если клиент “глупый” и полностью избавился от IT персонала, возможности у него оспорить этот счет будет очень мало. Так и случилось: сравнительно простая работа обошлась клиенту в миллионы фунтов.
Наверное, в этом случае каждый остался “при своих” :) Мне кажется, в случае аутсорсинга будет вечная борьба противоположностей: клиент/бизнес будет стараться заплатить меньше, скрывая накопленные знания о существующих проблемах и пытаясь переложить их решение на аутсорсера; аутсорсер, в свою очередь, будет стараться любой проект “раздуть до размеров слона”, чтобы получить “нескромные” деньги. А страдать будут бизнес-пользователи и качество :(

Засим раскланиваюсь,
Рустам.

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

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

• IT сервисы;
• Наличие подготовленного персонала (“гарантированно” и “по требованию”);
• Расходы на IT сервисы и персонал;
• Стратегия, связанная аутсорсинга.

В IT сервисах главным преимуществом является то, что аутсорсер, при правильном подходе к аутсорсингу со стороны бизнеса, может улучшить существующие сервисы. Как я уже писал, это может произойти при обоюдном желании: бизнеса – предоставить бюджет, а аутсорсера – инвестировать ресурсы и понести какие-то еще незначительные косвенные затраты.
Аутсорсер так же может помочь с внедрением новых сервисов, которые были бы недоступны без помощи аутсорсера. Аутсорсер может предоставить персонал (инженеров, менеджеров проектов и т.п.), обладающих необходимыми знаниями и умениями для внедрения сложного решения, а потом оказывать поддержку этой системы.Бизнес мог бы, конечно, воспользоваться консультатнами для внедрения, но вопрос поддержки все-равно бы потом “всплыл”.
Персонал: огромным “плюсом” любого крупного аутсорсера является наличие пула ресурсов. Это важно как и для краткосрочных, так и для долгосрочных проектов. Как я уже упомянул выше, бизнес может воспользоваться консультантами для внедрения какого-либо решения или системы. Но консультанты бизнесу будут обходиться раза в два дороже, чем дополнительный персонал аутсорсера, временно нанятый на срок выполнения проекта. А потом, как дополнительная “плюшка”, аутсорсер может дешевле взяться поддерживать систему, так как она была внедрена силами самого аутсорсера. Единственным “минусом” может являться то, что бизнесу для затребования необходимых ресурсов надо будет следовать формальным процессам, чтобы затребовать этот самый персонал аутсорсера, но я думаю, что на это уйдет или столько же времени, как на поиск консультантов, или даже меньше.
Расходы на IT сервисы и персонал: в случае с IT сервисами все просто. Основными преимуществами являются: возможность получения оговоренных IT сервисов за заранее оговоренную цену (финансовый отдел бизнеса будет пищать от восторга!) и понижение стоимости IT сервисов за счет разделяемых сервисов/ресурсов. Как это выглядит на практике, к примеру: аутсорсер может иметь систему мониторинга, за которую он выплатил N-ую сумму производителю этой системы и теперь имеет неограниченное количество клиентских лицензий. Или, как крупный клиент, имеет существенную скидку на клиентские лицензии. Используя эту систему мониторинга на своей инфраструктуре для разных своих клиентов, аутсорсер понижает издержки для себя и, если это не жадный аутсорсер, передает экономию в расходах своим клиентам. Т.е. бизнесы платят меньше, чем платили бы они, если бы сами покупали лицензии и внедряли решения на своей платформе.
С персоналом картина получается еще радужнее. Одна из самых больших статей расходов в развитой капиталистической стране является выплаты работникам (зарплата, больничные, отпускные и т.д.). Бизнес может экономить за счет использования аутсорсером более дешевой рабочей силы. Кроме того, в завимости от контракта, бизнес всегда может иметь гарантированное количество персонала аутсорсера, работающего на него. Т.е. отпуска, больничные и недостаток персонала бизнес волновать не будет. Сказано в контракте – два инженера 24х7, пусть аутсорсер  думает, где и как ему найти нужное количество инженеров :)
В случае аутосринга, бизнесу нет необходимости оплачивать обучение и курсы сотрудников. Это, опять же, задача аутсорсера - предоставлять бизнесу ресурсы с готовыми знаниями :)
Так же бизнес может существенно сэкономить за счет того, что сотрудникам аутсорсера не надо предоставлять дополнительные “бенефиты”: доплачивать в пенсионный фонд, оплачивать больничный и отпускные, премии и т.д. В случае кризиса и последующих увольнений бизнес не связан никакими обязательствами перед работниками аутсорсера: никаких выплат по сокращению, пособий и т.д.
Вот, наверное, и все. Данные “измышления” базируются на моем опыте. Кто-то может дополнит, если я много чего пропустил.

Засим раскланиваюсь,
Рустам.

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

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

1. Различие/отсутствие бизнес-процессов, управление и культура:
   • Разное понимание целей между компанией, аутсорсящей IT и самим аутсорсером – если компания, отдав аутсорсеру IT, “выторговав” себе крайне дешевый контракт поддержки, ожидает, что аутсорсер вдруг ринеться внедрять новые сервисы, производить апгрейд операционных систем настольных компьютеров и серверов, то эта компания очень ошибается :) Аутсорсер будет стараться сэкономить на поддержке как только можно, вполне и за счет качества. Поэтому сразу же на самом первом этапе обе стороны должн договориться, что ожидается получить в результате. Даже если это будет просто констатация намерений, но ясность в целях позволит обозначить “горизонты”, пусть это и повлияет на цену контракта в сторону удорожания. Зато все будут избавлены от появления неприятных сюрпризов в виде взаимных претензий;
   • Неготовность компании следовать формализованным процессам/отсутствие процессов в отношениях с аутсорсером – как я уже писал, аутсорсер не может интегрироваться в бизнес и в организационную структуру компании. Для эффективного взаимодействия с аутсорсером, компания должна “построить” связующие бизнес-процессы. Это приводит к интересному моменту: когда аутсорсится IT, компания может ожидать, что она подчистую избавится от внутреннего IT. Как бы не так! От технических специалистов она, может, и избавится, но взамен над будет создать организационную единицу, которая будет взаимодействовать с аутсорсером: контролировать выполнение, качество и т.д. Может возникнуть парадоксальная ситуация, когда маленький IT отдел будет заменен штатом более высокооплачиваемых сотрудников для работы с аутсорсером, что в конечном счете приведет к более высоким затратам на этих людей в плане зарплаты :);
   • Проблемы взаимодействия/управления аутсорсером:
     • Контроль качества – когда IT предоставляется внутренней службой/департаментом, гораздо легче получить правдивую картину о качестве IT. Если IT за-аутсорсено, очень тяжело понять, насколько предоставляемые IT сервисы соотвествуют требованиям качества;
     • Остутствие опыта управления распределенной средой – ресурсы, распределенные географически и в разных временных зонах. Вроде бы простая вещь, но для некоторых компаний может стать “камнем преткновения”: бизнесу, привыкшему к “карманному” IT, трудно перестроиться на взаимодействие с IT, которое расположено не на “расстоянии вытянутой руки”. Если раньше любые совещания, вопросы решались просто, можно было просто послать приглашение на совещание и собраться в какой-нибудь комнате, то организовать то же самое, но с людьми, которые находятся, скорее всего, на другом континенте и в другом часовом поясе, будет нелегко. Конечно, аутсорсер организовывает поддержку бизнеса, “выравниваясь” по рабочим часам компании, но это не означает, что все работники аутсорсера будут работать так. Скорее всего первая-вторая линия поддержки будут доступны все время, а вот с другими сотрудниками прийдется согласовывать время. Когда мой предыдущий работодатель организовал совместный бизнес с американцами и нам нужно было что-либо согласовать с техническими специалистами в Штатах, мы назначали совещание на 4-6 вечера, а у них это было раннее утро. Мы жертвовали своим свободным временем (я тогда работал до 16:00), а американцы часто выходили на связь прямо из дома – проснулись, почистили зубы и вперед – конференц-связь.
   • Различная культура общения. Сейчас ситуация улучшается за счет большего присутствия работников аутсорсинговых фирм в офисах компаний, пользующихся их услугами, но раньше это создавало много проблем и недопониманий. Например, индусы никогда не говорили “нет”. Можно было составить подробный план со списком задач, которые они должны были бы выполнить. Даже если работники в  Индии понимали, что столько им не сделать, они все-равно говорили “ОК”. Естественно, когда все задачи не выполнялись, бизнес начинал требовать объяснений, а индусские аутсорсеры недоумевали, что это от них хотят, ведь это сразу было понятно, что они этого не сделают!? :) Именно поэтому нормальные аутсорсеры, которые должны взаимодействовать с бизнесом, стараются увеличить свое “присутствие” у клиентов, нанимая сотрудников со знанием культуры в данной стране. Пусть даже и иммигрантов с других стран ;))
2. Уровень услуг:
   • Недостаточно высокое качество предоставляемых IT сервисов:
     • Персонал аутсорсера с низким уровнем знания и опыта. IT индустрия в странах, предоставляющих аутсорсинг, сейчас переживает бум. Как некоторое время назад в развитых странах, в IT сейчас идут кому не лень. Минимальные знания вдруг дают право людям называться инженерами. Имейте в виду, что контролировать кто там сидит на другом конце земного шара и нажимает на кнопки крайне тяжело (см выше);
     • Персонал аутсорсера может быть подвержен процессу текучки. Люди приходят, ходят и, как следствие, постепенно теряются накопленные знания. По большому счету, это проблемы атусорсера, но будет обидно, если проблемы аутсорсера рикошетом ударят по бизнесу;
     • Отсутствие стимулов и причин к повышению качества. Этот пункт немножко спорный, но, тем не менее, есть вполне оправданные подозрения, что это так. Чаще всего атсорсинг рассматривается как возможность сэкономить деньги. Т.е. получить все задешево. Но иногда для того, чтобы получить экономию, надо будет вложить достаточно большие деньги. Аутсорсер понимает, что после окончания контракта есть шанс проститься с клиентом, поэтому не хочет вкладывать свои деньги или ресурсы в глобальные проекты. А бизнесу будет трудно смириться с тем, что вместо экономии в IT они могут получить еще одни расходы. Аутсорсер будет внедрять без поддержки бизнеса только то, что не потребует больших вложений (прямо – деньгами, или косвенно – временем работников) и даст результат сиюминутно. У постоянно же IT персонала может быть дополнительная мотивация, чтобы “инвестировать” хотя бы свои усилия в то, чтобы улучшить IT.
3. Цена:
   • Оплата услуг, невошедших в первоначальный контракт, может сильно отличаться от цены на остальные сервисы. Как правило, компании, за-аутсорсившие IT, после подписания контракта и передачи IT аутсорсеру теряют главные рычаги воздействия на аутсорсера. Как я уже говорил, очень трудно описать всё в контракте и после некоторого времени бизнес может попасть в “мышеловку”, когда внутренний IT выполнял массу задач, не обговоренных в контракте, и потом обнаруживается, что это крайне важно. Аутсорсер в зависимости от жадности и условий контракта может запросить вполне нескромную цену :) Одна из компаний попалась на эту удочку: она сначала “прижала” аутсорсера контрактом, заставила сделать пару проектов задаром. А потом оказалось, что любой “чих” обходится в большие деньги. Все, что не попадало под контракт, оценивалось в десятки тысяч фунтов. Попытки бизнеса сделать что-то по мелочи самими выливалось в отказ аутсорсером поддерживать эти системы. Представьте себе, когда вам надо перенести пару компьютеров с одного офиса в другой. Аутсорсер выставляет такую цену, что бизнес решает силами своих сотрудников перетащить эти компьютеры и подключить кабеля. После этого аутсорсер заявляет, что эти комьпютеры он не будет поддерживать, так как изменения были внесены не квалифицированными сотрудниками :) Бизнес вынужден был заплатить аутсорсеру за “сертификацию” этих компьютеров “квалифицированными сотрудниками”, после чего аутсорсер “добил” бизнес заявлением о тем, что эти компьютеры уже не попадают под действие предыдущего контракта и на них надо заключать новый (более дорогой, естественно!) :)))
4. Стратегия:
   • Аутсорсер может не стремиться внедрять сервисы, которые в долгосрочной перспективе принесут экономию компании (бизнесу). На это могут быть разные причины: нежелание инвестировать свои ресурсы, нехватка ресурсов или просто тупое желание продолжать “рубить капусту”;
   • В зависимости от отношений аутсорсера и бизнеса, может возникнуть такая ситуация, когда стратегические проекты будет почти невозможно не то что провести, а даже начать! Причиной может быть недоверие между бизнесом и аутсорсером, культура бизнеса и т.д. Очень часто бывает, что люди из внутреннего IT уходят в новую структуру, которая занимается координацией проектов между бизнесом и аутсорсером. Как вы думаете, насколько беспристрастно эти люди могут работать с аутсорсером? Скорее всего, эти работники будут явно или неявно стараться насаждать свои идеи, как что-то должно быть сделано. Такова человеческая природа. Трудно перестроиться и признаться, что теперь ты не технический специалист, а просто еще один бизнес-аналитик. К слову: в этом нет ничего плохого и даже открываются неплохие перспективы в плане каръеры. Бизнесу будут важны люди, которые знают две стороны: бизнес и IT. Аутсорсеры будут меняться, а эти люди в бизнесе – нет;
   • Аутсорсер может упустить что-либо из-за непонимания бизнеса компании и возможной выгоды для бизнеса.
5. Персонал и отношение к работе:
   • Сотрудники аутсорера не будут лояльны к бизнесу. Только товарно-денежные отношения. Хотя, наверное, термин “лояльность” не применим к персоналу, предоставляемым аутсорсером. Какой-то определенной благодарности можно добиться :) Например, практикуется приглашение персонала аутсорсера на регулярные “дринки”, оплачиваемые, естественно, бизнесом;
   • Самой главной проблемой является невозможность получать ресурсы (т.е. инженеров) “на лету”. Я говорю о том случае, когда бизнесу надо “кровь из носа” что-то сделать еще вчера, а у аутсорсера может и не быть свободных инженеров. Могут иметься в наличие инженеры, но без знания конкретного бизнеса и IT, что не позволит выполнить необходимые задачи в срок. Бизнесу надо будет перестроиться и учиться планировать потребность в ресурсах. Обычное “окно” для затребования “ресурсов” – две недели. Причина проста: как я уже говорил, аутсорсер стремится снижать свои расходы и одним из методов является “размазывание” персонала по нескольким клиентам. Т.е. вроде бы есть прикрепленный к бизнесу инженер, но для какого-либо проекта он будет доступен только после оговоренной даты.
6. Ну, и самое вкусное: риск/проблема “выхода” из контракта с текущим аутсорсером:
   • После окончания контракта аутсорсер может отказаться/пассивно сопротивляться предоставлять необходимую информацию. Даже просто у аутсорсера может не оказаться необходимых ресурсов для гладкой передачи IT сервисов и инфраструктуры другому аутсорсеру или внутреннему отделу IT. Контракт заканчивается, зачем держать лишних инженеров, кроме самого минимума, необходимого для поддержания работы систем. Момент выхода (окончания контракта) должен быть очень четко оговорен в контракте, чтобы у аутсорсера не было другого пути, кроме как передать необходимые накопленные знания в приемлемом виде;
7. Сам бизнес по окончанию срока контракта с аутсорсером может не представлять, какую информацию затребовать. Что важно, а что нет. Может сложиться такая ситуация, когда документации много, а насколько она актуальна, насколько полно она описывает имеющуюся IT – непонятно. Тут уж самому бизнесу надо будет проявить себя с лучшей стороны. Как я уже писал, компании 3-го типа будет легко связать существующие 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 пункта в начале не должны служить автоматическим триггером для начала аутсорсинга, а всего-лишь началом долгого и вдумчивого процесса рассмотрения возможности аутсорсинга, потому что в случае неудачи будет очень трудно вернуть все обратно.

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

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

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

1. Желание сократить операционные расходы на ИТ – это деньги, которые тратяться на зарплату работников, амортизационные отчисления на оборудование, счета за электричество и т.д.;
2. Идея использовать аутсорсинговую компанию для для внедрения проектов, для которых организация не имеет опыта/ресурсов – это, конечно, ближе к использованию консалтинговой фирмы, но я и такое видел;
3. Попытка достичь лучшего соотношения между затратами на ИТ и получаемой выгоды (ROI) – как говорится: “иметь больше за меньшие деньги”. Т.е. получить от IT более высокий КПД;
4. Мода. Тут и говорить нечего.

В целом, кроме п.4 причины выглядят более чем обоснованными. Кто же не захочет сэкономить кучу денег на такой расходной службе, как IT? Но, как мне кажется, очень часто попытки обосновать возможные “прелести” аутсорсинга не учитывают некоторые фундаментальные вещи – об это ниже. 

По п.1:

Очень много действий, осуществляемых внутренней IT, остаются незамеченными. В этом случае начинают “плавать” все показатели КПД работников (KPI), в результате начинает казаться, что на внутреннюю IT денег тратится очень много, а результат вроде бы и как и незначительный. Потом при составлении контракта с аутсорсинговой компанией указывается список задач для выполнения, аутсорсинговая компания указывает свою цену и если все устраивает, договор подписывается. Если “неожиданно” обнаруживается, что требуется еще пачка действий для поддержания систем в работе, это будет уже дополнением к контракту, за дополнительные деньги и вполне возможно – с большой наценкой. Все зависит от того, как быстро это обнаружится. Но денег точно прийдеться платить больше. Этот риск не такой уж маленький, как кажется: дело в том, что решение об аутсорсинге принимается “ввреху”. По разным причинам информацию о том, что IT планируется аутсорсить, начальство захочет сохранить в тайне.  А достоверной информацией о списке задач для ежедневной поддержки начальство может не располагать, а если затребует – то IT в силу непонимания… или еще хуже, понимания, может выдать на “гора” неполный/неверный список выполняемых задач. Типа: “На те, отвяжитесь”.
Крайне тяжело перевести в денежные единицы действийя IT в плане важности операций по поддержке систем. Человек может каждый день с утра проверять логи серверов, проверять метрики производительности серверов и т.д. Причем он не просто “смотрит в книгу видит фигу”, он способен предвидеть (если он хороший работник) потенциальные проблемы: отклонение от графика загрузки процессора в это время, непонятные ошибки в логах и т.п. Так как он обладает знаниями инфраструктуры, бизнеса и того, как стандартная технология нестандартно реализована в данной компании, “внутренний” работник IT может предупредить серъезные проблемы до того, как они наступят. Т.е. ничего вроде бы не случается, но и нет видимости тех инциндентов, которые не наступили именно благодаря таким сотрудникам. Я как раз читаю книгу Нассим Талеба “Черный лебедь” по рекомендации Юры К. и Жени Я., там автор тоже подчеркивает, что мы не можем понять значимость событий, которые не наступили, но которые если бы они наступили, повлекли бы или огромные убытки, или потерю человеческих жизней. Талеб как пример приводит гипотетическию ситуацию, в которой какой-то сотрудник авиакомпании предусмотрел усиленные двери между кабиной экипажа авиалайнера и пассажирским салоном, в результате бы не наступило 11 сентября. Как можно было бы оценить важность решения оградить экипаж от легкого доступа со стороны салона, если бы мы никога не узнали бы об 11 сентября!? Так и действия работников, последствием которых будет отсутствие глобальных проблем, не получат качественной оценки. Этакий “… по гром не грянет” в IT :) Я свое время в одной крупной компании я постоянно говорил об необходимости системы управления компьютерами уровня предприятия для инвентаризацаи, установки приложений, а самое главное – установки хот-фиксов к одной популярной операционной системе. Стоить это должно было достаточно много и естественно, никто не хотел выделять деньги. Бизнес говорил, что вполне может пережить день простоя главного офиса. И вот, в один прекрасный день… три дня и две ночи, не уходя с работы, инженера “закатывали солнце вручную”. Это нам еще повезло, что  только около 2%-3% компьютеров оказались “завирусованными”. После “разбора полетов” бизнес понял, что они не смогли правильно оценить ежедневные бизнес-процессы, выполняемые работниками головного офиса и следовательно, правильно оценить риски. Нужно ли говорить, что деньги на продукт управление десктопами нашлись очень быстро. Так и с оценкой эффективности затрат на IT: очень велика вероятность что-либо проглядеть, а потом горько об этом жалеть;

По п.2:

Здесь, как и с консалтингом, есть риск получить в конце концов не то что хочешь. Я столкнулся с тем, что многие вещи недопонимаются из-за использования вроде бы одних и тех же терминов, но подразумеваются разные вещи! Это целое искусство: описывать задачи, обязанности и т.д. в терминах и определениях, которые не допускают двоякового толкования. Например, был случай, когда должна была внедриться система продаж страховых полисов и одним из требований было наличие репликации данных между распределенными офисами. “Домашняя” система, использующая сервера баз данных, это делала по расписанию в автоматическом режиме. Новый продукт одной крупной фирмы использовал устаревшую технологию и репликацию подобным образом реализовать было нельзя. Консультанты написали “приблуду”, которую надо было запускать вручную и требовалось, чтобы программа никем не использовалась на момент работы этой утилиты. Надо ли говорить, что такую систему в реальной жизни использовать было нельзя. Но консультанты были твердо уверены, что они сделали все, как в тех договоре: репликация реализована согласно тех. заданию. Никто же не прописал: репликация в реальном времени, без выхода из программы, с разрешением конфликтов и т.п.! Когда в тех. задание вносилось требование о репликации, имелось в виду по умолчанию “как сейчас”, а консультанты поняли это “как получиться” :). Если контракт с аутсорсером “привязывается” к выполнению проекта, то надо быть очень осторожным: оговорить цели и сроки окончания внедрения, критерии успеха и штрафы в случае невыполнения. Как мне кажется, составить такой  контракт – целое искусство! :) Для этого требуется очень сильная команда менеджеров и главных IT архитекторов.

О п.3:

ROI можно улучшить, получив более высокую отдачу или понизив затраты. С отдачей, так же как и в п.1.2, все не так-то проосто: очень сложно оценить выгоду от внедренных проектов. Особенно если в расчеты вкрадывается такая “тонкая” вещь, как “удовлетворение пользователей” (customer satisfaction). Т.е. переход с Windows Vista на Windows 7 сложно обосновать чем-либо, кроме как бОльшим удовлетворением пользователей. Vista и Windows 7 до сих пор поддерживаются MS (переход с Windows XP на Windows 7 можно “железно” обосновать требованиями безопастности), интерфейсы похожи и т.п. Можно сказать: “Windows 7 работает быстрее”. Но как это измерить? Как это перевести в денежные единицы, столь радующие менеджеров? На моей памяти очень редко получалось расчитать явно выраженную финансовую выгоду от внедрения какого-либо продукта. Переход с MS Office 2000 на 2010 не только не принесет прямой выгоды, а наоборот, будет сплошными расходами, и ROI перевести в “плюс” можно только используя неявную выгоду или пользу.
Понизить затраты можно путем или привлечения более дешевых ресурсов (дешевые инженеры из других стран) или использования ресурсов в совместном доступе. Например, виртуальная среда аутсорсера, которая используется и другими клиентами аутсорсера, в результате чего виртуальные машины обходяться дешевле и т.п. Или мониторинговая система, серверная часть которая настроена аутсорсером, а клиентская часть установлена на серверах/компьютеров организаций, покупающих услугу мониторинга. В принципе, это частный случай снижения операционных издержек (п.1).
Главный вопрос – подходит ли такая схема бизнесу. С использованием разделяемых ресурсов может встать вопрос об недостаточном качестве работ (при мониторинге надо не только смотреть на логи, но и понимать влияние систем, которые мониторятся, на бизнес и быстро и правильно реагировать), или неудовлетворительной скорости исполнения и т.д. Из моего опыта: я когда-то занимался “упаковыванием” приложений в msi формат для последующей автоматической установки пользователям. Мой личный рекорд – 2 часа. Это включало в себя обсуждение с бизнесом как приложение должно быть установлено (какие опции и компоненты выбрать), “упаковки” (InstallShield AdminStudio), тестирования и произведения необходимых действий для того, чтобы приложение было доступно пользователям. Как мне стало недавно известно, попытка в той компании (я уже там не работаю) аутсорсером перенести эту функцию за океан привело к тому, что теперь для этого требуется две недели как минимум и резко упало качество: требуется больше попыток и тестирования для получения необходимого результата. Т.е. вроде бы в абсолютных цифрах это дешевле, но никто же не учитывает время, которое тратят бизнес-пользователи на ожидание приложения, его тестирования, написания отчетов об ошибках и т.д.

п.4:

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

В заключение этой части хочу сказать: компаниям надо быть сверх аккуратными в оценке своих затрат на IT. В идеале надо потратить на это кучу времени, чтобы получить какую-то цифру. Еще больше времени надо для того, чтобы оценить выгоду, приносимую внутренней IT. Даже если эта выгода в конце-концов обозначена какой-то денежной единицей, я бы смело умножал бы ее на два! Это значение и стоит использовать для того, чтобы рассматривать, выгодно ли аутсорсить свое IT. Аутсорсер не заинтересован в снижении расходов клиентов! Главная задача аутсорсера – зарабатывать на клиентах деньги! Даже если сначала все будет выглядеть как снижение стоимости, то через некоторое время финансовый департамент может с удивлением обнаружить, что затраты на IT резко пошли вверх!
В следующем посте я постараюсь рассказать, о чем, по моему мнению, необходимо подумать прежде всего, прежде чем окончательно решить аутсорсить IT.

Засим раскланиваюсь,
Рустам.