Skip to Content

using UC Correction as a NC correction workflow

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

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Jul 15, 2011 at 11:26 PM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jul 17, 2011 at 04:15 AM

    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!

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jul 18, 2011 at 02:44 PM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member
      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!

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.