Good information Doug - thank you.  Can you comment on why BMC Sales is
discouraging folks from customizing the system.  My understanding is the
overlays were put in specifically to make it easi'er' to patch and upgrade
the applications.  I'm in complete support of that - but now folks are being
told NOT to customize the system (at least those I've conversed with).  I'm
sure you have interaction with more customers than I, but it seems to me BMC
shouldn't be discouraging clients from doing the things you are mentioning
here.  

 

Thank you for that link.  With the thousands of pages of documentation it
seems almost as difficult to find something in the Remedy documentation as
in the Affordable Health Care Act (before I get told to keep politics out of
it, that is just meant as a bit of humor).

 

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

 

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_ 


_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to