Proyecto de actualización del sistema de información de PNUD de El Salvador Versión 2 Vicent-Ramon Palasí Lallana Programa de las Naciones Unidas para.

1 Proyecto de actualización del sistema de información de...
Author: Sanchia Carolus
0 downloads 0 Views

1 Proyecto de actualización del sistema de información de PNUD de El Salvador Versión 2 Vicent-Ramon Palasí Lallana Programa de las Naciones Unidas para el Desarrollo en El Salvador.

2 Datos de contacto de Vicent Palasí Postal: Vicent-Ramon Palasí Lalllana. Calle Blasco Ibáñez, 103. La Vall d’Uixó (Castellón). España. Teléfonos: (+503) 964696025, (+503) 964697666. El más práctico: [email protected] (revisado varias veces al día)

3 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

4 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

5 Objetivo de esta exposición Presentar el resultado de mi trabajo de análisis del sistema de información de PNUD de El Salvador. Este resultado incluye información sobre: –Oportunidades de mejora del sistema actual. –El sistema de información propuesto para el futuro. –El método recomendado para implementar el sistema.

6 Experiencia profesional Formación: –Licenciado en Informática. Universidad Politécnica de Cataluña –Doctorado (Ph.D) en Informática. Universidad de Castellón –Maestría en NNTT aplicadas a la Educación. Universidad Carlos III de Madrid. 15 años de experiencia profesional en España y El Salvador. Sobre todo, en desarrollo de software y gerencia: Director de Informática de la Defensoría del Consumidor. Ev. Jacir Lovo. Gerente General de Aurum Solutions. Secretaría Técnica. Claudia Monzón. Profesor de varias universidades españolas y Director Académico en UFG. Roberto Mestanza. Martínez Perdomo Experiencia en cooperación internacional: AECI, ONGs. Experiencia en auditoría ISO9000, reingeniería de procesos y formación en Administración por procesos.

7 Mi trabajo en el PNUD de El Salvador Voluntario y sólo medio mes/hombre. Análisis de los procedimientos y sistemas informáticos de la oficina. Más concretamente: –Entrevistarme con gerentes y empleados para determinar las necesidades de información de la oficina. –Analizar los procedimientos administrativos. –Analizar los sistemas informáticos existentes en la actualidad. –Realizar propuestas de mejora en procedimientos y sistemas informáticos y mejorarlas con las aportaciones de gerentes y empleados. Se ha centrado en las unidades administrativas.

8 Productos de la consultoría La presente presentación (aprox. 180 transparencias) que explica los principales hallazgos y propuestas fruto de la consultoría. Comprende toda la organización. Una presentación (139 transparencias) que explica con detalle las oportunidades de mejora en la Unidad de Adquisiciones. Una presentación (166 transparencias) que explica con todo detalle las oportunidades de mejora en el Centro de Servicios, Recursos Humanos y Finanzas.

9 Sin embargo Aquí no tendremos tiempo de ver todo esto. Sólo veremos la presentación global y de ella sólo una parte. Cuando han detalles que se explican en las otras presentaciones lo indicaremos. De todas maneras, todo lo mencionado queda escrito para analizarlo con calma, para usarlo como material de consulta y como punto de partida del trabajo posterior.

10 Agradecimientos por un buen trabajo en equipo Claudia Monzón. Adquisiciones. –Misalia Quiñonez. –Hugo Barillas. Centro de Servicios –Marvin Santos. –Marielos. –Sonia. Recursos Humanos. –Nelson Amaya. Finanzas. –Rolando.

11 Y si hay alguna incorrección El responsable es aquel que menos conoce la organización.

12 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

13 Objetivo de esta exposición Presentar el resultado de mi trabajo de análisis del sistema de información de PNUD de El Salvador.

14 Sistema de información Conjunto de personas, registros y actividades (manuales o automáticas) que gestionan la información necesaria para el funcionamiento de una organización. Consta de dos componentes: –Los procedimientos que se ejecutan en la organización. –La tecnología (papel o automática) que se usa para ejecutarlos.

15 La gestión de la información Es vital en cualquier organización. Es mucho más vital en las unidades administrativas del PNUD de El Salvador, que son una organización de procesamiento de la información. No hay nada físico que se produzca en el PNUD: todo lo que se produce y con lo que se trabaja es información. –Se recibe información de agentes externos (contrapartes, oferentes, etc). –Se emite información a agentes externos –Internamente, se trabaja con información (la información se pasa de un departamento a otro y se transforma por los diversos usuarios).

16 Para decirlo de forma un poco simplista Las unidades administrativas del PNUD son una máquina que recibe información, la transforma y la transmite. PNUD Información entrada Información salida Se procesa (transforma) información

17 Por ejemplo, la Unidad de Adquisiciones Recibe información de la requisición de la contraparte. Trabaja con información sobre la lista de proveedores y sobre sus ofertas. Produce información sobre el proveedor seleccionado, los servicios o productos que va a ofrecer y su precio. Adquisiciones Información Requisición Información Adjudicación Se procesa (evalúa, se decide) información

18 Mejorar el sistema de información En el PNUD es mejorarlo todo: –Mejorar el funcionamiento interno. Reducir la carga de trabajo de los empleados. Reducir los tiempos de procesamiento. Permitir una mejor calidad del trabajo. –Mejorar las relaciones con el exterior Reducir los tiempos de respuesta de la oficina. Proporcionar más información a los agentes externos. En general, dar un mejor servicio a la sociedad.

19 Mejorar el sistema de información Es mejorar los dos componentes de los que consta: –Los procedimientos que se ejecutan en la organización. –La tecnología (papel o automática) que se usa para ejecutarlos. Mi consultoría se ha realizado en los dos aspectos, pero con especial énfasis en el segundo.

20 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

21 Procedimientos que se han analizado en esta consultoría 1.Procedimiento de adquisiciones. 2.Procedimiento de planillas. 3.Procedimiento de requisiciones de contrato. 4.Procedimiento de requisiciones de bienes, servicios y obra. 5.Procedimientos PO (de creación de orden de compra). 6.Procedimiento de entrega (de bienes, servicios y obra). 7.Procedimiento de pagos. 8.Procedimiento financiero (ciclo de pago y similares).

