Here's another complication. When implementation approvals are added to a change in Planning in Progress, which are "Future" approvals by definition, they are immediately available in Approval Central, even when they are not visible on the Change Request itself as Pending approvals. It seems to us that undermines the existing process if one can approve a Change before it is progressed to the appropriate phase.
-- 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:[email protected]] On Behalf Of Ken Pritchard Sent: Friday, November 07, 2014 8:56 PM To: [email protected] Subject: Re: Override Change Lock down during approval phase 8.1 ** One other suggestion if I might, the term 'best practice' rubs some folks the wrong way - it implies if they don't adhere to the 'best practice', their method of running the business is somehow inferior. I would venture that a more sellable term would be 'common practice' - that would then give businesses the idea that the 'common practice' is the way most folks operate without the implication. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, November 7, 2014 3:54 PM To: [email protected] Subject: Re: Override Change Lock down during approval phase 8.1 ** Ken, At the end of the day, every customer can decide what they want to do for themselves. And, that is allowed for in the product. From building completely custom on the AR System to using the applications and adding enhancements and overlays to the shipping product. And, as those enhancements are added, with a way to keep them across upgrades and continue to get upgrades. But, there is also a lot of value in providing a set of best practices that are everything from looking at standards to discussions with 100s of customers and all kinds of things between. There should be a set of practices with good descriptions of why they are best practices that gives the majority of customers the right fit. And, for customers who do not have practices at all, are a good set to work with. Without a set of best practices to start with, everyone is on their own with no guidance or directions and they have to figure everything out and code everything with all details for themselves for everything. That sounds a lot like every customer custom building.... I know that there are firms out there that are touting that you building everything yourself from scratch is a good thing (and we fully support the ability to do that), but we feel that having a complete solution with a set of practices that have been proven in many customer installations and that follow standards that have been agreed on and that provide a structure for how to run processes that avoid common pitfalls and failures is a good thing. Then, when you do want something to happen slightly different, you are modifying from a working system that does most things the way you want and you tailor the aspects to the way you want. Now, as for your issue of approving something you submitted.... There has been a solution in place for that for many years now (two at least and I think more like three or four). You are able to configure any approval process to have a field that is looked at to say that if a signature comes up with an assignment to that person, to not generate the signature and keep processing the rules. If they are in a group of users any one of which can approve, they are simply not in the list for this approval. If they are being assigned the approval directly, it will continue with other rules. This can be configured on any approval process and can reference any field - submitter included. So, there was a response to the reported concern and it was put into the product and many of our customers are (and have been) using the feature for quite some time (years). Look at the documentation for the "Exclude User Field" In 8.1 https://docs.bmc.com/docs/display/public/ars81/AP-Process+Definition+form[docs.bmc.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.bmc.com_docs_display_public_ars81_AP-2DProcess-2BDefinition-2Bform&d=AAMFAg&c=XK1GVu0Y2HvWRiFNJ9Hesw&r=gjUwhidUXaYE9_ljv1_0m4pmrahAVdR1jfwPOFX0GjI&m=5JAEKtAkKKBkl-zXW9SgSzTxTC1qMCqW4yrC3bKu7Z4&s=KF9FcM1FTTdZ2fh9py_91Kbht9J1mWVa3zKYTCdhe8o&e=> I believe the same feature is available in 7.6.04, but I cannot link to the doc for that release at the moment. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Ken Pritchard Sent: Friday, November 07, 2014 11:36 AM To: [email protected]<mailto:[email protected]> Subject: Re: Override Change Lock down during approval phase 8.1 ** But Doug... ... isn't that for the company to decide and govern? Over time, I've seen the product become more rigid so that it's no longer something that folks look at with the idea of it being able to conform to their business And before you quote 'best practices' and 'itil' and other such vague guidelines, why is it that you have never closed the hole of allowing a person to both submit AND approve their own request - can't tell you how many folks I've heard have had to put a check in for that. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, November 7, 2014 1:59 PM To: [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of Danaceau, Chris Sent: Friday, November 07, 2014 9:20 AM To: [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of Tommy Morris Sent: Friday, November 07, 2014 11:12 AM To: [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of Ken Pritchard Sent: Friday, November 07, 2014 9:13 AM To: [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of Danaceau, Chris Sent: Friday, November 7, 2014 9:15 AM To: [email protected]<mailto:[email protected]> 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_ _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. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
