Как разработать модель компетенций BI-аналитиков

В крупной частной медицинской сети стартовал проект по внедрению BI-системы. Первые успехи и амбициозные планы обусловили необходимость расширения команды. Видение целевой архитектуры и процесса разработки стали отправной точкой для составления профилей вакансий.

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

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

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

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

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

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

Значения варьировались для четырёх должностей:

1. Аналитик.
2. Ведущий аналитик.
3. Главный аналитик.
4. Руководитель проекта.

Итого получили 14 компетенций по трём кластерам с соответствующим намерением в основе:

1. Технический – действовать профессионально.
2. Коммуникативный – приносить пользу.
3. Управленческий – умножать усилия.

Технический кластер связан напрямую с этапом разработки процесса создания BI-продуктов и поддержкой готовых решений. Включает программирование на языках SQL и python, работу с технологиями: MS SQL Server, SSAS, SSRS, Power BI, Excel, Airflow, GitLab, Docker, PostgreSQL.

Т.1.Проектирование хранилищ измеряется широтой знаний:

• Аналитик (0): разбирается в реляционных СУБД. Знает нормальные формы. Мыслит слоями. Понимает разницу между пакетной и потоковой загрузкой.
• Ведущий аналитик (1): знает архитектурные подходы. Осознаёт отличия DWH от Data Lake. Представляет структуру таблиц по Kimball, Inmon, Data Vault, Anchor Model.
• Главный аналитик, Руководитель проекта (2): понимает основы масштабирования и отказоустойчивости. Выбирает оптимальный вариант организации витрин для задачи.

Т.2.Администрирование баз данных определяется охватом поддержки:

• Аналитик (0): знает элементы СУБД. Разбирается в способах аутентификации и разграничения доступа. Решает отдельные проблемы по инструкциям.
• Ведущий аналитик (1): автоматизирует регулярное обслуживание. Настраивает бэкапирование, перестроение индексов, очистку логов отдельного экземпляра.
• Главный аналитик, Руководитель проекта (2): понимает основы партицирования и репликации. Формулирует точный запрос в заявках системным администраторам.

Т.3.Организация ETL-процессов измеряется разнообразием операций:

• Аналитик (0): настраивает независимые потоки данных. Применяет временные таблицы и алгоритмические расширения в SQL. Запускает процедуры через задания. Пользуется функциями python-библиотек pandas, requests, SQLAlchemy.
• Ведущий аналитик (1): оптимизирует скрипты под СУБД. Читает планы запроса. Применяет индексы и хинты. Полноценно использует фреймворк Django и библиотеки alembic, pytest. Дорабатывает DAG’и Airflow по согласованному образцу.
• Главный аналитик, Руководитель проекта (2): организует параллельные и последовательные инкрементальные перегрузки. Кастомизирует классы и шаблонизирует код на python. Понимает основы распределённого процессинга в Airflow.

Т.4.Использование систем контроля версий определяется масштабом ответственности:

• Аналитик (0): сохраняет код в репозиторий. Владеет основными командами git. Ориентируется в графическом интерфейсе GitLab.
• Ведущий аналитик, Главный аналитик, Руководитель проекта (1): отвечает за мастер-ветку. Организует параллельную разработку. Разрешает конфликты при слиянии.

Т.5.Разворачивание решений измеряется сложностью конфигураций:

• Аналитик (0): поддерживает текущее. Перезапускает приложения по инструкциям.
• Ведущий аналитик (1): ставит новое. Самостоятельно устанавливает программу в единственном экземпляре. Понимает основы контейнеризации.
• Главный аналитик, Руководитель проекта (2): автоматизирует и масштабирует. Настраивает CI/CD в GitLab, устраняет ошибки в пайплайнах. Понимает основы оркестрации. Формирует точный запрос DevOps-инженерам.

Т.6.Визуализация показателей определяется сложностью калькуляций и представлений:

• Аналитик (0): проектирует простые дэшборды и отчёты. Знает базовые элементы и владеет DAX. Строит сводные таблицы и применяет функции в Excel.
• Ведущий аналитик (1): разрабатывает сложные визуализации. Понимает возможности и ограничения форматирования и языка формул. Дорабатывает OLAP-кубы.
• Главный аналитик, Руководитель проекта (2): создаёт OLAP-кубы. Выбирает многомерную или табулярную модель и настраивает процессинг под задачу.

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

К.1.Взаимодействие с конечным заказчиком измеряется степенью заботы.

