🚀Добро пожаловать в эту статью🚀 🍉Профиль：matinal,глазвперед Род занятийИТ-индустрия,Один медленновперед Обычные люди, которые могут это сделать。 🏀серия колонн：Охватывает различные модули SAP, Python, Excel, искусственный интеллект и т. д. 💡 Другие столбцы：Некоторые методы, которые вы обычно изучаете,Заинтересованные друзья могут посмотреть。 🎁Надеюсь всем → Нравится👍 + Коллекция ⭐️ + Оставьте сообщение 📝 ​ ⛱️Все начинается от сердца, а когда сердце движется, все движется🏄‍♂️

Предисловие: Любая многопользовательская система неизбежно связана с проблемами разрешений. Чем больше пользователей имеет система и чем сложнее социальные атрибуты или разделение труда пользователей, тем сложнее будут проблемы с разрешениями. Система SAP является типичной многопользовательской системой. -пользовательская, многопользовательская система задач. 🦙 (Если вы столкнулись с идиотом на работе, обязательно держитесь подальше. Есть тысячи способов держаться подальше от идиотов.)

Предисловие

Любая многопользовательская система неизбежно связана с проблемами разрешений. Чем больше пользователей имеет система и чем сложнее социальные атрибуты или разделение труда пользователей, тем сложнее будут проблемы с разрешениями. Система SAP является типичной многопользовательской системой. , многозадачная система. Как программное обеспечение для управления предприятием, SAP добилась больших успехов в области управления предприятием. Это происходит главным образом потому, что SAP интегрирует передовые идеи управления в программные продукты, а также усовершенствованную архитектуру дизайна и настраиваемые бизнес-модели самого программного обеспечения. управление контентом и т. д., конечно, неотделимо от идеальной функции управления правами. Однако мы можем обнаружить общее явление практически во всех компаниях, использующих программное обеспечение для управления SAP: после выхода в Интернет, при постоянной реорганизации бизнеса компании, частых изменениях позиций пользователей, расширении и совмещении должностных обязанностей и т. д., происходят соответствующие изменения. Требуется настроить разрешения SAP соответствующего пользователя. В этот момент у соискателя разрешения возникает вопрос. Какие разрешения имеет этот пользователь? Могут ли пользователи подать заявку на это разрешение? Существует ли какой-либо конфликт между подачей заявления на получение этого разрешения и предыдущим разрешением? , какой персонал необходимо утвердить при подаче заявления на получение этого разрешения? и т. д. Эта статья не объясняет управление разрешениями SAP с технической точки зрения, а представляет собой решение комплексной проблемы управления разрешениями проектов SAP после их выхода в Интернет с точки зрения системы, управления и решений.

2. Принципы реализации разрешений SAP

На рисунке выше перечислены несколько ключевых концепций, используемых в управлении разрешениями SAP. Интуитивно говоря, разрешения — это контроль «кто-то может что-то делать» и «кто-то не может что-то делать». В системе SAP коды транзакций (также называемые кодами транзакций, TCODE или кодом транзакции) используются для представления того, что может сделать пользователь. Например, TCODE MM01 используется для ведения данных о материале, MIGO используется для получения товаров, CS01 используется для ведения спецификации и т. д. При использовании SU01 для создания нового идентификатора разрешение по умолчанию пустое, то есть вновь созданный идентификатор не может ничего делать или использовать какой-либо код транзакции. Таким образом, вам нужно только присвоить соответствующий TCODE соответствующему идентификатору, чтобы получить «кто-то может что-то сделать», а его дополнением будет «кто-то не может что-то сделать». Но мы не можем напрямую присвоить TCODE идентификатору в SU01, мы должны передать его через ROLE. То есть: связка TCODE формирует ROLE, а затем присваиваем эту ROLE определенному ID, и тогда этому ID будет доставаться связка TCODE. Выше приведены лишь основные концепции управления разрешениями SAP. Чтобы понять все элементы управления разрешениями SAP, вы также должны понимать следующие концепции.

1. Роль (РОЛ), составная роль

Как упоминалось выше, роль, то есть ROLE, представляет собой набор TCODE. Разумеется, она также включает в себя необходимые «объекты разрешений», «поля разрешений», «разрешенные операции» и «разрешенные значения», необходимые для TCODE. Мы используем PFCG для поддержки персонажей. Составная роль может содержать несколько отдельных ролей. Подробности см. в концепциях ниже.

2. Объект авторизации, Поле авторизации, Разрешенные операции (Активность), Разрешенные значения (Значение поля)

