Консультант 1С: от основ до уверенной работы на проектах

Роль консультанта 1С: обязанности, компетенции, зоны ответственности

Кто такой консультант 1С

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

Если упростить, консультант 1С отвечает за то, чтобы:

бизнес-потребность была понята и зафиксирована

в 1С было реализовано решение, которое эту потребность закрывает

пользователи могли работать в системе без постоянных «пожаров»

Для ориентира по экосистеме 1С полезны официальные ресурсы: 1С:Предприятие 8 и 1С:ИТС.

Где консультант 1С находится в проекте

Консультант 1С почти всегда работает на стыке нескольких сторон:

заказчик и ключевые пользователи

бухгалтерия, финансовый контур, склад, продажи, производство (в зависимости от проекта)

разработчики 1С

тестировщики, администраторы, методологи

руководитель проекта

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

Основные обязанности консультанта 1С

Обязанности зависят от типа проекта (внедрение, развитие, сопровождение), но ядро роли обычно стабильно.

Работа с требованиями и процессами

Консультант отвечает за то, чтобы запрос бизнеса был превращён в чёткое, проверяемое описание.

Типичные действия:

выявлять потребности и ограничения (что нужно, к какому сроку, какие риски)

описывать бизнес-процесс и точки автоматизации

согласовывать правила учёта и регламенты (например, как вести НДС, как закрывать месяц)

фиксировать требования так, чтобы их можно было проверить на тестировании и приемке

Настройка 1С и постановка задач на доработку

Консультант выбирает, как закрыть требование:

типовой функциональностью

настройками (параметры учета, роли, интерфейсы, печатные формы из типовых механизмов)

доработкой (когда типового недостаточно или есть специфическая интеграция)

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

Тестирование и приемка результатов

Консультант помогает команде убедиться, что получилось именно то, что нужно бизнесу:

готовит тестовые сценарии и тестовые данные (или помогает пользователям их подготовить)

проверяет соответствие требованиям

принимает работу у разработчика и объясняет пользователям изменения

Внедрение, обучение и поддержка пользователей

Даже хорошее решение может провалиться без внедрения.

Консультант обычно:

готовит инструкции и проводит обучение

помогает в опытной эксплуатации

собирает обратную связь и превращает её в задачи на улучшение

помогает разбирать инциденты (что сломалось, как воспроизвести, кто и что делает дальше)

Зоны ответственности: что “обязан” обеспечить консультант

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

Качество понимания задачи

Консультант отвечает за то, чтобы:

требования были однозначны

терминология была единой (что такое «заказ», «реализация», «партия», «себестоимость» именно у этого клиента)

не было «плавающего смысла» при передаче задачи в разработку

Выбор способа реализации

Одна из самых ценных компетенций — предложить разумный путь:

типовое решение предпочтительнее доработки, если закрывает потребность

доработка оправдана, если без неё нельзя соблюсти закон, критичный процесс или интеграцию

«быстро и грязно» — это тоже решение, но консультант обязан обозначить последствия (долг, риски поддержки)

Коммуникация и согласование

Консультант несёт ответственность за то, чтобы все стороны одинаково понимали:

что делаем

зачем делаем

что будет в результате

как и когда это будет проверяться

Управление изменениями (change management) на своём участке

В проектах 1С требования меняются постоянно. Консультант отвечает за то, чтобы изменения:

фиксировались и не «просачивались» в работу разработчиков устно

оценивались по влиянию (сроки, деньги, риски)

согласовывались с заказчиком и руководителем проекта

Границы роли: за что консультант не должен отвечать в одиночку

Путаница ролей — частая причина конфликтов. Ниже — типичные границы.

Консультант 1С обычно не является:

руководителем проекта (не обязан сам собирать план, бюджет и управлять всей командой)

системным архитектором (не всегда принимает решения по архитектуре кластера, отказоустойчивости, CI/CD)

разработчиком (может уметь, но роль консультанта — не «писать код вместо всех»)

главным бухгалтером/финансовым директором заказчика (не утверждает учетную политику за бизнес)

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

Компетенции консультанта 1С

Компетенции удобно разделить на три группы: предметные, технические и коммуникационные.

Предметные (бизнес) компетенции

Это понимание того, как устроен учет и процессы.

Частые области:

бухгалтерский и налоговый учет

управленческий учет и финансовый анализ

склад, закупки, продажи, производство

документооборот и регламентированные процессы

Важно: консультант не обязан знать всё сразу, но должен уметь быстро разбираться и задавать правильные вопросы.

Технические компетенции в рамках 1С

Консультант должен уверенно ориентироваться в:

типовых конфигурациях (что уже есть «из коробки»)

настройках учета и прав

механизмах обменов и интеграций на уровне требований (что и с чем обменивается, какие справочники и документы участвуют)

диагностике пользовательских ошибок (как локализовать проблему до понятного описания)

Если консультант понимает базовые принципы платформы (объекты метаданных, роли, формы, отчеты), ему проще общаться с разработкой и принимать решения без лишних итераций.

Коммуникационные и организационные компетенции

На практике именно они отличают сильного консультанта.

Критично важно:

вести интервью и фиксировать договоренности

объяснять сложное простым языком

управлять ожиданиями (что реально сделать за срок, а что нет)

работать с конфликтами (например, бухгалтерия хочет одно, продажи — другое)

Артефакты (результаты работы), которые ожидают от консультанта

В разных компаниях формы разные, но смысл одинаков.

Чаще всего консультант готовит:

описание процессов как есть и как будет

требования (в любом согласованном формате)

постановки задач на доработку

сценарии тестирования и приемки

инструкции и материалы обучения

перечень известных ограничений и допущений (что не делаем и почему)

Как распределяются роли: пример RACI

RACI помогает договориться, кто делает, кто принимает, кого привлекают, кого информируют.

Обозначения:

R (Responsible) — выполняет работу

A (Accountable) — отвечает за итоговое решение/приемку

C (Consulted) — консультирует, участвует

I (Informed) — информируется

| Активность | Консультант 1С | Заказчик/ключевой пользователь | Разработчик 1С | Руководитель проекта | Тестировщик | |---|---|---|---|---|---| | Сбор требований | R | A | C | C | I | | Выбор варианта реализации (типовое/доработка) | R | A | C | C | I | | Постановка задачи разработчику | R | C | A | I | I | | Разработка | C | I | R | I | I | | Тестирование | C | C | C | I | R | | Приемка | R | A | C | I | C | | Обучение пользователей | R | A | I | I | I |

Важно: это пример. На реальном проекте роли могут смещаться (например, в маленькой команде консультант частично тестирует, а руководитель проекта может быть со стороны подрядчика или заказчика).

Типичные ошибки начинающего консультанта и как их избежать

Ниже — ошибки, которые чаще всего «ломают» проекты на уровне анализа и внедрения.

Обсуждать требования устно и не фиксировать договоренности.

Обещать сроки без согласования с разработкой и руководителем проекта.

Сразу предлагать доработку, не проверив типовой функционал.

Писать постановку «в общих словах» без критериев приемки и примеров данных.

Пытаться быть «универсальным солдатом» и закрывать роль разработчика, методолога и РП одновременно без явного согласования.

Что будет дальше в курсе

Эта статья задаёт рамки роли: что делает консультант 1С и за что отвечает. Далее в курсе логично перейти к практическим инструментам работы консультанта:

как собирать требования и проводить интервью

как описывать процессы и формулировать требования без двусмысленности

как делать постановки задач на разработку и критерии приемки

как организовывать тестирование и обучение пользователей

Оперативный контур: закупки, продажи, склад, производство, взаиморасчеты

Зачем консультанту 1С понимать оперативный контур

Оперативный контур — это часть учета, где система помогает бизнесу управлять текущими процессами: продавать, закупать, обеспечивать склад, выпускать продукцию, контролировать долги и оплаты. В отличие от регламентированного учета (где «экзамен» — отчетность и закрытие месяца), в оперативном контуре «экзамен» происходит каждый день: заказы, отгрузки, дефициты, сроки, остатки, резервы.

Связь с предыдущими темами курса:

после AS-IS и TO-BE оперативный контур обычно первым «обкатывают» на пилоте, потому что пользователи быстро видят эффект

требования и документация здесь должны быть особенно сценарными: один процесс тянет за собой другой (заказ → обеспечение → отгрузка → взаиморасчеты)

настройка типового функционала часто закрывает 70–80% запросов, если правильно выбрать параметры, политики и табличные настройки

ошибки оперативного контура почти всегда «долетят» до финансов и регучета: неверные остатки, неверные цены, неверная аналитика взаиморасчетов

Типовые конфигурации, где оперативный контур выражен сильнее всего:

1С:Управление торговлей

1С:ERP Управление предприятием

Что такое оперативный контур в терминах процессов и данных

Оперативный контур удобно понимать как связку:

процессы (что делают роли)

документы (какие события фиксируются)

мастер-данные (какие справочники должны быть качественными)

учетные результаты (остатки, резервы, задолженность, себестоимость управленческого контура)

Типовая «сквозная цепочка»

Ниже — самый частый каркас процессов для торговли и производства.

!Сквозная цепочка показывает, как один документ порождает потребности и движения в соседних контурах

Где чаще всего «живет истина»

В проектировании TO-BE консультант фиксирует «одну версию правды» по ключевым сущностям:

товары и их параметры (номенклатура, единицы, ставки НДС, характеристики)

остатки и резервы (какой склад и какая логика контроля)

цены и скидки (где утверждаются и как контролируются)

взаиморасчеты (на каком уровне ведем: контрагент, договор, заказ, документ)

Если это не зафиксировать, проект почти неизбежно приходит к:

двойному вводу

расхождениям по остаткам и задолженности

конфликтам между продажами, складом и бухгалтерией

Мастер-данные: что обязательно привести в порядок до запуска

Оперативный контур особенно чувствителен к качеству справочников. Консультант не обязан «чистить данные руками», но обязан:

выявить критичные справочники

описать правила ведения

закрепить владельцев и регламент изменений

Минимальный набор мастер-данных

| Сущность | Что важно договорить | Типовые риски при плохих данных | |---|---|---| | Номенклатура | единицы, ставки НДС, группы, характеристики/серии, правила закупки/продажи | пересортица, неверные цены, ошибки в отгрузке и документах | | Склады | структура складов, адресность/ячейки (если применимо), запреты отрицательных остатков | «товар есть по отчету, но отгрузить нельзя» | | Контрагенты и договоры | дубли, реквизиты, условия оплаты, валюты | «задолженность не сходится», ошибки в оплатах | | Цены/прайсы | виды цен, правила скидок, условия действия | ручные правки, «разъезд» маржи | | Организации/подразделения | кто ведет, как использовать в документах | документы «не туда», неверная аналитика |

Продажи: от лида и заказа до отгрузки

В оперативном контуре продажи — это управление обещаниями клиенту: срок, цена, наличие.

Ключевые вопросы консультанта при проектировании продаж

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

нужна ли фиксация условий: дата отгрузки, базис поставки, резерв, предоплата

как управляем скидками и отклонениями от прайса

кто имеет право менять цену и кто согласует

Типовой набор сценариев TO-BE для продаж

Заказ клиента создается менеджером.

Цена рассчитывается по правилам и при превышении порога скидки запускается согласование.

Система показывает доступность: остаток, резерв, ожидаемое поступление.

При готовности формируется отгрузка со склада.

По результату формируются закрывающие документы по принятой модели (в этой базе или в регучете).

Самые частые ошибки в продажах

нет правила, что считать «доступным» (остаток без учета резервов, или с учетом, или по будущим поступлениям)

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

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

Закупки: обеспечение потребностей и контроль сроков

Закупки в 1С-контурах редко «просто ввод документов». Обычно это управление дефицитами и сроками.

Ключевые вопросы консультанта по закупкам

откуда появляется потребность: вручную, из заказов клиентов, из планирования, из производства

как выбираем поставщика: по договору, по прайсу, по минимальной цене, по сроку

как контролируем даты поставки и частичные поставки

нужна ли приемка по ордерам и раздельные роли «закупщик/кладовщик»

Типовой цикл закупки

формируем потребность (дефицит)

оформляем заказ поставщику

получаем поступление (с контролем количества/качества)

отражаем расхождения и закрываем «хвосты» по недопоставке

Частые причины провала закупочного контура

потребности не связаны с заказами и резервами, закупают «по ощущениям»

нет статусов и дисциплины: заказ поставщику создан, но никто не контролирует срок

приемка делается «задним числом», и продажи не видят реальной картины

Склад: остатки, резервы, ордерная схема, инвентаризация

Склад — зона, где ошибки особенно видны: «товар на отчете есть, отгрузить нельзя».

Что консультант должен прояснить по складу

контроль отрицательных остатков: разрешаем или запрещаем и в каких ситуациях

используем ли резервирование и на каком уровне (по складу, по ячейкам, по сериям)

нужна ли ордерная схема (разделение управленческого документа и фактических складских операций)

нужны ли адресное хранение, ТСД, отдельная WMS (и где граница систем)

Типовые операции склада

приемка

размещение

отбор/комплектация

отгрузка

перемещение

инвентаризация

!Схема показывает разделение ролей и документов между закупкой, складом и продажами

Антипаттерны склада

«виртуальные склады» без правил, чтобы обходить дефицит

широкие права на проведение и исправления у всех ролей

отсутствие инвентаризации как процесса, из-за чего расхождения копятся и становятся «нормой»

Производство: от потребности к выпуску

Производственный контур может быть как легким (простая сборка), так и сложным (планирование, маршруты, полуфабрикаты). Консультанту важно определить уровень управляемости, который реально нужен бизнесу.

Минимальные сущности, которые обычно нужно согласовать

номенклатура: материалы, полуфабрикаты, готовая продукция

спецификации (состав изделия) и нормы расхода

этапы: заказ на производство, выпуск, списание материалов

склады: где лежат материалы и куда поступает выпуск

Вопросы, которые определяют сложность проекта

нужен ли учет по партиям/сериям в производстве

нужны ли замены материалов и как их согласовывают

нужна ли пооперационная детализация или достаточно «выпуск за смену»

как считать фактические затраты и себестоимость в выбранной методике

> В производстве особенно важно не перепутать TO-BE и «мечты»: если у предприятия нет дисциплины первички, запуск сложного планирования чаще всего дает сопротивление и формальные данные.

Взаиморасчеты: долги, оплаты, зачеты

В оперативном контуре взаиморасчеты нужны не только для бухгалтерии. Продажи хотят понимать:

клиент платит или нет

можно ли отгружать без предоплаты

какие лимиты и просрочки

Что консультант фиксирует в TO-BE по взаиморасчетам

уровень аналитики: контрагент, договор, заказ, документ

правила отгрузки: разрешена ли отгрузка при долге, при просрочке, без предоплаты

лимиты: кредитный лимит, лимит по просрочке, лимит по сумме заказов

порядок зачетов (авансы, частичные оплаты)

Типовые ошибки взаиморасчетов

«долг» считают по разным правилам в разных системах

оплаты не сопоставляются с документами, копится «неразнесенка»

нет регламента: кто отвечает за корректное разнесение оплат и в какие сроки

Как консультанту «приземлять» оперативный контур на объекты 1С

Опираемся на базовые понятия платформы из прошлых тем: справочники, документы, регистры, отчеты, роли.

Упрощенная карта соответствий

| Бизнес-смысл | Что это в 1С чаще всего | Пример | |---|---|---| | постоянная сущность | справочник | номенклатура, контрагенты | | событие в процессе | документ | заказ, поступление, реализация | | учет результата | регистр | остатки, резервы, взаиморасчеты | | анализ и контроль | отчет | дефицит, просрочка, валовая прибыль | | массовое действие | обработка | загрузка прайса, сопоставление оплат |

Критичный момент: консультант не обязан описывать «как сделать в коде», но обязан так зафиксировать сценарий и правила, чтобы команда могла понять:

какие документы участвуют

какие движения и проверки ожидаются

как это тестировать

Контроли и показатели оперативного контура

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

Примеры контрольных отчетов и проверок

дефицит по заказам клиентов

просроченные заказы поставщикам

отгрузки без резерва (если резерв обязателен)

отрицательные остатки (если запрещены)

просроченная дебиторская задолженность

заказы клиентов без даты отгрузки или без согласованной скидки

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

Хороший контроль должен быть:

привязан к роли (кто смотрит)

привязан к действию (что делаем при отклонении)

привязан к частоте (каждый день, перед отгрузкой, перед закрытием)

Границы с регламентированным учетом и интеграциями

Связь с прошлой статьей про финансы и регучет здесь ключевая: оперативный контур не должен создавать «вторую бухгалтерию» без договоренностей.

Типовые варианты границ

оперативный контур в УТ, регучет в Бухгалтерии, обмен документами и справочниками

оперативный и регламентированный контур в ERP, но с разграничением ролей и политик

Что консультант обязан зафиксировать:

где формируются юридически значимые документы

где печатаются первичные формы

что является источником по задолженности и по остаткам

что делаем при расхождениях и кто отвечает за исправления

Ресурс для методических разъяснений по типовым механизмам и практике ведения учета: 1С:ИТС.

Типовые ошибки консультанта при описании оперативного контура

описать продажи отдельно от склада и закупок, без «сквозной цепочки»

не договориться, что такое доступный остаток и как он учитывает резервы

запустить контур без владельцев мастер-данных и без регламента изменений

дать широкие права «на запуск», после чего процесс начинают обходить

не включить взаиморасчеты в сценарии (в итоге отгружают «кому угодно и сколько угодно»)

Практичные артефакты консультанта для оперативного контура

Чтобы перейти от TO-BE к реализации и приемке, обычно достаточно следующего набора:

схема сквозного процесса (заказ → обеспечение → отгрузка → оплата)

сценарии (основной и 3–5 ключевых исключений)

регламент (кто что делает, какие сроки, что запрещено)

матрица ролей и прав (особенно на проведение, исправления и «задние даты»)

реестр настроек (параметры/политики/табличные правила) с датой начала действия

список контрольных отчетов и порядок реакции на отклонения

Итоги

Оперативный контур в 1С — это управляемая система повседневных процессов: закупки, продажи, склад, производство и взаиморасчеты.

Ключевые мысли для консультанта:

думайте сквозным процессом, а не отдельными разделами

закрепляйте «одну версию правды» по остаткам, ценам и задолженности

начинайте с типовой логики и настроек, но фиксируйте их как проверяемые правила

качество мастер-данных и права доступа — часть проектирования, а не «потом разберемся»

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

Кадры и зарплата (ЗУП): кадровые события, начисления, отчетность

Зачем консультанту 1С разбираться в ЗУП

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

HR и кадровое делопроизводство

расчетчики зарплаты

бухгалтерия (налоги, взносы, отражение затрат)

руководители подразделений (штат, графики, табели)

ИТ (интеграции, доступы, обмены)

Связь с предыдущими темами курса:

из AS-IS вы приносите факты о реальных правилах кадровых событий и учета времени

в TO-BE вы фиксируете целевой регламент: кто и когда вводит кадровые документы, кто закрывает табель, кто пересчитывает зарплату

требования в ЗУП должны быть проверяемыми через сценарии: кадровое событие → учет времени → начисление → удержание → налоги/взносы → отчетность → выгрузка в бухучет

прежде чем идти в доработку, консультант проверяет типовые механизмы и настройки, потому что ЗУП часто закрывает запросы без изменения кода

Официальные точки входа:

1С:Зарплата и управление персоналом

1С:ИТС

Каркас ЗУП: что именно ведем в системе

Чтобы уверенно разговаривать с пользователями, консультанту полезно держать в голове три слоя:

кадровые данные (кто работает и на каких условиях)

учет времени и событий (когда и что происходило)

расчет и результат (сколько начислить/удержать и что отчитаться)

Основные сущности в терминах 1С

В терминах платформы (из темы про метаданные) это обычно выглядит так:

справочники: сотрудники, физлица, организации, подразделения, должности

документы: прием, перевод, увольнение, отпуск, больничный, командировка, начисление зарплаты

регистры: результаты расчетов, учет рабочего времени, параметры начислений и удержаний

отчеты: расчетные листки, анализ начислений, контрольные отчеты перед сдачей

Важно: конкретные названия объектов и меню зависят от версии и редакции ЗУП, но логика в проектах остается одинаковой.

!Сквозная логика ЗУП: от кадровых событий до отчетности и отражения в учете

Кадровые события: что фиксируется и почему это важно для расчета

Кадровое событие — это формально зафиксированное изменение статуса сотрудника или условий его работы. В ЗУП кадровые события важны не только для «кадровых документов», но и как входные данные для расчета.

Базовые кадровые события

Чаще всего в проектах «ядро» выглядит так:

прием на работу

кадровый перевод (подразделение, должность, условия оплаты, график)

увольнение

изменение условий оплаты (оклад, тариф, надбавки)

изменения занятости (совместительство, неполное время — если применимо)

Типовые вопросы консультанта на обследовании

Чтобы не получить ситуацию «в системе красиво, но зарплата считается не так», консультант на старте уточняет:

кто является источником правды по штатной структуре (HR или руководители)

как часто происходят переводы и изменения оплат, кто их инициирует

есть ли строгий кадровый регламент или многое делается «по факту и задним числом»

какие категории персонала есть (офис, сменные, сдельщики, дистанционные)

Типовые ошибки в кадровом контуре

кадровые события вводят после расчета, из-за чего появляются перерасчеты и «хвосты»

нет единого правила по датам: событие оформляют «как удобно», а не как должно быть по документам

не закреплен владелец данных: разные подразделения меняют одни и те же данные разными способами

Учет времени: графики, табель, отсутствия

ЗУП сильно зависит от учета времени: даже при фиксированном окладе важны отработанные дни, отсутствие, переработки, ночные, праздничные.

Базовые понятия (простыми словами)

график работы: календарь и норма времени для сотрудника или группы

табель: фактическое время и отклонения от нормы

отсутствия: отпуска, больничные, командировки, прогулы и прочие статусы

Что консультант обязан зафиксировать в TO-BE

Если в прошлой теме вы моделировали TO-BE через сценарии и регламенты, то для учета времени важно согласовать:

кто ведет графики и кто имеет право их менять

кто отвечает за табель и с какой периодичностью он закрывается

какие отсутствия вводятся кадровиками, а какие подтверждаются руководителями

что считается моментом «данные готовы к расчету зарплаты»

Практический риск

Если табель закрывается поздно или ведется «в Excel», расчет будет постоянно пересчитываться. Для консультанта это не «ошибка пользователей», а непроектированный процесс, который нужно зафиксировать регламентом.

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

В ЗУП пользователи часто формулируют запросы как «сделайте начисление» или «поменяйте формулу». Консультант переводит это в проверяемую постановку через методику.

Термины, которые важно определить

начисление: то, что увеличивает доход сотрудника (оклад, премия, доплата)

удержание: то, что уменьшает сумму к выплате (исполнительные листы, удержания за питание и т.д.)

база начисления: от каких показателей считается начисление (время, выработка, процент)

период расчета: за какой месяц/период считаем

Мини-шаблон описания начисления для требований

Чтобы требование было проверяемым (как в теме про документацию), полезно фиксировать:

назначение начисления (зачем оно и кому)

условия применения (кому положено и при каких условиях)

входные данные (оклад, ставка, отработанное время, показатель KPI)

правило расчета (словами, на примере)

ограничения и исключения (не начислять в отпуске, начислять пропорционально)

отражение в учете (на какие статьи затрат и подразделения)

критерии приемки (какие примеры должны сойтись)

Что чаще всего ломает расчет

недоописанные показатели (что такое KPI, откуда он берется, кто вводит)

смешение кадровой и расчетной логики (оклад меняют «в документе начисления», а не через кадровое событие)

отсутствие единого справочника оснований и правил (премия есть, но у каждого подразделения своя трактовка)

Налоги и взносы: зона высокой ответственности

Внутри ЗУП значительная часть логики опирается на законодательные требования. Консультант не «придумывает правила», но должен обеспечить управляемость процесса:

какие начисления облагаются какими налогами и взносами (по принятой методике и типовой логике)

кто контролирует корректность перед сдачей отчетности

как обрабатывают перерасчеты прошлых периодов

Практическое правило роли (из первой статьи курса): если есть спорная методика, консультант фиксирует варианты и последствия и выносит решение на уполномоченных лиц.

Отчетность: что сдаем и как консультанту проектировать контроль

Отчетность по персоналу — это не только «выгрузить форму», а процесс контроля качества данных.

Как смотреть на отчетность правильно

Отчетность опирается на:

кадровые данные (кто, когда принят/уволен, статусы)

учет времени (для части расчетов и подтверждений)

результаты начислений и удержаний

настройки и справочники (организации, подразделения, виды доходов)

Поэтому задача консультанта — обеспечить не только формирование отчета, но и контрольные шаги до него.

Примеры контрольных процедур, которые стоит включать в регламент

проверка незакрытых кадровых документов в периоде

проверка незаполненных обязательных реквизитов сотрудников

контроль «хвостов» перерасчетов

сверка выплат с начислениями (что начислили и что реально выплатили)

Выплата: как связать расчет, ведомости и ответственность

Выплата зарплаты — это связка нескольких ролей и документов. Даже если пользователи говорят «зарплата посчитана», проект может провалиться на этапе выплаты.

Консультанту важно зафиксировать:

кто формирует ведомости и кто утверждает суммы

какие способы выплаты используются (банк, касса, смешанный вариант)

как обрабатываются удержания и исполнительные листы

как фиксируются возвраты и депонирование (если применяется)

Отражение зарплаты в учете: граница ЗУП и бухгалтерии/ERP

В реальных проектах ЗУП редко живет «в одиночку». Чаще есть один из вариантов:

ЗУП рассчитывает зарплату, а результаты передаются в бухгалтерию для регламентированного учета

ЗУП интегрирован с ERP, где затраты по зарплате участвуют в себестоимости и финансовом результате

В терминах курса (из тем про экосистему и типовые конфигурации) консультант должен зафиксировать «одну версию правды»:

где ведутся сотрудники и подразделения как мастер-данные

где формируется юридически значимая первичка по выплатам (по модели клиента)

кто отвечает за расхождения между системами и как их диагностируют

Мини-таблица для фиксации границ обмена

| Объект | Источник (мастер) | Получатель | Как часто | Кто отвечает за качество | |---|---|---|---|---| | Сотрудники/Физлица | ЗУП | Бухгалтерия/ERP | По событию или по регламенту | HR | | Начисления (результат) | ЗУП | Бухгалтерия/ERP | Ежемесячно | Расчетчик | | Выплаты (факт) | ЗУП или Бухгалтерия (по модели) | Соседняя система | Ежемесячно/по выплатам | Казначейство/Бухгалтер | | Подразделения/статьи затрат | По договоренности | ЗУП | По изменениям | Финансы/HR |

Права и роли в ЗУП: почему это часть методики

Из темы про TO-BE важно помнить: права поддерживают процесс. В ЗУП это особенно критично, потому что ошибка доступа может превратиться в ошибку расчета.

