Кто должен отвечать за эксплуатацию ИС: разработчик или IT-аутсорсер?
Разработка и эксплуатация информационных систем – два очень разных по своей сути вида деятельности. Однако часто эти большие и разноплановые задачи совмещают и передают одному исполнителю – разработчику. Такое решение имеет массу недостатков.
Согласно опубликованным в конце 2012 года данным исследования Compuware Corporation, 71% опрошенных руководителей IT-отделов недовольны «скрытой стоимостью» аутсорсинга. Под этим термином подразумевают существенно более высокие затраты на IT-услуги, нежели планировалось изначально. Скрытая стоимость аутсорсинга, делает вывод Compuware, следствие комплекса причин, и в том числе неоптимального кодирования: оно создает повышенную нагрузку на IT-инфраструктуру и, по данным Compuware, приводит к ежегодному удорожанию эксплуатации инфраструктуры на 21%. Это явление можно считать закономерным, но вряд ли стоит винить в этом только аутсорсинговые компании и разработчиков – нередко все зависит от выбора исполнителей и понимания заказчиком спектра их возможностей.
Разделение функций разработки и эксплуатации
Разработка, внедрение и сопровождение ИС – разноплановые задачи, которые должны решать разные исполнители. Разработчик и/или внедряющая организация (консультант) отвечают за разработку изменений в ПО и их внедрение в организации. Эксплуатирующая организация обеспечивает функционирование ИС с заданными параметрами доступности. Обычно же обе эти задачи, как правило, передают разработчику. Об этом свидетельствует и информация из открытых источников (на сайте госзакупок или сайтах других организаций): очень часто разработка ИС, внесение в нее изменений и ее эксплуатация разыгрываются в одном конкурсе. Обратные примеры на рынке все же есть (по крайней мере, те два проекта, в которых участвует наша компания), но пока они скорее исключение, чем правило.
Идея разделения функций разработки ПО и эксплуатации систем возникла в ходе работы с крупной ИС федерального масштаба. ПО для нее разрабатывала компания «ЛАНИТ», а «ОНЛАНТА» (входит в группу «ЛАНИТ») обеспечивала его сопровождение. С одной стороны, мы входим в один холдинг и заинтересованы в том, чтобы заказчик был доволен всеми участниками процесса, но с другой стороны – у нас, как самостоятельных юридических лиц, разные бизнес-интересы. В ходе этого проекта нам пришлось учиться выстраивать взаимодействие как с заказчиком, так и с разработчиком.
Понятно, что в ходе проекта разработчик стремится в заданные сроки выполнить свою задачу и сдать систему в эксплуатацию. При этом он учитывает, что на начальной стадии эксплуатации могут обнаружиться недочеты, недоработки, но их можно будет «отшлифовать» уже после подписания актов сдачи-приемки. В случае же, когда привлекается IT-аутсорсер, именно на него возлагаются ответственность за доступность приложения и финансовая ответственность перед заказчиком в рамках SLA, а «недошлифованный» продукт может привести к финансовым потерям аутсорсера. Поэтому целесообразно передать тестирование ПО перед установкой аутсорсеру, кровно заинтересованному выявить как можно больше недоработок.
Еще одна особенность работы аутсорсера – во взаимодействии с разработчиком ПО. Не все недочеты выявляются на этапе тестирования, ошибки иногда возникают уже при «боевой» нагрузке системы, в которой работают пользователи. В рамках традиционной схемы разработчик сам решает эти проблемы, а заказчик зачастую даже не догадывается о них. В нашем случае мы регулярно общались с разработчиком, формулировали проблему, давали задание на доработку и вместе искали решение.
Опыт показал, что такой подход дает заказчику несколько преимуществ. Прежде всего, дополнительное звено контроля не позволяет установить в продуктивную среду ПО с дефектами. Ситуация с выполнением разработчиком своих обязательств становится прозрачной, так как недостатки работы фиксируются эксплуатирующей организацией. В итоге: повышается стабильность работы приложений, сокращается время простоев ИС, за счет оптимизации производительности приложений сокращаются затраты на приобретение новых аппаратных средств, растет эффективность применения ИТ в организации.
Минусов у такого подхода, пожалуй, нет. Теоретически можно предположить, что две независимые организации в случае обнаружения ошибок будут обвинять друг друга, а заказчик окажется в роли арбитра. Но даже в этом случае при наличии разногласий – ставить или нет новую версию в боевую эксплуатацию – стороны могут продолжать споры, но старая версия системы у заказчика будет работать, а не «лежать».
Модель разделения функций разработки ПО и эксплуатации системы мы предложили еще одному заказчику. Идея была одобрена, и пару месяцев назад подписан контракт на выполнение работ по эксплуатации ИС.
Различия в процессах управления
Надо отметить, что с точки зрения управления бизнес-процессами разработка и доработка ПО – производственная деятельность, в основе управления которой лежат принципы управления процессами разработки со своими стандартами, а эксплуатация – это «сфера IT-услуг», в основе которой лежат процессы управления предоставлением услуг. То есть речь идет о совершенно разных принципах и стандартах управления.
В рамках модели управления IT-услугами эксплуатирующая организация отвечает за доступность приложений и обеспечивает бесперебойность их работы в соответствии с SLA. Поэтому, если перед заказчиком стоит задача построить процессы эксплуатации ИС, ему нужно ориентироваться не только на квалификацию разработчиков, которые по мере необходимости будут вносить изменения в ПО, – он должен понимать процессы управления предоставлением услуг в эксплуатирующей организации. У последней должны быть соответствующие сертификаты, подтверждающие качество ее работы именно как сервисной компании, оказывающей IT-услуги.{PAID}
Особенности подбора персонала
Есть еще один очень важный, но неочевидный момент, о котором заказчикам необходимо помнить при выборе исполнителя: разработчики ПО и специалисты, которые занимаются эксплуатацией, – это разные по набору профессиональных навыков и складу характера люди.
Разработчики, как правило, воспринимают задачи, связанные с эксплуатацией, без большого энтузиазма. Они с удовольствием занимались бы только разработкой ПО и не тратили время на настройку, мониторинг работоспособности, оказание консультаций, решение проблем пользователей и т. д. В свою очередь, эксплуатационщики в значительной мере ориентированы на оказание услуг и обладают таким качеством как сервис-ориентированность. Из разработчиков сложно создать службу круглосуточной поддержки. А для специалистов, занятых эксплуатацией, посменная работа с ночными дежурствами – норма. Таким образом, компания-разработчик будет, скорее всего, не самой лучшей эксплуатирующей организацией. Если, конечно, не создаст отдельное эксплуатационное подразделение, со своей кадровой политикой, системой профессионального роста, системой мотивации. Но это уже совсем другой бизнес.
Поэтому, чтобы понять, насколько персонал той или иной компании ориентирован на оказание услуг поддержки, заказчику еще на этапе переговоров полезно поинтересоваться, как в этой компании выстроена система мотивации и построена работа с персоналом.
Скрытая стоимость vs прозрачные процессы аутсорсинга
Подытожим, из чего же складывается «скрытая стоимость аутсорсинга» – определения, с которого начался наш разговор.
Во-первых, это вполне объяснимое желание разработчика ПО передать заказчику систему в установленный договором срок, без задержек. При этом далеко не всегда ПО сразу готово к эффективной эксплуатации, что приводит к остановкам системы для исправления ошибок, то есть к ее простою.
Вторая составляющая обусловлена тем, что эффективно работающий программный код, написанный под текущие задачи заказчика, может по мере изменения задач и проведения доработок потребовать закупки дополнительных вычислительных мощностей для сохранения производительности. Стандартная схема эксплуатации ИС разработчиком не предусматривает наличия третьей стороны, способной дать объективную оценку эффективности работы ПО. А достаточно часто производительность работы системы можно сохранить на нужном уровне, оптимизировав код и не наращивая вычислительных мощностей.
Третья составляющая «скрытой стоимости» аутсорсинга – «нелогичное» использование кадровых ресурсов. Как уже отмечалось, разработчики и эксплуатационщики – разные люди, с разным набором навыков, ориентированные на разные процессы. Заставлять их заниматься непрофильной работой – все равно что забивать гвозди микроскопом. Каждый инструмент должен использоваться по назначению. В противном случае заказчик рискует заплатить слишком дорого за работу незаинтересованных и немотивированных людей.
И наконец, выбрав эксплуатирующего аутсорсера, бизнес-процессы которого формировались на протяжении длительного времени, заказчик может рассчитывать на получение услуг высокого качества за меньшие деньги.
Опубликовано 04.06.2013