Estrategia de integración y su implementación en un ambiente de sistemas legados

Texto completo

(1)Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey. Escuela de Ingeniería y Ciencias. Estrategia de integración y su implementación en un ambiente de sistemas legados Proyecto presentado por. Luis Bernardo Oropeza Hernández sometido a la Escuela de Ingeniería y Ciencias como un requisito parcial para obtener el grado académico de Maestro en Administración de Tecnologías de Información. Monterrey Nuevo León, 27 de Abril de 2018.

(2) ii.

(3) iii.

(4) Dedicatoria Dedico este proyecto a mi esposa e hija las cuales son el motor de mi vida y me dieron fuerzas para concluir este gran logro, y a mis padres que me animaron para iniciar esta aventura.. iv.

(5) Reconocimientos Agradezco al Tecnológico de Monterrey el llevar a cabo este proyecto y poder juntos lograr la eficiencia de procesos de negocio. Principalmente al departamento de Tesorería y Pagos el cual me apoyó con la información necesaria, y al departamento de Desarrollo de Servicios de Integración por invitarme a participar en este proyecto permitiéndome utilizar sus herramientas con el único fin de aprender las nuevas tecnologías, compartiendo así el compromiso por mejorar los procesos de la institución. Agradezco a su vez a mi asesor y mis sinodales que me han estado apoyado durante este proceso con su confianza, conocimientos, experiencias, tiempo y comprensión siendo un ejemplo para mí, mismos que me permitieron cumplir el objetivo deseado.. v.

(6) Estrategia de integración y su implementación en un ambiente de sistemas legados por Luis Bernardo Oropeza Hernández. Resumen A través del tiempo se ha demostrado que la tecnología está en constante evolución para cubrir eficientemente las necesidades de los seres humanos, y en el ámbito de negocios a las organizaciones. Ambas poblaciones deben estar conscientes de dichos cambios y necesitan estar preparados para adaptarse lo más rápido posible a las nuevas tendencias tecnológicas que surjan a través del tiempo. El proyecto analiza un escenario donde una institución debe afrontarse a un nuevo reto para integrar sus aplicaciones legadas con un nuevo sistema propietario de forma eficiente, rápida, de bajo costo, y capaz de reducir la necesidad de modificar sus procesos durante la implementación. El proyecto documentará las herramientas y estándares posibles a utilizar y analizará las distintas opciones idóneas para la integración, además diseñará y construirá la solución logrando así apoyar a la institución para adaptarse rápidamente a los retos actuales y futuros.. vi.

(7) Lista de Figuras Figura 1. Uso de sistemas electrónicos contra el desempeño del proceso de abastecimiento......... 5 Figura 2. Ejemplo de un proceso de procure-to-pay ......................................................................... 6 Figura 3. Mercado de los ERP en 2012. ........................................................................................... 8 Figura 4. Procesos de negocio soportados por los ERP ................................................................... 8 Figura 5. Framework de trabajo de un sistema ECM basado en 3 niveles: Empresarial, Información y de Sistema. .................................................................................................................................... 9 Figura 6. Cuadrante Mágico de Gartner para softwares IPaaS. ..................................................... 12 Figura 7. Diagrama ilustrativo TLS. ................................................................................................. 14 Figura 8. Diagrama ilustrativo SAML. ............................................................................................. 15 Figura 9. Jerarquía de actividades de protección de la información ............................................... 17 Figura 10. Arquitectura TI propuesta basada en una arquitectura SOA para el caso de estudio. ... 19 Figura 11. Página web de la empresa AWPL. ............................................................................... 21 Figura 12. Página web de la empresa WSO2. ................................................................................ 22 Figura 13. Estrategias definidas dentro del Plan Estratégico 2020. ................................................ 24 Figura 14. Competencias disciplinares y transversales del modelo educativo Tec21 ..................... 25 Figura 15. Portal web del Tecnológico de Monterrey. .................................................................... 26 Figura 16. Timeline del proyecto de Integración. ............................................................................ 27 Figura 17. Proceso de negocio deseado por el cliente ................................................................... 30 Figura 18. Arquitectura de integración propuesta por el proyecto................................................... 35 Figura 19. Organigrama del proyecto de Integración ...................................................................... 37 Figura 20. Estructura de trabajo WBS. ........................................................................................... 38 Figura 21. Plan de trabajo con las actividades del proyecto ........................................................... 41 Figura 22. Diagrama Gantt utilizado en el proyecto ........................................................................ 42 Figura 23. Listado de integraciones implementadas y su interrelación ........................................... 45 Figura 24. Transacciones realizadas durante el 2017 a través de los servicios expuestos por el ESB ................................................................................................................................................. 46. vii.

(8) Lista de Tablas Tabla 1. Sistemas identificados en el alcance del proyecto y su clasificación. ............................... 33 Tabla 2. Matriz de decisión para la selección del componente de integración................................ 33 Tabla 3. Matriz de decisión para la selección tipo de solución ESB. .............................................. 34 Tabla 4. Listado de interfaces requeridas. ...................................................................................... 36 Tabla 5. Información técnica de los servidores del ESB ................................................................. 36 Tabla 6. Tabla de roles y responsabilidades del proyecto .............................................................. 42 Tabla 7. Presupuesto definido para el proyecto .............................................................................. 43. viii.

(9) Contenido Resumen.......................................................................................................................................... vi Lista de Figuras ...............................................................................................................................vii Lista de Tablas................................................................................................................................ viii 1.. 2.. 3.. Introducción ............................................................................................................................... 1 1.1. Problemática ........................................................................................................................ 1. 1.2. Objetivo ................................................................................................................................ 2. 1.3. Alcance (Restricciones y limitaciones) ................................................................................. 2. 1.4. Entregables .......................................................................................................................... 3. Marco Teórico ............................................................................................................................ 4 2.1. Proceso de Procurement (Adquisición) y Procure-to-pay (Procura Pagar) .......................... 4. 2.2. Enterprise Resource Planning (ERP)................................................................................... 6. 2.3. Enterprise Content Management (ECM) .............................................................................. 9. 2.4. Modelos y Componentes de Integración .............................................................................. 9. . Servicios Web .................................................................................................................... 10. . Arquitectura Orientada a Servicios (SOA) ......................................................................... 10. . Bus de Servicios Empresariales (ESB) .............................................................................. 11. . SOA Gateways .................................................................................................................. 11. . Plataformas de Integración como un Servicio (IPaaS)....................................................... 11. 2.5. Componentes de Seguridad .............................................................................................. 13. . Certificados ........................................................................................................................ 13. . Encriptación TLS................................................................................................................ 13. . WS-Security ....................................................................................................................... 14. . Tokens de Seguridad ......................................................................................................... 14. . Federaciones de Identidad ................................................................................................ 14. . Security Assertion Markup Language (SAML) ................................................................... 15. . Open Authorization (OAuth)............................................................................................... 16. . Firewalls ............................................................................................................................. 16. 2.6. Casos de Estudios ............................................................................................................. 17. . Caso de Estudio de una Arquitectura Orientada a Servicios. ............................................ 18. . Caso de Estudio AWPL ..................................................................................................... 20. . Caso de Estudio eBay ....................................................................................................... 21. Contexto del proyecto .............................................................................................................. 23 ix.