22 Procedimientos que se han analizado en esta consultoría 1.Procedimiento de adquisiciones. 2.Procedimiento de planillas. 3.Procedimiento de requisiciones de contrato. 4.Procedimiento de requisiciones de bienes, servicios y obra. 5.Procedimientos PO (de creación de orden de compra). 6.Procedimiento de entrega (de bienes, servicios y obra). 7.Procedimiento de pagos. 8.Procedimiento financiero (ciclo de pago y similares). Las presentaciones de Adquisiciones y de Centro de Servicios, Recursos Humanos y Finanzas contienen el análisis completo y detallado de estos procedimientos. Aquí sólo se mencionan muy rápidamente y casi sin explicar.

23 Relación detectada entre procedimientos Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

24 Los procedimientos administrativos en el PNUD Aspectos positivos. Funcionan: –Cumplen su función. –Están probados por la experiencia. Aspectos negativos. Pueden mejorarse (con la experiencia): –Existen pasos que añaden trabajo pero no añaden valor. Se desperdicia trabajo, es decir, dinero. Se reduce el tiempo de respuesta. –Poca estandarización en algunas partes del procedimiento. –La integración de unidades no es óptima. –La mayor parte del procedimiento no está informatizada. Esto lo veremos después.

25 Front Office RRHH Elabora planilla Revisa planilla Elabora pago Creación lote Aprobac ión lote MarielosNelsonMarielosFinanzas [Otros casos] [Sal. + de 1] Finanzas Pasos que no añaden valor: Procedimiento actual de planillas Entrar datos Marielos Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Revisión aprobación Procedimiento financiero 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvin Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Pertinente] Paquete [No pertinente] [No aprobado] Paquete ProyectoFinanzas Aviso de transferencias Lista transf.

26 Voucher Atlas Aprobar Atlas Aprobador [No aprobado] Proyecto Finanzas Subir lote Aprobac ión lote Finanzas [Otros casos] [Sal. + de 1] Front Office Procedimiento propuesto de planillas Entrar datos Marielos Procedimiento financiero Aviso de transferencias Finanzas Sonia Lista transf. Pa que te Marvin Una vez se han eliminado los pasos superfluos y se ha mecanizado la generación de planillas

27 Diferencias entre el procedimiento actual y el propuesto Procedimiento actualProcedimiento propuesto 14 etapas7 etapas 9-10 cambios de Departamento 3-4 cambios de Departamento El cambio reduce dramáticamente el tiempo de respuesta y el trabajo necesario para realizar la planilla. Liberando trabajo para realizar otras acciones.

28 Conclusión Los procedimientos administrativos pueden y deben mejorarse. –Simplificación y estandarización. –Integración de unidades. –Tecnología. El último aspecto lo veremos a continuación y los dos primeros más adelante.

29 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

30 Bajo nivel de tecnología usado en los procedimientos La mayoría de etapas no se incluyen en Atlas y se realizan en papel, por lo que: –El tiempo y trabajo empleados mucho mayor al necesitado (poca eficiencia). –Menor control y calidad en los procedimientos. No se cuenta con: Generación automática de los cálculos por el sistema. Reportes que sirvan para la toma de decisiones. Estadísticas que permitan evaluar la eficiencia. Un mejor control y gestión por parte de los empleados y coordinadores. Sistema de información automático para agentes externos (contrapartes, oferentes, etc).

31 Solución: Un nuevo programa de computadora Que mecanice todo lo que sea posible mecanizar. Que aporte todas las ventajas que se acaban de explicar. Un solo programa pues: –Las diferentes unidades tienen necesidades similares: la mecanización de sus procedimientos de workflow. –Casi cada procedimiento involucra varias unidades. –La información debe ser completamente integrada. –Se necesitan estadísticas y reportes globales..

32 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

33 En este apartado Veremos los aspectos generales del programa de computadora. Estos aspectos se aplicarán a todos los procedimientos (más adelante, veremos los aspectos específicos de cada procedimiento). Como ejemplo, veremos el procedimiento de pagos directos simplificado.

34 Este es el procedimiento de pagos simplificado Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Procedimiento financiero Aviso y recogida Cheques Archivo cheques 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvinSonia Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Perti nente] Paquete [No pertinente][No aprobado] Lista transf. Lista cheques Paquete cheques Paquete cheques ProyectoFinanzas Paquete Tal como se propone en esta consultoría. Nos servirá de ejemplo.

35 Características principales del programa Es una aplicación Web: se accede desde un navegador con acceso a Internet. –Accesible sin restricciones de tiempo ni localización geográfica. Los gerentes pueden acceder cuando se encuentren en misión en otros países. También pueden acceder los agentes externos al PNUD (contrapartes, oferentes, etc). –Más fácil de mantener, actualizar y corregir. Usuarios: –Empleados del Front Office y Centro de Servicios. –Empleados del proyecto. –Finanzas. –Recursos Humanos. –Adquisiciones.

36 Seguridad del programa Es una aplicación Web pero segura en los datos. No se puede acceder a ninguna página sin haberse autenticado. A medio plazo habría que plantearse que toda la información viaje por Internet encriptada con SSL.

37 El programa mecaniza la planificación de los procedimientos administrativos Estos son procedimientos de workflow: –Una serie de etapas fijas que se desarrollan de forma secuencial. –Cada etapa es realizada por un usuario determinado.

38 El programa debe ser un programa de workflow Un programa de workflow es aquel que: –Es el programa el que le recuerda al usuario lo que tiene pendiente en cada momento. –Es el programa el que, cuando un usuario acaba una tarea, la asigna al usuario siguiente. –La idea es que la coordinación entre personas la haga el programa, no los usuarios.

39 Entrando al programa Se abre un navegador y se escribe www.pnud.org.sv/programa.html. Aparece una página donde el usuario debe autenticarse. www.pnud.org.sv/programa.html

40 Una vez se entra al programa Aparece la página principal de trabajo, donde aparecen las tareas que están pendientes de realizar por el usuario.

41 Las tareas pendientes están agrupadas por fecha de finalización Cada etapa tiene un período en el que se debería finalizar, según se define en el procedimiento y puede ser modificado para cada proceso.

42 Ventaja de esta interfaz El usuario puede estimar fácilmente la carga de trabajo y priorizar las tareas más urgentes. También puede ver si se le está acumulando el trabajo. El usuario no tiene un montón de menús y opciones por las que debe navegar. Sólo le aparecen las tareas que puede realizar en cada instante. Como resultado, la página principal de trabajo es diferente para cada usuario.