Типовое разделение ролей, которое стоит закладывать в матрицу ролей и прав:

кадровик: ввод кадровых событий и данных сотрудников

табельщик или руководитель: ввод/подтверждение времени и отсутствий (по принятому процессу)

расчетчик: расчет начислений, перерасчеты, формирование ведомостей

бухгалтер: контроль отражения в учете, контроль отчетности (в зависимости от распределения функций)

Типовые антипаттерны:

«на запуск дадим всем полные права»

нет запрета на изменение документов прошлых периодов

нет ответственного за исправление ошибок данных, из-за чего расчетчик начинает «чинить справочники» без регламента

Как консультанту превращать запросы по ЗУП в проверяемые требования

Ниже — практические примеры перевода «языка пользователя» в управляемые требования.

Пример запроса про кадровое событие

Запрос: «Нужно, чтобы перевод сотрудника автоматически менял условия оплаты и график».

Что уточняет консультант:

с какого числа действует перевод

какие именно условия оплаты меняются

как фиксируется график и кто его утверждает

Как фиксировать в требовании:

сценарий: кадровик оформляет перевод с датой, система применяет новые условия с этой даты

критерии приемки: расчет зарплаты за месяц корректно учитывает дни до и после перевода

Пример запроса про начисление

Запрос: «Нужна премия 20% от оклада, но только если сотрудник отработал полный месяц».

Что уточняет консультант:

что считать «полным месяцем» (нет отпусков? нет больничных? по норме часов?)

что делать в исключениях (часть месяца, прием/увольнение)

Как фиксировать:

условия применения и исключения

пример расчета на двух кейсах (полный месяц и неполный)

критерии приемки: на тестовых данных сумма совпадает с методикой

Пример запроса про отчетность

Запрос: «Не сходится отчетность, исправьте».

Как действует консультант:

переводит запрос в диагностируемый список: какая форма, за какой период, какие ошибки/контрольные соотношения

определяет источник расхождения: кадровые данные, начисления, выплаты, перерасчеты

фиксирует регламент контроля: какие отчеты проверяем до сдачи и кто отвечает за исправления

Итоги

ЗУП — один из самых методически чувствительных контуров 1С: он объединяет кадровые события, учет времени, сложные начисления и обязательную отчетность.

Ключевые выводы для консультанта 1С:

проектируйте ЗУП сквозным сценарием: кадры → время → расчет → выплата → отчетность → отражение в учете

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

не отделяйте права от процесса: матрица ролей и прав — часть работоспособного TO-BE

заранее определяйте границы интеграции ЗУП с бухгалтерией или ERP и «точку истины» по мастер-данным

Постановка задач разработчикам: декомпозиция, критерии приемки, контроль

Зачем консультанту 1С уметь ставить задачи разработчикам

Консультант 1С почти никогда не «просто передает пожелание». Его работа — превратить результаты AS-IS/TO-BE, требования и выбранный способ реализации (типовая настройка или доработка) в такие задачи, по которым разработчик сможет:

однозначно понять, что нужно изменить

реализовать без догадок и лишних итераций

покрыть изменения тестами

показать результат так, чтобы приемка прошла по заранее понятным правилам

Связь с предыдущими темами курса:

из TO-BE вы берете сценарии и регламенты, которые должны «ожить» в системе

из темы про требования и документацию вы берете проверяемость и трассируемость

из темы про настройки типового функционала — понимание, что не все задачи должны уходить в разработку

из тем про финансы/оперативный контур/ЗУП — понимание, что ошибка постановки приводит не к «красивой форме», а к неправильным остаткам, проводкам, расчетам и отчетности

> Практическое правило: если по постановке нельзя написать тестовый сценарий и критерии приемки, значит постановка недостаточно конкретна.

Термины: требование, задача, доработка, критерии приемки

Чтобы не путаться в коммуникации, закрепим минимальный словарь.

Требование — проверяемое ожидание от системы на языке бизнеса (зачем и какой результат нужен).

Задача разработчику — конкретное описание изменения в 1С, достаточное для реализации и тестирования (что меняем, где, на каких объектах, какие проверки).

Декомпозиция — разбиение требования/сценария на небольшие реализуемые части (настройки, формы, печать, роли, отчеты, обмены).

Критерии приемки — условия, по которым заказчик/консультант подтверждает выполнение задачи.

Определение готовности (Definition of Done) — внутреннее правило команды, что считается завершенной задачей (например: разработано, протестировано, есть инструкции, пройдены проверки прав).

В agile-командах термины часто связывают с практиками Scrum: полезный ориентир — The Scrum Guide.

Где задача разработчику находится в цепочке артефактов

Одна из причин провалов — «прыжок» из устного запроса сразу в код без связки с TO-BE и приемкой.

Нормальная цепочка выглядит так:

TO-BE сценарий и регламент (кто что делает и какие правила)

Требование (зачем и какой результат)

Декомпозиция на изменения (настройки/доработки/права/отчеты)

Задачи разработчику (что именно сделать)

Тест-кейсы и тестовые данные (как проверяем)

Демонстрация и приемка (подтверждаем критерии)

Внедрение: перенос в продуктив, обучение, обновление инструкции

!Диаграмма показывает, как сценарии и требования превращаются в задачи, тесты и приемку.

Декомпозиция: как разбить запрос так, чтобы его можно было сделать и принять

Почему без декомпозиции постановки «не летят»

Запрос бизнеса обычно звучит как «хочу кнопку», «не сходятся цифры», «добавьте реквизит». Но реализация в 1С почти всегда затрагивает несколько слоев:

данные (что храним)

интерфейс (где вводим)

правила (какие проверки)

права (кто может)

учетный результат (движения, расчеты)

отчеты/печатные формы

обмены (если есть интеграции)

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

Практичные «оси» декомпозиции

Декомпозировать удобно не по «меню 1С», а по смысловым частям.

По бизнес-сценарию: основной поток и ключевые исключения.

По объектам 1С: справочники, документы, регистры, отчеты, обработки, роли.

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

По риску: отдельно выносить то, что влияет на регучет, закрытие месяца, расчет зарплаты.

Шаблон декомпозиции для консультанта

Ниже — компактный шаблон, который помогает не забыть критичные части.

| Вопрос | Что фиксируем | Зачем это нужно | |---|---|---| | Что меняется в процессе | шаги, статусы, проверки | связывает задачу с TO-BE | | Какие объекты 1С затрагиваем | документы, справочники, регистры, отчеты | дает точку входа разработчику | | Какие данные нужны | реквизиты, табличные части, источники | предотвращает «пустые поля» | | Какие роли участвуют | кто создает, кто проводит, кто исправляет | чтобы не сломать контроль | | Как проверяем | критерии приемки, тест-кейсы, примеры | делает приемку предсказуемой | | Что может пострадать | обмены, закрытие, расчет, производительность | помогает оценке рисков |

Структура качественной задачи разработчику

Ниже — структура, которую можно использовать в Jira/Redmine/1С:Документооборот/почте. Важно не место хранения, а полнота.

Обязательные поля задачи

Заголовок: коротко, действие + объект + правило (например: «Запрет проведения реализации без резерва»).

Контекст: ссылка на TO-BE сценарий/требование/ЧТЗ (ID или документ).

Цель изменения: какую проблему решаем и для кого.

Область: конфигурация, подсистема, затронутые документы.

Описание поведения: что должно происходить в системе.

Ограничения и исключения: 2–5 самых важных.

Роли и права: кто должен иметь доступ и какие ограничения.

Критерии приемки: проверяемые условия.

Тестовые данные: минимальный набор примеров.

Границы: что не делаем в рамках этой задачи.

Полезные поля (сильно снижают число итераций)

Макеты: скриншоты, прототипы, образцы печатных форм.

Сообщения пользователю: текст и условия, когда показываем.

Логирование/диагностика: что должно писаться в журнал, если это важно.

Влияние на обновляемость: типовой объект или расширение, если применимо.

Критерии приемки: как писать так, чтобы не спорить на демонстрации

Что не является критерием приемки

«Сделать удобно»

«Как в Excel»

«Чтобы работало быстро» без цифр и условий

«Сделать как в старой системе» без примеров

Формула хорошего критерия приемки

Критерий приемки должен быть:

проверяемым действием

привязанным к роли

с ожидаемым результатом

по возможности — на конкретных данных

Практичная форма:

кто выполняет действие

что делает

при каких условиях

что должно получиться

Когда полезен формат Given/When/Then

Если задача сложная по логике, удобно описывать критерии в Given/When/Then (это не «ритуал», а способ убрать двусмысленность).

Пример (упрощенно):

Given заказ клиента не обеспечен (резерв отсутствует)

When кладовщик пытается провести реализацию по этому заказу

Then система запрещает проведение и показывает сообщение с перечнем строк без резерва

Мини-таблица качества критериев

| Признак | Плохо | Хорошо | |---|---|---| | Проверяемость | «контролировать лимит» | «при превышении лимита проведение запрещено, сообщение содержит значение лимита и текущую сумму» | | Привязка к роли | «пользователь может» | «роль “Менеджер” может создать, но не может провести» | | Данные | «по договору» | «для договора D-001 лимит 100 000, заказ на 120 000 не проводится» |

Примеры постановок: из бизнес-языка в задачу

Важно: примеры показывают логику постановки, а не конкретные пункты меню.

Пример из оперативного контура: запрет отгрузки без резерва

Контекст: TO-BE «Отгрузка по заказу клиента с резервом», роли: менеджер, кладовщик.

Декомпозиция:

настройка/правило контроля резерва

сообщение пользователю

права: кто может обходить запрет (если вообще может)

контрольный отчет: «Отгрузки без резерва» (опционально)

Критерии приемки:

кладовщик проводит реализацию по заказу с резервом — проведение успешно

кладовщик пытается провести реализацию по заказу без резерва — проведение запрещено

сообщение содержит список строк номенклатуры и склад, где нет резерва

Пример из финансов: запрет изменения документов закрытого периода

Контекст: регламент закрытия месяца.

Декомпозиция:

настройка запрета изменений

список ролей-исключений (если есть только у бухгалтерии/админа)

сценарий «перезакрытие» и кто имеет право

Критерии приемки:

пользователь без спецправ не может изменить и перепровести документ с датой в закрытом месяце

пользователь видит понятное сообщение, что период закрыт

пользователь с ролью «Главный бухгалтер» может выполнить регламентный сценарий «исправить → перезакрыть» (если согласовано)

Пример из ЗУП: начисление премии по условию полного месяца

Контекст: методика начисления.

Декомпозиция:

настройка начисления (условия применения)

определение «полного месяца» (по норме времени/отсутствиям)

тестовые примеры: полный и неполный месяц

Критерии приемки:

сотрудник отработал полный месяц по графику — премия = 20% оклада

сотрудник был в отпуске 5 дней — премия не начисляется (если так в методике)

Контроль исполнения: как консультанту управлять задачами, не превращаясь в РП

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

Минимальный цикл контроля задачи

проверить вход: задача полная, есть критерии приемки

согласовать спорные места с владельцем процесса до разработки

ответить на вопросы разработчика (быстро, письменно, с фиксацией)

принять на демо по критериям приемки

организовать пользовательскую проверку, если требуется

обновить регламент/инструкцию, если процесс поменялся

Статусы и контрольные точки (пример)

Статусы могут быть любыми, но важно, чтобы они отражали смысл.

Новая: задача заведена, но не готова к разработке

Готова к разработке: описана, критерии есть, приоритет согласован

В разработке: разработчик выполняет

На проверке консультанта: первичная проверка по критериям

На приемке у бизнеса: проверка ключевым пользователем

Готово к внедрению: принято, есть инструкции/обучение, согласовано окно

Внедрено: перенесено в продуктив

Как не потерять связь между требованиями и задачами

Используйте трассируемость на уровне идентификаторов:

у требования есть ID

у задачи есть ссылка на ID требования/сценария

у теста есть ссылка на ID задачи

Даже простая таблица помогает.

| ID требования | ID задачи | Что проверяем | Где зафиксирована приемка | |---|---|---|---| | R-015 | DEV-128 | запрет проведения без резерва | протокол демо от 07.02 | | R-016 | DEV-129 | права на исправление закрытого периода | акт приемки этапа |

Частые провалы постановок и как их предотвращать

Неполные входные данные

Признак: разработчик спрашивает «а как должно быть?» уже после реализации.

Профилактика:

добавлять 2–3 примера документов/кейсов

фиксировать исключения

Подмена требования интерфейсом

Признак: «добавили поле», но правило процесса не работает.

Профилактика:

описывать сценарий и проверку, а не только форму

Нет границ и неоговоренные зависимости

Признак: задача «расползается», затрагивает соседние контуры.

Профилактика:

явно писать «в рамках задачи не делаем…»

фиксировать зависимости: обмены, отчеты, закрытие месяца

Не описаны роли и права

Признак: либо «никто не видит», либо «все могут всё».

Профилактика:

включать в задачу мини-матрицу: роль → действие → объект

Нет управляемого изменения требований

Признак: правки приходят устно и ломают договоренности.

Профилактика:

все изменения фиксировать как комментарий/подзадачу/новую задачу

пересогласовывать критерии приемки при изменении логики

Практический шаблон задачи (как текст)

Ниже — формат, который удобно копировать в трекер.

Название: …

Ссылка на требование/сценарий: …

Цель: …

Конфигурация/контур: …

Роли: …

Текущее поведение (если есть): …

Целевое поведение: …

Правила и проверки: …

Исключения: …

Права доступа: …

Критерии приемки:

- … - …

Тестовые данные: …

Границы (не делаем): …

Влияние/риски: …

Итоги

Постановка задач разработчикам — ключевая компетенция консультанта 1С, которая соединяет TO-BE, требования и реальную реализацию.

Главные выводы:

качественная постановка начинается с декомпозиции по процессу, объектам 1С, ролям и рискам

критерии приемки — это проверяемые условия, а не «чтобы было удобно»

контроль задачи — это управление цепочкой «требование → реализация → тест → приемка → внедрение», а не микроменеджмент разработки

трассируемость и фиксация изменений защищают проект от хаоса и споров на приемке

Интеграции и обмены: планы обмена, веб-сервисы, JSON/XML, очереди

Зачем консультанту 1С разбираться в интеграциях

Практически любой проект 1С живет не в вакууме. Рядом почти всегда есть банк, ЭДО, сайт, CRM, маркетплейсы, WMS, BI, кадровые сервисы, внешние справочники и другие учетные системы. Поэтому консультант 1С обязан уметь:

выявлять интеграции на этапе обследования AS-IS и фиксировать их как часть карты систем

проектировать границы в TO-BE: где точка истины по данным, кто владелец справочника, какая система “главнее” для документа

выбирать подход к обмену без лишних доработок и с учетом поддержки

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

Официальные точки входа по экосистеме 1С и сопровождению: 1С:Предприятие 8 и 1С:ИТС.

Базовые понятия: интеграция, обмен, синхронизация

Чтобы говорить однозначно, зафиксируем термины.

Интеграция — способ взаимодействия 1С с другими системами для передачи данных или выполнения действий.

Обмен — конкретный процесс передачи данных: что передаем, куда, как часто, как подтверждаем успех.

Синхронизация — обмен, в котором мы добиваемся согласованного состояния данных в двух (или более) системах.

Мастер-данные — справочные данные, которые используются многократно: контрагенты, номенклатура, организации, склады.

Транзакционные данные — “события”: заказы, поступления, реализации, платежи, начисления.

Ключевой принцип из предыдущих тем курса (TO-BE и требования): для каждого объекта нужно зафиксировать одну версию правды.

Виды интеграций в 1С-проектах: что встречается чаще всего

Ниже — практичная классификация подходов. Она помогает консультанту не “прыгать в технику”, а сначала выбрать правильный класс решения.

!Карта основных способов интеграции, с которыми сталкивается консультант 1С

Обмен через файлы

Системы обмениваются файлами по расписанию или по событию (папка, SFTP, почта, выгрузка пользователем).

Когда уместно:

внешняя система не предоставляет API

обмен не должен быть “онлайн”

объем и частота умеренные

Риски:

сложнее контроль целостности и повторной загрузки

выше шанс человеческого фактора (не туда положили, загрузили дважды)

Веб-сервисы и HTTP-сервисы

1С может выступать и как клиент (запрашивает/отправляет), и как сервер (к ней обращаются извне). На практике чаще всего обсуждают:

HTTP API в стиле REST (часто с JSON)

SOAP веб-сервисы (часто с XML)

Когда уместно:

нужен обмен “почти онлайн”

нужно вызывать действия (создать заказ, получить статус, проверить остатки)

важно четко контролировать контракты данных

Риски:

нужны требования к безопасности и доступности (сеть, TLS, учетные записи)

при пиковых нагрузках возможны таймауты

Планы обмена (типовой механизм синхронизации)

План обмена — механизм платформы 1С для обмена данными между информационными базами, обычно в сценариях:

распределенные базы

“центр ↔ филиалы”

синхронизация между базами 1С (например, разные контуры или разные экземпляры)

Смысл для консультанта: планы обмена — это не “любой интеграционный инструмент”, а подход, наиболее естественный для 1С ↔ 1С, где важно передавать изменения данных контролируемо.

Риски:

нужно четко определить, какие данные “живут” в какой базе

ошибки в мастер-данных и правах быстро превращаются в дубли и конфликты

Очереди сообщений и брокеры

Очередь сообщений — подход, где системы общаются через промежуточный слой (message broker). 1С публикует сообщения, другая система их потребляет (или наоборот).

Когда уместно:

требуется устойчивость к временной недоступности одной из систем

важна разгрузка “онлайна” (асинхронная обработка)

есть много событий и получателей

Риски:

усложнение инфраструктуры (брокер, мониторинг)

нужна дисциплина контрактов сообщений и повторной обработки

Примеры распространенных брокеров: RabbitMQ и Apache Kafka.

Синхронный и асинхронный обмен: как выбрать

Это один из самых полезных “выборов уровня архитектуры”, который консультант должен уметь проговорить с бизнесом и ИТ.

Синхронно

Система А вызывает систему Б и ждет ответ.

Подходит, если:

пользователю нужен ответ прямо сейчас (например, проверить статус, получить остаток)

вызов короткий и надежный

Типовые проблемы:

таймауты и зависания при сбоях сети

рост времени отклика для пользователей

Асинхронно

Система А отправляет сообщение, обработка происходит позже.

Подходит, если:

допустима задержка

важнее надежность доставки и отсутствие “падений фронта”

нужно перерабатывать поток событий

Типовые проблемы:

сложнее объяснить бизнесу “когда точно появится результат”

нужны статусы обработки и диагностика

Форматы данных: JSON и XML в проектной практике

Консультант не обязан быть программистом, но обязан понимать контракт данных.

JSON

JSON — легкий формат для передачи структурированных данных. Очень часто используется в REST API.

Плюсы:

компактный и удобный для веб-интеграций

хорошо читается и легко валидируется на стороне интеграций

Минусы:

нужно отдельно договориться о правилах типов данных (даты, суммы, перечисления)

Нормативное описание формата: RFC 8259 (JSON).

XML

XML — более “тяжелый”, но формально строгий формат, исторически распространенный в SOAP и во многих корпоративных интеграциях.

Плюсы:

строгая структура и развитая экосистема схем (если используется)

часто обязателен в legacy-интеграциях

Минусы:

больше объем сообщений

сложнее читать и поддерживать руками

Спецификация: W3C XML.

Что фиксировать в контракте данных (минимум консультанта)

Чтобы интеграция не превратилась в “передаем что-то куда-то”, консультант фиксирует структуру обмена в виде таблицы.

| Поле | Что фиксируем | Пример | |---|---|---| | Объект | Что передаем | Контрагент, Заказ клиента | | Направление | Откуда → куда | CRM → 1С | | Ключ идентификации | Как узнаем сущность | GUID/код/ИНН+КПП | | Обязательные поля | Без чего нельзя | организация, сумма, валюта | | Правила типов | Даты, суммы, перечисления | дата в ISO 8601, сумма с 2 знаками | | Правила обновления | Можно ли менять задним числом | “заказы после отгрузки не меняются” | | Ошибки | Что считаем ошибкой и как возвращаем | код, текст, детали по строкам |

Важно: консультант не обязан выбирать конкретный формат даты, но обязан поднять вопрос и добиться согласования, иначе на тестировании появится “в одной системе 01.02, в другой 02.01”.

Планы обмена: как консультанту описывать “1С ↔ 1С” без углубления в код

План обмена чаще всего используют, когда обе стороны — информационные базы 1С. Для консультанта ключевое — не “как устроен механизм внутри”, а какие управленческие решения он требует.

Какие вопросы обязательно решить до реализации

какие данные являются мастер-данными и где они создаются

какие документы создаются в какой базе

что делать при конфликте изменений (если два места могут менять одно и то же)

как мониторим ошибки и “зависшие” пакеты

Типовые сценарии использования

“центр ↔ филиалы”: часть операций вводят в филиале, итоги и справочники идут из центра

“оперативный контур ↔ регламентированный”: перенос документов или результатов учета между базами 1С

Типовые ошибки в проектах

не закрепили владельца справочников, получили дубли и расхождения

не описали правило “что делать при ошибке”, в итоге обмен “молча перестал ходить”

Веб-сервисы и HTTP API: что консультант обязан уточнить

Интеграции через HTTP/SOAP часто кажутся простыми (“давайте дергать API”), но без уточнений быстро превращаются в источник инцидентов.

Договоренности по доступу и безопасности

Минимум, который нужно явно зафиксировать:

адреса контуров: тест и продуктив

способ аутентификации (учетная запись, токен, сертификат — по политике заказчика)

шифрование трафика (обычно TLS)

ограничения по IP и сетевым зонам (особенно если есть публикация наружу)

Договоренности по надежности

таймауты: сколько ждем ответа

повторы (retry): когда повторяем запрос

идемпотентность: что будет, если запрос пришел повторно

Идемпотентность простыми словами: повторная отправка одного и того же запроса не должна приводить к дублированию результата (например, к созданию двух одинаковых заказов).

Очереди: как объяснить бизнесу и правильно зафиксировать требования

Очереди часто выбирают, когда бизнес хочет “чтобы ничего не падало” при временных сбоях внешней системы.

!Понимание очередей: публикация, потребление, повторы и обработка ошибок

Что консультант фиксирует в TO-BE и требованиях

какие события публикуем (создан заказ, изменился статус, проведен документ)

какая задержка допустима (например, “до 5 минут”)

что считаем успешной обработкой (подтверждение от потребителя)

что делаем при ошибке: повторы, ручная обработка, отдельный журнал

Практичный список статусов обработки

В интеграциях через очереди полезно договориться о жизненном цикле сообщения:

создано

отправлено

обработано успешно

ошибка (с кодом причины)

отправлено на повтор

отправлено в “очередь ошибок”

Это важно для приемки: иначе получится “оно где-то в очереди”, и никто не понимает, кто отвечает.

Что обязательно описывать в спецификации интеграции (шаблон консультанта)

Интеграция — это место, где “слова” очень дорого обходятся. Поэтому консультанту полезно иметь стандартный шаблон спецификации.

Минимальная структура

Назначение интеграции и бизнес-ценность

Участники интеграции (системы) и контуры (тест/продуктив)

Объекты обмена (справочники, документы, статусы)

Точка истины по каждому объекту

Направления и триггеры

- по событию - по расписанию - по запросу

Контракт данных

- поля, обязательность, типы, правила заполнения

Правила сопоставления

- ключи - поиск дублей

Обработка ошибок

- коды ошибок - повторы - ручная обработка

Мониторинг и журналирование

- где смотреть статусы - кто отвечает

Критерии приемки

- тестовые сценарии - контрольные сверки

Пример таблицы “объект ↔ правило ↔ ответственность”

| Объект | Источник (мастер) | Получатель | Триггер | Ответственный за качество | |---|---|---|---|---| | Контрагенты | CRM | 1С | по событию | Руководитель продаж | | Заказ клиента | CRM | 1С | по событию | Отдел продаж | | Статус отгрузки | 1С | CRM | по событию/очередь | Склад/ИТ |

Приемка интеграций: что проверяет консультант

Логика из предыдущих тем курса (“критерии приемки должны быть проверяемыми”) в интеграциях особенно важна.

Минимальный набор проверок

создается тестовый объект в системе-источнике, появляется в системе-получателе

проверяются обязательные поля и типовые исключения

проверяется повторная отправка (не создает дубль)

проверяется обработка ошибки (например, неправильный ИНН или отсутствует номенклатура)

проверяется журнал/мониторинг: можно понять, что произошло и кто должен исправлять

Контрольные сверки, которые спасают проекты

сверка количества документов за период (сколько отправили, сколько приняли)

сверка сумм по ключевым показателям (например, сумма заказов)

реестр “не сопоставлено” (контрагенты/номенклатура не найдены)

Типовые ошибки интеграций и как их предотвращать

Не определили точку истины

Результат:

две системы “правят одно и то же”

дубли справочников

бесконечные расхождения

Профилактика:

фиксировать владельца данных в TO-BE и спецификации

Не договорились о ключе идентификации

Результат:

нельзя однозначно сопоставить сущности

появляется “ООО Ромашка” 10 раз

Профилактика:

заранее определить ключи и правила поиска дублей

Не описали обработку ошибок

Результат:

обмен “встал”, никто не заметил

исправления делаются вручную без системы контроля

Профилактика:

отдельный раздел “ошибки, повторы, ответственность, мониторинг”

Не учли права и безопасность

Результат:

интеграция работает только “у администратора”

утечки данных или блокировки ИБ службой безопасности

Профилактика:

описывать доступы как часть требований, а не “потом”

Итоги

Интеграции в 1С — это продолжение процессов AS-IS/TO-BE и требований, а не “техническая мелочь”. Консультант 1С должен уметь:

выбирать подход: файлы, планы обмена, HTTP/SOAP, очереди

фиксировать точку истины и правила синхронизации

описывать контракт данных (JSON/XML) так, чтобы не было двусмысленности

проектировать обработку ошибок, повторы и мониторинг

готовить критерии приемки, которые проверяют не только “передалось”, но и “как система ведет себя при сбоях”

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

Отчеты и аналитика: СКД, управленческие отчеты, витрины данных

Зачем консультанту 1С разбираться в отчетах и аналитике

Отчеты и аналитика в 1С — это место, где бизнес проверяет, что внедрение дает эффект: видны продажи, остатки, задолженность, маржинальность, затраты, ФОТ, отклонения от плана. Если в прошлых темах курса мы строили цепочку AS-IS → TO-BE → требования → настройки/доработки → приемка, то отчеты — это главный инструмент приемки на языке бизнеса.

Для консультанта 1С отчеты важны по трем причинам:

Отчет часто является критерием правильности учета (например, «дебиторка должна сходиться с актом сверки»).

Отчеты почти всегда «сквозные»: затрагивают несколько контуров (оперативный, финансы, ЗУП, интеграции).

