cancel
Showing results for 
Search instead for 
Did you mean: 

using UC Correction as a NC correction workflow

0 Kudos

I am trying to set up CHARM and I have found the the Normal Correction workflow is too cumbersome and actually may cause problems in our environment. I would like to use the UC Correction workflow as our maintenance cycle which occurs ever 2 weeks. Corrections that need to be imported into production could be imported as needed and the others could be imported on the 2 week schedule. Can anyone give me an argument as to why this is not a good idea.

Thanks,

Tania

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

The first time you install ChaRM I think there is a tendency to want everything to be ur.gent for flexibility. I would personally fight the urge to do this and also push back on the others that will try to coerce you into doing so. The normal correction brings structure to your changes and allows for proper testing. If you're throwing things in daily for non break/fix issues, I doubt you're testing everything properly before promoting it to production. It's not a best practice for sure, and I would question why you're using ChaRM at all.

Former Member
0 Kudos
The first time you install ChaRM I think there is a tendency to want everything to be ur.gent for flexibility. I would personally fight the urge to do this and also push back on the others that will try to coerce you into doing so.

Brilliant Point, something I came back to post in this thread, almost everything has to move quickly to prod as per most requirements, but moving into ChaRM's direction is not about just getting a new tool to handle your transports, but rather changing your approach to transports altogether. You need to convince your business stake holders to adapt to the mentality of moving to the release based approach of handling SAP ie become proactive and not reactive in terms of change management.

The normal correction brings structure to your changes and allows for proper testing. If you're throwing things in daily for non break/fix issues, I doubt you're testing everything properly before promoting it to production. It's not a best practice for sure, and *I would question why you're using ChaRM at all.*

You can establish multiple transaction types based on what needs to be delivered, but you must at all times adhere to the concept of having 2 primary types of changes, a normal one which works on the release concept, and an urgent one.

If everything moves urgent, eventually an auditor or someone like me will take issue with it.

Just my thoughts

Cheers!

Former Member
0 Kudos

If SDMJ is really that complicated for you, and just to avoid the clutter of so many tasklists/Maintenance Cycles whilst using SDHF , how about using SDMI? or is that too bad a thought?

I faced a similar situation, but I think just tweaking NC to eliminate certain steps may possibly be a better idea.

Just my thought!

Cheers!

Former Member
0 Kudos

Hello Tania,

I implemented ChaRM in the same way you are suggesting, with only UC because the WF for normal corrections was too complex; we customized the values "normal correction" and "ur.gent correction" in the field "catogory", so that we use this field to identify which UC is actually a UC and which is a NC.

Just remember to assign the variant SAP0 to your project task list, see item 14: /people/dolores.correa/blog/2009/07/22/change-request-management-scenario-usual-questions-and-known-errors

Hope that help you!

Best regards.

Federico.