Вышеупомянутое грубо заявило, что ROLE состоит из нескольких TCODE. Фактически между ROLE и TCODE существует промежуточное понятие «авторитетный объект»: Роль содержит несколько объектов разрешений, а связь между ними хранится в прозрачной таблице AGR_1250; Объект разрешений содержит несколько полей разрешений, разрешенных операций и разрешенных значений, а связь между РОЛЬ/Объект/Поле/Значение отражается в прозрачной таблице AGR_1251; Существует специальный объект разрешений, содержащий несколько кодов транзакций. Этот объект разрешений называется «S_TCODE», а поле разрешения этого объекта разрешений называется «TCD». Допустимое значение (значение поля) этого поля хранит код транзакции. Существует специальное поле разрешений, используемое для указания того, какие операции можно выполнять с объектом разрешений, разрешено ли создавать, изменять, отображать, удалять или другие. Это поле разрешений называется «ACTVT». Допустимое значение (значение поля) этого поля хранит код, разрешающий операцию: 01 представляет собой изменение, 03 представляет собой отображение и т. д.; Управление разрешениями SAP контролируется на уровне поля. Другими словами, его механизм управления разрешениями может проверять, есть ли у вас разрешение на ведение определенного поля прозрачной таблицы. Система SAP поставляется с несколькими объектами разрешений и по умолчанию управляет несколькими полями разрешений (соответствующими определенным полям в прозрачных таблицах). Вы можете использовать код транзакции SU20, чтобы проверить, какие поля разрешений имеет система, и использовать SU21, чтобы проверить, какие объекты разрешений по умолчанию имеются в системе. Итак, мы знаем разницу между кодом транзакции и объектом разрешения. С точки зрения управления разрешениями, код транзакции является специальным объектом разрешения; во время выполнения кода транзакции, чтобы определить, имеет ли определенный идентификатор разрешение на выполнение кода транзакции, также могут быть проверены несколько других общих объектов разрешений. Используйте SU22, чтобы увидеть, какие объекты разрешений включены в код транзакции. В прозрачной таблице USOBX хранится соответствующая связь между кодами транзакций и объектами разрешений.

3. Пользовательские объекты разрешений

Собственные объекты разрешений и поля разрешений, упомянутые выше, могут удовлетворить только ограниченные потребности, а логика проверки разрешений также жестко запрограммирована системой. Все, что мы можем сделать, это проверить, включен ли определенный объект разрешений (с помощью SU22). Если вам нужно его настроить, просто определите его через SU20 и SU21.

3. Как эффективно управлять разрешениями

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

2.1. «Описание работы».

«Описание должности» — это документ, который каждый бизнес-отдел должен предоставить с конкретным описанием различных должностей в этом отделе. Большинство компаний уже должны иметь этот документ. Для некоторых компаний, у которых нет этого документа, мы должны его подготовить. on, настолько важен этот файл. Основанием для настройки прав пользователей в системе является это описание работы. При этом настройки каждой роли также должны соответствовать этому описанию работы.

2.2. Список кодов транзакций.

Модуль, к которому он принадлежит Код бизнес-операции Описание кода транзакции Лицо, ответственное за утверждение Основные данные MM MM01 Создание материала Чжан Фэн MM02 Изменение материала Чжан Фэн Материал дисплея MM03 Чжан Фэн MM06 Удалить материал Чжан Фэн ME11 Создать информационную запись Ли Линь ME12 Изменить информационную запись Ли Линь ME13 отображает информационную запись Ли Линь ME15 Удалить информационные записи Ли Линь Закупка ME21N Создать заказ на поставку Ван Бинь ME22N Изменить заказ на поставку Ван Бинь ME23N Показать заказ на поставку Ван Бинь ME51N Создать заявку на покупку Ван Бинь ME52N Изменить заявку на покупку Ван Бинь ME53N отображает заявку на покупку Ван Бинь ME57 Назначение и обработка заявок на закупку Ван Бинь ME58 распределил заказ на поставку Ван Бинь Заказ на поставку ME59N создается автоматически Ван Бинь

Пользователь этого списка записывает последний список кодов транзакций, используемых в настоящее время компанией. Помимо перечисления объема кодов транзакций, в нем также есть лицо, ответственное за утверждение каждого кода транзакции. При использовании этой настройки новые пользователи/роли должны это сделать. быть добавлен после выхода в Интернет. Когда вы вводите код транзакции, вы можете узнать, чье одобрение требуется, что решает проблему, упомянутую в предисловии «Какой персонал должен быть одобрен при подаче заявки на это разрешение?» Этот список является динамическим списком. Во время реализации проекта этот список, как правило, может обновляться в режиме реального времени. Однако после запуска проекта мы часто пренебрегаем его обновлением. По прошествии длительного периода времени мы оглянемся назад. Если окажется, что он далек от реального списка в системе, то список потеряет должное значение. Выделенный персонал отвечает за ситуацию и обновляется в режиме реального времени. Это основное требование для ведения этого списка. Точный список кодов транзакций, используемых в настоящее время компанией, имеет решающее значение для последующего обучения, подачи заявок и утверждения.

