Аутсорсинг

Руководству сети Burger King удалось создать во многом уникальную модель управления большой сетью ресторанов, основанную на объективных показателях. Менеджеры ресторанов имеют доступ к объективной, наглядной и оперативной информации о своей работе, что обеспечивает их вовлеченность в повышение эффективности деятельности компании.

Максим Шарапов, директор департамента ИТ «Интернэшнл Ресторант Брэндс» и претендент на CDO Award, рассказывает о пользе меритократии, выработке у руководства ресторанов психологии бизнесменов и полном аутсорсинге процессов BI.

- С какого момента Burger King начал трансформироваться?

Трансформация имела подготовительный этап. Сеть Burger King начала бурно развиваться с 2012 года, тогда у нас было несколько десятков ресторанов и появился стратегический партнер. Получив финансирование, сеть начала экспансию. В этот момент я пришел в компанию и занимался стратегией развития ее информационных систем.

Базисом всей дальнейшей работы была подготовка единого источника данных, необходимого для последующего внедрения цифровых сервисов. Мы приняли решение внедрять ERP-систему, объединив в единой базе разрозненные данные различных подразделений. Более того, ERP стала системой мастер-данных. Таким образом был создан фундамент для дальнейшей цифровой трансформации.

- Какова история активной работы с данными? Когда произошел скачок, каковы его причины и результаты?

Когда внедрение ERP — а это большая и важная работа — было осуществлено, мы смогли направить силы на более конкретные бизнес-задачи. Были созданы все предпосылки для бизнес-аналитики: у нас появились данные, в отношении которых мы могли гарантировать целостность и корректность. Компания предпочитает в бизнесе прагматичный подход, руководство очень любит, когда в работе ориентируются на понятие quick wins — максимально быстрое достижение осязаемых результатов. Если в случае с ERP мы понимали, что быстро ее внедрить не получится, и были готовы терпеть целый год, то работу с BI-отчетностью мы вполне могли организовать по принципам Agile. Работа строится на поступающих от бизнес-подразделений вполне конкретных задачах по созданию приложений.

- Какие использованы платформы и продукты?

В качестве платформы мы выбрали Qlik и весьма оперативно подключили команду разработчиков. Эта платформа дает возможность действовать быстро и обойтись без создания хранилища данных. При помощи Qlik мы начали делать достаточно быстрые проекты. Задача состояла в предоставлении бизнесу подсказок и предложений относительно того, как скорректировать свою работу, чтобы максимизировать прибыль.

- Почему решили обойтись без хранилища? Сейчас этот подход используется повсеместно.

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

Да и сам принцип работы Qlik часто подразумевает отсутствие хранилища. Платформа всеядна, а ETL-процессы могут быть описаны в самой системе.

- Существует ли в компании стратегия работы с данными? Если есть, то в чем она заключается?

Четкой стратегии у нас нет, но есть основной принцип: компания регулярно и оперативно принимает решения на основе данных. Исходя из этого, мы формируем требования к данным. Например, от события в любом из более 600 ресторанов до его отражения в отчетности должно проходить не более 15 минут. Это означает, что все виды контроля по целостности и качеству данных должны быть зашиты в сами системы.

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

- Действительно ли скорость настолько важна? Каким образом достигается актуальность данных, близкая к реальному времени?

Первым крупным результатом в рамках работы с данными стал проект «Рутина», благодаря которому рестораны начали получать ежедневные отчеты, весьма объемные и детальные. Следующий шаг был направлен именно на оперативность. Мы переосмыслили работу с источниками данных и стали работать с локальными кассовыми базами, а не с центральной базой, где консолидировались данные при закрытии кассового дня. Это было нужно для того, чтобы сотрудники ресторанов могли в режиме, близком к реальному времени, видеть, на какие показатели они выходят по итогам дня. Если что-то идет не так, у них есть возможность изменить ситуацию.

- Переход к управлению на основе данных — это серьезная культурная трансформация. Люди не любят меняться. Как обеспечить принципиальную возможность таких изменений?

Это и просто, и сложно. Надо быть максимально честными с людьми. Компания в своей работе придерживается философии меритократии — воздавать каждому по его заслугам. Человек, принесший компании измеримый в деньгах результат, может претендовать на часть этого результата. Любой сотрудник ресторана может предложить идею, которая повысит эффективность компании. Такие идеи могут быть озвучены непосредственному начальству, затем совместно — вышестоящему руководству, и очень важно, чтобы эта цепочка была быстрой, а ценные идеи максимально оперативно воплощались в жизнь. Не нужно теоретических рассуждений — надо брать и пробовать, а пилотный проект покажет ценность на практике.

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

Таким образом, работу с данными можно считать некоторой базой для управленческого развития компании, которое во многом построено на стандартизации функций и их делегировании. Все управленческие решения на каждом из уровней управления основаны на объективных данных. На объективных показателях основана и мотивация сотрудников, что дает их высокую вовлеченность в улучшение работы ресторанов.

- Любопытным подходом является полный аутсорсинг всей работы с данными: в штате Burger King нет ни одного BI-специалиста, а функциональные менеджеры самостоятельно вносят задачи по работе с данными в очередь для реализации. Как такое стало возможным?

Да, работа с данными отдана на аутсорсинг в компанию Qlever Solutions, и у нас действительно нет ни одного BI-специалиста. Но зато есть мощное подразделение бизнес-аналитики, сотрудники которого не являются техническими специалистами, но имеют сильную экспертизу и глубокое понимание показателей экономической деятельности компании. Еще есть должность менеджера по развитию информационных систем, он управляет изменениями и принимает участие в расстановке приоритетов. Таким образом, все изменения проходят определенный контроль на достаточно высоком уровне.

Во многом такой подход стал следствием того, что компания довольно жестко ограничивает в подразделениях численность штатных сотрудников. В итоге образовалась гибкая структура, которая позволяет точно масштабировать ресурсы в соответствии с объемами работ и приобретать услуги по модели time&material.

Надо сказать, что к идеальному варианту пришли не сразу. У нас был негативный опыт работы с одной из очень известных компаний, занимающихся платформой Qlik, ставший примером того, какими отношения быть не должны. Действия по закрытию кода решения и неприкрытый шантаж вынудили нас разорвать с ней отношения и в дальнейшем более внимательно относиться к таким вопросам.

