Аналитик - это функциональный архитектор. Доказано Минтрудом

27.07.26

Управление ИТ - Стандарты и документация

В прошлых статьях я читал профстандарты и вывел, что архитектор - это тот, кто принимает архитектурные решения. А теперь неожиданный поворот: если открыть профстандарт «Системный аналитик», выяснится, что аналитик высокого уровня как раз такие решения и принимает. То есть, сюрприз, аналитик и есть архитектор. Просто функциональный. И это не мой комплимент аналитикам, а вывод прямо из формулировок Минтруда.

Бесплатные

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО

Наименование Скачано Бесплатно
06.022 Системный аналитик
.pdf 124,38Kb
11 Скачать бесплатно

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

 

Все хотят быть архитекторами - а многие уже ими стали

 

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

 

Сначала вспомним, кто такой архитектор

 

В предыдущей статье я доказывал простую вещь: архитектор - это не грейд, не самый опытный и не знаток платформы. Архитектор - это тот, кто на развилке принимает архитектурное решение и отвечает за него. Не «умеет много», а «решает, каким будет устройство системы».

Держите этот критерий в голове. Сейчас откроем стандарт аналитика и приложим критерий к нему.

 

Что говорит стандарт «Системный аналитик»

 

 

Профессия аналитика описана в профстандарте 06.022 «Системный аналитик» (утвержден приказом Минтруда № 367н от 27 апреля 2023 года). Он свежий - в отличие от стандартов программиста и архитектора, принятых раньше, это документ 2023 года, и видно, что писали его по современным представлениям о профессии.

Регистрационный номер 233. В отличие от стандартов программиста и архитектора, фирма 1С не принимала участия в его разработке:


 

Внутри - четыре уровня, и само деление любопытное:

  • Уровень 4. Техническое сопровождение проектирования Системы. Должности: младший специалист, младший системный аналитик, младший консультант. Образование - среднее профессиональное, опыт не требуется. Это вход в профессию: собирать исходные данные, изучать и описывать работу пользователей в системах-аналогах, оформлять документацию.
  • Уровень 5. Техническое проектирование Системы. Уже просто «системный аналитик» или «консультант». По-прежнему достаточно среднего профобразования - плюс год опыта на сопровождении. Этот аналитик проектирует сам, но на техническом уровне: по заданной сверху концепции.
  • Уровень 6. Концептуально-логическое проектирование Системы. Должность - «старший системный аналитик»: высшее образование (бакалавриат) и не меньше трех лет в проектировании. Вот здесь живут концепция системы, деление на подсистемы - и те самые архитектурные решения, ради которых мы все это читаем.
  • Уровень 7. Управление работами системных аналитиков. «Ведущий» и «главный» аналитик, руководитель группы или отдела системного анализа: магистратура или специалитет плюс три года концептуального проектирования. Обратите внимание: это уже не «еще более крутое проектирование», а руководство аналитиками.

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

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

Выявлять концептуальные архитектурные (технические) решения по Системе

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

 

Складываем два и два: аналитик 6-го уровня - это архитектор

 

Итак:

  • Архитектор - это тот, кто принимает архитектурные решения.
  • Аналитик 6-го уровня по стандарту выявляет концептуальные архитектурные решения по системе (профстандарт 06.022).

Вывод напрашивается сам: аналитик, который дорос до проектирования концепции, - уже архитектор. Не «Архитектор программного обеспечения» (это отдельный стандарт 06.003, про программную архитектуру, про «как реализовать»). А архитектор концептуального, бизнесового слоя - «что и зачем система делает». И именно этого человека в 1С-проектах зовут функциональным архитектором.

Выходит, «сильный системный аналитик» и «функциональный архитектор» - один и тот же человек, просто с двух ракурсов. Минтруд, сам того не афишируя, выдал аналитику архитектурные полномочия - надо было только дочитать умения на 6-м уровне.