(10) 3.1. Descripción de la institución. ............................................................................................. 23. 3.2. Importancia del proyecto .................................................................................................... 26. 4.. Planificación del Proyecto ........................................................................................................ 27. 4.1. Fase de Análisis .................................................................................................................... 28. 4.2. Fase de Diseño ..................................................................................................................... 28. 4.3. Fase de Construcción ........................................................................................................... 28. 4.4. Fase de Pruebas ................................................................................................................... 28. 4.5. Fase de Liberación................................................................................................................ 29. 5.. Configuración ........................................................................................................................... 29. 5.1. Proceso de Negocio .............................................................................................................. 29. 5.2. Alcance de la Integración y su Arquitectura .......................................................................... 33. 5.3. Especificación del Middleware por Utilizar ............................................................................ 36. 6.. Organigrama ............................................................................................................................ 37. 7.. Work Breakdown Structure (WBS) .......................................................................................... 38. 7.1. Fase de Análisis .................................................................................................................... 38. 7.2. Fase de Diseño ..................................................................................................................... 39. 7.3. Fase de Construcción ........................................................................................................... 39. 7.4. Fase de Pruebas ................................................................................................................... 40. 7.5. Fase Liberación..................................................................................................................... 40. 8.. Diagrama Gantt ....................................................................................................................... 41. 9.. Tabla de Responsabilidades .................................................................................................... 42. 10.. Recursos ............................................................................................................................... 43. 11.. Presupuesto .......................................................................................................................... 43. 12.. Resultados (Análisis crítico del proceso y los resultados) ..................................................... 44. 13.. Recomendaciones para Acciones Futuras ............................................................................ 47. 14.. Conclusiones (Lecciones aprendidas) .................................................................................. 48. 15.. Referencias Bibliográficas ..................................................................................................... 49. 16.. Anexos .................................................................................................................................. 52. x.

(11) 1.. Introducción. Desde la creación de los sistemas computacionales ha existido la necesidad de interconectarlos para transmitir o compartir información, donde la mayoría de las comunicaciones al principio eran basadas a través de hardware (como cintas, tarjetas perforadas, diskettes, discos magnéticos, etc.) debido a que no existían los componentes tecnológicos que poseemos en la actual época digital como las redes computacionales o Intranets, Internet, redes sociales, mensajería y comunicación, servicios de almacenamiento en la nube, software colaborativo empresarial, entre otros. Con el paso del tiempo la tecnología ha evolucionado y se han desarrollado nuevas estrategias y conceptos para comunicar sistemas, tales como “integración” o “integración de aplicaciones" permitiendo interconectar los distintos sistemas de una misma institución como escenarios A2A (Application to Application) o con distintas instituciones B2B (Business to Business) de una forma más sencilla y homologada. Sin embargo, con el surgimiento de las tecnologías en la nube nace un nuevo paradigma donde los sistemas que antes existían dentro de la infraestructura tecnológica de las instituciones ahora se encuentran separados a gran distancia y los sistemas o soluciones deben continuar interactuando como si aún existieran dentro de su site local. Para las instituciones hoy en día se considera al área de tecnología de información (TI) como parte integral de la estrategia institucional (Haynes & Chunyan, 2016) después de todo, cuando la estrategia de negocio depende de lo rápido que puede analizar y actuar sobre los datos, la construcción de flujos claros y consistentes de información será algo más que un estilo de vida (Hildebrand, 2016). Las instituciones deben responder rápidamente a las exigentes expectativas de los clientes y los cambios sin precedentes en el panorama de la competencia, para esto la integración se ha convertido en una prioridad en el lado de los negocios, así como de TI (Zavery, 2016). 1.1 Problemática La problemática de la institución surge debido a la reciente adquisición de un sistema tecnológico que soporta los procesos de recepción de facturas, validación fiscal, workflow de autorizaciones y confirmación de pagos al proveedor a través de un administrador de contenidos empresariales (ECM, por sus siglas en inglés) mediante el cual se busca soportar y almacenar cualquier documento derivado en dichos procesos. Con esta implementación se busca cumplir con los requerimientos del área de control interno y mejorar la experiencia de los proveedores agilizando el tiempo de respuesta de las solicitudes de pago (siendo este uno de los principales reclamos recibidos) y transparentando el proceso permitiéndoles llevar una mejor visualización y control de las transacciones relacionadas con la institución. La institución teme que, con la implementación de la solución adquirida no esté acompañada de una estrategia de integración adecuada la cual genere conflictos con los demás procesos del negocio y conlleve a un retraso en la implementación de la nueva solución expuesta anteriormente. Esto debido a la práctica común de la institución de usar una estrategia de interconexión a base de tablas temporales también llamado staging o incluso mediante archivos, esto acompañado de grandes desarrollos en cada componente para consumir o generar dicha información desencadenando así un proceso con dependencias en tiempos de ejecución programados. La institución mantiene sus 1.

(12) sistemas tecnológicos aun de forma local (on-premise) y desconfían de las soluciones en la nube por lo que han evitado su uso, ignorando los beneficios que puedan ofrecerles. 1.2 Objetivo A través de este proyecto se busca generar e implementar un esquema o arquitectura de integración que resuelva la problemática de interconexión la cual afecta actualmente a la institución y su proyecto enfocado a proveedores, logrando de esta manera apoyar a la institución en la incursión de las nuevas tendencias de integración, y optimizar su proceso de solicitudes de pago a proveedores obteniendo así un proceso eficiente y diferenciador. 1.3 Alcance (Restricciones y limitaciones) Dentro de la siguiente sección se enlistan y describen las restricciones identificadas para la correcta ejecución del proyecto. . .      .   . El proyecto consiste únicamente en la definición y desarrollo de un servicio de integración que permita conectar los sistemas legados de la institución con la nueva solución, y no la implementación de una solución para la recepción de facturas (portal de pago a proveedores y componente ECM). Los componentes para la integración tanto del ERP (Enterprise Resource Planning) legado como la nueva solución adquirida, y utilizados por el servicio de integración desarrollado serán realizados por la institución, basados preferentemente en un modelo de servicios API (Application Programming Interface). El proyecto debe enfocarse en desarrollar un servicio de integración y no el desarrollar un sistema completo que sirva de intermediario entre las aplicaciones. El proyecto de integración tampoco buscará cambiar el proceso de negocio ejecutado en su ERP siendo compatible con el proceso actual. Debido a la naturaleza del problema de interconexión, la solución propuesta debe cumplir con estándares de seguridad adecuados para el escenario presentado. Se requiere que el análisis del proyecto y su implementación no dure más de 6 meses, derivado de un nuevo cambio tecnológico por parte de la institución. El costo del proyecto no debe exceder en gran medida el presupuesto aprobado para su análisis e implementación. Se requiere que la misma persona dé el seguimiento durante todo el periodo que abarque el desarrollo del proyecto, de igual manera el contacto de la institución debe ser preferentemente la misma persona quien provea la información relacionada al proceso, y valide los resultados obtenidos. La institución debe comprometerse en apoyar al alumno tanto con la información completa del proceso (siempre y cuando no sea confidencial), ventanas de tiempo para realizar ajustes, recursos, y el esfuerzo necesario para implementar la arquitectura propuesta. El manejo de los recursos financieros será realizado por la institución y no por el alumno, en base a la propuesta presentada. No se podrá contratar a terceras personas quienes realicen el análisis e implementación del servicio de integración de este proyecto, ya que es responsabilidad del alumno.. 2.