С нынешними партнерами выстраиваются именно доверительные отношения. Мы даем им значительный объем работ и ждем от них честности и заинтересованности в долгосрочном сотрудничестве. От них имеем лояльное отношение и привлекательные цены.

- В руки партнеров попадают ваши данные. Как страхуетесь от утечек?

Я могу лишь повторить слово «доверие». Конечно, договоры о конфиденциальности подписаны, но понятно, что они не дают стопроцентную гарантию от утечек. Таков выбор компании: мы идем на немалый риск ради более эффективных процессов.

- Быстрое внедрение изменений достигается благодаря подходам Agile. В какой момент стало понятно, что они нужны компании?

Нельзя сказать, что мы жестко придерживаемся каких-либо методик. У нас есть потребность в быстрой разработке, оперативно осуществляемых пилотных проектах. При наличии хорошей экспертизы, особенно в случае, когда консультант и разработчик — это одно лицо, от обсуждения до выхода продукта в свет проходит очень немного времени. Кроме того, все бизнес-подразделения компании вовлечены в процессы реализации решений, что минимизирует эффект «испорченного телефона».

Еще очень важна работа с трехслойной моделью данных, когда уже созданные показатели могут передаваться из модели в модель. Это важное архитектурное ноу-хау нашего партнера Qlever Solutions, существенно ускоряющее процесс разработки.

- Сейчас массово применяется предиктивная аналитика — использование математических моделей для прогнозирования выручки, спроса и других бизнес-показателей. Насколько это актуально для вас?

Актуально, но мы относимся к этому без фанатизма. Часто маркетинговая составляющая в ИТ идет во вред: использование модных технологий оправданно не всегда.

У нас есть пример использования машинного обучения в прогнозировании выручки. Долгое время мы задействовали простой алгоритм, дававший приемлемые результаты. Но компании было важно повысить точность таких расчетов, поскольку они влияли на закупки продукции, планирование выхода сотрудников на работу. Чем точнее прогнозирование, тем лучше компания подстраивается под внешнюю ситуацию.

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

- Работа с данными направлена в первую очередь на внутренние нужды или на предоставление сервисов вовне?

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

Да, необходимо развивать персонализированную работу с гостями. Вероятно, придется анализировать путь клиента (customer journey), удобство приложений, наполнять CRM, подключать к ней внешние источники данных, в том числе из социальных сетей. Это серьезный вызов для компании, потому что объемы данных растут экспоненциально. Предстоит решать инфраструктурные вопросы, пересматривать принципы работы с данными.

Думается, что именно «внешние» цифровые сервисы принесут компании в будущем дополнительную прибыль.

- Как с профессиональной точки зрения отразилась на вас проведенная за последние годы работа ?

Можно сказать, что я пошел на повышение. Наши акционеры завершили покупку большой части ресторанов известного бренда. Я приглашен во вновь образованную компанию на позицию ИТ-директора. Мне предстоит реализовывать ранее опробованные идеи.

Потребуется масса подготовительной работы, которая ранее уже была проделана в Burger King. Без нее не обойтись, однако с учетом имеющегося опыта, думаю, удастся сделать всё гораздо быстрее. Сейчас запускаем ERP, причем на проект отведено менее полугода. Начинаем работу с источниками данных, проводим инвентаризацию существующей отчетности и, имея определенный багаж за плечами, развиваем ее.

Часть менеджмента новой компании осталась, часть пришла извне. Интересно, что получится из такого столкновения культур и подходов.

- Появления каких новых цифровых сервисов можно ожидать в ресторанном бизнесе в ближайшем будущем?

Распознавание клиентов — перспективная технология, и есть достаточно сильные алгоритмы, позволяющие это делать. С видеоаналитикой уже в текущем году на рынке будет достаточно много проектов.

Кроме того, последние достижения в области deep learning дают возможность выйти на новый уровень работы с продуктами и роботизации многих процессов. Инновации — это хорошо, но все считают свои деньги. И пока человеческий труд остается дешевым, будут выбирать именно его. Тем не менее в ближайшие пять лет, думаю, мы сможем увидеть полностью роботизированные рестораны.

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

Архитектурное бюро UNK Project специализируется на архитектурном и инженерном проектировании зданий и комплексов, на дизайне корпоративных интерьеров и общественных пространств. Наши проекты неоднократно удостаивались престижных профессиональных премий. Бюро объединяет специалистов разного профиля, и это дает возможность создавать комплексные решения и участвовать на всех стадиях работы над масштабными проектами.

Все работы над проектами ведутся с помощью высоких технологий: например, с помощью программных комплексов, предоставляющих возможности трехмерного моделирования элементов зданий, создания пользовательских объектов, организации совместной работы над проектом – от концепции до выпуска рабочих чертежей и спецификаций. Используются также технологии информационного моделирования зданий (Building Information Modelling, BIM), позволяющие оптимизировать процессы проектирования, грамотно управлять жизненным циклом объектов и экономической составляющей этого цикла.

Мы давно стремились к тому, чтобы ИТ-система работала безупречно, не приводила к сбоям в основной деятельности. Понимая, что эта задача требует профессионализма и непрофильных для нашей компании технологий, в 2013 году в рамках классического ИТ-аутсорсинга мы начали сотрудничать с ALP Group. Большинство запросов на обслуживание решалось удаленно, и лишь небольшая часть – непосредственно у нас в офисе.

Первоначальную задачу мы решили. Но в 2017 году, с началом новых масштабных проектов для таких клиентов, как «Росатом» и «Сколково», наши требования как к ИТ-поддержке, так и к самой информационной системе выросли.

Что же именно нам потребовалось и почему?

Максимально оперативное реагирование и скорость решения ИТ-инцидентов. При работе над комплексными проектами остановки в работе квалифицированных архитекторов и дизайнеров обходятся крайне дорого. К таким остановкам могут приводить различные сбои в ИТ, поэтому мы решили, что допускать их нельзя. Реакция на ИТ-инциденты и проблемы должна была стать примерно на 30% быстрее, чем в среднем по рынку.

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

Повышенные требования к доступности системы. Из-за большого объема данных рендеринг (отрисовка проектов) выполняется в основном ночью. Причем крайне важно, чтобы он не просто выполнялся, но и гарантированно был завершен к утру следующего дня. Только при этом условии сотрудник может начинать работу над очередной стадией проекта. Мы решили, что для нас совершенно неприемлемы любые простои из-за несвоевременного завершения рендеринга или каких-либо других нестыковок бизнес-процессов и ИТ. На техническом уровне это означало ужесточение требований к вычислительной мощности и более тонкое управление конфигурациями «железа». Сама система должна быть доступна круглосуточно. Днем – для сотрудников, ночью – для машин.