Отчеты — частый источник конфликтов на приемке, если заранее не зафиксировать показатели, разрезы, источники данных и правила расчета.

Полезные официальные точки входа по платформе и сопровождению:

1С:Предприятие 8

1С:ИТС

Термины: что мы называем отчетом, аналитикой и витриной данных

Чтобы дальше говорить однозначно, закрепим рабочий словарь.

Отчет — форма представления данных пользователю (таблица, диаграмма, расшифровки, отборы), обычно с возможностью детализации.

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

Разрез (измерение) — по чему группируем показатель (период, организация, склад, менеджер, номенклатура, контрагент).

Детализация (drill-down) — переход от итога к расшифровке (например, «выручка по менеджеру → по документам → по строкам документа»).

Управленческий отчет — отчет для принятия решений (может отличаться от регламентированных данных по методике и моменту расчета).

СКД (система компоновки данных) — механизм платформы 1С для построения отчетов на основе схемы компоновки: источников данных, наборов данных, настроек, группировок и ресурсов.

Витрина данных — подготовленный набор данных под конкретную аналитику (часто агрегированный и очищенный), чтобы отчеты строились быстро и одинаково у всех.

Если у заказчика параллельно есть BI/хранилище, полезно опираться на базовые определения:

Хранилище данных

Витрина данных

Где отчеты находятся в модели 1С: «от документов к цифрам»

Для консультанта важно понимать причинно-следственную цепочку:

Пользователь вводит справочники и документы.

Проведение документов формирует движения в регистрах.

Отчеты строятся по данным регистров (и иногда по документам напрямую).

Практическое правило:

Если спорят про цифру в отчете, почти всегда нужно выяснить, какие документы должны были сформировать движения и в какие регистры.

Типовые классы отчетов на проектах

Оперативные отчеты (день-в-день)

Обычно нужны продажам, складу, закупкам.

Типовые примеры:

остатки и доступность с учетом резервов

дефицит и обеспечение

отгрузки за день/неделю

просроченные заказы поставщикам

Особенность: данные «живые», требования к скорости и фильтрам высокие.

Финансовые и регламентированные отчеты

Обычно критичны для бухгалтерии и финансов.

Типовые примеры:

оборотно-сальдовая ведомость

анализ счета

задолженность (в разрезах, согласованных с методикой)

контроль закрытия месяца (ошибки, непроведенные документы)

Особенность: любые разногласия в методике или в мастер-данных становятся видны на закрытии периода.

Управленческие отчеты (KPI и управленческая методика)

Это отчеты, где особенно важно заранее договориться о правилах.

Типовые примеры:

валовая прибыль и маржинальность

план-факт продаж

эффективность менеджеров

ABC/XYZ анализ

Особенность: часто требуется уточнить, что такое показатель (например, «маржа» может считаться по-разному) и когда он считается окончательным.

СКД: что консультанту нужно понимать без программирования

СКД — основной механизм построения отчетов в 1С. Консультант не обязан писать запросы и макеты, но обязан уметь ставить задачу и принимать результат.

Из чего обычно состоит отчет на СКД (на уровне смысла)

Источники данных: регистры, документы, справочники, запросы.

Наборы данных: какие именно таблицы и поля участвуют.

Ресурсы: показатели, которые суммируются/считаются (сумма, количество).

Группировки: разрезы отчета (период, склад, менеджер).

Отборы: фильтры (организация, склад, номенклатура).

Параметры: переключатели логики (например, «учитывать возвраты»).

Оформление и варианты: как отчет выглядит и какие «сохраненные варианты» доступны ролям.

Почему СКД — это не только «красивая таблица»

СКД задает структуру и правила формирования результата. Для приемки важно проверять не только «выводится ли», но и:

корректность показателей

корректность группировок и фильтров

корректность расшифровок

соответствие правам (кто что видит)

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

Как консультанту описывать управленческий отчет так, чтобы его можно было реализовать

Проблема управленческих отчетов в том, что бизнес часто формулирует их как «сделайте как в Excel». Это не требование. Нужна спецификация смысла.

Мини-шаблон спецификации управленческого отчета

| Поле | Что фиксируем | Пример формулировки | |---|---|---| | Назначение | Зачем отчет и кому | «Коммерческий директор контролирует маржинальность» | | Показатели | Что считаем | «Выручка, себестоимость, валовая прибыль, маржа %» | | Разрезы | По чему анализируем | «Период/менеджер/клиент/товарная группа» | | Отборы | Какие фильтры обязательны | «Организация, склад, канал продаж» | | Правила расчета | Ключевые допущения | «Маржа = (выручка − себестоимость)» | | Источник данных | Где берем «истину» | «Реализации и себестоимость из регистров учета» | | Момент готовности | Когда цифры считаются финальными | «После закрытия месяца» | | Детализация | Куда проваливаемся | «До документа и строки документа» | | Ограничения прав | Кто что видит | «Менеджер видит только свои продажи» | | Критерии приемки | Как проверяем | «На тестовом периоде итог сходится с контрольной выборкой» |

Типовые вопросы, которые консультант обязан задать

Что считаем выручкой: по отгрузке, по оплате, с НДС или без?

Как учитываем возвраты и корректировки?

Как считаем себестоимость: по какой методике и когда она «созревает»?

Что такое «маржинальность»: по строкам, по документам, по клиентам?

Какие исключения важны: услуги, комиссионная торговля, комплекты, серийный учет?

Если эти вопросы не зафиксировать в требованиях, разработка сделает «как поняла», а бизнес примет «как ожидал» — и отчет станет спором.

Права и аналитика: почему «не вижу цифры» — это часто не баг

Из тем курса про TO-BE и матрицу ролей и прав важно помнить: отчет — часть процесса и контроля, значит он должен учитывать ограничения доступа.

Типовые требования по правам в отчетах:

ограничения по организации

ограничения по складу/подразделению

ограничения по менеджеру/ЦФО

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

Практический риск:

если права настроены «широко», управленческий отчет может раскрывать коммерческую информацию

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

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

Консультант не оптимизирует запросы, но должен проектировать отчет так, чтобы его можно было эксплуатировать.

Факторы, которые чаще всего «убивают» отчеты

слишком большой период (например, «за 5 лет по номенклатуре до SKU»)

отсутствие ограничений и предустановленных отборов

попытка считать сложные показатели «на лету» по документам, а не по регистрам

одновременная работа большого числа пользователей по тяжелому отчету

Как фиксировать нефункциональные требования к отчету

Формулировки «должно быть быстро» недостаточно. Лучше фиксировать измеримо.

Примеры корректных требований:

«Отчет формируется за период до 1 месяца при отборе по одной организации и одному складу не более чем за N секунд на тестовом стенде, согласованном с ИТ».

«Должен быть обязательный отбор по организации, иначе отчет не запускается».

Число консультант задает не «из головы», а согласует с ИТ и бизнесом, потому что это зависит от инфраструктуры и объема данных.

Витрины данных: когда СКД и регистров недостаточно

Зачем вообще нужны витрины

Витрина данных нужна, когда один из факторов делает отчет «неподъемным»:

слишком много источников и сложная логика объединения

нужны агрегаты и предрасчет (например, ежедневная маржа по множеству разрезов)

нужно стабилизировать методику (одна «версия правды») и ускорить отчеты

данные приходят из интеграций и требуют нормализации

Витрина — это не обязательно отдельная внешняя БД. В проектах 1С витрина часто реализуется как:

отдельный регистр (или набор регистров) с рассчитанными показателями

периодическое заполнение (регламентное задание)

отчет строится уже по «подготовленному слою»

Как консультанту понять, что пора говорить о витрине

Признаки:

отчет «работает», но только ночью или только у администратора

отчет требует сложных объединений и пересчетов при каждом открытии

показатели должны быть одинаковыми у разных пользователей и не зависеть от их «вариантов настройки»

бизнес хочет интерактивную аналитику по большим объемам

!Схема показывает, как витрина данных разгружает отчеты и связывает несколько систем

Что обязательно фиксировать в требованиях к витрине

| Раздел | Что фиксируем | Почему это важно | |---|---|---| | Состав показателей | что храним и в каких единицах | иначе витрина станет «еще одной таблицей» | | Разрезы | по чему агрегируем | определяет объем и производительность | | Периодичность обновления | раз в час/день/по событию | влияет на актуальность | | Источники и «точка истины» | какие системы и какие объекты | предотвращает расхождения | | Правила перерасчета | что делаем при перепроведении | иначе витрина «устареет» | | Мониторинг ошибок | где смотреть статус загрузки | иначе витрина будет молча ломаться | | Права | кто видит какие разрезы | аналитика = чувствительные данные |

Приемка отчетов: как консультанту сделать ее предсказуемой

Логика из темы про критерии приемки и постановку задач сохраняется: отчет принимают не «по красоте», а по проверяемым условиям.

Минимальный набор критериев приемки для отчета

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

Группировки и отборы дают ожидаемый результат.

Детализация приводит к правильным документам/движениям.

Варианты отчета доступны нужным ролям.

Пользователь без прав не видит «лишние» организации/склады/подразделения.

Производительность соответствует согласованным ограничениям (период, обязательные отборы).

Тестовые данные: что просить у бизнеса

5–10 документов типового сценария

2–3 документа исключений (возврат, корректировка, частичная отгрузка, аванс)

контрольный Excel/выборка «как считают сейчас» с описанием методики

Типовые ошибки в отчетах и аналитике на проектах 1С

Отчет описан как «как в Excel», без показателей и правил расчета.

Не зафиксирована «одна версия правды»: разные отчеты считают по разным источникам.

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

Права не учтены: либо «все видят всё», либо «никто ничего не видит».

Не учтены исключения (возвраты, корректировки), и отчет красив только на «идеальных» данных.

Практичные артефакты консультанта по отчетности

спецификация отчета (показатели, разрезы, правила, источники)

прототип формы (что на экране и какие расшифровки)

критерии приемки и контрольные примеры

матрица прав на отчет и детализацию

при необходимости: спецификация витрины данных и регламент обновления

Итоги

Отчеты и аналитика — это слой, где бизнес «видит правду» о процессе и учете. Для консультанта 1С ключевые идеи такие:

СКД — основной механизм отчетов, и его нужно принимать по показателям, разрезам, фильтрам, детализации и правам.

Управленческий отчет требует фиксации методики: что считаем, по каким правилам и когда цифры финальные.

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

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

Тестирование и приемка: тест-кейсы, UAT, регрессия, управление дефектами

Зачем консультанту 1С разбираться в тестировании и приемке

На проектах 1С консультант отвечает не только за понимание потребности и постановку задач (это мы разобрали в темах про требования и постановку задач разработчикам), но и за то, чтобы результат был проверен и принят бизнесом без сюрпризов.

Тестирование и приемка связывают воедино предыдущие артефакты курса:

TO-BE сценарии и регламенты задают, что именно считается правильной работой процесса.

Требования и критерии приемки превращают ожидания в проверяемые условия.

Задачи разработчикам задают точку входа для реализации.

Интеграции и отчеты требуют особенно строгих проверок, потому что ошибки часто проявляются не сразу.

Главная мысль: тестирование в 1С-проектах нужно не ради формальности, а ради управляемого качества учета, расчетов и данных.

Базовые термины: чтобы говорить однозначно

Ниже термины, которые консультант использует ежедневно.

Тест-кейс — пошаговое описание проверки: предусловия → действия → ожидаемый результат.

Тестовые данные — конкретные справочники и документы, на которых выполняется тест (контрагенты, номенклатура, заказы, начисления и т.д.).

Дефект — несоответствие фактического результата ожидаемому.

UAT (User Acceptance Testing) — пользовательское приемочное тестирование: проверка решения ключевыми пользователями на соответствие их сценариям и критериям приемки.

Регрессия (регрессионное тестирование) — повторная проверка ранее работавших функций после изменений, чтобы убедиться, что ничего не сломали.

Если нужно сверять определения тестовых терминов, удобно использовать официальный глоссарий ISTQB: ISTQB Glossary.

Место тестирования в цепочке проекта

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

!Связь сценариев, требований, задач, тестов и приемки

Практический вывод для консультанта:

если тест-кейсы не привязаны к требованиям и сценариям, приемка превращается в спор;

если дефекты не привязаны к тест-кейсам и версиям, исправления становятся хаотичными.

Что именно тестируем в 1С-проектах

В 1С важно тестировать не только интерфейс, но и учетные последствия.

Основные объекты проверки

Процессы и сценарии: последовательности действий ролей из TO-BE.

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

Права: кто что видит и что может делать (матрица ролей и прав из TO-BE).

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

Интеграции: доставка данных, идемпотентность, обработка ошибок.

Печатные формы и юридические реквизиты: когда документы уходят контрагенту или в ЭДО.

Уровни проверок, которые встречаются на проектах

Дымовое тестирование (smoke) — минимальная проверка, что сборка вообще запускается и ключевые операции доступны.

Функциональное тестирование — проверка требований и сценариев.

Интеграционное тестирование — проверка обменов и границ систем.

Приемочное тестирование (UAT) — подтверждение бизнесом, что решение пригодно к работе.

Регрессионное тестирование — защита от поломок при изменениях и исправлениях.

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

Тест-кейсы: как писать так, чтобы по ним можно было принять результат

Консультант чаще всего участвует в разработке тест-кейсов на бизнес-уровне и в проверке их полноты.

Минимальная структура тест-кейса

Ниже структура, которая подходит для Jira/Excel/Confluence и не требует сложных инструментов.

| Поле | Что писать | Зачем это нужно | |---|---|---| | ID | Уникальный номер | Трассируемость с требованиями и дефектами | | Сценарий/требование | Ссылка на TO-BE и требование | Понимание цели проверки | | Роль | Кто выполняет | Проверка прав и ответственности | | Предусловия | Что должно быть в базе | Убирает спор «у нас не такие данные» | | Шаги | Что делает пользователь | Воспроизводимость | | Ожидаемый результат | Что должно получиться | Основа приемки | | Тестовые данные | Конкретные примеры | Повторяемость и регрессия |

Какой уровень детализации выбрать

Консультанту важно удержать баланс.

Плохо: описывать клик за кликом, если это не критично.

Плохо: писать «создать заказ и проверить» без шагов и ожиданий.

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

Пример тест-кейса для оперативного контура

Кейс в стиле курса (сценарность, роли, критерии приемки).

| Поле | Пример | |---|---| | Название | Запрет проведения реализации без резерва | | Роль | Кладовщик | | Предусловия | Заказ клиента Z-1001 создан, резерв по строке 1 отсутствует | | Шаги | Открыть реализацию по заказу Z-1001 и выполнить проведение | | Ожидаемый результат | Проведение запрещено, сообщение содержит номенклатуру строки без резерва | | Доп. проверка | После создания резерва проведение выполняется успешно |

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

Тестовые данные: почему без них тестирование в 1С «не взлетает»

В 1С качество проверки почти всегда упирается в данные: ставки НДС, договоры, виды начислений, настройки учета, мастер-данные.

Принципы подготовки тестовых данных

Минимальный набор: данные должны покрывать сценарий, а не «всю жизнь компании».

Покрытие исключений: хотя бы 1–2 нестандартных случая на процесс (возврат, частичная отгрузка, перерасчет, корректировка).

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

Разделение сред: тестирование должно идти в тестовой базе, а не в продуктиве.

Что особенно важно для 1С

даты и периоды (часто ошибки проявляются «на границе месяца»);

закрытие месяца или расчет зарплаты как обязательный тестовый сценарий, если контур затронут;

влияние прав: один и тот же тест нужно иногда прогонять под разными ролями.

UAT: пользовательская приемка как управляемый процесс

UAT — это не «пусть пользователи потыкают», а формальная проверка, что решение закрывает сценарии бизнеса.

Когда UAT действительно нужен

внедрение нового процесса или изменение регламента;

изменения, влияющие на финансы, регучет, зарплату;

интеграции, которые меняют «точку истины» по данным;

отчеты, по которым бизнес будет принимать решения.

Роли в UAT

Ключевой пользователь: проверяет сценарии и подтверждает готовность.

Консультант: организует сценарии, тестовые данные, фиксирует результат и дефекты.

Разработчик: исправляет дефекты, отвечает на вопросы по реализации.

Руководитель проекта: управляет окнами, планом, рисками.

Что фиксируем в плане UAT

| Раздел | Что должно быть | |---|---| | Объем | какие сценарии и требования включены | | Участники | кто проверяет и кто принимает | | Среда | какая тестовая база и версия релиза | | Данные | какие тестовые наборы используем | | Правила дефектов | как заводим, кто приоритизирует, SLA на исправление | | Критерии завершения | когда UAT считается пройденным |

Критерии завершения UAT

Хорошая практика — договориться о критериях заранее, иначе UAT может длиться бесконечно.

Примеры критериев завершения:

все тест-кейсы из объема пройдены;

нет дефектов уровня блокирующий и критический;

для дефектов меньшей важности согласованы сроки исправления или обходные процедуры;

обновлены инструкции/регламенты, если изменился процесс.

Регрессия: как не сломать учет и процессы при изменениях

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

Когда регрессия обязательна

исправления дефектов в «ядре» процесса (проведение документов, расчеты);

изменения прав и ограничений доступа;

изменения обменов и форматов данных;

изменения отчетов, от которых зависит контроль учета;

обновление конфигурации или платформы.

Как выбрать набор регрессионных проверок

Консультанту помогает подход по рискам:

выбрать 10–30 ключевых сценариев, которые нельзя сломать;

включить топовые исключения;

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

Практика «регрессионный пакет»

Удобно вести таблицу или набор задач в трекере.

| Сценарий | Почему в регрессии | Частота | |---|---|---| | Продажа: заказ → резерв → отгрузка | критично для операционного контура | каждый релиз | | Закрытие месяца (минимальный прогон) | выявляет ошибки данных и политик | релизы, влияющие на учет | | Расчет зарплаты на 2 сотрудниках | выявляет поломки методики и прав | релизы в ЗУП | | Обмен с CRM: заказ и статус | риск дублей и разрыва «точки истины» | релизы интеграции |

Автоматизация регрессии возможна, но как консультанту важнее другое: регрессия должна существовать как договоренный контрольный набор.

Управление дефектами: как консультанту сделать исправления предсказуемыми

Дефекты в 1С-проектах неизбежны. Важно управлять ими так, чтобы команда не «тонула».

Дефект и его жизненный цикл

!Жизненный цикл дефекта и контрольные точки

Статусы могут называться иначе, но смысловые этапы обычно такие:

зарегистрировали проблему;

классифицировали и назначили приоритет;

исправили;

проверили;

закрыли или переоткрыли.

Severity и priority: в чем разница

Чтобы не путать термины:

Серьезность (severity) — насколько дефект влияет на систему и процесс.

Приоритет (priority) — насколько срочно его нужно исправить.

Например:

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

дефект может быть низкой серьезности, но высокого приоритета, если он мешает UAT или обучению (например, блокирует демонстрацию ключевому пользователю).

Что обязательно должно быть в описании дефекта

Консультант помогает писать дефекты так, чтобы разработчик мог воспроизвести проблему.

Минимальный шаблон:

Краткое описание: что не так.

Среда: тест/продуктив, база, версия релиза.

Роль: под кем выполняли.

Шаги воспроизведения: нумерованный список действий.

Фактический результат: что получили.

Ожидаемый результат: что должно быть по требованию/критериям.

Приложения: скриншоты, примеры документов, лог обмена.

Связь: ID требования/задачи/тест-кейса.

Типовые категории причин дефектов в 1С

Полезно классифицировать дефекты, чтобы находить системные проблемы.

Логика: неверное правило, контроль, расчет.

Данные: не заполнены обязательные реквизиты, дубли, некорректные настройки.

Права: роль не видит документ или может сделать лишнее.

Интеграция: не тот формат, не та идентификация, дубли при повторной отправке.

Отчет: неверный источник данных или правило расчета.

Такая классификация помогает на ретроспективе: где «течет» процесс — в требованиях, в данных, в правах или в реализации.

Приемка результата: как превратить проверку в формальное подтверждение

Приемка — это подтверждение выполнения критериев, а не «нам понравилось».

Что обычно входит в приемку на проектах 1С

демонстрация по согласованным сценариям;

подтверждение ключевыми пользователями (UAT протокол или отметки в тест-кейсах);

список известных ограничений и согласованных доработок «после запуска»;

подтверждение готовности регламентов и инструкций, если менялся процесс;

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

Практичный комплект артефактов к моменту приемки

список требований и критериев приемки (с ID);

набор тест-кейсов (основные сценарии и исключения);

протокол UAT или журнал прохождения тестов;

реестр дефектов с решениями и статусами;

регламент/инструкция для пользователей (если менялся процесс);

план регрессии на следующий релиз (если проект итеративный).

Типовые ошибки консультанта в тестировании и приемке

нет тестовых данных, тестируют «на чем придется»;

UAT начинается без критериев завершения, превращается в бесконечный поток замечаний;

дефекты описаны как «не работает», без шагов и ожидаемого результата;

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

нет регрессии, и каждое исправление ломает соседний контур;

отчеты принимают без фиксированной методики показателей и источников данных.

Итоги

Тестирование и приемка в 1С-проектах — это управляемая практика, которая защищает бизнес от ошибок учета, данных и процессов.

Ключевые выводы для консультанта 1С:

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

UAT — это управляемая приемка ключевыми пользователями, с заранее согласованным объемом и критериями завершения;

регрессия — обязательный контрольный набор, который защищает от поломок при изменениях и обновлениях;

управление дефектами требует дисциплины: воспроизводимость, связь с требованиями, серьезность и приоритет, понятный жизненный цикл.

Обновления и сопровождение: релизы, расширения, перенос доработок

Зачем консультанту 1С разбираться в обновлениях и сопровождении

В предыдущих темах курса мы выстроили «проектную цепочку» консультанта: AS-IS → TO-BE → требования → постановки задач → интеграции/отчеты → тестирование и приемка. Но даже идеально реализованная функциональность со временем перестает работать предсказуемо, если не управлять обновлениями и сопровождением.

В 1С это особенно заметно из-за двух факторов:

типовые конфигурации регулярно меняются (законодательство, методики учета, исправления ошибок)

на проектах почти всегда есть изменения от внедрения (настройки, расширения, доработки), и их нужно переносить между версиями без потери качества

Для консультанта компетенция «обновления и сопровождение» означает умение:

объяснять бизнесу, почему обновляться нужно регулярно, а не «когда сломается»

выбирать безопасный способ кастомизации (типовые настройки, расширения, минимальные доработки)

организовывать приемку релиза: критерии, регрессия, контроль рисков

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

Официальные точки входа по сопровождению и обновлениям, которые чаще всего используют на практике: 1С:ИТС и 1С:Предприятие 8.

Словарь: что такое релиз, обновление и сопровождение

Релиз

Релиз — это поставка изменений в систему (в продуктив), обычно в виде обновления платформы, конфигурации, расширений или набора доработок.

Важно различать:

релиз как набор изменений (что именно входит)

релиз как событие (когда это внедряем)

Обновление платформы и обновление конфигурации

Платформа 1С — технологическая основа (клиент, сервер, механизмы выполнения). Обновления платформы могут влиять на производительность, совместимость, безопасность.

Конфигурация — прикладное решение (Бухгалтерия, УТ, ЗУП, ERP). Обновления конфигурации чаще влияют на бизнес-логику, документы, отчеты, регламентированный учет.

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

Сопровождение

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

В сопровождении консультант чаще всего отвечает за:

входящий поток запросов и их формализацию (требование → задача)

анализ причин (ошибка данных, прав, методики, дефект)

приемку изменений и поддержание «управляемости» процесса

Почему типовые обновления важнее, чем кажется

Типовой сценарий провала выглядит так: «год не обновлялись, накопили доработки, теперь боимся обновляться». В итоге компания получает:

высокую стоимость перехода (слишком много накопленных изменений)

технологический долг (сложно тестировать, сложно переносить)

риски по регучету и отчетности (особенно в Бухгалтерии и ЗУП)

Преимущества регулярных обновлений:

меньше объем каждого обновления и проще приемка

выше предсказуемость поддержки (меньше нестандартных ситуаций)

быстрее закрываются изменения законодательства и методик учета

!Жизненный цикл релиза и контрольные точки консультанта

Что именно «обновляют» в реальных 1С-проектах

Обновление на практике почти всегда состоит из нескольких слоев.

Типовые обновления конфигурации (от вендора)

Это обновления, которые поставляет 1С для типовых решений.

Риски для проекта:

изменились формы/проведение/правила учета

изменились регламентные операции (например, закрытие периода)

появились новые обязательные реквизиты

Настройки в базе

Это то, что обычно «не видно в коде», но сильно влияет на поведение:

параметры учета, политики, табличные настройки

права доступа, профили/группы доступа

регламентные задания, обмены и расписания

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

Расширения

Расширение конфигурации — механизм, позволяющий изменять поведение типового решения без прямого изменения основной конфигурации.

Смысл для консультанта:

расширения часто позволяют снизить стоимость обновлений (меньше конфликтов при обновлении типовой конфигурации)

но расширение все равно требует тестирования и дисциплины версий

Доработки (изменение основной конфигурации)

Это прямое изменение типовой конфигурации (включая сценарии «сняли с поддержки»).

Смысл для консультанта:

это допустимо, но дорого в поддержке

перенос доработок на новую версию становится отдельным проектом

Расширения vs доработки: как консультанту выбирать стратегию

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

Когда расширение — хороший выбор

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

нужно изменить/добавить печатную форму или отчет

нужно добавить проверки и ограничения по сценарию TO-BE

важно сохранить обновляемость

Когда расширения может быть недостаточно

требуется глубокая переработка базовой логики проведения, которая упирается в ограничения расширений

нужно менять структуру данных или механизм, который нельзя корректно расширить без вмешательства в основной код

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

Когда изменение основной конфигурации почти всегда риск

«быстро поправим типовой объект, чтобы завтра работало» без фиксации и стратегии

множество мелких правок в разных местах без трассируемости «почему так»

!Как выбирать между настройкой, расширением и доработкой

Управление релизами: что консультант обязан обеспечить

Консультант не всегда является релиз-менеджером, но на своем участке должен удерживать управляемость.

Единый реестр изменений

Минимальный рабочий стандарт:

у каждого изменения есть ID (требование или задача)

для изменения известны: цель, владелец, контур, риски, критерии приемки

понятно, в каком релизе изменение уехало в продуктив

Практический результат: если возникает инцидент, можно ответить на вопрос «что изменилось и когда».

Разделение сред

Чтобы релизы были предсказуемыми, нужны как минимум:

тестовая среда (где проверяем и принимаем)

продуктивная среда (где работает бизнес)

В проектах с разработкой обычно добавляют среду разработки. Консультанту важно не «наличие серверов», а правила:

где можно экспериментировать

где запрещены изменения без релиза

как фиксируется перенос между средами

Definition of Done для релиза (простыми словами)

