Добавить в корзинуПозвонить
Найти в Дзене

Статья 12. 1С:ERP — Этап 5: права и готовность к миграции. Профили доступа, регламенты и чек‑листы (Артефакт №30 + Артефакты 32–38)

Есть два типа запусков 1С:ERP. Первый — когда предприятие переходит спокойно.
Второй — когда в день запуска выясняется, что: Разница между этими сценариями почти всегда одна: готовность была подтверждена артефактами — или была “на ощущениях”. Артефакты 30 и 32–38 превращают миграцию из аврала в управляемую операцию. Почему права доступа нельзя настроить в день запуска? Мы же админы, быстро дадим права. Зачем столько чек‑листов и регламентов? Давайте просто перенесём остатки и начнём работать. Права доступа и готовность — это не “второстепенные мелочи”. Это то, что определяет, будет ли запуск: Потому что в день запуска вы уже не управляетесь: И дальше всё идёт по наклонной: Потому что миграция — это операция с кучей зависимостей. Если что-то не готово (НСИ, инструменты переноса, параметры, права), перенос либо не получится, либо получится “криво”, а потом вы будете лечить последствия на живой системе. Профили групп доступа — это описанные наборы прав под роли: кто какие объекты видит, ч
Оглавление

Есть два типа запусков 1С:ERP.

Первый — когда предприятие переходит спокойно.
Второй — когда в день запуска выясняется, что:

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

Разница между этими сценариями почти всегда одна:

готовность была подтверждена артефактами — или была “на ощущениях”.

Артефакты 30 и 32–38 превращают миграцию из аврала в управляемую операцию.

Вопрос подписчика

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

Зачем столько чек‑листов и регламентов? Давайте просто перенесём остатки и начнём работать.

Суть проблемы

Права доступа и готовность — это не “второстепенные мелочи”.

Это то, что определяет, будет ли запуск:

  • управляемым переходом,
    или
  • лотереей.

Почему “права в день запуска” — почти всегда провал

Потому что в день запуска вы уже не управляетесь:

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

И дальше всё идёт по наклонной:

  • права начинают выдавать “шире, чем надо”,
  • контроль рушится,
  • данные портятся,
  • отчёты теряют доверие.

Почему “без чек‑листов быстрее” — самообман

Потому что миграция — это операция с кучей зависимостей.

Если что-то не готово (НСИ, инструменты переноса, параметры, права), перенос либо не получится, либо получится “криво”, а потом вы будете лечить последствия на живой системе.

Артефакты статьи

  • Артефакт №30 — Типовые профили групп доступа
  • Артефакт №32 — Регламент подготовки и проверки миграции
  • Артефакт №33 — Чек‑лист готовности целевой базы
  • Артефакт №34 — Проверка готовности данных НСИ
  • Артефакт №35 — Проверка готовности инструментов переноса
  • Артефакт №36 — Проверка настройки профилей доступа
  • Артефакт №37 — Реестр инструкций для пользователей
  • Артефакт №38 — Регламент работы пользователей в процессе миграции

Артефакт №30: типовые профили групп доступа

Что это такое (определение)

Профили групп доступа — это описанные наборы прав под роли: кто какие объекты видит, что может создавать/проводить, к каким складам/организациям/отчетам имеет доступ.

Коротко:

Если роль не определена и не проверена — роль в системе не существует.

Что входит в профили доступа

  • перечень ролей предприятия;
  • типовые профили под роли;
  • доступ к объектам (документы/справочники/отчёты);
  • ограничения по организациям/складам/подразделениям;
  • типовые сценарии, которые роль обязана проходить;
  • правила запроса нетиповых прав.

Артефакт №32: регламент подготовки и проверки миграции

Что это такое (определение)

Регламент миграции — кто что делает, в какой последовательности, какими инструментами и с какими контрольными точками.

Коротко:

Регламент нужен, чтобы миграция не была “героизмом”, а была технологией.

