1) General Mills implemented a SAP workflow application to automate and streamline their SOx-compliant user maintenance process by integrating role-based security, separation of duties checks, and approval workflows. 2) The new system replaced an email-based process and provided real-time security role assignment tracking and conflict prevention to help meet SOx compliance requirements. 3) Benefits of the new system included over 16 hours per week of productivity gains and improved integration for auditing and future applications.

1. A General Mills Workflow Application: Automated, SOx-Compliant User Maintenance Bijay Shrestha / Luis Martins Nov. 7–10, 2004

2. Learning Objectives Use of Workflow for SAP User maintenance with real-time Sarbanes-Oxley compliance Business learning Technical learning

3. About General Mills, Inc. Headquarters in Minneapolis, MN 27,000 employees World’s 7 th largest food company $12.3 billion in FY04 net sales Marketed in more than 100 countries

4. Some of our best known brands

5. SAP at General Mills Implemented R/2 in 1992 R/3 Go-Live: Nov 2000 for HR and BW Apr 2001 for ER Current modules: ERP, HR, BW, PLM, SEM-BPS, APO, CFM, Enterprise Portals, CRM (in progress)

6. SAP landscape at General Mills

7. Sarbanes-Oxley Act – Section 404 Section 404 requires annually: Management (CEO/CFO) responsible for internal controls over financial reporting Management identifies control framework employed Management makes assertion regarding effectiveness of internal controls over financial reporting External auditor attestation of that assertion, as of year-end (separate from financial statement audit)

8. Key Business drivers/challenges Decentralized administration of SAP Security Different levels of data sensitivity across functions Different role approvers within business functions Multiple levels of approval Email-based request and approval system Complex tracking of user role assignments Complex trail for system audits No real-time prevention of conflicting role assignments

9. Old Form (Word doc)

10. Key solution components Users Local Security Administrators (LSA) Role Owners Assertion Coordinators/SOD Approvers IS Security Request types CREATE (May trigger workflow) UPDATE (May trigger workflow) DELETE (Sends email to IS Security) DISABLE (Sends email to user) User Group management and CUA User maintenance by location Assertion Coordinators/SOD Approvers by location CUA - central distribution of role assignments and key for future web integration Job Roles (no connection to HR Jobs)

11. Technical details of Workflow Source code maintained in one system 14 tables 1 custom Business Object 1 extended Business Object Table driven dynamic role resolution HTML formatted Emails Currently used in the ER SAP system (rolling out to BW)

12. Some numbers 7000+ users 120+ Local Security Administrators 1100+ security roles 900+ requests per month (in ER system) 30 Role Approvers 26 Assertion Coordinators

13. Benefits/ROI of Workflow Automation 16+ hours a week saved in productivity for full-time central administrators incl. Role owners & Local Security Administrators System-based tracking mechanism Integration with Separation of Duties (SOD) engine from Virsa Systems Identify and fix SOD conflicts while maintaining users vs. fix after the fact Backbone for other applications such as Accounts Payable approval process Better integration / platform for future automation

14. Demo (custom ZAUTH transaction) Integration with Central User Administration (CUA) Key request types Screen examples

15. Integration with CUA Role assignments are triggered in the CUA child/component systems and committed in the central system via standard SU01 BAPIs/function modules. CALL FUNCTION 'BAPI_USER_CREATE1‘ DESTINATION V_CONNDEST… … CALL FUNCTION 'BAPI_USER_LOCACTGROUPS_ASSIGN' DESTINATION V_CONNDEST…

16. Request type CREATE Proposed role assignments What-if analysis for proposed role assignments Job Roles automatically enter the corresponding security roles in the request.

17. Job Role selection Each job role is composed of two or more security roles. Requestors do not need to know the PFCG role name when setting up user access.

18. Request type UPDATE Current role assignments CANCELLED or REJECTED requests can be copied and re-submitted after correction. Requests can have a NORMAL or CRITICAL priority

19. Real-time detection of SOD conflicts Real-time alert regarding SOD conflicts caused by proposed role assignments.

20. SOD conflicts in submitted request Requestor can SUBMIT or CANCEL the request.

21. SOD conflicts at authorization object level

22. Confirmation for email & workflow routing Confirmation triggers Outlook email and work item to higher level approvers.

23. Email to Role Owner/Approver List of security roles that require approval from Role Owner(s).

24. Approver’s inbox in Universal Work List (UWL) Pending requests from multiple SAP systems.

25. Approver’s inbox in Business Workplace (SBWP) Execution of work item opens screen with security request data.

26. APPROVED request – Role Owner Request in APPROVED status with pending SOD conflicts triggers Outlook email and work item to higher level approver – Assertion Coordinator.

27. Email to Assertion Coordinator (SOD Approver) List of SOD conflicts that require approval from Business Assertion Coordinator/SOD Approver.

28. SOD Approval – Assertion Coordinator Request can be APPROVED or REJECTED.

29. COMPLETED request – Assertion Coordinator Confirmation of completed request.

30. Confirmation email to initiator ( COMPLETED )

31. Request type DELETE Requestor must provide reason for deleting a user ID.

32. Substitution rule in request type DELETE Substitution user ID required for users with pending work items.

33. Reporting & system-based tracking/auditing Requests can be tracked using several search criteria.

34. Reporting & system-based tracking/auditing (cont.)

35. Project timeline & resources 3 ABAP developers (inc. 1 Technical Consultant) 1 Workflow developer 1 IS Security Analyst Phase 1 – from June 2003 to November 2003 Phase 2 (SOD project) – July 2004 to October 2004

36. Key lessons Start with prototype system Get input from end-users before and after major milestones Communicate frequently about enhancements and technical limitations Plan for future integration Be generous with time allocated for testing

37. 312 Session Code: