Только в блоге SLR: ИТ-услуги, что это и как разобраться, за 10 минут

Давно не писал ничего научного. Поправляю. Иллюстрация поясняет дальнейшие выкладки: традиционная ИТ-служба, аутсорсинг инфраструктуры (IaaS), аутсорсинг платформ (PaaS), аутсорсинг софта (SaaS). Итак приступим к короткому анализу основных характеристик каждой модели.

1. Традиционная служба ИТ.

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

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

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

2. Инфраструктура как услуга (IaaS).

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

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

Риски, связанные с работой инфраструктуры, соответственно, регулируются договорами с внешней ИТ-организацией через SLA (Service Layer Agreement), которые очень часто и в этом случае забывают включать в состав договора и, как следствие, предприятие-заказчик в итоге несет риски предприятия-поставщика, это является особенностью модели. SLA позволяет урегулировать риски и распределить зоны ответственности при сопровождении, такое приложение обязательно должно быть в составе договора, иначе ценность модели начинает приближаться к нулю, так как один сбой в хранилище данных может перечеркнуть всю экономию на железе/виртуализации и их поддержке. Модель характерна для сектора Corp (здесь нужно иметь ввиду предприятия размером более 500 человек и эксплуатирующие формально бизнес-процессы). Впрочем, это не всегда так, в силу разных причин, даже в этом секторе встречаются другие схемы работы, снижающие ценность применения ИТ.

3. Платформа, как услуга (PaaS).

В этой модели, к контейнерам добавляются платформы (Middleware) - это то, что позволяет устанавливать и запускать различный функционал и приложения, например, специализированные среды web-приложений, такие, как современные средства 1C. Конечные программные средства сопровождает собственный ИТ-отдел предприятия.

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

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

4. Софт, как услуга (SaaS).

Здесь не совсем точно, так как модель включает в себя и данные (Data). Подразумеваются и данные и метаданные и синтезированная информация, используемая непосредственно в бизнес-процессах предприятия.

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

Риски перекладываются на внешние организации, за исключением рисков, связанных с проектированием функционала. Здесь важно четко понимать уровень зрелости процессной системы предприятия (ISO 9000 и т.п.), которая и позволяет более четко проектировать ИТ-функционал и требования к качеству ИТ-поддержки. Здесь же, а не ранее, как это представлятеся многим, возникает такое понятие, как KPI. KPI могут существовать только строго в рамках формальной процессной системы.

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