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 . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: 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 .
### Output: 