Re: Need Suggestion
Could not agree more. Remark: I was the lucky guy that got the chance to integrate the telalert and netcool in those days. Cheers, -Original Message- From: Ray Gellenbeck ray.gellenb...@redmangollc.com Sent: 22/01/2015 04:13 To: arslist@ARSLIST.ORG arslist@ARSLIST.ORG Subject: Re: Need Suggestion Greater minds than me have pointed out the main issues with the stated approach...I lived it in the old TelAlert and NetCool gateway days (shudder). 1. Notifications for alarms should be outsourced to the related application, not stuck onto Remedy. Remedy CAN do it, but it's main focus is processing workflow, notifications should be the exception, not the main bulk of its focused work. 2. By putting this load on ARS instead, more resources will have to be devoted to scaling ARS appropriately AND its underlying DB cluster. How is it they think they are saving money by doing this? Reduced headcount because they think a dedicated notification person would be needed otherwise? I hope nobody would be that short-sighted. Here's another simpler thought: SMS notifications quickly turn into ignored white noise by most all that receive them as the volume increases. There are a lot of good bolt-on solutions for this topic, including ones that let individuals select when, what and how they get notifications. Remedy does the basics for all 3, but not as well. A good consultant will first try to sway the customer from this approach, but if that doesn't happen, ARS can handle it and someone will make a LOT of money from the ongoing care and feeding it will likely require. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: Need Suggestion
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
Re: Need Suggestion
Greater minds than me have pointed out the main issues with the stated approach...I lived it in the old TelAlert and NetCool gateway days (shudder). 1. Notifications for alarms should be outsourced to the related application, not stuck onto Remedy. Remedy CAN do it, but it's main focus is processing workflow, notifications should be the exception, not the main bulk of its focused work. 2. By putting this load on ARS instead, more resources will have to be devoted to scaling ARS appropriately AND its underlying DB cluster. How is it they think they are saving money by doing this? Reduced headcount because they think a dedicated notification person would be needed otherwise? I hope nobody would be that short-sighted. Here's another simpler thought: SMS notifications quickly turn into ignored white noise by most all that receive them as the volume increases. There are a lot of good bolt-on solutions for this topic, including ones that let individuals select when, what and how they get notifications. Remedy does the basics for all 3, but not as well. A good consultant will first try to sway the customer from this approach, but if that doesn't happen, ARS can handle it and someone will make a LOT of money from the ongoing care and feeding it will likely require. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Need Suggestion
I am in the Telco side. Those equipment will generate some huge amount of alarms. In the old day microMuse, now IBM got a product called netcool can based on the same type of alarm to generate 1 tickets, when the ticket is resolved, it help the counterpart, eg, hp openviiew to clear all those alarms. Just voice out one possibilities. Cheers, Omega -Original Message- From: Rick Cook remedyr...@gmail.com Sent: 21/01/2015 01:16 To: arslist@ARSLIST.ORG arslist@ARSLIST.ORG Subject: Re: Need Suggestion ** Great points, Janie. I don't know that Remedy would scale to processing 5 million Incidents a day, unless the DB was kept VERY well trimmed and tuned. If they processed through some very tiny form, then maybe. But the issue is why are there 3-9 million alarms a day going INTO the system. No one will ever actually process those, so deal with the duplicates and non-actionable items some other way, and specifically whitelist those you want/need to actually be tracked in an Incident. Rick Cook On Tue, Jan 20, 2015 at 8:54 AM, Janie Sprenger jrsrem...@gmail.com wrote: ** 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
Need Suggestion
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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Need Suggestion
Great points, Janie. I don't know that Remedy would scale to processing 5 million Incidents a day, unless the DB was kept VERY well trimmed and tuned. If they processed through some very tiny form, then maybe. But the issue is why are there 3-9 million alarms a day going INTO the system. No one will ever actually process those, so deal with the duplicates and non-actionable items some other way, and specifically whitelist those you want/need to actually be tracked in an Incident. Rick Cook On Tue, Jan 20, 2015 at 8:54 AM, Janie Sprenger jrsrem...@gmail.com wrote: ** 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Need Suggestion
Praveen, I'm sure you have already done the math9.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 itI'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
Re: Need Suggestion
Most organizations that I’ve worked in where Incidents are created via a monitoring tool do that escalation on the monitoring tool’s side. That’s really where you want to look. Leave the Incidents for things that actually require human intervention. I would propose getting the monitoring team to do two things: 1) Group alarms into logical relationships to weed out unnecessary alarms (e.g. if a switch that has ten servers connected to it is down, you don’t get 11 Incidents.) 2) Create a prioritization structure so that Incidents are only created when either 1) major failures are reported via monitoring, or 2) medium alarms are not resolved in a timely manner and must be looked at by a person. Additionally, there should be some Problem Management in place to address the issues causing these alarms. That way there can be a representation in Remedy as a Problem Investigation or Known Error, yet you don’t need to store each and every example of a minor alarm as an entire record in Remedy. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Saraswat, Praveen Sent: Tuesday, January 20, 2015 12:09 PM To: arslist@ARSLIST.ORG Subject: Re: Need Suggestion ** 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.ORGmailto: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
Re: Need Suggestion
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.commailto: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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