Повышенная адаптивность ИТ-поддержки. Требования к системам, на которых мы ведем моделирование и проектирование, всегда могут поменяться по решению наших заказчиков. Поэтому важно, чтобы соответствующие изменения в систему можно было вносить максимально оперативно.

Все перечисленное заставило нас серьезно задуматься о переходе на новый уровень организации и обслуживания ИТ.

Изменение модели ИТ-обслуживания

Изменения в потребностях отметили и специалисты ALP Group, ежедневно отслеживавшие нагрузку на оборудование, число заявок на ИТ-обслуживание в собственной системе Service Desk, а также многие другие параметры, важные для качественной работы ИТ.

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

Что было сделано

Прежде всего была переформатирована работающая c нами команда. В новый состав вошли сотрудники службы техподдержки, постоянно работающие со специализированным ПО для архитектурных бюро и студий (AutoCAD, Revit) и умеющие предотвращать падение его производительности с помощью проработанных методик и современных инструментов. Эти специалисты также умеют тонко настраивать используемые программы под клиента.

Еще более радикальное изменение претерпело подключение нашей информационной системы к экспертному сервису централизованного мониторинга и контроля здоровья ИТ – СЦМК «Аргус». Этот сервис помогает предотвращать порядка 80% инцидентов в ИТ-инфраструктуре и до 10 раз быстрее решать те 20% ИТ-инцидентов, которые все же происходят. Кроме того, благодаря точной диагностике инцидентов и максимально эффективному их устранению, процент выпадения из SLA при решении ИТ-проблем становится минимальным.

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

Кроме того, проектная команда ALP Group посоветовала нам вынести в облако один из серверов, на котором работает система проектирования зданий, чтобы не перегружать имеющуюся инфраструктуру и получить возможность следить за потреблением ресурсов этим важным ПО. Теперь мы не просто знаем, сколько ресурсов нужно для хорошей работы программы здесь и сейчас, но и сколько их потребуется завтра, когда появится еще несколько новых сложных проектов. За онлайн-аналитику по потреблению мощностей в облаке также отвечают специалисты подрядчика, как и за своевременное добавление их «по клику мыши», причем без переплаты вдвое-втрое. Анализ и оптимизация использования ресурсов производятся с помощью штатного ИТ-сервиса на базе СЦМК.

Результаты

Ускоренное решение ИТ-инцидентов

Благодаря работе СЦМК «Аргус» и включению экспертов в команду обслуживания наших информационных систем удалось сократить время реакции на ИТ-инциденты в восемь раз, с 2 часов до 15 минут, а время их решения – в четыре раза, с 4 часов до 1 часа.

Эксперты работают сообща, имеют доступ к полной и консолидированной информации, а также к набору инструментов анализа данных. Они предлагают нам решение той или иной проблемы уже при первых ее признаках. Это позволяет забыть о «тушении пожаров» и работать проактивно и спокойно. Причем специалисты не ограничиваются устранением выявленных проблем, а стремятся заблаговременно «расшить» возможные узкие места – с минимумом ресурсных затрат и с максимальной пользой для клиента.

Устранение проблем до того, как начнется их негативное влияние на бизнес

80% ИТ-инцидентов и проблем действительно стали решаться заблаговременно – еще на стадии возникновения. Частично благодаря проактивному обнаружению, частично – максимально точному присваиванию им приоритета. При сервисной модели инциденты решались в общем потоке – не с такой точностью – и могли перерасти в проблему (цепочку инцидентов, порожденную скрытыми причинами). Теперь же до минимума снизились сбои и простои по вине ИТ.

Оперативное планирование ресурсов

Когда в бюро приходит новый заказчик, у него обычно есть собственные требования к обмену данными (к форматам данных, графику обмена, протоколам «вытягивания» данных, информационной безопасности). Теперь это не проблема, так как появилась возможность оперативно предоставлять настроенные файловые сервисы, учитывающие эти требования. Более того, с помощью штатного сервиса автоматизированного анализа и сайзинга ресурсов команда тут же планирует расширение места под проекты с учетом предполагаемого графика и характера работ. Это спасает нас от перерасхода средств на оборудование.

Ускоренное решение рутинных задач

На подготовку рабочего места для новых сотрудников стало уходить не два-три дня, а всего один. Мы активно нанимаем персонал для новых архитектурных проектов. В день на работу в бюро могут выходить по три новых сотрудника – это немало. И для каждого специалиста должно быть готово абсолютно все – от оборудования до приложений. Это стало происходить очень четко и быстро.

Рост качества обслуживания и снижение затрат на ИТ-поддержку

Изменение модели ИТ-обслуживания с сервисной на сервисно ориентированную позволило нам существенно улучшить качество обслуживания – причем по многим параметрам и действительно очень значительно. При этом оказалось, что более высокий уровень ИТ-сервиса можно получить за гораздо меньшие деньги: экономия нашего ИТ-бюджета составила 30%. Такое стало возможным благодаря специальным высокоэффективным инструментам и высокой доле роботизации услуг ИТ-компании.

***

В условиях цифровой трансформации взаимодействие с ИТ-партнерами зачастую становится ключевым фактором успеха, способным непосредственно влиять на финансовые результаты компаний. Новые требования к гибкости, предъявляемые рынком, должны отражаться и на отношениях компаний с поставщиками. Поставщикам ИТ-обслуживания необходимо стремиться к тому, чтобы их услуги были более адаптивными и непременно включали в себя хорошо продуманную и уже проверенную на практике «умную» составляющую.

 – Автор: Наталья Якушева, административный директор UNK Project

Компании отдают на аутсорсинг все разновидности ИТ- и бизнес-функций, в том числе и стратегические. Все чаще передается «на сторону» и сфера аналитики данных – одно из наиболее конкурентоспособных технологических направлений.

Для аутсорсинга нанимают поставщика услуг, который анализирует предоставляемые ему данные. Исследования показывают, что спрос на услуги подобного рода находится на подъеме.

В отчете, опубликованном в 2017 году консультационной компанией Hexa Research, указывается, что с 2016 по 2024 год мировой рынок аутсорсинга анализа данных будет ежегодно расти более чем на 30%, а к концу этого периода объем продаж превысит 6 млрд долл.

