Metodología de Procesos

Metodologa de definicin de procesos
Proyecto Fin de Carrera
Presentado por: Director:
Sylvia Daz-Montenegro Quesnel Juan Zamorano Flores Departamento de Arquitectura y Tecnologa de Sistemas Informticos
1 de Junio de 2009
FACULTAD DE INFORMATICA
UNIVERSIDAD POLITCNICA DE MADRID
Agradecimientos
A mi marido, Juan Alonso-Villalobos, quien es el que ms me ha animado para hacer este esfuerzo, y el que ha suplido en casa el tiempo que le he dedicado, A Juan Zamorano, porque sin su gentileza, paciencia y nimo, no lo habra llevado a cabo, A mis hijos Guillermo, Ins, Blanca y Roco, por tantos fines de semana de trabajo en que los he abandonado, A la Facultad, por haberme esperado todo este tiempo.
Indice General
ndice de Figuras ndice de Tablas CAPTULO 1. 1.1. 1.2. INTRODUCCIN, OBJETIVOS Y ESTRUCTURA. 6 6 7 9 11 13 13 13 14 15 16 18 20 20 22 22 24 25 25 25 28 29 30 30 31 32 33 33 34 35 35 36 36 37 37 37 38 39 41 42
Objetivo del proyecto. Estructura. LA SITUACIN ACTUAL DE LA TECNOLOGA CORPORATIVA.
CAPTULO 2.
2.1. La utilizacin de los sistemas de informacin corporativos en la actualidad. 2.1.1. La universalidad de la informacin soportada por sistemas. 2.1.2. La gestin del riesgo operativo. 2.1.3. La especializacin. 2.2. 2.3. 2.4. 2.5. El impacto en las aplicaciones y sistemas corporativos. El impacto en los procesos de desarrollos de aplicaciones. Modelizacin de datos. Modelizacin de procesos. EL PUNTO DE PARTIDA: LOS DFDS.
CAPTULO 3. 3.1. 3.2. 3.3.
Introduccin. Flujo de trabajo vs. mquina de estados. Premisas.
3.4. La modelizacin con DFDs. 3.4.1. Breve recordatorio de la tcnica de DFD 3.4.2. Diagrama de contexto. 3.4.3. Diagrama de nivel 1 3.5. Las carencias de la tcnica de DFD 3.5.1. El flujo de control 3.5.2. La funcionalidad originada por los datos. 3.6. Flujos de datos y flujos de control. DEFINICIN DE COMPONENTES.
CAPTULO 4.
4.1. Elementos de la metodologa. 4.1.1. Expediente. 4.1.2. Perfiles. 4.1.3. Las etapas. 4.1.4. El mapa de procesos (las etapas). 4.1.5. Trabajos. 4.1.6. Reglas. 4.1.7. Transacciones. 4.2. Tipos de procesos. 4.2.1. Procesos sncronos. 4.2.2. Procesos colaborativos. 4.2.3. Procesos en tiempo real (on-line). 4.2.4. Procesos por lotes (batch).
CAPTULO 5. 5.1. 5.2. 5.3. 5.4.
METODOLOGA DE ANLISIS DE PROCESOS.
44 44 45 46 48 49 49 49 49 50 50 51 51 54 54 55 57 57 58 58 59 59 60 61 61 62 64 64 65 65 66 67 67 69 71 71 71 72 72 73 73 73 73 77 78 78 79 79
El proceso secuencial. Identificacin de resultados imprevistos. Gestin de plazos. Gestin de incidencias.
5.5. Agrupacin de etapas 5.5.1. El inicio del proceso 5.5.2. La entrada de informacin: recepcin de informacin 5.5.3. El final del proceso 5.5.4. Las bandejas de entrada 5.5.5. Los procesos masivos 5.5.6. Los procesos colaborativos. 5.6. El mapa de procesos.
5.7. Identificacin de reglas. 5.7.1. Reglas de transicin. 5.7.2. Reglas de disparo. 5.8. Identificacin de acciones. 5.8.1. Acciones permanentes. 5.8.2. Acciones de transicin arbitraria. 5.8.3. Acciones en las etapas automticas. 5.9. Definicin de perfiles. 5.9.1. Perfiles segn el proceso. 5.9.2. Perfiles segn los datos. 5.10. 5.11. 5.12. Evaluacin sistemtica. Modificacin de los datos del expediente. Verificacin del diseo. EL ANLISIS APLICADO A UN CASO PARTICULAR.
CAPTULO 6. 6.1.
La contratacin del seguro de coche: el proceso real.
6.2. La modelizacin DFD. 6.2.1. Diagrama de contexto 6.2.2. Diagrama de nivel 1 6.3. 6.4. 6.5. El proceso secuencial Los errores. La gestin de plazos.
6.6. La gestin de incidencias. 6.6.1. Denegaciones y respuestas negativas. 6.6.2. Problemas en el intercambio de informacin (documentacin). 6.7. La agrupacin de etapas. 6.7.1. El inicio del proceso. 6.7.2. La entrada de informacin: recepcin de informacin. 6.7.3. El final del proceso. 6.7.4. Las bandejas de entrada. 6.7.5. Los procesos masivos 6.7.6. Los procesos colaborativos 6.8. El mapa de procesos.
6.9. Identificacin de reglas de transicin en el caso prctico. 6.9.1. Las entradas 6.9.2. Errores de sistema
6.9.3. 6.9.4. 6.9.5. 6.9.6. 6.9.7. 6.9.8. 6.9.9. 6.9.10. 6.10. 6.11.
Incidencias Verificaciones Llamadas de rescate Documentacin pendiente Documentacin incorrecta Altas/Bajas en el sistema corporativo Envo de contratos a clientes Resumen de reglas de transicin
79 79 80 80 80 81 81 82 82 83 84 84 84 85 85 86 86 87 88 89 91 92 93 93 94 95 96 96 96 97 98 101
Identificacin de reglas de disparo en el caso prctico. Identificacin de acciones.
6.12. Definicin de perfiles. 6.12.1. Segn los datos 6.12.2. Segn el proceso 6.13. Modificacin de los datos del expediente. 6.13.1. Modificacin de las caractersticas del seguro. 6.13.2. Modificacin de las caractersticas de la persona. 6.13.3. Modificacin de las caractersticas del coche. CAPTULO 7. 7.1. 7.2. 7.3. LA ARQUITECTURA TCNICA.
El gestor de reglas de negocio. El disparo de eventos. Arquitectura de sistemas. CONCLUSIONES.
CAPTULO 8. 8.1.
Implantacin de la metodologa propuesta.
8.2. Ventajas de la utilizacin de la metodologa, un caso real. 8.2.1. Beneficios obtenidos en el mbito interno. 8.2.2. Beneficios obtenidos en el mbito externo. 8.3. Puntos crticos de la utilizacin de la metodologa. 8.3.1. El enfoque secuencial. 8.3.2. El rechazo a la imperfeccin. 8.4. Evolucin. GLOSARIO DE TRMINOS. BIBLIOGRAFA.
CAPTULO 9. CAPTULO 10.
ndice de Figuras
Figura 1 - DFD genrico de contexto ........................................................................ 28 Figura 2 - DFD genrico de nivel 1 ........................................................................... 29 Figura 3 - Mapa completo de procesos .................................................................... 53 Figura 4 - DFD de contexto ........................................................................................ 65 Figura 5 - DFD de nivel 1 ............................................................................................ 66 Figura 6 - Proceso secuencial .................................................................................... 67 Figura 7 - Identificacin de errores ............................................................................ 68 Figura 8 - Identificacin de incidencias..................................................................... 68 Figura 9 Gestin de plazos ..................................................................................... 70 Figura 10 Gestin de plazos y expedientes vencidos (bajas) ........................... 70 Figura 11 Gestin de incidencias ........................................................................... 72 Figura 12 - Identificacin de procesos ...................................................................... 74 Figura 13 - Clasificacin de procesos masivos ....................................................... 75 Figura 14 - Identificacin de capacidades ................................................................ 77 Figura 15 - Mapa completo de procesos .................................................................. 78
ndice de Tablas
Tabla 1 - Elementos de DFDs .................................................................................... 26 Tabla 2 - Formalizacin de reglas de transicin ..................................................... 55 Tabla 3 - Formalizacin de reglas de disparo ......................................................... 57 Tabla 4 - Formalizacin de Acciones ........................................................................ 59 Tabla 5 - Asignacin de acciones y perfiles a bandejas de entrada.................... 60 Tabla 6 - Asignacin genrica de perfiles ................................................................ 61 Tabla 7 Caso prctico: reglas de transicin ......................................................... 82 Tabla 8 Caso prctico: reglas de disparo ............................................................. 83 Tabla 9 Caso prctico: Resumen de acciones..................................................... 83 Tabla 10 Caso prctico: Asignacin de perfiles ................................................... 84 Tabla 11 Caso prctico: Asignacin de acciones a bandejas de entrada ....... 85
Captulo 1.
Introduccin, objetivos y estructura.
Para la comprensin tanto del concepto como del objetivo del presente Proyecto de Fin de Carrera, me temo que es fundamental saber el momento cronolgico en el que lo desarrolla su autora. Hace no menos de 20 aos que termin la ltima asignatura del Plan del 77. Debido al xito profesional que pareca esperar a todo aqul que ejerciera la Informtica al final de los aos 80, y de la prisa que parece apremiar a las personas alrededor de los 20 aos, nunca me detuve suficientemente como para desarrollar un Proyecto digno de ese nombre y con el que me pareciera aportar algo ms que el trmite de obtener un ttulo acadmico. Es tambin fundamental saber el tipo de profesional de Informtica que soy y que se parece mucho a la estudiante que era: en los aos de carrera, yo era de esos raros estudiantes que les apasiona el Algebra y se les hace difcil la Electrnica. En general, me encantaron todas las asignaturas que tenan que ver con desarrollar modelos conceptuales que me permitieran crear un mtodo de pensamiento, como la lgica formal o la programacin estructurada, y me llamaron mucho menos la atencin aquellas asignaturas que se ocupaban ms de los aspectos ms tcnicos de la carrera. Las asignaturas de Lgica, Programacin y Bases de Datos, con el aprendizaje del modelo de Entidad-Relacin, han contaminado para siempre mi manera de analizar los problemas, de discutir sobre ellos y de razonar, de modo que podra decirse que la parte que ms disfrut de la carrera fue la que tuvo que ver con su parte ms filosfica y desde luego la que ms contribuy a mi formacin, en la acepcin ms ambiciosa del trmino.
Mis 20 aos de vida profesional se han desarrollado en el mbito de la Informtica Corporativa, en particular en el sector financiero. En el ao 2004 decid dejar de hacer Informtica desde dentro de las organizaciones para vender desde fuera los sistemas que era capaz de disear, en una estructura de pago por uso. Una de las numerosas razones que me llevaron a tomar esta decisin fue la frustracin producida por la dificultad de desarrollar sistemas de forma interna, entre otras cosas porque en general el diseo de un sistema de informacin no se considera un ejercicio tcnico que requiere del mismo rigor, disciplina y necesidad de conocimientos que el de cualquier otro sistema, sea o no de informacin. Es verdad que lo que se conoce de un puente del famoso arquitecto Calatrava es la lnea, la ciudad y el ro que salva, pero lo importante del puente es que sirva para lo que est diseado, que es aportar un modo eficiente de cruzar un curso de agua. La belleza del diseo, adems de accesoria, debiera idealmente ser el reflejo de la eficiencia operativa del objeto. El hecho de que los sistemas no maten a nadie si se caen, al contrario que los puentes, puede llevar a que no sea necesaria la colegiacin de sus profesionales y el sellado de sus proyectos, pero no debera dar lugar a que esos mismos profesionales que los disean no tengan un criterio tcnico y que este criterio tcnico pueda formarse como cualquier cuerpo de conocimiento tcnico, es decir de forma sistemtica, medible y contrastable. Mi experiencia comercial, desde el 2004, me ha demostrado que esta falta de consideracin del diseo de sistemas como disciplina tcnica da lugar a dos aspectos que se retroalimentan entre s: por una parte, la insatisfaccin general de las compaas con los sistemas que desarrollan internamente; por otra, la inseguridad de los profesionales que se dedican al desarrollo, de forma que pueden llegar a abdicar del aspecto tcnico de su trabajo o, peor an, a despreciarlo, tomando decisiones guiadas mucho ms por el miedo al fracaso de los proyectos que por consideraciones tcnicas. La mayor parte de mi carrera se ha desarrollado en entidades financieras muy avanzadas en la distribucin de productos por canales directos, telfono e Internet. A lo largo de los aos he podido comprobar que mucha parte del diseo es comn y que los problemas que se ponen de manifiesto en el diseo, la implantacin y la vida til de estos sistemas provienen de los mismos defectos de enfoque. Esta experiencia, y la diferencia frente al mtodo ms frecuente de diseo, es la que ha dado lugar a la empresa que mont en 2004 y que, precisamente, ofrece servicios
destinados a suplir las carencias que de modo general tienen los sistemas internos de nuestros potenciales clientes, entidades financieras, seguros y otras grandes compaas. Los procesos que fabricamos para nuestros clientes estn basados en esta experiencia y se disean siguiendo una serie de tcnicas, prcticas y conocimientos, no muy novedosos en realidad, pero que ordenados en una metodologa aportan una manera sistemtica de enfrentarse a los problemas que se quieren resolver, asegurando una cierta industrializacin del proceso de modelizacin. Despus de 20 aos, pues, me parece que esta metodologa de diseo es la mejor expresin de lo que s de mi carrera y lo que ms me gustara formalizar tanto para su utilizacin como para su mejora por otros profesionales, de modo que este Proyecto de Fin de Carrera es, en realidad, una oportunidad de compartir mi experiencia, que es seguramente el mejor uso que se le puede dar.
1.1.
Objetivo del proyecto.
El objetivo de este proyecto es proporcionar una metodologa de diseo como un conjunto de tcnicas, recomendaciones y verificaciones, que permitan sistematizar la modelizacin de realizarlo. Las tcnicas que han servido como inspiracin para esta metodologa son las que rodean la modelizacin de datos mediante el mtodo de Entidad/Relacin. La utilizacin de estas tcnicas dentro de un equipo de trabajo proporciona una doble ayuda. Por una parte, la utilizacin de modelos de representacin de entidades y relaciones permiten ordenar la comunicacin alrededor del modelo en s, y no de la realidad que se modelizar. Es decir que mediante el uso de conceptos especficos como entidad, relaciones, cardinalidad o atributos etc., se facilitan dentro del equipo de trabajo aspectos tan importantes como: La creacin rpida de un vocabulario comn, La elaboracin comn alrededor de unas tcnicas conocidas y procesos con los requisitos que plantea el estado actual de la tecnologa y que supongan una ayuda real para los profesionales encargados de
La capacidad de verificacin o evaluacin objetiva del modelo, independientes de la realidad que se modeliza.
Por otra parte, el modelo de Entidad/Relacin se completa con toda una serie de consideraciones tcnicas (formas normales, gestin de redundancias etc.) que permiten organizar con ms facilidad los datos y que permiten evaluar a priori la eficiencia o el rendimiento de un diseo de datos segn la herramienta tcnica sobre la que se implemente. Este tipo de ayuda real a la modelizacin e implementacin no est formalizada, o al menos no la he encontrado, alrededor de los procesos. La tcnica ms conocida es la de los DFD, Data Flow Diagram, descrita por Michael Yourdon y Larry Constantine en los aos 80, pero que no he visto utilizar frecuentemente. En los primeros aos 90 se empez a ver todo un conjunto de sistemas de modelizacin y gestin de proyectos conocido como CASE (Computer Aided Software Engineering) y la propia IBM dedic mucho esfuerzo a la comercializacin de su AD/Cycle (Applications Development Cycle), sin embargo no forman parte del conjunto de herramientas que se ven habitualmente en un departamento de informtica corporativo. En esos aos surgi tambin con cada vez ms empuje la necesidad de adaptarse a la distribucin multicanal (Internet, telfono), junto con la aparicin de los grandes paquetes de software como solucin (SAP, Siebel, FileNet etc.) lo que ha modificado la funcin de las reas de desarrollo que cada vez menos disean y cada vez ms adaptan sistemas que les vienen dados. Esta metodologa sostiene que, precisamente porque se compran paquetes de software que resuelven aspectos enteros de la problemtica de una empresa, es an ms necesario que exista una visin que integre las soluciones tcnicas con los problemas de negocio a los que se est pretendiendo dar solucin y que permita articular procesos adecuados que utilicen todas las herramientas disponibles en la organizacin o fuera de ella. La metodologa que se presenta persigue precisamente ese objetivo: el proporcionar un conjunto de herramientas para los profesionales encargados de los diseos de procesos que les permita ordenar las necesidades que tienen que cubrir, organizar ese conocimiento en un formato comn y sistemtico y permitir su comunicacin, su evaluacin y la verificacin de la bondad del diseo.
10
1.2.
Estructura.
Esta memoria se ha estructurado con un doble criterio. Por una parte, inevitable, la descripcin de la metodologa de anlisis en s, con los elementos que la componen, las actividades que se recomiendan y un caso prctico con el que recorrer el mismo camino que se ha descrito. Por otra parte, sin embargo, se ha dado mucho peso a la explicacin de por qu este tipo de problemticas son de creciente importancia en el mundo en el que vivimos. en el primer captulo, la situacin actual de la Tecnologa en las corporaciones, se describe la importancia de la definicin de procesos y qu ha cambiado en este aspecto a lo largo de estos 20 aos a lo largo de los cuales hemos asistido a una dramtica evolucin en los sistemas de informacin y su funcionalidad. La importancia de entender el impacto real de los procesos en los sistemas de informacin actuales es crucial a la hora de dedicarle la atencin debida a su modelizacin y diseo. En este captulo se mencionar, aunque solamente de forma ligera, la arquitectura de sistemas como esa estructura lgica que sirve para articular los diversos elementos de un sistema, incluidos los procesos, y cuya solidez y modelo es garanta de la flexibilidad, robustez y longevidad del sistema que soporta. En el segundo captulo, el punto de partida: los DFDs, se describe el punto de partida de esta metodologa a partir de la modelizacin de procesos segn las tcnicas de diseo estructurado de Yourdon/Constantine. Para ello, se recuerdan los grandes aspectos de estas tcnicas, en una de sus mltiples versiones, y se identifican las carencias que se intentan cubrir, de acuerdo con las necesidades identificadas en el captulo anterior. En el tercer captulo, definicin de componentes, se describen los conceptos que se utilizan en la metodologa. Por una parte, se definen tanto los tipos de procesos que se pueden encontrar de forma ms comn en los sistemas de informtica corporativa o de gestin. Cada uno de estos tipos de procesos tienen sus propios requisitos y servidumbres, y se deben utilizar en cada caso segn las necesidades que deben cubrir. Por otra parte, se describen los elementos que se utilizan para el control del sistema.
11
En el cuarto captulo, se describe la metodologa propuesta de diseo, definido como etapas sucesivas que conducen del proceso, descrito en el mundo real, al modelo que soporte ese proceso, pero distinguiendo los componentes ms estables de las reglas arbitrarias, para utilizar en cada caso las herramientas que mejor soporten esas diferentes caractersticas.
En el quinto captulo, anlisis aplicado a un caso particular, se recorre el mismo camino que se describe en el captulo anterior, pero con un caso moderadamente complicado de la vida real de todo el mundo: la contratacin de un seguro de coche por Internet.
El siguiente captulo, la arquitectura tcnica, describe los elementos o herramientas que pueden facilitar la implantacin de estos procesos en los sistemas reales. En este caso estar la herramienta de gestin de las reglas de negocio, el disparo de eventos, la presentacin de los contenidos de informacin y la monitorizacin del proceso son los aspectos ms importantes de la puesta en marcha de un proceso modelizado y diseado de acuerdo con esta metodologa.
Finalmente, el trabajo concluye con algunas consideraciones sobre las experiencias de puesta en marcha de esta metodologa, los lmites que se han observado o se intuyen y lo que la evolucin de la tecnologa puede aportar a este tipo de ejercicios.
12
Captulo 2.
La situacin actual de la tecnologa corporativa.
2.1.
La utilizacin de los sistemas de informacin corporativos
en la actualidad.
Se pueden destacar tres tendencias que marcan las necesidades actuales de los sistemas de informacin corporativos.
2.1.1.
La universalidad de la informacin soportada por sistemas.
El desarrollo de sistemas de apoyo a la gestin corporativa se ha dado en llamar tradicionalmente la informtica de gestin, porque, tambin tradicionalmente, estos sistemas solan dar apoyo a las funciones de gestin, en particular las ms financieras y administrativas. Actualmente, los sistemas de informacin dan soporte a todas las funciones de negocio. Prcticamente todo lo que se hace en una compaa, sea cual sea su industria, sean cuales sean sus clientes, se apoya y tiene reflejo en sistemas de informacin. Prcticamente todas las gestiones realizadas se recogen en un sistema y sirven para disparar otras acciones. El grueso de la informacin de las empresas ya no est en los archivos fsicos; est en los archivos digitales hasta que, quizs por necesidad de archivo legal o para su verificacin, se tiene que
13
emitir el documento en papel como soporte ltimo de compromisos o certificaciones a largo plazo como los contratos o cualquier documento pblico. Globalmente, se lleva aos hablando de la sustitucin del papel por realidades puramente digitales. En gran medida, con la aparicin de los sistemas apoyados en voz y por Internet, se ha sustituido el valor probatorio del documento fsico firmado por firmas digitales como la grabacin de voz en sistemas con valor legal y la firma de transacciones mediante cdigos. La contratacin es ms complicada, porque hay que unir en un mismo elemento de informacin el contenido del documento que se firma, con la firma y la hora de la firma. Esto que ya se ha conseguido en los actuales sistemas de firma electrnica, sigue siendo incmodo para la persona normal, que, por lo tanto, sigue utilizando mayoritariamente el papel como soporte universal. En cualquier caso, las organizaciones trabajan como si la informacin en vigor fuera la que est en los sistemas y tiende a reducirse la informacin homloga fuera de ellos. Tanto es as que, en nuestro pas, Ley 56/2007, de 28/12/2007 de Medidas de Impulso de la Sociedad de la Informacin, recoge la obligatoriedad de poder utilizar la firma electrnica como nico y definitivo medio de contratacin de servicios esenciales para la vida diaria: entidades financieras, seguros, telecomunicaciones y servicios generales (luz, agua, electricidad, gas etc.).
2.1.2.
La gestin del riesgo operativo.
La economa global busca cada vez ms mecanismos que permitan evitar, o al menos gestionar adecuadamente, los riesgos, para garantizar en la medida de lo posible la estabilidad del sistema y la solvencia de los organismos que lo componen. En particular, el riesgo operativo ha sido objeto de mucha atencin en las nuevas regulaciones, por ejemplo, del sistema financiero (Basilea y la Ley de Solvencia del mercado de Seguros), de forma que muchos de los esfuerzos de los reguladores han ido encaminados a explicitar, dentro de la manera de trabajar de las organizaciones, y por tanto dentro de los sistemas, los criterios de actuacin y la separacin de funciones. De este modo, las tareas estn predeterminadas, as como los perfiles y permisos de los usuarios, lo que permite garantizar la segregacin efectiva de las funciones y evitar los desequilibrios entre ellas.
14
2.1.3.
La especializacin.
Finalmente, adelantos tecnolgicos como las centralitas inteligentes, conocidas por sus siglas ACD (Automatic Call Dispatcher) o el abaratamiento de las comunicaciones han hecho posible la centralizacin de determinadas tareas dentro de centros especializados. Es en el principio de los aos 90 cuando se empiezan a ver estructuras de Centros de llamadas, conocidos como Call Center. Estos Call Center son grandes organizaciones de cientos de operadores telefnicos que atienden las llamadas, normalmente del servicio de atencin de clientes. Esta es la explicacin de los nmeros 900, 901 y 902 que desde entonces han inundado la sociedad. Estas plataformas basan su xito en el empleo de personas no muy formadas que, mediante un sistema suficientemente organizado, pueden realizar un trabajo sencillo y repetitivo. Desde el principio de este siglo, muchos de estos Call Center se han desplazado incluso a reas geogrficas ms desfavorecidas, en Amrica Latina para el caso de Espaa. Tambin con el abaratamiento de las comunicaciones, las tareas administrativas se han podido reestructurar, dejando la capilaridad geogrfica sobre todo a la funcin comercial y centralizando este tipo de trabajo de trastienda, back-office en ingls, agrupado tambin en centros masivos con personas de formacin puramente administrativa. El desplazamiento de estas funciones administrativas centralizadas a reas geogrficas lejanas, soportado por capacidad en los sistemas y en las telecomunicaciones, es un movimiento global que se conoce como off-shoring y que persigue sobre todo la reduccin de costes, pero tambin el acceso a talento humano mejor preparado a un coste menor y la capacidad de crecer sin crear estructuras de soporte.
Estos tres factores han modificado profundamente la relacin de los usuarios humanos con los sistemas y la manera en la cual se disea actualmente el trabajo en las grandes organizaciones. Por una parte, la fragmentacin del trabajo entre reas tan dispares y a menudo tan separadas da lugar a una carencia de visin global, que solamente se reconstituye en la parte directiva de la organizacin y en los sistemas que soportan la actividad. De hecho, las personas que conocen o disean y desarrollan todo el sistema son de los pocos que realmente conocen lo que ocurre en l, y por tanto en la organizacin. Este factor, combinado con la externalizacin del
15
mantenimiento de aplicaciones y de la programacin, produce en definitiva que el conocimiento de lo que ocurre en la compaa est solamente en la mente de aquellos que conocen el sistema, lo que ofrece y las tareas que hace de forma automtica, an ms que en la del que lo dise. Como el ser humano ya no es el responsable del proceso de inicio a fin, es el sistema el que asegura de la coordinacin de las tareas y su control para obtener el resultado deseado. El control sobre el proceso tambin se ha desvirtuado en alguna medida puesto que ya no depende completamente de la actitud y conocimientos de las personas que realizan las tareas, sino de la articulacin de tareas automticas, semiautomticas y manuales, que ocurren en diferentes espacios de la organizacin. Es decir, el control sobre el proceso depende tambin de la manera en la cual estn diseados esos sistemas. Es posible ver, de hecho, una especie de sedimentacin de los sistemas que hace que cada vez el conocimiento de las aplicaciones es ms externo y superficial, con lo que se puede llegar a ver una organizacin que no puede cambiar de sistema porque no sabe muy bien qu hace en realidad. De hecho, este extremo dramtico es ms frecuente de lo que cabra suponer, aunque los grandes cambios debidos a la transicin al euro y las revisiones del ao 2.000 lo han suavizado en alguna medida.
2.2.
El impacto en las aplicaciones y sistemas corporativos.
La funcionalidad en las aplicaciones corporativas refleja con exactitud la evolucin en el uso de los sistemas. En los aos 80, el tpico terminal corporativo era un emulador con una coleccin de transacciones organizadas en forma de men. Esta funcionalidad es sencilla porque organiza de una manera muy simple las acciones posibles y las pone a disposicin de usuarios que tienen o no acceso a ellas. Sin embargo, es muy poderosa en el sentido de que cada usuario puede hacer lo que estime oportuno, dentro de sus derechos de acceso. El sistema no sabe del orden en el cual se suceden las tareas, para lo que depende del buen criterio del usuario. Era la organizacin en la cual se presentaban, por ejemplo, todas las utilidades de una oficina bancaria. Actualmente, esta funcionalidad, as organizada, sigue existiendo, pero lo que se ha reducido considerablemente es la proporcin de usuarios con acceso a ella. En la mayora de los casos, empujado incluso desde los poderes pblicos, el sistema se ha
16
ampliado en dos direcciones: con capacidades autoservicio para el cliente final, que opera fuera de la estructura de la empresa, y con utilidades en forma de flujo de tareas, para atender a las necesidades de nuevas reas operativas como los Call Center o los Back-Office centralizados. Tambin de forma mayoritaria, se ha incrementado la necesidad de intercambio de informacin con el exterior, bien por la aparicin de bases de datos sectoriales o bien por la utilizacin de terceros especialistas en algn punto del proceso. Esta tendencia da lugar a lo que se conocen como procesos colaborativos, en los que el resultado del proceso incorpora capacidades externas a la compaa, siguiendo el mismo modelo que se ha podido observar en la industria manufacturera, donde nadie espera ya ver que todas las piezas de un coche se fabriquen en el mismo sitio. Este efecto de proceso colaborativo, utilizando informacin exterior a la empresa o capacidades tcnicas especialistas, tambin exteriores, se ve potenciado con la reciente aparicin de fenmenos como el cloud computing, computacin en nube, que consiste en la utilizacin de recursos hardware en Internet, proporcionados por una compaa con intensas economas de escala en la gestin de sistemas, como Google), el mash-up (mezcla de capacidades de agentes heterogneos, externos y/o internos, como fuente de informacin o funcionalidad) o los fenmenos Web 2.0, en los que los receptores finales de los servicios son cada vez ms activos en la configuracin del servicio que reciben o en la interaccin con las organizaciones presentes en el mercado Internet. El cambio fundamental, sin embargo, no est en la capacidad de autoservicio, ni siquiera en la progresiva apertura de los sistemas de dentro afuera de las organizaciones. El cambio fundamental consiste en que el actor principal, el motor del proceso, era antes el ser humano que escoga la tarea de su men de transacciones en cada momento. Actualmente, es la aplicacin la que orquesta el proceso real de negocio de las compaas. Es decir, que el diseo del sistema, en trminos de proceso, es el verdadero vector director de la vida corporativa y va a impactar de forma definitiva en la capacidad de la compaa para poder, o no poder llevar a cabo decisiones de negocio totalmente independientes de la Tecnologa, y a qu precio, pero en las que, sin embargo, el sistema va a tener un peso decisivo. El impacto de esta situacin en las compaas depende de su grado de dependencia de los sistemas. En el caso, por ejemplo, de las fbricas de productos de consumo, o
17
de coches, o de construccin incluso, la dependencia proviene de que son compaas que operan en mercados muy maduros, con mrgenes muy estrechos, y que por tanto requieren de los sistemas para poder optimizar los costes y en definitiva sobrevivir, tal como estamos viendo estos das en los anlisis de la quiebra de General Motors. En el caso de los servicios basados en informacin, como las entidades financieras y los seguros, se trata de que todo el producto, su fabricacin, sus caractersticas, su distribucin, su precio, estn en los sistemas y no estn en ningn otro sitio, puesto que hasta los activos financieros se han desmaterializado y son ahora activos de informacin y solamente eso.
2.3.
El impacto en los procesos de desarrollos de aplicaciones.
Dentro de muchas corporaciones, como apoyo a la labor profesional de los especialistas en Tecnologas de la Informacin, se establecen marcos de trabajo que pretenden sistematizar el desarrollo. Algunos de estos marcos tericos han tomado incluso un aspecto extremadamente formalizado (CMM, TCMM, Itil) que persigue el objetivo de medir la capacidad de la organizacin de establecer un proceso controlado de desarrollo tecnolgico. Estos marcos tericos se basan en el control de la presencia de actividades dentro de un proyecto, y no vigilan en absoluto la calidad de diseo y adecuacin de los sistemas a su funcin, ni la satisfaccin de los usuarios, ni la participacin a los resultados de la empresa. Actualmente, los resultados ms positivos de la implantacin de estos marcos tericos se dan en actividades de diseo limitadas a programas como la unidad ms pequea de funcionalidad dentro de una aplicacin, de modo que no parece que estas disciplinas puedan servir realmente de apoyo a los profesionales encargados del diseo y desarrollo de sistemas complejos. Las metodologas de desarrollo consisten en la formalizacin de una serie de tcnicas y actividades que ayudan a sistematizar el proceso de anlisis y modelizacin y luego la puesta en marcha de la aplicacin para que sea estable y razonablemente eficiente. Este tipo de marco es mucho ms tcnico que el anterior, pero definitivamente de mayor utilidad en garantizar la correccin de las aplicaciones obtenidas del proceso. Las ms avanzadas de estas metodologas defienden el diseo, en paralelo, de los modelos de datos y los modelos de procesos.
18
Segn la teora aceptada de tericos como Yourdon, los modelos de datos, al reflejar el contexto en el que se sita el sistema, no dependen de la compaa para la que se est haciendo el diseo sino del contexto de esa compaa, es decir la industria para la cual se desarrolla. El modelo de procesos, sin embargo, es lo que define la diferencia de la compaa frente a sus competidores. Este modelo es el que describe el cmo la compaa hace las cosas, que es lo que la debe hacer reconocible para sus clientes, ms all del producto y de la publicidad. Esta difcil diferenciacin es lo que ha marcado casos de xito como el de Wal-Mart, en el sector de la distribucin en Estados Unidos, el de Direct Line, la primera compaa aseguradora directa del Reino Unido, o el de Bankinter, el banco minorista espaol, modelo de referencia internacional en el servicio por Internet a clientes. Se ha explicado que el impacto del diseo de los procesos en las organizaciones es enorme porque afecta tanto en su estructura de costes, en su capacidad de organizarse segn las tendencias actuales, como a sus ingresos por su capacidad de diferenciarse ante sus clientes. El impacto proviene tambin, y de forma igual de importante que las anteriores, de la flexibilidad ante el cambio de los procesos, porque todos los mercados cambian a una velocidad mucho ms alta de lo que a las propias organizaciones les gusta imaginar en cada momento. Los cambios de organizacin interna o de presentacin de los servicios a los clientes suelen ser respuestas a cambios insoslayables, por ejemplo regulatorios o de entorno competitivo, y afectan todos ellos a los procesos, de forma enteramente arbitraria. Por ejemplo, la decisin de que un sistema debe soportar o no Internet, por mucho que pueda tomarse en un momento dado despus de larga y madura reflexin, puede cambiarse al da siguiente. El diseo de los procesos debe asegurarse de que un cambio de estas caractersticas no comprometa, al menos, lo que ya est hecho o incluso en produccin. As pues el modelo de datos es el responsable de la solidez del sistema y de su adecuacin al sector de la empresa. Su aspecto conceptual dar lugar a la estabilidad del sistema ante los cambios de toda ndole y la implementacin tcnica ser responsable del consumo de recursos de la aplicacin, su rendimiento y la gestin de la complejidad. La bondad del modelo de procesos es la que permitir cuidar lo que se hace y cmo, es decir los costes, la orientacin a cliente, la capacidad de crecimiento, la calidad y la adaptabilidad del proceso de negocio. Nada menos que la capacidad competitiva de la empresa.
19
2.4.
Modelizacin de datos.
Actualmente, el diseo de los modelos de datos se apoya todava mayoritariamente en el modelo entidad-relacin. Esta tcnica es tal que una persona con experiencia puede ver con bastante claridad si un modelo de datos es estable o no, con cunta complejidad se deber gestionar en el momento de su definicin tcnica, qu datos debe tener como atributos en el modelo, e, incluso, el consumo de recursos que puede tener la aplicacin en produccin. En mucha medida, tambin, la modelizacin de datos de los sistemas ms extendidos (CRM, banca, seguros, etc.) ya est hecha. Basta conectarse a uno de estos servicios en Internet para tener toda la informacin que se necesita sobre lo que debe contener el modelo de datos, o al menos verificar que est todo lo necesario. Incluso, las grandes consultoras tienen elaborados desde mediados de los aos 90 modelos de datos por industria que se pueden comprar y que se adaptan a cada compaa. No existen grandes casos de xito de estas adaptaciones, pero es al menos un buen punto de partida para verificar la completud de un modelo. Estos modelos de industria facilitan tambin la entrada de nuevas compaas, en todos los entornos, con un punto de partida muy avanzado y sin curva de aprendizaje. En realidad, despus de la historia ya recorrida en las compaas con los desarrollos, con la aparicin de paquetes de software que se ocupan con bastante xito de subsistemas enteros y la visibilidad de los sistemas de los competidores en Internet, es cierto que muy pocos sistemas se comienzan ya por la modelizacin pura de los datos, porque hay cada vez ms informacin disponible. La modelizacin de datos se realiza ms en los mbitos no cubiertos por sistemas especialistas.
2.5.
Modelizacin de procesos.
Para el diseo de procesos, se pueden utilizar tcnicas menos conocidas como los DFD (Data Flow Diagrams) o Casos de Uso, pero no es frecuente encontrar en las compaas la disciplina en estos diseos o su presencia en las metodologas. Sin embargo, el mundo de los procesos, por las razones descritas ms arriba, se ha complicado drsticamente, por la aparicin de nuevos tipos de usuarios y por la aparicin de nuevos mtodos de trabajo. As, ahora se deben de tener en cuenta
20
aspectos tradicionales como la utilizacin de los mens de transacciones para los administradores del sistema, junto con aspectos como el autoservicio en canales directos como Internet, la posibilidad de invocar funciones del sistema desde sistemas externos y, cada vez ms, la de realizar funciones del sistema en otros sistemas externos. En resumen, en una economa cada vez ms colaborativa, los procesos deben tener la capacidad de coordinar tareas ejecutadas por personas que ya no controlan el proceso en su totalidad y la de proporcionar herramientas de gestin al pequeo equipo encargado de hacer el seguimiento global.
21
Captulo 3.
El punto de partida: los DFDs.
3.1.
Introduccin.
Tal como se describa en el apartado 2, actualmente es cada vez ms frecuente que la estructura de los procesos de negocio y su encadenamiento lgico de tareas no se encuentren en la organizacin real sino en la virtual que se encuentra dentro de los sistemas de informacin. Cuanto ms enfocada est una empresa a la optimizacin operativa, bien por atencin a los costes o bien por una mayor especializacin del equipo humano, mayor es el peso del sistema de informacin en la organizacin de la actividad de las personas que a l se conectan. El objetivo ltimo es que los sistemas ofrezcan bandejas de trabajo a los diferentes equipos de personas especializadas de forma que nadie se ocupe de secuenciar, priorizar o elegir tareas y que cada persona tenga, en su manera de conectarse al sistema, acceso a una serie de tareas simples en la cual se apilan los trabajos y se reduzca en lo posible las necesidades de coordinacin y gestin. Esta es la idea que subyace en la idea de la estructura plana, que apareci junto con la explosin de la utilizacin de los sistemas de informacin en las organizaciones, y que se basa en la disponibilidad universal de la informacin y en la carencia de estructura jerrquica, y por tanto de coordinacin, en el mundo fsico. Esta idea, tan seductora en cuanto a la impresin de florecimiento de una inteligencia humana universal, se soporta necesariamente, y esta es una consecuencia mucho menos conocida, en que la estructura, coordinacin y secuenciacin de las tareas estn organizadas de forma automtica.
22
Esta idea de las bandejas de entrada es la representacin virtual de las bandejas de entrada y salida de trabajo de los puestos administrativos, sin cualificacin especial, que se empezaron a dar en la segunda mitad del siglo XX en las grandes organizaciones de trabajo administrativo. El objetivo de reducir un proceso de negocio a tareas simples encadenadas es mltiple: Reducir la necesidad de especialistas con una capacidad global de gestin permite reducir la necesidad de capacitacin de los equipos humanos. Aumentar la flexibilidad ante variaciones en el volumen de trabajo, mediante la utilizacin de un equipo menos formado y con una menor necesidad de supervisin. Esto permite que el tiempo necesario para aumentar la capacidad real del proceso entero es el tiempo de reclutamiento y formacin del equipo humano que lo tiene que ejecutar, tiempo que se ve reducido en la medida en que se simplifica el mbito de la formacin necesaria. Mejorar la capacidad de control mediante la gestin automtica del proceso y de los perfiles de usuario y derechos de acceso. Con procesos as configurados, es fcil saber quin hizo qu, pero tambin evitar el error y organizar el proceso alrededor de una estrategia (de riesgos, de control operativo, de control de costes), que queda establecida en el propio sistema de informacin. Desde el inicio de los aos 90, al menos en el sector financiero, este enfoque de proceso ideal se ha intentado cubrir con diseos de flujo de trabajo (workflow). Al final de los 90, se ha visto aparecer toda una gama de productos diseados con este nombre y, ms adelante, con el de Business Process Management (BPM). Grandes nombres del sector tecnolgico como Oracle o IBM entre otros han publicado y vendido este tipo de productos, que se basan en la aproximacin a los procesos basados en informacin, llammoslos procesos digitales, de la misma forma que se disearan los procesos fsicos, basados en entidades fsicas, y en particular los procesos industriales. Este enfoque da lugar a una visin secuencial del proceso, tal como sera la construccin de un coche por ejemplo.
23
3.2.
Flujo de trabajo vs. mquina de estados.
Los flujos de trabajo (workflows) muestran un proceso como un encadenamiento secuencial de tareas, representable mediante un flujograma. Para comprender la necesidad y el alcance de la metodologa de diseo que se propone frente a los instrumentos actuales, es necesario comprender la diferencia entre los procesos secuenciales y los que no lo son. La construccin de un coche es un proceso secuencial, tanto de construccin como de desmontaje, si fuera el caso, porque la propia configuracin fsica del elemento as lo exige. La nica excepcin es el abandono, que siempre es posible, en el cual todo el producto sale del proceso. En el mundo fsico, tambin existen procesos que no son secuenciales, como puede ser el del diagnstico sanitario, por ejemplo, en donde las tareas secuenciadas son tramos muy cortos (anlisis de sangre + lectura, por ejemplo), no atienden ms que secundariamente a la historia anterior (una enfermedad anterior puede ayudar a diagnosticar pero nunca ms que los sntomas actuales) y en cualquier momento puede ocurrir cualquier cosa que requiera de un diagnstico que es esencialmente imprevisible a priori, como un accidente. En este caso, la nica secuencia previsible es la de los protocolos de los pacientes sanos, que establece intervenciones pautadas que se producirn salvo contraorden. Este es el caso de la de la vacunacin por ejemplo. La idea de proceso como de una secuencia ordenada de tareas es tan fcil y tan intuitiva como la programacin tradicional. Es una tcnica inmediata, que cualquier principiante utiliza y comprende, pero que no se considera adecuada en el momento en que se profesionaliza la programacin. La idea de proceso como mquina de estados es otra tecnologa, como la programacin estructurada o la orientacin a objeto lo son a la programacin tradicional. Se trata de tcnicas menos intuitivas pero ms eficaces por razones tanto puramente tcnicas como de trabajo en grupo (mantenibilidad, reusabilidad etc.).
24
3.3.
Premisas.
Esta metodologa parte por lo tanto de la siguiente premisa:
Los procesos secuenciales son solamente un caso particular de los procesos posibles, incluso dentro del mundo fsico. El comportamiento general de los procesos es el de una mquina de estados.
Es tambin cierto que: Los procesos digitales, basados solamente en informacin, son, por naturaleza, menos secuenciales que los procesos del mundo fsico. Las reglas que dirigen los procesos son, en general, decisiones arbitrarias, de origen interno o externo a la organizacin y por lo tanto esencialmente variables. Como es cierto que ninguna organizacin tiene control sobre lo que ocurrir en el futuro, por ejemplo sobre cambios en la regulacin o en el mercado, la volatilidad de las reglas que dirigen el sistema no puede nunca ser eliminada. Por otra parte, esta metodologa completa el anlisis de los procesos que propone Yourdon con tcnicas como los Diagramas de Flujo de Datos. Lo que hace es aadir una dimensin de control que se produce cuando se pretende automatizar el proceso y el encaminamiento de tareas.
3.4.
3.4.1.
La modelizacin con DFDs.

