Diesen Beitrag gibt es auch auf Deutsch.
SUMMARY: Clusters, which allowed large companies’ super-administrators to group customer numbers and installation numbers and then assign S-users authorizations on this level, are being phased out. All customers are encouraged to use the new Authorization Packages feature instead, which is more powerful and benefits companies of all sizes. To avoid data inconsistencies, S-users who in the past got authorizations assigned on cluster level should get these permissions amended.
Over the past few years, since its general availability in February 2016, the SAP ONE Support Launchpad and its applications have replaced traditional SAP support tools with modern alternatives. Right from the start, the focus of the launchpad development was not on copying existing functionality, but on questioning technical processes and adapting them wherever it makes sense.
Now, SAP Support is about to retire one of the few remaining legacy applications on the service.sap.com (SAP Service Marketplace) infrastructure, Cluster Maintenance. The feature replacing it, Authorization Packages, has been developed in close collaboration with our customers. It enables you to accomplish user management-related tasks with increased ease and efficiency.
However, the underlying concept is different from clusters, hence some groundwork needs to be completed.
What is a cluster?
Authorization management for your company’s S-user IDs deals with permissions (“authorization objects”) that are required to fulfill certain support-related tasks, for instance report incidents.
Most authorizations can be limited to selected installations, customer numbers or other so-called “authorization levels” at which the user can exercise this right.
Example: A user may be allowed to report incidents for one particular SAP product that your company has licensed (represented by an installation), but not for others.
The Cluster Maintenance feature allows you to group certain customer numbers, installation numbers, CCoE numbers and/or individual user IDs: you define “clusters”, your very own authorization levels. Subsequently, authorizations (like Report an Incident) can be granted to users on these clusters. The feature is mainly intended for customers with many installations and customer numbers.
And authorization packages?
Well, clusters are neither fish nor fowl: They only cover one aspect of granting authorizations, the level, but completely ignore permissions for the task. Authorization packages eliminate this functional shortcoming: User administrators can define a very specific authorization profile and reuse this “branding iron” over and over again. For instance, you can bundle some incident management-related authorizations like Report an Incident and Close Incidents for one of your subsidiaries – that’s a customer number – in a package Demo Company Argentina Helpdesk. If a new colleague joins the Argentinian IT team, simply apply this package to his user ID, thus adjusting his profile with one click.
Transition from clusters to authorization packages
By now you will have a better understanding of the two similar, but still different concepts. Unfortunately, there is no way to migrate clusters to authorization packages. Therefore, some manual work is required.
Step 1: Draft a blueprint for your S-user authorizations.
Are there colleagues in your company that share a huge part of their authorization profiles? If yes, using authorization packages will simplify user administration. You should then proceed to …
Step 2: Define authorization packages and apply them to these users.
Step 3: Identify users with permissions on cluster level and correct their profile.
You know these colleagues? Great, then please go ahead and delete all authorizations that had been granted on cluster level. If not, from around mid-May 2018, SAP Support will be able to assist: You can then report an incident under component XX-SER-SAPSMP-USR, and SAP will share a list of these user IDs with you.
A word of caution: You might be tempted to skip this clean-up step. But once the Cluster Maintenance application gets retired, these users will have “zombie” authorizations on some bizarre bundles of installation and customer numbers, which cannot be maintained anymore. Almost inevitably, data inconsistencies will be the result.
Step 4 (optional): Delete obsolete clusters.
Once a cluster is not assigned to any user, super-administrators can delete it using the Cluster Maintenance legacy application: From the list of all clusters, select the one you want to get rid of, enter the Edit mode, and click the Delete button.
So, what’s next?
With our Wave 4/2018 release for support applications, due to be delivered on May 26th, creating new clusters and changing existing ones will be disabled. But it goes without saying that you should stop creating and using clusters straightaway; the new authorization packages feature is powerful and mature enough to replace clusters. Every new cluster that you create between now and May 26 will cause unnecessary work.
Approximately six months later, on November 17th (our Wave 8/2018 release date), the Cluster Maintenance application shall be retired.
Piloting Program SAP ONE Support Launchpad
We invite interested customers and partners to a special piloting program for the SAP ONE Support Launchpad. In this program, we offer roll-out and feedback sessions. We present new functionality that has become available since the previous release; give an outlook and insight on what we are currently working on; and collect and discuss feedback and ideas with participants. Sessions are held every 6-8 weeks. All interested parties can participate without obligations. The only prerequisite is a valid Feedback Agreement with SAP.
In case you would like to be involved and invited to future sessions, simply send an e-mail to my colleague Arno Helmling containing your name, S-user ID, e-mail address, and the name of your company.