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.

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.

Figura 17. Proceso de negocio deseado por el cliente

Dentro de un taller se explicó a detalle cada componente del proceso por parte del usuario y se identificó la fuente que gobierna cada información junto con el sentido de la integración afectada por cada sistema involucrado en el proceso. Se detalla el entendimiento del proceso del usuario.

 Paso 1 Inicio del proceso. Para iniciar proceso, el proveedor debe autenticarse dentro del portal de la institución, el cual deben estar registrados sus datos en la base de datos del portal.

 Paso 2 Muestra las órdenes de compra y las entradas de mercancía del proveedor. Una vez el proveedor conectado en el portal, este podrá ver las órdenes de compras que estén asignadas a él previamente capturadas dentro del sistema ERP de la institución por el área de compras. Adicional podrá ver las entradas de mercancía realizadas por cada orden de compra y documentadas por el área de almacenes.

 Paso 3 Proveedor ingresa factura u otro documento de soporte. Una vez el proveedor haya visualizado el registro de la mercancía entregada puede proceder a solicitar el pago de dichas entradas, esto derivado de la política de flexibilidad y tolerancia de la institución de permitir

facturar parcialidades de un pedido y no esperar a que el pedido esté completo. Para esto es necesario que el proveedor suba los documentos necesarios que justifiquen su solicitud.

 Paso 4 Validación de three-way match. Una vez subidos los documentos necesarios al portal, se lanza la comprobación automática la cual valida los registros del pedido (orden de compra), las entradas de mercancía realizadas y los datos de la factura coincidan entre ellos, evitando así errores o fraudes. Además, incluye validaciones básicas de montos y RFC (Registro Federal de Contribuyentes) y validaciones fiscales ante SAT (Servicio de Administración Tributaria).

 Paso 5 Cambia estatus de factura a rechazada. Cuando una factura no sea válida, el proceso rechaza la factura y notifica al proveedor para que realice los ajustes necesarios y repita el proceso, además cambia su estatus de solicitud a rechazada en el portal.

 Paso 6 Guarda la factura en el repositorio. Cuando la factura es válida por el proceso de three-

way match, el sistema guarda la factura en el repositorio de ECM y se dispara el worflow de

autorizaciones.

 Paso 7 Requiere de Autorización. Por políticas de la institución, ciertas solicitudes de facturas son candidatos para una autorización automática, solo entraran dentro del proceso manual aquellas que no cumplan con las políticas de pago de la institución o requiera de una revisión manual.

 Paso 8 Notificar al autorizador. Cuando la factura requiera ser autorizada manualmente se le notifica al personal de pagos junto con la ubicación de los documentos de la solicitud para su revisión. El sistema distribuye en automático la carga a los autorizadores.

 Paso 9 Entra personal del Tec al portal para autorizar o rechazar las facturas. Una vez recibida la notificación, el autorizador entra al portal para cambiar el estatus de una factura en aprobado o rechazado agregando un comentario el cual es enviado al proveedor para dar un mayor contexto del estatus.

 Paso 10 Validación de factura autorizada. El workflow valida que la factura esté en un estatus de autorizada, en caso de la factura no fuese aprobada se guarda en el contenedor de facturas rechazadas dentro del ECM para futuras referencias.

 Paso 11 Notificación al proveedor del estatus. Cuando la factura es autorizada, se le envía una notificación al proveedor para que esté enterado lo más pronto posible del nuevo estatus de la solicitud.

 Paso 12 Cambio de estatus de factura a aprobada. El workflow lanza un proceso que ajusta el estatus de la solicitud del portal en aprobada, el cual permita al proveedor visualizar su estatus en cualquier momento que se conecte al portal.

 Paso 13 Realiza registro contable. En este proceso se requiere una integración que permita generar la factura dentro del ERP y el documento contable, los cuales son requisito para la generación de un documento de pago.

 Paso 14 Realiza propuesta de pago. Una vez registrada la factura en el ERP se procede de forma manual a realizar una promesa de pago y se guarda la factura en el contenedor de documentos correspondiente de ECM el cual permita ser identificado más fácilmente.

 Paso 15 Cambio de estatus de factura a fecha de pago. El workflow lanza un proceso que ajusta el estatus de la solicitud del portal en fecha de pago, el cual permita al proveedor visualizar su estatus en cualquier momento que se conecte al portal.

 Paso 16 Actualiza datos de pago. Una vez recibida la confirmación de pago por parte del banco en el ERP, se envía la confirmación al portal para que ajuste el estatus de la solicitud a pagada.

 Paso 17 Cambia estatus de factura a pagada. El workflow lanza un proceso que ajusta el estatus de la solicitud del portal en pagada, el cual permita al proveedor visualizar su estatus en cualquier momento que se conecte al portal.

 Paso 18 Genera el comprobante de pago. Con los datos recibidos por SAP, el ECM genera de forma automática los comprobantes de pagos y los relaciona con la factura para que el proveedor pueda descargarlos o imprimirlos en cualquier momento vía portal. Se procede a almacenar ambos documentos en un contenedor del ECM para efectos fiscales.

 Paso 19 Se almacena la factura como Histórico de Pagos. Por último, se guardan los documentos obtenidos durante la ejecución del workflow dentro del contenedor histórico de ECM donde se guardan las facturas pagadas por la institución, esto en caso de alguna reclamación, seguimiento u auditoria.

Se detecta que la información de órdenes de compra y entradas de mercancía existen dentro del ERP Institucional gobernados por los procesos del negocio de compras y almacenes, se requiere que exista una integración que replique la información al portal para efectos de validación y visualización.

De manera de resumen se identificaron las siguientes necesidades de integración provenientes del proceso to-be deseado por la institución y que permita la comunicación entre el sistema ERP legado y el portal de proveedores.

 Réplicas de Órdenes de Compra

 Réplicas de Entradas de Mercancías

 Registro de Facturas