Designing your way out of jeopardy

In an earlier post entitled, “Looking Forward to Jeopardy and Fall-outs,” I described a method for projecting forward to the likelihood of a design falling into a failure state and using that data to drive continual improvement. Not only that, but to drive the future of self-service telco designs, as I’ll describe today!

The diagram below shows the concept of a design tree.
Design Tree Analytics
This tree can get VERY complicated in big service providers that have many product offerings. In fact, it can get so out of control that the service providers don’t actually know how many design variants (ie leaves on the design tree) that they have. The number of variants can get so big and are evolving so fast that they are impractical to be mapped into process flows.

Alternatively, there may be theoretical variants that are never actually used in practice and are hence a distraction. There are probably even variants that aren’t even considered on process flow diagrams (operators call these workarounds 🙂 ).

A few thoughts about this model:

  1. Since it’s impractical to manage all the possible process flows (and program them into OSS), instead allow operators to move between design states
  2. Use data collection to monitor evolving design states and the flows between them rather than trying to pre-define them (refer to Sankey Diagrams as a method of visualising evolving flows) (diagram below courtesy of sankey-diagrams.com):
    Sankey Diagram
  3. Count the number of process iterations that follow a particular flow (eg the number of orders that follow an exact same path through to a single leaf)
  4. Analyse how many of those iterations have been successful or have failed (this could be across all past iterations, or just the most recent days/weeks/months to reflects current system responsiveness)
  5. Use closed loop techniques to feed forward information that helps designers to pick flows with a higher likelihood of success (eg if design variant #1 is 50% likely to fall-out and 75% likely to reach jeopardy, but equivalent design variant #2 has likelihoods of 5% and 10% respectively, then steer the operator to follow variant #2 the next time this type of order appears)
  6. Note: “Likelihood of success” could be metrics such as activation time, profitability, as well as fall-out rate and jeopardy rate amongst other KPIs
  7. Taking this beyond the closed loop and into the realms of AI, we could then use more advanced predictions and decision support to:
    1. Cull lossy variants
    2. Identify automated/manual ways of fixing lossy variants
    3. Identify equivalent leaves (ie which variants give service equivalency as far as the customer is concerned, irrespective of which network type or data flow is traversed)
    4. Cross-correlate with other data sets to identify other “success” metrics such as NPS
  8. With simplification and productivity in mind, the aim would be to automatically strip branches/leaves out of the tree and guide operators towards using the strongest branches (the Darwinian model)
  9. The strongest branches are laid out to operators as decision support, thus reducing the skills-base (and associated training) required to process them, leaving skilled staff to perform higher-value activities
  10. The biggest objective here is to allow customers to self-design / self-configure, which can only happen if:
    1. Product offerings are simple to understand (think Visio-style drag and drop into a network design canvas)
    2. Networks are modular and easily interconnected
    3. Designs are relatively fool-proof so that networks can be designed by customer representatives that aren’t experienced network engineers (with decision support if necessary)
    4. Design processes are robust and resilient so that they rarely fall into failure states
  11. Virtualisation and is only likely to increase the number of variants so we’re going to need machine-based help to manage them.
  12. Meanwhile intent models are abstracting (ie hiding) design paths from operators but should still be visualised in flows
  13. BTW. If new flows appear in the state machine, the flow data collection tool identifies it and automatically adds it to the design tree (as opposed to having to re-write process diagrams / documentation to handle new variants)
Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *