Clarity

Expand all | Collapse all

How the Change, Incident and Problem Management is defined in CA PPM ?

  • 1.  How the Change, Incident and Problem Management is defined in CA PPM ?

    Posted 02-05-2019 04:35 PM

    Curious to know the terms(Change, Incident and Problem Management) in terms of Business, used by any client in CA PPM.



  • 2.  Re: How the Change, Incident and Problem Management is defined in CA PPM ?

    Posted 02-14-2019 12:17 PM

    Hi Jaya, I see you are trying to reach out to fellow customers.

     

    Can any customers provide information to Jaya on usage of these functionalities from Clarity in their business?



  • 3.  Re: How the Change, Incident and Problem Management is defined in CA PPM ?

    Posted 02-14-2019 01:06 PM

    Change Requests:  We have some groups using this for document project changes, mainly those involving changes to the project's business case.  We do not use this for product changes, as our products require a much more integrated, traceable solution to our drawings, requirements, specifications, etc.

     

    Incidents:  Not used anymore.  At one time, we used this for users to enter issues they were having with Clarity.  Our IT group started using a different system, thus, this feature's use ended.  I would still like to see it used for this scenario, but with an integration to the IT system.  Also, I can see a use case for our plants to supply requests to our engineering folks.  We have a lot of engineering support going to our plants and this is being tracked in generic 'support' projects - very tough to identify what the engineers are actually working.  For such a significant drainage, would like more detail and Incidents would be a good place to start - with engineers either working directly on them or converting them into tasks on an existing project, or into projects of their own.

     

    Problem (Issue) Management:  We use this for when something breaks (can't meet a project's goals).  Issue page layout follows something called the "8 Discipline Approach to Problem Solving."  When an issue is completed, it is submitted for approval, where a process routes it to necessary parties for review and approval.  Approval results in status change to "Resolved."  Rejection sends status back to "Work in Progress."  "To do" items are not issues.  We also have a couple attributes with pick values, supporting a formula producing a R/Y/G rating of the issue.  Guidelines and procedure describing the use of the issue page and the pick values that one should use in various scenarios are available in the Action menu (put the instructions where they are needed).

     

    Issues are not Risks.

     

    Risks:  Managed in similar form to Issues.  However, if a risk (may happen) becomes an issue (has happened), we create an issue from the risk, close the original risk and then manage the issue to closure.  We also added a hyperlink to the original out of the box hyperlink, so that within a risk and issue, we have linkable traceability between the two.

     

    Dale