My understanding of what you just said is that the FMS Incidents aren't going to be handled by people unless the SLA is breached; in which case there is an escalation of sorts that means someone has to do something with that Incident because the alarm hasn't cleared and there's actual work to do. So that also means that any FMS Incidents that are created but don't alarm would need to mainly be closed by the system so they don't linger in an open state. I assume your customer has SLAs that have to be met, is volume of Incidents included in their reporting - if so, it's something to consider.
Maybe start putting some factual statements behind your hesitation. For example, what's the growth rate on the DB and can that be managed automatically, what's the method of import - how long does it take to import a record, update the record, other processing factors (such as Remedy internal processing, like workflow processing and escalations), how long does the system take to process an SLA breech? Do you have enough AR Servers, import servers? Will there be an archive of data? Sometimes a factual accounting of considerations leads to financial impact that the customer maybe didn't expect, like adding 12 servers to process the volume of data or maybe it resolves the hesitation into something that can't be done to something that can. But, I do think that legitimate faults in the environment make for legitimate Incidents. BMC also has products for managing system events; generally speaking, faults are isolated and filtered in the FMS and then mainly legitimate Incidents get created. It might be worth talking with some of your counterparts to discuss some of the methodologies that collect and filter those events in BMC's products so you can apply that conceptual knowledge. And, if the customer is really bent on using Remedy instead of FMS configuration, perhaps a staging area for processing Faults and Alarms (like what an FMS would do) is worth the design and build to keep 90% of the non-Incident Alarms out of Incident Management. Janie On Tue, Jan 20, 2015 at 10:08 AM, Saraswat, Praveen <psaras...@columnit.com> wrote: > ** > > Hi Janie, > > > > Customer has one of worlds largest passive support for Telcos due to which > the volume of alarms from different EMSs is high. Actual need was to notify > the stakeholders through SMS before it qualified to be converted to an > Incident and follow a set escalation matrix in case Alarm is not able to > clear itself from EMS systems. > > You are right in your understanding that Customer is trying to solve a > problem which the FMS(Alarm System) owner has declined to do due to various > reasons. > > > > There is a lot of processing done to get appropriate information for SMS > ,before it goes from Remedy System to the SMS gateway. > > > > Yes, the volume of the Alarms to be converted to Incidents( only incidents > will be created from Alarms) is high and the Customer is least bothered > about handling of these tickets. He just wants to trigger Escalation(SLA > breach) SMS if the Alarm is not automatically cleared. > > > > In addition to the above type of tickets. Remedy system is supposed to > handle approx 70k tickets per day , which will be assigned to the > appropriate groups and it needs to be worked upon by ground staff using a > Mobile App. These tickets(Incidents/Change/Problem) also have their own > processing and automation before it hits the database.SMS flows for these > type of tickets as well. > > > > We have already implemented this for 70k tickets per day, but the new > volume of Alarms makes me little hesitant to commit to the Customer. Also I > don’t want to make the Remedy System as a SMS dispatcher tool instead of > its core functionalities of ticket tracking and service management. > > > > I really appreciate your thoughts and opinion. Thanks > > > > Regards, > > Praveen > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Janie Sprenger > *Sent:* 20 January 2015 22:24 > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Need Suggestion > > > > ** > > Are you in disagreement because you don't think Remedy can handle the > volume or the volume won't be appropriately handled by personnel once it's > in Remedy? > > Some additional things to think about are: > > By ticket, do you mean Incident or Change Request or Task or Work Order or > something custom, by escalations do you mean related transaction records? > > Are all of the tickets that get generated supposed to end up being handled > manually by people? > > Is there more processing and automation that occurs once the ticket is > generated in Remedy? > > Is the process flow escalation intended to be more than a historical audit > record of the event? > > > > Obviously, the volume is really high and it's hard to think of any > companies that can manually handle that kind of volume on a daily basis so > that means there is more to the story. > > IMO, Here's the thing to keep in mind, the customer is trying to solve a > problem. They are attempting to use Remedy to solve that problem, which is > good so you don't want to deter from them from what Remedy can and should > be doing. But you also need to help to find a solution for the actual > issue at hand because if they really have 3.5 to 9.5 million daily faults > occurring in their environment, then they really do have a problem they > have to sort out. Perhaps it's a matter of getting a handle on what is > faulting, maybe SMS or FMS is or isn't configured correctly, maybe the > faults are warnings and some are faults that need to be addressed. Maybe > there is something to be aware of other than just processing millions of > individual tickets into a 1 to 1 mapping between the fault and the ticket. > > > > My suggestion is to find out what the end goal is for the data that goes > into Remedy, regardless of the volume and see where that takes you with > whether or not Remedy can assist with solving the customer's problem. > > > > HTH, > > Janie > > > > On Tue, Jan 20, 2015 at 3:25 AM, Saraswat, Praveen <psaras...@columnit.com> > wrote: > > ** > > Hi All, > > > > I have below requirement from one of the Customer. Wanted to check if > anyone has done this before for such volume. > > > > Requirement – Customer wants to send SMS to the stakeholders for any > escalations on the tickets generated from Alarm (Fault Management System). > > Volume of tickets to be generated from Alarms – 3.5 million per day on day > 1. Eventually the count to increase to 9.5 million per day. > > For any given ticket,2 to 3 SMS to flow from the system as part of the > escalation matrix. > > Is remedy system the right place to handle SMS flow of this volume? > > > > I am in disagreement to use the Remedy System as SMS dispatcher for such a > large volume of tickets. > > What are your thoughts on this? Any suggestions? > > > > Regards, > > Praveen > > > > > > > > > > _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"
