Reflection about Visualization

Challenge  Since one year I’m conducting IT initiatives dedicated to the company introduction of new and emerging  technologies, and this means sometimes - also in this specific case - the parallel usage of the newest thinking  and reasoning tools.

The initiative of which I’m talking in this reflection is the creation of the first chatbot of the company. It was  a totally new artificial intelligence, communicating via chat and dedicated to the IT helpdesk functionalities  provision for the white collars. The chatbot needs to be able to interact as a human helpdesk operator and it  must know how to help its users by solving all the user’s problems that we included into the initiative  perimeter. Regarding this las point, and talking before with some company managers, I discovered that it  wasn’t clear what will be the good way to manage any kind of support request. For example, regarding the  same support request, not all the helpdesk operators follow the same resolution flow - the same sequence  of steps - or interact with the same third-party IT systems. Additionally, no updated and shared agreed  documentation about the resolution flows was present.

This was for me a very big problem that had to be solved because, into the chatbot, it must be implemented  only one clear and precise resolution flow for any different support request. How to detect these was my  challenge.

Selection  In order to put in communication all the involved stakeholders - managers and operators - and detect, in  single dedicated meetings, for the first time in the company, a shared and agreed resolution flow for any  support request, I decided to make use of the Visualization tool. Starting from a prepared or blank sheet, this  tool lets anyone to reflect and describe easily, with different type of structured or unstructured drawings and  symbols, their personal idea of a concept, a process, a product and more.

I selected this tool because it was the only one - as I know - that gave me possibility to obtain at the same  time two important objectives: (1) capture and centralize the knowledge actually decomposed into different  company roles and people, (2) reasoning immediately on these information and obtaining a common  understanding and agreement. Only after this activity conclusion I could be able to move forward on  prototyping the chatbot resolution flows.

Application  Every meeting was dedicated to only one of the five support requests selected, and this information was  well-known in advance to every participant. During the meeting preparation, I decided to create a semi- prepared sheet for any participant, with the aim to remove from anyone the blank sheet fear and speed-up  the activity. In every sheet I drew some basic elements that must be present like: the explicit support request  coming from the user (the starting flow of the process), the helpdesk operator (placed at the centre of the  sheet) and the most used third-party IT systems (placed in different points of the sheet). The request to  anyone was clear: draw the resolution flow adopted by the helpdesk operator for the single support request.  I gave them 20 minutes and I also remembered them that they can draw and add everything they want into  the sheet.

In every meeting, after the drawing phase completion, I collected the participants’ sheets and I started in a  random order to read every drawn flow, asking clarifications to the drawer and to all the participants. In  parallel, after each clarification and agreement, I started to draw step by step - with subsequent  improvements and adjustments - the “final” resolution flow for each of the five support requests.

Insight  During the second phase of the first meeting, the one dedicated to the “final” resolution flow construction,  probably I had the most important insight. I understood clearly the unique advantage of the co-creation, the  advantage of involving from the beginning stakeholders coming from different company levels and with  different responsibilities and point of views. These intrinsic diversities revealed many doubts, constraints and  difficulties that were present also in simple and - in theory - linear operative tasks.

My second insight, even very important, was the autonomous thinking and drawing before the phase  mentioned above. If I imagine reaching the same result by starting to talk and discuss all together without a  previous personal work and clarification, probably my activity would fail. The lesson learned is to let each  one to reflect and reason alone before talking, if you don’t want to discuss for all day.

Approach  During a couple of the five meetings, it would be difficult to find a commonly agreed support request  resolution flow because of some company rules free interpretations or missing information, known to non- invited participants. In these cases, a better definition of the participants’ list and, in general, a better basic  knowledge about the resolution flows could be useful and could provide a significant speed-up on the  reasoning phase. I confirm the positive usage of the Visualization tool, but I warmly suggest to work hard in  the preparation phase, trying to think about everything you need before running it.


Reflection about Visualization Challenge Since one year I ’m conducting IT initiatives dedicated to the company introduction of new and emerging technologies , and this means sometimes - also in this specific case - the parallel usage of the newest thinking and reasoning tools . The initiative of which I ’m talking in this reflection is the creation of the first chatbot of the company . It was a totally new artificial intelligence , communicating via chat and dedicated to the IT helpdesk functionalities provision for the white collars . The chatbot needs to be able to interact as a human helpdesk operator and it must know how to help its users by solving all the user ’s problems that we included into the initiative perimeter . Regarding this las point , and talking before with some company managers , I discovered that it was n’t clear what will be the good way to manage any kind of support request . For example , regarding the same support request , not all the helpdesk operators follow the same resolution flow - the same sequence of steps - or interact with the same third - party IT systems . Additionally , no updated and shared agreed documentation about the resolution flows was present . This was for me a very big problem that had to be solved because , into the chatbot , it must be implemented only one clear and precise resolution flow for any different support request . How to detect these was my challenge . Selection In order to put in communication all the involved stakeholders - managers and operators - and detect , in single dedicated meetings , for the first time in the company , a shared and agreed resolution flow for any support request , I decided to make use of the Visualization tool . Starting from a prepared or blank sheet , this tool lets anyone to reflect and describe easily , with different type of structured or unstructured drawings and symbols , their personal idea of a concept , a process , a product and more . I selected this tool because it was the only one - as I know - that gave me possibility to obtain at the same time two important objectives : ( 1 ) capture and centralize the knowledge actually decomposed into different company roles and people , ( 2 ) reasoning immediately on these information and obtaining a common understanding and agreement . Only after this activity conclusion I could be able to move forward on prototyping the chatbot resolution flows . Application Every meeting was dedicated to only one of the five support requests selected , and this information was well - known in advance to every participant . During the meeting preparation , I decided to create a semi- prepared sheet for any participant , with the aim to remove from anyone the blank sheet fear and speed - up the activity . In every sheet I drew some basic elements that must be present like : the explicit support request coming from the user ( the starting flow of the process ) , the helpdesk operator ( placed at the centre of the sheet ) and the most used third - party IT systems ( placed in different points of the sheet ) . The request to anyone was clear : draw the resolution flow adopted by the helpdesk operator for the single support request . I gave them 20 minutes and I also remembered them that they can draw and add everything they want into the sheet . In every meeting , after the drawing phase completion , I collected the participants ’ sheets and I started in a random order to read every drawn flow , asking clarifications to the drawer and to all the participants . In parallel , after each clarification and agreement , I started to draw step by step - with subsequent improvements and adjustments - the “ final ” resolution flow for each of the five support requests . Insight During the second phase of the first meeting , the one dedicated to the “ final ” resolution flow construction , probably I had the most important insight . I understood clearly the unique advantage of the co - creation , the advantage of involving from the beginning stakeholders coming from different company levels and with different responsibilities and point of views . These intrinsic diversities revealed many doubts , constraints and difficulties that were present also in simple and - in theory - linear operative tasks . My second insight , even very important , was the autonomous thinking and drawing before the phase mentioned above . If I imagine reaching the same result by starting to talk and discuss all together without a previous personal work and clarification , probably my activity would fail . The lesson learned is to let each one to reflect and reason alone before talking , if you do n’t want to discuss for all day . Approach During a couple of the five meetings , it would be difficult to find a commonly agreed support request resolution flow because of some company rules free interpretations or missing information , known to non- invited participants . In these cases , a better definition of the participants ’ list and , in general , a better basic knowledge about the resolution flows could be useful and could provide a significant speed - up on the reasoning phase . I confirm the positive usage of the Visualization tool , but I warmly suggest to work hard in the preparation phase , trying to think about everything you need before running it .