Как утверждается в отчете, растущая осведомленность о преимуществах анализа данных становится ключевой движущей силой развития рынка. Бизнес постепенно осознает важность анализа в повышении доходов и влиянии на выбор потребителей. А между тем далеко не каждая организация обладает знаниями и ресурсами, необходимыми для эффективного анализа данных.

Нехватка аналитиков данных препятствует развитию конкурентоспособного анализа и порождает дополнительный спрос на аналитические услуги. В отчете Hexa все виды анализа подразделяются на три основных типа: прогнозный, предписывающий и описательный. Сейчас основная доля на рынке принадлежит описательному анализу. В дальнейшем ожидается существенный рост объемов предписывающего анализа, потребность в котором испытывают многие организации.

Что же касается самого аутсорсинга, он подразделяется на офшорный и оншорный.

«Облачные технологии упрощают доступ к данным в тех регионах мира, где рабочая сила более дешевая, поэтому может произойти сокращение расходов на текущее управление алгоритмами, – указала научный директор направления облачных технологий и ИТ-сервисов исследовательской компании 451 Research Кэти Ринг. – Технологии машинного обучения обещают дальнейшее снижение затрат в этой области. При этом офшорные источники имеет смысл выбирать главным образом для проектирования систем управления данными, нежели непосредственно для анализа».

«В условиях, когда ведущая роль в обработке отводится машинам, преимущества офшорных услуг постепенно будут нивелироваться, – добавила партнер консультационной фирмы EY в области глобального анализа Беатрис Санс-Саис. – Какой аутсорсинг будет выбран, не столь важно, гораздо большую значимость в достижении наилучших результатов имеет совместная работа людей и машин».

Передавать анализ данных на аутсорсинг имеет смысл только для определенных видов аналитики. Наряду с потенциальными преимуществами здесь есть и риски. Перечислим, в чем можно проиграть, а в чем выиграть, передав анализ данных на аутсорсинг.

Преимущество: доступ к нужным дефицитным навыкам

Не секрет, что многие ИТ-специальности сегодня в дефиците. Это в полной мере относится к облачным вычислениям, передовым методам анализа, большим данным, озерам данных и науке о данных. Аутсорсинговые компании могут смягчить образовавшийся дефицит, предложив клиентам свои услуги в указанных областях.

«В условиях продолжающегося роста объемов данных рассчитывать на то, что традиционные ЦОДы помогут с этим справиться, уже не приходится, – заметила Ринг. – Рост потребностей в управлении большими данными в облаке способствует дальнейшему развитию Amazon Web Services, Microsoft Azure и Google Cloud Platform».

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

Недостаток: риск выбрать не того провайдера

Неверный выбор поставщика услуг грозит неприятностями в любом виде аутсорсинга, и анализ данных не является исключением.

«Выбор поставщика услуг может превратиться в сложную задачу, – указала Элисон Клоуз, возглавляющая в компании International Data Corp. направление исследований финансов и бухгалтерского учета, BPaaS и аналитических сервисов. – В первую очередь внимание следует обращать на стоимость предлагаемых услуг, однако не менее важны культурные предпочтения и расстановка команд. Компании сегодня хотят тесного стратегического партнерства, при котором выделяемые ресурсы соответствуют объему повседневных операций, коммуникационные каналы эффективны и получение требуемых бизнес-результатов гарантируется».

Преимущество: отраслевой опыт

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

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

Недостаток: поиск компромисса между ценностями и затратами

После создания прогнозной модели и преобразования ее внешним поставщиком услуг в продукт, необходимо организовать сопровождение в течение требуемого периода. Это предполагает настройку и видоизменение правил алгоритма, чтобы обеспечить сохранение значимости получаемых результатов.

«Данные постоянно меняются, и применяемая модель не должна деградировать, – пояснила Ринг. – Однако постоянные обновления требуют затрат, которые могут превысить затраты на составление отчетов бизнес-анализа внутренней ИТ-службой».

При этом стоимость услуг аутсорсинга может стать проблемой, особенно в крупных организациях со сложными операционными моделями.

Преимущество: простота масштабируемости и быстрый путь к зрелому анализу

Помимо возможности приобрести навыки анализа данных, аутсорсинговые услуги могут помочь организации быстро выстроить аналитическую инфраструктуру, создать которую своими силами весьма затруднительно или вообще невозможно.

«Анализ данных стал естественной составляющей при ведении бизнеса и сегодня представляет собой нечто большее, чем совокупность хранилищ данных и бизнес-анализа, – указал директор Gartner по исследованиям данных и их анализу Йорген Гейзенберг. – Однако предприятие не всегда в состоянии справиться своими силами с тем уровнем масштабируемости и сложности, который требуется. Чаще всего организации обращаются за внешней поддержкой при отсутствии внутренних ресурсов, позволяющих удовлетворить растущий спрос».

Еще одним фактором может стать стремление сократить затраты при приобретении аналитических услуг, поскольку их поставщики зачастую используют уже имеющиеся у них аналитические ресурсы — фреймворки и ускорители.

«Использование технических наработок провайдера, будь то организация хранилища данных, автоматизация и внедрение роботизированных процессов или применение облачных инструментов, может стать большим плюсом, – добавила Клоуз. – Передача анализа данных поставщику услуг аутсорсинга способствует переходу на такие инновационные решения, которые в настоящее время предприятием даже и не рассматриваются».

Недостаток: потеря контроля над хранением данных и аналитическими моделями

Любой аутсорсинг предполагает отказ от чего-либо, выполняемого своими силами (например, от контроля), а иногда даже от собственных сотрудников. При аутсорсинге анализа одной из главных приносимых жертв могут стать аналитические модели.

«Клиент обычно предоставляет поставщику услуг свои данные, а тот, в свою очередь, возвращает ему ответы на интересующие его вопросы, – пояснила Ринг. – При такой модели клиент не владеет ни логикой, ни алгоритмами. В его распоряжении остаются лишь данные и полученные рекомендации. Моделей, подходов, фреймворков и конфигураций он лишен».

У компаний, передающих анализ данных на аутсорсинг, могут возникнуть вопросы и в отношении хранения их данных. Действительно ли это хранение организовано наилучшим образом? Есть ли в ЦОДе провайдера выделенная среда для вашего предприятия? Или же все данные находятся в «разделяемой» среде публичного облака?

Преимущество: постоянное обеспечение законодательных требований к защите данных

