Тематика четвертого ежегодного саммита “Аутсорсинг: стратегия эффективного управления и производства”, прошедшего в начале июня под эгидой infor-media Russia, была столь широка, что вопросам ИТ-аутсорсинга на ней было уделено далеко не главное внимание. Тем не менее, как показало обсуждение, многие проблемы аутсорсинга имеют общий характер, а способы их решения в нашей стране в основном носят эмпирический характер и не подкреплены действующей нормативной базой. С другой стороны, некая видимость благополучия возникает в том случае, если в круг обсуждения включать и так называемый производственный аутсорсинг. Под ним понимают как передачу внешнему исполнителю выполнения отдельных технологических процессов, так и рутинную закупку комплектующих и материалов у внешнего поставщика. Иными словами, при этом подходе лидерами в применении аутсорсинга окажутся, скажем, отечественные сборщики ПК: ведь они отдают изготовление всех узлов внешним производителям. Справедливости ради отметим, что вопросы производственного аутсорсинга на данной конференции практически не обсуждались, а основное внимание было приковано к передаче внешнему провайдеру тех или иных сервисных функций.

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

О том, насколько запутанными могут быть отношения клиента и аутсорсера, свидетельствует рассказ генерального директора компании “Капитал Страхование жизни” Олега Меркулова. Офис его организации был обворован, но претензии к службе охраны (по сути к аутсорсеру) были отвергнуты на том основании, что оборудование злоумышленники вынесли не через входные двери, а через крышу. Можно предположить, что проблемы не было бы, учти заказчик в договоре также и охрану выхода на крышу. Однако поскольку страховая компания заключала лишь общий договор с владельцем офисного центра, в данном случае имел место вмененный аутсорсинг, условия которого арендаторами не подписывались и не были им известны.

И даже в тех случаях, когда имеется некая нормативная база, о реальном правоприменении участники форума высказывались крайне осторожно, ссылаясь на несовершенство российской судебной системы. Не удивительно поэтому, что практически все докладчики отмечали необходимость тесных доверительных отношений между заказчиком и провайдером услуг. Без них попросту будет невозможно “совместное ведение хозяйства” на протяжении нескольких лет — лишь столь длительные аутсорсинговые контракты имеют смысл. Вопрос о том, как выстроить подобные отношения, сложен и вряд ли имеет однозначный ответ. Гораздо проще очертить некие зоны риска, попадание в которые крайне нежелательно.

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

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

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