SAP治理、风险与合规（GRC）管理
1. GRC 概述
GRC是Governance, Risk, Compliance三个单词的缩写；Governance指的是治理，包含公司治理、IT治理相关的内容；Risk指的是风险，由于不同行业对风险的定义略有不同，这里只认为风险是消极的事件，可能会造成损失；Compliance是合规性或者一致性，既包含外部法律法规的合规也包含内部政策、程序的合规。
2. GRC 的必要性
2.1 企业自身需要
-
企业内部管控的需要：由于越来越多的业务运行在信息系统上，需要一个统一的平台来分析和处理系统中以及业务中存在的风险。 -
完善风险管理的需要：企业的风险管理不是孤立的、只由一个部门来考虑的问题，而是需要全员的参与，乃至形成企业文化的一部分。因此，需要一个能将风险思想传递到每个部门、每个员工的信息平台。 -
业务部门与IT部门之间的鸿沟容易导致低效率和控制的缺失，需要一个既能保证有效的控制，又能提高效率的工具。
2.2 法律法规要求
| 名称 | 发布机构 | 发布时间 | 实施范围 |
| 《企业内部控制基本规范》 | 财政部、审计署等机构联合发布 | 2008/6/28 | 国内上市公司 |
| 《企业内部控制应用指引》 | 财政部、审计署等机构联合发布 | 2008年6月陆续发布 | 国内上市公司 |
| 《企业管治常规守则》 | 香港联交所 | 2004年11月 | 香港上市公司 |
| 《企业管治报告》 | 香港联交所 | 2004年11月 | 香港上市公司 |
3. GRC 的价值
- 分级管控规则制定——集团管控 VS 企业个性化需求：信息系统的授权不再是企业各行其是，而是按照集团审批通过的岗位设置、职责分离原则进行授权，在集团能够掌控系统中存在的风险的同时，兼顾企业自身的需求。
- 实时违规分析与授权——企业风险责任 VS 授权需求：将风险管理的意识推广到集团各级，使下属企业不再是单纯的考虑权限需求，而必须关注其中存在的风险。
- 定期检查与评估——连续审计 VS 审计取证：对信息系统进行实时的监控，可以及时预警并保证审计轨迹的完整性，实现对信息系统及相关业务的连续审计。
- 技术支持的持续优化——安全管理 VS 授权操作：使信息系统的管理人员可以更加全面的履行安全管理的职责，而不是简单的执行授权的操作。
4. 访问控制风险分析 Access Risk Management
4.1 规则架构
GRC风险分析的前提是事项的识别，也就是建立风险分析的规则架构，具体包括：梳理SAP中的操作（Function）；定义职责分离的规则与关键操作。Function（SAP中的业务操作）指的是SAP中一组功能相似的操作，同时还包括这些操作所涉及的对象与值。这些构成风险分析规则的基础，也是角色重组时的依据之一，例如：
| Function Category | Function ID | Description | 中文描述 |
| SD | AR04 | AR04 – Credit Management | 信贷管理 |
| SD | AR05 | AR05 – Maintain Billing Documents | 维护系统发票 |
| SD | AR06 | AR06 – Process Customer Credit Memos | 处理客户贷项凭证 |
| FICO | CC01 | CC01 – Maintain Cost Center Distributions | 维护成本中心分配 |
| FICO | CC02 | CC02 – Maintain CC or CE Groups | 维护成本中心或者成本要素组 |
| FICO | CC03 | CC03 – Maintain Cost Centers | 维护成本中心 |
| MM | PR01 | PR01 – Vendor Master Maintenance | 供应商主数据维护 |
| MM | PR02 | PR02 – Maintain Purchase Order | 采购订单维护 |
| MM | PR03 | PR03 – Service Master Maintenance | 服务主数据维护 |
| PP | PP01 | PP01 – Confirm Production Order | 确认生产订单 |
| PP | PP02 | PP02 – Production Order Processing | 生产订单处理 |
- Function Category指的是Function按照业务模块的分类。
- Function ID指的是系统中的ID号。
- Function在实施过程中已经结合企业自身业务，增加了自定义的程序、报表，以及需要特殊管控的对象、值。
- 在系统日常运行中，实际业务常会变化；因此，需要对应的检查Function是否需要随之变更。
4.2 风险识别
在4.1中对Function梳理的基础上，根据SOD（职责分离）的原则定义了不同Function的组合所产生的风险，以及所需关注的关键操作，例如：
| Risk ID | Function Description | Risk Level | Risk Type | Detailed Description | 中文描述 |
| F001 | GL02 – Maintain GL Master Data & GL01 – Post Journal Entry | Medium | Segregation of Duties | Create a fictitious GL account and generate journal activity or hide activity via posting entries. | 通过过账条目创建虚拟总账科目、生成日记账活动或隐藏活动。 |
| F002 | CC06 – Cost Transfer Processing & CC03 – Maintain Cost Centers | Medium | Segregation of Duties | Alter a cost center without authorization and process unauthorized cost transfers to this center, possibly distorting CO reporting. | 未经授权而改变成本中心并处理未授权的成本转账，这很可能会篡改 CO 报表。 |
- Risk ID是系统中此风险规则的ID。
- Function Description 是对此规则涉及到的需要分离的功能(Function)或关键操作的描述。
- Risk Level是风险等级，可以根据自身的风险偏好进行调整。
- Risk Type是风险的类型，具体分为Segregation of Duties和Critical Action。
- 项目上线后的日常运行时，业务变更会导致风险规则变更，需要检查规则是否要做相应调整。
5. 角色管理 Business Role Management
5.1 角色重组和设计
角色重组和设计的目的：
- 消除角色层面的风险。
- 便于无风险的用户账号的快速提供。
- 建立清晰的，基于风险分析的，便于长期维护的角色体系，形成SAP应用安全的基础。
角色重组和设计的原则：
- 与业务类型、组织结构相结合：在Role重组的过程中充分考虑集团业务类型与组织结构。例如Role按公司或组织的类型分为工厂、共享服务中心等，在名称上即给予区别。
- 与实际业务中的岗位设置相结合：梳理每个岗位的职责，避免因人设岗。例如共享服务中心的即使用了集团设置的标准的财务岗位。
- 可重用性：结合实际业务与风险分析的规则，定义粒度较小的模板Role，可反复用于派生或组合成新的Role。
- 职责分离：充分考虑职责分离的规则，在单个Role层面实现无SOD冲突。
- 统一性：充分考虑整个集团所有的业务，各公司的Role均按照统一的规则进行派生、复合。
5.2 重组的角色参考体系
| 模板ROLE | 模板Role描述 | 派生ROLE | 复合ROLE | 岗位描述 |
| T_FI_GL01_Post.Doc | 一般凭证记账 | D_FI_LG_GL01_Post Docs_01 | C_FI_LG_GL POST | 总账凭证记账 |
| T_FI_GL01_Doc.Dsp | 一般凭证显示 | D_FI_LG_GL01_Doc.Dsp_01 | ||
| T_FI_GL01_Doc.Rev | 一般凭证冲销 | D_FI_LG_GL01_Doc.Rev_01 | ||
| T_FI_Doc.Chg | 一般凭证修改 | D_FI_LG_GL01_Doc.Chg_01 | ||
| T_FI_Park.Doc.Dsp | 显示预制凭证(FV50显示） | D_FI_LG_GL01_Park.Doc.Dsp | ||
| T_FI__G/L.Clear | 总账清账/重置已清项 | D_FI_LG_GL01_G/L.Clear | C_FI_LG_GL Clear | 总账清账 |
| T_FI_Doc.Dsp | 一般凭证显示 | D_FI_LG_GL01_Doc.Dsp_01 |
- 模板Role即粒度最小的Role，不包含组织级别的值，不直接赋予用户，仅用来派生出各组织级别的派生Role。其命名规则为：’T’(Template) +,模块名（例如’FI’表示FI模块，） +具体操作的描述。模板Role层面保证没有风险冲突，是用来生成集团使用的其他角色。
- 模板Role描述保证了能从其中直接看出Role的功能。
- 派生Role在模板Role的基础上添加了组织级别的信息，用于组合成复合Role，也可直接赋予用户。其命名规则为：’D’(Derive) + 模块名称 + 公司代码+ 具体操作的描述。由于是从模板Role派生而来，因此也是没有风险冲突的，如需调整，只需更改模板Role便可实现全集团范围内的统一更改，因此便于长期的使用、维护。
- 复合Role是根据实际业务中的岗位设置，同时参考职责分离的规则制定的，是由派生Role组合而成。’C’ (Composite) + 模块名称 + 公司代码 +岗位描述。复合Role可能存在风险冲突，但是可能实际业务中需要的，可以对其创建Mitigation。
5.3 角色日常维护与风险分析、改进
通常情况下，在GRC的模板项目中，已经对SAP中的Role做了全局性的规划，但是在日常业务中，以下几种情况还是会导致SAP中角色的变更：
- 新工厂上线。
- 新增的二次开发的程序、报表。
- 支持人员在处理用户权限申请时找不到合适的角色。
- Basis检查发现Role存在风险。
6. 用户授权管理 Access Request
GRC中的工作流节点和流程可以客户化定制，在流程中任意节点都可以加入风险分析的步骤以及对需要添加的角色进行变更，在流程结束后，系统会自动将角色传输到目标系统中并和用户自动匹配。
- 用户方权限收集人登陆GRC提交申请，在申请中说明所要的权限。
- SAP支持人员确认关键用户的申请，并选择相应的角色。
- 关键用户（一般也是SAP小组人员）登陆GRC执行风险分析，如果有风险，则需检查权限授予是否必须（最小授权原则）。如果的确必须，则转入补偿控制流程。如果不是必须，则需修改授权，重新提交；如果没有风险，则直接审批通过。
- 用户方负责人登陆GRC审核。
- 权限已经分配到系统中。
- Basis最终确认执行结果。
- 用户使用和测试，授权流程完成。