Что обычно внутри:

  • последовательность действий;
  • ответственные;
  • контрольные точки;
  • инструменты;
  • план коммуникаций.

Артефакт №33: чек‑лист готовности целевой базы

Что это такое (определение)

Чек‑лист готовности базы — перечень подтверждений “целевой контур готов”.

Это снимает “ощущения” и заменяет их фактом.

Обычно проверяется:

  • подсистемы/параметры;
  • НСИ;
  • интеграции;
  • тестовые прогоны.

Артефакт №34: проверка готовности НСИ

Что это такое (определение)

Готовность НСИ — проверка полноты и качества справочников/аналитик до переноса.

Обычно это:

  • дубли;
  • обязательные поля;
  • классификаторы;
  • владельцы НСИ;
  • правила ведения.

Коротко:

Грязная НСИ — это грязные отчёты. Другого не бывает.

Артефакт №35: готовность инструментов переноса

Что это такое (определение)

Готовность инструментов переноса — проверка выгрузок/обработок/скриптов/доступов к техсреде.

Обычно проверяется:

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

Артефакт №36: проверка настройки профилей доступа

Что это такое (определение)

Проверка профилей доступа — подтверждение, что каждый профиль проходит ключевые сценарии.

Именно здесь выявляются разрывы:

  • не хватает прав на документ;
  • нет доступа к складу;
  • закрыт отчёт;
  • запрещено действие, без которого процесс не работает.

Формат проверки:

  • матрица ролей;
  • прогон сценариев;
  • фиксация разрывов;
  • решение: типовой профиль / нетиповой профиль / уточнение процесса.

Артефакт №37: реестр инструкций для пользователей

Что это такое (определение)

Реестр инструкций — список инструкций (ОИК/ROI), кому какую выдаём и по каким ролям.

Это нужно, чтобы обучение было не «сборником ссылок», а управляемым контуром:

  • роль → инструкция → сценарий → проверка.

Внутри реестра:

  • список инструкций;
  • роль → инструкция;
  • версия;
  • ответственный за актуальность.

Артефакт №38: регламент работы пользователей в процессе миграции

Что это такое (определение)

Регламент работы пользователей в миграцию — правила переходного периода:

  • кто где работает;
  • что запрещено вводить;
  • какие окна переноса;
  • что делать при ошибке;
  • как фиксировать инциденты.

Коротко:

Регламент 38 нужен, чтобы миграция не была “двойной реальностью”, где все продолжают вводить в старой системе.

Как 30 и 32–38 прошивают слои TOGAF/ArchiMate

  • Бизнес: роли становятся реальными, а не “в общем”.
  • Данные: НСИ подтверждается до переноса.
  • Приложения: сценарии проходят в целевой базе.
  • Техслой: инструменты переноса и доступы готовы.
  • Управление: миграция становится управляемой операцией, а не авралом.

Цепочка «30 и 32–38 → следующий этап»

  • 30/36/37 → 43: приёмочные испытания (кто что тестирует и по каким сценариям).
  • 32–35 → 39–42: резервная копия, выгрузки, закрытие периода, сверки.
  • 38 → 45: приказ точки перехода и заморозка ввода.

Хороший сценарий

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

Плохой сценарий

  • права “в день запуска”;
  • чек‑листов нет;
  • НСИ грязная;
  • инструменты переноса не проверены;
  • в день перехода хаос и остановка работы.

Итог простыми словами

Права и готовность — это то, что делает миграцию безопасной.

Без этого запуск — лотерея.

Мини‑чеклист для заказчика

  1. Есть роли и профили доступа.
  2. Профили проверены на сценариях.
  3. Есть регламент миграции.
  4. Чек‑лист готовности базы закрыт.
  5. НСИ проверена.
  6. Инструменты переноса проверены.
  7. Пользователи знают правила перехода.

Что дальше

Следующая статья: Артефакты 39–45 — миграция и запуск: резервная копия, выгрузки, закрытие периода, сверки, испытания и приказ точки перехода.

Там покажу “сам день перехода” как технологию, а не как аврал.