All golfers will recognise the phrase "Drive for show. Putt for dough"., but have you come across the phrase "Visualise for show. Operationalise for dough". No ? I'm not really surprised because I've just made it up. It might catch on, it might not but the sentiment is as true for analytics as it is for golf. Just as a great drive only really makes a difference if it is followed up by getting the ball in the hole a shot or two later, the value in great insight is in being able to execute on that insight and generate some business value. Otherwise, it’s just a picture.
I'm often asked "So, How do we operationalise the insights we create in Aster ?". I find it more difficult these days to get away with an "it depends" response so I usually answer this by describing 3 broad types of insight. Actually, the 3 has become 4 but more on that later.
In some cases the insight generated is just a new fact that we didn't know before, Once we know it , we can't not know it so there is no great value in analysing the same fact over and over again unless you happen to work in a 24 Hour News Channel.
Operationalising this type of insight usually involves a procedural change or a modification to an existing system rather than a requirement to create an operational analytic process.
Root cause analysis on engine failures using text analysis on engineer’s notes in Aster may indicate that there is a strong correlation between the failure of Part A and Part B. This insight can be operationalized by amending the engineer’s instructions to replace Part A and Part B at the same time. Job done.
In this case the Aster system is not required as part of the operational process.
Often the analytic techniques in Aster can be used to discover new variables or data items that can be used to improve the analytics or reporting in other systems. In these cases the Aster functions are used to uncover the new data item but once identified we don't have a dependency on a specific Aster function to use that knowledge on a regular basis.
Not all Big Data is created equal so Aster is often used to remove the noise and get to the key pieces of data that make a difference e.g. using Aster with Telco network data to detect the key data items that impact churn. This can then be operationalized by making sure the appropriate data is available on the Data Warehouse and creating or modifying SAS or SPSS or <insert tool of choice> churn models to use the new data.
Again, Aster is not actually required in the production process but has played a key part in improving the effectiveness of the production models.
In some cases there is no alternative but to operationalise the analytic process in Aster. This is usually the case when there is a dependency on the functions in Aster to generate the insight and there is no alternative system in which to do this type of analysis.
As an example, the graph functions in Aster can be used to detect the strength of relationships between people or things. Calculated values such as pagerank, centrality, betweenness etc provide a qualitative assessment of a relationship that can be used in a number of ways depending on the use case. Over time these relationships and calculated values may change and that change could be significant for things like churn, fraud, customer satisfaction etc. so keeping a track on these factors is important. This requires re-running the graph functions in Aster on a regular basis and using the generated values either in Aster or on some other system.
I mentioned earlier that I had 3 broad classifications of insight then I added another. My fourth classification is the Aster Scoring SDK. I won’t go into detail here (maybe a subject of another blog) but the Aster Scoring SDK is a means of producing a ‘scoring module’ in Aster that can be deployed on another system. This allows the scoring to be done in ‘near real time’ closer to where the action actually happens.
You could create a classification model in Aster that determines if some text input is a complaint or a product information request. In the classic scoring method we would score the text input in batches on the Aster system. With the Aster Scoring SDK we could create a Text Classification Scoring Module and deploy it in an application in the web channel. It would then score each text input as it is generated. This would allow us to route the message more effectively and respond more quickly. The analytic preparation work is done in Aster but the operational scoring is done elsewhere. Neat.
So we have 4 broad classifications of insight and operational approaches.
My initial response of “it depends” to the question “How do we operationalise the insights we create in Aster ?" is still valid but we now have a sense of what it depends on . This is not a rigid classification but thinking this through for a specific piece of insight will help narrow down the possible alternatives and take away some of the noise.
But we don’t get off that lightly. The follow up question is usually “Ok got that. So, how do we operationalise on Aster ?”. This is a different question and one for another day. In the meantime, I have a golf ball to find. It was last seen heading in to some wilderness so I may be some time. Luckily, it won’t have gone too far.
…and my putting is not much better.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.