Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

production access for functional consultants

Former Member
0 Kudos

as usual we have a discussion with our functional consultants about production access.

I stat the should only have display access in the own functional area the claim to need executional access for most of transactions in their own area,

what is you view on this and also what is best practice. to avoid al lot of war.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

I'm with Steve on this - display access for day to day work and some sort of SUPM type tool for emergencies and ad hoc requirements.

One of the advantages of this is that if the temporary Super User auths need to be approved by someone in the business, it gives them a good overview of just how many and what type of non-standard events are occurring in their system.

I had a recent client where the functional consultants had update auths in PRD from day one, and they were using them on a daily basis but the wider business had no idea just how frequently this happened because there was no SUPM / approval process involved. And of course, trying to restrict them to display authorizations was met with fierce resistance, because they knew that it would expose just how many things they were fixing "on the fly".

Lock 'em down nice and tight

7 REPLIES 7

Former Member
0 Kudos

It is not uncommon to see large migrations of techno-functional IT consultants crossing the boarder into the business departments as key users...

Cheers,

Julius

Former Member
0 Kudos

Hi Auke,

Can you be a bit more clear as to what additional access the functional consultants are requesting for and the need for it?

Nagarajan

alejandro_mejias
Active Participant
0 Kudos

Probably you are the responsible of the system operations (ensure the system is up and running, data consintency, backup, access, etc...).

However you have to find the answer to this question: "Who is the responsible in your organisation of the data?"... This will give you the answer about access to production. Think in the "data" of your organization as part of the core of the business. Assume you don't have a system at all, and somebody from an external company needs accesing to some financial document, or some production recipe. Who should this external people contact with in order to get this information?

So think in functional consultants in the same way as external people. If you want access to data in the organization, request a way to get it to the responsible of the information.

Former Member
0 Kudos

There are times when update access is legitimately required in production. Those times are rare, in my experience, in a stable system. In such a scenario, internal SAP support staff and consultants should only have read-only access as a general rule, with update access being given on a case-by-case basis and for a limited time only. Even better, implement Superuser Privilege Management (aka Firefighter) from the GRC suite and use that for all update access for support staff. That gives good control, and more importantly, an audit trail.

When new functionality is being rolled out, things are different. It is reasonable for consultants to have update access for the first few days of a go-live, to be able to sort out issues quickly. Although if you have SPM implemented you can use that even here and still not have regular users with update access.

Steve.

Former Member
0 Kudos

I'm with Steve on this - display access for day to day work and some sort of SUPM type tool for emergencies and ad hoc requirements.

One of the advantages of this is that if the temporary Super User auths need to be approved by someone in the business, it gives them a good overview of just how many and what type of non-standard events are occurring in their system.

I had a recent client where the functional consultants had update auths in PRD from day one, and they were using them on a daily basis but the wider business had no idea just how frequently this happened because there was no SUPM / approval process involved. And of course, trying to restrict them to display authorizations was met with fierce resistance, because they knew that it would expose just how many things they were fixing "on the fly".

Lock 'em down nice and tight

Former Member
0 Kudos

Auke,

I agree with Will and Steve. Just wanted to inform you that if you don't have the GRC suite to implement Firefighter, it is also possible to create your own similar solution by the ABAP development team.

And maybe your functional consultants are aslo part of a helpdesk team and you work with a helpdesk solution that makes it possible to view the screens of other people? In that case the functional team members can have a look at the users that are in need of help to see what is going wrong.

For authorizations restrictions they will only need display authorizations in production for their module, and update authorizations that are corresponding to their function. In case of emergencies they can have temporary broader authorizations via the firefighter solution. The firefighter use is monitored and approved by management.

0 Kudos

Hi

Would it be practical to set their user IDs up in SM19 if so?

Kind regards

David