SLA

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

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

Подготовка к росту мобильности сотрудников

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

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

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

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

Распространенной альтернативой созданию резервных копий на мобильных устройствах является централизованная система коммуникаций и совместной работы, такая как Office 365 или G-Suite. Сотрудников необходимо обучить их оптимальному использованию, с тем чтобы интеллектуальная собственность хранилась на сетевых корпоративных ресурсах, а не только на самих ноутбуках.

Защита данных SaaS-приложений

Чем больше вы полагаетесь на SaaS-приложения наподобие Office 365 или G-Suite, тем выше потребность в том, чтобы хранимые там данные были надежно защищены. Внимательно изучите соглашение об уровне обслуживания, предоставляемое каждым сервис-провайдером, с которым вы работаете, и выясните, обеспечивают они резервное копирование и восстановление данных. Большинство SaaS-провайдеров ничего подобного не обещает.

Не путайте возможность восстановления удаленных писем в самом сервисе электронной почты с реальными процедурами резервного копирования и восстановления данных (они должны соответствовать правилу 3-2-1, когда три резервные копии хранятся на двух различных носителях, один из которых физически находится где-то в другом месте). Как правило, при реализации такого функционала используется система версионирования, а не резервное копирование. Если что-то случится с вашей учетной записью, большинство SaaS-провайдеров не смогут восстановить ее, а поскольку в SLA ничего об этом не сказано, они не будут даже пытаться.

Облачное резервное копирование и аварийное восстановление

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

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

Без паники

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

Соглашения об уровне сервиса (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

Западные эксперты приходят к выводу, что традиционный подход к выбору вендора требует пересмотра в случае, когда речь идет о поставщике SaaS-решений (см. «Как выбрать провайдера SaaS», «Директор ИС» 09/2017). В какой степени эта точка зрения находит отражение в практике российского бизнеса? И с какими трудностями приходится сталкиваться тем, кто делает выбор в пользу облаков?

Проблема номер один: дефицит доверия

Сергей Папоян, эксперт Союза ИТ-директоров: «Выгода от использования облачных сервисов не всегда очевидна, так что многие компании предпочитают “купить один раз и забыть”»

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

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

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

Рынок действительно повзрослел

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

Дмитрий Пшиченко, директор департамента разработки и внедрения информационных систем компании «ЛокоТех»: «Мы стали более тщательно рассматривать поставщика с точки зрения того, действительно ли он предлагает SaaS-решение и насколько оно комплексное»

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

По мнению Антона Нагова, руководителя направления развития бизнеса департамента облачных технологий группы компаний Softline, изменение подхода к оценке поставщиков обусловлено взрослением рынка. Во-первых, сокращается цикл сделки: заказчики теперь значительно быстрее стали принимать решение о работе с конкретным поставщиком сервисов. Во-вторых, большинство заказчиков уже не хотят, чтобы на них экспериментировали: они желают получить готовый и полностью функциональный сервис через час после подписания договора или после перечисления денег на счет провайдера. Это возможно только при условии, что сервис у провайдера уже развернут в продуктивную эксплуатацию и технически поддерживается. И в-третьих, конкуренция за заказчика между провайдерами находит прямое отражение в соглашении об уровне обслуживания (service level agreement, SLA). Заказчик желает видеть понятный ему документ, который регламентирует, кто и за что отвечает в рамках договорных отношений между провайдером и клиентом, уточняет Нагов.

Совет: уделите внимание деталям

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

Вадим Горбунов, заместитель гендиректора по ИТ аптечной сети «Ригла»: «Мы всегда оговариваем права собственности на информацию – они должны быть нашими»

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

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

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

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

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

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

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

Эти нелегкие облака

Говоря о сложностях бизнеса при работе с облаками, Пшиченко привел в пример SaaS-систему Help Desk, которая в «ЛокоТех» функционирует в настоящее время: «У нас встал вопрос создания дополнительных отчетов по соблюдению SLA, но, из-за того что решение облачное и в нем, кроме нас, работают другие клиенты, мы фактически лишены возможности самостоятельно создавать отчеты или определять метрики по конкретным KPI. В итоге нам несколько недель пришлось ждать технического перерыва в работе SaaS-системы, чтобы внедрить в продуктивную систему Help Desk нужные нам виды отчетов».

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

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

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

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

В соглашениях об уровне обслуживания (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