1. Как было раньше
Современному HR сложно представить, каково приходилось его коллегам до наступления цифровой эры. Писали руками, считали на счетах или на арифмометре, данные хранили в полированном шкафу или в сейфе. Причем каменный век отступил не так давно: я сам помню начало своей карьеры в 2004 г, когда на отдел из 6 человек приходился 1 компьютер «Pentium II». Мы работали на нем по очереди, и ничего – справлялись и успевали. Как справлялись? Да очень просто: не было такого количества запросов, отработать которое нельзя было бы вручную.
Футурошоком для коллег стала покупка Oracle 11. Для консервативного и даже традиционалистского предприятия это был нонсенс. Мало того, что гигантские массивы данных за много лет пришлось вносить в систему руками. Пришлось еще овладевать технологией и, главное, жаргоном - далеко не всем было понятно с первого раза, что такое, например, «присвоить сущности идентификатор».
Начался эксперимент, разумеется, с КДП / C&B. Затем настала очередь обучения. Причем речь шла не о виртуализации процессов, а об учете результатов того, что сделано вручную. А до подбора и оценки за время моей работы дело так и не дошло.
(Дисклеймер для занудствующих коллег: я намеренно не разделяю термины «CRM» и «ERP», поскольку нормальный эйчар мыслит в терминах обслуживания внутренних клиентов, и с помощью любой АСУ решает клиентские вопросы)
Так вот, к чему это я? К тому, что вышеописанная история наглядно отражает логику HR-автоматизации в России. Сначала мы скрипим перьями, как чиновники в 18 веке, и группируем big data в амбарных книгах. Потом понимаем, что жизнь ушла далеко вперед, покупаем дорогую CRM и стремимся в кратчайший срок выжать из нее максимум. Начинаем с тех процессов, которые явно связаны с расходом бюджета и жесткой отчетностью, и маркируем процессы обучения, развития, подбора как «второстепенные». Только потом осознаем, что, вообще-то, развитие и подбор тоже коррелируют с затратами компании. А осознав, начинаем автоматизировать ВСЁ, бессмысленно и беспощадно!
Оно бы и ничего – в конце концов, к тому все придет. Проблема только в том, что человеческое сознание при отсутствии достаточного количества информации начинает демонизировать технический прогресс. Сон разума рождает примерно таких чудовищ:
«Чтобы выжить, мы должны разбираться в CRM не хуже программиста»
«Мы не разбираемся в CRM на уровне программиста. Поэтому нас всех уволят, а на наше место наберут молодых и умных».
Так или иначе, все фобии и фантазмы персонала сводятся к вышеперечисленным. И, хотя доля правды тут есть, паранойи в этих утверждениях куда больше. Что же делать работодателю, чтобы страхи эйчаров не стали «самосбывающимися пророчествами»?
2. Почему сопротивляются сотрудники и руководство: как привычка борется со здравым смыслом. Lotus, WebTutor, 1C, Oracle - чем именно они страшны
Давайте с этого места чуть подробнее. Итак, все сопротивляются, хотя и понимают – CRM – неизбежное добро, и нам с ним будет намного лучше. Нам важно понять, что сопротивление автоматизации на разных уровнях корпоративной иерархии имеет разную природу. К вышеописанным фобиям примешиваются и вполне рациональные мотивы.
С топами все более-менее ясно. Вариант первый: топ не сопротивляется, потому что как раз он и есть инициатор внедрения CRM. Вариант второй: топ сопротивляется изо всех сил, потому что автоматизация – это серьезные расходы, а он отвечает за бюджет.
На уровне миддл-менеджмента быстро зреет понимание того, что именно им предстоит быть «организаторами и вдохновителями» инноваций. (Впрочем, это справедливо и для любой другой инициативы). Среднее звено морально готовится получать пинки сверху и слушать глухое бурчание снизу. Если второе неизбежно, то первое еще можно предотвратить, поэтому каждый миддл заранее стремится подстелить соломки, резко сжимая сроки реализации проекта. Но назначить своим сотрудникам дедлайн на ближайший срок – это еще полдела. Надо ведь что-то делать и с подрядчиками, так? Достаточно трудно раздавать пинки представителям сторонней организации, которые действуют в рамках договорных сроков (которые, как правило, установил кто-то из топов). И тут уж каждый выкручивается, как может, применяя все мыслимые навыки влияния.
На самом деле, конечно, это я тут так долго все расписываю, а в миддлменеджерской голове похожие мысли проносятся за полсекунды. И мысли эти, в сочетании с пониманием меры ответственности (могут ведь и в расход пустить за срыв сроков / кривое ТЗ / перерасход бюджета) вызывают грусть, фрустрацию и обреченность.
Рядовые сотрудники. По определению против, за редким исключением. Совершенно справедливо они предвидят огромный объем дополнительной рутины, ломку привычных алгоритмов и сокращение отдельных позиций. И действительно – зачем передавать функции от человека к CRM, если это не сократит ОРЕХ-ы? Глухое бурчание, о котором мы упомянули выше, может перерасти в саботаж. Иногда саботируют не по злому умыслу, а потому что так удобнее.
Например, в некой организации сотрудники десятилетиями писали служебные записки, а контроль исполнительской дисциплины выполнял специальный страшный отдел (он может называться, например, «Бюро оперативного управления»). Но вот пришел 21 век, и компания внедрила Lotus! Что теперь делают сотрудники? Пишут служебные записки, подписывают их, сканируют и прикрепляют к карточке документа в Lotus. Бумажные версии аккуратно складывают в шкаф, как и раньше. А страшное Бюро оперативного управления (переименованное в отдел внутреннего аудита) по-прежнему контролирует исполнение, только теперь более продвинутым способом. Итого: сократились информации, улучшились коммуникационные механизмы, выросло количество рабочих операций по обслуживанию собственно документооборота. Народ первое время возмущается, потом навык использования АСУ уходит на подкорку и перестает критически оцениваться.
То же самое, только в более мягком варианте, с внедрением Oracle. Рядовой сотрудник долго продирается сквозь дубовый интерфейс, потом забивает вручную огромное количество данных. Если версия старая - вручную присваивает поставщикам и их продуктам коды. На выходе получаем упорядоченность и интегрированность процессов + возросшие трудозатраты на обслуживание АСУ.
Бесконечно можно апгрейдить и такую платформу, как WebTutor. Самый банальный уровень – нагрузить в систему дистанционных курсов (велкам, информационная безопасность, охрана труда), проинтегрировать платформу с кадровой АСУ, где проводятся КДПшные операции – и мы будем уверены, что каждый вновь принятый работник будет ознакомлен с необходимой инфой. Здесь не так много сложностей, но и профит минимальный. Гораздо интереснее, когда мы автоматизируем бюджетирование HR (кроме ФОТ), оценку, планирование обучения… В этом случае работы хватит всем: и идеологам проекта, и его исполнителям. Идеологи будут сутками переговариваться с разработчиками, а исполнители сутками же создавать объемистые справочники в системе (каталог провайдеров, каталог курсов, история обучения по каждому из сотрудников… и т.д.).
Особо продвинутые обязательно скажут вам о рисках, которые связаны с big data. Если коротко – вновь появившиеся в руках HR массивы данных ведут к соблазну вывести из них ложные зависимости. Один мой бывший коллега, который руководил таким проектом, однажды прикола ради сделал презентацию, где убедительно и красиво показывал совершенно абсурдные корреляции. Примерно такие: чем больше размер обуви продавца, тем выше выручка торговой точки. Количество незамужних продавщиц в филиале обратно пропорционально количеству установленных в торговых залах кофе-машин. Чем больше в филиале управляющих по имени Анастасия, тем выше средний балл тестирования персонала по филиалу.
Хорошо, что коллега был семи пядей во лбу и отнесся к своему открытию с юмором. Но ведь некоторые сгоряча могут принять это за чистую монету, так ведь? И тогда каждый сотрудник компании может столкнуться с безумными управленческими решениями: брать на работу только девушек с ногой 45 размера, желательно Анастасий, а, чтобы они раньше времени не ушли в декрет, убрать все кофе-машины из торговых залов. Одним словом, чтобы big data не морочили вам голову, понадобится выдержка, а главное – здравый смысл, основанный на практическом опыте.
3. Несколько простых действий, которые могут снизить накал страстей
Тут даже неудобно как-то писать очевидные вещи. Но придется. Во-первых, мало кто занимается «продажей» автоматизации персоналу. И тому, который будет непосредственно работать с CRM, и тому, который не будет. Вспомните, как внедряли SAP или Oracle в вашей компании? Я уверен, что так: в один прекрасный день вы ознакомились под расписку с приказом, который мог называться приблизительно «О внедрении в опытную эксплуатацию АСУ «ХХХХ». Там, конечно, были мероприятия, сроки и ответственные лица – но не было ни слова о том, что лично вы с этого будете иметь, так?
В идеале внутренний пиар проекта должен начаться с момента утверждения ТЗ. Раньше - не стоит: пока не утвердили ТЗ, вы сами не понимаете, к чему готовить сотрудников. Молчать, как рыба, до даты запуска системы в эксплуатацию – тоже не вариант (см выше). Итак:
- когда мы поняли, ЧТО именно будем внедрять – рассказываем об этом сотрудникам, и обязательно человеческим языком. Административно-канцелярский стиль вызывает зевоту, а айтишный жаргон – недоумение. Найдите человека, который может по-простому, на пальцах, внятно рассказать – зачем нужны все эти новшества, и как прекрасна станет жизнь после их внедрения (если такого человека в компании нет – у вас все плохо);
- ЦА, само собой, надо обучать. Круче всего сделать обучение в 2 этапа: 1) в период между утверждением ТЗ и запуском системы – на пальцах коротко рассказать будущим юзерам, что внедряем, когда и зачем 2) непосредственно перед запуском – рассказать, как все работает, и на какие кнопочки жать. Но только не сильно заранее – а то неподкрепленные практикой сведения быстро выветрятся. В том и в другом случае нам понадобится тот самый человек из предыдущего пункта – который владеет темой на джедайском уровне.
- во всех рассылках, письмах, ВКС, скайпах, митингах и т.п. – подчеркивайте поэтапность внедрения системы. Не все понимают, что в процессе опытной эксплуатации функционал CRM может существенно мутировать и стать гораздо более приятным для юзера. А значит, задача этого юзера – не прозевать этап допиливания и доведения CRM до ума, вовремя сказав свое веское слово.
4. Когда что-то идет не так: кто будет виноват и кто пострадает в первую очередь
Есть бесчисленное количество вариантов –почему что-то может пойти не так. Пропали данные, не пошла вовремя миграция между базами 1С, в интерфейсе обнаружились неработающие кнопочки, перекосило базу кандидатов…всему этому есть причина, а раз есть причина – есть и виновник. Как правило, конечный пользователь системы ничем не рискует, поскольку всегда может кивнуть на айтишника-эксплуатанта, а тот – на айтишника – разработчика. Другими словами, юзер пострадает, но виноват как раз не будет. Могут еще возникнуть вопросы к бетатестерам: это как же вы тестировали, что прозевали баги? Разработчик, он же идеолог, уже ни на кого кивать не может. Не заметил косяков в системе, не дисциплинировал вовремя подрядчиков, не принял превентивных мер – значит, виноват. Ну и, разумеется, отвечать будет директор по IT.
Правда, у архитекторов системы для объяснения непонятных ситуаций есть универсальная мантра: «Это штатная работа системы!». (После того, как юзеры успокоятся, всегда можно убедиться, так ли это, и если не так - что-то оперативно допилить).
5. Как запустить в эксплуатацию CRM, не нарушив Трудовой кодекс и 152-ФЗ. Два примера из практики (оба отрицательные)
Еще одна опасность, которая подкарауливает автоматизатора – некорректно построенная работа с персональными данными в CRM и риски нарушения ТК. Как правило, повышенную бдительность проявляет служба безопасности.
Случай первый. Компания «Х» внедряла автоматизированную ежегодную оценку. Схема была такой: из 1С в Web Tutor подтягиваются списки сотрудников. Каждый руководитель видит своих подчиненных, каждому подчиненному ставит по специальной шкале оценки, а сумма этих оценок конвертируется в особый коэффициент. На этот коэффициент – понижающий или повышающий – умножается сумма годового бонуса сотрудника. Казалось бы, всё прозрачно и все довольны. Но за пару недель до запуска оценки свое веское слово сказал начальник СБ (не зря за принципиальность и умение видеть неочевидные риски его прозвали в компании «Аццкий Сотона»).
СБ: Я не согласую вам запуск. Вы нарушаете федеральный закон. Вот, смотрите, статья 16 в 152-ФЗ: «Запрещается принятие на основании исключительно автоматизированной обработки персональных данных решений, порождающих юридические последствия в отношении субъекта персональных данных».
HR: Да мы же не на основе автоматизированной обработки! Оценки ведь люди ставят, а не система! Система – она только суммирует оценки и переводит в баллы. Все равно, что мы калькулятором бы воспользовались.
СБ: Нет. Вы используете АСУ. А потом кому-то из-за этого срежут премию…он жаловаться побежит. И кто будет за нарушение ФЗ отвечать?!
HR: Что нам делать?
СБ: Получать у каждого работника согласие в письменной форме - согласен, мол, на проведение оценки, включающей обработку моих персональных данных с использованием CRM.
В общем, пришлось нам так и сделать. Сбор «согласий в письменном виде» с нескольких тысяч работников стал действительно незабываемым квестом для HR, особенно с учетом сроков (2 недели).
Cлучай второй. В результате оценки нашелся-таки сотрудник, возмутившийся как раз тем самым: «Вы там наворотили непонятно чего в своей CRM, а я в итоге премию недополучил». И резонные возражения HR – оценку ставит не система, а ваш руководитель – понимания не нашли. Тем более, что руководитель занял позицию «Я все нормально ставил, а оно там что-то само перескочило!» Со стороны сотрудника была привлечена тяжелая артиллерия в виде личного юриста, со стороны компании – корпоративные юристы + HR. В ход пошли обвинения в дискриминации и нарушении принципа равенства оплаты труда. Надо сказать, что, хотя в тот раз HR вместе с идеологом-автоматизатором выиграли – сил и нервов было потрачено слишком много.
6. Как найти и сохранить разумный баланс между интересами HR, сотрудников, собственников и архитекторов CRM
Различия между интересами этих групп лежат на поверхности. Сотрудник и HR хотят, чтобы головной боли и рутины в автоматизируемом функционале не прибавилось, а убавилось. Архитектор хочет убедиться в том, что найденное решение было оптимальным и бюджет потрачен не зря – а, это, соответственно, позволит ему вписать красивую строчку в послужной список. Собственник ждет прозрачности аккумулированных данных и окупаемости внедренного продукта. И все вместе они хотят простой и очевидной вещи - работоспособности получившейся в итоге CRM. Даже удобство интерфейса поначалу не настолько важно. Как правило, конечный пользователь быстро привыкает к любым, даже самым замысловатым решениям – но если в CRM при этом будут регулярно виснуть хотя бы отдельные функции, то этот же самый конечный пользователь быстро организует «бунт против машин».
Так что там с разумным балансом? Его можно достичь единственным способом – заниматься апгрейдом CRM на всем протяжении ее существования. Как правило, все стейкхолдеры согласны с этим утверждением, но зачастую оно почему-то остается этаким благим намерением. Гораздо круче, когда владелец процесса целенаправленно и регулярно подводит все стороны к мыслям типа «Без нашей CRM не видать нам такой производительности труда», «Ручной труд в HR – чудовищная архаика», «Высокий уровень автоматизации в HR работает на наш HR-бренд» и т.п. Как он это делает – неважно: гораздо важнее отчетливое понимание того, что CRM максимально отвечает интересам бизнеса и каждого отдельного сотрудника на сегодняшнем этапе развития компании.
В общем, дерзай, дорогой автоматизатор! Помни, что твой труд почетен, нужен компании и стране, а еще очень неплохо оплачивается. Заботься о будущем сокращении костов, дружи с СБ и юристами и не забывай пиарить себя. А главное – днем и ночью будь готов прийти на помощь простым юзерам системы, ведь не будь их – не было бы и автоматизации :)
Читайте также:
Как эволюционировал рекрутер: от «тетки в окошке» до маркетолога
Быть умным придется все равно: топ-профессии грядущих 10 лет