Breve recordatorio de la tcnica de DFD
El Diagrama de Flujo de Datos (DFD) es una potente tcnica de descripcin de procesos. Parte de la idea de que todo en un sistema puede describirse como un flujo de informacin y que sta, como la energa, ni se crea ni se destruye sino que se transforma para diversos usos. Todo sistema, por lo tanto, se puede ver como una serie de estaciones de transformacin donde los datos sufren una modificacin debido a cualquier razn (tanto aportacin externa de datos como interna, por cualificacin de los datos).
25
Se definen solo 3 tipos de elementos:
Elementos
Significado Proceso Estacin de transformacin de los datos por cualquier mtodo. Se describe con La informacin que recibe y la que produce. Lo que hace
Almacn de informacin Basado en cualquier formato (papel, cinta, disco, carpeta etc.), se trata de donde la informacin reside. Puede ser tanto fuente de informacin como receptora, si existe creacin o modificacin de los datos. Entidad externa Agente externo al proceso que se estudia, incluso si pertenece a la misma organizacin pero es otra unidad sobre la que no se tiene un control directo dentro del proceso.
Tabla 1 - Elementos de DFDs La potencia del DFD proviene de su sencillez conceptual y del hecho de que el anlisis se lleva a cabo mediante una iteracin de descripcin de cada proceso encapsulado. As, el diagrama de Contexto da lugar al DFD de nivel 1, donde ya figuran los procesos en los que consiste el proceso del nivel anterior, as como la relacin de flujos de datos entre ellos y con el exterior. Siempre debe verificarse que un proceso en un nivel tiene el mismo flujo de informacin de entrada y de salida que el proceso que lo representa en el nivel superior. La descomposicin de tareas en procesos, as enmarcada, tiene varias ventajas: La simplificacin con cada nivel es de orden exponencial. Las utilidades estn encapsuladas de forma que se puede modificar con facilidad cualquiera de los componentes. Tiende a ayudar a independizar tanto funcionalidades como procesos en s y a basar la integracin del proceso en los datos, minimizando la necesidad de dilogos sncronos. Las reglas de gestin de la informacin son tambin muy sencillas: Los procesos no pueden ser fuentes de informacin ni sumideros de informacin. Toda la informacin viene de fuera o se genera en algn sitio
26
interno. Esto, que se detecta enseguida con esta tcnica, es uno de los orgenes de diseos ineficientes, incompletos o directamente ignorantes de la realidad completa del problema que se pretende solucionar. La nica informacin que se utilice en un DFD pero que no trascienda al nivel superior tiene que ser informacin de control y por tanto, seguramente, menos crtico que los datos en s. Las entidades externas tienen dos reglas que se ignoran con frecuencia dando origen a no pocas rigideces en los diseos. No se tiene informacin sobre los intercambios entre entidades externas. Si fuera necesaria esta informacin, es necesaria una funcionalidad de conector, es decir que el modelo de comunicacin es en estrella, con la organizacin en el centro. Las entidades externas pueden ser mltiples. Incluso si se trata de entidades aparentemente tan estables como el organismo regulador del mercado o el accionista, es necesario prever que en lugar de una sean varias, de forma que el intercambio de informacin con ellas prevea esta multiplicidad. Ambas reglas son cruciales para ver la complejidad inherente en la coordinacin de entidades externas y ste es un aspecto cada vez ms importante, por la externalizacin creciente de procesos especialistas en una economa cada vez ms colaborativa. El aspecto del grfico de los DFDs es muy til a la hora de estudiar la complejidad de un sistema debido a la cantidad de intercambio de informacin entre sus componentes, aunque solamente sea a nivel cualitativo. Un diseador con experiencia, ante un grfico con demasiados intercambios de informacin, deber preguntarse si la modularizacin que se ha realizado es correcta o si por el contrario se est dejando llevar por aspectos ajenos al sistema en s, como pueda ser la organizacin de los recursos humanos que llevan a cabo el sistema. Este aspecto permite aislar los aspectos de proceso y hallar un diseo de sistema estable que no afecte a, ni quede afectado por, otras caractersticas del proceso que se estudia.
27
3.4.2.
Diagrama de contexto.
El DFD empieza con el diagrama de contexto, cuyo objetivo es el de delimitar el mbito del sistema que se aborda. Su elaboracin permite identificar los siguientes elementos del sistema: las entidades externas con las cuales el sistema interacta (quines son los agentes involucrados), lo cual permite identificar el tipo de entorno del que se trata (financiero, industrial, etc.). la informacin que el sistema intercambia con el entorno y el canal utilizado.
Este diagrama es particularmente til cuando se trata de un sistema donde todas las entidades externas son externas tambin a la organizacin que est modelizando, porque en ese caso se trata en mucha medida de un diagrama propio de la industria y no de la compaa. Esto es una mtodo muy til para distinguir ambos aspectos, y por tanto la variabilidad del sistema en s. Se presenta como:
> Peticiones y datos, pagos < contratos, liquidaciones,facturas
Cliente
Regula dor
< Informacin obligatoria > Normativa
DFD de contexto
Cias. < Trabajos a realizar, pagos Subcontr. > Resultados, facturas
Ent. 1
Figura 1 - DFD genrico de contexto
28
3.4.3.
Diagrama de nivel 1
El diagrama de nivel 1 es la primera descomposicin funcional del sistema y su objetivo, como todos los diagramas sucesivos, es encapsular las funcionalidades de forma que cada una de ellas vuelva a estudiarse con la misma disciplina que un diagrama de contexto Idealmente, la comunicacin entre procesos debe hacerse a travs de los datos, minimizando la comunicacin entre procesos. Esto es porque la comunicacin entre procesos implica una interdependencia que introduce rigidez en el sistema. Es decir, los datos debern tener suficiente informacin para que cada proceso, de forma independiente, lleve a cabo correctamente la transformacin de la informacin necesaria.
> Peticiones y datos, pagos < contratos, liquidaciones,facturas
1
Contratacin
< Informacin obligatoria > Normativa
4
Proceso 4
Cliente
Regula dor
6
CRM? Datos de cliente
7
Admindel sistema
2
Gestin de Subcontr.
3
Proceso 3
Cias. < Trabajos a realizar, pagos Subcontr. > Resultados, facturas
Ent. 1
Figura 2 - DFD genrico de nivel 1
29
El anlisis se prosigue iterando esta explosin de cada uno de los procesos identificados y siempre conservando el equilibrio de los flujos de informacin. El resultado puede tener la granularidad que sea necesaria para el objetivo que se persiga. Si se trata del desarrollo tradicional de un sistema, debe llegar al nivel de programa y transaccin y ayuda a completar el modelo de datos con la informacin necesaria para la correcta ejecucin de los procesos. Es cada vez ms frecuente que el desarrollo d lugar a un sistema mixto en el cual se integren paquetes y funcionalidades existentes, y frecuentemente externas. En ese caso es particularmente til porque permite profundizar solamente en aquellos procesos en los cuales sea necesario y delimitar con precisin lo que se desarrolla y lo que se integra. Esto tambin es cierto en la evolucin del sistema, en el cual, con el tiempo, se querrn integrar nuevas funcionalidades, actualizar algunas existentes y desarrollar nuevas.
3.5.
3.5.1.
Las carencias de la tcnica de DFD

