Design of digital sales process 

 Ivica Marija 

 The challenge I had was designing a new , “ digitalized ” sales process for lending products for   large corporate clients . In my Bank , “ Large Corporates ” refer to companies that have more   than € 500 million yearly turnaround and require multi - million financing deals for their needs .   Negotiations and contracts are commonly very complex and can last for weeks or months .   Despite having many systems available , the whole process was still mostly manual : data   required for a credit application was manually copy - pasted from source systems to   predefined forms in Word ; calculations of exposures and limits were calculated in variety of   Excel sheets and also copy pasted to these forms , and these forms were sent by e - mail to   different approvers who would review them , print them , sign them and send it back in pdf   format . Finally , data from contracts was manually entered to booking systems . Only this task ,   due to complexity of contracts ( > 100 pages ) was usually taking 4 - 8 hours ( ! ) .     The initial set of requirements we got could be summarized with famous quote from Henry   Ford : “ give me faster horses ” . Despite having very modern digital workflow systems and   Customer Relationship Management ( CRM ) system , everyone expected “ easier way of   handling documents ” . “ Problems ” that were identified were mostly around > 20 systems being   used , primarily to extract data needed for the application , but nobody thought about big   picture . We could do that , of course , but that would n’t be digitalized and automated process .     In order to give participants the sense of complexity , I decided to use visualization – a tool   well described in video of Angela Myer in Week 1 . I often use Visualization , primarily for my   own better understanding of a problem , but also to ensure that there is a shared   understanding of the problem and possible solutions among groups of stakeholders . The   approach is very useful when stakeholders are diverse , in my case businesspeople from a   bank , and IT people from IT division .     In this particular case , I painted the entire process on the wall in a way that I : 

 1 ) highlighted the number of different tools they actually use to extract data they need 

 for an application – indicating that the problem is not in these tools , but in the fact that   they need to manually copy - paste data from different tools into application forms . 

 2 ) Listed different forms that are used for different approval bodies in several steps of 

 the process – indicating number of data items that are in common to these forms ( i.e.   client data ) – that are repeatedly copy - pasted into these forms . 

 3 ) Listed documents client needs to provide for the approval , which we now store for 

 compliance reasons , whereas we do n’t need documents , but information from these   documents ( i.e. confirmation from Commercial Register that company is registered ) in   order to proceed with the application . 

 4 ) Visualized document flow and number of e - mails , printing , physical signing of a 

 document and again scanning and forwarding – in order to “ collect all signatures ” for   the approval – whereas “ approval ” in form of confirmation in a tool would be sufficient . 

 Needless to say – no PowerPoint slides could describe the volume of waste we created in   every single step of credit approval process . Picture hardly fit on 10x2 m wall ( I had to repaint   it several times to fit it properly ) . But , I managed to made my point : problem is not in   systems , but in the way we approach the process . By integrating data sources to the   workflow and using built - in capabilities of CRM tool , administrative overhead could be   decreased by more than 90 % ! Moreover , the most of information we require from a client in   the form of a document – we can get by ourselves from public registries – automatically . This   would dramatically reduce the amount of work for our clients too and reduce waiting time   from days or weeks to minutes or even seconds . 

 The second phase was , however , more complex and more important . Now we knew the   problem – but what is the solution ? This took several weeks of discussions in smaller groups   and common meetings among groups to figure out : 

 1 ) Which data we really need ? In some cases , account managers collected a lot of 

 information about the deal , hoping this will help the case and get the approval from   the investment committee – whereas committee members admitted they do n’t need   these data to make their decision at all . 

 2 ) Which controls we need ? The whole process is rather collaborative , especially for 

 more complex deals , and there is no classical “ flow ” ( handover ) . Squeezing this into a   workflow would actually make it worse . So , we needed to be careful with defining   process steps and decided to minimize them to data collection and approval only –   despite the fact there are several formal approvals needed . 

 3 ) How to organize the data in a screen – especially on different screen sizes 

 ( smartphones / laptops / monitors ) to make the overview possible . Since we talk about   250 different data fields , among which there are “ free text ” fields containing several   sentences , images and graphs – this was the most challenging one . 

 Although I used visualization before , only now I got the true power of it . It was also very   interesting to observe how it also helped clients to involve themselves more . Previously ,   “ specifications ” were written in words . And , it takes thousands of words to describe – and   later , read a requirement . And nobody has time for that . Requirements were written   superficially and understood accordingly – wrong . Once when clients actually saw the vast   number of systems they use and the number of interactions they made – with picture – only   then they realized the problem they had .     On the other hand , something that would previously be written as “ simple ” requirement ( i.e. “ I   want all the data on one screen ” ) , brought them to the understanding that it is them who   need to make priority which datasets they want where , based on the importance . Because :   all the data could n’t fit into a screen ( especially smartphone screen ) ; scrolling was needed ,   so the data that is more important – you should put to the top .     Despite the fact that we did a lot of painting , the whole process proved to be very light in the   documentation – and yet , more descriptive . Additionally , it brought people together and made   the approach collaborative . Businesspeople understood limitations a system has , but also   benefits it can bring if we use it properly . IT people got better understanding of client needs –   and come with very valuable ideas that helped clients make better choices . And on the top : it   was n’t boring at all – it was actually fun !      Finally : there was no ( bad ) surprises about the final outcome . Clients knew exactly how the   new system will look like and how will they use it . There was no need for user manuals nor   training either – they know how to use the system , because they designed it together .     The only thing I would do differently in the future is : jumping immediately to visualization ,   without spending time on interviews and data gathering . A high - level overview is important at   the beginning , but that ’s all . Once when painting starts – there is no need for further “ data   gathering ” because clients can do quite a lot by themselves too .      Of course , some data gathering is still needed ( i.e. in this case we needed to list all data   source systems , and data we need to collect ) , but visualization helped us determine what we   really need – and what we thought we need . This made data gathering rather slim .   Nevertheless , the common opinion once we finished with design was : none of us could   imagined the new process the way it turned out – if we did n’t use the visualization . What we   understood as a problem , and what we envisioned as a solution before we turned to   visualization was completely different from the final outcome . Visualisation helped us 

 understand the big picture , understand the impact different teams have on each other and   design much better solution . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: Ivica Marija
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: Design of digital sales process 

 Ivica Marija 

 The challenge I had was designing a new , “ digitalized ” sales process for lending products for   large corporate clients . In my Bank , “ Large Corporates ” refer to companies that have more   than € 500 million yearly turnaround and require multi - million financing deals for their needs .   Negotiations and contracts are commonly very complex and can last for weeks or months .   Despite having many systems available , the whole process was still mostly manual : data   required for a credit application was manually copy - pasted from source systems to   predefined forms in Word ; calculations of exposures and limits were calculated in variety of   Excel sheets and also copy pasted to these forms , and these forms were sent by e - mail to   different approvers who would review them , print them , sign them and send it back in pdf   format . Finally , data from contracts was manually entered to booking systems . Only this task ,   due to complexity of contracts ( > 100 pages ) was usually taking 4 - 8 hours ( ! ) .     The initial set of requirements we got could be summarized with famous quote from Henry   Ford : “ give me faster horses ” . Despite having very modern digital workflow systems and   Customer Relationship Management ( CRM ) system , everyone expected “ easier way of   handling documents ” . “ Problems ” that were identified were mostly around > 20 systems being   used , primarily to extract data needed for the application , but nobody thought about big   picture . We could do that , of course , but that would n’t be digitalized and automated process .     In order to give participants the sense of complexity , I decided to use visualization – a tool   well described in video of Angela Myer in Week 1 . I often use Visualization , primarily for my   own better understanding of a problem , but also to ensure that there is a shared   understanding of the problem and possible solutions among groups of stakeholders . The   approach is very useful when stakeholders are diverse , in my case businesspeople from a   bank , and IT people from IT division .     In this particular case , I painted the entire process on the wall in a way that I : 

 1 ) highlighted the number of different tools they actually use to extract data they need 

 for an application – indicating that the problem is not in these tools , but in the fact that   they need to manually copy - paste data from different tools into application forms . 

 2 ) Listed different forms that are used for different approval bodies in several steps of 

 the process – indicating number of data items that are in common to these forms ( i.e.   client data ) – that are repeatedly copy - pasted into these forms . 

 3 ) Listed documents client needs to provide for the approval , which we now store for 

 compliance reasons , whereas we do n’t need documents , but information from these   documents ( i.e. confirmation from Commercial Register that company is registered ) in   order to proceed with the application . 

 4 ) Visualized document flow and number of e - mails , printing , physical signing of a 

 document and again scanning and forwarding – in order to “ collect all signatures ” for   the approval – whereas “ approval ” in form of confirmation in a tool would be sufficient . 

 Needless to say – no PowerPoint slides could describe the volume of waste we created in   every single step of credit approval process . Picture hardly fit on 10x2 m wall ( I had to repaint   it several times to fit it properly ) . But , I managed to made my point : problem is not in   systems , but in the way we approach the process . By integrating data sources to the   workflow and using built - in capabilities of CRM tool , administrative overhead could be   decreased by more than 90 % ! Moreover , the most of information we require from a client in   the form of a document – we can get by ourselves from public registries – automatically . This   would dramatically reduce the amount of work for our clients too and reduce waiting time   from days or weeks to minutes or even seconds . 

 The second phase was , however , more complex and more important . Now we knew the   problem – but what is the solution ? This took several weeks of discussions in smaller groups   and common meetings among groups to figure out : 

 1 ) Which data we really need ? In some cases , account managers collected a lot of 

 information about the deal , hoping this will help the case and get the approval from   the investment committee – whereas committee members admitted they do n’t need   these data to make their decision at all . 

 2 ) Which controls we need ? The whole process is rather collaborative , especially for 

 more complex deals , and there is no classical “ flow ” ( handover ) . Squeezing this into a   workflow would actually make it worse . So , we needed to be careful with defining   process steps and decided to minimize them to data collection and approval only –   despite the fact there are several formal approvals needed . 

 3 ) How to organize the data in a screen – especially on different screen sizes 

 ( smartphones / laptops / monitors ) to make the overview possible . Since we talk about   250 different data fields , among which there are “ free text ” fields containing several   sentences , images and graphs – this was the most challenging one . 

 Although I used visualization before , only now I got the true power of it . It was also very   interesting to observe how it also helped clients to involve themselves more . Previously ,   “ specifications ” were written in words . And , it takes thousands of words to describe – and   later , read a requirement . And nobody has time for that . Requirements were written   superficially and understood accordingly – wrong . Once when clients actually saw the vast   number of systems they use and the number of interactions they made – with picture – only   then they realized the problem they had .     On the other hand , something that would previously be written as “ simple ” requirement ( i.e. “ I   want all the data on one screen ” ) , brought them to the understanding that it is them who   need to make priority which datasets they want where , based on the importance . Because :   all the data could n’t fit into a screen ( especially smartphone screen ) ; scrolling was needed ,   so the data that is more important – you should put to the top .     Despite the fact that we did a lot of painting , the whole process proved to be very light in the   documentation – and yet , more descriptive . Additionally , it brought people together and made   the approach collaborative . Businesspeople understood limitations a system has , but also   benefits it can bring if we use it properly . IT people got better understanding of client needs –   and come with very valuable ideas that helped clients make better choices . And on the top : it   was n’t boring at all – it was actually fun !      Finally : there was no ( bad ) surprises about the final outcome . Clients knew exactly how the   new system will look like and how will they use it . There was no need for user manuals nor   training either – they know how to use the system , because they designed it together .     The only thing I would do differently in the future is : jumping immediately to visualization ,   without spending time on interviews and data gathering . A high - level overview is important at   the beginning , but that ’s all . Once when painting starts – there is no need for further “ data   gathering ” because clients can do quite a lot by themselves too .      Of course , some data gathering is still needed ( i.e. in this case we needed to list all data   source systems , and data we need to collect ) , but visualization helped us determine what we   really need – and what we thought we need . This made data gathering rather slim .   Nevertheless , the common opinion once we finished with design was : none of us could   imagined the new process the way it turned out – if we did n’t use the visualization . What we   understood as a problem , and what we envisioned as a solution before we turned to   visualization was completely different from the final outcome . Visualisation helped us 

 understand the big picture , understand the impact different teams have on each other and   design much better solution .
### Output: 