(13) 1.4 Entregables Como producto final se entregará un servicio de integración que interconecte las distintas soluciones tecnológicas que posee la institución junto con la solución adquirida recientemente generando un entorno de tiempo real, reduciendo costos derivados por adquisición de infraestructura tecnológica y desarrollos, disminuyendo el personal requerido para dar soporte a la aplicación, y disminuyendo tiempos de atención y respuesta que la institución ofrece a sus proveedores.. 3.

(14) 2. Marco Teórico Dentro del proyecto se utilizarán lineamientos estándares y metodologías existentes las cuales servirán como base para el análisis y el diseño de la propuesta que resuelva la problemática del cliente. Esta información se clasificará en base al sistema actual, el sistema o solución adquirido, las metodologías de integración, y la definición de los estándares para mantener la seguridad de la solicitud propuesta. Adicional se incluyen casos de estudio los cuales utilizan estos componentes para dar un mejor contexto de su uso y eficiencia. 2.1 Proceso de Procurement (Adquisición) y Procure-to-pay (Procura Pagar) Mayer (2012) define al proceso de adquisición como la compra de bienes, servicios o de construcción generalmente por una organización, ya sea en el sector público o privado. Kaur & Singh (2017) identifican que el proceso de adquisición debe involucrar una amplia gama de actividades que van desde la identificación de las fuentes, la asignación de las cantidades de piezas requeridas, y la logística del transporte para su recepción. Por lo tanto, según Oliveira (2017) el proceso de adquisición debe ser flexible para dar cabida a las incertidumbres de la adquisición y a la vez garantice que las responsabilidades de los participantes estén plenamente definidas y los intereses recibidos estén protegidos. Oliveira (2017) adicional hace énfasis sobre el problema de la adquisición el cual está obteniendo importancia en la gestión de la cadena de suministro debido al desarrollo de nuevos mercados, la aparición de contratos complejos, y la información en tiempo real que ha contribuido a un aumento de las estrategias de adquisición que disponen las instituciones entre los cuales pueden ser el negociar a través de contratos bilaterales, contratos futuros o mercados spot. Para Knutsson & Thomasson (2014), cuando el impacto financiero de la adquisición de un determinado producto aumenta, el proceso de adquisición adquiere cada vez más importancia. Por ejemplo, Kaur & Singh (2017) observaron que los costos de adquisición contribuyen cerca del 60% del costo de un producto acabado, lo que hace que la adquisición sea aún más importante para el desempeño de la institución en términos de generación de ingresos o minimización de costos por lo que el mismo autor concluyó que la optimización del proceso de adquisición es la actividad más desafiante y emergente que atrae la atención de investigadores y profesionales debido a complejidad del problema. Partida (2015) comenta también desde el punto de vista del proceso de adquisición y la investigación de APQC (American Productivity and Quality Center), las organizaciones que no toman medidas para automatizar las actividades transaccionales simplemente no pueden igualar la eficiencia y la efectividad de las que sí lo hacen.. 4.

(15) Figura 1. Uso de sistemas electrónicos contra el desempeño del proceso de abastecimiento. Como se ilustra en la figura 1 (Partida, 2015), y a su vez obtenida de APQC. A través de tiempos de ciclo de orden de compra más cortos y más pedidos de compras procesados por empleados de tiempo completo, las organizaciones con un proceso automatizado de pagos tienen plazos más cortos de entrega a proveedores. Partida (2015) menciona también que, en cualquier organización, el proceso de adquisición y cuentas por pagar están estrechamente vinculadas a través del proceso de pago (procure-to-pay). Varmazis (2008) señala que los proveedores de software se enfocaron hace años a la recopilación de datos de cuentas por pagar y su canalización a través de sistemas de clasificación automatizados para reducir o eliminar por completo los procesos en papel. El nuevo énfasis debe ser la automatización del siguiente paso del proceso el cual es el pago que es mucho menos sobre la eficiencia y más sobre la visibilidad y el control. Kumaran (2015) describe al proceso de pago como un proceso de obtención de las materias primas necesarias para fabricar un producto o proporcionar un servicio, y realizar el pago de estos. Además, provee un ejemplo de lo que sería un ciclo de abastecimiento y pago: El proceso comienza con la planificación de los materiales requeridos, luego la empresa prepara una lista de proveedores que creen que puede proporcionarles los materiales. La compañía le pide a cada uno de los proveedores que presente una cotización, que incluye el precio, los plazos de entrega, la calidad de los materiales y cualquier otra información que necesiten para tomar su decisión. Una vez que se ha elegido un proveedor, los compradores crean un formulario de solicitud de compra que incluye información como la descripción de los bienes y servicios, el número de cuenta del departamento, las firmas de los gerentes autorizados, las instrucciones de entrega, y las cotizaciones del proveedor autorizado. Se envía una orden formal de compra al proveedor para que suministre los productos junto con instrucciones sobre las condiciones en que deben ser suministrados. Una vez que la empresa recibe. 5.

(16) los productos del proveedor, el departamento de compras prepara una entrada de mercancía. Este es un documento importante que luego se puede usar para conciliar si lo que el vendedor entregó fue realmente lo que pidieron. La entrada de mercancías se compara con la orden de compra para validar si las dos coinciden. Si hay discrepancias, el comprador puede contactar al vendedor y publicar una queja. Los controles se realizan si los bienes son adecuados para su uso o no, si se ha entregado la cantidad correcta, si todos los productos cumplen con las especificaciones solicitadas y se les aplica un precio de acuerdo con los términos de la orden de compra. Si alguna mercancía se daña, los compradores deberán ponerse en contacto con los vendedores y solicitar un reemplazo o un reembolso. Una vez que se realiza la verificación de los bienes, se crea la factura de pago y se obtienen las aprobaciones necesarias de los administradores del proyecto. Cuando la empresa realiza los pagos finales al proveedor, el ciclo llega a su fin (Kumaran, 2015). Este proceso es ilustrado en la figura 2.. Figura 2. Ejemplo de un proceso de procure-to-pay. 2.2 Enterprise Resource Planning (ERP) Para llevar a cabo un análisis es necesario definir lo que es un ERP, para esto existen diferentes definiciones de autores acerca del significado de un ERP. Por ejemplo, Wu & Wang (2007) describen que la esencia del ERP es integrar las actividades principales del negocio, incorporando las mejores prácticas del mercado facilitando así la rápida toma de decisión, reducción de costos, y una mayor gestión de la alta dirección. Otra definición más sencilla la comenta Nwankpa (2015) donde los sistemas ERP son paquetes de software complejos que integran procesos de información y de negocio entre las distintas áreas funcionales de negocio. Entre los beneficios que se pueden obtener al implementar un ERP son la automatización de tareas repetitivas, emisión de facturas y documentos anexos, generación de órdenes de reposición o transferencia de otros depósitos a partir de pedidos (Scurtu, 2016) mismos que antes se hacían a través de otros procesos. Adicional los 6.

