Матрица компетенций аналитика 1С

Меня зовут Анна Бирюкова, я работаю руководителем аналитиков 1С в проектном отделе компании ФТО.

В сферу 1С я попала 15 лет назад, после окончания математического факультета Омского университета – начинала с разработчика на 7.7, затем была аналитиком на 7.7.

10 лет назад пришла в компанию ФТО и начала работать как аналитик с восьмеркой. Доросла до руководителя проектов. Сейчас руковожу аналитиками в проектном отделе компании ФТО.

Сегодня я хочу поделиться с вами нашим опытом разработки и использования системы оценки компетенции аналитика 1С. Это будет не доклад с позиции – смотрите, какую мы классную систему придумали, используйте ее. Скорее, это будет просто история про то, что мы хотели сделать, и что в итоге у нас получилось, а что – нет. Думаю, кому-то будет полезно и интересно.

О компании

Пару слов о компании ФТО, чтобы у вас сложилось понимание о нашей деятельности.

• Количество сотрудников у нас порядка 300.

• Мы располагаемся в 3 филиалах, плюс у нас есть удаленные сотрудники.

• Мы занимаемся крупными внедрениями, в основном ERP-систем – на базе 1С и BI.

• Аналитиков 1С в нашей компании порядка 100 человек. Это три отдела – проекты, поддержка и группа развития. Из них в проектах внедрения работает порядка 30 человек.

• Аналитики работают в командах вместе с разработчиками, они не занимаются разработкой, не занимаются программированием, могут читать несложный код, понимают архитектуру 1С, пользуются консолями запросов и т.д.

• Периодически мы работаем с вузами, запускаем стажерские программы, берем на работу выпускников.

Сегодня поговорим про финансовую мотивацию аналитиков 1С, а именно про матрицу компетенций, которую мы в 2020 году разработали и начали использовать.

Прежняя система мотивации

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

До 2020 года и частично еще в 2020 году у нас была система грейдов из 8 уровней, и наши аналитики росли по этой системе только вертикально.

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

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

• Проектный опыт – на каждом грейде у нас были свои требования к количеству пройденных проектов. Например:

  • условием перехода на второй грейд являлся успешный опыт в любом проекте по полному циклу (любой проект означает проект любого размера, любой длительности с любыми бизнес-процессами);

  • для перехода на третий грейд необходимо было пройти проект среднего уровня и выше (у нас были разработаны свои критерии, что такое средний и что такое крупный проект);

  • а чтобы перейти на четвертый грейд, нужно было пройти два проекта и т.д.

• Знание предметной области или бизнес-процессов - у нас были перечислены бизнес-процессы, и для перехода на каждый уровень необходимо было набрать определенное количество внедренных процессов. Например:

  • аналитик среднего уровня должен знать один любой бизнес-процесс;

  • аналитик следующего уровня должен знать как минимум два бизнес-процесса и т.д.

• Знание функциональности и архитектуры систем 1С.

• Технические навыки – качество написания ТЗ для разработчика, умение оценить трудозатраты с попаданием в оценку и т.д.

• Взаимодействие по всем фронтам – как с заказчиком, так и внутри проектной команды, с другими аналитиками, с разработчиком, со смежными отделами (обычно это отдел поддержки, куда мы проект передаем после внедрения).

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

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

• Для перехода с грейда на грейд нужно было получить опыт работы в проекте по полному циклу – от интервью до активной поддержки после запуска. Но у нас бывают ситуации, что аналитика привлекают только на часть проекта, на какой-то из этапов проекта. Это тоже был минус в этой системе.

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

• И, наконец, в системе присутствовала некоторая абстрактность и субъективность. В ней использовались такие понятия как «детальное ТЗ», «скорость оставляет желать лучшего», «успешно работает на проекте». Не очень было понятно, как это все оценивать, поэтому приходилось оценивать и учитывать профессиональный путь каждого аналитика, учитывать условия, в которых он работал, ставить индивидуальные цели и немного отходить от формальных требований этой системы.

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

Принципы новой системы мотивации

Мы решили, что новая система должна быть:

• Прозрачной – каждый сотрудник должен четко понимать, что ему нужно сделать, чтобы увеличить свой доход.

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

• Система должна быть справедливой.

• И она должна быть достижимой, чтобы каждый мог развивать интересные и перспективные для него компетенции.

• Новая система должна стимулировать на развитие.

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

• Зарплата в системе должна соответствовать рынку.

• Еще одна задача – система должна быть единой для всех отделов компании. Напомню, их у нас три.

