Стратегия ролей и полномочий в ERP-проектах
- Подробности
- Опубликовано: 07.09.2018 10:24
- Автор: Петров Сергей Владимирович
- Просмотров: 4126
Аннотация: в статье описывается стратегия ролей и полномочий в ERP-системах. Рассматривается содержание технической роли, заданной кодом программы, организационными уровнями, а также режимом доступа к данным. Анализируются бизнес-роли, состоящие из набора технических ролей. Демонстрируется пример матрицы доступа. Вводятся два подхода к организации ролей и полномочий, где пользователю может быть присвоена одна или несколько бизнес-ролей. Материал снабжается примерами из SAP ERP.
Скачать: PDF (статья), PDF (выпуск №3).
Ключевые слова: концепция ролей и полномочий в SAP, распределение ролей и ответственности, роли и полномочия в SAP системе, пользователи и их полномочия, настройка прав в SAP, роли и полномочия SAP, пользовательский объект полномочий, транзакция PFCG, профиль полномочий пользователя SAP, SAP объекты полномочий, segregation of duties, наследование ролей полномочий, наследуемые роли, деривация ролей SAP.
Введение
Проект внедрения ERP-систем подразумевает не только конфигурирование коробочного решения, но и его доработку. Согласно [1], настройка системы позволяет покрыть не более 30% бизнес потребностей предприятия, оставшиеся 70% требуют программных доработок решения. Приблизительное число требований в проекте внедрения ERP-системы для автоматизации логистических, финансовых и кадровых бизнес-прессов около 300. Следуя статистическим данным, в ходе проекта необходимо будет реализовать порядка 200 программных разработок. Полученная цифра выглядит достаточно убедительно и накладывает особые требования по обеспечению качества реализуемых приложений.
Логика работы программ, разрабатываемых при внедрении ERP-систем, лежит целиком и полностью на функциональных консультантах и программистах. Стандартная программа в коробочном ERP-решении уже имеет обязательные проверки, средства контроля полномочий и прочие запрограммированные алгоритмы работы. В случае клиентской разработки все это должно быть продумано и спроектировано консультантом, в противном случае некачественная программа может стать причиной неуспешного продуктивного запуска ERP-системы.
Запуская программу, пользователь не задумывается, что происходит с технической точки зрения. Он видит селекционный экран программы, вводит входные данные, нажимает «Выполнить» и наблюдает полученный результат. В тоже самое время программа проверяет полномочия пользователя, осуществляет выбор данных на основе ограничений селекционного экрана и пользовательских полномочий, отображает информацию на экран. Одним из ключевых вопросов при разработке приложений являются проверка ролей и полномочий. Существуют несколько подходов к организации ролей и полномочий, мы рассмотрим их в данной работе и подытожим в соответствующей концепции.
Цель и задачи
Целью статьи является рассмотрение подходов к организации концепции ролей и полномочий в проектах внедрения систем класса ERP. Это позволит повысить качество программных разработок и исключить несанкционированный доступ пользователей к не предназначенным для них данным. Реализация цели потребует выполнения нижеуказанных задач:
- рассмотрение структуры технических ролей;
- обзор принципов формирования бизнес-ролей;
- подготовка матрицы доступа в ERP-системах;
- формирование стратегии ролей и полномочий.
1. Логика работы программы
Рассмотрим логику работы любой программы, чтобы понять аспекты конфигурирования ролей и полномочий. Следуя работе [2], каждая программная разработка представима тремя экранами: селекционный, выбранных и обработанных данных. Селекционный экран позволяет указать входные данные для работы приложения, экран выбранных данных отображает информацию, изъятую из таблиц баз данных с использованием ограничений селекционного экрана, и, наконец, экран обработанных данных содержит обновленную информацию, если пользователь выполнил операцию добавления, изменения или удаления над записями предыдущего экрана. Для ролей и полномочий важна следующая парадигма:
- каждая программа имеет техническое наименование;
- селекционный экран содержит параметры, задающие организационные уровни организации, например: компания, завод, склад, материально-ответственное лицо и др., экран выбранных данных отображает информацию с учетом ограничений по оргуровням;
- программа имеет два режима работы: редактирования или только чтения данных, что обеспечивается специальным параметром на селекционном экране или копией оригинальной программы, имеющей отличное техническое наименование.
Тогда каждая техническая роль включает в себя информацию по техническому наименованию программы, организационным уровням, для которых будет работать программа, и режимам (полномочиям) работы с программой, то есть чтение или запись (рис. 1). Данные этих трех параметров содержатся в названии или техническом наименовании роли для возможности быстрой идентификации. Технические роли обычно ведутся в разрезе функциональных областей ERP-системы. Минимальное число программ, доступ к которым может быть выдан пользователю, задает количество программ в одной техроли. Если рассмотреть ERP-систему на примере SAP ERP, то в ней выполняется настройка отдельных технических ролей, каждая из которых содержит перечень доступных для запуска программ, набор данных, определяющий допустимые организационные уровни программ, а также объекты полномочий, задающие возможные операции над данными программ, такие как: просмотр, создание, изменение, архивирование и др.
Рис. 1. Логическая схема ролей
Бизнес-роль содержит в себе несколько технических ролей из разных функциональных областей [3]. Именно бизнес-роль роль в последующим присваивается конечному пользователю в ERP-системе. Возникает вопрос, по какому принципу включить техроли в бизнес-роль. Здесь существует два подхода. Первый подход состоит в том, что каждому пользователю может быть присвоена лишь одна бизнес-роль, значит, она будет содержать в себе максимум технических ролей. Второй способ говорит об обратном: пользователю может относиться несколько бизнес-ролей, значит каждая бизнес-роль будет содержать в себе меньшее число технических ролей по сравнению с первым подходом или вообще ситуация сведется к тому, что технические и бизнес роли будут совпадать. В этом вопросе нет какого-то правила, все зависит от потребностей заказчика. Бизнес-роль в терминах системы SAP ERP представляется композитной ролью, а в ее состав включаются отдельные технические роли. Проверка полномочий срабатывает следующим образом, в момент запуска из программы считывается тройка константных величин: код программы, оргуровень и объект полномочий, а далее выполняется ее поиск в любой технической роли, присвоенной пользователю через бизнес-роль.
2. Матрица доступа
Однако в случае, если на экранной форме нужно выдать сразу несколько полей, значения которых хранятся в той же таблице баз данных, описание кажется слишком нагромождённым. Ощущается необходимость разовой записи SQL-запроса, а далее лишь ссылки на результаты выборки. Поэтому переходим к следующему, финальному способу описания.
Рис. 2. Матрица доступа
Тогда стратегия ролей и полномочий фактически будет состоять из одного единственного параметра: подхода к присвоению бизнес-ролей конечному пользователю, в котором может допускаться одна бизнес-роль для пользователя или множество. В первом случае возникают сложности в настройке ролей, однако в последствии это дает выигрыш с точки зрения администрирования присвоений бизнес-ролей пользователям. Во втором подходе наоборот: создание и конфигурирование бизнес-ролей упрощается, но возникают проблемы с администрированием, так как разным пользователям, имеющим близкие бизнес потребности, могут быть присвоены принципиально разные роли.
Заключение
Подведем итоги проделанной работы. Реализация концепции ролей и полномочий в ERP-системе подразумевает скрупулёзное настраивание технических ролей, требующих указания запускаемых программ, допустимых организационных уровней, для которых программа может обрабатывать данные, а также полномочий для запуска программы. Рассматриваются все имеющиеся программы ERP-системы, неважно были ли они в стандартном комплекте поставки или разработаны под нужды заказчика. Совокупность технических ролей определяет бизнес-роли, которые в последствии присваиваются конечным пользователям. При этом, существует несколько вариантов по формированию бизнес-ролей.
Первый вариант предполагает, что одна бизнес-роль покрывает потребности пользователей во всех программных разработках, таким образом конечному пользователю присваивается единственная бизнес-роль. Бизнес-роль в этому случае может представляться должностью, например: главный бухгалтер, материальный бухгалтер, кладовщик и др., каждой из которых доступно максимально необходимо число программных разработок. Второй подход говорит о том, что пользователю могут быть присвоены несколько бизнес-ролей, то есть каждая роль позволяет запускать лишь ограниченное число программ. В этому случае все программы ERP-системы могут выполняться под пользователем, которому присвоены все бизнес-роли.
Литература
- Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
- Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268. – URL: https://stepanovd.com/science/26-article-2014-4-design.
- Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МГТУ МИРЭА. - М., 2017. – URL: https://stepanovd.com/science/12-erp/52-erp-8-applicationlevel.
Выходные данные статьи
Петров С.В. Стратегия ролей и полномочий в ERP-проектах // Корпоративные информационные системы. – 2018. – №3 (3) – С. 53-58. – URL: https://corpinfosys.ru/archive/issue-3/143-2018-3-authorizationstrategy.
Об авторе
 |
Петров Сергей Владимирович – эксперт по разработке программных решений в банковской, торговой и производственной сферах. Специализируется на языках программирования высокого уровня С++, Java и Transact SQL. Имеет более чем 10-летний опыт разработки приложений. Принимал участие в проектах разработки аналитических, экспертных, биотехнических и корпоративных систем. Электронный адрес:Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. |