“Refining is inevitable in science when you have made measurements of a phenomenon for a long period of time.”
Charles Francis Richter.
When setting up your alarm / fault management modules, the KISS principle again applies.
Focus first on getting raw alarms flowing and conduct audits to ensure all are reaching your OSS as planned.
Only once that step is completed should you look to augment your alarms with additional data that can be gathered or cross-referenced from other sources (eg taking acronyms / codes within the raw data and using reference tables to augment with human readable data, or referencing data from inventory to show impacted customers, etc).
Once that is bedded down, then build optimisation mechanisms (filtering, suppression, route-cause analysis, etc) in a step-by-step manner once your experts first evaluate and understand the flow of raw data.
I don’t recommend to start optimising in this manner before you know all alarms are reaching your OSS or before you have a thorough understanding of the raw data and how augmentations / mappings against this data work manually.
This KISS principle ensures that the tool is in and working as early as possible (a quick win for the project team to build credibility upon) and also gives operators a deeper understanding of your OctopOSS’s data. Many implementations will try to build alarm feeds, augmentation and optimisation mechanisms all at once for a big-bang cutover.
From my experience, this delays and complicates the solution as well as losing the opportunity to build momentum via phased developments.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email