Согласованный командой минимум, что значит «готово»:

реализовано по задаче

пройдены критерии приемки консультанта

пройдены ключевые сценарии регрессии (по риску)

обновлены инструкции/регламенты, если менялся процесс

известны ограничения и что остается в следующем релизе

Обновление типовой конфигурации: базовый сценарий работ

Ниже описан «скелет» процесса, который консультант должен понимать и поддерживать артефактами.

Подготовка

Зафиксировать объем обновления

Собрать список критичных процессов и отчетов, которые должны пройти проверку

Подготовить тестовые данные (или убедиться, что они существуют)

Договориться о критериях завершения UAT (из темы курса про приемку)

Обновление на тестовой среде и проверка

Обновить типовую конфигурацию в тесте

Установить/обновить расширения и перенести изменения

Прогнать регрессионный пакет

Провести UAT по ключевым сценариям

Зафиксировать дефекты и решения

Внедрение в продуктив

Согласовать окно работ

Сделать резервную копию

Выполнить обновление

Выполнить контрольные проверки (смоук + несколько ключевых тестов)

Обеспечить канал быстрого реагирования на инциденты после релиза

Перенос доработок: что это и почему это отдельная компетенция

Перенос доработок — это приведение ваших изменений (расширений, модификаций, отчетов, интеграций) к работоспособному состоянию на новой версии конфигурации и/или платформы.

Консультанту важно понимать, что перенос — это не «техническая магия разработчика», а управляемый риск:

типовая конфигурация могла поменять структуру данных и логику

ваши доработки могли конфликтовать с новыми типовыми механизмами

приемка должна подтверждать, что бизнес-сценарии TO-BE снова работают

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

перенос расширения без конфликтов: чаще всего проще, но все равно требует тестов

перенос изменений типовой конфигурации: чаще всего дороже и требует разборов конфликтов

перенос интеграций и отчетов: риск «формально работает, но цифры/статусы другие»

Что должен подготовить консультант для переносимости

Чтобы через год перенос не превратился в археологию, консультант поддерживает дисциплину артефактов:

постановки задач с критериями приемки и примерами данных

реестр изменений по релизам

описание критичных сценариев регрессии

фиксация «почему сделали именно так» для нетиповых решений

Расширения в сопровождении: правила, которые помогают не потерять обновляемость

Расширения снижают стоимость обновлений только при дисциплине.

Практичные правила использования расширений

одно расширение — понятная область ответственности (например, «интеграция с CRM» или «контроли отгрузки»), а не «свалка всего»

все изменения в расширении привязаны к задачам и релизам

критерии приемки и тест-кейсы хранятся рядом с изменениями (ссылками), а не «в памяти людей»

права доступа и ограничения проверяются так же, как и бизнес-логика

Типовые ошибки с расширениями

расширение становится «второй конфигурацией», где изменения никак не описаны

нет версионирования: непонятно, что сейчас установлено в продуктиве

расширение меняет процесс, но регламент и обучение не обновлены

Регрессия при обновлениях: как выбрать минимум, который защищает бизнес

Из темы курса про тестирование важна мысль: регрессия выбирается по рискам.

Минимальный регрессионный пакет при обновлении (пример логики)

один сквозной сценарий оперативного контура (заказ → обеспечение → отгрузка → оплата)

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

один сценарий интеграции (создание + повторная отправка + ошибка)

один ключевой управленческий отчет, который бизнес использует ежедневно

Консультант отвечает за то, чтобы этот набор был:

заранее согласован

воспроизводим

привязан к критериям приемки и тестовым данным

Роли и зона ответственности: кто что делает при обновлениях

Чтобы обновление не превращалось в «все делают все», полезно явно договориться о границах.

| Активность | Консультант 1С | Разработчик 1С | Администратор/ИТ | Ключевой пользователь | |---|---|---|---|---| | Формирование объема релиза и реестра изменений | R | C | I | C | | Анализ влияния на процессы и риски | R | C | C | C | | Обновление типовой конфигурации (технически) | I | C | R | I | | Перенос/адаптация доработок и расширений | C | R | C | I | | Подготовка тест-кейсов и критериев приемки | R | C | I | C | | UAT и подтверждение бизнесом | R | I | I | A | | Контроль пострелизных инцидентов и сбор обратной связи | R | C | C | C |

Обозначения:

R — выполняет

A — принимает/утверждает

C — участвует как консультируемый

I — информируется

Типовые инциденты после обновлений и как консультант снижает риск

«Цифры в отчете изменились»

Частая причина: изменение типовой методики, регистров, правил учета.

Что делает консультант:

проверяет источник данных отчета и изменения в сценариях

сравнивает на контрольном периоде «было/стало» по заранее согласованной методике

фиксирует: это дефект, изменение методики или ошибка данных

«Пользователь не видит документы/не может провести»

Частая причина: обновление ролей/прав, изменение доступа к подсистемам.

Что делает консультант:

проверяет по матрице ролей и прав (из темы TO-BE)

выполняет негативные проверки прав (что пользователь не должен видеть)

«Интеграция стала давать дубли/ошибки»

Частая причина: поменялись правила идентификации, формат, обязательные поля.

Что делает консультант:

поднимает спецификацию интеграции (из темы про обмены)

проверяет идемпотентность: повторная отправка не должна создавать дубль

проверяет журнал/мониторинг и ответственность за обработку ошибок

Практичный набор артефактов сопровождения, который “окупается”

реестр релизов: что вошло, когда внедрено, кто принял

реестр изменений: задача → релиз → ссылка на критерии приемки

регрессионный пакет (минимальный набор сценариев)

протоколы UAT по крупным изменениям

карта расширений и их назначение

Эти артефакты напрямую опираются на предыдущие темы курса: требования, постановки задач, тестирование, интеграции, отчеты.

Итоги

Обновления и сопровождение в 1С — это управляемый процесс, где консультант обеспечивает предсказуемость на языке бизнеса.

Ключевые выводы:

релиз — это не только «обновили конфигурацию», а контролируемый набор изменений с приемкой

регулярные обновления снижают стоимость владения и риски для учета и отчетности

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

перенос доработок всегда должен опираться на артефакты: критерии приемки, тестовые сценарии, реестр изменений и регрессию

консультант удерживает связку: изменение → сценарий → тест → приемка → релиз → мониторинг

Производительность и надежность: диагностика, блокировки, журнал регистрации

Зачем консультанту 1С разбираться в производительности и надежности

Производительность и надежность в 1С — это не «задачи админа» и не «чисто разработка». На практике именно консультант чаще всего первым получает сигнал:

«1С тормозит»

«документ не проводится»

«висит закрытие месяца»

«обмен остановился»

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

Связь с предыдущими темами курса:

из TO-BE и требований мы берем сценарии и критерии приемки, чтобы понять что именно должно работать и в каких условиях

из темы про интеграции — понимание, что зависания могут быть в очереди/обмене/внешнем API, а не «в форме документа»

из темы про тестирование и приемку — дисциплина воспроизведения, тестовых данных и фиксации дефектов

из темы про сопровождение и релизы — необходимость регрессии и контроля после изменений

Официальные точки входа по платформе и сопровождению: 1С:Предприятие 8 и 1С:ИТС.

Что такое производительность и надежность в контексте 1С

Производительность

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

В проектных терминах консультанта это означает:

сколько времени занимает ключевой сценарий (например, «провести реализацию», «сформировать отчет», «закрыть месяц»)

сколько пользователей могут выполнять сценарии параллельно

как поведение меняется в пиковые моменты (отгрузка, расчет зарплаты, закрытие периода)

Надежность

Надежность — это способность системы работать предсказуемо и восстанавливаться после сбоев.

Для консультанта это проявляется как:

отсутствие потери данных

предсказуемость статусов (проведено/не проведено, отправлено/не отправлено)

контролируемая обработка ошибок (понятные сообщения, журналирование)

воспроизводимость проблем и возможность доказать причину

Главная ошибка в коммуникации: «1С тормозит» — это не диагноз

Фраза «тормозит» не содержит признаков, по которым команда может действовать. Консультант должен превратить ее в диагностируемое описание.

Минимум вопросов, который должен задать консультант

Если задавать вопросы хаотично, вы потеряете время. Удобно фиксировать информацию в одном формате.

| Вопрос | Зачем | Пример ответа, который помогает диагностике | |---|---|---| | Где тормозит? | Локализовать узел | «При проведении реализации» / «При открытии списка заказов» | | У кого тормозит? | Исключить локальные факторы | «У всех кладовщиков» / «Только у одного пользователя» | | Когда началось? | Привязка к изменениям | «После обновления релиза» / «После включения нового обмена» | | Как воспроизвести? | Сделать тест повторяемым | «Открыть заказ Z-1001 и нажать Провести» | | Сколько длится? | Перевести в измеримость | «20–40 секунд, раньше было 2–3» | | Что еще происходило? | Найти внешний фактор | «Шла инвентаризация», «закрытие месяца», «обмен с CRM» |

Результат: вместо «тормозит» появляется сценарий, а значит можно связывать проблему с задачами, тестами и приемкой.

Инструменты диагностики, доступные консультанту

Консультант не обязан глубоко настраивать инфраструктуру, но он должен понимать, какие источники фактов существуют и что из них можно запросить у ИТ/разработчиков.

Источники фактов в 1С-проекте

Журнал регистрации: фиксация событий (ошибки, предупреждения, входы, критичные действия) и основа доказательности.

Технологический журнал: детальная техническая трассировка производительности и работы платформы (обычно включается и анализируется разработчиками/админами).

Замеры производительности: инструментальный способ измерить время выполнения операций и выявить «узкие места» на стороне прикладной логики.

Логи интеграций и статусы обменов: журналы отправки/приема, очереди, реестры ошибок.

Мониторинг СУБД: блокировки, ожидания, медленные запросы (обычно зона ИТ/администраторов, но консультант должен уметь сформулировать запрос).

> Практический принцип: консультант собирает признаки и сценарий, а затем организует получение технических фактов от нужной роли (разработчик, администратор, DBA), чтобы не «стрелять вслепую».

Диагностика по слоям: где может быть причина

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

!Слои, по которым удобно последовательно искать причину

Слой сценария и процесса

Иногда «тормозит» из-за процесса:

пользователи начали вводить данные иначе (например, «по одной позиции в документ», вместо «по партии»)

появился дополнительный шаг согласования, который воспринимают как зависание

в TO-BE не учли, что сценарий теперь выполняется массово (например, 5000 строк в документе)

Задача консультанта: проверить, что проблема действительно в системе, а не в изменении сценария или ожиданий.

Слой прав и ограничений

Признаки:

у части пользователей «все быстро», у части «долго»

«документ не открывается» оказывается отсутствием права на чтение связанного объекта

Задача консультанта: сверить с матрицей ролей и прав и проверить доступность объектов.

Слой данных и настроек

Частая причина — данные выросли или «испортились»:

появилось много дублей/неактуальных записей в справочниках

неверные настройки привели к большому числу движений

включили новый учетный разрез (характеристики/серии/ордерная схема), но не подготовили мастер-данные

Слой интеграций

Признаки:

операции зависают «на отправке»

документы создаются с задержкой

появляются дубли при повторной отправке

Задача консультанта: проверить статусы обмена, журнал ошибок, договоренности по повторам и идемпотентности из спецификации интеграции.

Слой инфраструктуры и СУБД

Признаки:

«тормозит у всех и сразу»

параллельные пользователи мешают друг другу

есть зависания, которые заканчиваются сообщением о блокировке

Здесь консультант чаще всего сталкивается с темой блокировок.

Блокировки: что это и почему они возникают

Что такое блокировка простыми словами

Блокировка — это механизм, который не дает двум параллельным операциям «сломать» данные. Если один сеанс изменяет данные, другие сеансы могут быть вынуждены ждать.

Важно для консультанта: блокировки не всегда зло. Они бывают нормальными (короткими) и проблемными (длинными, массовыми, циклическими).

Типовые проявления блокировок для пользователя

«Документ не проводится, висит»

«Система не отвечает»

«Не могу записать справочник, пишет, что объект заблокирован»

Наиболее частые причины проблемных блокировок в 1С-проектах

Долгие операции в транзакции

- проведение документа с большим объемом строк - массовое перепроведение - закрытие месяца параллельно с оперативной работой

Конкуренция за одни и те же данные

- один и тот же склад/остатки/партии - один и тот же заказ/договор

Неправильная организация регламентных заданий

- обмены и фоновые обработки идут в пик пользовательской нагрузки

Широкие права и хаотичные исправления

- пользователи массово перепроводят документы «задним числом»

Важный термин: взаимная блокировка (deadlock)

Deadlock — ситуация, когда два процесса ждут друг друга и никто не может продолжить.

На стороне СУБД это обычно диагностируется инструментами самой базы данных. Если заказчик использует PostgreSQL или Microsoft SQL Server, полезно знать, что у них есть отдельные понятия и средства диагностики блокировок:

Документация PostgreSQL: Explicit Locking

Документация Microsoft: Transaction Locking and Row Versioning Guide

Консультанту не нужно читать эти документы целиком, но полезно понимать: блокировки — это не «магия 1С», а закономерная часть работы СУБД.

Как консультанту действовать при жалобе на блокировки

Цель консультанта — не «разблокировать срочно», а сделать проблему управляемой: воспроизводимость, причина, решение и профилактика.

Алгоритм первичной диагностики

Зафиксировать сценарий

- что именно делал пользователь - номер/дата документа - время начала и окончания ожидания - роль пользователя

Определить масштаб

- один пользователь или многие - один документ или любой - повторяется постоянно или в определенное время

Проверить конкурирующие процессы

- идет ли закрытие месяца - работают ли обмены - есть ли массовые обработки

Запросить технические факты

- фрагмент журнала регистрации на время инцидента - данные от ИТ/DBA по блокировкам/ожиданиям (кто кого блокировал)

Согласовать временное правило, если нужно

- например, «закрытие месяца только ночью» - «массовые перепроведения запрещены в рабочее время»

Результат этого алгоритма — не «ощущение», а набор фактов, по которым можно поставить задачу разработчику или изменить регламент.

Частая ловушка: «снимите блокировку»

«Снять блокировку» (остановить сеанс) иногда нужно как аварийная мера, но:

это может привести к неполному выполнению операции

может оставить данные в промежуточном состоянии (в зависимости от сценария)

не устраняет причину и обычно повторяется

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

Журнал регистрации: зачем он нужен и как консультанту его использовать

Что такое журнал регистрации

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

Для консультанта журнал регистрации — это:

инструмент доказательности (что реально происходило)

источник времени и контекста (когда, кто, где)

способ связать жалобу пользователя с конкретным событием и объектом

Чем журнал регистрации отличается от технологического журнала

Важно не путать эти два инструмента.

| Критерий | Журнал регистрации | Технологический журнал | |---|---|---| | Назначение | Фиксация событий, ошибок, действий | Глубокая техническая трассировка производительности и работы платформы | | Кому полезен ежедневно | Консультант, поддержка, администратор | Разработчик, администратор, инженер производительности | | Уровень детализации | Средний (события и контекст) | Очень высокий (время, операции, запросы, ожидания — в зависимости от настроек) | | Типичный вопрос | «Что было в момент ошибки?» | «Почему операция занимала 40 секунд и где именно?» |

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

Какие события важно уметь искать консультанту

ошибки проведения документов

ошибки обменов и интеграций

ошибки прав доступа

сообщения о блокировках (если они фиксируются)

«массовые» проблемы в определенное время (по временным интервалам)

Как оформлять запрос «дайте журнал» корректно

Чтобы ИТ могла быстро помочь, запрос должен быть точным.

Укажите интервал времени

- например: «07:50–08:20 06.02.2026»

Укажите пользователя и роль

Укажите объект

- документ, справочник, отчет

Укажите симптом

- «ожидание при проведении», «ошибка записи», «не удалось выполнить обмен»

Типовые сценарии проблем и «правильные» артефакты консультанта

Сценарий: зависает проведение документа

Что нужно зафиксировать консультанту:

документ (вид, номер, дата)

объем (количество строк, особенности данных)

условия (какой период, какие включены разрезы учета)

параллельная активность (закрытие месяца, регламентные задания)

подтверждение через журнал регистрации (ошибка/предупреждение/время)

Результат для постановки задачи:

критерии приемки по времени и поведению

тестовые данные (пример документа)

уточнение: связано ли с блокировкой или с расчетом/логикой

Сценарий: «все зависает в одно и то же время»

Часто это не дефект формы, а конфликт с регламентными заданиями.

Что делает консультант:

собирает статистику: время, роли, операции

проверяет расписание обменов/обработок

согласует регламент: окно тяжелых операций

Итоговый артефакт:

изменение регламента выполнения (кто запускает, когда)

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

Сценарий: «пользователи делают массовые исправления задним числом»

Это комбинация риска по производительности и надежности учета.

Что делает консультант:

связывает проблему с темой ролей и прав из TO-BE

предлагает ограничение прав на изменения прошлых периодов

добавляет регламент «как правильно исправлять и перезакрывать»

Итоговый артефакт:

матрица прав (кто может исправлять)

сценарий исправления с критериями приемки

Профилактика: как консультанту снижать риск проблем заранее

Фиксировать нефункциональные требования по ключевым сценариям

Если на проекте есть критичные операции, полезно заранее согласовать простые ограничения:

допустимое время выполнения на типовом документе

ограничения по периоду/отборам для тяжелых отчетов

окна выполнения регламентных операций

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

Проектировать регламенты, которые защищают от блокировок

закрытие периода только в согласованное окно

запрет массовых перепроведений в рабочее время

регламент обработки ошибок обмена (а не «пока само пройдет»)

Поддерживать трассируемость «инцидент → причина → решение»

Практичный формат учета инцидентов и улучшений:

| Инцидент | Сценарий | Факт (журнал/лог) | Причина | Решение | Как проверяем | |---|---|---|---|---|---| | «Висит проведение реализации» | Проведение R-451 | Запись в журнале в 10:12 | Блокировка из-за инвентаризации | Разнести по времени + оптимизация | UAT + регрессия сценария |

Итоги

Производительность и надежность в 1С-проектах — это управляемая дисциплина, а не «периодические пожары».

Ключевые мысли для консультанта 1С:

жалоба «тормозит» должна быть преобразована в воспроизводимый сценарий с измеримыми признаками

диагностировать удобно по слоям: процесс → права → данные → интеграции → инфраструктура → СУБД

блокировки — нормальный механизм защиты данных, но проблемные блокировки возникают из-за долгих операций, конкуренции и неправильного регламента

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

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

Безопасность и права: роли, RLS, персональные данные, аудит

Зачем консультанту 1С разбираться в безопасности

В прошлых темах курса мы строили управляемую цепочку внедрения: AS-IS → TO-BE → требования → постановки задач → тестирование/приемка → обновления/сопровождение → надежность. Безопасность и права в 1С проходят через всю эту цепочку и напрямую влияют на то, будет ли процесс работать как задумано.

Если права спроектированы плохо, возникают типовые провалы:

пользователи обходят процесс (например, проводят документы «мимо согласования»)

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

менеджеры видят «чужие» цены, клиентов или зарплаты

расследование инцидента невозможно, потому что нет аудита

Для консультанта безопасность — это не «настроить роли потом», а часть проектирования TO-BE: роли, ответственность, контроль, приемка и сопровождаемость.

!Как права связывают TO-BE, настройку, тестирование и эксплуатацию

Термины: минимальный словарь консультанта

Чтобы одинаково разговаривать с бизнесом, разработчиками и ИТ, зафиксируем базовые понятия.

Пользователь — учетная запись, под которой человек (или интеграция) работает в системе.

Роль — набор разрешений на действия и данные.

Права — конкретные разрешения: чтение, добавление, изменение, проведение, удаление, просмотр отчетов.

Профиль/группа доступа — удобный способ назначать набор ролей пользователям (термины отличаются по конфигурациям).

Ограничение доступа к данным — правило, по которому пользователь видит только часть данных (например, только свою организацию или склад).

RLS (Row Level Security) — ограничение доступа на уровне записей (строк) данных: «видишь не всё, а только разрешенные строки».

Персональные данные (ПДн) — данные, относящиеся к определенному или определяемому физическому лицу.

Аудит — возможность восстановить, кто, что и когда сделал, и доказать это фактами.

Нормативная база по ПДн в РФ часто требуется на проектах (как минимум для корректных формулировок и ответственности): Федеральный закон №152-ФЗ «О персональных данных».

Принципы проектирования доступа в 1С

Принцип минимально необходимых прав

Пользователь должен иметь ровно те права, которые нужны для его сценариев.

Практический эффект:

меньше случайных ошибок и «непреднамеренных исправлений»

ниже риск утечек и злоупотреблений

проще расследовать инциденты и обучать пользователей

Принцип разделения обязанностей

Если один человек может:

создать документ

провести документ

исправить документ задним числом

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

Типовой пример разделения:

менеджер создает заказ

руководитель согласует скидку

кладовщик проводит отгрузку

бухгалтер формирует закрывающие и контролирует регучет

Эта логика напрямую опирается на материалы TO-BE из предыдущих тем курса.

Принцип «одна версия правды» для справочников и настроек

В проектах 1С права — это еще и инструмент защиты мастер-данных:

кто создает контрагентов

кто меняет номенклатуру и ставки НДС

кто редактирует статьи затрат и статьи ДДС

Если это не закрепить правами и регламентом, качество учета деградирует даже при идеальной функциональности.

Модель доступа в 1С: из чего обычно состоит решение

На практике решение по доступу складывается из нескольких слоев.

Роли и права на объекты

Ограничения на данные (включая RLS)

Процессные ограничения (например, запреты действий по статусам)

Аудит и журналирование

!Четыре слоя, из которых обычно складывается безопасность

Роли и матрица прав: главный артефакт консультанта

Два документа, которые нельзя путать

Матрица ответственности отвечает на вопрос кто что делает в процессе.

Матрица прав отвечает на вопрос кто что может сделать в 1С.

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

Минимальная матрица прав (пример структуры)

| Объект 1С | Действие | Роль «Менеджер» | Роль «Кладовщик» | Роль «Бухгалтер» | Комментарий | |---|---|---|---|---|---| | Заказ клиента | Создать/изменить | Да (до согласования) | Просмотр | Просмотр | Ограничение по статусу | | Реализация | Создать | Да (без проведения) | Да | Да | Проведение — отдельное право | | Реализация | Провести | Нет | Да | Да | Разделение обязанностей | | Контрагенты | Создать | По регламенту | Нет | Да | Часто ввод централизованный | | Отчет по валовой прибыли | Просмотр | Только свои продажи | Нет | Полный | Ограничения по данным |

Важно: на проекте матрица должна быть привязана к вашим TO-BE сценариям и критериям приемки из предыдущих тем.

RLS в проектах 1С: когда нужен и как его правильно обсуждать

Что такое RLS простыми словами

RLS — это механизм, который ограничивает видимость данных на уровне отдельных записей.

Примеры требований «по смыслу RLS»:

менеджер видит только своих клиентов и документы

филиал видит только свою организацию и склады

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

Когда достаточно «обычных» прав, а когда без RLS сложно

Часто достаточно обычных прав, если:

данные разделены по объектам (одни документы доступны одной роли, другие — другой)

доступ контролируется статуса́ми (например, «черновик видит автор, согласованное видят все») и это поддержано процессом

RLS часто нужен, если:

требуется разделение доступа по одному и тому же виду документа (например, одни и те же «Реализации», но по разным организациям/складам/подразделениям)

отчетность должна строиться на общей базе, но пользователи не должны видеть чужие разрезы

есть чувствительные данные (зарплата, персональные данные) и их нельзя «спрятать» простым разделением по объектам

Что консультант обязан зафиксировать в требованиях к RLS

Чтобы RLS не стал «магией, которая потом ломает отчеты», фиксируйте:

Критерий разделения данных

Источники значения критерия

Объекты, к которым применяется

Исключения и админские роли

Сценарии проверки

Пример формулировки уровня требований:

«Роль “Менеджер” видит документы продаж только по своим контрагентам, определяемым по закреплению в карточке контрагента. Роль “Руководитель продаж” видит документы всех менеджеров подразделения. В отчетах применяется та же логика, включая детализацию до документа».

Типовые ошибки при проектировании RLS

RLS задан для документов, но не учтен в отчетах и расшифровках

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

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

Персональные данные: что должен понимать консультант 1С

Консультант не обязан быть юристом или специалистом по ИБ, но обязан:

распознавать, где в проекте возникают ПДн

обеспечить корректную организацию доступа, хранения и аудита

поднимать вопросы ответственных лиц (ИБ, юристы, кадровая служба)

Где в 1С чаще всего появляются ПДн

ЗУП: сотрудники, физлица, кадровые документы, начисления, выплаты

Документооборот и сканы: паспорта, заявления, договоры, доверенности

CRM и продажи: контакты физических лиц, телефоны, e-mail

Интеграции: обмены с кадровыми сервисами, банками, ЭДО (в зависимости от сценария)

Практические требования к доступу для ПДн

В проектах это обычно превращается в конкретные решения:

ограничить круг ролей, которые видят полный набор реквизитов физлица

разделить роли «просмотр кадровых данных» и «просмотр расчетов зарплаты»

ограничить доступ к печатным формам и файлам-вложениям, если в них ПДн

установить регламент: кто и как выгружает данные в Excel и куда хранит

Что важно для сопровождения

ПДн — это не только доступ в интерфейсе. Это еще:

резервные копии

выгрузки и обмены

тестовые базы

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

Аудит в 1С: как сделать изменения доказуемыми

Что такое аудит в практическом смысле

Аудит отвечает на вопросы:

кто изменил документ или справочник

когда это произошло

что было изменено

было ли это в рамках полномочий

Основные источники фактов

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

Журнал регистрации: фиксирует события, ошибки, действия (полезен консультанту и поддержке)

Регламент процесса: определяет, какие действия допустимы и кем

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

Официальные входные точки по платформе и сопровождению, где чаще всего ищут методические рекомендации и практики эксплуатации: 1С:Предприятие 8 и 1С:ИТС.

Что консультант должен потребовать как критерии готовности (DoD) по безопасностным изменениям

обновлена матрица прав и согласована владельцем процесса

выполнены позитивные проверки (роль может то, что должна)

выполнены негативные проверки (роль не может того, что не должна)

проверены отчеты и детализация с учетом ограничений

определено, где смотреть аудит и кто расследует инциденты

Проверка прав: как тестировать и принимать безопасность

Безопасность нужно принимать так же, как функциональность — по тест-кейсам и критериям приемки.

Минимальный набор тестов по доступам

Позитивные проверки

- пользователь выполняет свой сценарий от начала до конца

Негативные проверки

- пользователь пытается выполнить запрещенное действие и получает понятный отказ

Проверка отчетов

- отчет и расшифровки соблюдают ограничения данных

Проверка «критичных операций»

- закрытый период, проведение, исправления задним числом

