How to model SAP transactions in CSDM 5.0 for proper assignment routing?

[klausschmid]

In SAP, we have thousands of transactions—some out-of-the-box and some custom (Z-transactions). We treat “bundles of transactions” as a kind of “virtual application,” to which we assign a support group.

In ServiceNow CSDM, I’m struggling to find the right level of abstraction for representing these transactions. From an end-user perspective, someone might report an issue with a specific transaction (e.g., ME21N). The User or Service Desk agent should be able to enter this transaction, and based on that information, the system should route the incident to the correct assignment group.

The challenge: the same transaction can belong to multiple “virtual applications.” For example:

• VirtualApp1: Order processing for purchased parts/services
  Transactions: CV02N, ME2xN, ME25, ME2x, ME80, ML8xN, etc.
• VirtualApp2: Internal Transfer Process
  Transactions: ME2XN, VL06I, VL10B, ZERM59, and many Z-transactions.

Question: What is the correct way to model this in CSDM 5.0? Should transactions be represented as Configuration Items (CIs) - which class?, Service Instances, or something else? How do we handle routing when a transaction is used in multiple contexts?

in the CSDM Model examples I only find a very common perspective instance-driven, but not really practical for SAP ERP/ECC use cases.

Thanks in advance for any shared experience!

[Mathew Hillyard]

Hi @klausschmid 

That’s an interesting question. These are not genuine apps but groups of transactions, so I don’t see these as being separate business applications. The fact that a transaction can belong to more than one group rules this out. To me they most closely align with technology management service offerings. But the key question will be whether each transaction belong to an individual service instance, or a common service instance. The answer is whether these transactions are supported by separate CIs; if not then a common service instance would work. I’d see such requests as coming from technology consumers, hence choosing technology service management instead of business service offerings.

The only final question is then how to represent the individual transactions. I would set this in the offering description and have this field visible when searching for offerings on the pop up list layout and the reference view. Don’t add it to the offering name as this will make the offering name too long and will likely be truncated.

Of course, you could model this other ways but the above aligns most closely to the function of each object in CSDM in my view.

I hope this helps!
Mat

[klausschmid]

hi @Mathew Hillyard 

Thanks for your feedback! Yesterday, we discussed two options:

1. Create a dedicated CI class, then create a CI for each transaction and relate it to the offering. We could get the transactions from a SAP table — however, there are 2.5 million entries, and only a few hundred are actually used. So, it is a bit of a challenge to import only the used transactions and make it meaningful for agents, so it can be used in incidents, etc., in combination with offering/service/portfolio.
2. "Tag" the offering with the transaction codes. Then you can use the standard filter with the tag column to identify the relevant "offerings" (or apps). Unfortunately, a single "virtual app" could have up to 150-200 tags, with most having between 20 and 40. From a UX/UI perspective, we need to verify if this is usable — at least it would be very lightweight. Another drawback is that anyone who can edit offerings can, by default, remove individual tags.

If you have any other ideas, I would appreciate your input!

[Mathew Hillyard]

Hi @klausschmid 

I agree, a dedicated CI class seems to be overkill as the only purpose is to identify the relevant transactions.

So long as you can easily search which tags are related to the offering and all you need is the transaction name, then option 2 might work. I do wonder how easy tags would be to manage with the volume of transactions, however.

Another option is to create a separate table that extends the data lookup matcher rules table (which makes the table free!) that you could add as a related list to the Service Offering, make it hidden if empty so it doesn't appear for non-SAP offerings, and model the data there. This would require more work and is less OOTB but would provide the advantages of being able to be centrally managed by end users, could be secured with access control, and could show more data per transaction if required (such as a description).

UI/UX is of course very important with any solution - but I suspect given the volume of transaction data it might need some agent training regardless of the solution.

Do let us know how you get on!

KR
Mat