El flujo de control
El DFD es la descripcin de los flujos de informacin. La modelizacin es ms estable cuanto ms reducida est la integracin a los datos, sin flujos de datos entre procesos. Si esto fuera as, tiene muy poco en cuenta el orden o la dependencia entre procesos. Del punto de vista del diseo de procesos, esto es un acierto dado que, a nada que el proceso no sea realmente secuencial, como hemos dicho que son la mayora, el orden de ejecucin de los procesos no es predefinido sino que se establece segn las necesidades de cada caso. Sin embargo, resulta necesario determinar cmo se organiza el trabajo y cuales son las posibles etapas por las cuales va a pasar un proceso. Es necesario saber definir las etapas posibles de un proceso para poder automatizar el despacho de tareas y simplificar al mximo cada una de ellas, acotando y minimizando la necesidad de recursos especializados. Hay que definir adems la forma en la cual esas tareas se articulan y el criterio o regla de negocio que rige en cada caso. Esto, tan importante, no se recoge en los DFDs y sin embargo es, de lejos, la parte ms voltil del sistema.
30
Como resumen, podra decirse que: El DFD define qu se hace, es decir la funcionalidad real que requiere la aplicacin El flujo de control tiene los mecanismos para despachar tareas y en cada caso decidir quin, en qu orden en cada caso y con cuntas repeticiones. Estas decisiones, sin embargo, son las que deben poder cambiarse con enorme flexibilidad porque estn sujetas a criterios arbitrarios cuya volatilidad es incontrolable.
3.5.2.
La funcionalidad originada por los datos.
Como todas las tcnicas de anlisis de arriba abajo, se corre el riesgo de perder de vista lo que tienen en comn las hojas del rbol resultante del anlisis, es decir, cunto se parecen entre s la transaccin de uno de los procesos con la de otro, separado del anterior en un nivel alto (1 2). Este aspecto no tiene ningn peso en el caso de los procesos por lotes (procesos batch), que suelen ser muy especficos, pero s en los procesos on-line, es decir donde una persona ve informacin y toma una accin de entre un conjunto de acciones posibles. Esta puesta en comn de la visualizacin se recoge bien en las tcnicas orientadas a objeto, aunque no se refleja en los DFDs. En realidad, existen relativamente pocas formas de ver una entidad de datos y de interactuar con ella, aunque se matice segn el perfil del actor o las transacciones posibles en un momento dado. Es por tanto posible lograr agrupar la presentacin o visualizacin de los datos para la mayora de tareas y de usuarios. Los derechos de acceso de cada uno es lo que debe marcar lo que se puede ver y lo que se puede hacer con lo que se ve. De hecho, suele ser bastante fcil identificar, de cada estructura de informacin, lo que es pblico y lo que tiene restricciones y suele corresponder a su vez con bloques de informacin y no a datos aislados. Por ejemplo, la manera de ver los datos bancarios de un cliente en web es prcticamente la misma, independientemente del banco tanto como del cliente. Esa misma interfaz de usuario, con alguna funcionalidad aadida, es utilizable por otros usuarios. Cuantos ms actores tenga un proceso, ms necesario es agrupar la presentacin en el mnimo nmero de componentes, dirigidos por el perfil de los usuarios.
31
3.6.
Flujos de datos y flujos de control.
Tal como se describa en la introduccin, es cada vez ms frecuente que los procesos de negocio y su encadenamiento lgico de tareas no se encuentre en la organizacin real sino en la virtual que se encuentra dentro de los sistemas de informacin. Una empresa puede prestar atencin a la optimizacin operativa por diversas razones que se han expuesto en el captulo anterior. Sin embargo, cuanto mayor sea la importancia que se le conceda, mayor es la importancia del sistema en la organizacin de la actividad de las personas que a l se conectan, incluidos los clientes finales. En el extremo, lo que se pretende conseguir es que los sistemas ofrezcan bandejas de trabajo a los diferentes equipos de personas especializadas de forma que nadie se ocupe de secuenciar, priorizar o elegir tareas y que cada persona tenga, en su manera de conectarse al sistema, acceso a una serie de tareas simples en la cual se apilan los trabajos. Los flujos de control, por tanto, son los que determinan quin hace qu en qu momento. Sin embargo, tal como se ha explicado, los DFDs no solo expresan mal este tipo de dependencias, sino que nuestro diseo se ha centrado en eliminarlas y dejarlo todo integrado a nivel de datos. Es necesario por tanto aportar al DFD una dimensin de control de flujo que no tiene. Se trata en realidad de ordenar el mismo anlisis que se realiza para los DFDs, pero estructurado alrededor de dos ejes diferentes: Segn las etapas, en las que puede estar un proceso, las tareas que se pueden realizar en cada una, los responsables de realizarlas y quin ms, si fuera necesario, podran llevarlas a cabo. Segn los datos o la informacin que se trata en el proceso, su visualizacin y las acciones que se pueden llevar a cabo sobre ella.
32
Captulo 4.
Definicin de componentes.
Antes de empezar el anlisis del control del proceso, es necesario definir los elementos que se van a utilizar.
4.1.
Elementos de la metodologa.
El objetivo de la metodologa es proporcionar una descripcin formal y completa del proceso. Los elementos que se utilizan son de dos tipos: Los elementos de datos: o o o o o El expediente Los perfiles de usuarios las etapas, los trabajos o procesos masivos la tabla de reglas
Los elementos de control que configuran el mapa de procesos y que son:
Solamente se definen aquellos elementos que son especficos de esta metodologa, puesto que los dems estn ya definidos en mltiples publicaciones. Por lo tanto, conceptos tan importantes para el diseo de sistemas como entidades, relaciones entre entidades o interfases, no se describen aqu por ser comn a la mayora de las tcnicas de descripcin de sistemas.
33
Muchas de las definiciones que se dan tambin son familiares a las tcnicas de gestin de procesos (BPM). La gran diferencia entre esta metodologa y la de BPM consiste en el uso y en el mecanismo de encadenado entre las tareas.
4.1.1.
Expediente.
El expediente es la estructura de datos que soporta todo el diseo del sistema. De hecho, los sistemas podran modularizarse segn la estructura de datos que los dirige, simplificando as el diseo alrededor de una misma entidad global. Cada expediente (o estructura de datos) puede pertenecer a un expediente de mayor rango o complejidad, que a su vez puede estar incluido en otro proceso. Un expediente es una coleccin estructurada de informacin, un conjunto de entidades y relaciones cuya transformacin es el origen y el objetivo de todo el proceso. Tienen un punto de entrada o creacin y uno o varios estados finales que hay que identificar por las necesidades de archivo que se producen. Hay que prever siempre que tenga adjunta informacin no estructurada correspondiente a comentarios, grabaciones, documentos incluso, que aportan informacin adicional que no merece sistematizar. Tal como se ha mencionado al analizar las carencias de la tcnica de DFD, las estructuras de datos tienen su propia interfaz de presentacin de forma que en cualquier momento, si fuera necesario por eventos externos al proceso como por ejemplo una llamada del cliente, se puede visualizar la informacin y llevar a cabo acciones sobre ella. Puede ser que haya varios bloques de datos o incluso entidades, cuyo acceso est permitido o no segn el perfil del usuario. En la medida de lo posible, la interfaz de presentacin puede mantenerse nica, para ser utilizada desde todos los canales necesarios y dirigida por una estructura de perfiles de acceso. Se puede dividir el tratamiento de los expedientes entre servicios y presentacin: las acciones que se realizan sobre las entidades residan en mdulos comunes a todos los procesos y centralizan as las reglas de control la presentacin se reduzca a los mnimos casos necesarios, soportados por una jerarqua de derechos de acceso.
34
4.1.2.
Perfiles.
Los perfiles son los diferentes niveles de autoridad que van a tener las personas para tomar decisiones sobre lo que se puede hacer con un expediente. Cada perfil podr acceder a determinados expedientes y no a otros, de acuerdo con unas reglas que hay que explicitar, y podr llevar a cabo determinadas acciones y otras no. Los usuarios del sistema debern darse de alta como parte de uno o varios perfiles, de forma que no sea personal, sino funcional, el acceso a transacciones y trabajos dentro del sistema. Merece la pena mencionar el hecho de que los perfiles deben orientarse ms bien hacia el reparto de trabajo, minimizando en lo posible aquellos casos en que un perfil tiene que escalar una peticin del mundo exterior por no poder resolverla. Estos casos sern siempre muy caros en trminos de organizacin, tanto por el retraso en la realizacin de una tarea como por la necesidad de coordinacin que se produce. La mejor manera de resolver este tipo de necesidades es igualmente con dos perfiles, uno que hace y otro que aprueba, pero de manera que el que hace pueda siempre hacerlo todo y la supervisin se lleve a cabo solamente por excepcin.
4.1.3.
Las etapas.
Son los estadios por los cuales pasa un expediente a lo largo del proceso que se disea. Estas etapas pueden ser de varios tipos: Bandejas de trabajo: etapas en las cuales se requiere que un equipo humano lleve a cabo una accin determinada y, de acuerdo con el resultado, informe al sistema para decidir la etapa siguiente. Etapas de espera: etapas en las cuales no ocurre nada de forma proactiva, salvo que se produzca un evento externo o que el propio paso del tiempo haga que el expediente ya no cumpla las condiciones de espera. Procesos colaborativos: etapas en las cuales se produce una salida masiva de la informacin para ser tratada por otro actor externo al proceso que solamente tiene que devolver el resultado de la accin. En realidad, este tipo de
35
procesos da lugar a dos etapas. Todo ello se describe ms adelante en este captulo, en el apartado de los procesos colaborativos. Procesos masivos: etapas en las cuales se lleva a cabo una tarea para todos los expedientes que estn disponibles y que constituyen una etapa dentro del proceso.
4.1.4.
El mapa de procesos (las etapas).
El mapa de procesos es donde se describen las etapas por las cuales pasa un expediente, es decir los estados en los cuales puede estar. Se trata de una particin arbitraria que debe recoger el mbito del proceso que se estudia y que debe corresponder a la visin que se podra tener si se congelara la produccin en un momento dado: la etapa es cada una de las situaciones en las que est distribuido el conjunto de los expedientes. La representacin del mapa de procesos como de un bus en el cual estn las etapas cumple con dos fines: Ofrece una idea de secuencialidad del proceso, que intuitivamente es la que resulta ms directa para la mayor parte de las personas Permite a la vez romper la idea puramente secuencial, de forma que es ms fcil imaginar una vuelta atrs o una modificacin del expediente que cuando se utilizan los flujogramas tradicionales. Separa etapas y trabajos, de forma que se pone de manifiesto la independencia entre unas y otros.
4.1.5.
Trabajos.
Los trabajos son procesos que se dedican a hacer una accin especfica para aquellos expedientes que lo necesiten. Se trata de procesos por lotes y pueden tener como resultado tanto la modificacin del expediente (enriquecindolo con una informacin de una fuente externa, por ejemplo) como la creacin de otra informacin diferente. Los trabajos deberan presentarse como una biblioteca de utilidades de forma que las reglas de trnsito del expediente puedan invocarlos cuando los necesiten, sin ninguna integracin con el flujo del proceso.
36
Las comunicaciones son una necesidad comn a todos los trabajos y todas las industrias. Sea cual sea el receptor, un proceso automtico requerir algunas de las capacidades siguientes: Envos de mail Envos de SMS Envos de carta, claramente cada vez menos utilizado, y sin embargo el nico con valor legal de comunicacin Emisin de llamadas.
4.1.6.
Reglas.
Las reglas son aquellas que dirigen la vida de cada expediente. Habr reglas de varios tipos: de validacin, que identificarn incidencias o incorrecciones en los datos del expediente. de trnsito, que son las que, de acuerdo con la informacin presente en el expediente, decidan en qu tipo de etapa est. de disparo, que son las que activarn determinadas acciones cuando se den unas condiciones en el expediente. Las reglas deben ejecutarse cuando se crea un expediente, cada vez que se modifica pero tambin de forma peridica en proceso batch porque el paso del tiempo es casi universalmente un factor de cambio de estado en los procesos.
4.1.7.
Transacciones.
Las transacciones son procesos on-line que dispara un usuario de forma asncrona y a priori imprevisible. Las bandejas de entrada constituyen un mecanismo para organizar grandes grupos de personas dedicadas a unas tareas masivas (pooling), que pueden utilizar transacciones para llevar a cabo su trabajo. Las transacciones, a priori, se pueden producir en cualquier momento porque son reactivas a una nueva informacin entrante.
4.2.
Tipos de procesos.
La razn para detenerse, aunque sea con brevedad, en los diferentes modelos de procesos, es la necesidad que tiene el diseador de saber de qu tipo de
37
herramientas dispone para sus necesidades y cuales son los impactos de elegir uno u otro tipo de procesos, antes de tomar una decisin. Actualmente, por ejemplo, existe la tendencia de considerar los procesos masivos por lotes como propios de pocas pasadas. Esto da lugar a que se diseen sistemas que obvian esta necesidad, a pesar de que es una necesidad que requiere esfuerzos especficos como las tcnicas de punto de sincronizacin, de planificacin de recursos y de rendimiento. El forzar la utilizacin de procesos inadecuados a las necesidades, es siempre un problema para la mantenibilidad y la estabilidad de la aplicacin.
4.2.1.
Procesos sncronos.
Definicin Se trata de aquellos procesos que establecen un dilogo sncrono con su contrapartida, sea ste un servidor, un Web Service externo o cualquier otra transaccin, externa o interna. Ventajas Este tipo de procesos conocen al instante el resultado de las acciones que se lleven a cabo, optimizando la posibilidad de la contrapartida de contestar o llevar a cabo una accin. Debilidades Este tipo de procesos, al establecer un dilogo en tiempo real con alguna contrapartida, es el que tiene el nivel ms alto de dependencia de su contrapartida. Este tipo de procesos tiene las caractersticas siguientes: su dependencia sncrona hace que la estabilidad dependa de la de su contrapartida y el canal de comunicacin (conexin ADSL, o pantalla, si la contrapartida es un usuario). La ventaja de la rapidez se pierde en los momentos en que actor y contrapartida no estn ambos disponibles (por ejemplo, nuestro proceso se conecta a un sistema que da un precio de Bolsa y est cado). La dependencia de la contrapartida obliga a una cantidad no desdeable de cdigo de recuperacin de errores y procedimientos de contingencia. Son procesos que se suelen ejecutar en prioridad mxima y cuyo impacto en el rendimiento de recursos tecnolgicos (servidores, bases de datos, lneas de comunicacin) puede ser muy alto y llegar a comprometer otro tipo de procesos sncronos.
38
La dependencia entre contrapartidas en procesos complejos presenta el problema aadido de la transaccionalidad (cmo estar seguros que todos los procesos, para una transaccin dada, se han comportado de forma coherente), una caracterstica entre procesos cuya coordinacin, si no est incluida en las herramientas, resulta muy difcil de codificar.
Recomendaciones Reducir en lo posible el uso de procesos sncronos a los dilogos con usuarios. En lo posible, sustituir todo intercambio sncrono entre procesos por una integracin a nivel de datos (un proceso deja unos datos que el otro utiliza cuando estn disponibles). Si deben utilizarse, cuidar especialmente todos los aspectos que afecten al rendimiento y a la transaccionalidad.
4.2.2.
Procesos colaborativos.
Definicin Se trata de aquellos procesos en los cuales existe la participacin de un tercero que tiene que llevar a cabo una tarea en nuestro proceso. Esta tarea se reflejar en una aportacin de informacin o el lanzamiento de otro proceso dentro o fuera del mbito de nuestro sistema. En mucha medida, la identificacin de un proceso colaborativo depender del tiempo de respuesta del intercambio de informacin. Es decir, si se trata de un proceso que utiliza capacidades externas mediante mecanismos on-line, como un web service por ejemplo, se puede obviar el hecho de que realmente parte del proceso ocurra fuera, porque al no aadir ninguna dificultad de gestin, el error o retraso es ms una caracterstica tcnica que otra cosa. El proceso colaborativo es aquel en que la responsabilidad sobre errores y retrasos es ms bien funcional y donde el tiempo de intercambio es perceptible. Es de sealar tambin que los procesos colaborativos dan en realidad lugar a dos etapas: Una etapa previa al envo de la informacin, donde se encuentran los expedientes pendientes de tratamiento Una etapa de pendiente de respuesta, donde se encuentran los expedientes enviados pendientes de recibir la respuesta del tratamiento.
39
En cuanto a la previsin de qu hacer cuando la respuesta se demora ms del tiempo esperado, depender de la frecuencia con la cual esto sea esperable. Se puede elegir entre tres opciones: No tratar de forma especfica, cuando existe una confianza razonable en la contrapartida y el impacto en el expediente no es muy alta, Tratar como error o incidencia genrica, cuando a pesar de que se espera con poca frecuencia, el impacto en el expediente requiere tratamiento rpido Tratar como incidencia especfica, cuando la frecuencia o el impacto son altos. Esta incidencia especfica ser una bandeja de entrada. Ventajas Este tipo de procesos permite utilizar capacidades diferentes de las internas para completar la funcionalidad o la informacin del sistema sin tener que invertir en su construccin. Se utilizan en la realizacin de trabajos externos y en el enriquecimiento de la informacin. La mayor parte de los trabajos externos, correctamente controlados, permiten la dispersin de proveedores lo cual es siempre una ocasin de mejora de costes y de dispersin del riesgo de proveedor. Debilidades Este tipo de procesos utilizan informacin comn a ambos sistemas, al menos durante un lapso de tiempo. En el diseo, hay que tener en cuenta los aspectos siguientes: Es fundamental definir la propiedad de los datos en cada momento, mediante el uso de semforos por ejemplo, de forma que no pueda interferir una modificacin de informacin con la funcionalidad externalizada. Es necesario, para cada uno de estos procesos, guardar traza tanto del momento en el cual se cede el control al proceso colaborativo como de aquel en el cual se recupera el control, as como del resultado del proceso y del tercero con quien todo ello se ha llevado a cabo. Tanto para la entrega como para la recepcin, hay que reservar el momento de entrega y carga de datos. Es necesario hacer un estudio de Riesgos de Informacin para cada una de las interfaces con procesos colaborativos para securizar el intercambio o prever contingencias.
40
Recomendaciones Salvo que el proceso sea indivisible o se trate de un intercambio con organismos nicos como las entidades reguladoras (Banco de Espaa por ejemplo), es razonable prever mltiples proveedores, a pesar de que la intencin no exista en la organizacin. Prever mecanismos de gestin de las interrupciones en los intercambios. Prever entornos de intercambio separados entre posibles proveedores. Prever logs de todos los procesos de envo, carga y monitorizacin de niveles de servicio. Prever la posibilidad de un proceso de asignacin de cargas segn algunos criterios (asignacin de tareas segn un ratio, segn resultados, segn geografa etc.).
4.2.3.
Procesos en tiempo real (on-line).
Definicin Se trata de los procesos que ejecutan tareas para cada uno de los expedientes de forma individual. Entran en esta categora, al menos, todas las transacciones hechas para seres humanos, aunque puedan disparar despus acciones masivas. Ventajas En este tipo de procesos, se conoce en tiempo real el resultado de las acciones que se lleven a cabo, acortando el tiempo de toma de decisiones. Debilidades Este tipo de procesos tiene las caractersticas siguientes: Para que el usuario tenga acceso, se requiere una estructura de presentacin que suele estar implementada sobre una arquitectura de servicios. Siempre es el caso cuando se trata de un acceso mediante explorador web. Son procesos que se suelen ejecutar en prioridad mxima y cuyo impacto en el rendimiento de recursos tecnolgicos (servidores, bases de datos, lneas de comunicacin) puede ser muy alto, por lo que deber cuidarse especialmente la eficiencia. Son procesos dedicados a usuarios y que por lo tanto tienen que tener controles slidos de recuperacin de errores de forma que el sistema pueda gestionarlos correctamente. Este aspecto ser ms importante cuanto ms numerosos sean los usuarios potenciales. Ser crucial en el caso de transacciones web.
41
Hay
que
tener
previstas
las
transacciones
de
gestin
de
usuario
(administracin, conexin, gestin de contraseas etc.). Recomendaciones Cuidar la usabilidad y la proteccin de errores. Cuidar especialmente todos los aspectos que afecten al rendimiento. Si se trata de una aplicacin basada en explorador web, en entorno externo, cuidar la seguridad.
4.2.4.
Procesos por lotes (batch).
Definicin Se trata de los procesos que ejecutan unas tareas de forma masiva. Esto quiere decir que seleccionarn todos los expedientes para los cuales hay que hacer una determinada tarea y la harn en bloque para todos ellos. Ventajas Este tipo de procesos permite utilizar los recursos fsicos de computacin de forma intensa, sin necesidad de atender a otros procesos ms all del bloqueo de los recursos que se estn tratando en cada momento. Debilidades Este tipo de procesos tiene las caractersticas siguientes: Es fundamental definir el bloqueo necesario de datos durante la ejecucin del proceso por cuanto un proceso masivo ejecutado sin prestar atencin al bloqueo puede inutilizar un espacio de datos entero hasta su finalizacin. La manipulacin masiva de datos puede tener que ser reservada a horas valle de ocupacin de recursos, por el consumo que tenga de stos. Recomendaciones Es necesario, para cada uno de estos procesos, utilizar tcnicas de rearranque (checkpoint-restart). Estas tcnicas aseguran que, en caso de una interrupcin o parada accidental del proceso, ste termine ordenadamente con la tarea del expediente en curso y pueda volver a arrancar tantas veces como sea necesario sin ocasionar repeticin en el tratamiento ni otros errores. Se debe considerar el tipo de accesos y el posible bloqueo de datos para ver si se pueden ejecutar a la vez que otros procesos con acceso a los mismos datos o procesos sncronos.
42
El lanzamiento de este tipo de procesos debe evitar en lo posible estar relacionado con dilogos sncronos o con un perfil de usuario. Idealmente, deben ser lanzados desde un script o, incluso mejor, un planificador de tareas.
43
Captulo 5.
Metodologa de anlisis de procesos.
La metodologa que se describe es una tarea que viene a continuacin de los mtodos tradicionales de los que ya se ha hablado y los completa. As pues, en este captulo se va a asumir que el anlisis del modelo de datos y el de procesos estn realizados, para enfocar la metodologa al estudio de los elementos de control, que se centra en el estudio de la coordinacin del proceso. Esto quiere decir que, en un sistema corporativo tpico, tanto transacciones como procesos masivos seguirn igual y diseadas del mismo modo. La metodologa permitir cerrar la definicin de los elementos de control en aquellas fases y procesos en los cuales se detecte una necesidad de coordinacin entre tareas o entre funciones para obtener un resultado. El eje director del anlisis es la identificacin de etapas, que coincide con el modo intuitivo con el que la mayor parte de los seres humanos describen los procesos. Este ejercicio se acompaa con un mtodo que asegure un resultado sistemtico y repetible que presta atencin a priori a aquellos puntos que suelen suponer un problema cuando el sistema en produccin.
5.1.
El proceso secuencial.
Es la descripcin ms inmediata e intuitiva, que suele consistir en una secuencia de tareas encadenadas. Incluso las personas de mente menos orientada al proceso consiguen identificar con bastante precisin los hitos o actividades principales del proceso ideal, es decir de aquel en que todo llega a buen trmino sin errores.
44
Es tambin muy intuitivo, una vez diseada la secuencia, identificar la condicin que cumplen todos los expedientes que pasan por esa tarea.
5.2.
Identificacin de resultados imprevistos.
A partir del resultado de la etapa anterior, hay que identificar, en cada uno de los pasos, las etapas o tareas que se deben llevar a cabo cuando se produzcan resultados imprevistos o errores. Los resultados imprevistos o errores y sus necesidades de tratamiento se deben identificar en cada paso de forma sistemtica, porque es de ah de donde va a provenir buena parte de la complejidad de coordinacin del proceso. Es necesario pues estudiar cada etapa de forma sistemtica en tres aspectos: Definir posibles errores tcnicos de salida de la etapa que se estudia (errores de sistema, errores en datos que imposibilitan seguir etc.) Buscar las diferencias, si las hay, entre el conjunto de expedientes de entrada al paso que se estudia y el conjunto de entrada al paso siguiente. Como el conjunto de entrada al paso siguiente es necesariamente un subconjunto del conjunto de entrada al paso que se estudia, hay que analizar la composicin del conjunto de expedientes que, cumpliendo el primero, no cumplen el segundo. Cuando existen varias etapas, es porque cada una de ellas aporta algn elemento de informacin al expediente y lo completa y cada una de ellas supone un avance a lo largo de una serie de actividades. Esto quiere decir que, necesariamente, cada etapa puede tener un resultado no satisfactorio y que hay que definir cmo se recuperan los expedientes en ese caso y qu se hace con ellos. De hecho, parte de estos casos estarn ya identificados en el paso anterior, con lo que se identificarn subconjuntos dentro de conjuntos ya definidos aunque seguramente cada uno de ellos dar lugar a acciones diferentes sobre el expediente. De acuerdo a la manera en la cual se enfrenten estos casos, hay que distinguir dos tipos de salidas imprevistas:
45
Los errores, como resultados atpicos de los sistemas que necesitan un estudio ad-hoc de cada caso. Este tipo de resultados, que debe ser poco frecuente y se debe tener siempre a minimizar, existe y existe ms cuanto ms sistemas de la compaa estn implicados en el proceso, por la diversidad de calidad esperable en las interfases con otros sistemas.
Las incidencias, como resultados no-positivos que hay que tratar de forma sistemtica dentro de las reas de negocio normales, dentro de las actividades previstas de la organizacin dedicada al proceso. Es importante saber que la proporcin de incidencias suele ser mucho ms alta que lo que se prev en las reas de negocio. Esto es ms cierto cuanta menos experiencia se tenga en el proceso y suele ser una fuente de grandes modificaciones a posteriori, cuando aparecen en la produccin real. Para cuantificar el problema, es til saber que determinados procesos tan simples como la apertura de una cuenta a travs de canales directos, por ejemplo, tienen una proporcin de incidencias superior al 20%.
As como el estudio de los errores es ms inmediata, puesto que algunas reas especializadas son las que se ocuparn de esta especie de rozamiento entre aplicaciones, el producto de la identificacin de incidencias dar lugar a la reflexin sobre qu errores son propios del negocio y cules no, y qu grupo de usuarios, o con qu herramientas, se van a solucionar estos casos. Es incluso posible que un mismo error o incidencia d lugar a diferentes actividades de acuerdo con caractersticas del expediente.
5.3.
Gestin de plazos.
Finalmente, hay que tener en cuenta que las tareas pueden no producirse. En particular, cuando una etapa requiere de la colaboracin de un tercero es fcil que existan retrasos que hay que gestionar. Si el tercero es un actor sin obligaciones para con el dueo del proceso, es seguro que esto ocurrir. En la manera de gestionar este aspecto, ser radicalmente diferente cmo tratar retrasos de terceros con obligaciones, como proveedores, que lo que afecte a terceros sin ellas, como clientes. Tpicamente, hay que considerar adems el impacto comercial que tienen estas etapas, tanto por la capacidad de llevar a buen
46
puerto el proceso del que se trate, como por la intensidad de los mtodos de seguimiento que se van a emplear. En el mundo actual, el cliente final es cada vez menos fiel, est ms informado y tiene ms medios a su alcance para negociar. Adems, tal como hemos dicho, la gestin comercial de las operaciones se desplaza hacia reas operativas donde ocurren de forma sistemtica. Con un cliente menos convencido, y un seguimiento ms tibio, hay que prever que un porcentaje alto de las tareas tienden a no ocurrir. Incluso las Administraciones Pblicas estn mejorando la gestin de sus incidencias. En un proceso comercial tpico de canal directo, esto puede afectar a ms de la mitad de las operaciones. Es esencial por lo tanto definir qu se va a hacer, y cmo, si la colaboracin no se produce. Esto requiere una nueva identificacin de conjuntos de reglas, que afectarn a las definiciones que ya se tenan, puesto que ya todos los expedientes estaban localizados. Este anlisis se suele desestimar considerando que son excepciones, cuando es un ratio superior al 20% en prcticamente todos los procesos. Enfrentarse a un volumen tan significativo de expedientes fuera del proceso pensado, sin herramientas de soporte y de modo manual resulta ser ms conflictivo para la organizacin cuanto ms orientada est hacia la industrializacin de tareas. Este razonamiento, basado en una premisa falsa, es responsable de mucha de la insatisfaccin, costes y problemas organizativos a los que han dado lugar este tipo de proyectos. Dependiendo de la naturaleza del tipo de reclamacin, los nuevos procesos a su vez podrn subdividirse en diferentes etapas dentro de la reclamacin y as sucesivamente. Sin embargo, es necesario tener en cuenta que la atomizacin de las etapas solamente es til en la medida en que ayudar a la gestin del proceso, bien porque dar lugar a la utilizacin de perfiles diferentes o a la de mtodos diferentes. En el momento en que esto no sea cierto y todas las iteraciones de la misma tarea impliquen los mismos recursos, no tiene sentido seguir afinando el anlisis. Es crucial, en todos los aspectos de este anlisis, cuidar de mantener identificadas toda la masa de expedientes, de forma que, desde el principio hasta el final, podamos garantizar el control sobre todos los casos, incluido el ms excepcional.
47
Igual que en el apartado anterior, se pueden obtener diferentes cursos de accin de acuerdo con el tiempo transcurrido o con datos propios del expediente.
5.4.
Gestin de incidencias.
La gestin de incidencias, identificadas en el paso 2 como resultados imprevistos no debidos a errores del sistema, es en realidad un anlisis mucho ms parecido al que hemos descrito como gestin de plazos. En ambos casos, se trata de gestionar de forma sistemtica, automtica en lo posible, un seguimiento que es lo nico que est en nuestra mano para asegurar que se consigue el objetivo del proceso. Este enfoque del anlisis de gestin de plazos y de incidencias permite recalcar algunas de las caractersticas importantes: Se trata de establecer a priori las posibilidades de un expediente hasta su final, sin dejar posibilidades abiertas. Se trata de establecer el seguimiento automtico o reclamaciones que se van a producir hasta que se abandone el expediente. Idealmente, este seguimiento podr hacerse de diferentes maneras atendiendo a caractersticas del propio expediente. Hay que tener en cuenta que el abandono requiere tanto una gestin interna de las acciones que ya se hayan llevado a cabo, como, sobre todo, una gestin de las responsabilidades externas que se puedan haber contrado. Volviendo a la idea inicial de que un proceso es siempre un paso, dentro de las actividades de una organizacin, para conseguir un objetivo, podemos decir que las etapas de gestin de incidencias y plazos son las que son verdaderamente cruciales para definir el xito del proceso, puesto que son las que dependen del mundo externo, y se debera asumir que las tareas internas no son un problema. Esto implica que estas etapas sern: Variables, porque dependen de los cambios en el mundo exterior Voltiles, porque se debern probar con criterios comerciales para poder asegurar o mejorar el xito final del proceso Crticas, porque atienden a aquellos expedientes que tienen problemas y por tanto estn menos controlados desde el punto de vista del riesgo operativo.
48
5.5.
Agrupacin de etapas
Una vez identificadas las etapas, se agrupan segn sus caractersticas propias para clasificarlas de acuerdo a los diferentes modelos de procesos que se han descrito en el captulo anterior. Se deben identificar los siguientes componentes:
5.5.1.
El inicio del proceso
El arranque del proceso es cuando se crea el expediente. Esto puede venir determinado por mltiples canales: las oficinas comerciales, con una persona con la que tratar o a la que informar de los posibles problemas en el proceso, o bien una entrada desde Internet, o incluso unos documentos que provengan por un nmero de fax simplemente porque se ha hecho una campaa comercial. Lo que es necesario estudiar para estas etapas es si existen diferentes tipos de proceso segn el canal de entrada de los expedientes. Aunque el dato debe formar parte del expediente, simplemente por trazabilidad de las diversas entradas, es necesario tambin estudiar si van a existir diferentes procesos de acuerdo con este dato y en cualquier caso preparar el sistema para que as sea en cuanto sea necesario.
5.5.2.
La entrada de informacin: recepcin de informacin
Las etapas de espera finalizan cuando se da una entrada de informacin en el sistema, bien del propio cliente, bien de una entidad externa. En el caso de la informacin que proviene del exterior de la organizacin, suele presentarse como documentos fsicos, con la variabilidad que esto ltimo trae consigo, o bien como informacin de otros sistemas. El proceso de recepcin, verificacin e integracin de esa informacin es un proceso tecnolgica y funcionalmente complejo. A nuestros efectos, sin embargo, se puede considerar como una sola entrada de informacin, que deber poderse referenciar al expediente de forma que se pueda evaluar, despus de cada recepcin, el estado en el cual queda el expediente.
5.5.3.
El final del proceso
Rara vez se piensa en el final real del proceso, cuando se puede dar por terminado. El final de un expediente puede requerir el archivado de evidencias o incluso de originales en papel. Se debe considerar, dentro de su mbito, dos aspectos que tradicionalmente se olvidan:
49
se deben controlar tanto los documentos que terminan correctamente como aquellos que han sufrido una de las mltiples incidencias que se han descrito. El archivo fsico o, si ste no existe, el cmo se transforman las evidencias fsicas en digitales, y cmo se conservan y con qu ciclo de vida, es un componente crucial del objetivo del proceso de negocio y para el que hay que asegurar que exista una solucin, sea la solucin corporativa o una externa adhoc por ejemplo.
5.5.4.
Las bandejas de entrada
De las etapas, hay que identificar aquellas que requieren de una intervencin humana para su resolucin o avance. En ese caso, habr que identificar ms adelante cules son los grupos de usuarios que tendrn esta etapa como bandeja de entrada y qu acciones tendrn a su disposicin para resolver la situacin.
5.5.5.
Los procesos masivos
Los procesos masivos deben recoger todos los expedientes que estn en el estado previsto para realizar con ellos una accin. Podran definirse como una etapa en la cual van quedando los expedientes con determinadas caractersticas y que se lleva a cabo de manera masiva, liberando todos los expedientes sobre los cuales se ha dado la accin. Existen dos tipos de procesos masivos a los efectos de la gestin de expedientes. Se diferencian no tanto en su naturaleza como en el efecto que tienen sobre los expedientes. Se deben distinguir: Aquellos procesos masivos que suponen una etapa clara en la gestin del expediente, lo cual suele coincidir con un tipo de proceso que no podra cambiarse con facilidad ni repetirse arbitrariamente. Aquellos procesos que no suponen ningn avance real en el estado del expediente si no que obedecen a una decisin arbitraria, y por lo tanto modificable en cualquier momento, de gestin de una etapa o incidencia. Tpicamente corresponden a envos masivos de mensajes, para reclamaciones o gestin de errores por ejemplo. Este tipo de procesos son en realidad una capacidad del proceso. La razn de identificar con claridad esta distincin es que, as como los primeros, procesos que suponen una etapa en la gestin del proceso, van a dar lugar a una etapa dentro del mismo, los segundos van a dar lugar a un proceso comn, como
50
pueda ser la elaboracin de mensajes (SMS, mails o de cualquier otro tipo) o su envo (envo al teleoperador responsable de los SMS o envo de los mail a travs de nuestro proveedor de acceso Internet).
5.5.6.
Los procesos colaborativos.
Estos procesos, definidos anteriormente, son un caso particular de los procesos masivos y consisten fundamentalmente en una descarga de la informacin para su tratamiento en un tercero y una carga del resultado del tratamiento. Hay dos aspectos que cuidar en este tipo de procesos: El retraso o error en estos procesos, incluso la simple coordinacin, requerir una vigilancia funcional en cuanto a la monitorizacin del proceso en s puesto que tpicamente dar lugar a algn proceso de cuadre por seguimiento del proceso de todos los expedientes o de facturacin de una empresa tercera. Es frecuente, aunque rara vez se prev en el momento del diseo, que un proceso colaborativo termine plantendose entre varias contrapartidas iguales, con un criterio de reparto que puede formar parte de las reglas de negocio. Es por lo tanto necesario prever tanto la distribucin como el control de cada una de las contrapartidas. Es de sealar que, tal como se indica en el apartado 4.1.2, si el sistema con el que se comunica estuviera habilitada para responder al alta o la baja mediante un web service, por ejemplo, el alta y la baja de los contratos podra considerarse un proceso sncrono en lugar de un proceso colaborativo, debido al menor lapso de tiempo para la situacin intermedia y al menos nmero esperable de incidencias de no-respuesta.
5.6.
El mapa de procesos.
El mapa de procesos es el producto final que debe describir el proceso. Se propone la utilizacin de un grfico en el cual: Se tenga una idea de secuencialidad flexible y en el cual las etapas figuran pero no tienen dependencia unas de otras. Las etapas se distinguen por la caracterstica de los expedientes que se encuentra en cada una. Se identifican las que equivalen a una bandeja de entrada. Se identifican las etapas de espera.
51
Se identifican los procesos masivos y colaborativos.
Adems de las etapas descritas, es necesario representar tambin otros elementos que se han identificado a lo largo del anlisis: El soporte de los datos, donde se conserva la informacin relativa al expediente Las reglas de negocio que se han descrito y que configuran el proceso Otros procesos, no directamente relacionados con las etapas pero que el proceso debe poder utilizar y que se han definido ms arriba como capacidades. El diseo de sistemas propio de los aos 90 distingue entre el soporte de los datos, con su modelizacin propia y su estructura, de los procesos, donde se recogeran tanto el mapa de etapas como las reglas que las dirigen y las capacidades que se pueden utilizar. Tal como se ha razonado en los apartados iniciales, es crucial distinguir estos elementos entre s, por ser diferente tanto su origen como su necesidad de cambio. El aislamiento de las capacidades como un catlogo de funcionalidades disponible permite: Su utilizacin cuando se necesiten y su reusabilidad entre procesos. La posibilidad de enriquecer cuando sea posible el conjunto de capacidades disponible con nuevos modos en el mercado, incorporando mtodos como los SMS, mayoritariamente utilizados ya, o la mensajera instantnea. Este crecimiento en funcionalidad se centraliza y se mantiene as independiente de cada proceso. Permite distinguir claramente entre los mensajes y el medio de entrega de los mismos. El aislamiento de las reglas de negocio permite: Aislar la arbitrariedad en el sistema, de forma que se puedan gestionar con agilidad cambios que pueden darse en cualquier momento y con cualquier frecuencia Crear componentes estables para la funcionalidad ms corporativa, es decir aquella que tiene ms que ver con la base del negocio que con la manera en la cual se distribuye en un momento dado.
52
Sin embargo, as como las capacidades son mdulos que se utilizarn en caso de necesidad, el caso de las reglas de negocio es diferente: Las reglas de negocio van a cambiar con toda seguridad. Es necesario poder determinar qu tipo de reglas se aplican en cada momento Es recomendable tener varios conjuntos de reglas que permitan variar todo el proceso de acuerdo a criterios comerciales y, tal como se describe ms arriba, decidir una secuencia diferente dependiendo del tipo de cliente o de su edad o de cualquier aspecto, externo al contexto del sistema, que se necesite tener en cuenta. As descritas, las reglas de negocio son otro componente de informacin, menos atomizado que los datos del expediente pero que necesitan tambin de un sistema de gestin. El mapa completo de procesos, por lo tanto, es un diagrama como el siguiente:
Entrada 1
Proceso colaborativo
Proceso masivo
Entrada n
Bandeja 1 Bandeja 2
Etapa de espera Bandeja n Etapa de Espera m
Fin OK Fin NOK
Reglas de estados
Bandeja Proceso masivo
Datos de los expedientes Proceso masivo (Capacidad) Envo de mails Envo de SMS
Entrada
Figura 3 - Mapa completo de procesos
53
5.7.
5.7.1.
Identificacin de reglas.
Reglas de transicin.
Una de las ideas principales que dirige toda la metodologa, es que los procesos secuenciales no son ms que un caso particular, y ms simple, dentro del conjunto de procesos. En lugar de depender de su historia, el axioma del que se parte es que el estado de un expediente, en general, no debe expresarse a partir de su historia, sino como resultado de la informacin que contiene en un determinado momento.
Las etapas en las cuales puede estar un expediente a lo largo de un proceso constituyen una clase de equivalencia creada sobre un conjunto de atributos de los expedientes.
Se trata pues de identificar cules son los atributos y cmo configurar las reglas que dan lugar a la configuracin del proceso tal como se ha diseado. El hecho de que las reglas que dirigen el proceso estn basados en la informacin presente en el expediente es la garanta de la flexibilidad del diseo tanto como de su estabilidad, puesto que los cambios que se presenten a lo largo del tiempo no afectan a esa estructura ms que, en el peor de los casos, para enriquecerla con informacin adicional que no se hubiera tenido en cuenta en un primer momento. Para cada etapa, por lo tanto, se debe verificar que existe: el dato o la combinacin de datos que indica que la etapa es necesaria (si es que no es deducible del resto de informacin del expediente): Aunque lo intuitivo sea tener un dato dedicado a esta tarea (indicador), es mucho ms estable identificar la combinacin de datos que dan lugar a la decisin y reservar el indicador para cuando se trate de una decisin arbitraria. En ese caso, es necesario prever la etapa que da lugar a esa decisin. la indicacin de que se ha realizado (idealmente, la fecha de realizacin, en lugar de un indicador, por ser informacin ms rica, pero tambin porque permite gestionar la caducidad de la informacin) la indicacin del resultado (con el conjunto de valores mnimos para asegurar la gestin posterior). Hay que tener en cuenta que suele ser necesario prever un campo de comentarios.
54
El resultado de esta fase debe ser una tabla que cruce los valores de los elementos de informacin que dirigen el proceso y el resultado de cada combinacin de valores. Esta tabla es el instrumento que permite verificar que el proceso es completo y que todas las etapas son accesibles.
Var 1 Valor 1
Var 2 Valor A Valor B Valor C
...
Var n Valor
Etapa Etapa 1 Etapa 2 Etapa 3 Etapa 4
Valor 2 Valor 3 Valor B ... Valor n Valor X Valor Valor
Etapa 5
Etapa t
Tabla 2 - Formalizacin de reglas de transicin
En lugar de la tabla, la formalizacin de etapas se puede sustituir por un conjunto de expresiones lgicas, pero la tabla ayudar a establecer el juego de pruebas necesario para contrastar el funcionamiento del sistema.
5.7.2.
Reglas de disparo.
En este contexto, un disparo es el evento que produce la utilizacin de una de las capacidades del sistema. Para asegurar la mayor estabilidad y flexibilidad del sistema resultante, es fundamental mantener a lo largo de todo el diseo la separacin entre los sucesos y las razones que los disparan, es decir entre qu ocurre y por qu ocurre. Cada mdulo o pieza del sistema as diseado tiene una capacidad pura de realizar cosas y espera instrucciones para saber qu tipo de cosas hay que hacer y para qu expediente.
55
Por ejemplo, un conector de mails se compondr de: El mdulo que compone mensajes segn los datos del expediente. El mdulo que se comunica con el Proveedor de Servicios de Internet y los emite. Los mdulos que deciden qu tipo de mensaje debe enviarse son ajenos a estos mdulos funcionales. Idealmente, sern unas reglas ms que decidan en cada caso lo que hay que hacer de acuerdo con el ltimo conjunto de reglas en vigor. Hay que evitar el error de incluir funcionalidades de unos mdulos en otros, como es el caso cuando el proceso que detecta un evento sujeto a mensajes se ocupa de generarlos de forma automtica. Esto dificulta el diseo en varios aspectos. No permite aislar las funcionalidades entre s, dificultando la posible evolucin de un mdulo de generacin de mensajes. No permite concentrar en un solo punto las reglas que las dirigen, reduciendo la flexibilidad total del sistema. Una vez identificadas las capacidades necesarias en el sistema, habr que identificar las reglas que las disparan y que no tienen por qu seguir la misma secuencia que las reglas del proceso. En este caso, el resultado del anlisis debe ser una tabla que establezca la combinacin de los valores de los elementos de informacin que dan lugar a un disparo. El disparo es una coleccin de informacin suficientemente detallada como para que el proceso, al ejecutarse, sepa qu hacer con esa informacin y no necesite ms, como si se tratara de un encargo. Los procesos de disparo, por tanto, deben tener un patrn de ejecucin que cumpla que: el proceso se ejecute y pueda no tener ningn evento en tiempo de ejecucin, el proceso debe recoger todos los expedientes vivos, de forma que cualquier combinacin de disparos que pueda darse en el futuro quede siempre recogida. el tipo de eventos que se disparan, los encargos, pueden ser de varios tipos. En ese caso, estarn tipificados mediante tablas de parmetros, de forma que aadir un nuevo tipo de encargo no signifique ms que darlo de alta como
56
evento y dar de alta las reglas que lo disparan, idealmente sin que ninguna funcionalidad ni cdigo se vean afectados.
Var 1 Valor 1
Var 2 Valor A Valor B Valor C
...
Var n Valor
Suceso Suceso 1 Suceso 1 Suceso 2 Suceso 2
Tipo Mensaje A Mensaje B Mensaje C Tipo x Tipo y --
Valor 2 Valor 3 Valor n Valor B Valor X Valor Valor
Suceso 2 Suceso s
Tabla 3 - Formalizacin de reglas de disparo
5.8.
Identificacin de acciones.
Las acciones son las decisiones posibles en cada momento sobre el expediente, en trminos de control de etapas. El hecho de que un expediente se modifique no forma parte de las acciones de etapas, sino de la vida normal del expediente. En muchos casos, como en el ejemplo, la decisin de la modificacin est fuera del control del sistema, como es la decisin del cliente. Las acciones sobre las etapas del proceso pueden ser de diferentes tipos.
5.8.1.
Acciones permanentes.
Son aquellas acciones que siempre deben ser posibles, porque son inevitables y propias del contexto. Por ejemplo, el abandono del proceso, en un proceso de comercializacin, es una opcin que el cliente siempre tiene a su disposicin. Es un error bastante comn el de pensar que esto no se produce o no se permite. Cuando el control ltimo del proceso est fuera, es necesario prever que esto puede ocurrir en todas las etapas, porque es necesario prever a priori el cmo deshacer la situacin del expediente en cada momento.
57
Tpicamente, las acciones posibles son: Abandono, que d lugar a la baja del expediente en el sistema y que, segn la situacin del expediente, lo lleve a Abandonos o Bajas. Escalar o desviar a un supervisor, cuando el usuario que lo est gestionando no tiene la posibilidad de tratarlo por cualquier razn. OK. Etapa o accin realizada. NOK. Etapa o accin no realizada. Esta accin, al igual que la anterior, debe estar disponible en la mayora bandejas de grupos de usuarios. En ambos casos, debe estar prevista la transicin por reglas de negocio. Es tambin posible que no est disponible en las bandejas de errores e incidencias.
5.8.2.
Acciones de transicin arbitraria.
Son aquellas acciones que pueden forzar la transicin de un estado a otro. Suelen estar disponibles en aquellos estados en los cuales el sistema no tienen recursos ni mecanismos para seguir evolucionando la situacin del expediente y que necesitan de una decisin arbitraria. Este es el caso de los estados de excepcin y suelen ser acciones reservadas a perfiles con mayores privilegios. Son necesarias en las bandejas de error e incidencias. Suelen estar presentes las acciones siguientes: Desviar a otro usuario, cuando sea necesario enviar un expediente a un usuario en particular para resolver una problemtica excepcional. Suele estar disponible para usuarios privilegiados. Dirigir a otra etapa. Esta accin solamente est disponible en etapas donde el sistema no tiene capacidad de tratamiento automtico. Es muy tpica de las bandejas de entrada.
5.8.3.
Acciones en las etapas automticas.
En las etapas de resolucin automtica, procesos masivos y colaborativos, solamente caben algunas acciones como las de abandono. Hay que estudiar con detalle el impacto de una accin en una etapa automtica por la posibilidad de que el expediente est en algn estadio intermedio.
58
El resumen es una tabla de de doble entrada con el formato siguiente:
Etapa Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa n Fin OK Abandono Bajas Etapas automticas Bandejas de entrada
Abandono
Escalar
Acciones posibles Desviar a otro OK NOK usuario segn perfil Etapa automtica
Enviar a otra etapa Etapa 2 Etapa 4
Inicio de proceso
Tabla 4 - Formalizacin de Acciones
5.9.
Definicin de perfiles.
Los perfiles que se dan en la organizacin van a afectar al uso del sistema en varios ejes que no tienen por qu reflejar la organizacin funcional de la empresa. Para tener todos los perfiles necesarios y slo esos, se debe hacer el anlisis siguiendo dos ejes: el del proceso (etapas y acciones), y el de los datos.
5.9.1.
-
Perfiles segn el proceso.