Эта логика напрямую продолжает тему курса про тестирование, UAT и регрессию: права должны входить в регрессионный пакет, иначе каждое обновление рискует «сломать безопасность» незаметно.

Типовые шаблоны решений по доступам для разных контуров

Оперативный контур (продажи, закупки, склад)

Типовые идеи:

менеджеры создают, но не проводят критичные документы

склад проводит складские операции, но не меняет цены и условия договоров

ограничения по складам и подразделениям (часто через RLS)

Финансы и регучет

Типовые идеи:

запрет изменения документов закрытого периода для большинства ролей

отдельная роль «исправления» с регламентом перезакрытия

строгая защита справочников, влияющих на проводки и отчетность

ЗУП и ПДн

Типовые идеи:

разделение ролей «кадры» и «расчет»

отдельные права на просмотр расчетов и выплат

ограничение доступа к печатным формам и вложениям, содержащим ПДн

Частые ошибки консультанта и как их предотвращать

Дать всем полные права «на запуск»

Проектировать доступы без связи с TO-BE

Ограничить документы, но забыть про отчеты и расшифровки

Не определить роли поддержки и расследования

Не включить права в UAT и регрессию

Профилактика сводится к дисциплине артефактов курса:

сценарии TO-BE

матрица ролей и прав

критерии приемки

тест-кейсы (включая негативные)

журналирование и трассируемость релизов

Итоги

Безопасность в 1С — это управляемое проектирование доступа, а не «настройка ролей в конце».

Ключевые выводы для консультанта 1С:

роли и права должны следовать за TO-BE процессом и разделением ответственности

RLS нужен там, где требуется ограничивать доступ к данным на уровне записей, особенно в отчетах и детализации

персональные данные требуют отдельного внимания: доступ, тестовые среды, обмены и хранение

аудит и журнал регистрации превращают безопасность в доказуемую практику и помогают расследовать инциденты

права обязательно тестируются: позитивные сценарии, негативные проверки, отчеты, регрессия

Коммуникации и проектная работа: внедрение, обучение, поддержка пользователей

Зачем консультанту 1С прокачивать коммуникации и «проектную механику»

Консультант 1С редко проваливает проект из-за того, что «не знает, где настройка». Чаще провал выглядит иначе:

требования согласовали, но пользователи делают «по-старому»

доработку реализовали, но ее никто не принял по сценариям

релиз выкатили, но поддержки и регламента нет — начинается поток инцидентов

Эта тема связывает в единую практику предыдущие материалы курса:

AS-IS и TO-BE задают процессы, роли и правила работы

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

тестирование, обновления, надежность и безопасность дают предсказуемость эксплуатации

Здесь мы добавляем то, без чего внедрение не становится рабочей системой:

как организовать коммуникации и договоренности

как провести внедрение (cutover), демонстрации и приемку

как обучить пользователей так, чтобы они реально работали

как выстроить поддержку и управлять инцидентами и изменениями

!Цикл жизни изменения в 1С: от требований до поддержки и улучшений

Роли и каналы: с кем консультант коммуницирует на внедрении

Коммуникации в 1С-проекте удобно рассматривать как работу со стейкхолдерами (участниками, влияющими на результат).

Типовая карта ролей

Заказчик / владелец процесса: принимает ключевые решения по методике и правилам

Ключевые пользователи: принимают результат в сценариях, формируют требования «с земли», обучают коллег или помогают обучению

Конечные пользователи: работают в системе и создают основной поток обращений

Разработчики: реализуют изменения, исправляют дефекты

ИТ/администраторы/DBA: инфраструктура, доступы, мониторинг, резервные копии

Руководитель проекта: сроки, бюджет, риски, план

Ваша зона ответственности как консультанта:

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

Ключевой принцип коммуникаций

не обсуждать изменения «устно и навсегда»

фиксировать договоренности в артефактах: требования, задачи, протоколы, регламенты, релиз-ноты

План коммуникаций: что фиксировать, чтобы не утонуть

Коммуникации становятся управляемыми, когда у проекта есть понятный ритм и правила фиксации.

Минимальный план коммуникаций (шаблон)

| Элемент | Что фиксируем | Пример | |---|---|---| | Цели коммуникаций | какие решения должны приниматься | «согласовать правила резервирования и запреты отгрузки» | | Форматы встреч | какие встречи существуют | «еженедельный статус», «демо», «воркшоп по процессу» | | Участники и роли | кто принимает решения | «владелец процесса утверждает, ключевой пользователь принимает сценарии» | | Каналы | где пишем и где фиксируем | «вопросы — в трекере, договоренности — в протоколе» | | SLA реакции | ожидаемое время ответа | «вопросы по UAT — ответ в течение 4 часов» | | Правила изменений | как меняем требования | «любое изменение — новой задачей или change request» |

Ошибки, которые ломают коммуникации

«Все обсуждаем в чате» без фиксации итогов

решения принимаются людьми без полномочий

нет единого места, где хранится актуальная версия правил и инструкций

Демонстрации и приемка: как консультанту показывать результат

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

Демо: цель и формат

Цель демо — не «показать форму», а подтвердить, что сценарий TO-BE выполняется.

Практичный формат демо:

Открываем сценарий: название, роли, предусловия

Проходим шаги в системе

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

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

Фиксируем итоги: принято, замечания, что переносим в следующий релиз

Протокол демо (что фиксировать)

| Поле | Зачем | |---|---| | Что показывали (ID требований/задач) | трассируемость | | Кто участвовал | подтверждение приемки | | Итог по каждому пункту | «принято/не принято/принято с оговорками» | | Замечания и решения | чтобы не спорить «что имели в виду» | | Сроки исправлений | управление ожиданиями |

Внедрение (cutover): как не превратить запуск в хаос

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

Что такое план внедрения

План внедрения отвечает на вопросы:

что меняем (функциональность, права, регламенты)

когда и в каком окне

кто делает шаги (RACI)

как проверяем, что запуск прошел успешно

как откатываемся, если все пошло плохо

Минимальная структура плана внедрения

| Раздел | Содержание | |---|---| | Объем релиза | список задач и изменений | | Предусловия | готовность тестов, UAT, резервная копия | | Окно внедрения | дата/время, ограничения бизнеса | | Технические шаги | обновление, расширения, настройки | | Данные | перенос/дозаполнение/сверки | | Коммуникации | кому сообщаем до/после | | Контрольный прогон | 5–10 критичных проверок | | Гиперподдержка | кто дежурит и как принимаем обращения |

Контрольный прогон после релиза (smoke на языке бизнеса)

Сформируйте короткий список сценариев, которые нельзя «уронить»:

вход под ключевыми ролями

создание и проведение 1–2 ключевых документов

формирование 1–2 ключевых отчетов

проверка интеграции по одному тестовому событию (если критично)

Эта логика продолжает тему тестирования и регрессии из предыдущей статьи.

Обучение пользователей: как сделать так, чтобы «начали работать»

Обучение в 1С-проекте — это не презентация про меню. Это подготовка людей к выполнению сценариев TO-BE в рамках ролей и прав.

Принципы эффективного обучения

обучаем по ролям, а не «всех всему»

обучаем по сценариям (из TO-BE), а не по разделам интерфейса

обучаем на похожих данных (реальные примеры, но с учетом политики безопасности)

закрепляем обучение инструкциями и регламентом

Матрица обучения (шаблон)

| Роль | Сценарии обучения | Формат | Артефакт | |---|---|---|---| | Менеджер продаж | заказ → резерв → контроль оплаты | воркшоп 1,5 часа | памятка + видео 10 минут | | Кладовщик | отбор/комплектация → отгрузка → инвентаризация | практикум | инструкция + чек-лист | | Бухгалтер | контроль первички → закрывающие → контрольные отчеты | демо + практика | регламент + контрольные отчеты |

Форматы материалов, которые реально «живут»

памятка на 1 страницу: «как сделать 5 основных действий»

инструкция по сценарию: шаги и контрольные точки

FAQ: топ-15 вопросов и ошибок

релиз-нота: что изменилось, кому важно, что делать иначе

Справочный материал по Scrum (как источник терминов и дисциплины итераций, если проект работает в agile-режиме): The Scrum Guide.

Типовые ошибки обучения

обучили «в конце», когда уже запуск завтра

обучили без доступа и без правильных ролей (в итоге на запуске «ничего не вижу»)

обучили без правил исключений (возвраты, частичные отгрузки, исправления)

Поддержка пользователей: как консультанту организовать «первую линию смысла»

Поддержка — это продолжение внедрения. Сразу после запуска у пользователей появляются реальные случаи, которые невозможно предусмотреть на 100%.

Разница между инцидентом, запросом и изменением

Чтобы не смешивать все в одну очередь:

Инцидент: что-то сломалось относительно согласованного поведения

Запрос на обслуживание: нужно действие/доступ/консультация (например, «создать пользователя», «помогите разнести оплату»)

Изменение: хотим новое правило или расширение функциональности

Если все это не разделять, команда поддержки будет «чинить учет методикой» или «программировать вместо обучения».

Триаж обращений: как быстро понять, что делать

Практичный алгоритм консультанта при обращении:

Зафиксировать сценарий и роль пользователя

Уточнить что ожидали и что получили

Проверить класс проблемы:

- права - данные - настройка/политика - дефект разработки - проблема интеграции

Принять решение:

- обучить и дать инструкцию - исправить данные по регламенту - поставить задачу разработчику (с критериями приемки) - эскалировать в ИТ (производительность, блокировки, инфраструктура)

Этот подход напрямую продолжает тему диагностики, журнала регистрации и причин проблем.

Карточка обращения (шаблон)

| Поле | Пример | |---|---| | Кто | «Кладовщик Иванов» | | Роль в системе | «Склад» | | Сценарий | «Проведение реализации» | | Объект | «Реализация №451 от 07.02» | | Шаги | «Открыть → Провести» | | Факт | «Ожидание/ошибка/не проводится» | | Ожидание | «Должно проводиться при наличии резерва» | | Время | «10:12–10:15» | | Приоритет | «Блокирующий отгрузки» |

Чем лучше заполнена карточка, тем быстрее вы либо решите вопрос обучением, либо поставите корректную задачу.

Гиперподдержка после запуска: как прожить первые недели

После внедрения обычно нужен режим повышенной поддержки.

Что такое гиперподдержка

Это короткий период (часто 1–4 недели), когда:

команда быстро реагирует на обращения

консультант собирает типовые ошибки и превращает их в улучшения процесса

фиксируются «дыры» в обучении и регламентах

Как измерять, что ситуация стабилизируется

Без сложной аналитики достаточно простых признаков:

снижается количество однотипных вопросов

доля «обучение/права/данные» уменьшается, растет доля «обычных запросов»

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

Что обязан сделать консультант по итогам гиперподдержки

обновить FAQ и памятки по реальным вопросам

обновить регламенты (если выяснилось, что правило неполное)

сформировать бэклог улучшений и согласовать приоритет

Конфликты и сопротивление изменениям: как консультанту действовать

Сопротивление почти всегда связано не с «вредностью людей», а с рисками:

потеря контроля (например, менеджеру запретили править цену)

рост ответственности (теперь нужно заполнять обязательные поля)

страх ошибок (особенно в финансах и зарплате)

Техники, которые работают у консультанта

говорить через ценность и риск на языке роли

показывать сценарий и последствия (что будет, если обходить процесс)

фиксировать решения владельцем процесса, а не «кто громче»

давать быстрые «маленькие победы»: чек-листы, подсказки, короткие видео

Что делать, если спор методический

Возвращаемся к границе роли из первой статьи курса:

консультант фиксирует варианты и последствия

решение принимает уполномоченный владелец процесса

результат оформляется в регламенте и требованиях

Как не потерять связку артефактов: от требований к знаниям поддержки

Одна из сильнейших практик консультанта — превращать знания проекта в воспроизводимую базу.

Минимальная трассируемость для эксплуатации

| Что | С чем связываем | Зачем | |---|---|---| | Требование (ID) | задача, тест-кейс, релиз | понимать «почему так работает» | | Демо/приемка | требования и сценарии | доказуемость | | Инструкция/FAQ | сценарии TO-BE | обучение и снижение обращений | | Инцидент | релиз и изменение | ускорение расследований |

Эта дисциплина напрямую поддерживает темы курса про сопровождение, регрессию, журнал регистрации и аудит.

Итоги

Коммуникации, внедрение, обучение и поддержка — это практики, которые превращают «сделали в 1С» в «бизнес работает по-новому и устойчиво».

Ключевые выводы для консультанта 1С:

коммуникации должны иметь ритм, роли, каналы и фиксацию договоренностей

демо и приемка проводятся по сценариям TO-BE и критериям приемки, а не «по ощущениям»

внедрение требует плана: окно работ, контрольные проверки, гиперподдержка

обучение строится по ролям и сценариям, закрепляется памятками, инструкциями, FAQ и релиз-нотами

поддержка становится управляемой, если разделять инциденты, запросы и изменения и собирать обращения в воспроизводимом формате

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

Экосистема 1С: платформа, клиент-сервер, лицензирование, сервисы

Зачем консультанту разбираться в экосистеме 1С

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

Чтобы уверенно работать на проектах, консультанту нужно понимать не только что хочет бизнес, но и в какой среде это будет жить:

на какой технологии работает решение (платформа и прикладное решение)

где хранятся данные и как масштабируется система (файловый вариант или клиент-сервер)

какие ограничения накладывает лицензирование (сколько пользователей может работать одновременно и что нужно докупить)

какие сервисы 1С можно подключить вместо доработок (отчетность, ЭДО, проверка контрагентов)

Официальные входные точки в экосистему: 1С:Предприятие 8 и 1С:ИТС.

Платформа 1С и прикладные решения

Что такое платформа 1С:Предприятие

Платформа 1С:Предприятие — это технологическая основа, которая обеспечивает:

хранение и обработку данных

механизм пользователей, прав и ролей

интерфейсы (толстый/тонкий/веб-клиент)

отчеты, печатные формы, обмены данными

расширяемость и разработку

Платформа одна, а прикладных решений (конфигураций) много.

Что такое конфигурация и почему это важно

Конфигурация (часто говорят конфигурация 1С или прикладное решение) — это прикладная логика для конкретных задач бизнеса: бухгалтерия, торговля, зарплата, производство.

Примеры распространенных типовых решений:

1С:Бухгалтерия

1С:Зарплата и управление персоналом

1С:Управление торговлей

1С:ERP

Для консультанта ключевая мысль:

платформа задает технические возможности и ограничения

конфигурация задает предметную логику и процессы

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

Информационная база

Информационная база (часто сокращают до ИБ) — это набор данных и настроек конкретной организации или контура учета, с которыми работают пользователи.

Обычно на проекте вы будете обсуждать:

сколько ИБ нужно (например, отдельная ИБ для тестирования и отдельная для продуктивной работы)

как переносить настройки и данные между ними

кто и как управляет доступом

Варианты развертывания: файловый и клиент-сервер

В 1С классически выделяют два основных варианта работы информационной базы.

Файловый вариант

В файловом варианте информационная база хранится в виде файла(ов) на диске, а пользователи подключаются к этому файлу по сети или локально.

Когда это подходит:

небольшая компания

мало одновременных пользователей

нет требований к высокой доступности

Ограничения, которые важно проговаривать с заказчиком:

чувствительность к качеству сети и состоянию файлового хранилища

сложнее масштабировать нагрузку

выше риск блокировок при одновременной активной работе

Клиент-серверный вариант

В клиент-серверном варианте появляется сервер 1С, а данные хранятся в СУБД (например, PostgreSQL или Microsoft SQL Server), и клиенты подключаются к серверу.

Когда это обычно выбирают:

много пользователей и высокая параллельность

интеграции и регламентные задания

требования к производительности и стабильности

необходимость разграничения сред (разработка, тест, продуктив)

Ключевые плюсы:

лучше масштабирование и управляемость

гибче администрирование

устойчивее работа при росте объема данных

Ключевой момент для консультанта: выбор варианта развертывания влияет на сроки внедрения, требования к инфраструктуре и стоимость владения.

!Сравнение файлового и клиент-серверного вариантов и роли сервера 1С и СУБД

Клиенты 1С: толстый, тонкий, веб

В 1С есть разные варианты клиентских приложений. Консультанту полезно понимать их не на уровне установки, а на уровне последствий для пользователей и ИТ.

Толстый клиент

Толстый клиент — клиентское приложение с более широкими возможностями администрирования и разработки.

Типично используется:

разработчиками

администраторами

иногда — опытными пользователями в специфических сценариях

Тонкий клиент

Тонкий клиент — основной вариант для повседневной работы пользователей.

Что важно в проектах:

проще управлять рабочими местами

типовой вариант для клиент-серверной архитектуры

Веб-клиент

Веб-клиент — работа через браузер.

Частые причины выбора:

упрощение доступа для удаленных сотрудников

работа на устройствах, где неудобно ставить клиент

Но нужно заранее уточнять:

все ли функции конкретной конфигурации корректно поддерживаются в веб-сценариях

требования безопасности и публикации сервера

Сервер 1С, кластер и СУБД: что нужно знать консультанту

Сервер 1С

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

Практически это означает:

производительность зависит не только от «скорости компьютера пользователя», но и от сервера

регламентные задания и фоновые обработки нужно учитывать при планировании окна работ

Кластер серверов 1С

В крупных установках используют кластер — несколько серверных процессов/узлов, которые распределяют нагрузку и повышают отказоустойчивость.

Консультант обычно не проектирует кластер в одиночку, но должен уметь:

собрать требования к доступности и нагрузке

донести риски, если инфраструктура не соответствует ожиданиям бизнеса

СУБД

СУБД (система управления базами данных) хранит данные в клиент-серверном варианте.

На уровне консультанта важны вопросы:

кто отвечает за резервное копирование и восстановление

какие регламенты обслуживания приняты у заказчика

какие ограничения по времени простоя допустимы

Лицензирование: базовые понятия без юридических деталей

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

Какие лицензии встречаются чаще всего

Обычно в обсуждении всплывают следующие сущности:

лицензии на рабочие места (клиентские лицензии): определяют, сколько пользователей может работать одновременно (в терминах подключений)

лицензия на сервер 1С: нужна для клиент-серверного варианта

лицензии прикладных решений: право использования конкретной конфигурации (самого продукта)

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

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

Лицензии влияют на:

возможность перевода с файлового варианта на клиент-сервер (часто нужен сервер)

число реальных одновременных пользователей в пиковые периоды (закрытие месяца, массовая отгрузка)

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

Практичный чек-лист вопросов на старте:

сколько пользователей будет работать в системе одновременно, а не «всего по штату»

будут ли внешние пользователи (филиалы, удаленные сотрудники, подрядчики)

есть ли тестовая база и нужна ли она на постоянной основе

планируется ли рост нагрузки в горизонте года

1С:ИТС и сервисы 1С: что это и как использовать в проектах

1С:ИТС

1С:ИТС — это инфраструктура сопровождения: доступ к обновлениям, материалам, методикам и сервисам (в зависимости от уровня договора).

Для консультанта это означает:

типовые обновления и изменения законодательства приходят через штатные механизмы сопровождения

многие вопросы по регламентированному учету и настройкам проще закрывать через официальные материалы, чем «изобретать заново»

Официальный ресурс: 1С:ИТС.

Сервисы 1С, которые часто заменяют доработки

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

1С-Отчетность: отправка регламентированной отчетности из 1С

1С:ЭДО: электронный документооборот (обмен юридически значимыми документами)

1С:Контрагент: проверка реквизитов и данных контрагентов, автозаполнение

1С:ДиректБанк: обмен с банком напрямую из 1С

На уровне роли консультанта важно:

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

понять, какие сервисы нужны для требований (например, ЭДО как часть процесса закупок)

описать изменения в процессе: кто подписывает, кто согласует, где хранится документ, как выглядит контроль статусов

1С:Fresh как вариант эксплуатации

1С:Fresh — модель работы, когда 1С предоставляется как облачный сервис (вместо разворачивания собственной инфраструктуры).

Консультант должен уметь проговорить с заказчиком:

какие ограничения и возможности у облачного варианта

как будет организован доступ, обмены, права

какие требования безопасности и хранения данных применимы

Официальная точка входа: 1С:Fresh.

Как консультанту применять знания об экосистеме в реальной работе

Типовые ситуации на проекте

Бизнес просит «ускорить 1С»

- Консультант уточняет: файловая или клиент-серверная база, сколько пользователей, когда пики, какие операции тормозят.

Заказчик хочет веб-доступ «для всех»

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

Пользователи просят «сделайте отправку отчетности»

- Консультант проверяет: можно ли закрыть сервисом 1С-Отчетность, какие роли и регламенты нужны, кто отвечает за сертификаты/подписи.

Требуется обмен с банком и автоматизация платежей

- Консультант рассматривает 1С:ДиректБанк и описывает процесс: подготовка, согласование, подписание, отправка, статус.

Что фиксировать в артефактах консультанта

Чтобы не возникало «мы думали, что оно само», полезно явно фиксировать:

вариант развертывания (файл или клиент-сервер)

состав сред (разработка, тест, продуктив) и правила переноса

предполагаемое число одновременных пользователей

необходимость лицензии сервера 1С

список сервисов 1С, которые требуются/уже подключены

ограничения и допущения (например, веб-доступ только для части ролей)

Итоги

Экосистема 1С — это сочетание платформы, прикладных решений, архитектуры развертывания, лицензирования и сервисов сопровождения.

Для консультанта 1С это практический инструмент:

точнее формулировать требования с учетом реальных ограничений

выбирать между типовым функционалом, сервисом и доработкой

заранее поднимать вопросы инфраструктуры и лицензий, чтобы не сорвать сроки

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

Карьера консультанта 1С: портфолио, сертификации, типовые собеседования

Зачем консультанту 1С думать о карьере уже сейчас

За предыдущие темы курса мы собрали «проектный скелет» профессии: роль консультанта, экосистема 1С, базовые понятия платформы, типовые конфигурации, AS-IS и TO-BE, требования, настройки, финансы, оперативный контур, ЗУП, постановка задач разработчикам, интеграции, отчеты, тестирование, обновления, надежность, безопасность и коммуникации.

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

портфолио и измеримые результаты

сертификации и их практический смысл

типовые форматы собеседований и кейсов

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

Роли и траектории: кем можно стать в 1С

Внутри профессии консультанта есть несколько устойчивых траекторий. Важно понимать их, чтобы правильно собирать опыт и портфолио.

Универсальный консультант (сквозные процессы)

Фокус: процессы и интеграция контуров.

Типичные задачи:

сквозные сценарии «заказ → отгрузка → оплата → отражение в регучете»

границы систем (например, УТ + Бухгалтерия)

постановка задач на доработки и приемка

Ценность на рынке: умеет соединять несколько подразделений и не «ломать» учет.

Предметный консультант

Фокус: глубина в одном контуре.

Типичные специализации:

финансы и регламентированный учет

оперативный контур (продажи, закупки, склад, производство)

ЗУП (кадры, расчет, отчетность)

Ценность: меньше ошибок методики и быстрее решения в «дорогих» зонах.

Функциональный архитектор

Фокус: целевая модель, границы, данные, интеграции, масштаб.

Частые артефакты:

модель TO-BE на уровне цепочек процессов

матрицы ролей и прав, принципы RLS

концепции интеграций и «точки истины»

Ценность: снижает стоимость ошибок на уровне проектных решений.

Руководитель направления или аналитик продукта

Фокус: управление бэклогом и ценностью, развитие системы.

Ценность: умеет упорядочить поток изменений, релизов, поддержки.

Уровни консультанта: что реально отличает Junior, Middle и Senior

Ниже не «официальные стандарты», а практичная рамка ожиданий, которая часто проявляется на собеседованиях.

Junior

Обычно умеет:

работать по готовым сценариям и инструкциям

собирать фактуру на интервью под руководством

оформлять задачи разработчику по шаблону

проверять доработки по базовым критериям

Слабое место: границы процесса и влияние на соседние контуры.

Middle

Обычно умеет:

самостоятельно вести участок: AS-IS → TO-BE → требования → задачи → приемка

выбирать «типовое/настройка/доработка» и объяснять последствия

связывать процесс с учетным результатом в отчетах

управлять изменениями на своем участке (реестр, версии, согласования)

Senior

Обычно умеет:

проектировать целевые модели и правила (процесс, данные, права, контроль)

видеть риски обновлений, производительности, безопасности

удерживать «одну версию правды» при интеграциях и нескольких базах

обучать и стабилизировать эксплуатацию (регламенты, гиперподдержка)

Портфолио консультанта 1С: что показывать, если вы не разработчик

Портфолио консультанта — это не GitHub с кодом. Это набор артефактов и кейсов, которые доказывают вашу способность доводить изменения до результата.

Принцип портфолио

Портфолио отвечает на три вопроса:

какую бизнес-проблему решали

каким способом в 1С это было сделано (типовое/настройка/доработка)

как проверили и запустили (критерии приемки, UAT, регрессия, сопровождение)

Что можно включить в портфолио (без нарушения NDA)

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

Подходящие элементы:

схема процесса TO-BE на 1–2 страницы (без названий компаний и контрагентов)

пример сценария с предусловиями, шагами, проверками и результатом

фрагмент матрицы ролей и прав (обезличенный)

пример постановки задачи разработчику с критериями приемки

пример набора тест-кейсов для UAT и регрессии

описание интеграции на уровне спецификации: объекты, направления, обработка ошибок

спецификация управленческого отчета: показатели, разрезы, источники, правила

> Практическое правило: в портфолио важна не «красота документа», а доказательство, что вы умеете делать работу проверяемой и приемлемой.

Формат «карточки кейса»

Чтобы не превращать портфолио в хаос, используйте единый формат. Это удобно и для резюме, и для рассказа на собеседовании.

Рекомендуемая структура карточки:

Контекст

Роль и зона ответственности

Проблема и риск

Решение

Артефакты

Тестирование и приемка

Результат и метрики

Что бы улучшили

Пример карточки кейса (кратко)

Контекст: торговая компания, связка УТ + Бухгалтерия

Роль: консультант по продажам/складу

Проблема: отгрузки без резерва приводили к отрицательным остаткам и конфликтам со складом

Решение: настройка правил резервирования, запрет проведения реализаций без резерва, регламент обработки исключений

Артефакты: сценарии TO-BE, матрица ролей, постановка задачи, чек-лист обучения

Приемка: UAT на 10 тест-кейсах, включили в регрессию

Результат: снизили число инцидентов «не можем отгрузить» и ручных корректировок

!Структура портфолио показывает, какие артефакты лучше всего демонстрируют компетенции консультанта

Как безопасно обезличивать материалы

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

Что убирать или заменять:

названия организаций, ИНН, номера договоров, номера счетов

реальные суммы, цены, зарплаты

ФИО и любые персональные данные

адреса серверов, токены, параметры безопасности

Что оставлять:

роли, шаги процесса, проверки

структуру документов и обязательность реквизитов

критерии приемки и сценарии тестирования

