By SteveW-Oracle on Jul 01, 2015
Support Identifier Groups are a way to manage and organize hardware and software assets in the My Oracle Support (MOS) application. While many customers are already utilizing this feature, Oracle Portal Services has noticed there are still large swaths of customers who have not set up any SI groups, or who have set up SI groups but haven't added any assets to the groups to activate them.
We've put together some quick examples to help Customer User Administrators, or CUAs, set up their Oracle support assets more functionally and logically.
Benefits of Support Identifier Groups (SIGs)
If you're new to My Oracle Support, an SI is an automatically-generated record "tag" that links purchased Oracle hardware or software to support resources.
Large organizations might have dozens (or possibly hundreds) of SIs scattered across multiple lines of business and geographic areas. In order for a user to receive support on Oracle products—say a database admin or HR manager—they must be assigned to an active SI. An SI is "active" as long is it has 1) an asset assigned to it and 2) hasn't expired.
So how are SI groups different from a standard SI? From a functional standpoint they're identical; the difference is an SI "group" is one generated by a CUA, rather than one generated automatically by Oracle. Normally assets and users get assigned to whatever support identifier they happen to land in when a purchase is made. This can make it hard to keep track of where assets and assigned users reside—functionally, geographically, based on role, and so on.
By creating their own SI groups, CUAs can organize assets and users as they see fit.
To make the most of Support Identifier Groups, you will need to pre-plan how users and assets are best organized. Once defined you can set up your Groups, adding users and assets logically the way you need them.
In this scenario a group of CUAs might want to reorganize their current SIs to reflect specific projects or lines of business.
Keep in mind that assets can reside in more than one SI at a time. The idea behind this scenario is to group assets according to specific projects or operations. An asset might be used for more than one project at a time; the goal is to organize them to make it easier to track.
In this scenario, the CUAs have a batch of SIs with assets assigned and scattered all over the place. They want to move the assets from their current SIs, and organize them into new SI groups consolidated by location.
Location-based operations are obviously good candidates; grouping by location makes it easy to chart how and where assets are being used.
Consolidating SIs can also be useful if you have assets that are used exclusively by one group with little or no crossover between lines of business.
Note that when you choose to remove all active assets from a current SI, that SI gets deactivated automatically. Any users assigned to a deactivated SI would need to be moved to one of the new SI groupings.
This scenario is similar to the previous consolidation scenario; the main difference is that one of the new SI groups is set up as a default for all future purchases going forward.
Note that all new hardware or software assets are automatically be assigned to the default going forward.
This scenario is useful when you have a specific set of assets and users that are logically segregated from other operations, and you want to keep them separate. Often this might include assets used for specific operations, while the "default" group is for the primary workflow.
When planned and managed properly, SI groups can help reduce time spent managing Oracle assets. Visit Document 1569482.2 for more information.