Las acciones permanentes a las que cada perfil tiene acceso, si existen restricciones. Las etapas que dan lugar a bandejas de entrada: cada una de ellas ser accesible a uno o varios perfiles, pero normalmente solo uno de ellos ser el encargado de realizar el trabajo.
Se trata de definir:
59
Bandejas de entrada Etapa 1 Etapa 2 Incidencias Errores
Perfil asignado Perfil 1 Perfil 2 Perfil 3 Perfil 4 Perfil n
Acciones posibles Desviar a Enviar a Enviar a Enviar a Etapa otro Etapa 1 Etapa 2 3 usuario
Tabla 5 - Asignacin de acciones y perfiles a bandejas de entrada
5.9.2.
-
Perfiles segn los datos.

Las limitaciones de acceso tienen determinados perfiles, tpicamente segn un criterio de asignacin o de pertenencia. Este es el caso en el que determinado perfil solamente puede ver aquello que est asignado a su grupo de usuarios, de acuerdo con un dato del expediente (restricciones geogrficas, por ejemplo).
Se trata de definir:
La informacin a la cual tiene acceso cada perfil siempre que accede a un expediente, y con qu privilegios (lectura, escritura, borrado, creacin). En este sentido, frente a la tentacin de restringir el acceso y dejar usuarios privilegiados que son los nicos que pueden, hay que reflexionar sobre el origen de la informacin. Cabe la posibilidad de que el perfil con menos privilegios tiene luego la mayor exposicin a modificaciones en la informacin, como es el caso de los operadores de Call Center, que son los que atienden al cliente directamente. En este caso, la restriccin de informacin para modificar no servira ms que para hacer esperar al cliente, sin ninguna aportacin de valor al proceso, ni tan siquiera de criterio, puesto que el cliente es el origen del cambio.
Este anlisis debe dar lugar a una tabla que se puede documentar con la granularidad que sea necesaria y que puede llegar al dato o a la entidad, segn lo que sea necesario para cada sistema:
60
Datos Perfil Perfil 1 Perfil 2 Perfil 3 Perfil n Entidad 1 LE B LE B LC Entidad 2 L L L Dato n LE L L LEC
LEC (L)ectura (E)scritura (C)reacin (B)orrado
Tabla 6 - Asignacin genrica de perfiles
Adems de esta asignacin, pueden darse excepciones en alguna transaccin en particular, en la que se modifique la asignacin general. Estas excepciones sern especficas y no quitan la utilidad global de la asignacin de privilegios a perfiles.
5.10. Evaluacin sistemtica.

