“The only way to get rid of Dirty Tickets of Work (DToW) is to get rid of Tickets of Work (ToW)”
DToW is terminology used in Telstra to indicate that incorrect information has been entered into the ToW or where the field tech hasn’t been able to complete the ToW as originally designed / planned. I’m not sure if only Telstra uses this terminology. I haven’t heard it used at any other service provider I’ve worked at.
A DToW is an important metric because it effectively means the job has just got more expensive due to quality issues. lt probably means re- design effort,perhaps data audit / remediation and an extra truck roll… at a minimum.
I love the concept and am proposing to extend it to other workflows like Dirty Service Orders, Dirty Trouble Tickets, Dirty API calls, Dirty Processing (fall-outs), etc.
Because of the quality / cost implications, many very clever people have spent a lot of effort wrestling with solutions to this problem. Technical solutions, process solutions, data solutions, user interface solutions. To my knowledge, the problem remains to be solved, not just at Telstra, but at every other Telco that uses a different name for the same metric.
Now we could take the traditional (eg Six Sigma) approach, which is improving the quality of all the ingredients of a ToW. Or, we could take the lightbulb perspective posed in the opening quote and ask how we can build a solution that doesn’t require ToWs or SOs or TTs, etc.
That might just start a revolution for OSS.
How do we get to zero field work? Ubiquitous and over-provisioned connectivity, virtualised networks and CPE (vCPE) and colour-palette solution simplicity are surely a starting point. Blanket wireless networks and a greater use of feedback loop thinking probably help too.
How do we get to no service orders? I’m thinking consumption-based billing here, not your first reaction – thinking I’m espousing free use. But perhaps free use is an option as there are plenty of other revenue models available to clever service providers.
How do we get to no trouble tickets? Self-healing, highly resilient, elastic networks (and OSS). Also, robotic event processing and automated pattern-recognition / decision-support / root-cause. The perspective here is a “no moving parts” electronics analogy – where Solid State Drives (SSD) tend to be more reliable than spinning drives.
Hat tip to Roger Gibson again for seeding a couple of ideas here.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email