Сертификации 1С: как выбрать и как они реально помогают

Сертификация не заменяет опыт, но помогает:

структурировать знания и закрыть «дыры»

быстрее пройти первичный фильтр резюме

показать серьезность намерений при переходе в 1С

Официальная точка входа по обучению и сертификации 1С: Обучение и сертификация 1С:Предприятие.

Как читать сертификаты правильно

Сертификация бывает разного уровня сложности и ценности для рынка. Удобно делить по назначению.

Базовые подтверждения знаний

Углубленные по платформе или прикладным решениям

Практико-ориентированные, если доступны в вашем регионе и формате

Ключевой принцип: сертификат сильнее, если он поддержан портфолио и кейсами.

Рекомендованная стратегия для консультанта

Подход «всё подряд» редко эффективен. Лучше связать сертификацию с вашей траекторией.

Пример стратегии:

Закрыть фундамент по платформе и типовым решениям, с которыми вы работаете

Выбрать предметную область, где вы будете «глубокими»

Добавить 1–2 подтверждения по смежным навыкам, если это нужно проектам

Что важнее сертификата на собеседовании

Даже если сертификация есть, на интервью чаще всего проверяют другое:

как вы собираете требования и фиксируете TO-BE

как выбираете между настройкой и доработкой

как ставите задачу разработчику и принимаете результат

как мыслите про данные, права, интеграции и регрессию

Резюме консультанта 1С: что писать, чтобы вас позвали

Резюме консультанта должно быть не «списком программ», а списком результатов и ответственности.

Что обязательно должно быть в резюме

ваша роль на проектах и контуры

типовые конфигурации и версии на уровне опыта (например, «Бухгалтерия», «УТ», «ERP», «ЗУП»)

типы работ: обследование, моделирование, требования, постановка задач, UAT, сопровождение

интеграции: какие классы интеграций делали (файлы, HTTP API, планы обмена, очереди) на уровне участия

отчеты и аналитика: постановка требований, приемка, СКД как объект взаимодействия

Как формулировать опыт правильно

Плохо:

«занимался внедрением 1С»

«писал ТЗ и тестировал»

Хорошо:

«описал TO-BE для процесса закупки и согласовал регламент; подготовил 25 требований, 40 задач разработчикам; провел UAT с ключевыми пользователями; внедрил с гиперподдержкой»

«спроектировал матрицу ролей и прав для оперативного контура и провел негативные проверки доступа»

Типовые собеседования: какие этапы встречаются чаще всего

Процесс найма зависит от компании, но в 1С-консалтинге часто встречается похожий набор этапов.

Скрининг HR

Проверяют:

мотивацию и адекватность ожиданий

общий опыт и коммуникацию

готовность к формату работы (офис/удаленка/командировки)

Ваши сильные тезисы:

какой контур вы закрываете

какие артефакты вы делаете

как вы обеспечиваете приемку и устойчивость

Техническо-функциональное интервью

Проверяют:

понимание платформенных терминов на уровне консультанта

понимание типовых процессов в выбранной конфигурации

умение превращать запрос в сценарий, требование и критерии приемки

Кейс или тестовое задание

Может быть:

мини-обследование по описанию ситуации

проектирование TO-BE и матрицы ролей

постановка задач разработчику по нескольким требованиям

подготовка UAT-пакета или регрессии

Интервью с руководителем практики или РП

Проверяют:

зрелость: управление ожиданиями, фиксация договоренностей, работа с конфликтами

способность вести участок работ автономно

Что спрашивают на собеседовании: темы и примеры вопросов

Ниже — перечень тем, который напрямую опирается на материал курса.

Процесс и требования

Частые вопросы:

как вы проводите интервью и фиксируете AS-IS

как делаете TO-BE и какие артефакты отдаете

как формулируете критерии приемки

Что важно в ответе:

говорить сценариями и проверками

уметь показать, где вы фиксируете договоренности

Типовое vs доработка

Частые вопросы:

как понять, что типовой функционал закрывает потребность

когда вы рекомендуете доработку и как объясняете риски обновлений

Хороший ответ содержит:

проверку типовых механизмов

оценку влияния на процесс, учет, права и обновляемость

фиксацию решения в артефактах

Интеграции

Частые вопросы:

как определить «точку истины» по справочнику

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

как принять интеграцию: какие тесты обязательны

Хороший ответ ссылается на:

спецификацию интеграции

обработку ошибок и мониторинг

контрольные сверки

Отчеты и методика

Частые вопросы:

как описать управленческий отчет

что делать, если «цифры не сходятся»

Хороший ответ:

уточняет показатели, разрезы, источники и момент готовности

предлагает контрольный расчет и тестовые данные

Права и безопасность

Частые вопросы:

как проектировать роли и разделение обязанностей

как тестировать права и RLS

Хороший ответ:

использует матрицу ролей и прав

включает позитивные и негативные проверки

Производительность и надежность

Частые вопросы:

как вы реагируете на «1С тормозит»

что вы просите у ИТ и разработчиков

Хороший ответ:

превращает жалобу в воспроизводимый сценарий

использует журнал регистрации как источник фактов

Как отвечать на кейсы: шаблон мышления консультанта

На кейсах оценивают не «знание кнопок», а структуру действий.

Универсальный алгоритм ответа

Уточнить контекст и границы

Описать основной сценарий и 2–3 исключения

Перевести на язык 1С: объекты, роли, данные, контроль

Предложить вариант реализации: типовое/настройка/доработка

Назвать критерии приемки и тестовые данные

Указать риски: учет, права, интеграции, обновления, производительность

Мини-пример кейса

Ситуация: «Менеджеры отгружают без предоплаты, бизнес хочет запретить».

Структура ответа:

Уточнения: по каким клиентам, есть ли лимиты, исключения, кто утверждает

TO-BE: заказ → контроль оплаты/лимита → отгрузка

Объекты: заказ, реализация, взаиморасчеты, отчеты контроля

Реализация: настройка контроля, статусы, права на обход (если допускается)

Приемка: сценарии «оплачено/не оплачено», сообщения, права ролей

Риски: интеграция оплат, разнесение выписок, регламент обработки «неразнесенки»

Подготовка к собеседованию: практичный план на неделю

Этот план помогает упаковать знания курса в демонстрируемый результат.

Соберите 3–5 карточек кейсов

Подготовьте 1 пример постановки задачи разработчику

Подготовьте 1 мини-набор UAT: 5–8 тест-кейсов по одному процессу

Подготовьте 1 пример спецификации отчета или интеграции

Продумайте ответы по границам ответственности консультанта

Отрепетируйте рассказ по схеме «контекст → проблема → решение → проверка → результат»

Типовые ошибки кандидатов и как их избежать

Говорить только про интерфейс, не связывая с процессом и учетом

Не уметь сформулировать критерии приемки

Не различать «ошибка данных», «ошибка прав», «дефект» и «изменение методики»

Предлагать доработку, не проверив типовые настройки

Не уметь объяснить влияние на обновления и сопровождение

Итоги

Карьера консультанта 1С строится вокруг способности делать работу управляемой и проверяемой.

Ключевые выводы:

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

Сертификации полезны как подтверждение базы, но сильны только вместе с практикой и портфолио.

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

Лучший способ подготовиться — собрать несколько реальных кейсов и показать, как вы доводили изменения до UAT, внедрения и устойчивой поддержки.

Базовые понятия платформы 1С: объекты, метаданные, режимы работы

Зачем консультанту понимать «внутреннюю кухню» платформы

В предыдущих статьях мы разобрали:

роль консультанта 1С как связующего звена между бизнесом и командой внедрения

экосистему 1С: платформу, варианты развертывания, лицензирование и сервисы

Дальше по курсу мы будем много говорить о требованиях, постановках задач, приемке и тестировании. И здесь консультанту критично понимать базовые термины платформы 1С:

что такое метаданные и зачем они вообще существуют

какие бывают объекты 1С и чем отличаются друг от друга

какие есть режимы работы (где проектируют систему, а где пользователи работают)

Эти знания помогают:

точнее формулировать требования (вы выбираете правильный «контейнер» для данных и действий)

качественнее ставить задачи разработчикам (без расплывчатых формулировок)

быстрее диагностировать пользовательские ошибки (понимать, где искать причину)

Официальная точка входа в технологическую документацию и описание платформы: Сайт 1С:Предприятие 8. Материалы по сопровождению и методикам: 1С:ИТС.

Платформа, конфигурация и информационная база: как связаны

Чтобы не путаться в терминах, зафиксируем три уровня.

Платформа 1С:Предприятие

Платформа — это технологическая «среда», которая предоставляет:

хранение данных

механизм прав и ролей

выполнение алгоритмов

формы, отчеты, печать

интеграционные механизмы

Платформа одна и та же, а прикладные решения могут быть разными.

Конфигурация

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

Примеры типовых конфигураций (как классы решений): бухгалтерия, торговля, зарплата, ERP.

Информационная база

Информационная база (ИБ) — это место, где лежат:

данные конкретной компании (справочники, документы, движения по регистрам)

настройки учета и администрирования

иногда часть настроек интерфейса и прав

Проще всего запомнить так:

платформа = движок

конфигурация = чертеж и правила

информационная база = данные и жизнь конкретного экземпляра

!Визуально показывает различие платформы, конфигурации и информационной базы

Что такое метаданные

Метаданные в 1С — это описание того, какие данные существуют и как система должна с ними работать.

Метаданные отвечают на вопросы:

какие сущности есть в системе (например, контрагенты, номенклатура, заказы)

какие у сущностей реквизиты (ИНН, артикул, сумма)

какие есть процессы (документы и проведения)

какие есть отчеты и печатные формы

какие есть роли и права

Важно не путать:

метаданные = описание структуры и логики

данные = конкретные записи (конкретный контрагент ООО «Ромашка», конкретная реализация №123)

Почему это важно консультанту

Почти любой запрос бизнеса можно «приземлить» на уровень метаданных:

«Нужно хранить новый признак» часто означает добавление реквизита или отдельной сущности

«Нужен процесс согласования» часто затрагивает документы, статусы, права, маршруты

«Нужен отчет» означает выбор источников данных и способа формирования

Чем лучше консультант понимает карту метаданных, тем меньше риск предложить неправильный путь.

Объекты 1С: два смысла слова «объект»

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

Объекты метаданных

Объекты метаданных — это «типы сущностей», которые проектируют в конфигурации.

Примеры:

справочник Номенклатура

документ Поступление товаров

регистр накопления Товары на складах

Объекты данных (экземпляры)

Объекты данных — это конкретные записи, созданные пользователями в информационной базе.

Примеры:

элемент справочника: «Кофе молотый 250 г»

документ: «Поступление товаров №451 от 07.02.2026»

движение: запись в регистре по складу «Основной»

Практическое правило для общения:

если обсуждаем «что в системе вообще есть» — речь про метаданные

если обсуждаем «что ввели пользователи и что посчиталось» — речь про данные

Основные типы объектов метаданных и их роль в задачах бизнеса

Ниже — базовый «алфавит» метаданных, который чаще всего встречается консультанту.

Справочники

Справочник — хранит относительно постоянные сущности.

Типичные примеры:

контрагенты

номенклатура

склады

статьи затрат

Практический критерий:

если объект описывает «кто/что/где» и используется многократно, это кандидат в справочник

Документы

Документ — фиксирует событие хозяйственной деятельности и обычно меняет состояние учета.

Примеры:

поступление

реализация

перемещение

начисление зарплаты

У документа часто есть важные атрибуты:

дата и номер

организация

контрагент

табличная часть (строки товаров/услуг)

Регистры

Регистры — механизм хранения учетных данных для расчетов и отчетов. Для консультанта важно понимать различие типов регистров на смысловом уровне.

#### Регистр накопления Регистр накопления хранит остатки и обороты (например, сколько товара на складе).

Примеры задач:

контроль остатков

расчет себестоимости (в зависимости от конфигурации)

анализ движения товаров

#### Регистр бухгалтерии Регистр бухгалтерии хранит бухгалтерские проводки (дебет/кредит) и поддерживает регламентированный учет.

Примеры задач:

формирование оборотно-сальдовой ведомости

закрытие периода

отчетность

#### Регистр сведений Регистр сведений хранит «факты и настройки», которые не являются движением остатков и не являются проводками.

Примеры:

курсы валют

цены номенклатуры

настройки маршрутов согласования

соответствия для обменов

Практический критерий:

справочник отвечает на «что это такое»

документ отвечает на «что произошло»

регистр отвечает на «какой учетный результат и где это хранить для расчета»

Отчеты и обработки

Отчет — инструмент анализа данных (выводит информацию пользователю).

Обработка — инструмент выполнения действий (массовое заполнение, загрузка, сервисные операции).

Для консультанта важно:

отчет чаще описывают через показатели, разрезы, отборы и форму результата

обработку — через сценарий действий, ограничения, права и контроль ошибок

Перечисления

Перечисление — фиксированный набор значений.

Примеры:

виды операций

статусы (если их немного и они стабильны)

Ограничение здравого смысла:

если бизнес просит «добавлять новые значения самостоятельно» без доработки, перечисление чаще всего не подходит, и лучше рассмотреть справочник

Планы видов характеристик и планы счетов

Эти объекты часто встречаются в типовых конфигурациях.

План счетов — справочник счетов бухгалтерского учета (актуально для регламентированного учета).

План видов характеристик — механизм для гибких характеристик (например, свойства номенклатуры, которые могут расширяться).

Консультанту достаточно понимать назначение:

это инструменты для «гибкости модели» и учетных правил

Как метаданные превращаются в поведение системы

Метаданные не просто «структура таблиц». Они описывают:

структуру данных (реквизиты, табличные части)

связи (подчиненность, ссылки)

интерфейсы (формы)

права доступа (роли)

логику (проведение документов, проверки, расчеты)

На практике важно помнить:

изменения метаданных почти всегда требуют обновления базы и тестирования

доработка может влиять на обновляемость типовой конфигурации

Режимы работы: где настраивают, а где работают пользователи

В повседневной речи консультанта и команды внедрения чаще всего встречаются два режима.

Конфигуратор

Конфигуратор — режим, где:

проектируют и изменяют метаданные

настраивают структуру конфигурации

выполняют технические операции администрирования (в зависимости от прав)

Что консультанту важно вынести:

конфигуратор — это «цех», туда обычно заходят разработчики и администраторы

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

1С:Предприятие

1С:Предприятие — режим, где:

работают пользователи

выполняются бизнес-процессы

вводятся документы

формируются отчеты

Здесь консультант проводит основную работу:

интервью с пользователями

анализ проблем в реальных сценариях

демонстрации и обучение

приемка результата

!Различие между режимом проектирования и режимом работы пользователей

Роли, права и интерфейс: базовая связка для консультанта

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

Роль — набор прав на действия и данные.

Права определяют, что пользователь может делать: видеть, создавать, изменять, проводить, удалять.

Интерфейс (что видно в меню и формах) зависит от настроек и прав.

Практическая связь с требованиями:

если пользователь «не видит документ», это может быть не ошибка данных, а отсутствие прав или ограничение интерфейса

если нужно разделить ответственность (например, один вводит, другой утверждает), это почти всегда задача на роли, права и бизнес-процесс

Как консультанту применять эти понятия в постановках задач

Ниже — типовые шаблоны переводов «языка бизнеса» на «язык 1С» без ухода в программирование.

Пример 1: «Добавьте новый признак в карточку товара»

Корректные уточнения консультанта:

признак нужен для всех товаров или только для части

признак должен участвовать в печатных формах/отчетах/обменах

признак выбирается из фиксированного списка или вводится произвольно

В терминах метаданных это часто означает:

реквизит справочника

или дополнительный реквизит/свойство (если конфигурация поддерживает такой механизм)

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

Корректные уточнения:

лимит по кому: по контрагенту, договору, менеджеру

где хранится лимит: настройка, договор, отдельный регистр

что делать при превышении: запретить проведение или предупреждать

В терминах 1С это обычно затрагивает:

документ

источник лимита (справочник или регистр сведений)

контроль в логике проведения

Пример 3: «Сделайте отчет по продажам по менеджерам и складам»

Корректные уточнения:

показатели: сумма, количество, маржа

разрезы: менеджер, склад, номенклатура, период

отборы: организация, контрагент, группа номенклатуры

В терминах 1С это:

отчет

источники данных (часто документы и/или регистры)

Мини-чек-лист консультанта: как не запутаться в терминах на проекте

«Сущность справочная» или «событие»

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

«Где хранить результат учета»

- регистры для расчетов и итогов

«Где это меняется»

- метаданные меняются в конфигураторе, работа идет в режиме 1С:Предприятие

«Почему пользователь не видит/не может»

- сначала проверяем права и роли, затем уже ошибки данных и логики

Итоги

Понимание базовых понятий платформы 1С — это фундамент для работы консультанта на проектах.

Ключевые выводы:

метаданные описывают структуру и поведение системы, а данные — конкретные записи

основные типы объектов метаданных: справочники, документы, регистры, отчеты, обработки, перечисления

есть два главных режима работы: конфигуратор (проектирование) и 1С:Предприятие (работа пользователей)

Дальше по курсу эти понятия понадобятся для практики: мы будем учиться формулировать требования так, чтобы они однозначно переводились в изменения метаданных, настройки и проверяемые критерии приемки.

Типовые конфигурации: Бухгалтерия, ЗУП, Управление торговлей, ERP

Зачем консультанту разбираться в типовых конфигурациях

В предыдущих статьях мы закрепили:

роль консультанта 1С и его ответственность за перевод потребностей бизнеса в реализуемые требования

устройство экосистемы 1С (платформа, варианты развертывания, лицензии, сервисы)

базовые понятия платформы (метаданные, объекты, режимы работы)

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

Для консультанта это критично по трём причинам:

вы быстрее понимаете язык пользователей (бухгалтер говорит “закрытие месяца”, кадровик — “табель”, продажник — “резервирование”)

вы реалистично выбираете способ реализации (типовой функционал, настройка или доработка)

вы корректно определяете границы: где заканчивается “настройка в рамках конфигурации” и начинается “изменение модели/архитектуры”

Официальные описания решений можно смотреть на сайте 1С:

1С:Бухгалтерия

1С:Зарплата и управление персоналом

1С:Управление торговлей

1С:ERP Управление предприятием

Что значит “типовая конфигурация” на практике

Типовая конфигурация — это готовая прикладная модель (метаданные, процессы, отчеты, права), которую 1С развивает и обновляет.

Для консультанта слово типовая означает:

есть “как задумано” (методика, регламенты, ограничения)

есть регулярные обновления (в том числе под законодательство)

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

В проектах почти всегда встречается комбинация:

типовой функционал

настройки

минимально необходимая кастомизация (доработки, расширения, печатные формы, интеграции)

> Практическое правило консультанта: сначала ищем способ закрыть потребность типовым механизмом или настройкой, и только затем рассматриваем доработку.

Четыре типовых решения и их “зоны”

!Схема показывает, какие бизнес-контуры чаще всего покрывает каждая конфигурация

1С:Бухгалтерия

1С:Бухгалтерия — решение для регламентированного учета (бухгалтерский и налоговый учет) и подготовки отчетности.

Ключевые пользователи:

бухгалтерия

финансовая служба (в части регламентированных данных)

Типовые задачи, с которыми к консультанту приходят в “Бухгалтерии”:

отражение первичных документов (поступления, реализации, услуги)

учет НДС, сверка счетов-фактур

закрытие месяца (косвенные расходы, амортизация, финансовый результат)

регламентированная отчетность

Что важно понимать консультанту на уровне модели (без программирования):

“истина” в регламентированном учете — это проводки и регистры учета, а не просто “печатные формы документов”

любое изменение в первичке часто влияет на закрытие месяца и отчетность

1С:Зарплата и управление персоналом (ЗУП)

ЗУП — решение для кадрового учета, расчетов зарплаты, налогов и взносов, кадровых документов и отчетности по персоналу.

Ключевые пользователи:

кадровая служба

расчетчики зарплаты

бухгалтерия (в части начислений и отчетности)

Типовые задачи в ЗУП:

приемы, переводы, увольнения

кадровые события (отпуска, больничные, командировки)

табель и учет рабочего времени

начисления, удержания, налоги и взносы

выгрузки/синхронизация начислений в учетную систему (часто в “Бухгалтерию”)

Что важно консультанту:

в ЗУП много “правил расчета”, и уточнение методики важнее “красивой формы документа”

ошибки часто рождаются на стыке: графики работы, виды времени, базы начислений, ограничения законодательства

1С:Управление торговлей (УТ)

УТ — решение для оперативного (управленческого) контура продаж, закупок, склада, ценообразования и взаиморасчетов.

Ключевые пользователи:

отдел продаж

закупки

склад

коммерческая служба

Типовые задачи в УТ:

заказы клиентов и заказы поставщикам

резервирование и обеспечение потребностей

складские операции (приемка, отгрузка, перемещения)

цены, скидки, акции

взаиморасчеты с клиентами (в управленческой части)

Что важно консультанту:

одна и та же “отгрузка” может существовать в нескольких представлениях: управленческом (УТ) и регламентированном (Бухгалтерия)

важно заранее договориться, где “ведем склад” и где “ведем взаиморасчеты”, чтобы не получить двойной ввод и расхождения

1С:ERP Управление предприятием

1С:ERP — комплексное решение для крупных и средних компаний, покрывающее несколько контуров: продажи, закупки, склад, производство, планирование, финансы, иногда МСФО/управленческая отчетность (в зависимости от внедрения).

Ключевые пользователи:

почти все ключевые подразделения (от снабжения до производства)

финансовая дирекция

планово-экономический блок

Типовые задачи в ERP:

сквозные процессы от планирования до исполнения

производство: спецификации, маршруты, потребности в материалах, выпуск

сложные цепочки обеспечения и планирования

управленческий и регламентированный контуры (в выбранной модели учета)

Что важно консультанту:

ERP почти всегда требует проектирования “как будет” (To-Be) и согласования методики между подразделениями

стоимость ошибки выше: изменение справочников/процессов может затронуть цепочку от закупки до финансового результата

Быстрое сравнение: когда какую конфигурацию ждать на проекте

| Конфигурация | Основной контур | Типичные подразделения | Сильные стороны | Типичные “болезни проекта” | |---|---|---|---|---| | 1С:Бухгалтерия | Регламентированный учет | Бухгалтерия, финансы | Законодательство, отчетность, закрытие периода | “Хотим управленческий учет прямо в Бухгалтерии” без методики и разграничения | | 1С:ЗУП | Кадры и расчет зарплаты | HR, расчетчики, бухгалтерия | Сложные расчеты и регламенты | Недоописанные графики, виды начислений, права и ответственность за данные | | 1С:УТ | Оперативный контур торговли | Продажи, закупки, склад | Заказы, склад, цены, обеспечение | Двойной ввод с бухгалтерией, неоговоренная модель остатков/резервов | | 1С:ERP | Сквозной контур предприятия | Большинство служб | Интеграция процессов, планирование, производство | Слишком широкий старт, отсутствие единой методики, сопротивление изменениям |

Типовые сценарии внедрения и взаимодействия конфигураций

Сценарий “УТ + Бухгалтерия”

Частая связка для торговых компаний:

в УТ ведут продажи, склад, закупки, цены

в Бухгалтерии ведут регламентированный учет и отчетность

Ключевая зона ответственности консультанта:

договориться, какие данные являются первичными и где они возникают

описать правила синхронизации: справочники (контрагенты, номенклатура), документы (реализация, поступление), статусы

Сценарий “ЗУП + Бухгалтерия”

Частая связка практически для любого бизнеса:

в ЗУП ведут кадры и начисления

в Бухгалтерию передают результаты начислений для отражения в регламентированном учете

Ключевая зона ответственности консультанта:

согласовать, кто и где отвечает за справочники сотрудников, подразделений, способов отражения

обеспечить воспроизводимость расчета (чтобы “вчера считалось так же, как сегодня” при одинаковых исходных данных)

Сценарий “ERP как ядро”

ERP может быть основным ядром, а некоторые специализированные контуры живут рядом:

ERP + ЗУП (зарплата отдельно)

ERP + отдельные витрины/BI

ERP + внешние WMS/CRM (если есть)

Ключевая зона ответственности консультанта:

зафиксировать границы процессов и точку “истины” по каждому справочнику и документу

заранее описать регламенты обменов и ответственность за ошибки (кто реагирует, в какие сроки, как диагностируем)

Как консультанту выбирать подход: типовой функционал, настройка или доработка

Из предыдущей статьи про метаданные полезно удерживать мысль: запрос бизнеса почти всегда “ложится” в один из классов изменений.

Нужно хранить новый признак:

- сначала проверяем типовые механизмы (дополнительные реквизиты/свойства, настройки) - если не хватает, формулируем задачу как изменение структуры данных (метаданные)

Нужно изменить процесс согласования/ответственности:

- проверяем роли, права, статусы, маршруты - фиксируем критерии приемки: кто видит, кто может провести, кто может отменить

Нужен отчет:

- описываем показатели, разрезы, отборы, периодичность - уточняем источник данных и “единую версию правды” (из какой системы строим)

Ключевой результат для консультанта — не “угадать решение”, а:

задать правильные уточняющие вопросы

предложить вариант, минимально конфликтующий с типовой логикой

зафиксировать проверяемые критерии приемки

Практический чек-лист консультанта перед стартом работ в конкретной конфигурации

Вопросы по бизнесу и методике

какие подразделения работают в системе и какие у них цели

какие документы являются юридически значимыми и где они формируются

что является “учетной истиной”: остатки, взаиморасчеты, себестоимость, зарплата

Вопросы по контуру и границам

что ведем в этой конфигурации, а что — в соседней

где справочник ведется “мастером”: контрагенты, номенклатура, сотрудники

как избегаем двойного ввода и расхождений

Вопросы по эксплуатационным ограничениям

число одновременных пользователей и пиковые нагрузки (закрытие месяца, массовая отгрузка, расчет зарплаты)

варианты работы (тонкий клиент/веб), доступы филиалов

требования к обменам и регламентным заданиям

Итоги

Типовые конфигурации — это “язык” большинства проектов 1С.

Ключевые выводы для консультанта:

1С:Бухгалтерия — про регламентированный учет и закрытие периода

ЗУП — про кадры и расчеты зарплаты с высокой методической сложностью

УТ — про оперативный контур торговли: заказы, склад, цены

ERP — про сквозные процессы и интеграцию контуров, где особенно важны методика и управление изменениями

Дальше по курсу логично переходить от “что за системы” к “как с ними работать”: как проводить интервью, описывать процессы и формулировать требования так, чтобы разработка и приемка были предсказуемыми.

Предпроектное обследование: интервью, сбор данных, фиксация процессов AS-IS

Зачем консультанту нужно предпроектное обследование

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

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

выбирать типовую функциональность или доработку

формулировать требования без двусмысленности

оценивать трудозатраты и риски

готовить постановки задач и критерии приемки

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

Термины, которые будут использоваться