El proceso se establece como un conjunto de etapas que configuran una clase de equivalencia de acuerdo a unas variables del expediente. Estas variables suelen tener un componente de tiempo o antigedad, lo que implica la necesidad de una reevaluacin sistemtica de los expedientes. Este tipo de procesos, por tanto, necesita de un proceso masivo de re-evaluacin de los expedientes vivos. Tpicamente, esta evaluacin peridica no afectar a los expedientes que estn en etapas intermedias de procesos colaborativos ni a aquellos que estn en etapas finales. S pueden afectar, sin embargo, a las bandejas de entrada, por lo que la periodicidad de la evaluacin debe tenerse en cuenta a la hora de tomar datos para el dimensionamiento de los equipos de trabajo.
5.11. Modificacin de los datos del expediente.

Esta metodologa aporta ms valor cuanto ms se aleja el proceso que se disea del proceso secuencial descrito en la introduccin, es decir cuanto ms modificable es un expediente a lo largo de su proceso.
61
Los expedientes estn ms sujetos a cambios cuando: el que inicia el expediente es un agente externo (cliente, por ejemplo) la capacidad de evitar la modificacin es pequea (el cliente es el dueo de la informacin y el expediente requiere de su aprobacin) el expediente se basa en informacin y no en realidades fsicas.
En estos casos, la transaccin de modificacin tiene que estar disponible en todo momento, puesto que la alternativa es la cancelacin de todo el expediente y la creacin de otro o la prdida del expediente sin ms. Es por tanto necesario que la modificacin sea lo menos restrictiva posible. Toda modificacin de los datos debe dar lugar a una reevaluacin del expediente segn las reglas de negocio, para verificar que se est en la etapa adecuada del proceso. Adems, hay que prever qu hacer en el caso que el expediente est en una etapa intermedia de un proceso colaborativo o automtico. Finalmente, es necesario tener en cuenta, en todas las etapas del proceso, el hecho de que un expediente puede estar pasando por ensima vez por ah, debido a cambios en la informacin. Esto debe estar controlado en las reglas de negocio para, por ejemplo, evitar repetir mensajes a un cliente o dar de alta dos veces una operacin en un sistema corporativo.
5.12. Verificacin del diseo.