43 Supongamos que hacemos clic en el enlace “Atrasados más de una semana” Como vemos hay dos tareas.

44 Aparece una página con todas las tareas que están atrasadas más de una semana Cada una tiene una descripción breve, que es a la vez un enlace. Si hacemos clic en el enlace, obtendremos más información y podremos realizar la tarea.

45 Vemos que la 1a tarea se refiere a la etapa de control documental Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Procedimiento financiero Aviso y recogida Cheques Archivo cheques 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvinSonia Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Perti nente] Paquete [No pertinente][No aprobado] Lista transf. Lista cheques Paquete cheques Paquete cheques ProyectoFinanzas Paquete Que es la etapa marcada roja aquí. Si hacemos clic en el primer enlace (el que comienza con 251)…

46 …nos apare- ce esta página

47 Por una parte tenemos datos informativos. Estos no los podemos modificar: son para nuestra información

48 Por otra parte, tenemos los datos que debemos rellenar para completar la tarea. Estos los debemos modificar

49 En nuestro caso, sólo hay que hacer clic al lado de las condiciones que cumple la solicitud. Fijémonos que la firma, la fecha y la hora no aparecen: las pone directamente el programa.

50 Cuando acabemos de hacer clic en las condiciones, debemos oprimir el botón “Finalizar tarea”

51 Cuando se hace clic en “Finalizar tarea” El proceso desaparece de la lista de tareas pendientes (ver dibujo). Pasa a la siguiente etapa y aparece como tarea pendiente en la siguiente etapa al usuario que le corresponde (que podría ser él mismo).

52 En este caso, la etapa siguiente es la de creación del voucher Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Procedimiento financiero Aviso y recogida Cheques Archivo cheques 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvinSonia Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Perti nente] Paquete [No pertinente][No aprobado] Lista transf. Lista cheques Paquete cheques Paquete cheques ProyectoFinanzas Paquete Que es la etapa marcada roja aquí. Y que corresponde a Marvin Entonces, cuando Marvin entre al programa, encontrará esta tarea dentro de la lista de pendientes.

53 Así, por ejemplo, Marvin encontrará algo como esto Ha aparecido una nueva tarea en la lista de pendientes así como una nota de nuevas tareas.

54 Cuando hacemos clic en el enlace “A realizar antes de una semana” o en el enlace “Tienes tareas nuevas” Aparece esta tarea, que antes estaba como pendiente de Sonia. Ahora ha desaparecido de Sonia y es tarea pendiente de Marvin.

55 Algunas ventajas Queda registrada automáticamente la fecha en que se finalizó esa etapa. El programa puede general reportes con los tiempos que ha durado cada tarea, etc. Todo ello con el único esfuerzo de que el usuario haga clic en “Finalizar tarea”. Un programa muy sencillo y, además, el usuario se le recuerda continuamente cuáles son las tareas a realizar.

56 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

57 2.1.2. Otros aspectos importantes 2.1.2.1. Funciones para los Directores y Gerentes 2.1.2.2. Funciones para los oferentes y contrapartes 2.1.2.3. Reportes. 2.1.2.4. Otras funciones.

58 Los Directores de unidades Cuando entran al programa obtiene una página principal un poco diferente que la de los otros usuarios. Es la que se muestra en la siguiente transparencia. Al contrario que los otros usuarios, los Coordinadores: –no sólo ve los procesos que tiene pendientes ellos mismos (en rojo en la transparencia). –sino que ve los procesos que tienen pendientes todos sus subordinados (en verde en la transparencia). Así tiene la información global que precisa para coordinar su unidad.

59

60 De la misma manera La Alta Gerencia (como, por ejemplo, la Representante Residente) puede entrar en el programa y ver el estado global de los procesos de la institución. También puede generar todos los reportes, estadísticas y gráficos de barra y de pastel que necesite.

61

62 2.1.2. Otros aspectos importantes 2.1.2.1. Funciones para los Directores y Gerentes 2.1.2.2. Funciones para los oferentes y contrapartes 2.1.2.3. Reportes. 2.1.2.4. Otras funciones.

63 Los oferentes son también usuarios del programa Se les da un usuario y una contraseña. Pueden entrar y les aparece una lista de los procesos de adquisición en los que están involucrados.

64 Los oferentes son también usuarios del programa Por cada proceso de adquisición, haciendo clic pueden ver –El nombre y número del proceso. –La etapa del proceso y la fecha prevista de finalización. –El responsable de esa etapa.

65 Además Si el oferente deja una dirección electrónica, cada cierta cantidad de días (que él puede elegir) le llegará un correo electrónico con el estatus de los procesos de adquisición en los que está involucrado. Asimismo, le llegará un correo electrónico a cada oferente después de la adjudicación. Cada mes se enviará un correo electrónico al administrador del proyecto.

66 También para las contrapartes Cada contraparte (otras agencias de la ONU, los proyectos de fuera y dentro de la ONU, el Ministerio, etc) podrá entrar con su usuario y contraseña. Podrá ver todos los procesos que tiene pendiente con el PNUD de El Salvador.

67 2.1.2. Otros aspectos importantes 2.1.2.1. Funciones para los Directores y Gerentes 2.1.2.2. Funciones para los oferentes y contrapartes 2.1.2.3. Reportes. 2.1.2.4. Otras funciones.

68 Reportes El programa puede generar todos los reportes que se necesiten: –Reportes que ahora se realizan a mano. –Reportes que facilitan la toma de decisiones. –Estadísticas sobre tiempo de respuesta, carga de trabajo por usuario, atrasos, evolución durante el transcurso del tiempo, etc. –Gráficos de barra y de pastel.

69 Reportes Algunos de estos reportes han sido definidos en las otras presentaciones. Otros reportes se deberán definir Otros reportes se deberán crear mientras se necesiten. También el programa tiene una herramienta para generar reportes sin necesidad de programar a partir de: –Datos de Atlas. –Datos del Programa. –Datos combinados de Atlas y del Programa. Esto lo veremos más adelante, cuando veamos la integración en Atlas.

70 2.1.2. Otros aspectos importantes 2.1.2.1. Funciones para los Directores y Gerentes 2.1.2.2. Funciones para los oferentes y contrapartes 2.1.2.3. Reportes. 2.1.2.4. Otras funciones.