Чтобы не возникало неопределенности, зафиксируем базовые термины.

Предпроектное обследование — набор активностей по сбору и структурированию информации перед внедрением или развитием системы.

AS-IS (как есть) — описание текущего состояния процессов, данных, ролей и систем.

TO-BE (как будет) — целевое состояние после внедрения.

Стейкхолдер — участник, который влияет на решение или испытывает на себе последствия изменений.

Процесс — повторяемая последовательность действий с понятным результатом (например, «закупка материалов», «отгрузка клиенту», «расчет зарплаты»).

Для общего понимания профессиональных подходов к выявлению требований полезно ориентироваться на материалы по бизнес-анализу (не как «обязательный стандарт», а как источник практик): BABOK Guide.

Цели обследования и границы ответственности консультанта

Что является результатом обследования

Результат обследования — это не «толстый отчет ради отчета», а набор согласованных материалов, которые отвечают на вопросы:

кто и что делает в текущих процессах

какие документы и данные используются

где возникают ошибки, потери времени и риски

какие системы участвуют и как они связаны

какие ограничения нужно учитывать при реализации в 1С

Что консультант должен сделать, а что — эскалировать

Консультант 1С обычно отвечает за:

проведение интервью и сбор фактуры

фиксацию процессов AS-IS в понятной форме

выявление проблем, разрывов, дублирования

первичную «приземленность» на 1С (какие справочники, документы, регистры, роли потенциально затрагиваются)

Консультант не должен в одиночку «утвердить методику учета» за заказчика. Если есть спорные вопросы (например, правила распределения затрат, модель себестоимости, ответственность подразделений), задача консультанта — зафиксировать варианты и последствия и передать на решение уполномоченным лицам.

План обследования: из чего состоит работа

Ниже — практичная структура обследования, которая подходит для большинства проектов 1С (внедрение, развитие, замена системы).

Определение рамок

- Цель проекта и ожидаемые эффекты. - Перечень контуров (продажи, закупки, склад, производство, регучет, зарплата). - Список подразделений и ролей.

Подготовка

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

Интервью и сбор данных

- Индивидуальные интервью. - Воркшопы (групповые сессии). - Анализ документов и регламентов. - Просмотр системы и «прогон» реальных сценариев.

Фиксация AS-IS

- Схемы процессов. - Матрица ролей. - Реестр документов и данных. - Карта систем и интеграций. - Список проблем и причин.

Сверка и согласование

- Проверка корректности у ключевых пользователей. - Фиксация допущений и открытых вопросов. - Подтверждение границ следующего шага (TO-BE, требования, постановки).

!Воронка обследования: от источников информации к артефактам AS-IS и далее к требованиям

Интервью: как получать факты, а не мнения

Кого интервьюировать

Ошибочная логика: интервьюировать только «инициатора» или только бухгалтерию.

Практичная логика: интервьюировать по цепочке процесса и ответственности.

Исполнители (кто делает руками).

Контролеры/согласующие (кто проверяет и утверждает).

Владельцы процесса (кто отвечает за результат и правила).

ИТ (кто обслуживает систему, интеграции, права, инфраструктуру).

Подготовка к интервью

Подготовка часто экономит больше времени, чем длительное «свободное обсуждение».

Сформулируйте цель интервью одним предложением.

- Пример: «Понять, как происходит отгрузка и какие данные нужны для закрывающих документов».

Подготовьте структуру вопросов.

- Про шаги процесса. - Про документы и данные. - Про исключения. - Про проблемы и метрики.

Заранее запросите примеры.

- 2–3 реальных документа. - Скриншоты или выгрузки отчетов. - Примеры «сложных случаев».

Структура вопросов, которая хорошо работает

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

| Тип вопроса | Задача | Пример | |---|---|---| | Про шаги | Восстановить последовательность | «Что происходит после того, как клиент прислал заказ?» | | Про роли | Понять ответственность | «Кто имеет право менять цену и кто это согласует?» | | Про данные | Выявить обязательные реквизиты | «Какие поля должны быть заполнены, чтобы документ приняли?» | | Про исключения | Найти нестандартные случаи | «Что делаете, если товара нет на складе?» | | Про контроль | Понять проверки и KPI | «Как вы понимаете, что отгрузка прошла без ошибок?» | | Про проблемы | Зафиксировать боли | «Где чаще всего теряется время и почему?» |

Техника фиксации на интервью

Цель фиксации — чтобы через неделю можно было восстановить смысл без «а что вы тогда имели в виду».

Рекомендуемый минимум:

цель интервью и контекст

участники и их роли

краткое описание процесса шагами

перечень документов и данных (что вводят, откуда берут)

проблемы и причины (как их видит пользователь)

открытые вопросы и кому адресованы

Практический прием: заканчивайте интервью коротким резюме и подтверждением.

«Я правильно понял, что…»

«Самое частое исключение — это…»

«Мы договорились, что вы пришлете примеры…»

Сбор данных: что запрашивать, кроме разговоров

Интервью дают контекст, но факты часто живут в документах, настройках и данных системы.

Документы и регламенты

Запрашивайте то, что реально используют.

регламенты и инструкции

шаблоны договоров, УПД, актов, заявок

учетная политика и правила (если речь о регучете)

схемы согласований (если существуют)

Данные и справочники

Для 1С-проектов критично заранее увидеть качество и структуру данных.

списки контрагентов, номенклатуры, договоров

классификаторы, единицы измерения, ставки НДС

примеры «проблемных» записей (дубликаты, пустые ИНН, разные наименования)

Текущая ИТ-карта и интеграции

Даже если проект «только про 1С», почти всегда есть окружение.

банк-клиент или интеграция с банком

обмены с маркетплейсами, CRM, сайтом

ЭДО и операторы

внешние WMS/TMS/BI (если есть)

Уместный формат фиксации — простая таблица.

| Система | Что делает | Какие данные отдает/получает | Как часто | Ответственный | |---|---|---|---|---| | CRM | Лиды, сделки | Контакты, заказы | Онлайн/пакетно | Отдел продаж/ИТ | | Банк | Платежи | Платежные поручения, выписки | Ежедневно | Казначейство | | ЭДО | ЮЗДО | УПД, акты, статусы | По событию | Бухгалтерия |

Фиксация процессов AS-IS: как описывать так, чтобы это было полезно

Какой уровень детализации выбирать

Главная ошибка — уйти в микрошаги, которые никому не нужны.

Практичное правило уровня детализации:

шаг процесса должен быть проверяемым действием

шаг должен иметь понятного исполнителя

шаг должен заканчиваться артефактом (документом, записью, статусом) или решением

Пример «слишком мелко»:

«нажали кнопку, выбрали вкладку, нажали еще кнопку»

Пример «нормально для обследования»:

«Менеджер регистрирует заказ клиента и фиксирует дату отгрузки»

Простой формат схемы процесса

Для обследования часто достаточно кросс-функциональной схемы (swimlane), где видно:

роли по горизонтали или вертикали

шаги процесса

точки согласования

исключения

!Пример фиксации AS-IS в виде swimlane-схемы по ролям

Что обязательно фиксировать в AS-IS, кроме «основного сценария»

Если описать только «как должно быть», вы не увидите реальные причины проблем.

Фиксируйте:

входы процесса (откуда появляется задача)

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

документы и данные на каждом шаге

контрольные точки и согласования

исключения и обходные пути

ручные операции вне системы (Excel, мессенджеры)

места, где люди «дублируют ввод»

Матрица ролей для процесса

Матрица помогает быстро увидеть разрывы ответственности.

| Роль | Создает документы | Согласует | Проводит | Исправляет ошибки | Отвечает за правило | |---|---|---|---|---|---| | Менеджер | Заказ клиента | Коммерческие условия | Иногда | Часто | Частично | | Склад | Расходные ордера | Нет | Да | Иногда | Нет | | Бухгалтерия | СФ/УПД | Да | Да | Да | Да |

Как «приземлять» AS-IS на 1С без программирования

На обследовании консультант уже начинает переводить бизнес-язык в термины 1С (из статьи про метаданные): справочники, документы, регистры, отчеты, роли.

Пример перевода наблюдений в объекты 1С

Наблюдение из интервью:

«Мы ведем список складов, но иногда отгружаем с “виртуального склада”, чтобы не блокировать продажи».

Как это звучит в терминах 1С:

справочник Склады и правила его использования

необходимость контроля остатков (регистры накопления)

бизнес-правило: запрещать/разрешать отгрузку без наличия

возможные настройки резервирования (актуально для УТ/ERP)

Важно: на обследовании вы не обязаны «спроектировать решение», но должны зафиксировать, какие механизмы 1С точно затрагиваются, чтобы дальше корректно оценивать изменения.

Привязка к типовым конфигурациям

На практике одинаковый процесс будет реализован по-разному в разных конфигурациях.

В 1С:Бухгалтерии акцент на первичку, проводки и закрытие периода.

В УТ акцент на заказы, резервы, складские операции.

В ERP нужно учитывать сквозные цепочки (обеспечение, планирование, производство).

В ЗУП процессы тесно связаны с правилами расчета, видами времени и кадровыми событиями.

Поэтому в AS-IS полезно фиксировать не только «шаги», но и «зачем шаг существует».

если шаг существует ради регламентированного учета, это один контур

если ради управления продажами и складом, это другой контур

Контроль качества обследования: как понять, что AS-IS “достаточно хорош”

Хорошее AS-IS — это такое, которое позволяет перейти к требованиям без догадок.

Проверочные вопросы к вашим материалам:

Понятно ли, где начинается и где заканчивается процесс?

Названы ли роли, которые выполняют шаги?

Для каждого ключевого шага понятно, какие документы и данные используются?

Зафиксированы ли исключения (топ-5 по частоте или по риску)?

Видны ли проблемные места и их причины, а не только «нам неудобно»?

Есть ли список открытых вопросов и ответственных?

Если на часть вопросов вы отвечаете «нет», это не катастрофа, но сигнал: рано обещать сроки и давать финальный дизайн.

Типичные ошибки на предпроектном обследовании

Смешивать AS-IS и TO-BE в одном описании без явной маркировки.

Фиксировать только «как по регламенту», игнорируя реальную практику.

Описывать процесс без данных: кто делает есть, что вводит — нет.

Не фиксировать исключения («у нас редко бывает») — а потом они становятся 80% обращений в поддержку.

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

Что должно получиться на выходе

Набор артефактов зависит от масштаба проекта, но практичный минимум обычно такой:

схемы процессов AS-IS по ключевым контурам

реестр документов и данных (что создается, где хранится, кто владелец)

матрица ролей и ответственности

карта систем и интеграций

список проблем, причин и «точек боли»

список открытых вопросов, допущений и ограничений

Эти материалы станут основой для следующего этапа: формулирования требований, проектирования TO-BE, выбора типового функционала и подготовки постановок задач на изменения в 1С.

Полезные официальные входные точки по 1С для сверки терминов и возможностей: 1С:Предприятие 8 и 1С:ИТС.

Моделирование TO-BE: сценарии, регламенты, матрица ролей и прав

Зачем консультанту нужно TO-BE после AS-IS

В прошлой статье мы разобрали предпроектное обследование и фиксацию процессов AS-IS (как есть): интервью, сбор фактов, схемы процессов, проблемы, карта систем. Следующий шаг на проектах 1С почти всегда один и тот же: описать TO-BE (как будет) так, чтобы команда могла:

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

оценить объем работ и риски

сделать постановки задач разработчикам без двусмысленности

подготовить тестирование и приемку

внедрить изменения через обучение и регламенты

TO-BE для консультанта 1С — это не «фантазия про будущее», а согласованная модель процессов, ролей и правил, которую можно реализовать в конкретной конфигурации и инфраструктуре.

Что такое TO-BE в проектах 1С

TO-BE — это описание целевого процесса и правил работы, включая:

сценарии работы пользователей (кто что делает и в какой последовательности)

регламенты и бизнес-правила (как именно надо делать, какие проверки обязательны)

данные и документы (что вводим, что получаем на выходе)

роли и права (кто что видит и что имеет право делать)

интеграции и границы систем (где «точка истины» по справочнику и документу)

Важно: TO-BE описывается на уровне, достаточном для постановок задач и критериев приемки, но без ухода в программирование.

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

Принципы хорошего TO-BE

Принцип «одна версия правды»

Для каждого объекта учета договоритесь и зафиксируйте:

где ведется справочник и кто владелец

где создается документ и кто отвечает за его корректность

какая система является источником данных для отчетности

Это особенно критично в связках УТ + Бухгалтерия, ЗУП + Бухгалтерия, ERP + внешние системы.

Принцип «минимум кастомизации без потери смысла»

Как и в статье про типовые конфигурации, порядок выбора решения обычно такой:

типовой функционал

настройки

расширения и доработки только там, где без них нельзя

Материалы по возможностям платформы и прикладных решений удобно сверять по официальным ресурсам: 1С:Предприятие 8 и 1С:ИТС.

Принцип «сценарий важнее формы»

Пользователи часто формулируют запрос как «добавьте поле» или «переделайте форму». В TO-BE фокус должен быть на воспроизводимом сценарии:

что является входом

что делаем шаг за шагом

какие проверки обязательны

что является результатом

как проверим, что работает правильно

Принцип «разделение обязанностей»

Права и роли должны поддерживать контроль:

кто вводит

кто утверждает

кто проводит

кто исправляет ошибки

Иначе TO-BE превращается в «все могут всё», что почти всегда приводит к инцидентам и спорным зонам ответственности.

Сценарии TO-BE: как описывать работу пользователей

Что такое сценарий

Сценарий — это описанный путь пользователя от цели к результату.

Типы сценариев, которые полезны консультанту:

основной сценарий (как должно происходить обычно)

исключения (товара нет, не согласовали скидку, ошибка в реквизитах)

альтернативы (частичная отгрузка, возврат, перенос даты)

Шаблон сценария, который удобно использовать в проектах 1С

Ниже — практичная структура, достаточная для постановок задач и тестов.

| Поле сценария | Что фиксируем | Пример формулировки | |---|---|---| | Название | Коротко и по делу | «Отгрузка по заказу клиента с резервом» | | Цель | Зачем сценарий нужен бизнесу | «Сформировать отгрузку без продаж “в минус”» | | Роли | Участники и ответственность | Менеджер, Склад, Бухгалтер | | Предусловия | Что должно быть до старта | Заказ согласован, цены утверждены | | Шаги | Последовательность действий | Создать документ, проверить остатки, провести | | Проверки | Контроли и ограничения | Нельзя провести без резерва | | Результат | Что считаем завершением | Создана реализация, распечатаны документы | | Данные | Обязательные реквизиты | Организация, склад, договор, ставка НДС | | Исключения | Частые нестандартные случаи | Частичная отгрузка, замена номенклатуры | | Критерии приемки | Как тестируем | Сценарий проходит на тестовых данных |

Как «приземлять» сценарий на объекты 1С

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

Пример логики соответствия:

«храним постоянную сущность» → справочник

«фиксируем событие и меняем состояние учета» → документ

«получаем остатки, обороты, правила расчета» → регистр

«анализируем данные» → отчет

«делаем массовое действие или загрузку» → обработка

!Помогает переводить описание процесса на язык 1С без программирования

Регламенты TO-BE: что фиксировать, чтобы процесс был управляемым

Что такое регламент

Регламент — это договоренность о правилах работы: кто, что и когда обязан делать, какие статусы использовать, какие документы обязательны, какие сроки.

В 1С-проектах регламенты особенно важны там, где:

есть согласования (скидки, лимиты, платежи)

есть контроль качества данных (обязательные реквизиты, классификаторы)

есть регламентные операции (закрытие месяца, расчет зарплаты)

есть обмены и интеграции (окна обмена, ответственность за ошибки)

Структура регламента, полезная для внедрения

| Раздел | Что описать | Зачем это нужно | |---|---|---| | Назначение | Цель и область применения | Убирает споры «зачем мы это делаем» | | Роли и ответственность | Кто выполняет, кто утверждает | Поддерживает разделение обязанностей | | Входы/выходы | С чего начинается и чем заканчивается | Делает процесс измеримым | | Правила и проверки | Ограничения, обязательные поля | Защищает качество учета | | Сроки | SLA, дедлайны, окна | Помогает эксплуатации | | Исключения | Что делаем в нестандартных случаях | Снижает хаос в поддержке | | Связанные документы | Шаблоны, инструкции, формы | Ускоряет обучение |

Как формулировать бизнес-правила, чтобы их можно было реализовать и проверить

Формулировки вида «сделайте удобно» или «пусть система контролирует» не работают. Хорошее бизнес-правило содержит три части:

Условие срабатывания

Действие системы

Результат для пользователя

Примеры корректных формулировок:

«При проведении реализации система проверяет наличие резерва; при отсутствии резерва проведение запрещено с сообщением, в котором указан склад и номенклатура».

«Скидка более 10% требует согласования руководителем отдела продаж; до согласования заказ имеет статус “На согласовании” и не может быть отгружен».

Матрица ролей и прав: как связать процесс, ответственность и доступы

Базовые термины про доступы в 1С

Без углубления в администрирование зафиксируем практический минимум:

роль — набор прав на действия и данные

права — что пользователь может делать: читать, создавать, изменять, проводить, удалять

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

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

Зачем матрица ролей и прав нужна именно консультанту

Матрица помогает:

убрать «серые зоны» ответственности

предотвратить ошибки и злоупотребления

снизить нагрузку на поддержку (меньше ситуаций «не вижу документ»)

подготовить тестирование доступов до запуска

Два уровня матрицы

#### Матрица ответственности по процессу Это про кто что делает.

| Шаг процесса | Роль | Действие | Результат | |---|---|---|---| | Регистрация заказа | Менеджер | Создает заказ | Заказ в статусе «Черновик» | | Согласование скидки | Руководитель продаж | Утверждает скидку | Статус «Согласовано» | | Комплектация | Кладовщик | Формирует отбор/комплектацию | Товар подготовлен | | Отгрузка | Кладовщик | Проводит отгрузку | Списание со склада | | Закрывающие | Бухгалтер | Формирует УПД/СФ | Документы для клиента |

#### Матрица прав в системе Это про что можно в 1С.

Рекомендуемый минимальный набор колонок:

объект (документ/справочник/отчет)

действия (просмотр, создание, изменение, проведение, удаление)

ограничения (по организации, складу, подразделению)

Пример фрагмента:

| Объект 1С | Менеджер | Кладовщик | Бухгалтер | |---|---|---|---| | Заказ клиента | Создание, изменение до согласования | Просмотр | Просмотр | | Реализация товаров | Создание без проведения | Проведение | Проведение, печать | | Контрагенты | Создание по регламенту | Просмотр | Изменение реквизитов по регламенту | | Отчет «Валовая прибыль» | Просмотр с ограничениями | Нет доступа | Просмотр |

Типовые ошибки в правах, которые ломают TO-BE

«Дадим всем полные права на старте, потом уберем».

Смешивание ролей ввода и контроля в одном человеке без фиксации ответственности.

Нет правил, кто исправляет ошибки и как возвращаем документ на доработку.

Права не привязаны к регламенту, из-за чего процесс «обходят» технически.

Как фиксировать TO-BE так, чтобы это превращалось в задачи и приемку

Связка артефактов

Практичная цепочка выглядит так:

схема процесса TO-BE

сценарии (основной и ключевые исключения)

регламент (ответственность и правила)

матрица ролей и прав

бэклог изменений (настройки, доработки, отчеты, интеграции)

критерии приемки и тестовые сценарии

Что должно быть в критериях приемки

Критерии приемки — это проверяемые условия, по которым бизнес подтверждает результат.

Хорошие критерии:

привязаны к сценарию

проверяются на конкретных данных

описывают ожидаемый результат

Пример:

«Пользователь с ролью “Менеджер” может создать заказ, но не может провести реализацию».

«При попытке провести реализацию без резерва система запрещает проведение и показывает сообщение с перечнем строк».

Мини-чек-лист качества TO-BE для консультанта

Есть ли определенные входы и выходы процесса.

Зафиксированы ли статусы и контрольные точки.

Есть ли описание топовых исключений.

Понятно ли, где и кем создаются ключевые данные.

Есть ли матрица ответственности и матрица прав.

Сформулированы ли критерии приемки по ключевым сценариям.

Итоги

Моделирование TO-BE — центральный этап между обследованием AS-IS и реализацией изменений в 1С.

Ключевые выводы:

TO-BE лучше всего фиксировать через сценарии, регламенты и матрицу ролей и прав.

Сценарии переводят «хочу» в последовательность действий, данные, проверки и критерии приемки.

Регламенты удерживают процесс в управляемом виде: ответственность, сроки, исключения.

Матрица ролей и прав связывает процесс с возможностями пользователей в 1С и защищает учет.

Дальше по курсу логично перейти к тому, как из TO-BE делать качественные требования и постановки задач на настройку и доработку в 1С, чтобы разработка и приемка были предсказуемыми.

Требования и документация: ТЗ, ЧТЗ, спецификации, user stories

Зачем консультанту 1С уметь работать с требованиями

В предыдущих темах курса мы прошли путь:

разобрали роль консультанта 1С и его зоны ответственности

поняли, в какой экосистеме живут решения 1С

закрепили базовые понятия платформы и типовых конфигураций

научились фиксировать AS-IS и моделировать TO-BE через сценарии, регламенты, матрицу ролей и прав

Следующий практический шаг — превратить TO-BE в управляемый набор требований и документов, по которым команда может:

оценить объем работ и договориться о границах

реализовать изменения (настройки, доработки, интеграции)

проверить результат на тестировании

принять результат у исполнителя и запустить в эксплуатацию

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

Полезные внешние ориентиры по практикам требований:

BABOK Guide (IIBA)

The Scrum Guide

Базовые понятия: что именно мы документируем

Чтобы не путаться в терминах, зафиксируем минимум.

Требование — проверяемое утверждение о том, что система должна делать или какими свойствами обладать.

Функциональное требование — что система делает (например, “запрещать проведение реализации при отсутствии резерва”).

Нефункциональное требование — как система должна работать (производительность, доступность, аудит, безопасность).

Критерии приемки — условия, по которым заказчик подтверждает, что требование выполнено.

Артефакт — любой согласованный результат работы (ТЗ, ЧТЗ, спецификация, user story, протокол согласования, матрица прав).

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

Где заканчивается TO-BE и начинаются требования

TO-BE описывает целевой процесс: роли, шаги, правила, исключения. Требования — это “разбор TO-BE на реализуемые куски”, пригодные для:

оценки

разработки/настройки

тестирования

приемки

!Визуально показывает, как материалы обследования превращаются в требования, затем в задачи, тесты и приемку

Форматы требований: когда что использовать

На проектах 1С одновременно встречаются разные форматы документации. Важно не “выбрать единственно правильный”, а подобрать набор, достаточный для вашего контекста: контракт, внутренний продукт, сопровождение, agile-команда.

Короткая карта форматов

| Формат | Что это | Когда уместно | Сильная сторона | Риск/слабое место | |---|---|---|---|---| | ТЗ (техническое задание) | Формальный документ на работы и результат | Контрактные проекты, большие внедрения, фиксированный объем | Юридическая и управленческая опора | Может стать “романом”, который никто не читает | | ЧТЗ (частное ТЗ) | ТЗ на часть системы/функцию | Поэтапная реализация, отдельные подсистемы, изменения в сопровождении | Быстро согласуется, проще управлять изменениями | Легко потерять целостность, если нет общей картины | | Спецификация | Детальное описание конкретной доработки/отчета/интеграции | Интеграции, сложные отчеты, права, печать, обмены | Высокая однозначность для разработки и тестов | Требует дисциплины поддержания актуальности | | User story | Требование в форме ценности для пользователя | Agile/итеративная разработка, продуктовый подход, бэклог | Удерживает фокус на ценности и приемке | Без критериев приемки превращается в “хотелку” |

Далее разберем каждый формат с точки зрения консультанта 1С: что обязательно фиксировать, чтобы требование было реализуемым и проверяемым.

ТЗ: зачем, как устроено, что в нем критично

ТЗ чаще всего используют как “главный договор” по результату: что делаем, где границы, как принимаем.

Что консультанту важно понимать про ТЗ

ТЗ должно быть проверяемым: любая существенная формулировка должна иметь способ проверки.

ТЗ должно фиксировать границы: что точно не делаем в рамках текущего этапа.

ТЗ должно связывать функционал с процессами TO-BE: иначе получится набор несвязанных хотелок.

Практичная структура ТЗ для 1С-проекта

Ниже не “единственный стандарт”, а рабочий минимум, который помогает не провалить приемку.

Введение и цели

Область автоматизации и границы

Описание TO-BE на верхнем уровне

Требования

Интеграции и обмены

Права и роли

Нефункциональные требования

Порядок тестирования и приемки

Требования к обучению и документации пользователя

Порядок управления изменениями

Если проект внедрения большой, полезно добавить “словарь терминов”, чтобы одинаково понимать сущности (“заказ”, “резерв”, “партия”, “себестоимость”).

Типичные ошибки ТЗ в 1С

“Сделать удобно” вместо проверяемых требований.

Нет связки с ролями и правами: все действия описаны, но неясно, кто может выполнять.

Не описаны исключения: в реальности они становятся основной нагрузкой на поддержку.

Отсутствуют критерии приемки: начинается спор “оно работает, но не так”.

ЧТЗ: как дробить объем и не потерять управляемость

ЧТЗ — это ТЗ на отдельный контур, функцию или этап. По сути, это способ:

быстрее согласовать небольшой объем

точнее оценить трудозатраты

изолировать изменения и риски

Когда ЧТЗ особенно полезно

вы внедряете по очереди контуры (сначала продажи и склад, затем регучет)

у вас сопровождение и поток задач, но часть требует формального согласования

есть несколько независимых интеграций, и их удобно оформлять отдельными документами

Что обязательно должно связывать ЧТЗ с общей картиной

Чтобы ЧТЗ не превратилось в набор “разрозненных патчей”, фиксируйте:

ссылку на исходный процесс TO-BE и сценарии

зависимости от других подсистем и обменов

изменения в ролях/правах

влияние на отчетность и закрытие периода (если затрагивается учет)

Практический прием: введите реестр требований, где у каждого требования есть идентификатор и ссылка на ЧТЗ/задачу/тест.

Спецификации: когда без детализации нельзя

Спецификация — это “точный чертеж” конкретной доработки. Чаще всего спецификации нужны, когда велик риск неоднозначной реализации:

интеграции и обмены

сложные отчеты и показатели

алгоритмы контролей

печатные формы с юридически значимыми реквизитами

сложные права доступа и ограничения

Спецификация на интеграцию: что фиксировать

Минимальный состав, который обычно спасает проект от хаоса:

Назначение интеграции

Системы-участники и “точка истины” по справочникам и документам

Состав объектов

Формат и структура данных

События и расписание (онлайн, пакетно, регламентно)

Правила сопоставления (ключи, идентификаторы, поиск дублей)

Обработка ошибок

