Зачем нужна карта компетенций

Рано или поздно любая команда внедрения 1С упирается в вопросы, на которые не хочется отвечать вслух. Кого повышать и за что? Почему один аналитик стоит вдвое дороже другого с точно такой же строчкой в трудовой? Кого из свободных коллег можно смело ставить на ЗУП, а кого только на бухгалтерию и под присмотром? И что сказать джуну, который третий раз за квартал спрашивает, чего ему не хватает для роста, кроме уклончивого «ну, опыта»?

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

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

Сколько нужно грейдов

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

• Младшие сотрудники: работают под контролем наставника, берут отдельные задачи вроде документирования и тест-кейсов, стараются ничего не удалить в проде и не положить базу
• Основные сотрудники: самостоятельно ведут обследование и тестирование, пишут ТЗ по типовым доработкам
• Опытные сотрудники: закрывают полный цикл аналитики по функциональному блоку, берут сложные доработки и интеграции, помогают расти младшим
• Руководители группы аналитиков: то же, что и в предыдущем пункте, но также руководят командой аналитиков на проекте
• Архитекторы: проектируют функциональную архитектуру решения и принимают ключевые решения

Когда ступеней больше трёх, сотрудник видит свой карьерный путь: шаги между уровнями достаточно короткие, чтобы рост ощущался. Но дробить слишком мелко тоже не стоит, иначе каждое небольшое достижение станет поводом для нового грейда.

Компетенции по этапам проекта

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

Пресейл → обследование → моделирование → проектирование → разработка → приёмо-сдаточные испытания → ОПЭ (Опытно-промышленная эксплуатация) → поддержка промышленной эксплуатации

Поверх этой линейки лежит сквозной блок: коммуникации, наставничество, методология и управление аналитикой, управление рисками, сертификаты и soft skills. Именно он сильнее всего разводит старшие уровни. Опытный сотрудник и архитектор могут одинаково уверенно писать ТЗ, но расходятся в наставничестве, координации команды и умении объяснить заказчику, почему «сделать как в Excel» — это не архитектура.

Отдельная история — дробность. Если делить каждый этап на десяток пунктов, получится полотно на 80+ строк, которое никто не захочет заполнять, включая авторов. Лучше оставить по несколько компетенций на этап и объединить родственные, например «обучение и инструкции», «тестирование и тест-кейсы», «методология и управление аналитикой». Карта станет обозримой и при этом не потеряет смысла.

Не унифицировать оценку

Здесь кроется решение, ради которого все и затевалось.

Соблазн ввести единую шкалу велик: одна легенда на весь файл, заполняется в два счета. Что может пойти не так? Оказалось, много что. «Эксперт в проведении интервью» и «эксперт в проектировании интеграций» — вещи сильно разные, и общая формулировка их не схватывает. Оценки становятся размытыми, а споры на аттестации тянутся неделями и заканчиваются ничем.

Поэтому под каждый критерий стоит расписать собственную шкалу. Например, для компетенции «Gap-анализ и функциональная карта решения» опорные уровни могут выглядеть так:

• 1 — находит разрывы в одном блоке и предлагает типовую реализацию
• 2 — сравнивает варианты в нескольких подсистемах по трудозатратам и рискам
• 3 — принимает решение по итоговой функциональной архитектуре

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

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

Строгая лестница: старший не бывает слабее младшего

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

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

Базовые знания по видам учета отдельно

Аналитик 1С без понимания предметной области — это, при всем уважении, оператор ПК с амбициями. Поэтому базовые знания по видам учета лучше вынести в отдельный блок и сгруппировать, например так:

• Регламентированный учет: бухгалтерский (РСБУ), налоговый (прибыль, НДС), основные средства
• Финансовый и управленческий контур: управленческий учет, МСФО, бюджетирование, казначейство
• Оперативный контур: закупки, продажи, склад и запасы, производство и себестоимость, взаиморасчеты
• Кадры и зарплата: кадровый учет, расчет заработной платы

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

Знание продуктов — отдельная система для стаффинга

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

Поэтому продукты (ERP, КА, БП, ЗУП и ЗУП КОРП, УТ, Документооборот, Управление холдингом, ERP.УХ, 1С:Аналитика) удобнее оценивать отдельно, через самооценку, которую сотрудник заполняет сам. В ее основе не абстрактная «экспертность» (ее каждый оценивает подозрительно высоко), а уровни подтверждения знаний — от простого знакомства с блоком до подтверждённого проектного опыта на проектах компании.

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

Наставничество, сертификаты и soft skills

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

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

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

Как это работает на практике

Аттестация сводится к заполнению матрицы: по каждой компетенции руководитель и сотрудник сверяют реальные кейсы с рубрикой и ставят балл. Собранный воедино профиль показывает, дотягивает ли человек до целевого грейда и что именно проседает. У новичка вместо туманного «расти дальше» появляется внятный план: чтобы вырасти, нужно выйти на нужный уровень вот по этим пяти компетенциям.

Для стаффинга используется самооценка продуктов: нужен человек на проект по ЗУП КОРП с настоящим опытом — отбираем тех, у кого в нужных блоках есть подтверждённый проектный опыт, а не тех, кто громче всех молчал на планерке.

Где легко набить шишки

• Единая шкала не работает. Пока не распишешь рубрику под каждый критерий, оценки останутся вкусовыми. На старте это дороже по времени, но окупается на каждой аттестации
• Слишком большое число компетенций делает карту непригодной. Список из восьмидесяти пунктов никто не заполнит до конца, даже его автор. Лучше сокращать список и объединять близкие компетенции
• Грейд и знание продуктов нужно оценивать отдельно, потому что это разные измерения. Если их смешать, узкие специалисты получат заниженные оценки, а подбирать людей на проекты станет сложнее
• Без проверки монотонности лестница грейдов теряет смысл. Нужно убедиться, что ни по одной компетенции старший грейд не оценивается ниже младшего, иначе итоговые баллы перестанут отражать реальный уровень
• Самооценка без подтверждения мало что говорит об уровне человека. Когда баллы привязаны к проектному опыту и резюме, картина становится достоверной

Итог

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

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

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

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

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