71 El programa también tiene funciones Para buscar un proceso según una combinación de criterios. Para manejar la documentación que no puede digitalizarse (facturas, recibos, etc.) Para incorporar códigos de barras. Para incorporar alertas para las tareas más urgentes. Todo esto se explica con detalle en las presentaciones de Adquisiciones, Front Office, Planillas y Finanzas.

72 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

73 Arquitectura funcional del programa Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos El programa mecaniza todas las necesidades de información de todas las unidades del PNUD. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

74 Arquitectura funcional del programa Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Las diferentes unidades comparten un único procedimiento e intercambian información. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

75 Arquitectura funcional del programa Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Todas las unidades usan una serie de módulos comunes: usuarios, proveedores, contrapartes e integración con Atlas. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

76 Arquitectura funcional del programa Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos El usuario ve el programa como un único programa, sin que se vea la diferencia entre unidades. Porque el programa integra los procedimientos de diferentes unidades. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

77 Avance de la consultoría Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos En medio mes/hombre, se ha avanzado mucho los módulos en verde, se ha avanzado bastante los módulos en amarillo y no se ha trabajado en absoluto el módulo en rojo. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

78 Avance de la consultoría Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos A partir de ahora, veremos cada uno de esos módulos por separado. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

79 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

80 Comencemos con el módulo de adquisiciones Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

81 Los procedimientos en los que la Unidad de Adquisiciones está más involucrada Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

82 El procedimiento más importante es en el de adquisiciones Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

83 Revisar informe Emitir informe Procedimiento actual de adquisiciones Recepción requisición Pertinencia Asignar adquisición Recibe docu. PliegoInvita Enviar Contra. Recibir Contra. Extender gar. oferta Devolver gar. oferta Obtener gar. cumpl Devolver gar. cumpl Extender gar. cumpl. Obtener gar. obra Devolver gar. obra Extender gar. obra Recibir ofertas Decisión CAP Registro ACP Elabora nota. Revisa nota. [>30k] [ DA] [Aprobado] [Aprobado y

84 No se ha hecho reingeniería del procedimiento de adquisiciones Al contrario que con el resto de procedimientos, pues habría que ver si es posible simplificarlo sin: –Salirse de las directrices mundiales del PNUD para los procesos de adquisiciones. –Garantizar la imparcialidad y la imagen de imparcialidad.

85 En general Este procedimiento se ha explicado con mucho detalle como computarizarlo. Esto se encuentra en la presentación de adquisiciones. El procedimiento de adquisiciones es el que está completamente especificado y detallado. Con la información que se ha dejado ya habría bastante para comenzar a programar.

86 Veamos ahora el procedimiento PO Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

87 Procedimiento PO Adquisiciones Genera PO Aprobar o Firmar PO Procedimie nto entrega Adm. proyecto Adquisiciones Viene del proced. de requisiciones de bienes, servicios y obra (ver Front Office) PO Proyecto Proveedor Se da cuando adquisiciones genera una orden de compra (PO). Se explica con más detalle en las otras presentaciones. Dispatch. Envío PO. PO [No aprobado] [Aprobado]

88 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

89 Ahora veremos el módulo de Centro de Servicios Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

90 Procedimientos que rige el Centro de Servicios Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

91 Procedimientos del Centro de Servicios Aquí sólo se explican los resultados resumidos del estudio de estos procedimientos. Todo el análisis y la explicación de la simplificación y reingeniería de estos procedimientos se encuentran en la presentación del Centro de Servicios.

92 Veremos ahora el procedimiento de pagos Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

93 Procedimiento actual de pagos directos Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Revisión aprobación Procedimiento financiero Aviso y recogida Cheques Archivo cheques 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvin Sonia Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Viene del proced. entrega. Docum. Solicitud L. verif Docum. [Pertinente] Paquete [No pertinente][No aprobado] Paquete Lista transf. Lista cheques Paquete cheques Paquete cheques ProyectoFinanzas La solicitud+lista verificación+documentación se abrevia como “paquete”.

94 Procedimiento propuesto de pagos directos Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Procedimiento financiero Aviso y recogida Cheques Archivo cheques 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvinSonia Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Solicitud L. verif Docum. [Perti nente] Paquete [No pertinente][No aprobado] Lista transf. Lista cheques Paquete cheques Paquete cheques ProyectoFinanzas Paquete Se han reducido tres comunicaciones y 1 tarea: –Generando el voucher antes de la pertinencia. –Prescindiendo de la revisión de la aprobación Viene del proced. entrega. Docum.

95 Diferencias con el procedimiento actual Procedimiento actualProcedimiento propuesto 9 etapas8 etapas 8 cambios de Departamento 4 cambios de Departamento Esto debe reducir el tiempo de respuesta a más de la mitad.

96 Veremos ahora el procedimiento de requisiciones de bienes Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

97 Procedimiento actual de requisiciones de bienes, servicios y obras Genera requisición Front Office Control documental Pertinencia requisición Revisar pertinencia Procedimie nto PO 1a autoridadAdm. proyecto SoniaMarvin Requis. Docum. Requis. L. verif Docum. [Inco rrecto] [Correcto] Solicitud L. verif Docum. [Pertinente] Paquete [No pertinente] Proyecto Adquisiciones La requisición+lista verificación+documentación se abrevia como “paquete”.

98 Procedimiento propuesto de requisiciones de bienes, servicios y obras Genera requisición Front Office Control documental Pertinencia pago Procedimie nto PO 1a autoridadAdm. proyecto Sonia Requis. Docum. Requis. L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Perti nente] [No pertinente] Proyecto Adquisiciones Si lo enviamos de administrador del proyecto a adquisiciones directamente, nos ahorramos un paso y una comunicación, con lo que se reduce el tiempo.

99 Veremos ahora el procedimiento de requisiciones de contrato Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

100 Procedimiento actual de requisiciones de contrato Genera requisición Front Office Control documental Pertinencia requisición Revisar pertinencia Resto del proceso 1a autoridadAdm. proyecto SoniaMarvin Requis. Docum. Requis. L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Pertinente] Paquete [No pertinente] Proyecto RRHH Es el mismo que el anterior pero acaba en Recursos Humanos y no en adquisiciones.

