“If destruction be our lot, we must ourselves be its author and finisher.”
Abraham Lincoln.
Flow-through provisioning is a wonderful thing. It usually takes a lot of effort to design the data model so that all the pieces of the jigsaw puzzle line up for each and every new service provisioned by your awesome product.
But the oft forgotten Cinderella at this dance is actually the flow-through deactivation process. It is this process that is often even harder, but usually more valuable to the CSP in terms of the time it saves. Tearing the service down may require you to deactivate just one link in the chain, so it doesn’t sound too hard at first glance. However, the key to the deactivation process is releasing all resources back into the pool for auto-provisioning of the next service.
In my early days as a SME (network Subject Matter Expert), I was focused only on the A in MACD (Moves, Adds, Changes, Deletes). I later found out that the D was often actually the bigger achievement.
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