(17) autores Haynes & Chunyan (2016) por su cuenta complementan la lista de beneficios con: gestionar activos y pasivos aumentando la transparencia, mejorando el control en los procesos de compras y gastos, los movimientos de capital a través de una organización e incrementar los controles internos y tradicionales que identifican riesgos potenciales en términos de fraude u otro uso indebido. Sin embargo, la implementación de un ERP requiere una inversión sustancial de tiempo, dinero, y recursos internos (Hitt, Wu, & Zhou, 2002). Es importante que las instituciones consideren todos los costos y beneficios de la adopción de un sistema ERP. Según la investigación de Haynes & Chunyan (2016), el costo promedio para la implementación oscila entre $ 11 y $ 17.5 millones y tarda casi dos años en completarse. Por ende, debe de quedar claro los beneficios que con lleva la adquisición principalmente sobre las áreas operacionales, gerenciales, estratégicas, de infraestructura de TI, y de organización (Nwankpa, 2015) junto con el impacto en la cultura organizacional (Jacobs & Weston, 2007). Wu & Wang (2007) recomiendan que, para lograr el éxito de una implementación ERP es necesario contar con 2 tipos de roles: Los usuarios clave que son seleccionados de los departamentos operativos y generalmente están familiarizados con el proceso de negocio. Y los usuarios finales que son los usuarios del sistema ERP, éstos solo tienen un conocimiento muy específico de una parte del sistema necesaria para trabajar. Durante el último siglo, los sistemas ERP se han reconocido como la infraestructura de tecnología de la información más imperativa de las instituciones modernas. Sin embargo, Fulmer & Gerard (2014) remarcan que en el mercado los sistemas ERP son altamente dinámicos: hay innovación constante, nuevos entrantes en el mercado, nuevos modelos de negocio, actualizaciones, la experiencia de usuario, movilidad, y la nube (Popa & Vaida, 2016). Bee (2015) menciona en su artículo que tal pareciera que los días de los ERP están contados debido a la falta de flexibilidad, usabilidad y rentabilidad provocando que los sistemas monolíticos ERP vayan por el mismo rumbo que las Palm Pilot, el cual desapareció del mercado debido a la evolución tecnológica. Los sistemas ERP ahora deben de entrar en una era de “configuración fácil" que permita una implementación reducida en días (Jacobs & Weston, 2007) y fácil operación. En la figura 3 podemos visualizar el mapa de mercado de los sistemas ERP propietarios del 2012 presentado por (Columbus, 2013).. 7.

(18) Figura 3. Mercado de los ERP en 2012.. Laudon & Laudon (2012) describen en la figura 4 algunos de los principales procesos de negocios que son soportados por los sistemas de gestión de recursos empresariales.. Figura 4. Procesos de negocio soportados por los ERP. 8.

(19) 2.3 Enterprise Content Management (ECM) Los autores Grahlmann, Helms, Hilhorst, Brinkkemper, & Van Amerongen (2012) señalan que la literatura científica sobre los softwares ECM es aún limitada y no hay un consenso exacto sobre su definición. Para Laumer, Beimborn, Maier & Weinert (2013) una de las definiciones que revisaron en su investigación es el conjunto de las estrategias, métodos y las herramientas utilizadas para capturar, administrar, almacenar, preservar y entregar contenido de los documentos relacionados con procesos organizacionales. Por su lado Grahlmann, Helms, Hilhorst, Brinkkemper, & Van Amerongen (2012) señalan que las organizaciones producen varias formas de contenido digital como documentos de texto, hojas de cálculo, páginas web o correos electrónicos, y a menudo los archivos solo se almacenan localmente, lo que dificulta su localización, accesibilidad, coherencia y el control de la publicación. Laumer, Beimborn, Maier & Weinert (2013) comentan que los sistemas ECM proporcionan la funcionalidad para admitir la compilación de información generada de manera no automática (capturar, administrar, almacenar, preservar, entregar) y, por otro lado, la funcionalidad para integrar información generada automáticamente, siendo ambos compatibles con el trabajo colaborativo y la seguridad de TI. Los sistemas ECM integran diversos repositorios y proporcionan a otras aplicaciones acceso a estos almacenes de contenido (Grahlmann, Helms, Hilhorst, Brinkkemper, & Van Amerongen, 2012). Dichos sistemas pueden además actuar como un facilitador de la gestión sostenible del conocimiento organizacional (Vom Brocke, Simons, & Cleven, 2011), se esquematiza todos los conceptos dentro de la figura 5 (Laumer, Beimborn, Maier, & Weinert, 2013).. Figura 5. Framework de trabajo de un sistema ECM basado en 3 niveles: Empresarial, Información y de Sistema.. 2.4 Modelos y Componentes de Integración Dado que las instituciones deben responder a las exigentes expectativas de los clientes y los cambios sin precedentes en el panorama de la competencia, la integración se ha convertido en una prioridad en el lado de los negocios, así como del área de TI (Zavery, 2016). Para esto la definición de estándares de tecnología desempeña un papel muy importante que ayuda a proteger a las instituciones contra el problema de bloqueo de proveedores derivados de software propietarios y. 9.

(20) son portadoras de conocimiento (Carey, 2008). Dicho conocimiento para Martínez, García & Gómez (2015) ha surgido a través de varios desafíos técnicos derivados de la evolución de los conceptos y tendencias tecnológicas, en general ha requerido de una gran cantidad de rediseños como cambios de mentalidad, y de un extenso grupo de gente tratando de encontrar un modelo de "una solución que se adapte a todos" que aplicaría a la mayoría de las instituciones. . Servicios Web. Castro & Flores (2015) especifican que los servicios web son protocolos de comunicación basados en texto, donde el cliente y su consumidor se comunican a través del intercambio de mensajes de texto estructurados según el estándar XML (Extensible Markup Language). Estos servicios se pueden implementar utilizando el estándar SOAP (Simple Object Access Protocol) que indica el formato de mensaje a utilizar durante la comunicación y la definición de un contrato WSDL (Web Services Description Language) donde se especifican la representación del mensaje, los tipos de datos, operaciones e información para la comunicación. También se cuenta con servicios web de tipo REST (Representational State Transfer) los cuales basan su funcionamiento en las capacidades que brinda el protocolo HTTP (Hypertext Transfer Protocol) donde toda la información se clasifica a través de recursos de servicio y se identifican a través de una URI (Uniform Resource Identifier), se manipulan utilizando un conjunto fijo de operaciones PUT, GET, POST, y DELETE y, además, los recursos no están acoplados con su representación por lo que su contenido puede ser accedido a través de otros formatos como HTML(HyperText Markup Language), XML, JSON (JavaScript Object Notation), texto plano, entre otros. Para Castro & Flores (2015) los servicios web se pueden combinar de dos formas, mediante una orquestación o una coreografía. La coreografía no depende de un orquestador central, cada servicio que interviene en el proceso tiene que conocer cuándo entrar en acción y cuándo estar inactivo. La orquestación a su vez es un proceso controlado por un agente en el sistema y es descrito en términos de intercambio de mensajes y órdenes de ejecución. . Arquitectura Orientada a Servicios (SOA). De acuerdo con Butler (2008), SOA (Service Oriented Architecture) representa un estilo de arquitectura de TI flexible en el que se pueden integrar varios servicios de aplicación, que pueden ser ofrecidos internamente o por proveedores de servicios. Los autores Van den Bergh & Viaene (2012) señalan que SOA ha surgido como un enfoque para diseñar e integrar nuevas aplicaciones con aplicaciones legadas de una manera orientada al proceso y clasificación de servicios. Butler (2008) adicional menciona que SOA describe una arquitectura de tecnología de la información o un enfoque de diseño que organiza los recursos de TI distribuidos en una solución integrada mediante la combinación de servicios de software interoperables de acoplamiento libre. Castro & Flores (2015) comentan que la esencia de SOA es la creación de servicios que deben tener, entre otras funcionalidades, la característica de ser reusables para todos los sistemas que utilicen o para implementar nuevas funcionalidades, producto de la composición de un conjunto de estos. Aunque las investigaciones sobre SOA han sido continuas durante varios años, Martínez, García & Gómez (2015) mencionan que los investigadores han comenzado a investigar su impacto real en el desempeño de las instituciones, para Butler (2008) el uso de SOA transformaría la forma en que los. 10.