101 Procedimiento propuesto de requisiciones de contrato Genera requisición Front Office Control documental Pertinencia pago Resto del proceso 1a autoridadAdm. proyecto Sonia Requis. Docum. Requis. L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Perti nente] [No pertinente] Proyecto RRHH Si lo enviamos de administrador del proyecto a Recursos Humanos directamente, nos ahorramos un paso y una comunicación, con lo que se reduce el tiempo.

102 Estos son procesos muy sencillos pero aún se pueden simplificar Procedimiento actualProcedimiento propuesto 5 etapas4 etapas 4 cambios de Departamento 3 cambios de Departamento Esto debe reducir el tiempo de respuesta a más de la mitad.

103 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

104 Ahora veremos el módulo de Finanzas Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

105 Finanzas El módulo de Finanzas interviene en el procedimiento de pagos directos que hemos visto (concretamente, en la etapa de archivos). También la mayor parte del procedimiento financiero (que se muestra a continuación) se realiza dentro de la unidad financiera.

106 Veremos ahora el procedimiento financiero Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

107 Procedimiento financiero Revisar documenta. Che ques [No correcta] [No correcto] Impresión cheques Front Office Control de calidad Firma inicial Firma gerencia Rellenar Datos Atlas Iniciar EFT en Atlas Proceso EFT Revisión transferen. [Cor rec ta] [Transfe rencias] [Cheques] Procedim. pagos [Cor rec to] Che ques Che ques Cheques Doc. Lista transf. Docum. Doc. Victor/Francisco Rolando RR/Peter Victor/Francisco ExternoRolando Externos Finanzas Viene de proced. pagos Este puede considerarse parte del procedimiento de pagos. Gerencia

108 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

109 Ahora veremos el módulo de Recursos Humanos Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

110 Se ha hecho la reingeniería del procedimiento de planillas Como siempre, aquí sólo se explican los resultados resumidos del estudio de estos procedimientos. Todo el análisis y la explicación de la simplificación y reingeniería del procedimiento se encuentran en la presentación de Recursos Humanos.

111 Veremos ahora el procedimiento de planillas Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

112 Front Office RRHH Elabora planilla Revisa planilla Elabora pago Creación lote Aprobac ión lote MarielosNelsonMarielosFinanzas [Otros casos] [Sal. + de 1] Finanzas Procedimiento actual de planillas Entrar datos Marielos Genera soli- citud pago Front Office Control documental Pertinencia pago Voucher Atlas Aprobar Atlas Revisión aprobación Procedimiento financiero 1a autoridadAdm. proyectoAprobadorFinanzas SoniaMarvin Solicitud Docum. Solicitud L. verif Docum. [Inco rrecto] [Correcto] Docum. Solicitud L. verif Docum. [Pertinente] Paquete [No pertinente] [No aprobado] Paquete ProyectoFinanzas Aviso de transferencias Lista transf.

113 Voucher Atlas Aprobar Atlas Aprobador [No aprobado] Proyecto Finanzas Subir lote Aprobac ión lote Finanzas [Otros casos] [Sal. + de 1] Front Office Procedimiento propuesto de planillas Entrar datos Marielos Procedimiento financiero Aviso de transferencias Finanzas Sonia Lista transf. Pa que te Marvin Una vez se han eliminado los pasos superfluos y se ha mecanizado la generación de planillas

114 Diferencias con el procedimiento actual Procedimiento actualProcedimiento propuesto 14 etapas7 etapas 9-10 cambios de Departamento 3-4 cambios de Departamento Los cambios de Departamento son unos de los cuellos de botella más importantes de nuestro procedimiento.

115 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

116 Ahora veremos el módulo de Proyectos Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

117 Proyectos Los procedimientos en los que intervienen los proyectos ya han sido mencionados cuando hablábamos de adquisiciones, centro de servicios, finanzas o recursos humanos. Sólo nos queda por ver el procedimiento de entrega de bienes y servicios, en el cual interviene el proyecto.

118 Veremos ahora el procedimiento de entrega Proced. requisici. contrato Proced. requisici. bienes, serv. Proced PO. Proced entrega Proced. pagos Proced. financiero Procedim. planilla Proced. adquisic. [Sin orden de compra] [Con orden de compra] Procedimientos de compras y pagos Procedimientos de personal Proc. competitivos

119 Procedimiento de entrega de los bienes y servicios Proyectos (con NEX) y Centro de Servicios (con DEX) Entrega producto Proyecto o Centro de Servicios Viene del proced. PO si hay orden de compra o comienza aquí si no hay orden de compra Documento de facturación Proveedor Cuando se entrega los bienes y servicios al proyecto. Proced. de Pagos directos Recibir factura Proveedor

120 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

121 Ahora veremos los módulos de Unidades no administrativas Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

122 Unidades no administrativas No se han trabajado en absoluto las necesidades informáticas de las unidades administrativas. Se ha tenido poco tiempo y lo más urgente eran las unidades no administrativas. Sin embargo, “a veces lo urgente no deja paso a lo importante”. También las unidades administrativas tienen necesidades importantes y no se deberían dejar de lado.

123 Algunas necesidades informáticas que podrían tener las unidades no administrativas Control del avance de los proyectos y del cumplimiento de metas (desde la Gerencia y los empleados). Coordinación y comunicación entre los diferentes actores del proyecto (PNUD, contrapartes, comunidades, medios de comunicación, otras agencias de la ONU, etc). Coordinación y comunicación entre los diferentes empleados del PNUD y la Gerencia. Creación automática de estadísticas y notas para los medios de comunicación.

124 ¡¡Pero si esto ya lo hacemos!! Se trata de hacerlo: –Con menos esfuerzo y tiempo. –Con más calidad. –Con más control. Y así poder hacer más cosas con el mismo esfuerzo.

125 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

126 Módulos de servicios Son los módulos que utilizan todos los otros módulos, pues proveen servicios comunes que son necesitados en todo el programa. Vamos a describirlos brevemente.

127 Ahora veremos el módulo de Usuarios y Seguridad Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

128 Módulo de usuarios y seguridad Es el que se ocupa de: –Impedir el acceso al programa a quien no sea usuarios autorizados. –Reconocer cada usuario autorizado y darle acceso a las funciones que le corresponden. –Mostrar a cada usuario las tareas pendientes. –Una vez un usuario ha acabado una tarea, pasar la tarea al siguiente usuario en el procedimiento.