Para verificar la bondad del diseo del proceso, se pueden contrastar los siguientes puntos: todas las transacciones son mdulos identificados en el DFD las peticiones que llegan al sistema se resuelven en un mximo de dos pasos, es decir se produce lo que se conoce como proceso directo o straight through processing. las bandejas de entrada obedecen a: o o o o errores e incidencias de difcil sistematizacin iteraciones para conseguir el xito del expediente (comercial) supervisin verificaciones cruzadas de otras reas del proceso.
62
si hay etapas intermedias de refrendo de una decisin, o etapas de supervisin, existe una justificacin de uno de los tipos siguientes: o o lmite en las potestades de un perfil, recogido en algn documento de compaa que lo exprese (verificacin de riesgos). aportacin de informacin que un perfil no tiene (ver la posibilidad de desplazar la decisin o la informacin, para eliminar la necesidad de etapa intermedia).
no existe ningn punto de salida manual que no quede recogido en bandejas del sistema.
63
Captulo 6.
El anlisis aplicado a un caso particular.
Este captulo pretende ilustrar con un caso prctico el encaminamiento que se ha descrito en el captulo anterior. Para ello, se va a estudiar un caso frecuente de la vida cotidiana, para que la parte del proceso sea familiar a cualquier lector, y lo vamos a desarrollar paso a paso tal como se ha indicado.
6.1.
La contratacin del seguro de coche: el proceso real.
Imaginemos el siguiente ejemplo de proceso: una compaa de seguros decide vender seguros de coche en Internet. Para ello, ha creado una pgina web en la cual se preguntan diversos datos del coche y del titular para dar un precio de acuerdo a cada caso particular. Si el cliente potencial decide comprar el seguro, puede hacerlo aunque se le comunica que debe quedar pendiente de la peritacin de su coche para verificar que todo est en orden. Una vez se haya hecho la peritacin y haya resultado satisfactoria, el perito se lo hace saber a la compaa de seguros que enva al cliente un dossier de presentacin de la compaa (Welcome Pack) con los documentos que necesita para el coche, la tarjeta de asistencia e incluso algn regalo debido a alguna campaa de captacin que est en curso en algn momento. El cliente recibe, dentro del Welcome Pack, instrucciones de firmar el contrato y remitirlo de vuelta a la compaa junto con una fotocopia del DNI, un recibo de su cuenta bancaria y la ficha tcnica del coche. A la recepcin de la documentacin, la compaa verifica que el contrato y la documentacin estn correctos. Los
64
expedientes as finalizados se archivan fsicamente en unas cajas de archivo definitivo donde deben guardarse al menos hasta 10 aos despus del vencimiento de la pliza, es decir, un plazo extremadamente largo durante el cual el documento fsico del contrato firmado se puede requerir si se discuten las coberturas del seguro en el caso particular de un siniestro (accidente o reclamacin).
6.2.
6.2.1.
La modelizacin DFD.
Diagrama de contexto
El diagrama de contexto ayuda a delimitar el mbito. Es de destacar la consideracin de entidades externas que tienen peritos, fulfillment y sistema corporativo de gestin de plizas, que permite la separacin clara del mbito de este anlisis, que solamente recoge la contratacin y no la gestin de lo que se contrata.
Cliente
> Datos del coche y del titular < Precio > Compra del seguro, datos de pago (Cuenta bancaria) < Instrucciones de firma.
> Datos de los Welcome Pack a imprimir y franquear < Datos de impresin y Fulfillment franqueo
DFD de contexto
Sistema de Correos
> Documentacin firmada
contratacin on-line de plizas de Seguro de Automvil

> Datos de las plizas listas para contratar < Fechas y datos definitivos de las plizas contratadas
Sistema Gestin Pliza Perito

< Datos del coches a peritar y datos de contacto de los titulares > Resultado de la peritacin
Figura 4 - DFD de contexto
65
6.2.2.
Diagrama de nivel 1
El diagrama de nivel 1 es la primera descomposicin funcional del sistema. En este caso, hay dos cosas extremadamente importantes que sealar. La primera es que se puede apreciar que toda la integracin se hace a travs de los datos y que no existe ninguna comunicacin entre procesos. Es decir, los datos debern tener suficiente informacin para que cada proceso, de forma independiente, lleve a cabo correctamente la transformacin de la informacin necesaria.
> Datos del coche y del titular < Precio > Compra del seguro, datos de pago (Cuenta bancaria) < Instrucciones de firma.
1
Web de contratacin
> Datos de los Welcome Pack a imprimir y franquear < Datos de impresin y franqueo
4
Envo de datos de WP
Cliente 6
Fulfillment
Envo de Mensajes
> Documentacin firmada
7 5
Recepcin de Documentos Solicitudes de Seguro Gestin de Incidencias
Correos
< Datos del coches a peritar y datos de contacto de los titulares > Resultado de la peritacin
2
Gestin de Peritaciones
3
Alta de plizas
> Datos de las plizas listas p contratar < Fechas y datos definitivos d las plizas contratadas
Sistema Gestin Pliza
Perito
Figura 5 - DFD de nivel 1

La segunda es destacar el proceso 7, de la gestin de incidencias. Tradicionalmente, se trata de algo que no se tiene en cuenta durante el anlisis de los sistemas cuando sin embargo es donde se esconde ms de la mitad de la complejidad. Incluso, puede hacer aparecer una nueva entidad externa, Call
66
Center, si es que la decisin de gestin fuera la de externalizar este tratamiento. En cualquier caso, ms adelante veremos que ste es un punto crucial del proceso. De hecho, pararemos aqu el anlisis a travs de DFDs, porque este nivel da una idea suficientemente clara de los componentes de la funcionalidad para el anlisis del flujo de control.
6.3.
El proceso secuencial
En el ejemplo que se ha definido de contratacin de seguros de coches, el proceso secuencial sera:
1. Peticin del cliente
2. Verificacin del coche
3. Alta del Seguro
4. Envo doctos
5. Recepcin Contrato
6. Archivo Fsico
A- Coche Sin verificar
B- Coches OK
C- Alta Plizas OK
D- Docum. Devuelta
E- Docum. Correcta
Procesos
Conjunto de entrada
Figura 6 - Proceso secuencial En el grfico, se han representado los procesos con cajas, mientras que los expedientes se reparten en los conjuntos de entrada a cada proceso, y que estn representados con los valos.
6.4.
Los errores.
Las verificaciones, tal como se da descrito, pueden tener como respuesta OK, NOK y error en el proceso. Los errores, salvo que tengan previsto un tratamiento
67
automtico, vuelven a ser bandejas de entrada para que usuarios, normalmente con un perfil relativamente alto, o incluso los administradores del sistema, puedan ver cul ha sido el problema y resolverlo, prcticamente al caso por caso.
3. Alta del Seguro
4. Envo doctos
6. Archivo Fsico
B- Coches OK B1- Coches NOK
C- Alta Plizas OK C1- Alta Plizas NOK
D- Docum. Devuelta D1- Docum. Pendiente
E- Docum. Correcta E1- Docum. Incorrecta
Figura 7 - Identificacin de errores
En este caso, vamos a representar tambin los errores, o solamente las incidencias, y a agruparlos: errores sin identificar, para los administradores del sistema (A2, C2) e incidencias que requieren accin por parte de las reas usuarias para reconducir el expediente (B2, D2 y E2).
3. Alta del Seguro
4. Envo doctos
6. Archivo Fsico
C- Alta Plizas OK C1- Alta Plizas NOK C2- Error en Alta Plizas
D- Docum. Devuelta D1- Docum. Pendiente D2- Error en envo
E- Docum. Correcta E1- Docum. Incorrecta E2- Error en recepcin
A2- Errores en peticin
B2- Error en verificacin
Figura 8 - Identificacin de incidencias
68
6.5.
La gestin de plazos.
Cuando un expediente lleve demasiado tiempo pendiente de peritar (5 das, para concretar un lmite en este caso), se deber gestionar. En este caso, se ha supuesto que se enviara un mail al cliente avisndole de un retraso en la peritacin. Se pueden dar dos casos diferenciados. Que el tratamiento que se realiza no afecte a la gestin del expediente, es decir, que se realiza una tarea pero la gestin del expediente no tiene ninguna diferencia antes o despus de esta reclamacin, la reclamacin es un proceso automtico sin intervencin con la gestin del expediente. Que el tratamiento d lugar a un cambio en la gestin: una tarea ms urgente o atendida por otro tipo de usuario. En ese caso, aparecera un conjunto de salida, A4, antes de la verificacin, que deber tener alguna diferencia con la descripcin de la etapa anterior. En el caso del proceso 2.1, la reclamacin no da lugar a un tratamiento diferenciado. Existe otro proceso de reclamacin identificado como 5.1. Tambin en ese caso se trata de un proceso que se da cuando haya pasado el lmite de tiempo definido, y tampoco da lugar a un tratamiento diferente. En este caso, es lo lgico, habida cuenta de que se trata de una etapa en la cual se espera una accin de un actor externo (el cliente) sobre el cual no se tiene autoridad y por tanto que no puede ser forzada. Este tipo de reclamaciones, que pueden ser ciclos de cierta complejidad (envo de SMS, al tiempo de un mail o una carta, o de una llamada), son muy habituales en este tipo de procesos. Es necesario prever las acciones a tomar en el lmite de estas situaciones. En el caso del proceso 5.1, cundo se espera la documentacin del cliente antes de abandonar la gestin? Y qu supone el abandono de esta gestin?
69
A3- Sin Ver. 2.1. Reclamacin hace mucho de la verif.
D3- Doc. Pdte 5.1. Reclamacin hace mucho del contrato.
3. Alta del Seguro
4. Envo doctos
6. Archivo Fsico
D- Docum. Devuelta D1- Docum. Pendiente - D3 D2- Error en envo
Figura 9 Gestin de plazos
Esta necesidad no estaba identificada en el diseo inicial. Existir una tarea 5.2, Baja del contrato, que se realizar cuando, despus de la reclamacin, an as no se reciba la documentacin, y consistir en el envo de una carta de baja para el cliente y una baja del seguro en los sistemas corporativos.
D3- Doc. Pdte hace mucho
5.1. Reclamacin del contrato.
3. Alta del Seguro
4. Envo doctos
6. Archivo Fsico
D- Docum. Devuelta D1- Docum. Pendiente - D3 D2- Error en envo
D4- Doc. Pdte para dar de baja
5.2. Baja del contrato.
Figura 10 Gestin de plazos y expedientes vencidos (bajas)
70
6.6.
La gestin de incidencias.
La gestin automtica de las incidencias que se haba identificado en el DFD de nivel 1 es una funcin que aporta mucha capacidad a los procesos de hacer seguimiento de situaciones con un coste bajo. Cuanto ms efectivo es este aspecto, mejor es el xito final del proceso. En este caso, como incidencias dentro del proceso se identifican las siguientes:
6.6.1.
Denegaciones y respuestas negativas.
Se tiene la necesidad de gestionar la respuesta NOK de los procesos. En este caso, por ejemplo, se puede decidir, de nuevo, enviar un mail al cliente potencial para comunicarle el resultado de la verificacin del coche y las razones por la cual el seguro no se contrata, o bien se puede optar por una llamada que intente reconducir el tipo de seguro de acuerdo a la recomendacin del perito (aadir una franquicia, por ejemplo, en caso de los coches demasiado antiguos). Se puede incluso decidir hacer ambas cosas, de acuerdo a la edad del posible titular, para favorecer la contratacin de seguros a personas de ms de 40 aos que se supone que son un tipo de conductor deseable dentro de los parmetros de gestin de riesgo de la entidad. Si se decidiera hacer as, apareceran dos gestiones diferenciadas y
complementarias de las verificaciones NOK, segn la edad del titular del seguro. Por una parte, la emisin de un mensaje mail de denegacin y, por otra, la emisin de una llamada para los gestores comerciales del call center. Existen en el proceso otra etapa de denegacin (C1) para la cual se deber realizar el mismo razonamiento que para B1. En este caso, vamos a simplificar el diseo de forma que no se den denegaciones en el proceso de Alta sino solamente errores de proceso.
6.6.2.
Problemas en el intercambio de informacin (documentacin).
Finalmente, existe otro tipo de error, correspondiente aqu al conjunto E1, cuando se recibe documentacin errnea. El diseo de esta etapa se asemeja mucho al razonamiento aplicado para B1, aunque con una dificultad aadida, que es el estadio intermedio que se produce cuando el proceso est a medias y no en uno de sus extremos. En estos casos, el ciclo de reclamaciones y mensajes para
71
completar la documentacin deber ser ms exhaustivo porque es un momento comercial ms delicado. Sin embargo, el diseo ser el mismo que para la etapa de denegacin B1, aunque sean ms oportunidades las que se le d al expediente. En ambos casos, habr que disear el ciclo de reclamacin hasta llegar a la baja del contrato (D4).
D3- Doc. Pdte hace mucho
5.1. Reclamacin del contrato.
3. Alta del Seguro
4. Envo doctos
6. Archivo Fsico
C- Alta Plizas OK
D- Docum. Devuelta D1- Docum. Pendiente - D3
E- Docum. Correcta E1- Docum. Incorrecta E2- Error en recepcin 6.1. SMS doc. incorr.
B2- Error en verificacin B11- NOK jvenes B12- NOK > 40 aos
C2- Error en Alta Plizas
D2- Error en envo
2.2. Mensaje D4- Doc. Pdte de baja para dar de baja 2.2. Llamada de rescate
5.2. Baja del contrato.
Figura 11 Gestin de incidencias
6.7.
La agrupacin de etapas.
Una vez identificadas las etapas, se agrupan segn sus caractersticas propias y clasificarlas de acuerdo a los diferentes modelos de procesos que se han descrito en el apartado 3.
6.7.1.
El inicio del proceso.
Es una transaccin web de contratacin, donde podemos suponer que se verificar, por ejemplo, que no se trata de un cliente existente ya que, si lo fuera, podra considerarse una modificacin y no requerira todo el proceso de alta.
72
6.7.2.
-
La entrada de informacin: recepcin de informacin.

la verificacin, que aportan los peritos a travs de un conjunto de transacciones (funcin 2 del DFD de nivel 1), la informacin de franqueo, que se recoge del proceso de impresin y la documentacin que remiten los clientes, que es un proceso masivo de entrada.
Los incrementos de informacin al proceso descrito se dan en:
Por lo tanto, como etapa de entrada de informacin est la recepcin de informacin, que se recogera en la funcin 5 del DFD de nivel 1.
6.7.3.
El final del proceso.
En este caso, toda la informacin de la que se habla es digital, salvo la documentacin firmada que potencialmente se recibe. Lo que se har entonces es, en la recepcin de la documentacin, asegurar que se archivan todos los documentos originales firmados por el cliente, por orden de llegada, y sin atender a que finalmente se contrate correctamente el seguro o no. El coste del archivo fsico es prcticamente irrelevante frente al coste de clasificar los documentos. Se verifica que el final de todos los expedientes est previsto y que todos los estados de espera tienen acotada su duracin.
6.7.4.
-
Las bandejas de entrada.

Errores administrativos A2 y C2 Errores con necesidades de gestin B2, D2 y E2. La verificacin de vehculos, proceso 2 Las llamadas de rescate, B12+2.2
Estarn en este caso las bandejas de entrada:
6.7.5.
Los procesos masivos
En nuestro ejemplo, se identifican los siguientes procesos masivos.
73
2.1. Reclamacin la verif. A3- Sin de Ver. hace mucho
5.1. Reclamacin contrato. D3- Doc. del Pdte hace mucho
Verificaciones
1. Peticin del cliente 2. Verificacin coche A-del Coche Sin verificar 3. Alta del Seguro B- Coches OK 4. Envo doctos C- Alta Plizas OK 5. Recepcin Contrato D- Docum. Devuelta 6. Archivo Fsico E- Docum. Correcta
Errores adm.
C2- Error en Alta Plizas A2- Errores en peticin
Errores con gestin

B2- Error en verificacin D2- Error en envo E2- Error en recepcin
D1- Docum. Pendiente - D3
6.1. SMS doc. incorr. E1- Docum. Incorrecta 5.2. Baja del contrato. D4- Doc. Pdte para dar de baja 2.2. Mensaje de baja B11- NOK jvenes
Llamadas de rescate
Entradas Bandejas Procesos 2.2. Llamada B12- NOKde rescate > 40 aos
Figura 12 - Identificacin de procesos
Dos de los procesos identificados corresponden al envo de SMS, y otro al envo de e-mail. Si nuestro proceso tiene estas capacidades, deberan poder ser invocadas en cualquier otro momento y por cualquier otra razn, simplemente porque se estime que es una mejor manera de dirigirse a un determinado colectivo. De hecho, tanto el nmero de los mensajes como su contenido o frecuencia son todas caractersticas que parecen arbitrarias y que, en cualquier caso, no van a alterar el curso de la gestin del expediente.
74
2.1. Reclamacin la verif. A3- Sin de Ver. hace mucho
5.1. Reclamacin contrato. D3- Doc. del Pdte hace mucho
Verificaciones
1. Peticin del cliente 2. Verificacin coche A-del Coche Sin verificar 3. Alta del Seguro B- Coches OK 4. Envo doctos C- Alta Plizas OK 5. Recepcin Contrato D- Docum. Devuelta
Envo de mails
6. Archivo Fsico E- Docum. Correcta
Errores adm.
Errores con gestin
D1- Docum. Envo B2- Error en de SMS Pendiente verificacin - D3 E2- Error en recepcin
6.1. SMS doc. incorr. E1- Docum. Incorrecta 5.2. Baja del contrato. D4- Doc. Pdte para dar de baja 2.2. Mensaje de baja B11- NOK jvenes
D2- Error en envo
Llamadas de rescate
2.2. Llamada B12- NOKde rescate > 40 aos
Procesos
Avances
Figura 13 - Clasificacin de procesos masivos
Estos procesos masivos, de envo de mensajes a travs de un tercero, aunque tengan un aspecto colaborativo real en cuanto a la gestin del envo y la recepcin correcta, no se tendrn en cuenta como procesos colaborativos, puesto que la resolucin de los conflictos y de los errores no tendrn relevancia del punto de vista funcional de la gestin del expediente sino que sern ms un problema tcnico. Por otra parte, se pueden identificar procesos en los cuales estos aspectos se mezclan. As, en nuestro ejemplo, se identifica el proceso B11+2.2, que es la emisin de un mensaje de baja a los jvenes cuya verificacin es No OK. Se da el caso aqu que se ha nombrado el proceso como Mensaje de Baja, pero si embargo est marcado como que supone un avance en la gestin del expediente, como de hecho es la baja del mismo antes de darlo de alta en el sistema
75
corporativo. Este es un caso en el que se puede confundir el hecho de la emisin de mensaje con la etapa en s. En realidad se trata de un proceso doble: por una parte, se da de baja aquellos casos en que una verificacin NOK se da para un titular/conductor de menos de 40 aos. Por otra, se emite un mail donde se le indica al cliente lo que ocurre. Es decir, que existe una baja automtica, que no una etapa adicional, y un mensaje comercial de aviso. El proceso 5.2 est en el mismo caso: por una parte, se da de baja aquellos casos en que la documentacin no ha llegado, lo que da lugar a una baja en el sistema corporativo porque se trata de una pliza que se ha dado de alta y por lo tanto que ha tenido formado parte realmente de la cartera de la compaa. Por otra, se emite un mensaje al cliente donde se le comunica la decisin.
En definitiva, se identifican como procesos masivos con avance de etapa: Alta de los contratos en la aplicacin corporativa 3 Baja de los contratos en la aplicacin corporativa 5.2
Y como procesos masivos sin avance de etapa: Generacin de mensajes para el cliente 7 Emisin de mails.
76
Por tanto, la identificacin de procesos masivos, con la agrupacin de capacidades, quedara as:
7 Creacin A3- Sin Verif. de mensajes hace mucho. B11-Verif. NOK jvenes D3- Doc. pdte hace mucho D4- Baja por doc. pdte. E1- Doc. Incorrecta
8. Emisin Mail
9. Emisin SMS
Verificaciones
1. Peticin del cliente 2. Verificacin coche A-del Coche Sin verificar 3. Alta del Seguro B- Coches OK 4. Envo doctos C- Alta Plizas OK 5. Recepcin Contrato D- Docum. Devuelta 6. Archivo Fsico E- Docum. Correcta
Errores adm.
Errores con gestin

