Segregation of Duties on

Order to Cash and Procure to Pay

Richard Symes, Scapa

November 2011

Agenda

• Scapa

• What we wanted to achieve

• What we did

• Results

Please be aware that several extra slides included in this file are ‘hidden’ from the slide show.

If any hidden slides lead you to need explanation then email me at richard.symes@scapa.com

November 2011 3

Types of questions

• A good question is one that I do not have the answer to

• A very good question is one that I do have the answer to

• An excellent question is one where I have a slide coming that answers it

November 2011 4

Your presenter

• Twenty years of operations management roles and change agent roles

• Ten years on Scapa’s SAP team with a focus on supply chain management improvement

• Picked up the SAP security role in the first SAP implementation and owned the area ever since

• Currently Scapa’s “SAP competence manager” one of a SAP global core team of six people

5 November 2011

Scapa Group

Who we are • Scapa is a leading worldwide manufacturer of bonding

solutions and adhesive components for applications in the Medical, Electronics, Industrial and Transportation markets

What we do • We help customers create better products by providing

adhesive solutions and components. We design our offering around the requirements of global OEMs, distributors and consumers

Facts & Figures • Founded as Scapa Dryers Ltd in 1927 • Headquarters in Manchester, UK, with sales and manufacturing

facilities throughout Europe, Asia and North America • Approximately 1,300 employees worldwide • Annual turnover (year ending 31 March 2011) of £192.3m

November 2011 6

Core markets

November 2011 7

Medical

Electronics Transportation

Industrial

High performance products

Scapa’s unrivalled product portfolio allows customers to work with a core supplier

• who can support their whole range of bonding solutions. Some of our technical

• solutions are below.

November 2011 8

AFT = acrylic foam tape, AFFT = acrylic foam film tape, EMI = electromagnetic interference EMC = electromagnetic conductivity

Scapa’s locations

9

USA on SAP everywhere

since April 2009

Europe on SAP everywhere

since April 2002

Asia not on SAP anywhere

November 2011

Scapa’s SAP system

• We have one SAP system on one set of servers

• We have implemented the FI, CO, MM, PP, QM, SD & WM modules and xMII

• We have uniform business processes globally, except for any fiscal reasons (e.g. France, Italy)

• We have kept our custom code to a minimum

• We run ECC 6.0 and have about 680 ERP users

November 2011 10

SAP security history

• Since day one in 2000 all the roles generated in the ERP system are custom Z prefix ones

… bar one role since 2008 named SAP_J2EE_ADMIN used with Manufacturing Integration & Intelligence (xMII)

• Since 2008 master and derived roles in use

• Since 2010 central user administration in use

• Since June 2010 ProfileTailor™ Dynamics in use

November 2011 11

SAP security management

• Our underlying philosophy is restrict access where you ought to but otherwise liberate users to take advantage of the power of the information system

• No user’s access is changed without their manager’s approval

• No human user on Scapa’s system has SAP_ALL anywhere except in the sandpit client

• Scapa users who change access in user accounts cannot change access in their own user account

November 2011 12

Agenda

• Scapa

• What we wanted to achieve

• What we did

• Results

November 2011 13

What we wanted to do was:

• Reduce the risk of fraud

• Remove persistent annual negative external audit findings

• Confront issues relating to segregation of duties, that we had put off addressing for years

• Invest in a SAP security monitoring & controls system … at an affordable price

November 2011 14

Agenda

• Scapa

• What we wanted to achieve

• What we did

• Results

November 2011 15

Implementation process

November 2011 16

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Not a SAP security team responsibility

Implementation process

November 2011 17

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Procure to Pay SoD requirement

Activity 1 Activity 2 Risk associated with conflict

Vendor Maintenance

Post Invoice Create fictitious vendor and post fictitious invoice for payment

Purchase Order Entry & Maintenance

Goods Receipt Release for payment without having received goods

Goods Receipt Post Invoice Release for payment without having received goods

Vendor Maintenance

AP Payment Processing

User might create fictitious mandate details paying away monies

November 2011 18

Combinations of activities

November 2011 19

Order to Cash SoD requirement

Activity 1 Activity 2 Risk associated with conflict Customer Maintenance – Credit Limits