129 Ahora veremos el módulo de Proveedores Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

130 El módulo de proveedores Es la base de datos de proveedores que el Comité de Tecnología ha especificado. Funciones: –Cargar los datos del proveedor (por el mismo proveedor o por el usuario del PNUD). –Categorizar los productos y servicios ofrecidos. –Generará un cuadro de seguimiento (dashboard) para identificar tendencias. –Generar reportes y estadísticas. Será compartida con otras agencias de la ONU.

131 El módulo de proveedores Además, como hemos visto, cada proveedor (u oferente) tiene usuario y contraseña y puede entrar al programa: –Puede consultar el estado de los procesos del PNUD en los que está involucrado. –Asimismo, recibirá notificación por correo electrónico de las gestiones, lo que podrá configurar. –También podría generar algunos reportes.

132 Ahora veremos el módulo de Contrapartes Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

133 El módulo de contrapartes Como con los proveedores, cada contraparte (proyecto, agencia de la ONU, Ministerios, etc) tiene usuario y contraseña y puede entrar al programa: –Puede consultar el estado de los procesos del PNUD en los que está involucrada. –Asimismo, recibirá notificación por correo electrónico de las gestiones, lo que podrá configurar. –También puede generar reportes.

134 Ahora veremos el módulo de Integración con Atlas Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

135 Los problemas Los reportes que saca Atlas son demasiado detallados, por lo que hay que quitarle datos para pasarlos a las contrapartes, oferentes, etc. Esto consume muchísimo tiempo y son tareas rutinarias y repetitivas. Además, Atlas no tiene todos los datos, porque no mecaniza todos los procedimientos. Es el programa que se va a desarrollar el que tiene todos los datos: los de Atlas y muchos más.

136 Lo propuesto en los términos de referencia No es factible, pues los datos transformados pueden ser cualquier cosa y no se va a saber cómo combinarlos con el nuevo programa. Programa Atlas Transformar datos Nuevo programa Combinar y elaborar datos Elegir presentación Datos en csv o xls Datos transformados Datos combinados Reporte

137 La solución que funcionaría Programa Atlas Combinar datos Nuevo programa Transformar y elaborar datos Elegir presentación Datos en csv o xls Datos elaborados Reporte Datos combinados Cómo sabemos cuáles son los datos del nuevo programa podemos combinarlos sin problemas.

138 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

139 ¿Cómo implementar este sistema de información? La consultoría para actualizar el sistema de información de una organización se compone de dos aspectos diferentes: –El sistema de información que se desea implementar. El QUÉ. –El método con el cual se implementará el sistema. El CÓMO. Hasta ahora sólo hemos descrito el primer aspecto. De nada sirve pintar un futuro brillante si no se sabe cómo llegar a él. Por ello, a partir de ahora nos centraremos en el segundo aspecto.

140 Los procedimientos Un sistema de información consta de los procedimientos y del programa que los implementa. Veremos primero los procedimientos Hay que hacer un estudio integral del funcionamiento del PNUD para rediseñar los procedimientos con el fin de evitar pasos inútiles. Algunos procedimientos ya han sido rediseñados en esta consultoría. Pero hay que continuar con los otros.

141 3. Método para implementar el programa 3.1. ¿Por qué es especialmente importante en este caso elegir un método adecuado? 3.2. Método adecuado para este proyecto.

142 El método adecuado El método adecuado tiene las siguientes propiedades: –Produce un producto de alta calidad informática. –Hace que el producto satisfaga las necesidades de PNUD de El Salvador. –Hace que el producto evolucione según esas necesidades. –Se puede aplicar a PNUD de El Salvador (especialmente, en el aspecto económico).

143 3. Método para implementar el programa 3.1. ¿Por qué es especialmente importante en este caso elegir un método adecuado? 3.2. Método adecuado para este proyecto.

144 Nos centraremos en el desarrollo de software específico de PNUD de El Salvador El hardware, comunicaciones, software estándar y página Web deseados no plantean grandes problemas –No hay mucha diferencia entre los que se necesitan y aquellos con los que se cuenta actualmente: sólo hace falta actualizar algunos equipos y licencias. –Estas actualizaciones están en marcha: algunas ya están realizándose y otras están planificadas, por lo que sería suficiente con ejecutar estos planes, invirtiendo el monto necesario para hacerlo. Atlas es un programa que es imposible de modificar en El Salvador y es sencillo no hacer nada. La única parte de la estrategia tecnológica que se presenta como difícil es el desarrollo de software específico para el PNUD de El Salvador.

145 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Motivo 2. El software es un producto complejo y su complejidad aumenta con el tamaño. Motivo 3. Se necesita mantener el proyecto modificándolo según las necesidades. Motivo 4. No deseamos invertir una excesiva cantidad de dinero. ¿Por qué es difícil el desarrollo de software específico?

146 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Motivo 2. El software es un producto complejo y su complejidad aumenta con el tamaño. Motivo 3. Se necesita mantener el proyecto modificándolo según las necesidades. Motivo 4. No deseamos invertir una excesiva cantidad de dinero. ¿Por qué es difícil el desarrollo de software específico?

147 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Los humanos somos malos para imaginar cosas. Los usuarios sólo tienen una idea vaga cuando se está diseñando el programa. Pero cuando ya se está trabajando con el programa, los usuarios se dan cuenta: –Que algunas cosas no se habían imaginado y otras son diferente a cómo se imaginaban. –Que hay necesidades que no se habían pedido y ahora resultan evidentes. –Que hay mejoras que se pueden aplicar: en las funciones y en la forma de operación.

148 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Lo que Adquisiciones necesitaba Lo que Finanzas necesitaba Lo que el Front Office necesitaba Lo que se discutió en la reunión Lo que se pidió programar Lo que se podía comprar con el presupuesto que se destinó

149 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Motivo 2. El software es un producto complejo y su complejidad aumenta con el tamaño. Motivo 3. Se necesita mantener el proyecto modificándolo según las necesidades. Motivo 4. No deseamos invertir una excesiva cantidad de dinero. ¿Por qué es difícil el desarrollo de software específico?

