Матрица компетенций бизнес-аналитика 1С: как понять, кого развивать, кому доверять сложные задачи и где у команды слабые места
Когда в 1С-команде появляется бизнес-аналитик, от него часто ждут очень многого.
Нужно поговорить с заказчиком, понять процесс, собрать требования, нарисовать схему, описать постановку, объяснить разработчику, договориться с пользователями, проверить результат, подготовить инструкцию, провести обучение, принять замечания, не забыть про НСИ, права, интеграции, законодательство, сроки, тестирование и ещё желательно не сойти с ума на третьей встрече.
На словах всё просто: “аналитик должен разобраться”.
Но что значит “разобраться”?
Разобраться в 1С:Документообороте — это одно. Разобраться в ЗУП — другое. Разобраться в ERP, производстве, заявках на оплату, договорах, ЭДО, КЭДО, складском учёте, НСИ и интеграциях — это уже совсем другой уровень.
И вот руководитель команды или проекта сталкивается с типичной ситуацией:
- одному аналитику можно доверить интервью с директором и сложный процесс;
- второй хорошо пишет постановки, но теряется на встречах;
- третья быстро понимает пользователей, но слабо видит риски интеграций;
- четвёртый знает ЗУП, но не умеет структурировать требования;
- пятый уверенно общается, но забывает проверять НСИ и права;
- а все сложные вопросы всё равно уходят к одному самому опытному человеку.
На уровне ощущений понятно, кто сильнее, кто слабее, кому нужна помощь. Но ощущения плохо помогают управлять командой. Нужен инструмент.
Таким инструментом может быть матрица компетенций бизнес-аналитика 1С.
В этой статье разберём, зачем она нужна, какие компетенции включать, как оценивать уровни, как не превратить матрицу в формальность и как использовать её в реальной работе 1С-команды.
Зачем вообще нужна матрица компетенций
Матрица компетенций — это не HR-табличка ради галочки. В нормальном варианте это рабочий инструмент руководителя, тимлида, ведущего аналитика и самой команды.
Она помогает ответить на практические вопросы:
- кому можно поручить интервью с заказчиком;
- кто может самостоятельно вести функциональную область;
- кому нужен наставник;
- где у команды слабые места;
- какие компетенции держатся на одном человеке;
- кого развивать в сторону 1С:ERP, ЗУП, ДО, интеграций или процессов;
- почему задачи зависают на определённых этапах;
- почему постановки получаются разного качества;
- какой аналитик готов к более сложным проектам;
- какие риски есть при отпуске или увольнении ключевого специалиста.
Без матрицы часто всё держится на памяти руководителя: “Мне кажется, Аня хорошо знает документооборот”, “Петя вроде работал с ERP”, “Марина когда-то делала ЗУП”, “Сергей может поговорить с заказчиком”.
Но когда задач становится больше, людей больше, областей больше, а сроки короче, управлять командой на ощущениях становится опасно.
Матрица компетенций нужна не для того, чтобы поставить людям оценки. Она нужна, чтобы видеть реальные возможности команды и развивать их осознанно.
Почему у аналитика 1С особая матрица компетенций
Матрица бизнес-аналитика в обычном IT-проекте и матрица аналитика 1С похожи, но не одинаковы.
В 1С есть своя специфика:
- сильная привязка к типовым конфигурациям;
- зависимость от предметной области;
- учёт законодательства и регламентов;
- много готовой типовой логики;
- частые интеграции между базами;
- важность НСИ;
- работа с пользователями, которые живут в учёте, документах, отчётах и регламентах;
- постоянная связь требований с возможностями платформы и конфигурации;
- большая роль сопровождения после запуска.
Обычная компетенция “умеет собирать требования” для 1С слишком широкая. Нужно понимать, какие именно требования человек умеет собирать:
- по договорному процессу;
- по заявкам на оплату;
- по кадровому учёту;
- по производству;
- по складскому учёту;
- по документообороту;
- по правам доступа;
- по интеграции ДО и БП;
- по ЭДО;
- по отчётам;
- по НСИ.
Поэтому матрица аналитика 1С должна учитывать не только общие навыки аналитики, но и 1С-контекст.
Какие блоки включить в матрицу
Матрицу лучше не делать слишком мелкой. Если включить туда 150 пунктов, её никто не будет поддерживать. Но и слишком крупная матрица вроде “аналитика — хорошо / средне / плохо” бесполезна.
Оптимально выделить несколько крупных блоков.
1. Базовая бизнес-аналитика
Это фундамент. Без него аналитик 1С превращается в человека, который просто записывает пожелания пользователей.
В этот блок можно включить:
- умение проводить интервью;
- умение выявлять потребность за просьбой пользователя;
- описание текущего и целевого процесса;
- работа с требованиями;
- формулирование критериев приёмки;
- ведение протоколов встреч;
- выявление ограничений и рисков;
- приоритизация требований;
- работа с изменениями требований;
- подготовка постановок для разработки.
Например, пользователь говорит: “Сделайте кнопку”. Слабый аналитик записывает: “Нужна кнопка”. Более зрелый аналитик выясняет, какую проблему пользователь хочет решить, в каком сценарии, какие данные нужны, что должно произойти после нажатия, кто имеет право выполнять действие и как проверить результат.
2. Знание 1С-платформы и логики 1С
Бизнес-аналитику 1С не обязательно быть разработчиком. Но она должна понимать, как устроены 1С-решения на уровне, достаточном для постановки задач и обсуждения вариантов.
В этот блок можно включить:
- понимание объектов 1С: справочники, документы, регистры, отчёты, обработки;
- понимание ролей и прав доступа;
- понимание управляемых форм на пользовательском уровне;
- понимание типовой логики проведения документов;
- понимание обменов и интеграционных сценариев на уровне требований;
- понимание ограничений типовых конфигураций;
- умение отличить настройку, доработку, расширение и внешний инструмент;
- понимание последствий доработок для обновлений и сопровождения.
Аналитик может не писать код, но должна понимать, что просьба “просто добавьте поле” может затронуть форму, документ, печатную форму, отчёт, обмен, права, заполнение, проверку и обучение пользователей.
3. Функциональные области и продукты 1С
Это один из самых важных блоков для 1С-команды.
Здесь можно оценивать знание конкретных продуктов и областей:
- 1С:Документооборот;
- 1С:ERP;
- 1С:Бухгалтерия;
- 1С:ЗУП;
- 1С:УТ;
- КЭДО;
- ЭДО;
- закупки;
- продажи;
- склад;
- производство;
- финансы и казначейство;
- договорная работа;
- управление качеством;
- НСИ;
- права доступа и роли.
Не обязательно, чтобы каждый аналитик был сильным во всём. Наоборот, матрица как раз помогает увидеть специализации.
4. Процессное мышление
1С-проект почти всегда связан с процессами. Даже когда задача звучит как “добавить реквизит”, за ней может стоять изменение маршрута, отчёта, контроля или ответственности.
В этот блок можно включить:
- умение видеть процесс от начала до конца;
- понимание ролей участников;
- выявление входов и выходов процесса;
- описание исключений;
- поиск ручных обходов;
- анализ узких мест;
- разделение текущего и целевого процесса;
- понимание владельца процесса;
- умение связывать процесс с настройками 1С;
- умение объяснять процесс пользователям.
Например, при внедрении 1С:Документооборота важно не просто настроить маршрут согласования. Нужно понять, кто инициирует документ, кто проверяет, кто утверждает, что делать при возврате, кто замещает отсутствующего, как фиксируется финальная версия и кто отвечает за изменение маршрута после запуска.
5. НСИ и качество данных
НСИ — это отдельная боль 1С-проектов. Аналитик, которая не видит проблемы данных, может собрать хорошие требования, но проект всё равно начнёт буксовать на дублях, пустых реквизитах и несогласованных справочниках.
В матрицу стоит включить:
- понимание роли справочников в 1С;
- умение выявлять критичные справочники процесса;
- понимание дублей и правил уникальности;
- умение задавать вопросы по владельцам НСИ;
- понимание обязательных реквизитов;
- умение выявлять источники данных;
- понимание мастер-системы;
- учёт НСИ в интеграциях;
- учёт НСИ в отчётах;
- умение формулировать правила ведения справочников.
Например, если аналитик описывает заявки на оплату, она должна спросить не только “какие поля нужны”, но и откуда берутся контрагенты, договоры, статьи расходов, ЦФО, проекты, банковские счета и кто отвечает за их актуальность.
6. Интеграции и сквозные процессы
Многие 1С-задачи живут не в одной базе.
Документ может создаваться в 1С:Документообороте, данные уходят в 1С:Бухгалтерию, статусы возвращаются обратно, вложения хранятся в архиве, часть документов приходит из ЭДО, пользователи берутся из AD, а отчётность строится в отдельной системе.
Аналитику не обязательно описывать технический протокол обмена, но нужно понимать бизнес-смысл интеграции.
В матрицу можно включить:
- умение описывать данные для передачи;
- понимание источника и получателя данных;
- описание статусов обмена;
- описание ошибок и реакции пользователей;
- понимание сопоставления справочников;
- выявление мастер-системы;
- описание ответственности между системами;
- учёт интеграции в тестировании;
- понимание влияния интеграции на процесс.
Простой пример: “Передать заявку на оплату в бухгалтерию” — это не одно требование. Нужно понять, какие реквизиты передавать, что делать с контрагентом, договором, статьёй расходов, вложениями, статусами, ошибками, дублями и изменениями после передачи.
7. Законодательство, методология и регламенты
В 1С нельзя полностью отделить аналитику от нормативной и методологической части.
В ЗУП важны кадровые документы, графики, отпуска, больничные, НДФЛ, отчётность. В бухгалтерии — первичные документы, НДС, закрытие периода. В КЭДО — электронные подписи, согласия, виды документов, юридическая значимость. В документообороте — хранение, регистрация, права доступа, внутренние регламенты.
Аналитик не обязана быть юристом или главным бухгалтером. Но она должна понимать, где нужно остановиться и привлечь профильного эксперта.
В матрицу можно включить:
- понимание нормативных ограничений области;
- умение выявлять вопросы для методолога;
- умение отличать пользовательское пожелание от обязательного требования;
- понимание внутренних регламентов заказчика;
- умение фиксировать ограничения в требованиях;
- умение работать с экспертами: бухгалтерией, юристами, HR, безопасностью;
- умение не придумывать норму там, где нужна проверка.
8. Тестирование и приёмка
Аналитик 1С не должна просто передать постановку и исчезнуть. Она участвует в проверке результата, помогает формировать сценарии тестирования и критерии приёмки.
В матрицу стоит включить:
- умение писать критерии приёмки;
- подготовку тестовых сценариев;
- проверку типового сценария;
- проверку исключений;
- учёт прав доступа в тестировании;
- учёт интеграций;
- учёт ролей пользователей;
- проверку отчётов и данных;
- работу с замечаниями пользователей;
- отделение ошибки от нового требования.
Если аналитик не умеет формулировать критерии приёмки, разработчик может сделать “как понял”, а пользователь принять “как получилось”. Потом все будут спорить, ошибка это или изменение требований.
9. Коммуникации и soft skills
Soft skills для аналитика 1С — это не приятное дополнение, а рабочий инструмент.
Аналитик постоянно общается с заказчиками, пользователями, разработчиками, руководителями, администраторами, методологами и поддержкой.
В матрицу можно включить:
- умение вести интервью;
- умение задавать уточняющие вопросы;
- умение работать с сопротивлением;
- умение объяснять сложное простыми словами;
- умение защищать решение;
- умение договариваться о границах задачи;
- умение фиксировать договорённости;
- умение проводить демонстрации;
- умение обучать пользователей;
- умение работать с конфликтами.
Например, аналитик может хорошо знать 1С:Документооборот, но если она не умеет объяснить руководителям, почему нельзя согласовывать договоры в личке, процесс всё равно уйдёт в обход системы.
10. Документация и передача знаний
В 1С-командах часто страдает документация. Задача сделана, но через полгода никто не помнит, почему было принято именно такое решение.
В матрицу можно включить:
- ведение протоколов;
- описание требований;
- описание схем процессов;
- подготовку инструкций;
- подготовку FAQ;
- описание настроек;
- фиксацию решений и рисков;
- подготовку материалов для сопровождения;
- ведение базы знаний;
- передачу знаний коллегам.
Как оценивать уровень компетенции
Самый простой вариант — использовать шкалу от 0 до 4.
| Уровень | Название | Что означает | Как использовать |
| 0 | Нет опыта | Не работала с темой или знает только название | Не назначать без обучения и наставника |
| 1 | Базовое понимание | Понимает термины и может участвовать в задаче рядом с более опытным коллегой | Подходит для обучения, простых вопросов, участия в интервью вторым номером |
| 2 | Рабочий уровень | Может самостоятельно выполнять типовые задачи в области | Можно назначать стандартные задачи, но сложные случаи лучше проверять |
| 3 | Уверенный уровень | Самостоятельно ведёт область, видит риски, может общаться с заказчиком | Можно доверять обследование, постановки и координацию по направлению |
| 4 | Эксперт | Глубоко знает область, обучает других, проверяет решения, помогает в сложных ситуациях | Можно использовать как наставника, владельца практики или эксперта по направлению |
Важно: уровень должен оценивать не уверенность человека, а наблюдаемое поведение.
Не “кажется, она хорошо знает ЗУП”, а:
- проводила интервью по ЗУП;
- готовила постановки;
- знает типовые документы;
- видит риски по кадровому процессу;
- может объяснить пользователю сценарий;
- понимает, когда нужно привлечь методолога;
- участвовала в тестировании и приёмке.
Пример матрицы компетенций
Ниже пример структуры. Её можно адаптировать под свою команду.
| Блок компетенций | Компетенция | Уровень 1 | Уровень 2 | Уровень 3 | Уровень 4 |
| Бизнес-анализ | Интервью с заказчиком | Присутствует на интервью и фиксирует ответы | Проводит типовое интервью по готовому плану | Самостоятельно ведёт сложное интервью и удерживает структуру | Обучает других, помогает в конфликтных и неопределённых интервью |
| Бизнес-анализ | Постановка требований | Описывает простые пожелания пользователей | Готовит постановки по шаблону | Пишет полные требования с критериями приёмки и рисками | Проверяет постановки команды и формирует стандарты |
| 1С | Понимание объектов 1С | Знает основные термины | Понимает, где справочник, документ, отчёт, обработка | Учитывает объекты 1С при описании требований | Помогает выбирать вариант реализации вместе с разработчиком |
| Процессы | Описание процесса | Может записать последовательность действий | Описывает текущий процесс с ролями | Выделяет целевой процесс, исключения и контрольные точки | Проектирует процесс с учётом 1С, рисков и сопровождения |
| НСИ | Работа со справочниками | Понимает, какие справочники используются | Выявляет обязательные реквизиты и источники данных | Определяет владельцев НСИ, дубли, правила ведения | Проектирует подход к качеству НСИ на уровне процесса |
| Интеграции | Описание обмена | Понимает, что данные передаются между системами | Описывает состав передаваемых данных | Учитывает статусы, ошибки, НСИ и ответственность | Проектирует сквозной интеграционный сценарий вместе с командой |
| Коммуникации | Защита решения | Может объяснить простую логику решения | Аргументирует решение на уровне пользователя | Защищает решение перед заказчиком, показывает риски вариантов | Помогает команде проходить сложные согласования |
Как собрать матрицу для своей команды
Не нужно начинать с идеальной большой таблицы. Лучше идти по шагам.
Шаг 1. Определить задачи команды
Сначала нужно понять, какие задачи реально выполняет команда аналитиков.
Например:
- сопровождение 1С:Документооборота;
- развитие ЗУП;
- внедрение КЭДО;
- интеграции ДО и БП;
- описание требований для разработчиков;
- обучение пользователей;
- проектные обследования;
- работа с обращениями;
- проверка доработок;
- регламенты и инструкции.
Матрица должна отражать реальные задачи, а не красивый универсальный список из интернета.
Шаг 2. Выделить критичные компетенции
Не все компетенции одинаково важны. Для команды, которая занимается документооборотом, критичны маршруты, роли, права, виды документов, архив, поручения, интеграции с БП и ЭДО.
Для команды ERP важнее закупки, продажи, склад, производство, финансы, НСИ, интеграции и управленческая отчётность.
Для команды ЗУП — кадровые процессы, начисления, отчётность, КЭДО, законодательство, персональные данные.
Шаг 3. Описать уровни простыми словами
Уровни должны быть понятными. Не “средний уровень компетенции”, а конкретно: что человек умеет делать.
Например, по компетенции “интервью”:
- уровень 1 — присутствует и фиксирует ответы;
- уровень 2 — проводит типовое интервью по готовому списку вопросов;
- уровень 3 — самостоятельно ведёт интервью, уточняет ответы, выявляет риски;
- уровень 4 — проводит сложные интервью, обучает других, помогает в конфликтных встречах.
Шаг 4. Провести первичную оценку
Оценку можно делать совместно:
- самооценка аналитика;
- оценка руководителя;
- оценка ведущего аналитика;
- подтверждение через реальные задачи.
Важно не превращать это в экзамен. Цель — не поймать человека на слабостях, а понять, как развивать команду.
Шаг 5. Найти зоны риска
После заполнения матрицы обычно сразу видно:
- какие компетенции держатся на одном человеке;
- где нет эксперта;
- где много уровня 1–2 и мало уровня 3–4;
- где команда зависит от внешних специалистов;
- какие области нельзя отдавать без наставника;
- кого можно развивать в резерв.
Шаг 6. Привязать матрицу к плану развития
Матрица без плана развития быстро устареет.
По каждой важной зоне можно определить:
- кого развиваем;
- до какого уровня;
- на каких задачах;
- кто наставник;
- какой срок;
- как поймём, что уровень вырос.
Как использовать матрицу в работе
Матрица полезна только тогда, когда она влияет на решения.
1. Распределение задач
Если задача простая и типовая, её можно дать аналитику с уровнем 2. Если задача сложная, межсистемная и с высокой ценой ошибки, нужен уровень 3–4 или наставник.
Например, интервью по изменению карточки документа в ДО можно доверить аналитику рабочего уровня. А обследование процесса заявок на оплату с интеграцией в бухгалтерию, маршрутами, НСИ и финансовыми рисками лучше поручить более опытному специалисту.
2. Планирование развития
Матрица помогает не писать абстрактное “развивать аналитические навыки”, а ставить конкретные цели:
- поднять уровень по интервью с 1 до 2;
- развить понимание 1С:Документооборота до уровня 3;
- дать опыт по интеграциям на уровне 2;
- научиться писать критерии приёмки;
- провести два интервью под наблюдением наставника;
- подготовить одну инструкцию для пользователей.
3. Наставничество
Матрица показывает, кто может быть наставником по конкретной области.
Один аналитик может быть экспертом по ДО, но слабее по ЗУП. Другой — наоборот. Третий хорошо ведёт интервью, четвёртый силён в документации и постановках. Наставничество можно строить не по должности, а по реальным компетенциям.
4. Снижение зависимости от незаменимых людей
Если по критичной области уровень 4 есть только у одного человека, это риск.
Например, только один аналитик понимает маршруты согласования, права и интеграцию ДО с БП. Пока он в команде, всё хорошо. Но отпуск, больничный или увольнение сразу создадут проблему.
Матрица помогает заранее увидеть такие точки отказа.
5. Подбор людей в проект
Для сложного проекта можно собрать команду не “кто свободен”, а по компетенциям:
- кто понимает предметную область;
- кто умеет вести интервью;
- кто знает нужную конфигурацию;
- кто видит интеграции;
- кто сможет подготовить документы и обучение;
- кто закроет коммуникацию с заказчиком.
Типичные ошибки при внедрении матрицы
Ошибка 1. Делать слишком большую матрицу
Если в матрице 200 строк, её никто не будет использовать. Начинайте с 20–40 ключевых компетенций.
Ошибка 2. Оценивать “по ощущениям”
Оценка должна быть связана с реальными задачами и поведением. Не “хорошо общается”, а “самостоятельно проводит интервью, удерживает структуру, фиксирует решения и выявляет риски”.
Ошибка 3. Использовать матрицу как инструмент давления
Если люди воспринимают матрицу как способ наказания, они начнут завышать оценки или защищаться. Матрица должна помогать развитию, а не создавать страх.
Ошибка 4. Не обновлять матрицу
Компетенции меняются. Человек может вырасти, перейти в другую область, потерять актуальность по старой теме. Матрицу нужно пересматривать хотя бы раз в несколько месяцев.
Ошибка 5. Не связывать матрицу с задачами
Если матрица живёт отдельно от распределения задач, проектных ролей и обучения, она быстро становится бесполезным файлом.
Ошибка 6. Ожидать, что каждый аналитик будет экспертом во всём
Матрица нужна не для того, чтобы сделать всех одинаковыми. Она нужна, чтобы видеть сильные стороны, зоны роста и баланс команды.
Пример профиля аналитика
По матрице можно составлять краткий профиль аналитика.
| Блок | Уровень | Комментарий |
| Интервью с заказчиком | 3 | Самостоятельно проводит встречи, хорошо уточняет процесс, фиксирует открытые вопросы |
| Постановка требований | 2 | Пишет постановки по шаблону, но сложные сценарии требуют ревью |
| 1С:Документооборот | 3 | Уверенно работает с маршрутами, задачами, видами документов и ролями |
| Интеграции | 1 | Понимает общие принципы, но не готова самостоятельно описывать сложные обмены |
| НСИ | 2 | Видит основные справочники, но не всегда выявляет владельцев и правила ведения |
| Документация | 3 | Хорошо оформляет протоколы, инструкции и схемы процесса |
| Коммуникации | 4 | Умеет договариваться с заказчиком и защищать решение без конфликта |
Из такого профиля уже понятно, какие задачи можно доверять, где нужен наставник и куда развивать специалиста.
Как матрица помогает самому аналитику
Матрица полезна не только руководителю. Самому аналитику она тоже помогает.
Она показывает:
- какие навыки уже сильные;
- куда можно расти;
- какие области стоит изучать;
- почему пока не дают более сложные задачи;
- что нужно показать на практике, чтобы перейти на следующий уровень;
- какие компетенции повышают ценность специалиста на рынке.
Например, аналитик может увидеть, что у неё хороший уровень по коммуникациям и ДО, но слабые интеграции и НСИ. Тогда план развития становится конкретным: взять задачу с обменом ДО-БП, изучить правила сопоставления справочников, подготовить вопросы для интервью по интеграции, пройти ревью у более опытного коллеги.
Это гораздо полезнее, чем абстрактное “хочу стать senior-аналитиком”.
Чек-лист хорошей матрицы компетенций
| Вопрос | Зачем проверять |
| Матрица отражает реальные задачи команды? | Чтобы она не была оторвана от практики |
| Есть ли отдельные блоки по 1С-продуктам и функциональным областям? | Чтобы учитывать специфику 1С |
| Описаны ли уровни через поведение и результаты? | Чтобы оценки были понятными |
| Не слишком ли много компетенций? | Чтобы матрицей реально пользовались |
| Видны ли критичные зоны риска? | Чтобы заранее закрывать зависимость от одного человека |
| Связана ли матрица с распределением задач? | Чтобы она помогала управлять работой |
| Связана ли матрица с обучением и наставничеством? | Чтобы она помогала развивать людей |
| Обновляется ли матрица регулярно? | Чтобы она не устаревала |
| Понятна ли матрица самим аналитикам? | Чтобы она не воспринималась как формальная оценка сверху |
| Помогает ли матрица принимать решения? | Если нет, её нужно упростить или пересобрать |
Минимальный вариант матрицы для старта
Если не хочется сразу делать большую модель, можно начать с короткой матрицы из 12 компетенций:
- Интервью с заказчиком.
- Описание бизнес-процесса.
- Постановка требований.
- Критерии приёмки.
- Понимание объектов 1С.
- Знание основной конфигурации команды.
- НСИ и справочники.
- Права и роли.
- Интеграции.
- Тестовые сценарии.
- Документация и инструкции.
- Коммуникации и защита решения.
Этого уже достаточно, чтобы увидеть основные перекосы.
Вывод
Матрица компетенций бизнес-аналитика 1С — это простой, но сильный инструмент управления командой и развитием специалистов.
Она помогает не гадать, кто что умеет, а видеть реальную картину:
- кто может вести интервью;
- кто понимает процессы;
- кто силён в 1С:Документообороте, ERP, ЗУП или другой области;
- кто умеет работать с НСИ;
- кто видит интеграции;
- кто хорошо пишет требования;
- кому нужен наставник;
- где у команды риски;
- кого можно развивать в эксперта.
Главное — не превращать матрицу в бюрократическую оценку. Она должна быть живым рабочим инструментом.
Хорошая матрица компетенций отвечает на три вопроса:
- какие задачи должна закрывать команда;
- какие компетенции для этого нужны;
- как развивать людей, чтобы команда становилась сильнее.
Сильная 1С-команда — это не набор людей, которые “как-нибудь разберутся”. Это команда, где понятно, кто в чём силён, кто чему учится, где нужен наставник и какие компетенции нужно развивать под будущие проекты.
А для бизнес-аналитика 1С такая матрица становится не ограничением, а картой роста: от простого сбора пожеланий до самостоятельного ведения сложных процессов, защиты решений, работы с интеграциями, НСИ, пользователями и реальными задачами бизнеса.