(21) departamentos de TI y las organizaciones interactúan. Donde Van den Bergh & Viaene (2012) atribuyen este cambio a que el departamento de TI pueda agilizarse removiendo la necesidad de gastos masivos de integración y reintegración cuando los requerimientos y/o requisitos cambien. . Bus de Servicios Empresariales (ESB). De acuerdo con Bhadoria, Chaudhari, & Tomar (2016), la palabra ESB (Enterprise Services Bus) fue introducida por primera vez por Roy W. Schulte del Grupo Gartner en 2002. Los autores Martínez, García & Gómez (2015) comenta que los softwares ESB proporcionan una capa de mediación, donde se convierta la información en distintos protocolos permitiendo así la comunicación entre diversas aplicaciones integradas por medio de adaptadores. Yin, Chen, Deng, Wu & Pu (2009) establecen que los softwares ESB debe de contener al menos ciertos patrones de integración como el ruteo de mensajes, la transformación del formato de los datos, el enrutamiento de mensajes confiable, la orquestación de servicios, entre otros. Los softwares ESB han sido también considerados como una forma prometedora de apoyar la integración de servicios dinámicos y entornos ágiles. En primer lugar, una arquitectura ESB flexible es necesaria para hacer frente a la complejidad y el dinamismo de Internet y proporcione mecanismos automatizados de adaptación y recuperación para asegurar operaciones continuas a pesar de fallas de nodo (Yin, Chen, Deng, Wu, & Pu, 2009). Por último, Martínez, García & Gómez (2015) mencionan que los ESB pueden considerarse como una extensión de la arquitectura EAI (Enterprise Application Integration). . SOA Gateways. Los softwares llamados SOA gateways según Ryan (2012), fueron diseñados originalmente para proporcionar seguridad en el intercambio de datos entre instituciones (escenarios B2B) a través de estándares de servicios web. Estas herramientas combinan las capacidades de un ESB tradicional a través de seguridad, agilidad y simplicidad e incluyen nuevas capacidades que resuelven los paradigmas de los softwares ESB como integraciones intercontinentales, escenarios B2B, cloud computing, y servicios móviles. Estos sistemas además incluyen un dispositivo basado en hardware para proporcionar protección contra nuevas amenazas, específicamente en torno a ataques basados en XML, privacidad e integridad de datos a nivel de mensaje y campo, y abstracción de interfaz. . Plataformas de Integración como un Servicio (IPaaS). McBride (2014) comenta que las infraestructuras de TI híbridas (locales y en la nube) son la nueva norma para las instituciones modernas, pero la integración de aplicaciones y la carga de trabajo en estos entornos tiende a ser compleja y desafiante. De Montcheuil (2016) menciona que Gartner definió a los softwares IPaaS (Integration Platform as a Services) como un servicio en la nube que proporciona una plataforma para soportar proyectos de integración de aplicaciones, datos, y de procesos involucrando usualmente una combinación de aplicaciones y fuentes de datos basadas en la nube, API’s, y sistemas on-premise. En pocas palabras, es un producto de integración que se ejecuta en una nube pública y es administrado por el proveedor donde se consolida múltiples 11.

(22) servicios en conjunto destinado a la integración y gobernanza de cualquier combinación de aplicaciones locales y externas, SOA, procesos, y datos en la nube dentro o fuera de una organización. Para Jankovic, Milojkovic, Mladenovic, Despotovic & Bogdanovic (2012), un iPaaS es una evolución de una arquitectura IaaS (Infrastructure as a Service) que ha sido ampliamente adoptada para escenarios B2B y pueden conectarse de muchas maneras con cualquier combinación de aplicaciones, servicios, procesos y datos dentro y fuera de la organización, en base a los distintos escenarios como cloud to on-premise, cloud to cloud, on-premise to on-premise, application to application, y business to business. De Montcheuil (2016) menciona también que Gartner identifica a cinco líderes en su cuadrante mágico ilustrado en la figura 6 (Gartner, 2016), estos son Dell Boomi, Informática, MuleSoft, SnapLogic y Jitterbit. Donde Informática y MuleSoft son proveedores de integración multipropósito con amplias soluciones en el mercado siendo el software iPaaS tan solo uno de sus bloques de construcción. Por el contrario, Boomi, SnapLogic, y Jitterbit son los "veteranos" del software iPaaS, creado antes de que el término fuese acuñado.. Figura 6. Cuadrante Mágico de Gartner para softwares IPaaS.. 12.

(23) 2.5 Componentes de Seguridad Como comentan Martínez, García & Gómez (2015), muchos de los usuarios de los sistemas ERP han sido resistentes en colocar sus datos sensibles en la nube. Sin embargo, estas vacilaciones se han ido evaporando gradualmente, a medida que las ventajas son cada vez más evidentes. La naturaleza de la comunicación con la nube implica nuevos tipos de ataques y, en consecuencia, la necesidad de nuevos mecanismos de seguridad para proteger los servicios web y sus mensajes. Para Ryan (2012) los servicios web deben de cumplir con al menos ciertos requerimientos de seguridad como autenticación, que es el proceso de identificación de un individuo o identidad para validar si es en realidad la entidad que afirma ser, este ha sido un problema de varios años y que hoy en día sigue presente. Jesudoss & Subramaniam (2014) incluyen el proceso de Integridad el cual debe de asegurar que los datos no se han alterado durante el tránsito, y por último la confidencialidad siendo el proceso de impedir que los usuarios no autorizados tengan acceso a los datos. Para esto existen un conjunto de herramientas que permiten cumplir estos requisitos para asegurar la comunicación de forma segura y confiable. . Certificados. Torroglosa, Pérez, Martínez & López (2013) definen a los certificados como documentos electrónicos por el cual un tercero de confianza asegura la vinculación de una clave pública con una identidad, usando una firma digital. La identidad puede hacer referente a un individuo o identidad e incluye información tal como el nombre de una persona o los datos de la organización, su dirección, y así sucesivamente. . Encriptación TLS. Para Brown & Jenkins (2016), la encriptación TLS (Transport Layer Security) proporciona un mecanismo mediante el cual un cliente web (navegador) y un servidor web establecen una conexión entre sí haciendo uso de la criptografía de clave pública para acordar una clave secreta compartida utilizada para cifrar la comunicación a través de un cifrado simétrico para el resto de la comunicación. Normalmente, el proceso comienza con el cliente proporcionando un nombre de dominio, que luego se traduce a una dirección IP (Internet Protocol) a través de la resolución de nombres DNS (Domain Name System), después el cliente envía un mensaje TLS “Hello Client” al servidor a través del puerto 443 hacia dicha IP. El cliente recibe entonces varios mensajes del servidor, entre los cuales uno contiene la clave pública. El cliente elige una clave secreta (con mayor precisión, un valor que determina la clave secreta), la encripta con la clave pública que el cliente recibe y, envía el texto cifrado resultante al servidor. En este punto, ambas partes tienen la misma clave secreta, y la comunicación cifrada puede comenzar, este proceso es ilustrado en la figura 7 por Brown & Jenkins (2016).. 13.