Забавно, что фирма «1С» пришла к этому раньше Минтруда. В первой редакции ее Технологии корпоративного внедрения (1С:ТКВ; публичные разборы - 2013 год) среди девятнадцати ролей проекта не было ни одного архитектора, а «спецификацию требований и архитектуру ИС» разрабатывал - так прямо и записано - системный аналитик. Потом роль переименовали в функционального архитектора, но суть с 2013 года не изменилась: архитектуру системы на бизнес-слое проектирует аналитик.

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

 

Оговорка: не каждый аналитик

 

И здесь легко скатиться в обратную крайность - инфляцию титулов, против которой направлена вся эта серия. Архитектором аналитика делает не должность и не стаж, а то, что он выявляет концептуальные архитектурные решения и отвечает за них. Джун, который пишет ТЗ по чужой концепции, - еще не архитектор, он на 4-5 уровне стандарта, и это нормально. А вот тот, кто сам строит концепцию системы, делит ее на подсистемы и решает, каким все это будет, - архитектор, как ни называй его должность в штатном расписании.

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

 

Сколько идти до архитектора

 

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

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

 

Что это меняет на практике

 

Если вы аналитик - не завидуйте слову «архитектор». Проектируете концепцию системы и принимаете решения о ее устройстве? Тогда вы уже архитектор, функциональный, и профстандарт на вашей стороне. Кстати, это аргумент и для разговора о зарплате.

И мысль на вырост. Функциональный архитектор - это, по сути, аналитик высшего уровня. Но раз он принимает архитектурные решения, то и относиться к ним стоит по-архитекторски. Двигаться нужно в две стороны сразу. Первая - научиться мыслить архитектурно: не просто описывать требования, а осознанно решать, каким будет устройство системы, и держать в голове последствия этих решений. Вторая - фиксировать решения так, как это делают архитекторы, в виде ADR (Architecture Decision Record): короткая запись «что решили, почему и какие альтернативы отвергли». Аналитик, который мыслит на уровне устройства системы и оставляет за собой ADR, - это уже не «тот, кто написал ТЗ», а полноценный функциональный архитектор. И это лучшее, что может случиться с сильным аналитиком: тот же человек, та же экспертиза - но решения приняты осознанно и не растворяются в переписке, а живут в задокументированном виде.

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

Если вы нанимаете - «функциональный архитектор» и «сильный системный аналитик» это по сути одна вакансия. Мерить ее надо по 06.022 «Системный аналитик», а не по 06.003 «Архитектор ПО»: перепутаете стандарты - перепутаете и требования, и вилку.

А как же технический архитектор? Это другой слой и другой стандарт - 06.003, программная архитектура. Получается стройно: два архитектора, два слоя, два профстандарта.

 

Откуда вообще взялись два архитектора

 

Почему в 1С архитектор разделился на функционального и технического - отдельная и интересная для меня история с корнями в SAP и методологии корпоративного внедрения. Ей посвящена статья «Загадка двух архитекторов».

 

Итог

 

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

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

А вы себя кем считаете - аналитиком или (функциональным) архитектором? И где, по-вашему, проходит граница: с какого момента аналитик становится архитектором?

К статье приложен файл профстандарта. Почитайте его. Что интересного вы из него возьмете?

 

Ссылки

 

Профессиональный стандарт Аналитик Архитектор

См. также

Стандарты и документация Разработчик Бесплатно (free)

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

23.10.2026    312    0    jack_nsk    0    

1

Стандарты и документация Разработчик Аналитик Россия Бесплатно (free)

Статья посвящена практическому опыту адаптации стандартов разработки фирмы «1С» для работы с ИИ-инструментами. Показано, почему обычного пересказа стандартов недостаточно для надёжной генерации и ревью кода: при сокращении теряются условия применения, исключения, обязательность требований и контекст. Авторы описывают переход к формализованным карточкам правил, содержащим источник, условия, исключения, способ проверки, тяжесть нарушения, возможности автоматического контроля и дату сверки со стандартом. Материал будет полезен руководителям проектов 1С, архитекторам и разработчикам, которые внедряют ИИ в разработку и контроль качества. На реальных тестах показано, как структурированное представление стандартов снижает число пропущенных дефектов, ложных замечаний и потенциально опасных исправлений.