В итоге в 2020 году у нас был собран экспертный совет из руководителей отделов, и мы приступили к решению этой задачи.

Какие компетенции и навыки решили оценивать

Мы поняли, что новая система грейдов должна быть древовидной.

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

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

В итоге мы видим развитие этого аналитика, его дерево со множеством ветвей, но это по-прежнему аналитик.

Мы выделили четыре главных направления, по которым в принципе и раньше оценивали аналитиков по компетенциям.

И расписали для этих направлений те компетенции, которые, как нам показалось, важны для аналитика. У нас получилось вот такое дерево, здесь в качестве направлений можно выделить:

• знания по предметной области – по бизнес-процессам;

• знания по конфигурациям 1С;

• технические навыки – сюда относится качество написания документации, концептуальный и функциональный дизайны, техзадания, тестовый сценарий, инструкции, попадание в оценку по срокам и прочее;

• и еще софт-скилы – то, что очень важно для аналитиков: взаимодействие с клиентом, внутри команды, со смежными отделами, навыки устной и письменной речи, самостоятельность, ответственность и т.д.

В итоге у нас получилось 37 навыков.

Для удобства работы с новой системой грейдов мы переложили ее в более понятный и удобный вариант – Excel, но сохранили древовидный вид, с группировками. На картинке вы можете видеть это дерево – здесь раскрыта одна из веток, «Навык работы с конфигурацией».

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

Поскольку очевидно, что не все навыки равнозначны, мы решили за разные навыки давать разное количество баллов.

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

• например, за работу с ERP мы назначили 8 баллов – это максимальное количество баллов, потому что на данный момент эта система самая перспективная и распространенная;

• за «Управление торговлей» мы поставили 2 балла;

• за ЗУП – 4 балла и т.д.

Так мы оценили знания по каждой из конфигураций и другие компетенции.

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

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

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

Например, по ERP максимальное количество баллов – 8. Эти баллы складываются из нескольких блоков:

• базовый уровень;

• продвинутый уровень;

• производство;

• казначейство;

• планирование;

• бюджетирование;

• НДС, налоги и т.д.

То есть мы расписали эти 8 баллов по подбаллам.

Или, например, по системе ЗУП максимально возможное количество баллов – 4. Они складываются из нескольких подбаллов:

• 0,5 балла можно получить за базовое умение оформлять кадровые документы;

• 0,8 балла – за умение работать с видами учета рабочего времени, графиками и табелями;

• 0,5 баллов – за умение работать с зарплатой по простой схеме (оклады, налоги, выплаты);

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

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

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

Эти баллы мы проставляем вместе с аналитиком на встрече «один на один», обсуждаем, на какие проекты он в ближайшее время идет, на каких проектах он сейчас работает.

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

Критерии для оценки навыков и компетенций

Мы решили, что для подтверждения навыков в предметной области нужно иметь:

• либо успешный опыт участия в проекте;

• либо опыт работы в поддержке от полугода.

Для подтверждения знаний по определенной конфигурации 1С сотруднику необходимо иметь:

• либо успешный опыт участия в проекте;

• либо опыт работы в поддержке, но уже от 1 года – мы решили, что шести месяцев для полноценного изучения конфигурации мало;

• и добавили еще третий вариант – подготовка и сдача сертификата «Специалист-консультант по конфигурации». Этот пункт мы добавили для тех аналитиков, кто хочет развиваться, повышать свой профессиональный уровень вне зависимости от проекта, на который мы его поставили.

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

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

Например, среди технических навыков у нас есть «Попадание в оценку» и «Соблюдение сроков по задачам проекта». Хочу немного подробнее рассказать, как мы оцениваем эти показатели.

Мы ведем проекты в отдельной корпоративной системе Redmine. Эта система позволяет вести проект позадачно, здесь аналитики у нас разносят фактические часы, и здесь можно указывать:

• плановые показатели – такие как оценка трудозатрат по тестированию, на написание тех. задания, на дизайн и т.д. (это видно на нижнем скриншоте);

• а справа на скриншоте можно видеть задачу, в которой указаны показатели по плану и фактические показатели по датам – это дата начала и окончания разработки, плановое и фактические начало/окончание теста и т.д.

Таким образом, система позволяет собирать план-факт. Особенно это легко делается на этапе билда и позволяет оценить каждую компетенцию.

Как бы нам ни хотелось сделать полностью объективную систему, без субъективных оценок обойтись не получилось.