Логи и мониторинг

Критерии приемки

Спецификация на отчет: что фиксировать

показатели (что считаем)

разрезы (по чему группируем)

отборы (фильтры)

источники данных (какие документы/регистры являются основанием)

правила расчета (особенно для маржи, себестоимости, скидок)

требования к скорости формирования (если отчет большой)

Спецификация на роли и права: что фиксировать

Связка из прошлой статьи про TO-BE остается центральной: процесс → ответственность → права.

Фиксируйте:

роли и их назначение

объекты (документы, справочники, отчеты)

действия (просмотр, создание, изменение, проведение, удаление)

ограничения (по организации, складу, подразделению)

сценарии проверки доступов (как тестируем, что “не пролезает”)

User stories: как писать требования в agile-формате, чтобы 1С-команда могла сделать и принять

User story — это короткая формулировка ценности:

Как роль

я хочу действие

чтобы получить ценность

Пример для 1С:

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

Почему для 1С user story недостаточно без уточнений

В 1С почти всегда есть:

роли и права

исключения

учетные последствия

границы между системами

Поэтому для консультанта “готовая” user story обычно состоит из трех частей:

сама story

критерии приемки

уточнения данных/ограничений

Критерии приемки для user story

Чтобы история была проверяемой, добавляйте критерии приемки в конкретных формулировках.

Пример критериев приемки:

пользователь с ролью “Менеджер” видит доступный остаток по складу “Основной”

доступный остаток уменьшается при создании резерва другим заказом

при отсутствии прав на склад пользователь не видит остатки по этому складу

При желании критерии можно писать в формате Given/When/Then, но важно не “ритуальное оформление”, а проверяемость.

Связь user stories с постановками задач разработчикам

User story отвечает на “зачем и для кого”, но разработчику и тестировщику нужно “что именно меняем”. Поэтому консультант обеспечивает связь:

story → список задач

задачи → спецификации (если нужны)

задачи → тестовые сценарии

Практический прием: добавляйте в story ссылку на сценарий TO-BE и отмечайте, какие объекты 1С затрагиваются (документы, справочники, отчеты, регистры) на уровне терминов, без кода.

Как выбрать формат документации: практичная логика

Критерии выбора

уровень формальности (контракт или внутренняя команда)

стоимость ошибки (регучет и зарплата обычно “дороже”)

сложность (интеграции и расчеты требуют спецификаций)

динамика изменений (если требования плавают, удобнее бэклог stories + короткие спецификации)

Упрощенное правило консультанта

если нужно юридически и управленчески зафиксировать результат этапа, используйте ТЗ/ЧТЗ

если нужно однозначно реализовать сложную часть, используйте спецификацию

если работаете итерациями и важно быстро получать ценность, используйте user stories с четкими критериями приемки

На практике это комбинируется: например, ЧТЗ фиксирует границы этапа, а внутри этапа требования ведутся как user stories, а для интеграций пишутся отдельные спецификации.

Качество требований: как консультанту проверять себя до согласования

Ниже — чек-лист, который применим к ТЗ, ЧТЗ, спецификациям и user stories.

требование однозначно и не допускает двойного толкования

понятно, какая роль является “пользователем” результата

указаны предусловия и ограничения (если критично)

описан ожидаемый результат

есть критерии приемки

понятно, какие объекты 1С затрагиваются

учтены исключения хотя бы для топовых случаев

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

Управление изменениями: как не утонуть в правках

Даже идеальная документация устаревает, если требования меняются. Поэтому консультант фиксирует процесс управления изменениями.

Что фиксировать минимально

где ведется “единый источник правды” по требованиям (реестр, бэклог)

как версионируются документы

как согласуются изменения (кто утверждает)

как изменения влияют на сроки и бюджет

Практичный набор артефактов контроля

реестр требований (ID, статус, ссылка на документ)

журнал изменений (что изменили, почему, кто согласовал)

связка “требование → задача → тест → результат приемки”

Пример: как превратить сценарий TO-BE в требования

Возьмем короткий сценарий TO-BE из торгового контура.

Фрагмент сценария TO-BE

роль: менеджер

цель: отгрузка только по согласованным заказам

проверка: нельзя провести реализацию без согласованной скидки

Вариант в формате user story

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

Критерии приемки:

менеджер может создать заказ со скидкой

если скидка выше порога, заказ получает статус “На согласовании”

реализация по заказу в статусе “На согласовании” не проводится

руководитель продаж может согласовать скидку, после чего реализация проводится

Вариант в формате спецификации контроля

условие: скидка в заказе больше X%

действие системы: присвоить статус “На согласовании”; запретить проведение реализаций, связанных с этим заказом

сообщение пользователю: указать причину запрета и ссылку на заказ

права: согласование доступно только роли “Руководитель продаж”

Смысл примера: один и тот же TO-BE сценарий можно зафиксировать разными форматами, но обязательны проверяемость и привязка к ролям.

Итоги

Консультант 1С превращает результаты AS-IS и TO-BE в набор требований и документов, по которым можно работать без догадок.

Ключевые выводы:

ТЗ и ЧТЗ фиксируют границы и результат этапа, полезны для формального согласования

спецификации дают однозначность там, где высок риск ошибки (интеграции, отчеты, права, алгоритмы)

user stories удобны для итеративной работы, но требуют критериев приемки и привязки к ролям и данным

качество требований определяется тем, можно ли по ним реализовать, протестировать и принять результат

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

Настройка типового функционала без доработок: параметры, политики, регистры

Зачем консультанту уметь «выжимать максимум» из типовой конфигурации

В прошлых темах курса мы прошли цепочку роль консультанта → экосистема и платформа → типовые конфигурации → AS-IS/TO-BE → требования и документация. Следующий шаг в реальной работе консультанта 1С почти всегда практический: прежде чем ставить задачу на доработку, нужно проверить, можно ли решить запрос типовыми механизмами.

Типовая настройка без доработок дает три ключевых эффекта:

быстрее получаем результат и снижаем стоимость изменений

уменьшаем риски обновлений типовой конфигурации

повышаем предсказуемость приемки, потому что опираемся на стандартную логику

При этом консультант отвечает не за «покрутить галочки», а за управляемый результат:

понять, какой настройкой закрывается бизнес-правило

зафиксировать изменения и их влияние на процессы TO-BE

подготовить критерии приемки и обучение пользователей

Официальные точки входа, где проверяют возможности типовых решений и методические рекомендации: Сайт 1С:Предприятие 8 и 1С:ИТС.

Что мы называем «настройкой типового функционала»

Настройка типового функционала — это изменение поведения прикладного решения без изменения кода конфигурации. Формально это может делаться по-разному (в зависимости от конфигурации), но для консультанта важно понимать смысловые классы настроек.

Ниже три базовых «языка настройки», которые чаще всего встречаются на проектах:

параметры: включают или ограничивают функциональность, задают режимы работы

политики: фиксируют правила учета и обработки операций (как считаем, как отражаем, какие допущения принимаем)

регистры: хранят настройки, значения норм, соответствия и «таблицы правил», на которые опирается типовая логика

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

!Как консультант переводит запрос бизнеса в типовую настройку

Параметры: что это и как с ними работать

Что такое параметры в прикладных решениях 1С

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

Типовые примеры параметров (в разных конфигурациях они называются по-разному):

включить учет по складам или по организациям

использовать ордерную схему на складе или нет

включить серийный учет, характеристики, партии

включить планирование, бюджетирование, производственные блоки

Чем параметры отличаются от политик

Параметр чаще отвечает на вопрос «используем ли мы этот механизм и в каком режиме?», а политика — «по каким правилам учитываем и рассчитываем?».

Пример различия на бытовом языке:

параметр: «ведем ли мы резервы по заказам»

политика: «что считается доступным остатком и можно ли отгружать в минус»

Как консультанту безопасно менять параметры

Изменение параметров часто влияет на процессы шире, чем кажется пользователям, поэтому консультант действует последовательно.

Уточнить мотив и сценарий

- какой процесс хотим поддержать - какие роли участвуют - что является результатом и как это будет проверяться

Проверить зависимости

- какие документы начнут требовать дополнительные реквизиты - появятся ли новые статусы, проверки, этапы процесса - изменится ли «жизненный цикл» документов (например, добавится обеспечение/резерв)

Оценить влияние на данные

- нужно ли дозаполнять справочники (склады, характеристики, серии) - появятся ли новые обязательные поля

Зафиксировать решение в документации проекта

- что включили, когда, кто согласовал - какие сценарии TO-BE изменились - какие критерии приемки должны пройти

Типовые ошибки при работе с параметрами

включить параметр в середине проекта без пересогласования TO-BE

не проверить, что изменились формы и обязательность реквизитов

не описать, как пользователи должны работать «по-новому» (инструкция и обучение)

Политики: учетная логика без программирования

Что такое политики в контексте 1С

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

Чаще всего политики живут в:

учетной политике организации и параметрах учета

настройках отражения операций

правилах закрытия периода

правилах расчета себестоимости, резервов, распределений

В разных конфигурациях «политики» выглядят по-разному:

в 1С:Бухгалтерии акцент на регламентированный учет и отражение в проводках

в УТ и ERP акцент на модель управления запасами, обеспечением, взаиморасчетами и себестоимостью

в ЗУП акцент на правила расчета и отражение начислений

Почему политики нельзя «просто настроить по просьбе пользователя»

Политика почти всегда является управленческим решением бизнеса. Консультант может:

собрать варианты и ограничения

показать последствия для процесса и отчетности

предложить типовой путь

Но консультант не должен единолично утверждать спорные правила. Если есть выбор между вариантами, это фиксируется как решение владельца процесса или уполномоченного лица.

Примеры политик, которые часто всплывают в проектах

Ниже примеры именно как класса вопросов, а не как «универсальных настроек».

Запасы и склад

- разрешать ли отгрузку при отрицательных остатках - как контролировать обеспечение (резервы, заказы поставщикам)

Себестоимость

- как и когда рассчитывается себестоимость - какие затраты включаются и как распределяются

Взаиморасчеты

- по каким объектам ведем расчеты (контрагент, договор, заказ) - как обрабатываем предоплаты, зачеты, корректировки

Зарплата и отражение в учете

- какие начисления входят в базу - как отражаем начисления по статьям затрат/подразделениям

Как описывать политику так, чтобы ее можно было принять

Формулировка «настроить учетную политику» сама по себе непроверяема. Консультант привязывает политику к сценариям и критериям.

Практичный шаблон фиксации политики:

Контур и цель

- что улучшаем или что обязаны соблюдать

Правило

- что именно считаем/запрещаем/разрешаем

Где это проявляется

- документы, отчеты, закрытие периода

Роли и ответственность

- кто вводит, кто контролирует, кто утверждает

Критерии приемки

- на каких данных проверяем - какой ожидаемый результат

Регистры как основа типовых настроек

Что такое регистры простыми словами

Регистры в 1С — это специальные хранилища данных для учета и вычислений.

На уровне консультанта полезно помнить три базовых вида:

регистры накопления: остатки и обороты (например, товары на складах)

регистры бухгалтерии: проводки и бухгалтерский учет

регистры сведений: факты и настройки (курсы валют, цены, соответствия, параметры маршрутов и прочие «таблицы правил»)

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

Как консультант сталкивается с регистрами в типовой настройке

Типовые ситуации:

«почему система так считает»

- ответ часто лежит в том, какие значения записаны в настройках, которые технически хранятся в регистрах сведений

«почему у одного подразделения так, а у другого иначе»

- в регистре может быть настройка с измерениями (например, организация, склад, подразделение), из-за чего правила отличаются

«почему вчера работало, а сегодня нет»

- в регистре могли поменять период действия настройки (настройка действует с определенной даты)

Период действия настроек

Многие настройки в 1С действуют с определенной даты. Практический смысл:

можно менять правила «с нового периода», не ломая прошлые данные

нужно явно договариваться, с какого момента включается изменение

Консультант обязан фиксировать:

дату начала действия

причину изменения

кто согласовал

какие сценарии нужно перепроверить

Риски «настроек в регистрах»

Регистры сведений удобны, но создают два типовых риска:

настройки распределены по разным местам, и без карты настроек команда теряет целостность

пользователи с широкими правами могут «тихо» менять правила, что ломает воспроизводимость

Поэтому консультант связывает регистры с регламентом:

кто имеет право менять настройки

как согласовываем изменения

как фиксируем журнал изменений (хотя бы организационно)

Практический алгоритм консультанта: «без доработок» как управляемый процесс

Ниже — рабочая последовательность, которая помогает не скатиться в хаотичное «покрутили, вроде норм».

Классифицировать запрос

- параметр: включить/режим - политика: правило учета/расчета - регистр: значение/таблица настроек/соответствий

Привязать к TO-BE

- какой сценарий меняется - где в процессе появится новая проверка или шаг

Найти точку настройки

- раздел настроек в конфигурации - документ/справочник, где задается правило - таблица настроек (часто регистр сведений)

Протестировать на примере

- 2–3 типовых кейса - 1–2 исключения - отрицательные проверки прав (кто не должен иметь доступа)

Зафиксировать артефакты

- описание настройки - дата действия - критерии приемки - изменения в регламенте и инструкции

Спланировать внедрение

- кому сообщаем - кого обучаем - нужен ли перенос/дозаполнение данных

Примеры «типовое вместо доработки» по конфигурациям

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

Пример из торгового контура

Запрос:

«Нужно запретить отгрузку, если товар не зарезервирован под заказ»

Типовая логика поиска решения:

Проверяем параметры и режимы обеспечения

- используется ли резервирование - как формируется обеспечение потребностей

Формируем политику

- отгружать только по обеспеченным заказам - что считаем «обеспечением» (резерв, ожидаемое поступление, внутреннее перемещение)

Проверяем настройки, которые опираются на регистры

- правила обеспечения и ограничения часто задаются табличными настройками (внутри системы они могут храниться как регистр сведений)

Критерии приемки должны быть сценарными:

заказ согласован, резерв есть, отгрузка проводится

резерв отсутствует, система запрещает проведение с понятным сообщением

Пример из регламентированного учета

Запрос:

«Нужно, чтобы закрытие месяца выполнялось корректно по нашей методике»

Типовая логика:

Политика учета

- уточняем, что именно не совпадает: распределения, амортизация, НДС, косвенные расходы

Проверяем параметры учета и учетную политику

- с какого периода действует - какие способы распределения выбраны

Проверяем настройки справочников и соответствий

- статьи затрат, способы отражения, подразделения

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

Пример из ЗУП

Запрос:

«Начисление должно считаться иначе для определенной категории сотрудников»

Типовая логика:

Политика расчета

- за счет чего меняется расчет: график, вид начисления, база, показатели

Табличные настройки

- соответствия категорий сотрудников, подразделений, начислений

Права и ответственность

- кто имеет право менять настройки начислений

Как документировать настройки, чтобы проект был управляемым

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

Практичный формат фиксации настройки (как артефакт консультанта):

| Поле | Что писать | Пример уровня детализации | |---|---|---| | Название | Коротко | «Запрет отгрузки без резерва» | | Класс изменения | Параметр/политика/регистр | «Политика + настройка ограничения» | | Контур | Где влияет | Продажи/склад | | Роли | Кто участвует | Менеджер, кладовщик | | Дата действия | С какого момента | «С 01.03.2026» | | Влияние на процесс | Что изменится | «Добавляется обязательный шаг резервирования» | | Критерии приемки | Как проверить | «Без резерва проведение запрещено» | | Риски | Что может пойти не так | «Нужно обучить менеджеров резервировать» |

Этот формат можно включать в ЧТЗ, спецификацию или вести как реестр изменений.

Чек-лист консультанта: когда не надо идти в доработку

Перед постановкой задачи на разработку полезно пройти короткую проверку.

существует ли в конфигурации типовой механизм, который закрывает цель

достаточно ли настройки и регламента, чтобы процесс работал

понятны ли критерии приемки без изменения кода

оценено ли влияние на права, роли и обучение

согласованы ли политика и дата начала действия

Если на эти вопросы можно ответить утвердительно, доработка часто не нужна.

Итоги

Настройка типового функционала без доработок — одна из ключевых практических компетенций консультанта 1С.

Главные идеи статьи:

параметры включают или переключают режимы работы функциональности

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

регистры (особенно регистры сведений) часто являются местом хранения табличных настроек и значений правил

любая настройка должна быть привязана к TO-BE сценариям, иметь дату действия и проверяемые критерии приемки

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

Финансы и регламентированный учет в 1С: ключевые контуры и ошибки

Зачем консультанту 1С разбираться в финансах и регламентированном учете

В предыдущих темах курса мы научились:

понимать роль консультанта и границы ответственности

ориентироваться в экосистеме 1С, платформе и типовых конфигурациях

фиксировать AS-IS и проектировать TO-BE

переводить TO-BE в требования и выбирать типовую настройку без доработок

Финансы и регламентированный учет — зона, где стоимость ошибки обычно максимальна:

ошибки всплывают не сразу, а на закрытии месяца, в НДС, в отчетности

исправления часто требуют перепроведения документов, перерасчета себестоимости и корректировок

«мелкая настройка» может менять проводки и налоговые последствия

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

Официальные точки входа для сверки терминов и логики типовых решений:

1С:Бухгалтерия

1С:ИТС

Термины: что мы называем «финансами» и «регламентированным учетом»

Чтобы дальше говорить однозначно, зафиксируем рабочие определения.

Регламентированный учет — учет по правилам законодательства и нормативов, который используется для регламентированной отчетности. В проектах 1С чаще всего это реализуется в 1С:Бухгалтерии или в регламентированном контуре 1С:ERP.

Финансы — контур управления денежными потоками и взаиморасчетами (казначейство, банк/касса, план-факт платежей, дебиторка/кредиторка). В зависимости от компании это может быть как управленческий контур, так и часть регучета.

Первичный документ — факт хозяйственной операции (поступление, реализация, акт, счет-фактура и т.д.), который в 1С обычно отражается документом и приводит к движениям по учетным регистрам.

Закрытие месяца — регламентные операции, которые рассчитывают итоговые показатели периода (себестоимость, распределения, финансовый результат и т.д.).

> Важно для консультанта: пользователи могут называть «финансами» что угодно — от платежного календаря до P&L. На интервью уточняйте, какие решения, документы и отчеты они относят к «финансам», и где ожидают «истину».

Где живет регучет на проектах: типовые варианты контуров

На практике встречаются 3 типовые модели.

Только 1С:Бухгалтерия

- Часто у малого и среднего бизнеса. - Плюс: проще поддержка. - Риск: начинают пытаться вести сложный управленческий контур «внутри Бухгалтерии» без методики.

Оперативный контур + Бухгалтерия (например, УТ + БП)

- В УТ ведут продажи/закупки/склад, в Бухгалтерии — регучет. - Критично: границы ответственности и правила обмена.

ERP как ядро (регламентированный + управленческий контур в одной системе)

- Сильные сквозные процессы. - Критично: единая методика и дисциплина мастер-данных.

!Карта контуров учета и потоков данных в типовых проектах 1С

Ключевые контуры регламентированного учета и типовые «точки риска»

Ниже — практическая карта: какие блоки почти всегда затрагиваются, и где консультант чаще всего «промахивается», если не задает уточняющих вопросов.

Денежные средства: банк и касса

Что обычно автоматизируют:

загрузка банковских выписок и сопоставление оплат

платежные поручения и контроль статусов

кассовые операции

Типовые точки риска:

разные правила заполнения статьи ДДС/назначения платежа

отсутствие регламента: кто исправляет несопоставленные платежи

смешение управленческого и регламентированного назначения платежа

Что уточнять консультанту:

кто владелец справочников статьи движения денежных средств, банковские счета, кассы

какие разрезы анализа обязательны (организация, проект, ЦФО — если применимо)

кто и как контролирует «неразнесенные оплаты»

Взаиморасчеты: дебиторка и кредиторка

Что обычно важно для бизнеса:

корректная задолженность по контрагентам и договорам

зачеты авансов, частичные оплаты, корректировки

Типовые точки риска:

неверная аналитика взаиморасчетов (на каком уровне ведем: контрагент, договор, документ)

ручные корректировки «в обход» первички

«двойная истина» при связке УТ + Бухгалтерия (в одной базе долг один, в другой — другой)

Что уточнять консультанту:

где ведется «мастер» по контрагентам и договорам

как отражаются авансы и зачеты в целевом процессе TO-BE

какие отчеты считаются контрольными для сверки

Продажи и закупки как основа регучета

Даже если продажи ведут в УТ/ERP, регучет зависит от корректности первички:

корректные реквизиты (организация, договор, ставка НДС, склад/подразделение — по методике)

корректные даты и номерные последовательности (по регламенту)

Типовые точки риска:

пользователи меняют документ «задним числом» без контроля

нет единого понимания, какие документы являются юридически значимыми

неверные ставки НДС/признаки налогообложения из-за плохих мастер-данных

Что уточнять консультанту:

какие документы печатаются и уходят контрагенту (УПД, акты, накладные)

кто утверждает правила заполнения (бухгалтерия или методолог)

нужны ли ограничения прав на изменение документов прошлых периодов

НДС и счета-фактуры (если применимо)

Это зона, где «вроде провели документ» не означает «правильно для отчетности».

Типовые точки риска:

несоответствие дат: реализация датой одной, счет-фактура — другой

пересортица ставок НДС в номенклатуре

отсутствие регламента: кто отвечает за корректировки и исправления

Что уточнять консультанту:

какие операции типовые, какие исключения (корректировки, возвраты)

какой процесс согласования исправлений

какие контрольные отчеты/проверки применяются перед сдачей отчетности

Основные средства и нематериальные активы

Часто всплывает не на старте, а при переходе на новую систему или при инвентаризации.

Типовые точки риска:

неполные данные по объектам (сроки, амортизационные группы, первоначальная стоимость)

перенос остатков без сверки с регламентами

Что уточнять консультанту:

кто предоставляет исходные данные и кто принимает перенос

какие события должны отражаться (модернизация, выбытие, аренда — по ситуации)

Затраты, себестоимость и финансовый результат

Здесь чаще всего ломается закрытие месяца.

Типовые точки риска:

«не договорились о методике», но начали вводить документы

неправильные статьи затрат и правила распределения

разрывы между подразделениями: производство/склад/бухгалтерия живут по разным правилам

Что уточнять консультанту:

какие статьи затрат и правила распределения применяются

где фиксируется методика (регламент, ЧТЗ, внутренний стандарт)

кто владелец справочников затрат и кто имеет право менять настройки

Закрытие месяца: почему это главный экзамен проекта

Закрытие месяца — это точка, где система проверяет на прочность:

качество первички

корректность настроек и политик учета

дисциплину пользователей

полноту интеграций

!Типовой процесс подготовки и выполнения закрытия месяца

Что консультанту важно обеспечить в TO-BE и требованиях:

какие контрольные отчеты считаются обязательными перед закрытием

кто отвечает за устранение ошибок (бухгалтерия, склад, продажи)

какие действия запрещены после закрытия (например, изменения документов прошлого периода)

какой порядок «перезакрытия» при найденных ошибках

Связка «процесс → документы → настройки → отчетность»: как консультанту удерживать целостность

Удобный практический инструмент — фиксировать требования не только как «что сделать», но и как «что станет доказательством корректности».

Мини-матрица трассируемости

| Элемент | Что фиксируем | Пример формулировки | |---|---|---| | Процесс TO-BE | Шаги и роли | «Отгрузка формируется менеджером, проводит кладовщик, закрывающие формирует бухгалтер» | | Первичные документы | Перечень и обязательные реквизиты | «Реализация: обязательны организация, договор, ставка НДС» | | Настройки учета | Параметры и политики | «Запрет изменения документов закрытого периода» | | Контроль | Отчеты и проверки | «Перед закрытием месяц: отчет по непроведенным документам должен быть пустым» | | Приемка | Критерии приемки | «Провести сценарий продаж → закрыть месяц → контрольный отчет сходится» |

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

Типовые ошибки консультанта в финансовом и регламентированном контуре

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

Ошибка: смешать управленческий и регламентированный контур без границ

Как проявляется:

разные суммы выручки/долга в разных системах

двойной ввод документов

«непонятно, где правильно»

Как предотвратить:

в TO-BE зафиксировать одну версию правды по справочникам и документам

для связок (например, УТ + БП) описать: что вводится где, что передается, кто отвечает за расхождения

Ошибка: менять политики учета в середине периода без согласования

Как проявляется:

задним числом меняются правила, пересчитываются проводки/себестоимость

закрытие месяца становится невоспроизводимым

Как предотвратить:

фиксировать дату начала действия политики

согласовывать изменения через управление изменениями (реестр изменений, протокол)

Ошибка: проектировать «по форме документа», а не по сценарию и результату

Как проявляется:

«поле добавили», но закрытие месяца не сходится

контрольные отчеты не подтверждают результат

Как предотвратить:

описывать сценарии с предусловиями и критериями приемки (как в теме про TO-BE)

требовать контрольный результат: какие отчеты должны сойтись после сценария

Ошибка: недооценить мастер-данные

Критичные справочники:

организации, банковские счета

контрагенты и договоры

номенклатура и ставки НДС

статьи затрат и статьи ДДС

Как предотвратить:

на обследовании собирать примеры проблемных данных

в TO-BE и регламентах закреплять владельцев справочников и правила изменения

Ошибка: «закрытие месяца протестируем потом»

Как проявляется:

на пилоте «все работает», а на закрытии — блокирующие ошибки

Как предотвратить:

включать сценарий закрытия месяца в план тестирования и приемки

готовить тестовые данные, которые покрывают исключения (возвраты, корректировки, авансы)

Ошибка: дать широкие права «чтобы не мешать работе»

Как проявляется:

пользователи исправляют документы задним числом

исчезает контроль, растет число инцидентов

Как предотвратить:

матрица ролей и прав из TO-BE должна учитывать финансовые риски

разделять ввод, утверждение и исправления (по возможности)

Практический чек-лист консультанта перед запуском финансового/регламентированного контура

Этот чек-лист помогает связать предыдущие темы курса в один управляемый проход.

Границы контура

- Где ведем регучет (БП или ERP)? - Какие системы участвуют рядом и каковы правила обмена?

Ключевые процессы и первичка

- Какие документы являются юридически значимыми? - Какие обязательные реквизиты и кто их обеспечивает?

Политики и дата действия

- Какие учетные правила согласованы? - С какого периода они действуют?

Роли и права

- Кто может вводить/проводить/исправлять? - Есть ли ограничения на изменения прошлых периодов?

Контроль и приемка

- Какие контрольные отчеты обязательны? - Прогоняем ли сценарий закрытия месяца на тестовой базе?

Итоги

Финансовый и регламентированный контур в 1С — это не «еще один раздел меню», а система взаимосвязей:

процессы TO-BE задают кто и как работает

первичные документы фиксируют факты

настройки и политики превращают факты в учетный результат

закрытие месяца и контрольные отчеты подтверждают корректность

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