(24) Figura 7. Diagrama ilustrativo TLS.. . WS-Security. Para Makino, Tamura, Imamura & Nakamura (2004) el WS-Security define mecanismos como firmas digitales y encriptación permitiendo que los mensajes SOAP estén protegidos. Esta especificación también define la sintaxis para codificar el formato arbitrario de los tokens de seguridad que se van a incrustar en los mensajes. Entre los objetivos de la especificación WS-Security Jesudoss & Subramaniam (2014) mencionan: dominios de confianza, múltiples tokens de seguridad, múltiples tecnologías de cifrado, múltiples formatos de firma y seguridad de extremo a extremo a nivel de mensaje. . Tokens de Seguridad. Lewis & Lewis (2009) definen básicamente al token de seguridad como la representación de conceptos abstractos tales como nombre o cuenta, clave y privilegios propiedad del remitente del mensaje. . Federaciones de Identidad. Las federaciones de identidad permiten que la autenticación de usuarios sea realizada por entidades que tienen una estrecha relación con ellos. El uso de federaciones de identidad permite además que el usuario se autentique una vez y tenga acceso a varios servicios y sistemas diferentes a través del mecanismo Single Sign-On (SSO). Finalmente, al centralizar la autenticación, los usuarios tendrán menos contraseñas que recordar, pudiendo elegir contraseñas más fuertes y seguras (Sette & Ferraz, 2014).. 14.

(25) . Security Assertion Markup Language (SAML). Lewis & Lewis (2009) definen como uno de los protocolos de federación a SAML el cual proporciona una solución segura basada en XML para intercambiar información de seguridad de usuarios entre un proveedor de identidad (nuestra organización) y un proveedor de servicios ya sea ASP (Active Server Pages) o SaaS (Software as a Service). Sette & Ferraz (2014) mencionan que SAML soporta varios mecanismos de transporte a través de diferentes enlaces, por ejemplo: SOAP (opción única en la versión 1.x), HTTP Redirect (GET) y HTTP POST. Para Lewis & Lewis (2009) hay principalmente tres roles involucrados en una transacción de SAML: una parte asertiva, una parte que confía, y un sujeto. La parte asertiva (proveedor de identidad) es el sistema en autoridad que proporciona la información del usuario. La parte que confía (proveedor de servicios) es el sistema que confía en la información de la parte que asevera y utiliza los datos para proporcionar una aplicación al usuario. El usuario y su identidad que participa en la transacción se conocen como el sujeto. El proveedor de servicios redirige al cliente hacia los proveedores de identidad que autentica al usuario y redirige al cliente de nuevo al proveedor de servicios que pasa los datos que demuestran la autenticación, este proceso es ilustrado en la figura 8 por Lewis & Lewis (2009). Todo el intercambio de datos entre el proveedor de identidad y el proveedor de servicios pasa a través del cliente a través de mensajes firmados, sin tráfico entre ellos. Ya en el perfil de resolución de artefactos, el proveedor de servicios, y el proveedor de identidad se hablan directamente para intercambiar datos de autenticación (Sette & Ferraz, 2014).. Figura 8. Diagrama ilustrativo SAML.. 15.

(26) . Open Authorization (OAuth). Torroglosa, Pérez, Martínez & López (2013) definen a OAuth como un protocolo de autorización que permite a una aplicación de terceros obtener acceso limitado a un servicio. Ya sea en nombre de un propietario de recursos y/o permitiendo que la aplicación de terceros obtenga acceso en su propio nombre, sin revelar las credenciales de inicio de sesión para ese servicio (Ferry, Raw, & Curran, 2015). Torroglosa, Pérez, Martínez & López (2013) señalan que, en lugar de utilizar las credenciales del propietario del recurso para acceder a los recursos protegidos, el cliente obtiene un token de acceso y el cliente utiliza el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos. Dicho token está asociado con un cliente, el ámbito al que está limitado el cliente junto con una fecha de caducidad (Ferry, Raw, & Curran, 2015). Para Ferry, Raw, & Curran (2015) OAuth busca resolver las deficiencias de los protocolos de autenticación de propiedad creando un mecanismo de autorización universal e interoperable entre los servicios siendo así el método más preferido de los proveedores de redes sociales como Facebook y Twitter para proteger sus API’s y federar la identificación a través de los dominios. . Firewalls. Existen diversas definiciones de firewall, Lynch (2000) encontró que el firewall es un sistema o grupo de sistemas que imponen una política de control de acceso entre dos redes. También menciona que su implementación más común es proteger las redes de las organizaciones de los ataques en Internet, sin embargo, también pueden utilizarse para aislar información de las distintas áreas de una organización. Los firewalls son una herramienta que cumple los 3 componentes de seguridad: confidencialidad, integridad y disponibilidad, ya que pueden prevenir el acceso no autorizado a la información, pueden prevenir cambios no autorizados a la información, y pueden ayudar a mantener la disponibilidad de acceso a la información (Lynch, 2000). En la figura 9 se tiene la jerarquía de actividades necesarias para proteger la información en una organización (Lynch, 2000).. 16.

(27) Figura 9. Jerarquía de actividades de protección de la información. Lynch (2000) describe la operación de un firewall como pasos donde, primero el firewall examina cada paquete que llega a la red de la organización a través de él, luego el firewall identifica varios parámetros que le ayuden a tomar una decisión de control como son dirección de origen, dirección de destino, protocolo asociado, número de puerto, aplicación asociada (solo disponibles en algunos firewalls). Y a través de reglas previamente programadas o cargadas, el firewall puede bloquear el acceso a la red del paquete, permitir su acceso a la red o restringirlo para ciertas aplicaciones. Para Navarikuth, Neelakantan, Sachan, Pratap, Kumar & Mallick (2013) los firewalls actuales se configuran manualmente, siendo la mayoría de estas estáticas hasta que se promulguen nuevas, como son las reglas y políticas, además la actividad de configuración se convierte en una actividad engorrosa para los administradores. Si bien los firewalls no son garantía de protección de la información, no son una panacea, pero pueden ser una parte fundamental en el programa de seguridad total para la protección de la información de la organización (Lynch, 2000).. 2.6 Casos de Estudios En la siguiente sección se incluyen 3 casos de estudio donde el uso o implementación de una correcta arquitectura de integración logró mejorar los procesos de la organización. Estos casos utilizan varios de los conceptos descritos dentro de los anteriores puntos del marco teórico y se incluyen los resultados que obtuvieron.. 17.

(28) . Caso de Estudio de una Arquitectura Orientada a Servicios.. Coleman & Akinsola (2012) mencionan como antecedente en su caso de estudio la necesidad de los hospitales de contar con un suministro seguro de sangre para salvar vidas porque a menudo la sangre es el único medio de supervivencia. La sangre debe tener la eficacia correcta y la cantidad adecuada para corregir cualquier defecto homeostático en la fisiología normal del paciente y la sangre debe estar libre de infecciones. Coleman & Akinsola (2012) encontraron que los suministros de sangre de los hospitales rurales en la Provincia del Noroeste de Sudáfrica incluyen un mal proceso de entrega que a veces dificulta el proceso de almacenamiento y distribución en los hospitales locales. Por lo que el estudio de Coleman & Akinsola (2012) se basó en la investigación del uso de métodos en los procesos de gestión sanguínea (ordenamiento, almacenamiento, y transferencia de existencias) en estos hospitales rurales. Después de un análisis profundo Coleman & Akinsola (2012) establecen que el uso de las tecnologías de información puede ayudar con la identificación de problemas relacionados con la asignación de sangre al proporcionarles a los usuarios análisis en tiempo real y una decisión automatizada sobre la asignación de sangre generado a través de una arquitectura SOA. Por último, Coleman & Akinsola (2012) concluyen entre otras causas, la falta de integración de los sistemas de TI para facilitar la transferencia y el intercambio rápidos de información, la conectividad a Internet lenta y las interrupciones constantes del suministro eléctrico en los hospitales rurales como impedimentos para la implementación de los servicios de salud electrónica como la requisición electrónica, la transferencia electrónica, el registro del inventario electrónico y el mantenimiento electrónico de la sangre, recomendando así su implementación en escala de piloto.. 18.

