Praveen, I'm sure you have already done the math....9.5M/day is roughly 110/sec if averaged out, which it of course wouldn't be. This sort of volume would be large just to store that many records per day, let alone 'process' them, but Remedy is scalable, and is a workflow engine, so yes, an infrastructure COULD be setup to handle it....I'm not sure if Remedy would be doing more than being a DB repository and lookup location at that point, so it might make sense to bypass Remedy altogether and just write a Java Daemon or something that did direct DB lookups for the data you need and called the external program that's actually doing the paging...
On Tue, Jan 20, 2015 at 11: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"