150 Motivo 2. La complejidad es grande y aumenta con el tamaño. Fuente: Patterns of Software Systems Failure And Success, Capers Jones. TamañoTempranoA tiempoRetrasoCancela- dos 1000 PF 1.24%60.76%17.67%20.33% 10000 PF 0.14%28.03%23.83%48.00% 100,000PF 0.00 %13.67%21.33%65.00%

151 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Motivo 2. El software es un producto complejo y su complejidad aumenta con el tamaño. Motivo 3. Se necesita mantener el proyecto modificándolo según las necesidades. Motivo 4. No deseamos invertir una excesiva cantidad de dinero. ¿Por qué es difícil el desarrollo de software específico?

152 Motivo 3. La importancia del mantenimiento Motivo 3. El software es un organismo vivo. Continuamente, los usuarios necesitan añadir nuevas funciones y modificar las antiguas, pues las necesidades cambian: Las leyes cambian. Los procedimientos cambian. Las formas de trabajo cambian. La naturaleza del trabajo cambia. Los usuarios detectan nuevas funciones que no habían contemplado. A esa reprogramación, se le llama mantenimiento. Toda esta reprogramación introduce errores a su vez.

153 Motivo 3. La importancia del mantenimiento Hay una falsa impresión que pone el énfasis en la programación primera de la aplicación. Pero la programación son meses y el mantenimiento son años. Hasta el 90% del presupuesto de un programa se usa en el mantenimiento. Si no se usa, debe contratarse un nuevo programa, lo que es más caro.

154 Motivo 1. Los usuarios sólo saben lo que quieren hasta que el producto está terminado. Motivo 2. El software es un producto complejo y su complejidad aumenta con el tamaño. Motivo 3. Se necesita mantener el proyecto modificándolo según las necesidades. Motivo 4. No deseamos invertir una excesiva cantidad de dinero. ¿Por qué es difícil el desarrollo de software específico?

155 Motivo 4 El software es caro. El software que necesitamos es complejo y, por lo tanto, es muy caro. Además, necesita mantenimiento, lo que lo hace aún más caro. Pero no hay presupuesto para el software necesitamos.

156 Necesitamos algo caro Pero no tenemos dinero. ¿Qué hacemos?

157 Hay dos posibilidades 1. El dilema es imposible. Entonces: –No hacemos nada y seguimos en la situación actual. –Gastamos una cantidad de dinero exagerada. 2. Hay alguna forma inteligente y creativa de realizar el software sin gastar una forma exagerada de dinero. Mi opinión es la segunda. De encontrarla, trataremos a partir de ahora.

158 3. Método para implementar el programa 3.1. ¿Por qué es especialmente importante en este caso elegir un método adecuado? 3.2. Método adecuado para este proyecto.

159 Una primera elección Dos alternativas: Desarrollar el programa dentro del PNUD. Contratar una consultoría a una empresa de software.

160 No es adecuado contratar una consultoría ya que: 1. Es mucho más caro (y el dinero es un problema). 2. El llamado “vendor lock-in”: Se acaba dependiente de una empresa/persona para algo que es de importancia vital. –Es subcontratar el núcleo de nuestro negocio: El PNUD es una organización de procesamiento de información y esto va a depender de un agente externo. –El 90% de la tarea es mantenimiento: Cada vez que se necesita un cambio hay que recurrir a la empresa (la única que sabe cómo el programa está hecho). Esto es muy caro y el gasto se prolonga. Esto no es fiable. ¿Qué pasa si? –La empresa/persona aumenta sus precios de forma exagerada. –La empresa/persona deja de existir en el mercado.

161 No es adecuado contratar una consultoría ya que: 3. El programa acaba no satisfaciendo nuestras necesidades. Las consultorías desarrollan el programa en cascada:

162 Desarrollo en cascada La empresa nos pregunta qué necesitamos: análisis. La empresa decide la estructura del programa: diseño. La empresa programa el programa: programación. La empresa instala el programa en el PNUD y hace pruebas: pruebas.

163 ¿Qué problema hay? Como hemos dicho, el usuario no sabe lo que quiere hasta que ve el programa acabado. Cuando la empresa consultora instala el programa, el usuario se da cuenta –Que eso no es exactamente lo que se necesitaba. –Que hay un montón de mejoras que se podrían introducir y que mejorarían el trabajo. Pero ya es demasiado tarde –La estructura del programa ya está diseñada. –El trabajo ya está realizado: excepto si se paga más dinero.

164 La forma correcta de desarrollar software El desarrollo iterativo: una vez se instala el programa. –Se examinan las mejoras –Se recoge la opinión de los usuarios. –Se vuelve a modificar el programa con las necesidades detectadas: se genera una nueva versión

165 El desarrollo iterativo: La forma correcta de desarrollar software El programa es algo vivo: –Se determinan las necesidades reales (más posibilidades de éxito). –Cuando las necesidades cambian, el programa cambia. Un estudio de la MIT define el desarrollo iterativo como el primer factor en el éxito de un proyecto informático.

166 El desarrollo iterativo: La forma correcta para el PNUD Realizar todo el programa de golpe resultaría la forma inadecuada. Hay que comenzar realizando los subprogramas más críticos: –Comenzar por adquisiciones. –Seguir por Finanzas, Front Office, etc. Después, unir todos los programas en un único programa que mecanice la totalidad del PNUD.

167 Secuencia de implementación Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Primero deberían programarse las adquisiciones, después el centro de servicios y proyectos y después finanzas y recursos humanos. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

168 Secuencia de implementación Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Las unidades no administrativas quizás deberían ser lo último, pero no se ha estudiado suficientemente para asegurarlo al 100% de seguridad. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

169 Secuencia de implementación Unidades no administrat. Centro de Servicios Adquisi- ciones Finanzas Recursos Humanos Los módulos de servicios están en blanco pues se implementan mientras se necesitan los otros módulos. Proyectos S E R V I C I O S C O M U N E S Usuarios y Seguridad ProveedoresContrapartes Integración con Atlas Flujo del procedimiento (temporal e información)Flujo de uso de módulos

170 Resumen: la consultoría 1. Es mucho más caro (y el dinero es un problema). 2. El llamado “vendor lock-in”: Se acaba dependiente de una empresa/persona para algo que es de importancia vital. 3. No permite un desarrollo iterativo y así se acaba con un programa que no se adapta a las necesidades.