B2- Error en verificacin D2- Error en envo E2- Error en recepcin
D1- Docum. Pendiente - D3 5.2. Baja del contrato. D4- Doc. Pdte para dar de baja
Llamadas de rescate
2.2. Llamada B12- NOKde rescate > 40 aos
Procesos
Avances
Figura 14 - Identificacin de capacidades
6.7.6.
Los procesos colaborativos
Se identifica como procesos colaborativos el envo de los contratos a un especialista para su impresin y franqueo C+4.
77
6.8.
El mapa de procesos.
El mapa completo de procesos, por lo tanto, quedara de la manera siguiente:
Solicitudes
7. Altas/Bajas en el Sistema corporativo
8. Envo de contratos al cliente
Documentacin de clientes
1. Errores 2. Incidencias
3. Verificaciones
5. Documentacin pendiente
9. Fin OK 10. Abandonos 11. Bajas
4. Llamadas de rescate
6. Documentacin Incorrecta
Reglas de estados
Bandeja Proceso masivo
Datos de los expedientes Generacin de mensajes Envo de mails Envo de SMS
Entrada
Figura 15 - Mapa completo de procesos
6.9.
Identificacin de reglas de transicin en el caso prctico.
La manera ms fcil es identificar primero las bandejas de trabajo y luego los intercambios de informacin con otros sistemas:
78
6.9.1.
Las entradas
Estas etapas no tienen realmente estado que las defina puesto que son eventos asncronos que son los que disparan la creacin o modificacin de la informacin de cada expediente.
6.9.2.
Errores de sistema
Deben estar en esta bandeja todos aquellos expedientes que en alguna de sus operaciones hayan dado un error atpico. Para esto, se puede utilizar un campo de error en el cual marcar todos los errores que se produzcan en casos en los cuales se trate de errores tcnicos o inesperados (fallos en los web-services de actualizacin del sistema corporativo, errores en el envo de los documentos, es decir lo que se ha descrito como A2 y C2). Es necesario por tanto crear un rea de informacin de error en el expediente con la informacin correspondiente al mdulo que lo produjo y el tipo de error que fue. Si este rea de informacin tiene contenido, estar en esta etapa.
6.9.3.
Incidencias
Deben estar en esta bandeja todos aquellos expedientes que en alguna de sus operaciones hayan dado un error de negocio, una incidencia. Esto requiere otro tipo de informacin en el cual marcar las incidencias y su razn. De no haber errores tcnicos, y existir alguna incidencia, estar en esta etapa. Actualmente, esta etapa se producir cuando: B2: Se produzca una incidencia en la verificacin (marcada por el perito) D2: Haya algn problema en el envo de la documentacin (marcado por la casa de impresin) E2: Haya algn problema en la recepcin de documentos.
6.9.4.
Verificaciones
Estarn en esta bandeja todos los expedientes que no tengan hecha la peritacin del coche y la necesiten. Deber existir la informacin: Verificacin requerida: no existe un circuito en el cual este dato se decida arbitrariamente por lo que cabe pensar que es resultado de una combinacin de valores del expediente. Fecha de verificacin Resultado de la verificacin.
79
La regla de llegada es: La combinacin de valores del expediente requiere verificacin La fecha de verificacin no tiene valor an.
6.9.5.
Llamadas de rescate
Esta bandeja de trabajo corresponde a la bandeja B12, en el ejemplo. La regla de llegada es: El titular tiene ms de 40 aos Se ha realizado la verificacin y es NOK
6.9.6.
Documentacin pendiente
No se trata de una bandeja de trabajo si no una etapa dentro del proceso en la cual solamente cabe la espera y, si as se decide, la intervencin al cabo de un cierto tiempo. La regla de esta etapa es: El expediente se ha franqueado No se ha recibido ninguna informacin.
6.9.7.
espera.
Documentacin incorrecta
Tampoco en este caso se trata de una bandeja de trabajo si no una etapa de
La regla de esta etapa es: Se ha recibido informacin del cliente La informacin recibida no es correcta.
Este es un ejemplo claro de la arbitrariedad de la organizacin de los procesos. La decisin de separar, para su monitorizacin y gestin, la documentacin pendiente de la documentacin incorrecta es una decisin que solamente corresponde con la necesidad de gestionar de forma diferente ambas bandejas, decisin que en cualquier momento puede deshacerse para ver todos los expedientes pendientes de cualquier documento como un solo conjunto.
80
6.9.8.
Altas/Bajas en el sistema corporativo
Este es un proceso de intercambio de informacin, que, para ilustrar mejor todos los tipos de procesos, se va a considerar solamente como proceso por lotes. Es decir, que en este caso se va a considerar que el interfaz utilizado para el intercambio de informacin va a ser un web service, por lo que el tiempo ser inmediato y por tanto no se tratar de un proceso colaborativo. Si el web service se puede ejecutar on-line cuando se necesite, por ejemplo en la misma recepcin de la verificacin, esta etapa no se tendra en cuenta como tal, porque ningn expediente podra de hecho estar en ella. Se utiliza el tratamiento de etapa en dos casos: cuando se trata de un proceso con intercambio de informacin no inmediato, pero tambin cuando se trata de un proceso por lotes que solamente se ejecuta de forma peridica, cada hora, por ejemplo, de forma que en realidad esta etapa ser la lista de entrada del proceso por lotes. En este caso, supondremos que se trata de un proceso diario que ocurre por la noche que es cuando se activa la recogida de informacin desde el sistema corporativo. La regla de esta etapa es: Para las altas: la verificacin es ok o no haca falta y no hay fecha de alta en los sistemas Para las bajas: la documentacin sigue sin estar ok y la fecha de alta es anterior a un mes y no hay an fecha de baja.
6.9.9.
Envo de contratos a clientes
Este es un proceso colaborativo que puede tardar varios das en completarse, desde que se enva a la empresa de impresin hasta que se recibe la fecha de franqueo. Aunque en este caso, para simplificar el ejemplo, no se va a desarrollar este aspecto, es crucial la gestin de las posibles modificaciones del expediente mientras est pendiente de impresin, en particular si lo que se imprime puede verse afectado por los cambios en el expediente. En ese caso, cabe la posibilidad de tener que crear un proceso paralelo para gestionar las diversas versiones de las comunicaciones al cliente. La regla de esta etapa es: Existe fecha de alta en los sistemas No existe fecha de envo a impresin.
81
6.9.10.
Resumen de reglas de transicin
Resumiendo las reglas identificadas, se puede construir una tabla de datos con la informacin requerida para el control del proceso
Variables directrices del proceso Error Edad del Fecha Estado F. Alta en Verificacin Impresin Recepcin Fecha alta Fecha baja sistema conductor recepcin document. sistemas 1 no existe ERR ERR ERR > (hoy - 60 Req das) no existe > 40 aos NOK <= 40 aos 0 no existe no existe existe no existe existe NOK NOK OK existe >= (hoy -30 das) < (hoy -30 das) existe existe no existe existe
F. baja en Fecha sistemas Abandono
Etapa resultante Error de sistema Incidencias Verificacin
no existe
No u OK
existe fecha
existe
Llamada de rescate Abandono Alta en los sistemas Envo de contratos Documentacin pendiente Documentacin incorrecta Baja en los sistemas Baja en los sistemas existe Baja en los sistemas no existe Fin OK existe Abandono Bajas
Valores posibles: Req (Requerido), No (No requerido), (OK) Verificacin realizada OK, (NOK) Verificacin realizada con salvedades, (ERR) Excepciones al proceso
Tabla 7 Caso prctico: reglas de transicin
6.10. Identificacin de reglas de disparo en el caso prctico.

Las reglas de disparo son aquellas que ponen en funcionamiento alguna de las capacidades del sistema pero que sin embargo no tienen por qu afectar a la situacin del expediente. En este ejemplo, es el caso de la creacin de mensajes, una capacidad que se debe poner en marcha en las condiciones que se han detallado. La evaluacin de cada expediente dar lugar al disparo de la creacin de mensajes. Es decir, que las reglas de disparo activarn siempre el suceso de creacin de
82
mensajes. Estos mensajes se crearn de acuerdo con el tipo de mensaje necesario en cada caso, siendo el tipo de mensaje el que determina todos los elementos que lo componen: el canal de envo (SMS, mail, carta etc.) el contenido del mensaje (personalizado con los datos del expediente) los destinatarios.
El conjunto de reglas de disparo es el siguiente:
Variables de disparo Edad del Fecha Estado F. Alta en F. baja en Fecha Error Tipo de mensaje Verificacin Impresin Fecha alta Fecha baja conductor recepcin document. sistemas sistemas Abandono sistema < (hoy - 15 A3: SMS de reclamacin de Req no existe das) verificacin NOK 0 no existe <= 40 aos no existe no existe B11: aviso de baja por mail no existe < (hoy -15 das) D3: mail de reclamacin No u OK existe fecha existe NOK E1: SMS de aviso Valores posibles: Req (Requerido), No (No requerido), (OK) Verificacin realizada OK, (NOK) Verificacin realizada con salvedades, (ERR) Excepciones al proceso
Tabla 8 Caso prctico: reglas de disparo
6.11. Identificacin de acciones.

De acuerdo con las posibles acciones en cada una de las etapas, la tabla de acciones queda como sigue:
Acciones posibles Desviar a otro NOK usuario Etapa automtica Etapa automtica
Etapa Error de sistema Incidencias Verificacin Llamada de rescate Alta en los sistemas Envo de contratos Documentacin pendiente Documentacin incorrecta Fin OK Abandono Bajas Etapas automticas Bandejas de entrada
Abandono
Escalar
OK
Enviar a otra etapa Todas las etapas Repetir etapa ant. solo supervisores
Inicio de proceso
Tabla 9 Caso prctico: Resumen de acciones
83
6.12. Definicin de perfiles.

En este ejemplo, se definen los perfiles de usuario siguientes: rea comercial, responsables de verificar y resolver resultados comerciales, excepciones, incidencias etc. Supervisores del rea comercial, responsables de la gestin del rea. rea de gestin de riesgos, responsables de establecer la estrategia de precios tcnicos y la poltica de verificacin de datos con documentos del cliente. Peritos, responsables de realizar las verificaciones Departamento de Operaciones, responsables de velar por el cumplimiento de los plazos y volmenes del proceso y de las interacciones con terceras partes Departamento de Sistemas, responsables de la infraestructura tcnica.
6.12.1.
Segn los datos
Segn los perfiles, se van a establecer los privilegios a nivel de entidad de datos, que vamos a simplificar a 3: expediente persona vehculo.
La asignacin de derechos de acceso, a nivel de entidad, queda como sigue:

Datos Personas LEC LECB L L LECB L
Perfil rea comercial - operadores rea comercial - supervisores gestin de riesgos peritos operaciones sistemas
Expedientes LEC LECB L L LECB L
Coches LEC LECB L LE LECB L
(L)ectura (E)scritura (C)reacin (B)orrado
Tabla 10 Caso prctico: Asignacin de perfiles
6.12.2.
Segn el proceso
Tal como se describe el proceso, las acciones en las diversas etapas se pueden resumir con la siguiente tabla:
84
Etapa Error de sistema Incidencias Verificacin Llamada de rescate
Perfil asignado Sistemas Operaciones Area com. Supervisores Peritos Operaciones Area com. Supervisores
Escalar
OK
Acciones posibles Desviar a otro NOK Enviar a usuario abandono Cualquiera abandono Area com. Error de sistema abandono Operaciones Error de sistema Incidencias
Incidencias
La accin de OK siempre da lugar a una re-evaluacin del estado del expediente.
Tabla 11 Caso prctico: Asignacin de acciones a bandejas de entrada
6.13. Modificacin de los datos del expediente.

En este caso se verifica la premisa de que, en cualquier momento, el cliente puede llamar o conectarse al site y cambiar todos los datos del expediente que quiera, y que pueden resumirse en las 3 entidades que se tienen identificadas y que son las que se reflejan en la asignacin de derechos de acceso por perfil. El objetivo de este ejercicio es garantizar que la estructura de control soporta adecuadamente los cambios que se hubieran podido concretar.
6.13.1.
Modificacin de las caractersticas del seguro.
Si un cliente llamara a modificar las caractersticas del seguro (hacerlo a Todo Riesgo en lugar de A Terceros, por ejemplo), el proceso solamente se ver afectado si ya se ha dado de alta. En ese caso, el sistema deber: Quitar la fecha de alta para volver a dar de alta en la aplicacin. Esto implica que las altas de la aplicacin tienen que tener en cuenta si el tratamiento es distinto para alta que para modificacin. Modificar las reglas del proceso masivo del paquete de envo para controlar que se trata de una comunicacin subsiguiente y por lo tanto modificar seguramente el paquete de envo, de forma que no sea el mismo paquete de bienvenida, sino una comunicacin de lo que ha ocurrido (Modificacin del proceso colaborativo para incluir al menos el dato).
85
6.13.2.
-
Modificacin de las caractersticas de la persona.