Например, в тех же технических компетенциях есть качество написания документации. У нас в каждом среднем или крупном проекте участвует функциональный координатор (или архитектор проекта), который производит обязательное рецензирование написанной документации – дизайнов, ТЗ, скриптов и т.д. И, прежде чем отправлять их клиенту либо отправлять в разработку, функциональный координатор их вычитывает. В данной компетенции мы решили, что будет три уровня:

• 0 баллов;

• 0,5 балла;

• 1 балл.

Как же проверить качество написания тех. задания? Для этого мы периодически проводим у наших разработчиков опрос в виде анкеты по каждому из аналитиков. В анкете есть раздел «Качество написания ТЗ», который как раз позволяет оценить качество написания техзадания аналитиком. Вопросы я привела на картинке.

По каждому вопросу можно дать оценку от 0 до 5. При этом ответ 0 означает, что разработчик затрудняется ответить на какой-то вопрос, что в принципе, как мне кажется, увеличивает объективизм этой, казалось бы, субъективной оценки.

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

При средней оценке больше 4 баллов по этой анкете по этому разделу аналитик получает дополнительные баллы в свою таблицу компетенций.

Таким образом мы сформировали критерии оценки для субъективных и труднопроверяемых навыков.

Остаются еще софт-скиллы, их ещё называют «мягкими компетенциями». Они отвечают за успешное участие в рабочем процессе, за высокую производительность аналитиков. Здесь критериями оценки стали как раз обратная связь от всего окружения аналитика:

• взаимодействие с клиентом – это обратная связь от заказчика, от экспертов заказчика, пользователей:

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

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

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

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

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

Когда я рассказывала про технические навыки, я уже показывала анкету для разработчиков и ее раздел «Качество написания ТЗ». Но в этой анкете есть и второй раздел – это «Взаимодействие с аналитиком».

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

В итоге у нас получилась стоимость каждого грейда равная 10 баллам.

Здесь на скриншоте указана реальная таблица одного из наших аналитиков, видно, что он набрал 48,1 балла. Зона ближайшего развития, если все будет хорошо – набрать еще 7,5 балла. Повторюсь, на встречах с аналитиками мы обсуждаем эти оценки.

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

Плюсы и минусы новой системы

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

Сначала о плюсах.

• Как я уже говорила, новая система в отличие от старой позволяет аналитику расти не только по вертикали, но и по горизонтали.

• Она достаточно хорошо работает примерно до 7-8 грейда, когда аналитик достаточно быстро может набирать новые навыки и увеличивать свою заработную плату.

• В целом аналитики нормально восприняли эту систему.

• Привязка к грейдам дает возможность менять ставки в разрезе разных городов, отделов, проводить индексацию.

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

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

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

Но есть и минусы.

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

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

• Аналитики не очень охотно идут на проекты, неперспективные с точки зрения системы – там, где они уже набрали свои баллы, и в принципе считают, что уже достигли своего потолка, например, по знанию ERP.

• Мы совсем не исключили субъективизм, но на самом деле непонятно, надо ли это делать и как это делать.

• Кроме того, система не позволяет дать какую-то временную премию руководителю за вклад аналитика в результат проекта – за какие-то сверхусилия, которые он совершил.

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

Планы

Недочетов, в принципе, хватает, но мы не останавливаемся.

Мы планируем дальше развивать эту систему.

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

• После того, как мы соберем эти замечания и обсудим их с управляющим составом, попробуем их либо внедрить, либо от них откажемся и объясним людям причину, почему мы их не реализовали.

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

• Следующий момент – надо подумать, как, по возможности, увеличить объективизм некоторых оценок.

• Возможно, следует пересмотреть или подумать о пересмотре баллов по некоторым компетенциям.

• И последнее – надо подумать, как сделать так, чтобы система была ориентирована больше на качество работы аналитика. На то, насколько он тщательно прорабатывает процессы, насколько качественно делает свои задачи, насколько поддержке комфортно работать с задачами аналитика после того, как он им передал проект.

Вопросы

Предусмотрено ли по вашей новой системе мотивации движение вниз? Например, раньше сотрудник попадал в оценку, а теперь перестал попадать. Что будет с его заработной платой?

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

Мы старались сделать нашу систему безопасной, поэтому если баллы уменьшаются, это не влияет на заработную плату человека. В этом случае аналитик понимает, что раньше ему, чтобы перейти на следующий грейд, нужно было набрать +5 баллов, а если у него сейчас стало -3, то теперь где-то нужно 8 баллов набрать.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий". Больше статей можно прочитать здесь.