ВСТАВКА 1. Основные вопросы по SLA – соглашение об уровне услуг

Что это такое? Важным моментом создания ОЦО является определение SLA (с англ. service-level agreement – соглашение об уровне предоставления услуг) по всем услугам.

Главное, не путать SLA с OLA (operational level agreement – соглашение об уровне операционного исполнения).

SLA – это то, что выходит непосредственно на внутренних клиентов (заказчиков услуги).

OLA – это то, что функционирует внутри HR (вкл. как работу HR ради\для HR, так и работу HR для госрегуляторов).

Согласование SLA. SLA обязательно согласовываются с внутренним клиентом. Методы согласования могут быть разными – групповая или индивидуальная встреча, е-мейл, телефон, видеоконференция… Главное – внутренний клиент должен (а) понять какой уровень услуги ему ожидать; (б) подтвердить, что его данный уровень устраивает.

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

В общем, главное прозрачность и функциональность, а не наличие подписанной бумаги (что вообще нефункционально и неудобно), которую в итоге если не потеряют, то долго искать будут (если вообще о ней не забудут).

Когда разрабатывать SLA. Многие организации «погрязают» в разработке SLA на этапе проектирования (дизайна) операционной модели ОЦО или всей бизнес-ориентированный HR-модели. На самом деле детально каждый SLA разрабатывается потом, уже при внедрении.

Но тем не менее на момент проектирования\дизайна модели важным является разработка ПРОЦЕССА ПРИНЯТИЯ РЕШЕНИЙ (об этом мы поговорим далее в книге, когда будем говорить об оргдизайне) «Управление уровнем сервиса», в котором отображаются задействованные стороны и их полномочия\решения в рамках процесса. В этом процессе обязательно отразить важные вещи: как пересматриваются SLA (в т.ч. постоянное улучшение), кто может инициировать пересмотр SLA, кем решаются несогласия и конфликты по выполнению SLA, у какого «кубика» (оргэлемента) какие полномочия по SLA и т. д.

Кто отвечает за SLA в HR. За выполнение SLA отвечают операционисты – в нашем случае ОЦО, а также People Partners. Но они просто выполняют так как положено и задано процессом.

Непосредственно за сам SLA отвечают СоЕ (ЦЭ, Центры Экспертизы), так как они отвечают за проектирование процессов и их эффективность в соответствии требованиям организации.

Многие компании «ведутся» на «единую точку ответственности» (старые добрые вертикали) – и считают, что раз ОЦО выполняет SLA, пусть сам их и проектирует (описывает, согласовывает с клиентами и подписывает). Нет. За процессы отвечают ЦЭ (СоЕ) – и их задача решить вопрос с SLA по своим процессам.

Объем SLA. Услышав об SLA, который нужно подписать с внутренними клиентами, многие представляют себе огромный талмуд (не менее объема серьезного договора на н-ный десяток страниц). На самом деле SLA на один процесс – это чаще всего помещается в одну строчку. Все SLA HR можно вместить на 1—2 страницы максимум (то, что я видел обычно вмещается до 30 строк).

Пример внешнего вида «большого» HR SLA условно в три строки (рис.3.11):

Рис.3.11. Прмер «большого» по объему SLA

В каком формате удобнее всего готовить SLA. Таблица в Excel. Формат см. выше.

Какие SLA у HRBP и СоЕ? Сами подумайте, есть ли у них вообще SLA. Ну и приложенную вставку-кейс о том, как разрабатывали в одной компании SLA почитайте.

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

Может быть такое, что SLA не нужны? Если у Вас компания-монополист (или в отрасли олигополия) и в компании исторически процветает «BSF-центрическая модель мира» в которой исторически «кадры» на «вершине ее пищевой цепи» и никаких изменений не планируется – то можете обходиться и без SLA. Или «для красоты» нарисуйте что-то похожее на SLA, чтобы хотя бы во внешний рынок транслировать «у нас тоже есть и мы работаем по SLA».

ВСТАВКА 2. Разработка SLA в одной компании

Это история из моего опыта. Работая над проектом для технической функции, я столкнулся с разработкой HR-функцией своих SLA.