(29) Figura 10. Arquitectura TI propuesta basada en una arquitectura SOA para el caso de estudio.. 19.

(30) . Caso de Estudio AWPL. La compañía AWPL (s.f.) (Automated Workflow Private Limited) realizó un caso de estudio para una aseguradora líder en Asia y una de las grandes marcas conocidas por la gestión de activos. Esta aseguradora atiende a más de 2.2 millones de clientes en 12 países como China, Hong Kong, India, Indonesia, Japón, Corea, Malasia, Filipinas, Singapur, Taiwán, Tailandia y Vietnam. Dentro del reporte de AWPL (s.f.) se indica que la compañía estaba usando un sistema propietario como su sistema de back-end, al que estaba conectado todas las aplicaciones front-end de la compañía y cada sistema mantuvo su propia copia de servicios. Esto provocaba que un pequeño cambio a nivel de sistema operativo requería que todos los servicios se actualicen de forma individual, siendo este un trabajo problemático ya que estos servicios no fueron implementados en un servidor central. AWPL (s.f.) comenta también que el cliente quería implementar un sistema basado en SOA, con el cual todos los servicios podrían consolidarse fácilmente y desplegarse como servicios reutilizables en un entorno SOA. El sistema SOA debe poder conectarse con el sistema back-end o al sistema administrador de contenidos, mientras que las demás aplicaciones deben conectarse al sistema back-end a través de los sistemas basados en SOA. En el reporte AWPL (s.f.) describe que se implementó IBM Message Broker como software ESB para facilitar el acceso de todos los sistemas front-end y otras aplicaciones generales al sistema back-end. Los flujos de mensajes basados en SOAP se desarrollaron para construir los servicios reutilizables, que luego se implementaron dentro del ESB. Actualmente, los flujos de mensajes están conectados a dos sistemas principales back-end y al software de contenidos de IBM. Como beneficios AWPL (s.f.) reporta que se pudo habilitar las aplicaciones existentes para servicios web sin ninguna reescritura de aplicaciones heredadas, que generalmente es un asunto costoso, permitiendo así a la solución ayudar al cliente a reducir significativamente el gasto de capital y también mejoró la disponibilidad de aplicaciones y hardware. En la siguiente figura se ilustra la página web de la compañía que realizó el estudio.. 20.

(31) Figura 11. Página web de la empresa AWPL quien realizó el caso de estudio. Fuente: www.awpl.co/about-us/. . Caso de Estudio eBay. En este caso de éxito se presenta a la compañía eBay la cual realiza una implementación ESB open-source para soportar la gran demanda de transacciones recibidas. Wso2 (2011) pone como antecedente que eBay es el mercado en línea más grande del mundo. En el 2011, más de 94 millones de usuarios activos en todo el mundo acuden a eBay para encontrar las mejores ofertas en el ciberespacio. Solo en 2010, el valor total de los productos vendidos en eBay fue de $ 62 mil millones o $ 2,000 por segundo (Wso2, 2011). Sin embargo, se enfatiza que junto con el éxito de eBay viene una gran demanda para garantizar la disponibilidad confiable de los servicios 24x7 que soportan estas transacciones sobre todo en días festivos. Wso2 (2011) expuso la problemática de eBay como: las soluciones actuales no satisfacían las necesidades de la organización, por lo que se consideró el construir un nuevo sistema interno o adoptar tecnología de terceros. Para Wso2 (2011) marca como puntos claves de decisión, que eBay quería acomodar las capacidades mejoradas de mediación y orquestación del servicio a su arquitectura existente orientada a servicios, con el fin de mejorar sus servicios comerciales. Además, cualquier solución implementada necesitaría la escalabilidad y el rendimiento para sostener las crecientes cargas de tráfico de la ascendente base de clientes de eBay.. 21.

(32) El software ESB de Wso2 superó a todas las demás opciones de software tanto en velocidad como en fiabilidad. Para eBay, ha visualizado implementar el software de Wso2 para llevar a cabo más de mil millones de transacciones por día durante los horarios pico de compra en 2010, (Wso2, 2011). Durante el proceso de implementación el reporte proveído por Wso2 (2011) describe que, a los pocos meses de elegir la solución en 2009, eBay realizó una implementación inicial que registró aproximadamente un millón de llamadas por día durante la temporada de compras navideñas de 2009. Tan solo 1 año después, todos los servicios de eBay que estaban expuestos al comercio electrónico eran mediados a través del software ESB de Wso2 y se manejaban más de mil millones de llamadas por día (Wso2, 2011) permitiendo así a eBay brindarles a sus clientes y socios la experiencia de calidad deseada, incluso cuando su base de clientes globales continúa en crecimiento. En la siguiente figura se puede visualizar la página del sitio Wso2.. Figura 12. Página web de la empresa WSO2 quien realizó el caso de estudio. Fuente: wso2.com. 22.

(33) 3. Contexto del proyecto La institución adquirió recientemente una plataforma tecnológica compuesta por un portal junto con un administrador de contenidos facilitándole la gestión de la recepción, validación, y almacenamiento de facturas como parte de su proceso de solicitud de pago a proveedores siendo esta solución instalada de forma on-premise. Para su correcta ejecución, se requiere que la nueva plataforma se comunique con el sistema legado ERP de la institución para intercambiar información transaccional de compras y almacenes además de la generación de documentos contables. El no contar con la comunicación necesaria ocasionaría que la nueva plataforma no fuese implementada o aprovechada en su totalidad motivo por el que se requiere de un proyecto de integración que asegure la interconexión entre los sistemas. El sistema con el que operan actualmente solo recibe la factura y genera un ticket al equipo del CSA (Centro de Servicios de Apoyo) el cual realiza todas las validaciones de forma manual provocando un aumento en los tiempos de respuesta de las solicitudes de pago realizadas por los proveedores. 3.1 Descripción de la institución. La institución a implementar el proyecto se identifica como Instituto Tecnológico y de Estudios Superiores de Monterrey, donde su ramo principal es la educación media-superior y superior siendo la universidad privada más importante de México, y parte del top 200 de universidades del mundo. Cuenta con al menos 30,000 colaboradores tanto nacional como internacional (Tec de Monterrey, s.f.). El Tecnológico de Monterrey nace en 1943 de la mano de un grupo de empresarios encabezados por don Eugenio Garza Sada basado en un enfoque de educación privada, sin fines de lucro, independiente y ajena a partidarismos políticos y religiosos, con el objetivo de acrecentar la calidad de la educación superior junto a asociaciones civiles y un destacado grupo de líderes y logrando como fin de convertirse en el motor de desarrollo de las comunidades y el país. Durante los últimos 25 años su estrategia se basó principalmente en 5 pilares: la adecuada selección de candidatos, evaluación de aprendizaje estandarizada, seguimiento a los egresados, la evaluación de la efectividad educacional y obtención de acreditaciones nacionales e internacionales permitiéndole localizarse hoy en día en una de las mejores instituciones del país y del mundo (Tec de Monterrey, s.f.). En el 2012 el consejo directivo de la institución reafirmó su compromiso de continuar elevando y fortaleciendo la calidad académica, para esto se desarrolló un modelo de transformación llamado plan estratégico 2020 el cual impulsaría sus componentes al éxito educativo. Tales estrategias son: Selectividad y Becas, Profesores Inspiradores, Modelo Tec21, Investigación que transforma vidas, Distrito Tec, Fortalecimiento en Ciudad de México y Vinculación con Egresados y Campañas Financieras (Tec de Monterrey, s.f.).. 23.