171 Comentarios sobre los términos de referencia Los términos de referencia describen un programa muy complejo que debe desarrollarse en sólo 3 meses (con 3 meses más de soporte técnico). Esto no es realista.

172 Posibles resultados A. Los buenos: –Presentan la consultoría y no se presentan tres ofertas. –Se presentan las ofertas pero con precios muy altos para el PNUD (pero los precios son correctos). La licitación se declara desierta (lo que es lo mejor que les puede suceder). B. El resultado más probable (y el peor). Una empresa les asegura que realizará el programa en el tiempo y dinero que ustedes determinan (que no son realistas). –Ustedes se dan cuenta antes del pago: problemas, tiempo y esfuerzo perdidos. –Dado el carácter abstracto del software: se dan cuenta después del pago y, además, han perdido dinero.

173 El desarrollar internamente permite 1. Conseguir un desarrollo más barato. 2. Evitar el llamado “vendor lock-in”: no se es dependiente de otra empresa. 3. Permite un desarrollo iterativo, con lo que acabamos con un programa que se adapta a las necesidades. 4. Permite desarrollar los términos de referencia de forma más realista.

174 Y aún más Si el PNUD desarrolla el programa, sabe cómo está construido: Puede modificarlo para otras oficinas del PNUD: Belice, resto de Centroamérica. Constituyendo un éxito para el PNUD de El Salvador.

175 El precio también se inclina al desarrollo interno Desarrollo externo de un sistema como el que necesita. Aprox. $90,000 Precio mensual de un analista y desarrollador competente en $2,000-$3,000. –Precio total: $24,000-$36,000 (Los pueden encontrar hasta de $500/mes pero no les recomiendo que boten su dinero)

176 Una advertencia El primer precio de la transparencia anterior es el precio de mercado en El Salvador para el desarrollo externo de un sistema de esta magnitud. Si alguien les dice que puede hacerlo por menos: –O bien no tendrá ninguna calidad y lo acabarán desechando. –O bien sólo les implementará una parte de lo que necesitan. Los términos de referencia del programa de workflow no ayudan porque son vagos y el sistema parece mucho menor que el que realmente se necesita.

177 Por ejemplo, los términos de referencia Dicen que el sistema se debe elaborar en 90 días calendario (con 90 días de soporte técnico), lo que es totalmente insuficiente. Sin embargo, un oferente puede pensar que es factible, pues los términos de referencia no concretan la magnitud del sistema (ya que decidirlo es parte de la consultoría)

178 Posibles resultados de un desarrollo externo con esos términos A. Los posibles resultados no tan malos: –Presentan la consultoría y no se presentan tres ofertas. –Se presentan las ofertas pero con precios muy altos para el PNUD (pero los precios son correctos). La licitación se declara desierta (lo que es lo mejor que les puede suceder). B. El resultado más probable (y el peor). Una empresa les asegura que realizará el programa en el tiempo y dinero que ustedes determinan (que no son realistas). –Ustedes se dan cuenta antes del pago: problemas, tiempo y esfuerzo perdidos. –Dado el carácter abstracto del software: se dan cuenta después del pago y, además, han perdido dinero.

179 Ahora bien, hay un problema Desarrollar el programa, requiere contratar un nuevo empleado por una cantidad de tiempo. Esto es mucho menos dinero que contratar una consultoría (y da mejores resultados), pero aún así, sigue siendo dinero. Y no nos sobra el dinero. ¿Cómo resolver este problema?

180 Hay que hacer que otro pague por el empleado Idealmente, un PNUD de un país desarrollado. Este puede enviar un profesional con un programa como JPO o similar. De esta manera, el PNUD de El Salvador puede obtener lo que necesita (que sería muy caro si lo contratara) a un costo prácticamente gratuito. En mi opinión, esta es la mejor opción.

181 Una posibilidad que podría interesarles Como funcionario español, puedo venir en una misión a una organización de desarrollo, sin perder mi plaza vitalicia (permiso llamado “servicios especiales”). Así que si el PNUD de España me enviara yo podría implementar el proyecto hasta que acabara, con las siguientes ventajas: –Costo gratuito. –Productividad. –Cuando deseen prescindir de mis servicios, pueden hacerlo sin problema, pues tengo plaza vitalicia. –Conozco el programa que se debe desarrollar y los requerimientos. Por ejemplo, consultar con la Unidad de Adquisiciones.

182 Otra ventaja: Experiencia profesional Formación: –Licenciado en Informática por Universidad Politécnica de Cataluña –Doctorado (Ph.D) en Informática por Universidad de Castellón –Maestría en NNTT aplicadas a la Educación por Universidad Carlos III de Madrid. 15 años de experiencia profesional en España y El Salvador. Sobre todo, en desarrollo de software: Director de Informática de la Defensoría del Consumidor. Evelyn Jacir Lovo. Gerente General de Aurum Solutions. Secretaría Técnica. Claudia Monzón. Mayra de Morán. Profesor de varias universidades españolas y Director Académico en UFG. Martínez Perdomo Experiencia en cooperación internacional: AECI, ONGs. Otras referencias: Roberto Mestanza (capacitación en software)

183 Sea como sea Parece que la solución óptima es contratar a un empleado con sólida experiencia en desarrollo de software. Mucho mejor si esto lo pagan desde otro PNUD, para no tener que asumir los costos.

184 1. Introducción. –1.1. Trabajo realizado. –1.2. Importancia de un sistema de información. 2. Sistema de información propuesto. –2.1. Mejoras en los procedimientos. –2.2. Mejoras en la tecnología 2.2.1. Funcionalidad general del programa. 2.2.2. Otros aspectos importantes. –2.3. Descripción de los componentes del sistema de información. 2.3.1. Adquisiciones. 2.3.2. Centro de servicios. 2.3.3. Finanzas. 2.3.4. Recursos humanos. 2.3.5. Proyectos. 2.3.6. Unidades no administrativas. 2.3.7. Módulos de servicios. 3. Método para implementar el sistema. 4. Conclusión. Índice

185 Conclusión Lo importante no es quién realice el nuevo programa de información. Lo importante es que se implemente y que se implemente bien. Sólo así se consiguen los grandes beneficios para el PNUD. Para que esto pase, se necesita seguir las indicaciones que son resultado de esta consultoría y que se han presentado en esta presentación y en las otras.

186 Preguntas, comentario, debate.

187 Gracias por su atención.