В одной компании в HR начали внедрять ОЦО. Не всю бизнес-ориентированную HR-модель, а только ОЦО (как возможность оптимизации затрат) и HR бизнес-партнеров (просто как «лучшую практику»). Стояла задача разработать SLA: и HR-функция расписала все, чем занимается – вплоть до сдачи каждого типа госотчетности.

А в придачу директор по персоналу под давлением директора будущего ОЦО еще и остальные подразделения HR дирекции заставила писать их SLA, а также и HR-бизнес-партнеров (для всех же, как по-другому!).

Получился Excel-файл под 250 строк…. Потом его «вывалили» клиентам с припиской «если есть комментарии – напишите до такого-то числа».

Клиенты «откровенно обалдели» от файла. Большинство даже читать не стали, а те, кто попытались – утонули в HR-внутрянке и бросили это дело…

Мне этот файл показал сначала директор производственного департамента, как «прикол, чем наши кадры заняты». А потом еще несколько производственников о нем язвительно рассказали.

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

Но вот только не было дано единого понимания (даже внутри самого HR было непринятие и недовольство от проекта). Не было явного собственника и заказчика проекта… У проекта не было даже проектного менеджера: довольствовались координатором, поскольку задача показалась легкой. В общем, налицо было нарушение почти всех заповедей управления проектами преобразований (я их упомяну в конце книги).

Закончилось это все тем, что через три года этот проект весь перезапускали только с более методологическим подходом и выделенным менеджером проекта…

А конкретно в HR все после SLA и создания ОЦО погрязли в операционке… И «королевой операционки» стала директор ОЦО, которая их все взяла под контроль и фактически монополизировала поставку информации для HR-директора, кто в дирекции «выполняет\не выполняет SLA». И перефокусировала его внимание на то, что это важнее всего – не зря так долго и все вместе эти SLA сочиняли… Да, именно та директор ОЦО, которая раннее требовала, чтобы вся HR-дирекция (вкл. бизнес-партнеров) написала свои SLA…

ВСТАВКА 3. Кейс «Проникновение ОЦО»

В одной компании стартовал проект создания мультифункционального ОЦО – правление компании решило реализовать рекомендации консультантов.

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

Закончилось тем, что ИТ сразу вернулись «на Родину» как «не поддающаяся централизации»! Обсуждать не будем, так как нас не ИТ и финансы интересуют, в фокусе нашего внимания HR функция.

HR еще до завершения проекта распался на 2 отдельно функционирующих ОЦО:

· «кадрово-зарплатно-оргструктурный»

· рекрутинговый

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

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

Во-вторых, потому что с одной стороны руководитель ОЦО не понимал кухню рекрутинга и развития – он был выходец из кадрового учета. А с другой стороны и у руководителя будущего СоЕ (ЦЭ) практик работы с людьми был «некомфорт» – она комфортнее и увереннее чувствовала себя с операционкой и большой структурой, чем управлять всего парой-тройкой экспертов с высокоинтеллектуальными задачами.

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

Механизмы реализации: ИТ-система (HRIS) и Аутсорсинг

Сразу после ОЦО скажу не об элементах, а о двух важных механизмах реализации.

Главными механизмами реализации рентабельного ОЦО, да и позволяющими достичь стратегических результатов всей HR-модели являются:

· ИТ система, на которой автоматизируются HR-процессы называемая HRIS (от англ. HR Informational System),

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

О этих двух вещах скажу немного важных слов.

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

При внедрении HR-модели важно чтобы ИТ-система с одной автоматизировала рутинные операции и не требовала операторов ввода данных (армии «кнопкодавов, кликеров и нажимателей» на кнопки). А с другой стороны (ВНИМАНИЕ!) имела помимо ролей для HR-администраторов порталы самообслуживания сотрудника и руководителей (на англ. ESS и MSS).

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

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

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

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

Но главный момент аутсорсинга – это считать ТСО (с англ. Total cost of ownership) или ОСВ (на нашем языке Общая Стоимость Владения). Т.е., учитывать все затраты на процесс, а не только, допустим, зарплату рекрутера или кадровика. Часто именно из-за этого момента аутсорсинг некорректно сравнивают – и в итоге никогда на него не переходят, потому что «куда ни ткнись так получается своими силами дешевле».