点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)嗨 对于访问控制(风险分析)的...
点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)嗨 对于访问控制(风险分析)的...
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
嗨
对于访问控制(风险分析)的GRC三层格局有两个建议:
第一个建议:
第二个建议:
将GRC prod连接到所有DEV,QA和Prod卫星系统的原因是,必须能够使用prod规则集规则ID并减轻所有卫星系统中的风险控制。
第三条建议
我的问题; 哪一个是最常见的?第二个 nd 提案是否有问题?
谢谢
Reza Ahoui
我主张选择2(一种将prod连接到prod和dev卫星的变体)。 我并不总是设置完整的开发环境(例如,可能仅使用1个ABAP连接器进行基本配置和验证)。
它为跨环境风险分析提供了机会,用户可以在DEV和 一个在生产中。 例如,更新PA0008表并放入运输工具,然后Prod运行基本工资等。
此外,您还可以具有特定于dev或qa的规则集(例如,所需的dev函数中的关键操作)
您最终可以将报告,工作流程批准等集中在一个定期备份的单一生产系统中。
问候
Colleen
# p#关于系统中测试数据的要点
从规则集的真实来源出发,我将Prod保留为主要规则集,并使用工作流主数据来批准更改(甚至自动批准更改)。 捕获更改文档)。 定期下载prod规则集,并将其应用于dev和qa
我观察到,当规则集有效地掌握数据时,一些客户将规则集更改应用于dev和qa,作为配置更改的一部分。 您可以在dev或qa中创建原型,但无需多次应用更改。
一周热门 更多>