2.3. Процесс подачи заявки.

Контактный номер заявителя отдела подачи заявок компании Дата заявки Одобрение департамента Конфигуратор системы Дата конфигурации Список разрешений Имя должности пользователя Имя пользователя системы Роль Код транзакции Описание функции Значение поля разрешения Утверждение владельца разрешения Примечание Отображение списка счетов VF23 Выше приведен образец формы заявления на получение разрешения. Формат и процесс подачи заявления в каждой компании могут различаться, но основное содержание процесса утверждения разрешения должно быть сохранено. (1) Процесс подачи заявки на получение разрешения должен представлять собой замкнутый цикл, начиная с заполнения пользователем формы заявки, прохождения проверки и утверждения и, наконец, поддержания в системе и заканчивая уведомлением заявителя. (2) Заявки на получение разрешений должны быть одобрены лицом, ответственным за разрешение. Если это заявка на получение кода транзакции, она должна быть одобрена лицом, ответственным за код транзакции; роль, она должна быть одобрена лицом, ответственным за эту роль. (3) Не только новые разрешения требуют одобрения, но и изменения и удаления также требуют одобрения. (4) Все разрешительные операции персонала BASIS в системе основаны на этом документе. Эти документы заявки необходимо правильно хранить, поскольку они будут использоваться во время ИТ-аудитов.

2.4. Не хочу

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

2.5. Два тренинга.

В списке кодов транзакций, который мы упоминали выше, в процессе подачи заявки на разрешение очень важны роли ключевых пользователей и лиц, утверждающих разрешения. Они должны очень четко понимать содержание и функции этого кода транзакции и роли разрешений SAP, чтобы конечные пользователи могли это сделать. может предъявлять требования при предъявлении требований. Только тогда ключевые пользователи узнают, на какие роли и транзакции необходимо подать заявку, и только тогда лица, утверждающие разрешения, узнают, может ли пользователь подать заявку на это разрешение. Ключевые пользователи и сотрудники, утверждающие разрешения в каждой сфере деятельности, должны хорошо разбираться в содержимом этой таблицы. Только таким образом применение и утверждение разрешений может быть действительно согласовано с потребностями бизнеса. Поэтому обучение ключевых бизнес-пользователей и персонала, утверждающего разрешения. имеет решающее значение. За счет эффективного обучения персонала по этим двум направлениям мы можем решить проблему, поднятую в предисловии: «Могут ли пользователи подать заявку на это разрешение?»

2.6. Три таблицы разрешений.

2.6.1. Форма обслуживания одной роли.

Серийный номер Роль Описание роли Код транзакции Описание кода транзакции Управление объектом разрешения Роль Ответственное лицо 1 ZSP_CN30_MM_DISPVNDR Запрос поставщика XK03 Показать поставщика

2 ZSP_CN30_MM_VENDOR_STD Обслуживание поставщиков XK01 Создавайте централизованно Account group <> C1EM or C2EM XK02 Сменить поставщика XK03 Показать поставщиков MK03 Показать данные о покупке XK05 заморозить поставщика XK06 Удалить поставщика тегов XK07 Изменить группу аккаунтов MK05 Заморозить данные о закупках MK06 Удалить отмеченные данные о покупке BD14 поставщик дистрибуции Обратите внимание, что у каждой отдельной роли есть ответственное лицо, которое несет полную ответственность за роль, включая добавление или удаление содержимого роли, утверждение пользовательских приложений на получение разрешений роли и т. д. 2.6.2 Составная таблица ролей.

Серийный номер Составной номер роли Описание составной роли Серийный номер одной роли Номер соотношения одной роли 1 ZCP_CN30_MM_GENREPNOPRICE_PUR Общий дисплей ММ без цены (PUR) 20 ZSP_CN30_MM_PUR_GEN_REP_NO_PRI 2 ZCP_CN30_MM_GENREPNOPRICE_IM Общий просмотр ММ без цены (IM) 60 ZSP_CN30_MM_IM_GENERAL_REP 64 ZSP_CN30_MM_IM_YPSTKLIST_NO_PR 71 ZSP_CN30_MM_READTX

