We have implemented something similar here as well. We use the Change Type to differentiate between various approval processes, as a "Change" can be used for development work, but every modification to Production (which is also tracked in the Environment field) requires a related "Release". You can set up your approval processes for each Change Type if you'd like, or try to keep just one.
This seems to work ok, although it does cause some confusion when people don't know that the two have different processes, and arbitrarily move the "Change Type" field to a value that is used for a different process. The other downside is that it may make your SOX reporting more difficult because your reports will have to combine the data from the various "Change" type requests that go into a single release. As a result of this, there is a lot of manual effort in providing evidence to the auditors because we have to filter out related Changes that are not SOX relevant (e.g. moving from dev to test environments.) Shawn Pierson From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lisa Westerfield Sent: Wednesday, September 03, 2008 12:26 PM To: [email protected] Subject: Re: Issue with Change Management and Tasks (ITSM 7) ** I had something very similar in my last Change Management implementation, as the client also required tasks such as Proof of Concept to be performed before the change could be approved. The client implemented a process where a change was created to perform the POC, or development environment tasks, because they still had to track those activities even though they were in a development environment. Once that POC was completed, a production change event was created/related to it. This allowed them all of the change functionality in both environments with no detachment of the entire process. I believe the first change record for the development environment was typically a "No Impact" type, requiring no approvals. As far as I know this is still working out for them. Good Luck! From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Chowdhury, Tauf Sent: Wednesday, September 03, 2008 11:39 AM To: [email protected] Subject: Issue with Change Management and Tasks (ITSM 7) ** All, I need some guidance here. The normal change process keeps Tasks in STAGED until the change is approved and in the Scheduled status. At that point, I believe this filter: INT:CHGTMS:CRQ:StatusScheduledActivateTasks Activates the tasks. One of our business groups is the development team. They need to be able to do some development tasks before the change is approved by their manager in the planning in progress stage so that after it is approved, they can then work on the production tasks. The 2 scenarios to accommodate this that I see is: 1. Create a filter that allows the tasks to be fired off at Planning in progress 2. Have them create a change request that requires no approvals for development tasks or use Incident management, and then relate it to the Change that will be used in production. 2 is the easy way out but more work for the user.... Any guidance is much appreciated. Thanks. Tauf Chowdhury | Forest Laboratories, Inc. Sr. Analyst Informatics Office: 631.858.7765 Mobile:646.483.2779 P Please consider the environment before printing this email ________________________________ This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ [http://www.turingsmi.com/images/userworld2008.jpg] <http://www.bmc.com/userworld/> TuringSMI is a Platinum Sponsor of both BMC UserWorld Events Email Disclaimer This email has been sent from the TuringSMI Group This message is subject to and does not create or vary any contractual relationship between TuringSMI, SMI Technologies, SMI Telco, its subsidiaries or affiliates and you. Internet communications are not secure and therefore the TuringSMI Group does not accept any legal responsibility for the contents of this message. Any views or opinions expressed are those of the author. This message is intended for the addressee(s) only and its contents and any attached files are strictly confidential. If you have received it in error, please contact the sender on the number above. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