По мере роста объемов данных в процессе управления ими и их анализа организация подвергается риску не соблюсти нормативные требования, установленные регуляторами.

Разница между политиками управления и безопасности в различных источниках данных порождает дополнительные трудности при переходе к аудиту в озерах данных.

«После вступления в силу требований к защите персональных данных и правил General Data Protection Regulation (GDPR) потребность в простом аудите может дополнительно подстегнуть поиски внешнего аутсорсингового партнера», – подчеркнула Ринг.

Недостаток: необходимость иметь стратегию управления данными

Для дальнейшей демократизации данных внутри организации директору по данным нужна общекорпоративная стратегия сбора, управления и обмена данными.

Уровни управления и анализа на условиях самообслуживания должны быть спроектированы правильно, с тем чтобы поддерживать различные сценарии использования. Вот почему роль директора по данным приобретает такое важное значение.

«В конечном итоге директор по данным отвечает за организацию взаимодействия бизнеса и ИТ в процессе управления данными, – пояснила Ринг. – Если в организации, передающей анализ данных на аутсорсинг, директора по данным нет, ее успехи, скорее всего, окажутся весьма скромными».

Преимущество: рост потенциальной ценности данных

Как уже отмечалось, данные – это новая валюта для бизнеса, и в их анализе заложен большой потенциал для получения конкурентных преимуществ.

«С переходом на машинную обработку данных потенциал данных и их анализа существенно изменился, – указала Саис. – Как и в любом цифровом бизнесе, мы сталкиваемся с дезинтермедиацией, в результате чего ценности остаются на двух сторонах бизнеса: на стороне данных, а также на стороне бизнес-анализа и поддержки принятия решений».

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

Недостаток: потенциальные конфликты

Подписывая аутсорсинговые соглашения, все рассчитывают на то, что взаимоотношения между сторонами будут развиваться гладко. Но могут возникнуть вопросы, которые поставят под угрозу гармонию этих взаимоотношений. Такая вероятность особенно велика, если в компаниях не озаботились тщательным изучением заключаемых договоров.

«При аутсорсинге анализа данных организации зачастую забывают о ключевых условиях, связанных с разрывом договора, управлением данными, правами на интеллектуальную собственность, ответственностью, основными параметрами и соглашениями об уровне сервиса, ценовой моделью, а также привлечением дополнительных ресурсов и увеличением затрат, – пояснил Гейзенберг. – Все это приводит к потенциальным конфликтам как в ходе взаимодействия, так и после его завершения».

– Bob Violino. The pros and cons of outsourcing data analytics. CIO. JUN 12, 2018

Соглашения об уровне сервиса (Service Level Agreement, SLA) являются важнейшим элементом контрактов аутсорсинга и служат основой для отчетов о предоставляемых ИТ-услугах. Любые недочеты, допущенные при составлении SLA, могут резко ударить по качеству обслуживания, при этом отчеты о безупречном соблюдении условий не будут соответствовать реальному положению дел.

Чаще всего подобные ситуации возникают, когда SLA относится лишь к части процесса оказания услуги исполнителем, а не ко всем его этапам. Как следствие, все индикаторы на информационной панели доставки услуг светятся зеленым, но реальное качество клиента не устраивает.

Именно поэтому важно составить SLA для сделок ИТ-аутсорсинга максимально правильно.

Составляя SLA, полагайтесь на здравый смысл

Уровни сервиса, не поддающиеся достижению или не отвечающие вашим потребностям, только затруднят контроль за соблюдением условий сделки. Если контролируемых показателей будет слишком много, это приведет к непроизводительным потерям для всех участников. Следует выбрать лишь несколько метрик, которые действительно обеспечат необходимый бизнесу результат. Будьте прагматичны и используйте SLA, чтобы постоянно поддерживать достаточный уровень эффективности.

Лучше, чтобы показателей уровня сервиса было меньше, но они были более комплексными, советуют в KPMG. Кроме того, все стороны должны быть правдивы в вопросе степени терпимости к неудачам – она почти всегда выше, чем предполагают ИТ-специалисты. Это позволит экономить деньги в процессе предоставления услуг и поможет в обосновании реально достигнутых уровней обслуживания.

Не рассчитывайте, что неустойки помогут экономить

В SLA нередко включают пункты о возмещении при неисполнении обязательств. Однако у подобных положений есть обратная сторона, особенно когда речь идет о сервисных кредитах, предоставляемых в качестве компенсации за ненадлежащее обслуживание.

Следует понимать, что денежные штрафы в SLA предназначены для того, чтобы заставить исполнителя соблюдать условия, а не для того, чтобы получать сервисные кредиты по любому поводу. Если вносить в SLA слишком много критических ключевых показателей, нарушение которых ведет к возмещению, то воспринимаемая значимость действительно важных показателей может уменьшиться.

Не забывайте, что сервисные кредиты сами по себе не могут полностью компенсировать низкое качество обслуживания. По сравнению со штрафными санкциями более важен анализ первопричин с последующей разработкой и реализацией плана решения проблем, которые привели к невыполнению условий.

От положений об отработке можно отказаться

Положения об отработке дают исполнителю право не выплачивать сервисный кредит, если позднее был достигнут определенный уровень обслуживания. Такого рода условия в последнее время «выходят из моды», и неспроста – клиенты убеждаются, что простой в обслуживании невозможно «отменить» путем перевыполнения требований позднее.

Следите, чтобы метрики не перекрывались

Все SLA должны охватывать разные области, перекрытий по контролируемым показателям быть не должно. В целом SLA должны обеспечивать клиенту видимость операционной среды и принципов ее работы.

Следите за точностью

Формулировки в SLA должны быть предельно четкими, а контролируемые параметры поддаваться количественному измерению. Необходимо обеспечить ясность относительно того, что именно и каким образом измеряется, как оценивается эффективность, а также указать возможные исключения.

До вступления соглашения в силу заказчику и исполнителю следует встретиться и совместно оценить измеримость всех предусмотренных в документе характеристик обслуживания, согласовать инструменты измерения и проанализировать возможное влияние SLA на бизнес. По свидетельству специалистов, в ходе такого совещания нередко обнаруживаются проблемы.

Не устанавливайте слишком высокую незащищенную часть оплаты