(34) Figura 13. Estrategias definidas dentro del Plan Estratégico 2020.. El objetivo del nuevo modelo educativo Tec21 es “mejorar la competitividad al potenciar las habilidades y desarrollar las competencias requeridas en los diferentes campos profesionales”. Y se compone de 4 pilares: Aprendizaje basado en retos, flexibilidad, profesores inspiradores y vivencia memorable, lo que preparará al alumno para resolver los retos del mundo actual (Tec de Monterrey, s.f.).. 24.

(35) Figura 14. Competencias disciplinares y transversales del modelo educativo Tec21. Esta información puede ser consultada desde el portal institucional, como se ilustra en la siguiente figura.. 25.

(36) Figura 15. Portal web del Tecnológico de Monterrey. Fuente: www.tec.mx. 3.2 Importancia del proyecto Para la institución, es de suma importancia la implementación del portal de pago a proveedores en combinación con la solución ECM debido a que el proceso actual está soportado por un conjunto de 3 plataformas tecnológicas las cuales gran parte de sus actividades son realizadas manualmente a causa de la falta de integración con el ERP institucional, y los retrasos en las respuestas de las solicitudes de pagos están relacionados directamente con la cantidad de personal que opera hoy en día dichas plataformas. A través de la nueva plataforma se obtendrían como beneficios la centralización de la operación cumpliendo así la estrategia de la institución por homologar sistemas y procesos, el correcto almacenamiento de los documentos y comprobantes fiscales de una forma fácil y segura, la validación automática three-way match el cual asegura que no se realicen pagos erróneos o fraudulentos a nombre de la institución, un workflow automatizado de autorizaciones, transparencia en cada momento del estatus de las solicitudes y las transacciones que tiene cada proveedor con la institución, y generación de reportes y estadísticas de las solicitudes que permita tener visibilidad cubriendo las necesidades de auditoria lo que generaría grandes ahorros en operación e infraestructura junto con un proceso seguro , automatizado y transparente para la institución.. 26.

(37) La importancia del proyecto de integración es poder facilitar y asegurar la correcta definición y liberación de los servicios de integración habilitando la operación transaccional entre el sistema de gestión empresarial de la institución siendo este la fuente de datos oficial, y el portal ECM para asegurar todos los beneficios descritos anteriormente permitiendo fortalecer y automatizar el proceso de solicitud de pago a proveedores de la institución. Cabe recalcar que al ser un proyecto que gestiona la salida de dinero está categorizado como un proyecto de gran impacto para la institución.. 4. Planificación del Proyecto Se acordó con el cliente que la duración del proyecto consistirá en 5 meses realizándose a través de 5 fases o etapas en las cuales se cubrirá la necesidad de integración de la institución, este solo incluirá el análisis y desarrollo de las integraciones y el tiempo de implementación irá a la par del proyecto de implementación del portal. Las fases consideradas son: Análisis, diseño, construcción, pruebas y liberación, cada una con actividades y entregas distintas. En la siguiente figura se describe el timeline general del proyecto.. Figura 16. Timeline del proyecto de Integración.. A continuación, se describe de forma general cada una de las etapas del proyecto.. 27.

(38) 4.1 Fase de Análisis En esta fase se espera que el cliente exponga tanto el proceso as-is como su proceso to-be el cual permita identificar claramente las necesidades de integración requeridas a través de un documento, presentación, entrevistas o historias de usuario. Es posible que se requiera sesiones o talleres de entendimiento que aseguren el claro entendimiento del proceso, el entorno o infraestructura tecnológica y posibles riesgos que pudiesen afectar la ejecución del proyecto. También será necesario identificar los recursos o talento humano requeridos durante el proyecto junto con la identificación de los alcances y responsabilidades de cada participante englobándolos dentro del plan de trabajo para un fácil y correcto seguimiento. 4.2 Fase de Diseño A través de esta fase se tomará la información recabada y analizada para identificar la arquitectura de integración idónea que servirá de marco de referencia (framework, en inglés) para el desarrollo de los servicios junto con el middleware previamente definido para realizar un piloto de las integraciones, dicho piloto será presentado al cliente para su evaluación y autorización. Es recomendable en esta fase ya contar con los casos de pruebas para facilitar la simulación del diseño. En esta fase pueden realizarse aún ajustes a la propuesta siempre y cuando no afecten la duración e integridad del proyecto. 4.3 Fase de Construcción Durante esta fase se tomará el diseño realizado y autorizado para iniciar las actividades de desarrollo en cada uno de los componentes definidos dentro de la arquitectura de integración. No es necesario que el equipo de trabajo esté reunido ya que puede acceder remotamente a los servidores desde fuera de la red institucional. Para esta fase es de suma importancia contar con los casos/escenarios de prueba que la permitan al desarrollador la correcta ejecución de pruebas unitarias agilizando la identificación de errores y en consecuencia la reducción de tiempo de la etapa de pruebas. 4.4 Fase de Pruebas La etapa de pruebas es crucial para el proyecto debido a que puede volverse iterativa generando retrasos al proyecto. Como objetivo se busca que el cliente pueda probar varios escenarios simulando lo mejor posible su actividad en producción, de tal manera que pueda validar cada componente de su proceso. En caso de existir una falla deberá ser documentada y reportada al equipo de desarrollo para su corrección. Una vez corregido el error reportado se entregará nuevamente el sistema al equipo de pruebas para que validen su operación. Previamente se deberá preparar el ambiente con cargas de datos reales a fin de ejecutar las pruebas dentro de un escenario idóneo y confiable buscando tener la mayor similitud posible con el ambiente productivo.. 28.

(39) 4.5 Fase de Liberación En esta fase se engloban principalmente todas las actividades a realizar para la salida a producción del proyecto, esto puede incluir desde instalaciones de hardware y software, liberaciones de código, migración de datos, cierres contables, compras de certificados, entre otras actividades. El tiempo destinado para cada fase de estipulará dentro del plan de trabajo con las actividades detalladas.. 5. Configuración A través de esta sección se busca documentar todos los criterios y configuraciones requeridos para el desarrollo del proyecto. Esto incluye el proceso de negocio el cual sea soportado por la integración, los modelos y componentes que se tomarán de base para la creación de la arquitectura en la integración, y las características del middleware a implementar. Con esto se podrá realizar los desarrollos y obtener los resultados de las ejecuciones de los servicios. 5.1 Proceso de Negocio Para identificar las integraciones a desarrollar el cliente definió el proceso to-be de un proveedor el cual realiza una solicitud de pago dentro del portal, junto con la información y documentos requeridos durante todo el proceso. En la figura 17 se puede visualizar cada una de las actividades del proveedor como las tareas automáticas que realiza el portal y la solución de ECM.. 29.