25.09.2026    428    0    Rico17    3    

1

Стандарты и документация Аналитик Руководитель проекта Бесплатно (free)

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

24.09.2026    302    0    YA_826532418    0    

3

Стандарты и документация 1С:Документооборот Бесплатно (free)

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

22.09.2026    260    0    YA_826532418    0    

3

Стандарты и документация 1С:Документооборот Бесплатно (free)

Жалоба клиента может привести к регистрации несоответствия, внутренний аудит — сразу к нескольким проблемам, а корректирующее действие — к новой редакции нормативного документа. Во второй части разбираю, какие механизмы 1С:Документооборота подходят для жалоб и внутренних аудитов, какие связи между объектами нужно предусмотреть и что спросить на обследовании, чтобы СМК не превратилась в набор несвязанных карточек.

22.09.2026    236    0    YA_826532418    0    

3

Стандарты и документация 1С:Предприятие 8 1С:Документооборот Бесплатно (free)

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

21.09.2026    357    0    YA_826532418    0    

4

Стандарты и документация Аналитик Руководитель проекта Бесплатно (free)

ИИ удобно использовать для анализа ТЗ, подготовки протоколов, писем и проверки требований. Но до загрузки рабочего материала его нужно обезличить, а после получения ответа — проверить. Рассказываю, как я разделяю эти две проверки и почему уверенный ответ ИИ еще не означает, что предложенный вариант существует в 1С.

04.09.2026    639    0    YA_826532418    0    

3

Стандарты и документация Бесплатно (free)

Разбираем ISO/IEC 42001:2023 – самостоятельный стандарт по системам менеджмента искусственного интеллекта, построенный на логике ISO/IEC 27001 и расширяющий привычные подходы информационной безопасности на разработку, поставку и использование ИИ-систем. Показываем, как типовая модель оценки рисков дополняется анализом воздействия на бизнес и общество, а приложение А объединяет меры управления рисками в десять групп контролей. Объясняем, чем отличаются требования к разработчикам, поставщикам и пользователям систем искусственного интеллекта и какие риски каждая из сторон должна учитывать на своих этапах жизненного цикла. Материал будет полезен специалистам по информационной безопасности и разработчикам информационных систем, интегрированных с ИИ.

31.07.2026    664    0    roman_nikishov    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Jokemas 196 28.07.26 08:51 Сейчас в теме
Подмену понятий вижу я. Ибо выявление концептуальных архитектурных решений и принятие решения об архитектурных изменениях, а значит и нести ответственность - абсолютно разные вещи.

Аналитик занимается анализом системы, в результате такого анализа находит (выявляет) потребности бизнеса, после чего на основании такого анализа запускается другой процесс - поиск технического решения, для выполнения концептуальной потребности. Т.е. ответственность аналитика закончилась, как только он передал информацию далее по инстанции. Он не несёт ответственность за то, как ситуация будет разрешена. Аналитик не принимает решения, как исправлять, его задача - выявить, а не решить. При этом на аналитике лежит ответственность контроля изменений. Т.е. он производит сверку решения с тем, что было затребовано бизнесом. Но это тоже не касается ответственности аналитика, это опять же реализация ответственности исполнителя. Если решение не соответствует затребованному и аналитик это выявил, то "решала" получит по загривку.

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

Любое архитектурное решение отталкивается от целесообразности. Вот эту самую целесообразность и формирует аналитик.
2. ardn 861 29.07.26 12:33 Сейчас в теме
(1) Спасибо.
"Выявлять" и "решать" не одно и то же, и для аналитика уровней 4-5 вы правы, он выявляет потребности, за устройство не отвечает. Про такого и оговариваюсь - "не каждый аналитик".

Но соль в формулировке стандарта на 6-м уровне. Там не "выявить потребности", а "разработка концепции Системы", "деление на подсистемы", "построение модели Системы концептуального уровня". Это уже само проектирование. Тот, кто это делает и отвечает за концепцию, и есть архитектор бизнес-слоя.
Для отправки сообщения требуется регистрация/авторизация