Считается, что если поставщик услуг рискует потерять больше, это будет дополнительно побуждать его к выполнению условий соглашения. Поэтому заказчики нередко предусматривают в SLA положение, согласно которому определенная доля вознаграждения за услуги выплачивается только при условии соответствия метрик некоторым значениям. Однако перебарщивать с этим не стоит. Если чересчур «взвинтить» незащищенную часть, поставщик услуг может в ответ повысить расценки, чтобы компенсировать риски.

Предусмотрите льготный период

Если на дату начала действия контракта отсутствуют надежные опорные данные, то финансовые штрафы, предусмотренные в SLA, первое время применять не стоит. Пусть первые 60-120 дней считаются периодом обучения, в течение которого штрафные санкции не действуют.

Не переплачивайте за повышенные уровни обслуживания

Если вашей организации нужен более высокий уровень обслуживания, увеличенная плата не всегда будет оптимальным вариантом. Как объясняют в KPMG, поставщики услуг могут единым образом обеспечивать качество услуг на всех уровнях, а повышенные тарифы использовать для компенсации рисков, а не для реального улучшения качества.

Вносите со временем коррективы в SLA

Если уровень сервиса не отвечает потребностям бизнеса или создает проблемы, то мириться с этим не нужно. Например, благодаря автоматизации и различным технологиям оптимизации обслуживания некоторые метрики сегодня становятся ненужными, но зато появляются новые, и их необходимо контролировать. Анализируйте SLA вместе с поставщиком услуг и вносите коррективы. Сами метрики и соответствующие целевые значения должны периодически по обоюдному согласию пересматриваться и изменяться в соответствии с актуальными требованиями.

Не рассматривайте выполнение SLA как гарантию успеха

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

– Stephanie Overby. 10 do’s and don’ts for crafting more effective SLAs. CIO. May 30, 2018

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

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

Смена поставщика вместо устранения первопричин

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

Фокусировка на решениях, а не на проблемах

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

Тенденция приобретать стандартные решения по минимальной стоимости сегодня встречается реже. Как отмечают специалисты, следствием такой политики будут частые запросы изменений и потребность докупать дорогостоящие специализированные ресурсы, что повлечет невыполнение экономического обоснования и утрату доверия к аутсорсингу.

Заключение сделки в расчете на преобразования

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

Клиент может жаловаться на то, что поставщик сервисов не обеспечивает творческий подход и инновации, но при этом отношения между сторонами регламентируются традиционным запросом на поставку, устанавливающим жесткие правила и не допускающим гибкости. Другими словами, обычно сам заказчик, а не поставщик сервисов создает ограничения, препятствующие обновлению.

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

Аутсорсинг «по шаблону»

Не следует полагаться на подход, разработанный в другой организации. Необходимо тщательно оценить потребности своего предприятия, рассчитать масштаб планируемой сделки аутсорсинга и продумать ее условия, чтобы обеспечить улучшение вашей конкретной ситуации. Нужно определить схему финансирования, структуру рисков вашего конкретного предприятия и, учитывая его цели, задачи и культуру, провести подготовку.

Чрезмерно строгий контракт

Если в переговорах по сделке настаивать на жестких ограничительных условиях, это может ударить по самому заказчику, так как провайдер будет выдвигать встречные условия, чтобы не пострадала его бизнес-модель. В результате определенные положения контракта напрямую отразятся на его стоимости и в совокупности она может вырасти на 5-7%. При заключении контракта целью переговоров должно быть согласование условий с требованиями вашей организации, а не создание чрезмерно жестких ограничений для поставщика.

Недооценка влияния на сотрудников

Многие ИТ- и бизнес-руководители не проводят подготовку к масштабным переменам, которые влечет переход на аутсорсинг. Из-за этого обычно возникают барьеры, мешающие достижению намеченных результатов. Нередко руководители пребывают в ложной уверенности, что организация легко перейдет на новую модель доставки. Но впоследствии, когда выясняется, что это не так, результат становится неприятным сюрпризом.

Не нужно полагать, что имеющийся персонал сам по себе справится с управлением новыми сервисами. Понадобятся, в частности, сотрудники, способные при работе поддерживать отношения с третьей стороной – кто-то обладает такими навыками, а кому-то это не дано. Следует помнить: один проблемный участник группы способен свести на нет конструктивную работу множества других.

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

Недостаточное внимание переходному периоду

Передача обязанностей от собственного ИТ-отдела сервис-провайдеру – поворотный момент сделки аутсорсинга, требующий обстоятельного планирования и контроля. Если не уделить достаточно внимания переходной стратегии, компания, скорее всего, столкнется с задержками, потерей преимуществ, утратой доверия и поддержки заинтересованных лиц, а бизнесу будет нанесен ущерб.

Любую сделку пользователи и поставщики услуг аутсорсинга должны начинать с детальной совместной оценки имеющейся среды, в том числе процессов, систем, уровней обслуживания, объемов, контрактов и исключений, а также тщательного планирования процесса передачи знаний. Необходимо разработать план на случай чрезвычайных ситуаций и ограничить влияние перемен на ключевые бизнес-процессы компании, например на подготовку квартальных финансовых отчетов, а в начале проекта представители поставщика и заказчика должны работать вместе.

В планах нужно предусмотреть вероятность длительного срока ожидания поставки технологий, которые придется разрабатывать или закупать, а также необходимость найма новых специалистов. Самое важное – укомплектовать сильную команду или центр управления проектом для переходного периода, которые смогут уверенно «держать удар». Для такой команды важен творческий подход, позволяющий гибко продвигаться вперед невзирая на ограничения.

Недостаточные инвестиции в руководство

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

Управление с помощью соглашений об уровне сервиса

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

Выбор и обеспечение нужных уровней обслуживания – это непрерывный процесс, а не разовый этап. На протяжении срока действия контракта покупатель ИТ-услуг должен постоянно пересматривать SLA и искать способы их улучшения.

Устойчивый уровень обслуживания, безусловно, плюс, однако в последнее время поставщики и клиенты переходят на контракты, основанные на результатах. В рамках таких аутсорсинговых сделок для улучшения результативности используется статистика по достигнутым показателям уровня обслуживания.

– Stephanie Overby. 9 IT outsourcing mistakes to avoid. CIO. MAR 7, 2018

Методологии agile-разработки программного обеспечения существуют уже достаточно давно, но устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.устоявшейся практики составления контрактов на передачу разработки внешним подрядчикам еще нет.

