Бизнес- и системный аналитик
Назад

Пример регламента · Бизнес- и системный аналитик

Регламент работы бизнес- и системного аналитика

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

Паспорт регламента

Код
EXAMPLE-REG-BUSINESS-ANALYST
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
Руководитель аналитики / ведущий системный аналитик
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

Цель регламента

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

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • В требованиях к обработке персональных данных явно фиксируются оператор, уполномоченные лица, цели, основания, категории данных, получатели, сроки хранения и права субъекта.
  • Требования к юридически значимым электронным документам отделяются от обычных записей в системе: определяются формат, реквизиты, ЭЦП, проверка подписи и архивное хранение.

Что проверить до начала работы

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

Зона ответственности

  • Исследование процессов и потребностей, требования, BPMN/UML, модели данных, API-контракты и управление изменениями.
  • Аналитик отвечает за ясность решения и связность артефактов, но не подменяет владельца бизнес-решения или архитектора.

Обязанности специалиста

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

Рабочий порядок

  1. Сформулировать проблему, цель и границы системы.
  2. Собрать стейкхолдеров, процессы, правила, данные и исключения.
  3. Смоделировать целевое поведение и согласовать системные контракты.
  4. Описать acceptance criteria и провести walkthrough с командой.
  5. Связать требования с задачами и тестами, управлять версиями до релиза.

Контрольные вопросы специалиста

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

  1. Какая проблема, норма или договорное обязательство порождает требование?
  2. Кто является оператором данных, кто уполномоченным лицом и кто получает результат?
  3. Каково основание и цель обработки каждого набора персональных данных?
  4. Какие данные обязательны, какие опциональны и каков срок их хранения?
  5. Есть ли трансграничная передача, внешняя система или новый получатель данных?
  6. Какие действия должны быть юридически значимыми и какой вид подписи или подтверждения нужен?
  7. Как субъект реализует доступ, исправление, удаление, отзыв согласия и получение информации?
  8. Какие роли, разделение обязанностей и audit trail необходимы?
  9. Как изменение пройдет по API, данным, отчетам, тестам, документации и договорам?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Добавлять к модели данных классификацию полей, владельца, допустимых получателей, retention и правила маскирования.
  • В acceptance criteria включать негативные сценарии прав доступа, удаления, отзыва согласия, экспорта и аудита.

Обязательные артефакты

  • Problem Statement и Context Diagram
  • BPMN/UML-модели
  • Каталог требований и бизнес-правил
  • OpenAPI и каталог ошибок
  • Traceability Matrix и Change Log

Критерии качества

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

Контрольные точки

  • До разработки согласованы scope, основной сценарий, исключения, NFR и данные.
  • Перед изменением выполнен impact analysis.
  • Перед релизом критичные требования связаны с тестами и версией поставки.

Антипаттерны

  • Собирать пожелания без проверки проблемы.
  • Прятать бизнес-правила в длинных протоколах.
  • Согласовывать API только после реализации.
  • Перезаписывать требования без истории решений.

Рабочий ритм и периодический контроль

  • По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
  • Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
  • Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
  • После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
  • Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
  • При каждом change request выполнять impact analysis по требованиям, данным, контрактам, тестам, регламентам и внешним обязательствам.

Метрики контроля

Покрытие требований критериямиДоля возвратов на уточнениеРазрывы трассировкиИзменения после начала разработки

Коммуникации и эскалация

  • Блокирующие противоречия эскалируются владельцу решения до разработки.
  • Решения фиксируются в общем источнике, а не только в переписке.
  • Изменение контракта заранее сообщается всем потребителям.

Матрица обязательной эскалации

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

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • Требование готово, когда оно трассируется к цели и источнику, согласовано владельцами, имеет модели, NFR, data rules, acceptance criteria и историю решений.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Хранить каталог требований и правил, glossary, BPMN/UML, data dictionary, OpenAPI, traceability matrix, decision log и версии нормативных оснований.

Нормативная основа и официальные материалы

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