Implantació del CRM Salesforce per l'empresa Servilusa
Abstract
El següent projecte consisteix en la implantació d'un sistema de gestió de relacions amb el client o Client Relationship Manager (CRM) per a l'empresa funerària Servilusa. El projecte es durà a terme en l'empresa Konozca Consulting, on juntament amb un equip de 4 persones més, plantejarem, desenvoluparem i implantarem aquest sistema. Amb la realització d'aquest projecte es pretén posar en pràctica els meus coneixements d'enginyer informàtic adquirits durant la meva formació en la Facultat d'Informàtica de Barcelona. També podré adquirir noves habilitats i experiència en poder treballar amb una empresa amb molt recorregut en l'àmbit de la consultoria i amb uns companys d'equip molt preparats.
Full text
id183228 IMPLANTACIÓ DEL CRM SALESFORCE PER L'EMPRESA SERVILUSA PERE ARNAU ALEGRE BALTASAR Director/a: ENRICMAYOLSARROCA(KonozcaConsultingSL) Titulació:GrauenEnginyeriaInformàtica(Sistemesd'informació) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 15/05/2024
Índex de continguts 1. Contextualització i Abast ................................................................................................... 1 1.1. Context ......................................................................................................................... 1 1.1.1. Introducció ........................................................................................................... 1 1.1.2. Termes i conceptes ............................................................................................. 2 1.1.3. Problema a resoldre ............................................................................................ 3 1.1.4. Stakeholders ....................................................................................................... 4 1.2. Justificació ................................................................................................................... 5 1.2.1. Solucions existents ............................................................................................. 5 1.2.2. Solució escollida ................................................................................................. 6 1.3. Abast ............................................................................................................................ 7 1.3.1. Objectius principals ............................................................................................. 8 1.3.2. Objectius secundaris ........................................................................................... 8 1.3.3. Competències tècniques .................................................................................... 9 1.3.4. Obstacles principals i riscs ................................................................................ 10 1.4. Metodologia ................................................................................................................ 11 1.4.1. Tipus de metodologia ........................................................................................ 11 1.4.2. Eines de seguiment ........................................................................................... 12 2. Planificació ........................................................................................................................ 14 2.1. Descripció de les Tasques del Projecte ..................................................................... 15 2.1.1. Gestió del Projecte ............................................................................................ 15 2.1.2. Desenvolupament ............................................................................................. 16 2.1.3. Go Live i Manteniment ...................................................................................... 19 2.3. Recursos .................................................................................................................... 19 2.3.1. Recursos Humans ............................................................................................. 19 2.3.2. Recursos Materials ........................................................................................... 20 2.3.3. Recursos de Software ....................................................................................... 20 2.4. Taula Resum .............................................................................................................. 20 2.4. Diagrama de Gant ...................................................................................................... 23 2.5. Gestió de Riscs .......................................................................................................... 24 2.5.1. Riscs Organitzacionals ...................................................................................... 24 2.5.2. Riscs d’Implementació ...................................................................................... 25 2.5.3. Riscs de Tecnologia .......................................................................................... 25 3. Gestió Econòmica ............................................................................................................. 27 3.1. Identificació i Estimació de Costs .............................................................................. 27 3.1.1. Recursos de Personal ....................................................................................... 27 3.1.2. Costs materials ................................................................................................. 29 3.1.3. Costs indirectes ................................................................................................. 30 3.1.4. Contingències ................................................................................................... 30 3.1.5. Imprevistos ........................................................................................................ 30 3.1.6. Pressupost Final ............................................................................................... 31 3.2. Control de Gestió ....................................................................................................... 31 4. Informe de sostenibilitat .................................................................................................. 33
4.1. Dimensió Ambiental ................................................................................................... 34 4.2. Dimensió Econòmica ................................................................................................. 34 4.3. Dimensió Social ......................................................................................................... 35 5. Arquitectura del Sistema .................................................................................................. 36 6. Eines de Salesforce .......................................................................................................... 39 7. Contractació ...................................................................................................................... 41 7.1. Presa de Requisits ..................................................................................................... 41 7.2. Característiques del Sistema ..................................................................................... 43 7.2.1. Requisits Funcionals i Casos d’ús .................................................................... 43 7.2.2 Requisits no Funcionals [41] .............................................................................. 51 7.3. Esquemes conceptuals .............................................................................................. 51 7.3.1. Esquema conceptual de l'objecte cas ............................................................... 51 7.3.2. Esquema conceptual de l'objecte Servei .......................................................... 54 7.3.2. Esquema conceptual de l'objecte Compte ........................................................ 55 7.4. Disseny Lògic ............................................................................................................. 57 7.4.1. Construcció de la Base de Dades en Salesforce .............................................. 61 7.5. Descripció de Taules .................................................................................................. 66 7.6. Interfícies d’Usuari ..................................................................................................... 79 7.6.1. Interfícies dels Serveis ...................................................................................... 79 7.6.3. Interfícies de Clients .......................................................................................... 84 7.6.4. Interfícies de Difunts ......................................................................................... 85 7.6.5. Interfície d’Interlocutor ....................................................................................... 87 7.7. Desenvolupament de les Funcionalitats .................................................................... 88 7.7.1. Regles de Validació ........................................................................................... 88 7.7.2. Configuració de Perfils i permisos ..................................................................... 90 7.7.3. Automatisme per als Codis Postals .................................................................. 90 7.7.4. Configuració dels Permisos .............................................................................. 94 7.8. Desenvolupament de la Integració Salesforce - Serviout ........................................ 100 7.8.1. Creació de l’objecte Log__c ............................................................................ 102 7.8.2. Desenvolupament de Codi .............................................................................. 103 7.8.3. Desenvolupament del Flux de Pantalla ........................................................... 105 7.9. Tests ......................................................................................................................... 111 8. Post-Contractació ........................................................................................................... 118 8.1. Presa de Requisits ................................................................................................... 118 8.2. Característiques del Sistema ................................................................................... 120 8.2.1. Requisits Funcionals i Casos d’ús .................................................................. 120 8.3. Esquemes Conceptuals ........................................................................................... 133 8.4. Disseny Lògic ........................................................................................................... 134 8.5. Descripció de les Taules .......................................................................................... 135 8.6. Interfícies d’Usuari ................................................................................................... 141 8.6.1. Interfícies dels Pressuposts, Línies de Pressupost i Productes ...................... 141 8.6.2. Interfície de Tasques ....................................................................................... 144 8.7. Desenvolupament de la Integració .......................................................................... 147 8.7.1. Web Service d’Autenticació ............................................................................ 149
8.7.2. Creació i Modificació (Upsert) de Clients ........................................................ 150 8.7.3. Creació i Modificació (Upsert) de Difunts ........................................................ 155 8.7.4. Creació i modificació (Upsert) de Serveis ....................................................... 155 8.7.5. Creació i Modificació (Upsert) d’Interlocutors ................................................. 160 8.7.6. Creació i Modificació (Upsert) de Pressuposts i Línies de Pressupost ........... 161 8.6.7. Pujada de Documents PDF de Pressupost ..................................................... 162 8.8. Desenvolupament de les Funcionalitats .................................................................. 168 8.8.1. Configuració de Camps Fórmula .................................................................... 168 8.8.2. Configuració de les Tasques de Post-Contractació ........................................ 175 8.8.3. Configuració dels Permisos ............................................................................ 180 8.9. Tests ......................................................................................................................... 184 9. Contact Center ................................................................................................................ 185 9.1. Resum de la Implementació .................................................................................... 185 10. Conclusions .................................................................................................................. 188 10.1. Objectius Assolits ................................................................................................... 188 10.2. Dificultats trobades ................................................................................................ 188 10.3. Aprenentatge Adquirit ............................................................................................ 189 11. Bibliografia .................................................................................................................... 190 Índex de figures Figura 1.1: Gràfica de quota de mercat en el temps dels diferents CRM ................................ 2 Figura 1.2 : Procés Scrum ...................................................................................................... 12 Figura 1.3: Diagrama de Gantt. ............................................................................................. 23 Figura 5.1: Diagrama del patró de disseny Model Vista Controlador. .................................... 37 Figura 5.2: Diagrama dels sistemes participants en el flux de processos de Salesforce ...... 38 Figura 7.1: Diagrama del procés de contractació de Serveis en Salesforce ......................... 42 Figura 7.2: Jerarquia d’usuaris en Servilusa .......................................................................... 43 Figura 7.3: Esquema dels Rols de Servilusa ......................................................................... 44 Figura 7.4: Diagrama de casos d’ús per als Casos ............................................................... 45 Figura 7.5: Diagrama de casos d’ús per als Serveis ............................................................. 46 Figura 7.6: Diagrama de casos d’ús per als Comptes ........................................................... 47 Figura 7.7: Diagrama de casos d’ús per als Interlocutors ...................................................... 48 Figura 7.8: Diagrama UML de l’objecte Cas .......................................................................... 52 Figura 7.9: Diagrama UML de les subclasses de l’objecte Cas ............................................. 53 Figura 7.10: Diagrama UML de l’objecte Servei .................................................................... 54 Figura 7.11: Diagrama UML de les subclasses de l’objecte Servei ....................................... 55 Figura 7.12: Diagrama UML de l’objecte Account ................................................................. 56 Figura 7.13: Diagrama del disseny lògic dels objectes del sistema ....................................... 60 Figura 7.14: Informació general de l’objecte Account en Salesforce ..................................... 61 Figura 7.15: Informació de camps de l’objecte Account en Salesforce ................................. 62 Figura 7.16: Especificació de l’atribut Lares Falecido de l’objecte Account en Salesforce ... 63 Figura 7.17: Interfície de configuració de tipus de registres (RecordTypes) de l’objecte
Account en Salesforce ............................................................................................................ 65 Figura 7.18: Capçalera de la interfície de Serveis ................................................................. 79 Figura 7.19: Secció de detalls dins d’interfície de Serveis ..................................................... 81 Figura 7.20: Configuració de dependències en el Lightning Page Builder per als camps de cremació en la interfície de Serveis ........................................................................................ 83 Figura 7.21: Llista relacionada dels historials d’un servei ...................................................... 83 Figura 7.22: Capçalera de la interfície de Clients .................................................................. 84 Figura 7.23: Secció de detalls de la interfície de Clients ....................................................... 85 Figura 7.24: Secció de detalls de la interfície de Difunts ....................................................... 86 Figura 7.25: Secció de detalls de la interfície d’Interlocutors ................................................. 87 Figura 7.26: Interfície de configuració per la VR Motivo Cerrado no Informado .................... 88 Figura 7.27: Interfície de configuració del missatge d’error per la regla de validació Motivo Cerrado no Informado ............................................................................................................. 89 Figura 7.28: Exemple d’error en l’edició d’un cas per la regla de validació Motivo Cerrado no Informado ................................................................................................................................ 89 Figura 7.29: Interfície de l’objecte codi postal ........................................................................ 91 Figura 7.30: Exemple de procés d’afegir un codi postal en un Compte ................................ 91 Figura 7.31: Exemple de taula de CPs que es genera en buscar-ne un per afegir ............... 92 Figura 7.32: Flux disparador per a la funcionalitat d’emplenar els camps de direcció en afegir un codi postal ................................................................................................................ 92 Figura 7.33: Configuració del component d’assignació dels atributs de direcció a partir d’un codi postal dins el flux ............................................................................................................. 93 Figura 7.34: Rols de Servilusa definits en Salesforce ........................................................... 94 Figura 7.35: Configuració dels permisos del perfil TC per a l’objecte Servei ........................ 95 Figura 7.36: Configuració de les Sharing Settings per a l’objecte Caso ................................ 95 Figura 7.37: Exemple de configuració permisos a nivell de camp per a l’objecte Servei ...... 96 Figura 7.38: Configuració dels permisos del perfil TC per a l’objecte Account ...................... 97 Figura 7.39: Configuració la Regla de Validació per evitar la creació de comptes no personals per a usuaris no administradors ............................................................................. 98 Figura 7.40: Configuració dels permisos del perfil TC per a l’objecte Historial ...................... 99 Figura 7.41: Esquema de la integració Salesforce-Serviout ................................................ 102 Figura 7.42: Capçalera de la interfície de Servei amb el botó Enviar a Serviout ................. 105 Figura 7.43: Flux de pantalla per als enviaments a Serviout ............................................... 107 Figura 7.44: Exemple de pantalla indicant un enviament no possible ................................. 108 Figura 7.45: Exemple de pantalla indicant un enviament correcte d’un servei a Serviout ... 108 Figura 7.46: Exemple de Log generat per l’enviament d’un Servei a Serviout .................... 109 Figura 7.47: Exemple de pantalla indicant que l’usuari requereix un identificador de Serviout per a poder efectuar enviaments .......................................................................................... 109 Figura 7.48: Exemple de pantalla indicant un error Apex en l’enviament a Serviout ........... 110 Figura 7.49: Exemple de pantalla indicant un error de Web Service en l’enviament a Serviout ................................................................................................................................. 110 Figura 7.50: Exemple de pantalla indicant un error per falta de dades en el Servei ............ 110 Figura 7.51: Pàgina d'un conjunt de canvis dins Salesforce ................................................ 112 Figura 7.52: Interfície de depuració inicial per a un flux de pantalla .................................... 113 Figura 7.53: Interfície de depuració per a un flux de pantalla .............................................. 113 Figura 7.54: Interfície inicial de depuració per a un flux disparador ..................................... 114
Figura 7.55: Diagrama de depuració per a un flux disparador ............................................. 115 Figura 7.56: Interfície de depuració de la Developer Console ............................................. 116 Figura 7.57: Visualització del Code Coverage d’una classe de test en una classe Apex .... 117 Figura 8.1: Diagrama del procés de post-contractació entre els sistemes Serviout i Salesforce. ............................................................................................................................ 119 Figura 8.2: Diagrama núm. 1 de processos per a la generació de les tasques de post-contractació. Elaboració pròpia. .................................................................................... 123 Figura 8.3: Diagrama núm. 2 de processos per a la generació de les tasques de post-contractació. .................................................................................................................. 125 Figura 8.4: Diagrama UML dels nous objectes afegits al sistema per la fase de post-contractació. .................................................................................................................. 133 Figura 8.5: Diagrama del disseny lògic dels nous objectes afegits al sistema per la fase de post-contractació. .................................................................................................................. 134 Figura 8.6: Interfície del serveis amb la llista relacionada dels Pressuposts. ...................... 141 Figura 8.7: Interfície dels Pressuposts. ................................................................................ 142 Figura 8.8: Interfície de les Línies de Pressupost. ............................................................... 143 Figura 8.9: Interfície dels Productes. ................................................................................... 144 Figura 8.10: Interfície de les Tasques.. ................................................................................ 145 Figura 8.11: Configuració en Lightning Page dels botons de la interfície de les tasques. ... 146 Figura 8.12: Pipeline de l’enviament d'objectes entre Serviout - Salesforce. ...................... 148 Figura 8.13: Interfície del Post-Man amb la configuració per a recollir la clau d’accés per als enviaments a Salesforce. ...................................................................................................... 149 Figura 8.14: Interfície del Post-Man amb l’endpoint per al web service d’enviament de clients. ................................................................................................................................... 150 Figura 8.15: Flux de gestió dels camps LookUp de la integració dels registres de clients i difunts. .................................................................................................................................. 154 Figura 8.16: Flux de gestió dels camps LookUp per integració dels registres de serveis. .. 159 Figura 8.17: Camí temporal del flux disparador en Pressuposts. ........................................ 165 Figura 8.18: Pantalla de configuració del camp IVA de Pressuposts. ................................. 168 Figura 8.19: Pantalla de configuració del camp Sub-Total de Pressuposts. ........................ 169 Figura 8.20: Pantalla de configuració del camp Desconto Total de Pressuposts. ............... 170 Figura 8.21: Pantalla de configuració del camp Total a Pagar de Pressuposts. .................. 170 Figura 8.22: Pantalla de configuració del camp Sub-total Unitario de Línia Pressupost. .... 171 Figura 8.23: Pantalla de configuració del camp Sub-Total de Pressuposts. ........................ 172 Figura 8.24: Pantalla de configuració del camp Valor Total de Pressuposts. ...................... 172 Figura 8.25: Pantalla de configuració del camp Valor Imposto de Línia de Pressupost. ..... 173 Figura 8.26: Pantalla de configuració del camp Desconto Total de Línies de Pressupost. . 174 Figura 8.27: Pantalla de configuració del camp IVA de Pressuposts. ................................. 175 Figura 8.28: Flux de pantalla per a la tasca Pedido Assento de Óbito. ............................... 177 Figura 8.29: Capçalera de la interfície de la tasca Pedido Assento de Óbito. ..................... 178 Figura 8.30: Pantalla per pujar l’arxiu Requisit de Certificats. ............................................. 178 Figura 8.31: Pantalla per seleccionar el tipus de Assento de Óbito. ................................... 179 Figura 8.32: Configuració de permisos per l’objecte Pressupost. ........................................ 181 Figura 8.33: Configuració de permisos per l’objecte Producte. ........................................... 182 Figura 8.34: Configuració de la regla de validació per garantir els permisos correctes d’edició per a les tasques de Post-Contractació. .................................................................. 183
Figura 9.1: Diagrama de processos en rebre una trucada en el Contact Center. ................ 186 Figura 9.2: Interfície de l’objecte Formulari. ......................................................................... 187 Índex de taules Taula 1.1: Taula comparativa entre les diferents solucions disponibles ................................... 6 Taula 1.2: Dates planificades per etapa i fase. ...................................................................... 15 Taula 2.1: Estimació d'hores, recursos i dependències de cada tasca. ................................. 22 Taula 2.2: Resum dels riscs del projecte, el seu impacte i la seva probabilitat. ..................... 26 Taula 3.1: Sous mitjans dels diferents rols del projecte en l’àmbit laboral espanyol. ............. 27 Taula 3.2: Cost dels recursos humans del projecte. .............................................................. 29 Taula 3.3: Cost dels recursos materials del projecte. ............................................................. 29 Taula 3.4: Cost dels recursos indirectes del projecte. ............................................................ 30 Taula 3.5: Cost de contingències. .......................................................................................... 30 Taula 3.6: Cost d’imprevistos. ................................................................................................ 31 Taula 3.7: Pressupost final. .................................................................................................... 31 Taula 4.1: Matriu de sostenibilitat ........................................................................................... 34 Taula 7.1: Especificació Brief Style de la funcionalitat de crear un client o difunt en un cas o servei. ..................................................................................................................................... 49 Taula 7.2: Especificació Brief Style de la funcionalitat d’enviar un servei a Serviout. ............ 49 Taula 7.3: Especificació Brief Style de la funcionalitat d’afegir un codi postal. ...................... 49 Taula 7.4: Especificació Brief Style de la funcionalitat de Crear un Compte Personal a través d’un interlocutor. ...................................................................................................................... 50 Taula 7.5: Especificació Brief Style de la funcionalitat de Vincular un Compte Personal en un Interlocutor. ............................................................................................................................. 51 Taula 7.6: Tipus de camps disponibles en Salesforce. .......................................................... 65 Taula 7.7: Especificació dels atributs de l’objecte Servei. ...................................................... 71 Taula 7.8: Especificació dels atributs de l’objecte Compte Personal. .................................... 74 Taula 7.9: Especificació dels atributs de l’objecte Compte. ................................................... 76 Taula 7.9: Especificació dels atributs de l’objecte Interlocutor. .............................................. 78 Taula 7.11: Taula de dependències per als camps de cremació en la interfície de Serveis. . 82 Taula 7.12: Taula d’atributs de l’objecte Log. ....................................................................... 103 Taula 8.1: Especificació Brief Style de la tasca “Obter Documentação” .............................. 126 Taula 8.2: Especificació Brief Style de la tasca “Pedido Assento de Óbito” ......................... 127 Taula 8.3: Especificació Brief Style de la tasca “Assignar Usuario Pedido [tipo] Assento Obito” .................................................................................................................................... 127 Taula 8.4: Especificació Brief Style de la tasca “Carregar Assento Óbito [tipo]” .................. 128 Taula 8.5: Especificació Brief Style de la tasca “Registar Óbito” ......................................... 129 Taula 8.6: Especificació Brief Style de la tasca “Pedido Outros Assentos” .......................... 130 Taula 8.7: Especificació Brief Style de la tasca “Assignar Usuario Pedido [tipo] Assento [outros]” ................................................................................................................................. 130 Taula 8.8: Especificació Brief Style de la tasca “Carregar Assento [outros] [tipo]” .............. 131 Taula 8.9: Especificació Brief Style de la tasca “Envio do registo de Óbito ao Cliente” ....... 131 Taula 8.10: Especificació Brief Style de la tasca “Validar Orçamento em Serviout” ............ 132 Taula 8.11: Especificació dels atributs de l’objecte Pressupost ........................................... 137
Taula 8.12: Especificació dels atributs de l’objecte Línia de Pressupost ............................. 138 Taula 8.13: Especificació dels atributs de l’objecte Producte ............................................... 139 Taula 8.14: Especificació dels atributs de l’objecte Tasca .................................................... 140 Taula 8.15: Especificació dels camps obligatoris en crear/modificar un client. .................... 151 Taula 8.16: Especificació del camp SERV_RecordTypeShort_aux__c per indicar el tipus de servei. ................................................................................................................................... 156 Taula 8.17: Especificació dels camps obligatoris en crear/modificar un servei. ................... 157 Taula 8.18: Especificació dels camps obligatoris en crear/modificar un interlocutor. ........... 160 Taula 8.19: Especificació de camps obligatoris en crear/modificar un Pressupost. ............. 162 Taula 8.20: Especificació de camps obligatoris en crear/modificar una Línia Pressupost. .. 162 Índex de codi Codi 7.1: Definició de l’esquema de la base de dades de Salesforce per l’etapa de Contractació. ........................................................................................................................... 59 Codi 7.2: Fórmula per a la regla de validació d’informar el motiu d’anul·lació. ...................... 90 Codi 7.3: Funció getAccessToken per a recollir la clau d’autenticació al web service de Serviout. ................................................................................................................................ 103 Codi 7.4: Funció callCreateRegServiout per a efectuar enviaments mitjançant web service a Serviout. ................................................................................................................................ 104 Codi 7.5: Classe Apex SendtoServiout per a habilitar els enviaments a Serviout a través d’un Flux de Salesforce. ....................................................................................................... 105 Codi 7.6: Classe CallToWSTest per a passar les validacions unitàries de les classes usades pels enviaments a Serviout. .................................................................................................. 116 Codi 8.1: Definició de l’esquema de la base de dades de Salesforce per l’etapa de Post-Contractació. ................................................................................................................ 135 Codi 8.2: JSON de resposta del web service d’autenticació de Salesforce. ........................ 150 Codi 8.3: JSON del body del web service de upsert d’un client. .......................................... 151 Codi 8.4: JSON de resposta del web service de upsert d’un client. .................................... 151 Codi 8.5: JSON del body del web service de upsert d’un difunt. ......................................... 155 Codi 8.6: JSON del body del web service de upsert d’un servei. ........................................ 156 Codi 8.7: JSON del body del web service de upsert d’interlocutors. ................................... 160 Codi 8.8: JSON de resposta del web service de upsert d’interlocutors. .............................. 161 Codi 8.9: JSON del body del web service de upsert de pressuposts amb línies. ................ 161 Codi 8.10: JSON del body del web service de pujada de documents. ................................ 163 Codi 8.11: JSON de resposta del web service de pujada de documents. ........................... 164 Codi 8.12: Classe Apex DeleteDuplicateDocsFlow, invocable des de fluxos. ..................... 166
Resum El següent projecte consisteix en la implantació d’un sistema de gestió de relacions amb el client o Client Relationship Manager (CRM) per a l’empresa funerària Servilusa. El projecte es durà a terme en l’empresa Konozca Consulting, on juntament amb un equip de 4 persones més, plantejarem, desenvoluparem i implantarem aquest sistema. Amb la realització d’aquest projecte es pretén posar en pràctica els meus coneixements d’enginyer informàtic adquirits durant la meva formació en la Facultat d’Informàtica de Barcelona. També podré adquirir noves habilitats i experiència en poder treballar amb una empresa amb molt recorregut en l’àmbit de la consultoria i amb uns companys d’equip molt preparats. Resumen El siguiente proyecto consiste en la implantación de un sistema de gestión de relaciones con el cliente o Client Relationship Manager (CRM) para la empresa funeraria Servilusa. El proyecto se llevará a cabo en la empresa Konozca Consulting, donde junto a un equipo de 4 personas más, plantearemos, desarrollaremos e implantaremos este sistema. Con la realización de este proyecto se pretende poner en práctica mis conocimientos de ingeniero informático adquiridos durante mi formación en la Facultad de Informática de Barcelona. También podré adquirir nuevas habilidades y experiencia al poder trabajar con una empresa con mucho recorrido en el ámbito de la consultoría y con unos compañeros de equipo muy preparados. Abstract The following project consists of implementing a Customer Relationship Management (CRM) system for the funeral company Servilusa. The project will be carried out at Konozca Consulting, where, along with a team of 4 more people, we will plan, develop, and implement this system. While working on this project, the aim is to put into practice my computer engineering knowledge acquired during my education at the Faculty of Computer Science of Barcelona (FIB). Additionally, I will be able to acquire new skills and experience by working with a company with extensive experience in the consulting field and with highly capable team members.
D’altra banda, tampoc sembla una solució viable realitzar canvis en l’aplicació web actual de l’empresa (Serviout), per, en gran part els mateixos motius pels quals no desenvoluparem una aplicació personalitzada. Modificar l’aplicació web per incorporar els canvis necessaris requeriria una gran inversió de temps i recursos econòmics. A més a més, no s’adaptaria al problema a excepció de canviar moltes funcionalitats principals de l’aplicació, el que podria causar corrupció de dades existents o rebuig per part dels usuaris si no s’apliquessin els canvis de forma correcta. Com a solucions existents més atractives tenim implantar un sistema CRM amb les funcionalitats i arquitectura bàsiques ja desenvolupades per a poder després adaptar i implementar noves funcionalitats i arquitectura de dades. En la taula s’ha comparat Salesforce i Oracle CX. En molts aspectes ambdós sistemes surten emparats, però Salesforce acaba destacant en uns punts clau [11] . En un punt on Salesforce destaca per sobre d'Oracle CX, és en la seva eina d’automatismes low code anomenada Flows. Oracle disposa també d’una eina d’automatismes, però aquesta té una funcionalitat molt limitada amb la possibilitat sols de realitzar accions predefinides i tampoc admet Disparadors (Triggers) a diferència de Salesforce. En altres aspectes on Salesforce destaca per sobre d’Oracle CX és en la seguretat, ja que Salesforce incorpora una aplicació per a la doble autenticació molt senzilla de configurar pels usuaris i gestionar pels administradors. A més a més, Salesforce utilitza algunes de les tecnologies més avançades de seguretat a Internet disponibles actualment. Salesforce usa Transport Layer Security (TLS) per protegir la informació que viatja pels servidors web mitjançant l'autenticació del servidor i el xifratge clàssic, assegurant que les dades estiguin segures. Salesforce també està allotjat en un entorn de servidor segur que utilitza molts firewalls i altres tecnologies avançades per evitar interferències o accés d'intrusos externs. [12] Per acabar de ratificar l’avantatge de Salesforce respecte a Oracle CX podem analitzar els estudis de Gartner respecte del mercat dels CRM resumits en el seu característic Quadrant Màgic de Gartner. Segons Gartner, Salesforce es posiciona com a líder indiscutible per sobre d’Oracle CX i altres CRM conjuntament com a sistema i en diferents aspectes puntuals com en Customer Engagement [13] , Low Code Applications [14] , Automation Platforms [15] i moltes més. Per ser totalment transparents, el sistema a implantar va ser escollit per Memora, una funerària espanyola que va comprar Servilusa uns anys enrere. Memora va escollir Salesforce donat que aquest mateix CRM es el que actualment usen ells i estan altament satisfets. En ser Memora clients de Konozca, ens van assignar a nosaltres la implantació d’aquest sistema. Tot i això, per l’estudi anteriorment presentat, Salesforce és la millor solució als problemes que presenta Servilusa. 1.3. Abast Un cop introduït el problema a resoldre, serà importat definir els objectius que es volen assolir per a poder dissenyar una bona planificació de les tasques a desenvolupar, dels recursos necessaris i per a plantejar possibles riscs. 7
1.3.1. Objectius principals L’objectiu principal del projecte és la implantació d’un CRM per als equips d'atenció al client, comercial, postvenda i qualitat, amb l'objectiu d'optimitzar i unificar els seus processos i eines utilitzades als diferents territoris de Servilusa, de manera que puguin utilitzar una plataforma única tant per als processos de relació amb el client, d’obtenció de clients i de servei postvenda. Per a proveir d’una idea general dels processos i objectius del sistema, s’han desenvolupat diagrames de processos per a l’esquematització dels objectius amb les principals funcionalitats. 1. En l’àmbit d'obtenció de clients es busca poder enregistrar tots els contactes entre els clients interessats i els comercials i analitzar quins són els clients amb més potencial per centrar els esforços de comunicació en ells. A més a més, es busca poder guardar totes les dades possibles del client per a poder oferir una millor assessoria de serveis. 2. Passant a l’àmbit de contractació i gestió dels serveis, es busca poder enregistrar les dades principals sobre les empreses que treballen amb Servilusa, les dades de clients i difunts i les dades dels serveis i altra informació relacionada amb els serveis. Així com poder disposar d’un sistema de navegabilitat que ens permeti identificar els registres relacionats entre si i el tipus de relació. 3. Finalment, en els aspectes de post contractació, es busca poder estandarditzar tot el procés de realització de tasques de gestió del servei, com, per exemple, contactar amb les empreses encarregades d’altres serveis, recollida de documentació necessària, contacte amb clients i familiars, etc. Per aconseguir aquest objectiu, implantarem Salesforce, el millor CRM existent en el mercat, segons el presentat en la introducció del treball (Figura 1) i també segons les comparatives i justificacions presentades en l’estat de l’art. També sent aquest el CRM amb el que treballa la consultoria de la qual formo part. Per abordar les necessitats del client, haurem d’adaptar molt detalladament el sistema en aspectes de model de dades, automatismes, interfícies i més. 1.3.2. Objectius secundaris Com a objectius secundaris en definirem per a millorar l’experiència d’usuari, per a mantenir un nivell de seguretat de dades pel que fa a usuaris de l’organització i també per a validar dades introduïdes per usuaris. Per a millorar l’experiència d’usuari, adaptarem moltes interfícies d’objectes del sistema a objectes ja presents a Serviout perquè la usabilitat entre els 2 sistemes sigui el més consistent possible. També crearem botons personalitzats per a facilitar la creació d’objectes, automatismes per introduir dades implícites en objectes, etc. 8
Per mantenir un nivell de seguretat de dades i sols garantir l’accés a les dades corresponents a cada usuari, implementarem una sèrie de perfils i rols assignats als diferents usuaris i configurarem els permisos d'accés, a nivell d’objecte i atribut, necessaris per a cada perill o rol. Finalment per a validar les dades introduïdes pels usuaris crearem dependències a nivell d’atributs d’objectes i regles de validació. 1.3.3. Competències tècniques Per aquest projecte de sistemes d’informació les competències tècniques escollides van ser: ● CSI1: Demostrar comprensió i aplicar els principis i les pràctiques de les organitzacions, de manera que puguin exercir d'enllaç entre les comunitats tècniques i de gestió d'una organització, i participar activament en la formació dels usuaris. En aquest projecte d’implantació de Salesforce es realitza una extensa enginyeria de requisits per a dissenyar el sistema que millor s’adapta a les necessitats del client. Se segueix també amb el disseny d’unes interfícies que faciliten moltíssim el seu ús i comprensió. A més a més, usant la metodologia agile , garantim una correcta implementació dels processos i acceptació de l’usuari. ● CSI2.2: Concebre, desplegar, organitzar i gestionar sistemes i serveis informàtics, en contextos empresarials o institucionals, per a millorar-ne els processos de negoci; responsabilitzar-se'n i liderar-ne la posada en marxa i la millora contínua; valorar el seu impacte econòmic i social. Aquesta competència s’assoleix amb el fet que estem implantant un nou sistema CRM per a Servilusa per a millorar els seus processos de negoci, en concret, l'adquisició de clients, contractació i post-contractació de serveis. També realitzem la posada en marxa i supervisem la millora continua implantant un sistema altament escalable, fent ús de les bones praxis de desenvolupament. ● CSI2.5: Demostrar coneixement i capacitat d'aplicació dels sistemes d'informació empresarial (ERP, CRM, SCM, etc.). Aquesta competència s’assoleix amb el fet que estem implantant un nou sistema CRM, amb tots els processos que això implica; presa de requisits, disseny d’esquemes conceptuals, disseny de la base de dades, configuració de permisos, desenvolupament de funcionalitats personalitzades, etc. ● CSI2.6: Demostrar coneixement i capacitat d'aplicació dels sistemes d'ajuda a la presa de decisions i de bussines intelligence. En aquest treball no es tracta tant aquest tema, però s’imposen les bases per a poder aplicar eines de Salesforce de business intelligence en una pròxima etapa com són els informes, avisos temporals, recomanacions automàtiques, etc. En aquesta primera etapa sí que s’afegeix estats en els casos i serveis el que facilita el seguiment d’aquests. 9
● CSI4.1: Participar activament en l'especificació dels sistemes d'informació i de comunicació. En aquest projecte es realitza una extensiva enginyeria de requisits per a poder plantejar i desenvolupar satisfactòriament el CRM Salesforce per a les necessitats de Servilusa. ● CSI3.4: Desenvolupar solucions de negoci mitjançant la implantació i la integració de hardware i software. Per aquest projecte es realitza la integració amb l’actual sistema de contractació de Servilusa, per la qual es requerirà la configuració i desenvolupament d’un web service personalitzat dins de Salesforce per a enviar i rebre dades de la plataforma. ● CSI3.5: Proposar i coordinar canvis per a millorar l'explotació del sistema i de les aplicacions. Com a un dels desenvolupadors principals del projecte i l’encarregat de totes les integracions amb aplicacions externes, va ser la meva responsabilitat coordinar els canvis necessaris per adaptar tant Salesforce com el sistema extern per garantir una correcta sincronització i assolir les necessitats del client. En altres aspectes del sistema, la meva experiència amb Salesforce també va ser d’ús en proposar solucions als diferents requisits del client. ● CSI4.2: Participar activament en el disseny, la implementació i el manteniment dels sistemes d'informació i de comunicació. Aquesta competència s’assoleix pels mateixos motius que s’assoleixen les anteriors competències. En aquest projecte s’implanta un CRM des de zero, i es documenta totes les etapes del procés, des de la presa de requisits, passant pel desenvolupament i finalment els test d’acceptació d’usuari. 1.3.4. Obstacles principals i riscs En aquest apartat es llisten els principals obstacles i riscs del projecte. En l’apartat 2.5 es proporciona una descripció més detallada d’aquests. ● Rebuig del CRM per part dels Usuaris. Aquest fenomen succeeix quan els usuaris no fan un bon ús o directament no usen el sistema per falta de coneixements o per falta de motivació. ● Retards en les entregues del sistema. Els retards en les entregues poden succeir per una mala planificació, per manca de recursos o per un plantejament incorrecte del desenvolupament a seguir. Pot arribar a provocar conflictes entre en client i l’empresa. ● Processos de negoci poc clars per part del client. Aquest és un risc molt comú donat per a poca comunicació entre diferents àrees del negoci. ● Processos de negoci mal definits per part dels consultors. ● Errors en el sistema produïts per bugs. Els errors en el sistema provocats per una programació incorrecta són molt comuns en desenvolupament de software i poden arribar a provocar retards en entregues o pèrdua de dades. 10
1.4. Metodologia 1.4.1. Tipus de metodologia L'elecció d'una bona metodologia de treball en un projecte de software impacta directament en l'eficiència, qualitat i èxit general del projecte. L'elecció s'ha de basar en les característiques del projecte, l'equip i les expectatives del client per maximitzar les possibilitats de complir amb els objectius establerts. [16] Per al nostre projecte s’ha escollit seguir una metodologia Agile de tipus Scrum donats tots els beneficis que ens aporta en molts aspectes tant organitzatius com tècnics. Els beneficis que aporta Scrum versus una metodologia més tradicional com la Waterfall són: ● Flexibilitat i Adaptabilitat: Scrum es basa en la filosofia àgil, fet que significa que s'adapta fàcilment a canvis en els requisits, prioritats o condicions del projecte. A diferència de les metodologies tradicionals, que tendeixen a ser rígides i requereixen una planificació detallada des del principi. Aquest aspecte ens ajudarà a adaptar-nos millor a una empresa tan gran com Servilusa en la que entren en joc molts departaments, directius i tècnics comercials. ● Lliurament Incremental: A Scrum, el treball es divideix en iteracions anomenades sprints . Al final de cada sprint, es presenta al client totes les novetats i canvis en el sistema. Això ens permetrà obtenir retroalimentació del client i ajustar la planificació del projecte i aconseguir una millora continua. ● Col·laboració Intensiva: Scrum promou la col·laboració constant entre tots els membres de l'equip, incloent-hi desenvolupadors, dissenyadors, stakeholders i el client. Les reunions diàries (Dailys) i altres esdeveniments de Scrum ens ajudaran a mantenir-nos al dia de tot el progrés del projecte i a millorar la comunicació i confiança dins l’equip. ● Enfocament al Client: Scrum posa un gran èmfasi a satisfer les necessitats del client. Tenint lliuraments funcionals a cada sprint, el client pot veure i usar el software en desenvolupament i proporcionar retroalimentació. ● Reducció de Riscos: El lliurament incremental i les revisions freqüents del client permeten identificar riscos i problemes primerencs, així com casuístiques no contemplades. Això facilita la mitigació de problemes abans que es tornin crítics. ● Motivació de l'equip: Scrum promou l'autogestió i la responsabilitat de l'equip. Tindrem la possibilitat de prendre petites decisions segons el nostre criteri sense haver de consultar-ho amb el client o amb altres membres. Aquesta capacitat ens ajudarà a avançar de forma més dinàmica i ràpida i a tenir més autonomia. ● Ràpida rendibilitat d'Inversió: En lliurar funcionalitats en cicles curts, Scrum pot proporcionar un retorn d'inversió més ràpid per als stakeholders, ja que poden utilitzar i beneficiar-se de parts del programari abans que es completi tot el projecte. 11
Figura 1.2: Procés Scrum [17] En resum, Scrum aporta beneficis substancials en enfocar-se en la flexibilitat, la col·laboració, la satisfacció del client i la millora contínua, en comparació de les metodologies tradicionals que tendeixen a ser més rígides i orientades cap a la planificació detallada des del principi. [18] En el nostre equip la jerarquia scrum seguida va ser: ● Product Owner: El responsable de definir els elements del producte, prioritzar-los i assegurar-se que l'equip de desenvolupament entengui els requisits del producte. En el nostre projecte el product owner també va ser la Project Manager. ● Scrum Master: És responsable de garantir que l'equip de desenvolupament segueixi els principis i les pràctiques de Scrum. Actua com a facilitador, eliminant obstacles i ajudant l'equip a assolir els objectius. En el nostre projecte el consultor amb més experiència va acollir aquest rol. ● Equip de Desenvolupament: Són els professionals encarregats de lliurar increment de producte al final de cada Sprint. Són autoorganitzats i multifuncionals. En aquest cas, el reste de membres de l’equip vam acollir aquest rol. Formant així un equip de 2 desenvolupadors i 1 consultor. Així doncs, el meu rol dins el projecte ha estat de desenvolupador del sistema. Encarregat del procés de planificació, disseny i desenvolupament a part de donar suport en altres tasques com la presa de requisits, i suport a altres companys. En els següents apartats de planificació es detallarà més en profunditat les tasques dutes a terme. 1.4.2. Eines de seguiment Les eines de seguiment en el desenvolupament de software ens ajudaran a mantenir el control, l'organització i la comunicació en el procés de desenvolupament. Ens ajudaran a nivell d’equip a treballar de manera més eficient, a mantenir-nos en el camí correcte i a lliurar un sistema d'alta qualitat en el temps previst. [19] 12
Les eines que usarem en aquest projecte són: ● Google Chat: Google Chat és una eina que permetrà la comunicació a través de xat de text entre membres de l'equip en cas de no estar treballant presencialment en les oficines. ● Google Meet: Google Meet ens habilitarà poder tenir reunions en línia tant amb membres del grup com amb altres stakeholders. ● Google Drive: Google Drive és una eina que permetrà l’emmagatzematge en cloud d'arxius i la compartició d’aquests amb altres usuaris. L’equip usarà aquesta eina per tenir guardats els diferents documents i arxius del projecte en un repositori compartit amb els membres de l’equip per habilitar la col·laboració i compartició instantània. ● Google Sheets: Google Sheets és un software paregut a Excel de Microsoft que ens servirà per estructurar, entre altres coses, els temps d’entrega, sprints i tasques a realitzar. ● Trello: Trello és una eina online que permet a equips gestionar qualsevol mena de projecte o flux de treball, així com supervisar tasques. La interfície de l’eina es divideix en taulers, llistes i targetes. Els taulers són els espais designats per a cada projecte i està dividit en llistes, que són les diferents fases d’una tasca. Com a llistes principals podrem tenir els estats bàsics d’una tasca: “Pendent”, “En Curs” i “Acabada”. A mesura que avança el projecte i necessitem més etapes, les podem anar afegint. Dins de cada llista tindrem targetes que representaran les tasques individuals i podran emmagatzemar tota classe d’informació rellevant a la tasca, com, per exemple, els responsables de la tasca, un títol i descripció, una llista de subtasques, etc. Aquesta eina encaixa molt bé amb la metodologia de treball escollida gràcies a la possibilitat d'organització de tasques que ofereix. En treballar amb un equip de 5 membres, podrem tenir organitzades les tasques de cada membre i veure el què treballa cadascú. També podrem moure les tasques entre les llistes i modificar tasques que a priori estaven acabades per a incorporar noves modificacions sol·licitades pel client. [20] 13
2. Planificació Una bona planificació serà important per a poder complir amb els terminis del projecte pactats amb els clients i altres stakeholders i també per a poder entregar aquest treball de fi de grau en els terminis establerts. Cal remarcar que el projecte d’implantació de Salesforce per a Servilusa per part de Konozca està dividit en dues etapes, sent la primera etapa centrada en adquisició de clients, la gestió de la contractació i les tasques de post-contractació i la segona etapa centrada en altres aspectes com la facturació, la contractació de serveis funeraris en vida i altres. Aquest treball se centra en la 1a etapa del projecte de la implantació, llavors aquesta planificació i en general el treball sols mostrarà aquesta 1a etapa i totes les tasques corresponents. Aquest projecte es va iniciar per part de Konozca a principis de juny del 2023, però jo no em vaig incorporar al projecte fins a mitjans de setembre del mateix any. La primera part del projecte té la data prevista de finalització provisional a finals de desembre de 2023. I el treball de fi de grau es va començar a inicis del curs acadèmic de tardor de 2023, el dia 7 de setembre i té com a data d'entrega de la memòria aproximadament el dia 12 de gener i data de lectura a finals de gener. Segons l’estructura del pla d’estudis de la Facultat d’Informàtica de Barcelona, el Treball de Fi de Grau correspon a una càrrega acadèmica de 18 crèdits on cada crèdit equival a un temps de treball de 30 hores. Això significa que haurem d’estructurar les tasques del treball perquè tinguin una durada conjunta d’aproximadament unes 540 hores per evitar fer ni un treball massa efímer ni fora dels terminis d’entrega. [21] La planificació provisional inicial d’aquest projecte va estar feta a gran escala sense entrar molt en detall en les subtasques pels consultors i la Project Manager. Quan es va acabar l’etapa inicial de consultoria i presa de requisits i es va passar a l’etapa de desenvolupament, els developers del projecte juntament amb els consultors vam definir millor la planificació del desenvolupament i les tasques internes de cada etapa. En la planificació que es mostra en els següents apartats es mostren únicament les meves tasques i s’han omès totes les tasques de consultoria prèviament realitzades quan encara no formava part de l’equip i les tasques assignades a la meva companya developer. Planificació de Desenvolupament implantació Salesforce: Fase Etapa Data d’Inici Data Final Gestió del Projecte Contextualització i abast 18-09-2023 25-09-2023 Planificació 25-09-2023 02-10-2023 Pressupost i sostenibilitat 02-10-2023 09-10-2023 Integració del document final 09-10-2023 16-10-2023 Desenvolupament Reunions de seguiment 02-10-2023 27-12-2023 14
Contractació 02-10-2023 30-10-2023 Post-Contractació 31-10-2023 29-11-2023 Contact Center 30-11-2023 16-12-2023 Càrrega de Dades 18-12-2023 27-12-2023 Go Live i Manteniment Neteja de dades 28-12-2023 28-12-2023 Suport Post-Implantació 28-12-2023 03-01-2023 Manteniment 04-01-2023 05-01-2023 Taula 1.2: Dates planificades per etapa i fase. Elaboració pròpia. 2.1. Descripció de les Tasques del Projecte Tenint en compte els riscs posteriorment descrits en l’apartat 2.5, totes les tasques disposen d’un cert marge de temps superior al plantejat inicialment per a poder tenir un cert marge d’actuació davant qualsevol imprevist i així poder evitar retards en l’entrega. 2.1.1. Gestió del Projecte A. GEP1 - Contextualització i abast: Definició de l’abast del projecte en el context del seu estudi. Plantejament dels objectius del projecte, el context, la rellevància i justificació de la temàtica, com es desenvoluparà i amb quins mitjans. En empresa: Introducció al projecte i presentació inicial realitzada per la Project Manager. Introducció sobre l’empresa Servilusa, sobre la seva organització interna i externa i sobre els seus processos de negoci. Presentat l’estat actual del projecte, els documents dels dissenys tècnics i funcionals realitzats pels consultors i la planificació del projecte. Assignació de les responsabilitats i tasques a realitzar per a cada desenvolupador. Duració: 25 hores Dependències: B. GEP2 - Planificació: En aquesta etapa s'elaborarà la planificació temporal del treball. Es proporcionarà una descripció de les diferents fases del projecte i els recursos i requisits associats a cada fase. A més a més, s’estructurarà un diagrama de Gantt amb les diferents tasques per a tenir una representació visual de la planificació. En empresa: Lectura dels dissenys tècnics i funcionals per acabar d’entendre l’organització de l’empresa i l’estructura del projecte. Resolució de dubtes amb la Project Manager i els consultors. Duració: 15 hores Dependències: GEP1 15
C. GEP3 - Pressupost i Sostenibilitat: Estimació del pressupost del projecte, incloent-hi costs materials, humans, indirectes i altres. Elaboració d’un informe de sostenibilitat centrat en les seves 3 dimensions: social, ambiental i econòmica. Duració: 15 hores Dependències: GEP2 D. GEP4 - Integració del document final: Elaboració del document corresponent a la gestió del projecte agrupant els 3 apartats anteriors i havent aplicat els canvis i millores suggerides pel tutor del projecte. Duració: 15 hores Dependències: GEP3 2.1.2. Desenvolupament ● D1 - Reunions de seguiment: Reunions diàries amb l’equip per a tractar el progrés del projecte, temes pendents i temes a prioritzar. Reunions setmanals amb el client per a tractar el progrés del projecte i altres temes. Duració: 30 hores Dependències: A. Contractació: ● CO1 - Presa de Requisits: Revisió de l’estructura de dades del sistema vell i el nou sistema de dades plantejat en el document funcional. Reunió amb l’equip de Servilusa i Winsig per a especificar les dades a integrar desitjades. Duració: 8 hores Dependències: ● CO2 - Plantejament i Estructuració de les Tasques: Traspàs dels requisits del client a funcions del CRM. Revisió dels objectes que s’han d’integrar i els atributs necessaris. Elaboració inicial de les tasques a realitzar. Reunions amb el client i Winsig per a validar el plantejament. Duració: 12 hores Dependències: CO1 ● CO3 - Disseny Arquitectura de Dades: Revisada l’arquitectura de dades dissenyada pels consultors per a validar la seva alineació amb els requisits del projecte i per a poder-la adaptar amb l’arquitectura de Serviout. Creació de nous Objectes i atributs dins els objectes existents. Validació metadades dels atributs (restriccions, tipus d’atribut, opcions dins de llistes de selecció, permisos). Creats triggers i flows per postprocessar i validar dades i automatitzar processos d’inserció de dades. Duració: 40 hores Dependències: CO2 ● CO4 - Creació i modificació d’interfícies: Desenvolupament d’interfícies d’objectes per adaptar-les a les de Serviout i per facilitar la lectura de les dades. Duració: 30 hores Dependències: CO3 ● CO5 - Desenvolupament Integració: Elaboració d’esquema tècnic en alt nivell per a l’arquitectura del sistema i la integració. Desenvolupament de codi 16
2.4. Diagrama de Gant Figura 2.1: Diagrama de Gantt. Elaboració pròpia amb l’eina Gantt Project. 23
2.5. Gestió de Riscs En l’anterior apartat 1.3.2 s’ha llistat els diferents riscs principals i una petita descripció del risc. En aquest apartat aprofundirem més en cada risc, detallant també el seu grau d’impacte, la seva probabilitat d’aparició i en les possibles solucions i plans alternatius. Segons l’anàlisi de fracassos en implantacions de sistemes CRM conduït per Mohamed Y. Tazkarji i Tom Stafford el 2020 [24] els punts més crítics que causen més fracassos en la implantació d’un CRM són factors organitzacionals i no tant factors d’implementació o tecnologia. Llavors per a dur a terme una bona implantació, haurem de tenir en compte aquests 3 factors de risc, fent especial èmfasi en els organitzacionals. 2.5.1. Riscs Organitzacionals ● Arquitectura organitzativa poc clara: Aquest és un risc provocat per a poca comunicació entre diferents àrees del negoci i és molt comú sobretot per a empreses d’una mida elevada. Ve causat també per la falta de comprensió sobre com està estructurada l'organització, el flux de processos de negoci o com s’organitzen les dades o la informació dins l’empresa en relació amb les interaccions amb el client. Aquest problema de comprensió pot ser la base d’altres problemes com, per exemple, la incorrecta configuració del CRM o confusions en el funcionament dels processos. [24] Per a fer front a aquest risc, l’equip treballarà amb una metodologia Agile on s'efectuaran entregues i demostracions continuades perquè el client pugui validar la solució i suggerir canvis abans d'aplicar altres canvis i treballar sobre un sistema incorrecte. ● Falta de compromís de la Gerència: Per a assegurar una bona presa de requisits i implementació del sistema, necessitarem el suport total de tots els membres de l’alta gerència de l’empresa per a poder recollir informació sobre els processos de negoci, l’arquitectura de l’organització i també necessitarem validar les solucions plantejades i desenvolupades. Una falta de compromís per part dels gerents pot comportar retards en la implantació, falta de recursos i en el pitjor dels casos un fracàs en el projecte. [24] Per a fer front a aquest risc, l’equip usarà a les eines de comunicació preferides del client i mantindrà oberts diferents canals de comunicació per a la resolució de dubtes o reunions. En l’equip hi haurà una consultora de parla portuguesa per a millorar la comunicació entre els clients i l’equip. A més a més, l’equip de consultors i la Project Manager faran visites periòdiques a les oficines de Servilusa a Lisboa per a fer reunions i demostracions presencials. ● Resistència al canvi: Aquest problema es dona quan els usuaris de l’empresa no usen el nou sistema i en comptes usen el sistema antic o fan un mal ús del nou sistema. Aquest problemes en 24
la fase inicial de la implantació poden venir a causa de falta de coneixements del nou sistema o el rebuig a fer un esforç addicional per adaptar-se. Gestionar eficaçment la resistència al canvi serà essencial per assolir una transició suau i perquè els empleats s'adaptin de manera positiva a les noves circumstàncies. [24] [25] Per aquesta raó, els desenvolupadors ens centrarem a implementar una interfície tan clara com sigui possible i en automatitzar totes les tasques redundants o trivials per a facilitar l’ús als usuaris. A més a més, els consultors realitzaran etapes de formació per a involucrar als empleats en el procés de canvi i poder mostrar els beneficis que els aportarà el nou sistema. 2.5.2. Riscs d’Implementació ● Processos de negoci mal definits per part dels consultors: El treball de consultoria no recaurà dins les meves responsabilitats, però, com a desenvolupador, hauré de donar suport als consultors per a poder tenir una connexió correcta entre requisits i tecnologia. Dins dels meus càrrecs estaran el fet de guiar als consultors per a poder traslladar tots els requisits dels clients a escala de sistema. També donar suport als consultors en les reunions amb els clients per a validar els requisits sol·licitats i per a presentar possibles solucions als problemes plantejats. ● Retards en les entregues del sistema: Aquest problema pot esdevenir d’una mala planificació de les tasques, retards en implementació per l’alta complexitat, per problemes tècnics, per manca de recursos o per canvis periòdics en els requisits per part dels clients. Els retards en les entregues poden acabar generant una pèrdua de confiança del client cap als desenvolupadors a part de suposar un cost addicional pel client. [26] Per mitigar aquest risc, és fonamental dur a terme una planificació adequada, assignar recursos suficients, establir expectatives realistes i mantenir una comunicació efectiva amb totes les parts interessades. A més, la gestió activa del projecte i la identificació primerenca de problemes poden ajudar a minimitzar els retards i garantir una implementació exitosa del CRM en el temps previst. ● Errors de programació: Els errors de programació o “bugs” són molt comuns en els desenvolupaments de software i poden esdevenir a causa d’una manca de temps per a desenvolupar tots els requisits o per l’alta complexitat del projecte. Les implicacions que poden tenir aquests erros són la pèrdua de dades, l’impacte en l’experiència d’usuari i la productivitat, la pèrdua de confiança i costs addicionals. Com a accions preventives, l’equip adoptarà una metodologia de desenvolupament iterativa com és Agile per a poder fer entregues i proves contínues amb els clients. A més també comptarem amb el suport del director de desenvolupament i d’altres companys amb més experiència per a la revisió de les solucions plantejades i per a la resolució de dubtes. 2.5.3. Riscs de Tecnologia ● Sistema obsolet o cancel·lat: 25
Aquest risc es basa en la possibilitat que el sistema CRM quedi obsolet i que l’empresa proveïdora, en el nostre cas Salesforce, abandoni el software i no tregui noves actualitzacions en el futur o que simplement tanqui els servidors del sistema. Aquest és un risc molt hipotètic i amb una molt baixa probabilitat donat que Salesforce és el proveïdor més gran de sistemes CRM en tot el món i s’esforcen molt a mantenir un sistema actualitzat, lliure d’erros i al dia amb les noves tecnologies i processos de negoci. En la següent taula podem trobar un resum dels diferents riscs esmentats amb la seva probabilitat d’aparició i el seu impacte. Risc Impacte Probabilitat Riscs Organitzacionals Arquitectura organitzativa poc clara Alt Mitjana Falta de compromís de la Gerència Molt alt Baixa Resistència al canvi Alt Mitjana Riscs d’Implementació Processos de negoci mal definits per part dels consultors Mitjà Baixa Retards en les entregues del sistema Baix Mitjana Errors de programació Mitjà Alta Riscs de Tecnologia Sistema obsolet o cancel·lat Molt Alt Inexistent Taula 2.2: Resum dels riscs del projecte, el seu impacte i la seva probabilitat. Elaboració pròpia. 26
3. Gestió Econòmica El càlcul del pressupost en un projecte és una pràctica essencial per a garantir l’èxit del projecte. La seva elaboració ajudarà a tenir una planificació financera, a tenir un control de costs i a l'assignació efectiva de recursos en les diferents etapes del projecte. Un pressupost també ens ajudarà a identificar riscs potencials i a estimar contingències per a mitigar-los. [27] 3.1. Identificació i Estimació de Costs La primeta etapa en formular un pressupost serà la d'identificar i estimar els costs de les diferents etapes tant en l'àmbit de personal com de recursos materials i de software. A més a més, també realitzarem una estimació dels costs d'imprevists. En aquest projecte elaborat en empresa intervendran molts treballadors directament, com la Project Manager, els consultors i els desenvolupadors, i alguns treballadors indirectament com són la CEO de l’empresa per a realitzar el seguiment del projecte i també la gestora de recursos humans i la gestora de finances. Malgrat aquest raonament, en aquest TFG sols informaré i desenvoluparé les tasques executades per mi en el projecte i sols comentaré algunes de les tasques fetes pels meus companys quan tinguin un impacte en les meves. Llavors en l’elaboració del pressupost sols tindré en compte els costs que impliquen el meu treball i ometré els costs de la resta de l’equip. 3.1.1. Recursos de Personal En la realització d’aquest projecte la gran majoria de temps el meu rol ha estat el de programador, però en diferents etapes he hagut d’assumir un rol diferent i per aquest motiu el càlcul del cost humà el realitzarem d'acord amb un desglossament de les hores realitzades per cada rol en cada tasca respectiva calculant finalment el salari corresponent per cada rol. D’aquesta forma el pressupost final tindrà uns costs més realistes. Els sous corresponents de cada rol s’han extret de diferents webs d’ofertes de treball de Glassdoor i Indeed per salaris espanyols. Rol Sou net (€/hora) Sou brut (€/hora) Junior Developer (JD) 16,1 23 Consultor Junior (JC) 14 20 Project Manager (PM) 23,8 34 Taula 3.1: Sous mitjans dels diferents rols del projecte en l’àmbit laboral espanyol. Elaboració pròpia. Per al sou net es calcula una retenció del 30% per al cost dels impostos. 27
Amb aquestes dades dels salaris i l’estructuració de les tasques enumerades en el plantejament, podem elaborar una taula amb el temps executat per rol per cada tasca i calcular el cost individual i el total. Codi Tasca JD JC PM Duració Cost GESTIÓ DEL PROJECTE 0 0 70 Total: 70 Total: 2380 GEP1 Contextualització i abast 25 25 850 GEP2 Planificació 15 15 510 GEP3 Pressupost i Sostenibilitat 15 15 510 GEP4 Integració del document final 15 15 510 DESENVOLUPAMENT 335 105 40 Total: 480 Total: 11165 D1 Reunions i seguiment 20 5 5 30 730 CONTRACTACIÓ 90 35 15 Total: 140 Total: 3280 CO1 Presa de Requisits 5 5 10 270 CO2 Plantejament i Estructuració de les Tasques 10 5 15 370 CO3 Disseny Arquitectura de Dades 30 5 5 40 960 CO4 Creació i modificació d’interfícies 25 5 30 675 CO5 Desenvolupament Integració 25 5 30 675 CO6 Tests 10 5 15 330 POST-CONTRACTACIÓ 125 40 10 Total: 175 Total: 4015 PC1 Presa de Requisits 5 5 10 270 PC2 Plantejament i Estructuració de les Tasques 10 5 15 370 PC3 Desenvolupament Integració 55 10 65 1465 PC4 Desenvolupament tasques post-contractació 50 10 60 1350 PC5 Tests 20 5 25 560 CONTACT CENTER 60 25 10 Total: 95 Total: 2220 CC1 Presa de Requisits 5 5 10 270 CC2 Plantejament i Estructuració de les Tasques 5 5 10 270 CC3 Desenvolupament Integració 15 5 20 445 CC4 Desenvolupament Lògica Salesforce 35 5 40 905 CC5 Tests 10 5 15 330 CÀRREGA DE DADES 40 0 0 Total: 40 Total: 920 CD1 Preprocessat de Dades 28 28 644 CD2 Importació a Salesforce 10 10 230 CD3 Inspecció Final 2 2 46 28
GO LIVE I MANTENIMENT 30 0 0 Total: 30 Total: 690 GL1 Neteja de dades del sistema 2 2 46 GL2 Suport post implantació 18 18 414 GL3 Manteniment 10 10 230 PROJECTE TOTAL 365 105 110 Total: 580 Total: 14235 Taula 3.2: Cost dels recursos humans del projecte. Elaboració pròpia. 3.1.2. Costs materials Per a dur a terme tant el projecte dins l’empresa com el següent treball de fi de grau, l'empresa em va proveir de tots els recursos necessaris que vaig necessitar. Dins dels recursos de hardware , vaig disposar d’un portàtil, teclat, ratolí, auriculars amb micròfon i un monitor extern. Com a recursos software no gratuïts, s’inclouen el Windows 11 i el Microsoft Office 365, tot i que el Windows 11 ens acabarà sortint de franc a l'estar inclòs en el portàtil. L'amortització dels recursos materials es calculen amb la següent fórmula per als recursos de pagament únic: 𝑐𝑜𝑠𝑡 ( € ) ⋆ 𝑢𝑠 𝑒𝑛 𝑒𝑙 𝑝𝑟𝑜𝑗𝑒𝑐𝑡𝑒 ( ℎ𝑜𝑟𝑒𝑠 ) 𝑣𝑖𝑑𝑎 ú 𝑡𝑖𝑙 ( 𝑎𝑛𝑦𝑠 ) ⋆ 𝑑𝑖𝑒𝑠 𝑙𝑎𝑏𝑜𝑟𝑎𝑏𝑙𝑒𝑠 𝑎𝑛𝑢𝑎𝑙𝑠 ⋆ 𝑑𝑒𝑑𝑖𝑐𝑎𝑐𝑖 ó 𝑑𝑖 à 𝑟𝑖𝑎 ( ℎ𝑜𝑟𝑒𝑠 ) On tindrem en compte que la dedicació diària és de 9 hores, la vida útil de 4 anys aproximadament, 220 dies laborables anuals i la duració del projecte són 580. A la Taula 7, es mostra aquests costos materials i la seva amortització. Per als recursos de pagament mensual com són els recursos de software, calcularem el cost mensual durant els 3,5 mesos de duració del projecte. Element Preu (€) Amortització Lenovo IdeaPad 3 15ITL6 amb un i7 [28] 749 54,85 Teclat Trust [29] 12 0,9 Ratolí Logitech G502 [30] 49 3,58 Monitor LG 24 [31] 95 6,95 Auriculars Logitech G432 [32] 50 3,66 Windows 11 0 0 Office 365 Business Basic [33] 5,6 mensuals 19,6 Total 974,6 89,54 Taula 3.3: Cost dels recursos materials del projecte. Elaboració pròpia. 29
3.1.3. Costs indirectes La major part d’aquest projecte es realitzarà en les oficines de l'empresa de forma presencial, llavors tots els costs indirectes seran també coberts per l’empresa. Com a costs indirectes calcularem el lloguer proporcional del meu espai en les oficines. Segons dades recollides de diferents anuncis de lloguers d’oficines a idealista.com, el preu per m² d’unes oficines situades en el barri de les Corts de Barcelona és d’aproximadament 25 €/mes, incloent-hi costs de comunitat, IBI i consums. Tenint en compte aquestes dades, el cost indirecte del projecte sortirà a: 5 𝑚 ² * 25 € 𝑚𝑒𝑠 ⋆ 𝑚 ² * 3 , 5 𝑚𝑒𝑠𝑜𝑠 = 437 , 5€ Element Cost (€) Lloguer i consums 437,5 Taula 3.4: Cost dels recursos indirectes del projecte. Elaboració pròpia. 3.1.4. Contingències Per a les despeses degudes a les contingències s’estableix un percentatge del 10%, tenint d’aquesta manera, un nou càlcul per als costos humans i materials, com es mostra a la Taula 9. Tipus de cost Cost (€) Contingència (%) Contingència (€) Cost Final (€) Cost Personal 14.235,00 10% 1.423,50 15.658,50 Cost Material 89,54 8,95 98,49 Cost Indirecte 437,50 43,75 481,25 Total 14.762,04 1.476,20 16.238,24 Taula 3.5: Cost de contingències. Elaboració pròpia. 3.1.5. Imprevistos Els riscos prèviament esmentats en l’apartat 2.5 també poden tenir un impacte als costos del projecte. No obstant això, a la fase de planificació, hem considerat aquests riscos i hem assignat tasques específiques per prevenir-ne l'aparició i també hem afegit hores extra de contingència. Aquestes tasques inclouen la correcció d'errors, la gestió d'incidències i la realització d'ajustaments al codi en cas d'errors. Per aquesta raó en aquest apartat sols tindrem en compte els costs per imprevistos dels recursos materials com avaries o defectes. El portàtil al ser nou estarà cobert per la garantia del fabricant, llavors sols tindrem en compte els materials no coberts per la garantia en ser ja vells. 30
Element Preu reparació (€) Probabilitat (%) Cost (€) Teclat Trust 12 2% 0,24 Ratolí Logitech G502 49 2% 1 Monitor LG 24 50 5% 2,6 Auriculars Logitech G432 50 10% 5 Total 161 8,84 Taula 3.6: Cost d’imprevistos. Elaboració pròpia. 3.1.6. Pressupost Final Després de desenvolupar els diferents tipus de cost tenint en compte les contingències i els imprevistos, podem elaborar la taula del pressupost final. Tipus de Cost Cost Total (€) Recursos de Personal 14.235,00 Cost Material 89,54 Costs Indirectes 437,50 Costs de Contingències 1.476,20 Costs d’Imprevistos 8,84 Total 16.247,08 Taula 3.7: Pressupost final. Elaboració pròpia. 3.2. Control de Gestió Un cop calculat el pressupost del projecte, durant la realització del projecte serà necessari portar un control de les desviacions respecte a les prediccions realitzades inicialment, en funció de les hores invertides a cada tasca i imprevistos. Les fórmules que es mostren a continuació, expliquen com obtenir aquestes desviacions respecte a valors teòrics: ● Desviació hores consumides per tasca: ( 𝐻𝑜𝑟𝑒𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑒𝑠 – 𝐻𝑜𝑟𝑒𝑠 𝑟𝑒𝑎𝑙𝑠 ) * 𝐶𝑜𝑠𝑡 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 ● Desviació dels costos segons les hores consumides per tasca: ( 𝐻𝑜𝑟𝑒𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑒𝑠 – 𝐻𝑜𝑟𝑒𝑠 𝑟𝑒𝑎𝑙𝑠 ) * 𝐶𝑜𝑠𝑡 𝑟𝑒𝑎𝑙 31
● Desviació dels costos en recursos humans per tasca: ( 𝐶𝑜𝑠𝑡 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑟𝑒𝑎𝑙 ) * 𝐻𝑜𝑟𝑒𝑠 𝑟𝑒𝑎𝑙𝑠 ● Desviació total dels costos materials: 𝐶𝑜𝑠𝑡 𝑚𝑎𝑡𝑒𝑟𝑖𝑎𝑙 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑚𝑎𝑡𝑒𝑟𝑖𝑎𝑙 𝑟𝑒𝑎𝑙 ● Desviació total dels costos indirectes: 𝐶𝑜𝑠𝑡 𝑖𝑛𝑑𝑖𝑟𝑒𝑐𝑡𝑒 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑖𝑛𝑑𝑖𝑟𝑒𝑐𝑡𝑒 𝑟𝑒𝑎𝑙 ● Desviació total dels imprevistos: 𝐶𝑜𝑠𝑡 𝑖𝑚𝑝𝑟𝑒𝑣𝑖𝑠𝑡 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑖𝑚𝑝𝑟𝑒𝑣𝑖𝑠𝑡 𝑟𝑒𝑎𝑙 ● Desviació total dels costos personals: 𝐶𝑜𝑠𝑡 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑙 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑝𝑒𝑟𝑠𝑜𝑛𝑎𝑙 𝑟𝑒𝑎𝑙 ● Desviació total d’hores: 𝐻𝑜𝑟𝑒𝑠 𝑒𝑠𝑡𝑖𝑚𝑎𝑑𝑒𝑠 – 𝐻𝑜𝑟𝑒𝑠 𝑟𝑒𝑎𝑙𝑠 ● Desviació total dels costos: 𝐶𝑜𝑠𝑡 𝑡𝑜𝑡𝑎𝑙 𝑒𝑠𝑡𝑖𝑚𝑎𝑡 – 𝐶𝑜𝑠𝑡 𝑡𝑜𝑡𝑎𝑙 𝑟𝑒𝑎𝑙 Durant el desenvolupament del projecte hi va haver diferents imprevistos, que gràcies a les hores estimades de contingència i al nostre procés de desenvolupament agile no van afectar la planificació ni van fer atraçar el termini d’entrega. Un d’aquests imprevists va estar relacionat amb una baixa laboral d'un desenvolupador de DXNet, l’equip encarregat del contact center. Durant el seu període de baixa es van centrar els esforços a acabar altres tasques pendents. També van sorgir diferents imprevistos relacionats amb el rebuig per part del client amb alguns dels desenvolupaments de les tasques de post-contractació. Però gràcies al nostre mètode agile i a l’entrega contínua d’ sprints , vam poder identificar ràpidament aquests problemes i canviar la solució. On realment va haver-hi desviacions respecte de la planificació inicial va ser en la realització de la memòria del TFG. Durant el desenvolupament del projecte de l’empresa no es va realitzar una documentació prou adequada als estàndards de la Facultat o directament no es va fer documentació. Això va suposar que hagués de dedicar més temps personal a la formalització de la memòria i també que hagués de demanar una pròrroga en l’entrega. Aquestes desviacions van ser aproximadament de 20 hores per cada una de les dues etapes desenvolupades. ● Tenint en compte un preu per hora mitjà dels recursos humans de 26€ la desviació de costs fan augmentar (26 €/h * 20*2h) = 1040€ el cost del projecte. 32
6. Eines de Salesforce En aquest apartat es farà una petita introducció a l'ecosistema de Salesforce per a poder preparar al lector inexpert en Salesforce per als pròxims apartats de desenvolupament. Aquesta primera introducció també ens habilitarà poder ometre informació redundant en els pròxims apartats i així facilitar la lectura pels lectors experts en aquest CRM. Així doncs, veurem com s’estructura en el back-end i en el front-end i quines opcions de personalització ens ofereix. Salesforce és un sistema de gestió empresarial basat en cloud, un software com a servei. Això significa que ofereix les seves aplicacions com a servei a través d'Internet, en lloc d'exigir als usuaris que instal·lin, mantinguin i executin el programari als seus propis ordinadors o centres de dades. En aquest sentit, Salesforce ens ofereix grans avantatges com, per exemple, la gestió automàtica del programa i les dades. L’accés habilitat des de gran varietat de dispositius, com mòbils i ordinadors sense la necessitat de configuracions addicionals. També ens ofereix gran escalabilitat i flexibilitat per adaptar-se a qualsevol model de negoci amb molts o pocs usuaris/clients o en constant creixement. [39] Com a qualsevol sistema de gestió empresarial, la base principal de Salesforce són els objectes, que són estructures de dades que funcionen com una taula amb columnes i files. Un objecte podrà tenir diferents atributs (columnes) i diferents instàncies o registres (files). Com a atributs d’un objecte podrem tenir gran varietat de variables com, per exemple, camps de text, numerals, dates, llistes de selecció o fins i tot, punters a altres registres del sistema. En l’aspecte del front-end del sistema, Salesforce ens ofereix de base unes interfícies molt estètiques i senzilles per a poder visualitzar les nostres dades, amb multitud de gadgets estàndards i personalitzables. Com aspectes a remarcar de les interfícies de Salesforce tenim opcions com [40] : ● La possibilitat de crear múltiples interfícies per perfils d’usuaris i tipus d’un mateix objecte. ● La possibilitat d’afegir botons amb funcions personalitzades. ● Poder marcar camps com a sols lectura o obligatoris. ● Poder establir filtres de visibilitat per a camps o components de la interfície. ● Components web amb funcionalitats personalitzades programables amb HTML i Javascript A escala de back-end tenim multitud d’eines per a l’automatització de processos i la gestió de la base de dades com, per exemple: ● Codi Apex, el llenguatge basat en Java de Salesforce que ens habilita: ○ Programar controladors per als components web ○ Programar disparadors per als objectes del sistema ○ Executar funcionalitats programades en el temps ( Schedulables ) ○ Executar processos de computació massiva ( Batches ) ○ Programar web services personalitzats 39
● Fluxes de Salesforce, una eina low code desenvoluapda per Salesforce que ens permeten: ○ Programar disparadors per als objectes del sistema ○ Programar interfases i fluxos de pantalla ○ Executar funcionalitats programades en el temps ( Schedulables ) ● Configuració de web Services estàndard de Salesforce ● Configurar protocols de seguretat de, per exemple, inici de sessió o connexions externes ● Configuració senzilla d’objectes i camps ● Configuració de perfils i rols per a parametritzar permisos a nivell d’objecte i registre Totes aquestes eines i moltes més les veurem en els següents apartats de desenvolupament. 40
7. Contractació 7.1. Presa de Requisits La primera etapa de desenvolupament del CRM serà l’etapa de contractació, que comprendrà, en termes generals, l’estructura per a gestionar els clients, empreses, potencials serveis i serveis contractats. En una primera instància l’equip de consultors ja va definir l’estructura de dades del sistema i molts dels requisits funcionals i no funcionals d’aquesta fase del sistema, però, tot i això, van caldre moltes més reunions amb l’equip de directors tècnics i comercials de Servilusa per acabar derivant amb el disseny final que es presentarà a continuació. La solució inicial proposada consta d’una sèrie d’objectes que emmagatzemaran la informació tant de clients, serveis i altres objectes relacionats i també d’un seguit de components auxiliars i automatismes. La figura 7.1 d’aquest apartat mostra una esquematització a gran escala d’aquesta solució. La base del procés de negoci de Servilusa seran els casos, que representaran oportunitats de negoci o serveis potencials que pot arribar a contractar un client. Els casos podran provenir dels formularis del contact center o dels formularis web o també podran ser creats manualment per comercials. En tenir un cas obert, els comercials tindran en l’objecte la informació primordial per a poder gestionar-lo i arribar a formalitzar la contractació del servei. Aquesta informació serà sobretot respecte del client i del difunt, si aplica. El cas podrà tenir diferents etapes de gestió fins a arribar a l’etapa de cancel·lat o tancat. Un cop el comercial formalitzi el servei amb el client, podrà tancar el cas i crear des del cas, un servei. En aquest nou registre es traspassarà automàticament tota la informació del cas. L’objecte servei, igual que els casos, podrà tenir diferents tipus amb diferents dades, però en termes generals tots els serveis podran emmagatzemar dades com el client, el difunt, el tanatori, hospital, loja (oficina), església, dades d'esdeveniments importants, etc. Els serveis tindran diferents objectes relacionats a aquests per a poder emmagatzemar altre tipus d’informació. Aquests objectes seran interlocutors o persones relacionades amb el client o difunt, el pressupost del servei, incidències o reclamacions, auditories, notes, documentació, etc. Una vegada que el comercial hagi emplenat la informació essencial d’un servei, el podrà enviar a Serviout, que és la plataforma antiga de Servilusa on podrà seguir la gestió del servei. Amb aquesta implantació de Salesforce es pretén migrar tota la funcionalitat de Serviout perquè en un futur els comercials sols treballin en aquest CRM i evitar així haver de treballar en 2 plataformes diferents. Tot i això, en aquesta Fase 1 del projecte es migrarà quasi tota la funcionalitat de Serviout excepte la gestió dels pressuposts, l’enviament d’aquests pressuposts a SAP i la generació de formularis pel client i documents legals amb PDF. A més a més, també no es realitza un canvi de plataforma directe per evitar tenir una dependència absoluta amb una nova plataforma i tenir així també un mètode de back-up. 41
Un cop el pressupost hagi estat tancat, s’envairan a Salesforce totes les dades del servei incloent aquest pressupost i començarà l’etapa de post contractació que cobrirem en el següent apartat 8. Figura 7.1: Diagrama del procés de contractació de Serveis en Salesforce. Elaboració pròpia. 42
7.2. Característiques del Sistema 7.2.1. Requisits Funcionals i Casos d’ús El nostre projecte agrupa tota l’empresa de Servilusa i amb això tots els diferents usuaris que gestionaran serveis o aspectes relacionats amb els serveis. Així doncs, tindrem diferents perfils d’usuaris dins l’empresa que emprendran diferents funcions dins l’empresa i de Salesforce. El següent diagrama mostra la jerarquia d’usuaris del sistema. En Salesforce podrem configurar aquests perfils i assignar-los diferents permisos dins la plataforma per a garantir la protecció de dades dins l’empresa. Vegeu apartat 7.7.4 per aquesta configuració. Figura 7.2: Jerarquia d’usuaris en Servilusa. Elaboració pròpia. Donat que Servilusa és una empresa que comprèn tot Portugal, realitzarem diferents divisions d’usuaris per cada zona de l’empresa, per a poder definir regles de visibilitat de dades dins de Salesforce. Aquesta divisió la configurarem amb els rols. Els rols de Salesforce ens permeten organitzar els usuaris amb una estructura jeràrquica on els usuaris d’una escala superior hereten tots els permisos de visualització de dades dels seus subordinats. A més a més, amb els rols podrem configurar regles de visibilitat de registres (vegeu apartat 7.7.4). Cal remarcar que Servilusa gestiona també l’empresa de Triunfo, i per aquesta raó tindrem definits els rols d’aquests usuaris per aquesta empresa. 43
Figura 7.3: Esquema dels Rols de Servilusa. Elaboració pròpia. Un cop definits els perfils i els rols dels usuaris, passarem a veure els casos d’ús dins de l'entorn de contractació. Els casos d’ús s’han dividit segons el tipus d’objecte amb què s’interactua. 44
Figura 7.4: Diagrama de casos d’ús per als Casos. Elaboració pròpia. 45
Figura 7.5: Diagrama de casos d’ús per als Serveis. Elaboració pròpia. 46
Figura 7.6: Diagrama de casos d’ús per als Comptes. Elaboració pròpia. 47
Figura 7.7: Diagrama de casos d’ús per als Interlocutors. Elaboració pròpia. Amb els diagrames, es veuen a grans trets les funcionalitats i casuístiques que es volen implementar o aconseguir amb el sistema. Per entrar una mica més detalladament, s'especificaran alguns dels casos d'ús mitjançant unes taules Brief Style . Per això, s'han seleccionat els casos d'ús on personalment s’ha treballat en el seu desenvolupament i en els que no venen preconfigurats per Salesforce. Crear Client / Difunt (Cas o Servei) Actors Usuari Precondicions Existeix un cas o servei. L’usuari té permisos per a crear comptes. Disparador L’usuari edita el cas i se situa en el camp LookUp de client o difunt. Un cop dins el camp, prem el botó de Nou Compte. Escenari Principal 1. Apareix un pop-up amb els camps per a un nou compte personal. 48
Figura 7.11: Diagrama UML de les subclasses de l’objecte Servei. Resticcions Textuals: 1. Claus Externes: (Servei, Id/Id Extern Serviout) 2. Atributs requerits de Servei: Número de servei, RecordTypeId 3. Si el servei és de tipus funeral, la data de contractació serà obligatòria. 4. Els valors disponibles del sub-estat d’un servei dependran del valor de l'estat del servei. Veure taula Annex A.4 5. És obligatori definir un sub-estat excepte quan no hi ha cap sub-estat possible per l’estat del servei. 6. La zona i empresa d’un servei seran els mateixos que els de la “Loja” (Oficina) indicada en el servei. 7. El camp de Lloc de Centres i Cementiri Destí Cendres s’habilitaran quan el camp de cremació en funeral tingui el valor de Amb Cremació. 8. Els camps de Pis Cementiri, Número Local Cementiri, Entrega a família, Entregat a familiar, Camí Cementiri, Secció Sepultura, Coordenades, s’habilitaran depenent dels valors de la llista de selecció de Lloc de Cendres. Veure taula apartat 7.6.1. 9. Els diferents tipus de serveis tindran habilitats diferents camps. Veure la taula de servei en l’apartat 7.5 de descripció de taules Atributs derivats Glossari del model conceptual 1. Tot servei tindrà 1 i sols 1 client principal. El reste de clients o familiars involucrats en el servei es registraran com a interlocutors. 7.3.2. Esquema conceptual de l'objecte Compte Aquest tercer objecte Compte també va ser estructurat en gran part per la meva persona, agafant com a exemple a seguir l’estructura dels objectes Client i Difunt de Serviout i adaptant alguns camps i afegint n'he de nous. També es van crear les subclasses dels comptes d’entitats amb els atributs requerits per Servilusa. 55
En aquest cas i en ser un objecte sense moltes relacions, es va realitzar 1 sol model conceptual per descriure l’objecte. Figura 7.12: Diagrama UML de l’objecte Account. Restriccions Textuals: 1. Claus Externes: (Compte, Id), (Codi Postal, Id/Codi Postal+País) 2. No poden existir 2 comptes que no siguin personals amb el mateix nom 3. Per als tanatoris i llocs de defunció, el tipus de tanatori/lloc és obligatori. Atributs derivats Glossari del model conceptual 1. Per als seus serveis, Servilusa pot informar el cònjuge del difunt, que podrà ser un difunt o un viu que es guardarà com a client. 56
7.4. Disseny Lògic Un cop realitzat el disseny conceptual d’una base de dades, el pas següent serà el disseny lògic d’aquesta. Per al disseny lògic transformarem les entitats, atributs i relacions del model conceptual a taules, atributs i claus en un model relacional. [42] Per aquest esquema de disseny lògic s’ha realitzat la transformació de tots els objectes instanciats en els esquemes conceptuals de cas i servei en un mateix diagrama. A més a més, sols s’han afegit els atributs més importants i necessaris per a poder muntar l’esquema relacional. Per a una definició completa de tots els atributs dels objectes, mireu el següent apartat 7.5. Table Caso__c { Id id [ primary key] RecordTypeId id SERV_Cliente__c id [ ref: > Account.Id] SERV_Fallecido__c id [ ref: > Account.Id] SERV_T_cnico_comercial__c id [ ref: > User.Id] SERV_Coordenador_comercial__c id [ ref: > User.Id] SERV_Servico__c id [ ref: > Servicio__c.Id] OwnerId id [ ref: > User.Id, not null] } Table Servicio__c { Id id [ primary key] SERV_Numero_do_Processo__c externalID unique RecordTypeId id SERV_Agencia_Loja__c id [ ref: > Account.Id] SERV_Cliente__c id [ ref: > Account.Id] SERV_Fallecido__c id [ ref: > Account.Id] SERV_Caso__c id [ ref: > Caso__c.Id] SERV_T_cnico_comercial__c id [ ref: > User.Id] SERV_Coordenador_comercial__c id [ ref: > User.Id] OwnerId id [ ref: > User.Id, not null] } Table Interlocutor__c { Id id [ primary key] SERV_Codigo_Postal__c id [ ref: > Codigo_Postal__c.Id] SERV_Id_Interlocutor_SO__c externalID unique SERV_NIF__c text SERV_Conta_Interlocutor__c id [ ref: > Account.Id] SERV_Servicio__c id [ ref: > Servicio__c.Id, not null] } Table Nota__c { Id id [ primary key] 57
Titulo__c text Corpo__c text Caso__c id [ ref: > Caso__c.Id] Servicio__c id [ ref: > Servicio__c.Id] Account_Nota__c id [ ref: > Account.Id] OwnerId id [ ref: > User.Id, not null] } Table Historial__c { Id id [ primary key] Campo__c text Valor_antigo__c text Valor_novo__c text Caso__c id [ ref: > Caso__c.Id] Servicio__c id [ ref: > Servicio__c.Id] OwnerId id [ ref: > User.Id, not null] } Table User { Id id [ primary key] SERV_Tecnico_Id_Serviout__c externalID FirstName text LastName text [ not null] Email text [ not null] Alias text Username text unique [ not null] } Table Account { Id id [ primary key] RecordTypeId id SERV_Conta_Pessoal_ID_SO__c externalID unique Name text [ not null] SERV_NIF__c text SERV_Codigo_Postal__c id [ ref: > Codigo_Postal__c.Id] SERV_Tipo_de_Conta__c picklist SERV_Hospital_Falecido__c id [ ref: > Account.Id] SERV_Lares_Falecido__c id [ ref: > Account.Id] SERV_Conjuge__c id [ ref: > Account.Id] OwnerId id [ ref: > User.Id, not null] } Table Codigo_Postal__c { Id id [ primary key] SERV_Numero_CP_ID__c externalID [ unique , not null] SERV_Cidade__c text 58
SERV_Concelho__c text SERV_Pais__c text OwnerId id [ ref: > User.Id, not null] } Codi 7.1: Definició de l’esquema de la base de dades de Salesforce per l’etapa de Contractació. L’esquema resultant de les següents taules es el següent: 59
Figura 7.13: Diagrama del disseny lògic dels objectes del sistema. 60
7.4.1. Construcció de la Base de Dades en Salesforce Un cop ja esquematitzada la base de dades en un model relacional, podrem començar a construir la base de dades dins de Salesforce. En ser un CRM amb moltes funcionalitats user-friendly, Salesforce ens permetrà crear la BBDD sense la necessitat de llenguatge SQL. La plataforma implementa una interfase per a la gestió d’objectes molt ben estructurada i amb moltes funcionalitats. Per a cada objecte, tenim la pestanya d’informació general, on podrem veure el nom api, la label i altres atributs. Figura 7.14: Informació general de l’objecte Account en Salesforce. En la pestanya de camps i relacions, tindrem el llistat de tots els camps de l’objecte i informació sobre altres metadades de l’atribut com són el nom del camp, l’etiqueta del camp, el tipus de dada, si hi ha un camp controlador i si està indexat. Per a tots els camps i objectes de Salesforce tindrem l’etiqueta i el nom API (derivat del nom del camp). L’etiqueta representa el que es veurà en pantalla, mentre que el nom API representa la nomenclatura interna del camp. El nom API serà usat dins de processos de Salesforce com disparadors , components o integracions. Aquesta distinció permet canviat l’etiqueta del camp sense tenir cap afectació en cap d’aquests processos. En la capçalera de la pantalla també trobarem 4 botons de funcionalitats, per a crear nous camps, per a visualitzar camps esborrats, per a analitzar dependències en camps i finalment per a configurar un historial de canvis de dades en els registres de l’objecte. 61
Figura 7.15: Informació de camps de l’objecte Account en Salesforce. Dins de cada camp, trobarem informació sobre les seves metadades, com el nom API, etiqueta, creador, tipus de camp, i depenent del tipus de camp, trobarem informació característica de cada tipus. L'etiqueta del camp és el nom del camp que es veu en les interfícies d’usuari mentes que el nom API es el nom que s’usa per a indicar el camp dins les fórmules i codi de Salesforce. També trobarem botons de funció per habilitar l’edició, veure els permisos del camp a nivell de perfil, l’accessibilitat del camp en funció de les interfícies de l’objecte i finalment on s’usa el camp dins el sistema. Aquest últim botó ens pot ser útil per a detectar possibles dependències i camps obsolets. Tot objecte de Salesforce estàndard i personalitzat tindrà uns camps estàndard per defecte. Aquests camps es diferenciaran dels camps personalitzats perquè aquests últims contenen els caràcters __c al final del nom API. D'igual manera els objectes personalitzats també contindran aquests caràcters al final del seu nom API. 62
Figura 7.16: Especificació de l’atribut Lares Falecido de l’objecte Account en Salesforce. Per a crear un nou camp dins d’un objecte, polsarem el botó de New situat en la pestanya de Fields and Relationships i seguirem el Wizard de creació de nous camps. Com a breu resum, haurem d’escollir el tipus de camp dels camps disponibles, haurem d’anomentar el nou camp amb una etiqueta i nom API i finalment acabar de configurar el camp segons el seu tipus. Com a tipus de camps dins de Salesforce tindrem [43] : Tipus de Camp Descripció Número Automàtic Un número de seqüència generat pel sistema que utilitza un format de visualització que definiu. El número s'incrementa automàticament per a cada registre nou. Fórmula Un camp de només lectura que deriva el seu valor d'una expressió de fórmula que definiu. El camp de la fórmula s'actualitza quan canvia algun dels camps d'origen. Roll-Up Un camp de només lectura que mostra la suma, el valor mínim o màxim d'un camp en una llista relacionada o el recompte de registres de tots els registres enumerats en una llista relacionada. 63
Relació LookUp Crea una relació que enllaça aquest objecte amb un altre objecte. El camp de relació permet als usuaris fer clic a una icona de cerca per seleccionar un valor d'una llista emergent. L'altre objecte és l'origen dels valors de la llista. Relació Mestre-Detall Crea un tipus especial de relació pare-fill entre aquest objecte (el fill o "detall") i un altre objecte (el pare o "mestre") on: ● El camp de relació és obligatori en tots els registres detallats. ● El registre mestre determina la propietat i la compartició d'un registre de detall. ● Quan un usuari suprimeix el registre mestre, s'eliminen tots els registres detallats. Casella Permet als usuaris seleccionar un valor Vertader (marcat) o Fals (no marcat). Divisa Permet als usuaris introduir un import en dòlars o una altra moneda i forma automàticament el camp com a import en moneda. Data Permet als usuaris introduir una data o triar una data d'un calendari emergent. Data amb temps Permet als usuaris introduir una data i una hora. Email Permet als usuaris introduir una adreça de correu electrònic, que es valida per garantir el format adequat. Geolocalització Permet als usuaris definir ubicacions. Inclou components de latitud i longitud i es pot utilitzar per calcular distància. Número Permet als usuaris introduir qualsevol número. Percentatge Permet als usuaris introduir un nombre de percentatge, per exemple, "10" i afegeix automàticament el signe de percentatge al nombre. Telèfon Permet als usuaris introduir qualsevol número de telèfon. El forma automàticament com a número de telèfon. Llista de selecció Permet als usuaris seleccionar un valor d'una llista que definiu. 64
R/T/M [confidencial] Text [confidencial] R/T/M [confidencial] Currency [confidencial] Atributs Interns All [confidencial] Checkbo x [confidencial] All [confidencial] Text [confidencial] Taula 7.7: Especificació dels atributs de l’objecte Servei. Account [RecordType=PersonAccount] (Compte Personal) Tipus de Compte Personal API SF Tipus de Camp Descripció Atributs d’Interfase Atributs Genèrics Client/Difunt [confidencial] Id [confidencial] Client/Difunt [confidencial] Id [confidencial] Client/Difunt [confidencial] Datetime [confidencial] Client/Difunt [confidencial] Id [confidencial] Client/Difunt [confidencial] Picklist [confidencial] Dades Generals del Compte Personal Client/Difunt [confidencial] Text [confidencial] Client/Difunt [confidencial] Text [confidencial] Client [confidencial] Text [confidencial] Client/Difunt [confidencial] Picklist [confidencial] Client/Difunt [confidencial] Date [confidencial] Client/Difunt [confidencial] Text [confidencial] Client/Difunt [confidencial] Picklist [confidencial] Client/Difunt [confidencial] Long-text [confidencial] Client [confidencial] Text [confidencial] Client/Difunt [confidencial] Picklist [confidencial] 71
Client/Difunt [confidencial] Picklist [confidencial] Client [confidencial] Text [confidencial] Client [confidencial] Text [confidencial] Client/Difunt [confidencial] Text [confidencial] Client/Difunt [confidencial] Text [confidencial] Client [confidencial] Text [confidencial] Apartat de Consentiments GDPR Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Client [confidencial] Checkbox [confidencial] Camps de Domicili Client/Difunt SERV_Codigo_Postal_ _c LookUp (Codigo Postal) Codi postal Client/Difunt SERV_Localidade__c Text Municipi Client/Difunt SERV_Freguesia__c Text Districte parroquial Client/Difunt SERV_Morada__c Text Direcció de l’habitatge Client/Difunt SERV_Concelho__c LookUp (Concelho) Comarca Client/Difunt SERV_Pais__c Picklist Pais Dades de la defunció Difunt [confidencial] Date [confidencial] Difunt [confidencial] Time [confidencial] Difunt [confidencial] Checkbox [confidencial] Difunt [confidencial] LookUp (Account) [confidencial] Difunt [confidencial] LookUp [confidencial] 72
(Account) Difunt [confidencial] LookUp (Concelho) [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] Checkbox [confidencial] Difunt [confidencial] Checkbox [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] LookUp (Account) [confidencial] Difunt [confidencial] LookUp (Account) [confidencial] Difunt [confidencial] Long-text [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Dades del difunt Difunt [confidencial] Date [confidencial] Difunt [confidencial] LookUp (Concelho) [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Date [confidencial] Difunt [confidencial] Numer [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Text [confidencial] Estat civil del difunt 73
Difunt [confidencial] LookUp (Account) [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] Date [confidencial] Difunt [confidencial] Text [confidencial] Difunt [confidencial] Picklist [confidencial] Difunt [confidencial] Long-text [confidencial] Difunt [confidencial] Checkbox [confidencial] Difunt [confidencial] Checkbox [confidencial] Atributs Interns Client/Difunt SERV_Codigo_Postal_ aux__c Text Camp intern de codi postal per la integració Serviout - Salesforce Difunt SERV_Concelho_aux_ _c Text Camp intern de concelho per la integració Serviout - Salesforce Difunt SERV_Concelho_Falec imiento_aux__c Text Camp intern de concelho falecimento per la integració Serviout - Salesforce Difunt SERV_Concelho_Fisca l_aux__c Text Camp intern de concelho fiscal per la integració Serviout - Salesforce Client/Difunt SERV_Conta_Pessoal _ID_SO__c Text Id extern del compte per la integració Serviout - Salesforce Client/Difunt SERV_Criado_de_Inter locutor__c Checkbox Indica si s’ha creat a partir d’un interlocutor Difunt SERV_Hospital_Faleci do_aux__c Text Camp intern d'hospital per la integració Serviout - Salesforce Difunt SERV_Lares_Falecido _aux__c Text Camp intern de Lares per la integració Serviout - Salesforce Taula 7.8: Especificació dels atributs de l’objecte Compte Personal. A continuació mostrarem la taula pels atributs dels comptes no personals, es a dir, els comptes d’entitats com empreses, espais, cementiris, etc. Com en els altres objectes tindrem la columna de tipus de registre. En aquest cas la llegenda serà C=Cementiri, L=Loja, T=Tanatori, LF=Lloc de Defunció 74
Account [RecordType!=PersonAccount] (Comptes d’Entitats) Tipus de Compte API SF Tipus de Camp Descripció Atributs d’Interfase Atributs Genèrics C/L/T/LF Id Id Id intern de cada servei dins Salesforce C/L/T/LF CreatedById Id Id del usuari que ha creat el registre C/L/T/LF CreatedDate Datetime Data de creació C/L/T/LF RecordTypeId Id Camp que identifica el tipus de compte Detalls del compte C/L/T/LF Name Text Nom de l’entitat C/L/T/LF SERV_Nome_Adicional __c Text Nom addicional de l’entitat. C SERV_Prazo_Ex__c Number Període d’anys per a realitzar l'exhumació C/L/T/LF SERV_Email__c Text Email C/L/T/LF Phone Text Telèfon C/L/T/LF SERV_IBAN__c Tect IBAN C/L/T/LF SERV_Capacidad_afor o__c Number Aforament C/L SERV_Cuenta_relacion ada__c LookUp (Account) Compte relacionat L SERV_Empresa__c Picklist Indica si l’entitat correspon a l’empresa de Servilusa o Triunfo L SERV_Delegacao__c Picklist Indica la delegació de Portugal T SERV_Tipo_Local_Vel orio__c Picklist Tipus de tanatori LF SERV_Tipo_Local_Fal ecido__c Picklist Tipus de lloc de defunció Detalls de direcció C/L/T/LF SERV_Codigo_Postal_ LookUp Codi postal 75
_c (Codigo Postal) C/L/T/LF SERV_Localidade__c Text Municipi C/L/T/LF SERV_Freguesia__c Text Districte parroquial C/L/T/LF SERV_Morada__c Text Direcció de l’habitatge C/L/T/LF SERV_Concelho__c LookUp (Concelho) Comarca C/L/T/LF SERV_Pais__c Picklist País C SERV_Coordenadas_N _e_W__c Text Coordenades de la geolocalització de l’entitat. C/L/T/LF SERV_Zona__c LookUp (Lugar) Zona de Portugal de l’entitat L SERV_Subzona__c Text Subzona Taula 7.9: Especificació dels atributs de l’objecte Compte. Finalment, com a últim objecte a descriure, tindrem els Interlocutors. Aquest objecte, a diferencia dels Comptes i Serveis, no tindran tipus de registre. Interlocutor__c (Interlocutor) API SF Tipus de Camp Descripció Atributs d’Interfase Atributs Genèrics Id Id Id intern de cada servei dins Salesforce CreatedById Id Id del usuari que ha creat el registre CreatedDate Datetime Data de creació Detalls d’Interlocutor [confidencial] Text [confidencial] [confidencial] Text [confidencial] [confidencial] Text [confidencial] [confidencial] Picklist [confidencial] [confidencial] Date [confidencial] 76
[confidencial] Text [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Number [confidencial] [confidencial] Picklist [confidencial] [confidencial] Text [confidencial] Altra Informació de l’Interlocutor [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Text [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Text [confidencial] [confidencial] LookUp (Account) [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Text [confidencial] [confidencial] Text [confidencial] [confidencial] LookUp (Servicio) [confidencial] [confidencial] Data [confidencial] [confidencial] Text [confidencial] [confidencial] Text [confidencial] Camps de Domicili SERV_Codigo_Postal__c LookUp (Codigo Postal) Codi postal SERV_Localidade__c Text Municipi SERV_Freguesia__c Text Districte parroquial 77
SERV_Morada__c Text Direcció de l’habitatge SERV_Concelho__c LookUp (Concelho) Comarca SERV_Pais__c Picklist Pais Atributs Interns SERV_Codigo_Postal_aux__c Text Camp intern de codi postal per la integració Serviout - Salesforce SERV_Concelho_aux__c Text Camp intern de concelho per la integració Serviout - Salesforce Taula 7.10: Especificació dels atributs de l’objecte Interlocutor. 78
7.6. Interfícies d’Usuari Per al disseny de les interfícies d’usuari, es va usar l’eina de Salesforce Lightning Page Builder, que és una eina estàndard de Salesforce que permet el disseny declaratiu d’interfícies d’usuari, sense la necessitat de codi ni desenvolupament front-end. Aquesta eina permet la distribució d'atributs en seccions, l’us de mòduls i components de Salesforce estàndard o personalitzats, l’ús de filtres de visibilitat en els diferents components i atributs. Finalment, també l’aplicació de filtres de visibilitat a nivell d’interfície, per a poder usar una Lightning Page segons el tipus de registre (RecordType), perfil d’usuari o inclús d’aplicació. Per a l’estructuració de les interfícies ens vam basar en les interfícies dels objectes ja existents a Serviout, com en el cas dels registres de Clients, Difunts, Serveis. Es va escollir replicar l’estructura d’aquests objectes de la plataforma anterior per a facilitar la usabilitat i interacció de l’usuari en fer el canvi entre les dues plataformes. Pels objectes en els quals no existien en el sistema antic, es van concertar reunions amb el client per a decidir la millor distribució. Molta de la feina del disseny d’interfícies la van fer els consultors, donat que, com s’ha explicat anteriorment, no es requereix codi per aquest desenvolupament. En aquest apartat, doncs, sols es mostraran i detallaran les interfícies en les quals personalment s’ha treballat la majoria de temps. 7.6.1. Interfícies dels Serveis ● Capcçalera: Figura 7.18: Capçalera de la interfície de Serveis. 79
En la capçalera de la interfície de serveis s’ha configurat per mostrar els 5 camps principals, com són el tipus de servei, el número de referència del servei, el client, el difunt, el cas i l'agència que tramita el servei. També s’ha configurat un flux d’estats per a mostrar l’estat del servei. També es mostren les accions que es poden realitzar dins el servei, com, per exemple, crear un nou cas Incidències/Reclamacions, Enviar a Serviout, crear una petició de suport, editar i Afegir un Usuari Addicional. També observem el component a la dreta de la pantalla per crear una nota dins el servei. Finalment, observem una llista de les tasques del servei pendents i completades. ● Detalls del Servei: 80
7.6.5. Interfície d’Interlocutor Per als interlocutors tindrem una interfície molt pareguda a la dels clients, exceptuant alguns camps com són el servei relacionat, el parentesc de l’interlocutor respecte al difunt del servei, si l’interlocutor ha estat usat per facturar, etc. No tindrem ni llistes relacionades ni cap component addicional. Figura 7.25: Secció de detalls de la interfície d’Interlocutors. 87
7.7. Desenvolupament de les Funcionalitats 7.7.1. Regles de Validació Per a mantenir una qualitat de dades i uns estàndards dins de l’organització, usarem, entre moltes altres eines de Salesforce, les Regles de Validació. Aquestes regles són una fórmula a nivell declaratiu que permeten avaluar unes condicions quan es crea o modifica un registre i retornar cert o fals. En cas d'avaluar a cert, es dispara un error, que es pot visualitzar a nivell de registre o camp. Aquesta eina es permetrà. Entre altres coses, aplicar moltes de les restriccions textuals dels objectes. Per a la configuració de les regles de validació, haurem de donar un nom a la regla, una fórmula, un missatge d’error i una ubicació d’error. Es pot veure un exemple en la figura següent. L'avantatja que ofereixen les regles de validació entre altes solucions estàndard de Salesforce és que permeten una configuració i modificació immediata en entorns de producció: canviar la fórmula, el missatge d’error, activar i desactivar. Per aquesta primera part de contractació, sols tindrem regles de validació per a casos. La primera regla de validació que veurem serà per a la restricció textual de casos número 8. Aquesta restricció diu que el motiu de tancament d’un cas ha de ser informat durant l’estat del cas és ‘Sense Èxit’ o ‘Desconegut’. Figura 7.26: Interfície de configuració per la regla de validació Motivo Cerrado no Informado. 88
Figura 7.27: Interfície de configuració del missatge d’error per la regla de validació Motivo Cerrado no Informado. Com es pot veure en la figura següent, en cas de no complir-se les condicions, salta un error en el camp indicat i no deixa guardar. Figura 7.28: Exemple d’error en l’edició d’un cas per la regla de validació Motivo Cerrado no Informado. La segona regla de validació ens servirà per a la restricció textual 10, per validar que per als casos cancel·lats s’informi el motiu d’anul·lació. Aquí finalment s’afegeix que aquest motiu sols haurà de ser informat per a uns tipus concrets de casos. 89
ISPICKVAL( SERV_Estado__c , "Cancelado" ) && ISPICKVAL( SERV_Motivo_Anulacion__c , "" ) && ( ( RecordType.Name = "Funeral" ) || ( RecordType.Name = "Pós-Contratação" ) || ( RecordType.Name = "Flores" ) || ( RecordType.Name = "Orçamentos" ) || ( RecordType.Name = "Exumações" ) || ( RecordType.Name = "Jazigos e Sepulturas" ) || ( RecordType.Name = "Reclamações" ) || ( RecordType.Name = "Incidências" ) ) Codi 7.2: Fórmula per a la regla de validació d’informar el motiu d’anul·lació. 7.7.2. Configuració de Perfils i permisos Dins Salesforce tenim diferents eines per a gestionar els permisos i funcions permeses dels diferents usuaris dins la plataforma. En aquest apartat es mostrarà com s’ha configurat aquestes eines per a mantenir uns rols i estructura organitzativa dins l’empresa i complir els requisits de privacitat sol·licitats pel client. En primer lloc, configurarem els perfils. Els perfils de Salesforce són una eina que podem assignar usuari a usuari. Ens ajudaran a configurar els permisos de lectura/escriptura a nivell d’objecte i d'atribut d’objecte. També ens ajudaran en l’assignació d’aplicacions i interfícies. Finalment, també permetran activar o desactivar diferents funcions dins de la plataforma com la possibilitat d’executar classes Apex, crear reports, vistes de llista, etc. 7.7.3. Automatisme per als Codis Postals Per a facilitar la introducció de direccions postals dins de les interfícies i per evitar errors, es va decidir dissenyar un automatisme que, quan s'indiqués el codi postal dins una secció de direcció, s’emplenessin altres dades extrapolables del codi postal com són el país, “localidade” (municipi) i “concelho” (comarca). Per a aconseguir aquest objectiu, vam haver de crear un objecte anomenat Codi Postal per emmagatzemar tota la combinació possible de codis postals de Portugal (170000) que vam extreure d’una pàgina governamental. Esquema de la Funcionalitat: En primer lloc, es va haver de plantejar l’estructura de l’objecte per a poder guardar tots els possibles codis postals i la seva informació. Més endavant, es va ficar un camp Look-Up en els objectes que tinguessin camps de direcció, en el nostre cas de moment sols en els comptes personals. Finalment, es va configurar un “Trigger Flow” perquè quan se seleccionés un Codi Postal de la llista, s'emplenessin els altres camps de direcció derivats. Amb aquesta configuració, habilitem aquesta funcionalitat de auto-emplenament i també deixem l’opció a l’usuari de poder canviar el valor dels camps auto-replenats si es desitgés. 90
Resultat Final: L’estructura de l’objecte Codi Postal es pot veure en el següent Page Layout: Figura 7.29: Interfície de l’objecte codi postal. Un cop tingut l’estructura de l’objecte, es va procedir a crear els Look-Ups en l’objecte “Account” (Compte) i a ficar-los en el Page Layout dels comptes personals. Figura 7.30: Exemple de procés d’afegir un codi postal en un Compte. En ser el camp en format Look-Up, el sistema ens deixa escriure el codi que desitgem i ens va mostrant suggeriments. Seleccionant l’opció de mostrar tots els resultats, podrem veure totes les opcions coincidents amb la nostra cerca i veure els atributs del codi. 91
Figura 7.31: Exemple de taula de codis postals que es genera en buscar-ne un per afegir. Finalment, vam configurar la lògica en el Trigger Flow de l’objecte Account. En el flow mirem si s’ha canviat el valor del camp Look-Up SERV_Codigo_Postal__c i en cas positiu, traspassem la informació del registre del codi postal introduït als camps de País, Localidade i Concelho. Finalment, actualitzem en la base de dades el compte. Figura 7.32: Flux disparador per a la funcionalitat d’emplenar els camps de direcció en afegir un codi postal. 92
Figura 7.33: Configuració del component d’assignació dels atributs de direcció a partir d’un codi postal dins el flux. 93
7.7.4. Configuració dels Permisos Per a la configuració dels permisos a nivell d’objecte i atributs usarem els perfils i rols de Salesforce assignats a cada usuari de la plataforma. Per aquesta etapa de contractació, haurem de configurar els permisos per a 7 objectes, els més importants sent Cas i Servei. Tot i això, sols es detallaran els permisos configurats per jo mateix. Abans de començar, però, haurem de configurar la jerarquia de rols, vista en l’apartat dels requisits funcionals, dins de Salesforce. Figura 7.34: Rols de Servilusa definits en Salesforce. Configuració dels Permisos de Casos i Serveis: Per a cas i servei, els requisits de l’empresa eren que els Tècnics/Coordinadors Comercials i els Coordinadors de Loja sols poguessin veure/editar els serveis els quals estaven assignats com a propietaris i que poguessin crear serveis. Per assolir aquest requisit, vam haver de configurar en el perfil l’objecte de Cas i Servei com a Read, Edit, Create . 94
Figura 7.35: Configuració dels permisos del perfil Tècnic Comercial per a l’objecte Servei. Els usuaris del Contact Center, a més dels permisos anteriors, també tenien el permís de veure tots els serveis del sistema. Per aquest motiu es va marcar la casella de View All . Els usuaris de GUN i els Administradors del sistema tindran tots els permisos habilitats. A més a més dels permisos atorgats perfils, els usuaris de Servilusa volien habilitat l’accés als serveis i casos segons el rol de l’usuari i la zona i empresa del registre. Per aquest requisit, es van configurar unes Sharing Settings . Figura 7.36: Configuració de les Sharing Settings per a l’objecte Caso. 95
En la figura anterior tenim la configuració completa de les Sharing Settings per als casos. La configuració per als serveis serà idèntica. En la configuració podem observar com, per exemple, si un cas es de la zona Alentejo i de l’empresa Servilusa, l’accés en lectura/escriptura pel registre s’habilitarà per a tots els usuaris amb el rol Alentejo i per a tots els usuaris damunt de la jerarquia del rol. A nivell d'atributs, per norma general, tots els usuaris tindran permisos de lectura i escriptura a tots els camps exceptuant als camps fórmula (que no es poden editar) i a alguns camps interns usats per a processos del sistema o integracions. Figura 7.37: Exemple de configuració permisos a nivell de camp per a l’objecte Servei. Configuració de Permisos de Comptes: Per als comptes, el requisit era que tots els usuaris tinguéssin acces CRUD a tots els comptes del sistema. A part, sols haurien de poder crear comptes personals de clients i difunts, els comptes de Lojas, Cementiris, etc, estaven reservats per la creació d’administradors del sistema i usuaris GUN. Com pels anteriors objectes, els usuaris de GUN i els Administradors del sistema tindran tots els permisos habilitats. Per assolir aquest objectiu, en el perfils es van marcar les caselles de llegir, escriure, crear, veure tots i modificar tots. 96
API SF Tipus de Camp Descripció Name Text Nom del log Exception__c Text Tipus d’excepció ExceptionStackTrace__c Text Traça de l'excepció HTTPMethod__c Text Mètode HTTP usat (GET, POST, etc) Id__c Auto-number Numeració automàtica del Log RecordId__c Text Id del registre o registres enviats en la integració RequestBody__c Text Cos de la petició HTTP ResponseBody__c Text Cos de la resposta HTTP Source__c Text Indicador de la procedència del Log Status__c Text Estat de la resposta HTTP (OK, unauthorized, read time out, etc) StatusCode__c Number Codi del estat de la trucada HTTP (200, 201, 401, etc) Taula 7.12: Taula d’atributs de l’objecte Log. 7.8.2. Desenvolupament de Codi Per començar amb el desenvolupament de la integració, començarem pel desenvolupament de les classes Apex encarregades de la comunicació HTTP amb el web service de Serviout. En primer lloc, haurem de desenvolupar un mètode per a fer la primera trucada HTTP per a recollir la clau d’accés per a posteriorment poder enviar les dades a Serviout. [confidencial] Codi 7.3: Funció getAccessToken per a recollir la clau d’autenticació al web service de Serviout. Aquesta traça de codi obté les credencials d’accès d’un Custom Metadata Object de Salesforce anomenat Integraci_n_Serviout__mdt i després crea una HTTP Request amb l’endpoint de Serviout, els headers i el body corresponent. Un cop configurada la request, aquesta és enviada i una resposta en format JSON és rebuda amb el token d’accés (vegeu Annex A.2 per al format de la resposta). Es processa la resposta i finalment es retorna el token. 103
Com a segon mètode a desenvolupar per la integració tindrem el mètode callCreateRegServiout , encarregat de l’enviament d’un servei i tots els altres registres relacionats a aquest a Serviout. Per a facilitar la lectura de la classe, en el codi s’ha afegit comentaris respecte a diferents funcionalitat i també respecte a la distribució del codi en parts. Com a primera part del mètode, obtindrem els registres i els seus atributs usant els mètodes auxiliars continguts en la classe ServioutIntegrationHelper. Aquesta classe està documentada posteriorment. En el cas de ser un servei PFV (Pla funeral en vida), agafarem les dades de la persona designada del servei, en comptes del difunt. Com a segona part del mètode, tindrem el codi per a muntar la request HTTP. Els passos a seguir seran, obtenir el token d’accés amb el mètode descrit anteriorment, obtenir l’endpoint d’enviament i establir el header, method i body de la request. Al tractar-se d’una request multi-form usarem la classe auxiliar HttpFormBuilder. Per al body també necessitarem transformar els registres a enviar al format JSON corresponent. Per a generar els JSONs dels objectes, usarem la classe auxiliar ServioutIntegrationHelper . En la tercera i última secció enviarem la request i processarem la resposta del servidor. Encapsularem l’enviament de la request en un try catch per a processar qualsevol error Apex o HTTP que es causi en l’enviament i poder registrar-lo en un Log. Si no es produeix cap error en l’enviament, es procedeix a processar la resposta del servidor. Si el codi de resposta es un 200 OK, significa que la request ha set exitosa i que les dades han set rebudes i processades correctament per Serviout. En aquest cas, llegirem les dades de la resposta i actualitzarem els registres amb els ids externs que ens ha retornat Serviout (vegeu annex A.2 per un exemple de la resposta). Per al cas del servei enviat, li assignarem el número de referència i l'ID extern retornats en la resposta. Per al cas del client i el difunt, els hi assignarem l'ID extern retornat per la trucada. Totes les actualitzacions als registres les encapsularem dins un try catch per a poder registrar qualsevol error. Finalment, guardarem en un Log la informació de la trucada HTTP. [confidencial] Codi 7.4: Funció callCreateRegServiout per a efectuar enviaments mitjançant web service a Serviout. Com ja hem comentat anteriorment, per a facilitar el desenvolupament i encapsular els mètodes auxiliars de la integració, tindrem la classe ServioutIntegrationHelper . Aquesta classe contindrà, principalment mètodes per a obtenir registres i els seus atributs mitjançant sentències SOQL i també mètodes per a construir els JSONs dels registres. Per a facilitar la lectura d’aquesta documentació el codi de la classe s’ha ubicat en l’annex A.3. Finalment, tindrem la classe SendtoServiout que serà la classe que invocarà el flux de pantalla per enviar els registres a Serviout. Com que els enviaments a Serviout els podrà realitzar qualsevol usuari amb accés a la interfície de serveis, haurem de validar que l’usuari 104
tingui els permisos necessaris per a efectuar totes les operacions DML necessàries. Per aquest objectiu, la classe inclou un mètode per a validar els permissos de l’usuari. En cas de no tenir els permisos, la classe retorna un codi d’error que es mostraria per pantalla en el flux. Finalment, trobem el mètode invokeIntegration , que serà el mètode invocat pel flux de pantalla. Per aquest mètode usarem 2 classes auxiliars, FlowInputs i FlowOutputs, necessàries per a poder introduir dades i rebre dades de resposta des del flux. En aquesta funció cridarem a la funció d’enviament de dades i recollirem el Log generat per la funció. Després llegirem les dades del log i emplenarem les variables de sortida amb les dades d’aquest. [confidencial] Codi 7.5: Classe Apex SendtoServiout per a habilitar els enviaments a Serviout a través d’un Flux de Salesforce. 7.8.3. Desenvolupament del Flux de Pantalla Com a desenvolupament final d’aquesta integració, tindrem el flux de pantalla que habilitarà als usuaris a enviar un servei a Serviout amb un botó ubicat en la interfície dels serveis. Figura 7.42: Capçalera de la interfície de Servei amb el botó Enviar a Serviout. 105
106
Figura 7.43: Flux de pantalla per als enviaments a Serviout. 107
Una explicació esquematitzada d’aquest flux es pot trobar en l’esquema 7.X en la introducció d’aquest apartat. Per a visualitzar més en detall com funciona i es visualitza el flux, veurem un exemple d’un enviament a Serviout amb totes les casuístiques possibles. En primer lloc, es pot donar el cas que el servei ja hagi set enviat a Serviout i l’usuari torni a enviar-lo per error. En aquest cas s’ha d’enviar l’enviament i mostrar un missatge d’avis en pantalla. En aquest cas, s’indica que el servei ja ha set enviat anteriorment, s’indica l’ID del servei, el seu número de referència i finalment un enllaç perquè l’usuari pugui accedir al servei de Serviout sense problemes. Figura 7.44: Exemple de pantalla indicant un enviament no possible degut a ja haver set enviat prèviament. En segon lloc tenim el cas que el servei encara no hagi set enviat. En aquest cas, haurem d’invocar des del flux la casse Apex SendtoServiout per a efectuar l’enviament a Serviout. En cas que no es produeixi cap error, mostrarem per pantalla un missatge d’èxit i les dades del servei enviat juntament amb el seu enllaç de Serviout. Figura 7.45: Exemple de pantalla indicant un enviament correcte d’un servei a Serviout. En qualsevol cas que s'efectuï un enviament de registres, es crearà un Log amb totes les dades de la trucada HTTP. A aquest Log hi podrem accedir a través d’una query SOQL des d’una eina de visualització de dades de Salesforce com la Developer Console o el Salesforce Inspector o des de la interfase de l'objecte. 108
Figura 7.46: Exemple de Log generat per l’enviament d’un Servei a Serviout. En cas que un usuari invoqui la integració sense tenir un ID d'usuari de Serviout, es mostrarà un error per pantalla. Figura 7.47: Exemple de pantalla indicant que l’usuari requereix un identificador de Serviout per a poder efectuar enviaments. 109
En cas que es produeixi una excepció d’Apex durant l’enviament HTTP, es mostrarà un error per pantalla. Aquests errors són molt inusuals i sols es poden produir degut a un error de configuració de Salesforce com, per exemple, no habilitar la connexió a un endpoint remot o per falta de permisos de l’usuari. També es poden produir a causa d'un error en la banda de l’endpoint com, per exemple, tardar més de 2 minuts en respondre. Figura 7.48: Exemple de pantalla indicant un error Apex en l’enviament a Serviout. En cas que Serviout ens respongui amb un missatge d’error, aquest es mostrarà per pantalla. Aquests missatges són molt inusuals, però poden arribar a ocórrer degut a un possible error de configuració de Salesforce. Figura 7.49: Exemple de pantalla indicant un error de Web Service en l’enviament a Serviout. Finalment, trobem els missatges d’error que provenen a causa de la manca de camps requerits en el servei per a efectuar l’enviament. Figura 7.50: Exemple de pantalla indicant un error per falta de dades en el Servei. 110
7.9. Tests Per a dur a terme tots els tests de les funcionalitat i de la integració, es va crear un entorn Sandbox que era una còpia exacta de l’entorn de Producció. Encara que l’enton de Producció no fos funcional, es bona praxi desenvolupar i fer totes les proves en un entorn Sandbox per després acabar pujant els canvis correctes a l’enton de producció. Un cop arrencat l’ús de l’entorn de producció es va passar a usar 2 Sanboxes per a passar tests i proves d’acceptació d’usuari. Per a dur a terme els canvis entre entorns, Salesforce disposa de l’eina Change Sets o conjunt de canvis. Aquesta eina ens habilita seleccionar tota mena de metadades de l’entorn, com interfícies, codi, objectes, atributs, etc, i carregar-ho i descarregar-ho entre entorns. En la següent imatge podem veure un exemple de conjunt de canvis en el que podem veure l'organització d'origen, el nom, l'històric de desplegaments i els components del conjunt. Per evitar errors de dependències entre entorns, els conjunts de canvis efectuen unes operacions de validació abans de desplegar un conjunt en un entorn. Per exemple, si es puja un camp fórmula on es referència un altre camp de l’objecte, però aquest camp no es troba en el sistema, el desplegament del conjunt falla i es mostra l’error. També es passen els tests unitaris per al codi Apex. 111
Figura 7.51: Pàgina d'un conjunt de canvis dins Salesforce. Per a testejar i depurar els fluxos, tenim l’eina Debug . Amb aquesta funció, podrem provar la funcionalitat d’un flux introduint els registres desitjats per executar. Podrem també executar els fluxos com un altre usuari del sistema per a poder comprovar, per exemple, si té tots els permisos necessaris per a realitzar la funció. En els fluxos de pantalla podrem veure un mode de depuració amb les pantalles a l’esquerra i el registre de depuració a la dreta. Amb els fluxos disparadors tindrem més paràmetres d’entrada, com, per exemple, escollir el camí del flux a depurar, escollir l’operació a executar i finalment decidir si fer un Rollback al final de l’execució. Quan executem el flux, ens sortirà un camí dins el flux indicant el camí i operacions que s’han anat fent. 112
Figura 8.1: Diagrama del procés de post-contractació entre els sistemes Serviout i Salesforce. Elaboració pròpia. 119
8.2. Característiques del Sistema 8.2.1. Requisits Funcionals i Casos d’ús Un dels principals motius de la implantació de Salesforce per a Servilusa era la informatització de les tasques de post contractació del serveis que ofereixen. La gestió dels serveis requereix una gran quantitat de burocràcia i la definició i digitalització d’aquests processos aportarà un gran valor i benefici a l’empresa, millorant la qualitat dels serveis i l’eficiència temporal. Gràcies als fluxos de pantalla de Salesforce i la seva fàcil construcció, no va suposar una gran inversió de temps implementar les interfícies i lògica interna per a les accions de les tasques, comparant-ho amb una implantació web estàndard, amb JavaScript, HTML i codi backend. Per aquesta primera fase 1 del sistema, es van desenvolupar les tasques corresponents als serveis de funerals. En ser un aspecte del negoci molt dificultós, donat que existien molts processos i casuístiques diferents, la definició d’aquestes tasques va passar 2 processos diferents. En primera instància els consultors van definir les tasques a grans trets, amb unes taules, indicant els diferents atributs de la tasca, com l’assignació i la data límit i després, l’acció a realitzar per a completar la tasca. Com que no es va participar en aquesta primera etapa, no es mostraran les taules. Per contra, sí que es mostrarà l'etapa 2, on es va treballar. En aquesta segona etapa vam participar els desenvolupadors del sistema i l’objectiu va consistir a esquematitzar tots els processos de l’acció de cada tasca en forma de Brief Style o, per a accions més llargues, en forma de diagrama de flux. En tenir un extens procés de gestió per als serveis funeraris, es va elaborar també un diagrama de processos amb totes les taques identificades i el disparador que provocava la seva creació. En el primer diagrama de processos mostrat a continuació, es mostra el flux de creació de tasques quan rebem un primer pressupost tancat del servei. En rebre aquest primer pressupost, haurem de generar la tasca de “Registo de Pagamento”, actualitzar el servei a estat de post-contractació i generar la tasca d'Obtenir Documentació. A partir de la tasca d’obtenir documentació, anirem generant les següents tasques, que es generaran quan es conclogui la tasca precedent o es canvii un camp designat del servei. Per assolir aquestes funció haurem de programar un disparador per l’objecte Pressupost (Orçamento), per a generar la tasca i actualitzar el servei i també un disparador pels serveis perquè quan passin a post-contractació o actualitzi qualsevol altre camp indicat, generi les tasques corresponents. En el diagrama, els requadres marcats amb groc representen la integració de Serviout i els marcats en verd representen les tasques desenvolupades per mi. També es representen les actualitzacions en BBDD amb un cilindre, les decisions amb un rombe, els bucles amb un cercle i les tasques i disparadors amb un requadre. 120
Diagrama de tasques de Post-Contractació: 121
122
Figura 8.2: Diagrama núm. 1 de processos per a la generació de les tasques de post-contractació. Elaboració pròpia. 123
En el segon diagrama de processos mostrat a continuació, es mostra el flux de creació de tasques quan rebem un pressupost definitiu del servei. En rebre aquest pressupost, haurem de generar un avís per a la Loja del servei, actualitzar l’etapa de post-contractació del servei i generar un seguit de tasques, algunes amb unes condicions particulars. A més a més, també haurem de llegir les línies de pressupost que ens arriben per identificar si el client ha contractat un servei de picapedrer i actualitzar el servei corresponentment. En una propera fase del projecte també es generaran tasques per aquests serveis addicionals. 124
Figura 8.3: Diagrama núm. 2 de processos per a la generació de les tasques de post-contractació. 125
Seguidament, veurem l'especificació en Brief Style de les tasques desenvolupades per mi. En el pròxim apartat de desenvolupament de les funcionalitats veurem com s’ha muntat totes les interfícies i lògica d’algunes tasques. Tasca 1: “Obter Documentação” Informació Assignada al tècnic del ervei. Data de venciment igual a data de contractació del servei. Etapa PC “estafetagem”. Actors Usuari Precondicions El servei té un pressupost inicial tancat. Disparador L’usuari pressiona el botó “Obter Documentação” de la tasca Escenari Principal 1. S’obre una pantalla on l’usuari ha de penjar els documents d'identificació de difunt i de declaració de difunt. 2. L’usuari penja els 2 documents obligatoris 3. Es crea la tasca de ‘Registo de Óbito’ en el servei, si no existia. 4. Es passa a una altra pantalla on els demana de pujar el document d’identificació del client i qualsevol altre document. 5. L’usuari puja el document d’identificació del client i opcionalment qualsevol altre. 6. S’envia un email al departament d’Estafetagem de la zona del servei 7. Es crea la tasca de ‘Pedido Assento de Óbito’ en el servei, si no existia. 8. El sistema conclou la tasca actual. Escenaris Alternatius 2a. L’usuari no penja tots els documents obligatoris. 2a1. El sistema indica que s’ha de penjar tots els documents obligatoris. 3a. L’usuari no penja el document d’identificació del client. 3a1. El sistema indica que s’ha de penjar el document. Taula 8.1: Especificació Brief Style de la tasca “Obter Documentação” Tasca 2: “Pedido Assento de Óbito” Informació Assignada al tècnic del servei. Data de venciment igual a data de defunció més 2 dies laborals. Etapa PC “estafetagem”. Actors Usuari Precondicions S’ha completat la tasca d'Obtenir Documentació Disparador L’usuari pressiona el botó “Pedido Assento de Óbito” de la tasca 126
Escenari Principal 1. S’obre una pantalla on l’usuari ha de penjar el document de “Requisição de certidões”, o generar-lo en Serviout (s’envia a Salefsorce per integració) 2. L’usuari penja el document obligatori 3. Es crea la tasca de ‘Registo de Óbito’ en el servei, si no existia. 4. Es passa a una altra pantalla on l’usuari selecciona el tipus de comanda de defunció de les opcions de la llista del camp SERV_Tipo_de_Pedido__c. Es pot escollir més d’una opció. 5. Per cada opció escollida el sistema crea una tasca de tipus “Assignar Usuario Pedido [tipo] Assento Obito”, si no existeixen. 6. El sistema conclou la tasca actual. Escenaris Alternatius 2a. L’usuari no penja el document obligatori. 2a1. El sistema indica que s’ha de penjar tots els documents obligatoris. Taula 8.2: Especificació Brief Style de la tasca “Pedido Assento de Óbito” Tasca 3: “Assignar Usuario Pedido [tipo] Assento Obito” Informació Assignada al departament d’Estafetagem de la zona del servei. Data de venciment igual a la data de creació de la tasca més 1 dia laboral. Etapa PC “estafetagem”. Actors Usuari Precondicions S’ha completat la tasca de Pedido Assento de Óbito Disparador L’usuari pressiona el botó “Atribuir Usuário Pedido Assento Óbito” de la tasca Escenari Principal 1. S’obre una pantalla on l’usuari pot visualitzar el document de “Requisiçõ de certidões” i on l’usuari haurà de buscar un usuari de la llista d’usuaris del sistema per assignar-li la tasca de “Carregar Assento Óbito [tipo]” (on el tipus és l’escollit en la tasca Pedido Assento de Óbito) 2. El sistema, si no existeix, crea la tasca “Carregar Assento Óbito [tipo]” on el propietari serà l’usuari assignat anteriorment. 3. El sistema conclou la tasca actual. Escenaris Alternatius 1a. El sistema no troba el document de “Requisiçõ de certidões” 1a1. El sistema indica que s’ha de penjar el document o generar-lo en Serviout. Taula 8.3: Especificació Brief Style de la tasca “Assignar Usuario Pedido [tipo] Assento Obito” 127
Tasca 4: “Carregar Assento Óbito [tipo]” Informació Assignada a l’usuari escollit en la tasca precendent. Data de venciment igual a la data de creació de la tasca més 4 dies laborals. Etapa PC “estafetagem”. Actors Usuari Precondicions S’ha completat la tasca Assignar Usuario Pedido [tipo] Assento Obito Disparador L’usuari pressiona el botó “Carregar Assento Óbito” de la tasca Escenari Principal 1. S’obre una pantalla on l’usuari pot visualitzar el document de “Requisiçõ de certidões” i on l’usuari haurà de carregar els fitxers de “Assento Óbito [tipo]” i si el tipus de “Óbito” fos online també haurà de carregar el fitxer “Código Assento de Óbito Online” 2. L’usuari penja els documents obligatoris 3. Es passa a una pantalla on l’usuari haurà d’indicar la “Data Pedido Registo Óbito” i la Data de Chegada à Loja. Ambdós valors es guardaran en el servei. 4. El sistema envia un correu al departament d’Estafetagem de la zona del servei i al tècnic comercial del servei amb motiu de conclusió de la tasca. 5. El sistema conclou la tasca actual. Escenaris Alternatius 2a. L’usuari no penja els documents requerits 2a1. El sistema indica que s’ha de penjar els documents Taula 8.4: Especificació Brief Style de la tasca “Carregar Assento Óbito [tipo]” Tasca 5: “Registar o óbito” Informació Assignada al departament d’Estafetagem de la zona del servei. Data de venciment igual a la data de creació de la tasca més 3 dies laborals. Etapa PC “estafetagem”. Actors Usuari Precondicions S’ha completat la tasca “Obter Documentação” Disparador L’usuari pressiona el botó “Registo de óbito” de la tasca Escenari Principal 1. S’obre una pantalla on es mostra una llista de selecció amb el tipus de document de “óbito” a pujar. 2. L’usuari selecciona el tipus de “óbito” 3. Si selecciona “Botetim”, es passa a una pantalla on deixa pujar el boletim de forma opcional. 128
RecordTypeId id } Table Task { Id id [ primary key] WhatId id [ ref : > Servicio__c.Id] } Table Orcamento__c { Id id [ primary key] SERV_Servicio__c id [ ref: > Servicio__c.Id] } Table Linha_Orcamento__c { Id id [ primary key] Orcamento__c id [ ref: > Orcamento__c.Id] Produto__c id [ ref: > Produto__c.Id] SERV_Nome_do_Pagador__c id [ ref: > Account.Id] } Table Produto__c { Id id [ primary key] } Table Account { Id id [ primary key] } Codi 8.1: Definició de l’esquema de la base de dades de Salesforce per l’etapa de Post-Contractació. 8.5. Descripció de les Taules Per a facilitar la lectura de les taules, els possibles valors de les llistes de selecció (Picklists) estaran indicats en l’annex A.1. Per als pressuposts, no tindrem cap diferenciació de registres (RecordTypes) i per això no indicarem la columna Tipus. 135
Orcamento__c (Pressupost) API SF Tipus de Camp Descripció Atributs d’Interfase CreatedById LookUp (User) Id del usuari que ha creat el registre. CreatedDate Datetime Data de creació. LastModifiedById LookUp (User) Últim usuari en realitzar una modificació en el registre. Name Text (Auto number) Nom del pressupost. S’usa un nombre autogenerat usant la plantilla Orçamento - {000000} [confidencial] Text [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Roll-Up Summary [confidencial] [confidencial] Roll-Up Summary [confidencial] [confidencial] Text (Long) [confidencial] [confidencial] Text (Long) [confidencial] [confidencial] Master-Detail (Servicio__c) [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] [confidencial] Checkbox [confidencial] [confidencial] Percentage [confidencial] [confidencial] Picklist [confidencial] [confidencial] Picklist [confidencial] 136
[confidencial] Text [confidencial] [confidencial] Roll-Up Summary [confidencial] [confidencial] Roll-Up Summary [confidencial] [confidencial] Checkbox [confidencial] Atributs Interns SERV_External_Id_SO__c Text, unique, external id ID extern per vincular el registre entre Salesforce i SO Id Id Id intern de cada servei dins Salesforce OwnerId LookUp (User) Usuari propietari del registre. Taula 8.11: Especificació dels atributs de l’objecte Pressupost Linha_Orcamento__c (Línia de Pressupost) API SF Tipus de Camp Descripció Atributs d’Interfase CreatedById LookUp (User) Id del usuari que ha creat el registre. CreatedDate Datetime Data de creació. LastModifiedById LookUp (User) Últim usuari en realitzar una modificació en el registre. Name Text Nom de la línia del pressupost. S’usa per indicar la categoria del producte. Orcamento__c Master-Detail (Orcamento__c) Pressupost de la línia. SERV_External_Id_SO__c Text, unique, external id ID extern per vincular el registre entre Salesforce i SO Produto__c LookUp (Produto__c) Producte de la línia. [confidencial] Text (Long) [confidencial] [confidencial] Text (Long) [confidencial] [confidencial] Text [confidencial] [confidencial] Text [confidencial] [confidencial] Text [confidencial] 137
[confidencial] Fórmula (Text) [confidencial] [confidencial] Fórmula (Currency) [confidencial] [confidencial] Fórmula (Currency) [confidencial] [confidencial] Fórmula (Currency) [confidencial] [confidencial] Fórmula (Currency) [confidencial] [confidencial] Fórmula (Currency) [confidencial] [confidencial] Number [confidencial] [confidencial] Number [confidencial] [confidencial] Percentage [confidencial] [confidencial] Currency [confidencial] [confidencial] Percentage [confidencial] Atributs Interns Id Id Id intern de cada servei dins Salesforce Taula 8.12: Especificació dels atributs de l’objecte Línia de Pressupost Produto__c (Producte) API SF Tipus de Camp Descripció Atributs d’Interfase CreatedById LookUp (User) Id del usuari que ha creat el registre. CreatedDate Datetime Data de creació. LastModifiedById LookUp (User) Últim usuari en realitzar una modificació en el registre. Name Text Nom del producte. OwnerId LookUp (User,Group) Propietari del registre. SERV_Id_Produto_SO__c Text, unique, external id ID extern per vincular el registre entre Salesforce i SO 138
SERV_Descricao_Alentejo_ _c Text Descripció especial quan el producte és venut en la zona d’Alentejo. SERV_Descricao_Algarve_ _c Text Descripció especial quan el producte és venut en la zona d’Algarve. SERV_Descricao_Centro__ c Text Descripció especial quan el producte és venut en la zona del centre. SERV_Descricao_Norte__c Text Descripció especial quan el producte és venut en la zona Nord. SERV_Familia__c Picklist Categoria del producte. SERV_Tipo_de_Produto__c Picklist Tipus de producte. Atributs Interns Id Id Id intern de cada servei dins Salesforce Taula 8.13: Especificació dels atributs de l’objecte Producte Task (Tasca) API SF Tipus de Camp Descripció Atributs d’Interfase CreatedById LookUp (User) Id del usuari que ha creat el registre. CreatedDate Datetime Data de creació. LastModifiedById LookUp (User) Últim usuari en realitzar una modificació en el registre. Subject Text Nom de la tasca. OwnerId LookUp (User,Group) Propietari del registre. SERV_Atribuicao_Adicional_ _c LookUp(User) Camp per afegir un propietari adicional. SERV_Etapa_Pos_Contratac ao__c Picklist Etapa de post contractació de la tasca. Description Text (Long) Comentaris de la tasca. SERV_Data_de_Inicio__c Fórmula Data de creació. SERV_Data_de_Fecho__c Date Data en què es conclou la tasca. ActivityDate Date Data límit per a realitzar la tasca. WhatId LookUp (polimorphic) Registre associat a la tasca. Pot fer referència a qualsevol classe de registre 139
que permeti ser vinculat a una tasca. SERV_N_Processo_Ref_SO __c Text Número de referència del servei a Serviout. S’indica automàticament quan la tasca està relacionada a un servei. SERV_Cliente__c LookUp (Account) Client del servei. S’informa quan una tasca està relacionada amb un servei. SERV_Falecido__c LookUp (Account) Difunt del servei. S’informa quan una tasca està relacionada amb un servei. Atributs Interns Id Id Id intern de cada servei dins Salesforce RecordTypeId Id Id que determina el tipus de tasca. SERV_Minha_Tarefa__c Fórmula (Checkbox) Camp que indica, de forma dinàmica segons l'usuari que llegeix el camp, si la tasca és seva o no. SERV_Queue_Users_Ids__c Text Text que conté totes les ids dels usuaris dins de la cua establerta com a propietària de la tasca. Type Picklist Tipus de tasca. SERV_Tipo_de_Pedido__c Picklist Tipus de comanda per al document de defunció. S’usa per a les tasques de documentació de defunció. Taula 8.14: Especificació dels atributs de l’objecte Tasca 140
8.6. Interfícies d’Usuari Com en l’apartat 7.6 d’interfícies de Contractació, per al disseny de les interfícies d’usuari, es va usar l’eina de Salesforce Lightning Page Builder i vam estructurar les interfícies basant-nos en les ja existents a Serviout. Pels objectes en els quals no existien en el sistema antic, es van concertar reunions amb el client per a decidir la millor distribució. 8.6.1. Interfícies dels Pressuposts, Línies de Pressupost i Productes Aquest nou objecte estarà relacionat amb els serveis i per accedir als registres, afegirem una nova pestanya en la interfície de servei per a mostrar els pressuposts de cada servei. Figura 8.6: Interfície del serveis amb la llista relacionada dels Pressuposts. Dins el pressupost tindrem una primera interfície amb els atributs del pressupost. Aquests atributs representaran la capçalera del pressupost i mostren informació com l’estat del pressupost, el servei del pressupost, els valors totals, camps d’observacions, etc. Com encara no es treballarà amb els pressuposts de la banda de Salesforce, no trobarem cap botó de funció en les capçaleres. En aquest cas, el pressupost no té diferents tipus de registre, llavors sols tindrem un disseny d’interfície per a tot el sistema. A sota de la pàgina de detalls, trobarem una related list amb totes les línies del pressupost. Les línies estaran ordenades segons la secció de productes a la qual fan referència. Aquesta related list està configurada per a mostrar els camps més rellevants de les línies, com són la secció del producte, el número de referència del producte, el nom del producte, la quantitat de producte, el preu unitari, el percentatge de descompte, el subtotal i l’IVA. Finalment, trobarem un component per a pujar i visualitzar arxius del pressupost, on podrem veure la impressió en PDF del pressupost que rebrem de Serviout. 141
Figura 8.7: Interfície dels Pressuposts. Dins de cada línia de pressupost, trobarem encara més camps de detall com són observacions, el nom del pagador, i altres camps fórmula auxiliars per càlculs del pressupost. 142
Figura 8.8: Interfície de les Línies de Pressupost. Finalment, tindrem la interfície dels productes, amb el nom del producte, el seu número de referència de Serviout i SAP, el tipus de producte i uns camps de descripció per a les diferents zones de Portugal. 143
Figura 8.9: Interfície dels Productes. 8.6.2. Interfície de Tasques Per les tasques trobarem una interfície senzilla, poc carregada de camps. Les tasques en serviran majoritàriament per a recordatoris i per a desencadenar accions d’usuari com pujar arxius, enviar recordatoris a clients, etc. Així doncs, les tasques no hauran de guardar informació relativa a altres registres i podrem usar una interfase pareguda a l'estàndard de Salesforce. Com normalment les tasques aniran relacionades a un servei, en la capçalera de les tasques trobarem el número de procés del servei a Serviout, el registre vinculat en la tasca, el nom del client i el nom del difunt. En la capçalera també trobarem, normalment, 2 botons, el d’alterar l’estatus de la tasca i un altre per a realitzar l’acció de la tasca. Ambdós botons invocaran un screenflow . Dins dels detalls de la tasca, trobarem molts camps estàndard i alguns personalitzats. Finalment, igual que en els casos i serveis, tindrem el component per a crear notes. 144