«Традиционный подход к заключению соглашений предполагает, что команда разработки может с помощью подробного технического проекта определять, с каким уровнем конкретизации будет конечный продукт, – говорит Дерек Шаффнер, адвокат юридической конторы Mayer Brown. – Согласовываются и указываются основные вехи, условия приемки клиентом и сроки получения выплат. Все это легко отразить в соглашении о разработке, поскольку процесс разработки традиционно носит линейный характер и начинается с детального планирования, после которого идут проектирование, написание кода, тестирование и ввод в эксплуатацию».

В agile-проектах от традиционных процессов разработки отказываются в пользу более гибких. «Подробных технических проектов и ключевых вех больше нет, поскольку клиент и разработчик непрерывно переопределяют приоритеты деятельности в рамках кратких итераций – спринтов, – напоминает Шаффнер. – Agile-подход требует доверия со стороны клиентов, тогда как те, возможно, привыкли к формализации и контролю, присущим традиционной разработке».

Однако существуют контрактные механизмы, и заказчики могут ими воспользоваться, чтобы уменьшить неопределенность, сохранив преимущества agile-разработки с ее кооперативным характером. О том, какие меры предосторожности понадобятся, Шаффер рассказал в интервью CIO Magazine.

- В чем главные сложности при составлении контрактов на agile-разработки?

Для agile-разработки ПО характерно неструктурированное, непрерывное взаимодействие между клиентом и разработчиком, основанное на доверии и взаимопонимании, а это трудно формализовать в контракте. Наибольшие сложности связаны с созданием системы норм, которая позволит получить преимущества agile-разработки с ее творческим подходом и одновременно выполнить требования клиента о своевременном создании продукта по справедливой цене.

- Для agile-разработки сделку с фиксированной ценой заключить не удастся. Как рассчитать расценки при подготовке agile-контракта?

Для agile-разработки ПО больше подойдет контракт, предусматривающий оплату затраченного рабочего времени и материалов (time and materials, T&M), но такой вариант может не устроить финансовый отдел и ИТ-директора. Ведь agile-разработка требует доверия, поскольку нет четких требований, а модель T&M может спровоцировать разработчика брать деньги за максимально большее количество часов.

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

Модель T&M более привлекательна, поскольку в ней предусмотрены условия прекращения проекта, более дружественные для клиента. Но есть и большой риск: когда проект идет уже достаточно давно, желание клиента закончить его перевешивает легкую возможность выхода из соглашения. Из-за этого может возникнуть ситуация, когда разработчик начнет выманивать деньги из заказчика к концу проекта, если, конечно, нет лимита на выплаты.

- Как именно право на расторжение контракта работает в описанных ситуациях?

Учитывая, что цель каждой итерации – создать работоспособный код, за который оплата осуществляется по принципам T&M, как правило, договор позволяет клиенту прекратить проект в конце любой итерации, обычно без платы за аннулирование заказа. Если клиента не устраивает продукт, созданный за очередную итерацию, он просто может выйти из контракта. Вероятность того, что проект сильно отойдет от спецификаций за одну итерацию, минимальна, поскольку требования определяются в начале каждой итерации так, чтобы продвинуться к цели создания продукта в соответствии с общим замыслом.

Но при agile-подходе ПО документируется лишь минимально, поэтому возрождение прекращенного проекта может оказаться очень затратным, поскольку новым разработчикам придется потратить больше времени на то, чтобы разобраться с кодом.

- Agile-разработка по сути своей является изменчивой. Как заказчику предусмотреть в контракте какие-то вехи еще до начала работы?

Agile-разработка начинается с формулировки общего замысла продукта. Пользуясь им как руководством, разработчики затем составляют список требований (product backlog), представляющий собой отсортированный по приоритетности перечень работ, которые нужно выполнить в рамках проекта. В соглашении о разработке стоит указать, как будет вестись этот список на протяжении проекта, в том числе четко сформулировать обязанности разработчика по предоставлению сметы на разработку каждой позиции из списка. Пользуясь списком, стороны могут также определять порядок работы над позициями.

Если стороны решат не использовать первоначальный список в качестве контрактного документа, следует указать в соглашении, как список будет создаваться и сортироваться. У клиента также должно быть исключительное право вносить поправки в список и менять расстановку приоритетов в нем.

В соглашении об agile-разработке стоит еще описать процедуру прохождения итерации, в том числе продолжительность каждой итерации (обычно не подлежащую продлению; неоконченная работа вносится в список задач как приоритетная), частоту собраний и процесс, с помощью которого стороны будут определять, что работа в рамках итерации окончена. Следует отметить, что перенос неоконченной работы в следующую итерацию может увеличить денежные затраты.

- Как заказчику снизить риск текучки сотрудников на проектах, требующих непрерывной работы?

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

В соглашении также должны быть гарантии того, что разработчик предоставит все ресурсы, необходимые для завершения задач в рамках отдельной итерации. Тем самым исключается возможность оправдать незавершенность итерации нехваткой ресурсов. Кроме того, в контракте стоит указать, что передача знаний между разработчиками не оплачивается.

- При традиционном аутсорсинге разработки приложений поставщик услуг на определенное время дает гарантию того, что продукт будет работать согласно требованиям и любое несоответствие им будет устранено. Можно ли получить такие гарантии при agile-разработке?

Подобные гарантии были бы проблематичны, но разработчик мог бы гарантировать, что рабочий код, созданный в рамках каждой итерации, отвечает требованиям этой итерации. Учитывая, что объем рабочего кода от итерации к итерации растет, клиенту стоит потребовать гарантий того, что интегрированные компоненты будут работать друг с другом и финальный продукт будет функционировать согласно совокупности требований ко всем итерациям. Если для продукта характерны сезонные колебания нагрузки, надо позаботиться о том, чтобы такая гарантия охватывала периоды высокой нагрузки.

- Как обговорить права на интеллектуальную собственность с учетом того, что agile-разработка подразумевает активное взаимодействие клиента и поставщика услуг?

В соглашении об agile-разработке нужно уточнить, какая сторона владеет правами на интеллектуальную собственность в готовом продукте и имеет ли другая сторона право на его использование и создание производных работ. Если поставщик услуг непременно хочет обладать правами на интеллектуальную собственность, у клиента должна быть неограниченная лицензия на готовый продукт, и, возможно, стоит требовать ограничений на его использование разработчиком в той же отрасли, в которой специализируется клиент. Ситуация дополнительно усложняется, если какая-то из сторон предоставляет для проекта уже готовый код, – тогда может потребоваться отдельное согласование для каждого случая.

