Часто приходится слышать, что западные компании привыкли передавать свои ИТ-системы на внешнее управление, и так же они стремятся делать и в своих представительствах в России. Случай с финским фармацевтическим дистрибьютором и ритейлером «Oriola-KD» является, однако, не вполне типичным, так как большая часть систем ему досталась от поглощенных российских предприятий. Наш разговор с исполняющим обязанности директора ИТ-департамента компании «Oriola-KD Россия» Дмитрием Рудько был посвящен переводу информационных систем внешнему оператору и первым итогам этого проекта.
Intelligent Enterprise: Решение о переходе на аутсорсинг принимали вы или это требование финской стороны? Как долго вызревал данный проект?
Дмитрий Рудько: Да, у нашей головной компании есть определенная корпоративная политика. И она настоятельно рекомендует все непрофильные функции выносить на аутсорсинг. В том числе это касается и обслуживания информационных систем и ИТ-инфраструктуры. С другой стороны, обслуживание всего этого хозяйства было наболевшей проблемой. С обеспечением отказоустойчивой работы всех систем и приложений поддержки бизнес-процессов возникало немало сложностей. Так что и без внешнего влияния мы тоже двигались в сторону аутсорсинга. Хотя сама форма аутсорсинга целиком позаимствована у финской стороны: как и они, мы передали на внешнее управление все ИТ.
Останавливаться на таких более популярных у нас услугах, как collocation (размещение своего оборудования в коммерческом ЦОДе), мы не стали.
В целом от принятия решения до выбора поставщика и подписания с ним контракта прошел год, даже немного больше: порядка 14–15 месяцев. При этом параллельно готовилась тендерная документация и проходила первая фаза выбора поставщика услуг.
Как выбирали оператора? И почему в итоге сделан именно этот выбор?
Всё проходило по классической схеме. В тендере участвовало пять компаний – четыре российские и одна зарубежная, рекомендованная финской стороной. Все они предложили весьма похожие условия. Тендер проходил в два тура, как это и бывает обычно. Сначала длинный список, затем выбор сужается до короткого, и наконец принимается окончательное решение.
При этом изначально мы не смотрели в сторону ЦОДов, которые имеют наиболее высокие показатели по отказоустойчивости и имеют сертификаты TIER III. Их услуги обходятся существенно дороже, в то время как выигрыш для нас не очевиден. Нам вполне достаточно было того уровня, который способен обеспечить ЦОД класса TIER II.
В итоге главным при выборе поставщика было соотношение цены и качества сервиса по обслуживанию наших бизнес-приложений. И мы остановились на той компании, которая обещала более высокий уровень сервиса. Именно поэтому победителем тендера и были признаны «Инфосистемы Джет».
Важной частью контрактной документации стало соглашение об уровне сервиса (SLA) для каждого из бизнес-приложений, несоблюдение которого влечет ощутимую материальную ответственность. Важно отметить, что контрактная база, составленная именно таким образом, не в контексте серверов, а в контексте бизнес-приложений, является вполне прозрачной для бизнеса: он понимает, какое отклонение от заданных параметров функционирования ПО влечет за собой санкции.
Относительно выработки соглашений об уровне сервиса могу сказать, что число девяток в показателях надежности нужно очень тщательно взвешивать и четко понимать, на какой величине следует остановиться. Тем более, что зависимость между этим числом и стоимостью не линейна, и каждая новая девятка существенно удорожает услуги. Хотя донести это до бизнеса, может быть, и не просто. Но нам это удалось.
Как проходили сами работы по проекту? Были ли здесь какие-либо сложности? Как они решались?
Самым сложным этапом был перенос данных в ЦОД оператора. Выработка SLA – это одно, а конкретное погружение в системы – уже совсем другое.
Перенос данных проходил последовательно. Мы поэтапно освобождали своё оборудование, а системы, которые на нём работали, переносились в ЦОД компании «Инфосистемы Джет». Всего таких итераций в ходе данного процесса было пять.
Очень сильно осложняло ситуацию то, что у нас самый настоящий техно-зоопарк из систем и приложений. Всего их около двух десятков, и как некоторые из них работают, наш персонал часто даже толком и не знал. Так что в нашей ИТ-архитектуре было немало самых настоящих белых пятен. Когда системы плохо задокументированы или не документированы вообще, обязательно возникают такого рода сложности.
А у нас очень много самописных систем, а в таких случаях с документацией дела всегда обстоят не слишком хорошо. В итоге действовать часто приходилось буквально как на минном поле. Ну, по крайней мере подходить к процессу переноса некоторых приложений и данных с очень большой аккуратностью и тщательностью.
Была сформирована проектная группа, куда вошли представители головной Oriola-KD, «Oriola-KD России» и «Инфосистем Джет». Эта трехсторонняя группа регулярно собиралась и обсуждала всякого рода проблемы. А их и помимо проблем с миграцией было немало. Так, например, масса сложностей была со своевременными поставками оборудования, с его монтажом и пусконаладочными работами. При этом надо учесть, что в течение года, что прошел от старта работ по проекту до его финальной стадии, компания росла и развивалась. Равно как увеличивались и объемы данных, с которыми пришлось иметь дело. Да и ландшафт систем претерпел некоторые изменения за это время: появилось несколько сервисов, довольно важных для бизнеса, которых раньше не было.
Занял процесс переноса данных около полугода. Так что в общей сложности работы по проекту шли почти два года.
Каким образом удалось решить задачу сохранения производительности?
На этапе миграции мы использовали гигабитный канал между нашей серверной и ЦОДом «Инфосистем Джет». Мы не привозили оборудование физически. Для ускорения процесса все работы проводили в выходные дни. Естественно, соответствующий сервис был недоступен. По завершении переноса данных сервис вновь публиковался. А для повышения производительности приобретали новое оборудование, обеспечивающее большее быстродействие систем. В итоге при переносе систем на внешнюю площадку мы получали прирост производительности. Хотя с некоторыми сервисами бывали проблемы из-за некорректного документирования и явных ошибок, допущенных на стадии разработки. Так что приходилось решать задачи, связанные с рефакторингом архитектуры ряда приложений.
На что стоит рассчитывать при переходе на аутсорсинг?
Часто говорят, что переход на аутсорсинг позволяет добиться снижения затрат. Это не совсем так. Например, наш опыт показывает, что процесс миграции связан с довольно значительными расходами, многие из которых далеко не очевидны при старте проекта. Кроме того, переход на аутсорсинг означает, что какой-то части персонала придётся покинуть компанию. С одной стороны, это хорошо. Но с другой, пока проект не закончен, они и их работа все равно нужны и важны. И мотивация линейного персонала в таких условиях – дело довольно сложное.
Но при этом аутсорсинг привнес стабильность в работу информационных систем. На момент старта работ по нашему проекту, три года назад, простои были регулярными. Они достигали четырёх часов в неделю, а то и больше. Естественно, все это вело к невозможности поддержки бизнес-процессов, а значит, к потерям заказов, что отражалось на выручке и прочих показателях. Сейчас все это осталось далеко в прошлом благодаря использованию правильного оборудования и работе квалифицированных специалистов. Преимущества налицо.
Прямую выгоду дает и сокращение численности ИТ-персонала. Сейчас много говорят о том, что этот сегмент рынка труда перегрет, и задача найти и удержать специалистов становится все более сложной и затратной.
А у нас в них сейчас нет необходимости. Все задачи по обслуживанию СУБД, причем разных – Oracle и Microsoft SQL Server – и ПО, которое работает поверх них, выполняют сотрудники оператора. Не говоря уже о таких дефицитных специалистах, как инженеры по обслуживанию инфраструктуры ЦОДа: систем бесперебойного электропитания, прецизионного климат-контроля и других. Раньше для нас поддержка таких систем была большой головной болью. Да и серверные платформы и системы хранения данных, которые мы используем, требуют квалифицированного персонала для обслуживания. Да еще и с запасом, поскольку люди есть люди: кто-то ушел в отпуск, кто-то заболел… А оставлять компанию в ситуации, когда некому устранить ту или иную неисправность, нельзя. К слову, на обслуживание компании «Инфосистемы Джет» помимо ЦОДа мы передали техническую поддержку всех двухсот тридцати наших аптек. Это позволило высвободить еще десять сотрудников ИТ-отдела.
В целом в ИТ-отделе остались лишь те сотрудники, которые владеют ключевыми компетенциями по бизнес-приложениям и бизнес-процессам, которые они поддерживают. Ну и сотрудники первой линии технической поддержки, без которых обойтись сложно.
К каким возможным проблемам и сложностям надо быть готовым при переходе на аутсорсинг?
Основные проблемы и сложности имеют место на стадии реализации проекта. На два-три месяца придётся забыть не только о свободном времени, но даже и о полноценном сне. У нас на стадии переноса приложений и данных всё обстояло именно так. Но зато потом все сложности оставались далеко позади. Положительный эффект мы почувствовали сразу. Так что китайский лозунг времен «Большого скачка»: «Десять лет упорного труда – десять тысяч лет счастья» – довольно адекватно передает суть проектов, связанных с передачей инфраструктуры на аутсорсинг.
Достигнута полная прозрачность во взаимоотношениях с бизнесом. У меня нет затрат, которые можно было бы посчитать необоснованными. Я могу показать любому бизнес-руководителю или инвестору, на что и зачем я трачу средства.
От компании «Инфосистемы Джет» пришел также новый уровень ИТ-подразделения. Там работают по-настоящему квалифицированные специалисты, и на них приходится равняться моим сотрудникам. Повысилась дисциплинированность разработчиков, что выражается хотя бы в снижении количества грубых ошибок. Такие огрехи быстрее выявляются, и соответственно следуют всяческого рода санкции. И мы используем службу Service Desk, которую нам предоставляют «Инфосистемы Джет».
