Who has SAP access,and who approved it.
How a medical devices manufacturer put SAP user-rights requests and change requests on one help desk - a standard form instead of an email, approval through the Head of Department and IT, and a change tested before it reaches the live system.
The situation
Two requests dominate the life of an SAP team, and neither has an obvious home. The first is access: someone joins, moves department, or needs a transaction they do not currently hold. The second is change: a report needs another field, a process needs a different rule. Both tend to arrive as an email, a phone call, or a word in a corridor.
Handled that way, neither leaves a record. Nobody can say afterwards who approved a set of rights, or on what basis. A change reaches the live system without a documented test behind it. And because there is no queue, the IT team cannot show what it is carrying - so the work stays invisible until something breaks.
Nobody can say afterwards who approved a set of rights, or on what basis.
What we built
We built a help desk carrying both workflows. A requester fills in a standard form - one for SAP login and user-rights access, another for a change request - so every submission arrives with the same information rather than whatever the requester thought to mention. From there it routes through a multi-level approval involving the Head of Department and the IT team, and each stage is recorded against the person who acted on it.
Reviewers are not limited to approving or rejecting. They can add a comment or ask the requester for clarification, and the requester is notified as the status moves, so nobody has to chase. Change requests carry the step that matters most: a testing stage between approval and go-live, so a change is proven before it is applied rather than applied and hoped for. Where the request touches SAP itself, the application integrates with the systems already in place.
Inside the help desk
Two request types, one governed path.
SAP right assignment
- Standard form for SAP login and user-rights requests
- Authorisation captured alongside the rights being granted
- Multi-level approval through the Head of Department and IT
- Documentation retained against every assignment
- Requester notified as the status moves
SAP change request
- Standard form covering the submission of a change
- Approval routed before any work begins
- Testing stage completed before go-live
- Implementation recorded once the change is applied
- Comments and clarifications held against the request itself
What changed
Outcomes as reported by the client. We have not attached percentages to them, because the ones worth quoting are the ones the client measured themselves.
Access became a decision with a name on it
Every set of rights granted carries the request that asked for it, the Head of Department who approved it, and the IT action that applied it. What used to be a corridor conversation is now a record somebody can produce.
Changes are tested before they are live
A change request cannot jump to implementation - the testing stage sits between approval and go-live. That ordering is the whole difference between a change that was vetted and one that was merely wanted.
The IT queue became visible
Requests sit in one place with a status against each. The team can see what it is carrying, and a requester can see where their own request has reached without having to ask.
Other systems we have built near this one
Pharma & Life SciencesEcommerce GST reconciliation, from eight days to a few minutesRead the case study>
Pharma & Life SciencesA Kaizen system tracking employee ideas from submission to rewardRead the case study>
Pharma & Life SciencesCertificates of Analysis, from Excel to a controlled workflowRead the case study>How does someone get access to your core system?
SAP rights, ERP roles, database permissions, admin accounts - the request is small and the cost of getting it wrong is not. Tell us how yours works today and we will tell you honestly whether it needs a workflow or just a better form.