Crack­ing the op­er­a­tional an­a­lyt­ics nut

Malta Independent - - ENEWS & TECH -

An­a­lyt­ics man­agers or busi­ness peo­ple in­ter­ested in an­a­lyt­ics of­ten say that per­form­ing some an­a­lyt­ics on data is not the pri­mary prob­lem they have. They say they have to get the an­a­lyt­ics in­te­grated with the process and the sys­tems that sup­port it. This is­sue, some­times called “op­er­a­tional an­a­lyt­ics,” is the most im­por­tant fac­tor in de­liv­er­ing busi­ness value from an­a­lyt­ics. It’s also crit­i­cal to de­liv­er­ing value from cog­ni­tive tech­nolo­gies, which are es­sen­tially an ex­ten­sion of an­a­lyt­ics any­way.

Three things make op­er­a­tional an­a­lyt­ics tough. First, to make it work, you have to in­te­grate it with trans­ac­tional or work­flow sys­tems. Sec­ond, you of­ten have to pull data from a va­ri­ety of dif­fi­cult places. And third, em­bed­ding an­a­lyt­ics within op­er­a­tional pro­cesses means you have to change the be­hav­iour of the peo­ple who per­form that process.

If you are suc­cess­ful, you even­tu­ally will run into a fourth prob­lem: The em­bed­ded an­a­lyt­i­cal mod­els will have to be mon­i­tored over time to make sure they re­main cor­rect.


To suc­ceed with op­er­a­tional an­a­lyt­ics, a com­pany has to com­bine trans­ac­tion sys­tems, work­flow sys­tems, an­a­lyt­i­cal sys­tems, data­bases, and dis­play/user ex­pe­ri­ence tools—no easy task. In­te­grat­ing with trans­ac­tional sys­tems takes a good deal of ef­fort, although mod­ern sys­tems ar­chi­tec­tures make it a bit eas­ier. Most trans­ac­tional sys­tems th­ese days (in­clud­ing SAP and Or­a­cle ERP sys­tems) al­low API-based con­nec­tions. But there is usu­ally a fair amount of ef­fort in­volved in in­te­grat­ing an op­er­a­tional sys­tem ex­tract­ing the data you need, do­ing the an­a­lyt­ics some­where (the cloud, in-data­base pro­cess­ing), and em­bed­ding the re­sult into an in­ter­face for the front­line user.

You might be able to ac­com­plish much of the in­te­gra­tion with a work­flow-ori­ented over­lay tool like case man­age­ment, busi­ness process au­to­ma­tion (BPA), or ro­botic process au­to­ma­tion, although those types of sys­tems gen­er­ally don’t do any an­a­lyt­ics. That means hu­man labour - from your or­gan­i­sa­tion or an ex­ter­nal ser­vices provider - will be re­quired to com­bine work­flow and an­a­lyt­ics. For ex­am­ple, a Bos­ton­based BPA com­pany, Pe­gasys­tems, part­ners with pro­fes­sional ser­vices firms to com­bine an­a­lyt­ics-based rec­om­men­da­tion en­gines with Pega’s mul­ti­chan­nel mar­ket­ing au­to­ma­tion ca­pa­bil­i­ties.

Var­i­ous Data Sources

Prob­lem two is get­ting all the needed data. That can be han­dled fairly eas­ily if the data is in an in­for­ma­tion sys­tem in some sort of ac­ces­si­ble for­mat. But in many cases, the data is in a va­ri­ety of for­mats - in­clud­ing pa­per re­ports, PDF files, un­struc­tured ar­ti­cles, med­i­cal records, and more. To get that kind of data into your op­er­a­tional an­a­lyt­ics sys­tem, you need more than an­a­lyt­ics - you need ar­ti­fi­cial in­tel­li­gence (AI).

One of the few ven­dors that com­bines AI ca­pa­bil­i­ties with BPA is RAGE Frame­works, headed by a for­mer pro­fes­sor, Venkat Srini­vasan, who holds a doc­tor­ate in com­pu­ta­tional lin­guis­tics. The AI ca­pa­bil­i­ties al­low RAGE ap­pli­ca­tions in, for ex­am­ple, fi­nan­cial as­set man­age­ment to ex­tract and clas­sify rel­e­vant con­tent from an­a­lyst re­ports and drive in­vest­ment rec­om­men­da­tions. RAGE also has worked with au­dit firms to ex­tract data from pa­per and PDF files for ac­count rec­on­cil­i­a­tions. You sim­ply can’t au­to­mate such pro­cesses if you can’t au­to­mate the “data in­ges­tion” process. In ad­di­tion, RAGE em­ploys a va­ri­ety of other “en­gines” - 21 in to­tal, in­clud­ing a com­pu­ta­tional lin­guis­tics en­gine, a de­ci­sion tree en­gine, and a busi­ness-rules en­gine - to rapidly de­velop in­tel­li­gent ap­pli­ca­tions. This mul­ti­plic­ity of mi­croser­vices is a way to quickly cre­ate op­er­a­tional sys­tems that can an­a­lyse and think.

Chang­ing Be­hav­iour

Fi­nally, there is the need to per­suade front-line users to change their be­hav­iour to­ward de­ci­sions and ac­tions based on op­er­a­tional an­a­lyt­ics. A “next-best of­fer” sys­tem for bank tell­ers, for ex­am­ple, has to per­suade the teller to ac­tu­ally use the rec­om­men­da­tions when work­ing with cus­tomers. They won’t em­ploy an­a­lyt­i­cal rec­om­men­da­tions if they don’t trust them.

To build such trust, trans­parency of an­a­lyt­i­cal rec­om­men­da­tions is essen­tial. If the rea­son for the rec­om­mended prod­uct or ac­tion can’t be de­scribed in un­der­stand­able lan­guage, the user won’t be able to as­sess whether it makes sense. That re­quires some sort of nat­u­ral-lan­guage gen­er­a­tion ca­pa­bil­ity to de­scribe the de­ci­sion logic. It doesn’t favour many ma­chine-learn­ing ap­proaches to an­a­lyt­ics be­cause, most of the time, there is sim­ply no way to de­scribe or in­ter­pret why a par­tic­u­lar model pre­vails in a ma­chine-learn­ing process.

Or­gan­i­sa­tions em­bark­ing on op­er­a­tional an­a­lyt­ics are learn­ing that an­a­lyt­ics it­self is the easy part. There is no short­age of avail­able ven­dors, both pro­pri­etary and open source, of an­a­lyt­i­cal al­go­rithms. But build­ing an op­er­a­tional an­a­lyt­ics sys­tem means in­te­grat­ing and chang­ing ex­ist­ing ar­chi­tec­tures and be­hav­iours, and that’s al­ways the hard part. It’s well worth the trou­ble, how­ever, to build ap­pli­ca­tions in which an­a­lyt­ics and smart de­ci­sion-mak­ing are em­bed­ded in a com­pany’s sys­tems and pro­cesses.

For more in­for­ma­tion, please visit­nol­ogy

Newspapers in English

Newspapers from Malta

© PressReader. All rights reserved.