Tener en cuenta, de nuevo en el alta y en el paquete de envo, que se puede tratar de una segunda vez. En las llamadas de rescate, se puede pensar qu hacer si la misma persona da lugar a varios ciclos de rescate, por si puede ser un indicador de posible fraude y por lo tanto se abandonan.
Las modificaciones de la persona requieren:
En las reglas de disparo de los mensajes de reclamacin de documentacin, habr que tener en cuenta si se quieren establecer mensajes diferentes para solicitudes modificadas, no repitiendo lo que fuera en mensajes anteriores
6.13.3.
Modificacin de las caractersticas del coche.
Las modificaciones del coche requieren tener en cuenta lo mismo que para los cambios en la solicitud.
86
Captulo 7.
La arquitectura tcnica.
En este captulo se mencionan posibles componentes de software que hay en el mercado para dar soporte al tipo de sistemas que hemos descrito. Cuando hay que decidir entre utilizar un componente externo, ya existente, o abordar y gestionar un proceso interno de desarrollo de software, tiene cada vez ms peso la idea de que el recurso interno es escaso y tiene una capacidad de produccin limitada y con poca flexibilidad. Debido a este criterio, un gran nmero de compaas, incluso se podra decir que la mayora de las compaas muy grandes o cotizadas, prefieren de forma sistemtica el software que se puede comprar frente a lo que se puede construir y as lo explicitan en su estrategia de sistemas. Es cierto tambin que, actualmente, todos los departamentos de desarrollo interno de las compaas tienen carteras de peticiones que van desde uno a varios aos y parece ser algo endmico en la informtica corporativa. La plataforma de sistema en la cual establecer esta metodologa de procesos tiene que poder soportar los aspectos que se han descrito de apertura al mundo externo, de capacidad de separar reglas de negocio y otros procesos, capacidad por lo tanto de gestionarlas etc. Asumiendo que la mayor parte de las organizaciones van a preferir comprar que desarrollar, se ha querido revisar algunos de los componentes necesarios que se pueden encontrar ya en el mercado. En particular, dentro de la arquitectura que se ha mencionado, existen algunas funcionalidades muy especficas y poco afectadas por la rama de la industria a la que el sistema debe dar servicio. Esto permite pensar que la utilizacin de herramientas de
87
mercado sea posible sin grandes adaptaciones y, por lo tanto, que son funcionalidades donde la aportacin del desarrollo interno no tiene tanto valor. Este es el caso de la gestin de las reglas de negocio y del disparo de eventos. Finalmente, es necesario detenerse brevemente en los aspectos de la arquitectura de sistemas que permiten implantar con mayor seguridad y menos costes metodologas como la que se ha presentado.
7.1.
El gestor de reglas de negocio.
Las reglas de negocio son equivalentes a las condiciones clsicas en los lenguajes de programacin. Lo que esta metodologa promueve, sin embargo, es la separacin real entre estas reglas de comportamiento del sistema y los mtodos de comportamiento del propio sistema de forma que la regla no est nunca embebida en el cdigo. Esta idea es muy atractiva a la luz de lo que tradicionalmente da lugar a problemas en el desarrollo de software y entre lo que cabe mencionar aspectos como: La falta de entendimiento de los receptores y usuarios del software que da lugar a funcionamientos indeseados por una parte y dados por buena por otra. La dificultad inherente a los cambios de versiones del software, por la inestabilidad que puede introducir en los sistemas. La falta de disponibilidad rpida de los equipos de desarrollo para cambios pequeos en los umbrales de funcionamiento. La escasa trazabilidad real de los cambios en el software clsico.
Si se acepta la premisa de que es mejor separar la lgica del cdigo, la siguiente pregunta es cmo mantener de forma independiente una estructura de informacin tan particular como puedan ser las reglas de negocio. Para ellos, existen herramientas en el mercado de gestin de reglas, como Ilog Jrules, actualmente de IBM. Frente a la impresin que se puede tener de que un conjunto de reglas no necesita realmente un mantenimiento, es necesario detenerse a pensar en la trazabilidad y mantenibilidad de un sistema de 5 aos, por ejemplo. No parece que la tecnologa est dando grandes cambios estructurales como en los aos 90 y por tanto cabe
88
pensar que la mayor parte de los sistemas que conocemos seguirn en vigor dentro de unos aos, seguramente con evoluciones muy interesantes en el lado del interfaz de usuarios, pero mucho menores en cuanto al sistema de informacin en s. Esto quiere decir que el sistema que se disea va a tener mltiples cambios que habr que identificar, documentar y controlar para saber cosas tan esenciales como saber qu est en produccin, desde cundo y por qu. Para gestionar realmente este aspecto, es necesaria una herramienta ms all de los actuales gestores de cdigo. Volviendo a Ilog como ejemplo de lo que debe aportar un gestor de reglas de negocio, las funcionalidades principales de un gestor de reglas son: Capacidad de edicin de las reglas en un meta-lenguaje ms cercano al lenguaje natural Capacidad para secuenciar paquetes de reglas Capacidad para establecer caminos alternativos de validacin Posibilidad de utilizacin de herramientas ms intuitivas como las tablas de valores Capacidad para depurar y verificar los paquetes de reglas resultantes en tiempos de edicin Posibilidad de organizar la puesta en produccin de forma que quede traza, y posibilidad de reconstruir en cualquier momento el repositorio de reglas que se utiliz en un momento dado. Finalmente, es posible que el usuario que tenga el conocimiento ms profundo del sistema, y por lo tanto el perfil ms tcnico, sea capaz de editar y probar sus propias reglas. Si est suficientemente enmarcado como para no resultar un factor de inestabilidad, esta autonoma en el rea usuaria aportara una mayor flexibilidad real de los sistemas y, no menos importante, una importante mejora en la satisfaccin de los usuarios.
7.2.
El disparo de eventos.
Igual que en el caso de las reglas de negocio, el disparo de eventos como un envo de mails o de SMSs no parece algo difcil de hacer y no parece necesario tener grandes subsistemas que lo gestionen. Sin embargo, en el caso particular de las comunicaciones con clientes, se han visto grandes inversiones en los sistemas de gestin de relacin de clientes, llamados CRM (Customer Relationship Management),
89
como puedan ser Siebel, Oracle etc. Es precisamente el control de estas comunicaciones con el cliente el que ha estado con frecuencia en el origen del proyecto. Antes de los aos 90, de hecho, ni siquiera caba pensar en gestionar las relaciones con el cliente, puesto que ste estaba enmarcado en un agente o director de oficina y era prcticamente cierto que con el cliente solamente hablaba un interlocutor en cada organizacin, o sobre todo uno, encargado de su seguimiento comercial. Esa visin sencilla no puede ser cierta hoy en da, porque ahora el cliente tiene, adems de ese interlocutor, mltiples canales a travs de los cuales se puede dirigir o ser servido por su proveedor. Los clientes, sobre todo los ms jvenes, trabajan con toda naturalidad en este mundo conectado y, por si fuera poco, este mundo conectado permite que los clientes sean mucho ms accesibles a otras compaas. En definitiva, es un mundo mucho ms complejo y mucho ms intenso en comunicaciones que, sin embargo, deben seguir siendo pertinentes, fiables, precisas y rpidas. Gestionar la comunicacin es generalmente tan complejo que se requiere de una herramienta que permita asegurar la coordinacin de todos estos flujos. Existen una serie de herramientas, que forman parte de la familia de los sistemas CRM, pero que son especialistas en gestionar campaas. Estas campaas se disparan cuando se cumplen una serie de condiciones. Las comunicaciones pueden pensarse como campaas, comerciales pero tambin operativas o de servicio, que dan lugar a mensajes que se envan por el canal que se encuentre ms adecuado. El inters de estas herramientas es que permiten centralizar todo el flujo entrante y saliente de comunicaciones, asegurando en lo posible su coordinacin. Tambin tienen herramientas de monitorizacin y seguimiento de xito. Este es el caso de herramientas como Epiphany o SAS que, si existen en el sistema corporativo que se pretende, se pueden utilizar como las capacidades que se describen en los apartados anteriores.
90
7.3.
Arquitectura de sistemas.
Se han mencionado con cierto detalle dos ejemplos de utilidades para las que conviene reflejar las herramientas que se pueden encontrar en el mercado. Lo interesante, sin embargo, es que la utilizacin de cualquier herramienta estara completamente circunscrita a una utilidad y bsicamente no variara el diseo sino la realizacin de uno de los puntos. Esta estratificacin del diseo, separando y aislando en lo posible componentes, es lo que va a permitir la mantenibilidad y la evolucin del sistema, porque se podrn ir incorporando utilidades segn vayan apareciendo en el mercado, limitando el tamao de los proyectos de migracin de tecnologa, que desde el punto de vista de las organizaciones son como ir de un punto al mismo punto jugndose la vida en el camino. Es necesario mencionar muy particularmente un aspecto de estratificacin en el que esta metodologa no entra tanto y que es el que afecta a la funcionalidad del sistema. La correcta estratificacin de las funciones del sistema, separando los datos, de las funciones, de la presentacin, es crucial en cuanto a facilitar y permitir la evolucin del sistema y la incorporacin de nuevas funcionalidades a lo largo del tiempo.
91
Captulo 8.
Conclusiones.
Esta metodologa de trabajo es el fruto de aos de experiencia en el diseo de sistemas cuya parte ms difcil es la gestin de las secuencias de los procesos, de las incidencias y del volumen. En los sistemas financieros y, en particular, en el negocio de particulares, la industrializacin es una necesidad sin la cual no se puede ser competitivo y el cambio del entorno es una constante. Las nuevas maneras de comprar y de operar que todos nosotros desarrollamos como clientes imponen a nuestros proveedores, de cualquier sector, la necesidad de desarrollar capacidades de respuesta muy diferentes a las que estaban en vigor hasta hace unos aos. Sin embargo, el gran cambio no solamente es que las cosas son muy diferentes ahora sino que van a seguir cambiando a la misma velocidad o ms y la manera de disear sistemas debe enfocarse en la variacin no como una realidad incmoda sino como un factor de supervivencia. El diseo de sistemas corporativos, actualmente, debera dejar de centrarse en la industria interna. Por poner un ejemplo, los bancos se soportan con una centena de sistemas que ya recogen bsicamente toda la necesidad operativa del banco. La diferencia ahora est ya mucho ms en la capacidad de utilizar capacidades externas mejores, en la posibilidad de utilizar lo que est disponible en web, en la evolucin que no dependa del movimiento interno, sino en la conjuncin de lo que ocurre en el mundo.
Esta metodologa est enfocada precisamente a eso: a mantener un esquema muy simple de interconexin que permita que cualquier utilidad, cualquier mejora, cualquier
92
cosa pueda encajarse rpidamente sin afectar al resto del diseo. Se trata de utilizar estndares de mercado de interconexin y de mantener encapsuladas las cosas homogneas como las decisiones de negocio frente a la lgica de presentacin, de forma que la capacidad de cambio provenga de la adecuada concentracin de funcionalidad.
8.1.
Implantacin de la metodologa propuesta.
La manera ms rpida de implantar esta metodologa es basndose en 3 premisas: Escoger un proceso de negocio, de inicio a fin. Utilizar el sistema existente como una caja negra con la cual interactuar sin interferir, es decir, completando sus carencias ms que mejorando su funcionalidad. Ser muy estricto en: del sistema. Empezar lo antes posible la produccin real con un proyecto piloto y prever revisiones frecuentes de la funcionalidad. Despus de uno o, como mximo, dos procesos en produccin es necesario establecer mecanismos de control que permitan asegurar: La adecuacin de los procesos que se crean al esquema descrito, en particular en lo que atae a secuencialidad y encapsulamiento de funciones, La utilizacin de los aspectos formales de la metodologa como herramientas de documentacin, La reutilizacin de las capacidades instaladas en todos los procesos, La gestin de las reglas de negocio, La no secuencialidad del sistema El encapsulamiento de funciones
Que como hemos visto es lo que va a redundar en la estabilidad y mantenibilidad
de forma que se mantengan los beneficios del enfoque.
8.2.
Ventajas de la utilizacin de la metodologa, un caso real.
Lelo (www.leelo.es) es una empresa que naci en 2005 precisamente con la idea de externalizar procesos y dar el servicio utilizando un sistema construido de acuerdo
93
con esta metodologa. Cada nuevo cliente o cada nuevo proceso dentro de un cliente, da lugar a un estudio con un nuevo mapa de procesos. Lelo, en ese caso, es una empresa que da el servicio que debieran dar los Departamentos de Operaciones e Informtica. Los beneficios que se obtienen por esta utilizacin son tanto internos al proceso (reas responsables como los Departamentos de Operaciones o Tecnologa) como externos al mismo (el cliente y los proveedores).
8.2.1.
Beneficios obtenidos en el mbito interno.
Para Lelo y su cliente, o lo que es lo mismo, el desarrollador y sus usuarios, las ventajas fundamentales son: La creacin de unas herramientas comunes para describir procesos: cambiar un relato por un mapa con tablas de transicin es mucho ms preciso y ms til a la hora de comprender un proceso completo. La aportacin de un anlisis de errores y resultados imprevistos antes de que se produzcan en produccin y se genere una avalancha de cambios a un sistema recin construido. Una enorme flexibilidad, contrastable, para atender los cambios de la vida diaria. Una posibilidad de monitorizar los procesos de inicio a fin y de ver dnde puede haber estancamientos o estrangulamientos. La posibilidad de general incidencias de una manera activa y monitorizable, por la capacidad de ver qu les ha ocurrido a los expedientes, en qu etapa se hayan y porqu. Adems existen otras ventajas ms tecnolgicas: la capacidad de modificar el proceso con rapidez y con una dependencia menor de Tecnologa, la capacidad de incorporar al sistema nuevas herramientas o nuevos modos de hacer con mayor velocidad, la disminucin de pasos de cdigo a produccin, cuando se es uno de los mayores factores de inestabilidad en los sistemas.
94
8.2.2.
Beneficios obtenidos en el mbito externo.
Para el cliente de Lelo, sus clientes y sus proveedores, las ventajas fundamentales son: La capacidad de gestionar fracasos del proceso mediante la utilizacin intensiva de comunicaciones. La capacidad de gestionar excepciones y de acortar los tiempos totales del proceso. La capacidad de dar un mejor servicio mediante la absorcin de cambios en el entorno competitivo o tecnolgico. La capacidad de gestionar proveedores de una forma ms desatendida, facilitando la incorporacin de nuevos proveedores, y por lo tanto reduciendo costes. Cuatro aos despus, sigue siendo sorprendente la satisfaccin que se genera en el usuario/cliente. Ellos identifican las siguientes diferencias frente al desarrollo tradicional: Tienen una manera intuitiva de razonar a propsito de un proceso. La gestin de reglas de negocio es algo que comprenden bien y que mejora tanto su sensacin de control como de autogestin. Obtienen una sensacin de control y una flexibilidad real a partir de la reglas de negocio, incluso con cierta capacidad de autoservicio. Pero, sobre todo, adems, evita dos aspectos que siempre son muy difciles de aceptar y gestionar en el desarrollo tradicional: Se evitan esas reuniones alrededor del anlisis funcional tradicional, las primeras en las cuales hay que enfrentarse a una hoja en blanco y empezar a escribir, y las finales en las que se comprometen con una funcionalidad descrita en papel y que no puede evolucionar durante los prximos n meses. El desarrollo es mucho ms rpido y, mejor an, se utilizan tcnicas de prototipado que permiten ver el proceso en etapas muy tempranas y hacerlo evolucionar ms adelante.
95
8.3.
Puntos crticos de la utilizacin de la metodologa.
En la experiencia que se ha vivido con proyectos basados en esta metodologa de diseo se ha observado que se producen dos fenmenos, muy poco tecnolgicos pero muy reales, que hay que gestionar.
8.3.1.
El enfoque secuencial.
Todas las personas entienden el orden secuencial. Es la forma en la cual las personas se comunican las cosas desde siempre y resulta muy familiar y fcil. Sin embargo, en el momento de la introduccin de la idea de que los procesos no son secuenciales en s y que por tanto la gestin del proceso no debe serlo, es muy frecuente encontrar grandes resistencias que pueden llegar a la oposicin frontal. Es la razn por la cual el mapa de procesos da una ilusin grfica de secuencialidad, de forma que todo el mundo pueda comprenderlo, aunque no tanto el porqu se comportar como lo estamos diseando. Es curioso que, incluso en los perfiles tcnicos, incluso en profesionales que comprenden el objetivo que se pretende y la base del razonamiento, es muy difcil que, al menos la primera vez, las reglas de transicin no tengan elementos de secuencialidad como por ejemplo: si estoy en la etapa A y pulsan OK entonces paso a la etapa B. No parece nada fcil de interiorizar que una mquina de estados no funciona as y que el mundo se ha podido mover de tal forma, entre que el expediente lleg a la etapa A y se ha pulsado OK, que es absurdo pensar que se sabe dnde va a ir este expediente y cmo va a evolucionar. Sin embargo, la no-secuencialidad es un punto completamente crucial para la evolucin del sistema, por ejemplo, para aadir una nueva etapa en el medio. Por lo tanto, este es un aspecto que hay que seguir en los primeros proyectos de cada profesional.
8.3.2.
El rechazo a la imperfeccin.
Cuando una persona, sobre todo alguien con responsabilidad comercial, est diseando el proceso, las etapas de la gestin de las incidencias resulta muy difcil. Ms que porque suponga un trabajo arduo, es difcil porque desata reacciones de hostilidad. En ese caso, es mejor concentrarse en identificar los criterios segn los cuales se podrn gestionar las incidencias y dejarlas resumidas inicialmente en una
96
bandeja de entrada para un rea de control. Siempre se estar a tiempo, con el sistema en produccin, de modificar el flujo real.
8.4.
Evolucin.
Toda la tecnologa y el negocio que rodean Internet, y que dieron tanto que hablar alrededor del 2.000, estn en realidad empezando ahora a transformar realmente el mundo el mundo corporativo, en una revolucin silenciosa su libro The big switch. Es lgico pensar que, debido a su infinita disponibilidad, las telecomunicaciones van a ir desapareciendo de nuestro mapa mental igual que en su da lo ha hecho la luz o el agua. Sin embargo, con una posibilidad de comunicacin infinita, desaparece la distancia real entre nosotros, nuestro sistema, nuestra empresa, y el resto de cosas disponibles en el exterior. Tambin es lgico pensar que los mejores tcnicos y el mejor sofware est en el exterior de las compaas. Si las telecomunicaciones no son un problema, lo lgico parece utilizar ese software en vez de instalarlo internamente, sustituyendo un proyecto de inversin y riesgo por un coste variable sin ms. Este es el movimiento llamado Software como servicio (SaaS Software as a Service) que est creciendo ms que el software tradicional. Con ambas ideas, se me ocurre que lo que habr que buscar en la informtica corporativa es la capacidad de utilizar, combinar y poner en marcha toda esa potencia externa para articularla como mejor nos sirva. Esta metodologa debera permitirlo. a la que estamos asistiendo sin darnos del todo cuenta. Esta es la tesis que defiende Nicholas Carr en
97
Captulo 9.
Glosario de trminos.
ACD (Automatic Call Dispatcher): Centralitas inteligentes, fabricadas por Alcatel, Avaya, Cisco, que son capaces de gestionar grandes cantidades de lneas, de cualquier tecnologa, y despachar las llamadas a los agentes conectados, fsicos o automticos. Se puede conectar con los sistemas internos de forma que el dispatching tenga en cuenta criterios fijados por los usuarios segn el nmero marcado, tiempo de espera, tipo de cliente etc. Aplicacin: Conjunto de funcionalidades alrededor de un proceso de negocio. Arquitectura: Estructura de integracin que soporta todos los elementos de las aplicaciones y define y soporta cmo interactan. Bandeja de trabajo: Modo de entrada de los usuarios a las aplicaciones de gestin de flujos y que les ofrece tareas a los cuales estn asignados y, dentro de cada tarea, expedientes para los cuales las tengan que realizar. El trmino es una analoga con las bandejas de entrada del mail. BPM (Business Process Management): Tcnicas de descripcin de procesos como un flujo de trabajo con tareas, decisiones y perfiles responsables por tareas. El encadenamiento entre tareas es secuencial.
98
Existen paquetes de software muy relevantes en este terreno como FileNet, de IBM u Oracle. Call Center (Centro de atencin de llamadas): Es una organizacin, interna o externa, en la que un gran nmero de agentes atienden llamadas, normalmente a travs de un ACD. Chequeo y rearranque (Checkpoint-restart): Tcnica de control, utilizada en los procesos por lotes, que consiste en hacer un punto de control (checkpoint) cada n operaciones de forma que se liberen recursos, se asegure el cumplimiento parcial del proceso y se pueda minimizar la repeticin de trabajo en caso de problemas. Computacin en nube (Cloud computingt): Segn el IEEE Computer Society, es un paradigma en el que la informacin se almacena de manera permanente en servidores en Internet y se enva a cachs temporales de cliente, lo que incluye equipos de sobremesa, centros de ocio, porttiles, etc. Se concreta en una oferta de servicios de computacin a travs de Internet, de modo que el usuario final accede a los servicios sin preocuparse de qu son ni de cmo se generan. Diagrama de flujo de datos (DFD, Data Flow Diagram): Es una representacin grfica del "flujo" de datos a travs de un sistema de informacin. Los diagramas de flujo de datos fueron desarrollados por Larry Constantine y Michael Yourdon en los aos 70. Entidad/Relacin (E/R). El Modelo Entidad-Relacin es un concepto de modelado para bases de datos desarrollado por Peter Chen en los aos 70. Se detallan las entidades, que tienen unos atributos, datos, y estn vinculadas mediante relaciones. Mash-up: Se describe as a cualquier funcionalidad (incluso, ltimamente, msica) que se presenta como mezcla de otras funcionalidades recogidas de Internet, como por ejemplo, los portales inmobiliarios cuando muestran Google Maps.
99
Off-shoring: Se llama as al desplazamiento de reas productivas de una compaa hacia pases con menores costes. Pooling (de recursos): Puesta en comn de la capacidad de recursos equivalentes para su utilizacin mediante colas de acceso. Este mtodo supone normalmente una optimizacin de la capacidad por que se evita la ineficiencia y la rigidez de la asignacin individual. Proceso colaborativo: Actividad en la cual se coordinan varios agentes y en la que cada uno aporta su especializacin. STP (Straight-through Processing): Concepto segn el cual todo un proceso puede llevarse a cabo directamente, de forma electrnica, sin necesidad de reentradas ni de intervenciones manuales. Sistema (ver aplicacin). Transaccin: Unidad de mnima funcionalidad del punto de vista del usuario, que se llevar a cabo utilizando uno o varios programas. Workflow: Sistema que automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecucin del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportacin de las herramientas necesarias para gestionarlo.
100
Captulo 10.
Bibliografa.
Autor CARR, Nicholas YOURDON, Edward
Ao de publicacin 2008 1979
Ttulo completo The Big Switch: Rewiring the World, from Edison to Google Structured Design: Fundamentals of a Discipline of
CONSTANTINE, Larry CHEN, Peter P. 1991
Computer Program and Systems Design The entity-relationship approach to logical database design
Textos legales Basilea II Comit de supervisin bancaria de Basilea: Convergencia Internacional de Medidas y Normas de Capital (Junio 2006) Ley 56/2007, de 28/12/2007 de Medidas de Impulso de la Sociedad de la Informacin.
101

Metodología de Procesos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodología de Procesos

Cargado por

Copyright:

Formatos disponibles

Metodologa de definicin de procesos

Proyecto Fin de Carrera

Presentado por: Director:

UNIVERSIDAD POLITCNICA DE MADRID

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Objetivo del proyecto. Estructura. LA SITUACIN ACTUAL DE LA TECNOLOGA CORPORATIVA.

CAPTULO 3. 3.1. 3.2. 3.3.

Introduccin. Flujo de trabajo vs. mquina de estados. Premisas.

Metodologa de definicin de procesos

CAPTULO 5. 5.1. 5.2. 5.3. 5.4.

METODOLOGA DE ANLISIS DE PROCESOS.

El proceso secuencial. Identificacin de resultados imprevistos. Gestin de plazos. Gestin de incidencias.

La contratacin del seguro de coche: el proceso real.

Metodologa de definicin de procesos

Identificacin de reglas de disparo en el caso prctico. Identificacin de acciones.

El gestor de reglas de negocio. El disparo de eventos. Arquitectura de sistemas. CONCLUSIONES.

Implantacin de la metodologa propuesta.

CAPTULO 9. CAPTULO 10.

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Objetivo del proyecto.

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

La utilizacin de los sistemas de informacin corporativos

La universalidad de la informacin soportada por sistemas.

Metodologa de definicin de procesos

La gestin del riesgo operativo.

Metodologa de definicin de procesos

Metodologa de definicin de procesos

El impacto en las aplicaciones y sistemas corporativos.

Metodologa de definicin de procesos

Metodologa de definicin de procesos

El impacto en los procesos de desarrollos de aplicaciones.

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Metodologa de definicin de procesos

Flujo de trabajo vs. mquina de estados.

Metodologa de definicin de procesos

Esta metodologa parte por lo tanto de la siguiente premisa:

La modelizacin con DFDs.

Metodologa de definicin de procesos

Se definen solo 3 tipos de elementos:

Metodologa de definicin de procesos

Metodologa de definicin de procesos

> Peticiones y datos, pagos < contratos, liquidaciones,facturas

Cias. < Trabajos a realizar, pagos Subcontr. > Resultados, facturas

Figura 1 - DFD genrico de contexto

Metodologa de definicin de procesos

> Peticiones y datos, pagos < contratos, liquidaciones,facturas

< Informacin obligatoria > Normativa

Cias. < Trabajos a realizar, pagos Subcontr. > Resultados, facturas

Figura 2 - DFD genrico de nivel 1

Metodologa de definicin de procesos

Las carencias de la tcnica de DFD

Metodologa de definicin de procesos

La funcionalidad originada por los datos.