Немного об оргструктуре и ролевой модели

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

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

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

Уделю внимание последнему пункту, т.к. часто возникают проблемы при использовании этой возможности. Всегда необходимо помнить, что оргструктура является глобальным объектом в рамках разрабатываемой конфигурации. Исходя из этого, при ведении проекта в нескольких средах-площадках (dev-stage-production) становится невозможным пользоваться механизмом экспорта\импорта\обновления решений. И здесь как раз в помощь оргструктуре приходит механизм функциональных групп и ролей.

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

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

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

Для компании в ходе разработки были реализованы следующие решения: Кадры, HR, ЭДО, Логистика. Для каждого раздела была разработана функциональная ролевая модель. Таким образом, допустим, для раздела HR у нас существует роль «Бухгалтер для начисления ЗП», а для раздела Кадры — роль «Бухгалтер для начисления командировочных» и группа «Сотрудники, ответственные за проверку авансового отчета». В эти роли и группы мы можем добавить уже конкретного пользователя или выбрать элемент оргструктуры, например, в качестве участника группы «Сотрудники, ответственные за проверку авансового отчета» добавить группу из оргструктуры «Бухгалтер».

Далее, уже при реализации бизнес-процессов в конкретные ЗО мы ставим в качестве исполнителей функциональные группы и роли из приложений и разделов («Бухгалтер для начисления ЗП», «Сотрудники, ответственные за проверку авансового отчета»). Также эти объекты выбираем при настройке прав доступа к элементам приложений.

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

Также, ролевую модель можно сделать еще гибче, за счёт использования приложений-справочников, которые бы отражали структуру отделов и сотрудников в них. Такие приложения позволяют строить достаточно сложные матрицы ответственности и применять их в бизнес-процессах. Но это тема для отдельной статьи, возможно появится позже, уже после реализации нового типа данных «Роль».

Спасибо за статью