- Если клиент тратит слишком много усилий на составление соглашения об agile-разработке, может ему не стоит передавать такую разработку вовне?

Соглашение на agile-разработку требует от клиента отказаться от определенной доли контроля и некоторых контрактных инструментов, которые можно было бы применить, если проект собьется с плана. Среди сложностей – необходимость полагаться на доверие, чему скорее всего будут противиться юристы организации-заказчика. Если клиента не устраивают отсутствие контроля и вариативность денежных затрат, то ему для разработки критически важных приложений больше подойдет традиционный подход.

– Stephanie Overby. How to contract for outsourcing agile development. CIO. July 1, 2016

В соглашениях об уровне обслуживания (Service Level Agreement, SLA) регламентируется ожидаемый уровень результативности работы поставщика услуг. При аутсорсинге разработки и сопровождения приложений само по себе SLA успеха не гарантирует, но является одним из многих инструментов по управлению взаимоотношениями с поставщиком услуг.

Если обеспечить эффективное руководство разработкой и сопровождением, то грамотно составленные SLA становятся весьма действенными инструментами, регламентирующими стандарты качества работы поставщика услуг, подчеркивает Стивен Кирц, управляющий директор по трансформации бизнеса компании Pace Harmon, специализирующейся на консультациях в области аутсорсинга.

В SLA важно указать эффективный график разработки и сопровождения приложений – такой, который не просто хорошо смотрится на бумаге, но в первую очередь обеспечивает контролируемость поставщика и приносит реальные результаты бизнесу. В интервью CIO Magazine Кирц рассказал о базовых принципах действия SLA, об основных моделях аутсорсинга разработки и сопровождения и о том, как подготовить стратегическое содержание SLA, учитывающее трудности работы с поставщиками соответствующих услуг.

Насколько важны SLA для сделок разработки и сопровождения приложений?

Стоит иметь в виду, что SLA, хотя и помогают управлять предоставлением услуг, не заменяют стратегическое руководство отношениями с поставщиком в целом и не отменяют ответственности заказчика за установление архитектурных стандартов, политик и приоритетов.

Важно помнить, что SLA – это не только контролируемые показатели. В соглашении об уровне обслуживания также задаются протоколы измерения, планки производительности, приоритеты и процессы их изменения, а также процедуры добавления и исключения контролируемых показателей. Лучшие организации не ограничиваются регламентацией целевых показателей, пользуясь SLA как механизмом ведения диалога с поставщиком услуг о прошлых показателях производительности, а также о приоритетах и перспективах.

Важно, чтобы пользователи услуг аутсорсинга рассматривали SLA как «живой» документ, эволюционирующий на всем протяжении сотрудничества

Чтобы выполнять SLA, поставщик услуг добавляет необходимые ресурсы и инвестирует в более оптимальные процессы и инструменты, как того требует соглашение. Без верно составленных SLA качество предоставляемых ресурсов может быть заметно хуже, а оптимизации процессов не будет.

Какие ошибки совершают заказчики при составлении SLA для разработки и сопровождения приложений?

Полноценное SLA включает в себя контролируемые параметры с указанием желательных и опасно низких уровней и – как правило – протокол добавления и исключения показателей. Важно, чтобы пользователи услуг рассматривали SLA как «живой» документ, эволюционирующий на всем протяжении сотрудничества.

Максимальную пользу получат те, кто рассматривает SLA с точки зрения «траектории роста», используя как средство побуждения поставщика услуг к непрерывному улучшению качества предоставляемых услуг. Противоположного мнения придерживаются заказчики, считающие SLA статичным документом, служащим лишь механизмом возвращения средств. Такие заказчики не смогут добиться наивысшей продуктивности от поставщиков услуг и обеспечить качественное обслуживание своих внутренних клиентов.

Стивен Кирц, управляющий директор по трансформации бизнеса, Pace Harmon

На что заказчику нужно обращать внимание при подготовке содержания SLA для долгосрочного сотрудничества с учетом сложностей, характерных для разработки и сопровождения приложений?

В сфере разработки и сопровождения приложений продолжается отход от найма временных сотрудников к использованию управляемых услуг – схемы, ориентированной на результаты. В связи с этим появляется потребность и в соответствующем изменении контрольных параметров уровня обслуживания. Заказчикам нужно помнить об этом и согласовывать с поставщиками услуг готовность к выполнению постоянно растущих требований внутренних клиентов.

Во-первых, отмечу, что в случае найма временных сотрудников вполне реально использовать SLA. Процесс доукомплектации персонала поставщиком услуг можно и нужно регулировать с помощью SLA – например, надо контролировать время, уходящее на введение новых специалистов в курс дела, и текучку персонала.

Во-вторых, SLA для сопровождения сильно отличаются от соглашений для разработки. По каждому направлению деятельности должен быть отдельный набор SLA со своими диапазонами показателей и пулом кредитных баллов.

В-третьих, SLA должны постоянно совершенствоваться со временем. Заказчики нередко либо не включают положения, гарантирующие постоянное улучшение SLA, либо позволяют поставщику услуг применять сугубо статистический подход, допускающий лишь незначительные улучшения. Нужны отдельные пункты, обеспечивающие ежегодное улучшение SLA.

Какие виды эффективных SLA для разработки и сопровождения приложений можно порекомендовать ИТ-руководителю?

При схеме с временным наймом персонала обычно хорошо работают SLA, ориентированные на измеримые показатели, касающиеся ввода новых специалистов в курс дела, текучести, продуктивности и качества кода.

Для схемы управляемых услуг лучше подходят метрики, отражающие ожидаемые результаты: время выполнения заявок, продуктивность пакетных процессов, срок выпуска приложения и удовлетворенность заказчика.

Но важно понимать, что у большинства сделок есть элементы обеих схем – временный наем и управляемые услуги, – поэтому для SLA нужен соответствующий полный набор показателей.

Для разработки приложений, помимо стандартных условий, в SLA стоит предусмотреть пункты, регулирующие управление изменениями, соответствие функционала требованиям, а также то, за какое время до выпуска полностью устраняются дефекты.

Для сопровождения приложений в SLA стоит включить управление сроками анализа первопричин сбоев, а также ограничения на время выполнения синтетических транзакций и количество возобновленных заявок.

– Stephanie Overby. How to build better SLAs for more strategic applications outsourcing. CIO. August 21, 2015