Ролевая модель для 1С:Документооборота: от интервью до проверки прав

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

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

Фраза «работа с документами» может означать десяток разных наборов прав. Один сотрудник создает проект договора и меняет файл до согласования. Другой только читает документ в своей задаче. Третий регистрирует карточку, но не должен видеть договоры другой организации. Руководитель контролирует исполнение, хотя менять содержание документа ему не требуется.

В 1С:Документообороте доступ складывается из нескольких настроек: полномочий пользователя, разрезов доступа, состава рабочей группы, участия в обработке, состояния документа, связей между объектами и отдельных правил для руководителей, заместителей и локальных администраторов (более подробно о технической стороне настройки прав доступа я писала ранее). 

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

Сначала разделить три разных типа прав

В ролевой модели удобно сразу разделить три вещи.

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

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

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

Эти уровни легко перепутать. Например, полномочие разрешает регистрировать входящие документы, но не говорит, документы каких организаций доступны регистратору. Участие в согласовании открывает конкретный договор, однако пользователь может не пройти ограничение по грифу или группе контрагентов.

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

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

Во время обследования важно помнить и о том, что штатное расписание дает список должностей, но не готовую ролевую модель. И проводить интервью с заказчиком нужно, исходя из этого тезиса.

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

Бывает и наоборот. Входящую корреспонденцию регистрирует секретарь в головной организации и офис-менеджер в филиале. В системе им может понадобиться одна функциональная роль с разными ограничениями по организациям и подразделениям.

На обследовании я сначала выясняю, кто создает документы, кто регистрирует, согласует, подписывает, исполняет, контролирует и исправляет ошибки. Затем связываю эти функции с сотрудниками и подразделениями.

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

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

Формулировка «имеет доступ к договорам» не годится для реализации. Нужно разложить ее на действия.

Эта детализация часто меняет первоначальный запрос. Например, заказчик говорит, что контролеру нужен доступ к документу. После уточнения выясняется, что ему достаточно видеть срок, ответственного и результат исполнения. Сам файл открывать не требуется.

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

Разрезы доступа проверяются в сочетании

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

Чтобы получить целостную картину, лучше сразу проходить по шести разрезам:

• организация;
• подразделение;
• вид документа;
• гриф доступа;
• группа контрагентов;
• группа физических лиц.

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

Доступ может появиться во время обработки

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

Согласующий может получить карточку только при старте своего действия. Подписант — после завершения согласования. Исполнитель поручения — после назначения задачи. Руководитель — из-за положения в структуре. Автор — с момента создания документа.

На обследовании я отдельно фиксирую момент выдачи и момент прекращения права.

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

Нужно проверить и ручное изменение рабочей группы. Может ли автор добавить коллегу? Кто вправе удалить автоматически назначенного участника? Разрешено ли расширять доступ к кадровому или конфиденциальному документу без дополнительного согласования?

Связанные документы — отдельный источник ошибок

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

Сотрудник получил дополнительное соглашение на согласование. Должен ли он автоматически увидеть основной договор? А служебную записку с расчетом цены? Нужно ли открывать акт человеку, который имеет доступ только к договору?

Я описываю правила для связанных документов по типам связей. Например:

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

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

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

Без такой детализации удобная автоматизация может открыть документ тому, кто не должен был его видеть.

Состояние документа меняет набор разрешенных действий

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

Значит, одной строки «Автор — изменение» мало. Нужно указать состояние документа.

Соответственно, нужно определить права для каждого из состояний документа: проект, на согласовании, согласовано/не согласовано, на регистрации, зарегистрирован и т.д. Для каждой стадии фиксируются права на каждый из реквизитов карточки документа, действия с файлами, удаление.

Фраза «после согласования документ блокируется» тоже требует расшифровки. Блокируется файл или вся карточка? Может ли делопроизводитель заполнить регистрационные реквизиты? Кто исправит ошибочно выбранного ответственного?

После завершения согласования автор не меняет файл и основные реквизиты. Делопроизводитель заполняет регистрационный номер. Руководитель подразделения может изменить ответственного по отдельной настройке доступности по состоянию.

Такое правило можно настроить и проверить. Формулировку «документ недоступен для редактирования» — нельзя.

Руководитель, заместитель и помощник — не одна роль

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

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

Замещение тоже нельзя описывать одной отметкой. Замещающий получает только задачи или еще и права на документы? Видит ли он карточки, созданные до начала замещения? Что происходит после окончания срока?

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

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

Кто меняет права после запуска

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

Поэтому на обследовании нужен разговор не только о первоначальной настройке. Заказчик должен назвать владельцев изменений.

Кто включает сотрудника в закрытую группу? Кто согласует временный доступ? Кто меняет права после перевода? Кто проверяет доступ уволенного сотрудника? Кто отвечает за грифы и группы контрагентов? Можно ли передать часть операций локальному администратору организации или подразделения?

Без ответственных временные права постепенно становятся постоянными, а состав групп перестает соответствовать реальной структуре.

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

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

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

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

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

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

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

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

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