3 ZCP_CN30_MM_GENREPWIPRICE_PUR Общий дисплей ММ с ценой (PUR) 21 ZSP_CN30_MM_PUR_GEN_REP_WI_PRICE 78 ZSP_CN30_MM_PR_CONVERTSTATUS Составная роль может включать в себя несколько отдельных ролей. Таким образом, назначая пользователю составную роль, можно достичь того же эффекта, что и присвоение пользователю нескольких отдельных ролей. 2.6.3. Список позиций.

Серийный номер Отдел Должностная инструкция Назначенная роль Отдел пользователя Пользователь 1 Все Отображение информации о заказе на покупку с ценой ZCP_CN30_MM_GENREPNOPRICE_PUR Покупка ZHUANGXX Логистика 1 SUNWM Логистика 2 ИНХИ 2 Все Отображать информацию о заказе на поставку без цены ZCP_CN30_MM_GENREPNOPRICE_IM Качество WANGP Установите связь между пользователями и ролями с помощью списка заданий.

2.7. Платформа проверки согласованности разрешений пользователей.

Эта платформа является предметом внимания этой статьи. Она может решить проблемы, упомянутые в предисловии: «Могут ли пользователи подать заявку на это разрешение? Есть ли конфликт между подачей заявки на это разрешение и предыдущим разрешением и другими проблемами?» Эта платформа связывает некоторые нормы и точки контроля в повседневной деятельности предприятия с конкретными ролями, кодами транзакций и т. д. Когда пользователи подают заявку на получение разрешений, они могут проверить, есть ли на этой платформе сообщения об ошибках согласованности. Если нет, они могут подать заявку. Например: те в отделе закупок, которые устанавливают цены, не могут иметь полномочий на открытие заказов, а те, кто создает заказы на закупку, не могут получать товары и т. д. Вот несколько примеров правил проверки:

ТКОД Описание ТКОДА F22 MB1A Введите счет-фактуру/отгрузку клиента F-22 VF11 Ввести счет клиента/отменить счет F-27 MB1A Введите уведомление о кредите/доставке клиента F-27 VF11 Ввод кредитного уведомления клиента/отмена счета F110 F-41 Информация об автоматическом платеже/Ввод кредит-ноты поставщика F110 F-42 Автоматическая информация о платеже/ввод переноса проводки F110 F-43 Автоматическая информация об оплате/ввод счета поставщика F110 FB01 Информация об автоматическом платеже/счетовой ваучер F110 FB50 автоматическая платежная информация/ввод ваучера счета главной книги F110 FB60 Автоматическая информация об оплате/ввод счета поставщика F110 FB65 Информация об автоматическом платеже/Ввод кредит-ноты поставщика F110 MB01 Автоматическая информация об оплате/получение заказа на поставку F110 MB0A Автоматическая информация об оплате/получение заказа на поставку F110 MIGO автоматическая информация об оплате/получение внешних покупок Создание библиотеки проверки согласованности также может быть достигнуто двумя способами: 1. Создайте библиотеку проверки согласованности вне системы SAP. При появлении нового запроса вручную сравните его с содержимым библиотеки согласованности. Если он соответствует требованиям, он будет поддерживаться в системе, если он не соответствует требованиям, он будет поддерживаться в системе. будет возвращен пользователю. Этот метод прост в реализации и не требует дополнительных разработок и затрат. 2. Создайте библиотеку проверки согласованности в системе SAP. При применении система автоматически определяет разрешения, которые уже есть у пользователя, из таблицы разрешений пользователя, затем извлекает правила проверки из таблицы проверки согласованности и проверяет, есть ли они. квалифицирован в соответствии с правилами проверки. Этот метод реализует плавную связь между функциональной проверкой разрешений и исходным содержимым разрешений SAP и автоматически контролирует согласованность при сохранении разрешений пользователя. Эта платформа представляет собой процесс постепенного улучшения, который можно постоянно совершенствовать по мере того, как бизнес предприятия продолжает стандартизироваться. Каждое предприятие может иметь свои собственные уникальные правила проверки согласованности.

4. Заключение

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

Как насчет этого,В пониманииСамый подробный анализ управления разрешениями SAPКак вы думаете, эта штука в конце концов окажется очень сильной?？Но это кажется разумным и разумным.,Самый подробный анализ управления разрешениями SAP😏

Если эта статья оказалась для вас полезной, надеюсь, вы поставите лайк, соберете ее и прокомментируете. Спасибо всем💕! ! ! Кроме того, если у вас есть какие-либо вопросы или предложения, оставляйте их в комментариях.