Doug, While much of what you say makes sense, I have to ask what the logic is in preventing people from being on a Change Request and relating other requests to it. It works the other way around, but for example if your Change Request is part of a larger effort (not necessarily a release though) and need to be related to each other, there's no way to accomplish it if both CRQs are pending approval.
Also, there are ways to compromise on these matter. For example, we overlaid and modified the Active Links that prevent you from changing the Scheduled Start Date and Scheduled End Date on a "Scheduled" Status Change Request. We want 99.9% of the people to follow the best practices, but we changed it so that the guy in charge of our CAB can modify the dates in the event that it's needed and he's ok with it. It's rare, and most people are afraid to ask him to change the dates, but it is used probably a couple of times a year. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Friday, November 07, 2014 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Override Change Lock down during approval phase 8.1 ** Chris, As you found, it is an easy customization - and using overlays you can define the change easily and that change is then preserved across upgrades. HOWEVER, I want to make sure that everyone is really aware of what the ramifications are. Planning as gone on and there was a proposal to install version zzz of some program. It was discovered that version zzz has a major security hole that allows unrestricted and global access to all corporate databases. So, that was taken out. Things went out for approval and the security team - who understands the issue here and the vulnerability - checked the change to be sure that version zzz of the program was not being installed. They approved the change request. Now, someone who was on vacation at the time of the planning discussion comes along and sees the change and while looking at it notices that the upgrade to version zzz of the program is not present and they knew it was in the plan. So, they assume it must have been forgotten and add a task to do the work (and it is not prevented as you removed the block). So, the change proceeds and your company ends up on the front page of the Wall Street Journal the next morning with a report of a massive data breach.... No, I am not kidding. This exact scenario is not necessarily going to happen, but there will be errors and flaws and failed changes and exposures of risk. Once you are to the stage of approval, the change should be locked down so that everyone can be doing appropriate due diligence and have confidence that they did the review and don't have to constantly recheck because someone may have changed the plan that they reviewed. Of course everyone just wants to "streamline" and "do the right thing". In my example, that is EXACTLY what the person I describe was doing. They were "streamlining" the process by not asking others and were "doing the right thing" by correcting the error they found that forgot a step of the process. All intentions were pure and true. But, the result was a disaster. Anyway, I wanted to comment on this posting as it provides a terrific example of a packaged solution that includes best practices FOR A REASON. That is what you get an application for. And, at the same time, it shows that small or large or even violating protections and safety protocols, you can adjust the logic easily to match your desires/requirements. AND, that change is often quite easy. AND, the change is clearly recorded and you can see the original and your change at any time (actually anyone with permissions can). AND, your change is preserved across upgrades with new updates coming in from BMC to the area you customized with your customization still applying. The best of both worlds.... In all cases, just be sure that it is clear what the ramifications of each direction so that the right path is taken for your situation. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Danaceau, Chris Sent: Friday, November 07, 2014 9:20 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Override Change Lock down during approval phase 8.1 ** Thanks, all. Was able to track down the workflow involved. As Shawn mentioned, it's really not that much. The lynchpin is the AL "CHG:CRQ:HideBtnForAprvl_120" which keys off the 'Active Approval' field. -- Thank You, Chris Danaceau FINRA 240-386-6728 (desk) 301-367-8949 (cell) Remedy FAQ<http://wiki.finra.org/confluence/display/TechOpsCtr/Remedy+FAQ> From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tommy Morris Sent: Friday, November 07, 2014 11:12 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Override Change Lock down during approval phase 8.1 ** I believe that simply setting the Active Approvals field to NULL will unlock the record. I have unhidden that field on my CRQ view so I can "uncheck it" and then move the status of the change forward. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ken Pritchard Sent: Friday, November 07, 2014 9:13 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Override Change Lock down durring approval phase 8.1 ** My client insisted on it also. What we came up with is that I created a console (sort of like a data management tool) where certain individuals (ie the change managers) could perform the updates indirectly. The console allows for certain changes that the customer said were allowed - it pushes / creates the information for them. I had to do a fair amount of log reading to figure out how to duplicate / allow the updates. I also have an audit logging so that statistics can be gathered on how many changes folks were making. It's up to the POC from the customer to review the changes (they have a report that goes to them) and make sure folks aren't abusing it. Rather than fight the battle of arguing what is meant by 'best practice' I opted to just build this type of interface. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Danaceau, Chris Sent: Friday, November 7, 2014 9:15 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Override Change Lock down durring approval phase 8.1 ** Has anyone done a customization to override this? It's causing a bit of a storm for us as we go through our upgrade and our release teams are insisting they have to be able to add tasks and change other information even during implementation approval. Discussion about best practice are falling on , if not deaf, then unresponsive ears. I'm about to go in and see what's involved from a workflow perspective. -- Thank You, Chris Danaceau FINRA Confidentiality Notice:: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Confidentiality Notice:: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