• Аналитик (-1): при обращении вспоминает, что сделал. Для ответа на вопрос смотрит в техническую документацию или код.
• Ведущий аналитик (0): пользуется своим продуктом. Интересуется результатами. Находит и исправляет баги. Предлагает, согласовывает и осуществляет улучшения дизайна.
• Главный аналитик, Руководитель проекта (1): заранее думает об удобстве. Минимизирует неоднозначность. Выбирает оптимальную визуализацию. Предусматривает справку.

К.2.Взаимодействие с методологом-верификатором определяется глубиной понимания.

• Аналитик (-1): нуждается в разъяснениях. Ждёт помощи от коллег при переработке бизнес-требований в техническую реализацию.
• Ведущий аналитик (0): вникает автономно. Самостоятельно воспринимает запрос заказчика. Помогает оформить техническое задание.
• Главный аналитик (1): предугадывает потребность. Способен выяснить и уяснить конечную цель. Предлагает алгоритмы прозрачнее и BI-продукты удобнее.
• Руководитель проекта (2): рекомендует произвести улучшения по итогам. Оценивает взаимосвязанные решения для заказчика и прорабатывает оптимизированное.

К.3.Взаимодействие с экспертом по системе-источнику измеряется техническим кругозором:

• Аналитик (-1): не способен полноценно разобраться. Понимает только хорошо описанный функционал. Просит подробных объяснений. Расширяет настроенное.
• Ведущий аналитик (0): автономен в подключении. Изучает документацию, ищет информацию о приложении в интернете, исследует GUI, задаёт правильные вопросы.
• Главный аналитик, Руководитель проекта (1): влияет на информационную систему. Предлагает варианты интеграции. Рекомендует изменить отражение бизнес-процесса.

К.4.Взаимодействие с коллегами определяется направлением обмена опытом:

• Аналитик (-1): требует пояснений. Ждёт дополнительных инструкций со стороны старших коллег по делегированной задаче.
• Ведущий аналитик (0): не просит советов. Пользуется базой знаний и открытыми источниками. Решает проблемы самостоятельно.
• Главный аналитик, Руководитель проекта (1): развивает других. Исправляет и объясняет код. Рассказывает об удачных решениях на общих встречах.

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

У.1.Планирование измеряется горизонтом предвидения:

• Аналитик (-1): планирует день. В состоянии оценить, с чем справится за восемь рабочих часов.
• Ведущий аналитик (0): планирует неделю. Корректно предсказывает, сколько задач выполнит в пятидневный срок.
• Главный аналитик (1): планирует месяц. Разбивает комплексное техническое задание на части в несколько недельных спринтов.
• Руководитель проекта (2): планирует квартал. Ставит реалистичные проектные цели и задаёт достижимые процессные метрики членам команды.

У.2.Регламентирование определяется объёмом заполняемых материалов в базе знаний:

• Аналитик (-1): дополняет или актуализирует статью. Самостоятельно заменяет устаревшую информацию или фиксирует решение проблем в описанной области.
• Ведущий аналитик (0): создаёт инструкцию. Изучает новый инструмент и перечисляет необходимые настройки, команды, особенности графического интерфейса.
• Главный аналитик (1): документирует часть процесса. Проектирует верхнеуровневую последовательность этапов. Глубоко прорабатывает выделенную стадию.
• Руководитель проекта (2): описывает зону ответственности. Исчерпывающе перечисляет необходимые ресурсы, фазы, наполнение работ, правила кодирования.

У.3.Руководство измеряется количеством подчинённых:

• Аналитик, Ведущий аналитик (0): никем не руководит. Обязанности, возлагаемые должностной инструкцией, не предполагают функцию постоянного делегирования.
• Главный аналитик (1): курирует одного аналитика. Поясняет техническое задание, декомпозирует задачу, консультирует по проблемам, проверяет результат.
• Руководитель проекта (2): управляет пятью сотрудниками. Распределяет задачи, координирует деятельность, оценивает производительность.

У.4.Обеспечение определяется объёмом расчётов:

• Аналитик (-1): не задумывается о ресурсах. Исполняет задачу только в терминах функциональных требований. Прибегает к оптимизации вынужденно или реактивно.
• Ведущий аналитик (0): рассчитывает место под результат. Знает эффективные способы хранения и прогрузки. Оценивает долю решения в вычислительных мощностях.
• Главный аналитик (1): прогнозирует потребность. Отслеживает тренды. Формирует заказ на модификацию и добавление виртуальных машин.
• Руководитель проекта (2): добивается максимальной и равномерной нагрузки. Регулярно мониторит и устраняет неактуальные элементы.

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

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