Согласно отчету Gartner, который был выпущен в июне нынешнего года и посвящен будущему офисной печати, в течение последующих 2—5 лет рынок услуг MPS (Managed Print Services), пройдя период устранения недостатков, выйдет на стадию продуктивности, обещающую значительный рост числа соответствующих контрактов. Уже сейчас можно констатировать повышение интереса к этой категории услуг, в том числе и в России. Вместе с тем речь идет о нишевом рынке, где действует ограниченное количество игроков — крупных вендоров, включая Canon, а также локальных системных интеграторов, а круг решаемых в рамках MPS-контрактов задач, как правило, носит вспомогательный характер по отношению к критически важным ИТ-системам заказчика. Такая ситуация в ряде случаев провоцирует упрощенный подход российских заказчиков к реализации MPS-проекта, что ставит под сомнение его конечные результаты. Между тем, согласно имеющемуся опыту, вхождение крупной компании в MPS-контракт занимает от одного до двух лет, и подходить к нему необходимо как к любому другому проекту управления ИТ-услугами. Именно поэтому, реализуя MPS-проекты, Canon рекомендует своим заказчикам неуклонно следовать базовым рекомендациям ITIL.

Ошибки на старте

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

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

Опираясь на ITIL

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

Обследование. Без этого этапа невозможно в принципе с достаточной точностью оценить параметры MPS-контракта, в том числе его бюджет. В его ходе предполагается сбор данных (с помощью технических средств) о количестве используемых у заказчика устройств и реальных объемах печати, а также качественная оценка ситуации и формулирование ожиданий пользователей, которые должны быть отражены во внутреннем SLA ИТ-службы заказчика и затем транслированы в SLA на MPS-услуги. В дальнейшем это позволит четко выстроить взаимоотношения в цепочке “пользователь — ИТ-служба — поставщик услуг”.

В зависимости от ситуации этап обследования может выполняться с разной глубиной, в связи с чем в перечне услуг Canon для этого предусмотрены три опции: Basic Print Assessment (общее ознакомление в случае контракта с небольшой компанией), Print and Device Audit (сбор данных с помощью технических средств), Print TCO Audit and Assessment Service (расчет совокупной стоимости владения печатным парком). Результаты анализа, как правило, представляются в виде отчета.

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

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

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

В проекте MPS заказчик часть своего бизнеса выносит на сторону вендора, владеющего по сути инфраструктурой, в том числе той, которую он сам произвел. Canon, например, имеет возможность разрабатывать все инструменты для предоставления услуг печати в совокупности: и оборудование, и ПО, и сервисы как цементирующее звено. Понятно, что в таком случае качество решения оказывается выше, а его цена — ниже. При этом сервисные подразделения компании имеют прямой доступ к ее новым разработкам (R&D) и на стадии проектирования решения могут закладывать в него функционал, который еще не анонсирован, но появится в ближайшее время, или размещать заказ на кастомизацию продукта (например, системы управления печатью).

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

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

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

При реализации MPS-контракта главное на этапе внедрения — обеспечение гладкого перехода персонала к работе в новых условиях, подготовка которого должна начинаться еще на стадии проектирования решения. Типовое заблуждение выглядит так: если ПО установлено и оборудование запущено, значит, дело сделано. В действительности же этап не может быть закрыт, пока не собрана статистика и не оценены первичные результаты. И здесь просто необходимо работать с пользователями сервиса. Если на стадии перехода просто поставить их перед фактом, это неизбежно вызывает негатив. В этом случае любая ошибка или шероховатость в процессе внедрения обретает масштаб серьезной проблемы. Поэтому готовить пользователей к работе в новых условиях нужно заблаговременно. Если у заказчика такого опыта нет, Canon рекомендует воспользоваться соответствующей услугой вендора. Предварительное обучение пользователей, вовлечение их в процесс изменений, подготовка “чемпионов” из числа социально активных работников дает помимо прочего интересный эффект в виде повышения качества использования техники. Нормализовать ситуацию во многом помогает и наличие внутреннего SLA, на который ИТ-служба может опереться в конфликтных случаях.

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

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

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

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

Подводя итог

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

НА ПРАВАХ РЕКЛАМЫ