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

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

Я долго терпел, но решил поделиться с вами своими мыслями по поводу аутсорсинга. С одной стороны, мне ругать аутсорсинг “не с руки” – это нас в данным момент “кормит”, с другой стороны – я побывал и с обратной стороны баррикады, когда компания, на которую я работал, стала аутсорсить различные функции внутреннего 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.

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