Введение
Проект внедрения ERP-систем подразумевает не только конфигурирование коробочного решения, но и его доработку. Согласно [1], настройка системы позволяет покрыть не более 30% бизнес потребностей предприятия, оставшиеся 70% требуют программных доработок решения. Приблизительное число требований в проекте внедрения ERP-системы для автоматизации логистических, финансовых и кадровых бизнес-прессов около 300. Следуя статистическим данным, в ходе проекта необходимо будет реализовать порядка 200 программных разработок. Полученная цифра выглядит достаточно убедительно и накладывает особые требования по обеспечению качества реализуемых приложений.
Логика работы программ, разрабатываемых при внедрении ERP-систем, лежит целиком и полностью на функциональных консультантах и программистах. Стандартная программа в коробочном ERP-решении уже имеет обязательные проверки, средства контроля полномочий и прочие запрограммированные алгоритмы работы. В случае клиентской разработки все это должно быть продумано и спроектировано консультантом, в противном случае некачественная программа может стать причиной неуспешного продуктивного запуска ERP-системы.
Запуская программу, пользователь не задумывается, что происходит с технической точки зрения. Он видит селекционный экран программы, вводит входные данные, нажимает «Выполнить» и наблюдает полученный результат. В тоже самое время программа проверяет полномочия пользователя, осуществляет выбор данных на основе ограничений селекционного экрана и пользовательских полномочий, отображает информацию на экран. Одним из ключевых вопросов при разработке приложений являются проверка ролей и полномочий. Существуют несколько подходов к организации ролей и полномочий, мы рассмотрим их в данной работе и подытожим в соответствующей концепции.
Цель и задачи
Целью статьи является рассмотрение подходов к организации концепции ролей и полномочий в проектах внедрения систем класса ERP. Это позволит повысить качество программных разработок и исключить несанкционированный доступ пользователей к не предназначенным для них данным. Реализация цели потребует выполнения нижеуказанных задач:
- рассмотрение структуры технических ролей;
- обзор принципов формирования бизнес-ролей;
- подготовка матрицы доступа в ERP-системах;
- формирование стратегии ролей и полномочий.
1. Логика работы программы
Рассмотрим логику работы любой программы, чтобы понять аспекты конфигурирования ролей и полномочий. Следуя работе [2], каждая программная разработка представима тремя экранами: селекционный, выбранных и обработанных данных. Селекционный экран позволяет указать входные данные для работы приложения, экран выбранных данных отображает информацию, изъятую из таблиц баз данных с использованием ограничений селекционного экрана, и, наконец, экран обработанных данных содержит обновленную информацию, если пользователь выполнил операцию добавления, изменения или удаления над записями предыдущего экрана. Для ролей и полномочий важна следующая парадигма:
- каждая программа имеет техническое наименование;
- селекционный экран содержит параметры, задающие организационные уровни организации, например: компания, завод, склад, материально-ответственное лицо и др., экран выбранных данных отображает информацию с учетом ограничений по оргуровням;
- программа имеет два режима работы: редактирования или только чтения данных, что обеспечивается специальным параметром на селекционном экране или копией оригинальной программы, имеющей отличное техническое наименование.
Тогда каждая техническая роль включает в себя информацию по техническому наименованию программы, организационным уровням, для которых будет работать программа, и режимам (полномочиям) работы с программой, то есть чтение или запись (рис. 1). Данные этих трех параметров содержатся в названии или техническом наименовании роли для возможности быстрой идентификации. Технические роли обычно ведутся в разрезе функциональных областей ERP-системы. Минимальное число программ, доступ к которым может быть выдан пользователю, задает количество программ в одной техроли. Если рассмотреть ERP-систему на примере SAP ERP, то в ней выполняется настройка отдельных технических ролей, каждая из которых содержит перечень доступных для запуска программ, набор данных, определяющий допустимые организационные уровни программ, а также объекты полномочий, задающие возможные операции над данными программ, такие как: просмотр, создание, изменение, архивирование и др.
Рис. 1. Логическая схема ролей
Бизнес-роль содержит в себе несколько технических ролей из разных функциональных областей [3]. Именно бизнес-роль роль в последующим присваивается конечному пользователю в ERP-системе. Возникает вопрос, по какому принципу включить техроли в бизнес-роль. Здесь существует два подхода. Первый подход состоит в том, что каждому пользователю может быть присвоена лишь одна бизнес-роль, значит, она будет содержать в себе максимум технических ролей. Второй способ говорит об обратном: пользователю может относиться несколько бизнес-ролей, значит каждая бизнес-роль будет содержать в себе меньшее число технических ролей по сравнению с первым подходом или вообще ситуация сведется к тому, что технические и бизнес роли будут совпадать. В этом вопросе нет какого-то правила, все зависит от потребностей заказчика. Бизнес-роль в терминах системы SAP ERP представляется композитной ролью, а в ее состав включаются отдельные технические роли. Проверка полномочий срабатывает следующим образом, в момент запуска из программы считывается тройка константных величин: код программы, оргуровень и объект полномочий, а далее выполняется ее поиск в любой технической роли, присвоенной пользователю через бизнес-роль.
Полный текст статьи: https://corpinfosys.ru/archive/2018/issue-3/143-2018-3-authorizationstrategy