Process Sales Order

User can increase credit limits and process sales order beyond insured limit.

Customer Maintenance – Payment Terms

Process Sales Order

Unauthorised changes to payment terms, impacting cash position

Sales Order Maintenance – Payment Terms

Process Sales Order

Unauthorised changes to payment terms, impacting cash position … limit to Credit Control

Sales Order Release on Credit Hold

Process Sales Order

User can bypass credit control checks … limit to Credit Control

Process Sales Order Despatch Goods

User can create sales orders to hide misappropriation.

Process Sales Order Sales Price Maintenance

User can inflate or reduce prices to set against sales orders

Despatch Goods Credit Note Processing

User can create/change delivery and create/change a credit note to hide the misappropriation of goods

Customer Master Maintenance

Credit Note Processing

Set up of a fictitious customer with credits issued against the account

November 2011 20

Order to Cash

• Maintain customer credit limits: – T-code FD32 Change

customer credit management

– T-code FD37 Credit management mass change

• Release credit held orders: – T-codes VKM1, VKM2, VKM3,

VKM4, VKM5 and object V_KNKK_FRE field ACTVT value 23

Procure to Pay

• Create / change purchase orders: – T-code ME21 Create PO

– T-code ME21N Create PO

– T-code ME22 Change PO

– T-code ME22N Change PO

• Book goods in on PO: – T-code MIGO with object

M_MSEG_BWE field BWART value 101 and field ACTVT value 01

Rule set examples

November 2011 21

Authorisation detail on SAP

November 2011 22

Other roles don’t have the 101, 102 movement type access in the object M_MSEG_BWE

Activity group content

November 2011 23

Combinations of activities detail

If you want the details of the all transactions and authorisations used at Scapa in Segregation of Duties then email richard.symes@scapa.com and I will send you back an Excel file with all of them included.

November 2011 24

Implementation process

November 2011 25

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

SoD analysis

• Show me all roles that contain an SoD violation

• Show me all users that have a combination of roles that cause an SoD violation

• Show me all users that have actually performed activities that are of violation of SoD rules

• Simulate adding a role to a user to check if it will cause a violation of SoD rules

• Simulate adding activities to a role to check if it will cause a violation of SoD rules

November 2011 26

Violations of single combination

November 2011 27

Activity monitoring

When a user is given SAP_ALL you can see what they have run when they had it November 2011 28

Activities to users (real use)

November 2011 29

Activities to users (real use)

November 2011 30

Activities to users (real use)

November 2011 31

Every transaction

run

You can see who uses SAP the most You can see who has never run a transaction You can use the matrix to drive user training

Activities to users (real use)

Every user

November 2011 32

Security analysis examples

• Show me a user’s capabilities (via roles, profiles) versus a user’s actual activity

• Who can perform transaction xxxx?

• Who has performed transaction xxxx?

• Show me an audit trail of system usage and transactions performed by user xxxx

• Show me an audit trail of all usage of transaction xxxx

• Show me unused or rarely used roles or transactions

November 2011 33

User profile, activities

November 2011 34

User profile, role usage

November 2011 35

Transaction use in a role by a user

November 2011 36

First

Etc.

Implementation process

November 2011 37

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Iteratively reduce SoD violations

November 2011 38

The easy stuff is the hard stuff

The hard stuff is the soft stuff

SoD role changes

• Changes to existing roles

– Removal of transactions or authorisations that you wish to segregate from all of the roles that they do not need to be within

• Creation of new roles

– Assignment of transactions or authorisations that you wish to segregate to unique roles … if you do not have this role you cannot perform this duty

November 2011 39

Other Order to Cash answers

• We prevented Customer Care users changing payment terms in sales orders by a customised security object Z_ZTERM and some ABAP code in the sales order user exit MV45AFZZ (we did this in 2006)

• We prevented any users bar Credit Control changing payment terms in customer masters we used the same security object Z_ZTERM to stop use of t-code XD02 and require use of both t-codes VD02 & FD02 to change payment terms and limited t-code FD02 access to Credit Control

November 2011 40

Other Order to Cash answers

• We did not need to segregate duties on credit note processing on SAP as we have an intranet credit note system with workflow for credit note authorisations and every credit note on the intranet is reconciled to SAP

