Зачем вообще аналитикам 1С писать аналитические записки
В проектах 1С мы постоянно делаем артефакты “на стыке”: между бизнесом, разработкой, архитектором, безопасностью, сопровождением, IDM и эксплуатацией. Не все вопросы удобно решать через ЧТЗ, user story или переписку в почте.
Есть класс задач, где нужна именно аналитическая записка:
- когда уже есть текущая реализация;
- когда выявлено расхождение между ожиданием бизнеса и фактом;
- когда надо не просто “описать доработку”, а подвести участников к управленческому решению;
- когда цена ошибки — не только в коде, но и в администрировании, процессах и сопровождении.
И вот здесь мне стало интересно: а есть ли на Инфостарте хорошие практические примеры именно аналитических записок аналитика 1С? Поискал — и, по крайней мере в открытой выдаче, не нашёл отдельного нормального разбора или шаблона именно такого документа. Если у кого-то есть ссылки — буду благодарен.
Сразу скажу: записка не идеальная, но как рабочий документ у неё есть сильные стороны.
Встречаем:
Аналитическая записка
Тема: анализ текущей реализации ограничений доступа по складам и документам в 1С ERP
Цель: подготовка решения по дальнейшему использованию текущей модели прав доступа
1. Контекст
В системе 1С ERP реализована модель разграничения прав доступа пользователей, основанная на сочетании:
- функциональных ролей пользователей;
- групп пользователей;
- механизма RLS (ограничение доступа на уровне записей).
Права назначаются через группы пользователей, которые содержат профили доступа. Профили включают набор ролей, определяющих функциональные возможности пользователя.
Согласно регламенту прав доступа, ограничение доступа пользователей должно выполняться по складам: пользователь должен работать только со складами, закрепленными за его ролью и группой пользователей.
На объектах работают пользователи разных профилей, согласно корпоративному шаблону:
- Аудитор РОМАШКА
- Контроллер РОМАШКА
- Менеджер по закупкам РОМАШКА
- НСИ РОМАШКА
- Товаровед РОМАШКА
2. Текущая реализация прав доступа
2.1 Архитектура доступа
В системе используется следующая модель:
- Пользователь включается в группу пользователей через запрос в IDM.
- Группа пользователей содержит группу доступа, к которой привязан профиль доступа.
- Профиль включает роли системы.
- Ограничение по складам реализовано через механизм RLS.
Таким образом, фактический доступ формируется как комбинация: профиль пользователя + набор разрешенных складов.
2.2 Ограничение по складам в документах
Ограничение доступа по складам применяется для документов системы.
Пользователь может:
- создавать и редактировать документы только по разрешенным складам;
- проводить документы только по разрешенным складам.
Если пользователь пытается выполнить операцию по чужому складу, система не позволяет записать документ.
Ограничение действует для всех типов документов первой очереди, включая:
- заказ поставщику
- приходный ордер
- заказ на внутреннее потребление
- расходный ордер
- заказ на перемещение
- пересчет товаров
Таким образом, пользователь не может выполнить операции по складам, к которым не имеет доступа.
2.3 Видимость складов
В текущей реализации:
- справочник «Склады» доступен для просмотра без ограничения по RLS;
- пользователь может видеть все склады в системе;
- при этом выполнять операции может только по разрешенным складам.
Таким образом реализована следующая модель:
|
Возможность |
Поведение |
|
Просмотр складов |
доступны все склады |
|
Выбор склада в документе |
возможен |
|
Запись документа |
возможно только по разрешенному складу |
2.4 Видимость документов
Документы, относящиеся к чужим складам, скрыты от пользователя и недоступны для проведения и редактирования.
Операции по чужим складам блокируются механизмом RLS.
3. Выявленное расхождение
В ходе обсуждения была отмечена следующая особенность текущей реализации:
Пользователь может иметь доступ только к части складов, но при этом видеть все склады в справочнике.
Ожидание бизнеса формулируется следующим образом:
пользователь должен работать только со своими складами и видеть документы только по своим складам.
При этом вопрос ограничения видимости справочника складов остается открытым.
4. Формулировка проблемы
Требуется определить, необходимо ли дорабатывать текущую модель прав доступа.
Ключевые вопросы:
- соответствует ли текущая реализация ожиданиям бизнеса;
- требуется ли ограничивать видимость складов в справочнике;
- достаточно ли ограничений только на уровне документов;
- требуется ли фиксировать дополнительную доработку в бэклог.
5. Возможные дополнительные доработки текущей модели
5.2. Ограничения для списка документов-распоряжений в рабочем месте приемки и отгрузки
Пользователь может увидеть в рабочем месте приемки-отгрузки в табличной части список распоряжений по «чужим» складам, но не может в них зайти.
Предлагается:
- Сохранить доступность чтения документов-распоряжений для приемки / отгрузки по доступному складу.
- Ограничить отображение документов-распоряжений для приемки / отгрузки по «чужим» складам.
5.2. Ограничения для документа «Перемещение товаров»
Если в дальнейшем в процессы будет включаться документ «Перемещение товаров» или любой другой документ, в котором указывается два склада (доступный пользователю и «чужой»), то необходимо будет доработать доступность объекта.
Предлагается:
- Сохранить ограничение на отображение документов, которые не относятся к доступному складу пользователя (пользователь не видит их в списке).
- Добавить ограничение на запись документов, которые создаются на «чужом складе» аналогично текущей доработке для «Заказа на перемещение» (Пример: «чужой» склад создает документ «Перемещение товаров» и указывает доступный пользователю склад как склад-получатель. Пользователь может видеть такой документ, но не может его изменять).
6. Варианты дальнейшей реализации
На основе выявленных особенностей и проведённой доработки по документам «Заказ на перемещение» сформировано два варианта развития модели прав доступа.
Вариант 1. Сохранение текущей модели
Фиксируется текущее состояние системы, включающее выполненную доработку по документам перемещения. Пользователь видит все склады в справочниках и формах выбора, но запись и проведение документов возможны только по разрешённым складам. Для документа «Заказ на перемещение» действует особый режим: пользователь видит документы, где его склад является получателем (право «Чтение»), но изменять может только свои.
Последствия для бизнеса:
- Пользователь видит все точки хранения (склады), в том числе настройки складов и их адреса.
- При выборе склада в документе или при работе в рабочем месте приемки / отгрузки пользователь видит «чужие» объекты, что может вызвать вопросы у новых сотрудников и требует разъяснений «почему вижу, но не могу трогать».
- Критичные операции (изменение, проведение) по «чужим» объектам заблокированы RLS. Пользователь не может случайно или намеренно повлиять на объекты или остатки других складов.
- Не требует дополнительных настроек и согласований. Система готова к работе в текущем виде.
Вариант 2. Углубление ограничений (по группам складов)
Доработка логики RLS с привязкой не просто к конкретному складу, а к группе складов. Предполагается настройка правил подбора складов в зависимости от типа документа (например, в «Заказе поставщику» доступны склады А и Б, а в «Заказе на перемещение» - только склад А). Видимость справочника «Склады» также предлагается ограничить согласно группам складов.
Последствия для бизнеса:
- Сохранение потребности бизнеса: пользователь видит в системе ровно то, с чем должен работать (только «свои» склады и документы).
- Гибкое описание сценариев, где один сотрудник видит одни склады, но не видит другие.
- Требуется глубокая совместная проработка с бизнес-заказчиками по каждой роли и по каждому типу документа.
- Увеличивается время на разработку, тестирование и согласование.
- Усложняется администрирование: требуется выделение отдельного сотрудника, который будет курировать вопрос назначения прав через IDM и распределять их между сотрудниками.
*Интересный момент - картинку для АЗ, мне делала ИИ NanaBanana, мне понравился такой комикс :)
Вопросы к сообществу
Коллеги, интересно ваше мнение.
- Считаете ли вы такую записку хорошей аналитической запиской для 1С-проекта?
- Достаточно ли в подобных кейсах описать контекст, проблему и варианты — или аналитик обязан дать прямую рекомендацию?
- Нужно ли в аналитической записке сразу показывать трудоёмкость, риски и влияние на администрирование, или это уже отдельный документ?
- Есть ли у вас в командах шаблон аналитической записки, который реально работает на согласованиях?
Буду рад, если в комментариях покажете свои подходы: что вы считаете признаком сильной аналитической записки, а что — признаком недоработки.