• We initially wanted to segregate duties on sales order maintenance and sales price maintenance but Commercial were unprepared to make the necessary organisation structure change to do this for reasons of cost/efficiency

• One site asked for a way stop users being able to both create a sales order and despatch goods against the sales order on their user name; this bit of ABAP programming was possible with the user exit SAPMM07M_009

November 2011 42

Implementation process

November 2011 43

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Removing SAP access from users

November 2011 44

Remove SAP access from the users who never use one half of a SoD conflict

Prepare the SAP user accounts of users who do use both halves of a SoD conflict so that it is easy to remove one half

Give the users who are going to lose access notice of when access will be removed if they do not appeal

User appeals?

Appeal upheld?

Users lose SAP access

No

No

Yes Users keep SAP access

Yes

Start

End End

Implementation process

November 2011 46

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

ProfileTailor™ Dynamics Dashboard

•User xxxx has performed high risk activity yyyy

•User xxxx has performed direct table access (SE16, not SE16N)

•User xxxx has been assigned a high risk profile

•User xxxx has been assigned a high risk SoD combination

•User xxxx ran a high risk SoD combination in past N days

November 2011 47

Scheduled reports

November 2011 49

Granting authorisation simulation

November 2011 51

Implementation process

November 2011 53

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Audit the rule set

PwC told us that we had missed:

• Procure to Pay:

– T-code MASS allows a user to change purchase orders

– 32 Finance module T-codes allowing manual posting of an accounting document in the Accounts Payable ledger

• Order to Cash:

– T-code MASS allows a user to change customer masters

– T-codes MM01 and MM02 allow sales prices to be set via material masters (but only applies if a user has the authorisation objects that t-codes VK11 and VK12 need)

November 2011 54

Agenda

• Scapa

• What we wanted to achieve

• What we did

• Results

November 2011 55

Procure to Pay events in 2010

• April

• 15-16th June

• July

• August

• September

• October

• 17th November

• Listed the conflicts

• Installed ProfileTailor Dynamics

• Began collecting users’ SAP behaviours

• Got roles ready for user access changes

• Removal of access communications

• Some job re-organisation happened

• All conflicts enforced, bar on one user … who was the only user at one location!

November 2011 56

Procure to Pay events in 2011

• July

• August

• September

• September

• September

• September

• October

• Given PwC’s findings on Scapa SAP rule set

• Added to the rule set 30+ new transactions

• Removed some static access

• Asked Risk manager about 19 new SoD users

• 7 non-Finance users’ SoD access approved

• 12 Finance users still left with a SoD conflict

• 12 Finance users’ SoD access approved

November 2011 58

Procure to Pay SoD outcome

Activity 1 Activity 2 Result

Vendor Maintenance Post Invoice Purchase Order Entry & Maintenance Goods Receipt Goods Receipt Post Invoice Vendor Maintenance AP Payment Processing

November 2011 60

Order to Cash SoD outcome

Activity 1 Activity 2 Result

Customer Maintenance – Credit Limits Process Sales Order Customer Maintenance – Payment Terms Process Sales Order by Z_ZTERM

Sales Order Maintenance – Payment Terms Process Sales Order by Z_ZTERM

Sales Order Release on Credit Hold Process Sales Order

Process Sales Order Despatch Goods 90% done;

Canada user exit

Process Sales Order Sales Price Maintenance needs too big

a re-organisation

Despatch Goods Credit Note Processing intranet

Customer Master Maintenance Credit Note Processing intranet

November 2011 61

Record to Report events in 2011

November 2011 62

Define the SoD requirement

Write SAP rule set

Configure SoD as active in PTD

Look at dynamic and static picture in PTD

Deal with roles containing two sides

of a SoD conflict

Compose a SAP role re-design

Create new roles with limited transactions that are half a SoD

Give new roles to users running the transactions,

but not to users who are not running them

Take SoD transactions out of old roles

and test SoD will work

Propose who should lose what access

and give them notice

Audit the rule set

Accept or reject any appeals

Remove access

Approve SoD retention in PTD

Continuously monitor in PTD

Questions?

November 2011 63