MANUAL DE ADMINISTRACION DE PROYECTOS.pdf

INTRODUCCION ........................................................................................................................ 1 PARTE I - ADMINISTRACION DE PROYECTOS ..................................................................... 3 Conceptos Básicos ....................................................................................................................................... 3 Factores Críticos de Éxito........................................................................................................................... 6 Oficinas de Proyecto: organización y personal ......................................................................................... 8 Estructura Organizativa ............................................................................................................................................. 8 Responsabilidades ................................................................................................................................................... 13

Gerentes de Proyecto ................................................................................................................................ 19 Perfil........................................................................................................................................................................ 19 Liderazgo ................................................................................................................................................................ 24 Evaluación del equipo de trabajo ............................................................................................................................ 29

Toma de decisiones .................................................................................................................................... 31 Manejo de Conflictos ................................................................................................................................ 36 Técnicas de programación ........................................................................................................................ 44 Documentación .......................................................................................................................................... 47 Conceptos Básicos .................................................................................................................................................. 47 Codificación ............................................................................................................................................................ 49 Carpeta de Proyecto ................................................................................................................................................ 51

Estimación de tiempo ................................................................................................................................ 52 Código de Etica .......................................................................................................................................... 57 PARTE II – METODOLOGÍA .................................................................................................... 59 Introducción............................................................................................................................................... 59 I. Planificación .......................................................................................................................................... 61 I.a. Sensibilización .................................................................................................................................................. 65 I.a.1. Organización ............................................................................................................................................. 67 I.a.2. Estudio inicial y diagnóstico ..................................................................................................................... 81 I.a.3. Identificación de procesos críticos y desarrollo de visión ......................................................................... 89 I.b. Definición de proyectos y asignación de prioridades ....................................................................................... 95 I.b.1. Organización ............................................................................................................................................ 97 I.b.2. Definición de estrategias ......................................................................................................................... 100 I.b.3. Definición de los proyectos ..................................................................................................................... 105 I.b.4. Asignación de prioridades y elaboración de términos de referencia ....................................................... 111

II. Diseño de Soluciones ......................................................................................................................... 119 II.a. Análisis de procesos y estructuras de soporte ............................................................................................... 125 II.a.1. Organización ......................................................................................................................................... 127 II.a.2. Modelado de los procesos vigentes ....................................................................................................... 131 II.a.3. Relevamiento de la infraestructura tecnológica y sistemas de información .......................................... 136 II.a.4. Relevamiento de la estructura organizacional y marco normativo ........................................................ 142 II.a.5. Análisis de los procesos ......................................................................................................................... 146 II.b. Diseño técnico .............................................................................................................................................. 152 II.b.1. Modelado de los nuevos procesos ........................................................................................................ 154 II.b.2. Definición de las especificaciones técnico-funcionales del sistema de información ............................ 159 II.c. Diseño organizacional ................................................................................................................................. 166 II.c.1. Definición de nuevos cargos y perfiles.................................................................................................. 168 II.c.2. Diseño de la estructura organizativa ...................................................................................................... 172

Manual de Administración de Proyectos INDICE II.d. Planificación de la implantación ................................................................................................................... 177 II.d.1. Definición de las estrategias de cambio ................................................................................................ 179 II.d.2. Especificación de la implantación .......................................................................................................... 184

III. Implantación .................................................................................................................................... 201 III.a. Lanzamiento ................................................................................................................................................ 209 III.a.1. Organización ......................................................................................................................................... 211 III.a.2. Contratación de bienes y servicios ....................................................................................................... 215 III.b. Diseño detallado .......................................................................................................................................... 219 III.b.1. Ajuste de diseño de procesos ................................................................................................................ 222 III.b.2. Ajuste de diseño del software aplicativo pre-programado .................................................................... 228 III.b.3. Ajuste de diseño del software aplicativo a medida .............................................................................. 232 III.c. Instalación de hardware, comunicaciones y software de base ...................................................................... 237 III.c.1. Instalación de hardware y comunicaciones ........................................................................................... 239 III.c.2. Instalación de software de base ............................................................................................................. 244 III.d. Configuración de paquetes y programación ................................................................................................. 247 III.d.1. Configuración del software aplicativo pre-programado........................................................................ 249 III.d.2. Programación a medida ........................................................................................................................ 254 III.e. Preparación de la conversión ....................................................................................................................... 258 III.e.1. Desarrollo de los procedimientos de conversión .................................................................................. 260 III.e.2. Preparación de la prueba integral y de aceptación .............................................................................. 265 III.f. Evaluación y capacitación ........................................................................................................................... 269 III.f.1. Evaluación del personal ......................................................................................................................... 271 III.f.2. Capacitación del personal ...................................................................................................................... 274 III.g. Prueba final y conversión ............................................................................................................................. 279 III.g.1. Prueba final ........................................................................................................................................... 282 III.g.2. Conversión ............................................................................................................................................ 287

ANEXOS ................................................................................................................................ 291 Bibliografía .............................................................................................................................................. 291

Primus Consultores Asociados

MANUAL DE ADMINISTRACION DE PROYECTOS Capítulo INTRODUCCION

Sección ---------------

Subsección ---------------

Fecha 20/05/98

Versión Recomendado

INTRODUCCION 1. Objetivo del Manual El Manual de Administración de Proyectos del Programa de Reforma Administrativa del Ministerio de Cultura y Educación de la Nación tiene los siguientes objetivos:  Proveer los conceptos básicos de administración de proyectos.  Desarrollar una guía que facilite la organización, planificación, conducción y control de los proyectos que se ejecuten en las áreas administrativas de las jurisdicciones educativas provinciales.  Facilitar la comunicación y transferencia de conocimientos entre los miembros del equipo del proyecto y los Ministerios provinciales. 2.

Alcance  Respecto de los destinatarios: El presente documento está dirigido a quienes asuman responsabilidades gerenciales y ejecutivas, de carácter permanente o eventual, en el Programa de Reforma Administrativa del Ministerio de Cultura y Educación de la Nación y en las Oficinas de Proyectos o Coordinaciones Provinciales.  Respecto de la categoría de proyectos: Está orientado a proyectos relacionados con reingeniería de procesos y sistemas de información, conforme a la categorización establecida por la Asociación Americana de Administradores de Proyectos.

3. Estructura del manual El Manual está compuesto de 2 partes:

Parte Administración de Proyectos Metodología

Contenido Conceptos básicos sobre proyectos y su administración. Descripción de fases, segmentos y actividades críticas con indicación de insumos, productos, puntos de control y documentación.

 La parte I del manual está estructurada en Capítulos que se subdividen, si es necesario , en Secciones y éstas últimas en Subsecciones.  La parte II, correspondiente al desarrollo de la Estructura de los Proyectos, se ha organizado de acuerdo al ciclo de vida un proyecto tipo, dividiéndose a ese efecto en Fases, Segmentos y Actividades.


Página 1

MANUAL DE ADMINISTRACION DE PROYECTOS Capítulo INTRODUCCION

Sección ---------------

Subsección ---------------

Fecha 20/05/98


 Por cada división del manual, en sus distintas jerarquías, se desarrolla un tema con la siguiente organización:  Denominación del tema: figura en el encabezamiento , debajo de los rubros Capítulo[Fase], Sección[Segmento] o Subsección[Actividad], según corresponda. 

Objetivo describe el propósito del tema explicitado.



Alcance enumera los distintos ítems que se desarrollarán.



Desarrollo: en forma correlativa, y siguiendo el orden establecido en el Alcance, se explican cada uno de los ítems.

 La Versión indica el estado de desarrollo y revisión en que se encuentra cada tema. Los posibles estados son:  Desarrollo: está sujeto a cambios importantes, aún no se ha terminado de elaborar el tema. 

Borrador: se ha concluido el desarrollo del tema, pero aún no ha sido aprobado por el equipo del proyecto. Se esperan cambios menores.



Recomendado: no está liberado para su publicación, pero se recomienda su uso por el equipo del proyecto para comprobar su utilidad en la práctica. No se esperan cambios importantes.



Liberado: está habilitado para su difusión. El estado Liberado se codifica con un número decimal, comenzando con 1.0. El entero identifica las distintas versiones liberadas con cambios radicales y el decimal identifica cambios menores dentro de la versión.


Página 2

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección CONCEPTOS BASICOS ---------------------------

Fecha 20/05/98


PARTE I - ADMINISTRACION DE PROYECTOS Conceptos Básicos 1. Objetivo  Conocer los conceptos básicos de administración de proyectos. 2.

Alcance      

a. b. c. d. e. f.

Proyecto y administración de proyectos Funciones primarias Objetivos del proyecto Recursos del proyecto Beneficios potenciales de las metodologías de administración de proyectos Principales obstáculos de la administración de proyectos

3. Desarrollo a. Proyecto y administración de proyectos Se define como proyecto a la agrupación de una serie de actividades y tareas que se caracterizan por: a) tener un objetivo específico a ser completado dentro de determinadas especificaciones, b) tener fechas de inicio y terminación definidas, c) desarrollarse dentro de ciertas restricciones, principalmente presupuestarias y d) consumir una diversidad de recursos (Ej: mano de obra, equipos, materias primas, etc). Administración de proyectos es la planificación, organización, conducción y control de recursos específicos asignados por un tiempo definido para alcanzar determinados objetivos y metas. b. Funciones primarias De las cuatro funciones definidas en la administración de proyectos, dos son críticas: la planificación y el control. Las citadas funciones incluyen los siguientes aspectos: 

Planificación del proyecto:



Definición de los objetivos, metas y actividades  Definición de la cantidad y calidad de trabajo  Definición de los recursos necesarios 

Control del proyecto:



Seguimiento del progreso  Comparación de los resultados reales respecto de los previstos (en cantidad, tiempo, calidad y costo)


Página 3


Fecha 20/05/98




Análisis del impacto en la Organización  Implementación de los ajustes c. Objetivos del proyecto Cada proyecto debe tener al menos un objetivo. Los objetivos deben ser conocidos e interpretados clara y uniformemente por todos los miembros del equipo del proyecto y los distintos niveles de responsabilidad de la Organización en que se trabajará. Los objetivos deben ser: 

Específicos, no generales



De una complejidad manejable



Mensurables, tangibles y verificables



Realistas y accesibles



Establecidos dentro de los límites de recursos disponibles o previstos



Consistentes con los planes, las políticas y los procedimientos de la Organización.

d. Recursos del proyecto Los principales recursos afectados en un proyecto son: 

Recursos financieros



Recursos humanos



Equipos



Materiales



Información



Tecnología

e. Beneficios potenciales de las metodologías de administración de proyectos La aplicación de metodologías de administración de proyectos genera los siguientes beneficios: 

Identificación de las actividades críticas y principales obstáculos



Minimización de la necesidad de generar continuos reportes.



Identificación de los tiempos límites en la programación de actividades.



Facilidad en la medición del cumplimiento.



Identificación de las responsabilidades de los distintos participantes


Página 4


Fecha 20/05/98




Identificación temprana de los focos de problemas, permitiendo la aplicación de medidas preventivas.



Conocimiento anticipado de cuando los objetivos no podrán ser cumplidos y cuando serán excedidos



Mejoramiento de la capacidad de estimación para futuros proyectos

f. Principales obstáculos de la administración de proyectos La administración de los proyectos enfrenta generalmente los siguientes obstáculos: 

Complejidad del proyecto



Cambios en los requerimientos



Cambios en las prioridades



Reestructuración de la Organización



Riesgos e incertidumbres



Cambios en la tecnología



Cambios en los costos



Recursos humanos sin adecuada capacitación



Falta de adherencia a estándares


Página 5

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección FACTORES CRITICOS DE Estructura -------------EXITO Organizativa

Fecha 20/05/98


Factores Críticos de Éxito 1.

Objetivo Enunciar los factores claves que deben mantenerse controlados para alcanzar el éxito del proyecto

2. Alcance  a.  b. 3.

Factores Críticos de Éxito de un proyecto. Guías de acción.

Desarrollo a. Factores Críticos de Éxito de un proyecto Se considera que un proyecto es exitoso cuando se han cumplido los objetivos previstos: 

Dentro del tiempo acordado



Dentro de los costos presupuestados y aprobados



Con adecuados criterios de calidad



Con la aceptación por parte del destinatario



Con mínimos cambios y previamente aprobados



Sin ocasionar disturbios en la actividad principal de la Organización



Sin afectar los valores más nobles de la Organización ni los principios morales de sus miembros

b. Guías de acción para alcanzar el éxito en los proyectos: Se recomienda observar en todo proyecto el cumplimiento de las siguientes acciones: 

Contar con el patrocinio de la Alta Conducción de la Organización desarrollará el proyecto



Ser realista en la determinación de los objetivos, el calendario y los criterios de performance a lograr



Seleccionar los miembros clave del equipo con probada experiencia en la especialidad en la que se desempeñarán



Entregar a los miembros del proyecto especificaciones claras de las actividades a realizar, los productos que se esperan obtener, el calendario a respetar, los puntos que se controlarán, las formas de comunicación y los criterios de calidad: todos deben conocer qué hay que hacer y las interrelaciones con los distintos miembros del equipo del proyecto



Desarrollar en el equipo del proyecto el sentido de misión y compromiso, desde el principio


en dónde se

Página 6

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección FACTORES CRITICOS DE Estructura -------------EXITO Organizativa

Fecha 20/05/98




Buscar el incremento de la imagen pública del proyecto dentro de la Organización en que se trabaja.



Desarrollar canales de comunicación cortos y efectivos



Desarrollar la capacidad de diálogo en el equipo del proyecto.



Coordinar y mantener una buena relación con sus Superiores, con los miembros del equipo y con el personal de la Organización destinataria del proyecto.



Anticipar los puntos de probable conflicto.



Contar con estrategias de back-up en anticipación a potenciales problemas



Controlar el proyecto en base al cumplimiento de hitos mensurables, evitando controles por simple porcentaje de avance.



Mantener los cambios del proyecto bajo control.



Dotar al equipo del proyecto de una organización flexible



Brindar al equipo de trabajo los recursos ambientales y técnicos necesarios.



Evitar la sobredependencia de un solo tipo de herramienta de control



Evitar el sobre-optimismo


Página 7

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección OFICINAS DE PROYECTO: Estructura -------------ORGANIZACIÓN Y PERSONAL Organizativa

Fecha 20/05/98


Oficinas de Proyecto: organización y personal Estructura Organizativa

1. Objetivo  Definir la estructura organizativa que permita administrar eficientemente los proyectos. 2.

Alcance    

3.

a. b. c. d.

Oficinas de Proyecto: concepto y alcance Oficina Central de Proyectos: funciones e integrantes Oficina Provincial de Proyectos: funciones e integrantes Interrelación entre la Oficina Central de Proyectos y la Oficina Provincial de Proyectos.

Desarrollo a. Oficinas del Proyecto: concepto y alcance. Las Oficinas de Proyecto, en términos generales, son las unidades organizativas, permanentes o eventuales, responsables de la gestión de proyectos. Los conceptos y guías que se desarrollan en el presente capitulo son aplicables al Programa de Reforma Administrativa del Ministerio de Cultura y Educación de la Nación, bajo el concepto de Oficina Central de Proyectos , y a las Oficinas de Proyectos que se constituyan en las distintas Jurisdicciones provinciales. b. Oficina Central de Proyectos: funciones e integrantes. Las principales funciones son: 

Estimular y coordinar el proceso de reforma administrativa de las distintas Jurisdicciones provinciales



Colaborar con la Alta Conducción de las Jurisdicciones provinciales en la definición de proyectos y prioridades



Asesorar técnicamente a las Oficinas de Proyectos Provinciales respecto de la selección del equipo de proyecto, entrenamiento, diseño de los términos de referencia del proyecto y criterios de calidad



Definir las ideas rectoras de modelos de gestión administrativos eficientes que faciliten y guíen los procesos de transformación



Definir los hitos de control y criterios de calidad de los proyectos



Supervisar los proyectos desarrollados en cada Jurisdicción



Asignar y/o financiar recursos humanos y/o técnicos para el desarrollo de los proyectos de las Jurisdicciones provinciales


Página 8


Fecha 20/05/98




Documentar las principales instancias y controles de progreso de los proyectos de las Jurisdicciones provinciales



Facilitar la integración horizontal de las jurisdicciones provinciales

La Oficina de Proyectos Central está integrada por: 

Coordinador General del Programa



Gerentes Regionales de Proyectos



Coordinador de Soporte Logístico



Equipo de Expertos.



Equipo de Asistentes de Gerentes de Proyectos



Equipo de Asistentes Técnicos Estructura Organizativa Oficina Central de Proyectos Programa de Reforma Administrativa

Coordinador General de Programa de Reforma Administrativa

Gerentes Regionales de Proyectos

Coordinador Soporte Logístico

Equipo de Expertos


Equipo de Asistentes Técnicos

c. Oficina Provincial de Proyectos: funciones e integrantes


Página 9


Fecha 20/05/98


Las principales funciones son: 

Definir los términos de referencia de los proyectos conforme a las prioridades que determine la Alta Conducción



Seleccionar los integrantes del equipo de proyecto



Integrar las segmentos de los miembros del equipo del proyecto y de éstos con la Organización en la que trabajan a fin de alcanzar los objetivos establecidos en el proyecto



Facilitar la comunicación entre los miembros del equipo y de éstos con la Organización en la que trabajan



Actuar como centro de información de todas las etapas del proyecto



Asegurar que todo el trabajo requerido esté documentado y distribuido a todos los miembros claves del equipo del proyecto.



Facilitar los medios técnicos que el equipo de proyecto requiera

La Oficina de Proyectos Provincial está integrada por: 

Gerente de Proyectos



Equipo de Especialistas






Equipo funcional (personal de la Organización)


Página 10



Alta Conducción Ministerio Provincial

Estructura Organiz ativa Oficina Provincial de Proyectos


Fecha 20/05/98

(o Niv el equiv alente)

Unidad Organizativa de línea


Empleados de la Organización


Equipo de Especialistas Equipo Funcional de Proyecto Dedicación Part-Time


Equipo de la Oficina de Proyecto Dedicación Full-time

Equipo del Proyecto


Página 11

Primus

Consultores Asociados

Equipo de Expertos

Coordinador Soporte Logístico


Coordinador General de Programa de Reforma Administrativa


Asesoramiento Técnico Nivel Estratégico y Tactico Selección de Proyectos Selección personal clave


Dedicación Full-time



Dedicación Part-Time

Equipo Funcional de Proyecto



Alta Dirección Ministerio Provincial (o Nivel equivalente)

Estructura Organizativa Oficina Provincial de Proyectos

Equipo del Proyecto

Equipo de la Oficina de Proyecto

Equipo de Especialistas


Asesoramiento Nivel Estratégico Asesoramientoy asistencia Financiera

Supervisión Asesoramiento Técnico Gestión Proyecto

Asesoramiento Técnico

Gerente Regional de Proyectos

Oficina Central de Proyectos Programa de Reforma Administrativa

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección OFICINAS DE PROYECTO: Estructura -------------ORGANIZACIÓN Y PERSONAL Organizativa Fecha 20/05/98 Versión Recomendado

d. Interrelación entre la Oficina Central de Proyectos y la Oficina Provincial de Proyectos

Página 12

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección OFICINAS DE PROYECTO: Responsabilidades -----------------ORGANIZACIÓN Y PERSONAL

Fecha 20/05/98


Responsabilidades 1. Objetivo Identificar las principales responsabilidades de los participantes del proyecto 2. Alcance          

a. b. c. d. e. f. g. h. i. j.

Alta Conducción. Coordinador General del Programa. Gerentes Regionales de Proyectos. Coordinador de Soporte Logístico. Equipos de Asistentes de los Gerentes de Proyectos. Equipo de Expertos. Equipo de Asistentes Técnicos. Gerentes de Proyectos (Provincia). Equipo de Especialistas (Provincia). Equipo Funcional del Proyecto (Provincia).

3. Desarrollo a. Alta Conducción Por Alta Conducción debe entenderse el responsable mayor de la Organización y sus inmediatos colaboradores en nivel jerárquico, con suficientes atribuciones para tomar decisiones estratégicas y tácticas. Las responsabilidades dentro del proyecto pueden ser asumidas por una persona (Ej: Ministro o Subsecretario) o por un Comité de Seguimiento de Proyectos, que estará integrado por funcionarios de la jerarquía mencionada y , adicionalmente, por miembros claves de la Organización. Las principales responsabilidades asignadas a la Alta Conducción son: 

Establecer las prioridades de los proyectos.



Definir claramente las expectativas del proyecto.



Participar en la selección del Gerente de Proyectos y miembros clave del equipo del proyecto.



Comunicar en forma clara a la Organización el objetivo del proyecto y sus expectativas.



Asistir e intervenir en la resolución de conflictos graves.



Respaldar las conductas de los miembros del equipo del proyecto que sean correctas y favorezcan el cumplimiento de los objetivo



Facilitar a los miembros del proyecto el acceso a las fuentes de información. y a las distintas áreas de la Organización donde deban trabajar.


Página 13


Fecha 20/05/98




Disponer de que el equipo de proyecto tenga los recursos básicos para trabajar eficientemente.



Proveer información estratégica.



Proveer la retroalimentación (feedback) del proyecto.

b. Coordinador General del Programa Es el responsable mayor de la Oficina Central de Proyectos. Sus principales responsabilidades son: 

Coordinar el proceso de reforma administrativa de las distintas jurisdicciones provinciales.



Establecer las estrategias de implementación del Programa de Reforma Administrativa.



Controlar que en los procesos de reforma de la jurisdicciones provinciales se respeten las ideas rectoras de modelos de gestión eficientes.



Asesorar a la Alta Conducción de las provincias respecto del impacto de los proyectos y obtención de fuentes de financiamiento.



Supervisar que los recursos afectados a los procesos de transformación se utilicen eficientemente.



Facilitar el intercambio de experiencias de reforma entre las Jurisdicciones provinciales.



Establecer los criterios de supervisión respecto de la gestión de los proyectos provinciales.



Facilitar la asistencia técnica a las jurisdicciones provinciales respecto de la gestión de los proyectos y la aplicación de soluciones estándares.



Mantener informado a la Conducción del Ministerio de Cultura y Educación de la Nación del estado de los proyectos provinciales que son asistidos y/o dirigidos por el Programa de Reforma Administrativa.

c. Gerentes Regionales de Proyectos Son integrantes de la Oficina Central de Proyectos y reportan al Coordinador General del Programa. Sus principales responsabilidades son: 

Asesorar a la Alta Conducción de la Organización respecto de la aplicación de metodologías para determinar la prioridad de los proyectos y la selección del Gerente Provincial de Proyectos y personal clave.



Intervenir en la etapa de planificación de los proyectos de cada Jurisdicción respecto de la especificación de las actividades a realizar y los principales hitos que se supervisarán.



Intervenir en la preparación de los términos de referencia del proyecto.



Asesorar al Gerente de Proyectos respecto de la planificación, Conducción y control de los proyectos.



Supervisar y mantener documentado el progreso de los proyectos a cargo.


Página 14


Fecha 20/05/98




Servir de enlace entre los equipos técnicos de la Oficina Central de Proyectos y la Oficina Provincial de Proyectos.



Mantener informado al Coordinador General respecto del estado de los proyectos provinciales que son asistidos y/o dirigidos por el Programa de Reforma Administrativa.



Servir de enlace entre los distintos Gerentes de Proyectos Provinciales.



Difundir las pautas desarrolladas por la Oficina Central de Proyectos relacionada con: el diseño e implantación de modelos de gestión, especificaciones funcionales de soluciones informáticas, modelos de contratación y cualquier otra información o servicio que colabore con la realización de los objetivo.



Promover la contratación de soluciones estándares que faciliten la normalización de las distintas Jurisdicciones y produzca sensibles economías de escala.

d. Coordinador de Soporte Logístico Es integrante de la Oficina Central de Proyectos y reporta al Coordinador General del Programa. Sus principales responsabilidades son:

e.



Coordinar, dirigir e integrar los equipos de expertos y asistentes técnicos a cargo, a fin de brindar un eficiente soporte a los Coordinadores Regionales y Gerentes de Proyectos Provinciales.



Brindar al equipo de expertos y técnicos los medios necesarios para que se mantengan actualizados en sus distintas especialidades.



Colaborar ante los requerimientos de los selección del personal técnico clave.



Brindar soporte técnico ante los requerimientos de los Coordinadores Regionales o Gerentes de Proyectos Provinciales.

Gerentes de Proyectos Provinciales en la

Equipo de Asistentes de los Gerentes de Proyectos Son integrantes de la Oficina Central de Proyectos y reportan al Gerente Regional de Proyectos. Sus principal responsabilidades son: 

Mantener actualizada la Carpeta de los Proyectos.



Administrar la agenda de los Gerentes Regionales de Proyectos.



Brindar soporte administrativo a los Gerentes Regionales de Proyectos.

f. Equipo de Expertos Son integrantes de la Oficina Central de Proyectos y reportan al Coordinador de Soporte Logístico. Sus principales responsabilidades son:


Página 15


Fecha 20/05/98




Elaborar las especificaciones funcionales y técnicas de las soluciones informáticas y de comunicaciones que puedan ser utilizadas como estándares en los procesos de reforma de las jurisdicciones provinciales.



Investigar y examinar soluciones maduras existentes en el mercado que puedan soportar los procesos de reforma de gestión administrativa.



Generar modelos administrativos y normativos que hagan más eficientes las gestiones de las Administraciones Educativas Provinciales.



Redactar los pliegos de contratación normalizados de productos y/o soluciones estándares.



Asesorar técnicamente a los Gerentes de Proyectos Regionales y Equipos de Proyectos Provinciales.



Participar en los relevamientos de la fase de Sensibilización y elaborar los diagnósticos.

g. Equipo de Asistentes Técnicos Son integrantes de la Oficina Central de Proyectos, reportando al Coordinador de Soporte Logístico; o de las Oficinas de Proyectos Provinciales, en cuyo caso reportan al Gerente de Proyectos o Asistente de Gerente de Proyecto. Sus principales funciones son: 

Documentar los trabajos desarrollados por el equipo de expertos o equipo de especialistas.



Investigar y adquirir experiencia en el uso de herramientas informáticas que puedan brindar soporte a las distintas etapas de un proyecto.

h. Gerente de Proyectos Provincial Es el responsable mayor de la Oficina Provincial de Proyectos y reporta a la Alta Conducción. Su principal responsabilidad es alcanzar los objetivos del proyecto dentro de las restricciones de tiempo, costo, recursos y tecnología. Adicionalmente sus otras responsabilidades son: 

    

Desarrollar, junto con el Gerente de Proyectos Regional, los términos de referencia del proyecto, principalmente respecto de:

La definición de los objetivos y metas del proyecto. La definición de las especificaciones de los trabajos a realizar. El establecimiento de los hitos del proyecto y puntos de control. El establecimiento de los criterios de calidad y medidas de performance. El establecimiento de las fechas de comienzo y terminación de las fases que integren el ciclo de vida del proyecto. 

Planificar, coordinar y controlar las actividades y recursos para alcanzar los objetivos del proyecto con la calidad requerida, en el tiempo asignado y dentro del presupuesto aprobado.



Seleccionar el personal clave del proyecto.


Página 16


Fecha 20/05/98




Dirigir la preparación de los planes de trabajo de detalle.



Establecer las estrategias de comunicación.



Administrar y asignar recursos.



Mantener los cambios del proyecto bajo control, anticipando y reduciendo los riesgos.



Presentar alternativas de resolución a los problemas que se presenten.



Obtener el máximo rendimiento de los recursos asignados.



Resolver los conflictos que se produzcan durante el ciclo de vida del proyecto



Minimizar los impactos negativos que el proyecto pueda producir en la Organización.



Reportar a la Alta Conducción respecto de la marcha de los proyectos



Balancear las soluciones técnicas dentro del tiempo, costo y características particulares de la Organización destinataria del proyecto



Mantener integrado y motivado al equipo de trabajo.

i. Equipo de Especialistas Son integrantes de la Oficina Provincial de Proyectos y reportan al Gerente de Proyectos. Sus principales responsabilidades son: 

Desarrollar los programas de trabajo.



Ejecutar las fases del proyecto y entregar los productos comprometidos en el tiempo y calidad acordados.



Documentar los trabajos realizados.



Realizar los informes de avance bajo los términos determinados por el Gerente de Proyecto.

j. Equipo Funcional del Proyecto Son integrantes del Equipo de Proyecto pero no pertenecen a la Oficina Provincial de Proyectos. Está compuesto por agentes de la Organización que participan, generalmente, con dedicación part-time. Sus principales responsabilidades son: 

Proveer antecedentes y conocimientos de los procesos afectados.



Facilitar y/o realizar las actividades administrativas que el proyecto exija de la Organización (Ej: tramitación de contrataciones, pago a consultores, etc)



Conducir o realizar las actividades técnicas no cubiertas por el Equipo de Especialistas.



Participar en las estimaciones de impacto de los nuevos diseños.



Facilitar las comunicaciones entre el equipo externo y la Organización.



Participar en las reuniones de control de progreso.


Página 17

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección OFICINAS DE PROYECTO: Responsabilidades -----------------ORGANIZACIÓN Y PERSONAL 

Fecha 20/05/98


Representar a la Organización en la recepción y control de los trabajos entregados por el equipo externo.


Página 18

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTES DE PROYECTO Perfil -----------------

Fecha 20/05/98


Gerentes de Proyecto Perfil 1. Objetivo  Proveer una guía para seleccionar y evaluar los Gerentes de Proyectos. 2.

Alcance  a.  b.  c.

3.

Destrezas profesionales. Habilidades Personales. Efectividad del Gerente de Proyectos.

Desarrollo a. Destrezas profesionales El éxito del proyecto depende de la selección de un buen Gerente de Proyectos. La experiencia en gestión de proyectos de magnitud similar o mayor, y el conocimiento de Organizaciones dedicadas a administrar educación son condiciones muy importantes al momento de la selección. Independientemente de las características mencionadas, las principales destrezas en que debe calificar son:



Capacidad para construir y mantener equipos de trabajo efectivos Se manifiesta a través de las siguientes destrezas:

     

Generación de climas de trabajo productivos con buenas relaciones interpersonales y “espíritu de grupo” Identificación durante la selección del equipo a las personas que se caractericen por su idoneidad y compromiso con el proyecto. Facilidad para integrar nuevos miembros al equipo. Claridad para transmisión de los objetivos y las especificaciones de los trabajos a realizar. Generación y mantenimiento de canales abiertos y cortos de comunicación dentro del equipo de trabajo y entre éste y la Organización. Neutralización de los conflictos personales que pongan en riesgo la continuidad del equipo. 

Liderazgo Se manifiesta como la capacidad para conducir al equipo de trabajo en ambientes relativamente desestructurados. El liderazgo se relaciona con un estilo de Conducción caracterizado por:


Página 19

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTES DE PROYECTO Perfil ----------------    

Fecha 20/05/98


Claridad en el mando y orientación dada al proyecto. Asistencia en la resolución de los problemas. Capacidad para generar el compromiso en el equipo. Habilidad para comunicar claramente. Habilidad para negociar y balancear los requerimientos técnicos en contexto de limitaciones de recursos humanos y financieros.  

Capacidad para resolver conflictos Esta relacionada con la habilidad para:



Identificar las fuentes probables de conflicto y su duración en las distintas etapas del proyecto.  Anticipar las medidas correctivas para evitar los conflictos.  Neutralizar los conflictos no productivos y capitalizar los efectos positivos (Ej: ambiente de sana competencia)  

Conocimientos del entorno tecnológico Los proyectos comprendidos en el Programa de Reforma Administrativa incluyen diversas áreas de interés como: informática, comunicaciones, arquitectura organizacional, reingeniería de procesos, administración de personal y administración presupuestaria, entre otras. Encontrar un Gerente de Proyectos que posea experiencia en todas las áreas es difícil e inconveniente ya que puede dar al proyecto un fuerte sesgo tecnológico olvidando el “compromiso” con el objetivo final del proyecto. El Gerente de Proyectos, más que ser un experto debe comprender la tecnología a través de:



El conocimiento conceptual de los productos, herramientas y técnicas vigentes.  El impacto que la tecnología puede producir en logro de los objetivo del proyecto.  La tendencia tecnológica y su evolución  El conocimiento de las fuentes que pueden proveer los expertos y tecnología que necesita



Capacidad en planificación Se manifiesta como la habilidad para:

     

Especificar el trabajo a realizar para obtener los objetivos previstos. Agrupar las actividades en fases y segmentos. Identificar los insumos y productos a obtener de cada fase. Estimar los tiempos. Estimar los recursos. Identificar los hitos de control.


Página 20


Fecha 20/05/98


Una planificación efectiva requiere destrezas en :     

Procesamiento de información Comunicaciones Negociación de recursos Técnicas de medición Toma de decisiones. 

Capacidad en Organización Se sintetiza en la habilidad para entender cómo funciona la Organización y cómo se trabaja con la Organización. Es útil poseer conocimientos en diseño organizacional , comunicaciones y resolución de conflictos.



Capacidad en técnicas de administración: El Gerente de Proyectos debe tener experiencia en administración de presupuestos, administración de personal, delegación, motivación, contrataciones, manejo de reuniones y confección de informes.

b. Habilidades personales Las principales habilidades personales que caracterizan un buen Gerente de Proyectos son: 

Capacidad para tomar decisiones rápidas y razonables en condiciones de incertidumbre y riesgo.



Capacidad para resolver los problemas y no dar simplemente alternativas.



Capacidad para confrontar, persuadir, halagar o presionar, dependiendo de las situaciones.



Capacidad para entender la Organización sino tiene experiencia.



Habilidad para “negociar”.



Habilidad para adaptarse a situaciones cambiantes, aún obviando ciertas reglas o procedimientos preestablecidos, siempre que no violen normas éticas o morales o valores culturales que no pueden alterarse.



Paciencia para escuchar mientras evalúa.



Habilidad para entender la naturaleza de los conflictos y el sentimiento de los miembros del equipo.



Energía y perseverancia.



Versatilidad.



Imaginación y entusiasmo.



Credibilidad



Experiencia


Página 21


Fecha 20/05/98




Organización y disciplina



Comprensión de los problemas de relaciones humanas.



Facilidad para delegar efectivamente.



Facilidad para comunicarse e integrar grupos.



Lealtad con las necesidades de la Organización aún a costa de modificar el proyecto.

c. Efectividad del Gerente de Proyectos: Para satisfacer las expectativas de la Alta Conducción a fin de mantener el apoyo al proyecto, el Gerente de Proyectos debe mantener bajo control las siguientes cuatro variables: 

Credibilidad Es la imagen que la Organización tiene del Gerente de Proyectos respecto de su capacidad para tomar decisiones rápidas y correctas en los momentos oportunos. Está basada normalmente en la experiencia respecto de una variedad de asignaciones importantes para la Alta Conducción. Es la principal fuente de poder para mantener el estatus del proyecto: debe ponerse énfasis en mostrar hechos y no sólo en tener buenas opiniones. Es justo y sano otorgar el crédito a otros cuando así corresponde; además de dar credibilidad puede generar una conducta similar cuando el Gerente de un Proyectos colabora con otro proyecto.



Prioridad El proyecto aún cuando haya sido asignado como prioritario al momento de su lanzamiento, competirá con otros proyectos concurrentes. Por ello debe “destacarse” la importancia del éxito del proyecto respecto de los objetivos generales de la Organización. Es útil estimular los aspectos competitivos cuando sean importantes.



Accesibilidad Es la facilidad que el Gerente de Proyectos tiene para comunicarse directamente con la Alta Conducción y ser conocido personalmente por los miembros de la Alta Conducción. Debe mostrar capacidad para generar curiosidad por el trabajo que está realizando, demostrar que los propósitos son buenos para la Organización y no sólo para el proyecto; y ser lógico y prolijo en las presentaciones.



Visibilidad Consiste en la capacidad para mantener vigente en la mente de la Organización el proyecto.


Página 22


Fecha 20/05/98


Para ello es útil generar un buen impacto cuando se presente el proyecto a la Alta Conducción, utilizar los miembros del equipo para ayudar a regular la visibilidad que necesita el proyecto y mantener reuniones informales con los miembros claves de la Alta Conducción.


Página 23

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTES DE PROYECTO Liderazgo --------------

Fecha 20/05/98


Liderazgo 1. Objetivo  Brindar una guía práctica y fundamento teórico para una efectiva Conducción de equipos de trabajo. 2.

Alcance    

a. b. c. d.

Característica del liderazgo en el Gerente de Proyectos Teoría X y Teoría Y. Liderazgo situacional. Selección del estilo adecuado

3. Desarrollo a. Características del liderazgo en el Gerente de Proyectos El liderazgo de un Gerente de Proyectos se manifiesta en la energía personal, el poder, la influencia y la rapidez para: 

Mantener todo el equipo en un movimiento productivo.



Evitar estancamientos.



Resolver problemas que parecen no tener solución.



Comprender que “las medidas correctas” a tomar pueden variar de una situación a otra.



Reconocer que los demás poseen valores o actitudes hacia el trabajo distintos: ellos trabajan por sus propias razones y no por las que impone el Gerente del Proyecto.



No tratar a los desiguales en forma igualitaria: los motivos y la motivación difieren de uno a otro.



Comprender los estados de madurez de las personas integrantes del equipo y actuar en consecuencia.

b. Teoría X y Teoría Y (Extractado y adaptado de Management of Organizational Behavior de Paul Hersey y Ken Blanchard) Su autor es Douglas McGregor. La “Teoría X – Teoría Y” establece que las organizaciones piramidales de toma de decisiones centralizada, está basada en las suposiciones acerca de la naturaleza y motivación humana. La Teoría X asume que la mayoría de las personas prefiere ser dirigidas, no están interesadas en tomar responsabilidades y desean, principalmente, seguridad. Esta creencia está acompañada de


Página 24


Fecha 20/05/98


que las personas se motivan por dinero, beneficios y rigor del castigo. Los Gerentes de Proyecto que aceptan esta Teoría tienden a estructurar, controlar y supervisar muy de cerca a sus empleados. La Teoría Y asume que las personas no son haraganas o poco confiables por naturaleza. Propone que las personas pueden ser autónomas y creativas en el trabajo si están motivadas adecuadamente. Por lo tanto, es una actividad esencial para la administración el desarrollar este potencial de los individuos. c. Liderazgo situacional Basándose en la Teoría X y Teoría Y, el Dr. Paul Hersey y Kenneth Blanchard proponen el Modelo de Liderazgo Situacional que se sintetiza en el siguiente cuadro:

COMPORTAMIENTO ORIENTADO A LAS RELACIONES

ESTILO DE LIDERAZGO

PARTICIPAR

VENDER

DELEGAR

DECIR

COMPORTAMIENTO ORIENTADO AL TRABAJO Alto

Hábil Colaborador

Moderado - Madurez de los Integrantes del equipo del proyecto Hábil No Inhábil Colaborador Colaborador

Bajo

Inhábil No Colaborador

En el Modelo de Liderazgo Situacional se interpreta al estilo como los patrones de comportamiento (palabras y acciones) del líder tal cual como es percibido por los demás. En este caso, no interesa como se ve a sí mismo el Gerente de Proyecto sino como lo ven los demás. Se ha clasificado el comportamiento de los líderes en dos formas: quienes tienen un comportamiento orientado al trabajo y quienes un comportamiento orientado a las relaciones interpersonales.


Página 25


Fecha 20/05/98




Comportamiento orientado al trabajo: el líder indica a cada persona sus deberes tanto a nivel personal como grupal. Este comportamiento incluye decirles a las personas qué hacer, cómo hacerlo, dónde hacerlo y quién debe hacerlo. Se caracteriza por la comunicación en un solo sentido.



Comportamiento orientado a las relaciones: el líder se somete a una comunicación en dos sentidos o varios sentidos, en el caso de que exista más de una persona. Este comportamiento incluye escuchar, alentar, facilitar, clarificar y proporcionar soporte emocional.

El Gerente de Proyectos en su papel de líder debe estar interesado tanto en los resultados finales como en las personas, adaptándose a las diferentes situaciones o problemas que deba enfrentar.

Así se han determinado cuatro combinaciones de comportamiento, que llamaremos estilos:. 

Estilo Decir: se caracteriza por un fuerte comportamiento orientado al trabajo y débil respecto de la orientación a las relaciones. Consiste en decirles a las personas o al grupo qué tiene que hacer, cuándo, dónde, cómo y con quién. Se caracteriza por una comunicación de un solo sentido en la que el líder dirige a los integrantes del equipo del proyecto. El Gerente de Proyectos:



Establece los objetivos sin consultar.  Define el papel para cada integrante del equipo.  Especifica exactamente las actividades que debe realizar.  Asigna trabajos cortos y los supervisa muy de cerca. 

Estilo Vender: se caracteriza por una fuerte orientación tanto hacia el trabajo como hacia las relaciones. Proporciona guía. Las acciones y determinaciones del líder exhiben un alto nivel de comportamiento orientado al trabajo que varía de medio a alto. Al mismo tiempo el líder proporciona explicaciones y oportunidades de clarificación.

El Gerente de Proyectos: 

Establece los objetivos luego de darles una oportunidad a los integrantes del equipo de exponer sus propias ideas.  Define el papel para cada integrante del equipo.  Deja que cada uno determine como hacerlas.  Asigna trabajos de mediana y larga duración y los supervisa frecuentemente.


Página 26

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTES DE PROYECTO Liderazgo -------------

Fecha 20/05/98


Estilo Participar: se caracteriza por el comportamiento orientado a la relación mayor que el promedio y el comportamiento orientado al trabajo menor que el promedio. Proporciona aliento, promociona la discusión y solicita contribuciones a los colaboradores.

El Gerente de Proyectos: 

Negocia los objetivos, alentando a los integrantes del equipo a que expongan sus ideas  Define el papel para cada integrante del equipo.  Asigna trabajos de larga duración y está a disposición del equipo para cuando necesiten ayuda. Ocasionalmente interviene para ver como progresa el trabajo. Los integrantes del equipo deducen que trabajos deben hacer y cómo hacerlos.  

Estilo Delegar: se caracteriza por una utilización de los comportamientos orientado al trabajo como a la relación en un nivel más bajo que el promedio. Proporciona poca Conducción y bajos niveles de comunicaciones en dos sentidos.

Bajo esta situación: 

Los trabajadores establecen sus objetivos dentro del marco establecido por el Gerente de Proyectos.  El equipo identifica los trabajos que deben hacerse, deciden los métodos para hacerlos y establecen los papeles que cada uno jugarán.  El equipo se autodirige y periódicamente es controlado por el Gerente del Proyecto

La efectividad del líder, de acuerdo a investigaciones realizadas, está muy relacionada a la relación entre el líder y los integrantes del equipo del proyecto. Para ello es clave el factor de llegar a una buena relación con los integrantes del equipo del proyecto y ayudarlos para que alcancen madurez. Los dos principales componentes de la madurez de los integrantes del equipo del proyecto son la habilidad y la colaboración. La habilidad la brinda el conocimiento y la experiencia. La colaboración se relaciona con la confianza, el compromiso y la motivación para cumplir con el trabajo. Las personas están en niveles diferentes de colaboración según lo que se les pida. Los grados de habilidad y colaboración determinan cuatro niveles de madurez, de menor a mayor: 

M1-Inhábil No Colaborador



M2- Inhábil- Colaborador



M3- Hábil No Colaborador



M4-Hábil Colaborador.


Página 27


Fecha 20/05/98


d. Selección del Estilo Apropiado El modelo de Liderazgo Situacional relaciona los cuatro niveles de madurez con los cuatro estilos básicos de liderazgo. Para utilizar el modelo debe seleccionarse un punto en la escala de madurez que represente el seguidor y trazar una línea perpendicular desde ese punto hasta que intercepte a la curva que representa el comportamiento del líder. Este punto indica el nivel apropiado de comportamiento orientado al trabajo y de comportamiento orientado a la relación para la situación en particular. En el cuadro del Modelo de Liderazgo situacional se ha desarrollado un ejemplo para el caso de un integrante del equipo de trabajo calificado como “inhábil colaborador”. Ante esta situación el estilo de liderazgo más conveniente sería el calificado como “decir, es decir un Gerente que establece los objetivos luego de darles una oportunidad a los integrantes del equipo de exponer sus propias ideas y posteriormente aplica una fuerte supervisión.


Página 28

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTE DE PROYECTO Evaluación del equipo ---------------de trabajo

Fecha 20/05/98


Evaluación del equipo de trabajo 1. Objetivo  Proveer una grilla que resuma los conceptos a evaluar en los integrantes del equipo del proyecto. 2. Alcance  Modelo de grilla de evaluación 3. Desarrollo

PROYECTO:

FECHA:

EMPLEADO:

FECHA ULT. EVALUACION:

ROL ASIGNADO EN EL PROYECTO: TIEMPO AFECTADO AL PROYECTO:

TIEMPO REMANENTE:

EVALUADOR: TOMA DE DECISIONES:  Llega a buenas  Usualmente genera buenas  Ocasionalmente llega a  Necesita asistencia técnica conclusiones en forma rápida conclusiones buenas conclusiones

 Usualmente sus conclusiones son incorrectas

PLANIFICACION DEL TRABAJO:  Es buen planificador

 Planifica bien con ayuda

 Ocasionalmente planifica  Necesita bien detalladas

instrucciones  Le resulta difícil planificar su trabajo

COMUNICACIONES: 

Siempre entiende las  Algunas veces necesita  Siempre necesita nuevas  Necesita eventuales  Necesita instrucciones clarificación explicaciones controles para verificar si instrucciones entendió bien

constantes

ACTITUD:  Siempre demuestra interés  Demuestra interés la mayor  No demuestra interés por el  Demuestra interés en otras  Descuida su trabajo por su trabajo parte del tiempo trabajo segmentos

COOPERACION  Fomenta el trabajo en  Trabaja bien con otros  Usualmente trabaja bien  Tiene dificultad equipo hasta que el trabajo se ha con otros colaborar con otros completado

para  Todo tiene que ser hecho a su manera

HABITOS DE TRABAJO


Página 29

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección GERENTE DE PROYECTO Evaluación del equipo ---------------de trabajo  Está comprometido proyecto.

siempre  Frecuentemente con el comprometido con proyecto.

está  Usualmente satisface los  Tiene dificultad el requerimientos trabajar junto a otros

Fecha 20/05/98


para  Siempre trabaja solo.

ADAPTABILIDAD  Rápidamente se adapta a  Usualmente se adapta a  Necesita asistencia para  Necesita instrucciones  No se adapta a nuevas nuevas situaciones nuevas situaciones adaptarse detalladas y seguimiento. situaciones

CALIDAD DE LOS TRABAJOS  Entrega trabajos completos  Usualmente y probados. trabajos completos

entrega  Usualmente los trabajos  Usualmente falta completar  Debe tener seguimiento entregados son completo el trabajado. para que complete los pero no han sido revisados en trabajos. forma completa.

CONOCIMIENTOS TÉCNICOS  Alto nivel, es autónomo

 Muy buen nivel,  Tiene independencia pero  Necesita asistencia ocasionalmente consulta a necesita siempre que alguien otros lo ubique

 No puede realizar el trabajo, ni aún con guía.

OBSERVACIONES:

EVALUADOR

Apellido y nombre

EMPLEADO


Firma firma

Página 30

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección TOMA DE DECISIONES ----------------------------

Fecha 20/05/98


Toma de decisiones 1. Objetivo  Proveer conceptos y guías prácticas que faciliten el proceso de toma de decisiones en la administración de proyectos. 2. Alcance    

a. b. c. d.

Definición La toma de decisiones en el proyecto Incertidumbre El proceso de toma de decisiones

3. DESARROLLO a. Definición La toma de decisiones es un juicio, que se efectúa entre dos o más alternativas, probablemente todas ellas válidas, que genera en el decisor un estado de incertidumbre que debe controlar. b. La toma de decisiones en el proyecto La totalidad de las actividades a desarrollar en un proyecto implican una toma de decisión. Sin importar cuan fundamentales sean virtualmente, todas las decisiones se toman respondiendo a las siguientes preguntas: 

Qué debe hacerse (alcance y definición del trabajo)



Cuándo se lo necesita (cronograma y control)



Dónde se llevará a cabo, qué se entregará (logística)



Quién hará el trabajo, quién será el responsable (asignación de tareas)



Porqué debe hacerse de esta manera (evaluación)



Cómo debe hacerse (Planificación y análisis)

Siendo la misión del equipo tomar decisiones que conduzcan hacia el logro de los objetivos en la forma más eficaz y eficiente posible, deben distinguirse con claridad que se presentan para tomarlas. Según Russell L. Ackoff, estas oportunidades se dan siempre bajo las siguientes circunstancias: 

Cuando hay por lo menos dos cursos de acción posibles



Cuando existen al menos dos posibles soluciones de diferente valor



Cuando las diferentes posibilidades tienen distinto nivel de efectividad


Página 31


Fecha 20/05/98


Es necesario, entonces, antes de hacer la elección, poner el problema a resolver en perspectiva, de manera de visualizarlo desde distintas ópticas. Estas, también según Ackoff, son cinco: 1. El problema se visualiza desde el grupo o la persona que lo enfrenta. 2. El problema se visualiza desde sus variables controlables. 3.

Se determinan las variables que cuantitativa o cualitativamente no son controlables (externas).

4. Los problemas se exponen como restricciones internas o externas, por la misma persona que debe tomar la decisión o por otras sobre las que va a recaer esta decisión. 5. Se analizan las posibles soluciones que se producirían por la combinación de la elección y las variables no controlables que influyen c.

Incertidumbre El hecho que una decisión sea correcta o no, depende de la relativa estabilidad del entorno dentro del cual se haya tomado. Los cambios inesperados en el entorno generan lo que llamamos incertidumbre. En virtud de ésta afirmación, se infiere que las decisiones pueden tomarse dentro de un marco que va de la “absoluta certeza” hasta la “absoluta incertidumbre”, siendo estos dos polos, situaciones extremas, que raramente se presenten en la realidad. Lo cotidiano, lo normal, es que las decisiones se tomen con relativa certeza, basadas en información parcial. La certeza relativa , a su vez, se divide en riesgo e incertidumbre específica. En situaciones de riesgo, se dispone de suficientes datos para utilizar distribuciones matemáticas con el objeto de asignar probabilidades para las soluciones alternativas. Estas técnicas cuantitativas requieren, sin embargo, gran volumen de información, haciendo de la recolección de datos una tarea monumental. La incertidumbre específica cubre un rango en el que los datos no son suficientes para elaborar un modelo matemático, permitiendo sólo estimaciones subjetivas. En este caso la experiencia de la persona tiene un rol preponderante. Sobre la base de una serie de estudios, Adams y Martin señalan diez factores para analizar la incertidumbre de un proyecto: 1. Número de alternativas percibidas como posibles. 2. Organización de la información disponible. 3. Grado de conocimiento del tema 4. Diversidad de propuestas recibidas 5. Tiempo que queda antes que suceda un evento


Página 32


Fecha 20/05/98


6. Grado de refinamiento posible para un requerimiento 7. Semejanza con productos, servicios e ideas pasadas 8. Frecuencia y periodicidad de los eventos 9. Nivel relativo de confianza del evento 10. Grado de seguridad necesario d.

El proceso de toma de decisiones: método de Kepner-Tregoe En el proceso de toma de decisiones, confluyen una serie de factores, tales como la experiencia previa, el volumen de información, la características del grupo afectado, las variables externas condicionantes, las restricciones del proyecto, etc, de tal manera que quien debe hacerlo, muchas veces ni siquiera toma conciencia de cómo fue el procedimiento que adoptó para decidirse. Cuando las decisiones deben tomarse en grupo, el proceso se complica aún más. No obstante ello, algunos autores han desarrollado metodologías que facilitan este proceso. Uno de ellos es el Método Kepner – Tregoe (K – T). La aplicación del proceso K –T puede mejorar la calidad de las decisiones de la administración de proyectos. El proceso se centra en resolver problemas, o tratar con situaciones en las que lo que está actualmente ocurriendo se desvía de lo que debería estar ocurriendo. El proceso clasifica datos relevantes e irrelevantes asociados con la causa del problema. El método incluye los ciclos básicos del análisis de problemas, de decisiones y de problemas potenciales. El sistema alarga el proceso de toma de decisiones, haciéndolo más visible para la persona que toma las decisiones. Esta alta visibilidad junto con un método analítico y sistemático forma una herramienta efectiva para la resolución de problemas.



Análisis de problemas: El análisis de problemas es la primera parte del proceso K –T. La metodología al empezar con un análisis detallado del problema coincide con el axioma: “Si identifica correctamente y comprende el problema, ya está a mitad de camino de la solución”. El analista deberá comenzar con un estándar de desempeño contra el que se mide el progreso. Las desviaciones respecto del estándar se utilizan para identificar el problema que debe ser analizado. Se señala la variación y se la describe en detalle. Luego se destaca lo que fue afectado y lo que no lo fue Posteriormente se identifica la característica o condición que produjo el efecto no deseado. Finalmente, se buscan las causas más probables comparándolas con la especificación del problema. Los pasos, entonces son los siguientes:


Página 33


Fecha 20/05/98


1. Establecer el estándar de desempeño 2. Identificar la desviación del desempeño 3. Describir la desviación en detalle 4. Analizar el factor que lo distingue 5. Identificar los cambios causados por distintas situaciones 6. Señalar posibles causas 7. Identificar la causa más probable de la desviación 

Análisis de las decisiones El proceso de análisis de las decisiones comienza por establecer los objetivos y clasificarlos en orden de importancia. De esta manera se generan las alternativas y se miden contra metas fijas. Se individualiza una elección tentativa y se analizan sus consecuencias adversas, que se toman en cuenta en la decisión final. Los pasos, entonces, son los siguientes:

1. Fijar objetivos 2. Establecer prioridades de objetivos 3. Desarrollar soluciones alternativas 4. Evaluar alternativas 5. Hacer una elección tentativa 6. Probar los aspectos adversos 7. Planear contra la adversidad

Este procedimiento estructurado ayuda a evitar las decisiones impulsivas. Aunque el resultado final es todavía un juicio subjetivo, está guiado por la lógica y la disciplina del procedimiento. 

Análisis de problemas potenciales El análisis de problemas potenciales comienza con un plan de acción. Se individualizan los problemas potenciales y se determina el riesgo. Se identifican las posibles causas y se considera la probabilidad que ocurran. Los pasos son los siguientes:

1. Desarrollar un plan de acción 2. Individualizar problemas potenciales 3. Determinar riesgos 4. Identificar las causas


Página 34


Fecha 20/05/98


5. Determinar probabilidades 6. Prevenir las causas 7. Fijar un plan para el problema principal 8. Establecer controles


Página 35

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Capítulo Subsección MANEJO DE CONFLICTOS ------------------------------

Fecha 20/05/98


Manejo de Conflictos 1. Objetivo  Identificar los conflictos más probables durante el ciclo de vida del proyecto.  Proveer guías de acción para resolverlos. 2. Alcance          3.

a. b. c. d. e. f. g. h. i.

Conceptos Tipos usuales de conflictos Causas de los conflictos. Efectos positivos de los conflictos. Efectos negativos de los conflictos. Métodos y estilos de resolución. Modelo de resolución de Thomas-Kilmann Recomendaciones generales Otras causas de conflictos y sus estrategias de resolución

Desarrollo a. Conceptos Los conflictos derivan del desacuerdo entre los individuos y es inevitable en los entornos en que participen personas. Según L. Ackoff “Una parte está en conflicto con la otra si la acción de la primera parte tiene un efecto en el resultado de la acción de la segunda”. El conflicto requiere que algo esté comprometido. Así, si la acción de una parte reduce las oportunidades de la otra de ganar esa contingencia, entonces el conflicto aumenta. En la escuela tradicional el conflicto se consideraba una situación negativa causada por personas que ocasionan problemas, por lo tanto son situaciones que deben evitarse. En la escuela contemporánea el conflicto se asume como inevitable y si es manejado adecuadamente puede producir resultados positivos. En la administración de proyectos, prevalece la visión contemporánea, aunque dentro de esta línea de pensamiento el conflicto puede ser visto como positivo o negativo. Es positivo cuando ayuda a resolver problemas para alcanzar el objetivo y es negativo cuando aún resolviéndolo no mejora la situación inicial.

b.

Tipos usuales de conflictos Los tipos comunes de conflictos están relacionados con distintos puntos de vista o desacuerdos en: 

Las prioridades: distintas opiniones sobre la secuencia de actividades para lograr los objetivos del proyecto.


Página 36


Fecha 20/05/98




El calendario: desacuerdos relacionados con el tiempo, la secuencia y la cronogramación.



Los procedimientos administrativos: diferencias sobre cómo debe ser administrado el proyecto, incluso respecto de las relaciones y la jerarquía, la asignación de responsabilidades y los procedimientos de soporte administrativo.



El personal : diferentes puntos de vista sobre la utilización del personal.



Las opiniones técnicas: desacuerdo sobre temas técnicos y especificaciones de calidad.



Las distintas personalidades y estilos de trabajo: desavenencias por diferencias interpersonales, en oposición a los temas técnicos, conflictos propios del egocentrismo.



Los costos: desacuerdos sobre las estimaciones de costos.

Las intensidades de los conflictos dependerán principalmente de: 

La cantidad de restricciones del proyecto.



La fase y etapa en que se produce el conflicto.



La personas involucradas.

c. Causas de los conflictos Las causas de los conflictos son dinámicas conforme al ciclo de vida del proyecto. En la iniciación prevalecen las desavenencias por las prioridades y a medida que avanza el proyecto los desacuerdos son por los cronogramas y utilización del personal. De acuerdo a estudios estadísticos 1 se ha establecido el siguiente ranking de conflictos durante el ciclo de vida del proyecto:

Conflictos en las prioridades Conflictos en los procedimientos administrativos Conflictos en el calendario Conflictos en la asignación del personal Conflictos en las opiniones técnicas Conflictos de personalidades Conflictos en los costos

1

Formación del proyecto

Primeras etapas del proyecto

Durante el proyecto

En las últimas etapas del proyecto

1

1

4

3

2

3

5

7

3

2

1

1

4

5

3

4

6

4

2

6

7

7

7

2

5

6

6

5

Hans J. Thamhain y David L. Wilemon , “Conflict Management in Project Life Cycles”, Sloan Management Review.


Página 37


d.

e.

Fecha 20/05/98


Efectos positivos de los conflictos  Anticipa problemas más graves: si el Gerente de Proyectos tiene suficiente sensibilidad para detectar los primeros síntomas del conflicto y resolverlo, podrá evitar otros conflictos que se desencadenen como consecuencia de éste y tengan efectos más perniciosos. En este caso el conflicto actúa como el dolor en el organismo humano: es una señal de que algo está mal. 

Ofrece desafíos para encontrar nuevas soluciones: brinda a los participantes del proyecto nuevas oportunidades para resolver en forma conjunta los problemas. Esto se produce porque los grupos toman posiciones ante el conflicto que puede servir de estímulo para revelar nuevos hechos e información.



Permite acelerar actividades: es el caso de utilizar la instigación del conflicto o sea provocarlo. Las situaciones más frecuentes son cuando los responsables de la planificación demoran la asignación de fechas porque carecen de información suficiente y no hacen un esfuerzo importante por obtenerla. En este caso el Gerente del Proyecto puede proponer un plazo de terminación intencionalmente breve que les servirá de estímulo para acelerar la entrega del cronograma.

Efectos negativos de los conflictos  Estrés: ocasiona tensión física y mental que puede afectar emocional y orgánicamente a las personas. 

Genera atmósfera de trabajo improductiva: los niveles de productividad decaen debido a la incertidumbre generada por las opiniones antagónicas.



Puede causar pérdida de estatus o de poder: puede colocar a una de las partes en posición de perdedor, pero paradójicamente el ganador también puede perder ya que se puede comprometer el éxito del proyecto.



Distorsionan el comportamiento entre las personas: el sentido de los valores de las personas puede ser reemplazado por una enfermiza urgencia en buscar una solución.

f. Métodos y estilos de resolución Los métodos más usuales son: 

Establecer los procedimientos de resolución de los casos más comunes que deberían estar formalizados y comunicados fehacientemente a los miembros del equipo del proyecto y participantes de la Organización donde se trabaja.



Utilizar la referencia jerárquica, principalmente cuando los conflictos se suscitan entre el Gerente de Proyectos y algún miembro jerárquico de la Organización.



Por contacto directo

Los estilos dependerán de varias circunstancias como la personalidad y experiencia del Gerente del Proyecto y las relaciones jerárquicas de las personas que están involucradas en el conflictos. Inclusive durante una reunión, las partes podrán utilizar distintos estilos. Cada Gerente de

Primus


Página 38


Fecha 20/05/98


Proyectos evaluará el estilo más conveniente. Los principales modos de resolución según Blake y Mouton son: 

Confrontación o resolución de problema: se enfrenta el conflicto directamente con participación de las partes involucradas, se expone el problema y se busca objetivamente resolverlo. Es el más utilizado. Requiere un diálogo abierto entre los participantes.



Forzado: significa utilizar el poder para resolver el conflicto, se apoya más un punto de vista en detrimento de otro: el resultado final es una situación ganador-perdedor, en la que una de las partes literalmente destruye a la otra. Toma menos tiempo, pero deja generalmente personas resentidas. A pesar de tener la desventajas de provocar la generación de otros problemas en el futuro, es también en muchos casos la forma definitiva de resolverlos. Se da principalmente en situaciones de competencia.



Acuerdo o regateo: se llega a una situación satisfactoria para ambas partes, se caracteriza por el estilo “toma y deja”.



Suavizador o pacificador: se saca énfasis o se evitan los puntos en conflicto, reforzando las áreas de acuerdo. Es una situación provisoria, no proporciona una solución a largo plazo.



Retractación o retirada: se deja pasar el momento de crisis hasta que la situación mejore. Se utiliza también para ganar tiempo o como método estratégico en períodos más largos. La retractación es una forma pasiva de resolver los conflictos. No obstante, es el método menos aconsejable y es el menos utilizado.

En general el método más conveniente es el de confrontar o de resolución de problemas, pero requiere que se den las siguientes condiciones: 

Que todas las partes busquen una solución que cumpla con los objetivos de todos



Que todas las partes son honestas y abiertas sobre los hechos, las opiniones y sentimientos



Que todas las partes deben estar de acuerdo en controlar el proceso para llegar a un acuerdo , pero no en imponer su contenido.

Cuando las dos partes tienen una actitud favorable para resolver problemas, se llega a un acuerdo. Cuando las dos partes tiene actitudes de forzar, suavizar o retractar se producen estancamientos. La persona que utiliza la modalidad comprometer es vencida por la que utiliza la modalidad confrontar o forzar, pero llega a un acuerdo con las modalidades comprometer, suavizar o retractar. Suavizar prevalece sobre retractar y cede ante confrontar, forzar y comprometer. Retractar cede ante cualquier otra modalidad de resolución y produce estancamiento con otro que comparte la misma modalidad.

g. Modelo de resolución de Thomas-Kilmann El modelo de resolución de Thomas-Kilmann clasifica las modalidades de resolución de


Página 39


Fecha 20/05/98


conflictos en términos del interés en los puntos de vista propios o en el de los demás.        

Cuando no pueda ganar Cuando los riesgos son bajos Para ganar tiempo. Para desalentar a sus oponentes Para preservar la neutralidad o la reputación. Cuando piensa que el problema desaparecerá Cuando le conviene retrasar. 

        

      

   

Utilice comprometer:

Cuando ambas partes necesitan ser las ganadoras. Cuando usted no pueda ganar. Cuando los demás son tan fuertes como usted. Cuando no tiene tiempo de ganar. Para mantener la buena relación con su oponente. Cuando no está seguro de que tenga la razón. Cuando los riesgos son moderados. Para evitar dar la imagen de estar peleando. 



Utilice suavizar:

Para crear una obligación y negociar más tarde Cuando los riesgos son bajos. Cuando la responsabilidad es limitada. Para mantener la armonía. Cuando ninguna otra solución es adecuada. Cuando piensa que el problema desaparecerá. Para crear un buen entorno. Cuando perderá de todas formas. Para ganar tiempo. 



Utilice retractar:

Utilice confrontar:

Cuando ambos obtuvieron al menos lo que querían o quizás más Para reducir costos Para crear una base común de poder Para atacar a un enemigo común Cuando los conocimientos son complementarios.


Página 40


Fecha 20/05/98




Cuando hay suficiente tiempo.  Cuando quieren preparar la utilización posterior de otro método de resolución..  Cuando hay confianza.  Cuando tiene confianza en la habilidad de la otra persona.          

Utilice forzar:

Cuando tiene razón. Cuando es una situación de “vida o muerte”. Cuando los riesgos son altos. Cuando están en juego principios importantes. Cuando ustedes es más fuerte (Nunca empiece una batalla que no sabe si pueda ganar) Para ganar estatus o demostrar poder. En asuntos de corto plazo. Cuando la relación no es importante. Cuando se entiende que se está jugando “un partido”.

h.

Recomendaciones generales Una vez que se ha producido el conflicto se sugiere que al Gerente de Proyectos: 

Estudiar el problema y recolectar toda la información disponible.



Desarrollar una metodología de resolución o enfoque situacional.



Generar el clima apropiado para las reuniones: debe establecerse la buena voluntad de las personas en conflicto y de quién oficia de árbitro para llegar a alguna solución.



Analizar los puntos de vista de cada parte (como se ve cada parte a sí misma y respecto de los demás y cómo entienden que los demás lo ven)



Definir con claridad el problema y la posición de cada uno.



Compartir la información disponible.



Identificar las prioridades y los tiempos.



Organizar grupos de resolución si es conveniente.



Resolver el conflicto, incluso con la participación de un referente jerárquico si hace falta.



Desarrollar un plan de acción para resolver el conflicto.



Implantar el trabajo de resolución.



Realizar un seguimiento.

Otras reglas útiles durante las reuniones son: 

Usar convenientemente las pausas y pensar antes de reaccionar.


Página 41


Fecha 20/05/98




Construir un clima de confianza donde se piensen que de las reuniones debe salir la solución.



Tratar de entender los motivos del conflicto aunque no se compartan.



Mantener la reunión bajo control.



Escuchar a todas las partes involucradas.



Mantener una actitud de “tomo y dejo”.



Educar a las partes para que traten de interpretar el punto de vista del otro.



Tener la buena voluntad de decir lo que está incorrecto sin dañar al otro.

I. Otras causas de conflictos y sus estrategias de resolución Conflicto Conflictos de prioridades

Sugerencia En la fase de formación del proyecto debe definirse claramente los planes y lograr un acuerdo con las partes que potencialmente puedan estar en conflicto. Durante el desarrollo monitorear el progreso y comunicar los resultados que puedan afectar a las partes o generar inquietud. Realizar pronósticos.

Diferencias en los puntos de vista.

Es conveniente que se detecten las diferencias en las primeras etapas del proyecto. Establecer un método para tomar las decisiones, principalmente, en los aspectos técnicos que no pongan en discusión los objetivos del proyecto. Internalizar el concepto de “equipo” y aclarar las responsabilidades de cada integrante. Tratar de integrar los intereses personales con los objetivos del proyecto Esta situación puede ser evitada antes de asignar las personas al equipo de trabajo, explicándoles como particiona el proyecto en subproyectos, fases y etapas e .indagándolas respecto de dónde se “verían trabajando” dentro del proyecto. Es conveniente, no obstante, que durante las reuniones de revisión del proyecto se detecte este tipo de conflictos y se mantenga al equipo informado del progreso del proyecto. Asegurarse que todos los integrantes comprendan el objetivo del proyecto y los productos y servicios a obtener, antes de comenzar a trabajar. Se sugiere bautizar al equipo y al proyecto con un nombre que refuerce los objetivos. En las reuniones habituales de revisión es conveniente solicitar a algún miembro del equipo que explique los objetivos del proyecto. El Gerente de Proyecto debe tratar de estabilizar las influencias de las variables externas. Es conveniente que se mantenga actualizado respecto de sus influencias externas en el proyecto, realizar los pronósticos adecuados y tener preparados planes de contingencia. Los miembros claves del equipo deben estar preparados para mantener la Conducción de los proyectos y recordar frecuentemente los objetivo.

Conflicto de roles

Objetivos poco claros

Variables externas dinámicas

Competencia por el liderazgo.


La Alta Conducción debe ayudar a comunicar claramente y establecer el rol del líder del proyecto que fue seleccionado. Clarificar el rol y las Página 42


Conflicto Pérdida de la definición del equipo y su estructura

Fecha 20/05/98


Sugerencia responsabilidades por escrito minimizan los problemas de competencia. La participación de Alta Conducción en las reuniones de equipo refuerzan la importancia del equipo del proyecto. Es conveniente que estas reuniones se repasen los trabajos, roles y responsabilidades compartidas para obtener un servicio o producto.

Credibilidad en el Gerente de Proyecto o líder

Es crucial para la efectividad del equipo del proyecto. Crecerá la imagen del líder si se destacan acciones concretas de toma de decisión correctas y exposición de conocimientos técnicos. Se incrementa también con las buenas relaciones interpersonales con los miembros claves del equipo que soportan los principales esfuerzos del proyecto.

Pérdida del compromiso en el equipo de trabajo

Debe tratar de determinarse en las etapas más tempranas del proyecto la posible pérdida de interés de algún miembro del equipo e intentar cambiar la visión negativa. Las razones más frecuentes son la inseguridad y el conflicto con algún miembro del equipo. El Gerente del Proyecto o líder del grupo debe indagar la razón del conflicto y tratar de solucionarlo, o eventualmente, considerar su reemplazo.

Problemas de comunicaciones El Gerente de Proyectos o líder de grupo debe dedicar una importante porción de su tiempo a mantener comunicaciones efectivas con los miembros del equipo, a fin de conocer sus necesidades e inquietudes. Otra herramienta es mantener sesiones periódicas con los miembros individuales. Debe ponerse énfasis en las estrategias de comunicación orales y escritas. Disminución del apoyo de la Alta Conducción


Una vez que la Alta Conducción da el apoyo inicial para el lanzamiento del proyecto, el Gerente de Proyectos debe establecer claramente los recursos que necesita para trabajar eficientemente y luego mantenerla informada del avance del proyecto, haciéndola participar, incluso, de las reuniones de revisión. La relación Alta Conducción-Oficina de Proyectos debe ser fluida y efectiva, ya que es crítica para mantener la visibilidad y prioridad del proyecto.

Página 43

Capítulo TECNICAS DE PROGRAMACION

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subsección --------------------------

Fecha 20/05/98


Técnicas de programación 1. Objetivo  Identificar las técnicas más usadas para facilitarla programación y seguimiento de proyectos.  Proveer una guía para seleccionar el software de programación y control de proyectos. 2. Alcance  a.  b. 3.

Técnicas de programación y control de proyectos. Recomendaciones para la selección de software.

Desarrollo a. Técnicas de programación y control de proyecto Las técnicas de programación más utilizadas son: PERT (Técnica para evaluación y seguimiento de programas), CPM (Programación por camino crítico) y GANTT (Técnica de programación de barras). Se recomienda el uso de técnicas de programación y control de proyectos porque: 

Permite la visualización del proyecto en forma completa y rápida, facilitando la comunicación entre los miembros del equipo de trabajo.



Identifica la interdependencia de las actividades y eventos2.



Identifica las tareas, cuya terminación en las fechas previstas son críticas para que el proyecto finalice en término.



Facilita el cálculo de alternativas.



Provee información rápida para tomar decisiones.



Provee estructuras estándares de reportes.



Permite medir los progresos.

Aunque con las herramientas de software disponibles los proyectos se pueden representar con diferentes técnicas, es recomendable que los aquellos que son extensos se programen y expongan utilizando los diagramas de redes del PERT/CPM Si bien los diagramas GANTT son fáciles de graficar tienen la dificultad de no mostrar en forma rápida y sencilla interdependencia entre las tareas. Las técnicas PERT/CPM se utilizarán en forma indistinta aunque sus diferencias más importantes son:

2

Evento se define como el comienzo o terminación de una o un grupo de tareas, y actividad como el trabajo necesario para transitar desde un punto del proyecto (evento) a otro.


Página 44


b.


Fecha 20/05/98




PERT utiliza tres estimaciones (optimista, más probable y pesimista3) de la que se deriva el tiempo a utilizar. CPM uso sólo el tiempo normal, que es el que se calcula con en base a experiencia o registros históricos, tiene en general más precisión.



PERT es probabilístico por naturaleza, se basa en tiempos de difícil cálculo e incluye el factor riesgo de un proyecto completo. CPM está basa do en tiempos simples y es por naturaleza determinístico.



PERT es utilizado en proyectos con alta variabilidad e incertidumbre. CPM es utilizado en proyectos con certeza en las estimaciones.



PERT se utiliza en proyectos en que es difícil de determinar el porcentaje de avance de una actividad hasta tanto se llega a completar un evento. CPM es utilizado en proyectos en que es fácil medir el progreso de una actividad.

Recomendaciones para la selección del software Existen tres categorías básicas de software de administración de proyectos: 

Nivel 1: software para proyectos simples de fácil uso y con salidas sencillas. Provee limitado análisis de datos. No proveen recálculo automático ante determinados cambios, que impiden guardar la imagen original del proyecto y compararlo con posteriores versiones producto de ajustes.



Nivel 2: software para proyectos simples con ayuda para planificar, supervisar y reportar los proyectos. Provee un análisis comprensivo del proyecto, reportes de progresos y planes de revisión basados en la performance actual. Este tipo de software está diseñado para brindar soporte más allá del estadio de planificación y provee herramientas de control semiautomáticas.



Nivel 3: software para planificación, monitoreo y control de multiproyectos, mediante la utilización de bases de datos comunes y sofisticados monitoreos inter-proyectos y reportes autodefinibles por el usuario.

El software a seleccionar deben encontrarse preferiblemente en la categoría tres y satisfacer los siguientes requisitos 4:

3



Capacidad: soporte de multiproyectos. Verificar la cantidad máxima de actividades, subredes y subproyectos que puede administrar.



Esquemas de redes: manejo de diagramas de actividad y relaciones de precedencia. Debe permitir agrupar actividades en grupos jerárquicos (WBS-Work Breakdown Structure) y manejo de redes PERT. Es recomendable que puede relacionar las actividades en árboles de decisión y matrices de correlación de estructura organizativa/actividades



Versatilidad: que el ingreso y visualización del proyecto se pueda realizar según diagramas GANTT, PERT, Calendario u Hoja de trabajo.

Ver Sección “Estimación de tiempo”.

4

Test utilizado por The National Software Testing Laboratories of Conshohoken de Pensylvania para softwares de administración de proyectos.


comparar

Página 45



Fecha 20/05/98




Recursos: asignación de recursos a todo el proyecto o a una actividad en particular. La asignación podrá ser en forma manual o automática, a cuyo efecto el software utilizará alguna de los algoritmos heurísticos disponibles. Debe incluir la facilidad de proponer nivelación de los recursos y resolución de sobreasignaciones.



Reportes: sugerencia de reportes pre-formateados y disponibilidad de generador de reportes. Que acepte impresión en plotters. Los reportes mínimos preformateados son: diagramas GANTT, diagramas PERT, calendario, distribución de recursos, carga de trabajo, costos presupuestados vs. ejecutados, cash-flow y desviaciones.



Clasificación: posibilidad de clasificar las actividades por distintos criterios.



Selección: posibilidad de seleccionar actividades y recursos según distintos criterios.



Restricciones: aceptación de restricciones en calendario y recursos, con producción de sugerencias cuando la información ingresada las supera.



Desvíos: advertencia de desvíos en calendario, recursos y presupuestos.



Actualización: que acepte revisiones de estimaciones y recálculos.



Control de costos: que acepte presupuestos de mano de obra, materiales y otros insumos por actividad, por grupo de actividades o para todo el proyecto. Debe contabilizar los costos presupuestados y sumarizar los costos reales, permitiendo su comparación y seguimiento mediante la emisión de reportes.



Calendario: manejo de calendario por todo el proyecto, por recurso o por grupo de actividades. Las actividades podrán ingresarse y exponerse en distintas unidades de medida de tiempo.



Requerimientos de máquina: cantidad de recurso que afecta en hardware (memoria y discos).



Facilidad de aprendizaje y de uso.


Página 46

Capítulo DOCUMENTACION

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subsección Conceptos Básicos ---------------

Fecha 20/05/98


Documentación Conceptos Básicos 1. Objetivo  Entender el propósito y conceptos básicos de la documentación, la forma de generarla, distribuirla y ordenarla. 2. Alcance  a.  b.  c.

Beneficios de la documentación Guías de acción Tipos de documentos

3. Desarrollo a. Beneficios de la documentación  Facilita la comunicación entre los distintos participantes del proyecto. 

Favorece la calidad del trabajo al permitir que el equipo del proyecto y quienes lo supervisan dispongan de una base para comentar problemas en particular.



Permite el análisis de las distintas etapas del proyecto y el registro de los hitos más importantes (bitácora).



Facilita la transmisión de experiencia de un proyecto a otro (background).

b. Guías de acción  Todos los aspectos importantes del proyecto deberán documentarse minuciosamente. Por oposición, deberá evitarse la documentación de asuntos a los que nunca se hará referencia. 

Se tenderá a estandarizar la documentación más utilizada en todo tipo de proyecto, generando a tal efecto plantillas en el software utilitario, que se haya determinado sea de uso oficial.



Toda documentación tendrá un código identificadorio único que facilite su archivo y recuperación.



Los datos mínimos que todo documento debe contener son: código del proyecto, código del documento , número correlativo dentro del código del documento, fecha de confección, autor y destinatario.



Los documentos más utilizados deberán estandarizarse, generando modelos-ejemplos con instructivos de uso, cuyo archivo junto con la totalidad de la documentación, deberá estar centralizado en la Oficina de Proyecto.



Cuando un proyecto sea susceptible de generar subproyectos, se archivará por cada subproyecto documentación independiente. En este sentido se analizará la conveniencia de


Página 47


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subsección Conceptos Básicos ---------------

Fecha 20/05/98


generar subproyectos por cada una de las siguientes áreas: a) Normas legales; b) Sistemas informáticos y Comunicaciones y c) Organización y procedimientos administrativos. c. Tipos de documento  Según el destinatario: 

Documentación orientada al Equipo del Proyecto: está conformada generalmente por los papeles de trabajo que respaldan la actividad realizada por los miembros del equipo del proyecto con responsabilidades de ejecución.  Documentación orientada a la Alta Conducción: está conformada por informes ejecutivos que relatan el estado de avance del proyecto o aspectos muy relevantes.  Documentación orientada a los Usuarios: esta constituida por documentos relacionados a segmentos realizadas por y para los usuarios (Ej: entrenamientos) y manuales o instructivos.  Documentación orientada a los Gerentes de Proyecto: está constituida por documentación relacionada al control de gestión del proyecto y administración de recursos.  

 

 

Según el uso:

Documentación de Gestión del Proyecto: está relacionada con la planificación y seguimiento de los planes de trabajo, los informes de progreso y la documentación relevante de las segmentos que han sido consignadas como hitos del proyecto. Documentación Técnica: se refiere a la que se producen los especialistas durante el ciclo de vida del proyecto durante las etapas de planificación, relevamiento, análisis, diseño y conversión. Documentación administrativa: es la que se genera por la administración de los recursos y por necesidades de comunicación de temas diversos (ej.: Memos) que no pueden ser catalogados en algunos de la anteriores categorías. Documentación de recursos: se refiere a la documentación que se genera como consecuencia de la contratación y afectación de los recursos destinados al proyecto. Documentación relacionada con los antecedentes de la Organización: comprende el esquema normativo, las políticas, los manuales de funciones, los manuales de procedimientos, los organigramas, los antecedentes de proyectos similares anteriores y cualquier otra información producida por la Organización que pueda ser útil al proyecto.


Página 48


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subsección Codificación

Fecha 20/05/98


Codificación 1. Objetivo  Establecer el criterio de indexación y archivo de la documentación del proyecto. 2. Alcance  a.  b.

Criterios de codificación Criterios de archivo

3. Desarrollo a. Criterios de codificación: Código del Proyecto: JJ-PPPPPP-SS

, dónde JJ PPPPPP

es un código numérico que identifica la Provincia o Jurisdicción es un código alfanumérico que identifica el objeto

del proyecto Ej: PSL

Programa de Salud Laboral

RRRHH Adm. de Recursos Humanos DIGEST Digesto APA Administración de Piezas Administrativas PRE Presupuesto COM Compras SS

código numérico que identifica el subproyecto , 00 corresponde al proyecto de mayor jerarquía del

que se pueden o no desprender otros subproyectos. Código de Documento : TTT-ZZ-XXX , dónde TTT es un código alfanumérico que identifica el tipo de documentación. Se utilizará la siguiente nomenclatura: GPR Documentación de Gestión de Proyecto TEC - Documentación Técnica ADM - Documentación Administrativa REC - Documentación de los Recursos


Página 49


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subsección Codificación

Fecha 20/05/98


ANT - Antecedentes de la Organización , dónde ZZ

es un código numérico que indica la documentación perteneciente a una misma familia. , dónde XXX es un código numérico que identifica la

secuencia correlativa dentro de cada familia de documento b.

Criterios de Archivo  Se generarán dos carpetas por cada proyecto: una con mayor detalle en la Oficina de Proyectos de la Organización bajo reforma y otra con la información de la gestión del proyecto, ubicada en la Oficina Central de Proyectos. 

Cada carpeta estará compuesta por: un índice general, secciones por cada tipo de documentación identificadas mediante separadores y subsecciones por cada familia de documentos.



La información que por su volumen esté almacenada en un medio magnético (Ej: manuales), será referenciada dentro de la sección y subsección correspondiente, indicando la denominación del archivo magnético

.


Página 50


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Sección Subseccióon Carpeta de proyecto

Fecha 20/05/98


Carpeta de Proyecto 1. Objetivo  Describir una estructura tipo de carpeta de proyecto. 2. Alcance  Modelo de carpeta de proyectos. 3. Desarrollo Modelo de carpeta de proyectos El modelo representa un ejemplo que variará respecto de la documentación contenida de acuerdo a la dimensión , naturaleza y complejidad del proyecto.

Sección Subsección Carátula Indice General Documentación de Gestión del Proyecto Términos de Referencia del Proyecto Planes y programas de trabajo (estimados y ejecutados) Informes de Avance Actas de aceptación de servicios Verificaciones de calidad Controles de Cambio Reporte de conflictos Seguimiento de Costos

Código JJ-PPPPPP-SS

Documentación Técnica Fase Planificación Fase Diseño de soluciones Fase Implementación Documentación de los Recursos Recursos Humanos Equipamiento Alquileres Insumos Documentación Administrativa

TEC-0000 TEC-0100 TEC-0200 TEC-0300 REC-0000 REC-0100 REC-0200 REC-0300 REC-0400 ADM-0000

Antecedentes de la Organización

ANT-0000


GPR-0000

GPR-0100 GPR-0200 GPR-0300 GPR-0400 GPR-0500 GPR-0600 GPR-0700 GPR-0800

Página 51

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección ESTIMACION DEL TIEMPO ------------------------------

Fecha 20/05/98


Estimación de tiempo 1. Objetivo  Establecer una guía de acción para calcular los tiempos de los ciclos de vida del proyecto. 2. Alcance    

a. b. c. d.

Introducción Guías de acción. La Técnica Delphi Bitácoras y curvas de aprendizaje

3. Desarrollo a. Introducción Uno de los puntos más débiles de los proyectos y por lo que generalmente fracasan es la falta de tiempo por estimaciones erróneas. Las principales causas son:

b.



No se usan técnicas de estimación y si se utilizan, generalmente, están poco desarrolladas.



Se toman supuestos pocos válidos (Ej: “todo va a funcionar bien”)



Se confunde esfuerzo con progreso, creyendo que las personas y los meses son intercambiables. Por esto, la respuesta más frecuente ante los atrasos es colocar más gente, lo que generalmente provoca más costos y más retrasos.



Se utiliza peligrosamente el concepto de mes-hombre para medir el tamaño de una actividad, lo que implica aceptar tácitamente que las personas y los meses son intercambiables.



La urgencia del cliente determina el fin del cronograma, pero no necesariamente el fin del trabajo real



No se llevan buenos controles e historias, lo que imposibilita el autoaprendizaje y la aplicación de estimaciones por situaciones análogas.

Guías de acción:  Generar un manual de estimaciones que permita ir recopilando la experiencia de proyectos y actividades similares. Por cada actividad de la que exista un método definido se deberá especificar la clase de estimación, el método recomendado y el margen de seguridad.


Página 52

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE I: ADMINISTRACION DE PROYECTOS Capítulo Sección Subsección ESTIMACION DEL TIEMPO -----------------------------

Fecha 20/05/98


Existen básicamente tres tipos de estimaciones de acuerdo al ciclo de vida del proyecto5:



Orden de magnitud: se utiliza en las etapas más tempranas del proyecto (conceptualización). Se estima con muy pocos datos. Se usa, principalmente, la experiencia, aunque no necesariamente en proyectos similares. El margen de seguridad es del es del  35%  Aproximación: se utiliza durante la planificación de la primer fase.Tampoco se disponen de datos precisos pero pueden utilizarse otras experiencias análogas. El margen de seguridad es del es del  15 %  Estimación definitiva: se utiliza en el desarrollo de programas de trabajo. Se disponen de datos más precisos. El margen de seguridad es del  5% 

Los tiempos totales insumidos en mano de obra directa durante el ciclo de vida de un proyecto, estadísticamente se distribuyen de la siguiente manera 6:

Conceptualización y sensibilización Definición de proyectos y asignación de prioridades Planificación detallada Diseños Implementaciones Ajustes post-implementación 

5 % 10 % 15 % 20 % 40 % 10 %

En la planificación deben identificarse las segmentos según la siguiente clasificación:



Segmentos compuestos por actividades secuenciales .  Segmentos compuestos por actividades paralelas que requieren comunicación entre sí.  Segmentos compuestos por actividades paralelas que no requieren comunicación entre sí. 

El número máximo de meses de un proyecto depende de la secuencialidad. de las actividades.



El número máximo de personas depende del número de actividades independientes.



Las personas y los meses son ítems intercambiables (más personas menos meses, menos personas más meses) exclusivamente cuando un trabajo puede ser repartido entre varias personas sin necesidad de comunicación entre ellos.

Fundamento: 

Cuando un trabajo no puede ser repartido porque posee actividades secuenciales la aplicación de más personas (un esfuerzo mayor) no produce efecto alguno en el cronograma (más progreso)  En los trabajos que pueden ser repartidos entre varias personas pero requieren comunicación entre las actividades, debe adicionarse al trabajo propiamente dicho el esfuerzo de la comunicación. 5 Los márgenes de seguridad que se mencionan surgen de estadísticas citadas en “Project Management “ de Harold Kerzner, pág.722 6

Fuente: Project/Systems Management Research Institute

Primus


Página 53


Fecha 20/05/98




El esfuerzo de comunicación se integra de dos componentes: el entrenamiento y la intercomunicación.  El entrenamiento implica una relación personal con cada persona entrenada, no puede ser repartido. En consecuencia este esfuerzo varía proporcionalmente a la cantidad de personas.  El esfuerzo de coordinación para la intercomunicación aumenta a razón de n(n-1)/2. Ej: tres trabajadores requieren tres veces más esfuerzo que dos {3(3-1)/2= 3; 2(2-1)/2=1}. 

           

Transferencia de recursos de actividades no críticas a críticas. Eliminación de algunas partes del proyecto Adición de más recursos a tareas críticas. Sustitución de partes del proyecto por componentes que demanden menos tiempo. Realización de actividades en paralelo. Acortamiento de actividades críticas. Acortamiento de actividades tempranas. Acortamiento de actividades largas. Acortamiento de actividades fáciles. Acortamiento de actividades con menor costo en caso de ser aceleradas. Acortamiento de actividades para las que no se disponen de más recursos. Incremento de números de horas de trabajo diarias por recurso. 



Ante la necesidad de reducir los tiempos, y siempre considerando los riesgos que implican, se verificarán las siguientes alternativas:

Para las actividades críticas de las que no existan experiencias o registros históricos ,cualquiera sea el método de estimación utilizado, el método de cálculo parte de considerar:

Que existen tres apreciaciones del tiempo: 1. El tiempo optimista que asume que todo saldrá de acuerdo a lo planeado y que la cantidad de dificultades será mínima. 2. El tiempo pesimista que asume que nada irá como se planeó y que las dificultades serán muchas. 3. El tiempo más probable, que es tiempo que en la mente de quién calcula será el que se cumplirá.



Que la desviación estándar es un sector del tiempo total del rango.  Que, siguiendo la teoría de probabilidades, los tiempos más alejados del promedio están a tres desviaciones estándares.  Bajo estos supuesto el cálculo de la estimación se basa en la siguiente fórmula7:  

7

Te 

a  4m  b 6

F. S. Hiller y G. J. Lieberman, Introduction to Operations Research (San Francisco: Holden-Day, 1967), p. 229.


Página 54


Donde,

Fecha 20/05/98


Te, es el tiempo estimado a, es el tiempo optimista que asume que todo saldrá de acuerdo a lo planeado y que la cantidad de dificultades será mínima. b, es el tiempo pesimista que asume que nada irá como se planeó y que las dificultades serán muchas. m, es el tiempo más probable Ejemplo: si a = 3 días, b= 7 días y m=5 días, el tiempo estimado es 5 días





Para calcular la probabilidad del tiempo total para terminar, si la herramienta de software no lo calcula, se seguirá el siguiente procedimiento:

Determinar la desviación estándar de cada actividad 

 te 

ba 6

Donde,

 te desviación estándar del tiempo esperado



a, es el tiempo optimista



b, es el tiempo pesimista. Ejemplo: si a=2 y b=4, la desviación estándar de la actividad es igual a 0,33



La desviación estandar del total de actividades, siguiendo el cálculo de probabilidades es igual a la raíz cuadrada de la sumatoria de los cuadrados de las desviaciones estandar de cada actividad



total 

2 2 2   actividad 1 actividad2 actividad n

Ejemplo: si la actividad uno tiene una desviación estándar de 0.33 y la dos de 1 y la tres de 0.67, la desviación estándar total será de 1.25 días para una probabilidad del 68% de cumplimiento. Así para calcular una probabilidad de ocurrencia del 95% debe multiplicarse la desviación estándar por 2 y resultará 2.5 días y para una probabilidad del 99% debe multiplicarse la desviación estándar por 3 y resultará 3.75 días. c. La Técnica Delphi La técnica Delphi es un procedimiento sistemático para llegar a un acuerdo sobre un tema en particular (en este caso estimación del tiempo de una actividad o su costo) en base a las opiniones de expertos. Fue originalmente diseñado por la Rand Corporation. El procedimiento consiste en realizar cuatro ruedas de opiniones con sucesivos refinamientos a la estimación de la pregunta realizada:


Página 55


Fecha 20/05/98




En la primer rueda se solicita la primer estimación en base a una serie de especificaciones (Ej: realizar el relevamiento del área sistemas respecto software aplicativo de administración de recursos humanos, especificar en horas trabajando 1 especialista) sin previa discusión con los otros miembros del panel. El moderador recoge las opiniones y ubicadas en forma ascendente muestra los extremos y el promedio de las primeras respuestas.



En la segunda rueda, previo a mostrarles los extremos y promedio de la primer rueda, se les solicita una segunda estimación sin previa discusión. Los resultados se ordenan de mayor a menor y se identifican los extremos y el promedio. En este momento se compara con los resultados de la primer rueda y se les pregunta anónimamente a las personas que están en los extremos por qué sus respuestas están fuera del rango.



En la tercer rueda se le da al panel una explicación concisa de las razones de aquellas personas que aportaron posiciones extremas en la segunda rueda. Luego se les solicita una tercer estimación, determinando también los extremos y el promedio. Ante cualquier estimación que caiga en los extremos se les solicita a las personas que den una explicación de las razones.



La cuarta rueda se toma luego de que cada persona ha recibido los comentarios de la tercer rueda. Se determina como resultado el promedio de la cuarta rueda.

d. Bitácoras y curvas de aprendizaje  El procedimiento de generar bitácoras, consiste en llevar una historia de los tiempos mínimos, promedio y máximos insumidos por tipo de actividad o tarea con indicación del grado de experiencia de las personas que participaron. Esta técnica es de buena práctica en cualquier proyecto y exige una buena documentación. De esta manera en otro proyecto con tareas similares se aplicará los tiempos recopilados. 

La curva de aprendizaje es aplicable a tareas que sean repetitivas dentro del proyecto y según esta teoría, a medida que una persona o grupo de trabajo duplica su producción , se produce un ahorro entre el 10% y 30% del tiempo directo insumido en la actividad.


Página 56

Capítulo CODIGO DE ETICA

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Sección Subsección ----------------------------

Fecha 20/05/98


Código de Etica 1. Objetivo Establecer las normas éticas que deben orientar el trabajo de los integrantes del equipo del proyecto, en sus distintas responsabilidades, a fin de obtener y mantener el nivel profesional y confianza requerido por sus empleadores, funcionarios. 2. Alcance  a.  b.  c.

Respecto de la conducta personal y profesional. Respecto del trabajo y personas asignadas a cargo. Respecto de la relación con empleadores y destinatarios de servicios.

3. Desarrollo a. Respecto de la conducta personal y profesional  Aceptar la responsabilidad de sus acciones. 

Emprender proyectos sólo si está capacitado por entrenamiento o experiencia; o bien si ha sido aceptado por sus empleadores luego de haber expuesto sinceramente sus verdaderos conocimientos.



Mantener su nivel profesional, reconociendo la importancia de la capacitación continua.



Mantener la integridad y prestigio de su profesión mediante la práctica de modos de actuar nobles y dignos.



Sostener el presente código de ética y animar a los compañeros de trabajo y colegas a respetarlo.



Proveer el adecuado cuidado profesional que asegure la máxima productividad de los recursos que solicite o se le asignen, en orden a la concreción de los objetivos asignados.



Aplicar su mejor conocimiento y técnica tendientes a cumplir con la entrega de los productos en el tiempo y con la calidad comprometida. No hacer propio el crédito obtenido por otro colega o compañero de trabajo.



Obedecer las leyes y normas de los lugares en dónde se desempeñen.



Obedecer las normas profesionales y éticas emitidas por los Colegios o Asociaciones profesionales a las que pertenezcan.



Proceder con decoro y lenguaje apropiado.

b. Respecto del trabajo y personas asignadas a cargo:  Tratar con equidad y justicia a todos los participantes del proyecto, sin distinción de raza, religión, sexo, edad o nacionalidad. 

Proteger a los miembros del proyecto de daños físicos o mentales.


Página 57

Capítulo CODIGO DE ETICA


Fecha 20/05/98




Proveer condiciones dignas de trabajo y justas oportunidades de desarrollo a los miembros del equipo.



Asistir a los miembros del equipo, colegas y compañeros de trabajo en sus necesidades de desempeño profesional.



Realizar críticas objetivas y honestas que contribuyan al proyecto y crecimiento de las personas a las que están destinadas.



Reconocer los méritos de colegas e integrantes del equipo del proyecto.

c. Respecto de la relación con empleadores y destinatarios de sus servicios  Actuar como asesores de buena fe en sus relaciones profesionales con empleadores y destinatarios finales de sus trabajos. 

Mantener la confidencialidad de la información a la que tengan acceso y que sea de carácter privado o requiera autorización de su dueño o custodio, durante su desempeño y aún con posterioridad, hasta tanto la misma sea catalogada de uso público o se disponga de una autorización escrita expresa para difundirla.



Informar a sus empleadores o destinatarios de su trabajo o asociaciones profesionales de las que sea miembro de cualquier circunstancia que pueda generar un conflicto de intereses.



No dar ni aceptar, directa o indirectamente regalos, pagos o servicios hacia o de quienes tengan o puedan tener en virtud del trabajo que está realizando, relaciones comerciales con sus empleadores o destinatarios de trabajos.



Ser honesto y sincero en el reporte de los avances, de los costos y de la performance obtenida.


Página 58

Capítulo INTRODUCCION


Fecha 20/05/98


PARTE II – METODOLOGÍA Introducción 1. Objetivo  Explicar conceptualmente la metodología propuesta para la administración de proyectos.  Formular el enfoque de desarrollo de cada fase, segmento y actividad. 2. Propósito de la metodología La adherencia a una metodología provee una guía sistemática de acción que orienta a los participantes del proyecto respecto del alcance y orden sugerido en que deben realizarse las actividades para alcanzar el fin propuesto. Los principales beneficios son:  Facilitar la comunicación entre los miembros del equipo al aportar claridad respecto de qué actividades son conducentes a lograr el objetivo planteado, en qué orden es conveniente que se realicen, con qué otros trabajos están relacionados, quiénes son los principales responsables, qué productos deben obtenerse, qué insumos pueden utilizarse y, en algunos casos, el modo en que pueden ejecutarse (Ej: técnicas, herramientas, etc).  Proveer una lista de control (check-list) que facilite la verificación de no haber omitido pasos esenciales.  Proveer los puntos de control (chekpoint) que permitan medir en forma objetiva el progreso del proyecto, a fin de erradicar la perniciosa costumbre de determinar los avances por porcentajes que, generalmente, responden a “sensaciones” o intenciones de mostrar logros que no responden a la realidad.  Proveer medidas válidas de rendimiento.  Ahorrar tiempo  Utilizar en forma eficiente las herramientas y técnicas disponibles en el mercado.  Facilitar la determinación de los roles y responsabilidades de los participantes.  Facilitar la reproducción para situaciones similares.  Agilizar los procesos de capacitación de los miembros del equipo. 3. Enfoque del desarrollo Es dable aclarar que no existe una convención respecto de la cantidad y denominación de las fases o etapas que comprende el ciclo de vida de un proyecto. En general, y siguiendo las definiciones de Cleland y King, se verifican en cualquier proyecto los siguientes estados de madurez: concepción (la idea), planificación, diseño, desarrollo o producción y conversión o transformación. El orden de las fases transcurre desde el máximo nivel de abstracción hasta el mínimo nivel de concreción. Así es como también cada fase es en sí misma un proyecto, ya que se requiere que se planifique, diseñe y ejecute.


Página 59

Capítulo INTRODUCCION


Fecha 20/05/98


En cada proyecto se analizará el punto de partida y los antecedentes que están disponibles a fin de plantear qué actividades son necesarias realizar. No es imperativo que se transiten todas las actividades y sí es conveniente que al principio de cada fase se repitan las actividades de Organización a fin de verificar qué se ha hecho y con qué calidad. Así cuando del análisis de los antecedentes que deberían estar disponibles por estar comprendidos en una fase anterior, se advierta que no existen o están incompletos o fueron mal ejecutados, se volverán a reiterar en la presente etapa sin necesidad de repetir en forma completa la fase anterior. En el caso particular del presente desarrollo, está orientado a la gestión de proyectos relacionados con transformaciones en los sistemas de gestión administrativos que, a su vez contienen proyectos informáticos, reingeniería de procesos y reorganizaciones estructurales, principalmente. Se ha omitido en el desarrollo de la metodología la fase que produce el Modelo de Gestión estándar que sirve como base para constatar las realidades provinciales y orientar las transformaciones. El Esquema del Proyecto se ha divido en fases, segmentos y actividades. La metodología plantea jerarquías de fases, segmentos y actividades. Las fases identifican los principales momentos o etapas del ciclo de vida del proyecto. Tiene productos determinados y cada una puede ser desarrollada como un proyecto en sí mismo. Las fases se han subdivido en segmentos que son grupos de actividades que por analogía o conveniencia se tratan en forma conjunta y que, generalmente, su terminación habilita para la continuidad de otro segmento. Los segmentos están subdivididos en actividades. Las actividades identifican los esfuerzos operativos que deben producir a su terminación resultados concretos. Por cada fase se describen: objetivo, segmentos comprendidos, enfoque de desarrollo, productos principales y puntos de control. Por cada segmento se describen: objetivo del segmento, actividades comprendidas, productos principales y puntos de control. Por cada actividad se describen: objetivo , tareas comprendidas, desarrollo, insumos, productos, documentación y herramientas. Eventualmente, se citan ejemplos.


Página 60

-

Primus

Consultores Asociados -

I.a.2. Estudio Inicial y Diagnóstico

I.a. SENSIBILIZACION

I.a.1. Organización

FASE 1: PLANIFICACIÓN

I.a.3. Identificación de Procesos Críticos y Desarrollo de Visión

-

I.b.2.. Definición de Estrategias Globales

I.b.3. Definición de los Proyectos

-

I.b.4. Asignación de Prioridades y elaboración de los Términos de Referencia

I.b. DEFINICION DE PROYECTOS Y ASIGNACION DE PRIORIDADES

I.b.1. Organización

Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Compendio -----------------Fecha 20/05/98 Versión Recomendado

I. Planificación

Página 61

Fase I – PLANIFICACION

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Compendio ------------------

Fecha 20/05/98


1. Objetivo  Entender los objetivos estratégicos de la Organización e identificar los Factores Críticos de Éxito de un modelo de gestión eficiente.  Reconocer la realidad del modelo de gestión vigente e identificar las necesidades vitales de cambio para alcanzar los objetivos de desarrollo.  Desarrollar la visión del nuevo modelo de gestión en su máximo nivel de abstracción- y aproximar el esfuerzo que su concreción implica.  Definir y priorizar los proyectos que permitan concretar la visión declarada por la Alta Conducción.  Obtener el respaldo y compromiso de la Alta Conducción para implantar lo planificado. 2. Segmentos  I.a. Sensibilización  I.b. Definición de proyectos y asignación de prioridades. 3. Enfoque del desarrollo La presente fase está orientada al horizonte estratégico: los proyectos que en los próximos 2 a 4 años permitirán hacer realidad el nuevo modelo de gestión., conforme a la visión de la Alta Conducción. Durante esta etapa:  Se evaluará el modelo de gestión vigente a fin de reconocer los puntos fuertes y débiles, que permitan determinar las oportunidades de mejora que sustenten un cambio del modelo de gestión.  Se desarrollará la visión del modelo de gestión que permita cumplir con los objetivos estratégicos planteados por la Alta Conducción.  Se definirán los proyectos con sus respectivas prioridades.  Se obtendrá la aprobación y patrocinio de la Alta Conducción respecto del plan integral que habilitará el comienzo de la fase de Diseño de Soluciones. El uso de una metodología, como la propuesta en este manual, no asegura el éxito de la planificación ni que su realización sea sencilla. No debe olvidarse que los Organismos, en general y las Administraciones Educativas, en particular se mueven en ambientes cambiantes en lo político, económico y social. Por ello, durante el desarrollo de la fase deben considerarse especialmente los siguiente aspectos:  Obtener compromiso y participación de la Conducción El apoyo de toda la Organización dependerá fundamentalmente del respaldo y participación que el principal responsable y sus colaboradores inmediatos, brinden al esfuerzo de planificación. Es altamente probable que los proyectos de transformación de la gestión administrativa compitan respecto de los recursos financieros y humanos, con proyectos de otras áreas de interés. Por esta razón, la Conducción deberá participar activamente en la definición del alcance y prioridades de


Página 62



Fecha 20/05/98


los proyectos.  Definir el alcance de la planificación A fin de no desperdiciar esfuerzos en tareas de planificación que no sean conducentes al logro de los objetivos estratégicos del Organismo, deberá definirse el alcance respecto de dos dimensiones: horizonte y cobertura. 

Respecto del horizonte: El horizonte indica el número de años que cubrirá la planificación. Este lapso, generalmente se ubica entre los 2 y 4 años. Este plazo es razonable como para lograr transformaciones importantes que colaboren con los objetivos estratégicos del Organismo y se puedan cumplir dentro del período político de gestión de la Conducción. A su vez, es suficientemente corto como para hacer aproximaciones de los requisitos necesarios.



Respecto de la cobertura: Se refiere a los procesos y proyectos que serán incluidos en la planificación. Para definir el alcance de los procesos se propone una metodología que contempla los Factores Críticos de Éxito y la calidad de los diferentes procesos. El alcance de la planificación de los proyectos dependerá:



Del grado de similitud de los requerimiento de los diferentes procesos.  Del grado de madurez administrativo que exija la atención de necesidades primarias generales o de requerimientos muy específicos.  De la capacidad de gestión del Organismo que permita absorber transformaciones importantes en una sola etapa o gradualmente.  Del plazo que la Conducción tiene para concluir su gestión. Si los planes de transformación responden a proyectos que exceden dicho plazo, se corre el riesgo de que la próxima Conducción no adhiera a las mismas estrategias. Este aspecto debe ser cuidadosamente considerado al establecer el alcance.  Reconocer que el plan cambiará El plan desarrollado no debe verse como inflexible. Los planes serán reevaluados y actualizados cada cierto tiempo y sufrirá periódicas enmiendas. Por ello, es importante que los planes de transformación de la gestión administrativa estén integrados al plan general de la Organización.  Planear el nivel adecuado de detalle Es inconveniente que en la etapa de definición de la transformación se llegue a un excesivo nivel de detalle y exactitud, por otra parte difícil de lograr atento al nivel de los relevamientos realizados. Las planificaciones de mayor detalle serán el objetivo de un proyecto subsiguiente. 4. Productos principales  Diagnóstico con identificación de oportunidades de mejora.  Declaración de la visión .  Términos de referencia de los proyectos


Página 63



Fecha 20/05/98


5. Puntos de control Los principales eventos que deben controlarse para asegurar la eficacia de la fase son:  El diagnóstico, a nivel de un Resumen Ejecutivo, que exprese las debilidades advertidas y oportunidades de mejora.  La adherencia de la Alta Conducción a través de su máximo responsable o de quienes lo representen, asegurando que el consenso se manifieste por escrito en un acta de compromiso que exprese globalmente la visión de la Organización hacia la tiende mediante la descripción de los factores críticos de éxito y una breve explicación de la estrategia a seguir.  El ajuste al cronograma.  La eficacia en la transmisión de la visión al resto de la Organización y principalmente a las áreas funcionales que se verán afectadas La definición y aplicación de criterios adecuados para seleccionar los procesos críticos y determinar las prioridades de los proyectos.  La definición de los Términos de Referencia con aproximación de recursos, costos, cronogramas y riesgos.


Página 64


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización Compendio

Fecha 20/05/98


I.a. Sensibilización 1. Objetivo  Entender los objetivos estratégicos de la Organización e identificar los Factores Críticos de Éxito.  Obtener el consenso de la Alta Conducción respecto de la visión del modelo de gestión - a nivel conceptual- que desea promover y el esfuerzo que su concreción implica.  Obtener el patrocinio y compromiso de la Alta Conducción para continuar con la definición y planificación de los proyectos que viabilicen el proceso de reforma.. 2. Actividades  I.a.1. Organización  I.a.2. Estudio inicial y diagnóstico.  I.a.3. Identificación de procesos críticos y desarrollo de la visión 3. Desarrollo: Durante esta etapa:  Se identificará el contexto, los objetivos estratégicos del Organismo y las Factores Críticos de Éxito de la Alta Conducción.. El reconocimiento de la realidad se realizará mediante un relevamiento estructurado que contrastará un modelo de gestión ideal con el vigente en el Organismo estudiado.  Se evaluará el modelo de gestión vigente. De allí surgirán los puntos fuertes y débiles, que permitan determinar las oportunidades de mejora y consecuentes recomendaciones, que sustenten un cambio del modelo de gestión.  Se elaborará una visión global del modelo estratégico de la Organización , que deberá estar caracterizado por los Factores Críticos de Éxito definidos por la Alta Conducción. Esta visión conformará una declaración de objetivos y metas lo suficientemente clara y motivadora como para ser trasmitida a todo el Organismo. Se desarrollará en este segmento la estrategia de difusión de la visión..  Se desarrollará la visión del modelo de gestión que permita cumplir con los objetivos estratégicos planteados por la Alta Conducción.  Se seleccionarán los procesos críticos que deben ser mejorados o reformulados mediante una metodología de asignación de prioridades. 4. Productos principales  Diagnóstico con identificación de oportunidades de mejora.  Declaración de la visión .


Página 65


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización Compendio

Fecha 20/05/98


5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  El ajuste al calendario de entrevistas.  La preparación de las entrevistas y el conocimiento previo de las principales características estructurales y funcionales de la mayoría de los Ministerios de Educación u Organismos similares.  La claridad y rigurosidad técnica de los informes ejecutivos.  La definición correcta de los Factores Críticos de Éxito.  La claridad de la terminología utilizada en la declaración de la visión.  La adherencia de la Alta Conducción a través de su máximo responsable o de quienes lo representen, al proceso de reforma. El apoyo y patrocinio de la Alta Conducción debe ser permanente y visible ante toda la Organización.


Página 66

Primus


-

I.a.1. Organización -




I.b.4. Asignación de Prioridades y Elaboración de los Términos de Referencia

I.a.1.4. Preparar el cronograma de entrevistas

I.b. DEFINICION DE PROYECTOS Y ASIGNACION DE PRIORIDADES -

I.a.1.3. Preparar el material y entrenar el equipo de trabajao

I.a.1.2. Organizar el equipo de trabajo


Fecha 20/05/98

-

I.a.1.1 Realizar entrevista inicial con el Responsable Mayor de lla Alta Conducción

-





Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.1. Organización Versión Recomendado


Página 67


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.1. Organización

Fecha 20/05/98


1. Objetivo  Asegurar el compromiso y la participación de la Alta Conducción en la fase de planificación.  Organizar el equipo de trabajo. 2.

Tareas    

3.

I.a.1.1. I.a.1.2. I.a.1.3. I.a.1.4.

Realizar entrevista inicial con el responsable mayor de la Alta Conducción Organizar el equipo de trabajo. Preparar el material y entrenar el equipo de trabajo. Preparar el cronograma de entrevistas.

Desarrollo I.a.1.1. Realizar la entrevista inicial con el responsable mayor de la Alta Conducción La primera entrevista se realizará con el responsable mayor de la Organización (Ministro, Director Gral. de Escuelas, Presidente del Consejo de Educación, Subsecretario de Educación, etc). Es conveniente que sea breve, salvo que se extienda ante inquietudes manifestadas por el entrevistado. Los objetivos de la entrevista inicial de presentación son: 

Explicar brevemente los resultados que se esperan obtener de la presente fase y la importancia de la participación real y efectiva de la Alta Conducción en el proceso de transformación.



Designar un responsable por parte del Organismo (Coordinador) encargado de recolectar los antecedentes solicitados y coordinar las entrevistas a realizar durante la actividad de Estudio Inicial.



Establecer la fecha de convocatoria para mantener una reunión introductoria con los responsables principales de las áreas funcionales que serán relevadas a fin de explicarles los objetivos y alcance la presente fase.

Para la reunión introductoria con los responsables de las áreas funcionales se sugiere que el Responsable Mayor convoque a los funcionarios de las siguientes áreas: Secretaría General, Planificación, Presupuesto y Contabilidad, Abastecimiento, Personal, Juntas de Clasificación, Juntas Disciplinarias, Direcciones de Nivel , Control Médico o Junta Médica, Sistemas, Asesoría Letrada y Mesas de Entradas 8

I.a.1.2. Organizar el equipo de trabajo El equipo de trabajo requerido no configura, en esta fase, una Oficina Provincial de Proyectos, 8

Es probable que las áreas mencionadas respondan a otros nombres o que algunas no existan


Página 68



Fecha 20/05/98


si es que aún no existe. Una Organización tentativa es que esté integrado por el Gerente Regional de Proyectos, un representante por la Alta Conducción (funcionario de jerarquía), el Coordinador del Organismo, un especialista en análisis organizacional y/o funcional ,y un especialista en sistemas informáticos. Los especialistas mencionados pueden ser aportados por la Oficina Central de Proyectos a través del Equipo de Expertos. Entrevistar al Coordinador designado a fin de explicarle el enfoque, los objetivos, el plan de trabajo a realizar durante el primer segmento y los productos a obtener. Es aconsejable que el Coordinador conozca integralmente el Organismo y mantenga sólidas relaciones personales con los responsables de las distintas áreas funcionales. Si no existe en la Organización una persona con estas habilidades, debe considerarse la incorporación de un asesor con experiencia en las gestiones a relevar y en gestión de proyectos.

I.a.1.3. Preparar el material y entrenar el equipo de trabajo Los pasos sugeridos son: 

Solicitar al Coordinador los siguientes antecedentes: a) organigramas más actualizados (supletoriamente un dibujo hasta el 4° nivel de responsabilidad que surja de la entrevista con el coordinador , b) identificación de los responsables principales, horarios de trabajo, formación que poseen, etc.; c) normas vinculadas al área que se va a investigar; d) antecedentes de proyectos relacionados y e) mapa con indicación de la dispersión geográfica de las unidades organizativas a relevar.



Ajustar los esquemas de relevamiento a las áreas funcionales y unidades organizativa que figuran en el organigrama. El equipo parte del conocimiento de una situación inicial ideal correspondiente a lo que sería un modelo de gestión eficiente del que se desprende una estructura de preguntas que tratarán de constatar ese “ideal” con la realidad del Organismo a estudiar.



Acordar los indicadores de rendimiento que se medirán durante el relevamiento. Los indicadores de rendimiento se pueden expresar a través de indicadores positivos (cuya mejora es aumentarlos) o negativos (cuya mejora es disminuirlos). Ejemplos de medidas de rendimiento son:



Días promedio de resolución de un trámite (Expediente)  Días perdidos de clases que originan dobles pagos  Porcentaje de ausentismo  Días promedio para tramitar una licencia de largo tratamiento I.a.1.4. Preparar el cronograma de entrevistas Los pasos sugeridos son:


Página 69


4.

Fecha 20/05/98




Programar suficientes entrevistas para asegurar que se cubran adecuadamente todas las áreas funcionales.



Establecer la estrategia de comunicación, de confirmación y de reemplazos.



Programar entrevistas en grupo entre el personal con responsabilidades similares, siempre que sea posible.

Insumos principales     

5.


Organigramas. Antecedentes de estudios de gestión que estén vigentes. Antecedentes de proyectos anteriores de reforma realizados en el Organismo Antecedentes de proyectos del Programa de Reforma Administrativa Guías de relevamiento

Productos principales  Cronograma tentativo de entrevistas.  Guía de relevamiento adaptada.  Programa de trabajo del resto del segmento.

6.

Herramientas y Técnicas     

Administración de Proyectos. Manejo eficiente de reuniones. Presentaciones efectivas. Formación de equipos de trabajo. Técnicas de entrevistas.


Página 70



Fecha 20/05/98


7. Ejemplos  GUIA DE RELEVAMIENTO A. DATOS ESTRUCTURALES Y FUNCIONALES: Ubicación del Organismo dentro del organigrama de Gobierno. Adjuntar fotocopias de antecedentes legales (Constitución Provincial, Ley de creación, Estatuto del docente, etc). Organigrama hasta nivel de Direcciones. Existe otro organismo dentro del Poder Ejecutivo con áreas de incumbencia que se solapen y generen zonas de responsabilidades compartidas? Existe un manual de misiones y funciones (Si existe, factibilidad de disponer de una copia) Cuál es el grado de coherencia entre el organigrama formal y funciones definidas con la realidad? Promueven la descentralización operativa? Hasta qué nivel pretenden llegar respecto de las principales gestiones (Ej.: administración de legajos, abastecimiento de escuelas, presupuesto, etc)? B. DATOS DE LA PLANTA DE PERSONAL: ESTRUCTURA DE LA PLANTA DE PERSONAL CANTIDAD TOTAL

(en personas) pepersonas) INTERINOS Y/O

ESCALAFON TITULARES

SUPLEMENTES

SUBTOTALES PRESUPUESTARIOS (En miles de pesos) INTERINOS Y/O TITULARES SUPLEMENTES

Funcionarios Profesionales Personal Administrativo Personal de Servicios Subtotal 1 Supervisores Docentes nivel inicial Docentes nivel primario Docentes nivel medio Docentes nivel superior Auxiliar docentes t/niveles Subtotal 2 TOTAL GENERAL

C. DATOS PRESUPUESTARIOS: DISTRIBUCION DEL GASTO POR NIVEL ORGANIZATIVO (en miles de pesos) CONCEPTO Año (actual - 2) Año (actual - 1) Año Actual Ejecutado Ejecutado Autorizado Administración Central Educación Pública Nivel Inicial Nivel Primario Nivel Medio Nivel Superior Nivel Permanente Nivel Especial Educación Privada TOTAL


Página 71





Fecha 20/05/98


GUIA DE RELEVAMIENTO

DISTRIBUCION DEL GASTO SEGUN CLASIFICACION ECONOMICA (En miles de pesos) CONCEPTO Año (actual - 2) Año (actual - 1) Año Actual Ejecutado Ejecutado Autorizado Bienes Servicios Personal Erogaciones Bs. de Capital Transferencias Servicio de la Deuda Trabajos públicos Otros TOTAL

D. PLANES ESTRATÉGICOS Y PROYECTOS: Existe un plan maestro de las reformas administrativas y organizativas a realizar en los próximos años? Está formalizado el plan y sus programas con metodología de planificación estratégica o tradicional? Existe un sector específico con esta responsabilidad? Cuáles son sus principales proyectos por área de gestión administrativa? Tienen presupuesto previsto o trámites en estado de aprobación o aprobados con organismos internacionales? (Especificar proyectos, objetivos, montos)? Cuál ha sido la experiencia en el cumplimiento de las metas? ¿Cómo miden objetivos? Tienen gente entrenada en planificación y control de gestión de proyectos? E. INFRAESTRUCTURA INFORMATICA Y DE TELECOMUNICIONES: Existe una Dcción.. Provincial de Informática u organismo rector que fije normas respecto de los sistemas de información automatizados e infraestructura informática y de comunicaciones? Cuál es la relación? Debe pedirse autorización para encarar algún proyecto en el área de sistemas sea por soluciones en hardware, software o comunicaciones? Tienen centros de cómputos o de información? Cuántos? Existe dentro del Ministerio un área que coordine la generación, crecimiento e implementación de los sistemas de información en sus distintos componentes: informáticos, administrativos, comunicaciones y capacitación. Existe un mapa de sistemas? Existe un plan maestro de sistemas de información y de comunicaciones? Existen manuales de funciones? (Indicar nivel de actualización). Cuál es el equipamiento disponible? (Solicitar inventario con distribución de equipos por tipo y ubicación) Cuál es la tecnología utilizada (Ej.: propietaria, redes de PC’s, UNIX, etc? Cuál es el modelo de procesamiento más utilizado (Ej.: centralizado, distribuido, etc). Existe una estructura de comunicaciones disponible dentro de los edificios de la Administración Central (Ej: cableado estructurado), entre los edificios de la Administración Central (Red Metropolitana), entre la Administración Central y las escuelas, delegaciones o regionales (Red de Area Extendida - WAN). Indicar porcentaje estimado de cobertura por tipo de vínculo (ej.: teléfono conmutado, teléfono dedicado, radio-enlaces, microondas, fibra óptica y satélite) Proyectos en comunicaciones. Indicar expansión respecto de situación actual y fecha probable de concreción. Administradores de redes más utilizados (Ej.: Novell, Lantastic, Lan Manager, UNIX, etc) Señalizaciones más utilizadas (Ej.: Token Ring, Ethernet, etc). Protocolos más utilizados (Ej.: SNA, TCP/IP, X.25, etc). Porcentaje del presupuesto afectado a contratos por informática y telecomunicaciones. Cuántas personas están afectadas al área de sistemas y de comunicaciones? Nivel de profesionalismo del área de sistemas (Ej.: x % de idóneos, x% de universitarios, etc).


Página 72





Fecha 20/05/98



GRADO DE AUTOMATIZACION DE CADA GESTION AREA / GESTION

EQUIPAMIENTO CAPTURA DE SISTEMAS NIVEL DE AUTOMATIZACION EN INFORMATICOS DE NOVEDADES EN .... INFORMATICO DE ... .... MINISTERIO

Tablero de Comando (Información para Toma de Decisiones) Formulación Presupuestaria Ejecución Presupuestaria Control Presupuestario Sistema de Responsables Pagos (Tesorería) Sistema Contable Abastecimiento para Edificios Escolares Control de uso de servicios públicos Gestión de Edificios Escolares Legajos docentes Legajos no docentes y administrativos Administración de actividades y tiempos Administración de puestos (carreras profesionales) Administración de Plantas Funcionales Selección de Personal Evaluación Personal Capacitación de Personal Control de Ausentismo Liquidación de Haberes Seguimiento de Piezas Administrativas Secretaría General (Digesto Automatizado)

F. NIVEL DE DESCENTRALIZACION Gestión

Adm. Central

Delegaciones Colegios /Regionales

Formulación Presupuestaria Ejecución Presupuestaria Control Presupuestario Contabilidad Sistema de responsables Inventario de bienes de capital Inventario de bienes de consumo Compras/ Abastecimiento Pagos Recolección novedades sueldos (control ausentismo) Administración legajos Selección de Personal Capacitación Liquidación de sueldos Asesorías letradas Auditorías Mantenimiento de edificios escolares Archivos


Página 73



 GUIA G. GESTIÓN PRESUPUESTO: (Cuestionario para los responsables del área)

Fecha 20/05/98


DE RELEVAMIENTO

Adjuntar antecedentes legales de la Ley de Contabilidad, Ley de Procedimientos Administrativos, Ley de Compras, etc. Grado de centralización y descentralización de la formulación, ejecución y control presupuestario. Formulación Presupuestaria: Se trabaja con presupuestos por programa? Metodología (Se solicitan datos a las escuelas?, se toma el presupuesto anterior ?, se trabaja en pesos y/o unidades? , existen planillas tipo e instructivos?, etc) Registración (Se registra en el Ministerio de Educación o en Hacienda?, es manual o automatizado?) Personal afectado durante la formulación Ejecución Presupuestaria: Metodología (Qué momentos se registran: preventivo, definitivo, mandado a pagar, pagado?) Registración (Manual o automatizado?, está integrado al sistema Contable y de Tesorería?, cuál es el nivel de descentralización?, se registra en el Ministerio de Educación o en Hacienda?) Frecuencia Personal afectado. Control Presupuestario: Qué sector lo realiza y qué metodología utilizan? Frecuencia Personal afectado. Acciones correctivas. Existen controles cruzados con sistema financiero y patrimonial? Con qué facilidad (oportunidad, confiabilidad, versatilidad) se obtiene información del presupuesto? Se depende en grado extremo de Hacienda? Está integrado el presupuesto de cargos al sistema presupuestario general? Contabilidad de Responsables: Existe un sector afectado al Sistema de Responsables? Existen manuales de procedimientos? Cuántas personas están afectadas? Existen normas legales que regulen este sector? Se realizan auditorías? Son internas o externas? Con qué frecuencia? H. GESTION DE PAGOS: Qué pagos realiza las Habilitaciones (si existen?), la Tesorería del Ministerio y la Tesorería de la Provincia? Desarrollar el circuito administrativo por las siguiente gestiones (pago de sueldos, rendiciones de fondos fijos y fondos permanentes, compras menores a proveedores, pago de servicios públicos, pago de compras por concursos, licitaciones privadas y públicas). Por cada una de las gestiones descriptas en el punto anterior quién autoriza el pago, quién genera la Orden de Pago, quién emite el cheque, quién lo entrega y quién registra) Existen procedimientos escritos? Cuántas personas están afectadas directamente al proceso de pagos dentro del Ministerio? Existe división entre la registración financiera/contable (emisión de ordenes de pago y cheques) y el efectivo pago? Cuál es el procedimiento de autorización de pagos? Existen firmas conjuntas? Existe un registro especial por la deuda con análisis por proveedor y por anticuación? Se administran fondos fijos? Quienes son los responsables? Con cuantos Bancos trabajan? Cuántas cuentas tienen abiertas? (ej.: una por cada escuela)


Página 74



Fecha 20/05/98


 GUIA DE RELEVAMIENTO Cuáles son los medios de pago utilizados (cheques, débito automático) Está integrado el sistema de Tesorería al sistema presupuestario y al contable. Si existe automatización de la gestión, cuáles de las siguientes gestiones tienen automatizadas: Emisión de Orden de Pago (integración con Contabilidad - Mandado a Pagar) Afectación del presupuesto financiero Emisión de cheques (Cargo al Tesorero) Integración con Contabilidad (pagado) Conciliación bancaria I..

GESTIÓN ABASTECIMIENTO DE ESTABLECIMIENTOS ESCOLARES: (Cuestionario para los responsables del área) Está centralizada en la Administración Central o descentralizado a nivel de regionales o escuelas o es mixta? (averiguar respecto de qué y quienes)? Se administran fondos fijos o fondos reintegrables en las escuelas? Cómo se determinan las necesidades de las escuelas? Quién realiza la gestión de compras? Cómo se controla que lo que requiere la escuela se entregue efectivamente y que el dinero no se derive a otros gastos? Existen manuales de procedimientos, reglamentaciones y normas legales respecto del manejo la gestión de la compra? Cuántas personas están afectadas directamente al proceso de compra tanto en Administración Central como en las Regionales o Escuelas? Cuáles son los niveles de autorizaciones para las compras? Se manejan para los proveedores los mismos códigos que el Ejecutivo? Cantidad promedio de compras directas, licitaciones privadas y licitaciones públicas por ejercicio. Si existe automatización de la gestión, cuáles de los siguientes eventos están automatizados?: Antecedentes de Proveedores (legajo por cada uno con indicación del grado de cumplimiento) Modelos de pliegos Invitación a proveedores Pedidos de compra de oficinas, pudiendo verificar su estado. Integración con sistema contable/presupuestario (preventivo) Cronogramas de gestión agendas (redacción pliego, publicación, apertura, etc) Legajo completo de la compra Emisión de Ordenes de Compra Integración con sistema contable/presupuestario (definitivo) Control de cumplimiento de O. de Compra Emisión de notificaciones a proveedores por incumplimientos Sistema utilizado para compras menores (Fondos Fijos) Cuál es el procedimiento de rendición de las escuelas?


Página 75



Fecha 20/05/98


 GUIA DE RELEVAMIENTO GESTIÓN DE CONTROL DE USO DE LOS SERVICIOS PÚBLICOS: (Cuestionario para los responsables del área) Existen pautas respecto del control de los servicios? Existen estándares de consumo por cada escuela y tipo de servicio (teléfono, gas, energía, etc? Se lleva un registro en unidades por cada escuela y tipo de servicio? Si no se lleva el registro del punto 3, cómo se proyecta el presupuesto? Cuál es el grado de descentralización en el control? Cuáles son las acciones correctivas ante los abusos? J.

K. . GESTIÓN DE EDIFICIOS ESCOLARES: (Cuestionario para los responsables del área) Existe un sector responsable de la planificación y mantenimiento de edificios escolares? Existe dentro del Poder Ejecutivo otro sector responsable de la presente gestión (Ministerio de Obras y Servicios Públicos). Si es así como se distribuyen las áreas de incumbencia? Nivel de descentralización en la ejecución del mantenimiento (Personal propio, convenios con cooperadoras, convenios con Municipalidades, etc). Cuántas personas trabajan? Cuáles son sus perfiles? Cuáles son los criterios de asignación de fondos? Cuáles son los criterios de control de gastos? Existe un sistema de información que permita por cada edificio escolar historiar los siguientes ítems? Estado estructural de las escuelas Aulas disponibles (capacidad de cada una y estado) Bancos Teléfono Servicios disponibles Cuerpo de profesores/maestros Cronograma de mantenimientos preventivos Inversión requerida en cada escuela existente para mantenimiento y mejoras Cuáles son las inversiones previstas en nuevas escuelas? L.

GESTIÓN DE RECURSOS HUMANOS: (Cuestionario para los responsables del área)

Administración de legajos Los legajos están centralizados en la Administración Central o descentralizado en delegaciones o en las escuelas? Cuáles son las formas de identificar un legajo (Nro. correlativo, CUIL, etc)? Cuántos legajos puede tener un agente (Personal, Junta de Clasificaciones, Junta de Disciplina, Junta Médica, Liquidaciones, etc)? Si existen varios legajos por cada agente, se identifican de manera uniforme? Existen normas escritas de los procedimientos? Cuantos legajos administran?


Página 76



Fecha 20/05/98


 GUIA DE RELEVAMIENTO Cuánto espacio ocupan? Cuántas personas están afectadas al tema en Adm. Central? Cuál es la metodología de actualización de los comprobantes (los envían las escuelas?, los envían las delegaciones?, se traslada el docente a la Adm. Central?, etc). Dónde se archiva la documentación? Existe documentación duplicada en distintos archivos o sectores? Qué volumen de novedades mueven por mes/día? Cuál es el nivel de automatización de la presente gestión? Administración de Plantas Funcionales: Cuál es procedimiento de un nombramiento? Conocen en la actualidad cuantos cargos están presupuestados por grado o materia por cada escuela y cuáles son las vacantes? Conocen en la actualidad cuántos titulares y suplentes tienen? Cuál es la metodología y frecuencia de actualización de novedades? Existen coincidencias con los cargos ocupados y vacantes determinados en presupuesto y en las plantillas de nómina? Qué sector concentra la información? Se puede hacer el seguimiento de un cargo identificando su evolución en el tiempo (Ej: generación, reserva, designación, transformación, personas que lo ocuparon, etc) Cuál es el nivel de automatización de la presente gestión? Control de Ausentismo: Existen normas escritas de los procedimientos? Está centralizado o descentralizado? Está privatizado? Se conoce el costo de pagos de suplentes por licencias cortas y licencias largas? Se administran estadísticas que permitan detectar las causas más frecuentes para aplicar medidas sanitarias preventivas y diseñar políticas de salud? Cómo se administran las novedades de la Administración Central y las provenientes de los colegios? Cuál es la frecuencia? Cuál es el volumen? Qué soporte utilizan (diskette/papel) Cuántas personas trabajan en este sector? Como se registra? (Tarjetas, firmas en planillas, credenciales magnéticas, etc) Cómo llegan las novedades desde las escuelas? (frecuencia, volumen) Está integrado el sistema al de liquidación de sueldos? Cuál es el nivel de automatización de la presente gestión? Liquidación de haberes y procesamiento de sueldos: Recabar antecedentes legales Existen normas escritas de los procedimientos? Describir el procedimiento desde la recepción de novedades que afecten la liquidación hasta llegar al momento de la cobranza del agente en el Banco o Tesorería.


Página 77



Fecha 20/05/98


 GUIA DE RELEVAMIENTO Quién procesa (Hacienda, procesamiento propio o tercerizado) Cuántas liquidaciones se hacen al mes? La identificación en el recibo de sueldo es distinta de la del legajo principal? Si un profesor tiene distintos cargos, se hace un recibo único? Cuál es la modalidad de cobranza (cheque, acreditación automática, efectivo)? Cuál es la relación con Contaduría General de la Provincia? Quién tiene la responsabilidad del resultado del procesamiento? Cómo administran los descuentos que no son de ley (mutuales, sindicatos, farmacias, etc)? Los permiten? Si los permiten se dan casos que excedan el sueldo disponible? Cómo manejan estas situaciones? Como envían la información a la Caja de Jubilaciones? Selección: Existen normas escritas? Se toman exámenes de evaluación para las incorporaciones del personal administrativo? Existen registros de postulantes? Se lleva en la Junta de Clasificación, en las Delegaciones o en las escuelas? Existen perfiles de cargos para aparear con perfiles de postulantes?

Evaluación: Existen normas escritas que indique qué y cómo se evalúa? Se hacen regularmente evaluaciones? Se actualizan los legajos con estas evaluaciones? Cómo se manejan los premios y castigos? Capacitación: Está programada la capacitación de los niveles administrativos? Se conocen las necesidades? Se trabaja con recursos propios/terceros/mixtos? Qué presupuesto tiene asignada esta gestión? Se dejan los antecedentes en el legajo? M. ADMINISTRACIÓN DE NORMAS LEGALES Y DICTÁMENES: Cuántos abogados trabajan como asesores letrados? Cuantos administrativos? Cuál es el tiempo promedio de resolución de trámites? Cuántos trámites (asuntos sometidos a dictamen) se generan en promedio por año? Cuál es el nivel promedio de atraso ? Está automatizada la gestión? Se tienen estadísticas de juicios ganados/perdidos por tipo de demanda (Ej.: indemnizaciones, etc) y montos involucrados? N.

GESTIÓN DE MESAS DE ENTRADAS Y ARCHIVOS:


Página 78





Fecha 20/05/98



Cuántas personas trabajan en la Mesa de Entradas o sector responsable? Si existen varias Mesas de Entradas, están integradas? Cuántas personas trabajan en el Archivo? Cuántas piezas administrativas se generan en promedio por año, por mes y por día? Existen estándares para el manejo de las Mesas de Entradas? Existen estándares para trámites tipos? Se puede ubicar un expediente por persona, tipo de trámite, número de CUIT o fecha? Cuántos piezas administrativas existen en archivo? Qué espacio ocupan en metros cuadrados? Cuánto tiempo retienen el material en el archivo? Si una pieza sale del ámbito de la Dcción. General de Escuelas u organismo similar se puede saber en qué oficina está?


Página 79



Fecha 20/05/98


O . GESTIÓN SECRETARIA GENERAL Está unificado el control, redacción y despacho de firma de las resoluciones? Existe un Digesto o banco de datos de normas y dictámenes de temas relacionados con el área educativa? Existe dispersión en la normativa? Se conocen las redundancias y los vacíos legales? Si existe el Digesto, está automatizado? Existen estándares respecto de la redacción de normas?


Página 80


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.2. Estudio inicial y diagnóstico

Fecha 20/05/98


I.a.2. Estudio inicial y diagnóstico


Página 81

Primus


-


-

I.a.2.2. Conocer los objetivos estratétgicos y Factores Críticos de Exito


I.b.2.. Definición de Estrategias



I.a.2.3. Realizar las entrevistas

I.a.2.4. Analizar el modelo de gestión vigente

I.a.2.5. Preparar y exponer el informe ejecutivo a la Alta Conducción



Fecha 20/05/98

-

-


I.a.2.1. Realizar la reunión preliminar con los responsables de las áreas funcionales




Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.2. Estudio inicial y diagnóstico Versión Recomendado

Página 82



Fecha 20/05/98


1. Objetivo  Comprender las principales características del modelo de gestión vigente, la estructura organizativa que lo soporta y los sistemas y políticas que lo sustentan.  Establecer el grado de eficiencia y eficacia de la gestión administrativa para que el Organismo alcance sus objetivos estratégicos. 2. Tareas Las tareas comprendidas son:     

I.a.2.1. I.a.2.2. I.a.2.3. I.a.2.4. I.a.2.5.

Realizar la reunión preliminar con los responsables de las áreas funcionales. Conocer los objetivos estratégicos y factores críticos de éxito. Realizar las entrevistas. Analizar el modelo de gestión vigente. Preparar y exponer el informe ejecutivo a la Alta Conducción.

3. Desarrollo I.a.2.1. Realizar la reunión preliminar con los responsables de las áreas funcionales La introducción es conveniente que la realice el responsable mayor del Organismo Los objetivos de la reunión son: 

Explicar brevemente los resultados que se esperan obtener de la presente fase.



Conocer antecedentes de experiencias similares y sus resultados.



Anticipar los esquemas de relevamiento a fin de que reúnan la documentación y datos que se les solicitará.



Reconocer las principales restricciones a enfrentar y las características del ambiente de trabajo (Ej: experiencias anteriores fracasadas, personal cansado, expectativas insatisfechas, etc). La experiencia demuestra que es importante insistir en que los participantes preparen los datos solicitados a fin de agilizar el Estudio Inicial y que durante el período de entrevistas se les requerirá, probablemente, una extensión de la jornada laboral normal. Se pretende un esfuerzo corto pero intensivo a fin de interrumpir lo menos posible sus trabajos habituales.

El Coordinador actuará como activador para que al momento de las entrevistas esté preparada la documentación y datos solicitados. I.a.2.2. Conocer los objetivos estratégicos y factores críticos de éxito


Página 83



Fecha 20/05/98


Los objetivos de la entrevista con el máximo responsable de la Conducción son: 

Lograr la primera aproximación respecto del ambiente y los objetivos estratégicos del Organismo



Conocer las estrategias de la Organización respecto de los procesos de transformación, en el caso de que existan.



Conocer los principales problemas que preocupan a la Conducción y las expectativas respecto de los proyectos de reforma.



Identificar los Factores Críticos de Éxito. Es poco probable que la Autoridad enumere taxativamente los Factores Críticos de Éxito, sino que éstos surgirán de la interpretación que el entrevistador realice de las características vitales del modelo de gestión que la Conducción imagina y a la que aspira. El concepto de Factores Críticos de Éxito adoptado en el presente trabajo – atento a que la literatura le ha dado distintas interpretaciones- es el desarrollado por John Rockard , en base al concepto original de Ronald Daniel, que los define como “... aquellos aspectos o tareas en que si los resultados son satisfactorios, asegurarán un desempeño competitivo de la Organización. Son unas pocas áreas claves en las que las cosas deben marchar bien”. Algunos ejemplos de FCE extraídos de expresiones de Autoridades de las áreas educativas son:

       

Máxima presencia de docentes frente al curso en buenas condiciones psicofísicas. Agilidad y transparencia en los procesos de designación Conocimiento inmediato del estado y costo de la planta de personal. Menos trámites, más rápidos y sencillos. Conocimiento rápido y preciso de las demandas reales y potenciales (de las escuelas) Profesionalización del sector administrativo. Disponibilidad inmediata de información de los agentes y sus antecedentes. Escuelas con capacidad de autogestión Se verificará que los objetivos estratégicos estén en armonía con los FCE. Estos objetivos pueden existir a nivel de planes estratégicos ya desarrollados o pueden explicitarse durante esta actividad.

I.a.2.3. Realizar las entrevistas Las entrevistas con los responsables máximos de las áreas funcionales están orientadas a obtener antecedentes que permitan entender el ambiente, funcionamiento del Organismo yestructura organizativa que lo sustenta. En un análisis posterior se determinará si los recursos son obtenidos y empleados eficaz y eficientemente para el logro de los objetivos estratégicos de la Organización.


Página 84



Fecha 20/05/98


Los antecedentes a relevar deben facilitar la obtención de una visión global de la calidad de la gestión administrativa. Se recuerda que el análisis corresponde a la gestión administrativa y no educativa., que no es objeto del presente estudio. Adicionalmente, se identificarán las medidas de rendimiento que podrán luego podrán convertirse en metas de mejora en la declaración del nuevo modelo de gestión. Se recomienda antes de realizar las entrevistas: 

Que el Coordinador verifique que los responsables de las áreas a relevar hayan preparado los antecedentes requeridos en el esquema de relevamiento que se les anticipó dentro del plazo establecido en el programa de trabajo.



Que el representante de la Alta Conducción realice una reunión de control con el Coordinador y quienes participaron en la reunión introductoria de Organización a fin de constatar si ya se ha obtenido la información requerida y ajustar, si corresponde, el cronograma de entrevistas.

Los aspectos a cuidar durante la realización de las entrevistas son: 

Que sean realizadas por los expertos designados en no más de dos o tres jornadas, reservando una jornada adicional para completar información faltante o resolver dudas que surjan de la lectura de las entrevistas. La experiencia demuestra que la información faltante que no se obtenga en los días cercanos a la entrevista es de dificultosa obtención con posterioridad.



Que no se realicen en el lugar de trabajo si las interrupciones no podrán ser controladas.



Que previamente el entrevistador se familiarice con el área funcional. Para ello es útil identificar los principales procesos comprendidos. Si bien , las entrevistas se realizan por área funcional o unidad organizativa, no debe perderse la visión del proceso que se está relevando.



Que la entrevista sea realizada por un equipo de dos personas. La persona de mayor experiencia en el área debe conducir la entrevista mientras la otra toma notas y documenta.



Usar un formato estándar para documentar las entrevistas.



Destacar los puntos importantes.



Asignar la responsabilidad de completar el formulario de entrevista a un miembro del equipo.

I.a.2.4. Analizar el modelo de gestión vigente Se evalúa la calidad del modelo actual de gestión a través de la detección de las debilidades y fortalezas. Los indicadores claves que como mínimo deben ser analizados son: 

Estructura organizativa Se analiza la capacidad de la estructura para brindar soporte efectivo al logro de los objetivos de la Organización. Entre otros aspectos se evalua: la existencia de “centros de


Página 85



Fecha 20/05/98


responsabilidad” asociados a los procesos; la unidad de mando; el estilo de Conducción; el nivel de descentralización;el nivel de formalización de las misiones y funciones y la relación cooperativaentre personal afectado a actividades sustantivas versus personal afectado a actividades de apoyo. 

Cultura organizacional Se evalúa el sistema de valores formal y real; la vocación y compromiso de la Conducción para mejorar en forma permanente los servicios que brindan; la difusión de valores de calidad ;la transmisión clara de los objetivos estratégico; el liderazgo y la identificación y orientación de los procesos hacia los “clientes internos” y “clientes externos”.



Nivel de descentralización Se analiza la intención y capacidad operativa de descentralizar.



Información para toma de decisiones y control de gestión Se analiza la producción, disponibilidad y utilización de información estratégica, táctica y operativa que disminuyan la incertidumbre para tomar decisiones.



Eficiencia en el uso de los recursos físicos y financieros: Se analiza la estructura presupuestaria, el nivel de ejecución y el uso eficiente de los recursos Las organizaciones educativas se caracterizan por ser “mano de obra intensivas”, absorbiendo el rubro sueldos gran parte del presupuesto ; es por ello que deberá evaluarse el porcentaje de ausentismo alcanzado y la incidencia respecto del doble o triple pago de haberes por un mismo puesto de trabajo.



Gestión de los recursos humanos Se los medios empleados para promover el máximo desarrollo del potencial del personal y su contribución al logro de los objetivos de la Organización. Se examina la capacidad del personal para responder a las demandas reales y enfrentar el proceso de transformación.



Planificación y estrategias Se analiza la capacidad para trabajar en horizontes de mediano y largo plazo, la calidad en la fijación de las metas, la formulación de estrategias adecuadas y la gestión de proyectos conducentes a lograr las metas propuestas.



Infraestructura informática y de comunicaciones: nivel de automización Se analiza el adecuado soporte operativo del equipamiento, software aplicativo y redes de comunicaciones para apoyar una gestión eficiente y facilitar el proceso de


Página 86



Fecha 20/05/98


descentralización. 

Calidad de los sistemas los sistemas de información Se analiza la efectividad de los sistemas de información como herramienta de gestión en los distintos niveles de la Organización. Los principales aspectos a evaluar son: el nivel de automatización; el grado de cobertura de los procesos; los mecanismos de definición, obtención y utilización; el nivel de integración con otros sistemas; la confiabilidad y la oportunidad.

        

Los principales sistemas a evaluar son: Sistema de administración de recursos humanos. Sistema de administración presupuestaria, contable y financiera. Sistema de control de consumos de servicios públicos. Sistema de seguimiento de piezas administrativas. Sistema de información de infraestructura escolar. Sistema de normas y dictámenes. Sistema de Secretaría Legal. Sistema de abastecimiento de edificios escolares. Sistema de apoyo para toma de decisiones. Del análisis se determinarán las oportunidades de mejora e identificarán las principales restricciones que conformarán el contexto en el que se desenvolverán los potenciales proyectos de transformación.



Calidad de los procesos básicos Se denominan procesos básicos al conjunto de actividades interrelacionadas que comparten insumos y producen productos o servicios de valor agregado para el Organismo. Se analiza la calidad de sus estructura a través de la verificación de la presencia y medición de indicadores específicos de rendimiento. Los procesos básicos vitales definidos son:

        

Gestión Presupuestaria y Contable. Gestión de Recursos Humanos. Gestión de Piezas Administrativas. Gestión de Pagos. Gestión de Abastecimiento de Unidades Educativas. Gestión de Mantenimiento de Edificios Escolares. Gestión de Salud Laboral Gestión de Recursos Humanos. Gestión de Normas Legales.


Página 87

Fase I – PLANIFICACION 


Fecha 20/05/98


Gestión de Secretaría General.

I.a.2.5.

Preparar y exponer el informe ejecutivo a la Alta Conducción

El informe que se prepare debe tener las siguientes características: 

Ser claro, directo y breve.



Exponer desde lo general a lo particular, destacando exclusivamente lo que sea relevante. Es conveniente que en se realice un diagnóstico del modelo de gestión en general y luego se desarrolle en hojas separada el diagnóstico de cada uno de los indicadores seleccionados (preferiblemente no más de 1 hoja por c/u)



4.

Por cada indicador desarrollar las fortalezas, debilidades, oportunidades de mejora y recomendaciones.

Insumos principales  Organigramas.  Presupuestos aprobados y ejecutados.  Composición de la planta de personal con distribución por nivel jerárquico, afectación a actividades administrativas y sustantivas, y distribución geográfica.  Distribución y composición de las unidades escolares.  Estadísticas de ausentismo (en unidades y costos)  Antecedentes de estudios de gestión ya realizados.  Plan de sistemas.  Encuestas y relevamientos.  Planes estratégicos y políticas formalizadas del Organismo.  Antecedentes legales: norma de creación, organigrama aprobado, ley de presupuestos, estatuto del docente, régimen de licencias y norma de creación y funcionamiento del Organismo de Control de Licencias  Matriz modelo de procesos.

5.

Productos principales  Informe ejecutivo de oportunidades de mejora y recomendaciones para la Alta Conducción.

6.

Herramientas y Técnicas:  Técnicas de entrevistas y encuestas.  Técnicas de control de gestión.


Página 88

Primus


-

-

I.a3.2. Desarrollar la visión estratégica




-

I.a.3.4. Obtener la aprobación de la Alta Conducción



I.a.3.3. Determinar los procesos candidatos



I.a.3.1. Organizar el talller de trabajo

-





Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.3. identificación de procesos críticos y desarrollo de visión Fecha 20/05/98 Versión Recomendado

I.a.3. Identificación de procesos críticos y desarrollo de visión

.

Página 89


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad I.a. Sensibilización I.a.3. identificación de procesos críticos y desarrollo de visión

Fecha 20/05/98


1. Objetivo  Desarrollar la visión compartida del nuevo modelo gestión a fin de obtener consenso en la Conducción respecto de la Conducción y alcance del proceso de transformación.  Identificar los procesos críticos en los que se priorizarán los esfuerzos del plan de transformación. 2. Tareas Las tareas comprendidas son:     3.

I.a.3.1. I.a.3.2. I.a.3.3. I.a.3.4.

Organizar el taller de trabajo. Desarrollar la visión estratégica. Determinar los procesos candidatos Obtener la aprobación de la Alta Conducción.

Desarrollo I.a.3.1. Organizar el taller de trabajo El taller a realizar, cuyo objetivo es desarrollar la visión compartida del nuevo modelo de gestión, debe ser organizado cuidadosamente respecto de los integrantes que participarán, el material a utilizar y la metodología de desarrollo. Previo a la iniciación del taller se ajustará el contenido y se preparará el material de trabajo que debe incluir, como mínimo: temario; extracto de las fortalezas, debilidades y oportunidades de mejora consignadas en el informe ejecutivo; y desarrollo de los aspectos metodológicos y matriz de procesos. El temario sugerido es el siguiente: 

Objetivo del taller



Repaso de las debilidades y fortalezas expuestas en el Informe Ejecutivo



La Organización vista desde los procesos.



Repaso de conceptos teóricos: factores críticos de éxito, oportunidades de mejora, objetivos estratégicos y metas.



Enunciación de pautas rectoras de un Modelo de Gestión eficiente



Repaso de los Factores Críticos de Éxito.



Desarrollo de la visión compartida.



Explicación de la metodología para identificar procesos críticos.



Determinación de los procesos críticos.

Se recomienda que el taller no supere un día de trabajo atento a que el tiempo que le pueden


Página 90



Fecha 20/05/98


dedicar los participantes, por su nivel jerárquico, es escaso.

I.a.3.2. Desarrollar la visión estratégica El objetivo de esta tarea es sintetizar, en una declaración sencilla, las principales características del modelo ideal de gestión que se pretende alcanzar. Puede resumirse como un compendio de metas e ideas fuerza.. Parte del reconocimiento de que existen situaciones a mejorar (argumentos pro-activos que fueron citados en las oportunidades de mejora del informe ejecutivo) y termina con la descripción de una imagen, sin mucho detalle, de la Organización que se desea alcanzar. Dos insumos son básicos para el desarrollo de la visión: los Factores Críticos de Éxito (FCE), que fueron enunciados por el responsable mayor de la Conducción en oportunidad de la entrevista inicial y la referencia de las pautas rectoras de un modelo de gestión eficiente. La declaración de visión debe ser corta, concreta, expresada en términos sencillos, que pueda traducirse en objetivos mensurables. Dependiendo del grado de análisis y antecedentes existentes, se podrán convertir los ideales en objetivos o en metas. Las metas son la expresión concreta de los objetivos que no siempre será posible definir mediante valores discretos, bien porque en el estudio inicial no se pudieron obtener medidas de rendimiento o porque no se disponen de valores comparativos. Por ejemplo el FCE “Máxima presencia de docentes frente al curso ...” puede relacionarse con el objetivo “Minimizar el ausentismo por razones de salud mediante la aplicación de políticas de salud preventivas” y a su vez con la meta “Alcanzar y mantener un nivel de ausentismo del 3%”. Por cada FCE pueden asociarse uno o varios objetivos y en consecuencia , a una o varias metas. Los argumentos de la visión debe ser de fácil transmisión y entendimiento para todos los miembros de la Organización, ya que se constituirá en el faro que guíe todos los procesos de reforma. Por último la visión debe traducirse en políticas, asumidas como grandes estrategias de acción. Si ya existen y no están de acuerdo con los FCE acordados , es el momento de redefinirlas.

I.a.3.3. Determinación de procesos candidatos Los potenciales proyectos sujetos a transformación son aquellos que se determinen como vitales para el cumplimiento de la visión estratégica. La metodología de selección de prioridades, que se utilizará durante el taller de trabajo, requiere como insumos: los procesos, los Factores Críticos de Éxito y los criterios de calidad para medir los procesos Se entiende por proceso, siguiendo las definiciones tradicionales de las teorías de administración, como el conjunto de actividades relacionadas entre sí, que reciben uno o


Página 91



Fecha 20/05/98


varios insumos y los transforman en productos que tienen valor que directa o indirectamente sirve para cumplir con los objetivos de la organización. El proceso de selección se fundamenta en la siguientes variables:

calificación del proceso de acuerdo a las



Valor agregado: se obtiene a través de la cantidad de Factores Críticos de Éxito que están asociados al proceso. Se interpreta como el nivel de contribución del proceso al cumplimiento de los objetivos estratégicos de la Organización. Por ende a mayor cantidad de FCE asociados, más importante es el proceso.



Calidad: la calidad del proceso se determina mediante la evaluación de conceptos claves – a determinar en cada caso – que permitan establecer su eficacia y eficiencia para satisfacer a los clientes internos y/o externos. Los factores se pueden determinar desde la visión del cliente externo o de la Organización. Desde la visión del cliente se podrá determinar que la buena calidad es entregar el servicio o producto en las fechas previstas, en la cantidad acordada y cumpliendo con los requisitos solicitados. Por ejemplo, en el proceso de liquidación de haberes (sin incluir el pago), la buena calidad se puede determinar por liquidación en base a las novedades recibidas hasta las 24 horas anteriores y sin errores. Desde la visión de la Organización se evaluarán, entre otros: la sencillez y rapidez de los procesos, el soporte tecnológico (informática y comunicaciones), la eficiencia en el uso de los recursos físicos, la eficiencia en el uso de los recursos humanos, el nivel de integración con otros procesos y la eficacia/eficiencia de los sistemas de información. A su vez a cada factor se le otorgará un peso relativo en la calificación, determinando un cuadro del siguiente estilo: Factor

Ponderación

Sencillez y rapidez del proceso

0-20

Soporte tecnológico

0-20

Eficiencia en el uso de los recursos físicos

0-20

Nivel de integración con el resto de los procesos

0-20

Eficacia y eficiencia de los sistemas de información (nivel de cobertura, oportunidad, confiabilidad)

0-20

Total

0-100

(Calificación : A (0-20), B (21-40), C (41-60), D (61-80) y E (81-100)

El procedimiento para determinar las prioridades de los procesos es el siguiente:


Página 92



Fecha 20/05/98




Se confecciona una matriz de correlación de procesos y Factores Críticos de Éxito..



Se evalúa la calidad de cada proceso (A=Excelente, B=Muy bueno, C=Promedio, D=Regular y E=Bajo).



Se identifican las intersecciones de FCE/Procesos en función de la existencia de una relación.



Se suma por cada proceso la cantidad de FCE asociados (sumatoria de marcas por cada fila).



La prioridad de los procesos se obtiene ordenándolos de mayor a menor según la cantidad de FCE asociados. A su vez los procesos ya clasificados se reordenan priorizando los que tienen menor calidad. En otros términos, son prioritarios los procesos que mayor cantidad de FCE tienen asociados y cuya calidad es baja.

I.a.3.4. Obtener la aprobación de la Alta Conducción La Alta Conducción debe llegar a un consenso respecto de la declaración de visión, objetivos, metas planteadas y los procesos candidatos de los que surgirán la propuesta de proyectos. La obtención de la aprobación se constituye en el hito que formaliza el patrocinio para comenzar con la definición y priorización de los proyectos. La aprobación debe quedar registrada mediante la firma de la Declaración de Visión por el máximo responsable y el resto de los miembros de la Alta Conducción.

4.

Insumos principales    

Antecedentes de planes estratégicos, objetivos globales y políticas. Informe Ejecutivo de las Oportunidades de Mejora. Pautas rectoras de un Modelo de Gestión Eficiente (Parte III del presente manual). Antecedentes de otros modelos de gestión eficientes que brinden respuesta a las debilidades advertidas durante el estudio inicial..  Matriz de procesos. 5.

Productos principales  Declaración de visión estratégica de la nueva organización.

6.

Herramientas y Técnicas  Administración de reuniones efectivas  Facilitación y trabajo en equipo


Página 93



Fecha 20/05/98


 Técnicas de visualización  Métodos de asignación de prioridades


Página 94


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos Compendio y asignación de prioridades

Fecha 20/05/98


I.b. Definición de proyectos y asignación de prioridades 1. Objetivo  Determinar los proyectos que permitan la implementación de la visión y sean coherentes con las estrategias de la Organización.  Aproximar los costos, tiempos , riesgos y factibilidades de implementación de cada proyecto.  Definir las prioridades de los proyectos. 2. Actividades    

I.b.1. I.b.2. I.b.3. I.b.4.

Organización. Definición de las estrategias. Identificación de los proyectos. Asignación de prioridades y elaboración de términos de referencia

3. Desarrollo La Organización del equipo de trabajo exigirá la participación de profesionales con experiencia en la definición de proyectos. La primera actividad consistirá en agrupar los objetivos de largo, mediano y corto plazo en “unidades de realización” con aproximaciones de costos y tiempos. Los cálculos de costos y tiempos serán aproximados ya que se trabajará con “ordenes de magnitud”, admitiendo márgenes de +/- 35%, y se irán ajustando en la medida que cada proyecto sea transformado en programas de trabajo durante las etapas sucesivas. Por ello es que realizar una planificación de detalle puede ser un proyecto en sí mismo. Se podrá pasar de aproximación a estimación, cuando se tenga experiencias en proyectos similares. Se identificarán las principales restricciones que puedan obstaculizar el desarrollo de los proyectos para las que deberán establecerse estrategias de superación o bien el replanteo de los objetivos y alcance de cada proyecto. Posteriormente, la Alta Conducción, con el aporte de una propuesta metodológica del equipo de trabajo, determinará las prioridades de los proyectos. Por último se elaborarán y aprobarán los términos de referencia de cada proyecto, que además de establecer el plan de acción, de ser necesario, servirán de base para solicitar financiamiento , en cuyo caso se adaptarán las formas que cada organismo financiero determine (Ejemplo: BID, BIRD, PNUD) 4.

Productos principales  Declaración de estrategias globales


Página 95


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos Compendio y asignación de prioridades

Fecha 20/05/98


 Términos de referencia de cada proyecto

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La conformación de un equipo de trabajo con personal que tenga experiencia en la formulación de proyectos.  La documentación adecuada.  El uso de una metodología estándar para aproximar los tiempos y costos de los distintos proyectos.  La elección cuidadosa de las estrategias considerando las principales restricciones.  La participación de un miembro de la Alta Conducción en las revisiones de los principales hitos.


Página 96

Primus


-



-



-




I.b.1.4. Recopilar los antecedentes

I.b.1.3. Organizar las actividades del segmento

Fecha 20/05/98

I.b.1. Organización -

I.b.1.2. Acordar una metodología y entrenar el equipo

- I.b. DEFINICION DE PROYECTOS Y ASIGNACION DE PRIORIDADES -


I.b.1.1. Establecer el equipo de trabajo


Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.1. Organización y asignación de prioridades Versión Recomendado


Página 97


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.1. Organización y asignación de prioridades

Fecha 20/05/98


1. Objetivo  Seleccionar, organizar y entrenar el equipo de trabajo que participará en el segmento. 2. Tareas    

I.b.1.1. I.b.1.2. I.b.1.3. I.b.1.4.

Establecer el equipo de trabajo. Organizar las actividades del segmento. Acordar una metodología y entrenar al equipo. Recopilar los antecedentes.

3. Desarrollo I.b.1.1. Establecer el equipo de trabajo Continuarán trabajando como integrantes del equipo de trabajo el Coordinador y el representante de la Alta Conducción. Respecto de éste último participará exclusivamente en las reuniones de coordinación y control. El equipo de trabajo deberá estar integrado por personas que tengan experiencia en la formulación de proyectos de las áreas de interés comprendidas. La mayor experiencia de los participantes producirá mejores aproximaciones, al momento de los cálculos, y acortamiento del plazo de la fase. Podrán continuar las personas que han estado trabajando si el perfil se adapta. Atento a que este segmento es el más técnicamente orientado de la fase de Planificación, puede requerir habilidades no poseídas por el equipo del proyecto. En este caso es recomendable incorporar recursos técnicos del Organismo o externos que conozcan la tendencia y tengan experiencia en estimar configuraciones de hardware, software y facilidades de comunicaciones. La Oficina Central de Proyectos colaborará con el aporte de experiencias de otras Jurisdicciones y modelos de términos de referencia. Se preverá la participación, a requerimiento, de algunos representantes de las áreas funcionales comprometidas.

I.b.1.2. Organizar las actividades del segmento Es conveniente comenzar con la verificación de las actividades ya realizadas. Si el proyecto se toma en este segmento y se advierte que no se han realizado o cumplimentado debidamente actividades pertenecientes a l segmento anterior, se incluirán dentro del plan de trabajo. Desarrollar el plan de trabajo con determinación de los productos a obtener, los tiempos aproximados y la asignación de responsabilidades.


Página 98


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.1. Organización y asignación de prioridades

Fecha 20/05/98


I.b.1.3. Acordar una metodología de trabajo y entrenar el equipo. Consiste en: 

Establecer los estándares de trabajo respecto de las reuniones e informes.  Determinar los mecanismos de control de progreso.  Acordar las metodologías de aproximación o estimación de tiempos y costos.  Determinar el contenido mínimo de los términos de referencia.

I.b.1.4. Recopilar los antecedentes Reunir los antecedentes de trabajos realizados en el segmento anterior y de trabajos similares realizados en otras Jurisdicciones, a través de la información que brinde la Oficina Central de Proyectos.

4. Insumos principales  Antecedentes de otros proyectos desarrollados en el país.  Antecedentes recopilados y generados en el segmento anterior:  Organigrama  

Informe ejecutivo de oportunidades de mejora e informe ampliado. Declaración de la visión estratégica.



Pautas rectoras de un modelo de gestión eficiente (Parte III del Manual)



Matriz de procesos.

 Informe de tendencias en hardware, software y comunicaciones.

5.

Productos principales  Plan de trabajo.

6.

Herramientas y Técnicas  Administración de Proyectos  Manejo eficiente de reuniones.  Formación de equipos de trabajo.


Página 99

Primus


-

-





-




I.b.2.2. Identificar las tendencias tecnológicas

I.b.2..1. Identificar las restricciones I.b.2..3. Establecer los criterios de selección de proyectos

I.b.2.4. Establecer las estrategias



Fecha 20/05/98

I.b.2. Definición de estrategias


Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.2. Definición de y asignación de prioridades estrategias Versión Recomendado

I.b.2. Definición de estrategias

Página 100


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.2. Definición de y asignación de prioridades estrategias

Fecha 20/05/98


1. Objetivo  Definir las estrategias globales a las que se deberán ajustar todos los proyectos. 2. Tareas    

I.b.2.1. I.b.2.2. I.b.2.3. I.b.2.4.

Identificar restricciones. Identificar tendencias tecnológicas. Establecer los criterios de selección de los proyectos. Establecer las estrategias.

3. Desarrollo I.b.2.1. Identificar las restricciones: El objetivo de esta tarea es anticipar los potenciales obstáculos que configurarán el contexto en el que se desarrollarán los proyectos, a fin de establecer medidas preventivas o compensatorias. Los principales factores a considerar son: 

Restricciones externas: identificar las variables que no “maneja” el Organismo y que podrían impactar en forma negativa en los proyectos (Ej: cambio en los encuadres normativos, inestabilidad económica, probables cambios en la Conducción, etc)



Restricciones financieras: identificar las limitaciones presupuestarias, los cronogramas de ingresos y desembolsos comprometidos y la factibilidad de financiamiento externo (Ej: Pacto Federal, BIRF, BID, etc).



Restricciones de tiempo: factor relevante en la Administración Pública, ya que existe el “tiempo político”, período que en general, tiene un máximo de cuatro años , durante el que la Conducción deberá “mostrar” resultados efectivos. Es crítico al momento de establecer las estrategias de selección de los proyectos. Por ello, en una canasta de proyectos deben figurar aquellos que sean de alto impacto y corto plazo, ya que generarán la confianza para asumir compromisos de más largo plazo.



La rutina: el desarrollo de los proyectos compite con la rutina del día-a-día (contingencia), la que absorbe progresivamente los recursos de la Organización, impidiendo la dedicación necesaria para que los nuevos proyectos avancen, siendo que en muchos casos su implementación solucionarán los problemas cotidianos. Este factor es importante para establecer la estrategia de selección de proyectos y participación del personal que forme parte del futuro equipo del proyecto. Si la Organización está muy comprometida con los problemas rutinarios es aconsejable que la mayor parte del equipo del proyecto esté formado por personal contratado y que las personas del Organismo que se integren al equipo de trabajo sean desafectadas de las unidades funcionales a las que pertenecen.


Página 101



Fecha 20/05/98




Las comunicaciones internas: un proyecto debe tener visibilidad permanente para lo cuál debe establecerse una estrategia de comunicación de los avances logrados que mantenga informado al personal que no participa directamente del proyecto.



La habilidades del personal: los proyectos bien diseñados fracasan usualmente por la incapacidad de gestión de los recursos humanos pertenecientes al Organismo y la ausencia de adecuadas estrategias de implementación. En este sentido se analizará la factibilidad de capacitar y “reconvertir” al personal de las áreas críticas y el tiempo que demandará; a fin de determinar las alternativas de solución posibles.

I.b.2.2. Identificar tendencias tecnológicas Las soluciones a implantar deben estar en acuerdo con las tendencias tecnológicas en hardware, software, modalidades de procesamiento y comunicaciones, que hayan alcanzado un grado de madurez en el mercado. No obstante, se analizará la relación costo-beneficio de adherir a la última tecnología. Se considerarán pautas o políticas informáticas y de comunicaciones vigentes en la Organización o cuya adherencia imponga el Gobierno Provincial o Nacional. El nivel de automatización de la Organización y del personal afectado a las áreas de tecnología serán factores determinantes para determinar la estrategia de incorporación de soluciones informáticas que pueden incluir distintas alternativas, entre otras: 

Desarrollos propios.



Incorporación de soluciones estándares de mercado



Preferencia por paquetes integrados.



Preferencia por las mejores soluciones puntuales con integración a cargo del Organismo.



Tercerización del procesamiento.

I.b.2.3.

Establecer los criterios de selección de proyectos

Con la participación del representante de la Alta Conducción se determinarán los criterios que han de usarse para evaluar y asignar las prioridades a los proyectos que se definan. Los factores sugeridos para la selección son: 

Los beneficios: deben ser medidos conforme al grado de contribución para el logro de los Factores Críticos de Éxito. Se considerarán los tangibles e intangibles. Los beneficios tangibles se calificarán en forma independiente respecto de los intangibles, asignándoseles a cada tipo un rango de puntajes. La uniformidad de los beneficios se obtendrá aplicando valor actual neto. Así los tangibles se medirán de la siguiente manera:


Página 102



Puntaje beneficio proyecto(i ) 



Fecha 20/05/98


Puntaje máx imo factor beneficio * Beneficio en pesos proyecto (i ) Máximo beneficion en pesos

Los costos: los costos aproximados se calificarán de la siguiente manera:

Puntaje cos to proyecto(i ) 

Costo mín imo en pesos * Puntaje máx imo factor cos to Costo en pesos proyecto (i)



El riesgo: se evaluará la probabilidad de fracaso del proyecto. Los grados a evaluar serán: muy alto, alto, moderado, bajo y muy bajo. Se le otorgará el máximo puntaje del rango al nivel “muy bajo”.



El plazo: se le asignará el mayor puntaje del rango al menor plazo en meses. La fórmula a aplicar es la siguiente: Puntaje plazo proyecto(i ) 



Plazo mín imo en meses * Puntaje máx imo factor plazo Plazo en meses proyecto (i)

El impacto positivo: se refiere al grado de apoyo que los buenos resultados tendrá en los clientes internos y externos. Existen proyectos más “visibles y rápidos en cuanto al efecto de los resultados” que otros, aún cuando los beneficios puedan ser menores. A este factor se los denomina en el ámbito de la Administración Pública “efecto político”. Los grados de medición del impacto son: alto, moderado y bajo.

I.b.2.4. Establecer las estrategias Por último se elaborará un documento que sintetice las principales restricciones y estrategias adoptadas.

4.

Insumos principales  Antecedentes de otros proyectos desarrollados en el país.  Antecedentes recopilados y generados en el segmento anterior:  Organigrama 

Informe ejecutivo de oportunidades de mejora e informe ampliado.



Declaración de visión estratégica.



Pautas rectoras de un modelo de gestión eficiente.


Página 103



Fecha 20/05/98


 Literatura sobre tendencias tecnológicas en hardware, software de base, software aplicativo, modalidades de procesamiento y comunicaciones. 5. Productos principales  Declaración de estrategias. 6. Herramientas y Técnicas  Administración de proyectos  Administración de cambios.  Ingeniería informática.


Página 104

-

Primus




-



-




I.b.3.2. Determinar el perfil de riesgo

I.b.3.3. Definir los segmentos y actividades

I.b.3.4. Aproximar costos, beneficios y tiempos



I.b.3. Definición de los proyectos

I.b.3.1. Identificar los proyectos asociados a los procesos seleccionados


Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.3. Definición de y asignación de prioridades los proyectos Fecha 20/05/98 Versión Recomendado

I.b.3. Definición de los proyectos

Página 105


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.3. Definición de y asignación de prioridades los proyectos

Fecha 20/05/98


1. Objetivo  Identificar los proyectos que permitan implantar la visión del nuevo modelo de gestión. 2. Tareas     3.

I.b.3.1. I.b.3.2. I.b.3.3. I.b.3.4.

Identificar los proyectos asociados a los procesos seleccionados. Determinar el perfil de riesgo. Definir los segmentos y actividades. Aproximar costos, beneficios y tiempos.

Desarrollo: I.b.3.1. Identificar los proyectos asociados a los procesos seleccionados El objetivo de esta tarea es identificar conceptualmente los proyectos que permitan la implementación de la visión del modelo de gestión. Los proyectos a definir deberán estar relacionados con los procesos que fueron seleccionados como prioritarios en la actividad “Identificación de los procesos críticos y declaración de la visión”. Un método práctico es reunir las oportunidades de mejora que tengan objetivos comunes. Así, surgirá que algunos objetivos están relacionados exclusivamente a un proceso, como son los concernientes al sistema de salud laboral que justifican en sí la generación de un proyecto específico. También existen objetivos que son comunes a varios procesos, tal es el caso de las relacionadas a la administración de las piezas administrativas o capacitación básica. En estos supuestos conviene la generación de un proyecto común. A su vez, la interrelación y jerarquía de los proyectos está relacionados con el horizonte de los objetivos. Los objetivos de largo plazo o de desarrollo, como fin último de un gran proyecto, se subdividirán en objetivos de mediano y corto plazo, y estos a su vez en metas. De esta forma en cada instancia se podrán generar distintos proyectos subordinados e interrelacionados, partiendo de la dependencia del proyecto de mayor jerarquía. Por lo tanto por cada proyecto se definirá: 

Objetivos (largo, mediano y corto plazo)



Metas



Beneficios esperados (dan respuesta a las oportunidades de mejora planteadas)

El siguiente cuadro expone una guía tentativa de proyectos y subproyectos relacionados con los procesos administrativos del área educación. Al momento de las definiciones podrán sugerirse otras formas de clasificación y agrupación.


Página 106



Proyecto/Subproyectos

Fecha 20/05/98


Objetivos del proyecto

Programa de Salud Laboral

Identificar y evitar el ausentismo provocado por abusos Modelo organizacional y funcional Tercerización servicio de verificación domiciliaria Disminuir las causas estructurales del ausentismo a fin de mejorar el estado de Régimen de licencias. salud del agente Establecer programas de política de salud.

Sistema integral de gestión de recursos Diseñar e implantar un sistema eficiente de administración e información de recursos humanos humanos sobre la base del legajo único por Modelo organizacional y funcional agente. Tercerización del servicio de verificación Optimizar la capacidad estructural y funcional de la planta para promover domiciliaria ahorros en el presupuesto Reforma régimen de licencias Mejorar la competitividad y desarrollar las Reingeniería de procesos capacidades potenciales del personal Rediseño de estructura organizativa Sistema integral automatizado de administración de RRHHH Capacitación Encuadre normativo Sistema Integral administrativas

de

gestión

de

piezas Agilizar y estandarizar los procesos relacionados con el registro y seguimiento de los trámites administrativos de la Administración Central a fin de identificar en administración forma rápida y confiable los orígenes, recorridos, costos, tiempos insumidos y responsables

Sistema automatizado de de piezas administrativas Rediseño de procesos comunes críticos Intercomunicación Sede Central – Simplificar los circuitos administrativos de Delegaciones –Escuelas intercomunicación de procesos. Disminuir la incidencia del papel y brindar Racionalización de archivos

soporte informático a los procesos de tomas de decisiones. Sistema integral de presupuestaria y financiera

administración Sustentar y consolidar descentralización

Sensibilización y capacitación en nuevos procedimientos. Administración de nomencladores. Sistema automatizado de control de servicios Sistema automatizado de abastecimiento. Sistema automatizado integral de administración presupuestaria y financiera Gestión de normas y Secretaría General


el

proceso

de

Integrar los distintos niveles del organismo. Asignar en forma eficiente los recursos. Facilitar los decisiones.

procesos

de

toma

de

Descongestionar el nivel de Conducción respecto de las decisiones operativas. Página 107


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de proyectos I.b.3. Definición de y asignación de prioridades los proyectos Proyecto/Subproyectos

Organización de la Secretaría General. Digesto electrónico.

Fecha 20/05/98


Objetivos del proyecto Facilitar los procesos de delegación. Organizar el cuerpo normativo, racionalizar los procesos de archivo y agilizar la recuperación de antecedentes.

Sistema de administración establecimientos escolares Gestión recursos humanos Gestión alumnos. Banco de datos unificado de alumnos

de Agilizar y simplificar la administración de las unidades educativas. Uniformar los procedimientos administración escolar

de

Sistema de administración de infraestructura Racionalizar el uso de los recursos escolar financieros afectados a manteniendo. Descentralización de mantenimientos. Automatización sistema preventivo y correctivo Facilitar la planificación del mantenimiento. de mantenimiento. Capacitación básica Area administrativa Area informática

Nivelar los recursos humanos respecto del conocimiento teórico-práctico básico de temas administrativos e informáticos.

I.b.3.2. Determinar el perfil de riesgo Se establece el perfil de riesgo de cada proyecto considerando dos factores básicos: el nivel de certeza en el conocimiento de las variables que influyen en el proyecto y el daño que puede provocar el incumplimiento de los objetivos. En la evaluación del riesgo participan variables externas (Ej: el cambio tecnológico, la macroeconomía, los cambios en la legislación, etc) y variables internas (Ej: las habilidades del personal, el financiamiento, la compatibilidad con otros proyectos, el logro de los beneficios estimados, etc). Se considerarán las restricciones enunciadas en la declaración de estrategias. En esta etapa del proyecto no se disponen de toda la información, acercándose más al grado de incertidumbre que de riesgo. Es por ello que deberán ser consideradas otras experiencias en Organizaciones similares a la objeto de estudio.

I.b.3.3. Definir los segmentos y actividades


Página 108



Se organiza el proyecto en establecidas.

Fecha 20/05/98


las actividades necesarias para la obtención de las metas

Las actividades se relacionan entre sí, estableciendo la jerarquía y orden. Debe recordarse que la concurrencia de actividades que puedan realizarse en forma paralela, estará condicionada a la cantidad de recursos humanos que intervengan. Por cada actividad se estimarán los recursos humanos e insumos necesarios.

I.b.3.4. 

Aproximar costos, beneficios y tiempos

Costos: Se determinan los recursos humanos, materiales, técnicos y de servicios necesarios para el desarrollo de cada proyecto en base la metodología elegida, aunque siempre se estará en el ámbito de las aproximaciones. Por lo tanto los resultados que se alcancen son al solo efecto de comparar los proyectos y tener una idea aproximada del esfuerzo , por lo que estarán sujetos a sucesivos ajustes en la medida que se vaya avanzando en las distintas fases. Deben usarse escalas para indicar el nivel de incertidumbre asociada a las cifras Una vez calculadas las cantidades y los valores, se estimará el flujo de desembolsos en el tiempo.Esta tarea debe ser elaborada por personal con experiencia en proyectos similares.



Beneficios El análisis de los beneficios tangibles e intangibles es vital para la justificación del proyecto y deben expresarse cuantitativamente, siempre que sea posible. Deben usarse escalas para indicar el nivel de incertidumbre asociada a las cifras. Como beneficios se indicarán los costos de funcionamiento que se ahorren con la implantación del nuevo sistema.



4.


5.

Tiempos: por último se aproximarán los tiempos a nivel de cada uno de los segmentos de las fases contenidas en el ciclo de vida de cada proyecto. El cálculo del calendario debe estar asociado a los principales hitos y productos a obtener.

Declaración de estrategias. Antecedentes de proyectos similares. Declaración de visión estratégica. Pautas rectoras de un modelo de gestión eficiente (Parte III del Manual).

Productos principales  Matriz de proyectos

6.

Herramientas y Técnicas  Técnicas de estimación de costos.


Página 109



Fecha 20/05/98


 Técnicas de estimación de tiempos.  Técnicas de evaluación de riesgos.  Software de administración de proyectos.


Página 110

Primus


-

-







I.b.4. Asignación de Prioridades y elaboración de los Términos de Referencia

I.b.4.2. Desarrollar los términos de referencia

I.b.4.3. Aprobar los términos de referencia



I.b.4. Asignación de prioridades y elaboración de términos de referencia

I.b.4.1. Asignar prioridades y establecer secuencia


Fase I – PLANIFICACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de I.b.4. Asignación de proyectos y asignación prioridades y elaboración de prioridades de términos de referencia Fecha 20/05/98 Versión Recomendado

I.b.4. Asignación de prioridades y elaboración de términos de referencia

Página 111


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad I.b. Definición de I.b.4. Asignación de proyectos y asignación prioridades y elaboración de prioridades de términos de referencia

Fecha 20/05/98


1. Objetivo  Determinar la prioridad que se le asignará a cada proyecto en base a los criterios definidos por la Alta Conducción.  Seleccionar entre los proyectos prioritarios aquellos que se llevarán a cabo atendiendo a las factibilidades técnicas, operativas y económicas.  Desarrollar los términos de referencia de cada proyecto a fin de comenzar con su desarrollo. 2. Tareas  I.b.4.1. Asignar prioridades y establecer secuencia.  I.b.4.2. Desarrollar los términos de referencia.  I.b.4.3. Aprobar los términos de referencia.

3. Desarrollo: I.b4.1.

Asignar prioridades y seleccionar los proyectos

Los criterios aprobados por la Alta Conducción serán ponderados y aplicados para determinar la importancia y consecuente prioridad de cada proyecto o subproyecto. El peso relativo que se le asigne a cada factor dependerá del contexto de cada Organismo; así por ejemplo si es necesario producir resultados en el corto plazo que sean advertidos fácilmente por el personal y se tienen importante restricciones financieras; se asignarán puntajes altos a los factores plazo, riesgo (por la complejidad) y costos. Determinada la prioridad de los proyectos se someterán a una nueva selección considerando las restricciones, principalmente de costos y tiempos, que hacen imposible el lanzamiento concurrente de los proyectos prioritarios. En este tarea es conveniente tener aproximación de beneficios y costos de cada subproyecto a fin de avanzar con objetivos parciales ante la imposibilidad de cumplir con los objetivos totales del proyecto . Es probable que requiere un nuevo esfuerzo de planificación para identificar y distribuir riesgos, costos, beneficios, plazos e impactos de cada subproyecto.

I.b.4.2. Desarrollar los términos de referencia Mediante esta tarea se alcanza el producto más importante de la fase Planificación al sintetizar los aspectos vitales del proyecto y desarrollar a nivel de programa de trabajo los objetivos inmediatos. Los términos de referencia pueden responder a distintas estructuras de presentación según que su finalidad sea la de establecer las bases para continuar con el proyecto o que se utilice para


Página 112



Fecha 20/05/98


solicitar financiamiento En el último supuesto deberá respetar la estructura que los Organismos financieros determinen. La estructura básica del término de referencia de un proyecto es la siguiente:  

 

 

Título del proyecto, incluye:

Código: clave de identificación del proyecto de acuerdo a las normas de codificación de la Organización. Adicionalmente, si corresponde, se consignará la codificación según el Organismo de financiamiento. Categoría: indicar si es un macroproyecto, proyecto o subproyecto. Denominación: especificar el objeto del proyecto (Ej: Reforma del Sistema de Gestión Administrativa, Programa de Salud Laboral, Sistema Integrado de Administración Presupuestaria, etc). Destino: indicar denominación del o de los beneficiarios y el radio geográfico (si corresponde) o cualquier otro dato que precise el alcance. Tipo: determinar si es un proyecto nuevo, actualización o ampliación. 

Jerarquía: mencionar los proyectos de mayor jerarquía de los que dependa el que es objeto de desarrollo con indicación de la codificación.



Síntesis: desarrollar un resumen de los aspectos más relevantes del proyecto, que permitan su comprensión , mediante una rápida lectura. Es recomendable que no exceda dos carillas. La información básica a consignar es la siguiente:

       

Organismo beneficiario Organismo ejecutor Principales problemas a solucionar Objetivos a desarrollar con el proyecto. Resultados esperados. Duración. Fecha estimada de iniciación. Costo, con indicación de la participación en el financiamiento. 

Antecedentes de contexto: describir el ambiente en que se desarrollará el proyecto y los factores internos y externos que influirán durante su evolución. Entre las variables externas se considerará el marco normativo, la situación socio-política y la situación macroeconómica internacional, nacional o regional que impactarán en los resultados. Respecto de las variables internas, se detallarán las principales características del Organismo ejecutor que permitan apreciar su capacidad para llevar a la práctica la realización de los trabajos incluidos en el proyecto. El siguiente es un detalle sugerido de la información a proporcionar:


Página 113


         


Fecha 20/05/98


Denominación Domicilio Dependencia Recursos financieros Antecedentes legales de creación. Encuadre normativo que regula la actividad objeto del proyecto. Misión, funciones y estructura organizativa del Organismo. Personal y calificación general. Facilidades físicas. Experiencia institucional en la realización de trabajos similares 

Diagnóstico y Justificación: este apartado incluye los fundamentos, en términos de problemas , soluciones y beneficios, que impulsan la propuesta del proyecto, de modo que quede adecuadamente justificada la necesidad de ejecutar el proyecto. Se sugiere abordar el desarrollo en el siguiente orden:

    





Describir el problema a resolver en base a las debilidades y oportunidades de mejora advertidas en el estudio inicial y diagnóstico. Mencionar la estrategia global en la que se encuadra el proyecto. Indicar la relación con otros proyectos ya existentes o a desarrollarse. Mencionar cada una de las alternativas posibles de solución estudiadas, a fin de demostrar que la elección adoptada surge como la más razonable. Describir los beneficios tangibles e intangibles que el proyecto producirá en término de los sujetos beneficiarios y de los resultados a obtener. Aportar indicadores de rendimiento que permitan verificar que se ha alcanzado la mejoría prevista. Indicar el tiempo en que se estima se solucionará la situación-problema. 

Restricciones: mencionar las principales restricciones que condicionan la ejecución del proyecto (Ej: limitaciones económicas-financieras, plazo de ejecución, disponibilidad y capacidad de los recursos humanos, etc)



Objetivos: se desarrollará: el objetivo de desarrollo, los objetivos intermedios y los objetivos inmediatos.

El objetivo de desarrollo (mediatos o último) representa el logro del resultado más amplio que se pretende con la ejecución del proyecto. El proyecto mismo, por definición, no puede lograr el objetivo de desarrollo, lo cual puede requerir toda una gama de proyectos o actividades conexas. Por consiguiente el objetivo de desarrollo es el de nivel más alto y se encuentra por encima de los objetivos inmediatos. El objetivo de desarrollo se expondrá en el Diagnóstico y Justificación del proyecto, definiendo la cadena de objetivos entre éste y el objetivo u objetivos inmediatos que constituirán la finalidad del proyecto.


Página 114





Fecha 20/05/98


Los objetivos inmediatos (generalmente más de 1) constituyen el elemento fundamental del proyecto a describir en este apartado. Por consiguiente, merecen la mayor atención en el proceso de formulación y redacción de los términos de referencia del proyecto. En el proyecto se incluirá un número limitado de objetivos inmediatos. Puede contemplar uno solo y no debería exceder de dos o tres. En caso de mayor número, puede ser necesario considerar la elaboración de más de un proyecto, ante el riesgo que la diversidad de objetivos lo torne inmanejable. Cada vez que se formule un objetivo inmediato debe sometérselo a las siguientes preguntas: 1. ¿Qué se pretende lograr? 2. ¿Qué indicaría haberlo logrado? Deben exponerse de tal modo que sea posible medirlos, o al menos, observar su logro (metas o resultados). Si el proyecto ha sido bien formulado cuando se logren los objetivos inmediatos ha de pasarse de la situación actual a la que se espera al final del proyecto. Ello representa la base sobre la cual se evalúa el éxito o fracaso del proyecto.



Los objetivos intermedios (o secundarios) son también objetivos inmediatos pero de inferior alcance. Contribuyen al logro de los objetivos del proyecto y, definidos en sentido descendente (hasta el nivel de actividades) contribuyen la cadena de objetivos del proyecto. Para su formulación deben utilizarse idénticos criterios que los aplicados para los objetivos inmediatos. Cada objetivo inmediato debe exponerse por separado incluyendo los objetivos intermedios, metas, resultados y actividades relacionadas. 

Metas o resultados esperados: Son los productos que el proyecto debe producir para obtener su objetivo u objetivos inmediatos. Deben describirse lo más claramente posible y en términos verificables. Al formular las metas o resultados, es conveniente someterlas a las siguientes preguntas:



Se exponen de manera que permitan determinar que han sido alcanzados?  Se define la oportunidad en que deben producirse?  Queda adecuadamente definida la calidad necesaria que deben tener? Debe considerarse que las metas o resultados constituyen indicadores que permiten el control de la ejecución del proyecto. Por lo tanto, si las preguntas mencionadas no pueden ser respondidas razonablemente, deberán reformularse las metas o resultados definidos. Las metas permiten determinar los puntos de control o hitos. Todo objetivo inmediato debe tener como sensor por lo menos un resultado. De no existir, es menester revisar su formulación. Pueden existir más de una meta o resultado para cada objetivo. Es necesario describir cada


Página 115



Fecha 20/05/98


uno de ellos.



Actividades: Se brindará una información detallada del grupo de tareas sustantivas a realizar para producir los resultados o metas previstas. Las actividades representan la forma en que se prevén alcanzar las metas, por lo tanto debe existir relación directa entre ellas. Los puntos a desarrollar serán:



Definición y descripción de actividades Es conveniente subdividir la ejecución del proyecto en tantos segmentos o etapas como sea posible sin que se produzca atomización. Ello facilitará la exposición de los elementos y costos del proyecto. Pueden existir actividades principales y secundarias.



Cronograma de actividades Se establecerá el orden y la relación entre las distintas actividades con sus tiempos estimados, a fin de establecer las fechas de entrega de los productos o resultados. Se presentará en forma gráfica mediante diagramas GANTT y PERT. 

Organización para la ejecución: Se describirá la estructura organizativa que brindará soporte al desarrollo del proyecto y se asignará a cada actividad el responsable de supervisarla y el o los responsables de ejecutarlas. Debe mencionarse si se recurrirá o no a la contratación de consultorías para actividades de ejecución o de seguimiento y las razones que lo justifican. Deberá detallarse la conformación del equipo de trabajo, sus características generales (por especialidades, afectación por actividad, interrelación entre expertos, etc..), cómo se efectuará la supervisión del grupo y las tareas; los niveles de dependencia y relaciones dentro de la organización De acuerdo con el esquema organizativo que se adopte, adjuntar organigrama. Podrán existir diversos responsables para cada una de las metas a alcanzar.



Insumos: Se proporcionará información cualitativa y cuantitativa de los insumos que requerirá el proyecto para su ejecución diferenciando los que serán proporcionados por el Organismo y los que deberán ser contratados en el marco del proyecto. La estimación se realizará por cada actividad. A modo enunciativo los principales insumos son:


Página 116


     


Fecha 20/05/98


Servicios de Consultoría (individuales y de firmas) Viáticos y pasajes Equipamiento (hardware, software, facilidades de comunicaciones, etc) Materiales y alquiler de oficinas Personal de apoyo Otros servicios y elementos (traducción, publicidad, mecanografiado, fotocopiado, papel, cartuchos de tinta, etc) 

Costos: El presupuesto de costos deberá incluir la totalidad de las erogaciones previstas por contrataciones de personal e insumos, diferenciando aquellos desembolsos a cargo del Organismo de los que serán financiados en forma externa . Se excluirá cualquier concepto que no haya sido identificado y descripto previamente. Los costos estimados se distribuirán en un “calendario mensual de erogaciones” que permita determinar los flujos de caja del proyecto para organizar los desembolsos y consecuentemente, los requerimientos financieros a las entidades crediticias.



Estrategias de supervisión e informes: En este apartado se describirán los mecanismos de control del proyecto a través de la identificación de los hitos y la modalidad de verificación (Ej: reunión, evaluación, etc). En los casos de reuniones periódicas se establecerá la frecuencia, los participantes, el objetivo y las pautas de planificación. Respecto de los informes se distinguirá los informes técnicos periódicos del informe final. En cada caso se indicará quienes deben presentarlos , el contenido mínimo y el responsable de aprobarlos.



Términos de referencia de los integrantes del equipo de trabajo: Por cada especialista a contratar se desarrollarán los términos de referencia que deberán contener como mínimo:

       

Objetivo (se relaciona con un objetivo del proyecto o algunas metas de un objetivo específico) Duración: plazo de contratación Dedicación: full-time o part-time. Tipo de contrato: locación de obra, locación de servicio Categoría: Consultor Senior, Consultor Junior, etc. Perfil: descripción de la educación formal requerida, destrezas profesionales y habilidades personales. Actividades: descripción del grupo de tareas a realizar. Resultados: descripción de los productos a entregar con indicación de plazos.

Primus


Página 117



Fecha 20/05/98




Honorarios: monto total a ser abonado, indicando si corresponden descuentos.  Forma de pago: indicar el evento que produce el devengamiento del desembolso.  Reconocimiento de gastos: especificar qué gastos se reconocen y la modalidad de reembolso. I.b.4.3. Obtener la aprobación de la Alta Conducción La concreción exitosa de esta tarea formaliza la autorización de la Alta Conducción para comenzar con la implementación del plan, que comenzará con la organización de la Oficina de Proyectos Regional.

4. Insumos principales  Matriz de proyectos  Aproximaciones de costos y tiempos.  Formas exigidas por Banco Mundial y BID 5.

Productos principales:  Términos de referencia de cada proyecto  Términos de referencia de los participantes

6.

Herramientas y Técnicas  Técnicas de asignación de prioridades.  Procesadores de palabra y planillas de cálculos con plantillas tipo.  Software de administración de proyectos.


Página 118

Primus


II.a.2. Modelado de los procesos vigentes

II.a.4. Relevamiento de la estructura organizacional y marco normativo

II.a. ANALISIS DE PROCESOS Y ESTRUCTURAS DE SOPORTE

II.a.1. Organización

II.a.3. Relevamiento de la infraestructura tecnológica y sistemas de información

FASE 2: DISEÑO DE SOLUCIONES

II.a.5. Análisis de los procesos

II.b. DISEÑO TECNICO

II.b.1. Modelado de los nuevos procesos

II.c. DISEÑO ORGANIZACIONAL

II.c.1. Definición de los nuevos cargos y perfiles

II.b.2. Definición de las especificaciones técnico-funcionales del sistema de información

II.c.2.. Diseño de la estructura organizacional

II.d.2. Especificación de la implementación

II.d. PLANIFICACION DE LA IMPLEMENTACION

II.d.1. Definición de las estrategias de cambio

Fase II – DISEÑO DE SOLUCIONES MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad Compendio ---------------------Fecha 20/05/98 Versión Recomendado

II. Diseño de Soluciones

Página 119

Fase II – DISEÑO DE SOLUCIONES

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: MEDOTOLOGIA Segmento Actividad Compendio ----------------------

Fecha 20/05/98


1. Objetivo  Especificar la estructura y flujo de los procesos rediseñados.  Definir la infraestructura tecnológica y especificaciones funcionales de los sistemas informáticos que brindarán soporte a los procesos rediseñados.  Definir la estructura organizacional y el marco normativo que sustente los nuevos flujos de trabajo.  Especificar el plan de implantación . 2.

Segmentos comprendidos    

3.

II.a. II.b. II.c. II.d.

Análisis de procesos y estructuras de soporte. Diseño técnico. Diseño organizacional. Planificación de la implantación .

Enfoque del desarrollo Las fases Diseño de Soluciones e Implantación se desarrollarán por cada uno de los proyectos definidos y aprobados por la Alta Conducción al término de la Planificación de la Fase 1. Durante la presente etapa, que abarca en promedio entre el 15% y el 20% de la vida del proyecto, se trabajará en forma intensiva en la mejora del rendimiento de los procesos mediante la producción de un diseño que, en sus aspectos estructurales y funcionales, sea capaz de realizar la visión del nuevo modelo de organización definido durante la Planificación Las preguntas claves que se contestan en esta etapa son:  ¿ Cuáles son las actividades que componen los procesos a mejorar?  ¿ Cuáles son las actividades que aportan valor agregado para alcanzar los objetivos estratégicos definidos en el nuevo modelo de Organización?  ¿ Cuál es el soporte que reciben los procesos desde la estructura organizacional?  ¿ Cuál es el soporte que reciben los procesos desde la infraestructura tecnológica?  ¿ Cuál es el soporte que reciben los procesos desde los sistemas de información?  ¿ Cuál es el soporte que reciben los procesos desde las políticas institucionales y el marco normativo?  ¿ Cuáles son los indicadores de rendimiento que permiten medir la eficacia de los procesos analizados y facilitarán en el futuro la individualización de las mejoras alcanzadas?  ¿ Cuáles son los indicadores de rendimiento que permiten medir la eficiencia?  ¿ Qué diferencias sustanciales existen entre los procesos analizados y los descriptos en el Modelo de Gestión desarrollado por el Programa de Reforma Administrativa?  ¿Cuáles son las metas de mejora de los nuevos procesos?


Página 120



Fecha 20/05/98


 ¿Cuáles serán las actividades que compondrán los procesos rediseñados, identificando su alcance, características, recursos y orden en que se realizarán?  ¿ Cuáles son las características funcionales y especificaciones técnicas del sistema de información que soporte el o los procesos rediseñados?  ¿ Existen soluciones informáticas maduras en el mercado que eviten la necesidad de desarrollos propios?  ¿ Qué infraestructura tecnológica será necesaria para apoyar el proceso de transformación y cuál será la estrategia de incorporación?  ¿ Qué características deberá tener la nueva estructura organizacional para soportar los procesos rediseñados?  ¿ Cuáles son los recursos humanos que requiere el nuevo modelo organizacional? ¿ Existen personas con estos perfiles? ¿ Cuál es la estrategia para lograrlos?  ¿ Qué modificaciones deberían realizarse en el marco normativo y políticas institucionales para completar el proceso de reforma?  ¿ Cuáles son las principales resistencias que existirán en el proceso de cambio y cómo pueden ser vencidas?  ¿ Cuáles son los costos y beneficios en términos económicos?  ¿ Es factible implementar la solución desarrollada? ¿Existen alternativas?  ¿ Cuál es la estrategia de implantación de cada una de las partes que componen la solución y qué pasos se deberían dar? La contestación a las preguntas planteadas se desarrollará en los siguientes segmentos:  Análisis de procesos y estructuras de soporte Se comienza con la organización del equipo de trabajo que participará en la presente etapa. Se recolectará y estudiará la información producida durante la fase de Planificación, para luego realizar un relevamiento de los procesos respecto de las actividades, insumos y productos obtenidos. Conjuntamente, se analizará la estructura organizacional directamente relacionada al proceso en estudio, el marco normativo, la infraestructura tecnológica y los sistemas de información que le brindan soporte. Mediante la aplicación de técnicas administrativas se referenciarán los rendimientos y sus impulsores para concluir en la determinación de las oportunidades de mejora para cada una de las actividades que componen los procesos.

 Diseño técnico Se modelará el nuevo proceso especificando los eventos, las actividades, las tareas, el orden de ejecución, las interrelaciones, los insumos y los productos que deben obtenerse, bajo criterios definidos de calidad. Se definirán las especificaciones técnicas y funcionales del sistema de información que satisfaga


Página 121



Fecha 20/05/98


las exigencias de los usuarios y del nuevo proceso. Se evaluarán las soluciones informáticas disponibles en el mercado a fin de determinar la factibilidad de ser incorporadas para evitar costosos desarrollos propios o , en su defecto, para sugerir características posibles de ser incluidas en un sistema desarrollado a medida. Por último, se estimarán los costos de la solución técnica desarrollada.

 Diseño organizacional Se producirán las especificaciones del nuevo modelo organizacional respecto de las unidades organizativas, misiones, responsabilidades, cargos y perfiles de los recursos humanos. Se analizará los cambios entre la Organización vigente y la propuesta a fin de determinar la factibilidad de aplicar la nueva estructura principalmente en sus aspectos operativos y económicos, identificando los principales obstáculos que enfrentarán durante la transición. Se definirán las pautas de desarrollo del personal a través de planes de carrera y sistemas de incentivos que sean motivadores para afrontar la transformación y mantener el nivel competitivo del personal. El Diseño Organizacional se realizará concomitantemente con el Diseño Técnico, a partir de la definición de los nuevos procesos.

 Planificación de la implantación La Alta Conducción revisará y eventualmente, aprobará, el diseño organizacional y técnico en que se sustenta la solución. Se podrán sugerir ajustes hasta llegar al diseño definitivo que permita continuar con la elaboración de las estrategias de cambio. Los costos de las soluciones informáticas serán estimados y se diseñará una estrategia respecto del software aplicativo y la infraestructura de equipamiento y comunicaciones. Concurrentemente se diseñarán las estrategias para cambiar los circuitos administrativos, los procedimientos de los procesos rediseñados y transitar del actual modelo organizacional a la estructura organizacional rediseñada. Se desarrollará el plan de implantación mediante la identificación y documentación formal de los principales eventos, actividades y tareas. Se estimará el tiempo de ejecución y de los recursos necesarios que concluirá en el cálculo de costos y cuadro de desembolsos. Se evaluará económicamente la solución final considerando los costos y beneficios tangibles e intangibles, de única vez y periódicos. Luego de la aprobación de los proyectos que integran el plan de implantación se redactarán los términos de referencia y las bases de contratación para avanzar en la efectiva instalación de la solución diseñada y aprobada. Por último, se resumirán las conclusiones y recomendaciones que serán sometidas a la aprobación de la Alta Conducción, como paso necesario para habilitar el inicio de la fase de Implantación .


Página 122



Fecha 20/05/98


Los aspectos críticos a considerar para el éxito de la fase de Diseño de Soluciones son:  Mantener el interés y apoyo de la Alta Conducción Durante esta fase se producirá una fuerte interrelación entre el equipo de trabajo y los miembros de la Organización, que generarán los primeros síntomas de resistencia. Es importante que la Alta Conducción manifieste en forma visible su apoyo al proceso de transformación mediante la comunicación clara de los objetivos definidos en la visión de la nueva organización. Como se anticipó en la fase de Planificación, el apoyo de toda la Organización dependerá fundamentalmente del respaldo y participación del principal responsable y sus colaboradores inmediatos.

 Seleccionar recursos humanos capacitados Del correcto diseño dependerá el éxito final del proyecto. Por ello, es crítico seleccionar recursos humanos con probada capacidad técnica en el área específica en la que se desempeñarán y capacidad conceptual para comprender el funcionamiento integral de la Organización y la interrelación de su proyecto con otros que se estén desarrollando.

 Considerar las experiencias El equipo de trabajo debe estar abierto a considerar modelos de gestión ya desarrollados que puedan servir como marco de referencia, sea para adoptarlos o para obtener nuevos enfoques o conceptos que sean beneficiosos para el proyecto en que estén trabajando.

 Asegurar un diseño operativo Se deberá llegar a un diseño con suficiente nivel de detalle que permita ser sometido a las distintas situaciones que deba resolver y de las que pueda estimarse, con un alto nivel de certeza, el esfuerzo que demandará en recursos y tiempo. Por ello es que durante la fase de Diseño de Soluciones los cálculos de costos y tiempos deben pasar de la aproximación de la fase de Planificación a estimaciones fundamentadas en metodologías probadas.

 Mantener la coherencia del proyecto con los objetivos estratégicos de la Organización Es importante que el equipo de trabajo conozca como se integra el proyecto que desarrollan con otros proyectos actuales o futuros.

 Comunicar eficazmente a los usuarios Se necesita que la comunicación con los usuarios sea eficaz a través de toda la fase. Durante la actividad de Organización se deben establecer medios formales e informales de comunicación.


Página 123



Fecha 20/05/98


 Identificar los obstáculos y anticipar sus efectos Hace a la definición de las estrategias adecuadas el reconocimiento de los obstáculos que se enfrentarán y que podrían representar la diferencia entre el éxito y fracaso del proyecto; o como mínimo los desfasajes de costos y tiempos de implantación . 4. Productos principales                    

Esquema de actividades y eventos de los procesos rediseñados Diagrama de dependencia entre los procesos Especificaciones técnico-funcionales del sistema de información Informe de alternativas de infraestructura informática y de comunicaciones Diagrama de contexto Diagrama de flujo de datos Diagramas de entidad-relación Organigrama rediseñado. Matriz de evaluación de cargos nuevos Matriz de correlación de Actividades/Tareas-Estructura Organizacional Cuadros de necesidades de personal Matriz de transición de cargos Pautas para implementar planes de carrera y sistema de incentivos. Resumen de estrategias de cambio. Plan de trabajo de Implantación . Diagrama Gantt de Implantación Términos de Referencia proyectos de implantación . Pliego de condiciones generales, particulares y técnicas . Matriz de evaluación económica de beneficios y costos. Resumen Ejecutivo de implantación para la Alta Conducción.

5. Puntos de control Los principales eventos que deben controlarse para asegurar la eficacia de la fase son:       

La selección del personal del equipo técnico y la definición del plan de trabajo. La selección de los criterios de rendimiento y la definición del nuevo modelo funcional. La definición de las especificaciones funcionales y técnicas del nuevo sistema de información. La definición de la nueva estructura organizacional. Las estimaciones de costos y tiempos de implantación . La formulación del plan de instalación y estrategias asociadas. La confección de los términos de referencia y bases de contratación.


Página 124

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de Compendio procesos y estructuras de soporte

Fecha 20/05/98


II.a. Análisis de procesos y estructuras de soporte 1. Objetivo  Analizar la estructura y funcionamiento de los procesos objeto de reforma.  Analizar los sistemas de información, infraestructura tecnológica, políticas y estructura organizacional que sustentan los procesos.  Identificar los factores clave a mejorar que orientarán el diseño de los procesos. 2. Actividades     

II.a.1. II.a.2. II.a.3. II.a.4. II.a.5.

Organización. Modelado de los procesos vigentes. Relevamiento de la infraestructura tecnológica y sistemas de información. Relevamiento de la estructura organizacional y marco normativo. Análisis de los procesos.

3. Desarrollo: Durante esta etapa:  Se seleccionará y entrenará el equipo de trabajo que integrará la Oficina Provincial de Proyectos, responsable de ejecutar la fase Diseño de Soluciones.  Luego de revisar los pasos cumplidos en la fase de Planificación se completarán las tareas que no se hayan sido realizado o fueron ejecutadas en forma insatisfactoria o incompleta.  Se analizarán los flujos de trabajo que integran los procesos sometidos a estudio, para comprenderlos al nivel de insumos, actividades y productos.  Se analizará el contexto interno y externo que brinda soporte e influye en el desarrollo de los procesos. Desde el punto de vista interno, se evaluará el nivel de apoyo o de dificultad que aporta la estructura organizativa, el marco normativo, las políticas institucionales, la infraestructura tecnológica y los sistemas de información.  Se identificará y evaluará, desde el punto de vista técnico y funcional, el software aplicativo existente en el mercado.  Se identificarán las oportunidades de mejora mediante la detección de los factores claves que deben mejorarse y los indicadores de rendimiento, que servirán para monitorear los progresos.


Página 125

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de Compendio procesos y estructuras de soporte

Fecha 20/05/98


4. Productos principales              

Programa de trabajo de la fase Esquema de actividades y eventos de los procesos vigentes Diagrama de actividades y eventos Diagrama de flujo de datos Matriz de insumo-producto Matriz de indicadores de rendimiento Inventario de infraestructura informática y de comunicaciones (afectada al proceso) Inventario de habilidades del personal del área de sistemas Informe preliminar de soluciones informáticas desarrolladas por terceros Informe de costos informáticos y de comunicaciones Organigrama actualizado Matriz de correlación de Actividades/Tareas- Estructura Organizacional Matriz de evaluación de cargos actuales Matriz de oportunidades de mejora y recomendaciones

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:    

La selección del personal del equipo del proyecto y la definición del plan de trabajo. La determinación de las actividades, eventos e indicadores de rendimiento. La correcta modelización de los procesos involucrados. La confección de la matriz de oportunidades de mejora y su correlación con los Factores Críticos de Éxito (FCE) e indicadores de rendimiento.


Página 126

Primus





II.a.1.1. Seleccionar los miembros del equipo de trabajo

II.a.1.3. Organizar el equipo de trabajo

II.a.1.2. Recopilar antecedentes







II.a.1.4. Preparar el programa de trabajo









MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.1. Organización procesos y estructuras de soporte Fecha 20/05/98 Versión Recomendado


Página 127

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.1. Organización procesos y estructuras de soporte

Fecha 20/05/98


1. Objetivo  Seleccionar y organizar el equipo de trabajo que ejecutará la presente fase del proyecto.  Elaborar el programa de trabajo. 2. Tareas    

II.a.1.1. II.a.1.2. II.a.1.3. II.a.1.4.

Seleccionar los miembros del equipo de trabajo. Recopilar antecedentes. Organizar el equipo de trabajo. Preparar el programa de trabajo.

3. Desarrollo II.a.1.1. Seleccionar los miembros del equipo de trabajo La primera tarea es conformar el equipo de trabajo mediante la selección de los miembros que respondan a los términos de referencia que fueron elaborados al finalizar la fase de Planificación. Si no existe la Oficina Provincial de Proyectos, es el momento de constituirla, comenzando con la selección del Gerente de Proyectos. Esta tarea estará a cargo del Coordinador, nombrado en el Organismo y puede ser asistido por el Gerente Regional de Proyectos de la Oficina Central de Proyectos. La selección de los especialistas, que respondan al perfil solicitado en los términos de referencia, es responsabilidad del Gerente de Proyectos Provincial, pudiendo también ser asistido por el Gerente Regional de Proyectos. Es aconsejable que el equipo de especialistas básicos esté integrado por, al menos, un especialista en análisis organizacional y/o funcional y un especialista en sistemas informáticos. Dependiendo del tipo de proyecto, el equipo de profesionales se podrá complementar con: un médico especializado en medicina laboral (Proyecto: Programa de Salud Laboral), un especialista en Contabilidad Pública (Proyecto: Presupuesto y Contabilidad), un ingeniero o arquitecto (Proyecto: Administración de Infraestructura Escolar), un especialista en Administración de Recursos Humanos (Proyecto: Sistema Integral de Administración de Recursos Humanos) o un abogado (Todos los proyectos que requieran análisis de marcos legales y específicamente, para el Proyecto de Digesto Automatizado). Independientemente de los especialistas que integren el equipo de trabajo, se debe prever el apoyo del cuerpo de expertos que trabajan en la Oficina Central de Proyectos, quienes pueden aportar su experiencia para contratar especialistas en las Provincias con un menor perfil.


Página 128


Fecha 20/05/98


II.a.1.2. Recopilar los antecedentes Durante la fase de Planificación se produjo material y se recopilaron antecedentes que servirán de base para el desarrollo del Diseño de Soluciones. Si no existen dichos antecedentes o al revisar el material existente se advierte que está incompleto o su calidad es deficiente, deben incorporarse en el plan de trabajo las tareas necesarias para completar los insumos faltantes. II.a.1.3. Organizar el equipo de trabajo Las principales tareas que debe realizar el Gerente de Proyectos son: 

Explicar los términos de referencia del proyecto que fueron desarrollados durante la fase de Planificación. A este efecto, se describe claramente el objetivo, alcance, tareas principales y productos que se pretenden obtener al término de la presente fase.



Describir las principales características de la Organización y la contribución del proyecto a los Factores Críticos de Éxito y los objetivos estratégicos. También se explican las relaciones con otros proyectos en marcha o a ejecutarse.



Poner a disposición los antecedentes recopilados y elaborados durante la fase de Planeamiento. Respecto de los antecedentes que no existan y deban ser relevados, se establecerá la estrategia de recolección (Ej. : entrevistas, encuestas, etc.) a fin de prever las actividades en el programa de trabajo y preparar los listados de requerimientos que deben ser anticipados al personal del Organismo para que los vayan preparando.



Armar la Oficina de Proyectos, si no existe, respecto de las necesidades de espacio físico, equipamientos (computadoras, impresoras, fotocopiadoras, etc.) e insumos.



Establecer los estándares de trabajo, principalmente respecto de las metodologías requeridas para tareas específicas, estrategias formales e informales de comunicación, presentación de informes, calidad de los productos a entregar y mecanismos de resolución de conflictos.

II.a.1.4. Preparar el programa de trabajo Durante la fase de Planificación se elaboró un plan de trabajo que aquí debe ser ajustado para concluir en un programa de trabajo que describa las actividades a realizar, su alcance, el calendario y los productos que se pretenden obtener. Durante esta actividad se preparará el cronograma de entrevistas. Definidas las actividades y productos se asignarán los responsables.


Página 129


Fecha 20/05/98


4. Insumos principales     5.

Organigramas Términos de referencia del proyecto Antecedentes recopilados en la fase de Planificación Matriz de correlación de Procesos y FCE

Productos principales  Programa de trabajo de la fase Diseño de Soluciones

6.

Herramientas y técnicas     

Administración de Proyectos Manejo eficiente de reuniones. Presentaciones efectivas Formación de equipos de trabajo Técnicas de entrevistas


Página 130

Primus




II.a.2.2. Identificar los indicadores de rendimiento

II.a.2.3. Modelar los procesos vigentes











Fecha 20/05/98


II.a.2.1. Identificar los eventos y actividades





MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGÍA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.2. Modelado de los procesos y estructuras procesos vigentes de soporte Versión Recomendado


Página 131

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGÍA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.2. Modelado de los procesos y estructuras procesos vigentes de soporte

1.

Fecha 20/05/98


Objetivo  Modelar y analizar los procesos objeto de estudio en sus aspectos estructurales y funcionales.  Identificar los indicadores de rendimiento asociados a los Factores Críticos de Éxito.

2.

Tareas  II.a.2.1. Identificar los eventos y actividades.  II.a.2.2. Identificar los indicadores de rendimiento.  II.a.2.3. Modelar los procesos vigentes.

3.

Desarrollo II.a.2.1. Identificar los eventos y actividades Si bien existen metodologías que orientan en la determinación de los eventos y actividades, ello no asegura que diferentes analistas coincidan en la cantidad y alcance de los mismo, ya que es básicamente una tarea de abstracción y síntesis en la que influyen criterios subjetivos. Como base para comenzar el análisis se puede considerar la Matriz de Procesos y Actividades que se expone al final de la presente actividad. 

El primer paso para conocer los procesos en sus aspectos estructurales es identificar los eventos que lo componen. Algunas reglas para reconocer los eventos son:



Identificar los principales momentos que se producen en un proceso.  Identificar los cambios de estado que se producen en los objetos que participan del proceso y que son producto de la realización de una operación exitosa. A este efecto, un objeto puede ser una persona, una cosa o una transacción. Por ejemplo si analizamos el proceso “Administración de ingresos del personal” se podrán identificar como principales eventos: la inscripción, la selección, la designación, el entrenamiento y la toma de posesión. Estos eventos se corresponden con los cambios de estado del objeto “agente” que sufre las siguientes transformaciones: inscripto, seleccionado, designado, entrenado y asignado a un cargo. 

El segundo paso es la identificación de las actividades, que son las agrupaciones de tareas que producen el pasaje de un evento a otro dentro del proceso. Cada actividad se compone de insumos, tareas y productos o resultados. Volviendo al ejemplo del proceso “Administración de ingresos de personal” y su evento “Inscripción” se pueden identificar las actividades: “Determinar las vacantes”, “Solicitar los cargos a cubrir” e “Inscribir los postulantes”.


Página 132


Fecha 20/05/98




El tercer paso consiste en identificar, por cada actividad, el marco normativo que la regula.



El cuarto paso, consiste en identificar las tareas que se realizan, los insumos y los productos o resultados que se obtienen. Al relevar las actividades deben considerarse los siguientes aspectos:

     

Los insumos son la materia prima que alimenta la actividad y que luego será transformada para lograr un resultado o producto. Los insumos y los productos pueden ser tangibles (mercadería, papeles, etc.) o intangibles (decisiones, información). Los insumos y los productos pueden tener su origen o destino dentro o fuera de la Organización. Al describir las tareas es importante mantener un equilibrio entre una excesiva síntesis o abrumadores detalles. No debe llegarse al nivel de las operaciones. Por cada producto debe referenciarse cantidades máximas, mínimas y promedio obtenidas en el período de tiempo sometido a estudio. Describir especialmente las tareas que se realizan en forma secuencial o paralela. Por cada tarea:



Especificar si existen procedimientos escritos.  Determinar y estimar los recursos que se utilizan (insumos, servicios, equipamiento, cantidad de personal en equivalencia de tiempo completo).  Estimar los tiempos máximos, mínimos y promedio de realización.  Solicitar los comprobantes intervinientes “ya utilizados y con una variada casuística” determinando su origen y su(s) destino(s), (por cada copia). De esta manera se podrá verificar lo siguiente: que algunos campos nunca se utilizan, que el contenido no responde a lo que solicita el título, que los completados en forma manuscrita son ilegibles, que no se prenumeran, etc. El comprobante es el “vehículo de información de la Organización. Si se sabe leer se pueden extraer importantes conclusiones.Cada comprobante debe ser fotocopiado y referenciado en el Anexo de Documentos que acompañará el relevamiento. La citada referencia es la que se usa en la narración de cada procedimiento.      

Identificar los archivos transitorios (Ej.: canasta o pinche para papeles, etc.) y definitivos. Identificar el mecanismo de control. Especificar el nivel de estandarización. Especificar el nivel de burocratización Especificar el nivel de automatización. Identificar las personas que participan y el tipo de intervención (produce información o servicio o bienes, se informa, controla, transfiere, decide entre distintas acciones) II.a.2.2. Identificar los indicadores de rendimiento Los indicadores de rendimientos, que en la fase de Planificación, fueron determinados en


Página 133


Fecha 20/05/98


términos generales para cada proceso, en la presente etapa se definen al nivel de cada actividad. Estarán directamente relacionados con las medidas de desempeño que se mencionan en la literatura de Gestión de la Calidad Total, principalmente respecto de: la velocidad de respuesta (Ej. : tiempo promedio de resolución de un trámite), eficacia (Ej.: cantidad de trámites sin errores respecto del total de trámites) y eficiencia (Ej. : costo unitario por productos obtenidos). Los indicadores definidos deberán estar relacionados con los Factores Críticos de Éxito, ya que deben servir de referencia para medir los progresos alcanzados en pos del logro de los objetivos estratégicos de la Organización. Por otra parte, si los indicadores son estándares, permitirán aplicar la técnica de “benchmarking” (comparaciones estratégicas entre los que hace la Organización analizada y lo que hacen otras Organizaciones, que no necesariamente desarrollen la misma actividad). II.a.2.3. Modelar los procesos vigentes Esta tarea permite sintetizar en gráficos y tablas la estructura y flujo del proceso. Es recomendable utilizar herramientas de modelación de procesos, modelación de información y matrices de fijación de costos basándose en actividades. Las herramientas de modelación automatizadas pueden tener capacidades de simulación que permitan mediante la carga de datos, como recursos y tiempos, calcular tiempos de respuesta, eficiencia de los recursos y cantidad de productos a obtener.

4. Insumos principales  Matriz de correlación de Procesos y FCE  Resultados de relevamientos, encuestas y entrevistas 5.

Productos principales     

Diagrama de actividades y eventos. Diagrama de flujo de datos. Anexo de documentos vigentes. Matriz de insumo-producto. Matriz de indicadores de rendimiento.

6. Herramientas y técnicas  Administración de Proyectos  Técnicas de entrevistas  Técnicas de administración de requerimientos (Ej.: IDEF3 – Integration Definition Method for Process Description Capture – con orientación a procesos o a objeto)  Metodologías de modelado de procesos (Ej.: IDEF0 e IDEF 3, Constantine, Jackson)


Página 134


Fecha 20/05/98


 Metodologías de modelado de flujos de datos (Ej.: Yourdon, Gane-Sarson, Martin-Odell)  Herramientas de modelado (Ej.: Diagrama de actividades, Esquemas de eventos, Diagrama de dependencia entre procesos, Diagrama de flujos de objetos, Diagrama de transición de estados, Diagrama de flujo de datos, etc.)  Productos de software para modelado de procesos y flujos de datos (Ej.: System Architect, Optima!, Orfeo, Q+Isodoc,  Técnicas de fijación de costos basándose en actividades


Página 135

Primus




II.a.3.4. Identificar las soluciones informáticas desarrolladas por terceros




II.a.3.Relevamiento de la infraestructura tecnológica y sistemas de información

II.a.3.3. Relevar la capacidad de gestión de los servicios informáticos

II.a.3.2. Relevar la infraestructura de equip., SW de base y comunicaciones

II.a.3.1. Relevar el SW aplicativo












MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.3. Relevamiento de 20/05/98 procesos y estructuras infraestructura de soporte tecnológica y sistemas de información Versión Recomendado


Página 136

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.3. Relevamiento de 20/05/98 procesos y estructuras infraestructura de soporte tecnológica y sistemas de información


1. Objetivo  Identificar la eficacia de los sistemas informáticos y de comunicaciones en relación a los procesos objeto de análisis.  Identificar las soluciones informáticas existentes en el mercado que están brindando soporte a procesos de igual o similar naturaleza que los analizados. 2. Tareas     

II.a.3.1. II.a.3.2. II.a.3.3. II.a.3.4. II.a.3.5.

Relevar el software aplicativo. Relevar la infraestructura de equipamiento, software de base y comunicaciones. Relevar la capacidad de gestión de los servicios informáticos. Estimar los costos de los servicios informáticos. Identificar las soluciones informáticas desarrolladas por terceros.

3. Desarrollo II.a.3.1. Relevar el software aplicativo Se puede partir de un Mapa de Sistemas o Diccionario de Aplicaciones, si existe; de lo contrario es aconsejable que se desarrolle un inventario del software aplicativo que contenga como mínimo: 

Denominación del sistema o subsistema



Antigüedad promedio



Cantidad de aplicaciones que lo integran



Desarrollo propio o de terceros, indicando si la Organización tiene capacidad de automantenimiento



Lenguaje de desarrollo



Esfuerzo de mantenimiento exigido.



Objeto y alcance: eventos o actividades del proceso que automatiza



Productos que brinda



Calidad funcional (nivel de cobertura de eventos, grado de automatización, facilidad para integrar los eventos) y técnica (modularidad, flexibilidad, eficiencia, documentación, potabilidad, seguridad, etc.).



Estimación en equivalencia de tiempo completo de la cantidad de personas afectadas al desarrollo, mantenimiento y operación del sistema.



Costo de licencias y de mantenimiento, en caso de contratos con terceros.


Página 137



II.a.3.2. Relevar la infraestructura de equipamiento, software de base y comunicaciones Se utilizará como insumo el relevamiento realizado durante la fase de Planificación para analizar lo siguiente: 

La existencia de una estrategia global de equipamiento, software de base, desarrollo y comunicaciones.



El modelo o modelos de procesamiento que sustentan el o los procesos en estudio (centralizado, descentralizado, distribuido, cliente-servidor, indicando nivel, NCANetworking Computer Architecture).



La capacidad del equipamiento para absorber, en situaciones de exigencia, las operaciones del proceso que están automatizadas y el crecimiento permitido para incorporar las faltantes.



La cantidad de cargos afectados al proceso por rangos de antigüedad.



El software de base dominante al nivel de equipamiento central y cargos.



Las facilidades de comunicaciones instaladas y sus características técnicas (señalización, protocolos, software de red, etc.). Se relevarán las redes de área local y las de área extendida (WAN), como así también las posibilidades de instalación de áreas no cubiertas en las que se ejecuten los procesos analizados.



Las ubicaciones geográficas y direcciones de los distintos inmuebles en los que se realizan los procesos con indicación de distancias entre ellos. Especificar antigüedad de los edificios, si son propios o alquilados, si están previstas mudanzas y el estado general de las instalaciones.



Los costos por servicios informáticos y de comunicaciones (Ej.: mantenimiento de hardware o software, comunicaciones, licencias de software de base, alquiler, leasing o financiamiento de equipamiento, etc.

II.a.3.3. Relevar la capacidad de gestión de los servicios informáticos Se revisará la capacidad de respuesta de los recursos humanos integrantes del servicio informático para afrontar los requerimientos de información que se plantean en la ejecución de los procesos estudiados. Se constatará si existen normas, métodos, procedimientos y el nivel de retraso respecto de requerimientos de mantenimiento o nuevos sistemas (backlog). Es útil desarrollar un inventario de habilidades del personal en donde se describan: el nombre, cargo, responsabilidades principales, antigüedad, formación, dedicación y afectación a los procesos en estudio en horas mensuales equivalentes a tiempos completos. Las conclusiones obtenidas servirán de base para determinar mejoras a implementar en dicha área y serán un factor decisivo al momento de optar por soluciones desarrolladas por terceros.


Página 138



II.a.3.4. Estimar los costos de los servicios informáticos Los principales insumos para la determinación del costo de los servicios informáticos son: 

Contratos informáticos por alquiler, leasing o software de base y comunicaciones.

compra financiada de:

equipamiento,

Si la infraestructura es propiedad de la Organización se estimarán los costos de reposición para aplicar cuotas de amortización para un período de cuatro años, plazo que se estima razonable para la depreciación de un sistema de información automatizado. Antigüedad promedio. 

Contratos de alquiler de licencias de software aplicativo.



Sueldos brutos (incluidos aportes patronales) de los empleados del servicio informático.



Insumos mensuales (Ej. : papeles, cintas, etc.).



Servicios varios (alquiler de inmuebles, luz, calefacción, etc.).

Cada uno de los ítems relevados deberá ser prorrateado conforme a la base de distribución que se considere más adecuada. Por ejemplo, para distribuir los costos de personal se puede utilizar el procedimiento equivalente de tiempo completo (ETC). Si una persona que trabaja 200 horas mensuales le dedica el 10% de su tiempo a mantener un sistema relacionado al proceso en estudio, estará afectando el ETC de 20 horas de trabajo. Luego, si su sueldo más leyes sociales es de $2.000 por mes, resultará que el costo proporcional de dicha actividad es de $ 200. En otras situaciones, como alquileres de inmuebles, la base de prorrateo puede ser metros cuadrados ocupados. II.a.3.5. Identificar las soluciones informáticas desarrolladas por terceros La decisión de evaluar paquetes de software de aplicación desarrollados por terceros se tomó en la fase de Planificación, al momento de establecer las estrategias de incorporación de tecnología en informática y comunicaciones. Aún cuando todavía no están definidas las características funcionales de detalle del software que deberá soportar el proceso rediseñado, sí existen criterios generales de que pueden orientar la búsqueda. Las principales fuentes para identificar soluciones aplicables a los procesos objetos de estudio son: 

Experiencias de otros Organismos que desempeñan igual actividad o similar.



Bases de datos de software aplicativo publicadas por las Cámaras de Proveedores de Software o Administradores de Bancos de Datos


Página 139





Publicaciones especializadas



Software House reconocidas.



Proveedores de equipamiento o software de base que estén alineados a las estrategias que se hayan definido, quienes generalmente disponen de socios tecnológicos (Solution Providers o Business Partner) que cuentan con soluciones en distintas áreas de interés.

Si bien, durante la presente tarea no se realiza la evaluación final de las soluciones, es conveniente que, previo a iniciar la búsqueda, se confeccione una grilla de preguntas que permita determinar los aspectos funcionales y técnicos más importantes de los productos y de los proveedores. Esta metodología permitirá a su vez, restringir la preselección a un número de paquetes que luego puede ser manejable en la evaluación final - es recomendable que no sean más de cuatro.

Entre otros, los aspectos a relevar durante la búsqueda son:

4.



Opinión de los clientes respecto del producto y de la empresa. Los datos obtenidos permitirán diferenciar entre las características del software de aplicación según las expresiones de la empresa y su folletería; y las reales, expresadas por los usuarios comprometidos en hacer que el paquete de software trabaje para ellos.



Nivel de automatización de los procesos sometidos a análisis y grado de colaboración para una solución integral de gestión..



Portabilidad de la solución respecto de plataformas de equipamientos y sistemas operativos.



Infraestructura de la empresa y cantidad de productos instalados.



Facilidad de instalación y requisitos de entrenamiento del personal que seguirá con el mantenimiento.



Nivel de parametrización.



Facilidad de uso.



Calidad de la documentación disponible.



Flexibilidad ante la necesidad de ajustes.



Frecuencia de aparición de nuevas versiones.

Insumos principales  Mapa de sistemas  Diccionario de Datos o Aplicaciones  Listado de productos de Cámaras de Software.


Página 140


    5.

Revistas especializadas en temas de informática y de comunicaciones Relevamiento de infraestructura informática y de comunicaciones ( Fase Planificación) Definición de estrategias (Fase Planificación) Guías de relevamiento de la Subsecretaría de Tecnologías para la Función Pública

Productos principales    

6.


Inventario de infraestructura informática y de comunicaciones (afectada al proceso) Inventario de habilidades del personal del área de sistemas Informe preliminar de soluciones informáticas desarrolladas por terceros. Informe de costos informáticos y de comunicaciones.

Herramientas y técnicas  Administración de Proyectos  Técnicas de entrevistas  Herramientas CASE con repositorio común de datos (útil para el relevamiento de los sistemas y conformación de diccionario de datos)  Técnicas de administración de requerimientos (Ej.: IDEF3 – Integration Definition Method for Process Description Capture – con orientación a procesos o a objeto)  Técnicas de fijación de costos basándose en actividades


Página 141

Primus




II.a.4.5. Relevar el marco normativo

II.a.4.4. Identificar el perfil de los cargos actuales

II.a.4.3. Correlacionar la estructura con los procesos










Fecha 20/05/98


II.a.4.1. Relevar la estructura organizacional


II.a.4.2.Relevar la estructura de remuneraciones e incenttivos





MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.4. Relevamiento de procesos y la estructura estructuras de organizacional y marco soporte normativo Versión Recomendado


Página 142

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.4. Relevamiento de procesos y la estructura estructuras de organizacional y marco soporte normativo

Fecha 20/05/98


1. Objetivo  Describir la estructura organizacional formal e informal.  Identificar el tipo de participación de cada integrante en el proceso.  Identificar el contexto normativo que regula el proceso. 2. Tareas     

II.a.4.1. II.a.4.2. II.a.4.3. II.a.4.4. II.a.4.5.

Relevar la estructura organizacional. Relevar la estructura de remuneraciones e incentivos. Correlacionar la estructura con los procesos. Identificar el perfil de los cargos actuales. Relevar el marco normativo.

3. Desarrollo II.a.4.1. Relevar la estructura organizacional Previo a comenzar con un relevamiento detallado se establecerá el tipo de organización al que el Organismo ha adherido (Ej.: Funcional jerárquico, Por proyecto, Matricial, etc.), a fin de reconocer el estilo de gerenciamiento que prevalece y su esquema decisorio. Se solicitarán los Organigramas y Manuales de Funciones, con indicación de su nivel de actualización. La ausencia de este material, puede ser un indicador de la falta de precisión de las áreas de responsabilidad y su dificultad para comunicarlas a los distintos integrantes del Organismo. Independiente de la existencia o no del citado material, se deberá construir un Organigrama actualizado en dónde se detalle: la denominación de las unidades organizativas, la cantidad de cargos previstos y ocupados; y las relaciones jerárquicas entre las unidades organizativas. Por cada unidad organizativa que participa en el proceso analizado, se identificarán: 

Los cargos que lo integran y sus relaciones jerárquicas (de quién depende directamente y a quienes supervisan, aún cuando no dependan directamente del puesto analizado, indicando si la supervisión es directa/indirecta, formal/informal y permanente/eventual.



La identificación de la persona afectada a cada puesto: apellido y nombre, dedicación, antigüedad en la Organización y en el puesto, formación y experiencia.



El perfil “teórico” exigido para el cargo.



Las tareas asignadas al cargo.


Página 143


Fecha 20/05/98


II.a.4.2. Relevar la estructura de remuneraciones e incentivos Se identificarán los sueldos promedios brutos por cada cargo y se construirá la pirámide salarial que relacione nivel de responsabilidad con sueldo. Se relevará la metodología de calificación del personal y sistema de incentivos.

II.a.4.3. Correlacionar la estructura organizacional con los procesos Mediante esta tarea se correlacionan los cargos relevados con las tareas que conforman las distintas actividades del proceso, a fin de determinar el tipo de intervención – o aporte - de cada posición laboral a las distintas instancias del proceso. Se sugiere la exposición mediante una matriz que identifique por cada intersección tarea/cargo, cuál de las siguientes situaciones prevalece: 

Produce: significa que el responsable del cargo aporta insumos o realiza una operación necesaria para generar un resultado o decide la acción a seguir, pero en cualquier caso, su intervención es importante para que el proceso pueda concluir en forma exitosa.



Controla: simplemente se verifica total o parcialmente la calidad de una operación o de un producto.



Transfiere: distribuye datos o materiales a uno o varios destinatarios



Responde: el titular del puesto es el responsable de la tarea aunque no participe en forma directa.



Se informa: se notifica del estado de la tarea para que el responsable esté enterado, pero no toma decisiones.

II.a.4.4. Identificar el perfil de los cargos actuales Se relevarán las características humanas que exigen los cargos actuales de la Organización. Las caracterizaciones más importantes son: la formación, las habilidades y la orientación. La formación sintetiza los conocimientos adquiridos por aprendizaje, experiencias e información que le permiten a quién ocupa el cargo utilizar eficientemente sus destrezas. Representa saber qué hacer ante una situación determinada. Las habilidades y aptitudes expresan el conjunto de destrezas que el cargo exige de las personas que lo ocupen. Como el conocimiento representa saber qué hacer, las habilidades y aptitudes están asociadas con hacer las cosas bien. La

orientación indican el estilo que es más conveniente para realizar el trabajo. Está


Página 144


Fecha 20/05/98


relacionado con lo expuesto en la Teoría X y la Teoría Y. Así existirán cargos que exigen que estén más orientado al trabajo y otros a las personas. La exposición de la información se realizará mediante una Matriz que correlacione cada factor con cada cargo, indicando si el peso del factor en el cargo es alto, promedio o bajo. Cada factor será desglosado en distintas variables Ej.: habilidades y aptitudes (relaciones interpersonales, atención telefónica, análisis, etc.); formación (análisis de riesgos, contabilidad, Administración de empresas, negociación, etc.) y orientación (a las personas y al trabajo).

II.a.4.5. Relevar el marco normativo Se relevarán todas las normas legales de nivel nacional, provincial, municipal o institucional que imponen restricciones al proceso objeto de análisis. Se diseñará una matriz que relacione cada actividad con la norma, explicando brevemente los principales aspectos regulados. 4. Insumos principales     5.


6.

Organigramas. Manuales de funciones o Reglamentos (Ej.: Leyes, Decretos, Resoluciones). Sistemas de incentivos y ascensos. Planillas de remuneraciones.

Organigrama actualizado. Matriz de correlación de Actividades/Tareas- Estructura Organizacional. Matriz de evaluación de cargos actuales. Matriz de marco regulatorio-procesos.


Técnicas de análisis organizacional Técnicas de entrevistas Técnicas de incentivos Técnicas de diagramación de estructuras organizacionales Software para diagramación de estructuras organizativas (Ej.: Visio, MS Organization Chart, etc.)  Software para correlacionar estructura organizacionales (Ej.: Orfeo, Q+Isodoc, etc.)  Software de evaluación de puestos (Ej.: Description Now®, High-Tech®)


Página 145

Primus




II.a.5.2.Identificar las actividades de valor agregado


II.a.5.1. Estimar los costos del proceso


II.a.5.3. Identificar las oportunidades de mejora





II.a.5.4. Establecer y aprobar las recomendaciones










MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.5. Análisis de los procesos y estructuras procesos de soporte Fecha 20/05/98 Versión Recomendado


Página 146

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.5. Análisis de los procesos y estructuras procesos de soporte

1.

Fecha 20/05/98


Objetivo  Identificar las oportunidades de mejora del proceso.  Establecer las pautas que regirán el diseño técnico y organizacional.

2. Tareas    

II.a.5.1. II.a.5.2. II.a.5.3. II.a.5.4.

Estimar los costos del proceso. Identificar las actividades de valor agregado. Identificar las oportunidades de mejora. Establecer y aprobar las recomendaciones.

3. Desarrollo II.a.5.1. Estimar los costos del proceso Con los costos obtenidos durante el relevamiento de los procesos, estructura organizacional e infraestructura informática, se estimarán los costos mensuales o anuales de cada actividad. Mediante la relación de costos/ productos se podrá determinar el nivel de eficiencia de la actividad.

II.a.5.2. Identificar las actividades de valor agregado Durante la fase de Planificación se determinaron los procesos candidatos a ser mejorados, mediante la identificación de los que aportaban valor agregado a la Organización en función de su relación con los Factores Críticos de Éxito. De igual modo, para cada proceso seleccionado se determinará la importancia de las actividades y tareas.. La metodología propuesta consiste en relacionar las tareas de cada una de las actividades integrantes del proceso con los indicadores de rendimiento que fueron definidos durante el “Modelado de los procesos vigentes”. De esta forma se identificarán aquellas tareas que estén fuerte o débilmente relacionadas con las medidas de rendimiento, en forma positiva o negativa; o que incluso no tengan relación Las tareas que tengan impacto positivo en el proceso podrán ser mejoradas si las medidas de rendimiento obtenidas no son las óptimas. Las tareas fuertemente relacionadas que tengan impacto negativo o no estén relacionadas podrán ser analizadas a fin de determinar su eliminación o su integración en otras tareas de valor agregado.

II.a.5.3. Identificar las oportunidades de mejora Las oportunidades de mejora pueden surgir de las siguientes fuentes complementarias:


Página 147

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.a. Análisis de II.a.5. Análisis de los procesos y estructuras procesos de soporte 

Fecha 20/05/98


De la comparación con indicadores de rendimiento de otras Organizaciones que tienen procesos similares al objeto de análisis (benchmarking) Se sugiere como fuente de información las publicaciones académicas, la literatura comercial, los seminarios, los cursos, las conferencias, los bancos de datos especializados o las medidas de rendimiento que pueda brindar la Oficina Central de Proyectos, basándose en la experiencia acumulada por los integrantes de los equipos de especialistas. La forma de medir entre una Organización y otra pueden ser diferentes, por lo que se recomienda que sólo se consideren aquellos indicadores que son sustancialmente mejores que los relevados en la Organización estudiada. En consecuencia, mejoras de hasta el 20% no deben ser consideradas como interesantes de ser investigadas. Detectado un indicador sensiblemente mejor se procederá a conseguir información respecto de la forma en que la otra Organización ejecuta el proceso a fin de obtener ideas innovadoras u otros puntos de vista que mejoren sustancialmente los procesos objetos de reforma.



De la comparación con las pautas rectoras del Modelo de Gestión que se haya tomado como referencia.



De las pautas y casos expuestos en la abundante literatura existente de reingeniería de negocios, reingeniería de procesos, Total Quality Management y las buenas prácticas que sugieren las técnicas administrativas.

A continuación se exponen una serie de situaciones que de verificarse, si bien no aseguran que se puedan producir cambios radicales, son orientadoras para identificar oportunidades de mejora: 

Excesivo intercambio de información con redundancia de capturas.



Procesos complejos: muchas excepciones y casos especiales.



Excesiva fragmentación de las actividades que componente un proceso sin que se pueda identificar un responsable.



Actividades con errores que se detectan pero rara vez se corrigen.



Dificultad para identificar el producto de una actividad.



Existencia de procesos secuenciales aún cuando podrían realizarse en forma concomitante (ingeniería concurrente)



Dificultad para identificar a los clientes internos desconocimiento de sus preferencias



Generación de archivos que pocas veces se acceden y que no son exigidos por la normativa vigente.


o externos; y consecuente

Página 148


Fecha 20/05/98




Reservas de personal o activos por si se necesitan en momentos críticos, ante la dificultad de preveerlos.



Repetición del trabajo en distintos sectores.



Información similar producida por distintos sectores.



Inexistencia de sistemas de información que permitan agrupar todos los datos relacionados a un objeto, persona o hecho.



Información para toma de decisiones de dificultosa obtención.



Alta centralización del proceso decisorio.



Falta de estandarización: ante situaciones exactamente iguales se realizan tareas distintas.



Excesiva estandarización: no se contempla las distintas variantes que puede tener un proceso y se aplica un único procedimiento que en algunos casos es excesivamente lento o burocrático (ausencia de flexibilidad)



Ubicaciones inadecuadas para realizar un trabajo



Excesivos controles focalizados en los procesos que no le agregan valor o son excesivamente costosos en relación con el riesgo de cometer errores.



Frecuentes trabajos de conciliación.



Rigidez en esquemas centralizados o descentralizados, no aceptando que se aplique lo que más convenga en cada situación.



Dificultad para trabajar en equipo.



Dificultad para adaptar a un empleado a un nuevo oficio.



Dificultad para acceder a la información desde distintos lugares.



Duplicidad de conducción o áreas de responsabilidad compartidas



Falta de definición o imprecisión de misiones o funciones o roles (no formalizadas)



Alcance de control excedido.



Deformación de la estructura organizacional (Ej.: formas acampanadas por exceso de jefaturas).



Estructuras salariales descompensadas con los niveles de responsabilidad.



Exceso de burocratización (muchos pases que no agregan valor agregado).



Procedimientos no formalizados (Están en la cabeza del responsable del agente).



Baja calidad de la información producida para operar: por inoportuna, por difícil de leer, por insegura o por insuficiente.



Sistemas de información que no detectan inconsistencias o incoherencias que podrían reemplazar controles manuales inefectivos.



Sistemas de información no integrados.



Normas permisivas.


Página 149


Fecha 20/05/98




Bajo nivel de automatización o automatización inadecuada.



Ausencia de códigos de interoperabilidad que faciliten la integración de los sistemas.

II.a.5.4. Establecer y aprobar las recomendaciones Determinadas las oportunidades de mejora se identifican los cambios que se proponen, en coherencia con la “Declaración de la Visión Estratégica” de la fase de Planificación. Por cada oportunidad de mejora se consignarán los cambios propuestos con indicación de los beneficios, esfuerzos y riesgos. Los beneficios y esfuerzos se expresarán en forma cualitativa, ya que no se disponen de los datos suficientes para cuantificar la nueva solución. Por último se someterá a consideración de la Alta Conducción los cambios propuestos, a fin de obtener la aprobación que permita continuar con los segmentos de Diseño Técnico y Diseño Organizacional.

4. Insumos principales       

Diagrama de actividades y eventos Diagrama de flujo de datos Anexo de documentos vigentes Matriz de insumo-producto Matriz de indicadores de rendimiento Matriz de correlación de Actividades/Tareas- Estructura Organizacional Inventario de infraestructura informática y de comunicaciones con indicadores de afectación al proceso  Inventario de habilidades del personal del área de sistemas  Lista de productos de software aplicativo preseleccionado con detalle de perfil de producto y empresa  Informe de costos informáticos y de comunicaciones relacionados con los procesos analizados. 5.

Productos principales  Matriz de oportunidades de mejora y recomendaciones.

6.

Herramientas y técnicas    

Técnicas de benchmarking. Técnicas de análisis de flujos de trabajo. Técnicas de costeo de procesos. Técnicas de incentivos.


Página 150


Fecha 20/05/98


 Técnicas de medidas de rendimiento.  Software de análisis y simulación de procesos (Ej.: Optima!, Orfeo).  Software de costeo a base de actividades.


Página 151

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico Compendio

Fecha 20/05/98


II.b. Diseño técnico 1.

Objetivo  Especificar la estructura y flujo de trabajo del proceso rediseñado.  Definir la infraestructura tecnológica y las especificaciones funcionales de los sistemas de información que brindarán soporte a los procesos rediseñados.  Definir la estrategia de implantación del nuevo proceso.

2.

Actividades  II.b.1. Modelado de los nuevos procesos  II.b.2. Definición de las especificaciones técnico-funcionales del sistema de información

3. Desarrollo Durante esta etapa:  Se realizará el diseño conceptual del nuevo proceso que describa los principales eventos y actividades con su secuencia, orden, interrelación y especificación de insumos y productos. A este efecto se seguirán las recomendaciones que surgieron del análisis del segmento anterior. Para esta aproximación del diseño definitivo se considerarán los aportes que puede brindar la tecnología informática y de comunicaciones como impulsor de transformaciones.

 Se producirán diferentes aproximaciones, cada vez con mayor detalle, hasta llegar a la especificación de los circuitos administrativos, los procedimientos y los requerimientos del sistema de información que sustente el nuevo proceso. En esta instancia se determinarán los nuevos puntos de control y las especificaciones de espacio (Ej.: nivel de descentralización geográfica) y tiempo (Ej.: frecuencia de actualizaciones) que potenciarán el nuevo proceso.

 Se definirán las especificaciones técnicas y funcionales del sistema de información que satisfaga las exigencias de los usuarios y del nuevo proceso. Se evaluarán las soluciones informáticas preseleccionadas, a fin de determinar la conveniencia de incorporarlas respecto de realizar desarrollos a medida con personal del Organismo o contratado.

4. Productos principales  Esquema de actividades y eventos de los procesos rediseñados.  Especificaciones técnico-funcionales del sistema de información.  Informe software de terceros preseleccionado


Página 152

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico Compendio

Fecha 20/05/98


 Informe de alternativas de infraestructura informática y de comunicaciones  Diagrama de flujo de datos  Modelo de datos.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La coherencia del proceso rediseñado con los objetivos estratégicos del Organismo y los Factores Críticos de Éxito definidos en la fase de Planificación  La definición completa de las especificaciones funcionales y técnicas del sistema informático.


Página 153

Primus




II.b.1..2. Elaborar el diseño técnico de detalle


II.b.1.1. Elaborar el diseño técnico conceptual


II.b.1..3. Definir las alternativas por casos especiales



II.b.1..4. Ubicar los controles










II.b.1.



MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.1. Modelado de los nuevos procesos Fecha 20/05/98 Versión Recomendado

Modelado de los nuevos procesos

Página 154

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.1. Modelado de los nuevos procesos

Fecha 20/05/98


1. Objetivo  Especificar la estructura del nuevo proceso.  Especificar el flujo de trabajo del nuevo proceso. 2. Tareas    

II.b.1.1. II.b.1.2. II.b.1.3. II.b.1.4.

Elaborar el diseño técnico conceptual. Elaborar el diseño técnico de detalle. Definir las alternativas por casos especiales. Ubicar los controles.

3. Desarrollo II.b.1.1. Elaborar el diseño técnico conceptual El diseño técnico comenzará con la elaboración del modelo del proceso en un elevado plano de abstracción -mínimo nivel de complejidad- hasta llegar por sucesivas etapas a un diseño detallado -menor nivel de abstracción y máxima complejidad-. Este primer diseño contemplará la situación del proceso en su estado normal, de modo que el tratamiento de las excepciones será desarrollado en las etapas finales del diseño de detalle. El primer paso será definir los eventos que componen el proceso rediseñado e identificar los estímulos internos y externos que “disparan” cada evento como así también los resultados que se producen. Por cada evento se consignarán los principales grupos de datos que lo alimentan –insumos- y la información que genera –productos -, siempre mediante denominaciones genéricas, atento al nivel de abstracción en el que se desarrolla el diseño. En este nivel quedarán determinadas las relaciones con los principales clientes y proveedores del proceso (Ej.: agente, escuela, delegación administrativa, ministerio, etc.), estableciéndose los insumos e productos genéricos que entregarán y recibirán. El segundo paso consistirá en el diseño de la matriz de responsabilidades que relacione cada evento con las áreas de responsabilidad establecidas en el nuevo modelo organizacional. El tercer paso es la definición de las principales características innovadoras que se desprenden de la aplicación de la tecnología (Ej.: capturas automáticas del ausentismo en las escuelas mediante formularios de marcas) y la explicitación de las principales estrategias.

II.b.1.2. Elaborar el diseño técnico de detalle Mediante esta tarea “se explota” el diseño conceptual en niveles de detalle que permitan definir las actividades y tareas; y su forma de conexión.


Página 155


Fecha 20/05/98


En esta instancia se establecerá la secuencia, orden y relaciones entre las actividades y sus tareas. Durante la presente tarea se considerarán los siguientes aspectos: 

Establecer la cadena de valor: las actividades que se definan, sean directas o indirectas, respecto del proceso, deben producir bienes o servicios de mayor valor que los insumos utilizados. Ese mayor valor debe impactar directamente y en forma positiva en los indicadores de rendimiento que se han definido para medir los progresos de rediseñar los procesos.



Cambiar actividades y/o tareas secuenciales a concurrentes: aquellos pasos que pueden ser realizados simultáneamente abreviarán sensiblemente los procesos, respecto de la tradicional ejecución serial. La mejora propuesta es de aplicación a la mayoría de los procesos. En el Modelo de Gestión, entre otros, se proponen cambios importantes a los procesos de Administración de Piezas Administrativas (el tradicional expediente de las Mesas de Entradas) y Compras.



Establecer los niveles de centralización y descentralización: determinar la distribución de las actividades en el espacio.



Cambiar los lugares o instancias en que realizan los controles: se puede restablecer mediante distintos criterios como por ejemplo, la existencia de bases de datos que puedan ser consultadas por todos, la posibilidad de conciliaciones automáticas, el rechazo automático de los errores cuando se producen o la aplicación de procedimientos preventivos.



Acercar la oferta y la demanda: integrar y relacionar las actividades de forma tal que detecten o ,incluso, anticipen las necesidades a fin de satisfacerlas desde el “lugar más cercano” y “en el menor tiempo posible”. Esta pauta es de aplicación respecto de la ubicación de los centros de captura de información y está relacionada también con el cambio del orden en la ejecución de las tareas.



Ubicar los nuevos centros de responsabilidad: en ocasiones un traspaso o agrupamiento de distintas responsabilidades en relación a una actividad permite optimizar todo el proceso, reduciendo tiempo, personal ocupado y costo unitario por producto obtenido. Ejemplos de lo expuesto, son los siguientes casos:



Cuando se transfiere la responsabilidad de gestionar compras y gastos (Ej.: reparaciones menores, comestibles, útiles, etc.) desde la Administración Central a las Escuelas, mejorando los precios, tiempo de respuesta y calidad de los productos o servicios adquiridos.  Cuando se transfiere la responsabilidad de gestionar el pedido de la verificación del ausentismo o la convocatoria de la Junta Médica, desde la escuela al propio agente. En los casos de Juntas Médicas se puede reducir el tiempo de gestión usual que estaba en un mínimo de 30 a 45días a 7 días promedio. 

Simplificar las interfaces que utilizan los clientes y proveedores, internos y externos, para comunicarse con la Organización: la informática y las comunicaciones realizan un sensible aporte permitiendo que las personas realicen trámites desde su domicilio.


Página 156

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.1. Modelado de los nuevos procesos 

Fecha 20/05/98


Determinar los servicios que es conveniente sean tercerizados: puede ser considerado como una variante de la ubicación de nuevos centros de responsabilidad que implican la supresión de actividades internas. Entre las variadas razones que justifican la tercerización del servicio, merecen citarse:



Dificultad para mantener el nivel de especialización necesario de los recursos humanos. Dificultad para mantener la inversión actualizada  Ineficiencias “crónicas” difíciles de erradicar por afectar cambios culturales fuertemente arraigados en los responsables del servicio.  Falta de objetividad en quienes son responsables de realizar actividades de control por mantener fuertes lazos “corporativos” con los controlados . 



Aplicar la tecnología: plantearse en qué medida la tecnología informática puede colaborar en la mejora del proceso, a cuyo efecto deberá contemplarse en el diseño de detalle. Las siguientes preguntas pueden orientar en este sentido:



¿ Existe un volumen importante de archivos que no puedan ser evitados pero sí optimizados respecto del espacio que ocupan o la rapidez para rescatar información aplicando microfilmación o técnicas de almacenamiento de imágenes?  ¿ Se mejoraría el proceso mediante el uso de redes de comunicaciones de datos, imágenes y voz ?  ¿ En qué medida ayudaría compartir información a través de bases de datos comunes?  ¿ Es posible aplicar sistemas de automatización de captura por códigos de barra, OCR, bandas magnética o lectores de marcas ?

II.b.1.3. Definir las alternativas por casos especiales Esta tarea es un desprendimiento del diseño técnico de detalle que hasta ahora estuvo abocado al proceso en su condición normal , para pasar a analizar y diseñar soluciones que den respuesta a situaciones de excepción. En esta instancia se puede “romper” un estándar que si bien es óptimo para la situación normal de la actividad puede generar demasiada complejidad o el desperdicio de recursos. Por ejemplo: en la propuesta del Programa de Salud Laboral incluido en el Modelo de Gestión , se diferencia el procedimiento de notificación de un agente que vive en un centro urbano (situación más frecuente) del que vive en un centro rural alejado. El primero notifica por teléfono al prestador del servicio de verificación domiciliaria para que constate y diagnostique el ausentismo extendiendo el certificado correspondiente que deberá presentar en la escuela, no siendo válido otra justificación. En cambio al agente que vive en un paraje muy alejado se le aceptará como constancia el certificado emitido por un centro de salud u hospital, optando en tales casos por verificaciones ex_post en base a muestreos. II.b.1.4. Ubicar los controles Mediante esta tarea se ubicarán nuevos controles o reubicarán los existentes , simplificando la


Página 157


Fecha 20/05/98


estructura de control. Aquí se analizarán los procesos manuales de control o conciliación que puedan ser reemplazados por controles automáticos. A continuación se presenta una guía para ubicar los controles:

4.

Trasladar la detección del error al lugar más cercano en dónde se puede producir.



Integrar los controles a actividades que agreguen valor.



Mejorar las actividades en dónde se producen los errores, introduciendo alarmas que permitan anticiparlos.



Generar bancos de datos en que la información pueda conciliarse en forma automática por cruzamiento.

Insumos principales       

5.



Diagrama de actividades y eventos (vigentes) Diagrama de flujo de los procesos vigentes. Matriz de insumo-producto Matriz de indicadores de rendimiento Matriz de oportunidades de mejora y recomendaciones. Matriz de correlación de Actividades/Tareas- Estructura Organizacional Inventario de infraestructura informática y de comunicaciones con indicación del porcentaje de afectación al proceso

Productos principales  Esquema de actividades y eventos de los procesos rediseñados  Diagrama de dependencia entre los procesos

6.

Herramientas y técnicas  Metodologías de modelado de procesos (Ej.: IDEF0 e IDEF 3, Constantine, Jackson)  Metodologías de modelado de flujos de datos y objetos (Ej.: Yourdon, Gane-Sarson, MartinOdell)  Herramientas de simulación de performance de procesos  Herramientas de modelado (Ej.: Esquemas de eventos, Diagrama de dependencia entre procesos, Diagrama de flujos de objetos, Diagrama de transición de estados)  Productos de software para modelado de procesos (Ej.: Optima!, Orfeo, Q+Isodoc)


Página 158

Primus




II.b.2..2. Especificar las características funcionales del sistema informático II.b.2..4. Evaluar el software preseleccionado




II.b.2.1. Identificar los requerimientos de información









II.b.2. Definición de las especificaciones información

II.b.2..3. Definir la infraestructura informática y de comunicaciones





MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.2. Definición de especificaciones técnicofuncionales del sistema de información Fecha 20/05/98 Versión Recomendado

técnico-funcionales del sistema de

Página 159

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.2. Definición de especificaciones técnicofuncionales del sistema de información

Fecha 20/05/98


1. Objetivo  Definir las características del sistema de información que servirá de soporte a los procesos rediseñados.  Traducir los requerimientos del sistema de información rediseñado a términos técnicofuncionales suficientemente detallados que permitan la especificación del sistema informático.  Determinar la factibilidad de utilizar software aplicativo de terceros preseleccionado.  Definir la infraestructura necesaria en equipamiento, software de base y comunicaciones. 2. Tareas    

II.b.2.1. Identificar los requerimientos de información. II.b.2.2. Especificar las características funcionales del sistema informático. II.b.2.3. Definir la infraestructura informática y de comunicaciones. II.b.2.4. Evaluar el software preseleccionado.

3. Desarrollo II.b.2.1. Identificar los requerimientos de información En esta tarea se definen las principales características (nivel conceptual) de los requerimientos de información que exigen los nuevos procesos. La descripción del sistema de información debe satisfacer los requerimientos de los niveles de conducción, gerenciamiento, control y operación. Las descripciones, gráficas o narrativas, deben especificar: 

Los funciones principales identificándolas por tipo (manual o automatizada) y residencia (centralizada o distribuida)



Las principales alimentaciones del sistema de información integral.



Los principales grupos de información a ser producidos y distribuidos.



Los principales grupos de información a ser retenidos (almacenamientos).

II.b.2.2. Especificar las características funcionales del sistema informático En esta instancia se declara lo que “el sistema informático debe hacer y lograr” a través de los distintos procesos y funciones que han de automatizarse, con indicación de los insumos y salidas. El producto que se obtenga servirá de base para la contratación de una solución externa o el desarrollo de las especificaciones técnicas de detalle.


Página 160


Fecha 20/05/98


En esta instancia no se avanza en el diseño técnico de detalle (Ej.: bases de datos, módulos, programas y procedimientos, arquitectura de seguridad y control, etc.) que serán desarrollados durante la fase 3 – Implantación , según se haya determinado realizar desarrollos a medida (con recursos propios o de terceros) o contratar soluciones pre-programadas. Las características generales de las especificaciones funcionales son:

          



Las especificaciones deben contemplar todas las características del sistema que se consideren críticas respecto de la funcionalidad requerida para la solución.



Las especificaciones deben indicar lo que se desea y no cómo debe llevarse a cabo. En este sentido debe distinguirse claramente la definición de la funcionalidad del sistema respecto de la descripción de los detalles técnicos de implantación . Se admitirán la especificaciones de detalles técnicos de diseño cuando existan condicionantes muy importantes a ser respetados.



Deben estar explicitadas en forma clara y comprensible, con un grado de detalle tal que reduzcan al mínimo las posibles ambigüedades o interpretaciones erróneas por parte de quienes tengan la responsabilidad de desarrollar el sistema. Es importante considerar que constituyen la base del proceso de selección de los Oferentes en caso de contratarse y son referencia del cumplimiento de la garantía de calidad durante el proceso de desarrollo.



Las características de calidad y performance que se definan deben ser comprobables y verificables. Se pueden seguir las pautas de aseguramiento de calidad que han definido métricas para medir los siguientes factores:

Correctitud Fiabilidad Eficiencia Integridad Facilidad de uso Facilidad de mantenimiento Flexibilidad Facilidad de Prueba Portabilidad Reusabilidad Interoperabilidad 

Deben ser versátiles en lo conceptual, es decir, no ser excesivamente rígidas en sus definiciones y límites, de forma tal que ella impida que se pueda optar por una oferta de mejores prestaciones que la solicitada pero que, por la inflexibilidad de las definiciones del documento, no cumple exacta y taxativamente con lo requerido, con lo cual el Organismo es presa de su exceso de precisión en la misma.



Deben hacer referencia a todos aquellos factores significativos (dentro del contexto del proyecto) relativos al entorno de implantación , tanto desde el punto de vista de los


Página 161


Fecha 20/05/98


recursos físicos y lógicos como de los factores humanos y organizativos si fuesen relevantes. 

Se sugiere la elaboración de tablas de características fundamentales que el producto y/o los servicios anexos deben tener.

Los pasos sugeridos para describir las especificaciones funcionales son:

     



Resumir los objetivos y beneficios esenciales del sistema de información automatizado.



Especificar el alcance (Ej.: nivel de actividades y eventos comprendidos, área geográfica, nivel organizacional, etc.)



Modularizar el sistema de información automatizado en distintos subsistemas, dándole a cada uno una denominación inequívoca respecto de su naturaleza y alcance. En esta instancia se sugiere desarrollar un diagrama de contexto



Por cada uno de los subsistemas especificar:

Los objetivos y alcance. Las interfases con el usuario. Las interfases con otros subsistemas. Las novedades que deben ingresar. La información que debe producir. Las descripciones de las funciones y subfunciones. 

Especificar las entidades, sus principales atributos y sus relaciones. Se entiende por entidades las abstracciones que representan los principales “conceptos” o “tipos de objetos” 9. Por cada entidad se especificarán los atributos10 más importantes y su imagen11, si esto último es un condicionante que es importante aclarar.



Especificar los requerimientos de calidad: a nivel general y por función.



Especificar los requerimientos de performance: a nivel general y por función.



Especificar los requerimientos de seguridad: a nivel general y por función.



Especificar volúmenes de almacenamiento y crecimiento promedio por cada entidad.

9

Concepto: idea o nocion compartida que se aplica a ciertas cosas (objetos) de nuestra conciencia, también se llama tipo de objeto o dato abstracto (Ej: alumno, escuela, agente, solicitud licencia, familiar a cargo, etc.) 10

Atributo: las características que describen la entidad (Ej: en alumno, apellido y nombre, DNI, edad, domicilio, etc.)

11

Imagen: tipo de rúbrica y longitud máxima (Ej: apellido y nombre, alfanumérica de 30 posiciones)


Página 162


Fecha 20/05/98


II.b.2.3. Definir la infraestructura informática y de comunicaciones En base a las estrategias establecidas se identificarán, evaluarán y recomendarán las combinaciones posibles de equipamiento, software de base y comunicaciones que respaldarán los requisitos funcionales y técnicos del sistema informático definido. Es conveniente que se especifique la orientación de la tecnología a la que se adhiere y se llegue a un nivel de precisión que permita calcular el costo aproximado. Respecto de cada definición se puede precisar una opción base y alternativas. Esta tarea debe producir un informe de estrategias tecnológicas que generen recomendaciones de los siguientes aspectos: 

El modelo de procesamiento: centralizado, descentralizado, distribuido o cliente-servidor, en alguno de sus niveles, Networking Computer Architecture o combinaciones de los distintos modelos .



El equipamiento central: tamaño o potencia relativa, tecnología (RISC, CISC), capacidades en memoria y almacenamiento, etc.



El equipamiento periférico: terminales bobas, terminales inteligentes, impresoras centrales, impresoras de escritorio, scanner, lectores de códigos de barra u OCR, etc.



El sistema operativo del procesador central y los cargos (caso de terminales inteligentes: PC's).



El gestor de base de datos.



Las herramientas de desarrollo: lenguajes, integraciones en herramientas de CASE en alguno de sus niveles, etc.



El ambiente de comunicaciones local: el sistema de cableado(estructurado o no), tipo de señalización (Ethernet, Token-Ring, etc.), sistema operativo de red (Novell™, Window NT™, Unix, SCO™, Lantastic™, etc.), el equipamiento de distribución de señales (Hubs, Switchers, Gateways, Routers, etc.).



El ambiente de comunicaciones remoto: está ligado a la estrategia de comunicaciones seleccionada, ya que no impacta de la misma forma comunicaciones en línea permanentes que transmisiones periódicas mediante correo electrónico. En este ítem se especifican: medio (fibra óptica, teléfono conmutado, línea dedicada, satélite, etc.) y el equipamiento (procesadores de comunicaciones, routers, modems, etc.).

Al hacer las recomendaciones se considerará la posibilidad de integrar el equipamiento existente o cambiarlo total o parcialmente, atento al costo de las ampliaciones y el peligro de incompatibilidades con el equipo anexado.

II.b.2.4. Evaluar el software preseleccionado Se determinará la aplicabilidad del software identificado en el segmento anterior. La evaluación comprende, como mínimo:


Página 163

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.b. Diseño técnico II.b.2. Definición de especificaciones técnicofuncionales del sistema de información 

Las características funcionales.



La calidad técnica.



La facilidad de transferencia.



La facilidad de implantación .



La documentación respaldatoria.



El esfuerzo de adaptación.



El nivel de actualización.



El respaldo del proveedor.



Los costos aproximados de adquisición y modificaciones.

Fecha 20/05/98


Es conveniente que por cada uno de las áreas a evaluar y los distintos ítems que la componen, se describan en una planilla con su peso relativo. Al final de la evaluación debe surgir un informe que:

4.

Resuma los puntos fuertes y débiles de cada software candidato.



Recomiende la contratación de una solución de terceros o la contratación de un software a medida o el desarrollo propio.



Indique cuáles son las soluciones que califican y sus costos.



Describa el esfuerzo de las modificaciones requeridas para implementar el software y sus costos.


5.



Esquemas de actividades y eventos de los procesos rediseñados. Declaración de estrategias (Fase Planeamiento). Inventario de infraestructura informática y de comunicaciones. Inventario de habilidades del personal del área de sistemas. Informe preliminar de soluciones informáticas desarrolladas por terceros (paquetes preprogramados).

Productos principales  Informe de especificaciones técnico-funcionales.  Informe software de terceros preseleccionado.  Informe de alternativas de infraestructura informática y de comunicaciones.


Página 164


Fecha 20/05/98


 Diagrama de contexto.  Diagrama de flujo de datos.  Diagramas de entidad-relación.

6.

Herramientas y técnicas  Metodologías de análisis y diseño estructurados (Ej.: Gane-Sarson, Yourdon, etc.)  Metodologías de análisis y diseño orientado a objetos (Ej.: Martin-Odell, Booch’94, OMT/Rumbaugh, Coad/Yourdon, Shlaer/Mellor, IDEF3, etc.)  Diagramas de entidad-relación (Ej.: IDEF1X)  Herramientas CASE (Ej.: System Architect, Designor, Omnis7, Erwin, Silverrun)


Página 165

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.c. Diseño Compendio organizacional

Fecha 20/05/98


II.c. Diseño organizacional 1. Objetivo    

Diseñar la estructura organizacional que sustente los nuevos flujos de trabajo. Establecer los perfiles de los cargos rediseñados. Establecer las políticas para diseñar los planes de carrera y sistemas de incentivos. Diseñar las estrategias de transición.

2. Actividades  II.c.1. Definición de nuevos cargos y perfiles  II.c.2. Diseño de la estructura organizativa 3. Desarrollo Los procesos rediseñados estarán sustentados en una estructura organizacional que requerirá la generación de nuevos cargos, la absorción de unos cargos en otros existentes y la desaparición de algunos. Durante esta etapa:  Se definirán los cargos responsables de operar los nuevos procesos rediseñados definiendo el perfil requerido para cada uno: formación, habilidades y aptitudes y orientaciones. En esta instancia se determinarán que partes del proceso serán asignadas a un cargo o a un equipo de trabajo.  Se identificarán los cambios entre la Organización vigente y la propuesta a través de las correlación de los cargos vigentes con los rediseñados.  Se agruparán los cargos nuevos y los transformados en nuevos centros de responsabilidad adoptando el modelo organizacional más conveniente, pero dentro de los nuevos enfoques de la administración de las fuerzas de trabajo.  Se establecerá la complejidad de transformar los perfiles de cargos vigentes en los nuevos cargos, mediante la aplicación de indicadores de esfuerzo que permitan merituar si es factible el cambio, el nivel de dificultad y cuáles son los perfiles de los cargos existentes que están más cercanos de asumir las nuevas responsabilidades.  Se definirán las pautas de desarrollo del personal a través de planes de carrera y sistemas de incentivos que sean motivadores para afrontar la transformación y mantener el nivel competitivo del personal. 4.

Productos principales  Organigrama rediseñado.  Matriz de evaluación de cargos nuevos.  Matriz de correlación de Actividades/Tareas-Estructura Organizacional.


Página 166

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.c. Diseño Compendio organizacional

Fecha 20/05/98


 Cuadros de necesidades de personal.  Matriz de transición de cargos.  Pautas para implementar planes de carrera y sistema de incentivos.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La definición de los nuevos perfiles y estructura organizacional.  La medición del impacto del cambio.  El establecimiento de estrategias adecuadas que faciliten la gestión eficiente del cambio.


Página 167

Primus




II.c.1..2. Determinar las necesidades de personal


II.c.1.1. Definir cargos y perfiles


II.c.1..3. Correlacionar cargos con procesos














MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.c. Diseño II.c.1. Definición de 20/05/98 organizacional nuevos cargos y perfiles Versión Recomendado

II.c.1. Definición de nuevos cargos y perfiles

Página 168

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.c. Diseño II.c.1. Definición de 20/05/98 organizacional nuevos cargos y perfiles


1. Objetivo  Establecer los nuevos cargos y sus áreas de responsabilidad.  Definir la formación, destrezas y orientación requeridos en cada puesto. 2. Tareas  II.c.1.1. Definir cargos y perfiles.  II.c.1.2. Determinar las necesidades de personal.  II.c.1.3. Correlacionar cargos con procesos.

3. Desarrollo II.c.1.1. Definir cargos y perfiles 

Se definirán los cargos (puestos de trabajo) responsables de operar los procesos rediseñados. A este efecto se seguirán las recomendaciones que las metodologías de reingeniería de recursos humanos y modernos enfoques de trabajo sugieren. El principio general de reingeniería, como citan Manganelli y Klein, en su libro Como hacer reingeniería, “... es reemplazar procesos complejos antes separados en cargos sencillos, por procesos simplificados que ejecutan empleados que tienen cargos más complejos”. Si es factible, debe tenderse a generar cargos que sean responsables de trabajar un proceso o grupo de actividades o al menos una actividad desde el principio hasta el fin, para eliminar las actividades que no agregan valor. De esta forma el cliente interno o externo tendrá un solo responsable y se mejorará la calidad y productividad del proceso. Ante la dificultad de que en una persona cumpla con todo el perfil, se estudiará la posibilidad de asignar la responsabilidad a un equipo de trabajo.



Se correlacionarán los cargos anteriores con los nuevos. En una matriz que especifique cargo anterior y cargo nuevo, se establecerán las siguientes relaciones: cargos que desaparecen, cargos que se absorben en uno existente, cargos que se absorben en uno nuevo y cargos que se generan.



Se definirán los perfiles de cada cargo. Para ello se utilizará la matriz de evaluación de cargos, utilizada en la tarea “Identificar el perfil de los cargos actuales”. Es recomendable que al evaluar el peso de los factores formación, habilidades y aptitudes, y orientación se citan las mismas variables utilizadas durante la evaluación de los cargos vigentes, más aquellas que sean necesarias en los nuevos puestos. Para los casos de cargos que resulten de la combinación de otros ya existentes se puede tomar como norma asignar a cada requisito del nuevo cargo, el nivel máximo asignado para ese requisito en los cargos absorbidos (Ej.: si el nuevo cargo X resulta de la absorción de los cargos A y B, y estos últimos tenían asignados para el requisito “Conocimiento de microinformática” un nivel Alto y Promedio , respectivamente; determinará que dicho


Página 169



requisito se califique en el cargo X como Alto)

II.c.1.2. Determinar las necesidades de personal Por cada cargo nuevo se estimará la dotación de personas necesarias. El procedimiento consistirá en relacionar el “volumen de trabajo”, que requiere intervención de mano de obra, con la “capacidad de trabajo promedio” de cada persona. El volumen de trabajo se puede estimar a partir de los insumos del proceso que son generadores de mano de obra. Posteriormente se expresará el volumen del trabajo en la relación cantidad/unidad de tiempo, a cuyo efecto se considerará el promedio y el máximo que surgirá de los datos obtenidos en el relevamiento, considerando fundamentalmente los picos (Ej: cantidad de personas atendidas por día: máximo 30, promedio 20). La capacidad de trabajo representa el volumen de trabajo que una persona puede absorber. Se pueden presentar dos situaciones: que el trabajo ya se esté realizando o que sea nuevo. Si el trabajo ya existe, atento a que los rendimientos de las personas pueden ser distintos e incluso variar de acuerdo a los días, se tomará un rendimiento promedio. Si el trabajo es nuevo, se comparará con el o los trabajos que reemplaza a fin de estimar en que medida lo simplifica o lo dificulta; y así determinar el rendimiento ajustado. La dotación del personal promedio y máxima surgirá de dividir el volumen de trabajo máximo y promedio por la capacidad de trabajo estimada. Por último se deben estimar la cantidad de puestos de trabajo a generar a fin de contemplar las ausencias previstas y no previstas (Ej.: enfermedad, en vacaciones, etc.). Para solucionar este interrogante existen distintas políticas: 

Horas extras: los trabajadores extienden su período laboral. El peligro es bajo rendimiento y agotamiento.



Personal eventual: se anticipan los períodos picos y se contrata personal , que puede ser brindado por una empresa de servicios o por ex-empleados que tienen tiempo disponible. Este método es factible para tareas de poca complejidad.



Personal intercambiable: a través de entrenamiento una persona está capacitada para trabajar en más de un proceso.



Nivelación de carga: se trata de mantener un trabajo constante evitando los picos y las depresiones. Este método no siempre es factible ya que depende de la magnitud de la carga, la duración del período máximo y la factibilidad de regular la demanda.



Outsourcing: se contrata a un tercero para que se haga responsable de parte o todo el proceso.

II.c1.3. Correlacionar cargos con procesos Mediante esta tarea se correlacionan los nuevos cargos con las actividades que componen los procesos rediseñados a fin de determinar el tipo de intervención – o aporte - de cada posición


Página 170



laboral a las distintas instancias del proceso. Se confecciona la matriz descripta en la tarea II.a.4.3. de la actividad “Relevamiento de la estructura organizacional y marco normativo” que identifica por cada intersección tarea/cargo, cuál de las siguientes situaciones prevalece: produce, controla, transfiere, responde o se informa. 4.

Insumos principales  Organigrama actualizado.  Matriz de correlación de Actividades/Tareas- Estructura Organizacional (Procesos actuales).  Matriz de evaluación de cargos actuales.

5.


6.

Cuadro de correlación de cargos anteriores y cargos nuevos. Matriz de evaluación de cargos nuevos. Matriz de correlación de Actividades/Tareas- Estructura Organizacional (Procesos rediseñados) Cuadro de necesidades de personal.

Herramientas y técnicas  Técnicas de análisis organizacional.  Técnicas de diagramación de estructuras organizacionales.  Software para diagramación de estructuras organizativas (Ej.: Visio, MS Organization Chart, etc.).  Software para correlacionar estructura organizacionales (Ej.: Orfeo, Q+Isodoc, etc.).  Software para simulación de cargas de trabajo (Ej.: Optima!®, I-think®, etc.).  Software de evaluación de puestos (Ej.: Description Now®).


Página 171

Primus











II.c.2..2. Determinar la dificultad de cambio

II.c.2. Diseño de la estructura organizativa

II.c.2.1. Definir las unidades organizativas




II.c.2..3. Definir las pautas de desarrollo e incentivos del personal





MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.c. Diseño II.c.2. Diseño de la 20/05/98 organizacional estructura organizativa Versión Recomendado

II.c.2. Diseño de la estructura organizativa

Página 172

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.c. Diseño II.c.2. Diseño de la 20/05/98 organizacional estructura organizativa


1. Objetivo  Establecer la nueva estructura organizativa que brindará soporte a los procesos rediseñados.  Determinar los cambios a realizar y sus dificultades. 2. Tareas  II.c.2.1. Definir las unidades organizativas.  II.c.2.2. Determinar la dificultad del cambio.  II.c.2.3. Definir las pautas de desarrollo e incentivos del personal. 3.

Desarrollo II.c.2.1. Definir las unidades organizativas Los nuevos cargos y los existente rediseñados o no, deben integrarse en centros de responsabilidad adoptando el modelo organizacional más conveniente. La tendencia actual es diseñar organizaciones “más planas”, que contengan menos niveles de supervisión. En este sentido, el espacio de control tradicional que estaba establecido entre 5 y 7 personas, ha pasado a un rango de 10 a 30. Los procesos rediseñados deben brindar la posibilidad de compartir información, realizar tareas paralelas a través de la tecnología y otorgar mayor autonomía a los empleados (empowerment), factores que colaboran para que no sean necesarios tantos niveles intermedios, qué básicamente realizan controles inefectivos sobre los procesos y actúan como “correos” entre la Alta Conducción y el nivel de ejecución. Al definir las unidades organizativas debe tenderse a que la mayor parte de los cargos que intervienen en un proceso queden agrupados bajo un solo centro de responsabilidad y ,en consecuencia, bajo un solo responsable. Como excepción, se presentarán los casos de actividades que son comunes a varios procesos, en cuyo caso se establecerán unidades organizativas separadas, analizando no obstante, si algunas de las tareas pueden redistribuirse entre los cargos que integran la unidad organizativa que es la principal responsable del proceso. Una vez conformada la unidad organizativa que reúne los distintos cargos que participan del proceso se establecerá el cargo responsable del éxito o fracaso del proceso rediseñado. Este cargo, usualmente es denominado en la literatura de reingeniería de procesos, “Gerente del Proceso” o “Dueño del Proceso”. Tradicionalmente el responsable mayor de una unidad organizativa debía tener la capacidad de planificar, dirigir, controlar, organizar y desarrollar a las personas que ejecutan el proceso. En el enfoque moderno se admite que es muy difícil encontrar una persona con todas estas capacidades, por lo que distintas personas pueden asumir las responsabilidades que antes se les exigía a una sola. En síntesis, a un cargo no se le puede asignar un perfil mayor que el mejor de los perfiles de las personas que pueden ocuparlo. En síntesis, el cargo responsable del proceso puede ser resultante de la generación de un nuevo cargo o de la elevación de algunos de los cargos rediseñados; y exigirá como perfil una persona que “entienda” el proceso desde el principio hasta el fin, sin necesidad de ser un experto y con


Página 173



orientación a la excelencia en el servicio y aptitudes de facilitador.

II.c.2.2. Determinar la dificultad del cambio En esta instancia se determinará el esfuerzo necesario para transformar un cargo actual en un cargo nuevo o rediseñado. En este sentido, pueden existir varios cargos actuales que por su perfil sean candidatos a ser convertidos en cargos nuevos o modificados. Se tomarán como insumos la matriz de evaluación de cargos actuales y la matriz de evaluación de cargos nuevos. El puntaje ponderado de esfuerzo de pasar de un cargo actual a uno nuevo, surgirá de aplicar el siguiente procedimiento: 

Se compararán, uno por uno, los cargos actuales candidatos con el nuevo cargo.



Por cada una de las variables que componen los factores Orientación,, Formación y Habilidades y aptitudes se otorgará un puntaje que pondere el grado de dificultad para pasar de un nivel a otro, en una escala de 1 a 10. Veamos un ejemplo: Consideremos la variable “Comunicaciones de datos” en el factor Formación. Pasar de conocimiento .....

A conocimiento ....

Requiere un esfuerzo de

Nulo

Bajo

8 puntos

Bajo

Promedio

5 puntos

Promedio

Alto

6 puntos

Esta evaluación se realizará por cada una de las variables definidas en los tres factores de ponderación. 

El puntaje de dificultad para la variable surgirá del nivel de partida y el nivel de llegada de la variable evaluada. Siguiendo con el ejemplo de la variable “Comunicaciones de datos” en el factor Formación, consideremos los siguientes casos: Cargo Actual Denominación

Nivel variable “Comunicaciones de Datos

Cargo Nuevo Denominación

Puntaje de dificultad

Nivel variable “Comunicaciones de Datos

AAAAA

Nulo

ZZZZZZ

Promedio

8 +5 = 13

BBBBB

Bajo

ZZZZZZ

Promedio

5


Página 174

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.c. Diseño II.c.2. Diseño de la 20/05/98 organizacional estructura organizativa 


Por último el puntaje de dificultad total de transformar cada par de cargos surgirá de sumar los puntajes de dificultad de cada variable comparada.

II.c.2.3. Definir las pautas de desarrollo del personal e incentivos Establecido el nuevo diseño organizacional será necesario determinar como se producirán los cambios de una posición a otra dentro de la Organización, sea dentro del mismo proceso o transitando a otro. Una restricción importante es el marco normativo, analizado en la actividad “Relevamiento de la estructura organizacional y marco normativo”, que determinará la factibilidad, extensión y el nivel de formalización del cambio. La Administración Pública y dentro de ella los regímenes de remuneraciones y clasificación del personal son un claro ejemplo de lo expuesto. El marco regulatorio estatal , de cuyas características participa el área de educación, se caracteriza por: 

Encasillamiento en rígidas clasificaciones – escalafones - que no siempre responden a las necesidades de la Organización, que dificultan la transferencia del personal entre distintas áreas y procesos , y que imponen límites a los empleados que desean progresar.



Ausencia de un plan de carreras, principalmente en las áreas administrativas.



Ascensos e incentivos basados fundamentalmente en la antigüedad que, en ocasiones son sinónimo de “permanencia en un puesto de trabajo” y no necesariamente de mayor conocimiento y experiencia.



Ausencia de evaluaciones periódicas basadas en los factores Habilidades y aptitudes, Formación y Orientación.



Poca capacitación.



En esta instancia se desarrollarán las pautas que servirán de base para el desarrollo de un plan de carreras y una política de incentivos.



Respecto del plan de carreras, algunas pautas a considerar son las siguientes:



En lo posible las distinciones de cargos y remuneraciones basadas en la posición jerárquica deberán ser reemplazadas, progresivamente, por distinciones basadas en la formación y destrezas. Este principio debe imperar desde la selección, que será por concurso, hasta la finalización de la carrera del personal dentro de la Organización.



El procedimiento de evaluación del personal deberá ser una parte importante del legajo del empleado y única base para medir los progresos y habilitar las transferencias del personal.



Se definirá una política de capacitación que asegure mantener y mejorar el nivel de conocimientos de los empleados.



Deberá evitarse que la mayor posición jerárquica tenga relación directa con el sueldo. De esta forma podrá admitirse que una posición independiente que aporta gran valor agregado a la Organización tenga más remuneración que un cargo jerárquico de línea.



Respecto de la política de incentivos, algunas pautas a considerar son las siguientes:


Página 175


4.

Generar incentivos monetarios y no monetarios que satisfagan las necesidades de los trabajadores en sus distintos niveles de necesidades12 y que sean motivadores del cargo desempeñado 13



Favorecer la formación de equipos de trabajo



Aumentar el sueldo por rendimiento y ascender por capacidad. A este efecto deberán establecerse los premios por niveles de rendimiento en función de los indicadores que fueron definidos al rediseñar los procesos.

Organigrama actualizado Matriz de evaluación de cargos actuales. Matriz de evaluación de cargos nuevos. Cuadro de correlación de cargos anteriores y cargos nuevos.


6.




5.


Organigrama rediseñado Matriz de transición de cargos Informe de pautas para desarrollar un plan de carrera Informe de pautas para implementar un sistema de incentivos

Herramientas y técnicas  Técnicas de análisis organizacional  Técnicas de diagramación de estructuras organizacionales  Software para diagramación de estructuras organizativas (Ej.: Visio, MS Organization Chart, etc.)  Software de evaluación de puestos (Ej.: Description Now®, High-Tech®)

12 Teoría de Maslow que determinó una jerarquía de necesidades humanas de 5 niveles: fisiológicas, de seguridad, sociales, de estimación y de autorealización, concluyendo que sólo la insatisfacción de las de menor nivel (Ej: hambre) son motivadoras de superación y que el dinero no siempre es el mejor motivador. 13 Teoría de Herzberg que determinó dos factores de motivación: los del contexto del empleo (factores higiénicos, equipo, oficina, paga e información) y los del contenido del empleo (atractivo y variedad del trabajo, autonomía, oportunidad de aprender, y reconocimiento). Los primeros si faltan causan insatisfacción , pero una vez satisfechos no aseguran motivación; los segundos son en sí mismo motivadores. De allí que personas con buenos salarios no estén motivados y otros con menores salarios pero empleos más gratificantes se sientan satisfechos.


Página 176

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la Compendio implantación

Fecha 20/05/98


II.d. Planificación de la implantación 1.

Objetivo  Establecer las estrategias de implantación .  Analizar los costos y beneficios de las soluciones a implementar.  Elaborar y aprobar los términos de referencia y pliegos de contratación de las soluciones a implementar.

2. Tareas  II.d.1. Definición de las estrategias de cambio.  II.d.2. Especificación de la implantación . 3. Desarrollo Durante esta etapa:  La Alta Conducción revisará y eventualmente, aprobará, el diseño organizacional y técnico en que se sustenta la solución. Se podrán sugerir ajustes hasta llegar al diseño definitivo que permita continuar con la elaboración de las estrategias de cambio.  Los costos de las soluciones informáticas serán estimados y se diseñará una estrategia respecto del software aplicativo y la infraestructura de equipamiento y comunicaciones.  Concurrentemente, se diseñarán las estrategias para cambiar los circuitos administrativos, los procedimientos de los procesos rediseñados y transitar del actual modelo organizacional a la estructura organizacional rediseñada.  Se desarrollará el plan de implantación mediante la identificación y documentación formal de los principales eventos, actividades y tareas. Se estimará el tiempo de ejecución y los recursos necesarios a fin de producir el cálculo de costos y cuadro de desembolsos.  La implantación se podrá concretar a través de un proyecto único o proyectos diferentes, si los productos o servicios, aunque integrados en la solución final, requieren una administración de proyectos diferenciadas por su complejidad o nivel de especialización.  Con el nivel de detalle obtenido se realizará un análisis de costos y beneficios, tangibles e intangibles que sirva de base para tomar la última decisión respecto de continuar o no con la implantación . Se considerarán los costos de única vez (Ej.: adquisiciones de equipamiento) y los operativos (Ej.: mantenimiento de las tareas operativas). Los costos y beneficios intangibles que no puedan ser llevados a una medida económica, serán enunciados a fin de que la Alta Conducción los considere como dato para la toma de decisiones.  Luego de la aprobación de los proyectos que integran el plan de implantación se redactarán los términos de referencia y las bases de contratación para avanzar en la efectiva instalación de la solución diseñada y aprobada.


Página 177

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la Compendio implantación

Fecha 20/05/98


4. Productos principales       

Resumen de estrategias de cambio. Plan de trabajo de implantación . Diagrama Gantt de implantación Términos de referencia de los proyectos de implantación . Pliego de condiciones generales, particulares y técnicas . Matriz de evaluación económica de beneficios y costos. Resumen ejecutivo de implantación para la Alta Conducción.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La factibilidad económica, técnica y operativa de implementar la solución técnica y organizacional diseñada.  El diseño de adecuadas estrategias que faciliten la transición no traumática entre el modelo vigente y el rediseñado.  La confección de planes de implantación con estimaciones sustentadas en métodos comprobables que identifiquen claramente los pasos a realizar, sus interrelaciones, las responsabilidades a asignar, los recursos a utilizar, los puntos críticos de control y los resultados parciales y finales que permitan verificar el progreso.  La confección de términos de referencia y pliegos de contratación que aseguren: la adhesión a los estándares de calidad internos y externos; la implantación de soluciones que viabilicen el diseño técnico y organizacional aprobado, que el producto o servicio contratado sea la solución más conveniente, eficaz y eficiente para la Organización; que respete las normas legales de contratación; que sea ventajoso y justo para ambas partes; y que resguarde al Comprador de los efectos negativos por incumplimientos del proveedor.


Página 178

Primus















II.d.1.4. Diseñar las estrategias de cambio organizacional


II.d.1.1. Aprobar el diseño técnico-organizacional

II.d.1..2. Estimar los costos de la solución informática y diseñar estrategias

II.d.1.3. Diseñar las estrategias de cambio de los procesos




MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.1. Definición de las 20/05/98 implantación estrategias de cambio Versión Recomendado


Página 179

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad Fecha II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.1. Definición de las 20/05/98 implantación estrategias de cambio

1.


Objetivo  Establecer las estrategias de cambio que guiarán la implantación .

2.


3.

II.d.1.1. II.d.1.2. II.d.1.3. II.d.1.4.

Aprobar el diseño técnico y organizacional. Estimar costos de la solución informática y diseñar estrategias. Diseñar las estrategias de cambio de los procesos. Diseñar la estrategia de cambio organizacional.

Desarrollo II.d.1.1. Aprobar el diseño técnico y organizacional La Oficina Provincial de Proyectos elaborará un resumen ejecutivo, apoyado con gráficas, destinado a la Alta Conducción que explicite los procesos rediseñados y la estructura organizativa, el marco normativo y los sistemas de información que le servirán de sustento. La Alta Conducción evaluará el modelo presentado y verificará que sea coherente con la visión del nuevo modelo de Organización elaborado en la fase de Planificación. De sugerirse correcciones, se realizarán progresivos ajustes que serán sometidos a consideración hasta lograr la aprobación final que habilitará continuar con el diseño de las estrategias de cambio.

II.d.1.2. Estimar costos de la solución informática y diseñar estrategias Se considerará la alternativa de contratar una solución pre-programada, evaluando el esfuerzo de ajustes de diseño necesarios o realizar un desarrollo a medida, con recursos contratados o propios de la Organización. Se estimarán los tiempos de cada alternativa en base a algunas de las métricas de desarrollo de software que calculan el esfuerzo en personas/mes y tiempo (Ej.: Método de Punto Función, SRP-Software Productivity Research, COCOMO-Constructive Cost Model, etc.). Para los casos de contratación de soluciones pre-programadas, el esfuerzo del ajuste a realizar podrá ser calculado por el proveedor en base a la descripción de las especificaciones técnicofuncionales Otro factor es el alcance de la solución informática, ya que se podrán contratar los distintos componentes de la solución por separado (Ej.: equipamiento, software aplicativo, comunicaciones, etc.) u optar por combinaciones de ellos o , en última instancia, por una solución “llave en mano” que llegue hasta la conversión del nuevo sistema informático. Se estimarán los costos totales de las distintas alternativas combinando los siguientes factores:


Página 180





Costo del software aplicativo (en sus distintas alternativas: desarrollo propio, contratación de desarrollo a medida o producto pre-programado)



Costo de adquisición, instalación y mantenimiento del equipamiento.



Costo de adquisición, instalación y mantenimiento del software de base.



Costo de adquisición, instalación y mantenimiento de las comunicaciones.



Costos de operación y mantenimiento del área de sistemas.



Otros costos (Ej.: migración de datos, suministros, muebles, servicios externos, reformas edilicias, capacitación, etc.)

Luego se elaborará un informe recomendando la mejor solución y una alternativa, con descripción del alcance, recursos y costos. Serán factores fundamentales en la selección de alternativas de solución, los siguientes: 

El nivel de capacitación del personal de la Organización.



La factibilidad de contratar personal para realizar los desarrollos.



El presupuesto disponible y la disponibilidad de financiar la solución.



El tiempo en que la solución debe estar operativa.

II.d.1.3. Diseñar las estrategias de cambio de los procesos La implantación de los nuevos procesos implica el diseño de los circuitos administrativos, procedimientos y comprobantes, como la expresión más detallada del modelo funcional. En esta instancia se estiman los recursos humanos necesarios y su perfil a fin de establecer si existe personal dentro de la Organización que tenga dicho perfil o que se lo pueda capacitar, y si esto último es factible, que tenga el tiempo disponible para concretar la tarea dentro de los límites aceptables para no retrasar la implantación . De no ser factible su implantación con personal de la Organización, se estimarán los costos de contratar personal externo para desarrollar un proyecto separado o bien integrarlo a los distintos proyectos que se ejecutarán durante la implantación .

II.d.1.4. Diseñar la estrategia de cambio organizacional La clave del éxito o fracaso del proceso de transformación, una vez que se han reformulado los procesos con el soporte de la mejor tecnología y diseñado una adecuada estructura organizativa, es la ejecución de una eficiente gestión de cambio. En este sentido es importante anticipar las resistencias potenciales y los pasos en que es factible que se produzca la transformación, factores claves para los que habrá que desarrollar estrategias precisas de neutralización o compensación.


Página 181



Los principales aspectos a considerar para la elaboración de una estrategia adecuada en el área organizacional son: 

Determinar los requerimientos de capacitación del personal en base a los niveles de dificultad para transitar del modelo actual al modelo rediseñado, estableciendo los tiempos que demande que la gente pueda ser productiva dentro del nuevo esquema de trabajo.



Determinar los requerimientos de personal externo por no existir el perfil dentro de la Organización y ser de dificultosa obtención a través de capacitación.



Prever los focos de resistencia que pueden presentarse, la forma de identificarlos precozmente y de medir su intensidad. Tomar en cuenta especialmente los cargos que desaparecerán , los que asumirán mayores responsabilidades y consecuentemente más carga de trabajo, los que cambiarán de unidad organizativa y los que sufrirán disminución del personal a cargo.

Las estrategias a desarrollar en esta instancia comprenderán: 

La modularización del cambio organizacional Partiendo del modelo de Organización actual y teniendo como meta la Organización rediseñada, se establecerán las distintas instancias de cambio que sean factibles, considerando básicamente los períodos de aprendizaje y adaptación



Los mecanismos de detección de focos de resistencia Dependiendo del nivel jerárquico y la cantidad de personas afectadas, se establecerán canales de comunicación masivos y fluidos o entrevistas o , simplemente, la identificación de indicadores que indiquen desmotivación o rechazos (Ej.: nivel de ausentismo)



Los mecanismos de neutralización de resistencias En este aspecto las estrategias son muy variadas y dependerán de factores diversos (Ej.: nivel del cargo afectado, personalidad de la persona que ocupa el cargo, posibilidad de ser reabsorbido dentro de la Organización, etc.) Algunas estrategias para neutralizar resistencias son:

     

Para los incrédulos: pruebas exhaustivas con su participación. Para los que presentan problemas legales o contables: certificación de los asesores legales y contables de que la solución es factible Para los cargos que desaparecerán pero se requiere la persona para transferir su experiencia: contratación como asesores, participación en el equipo de implantación , etc. Para quienes asuman mayores responsabilidades: compensaciones monetarias u otros estímulos Para personal de niveles administrativos que cambiarán sus estilos de trabajo y asumirán como equipo otras obligaciones: comunicación fluida y capacitación. Para personal que ocupa cargos que serán eliminados y cuya experiencia no es requerida para los nuevos procesos: evaluación justa para determinar si pueden ser reubicados en los nuevos perfiles que


Página 182



exige la Organización, asesoramiento y ayuda para buscar otros empleos, contratación para que colaboren en la implantación con una remuneración superior a la actual, etc.

4. Insumos principales          5.

Esquemas de actividades y eventos de los procesos rediseñados. Organigrama rediseñado Matriz de transición de cargos Matriz de evaluación de cargos nuevos Cuadro de necesidades de personal Inventario de habilidades del personal del área de sistemas Informe de especificaciones técnico-funcionales Informe de alternativas de infraestructura informática y de comunicaciones Informe software de terceros preseleccionado

Productos principales  Cuadro de costos del sistema informático.  Resumen de estrategias de cambio.

6.


Técnicas de análisis organizacional Técnicas de evaluación de puestos y análisis de destrezas Software de evaluación de puestos (Ej.: Description Now®, High-Tech®) Métricas para estimar tiempos y costos de desarrollo de software (Ej.: Método de Punto Función, SRP-Software Productivity Research, COCOMO-Constructive Cost Model, etc.)


Página 183

Primus














II.c.2.. Diseño de la estructura organizacional II.d.2. Especificación de la implementación

II.d.2.1. Desarrollar el plan de implementación

II.d.2.2. Analizar los costos y beneficios




II.d.2.3. II.d.2.3. Aprobarlos losproyectos proyectosyy Aprobar asignarprioridades prioridades asignar

II.d.2.4. Elaborar y aprobar los términos de referencia y pliegos de contrataciones

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.2. Especificación implantación de la implantación Fecha 20/05/98 Versión Recomendado

II.d.2. Especificación de la implantación

Página 184

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.2. Especificación implantación de la implantación

Fecha 20/05/98


1. Objetivo  Desarrollar el plan de implantación .  Aprobar los proyectos y asignar las prioridades.  Definir los términos de referencia de las contrataciones. 2. Tareas    

II.d.2.1. II.d.2.2. II.d.2.3. II.d.2.4.

Desarrollar el plan de implantación . Analizar los costos y beneficios. Aprobar los proyectos y asignar prioridades. Elaborar y aprobar los términos de referencia y pliegos de contrataciones..

3. Desarrollo II.d.2.1. Desarrollar el plan de implantación Los esfuerzos necesarios para la implantación de la solución integral deben ser agrupados en productos y/o servicios identificables a obtener en un tiempo limitado. A su vez, los eventos deben interrelacionarse, ya que el resultado de unos son los insumos de otros. Es común que los siguientes objetivos de implantación generen eventos separados o combinados, aún cuando todos puedan contribuir a la solución integral: 

Adquisición e instalación de equipamiento informático y software de base.



Adquisición e instalación de equipamiento y cableado para redes locales .



Adquisición e instalación de equipamiento y vínculos para redes de área extendida.



Adquisición e instalación de software pre-programado.



Contratación de desarrollos de software a medida.



Contratación de consultores para diseño detallado e implantación administrativos.



Capacitación del personal en distintas áreas y niveles.



Desarrollo de nuevos encuadres normativos.



Tercerización de servicios.



Selección de personal para la nueva estructura organizacional.



Desarrollo de plan de carreras.



Desarrollo del sistema de incentivos.

de circuitos

Posteriormente, por cada evento se generará un plan de implantación a nivel de plan de trabajo y no de programa de trabajo. El plan de implantación identifica los distintos pasos, asigna los


Página 185


Fecha 20/05/98


niveles de habilidad y los días estimados de trabajo por cada uno de los pasos. El nivel de detalle del plan de trabajo será el necesario para determinar la factibilidad y los factores económicos de la implantación . El desarrollo del plan de implantación es importante porque: es la base para la preparación del programa de trabajo a desarrollar en la fase de Implantación , sirve para estimar el trabajo requerido en cada etapa, identifica las actividades críticas, permite medir el avance durante la implantación y es útil para estimaciones futuras. Al término de la planificación, se verificará: 

Que todas las tareas tengan recursos asignados.



Que todas las dependencias entre tareas estén definidas.



Que todas las tareas tengan sus estimaciones de tiempos y recursos distintos de cero; y que estas estimaciones estén actualizadas.



Que todas las fases, actividades y segmentos tengan resultados definidos.

Las principales etapas a contemplar en la planificación, y que con mayor detalle se desarrollarán en la fase Implantación son: 

Segmentos comunes:



Organización Se relaciona con la conformación del equipo de trabajo, la recopilación de los antecedentes, el establecimiento de los estándares de trabajo, la organización de la oficina del proyecto y la confección del programa de trabajo.



Selección y contratación Se aplica a cualquier tipo de contratación (Ej.: consultores, equipamiento, software, etc.) debiendo transitarse las etapas de convocatoria, evaluación de propuestas, selección, adjudicación y contratación. 

Segmentos relacionados con proyectos de implantación de sistemas de información a medida con personal propio o contratado



Ajuste de diseño detallado Se realiza el ajuste del diseño técnico-funcional hasta alcanzar el plano de implantación físico (Ej.: definición de bases de datos, diseño de interfases, diseño de reportes y diseño de unidades de programación).



Programación Comprende la ejecución de la codificación , la preparación de los datos de prueba, la revisión del código y la realización de las pruebas a nivel de cada unidad de programación



Desarrollo de circuitos administrativos y procedimientos Comprende el diseño de los circuitos administrativos y procedimientos, el diseño de los formularios y el desarrollo de los manuales.


Página 186


Fecha 20/05/98




Preparación de la conversión Comprende el diseño de las estrategias de conversión, el desarrollo de los procedimientos de conversión, la planificación de la prueba, la generación de los archivos de conversión y la creación de un modelo de prueba del sistema completo.



Entrenamiento Comprende la preparación del material para capacitación y el entrenamiento de los usuarios del sistema.



Prueba del sistema Comprende la ejecución de la prueba integral, la revisión de resultados, la ejecución de los ajustes y la aprobación final.



Conversión Comprende la migración de los datos del sistema anterior al nuevo, la implantación de los nuevos circuitos y la puesta en producción del nuevo sistema.



Seguimiento de la conversión Se refiere al período normal de seguimiento del trabajo de migración 

Segmentos relacionados con proyectos de implantación de sistemas pre-programados Se transitan las mismas etapas mencionadas en la implantación de sistemas informáticos a medida. El alcance de las tareas de ajuste de diseño y programación, es menor que en un desarrollo a medida; no obstante, es importante tener claridad respecto de los puntos de control.



Segmentos relacionados comunicaciones

con

proyectos

de

incorporación

de

equipamiento



Preparación de instalaciones Se refiere a la preparación de los lugares en dónde se instalará el equipamiento (Ej.: ampliaciones, reparaciones, instalaciones eléctricas, etc.)



Instalación de hardware Comprende el armado y puesta en funcionamiento del equipamiento.



Instalación de software de base Comprende la instalación y prueba del software de base.



Instalación de comunicaciones Comprende los tendidos de cables, la instalación de equipamiento de comunicaciones y las pruebas



Prueba de instalación Comprende la prueba de todos los elementos que deben funcionar en forma integrada. 

Segmentos relacionados con la implementaciones de cambios de estructuras organizativas


Página 187

y


Fecha 20/05/98




Implantación de planes de carrera y sistemas de incentivos Comprende el diseño de los planes de carrera en base a las pautas establecidas durante la fase de Diseño Técnico



Capacitación del personal Se refiere a la formación del personal para ajustar sus perfiles conforme a los requerimientos de los nuevos cargos.



Diseño de manuales de misiones y funciones Comprende la generación de la documentación que formalice las nuevas áreas de responsabilidad. Identificadas las etapas deberá estimarse los recursos físicos y humanos de cada una, los perfiles del personal y el tiempo estimado para completar cada etapa. Existen distintas técnicas para la estimación de recursos y tiempos, las principales son: 

Modelos algorítmicos: se utiliza un modelo basado en información histórica que toma algunas variables que se repiten en todos los proyectos y en base a las cuales se puede proyectar los tiempos y recursos (Ej.: modelo COCOMO, Puntos Función, etc.).



Estimación por analogía: se basa en el desarrollo de proyectos similares.



Juicio experto: se realizan las estimaciones por consenso de experiencias similares.



Ley de Parkinson: el trabajo se expande hasta llenar todo el tiempo disponible.



Estimación top-down: el esfuerzo se estima considerando la funcionalidad total del producto o servicio, y ésta es provista por las subfunciones interactuantes.



Estimación bottom-up: se estima el esfuerzo de cada componente para luego agregarse al esfuerzo total

expertos que tienen

II.d.2.2. Analizar los costos y beneficios Si bien la factibilidad económica se determinó en la fase de Planificación, el propósito de esta tarea es confirmarla a la luz de la información detallada que está disponible. Los costos en concepto de adquisiciones, instalaciones y operaciones que aún no fueron estimados durante el desarrollo de la presente fase, se completarán en esta instancia. Los costos y los beneficios operativos se estimarán comparando los aspectos económicos de continuar con el actual modelo de gestión respeto del modelo propuesto, y se proyectarán para un período futuro razonable (Ej.: 3 a 4 años). El ahorro o costo neto surgirá de la diferencia entre la reducción o aumento del costo neto de operación y los costos no periódicos (Ej.: indemnizaciones, instalaciones, compras, etc.).


Página 188


Fecha 20/05/98


Como beneficios, entre otros, se considerarán la venta del equipamiento actual, el incremento de servicios o productos ofrecidos, etc. La distribución de ahorros y beneficios netos en el tiempo, deberán ser sometidos a un análisis económico de valor actual neto y punto de equilibrio. Por último, se resumirán las consideraciones intangibles, tanto en costos como en beneficios (Ej.: imagen positiva o negativa) que pueda afectar la decisión de la Alta Conducción, respecto de continuar o no con la implantación .

II.d.2.3. Aprobar los proyectos y asignar prioridades En esta instancia se someterá a consideración de la Alta Conducción el diseño técnico y organizacional, el informe económico y las estrategias de cambio a fin de obtener la aprobación para elaborar los términos de referencia y pliegos de contrataciones para continuar con la fase de Implantación . Se elaborarán borradores del informe ejecutivo y se resolverán los puntos que hayan sido identificados como dudosos, hasta poder concluir en el informe final. Si el proyecto continúa, se establecerá la fecha de comienzo. Basado en el informe final, la Alta Conducción, decidirá respecto de la razonabilidad económica del proyecto, la asignación de prioridades y la fecha de efectivo comienzo de la fase de Implantación .

II.d.2.4. Elaborar y aprobar los términos de referencia y pliegos de contrataciones Para el desarrollo de los términos de referencias de los proyectos de implantación se siguen las pautas desarrolladas en el punto I.b.4.2. de la fase de Planificación. Los contratos tienen por objetivos explicitar un acuerdo entre las dos partes con una definición precisa de los roles y responsabilidades de cada una, que se traducen en productos y/o servicios que deben ajustarse a criterios de calidad definidos. Los aspectos críticos de un contrato informático14, que pueden ser extendidos a cualquier contratación que se desprenda de un proceso de transformación en las áreas administrativas, son: 

El producto o servicio: adecuada definición de las características técnico-funcionales del producto o servicio a ser provisto .



Las entregas y plazos: la cantidad y plazos en que deben estar disponibles los servicios o productos.

14

BEL, Juan de Dios, Trabajo “Auditoría Especializada de Contrataciones Informáticas “ expuesto en el X Congreso Argentino de Informática en representación de la Sindicatura General de la Nación, Buenos Aires, 1997.


Página 189


Fecha 20/05/98




La confiabilidad: la consistencia de la eficacia esperada del producto.



La integridad: el nivel de protección incorporado dentro del producto o servicio.



La documentación: el tipo, extensión y suficiencia de las explicaciones suministradas del producto o servicio que otorgue importantes niveles de autonomía al Comprador.



El entrenamiento: las ofertas educacionales y materiales provistos por el proveedor para enseñar a utilizar el producto, y eventualmente, a mantenerlo.



El mantenimiento: los medios que provee el proveedor para ajustar los defectos del producto.



La utilidad: el esfuerzo requerido para utilizar las características del producto.



La flexibilidad: la facilidad con que los nuevos requerimientos pueden ser agregados al producto.



La portabilidad: la facilidad con la que el producto puede ser movido a otro ambiente operacional.



Los antecedentes del proveedor: la confianza de que el proveedor cumplirá con el objeto del contrato.



Las provisiones contractuales: las cláusulas en el contrato especificando los términos y condiciones a ser seguidos durante la ejecución del mismo.

A continuación se desarrollarán las principales consideraciones que deben ser contempladas en la confección de los pliegos de contrataciones, las que se adaptarán a las exigencias formales que el Organismo que financia (Ej.: BID, Bco. Mundial, etc.) o la Organización contratante.

Consideraciones Generales: 

El pliego se desarrollará desde los aspectos más generales, y comunes a cualquier contratación, hasta los particulares y específicos del producto o servicio a contratar. Debe ser de fácil lectura y comprensión.



Las condiciones generales y particulares que regularán la relación de las partes deben seguir el ciclo de vida de la contratación: definición de requerimientos, presentación de ofertas, apertura, selección, adjudicación, ejecución, pruebas de aceptación y finalización del contrato.



Es recomendable elaborar un borrador del pliego que se anticipará a los potenciales Oferentes para que dentro de un plazo determinado realicen las observaciones necesarias, cuya incorporación quedará a criterio de la Organización contratante. Esta aclaración debe ser incluida en la nota de distribución..



Las bases del concurso deben incluir como mínimo: los pliegos de especificaciones generales y particulares que regulen el proceso del concurso; los datos particulares del concurso que modifican las especificaciones generales y particulares, cuando las primeras ya están pre-impresas; el modelo del contrato a firmar con el Adjudicatario, las especificaciones técnico-funcionales de los productos y/o servicios a contratar, los Anexos


Página 190


Fecha 20/05/98


necesarios y la Carta-Invitación, en los casos en que los proponentes hayan sido preseleccionados

Aspectos relacionados con el proceso de selección y adjudicación – Condiciones Generales y Particulares Comprende los eventos: llamado a concurso, preparación de las ofertas, presentación de las ofertas, selección y adjudicación. Las principales cláusulas que deben estar presentes: 

Objetivo y alcance de la contratación: resume los productos y/o servicios principales y conexos, a contratar.



Definiciones: comprende un glosario con todos los términos utilizados en los documentos incluidos en las bases de contratación que puedan dar lugar a distintas interpretaciones. Se aclararán expresamente los sinónimos.



Oferentes elegibles: indicar las restricciones generales (Ej.: origen de los licitantes, admisibilidad de UTE, etc.) impuestas por los Organismos que financian, por la legislación vigente o por el propio Comprador.



Bienes y servicios elegibles: indicar las restricciones generales (Ej.: origen de los bienes) impuestas por los Organismos que financian, por la legislación vigente o por el propio Comprador, respecto de las condiciones que deben reunir los bienes y servicios a contratar para ser admitidos.



Domicilios: aclarar las exigencias de domicilios especiales y legales.



Apoderados: especificar los instrumentos que se requerirán para acreditar representaciones válidas.



Sistema de contratación: especificar la modalidad de contratación (Ej.: ajuste alzado, por unidad de medida, etc.)



Costos del concurso: aclarar que el Oferente no podrá reclamar ningún gasto que le demande la preparación y presentación de la Oferta independientemente del resultado final.



Precio de los pliegos: especificar el valor de los pliegos y qué se solicitará como constancia de su pago.



Documentos del concurso o licitación: listar todos los documentos que componen las bases del concurso indicando su validez como fuente única de información , establecer el orden de prelación en caso de que se presenten contradicciones entre los documentos y de éstos respecto de la legislación.



Enmiendas: dejar abierta la posibilidad de introducir enmiendas, aclarando cuáles serán los medios válidos de notificación.



Idioma: establecer el idioma oficial de la presentación y las condiciones de traducción cuando venga en otro idioma que no sea el oficial.


Página 191


Fecha 20/05/98




Interpretación de los plazos: especificar como se cuentan los términos establecidos en el pliego (Ej.: días corridos) y qué sucede cuando concluyen en un día inhábil.



Consultas y aclaraciones: establecer los medios y plazos en que los Oferentes podrán expresar sus inquietudes y en los que el Organismo licitante responderá.



Forma de presentación: aclarar cuál de las tres alternativas de presentación se exigirán Sobre único: antecedentes del Oferente, propuesta técnica y propuesta económica, juntas; Dos sobres: sobre 1 con antecedentes y propuesta técnica y sobre 2 con propuesta económica. Se abren en distintos momentos. El sobre 2 es abierto exclusivamente respecto de aquellos que superaron la calificación del sobre 1. Tres sobres: sobre 1 con antecedentes del Oferente, sobre 2 con propuesta técnica y sobre 3 con propuesta económica. En las etapas 2 y 3 concursan los Oferentes que hayan superado las instancias anteriores. Se determinará la carátula y contenido de cada sobre, indicando: exigencias de copias y detalle de la documentación a presentar, orden y forma de identificación.



Plazo de presentación: indicar hasta que momento se admiten la presentación de ofertas, el tratamiento de las ofertas tardías y las posibilidades de retirar o modificar ofertas.



Antecedentes del Oferente: especificar los antecedentes que hacen elegible a un Oferentes, a cuyo efecto deberá solicitarse:



Antecedentes institucionales ,legales e impositivos.



Referencias de su capacidad para contratar (Ej.: declaración de juicios, quiebras, inexistencia de impedimentos para contratar con el Organismo contratante, DDJJ de la veracidad y exactitud de la documentación presentada, inexistencia de inhabilitaciones generales, etc.)



Referencia de su actividad general y específica respecto de los bienes y servicios a contratar



Propuesta técnica: enunciar los antecedentes que el Oferente incorporará en su propuesta, los que en detalle se describirán en las especificaciones funcionales y técnicas de los productos y/o servicios.



Descripción detallada de los productos y servicios con aclaraciones respecto de cada uno de los puntos solicitados en las especificaciones funcionales y técnicas de los productos y /o servicios contratados.



Descripción de la metodología de trabajo.



Organización y composición del equipo de trabajo.



Plan de trabajo.



Plan de entregas.



Propuesta económica:describir los ítems (productos/servicios) que debe cotizar en forma mandatoria, la unidad de medida de cotización, los conceptos a desglosar, la moneda de cotización, las condiciones especiales que puede incluir, la posibilidad de presentar ofertas


Página 192


Fecha 20/05/98


básicas y alternativas, las modalidades de financiación (contado, contado financiado, leasing, etc.) y el período de mantenimiento de la oferta. 

Apertura de las ofertas: indicar lugar, fecha y hora de apertura del primer o único sobre, principales pasos del acto de apertura, causales de rechazo durante el acto, observaciones subsanables en un plazo determinado y forma de comunicar la apertura de los sobres subsiguientes.



Garantía de Oferta: enunciar el monto o porcentaje que cubre la Garantía de Oferta, las formas de instrumentarlas, las situaciones que provocan su ejecución y el momento y modalidad de devolución.



Calificación: describir el proceso de calificación de cada una de las etapas hasta llegar a la adjudicación, los rubros e ítems que se calificarán, los conceptos que comprenden, el puntaje mínimo y máximo de cada ítem; y el puntaje mínimo admitido para que el Oferente precalifique en cada una de las etapas del proceso licitatorio. Aclarar expresamente si el Oferente deberá poner a disposición el producto para ser sometido a pruebas de calidad o performance. A continuación se enuncian los principales rubros y conceptos que permiten merituar tanto al proponente como a la propuesta técnica: Antecedentes del Oferente: envergadura; presencia local; capacidad económica, financiera y operativa; experiencia general, visión estratégica, experiencia específica en el objeto de contratación, nivel de respuesta ante requerimientos de servicios, etc. Antecedentes de la propuesta técnica: equipo de trabajo: antecedentes del director del proyecto y los integrantes críticos del equipo, experiencia como integradores (supuesto de soluciones llave en mano), etc. Plan de trabajo: coherencia, nivel de detalle de tareas, plazos de entrega, etc. Metodología de trabajo: adherencia a estándares, calidad de la propuesta de gestión y control del proyecto, etc. Software aplicativo: nivel de ajuste para asimilar las características funcionales y técnicas de la solución requerida, portabilidad, performance, integridad, confiabilidad, flexibilidad, nivel de actualización, facilidad de migración, ambiente de desarrollo, seguridad, auditabilidad, simplicidad de operación, adherencia a estándares, adecuación a tendencias tecnológicas, nivel de mantenimiento, documentación, entrenamiento, etc. Hardware, software de base y comunicaciones: por cada uno de sus componentes se desglosarán los conceptos a calificar, entre otros: diseño de la solución, configuración, expansión, performance, nivel de compatibilidad con equipamiento existente, confiabilidad, facilidad de administración, tolerancia a fallas, mantenimiento, garantía, soporte técnico, documentación, entrenamiento, etc.



Comunicaciones con el Oferente durante el proceso de calificación: establecer la forma en que el Contratante se comunicará con el Oferente para aclarar dudas.


Página 193

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.2. Especificación implantación de la implantación 

Fecha 20/05/98


Adjudicación: establecer los criterios para adjudicar, los derechos del Comprador respecto del alcance en ítems y cantidades, la modalidad de notificación y la formalización de la adjudicación (Ej.: firma del contrato). Respecto del criterio existen dos posturas: la que adjudica al Oferente que presente menor precio con la condición de haber resultado precalificado en los antecedentes, sin importar el orden de mérito que obtuvo ; y la que se basa en el Oferente que haya obtenido el mayor puntaje final resultado de la sumatoria de la calificación obtenida en los antecedentes, la propuesta técnica y la propuesta económica.



Garantía de adjudicación: enunciar el monto o porcentaje que cubre la Garantía de Adjudicación, las formas de instrumentarlas, las situaciones que provocan su ejecución y el momento y modalidad de devolución.

Aspectos relacionados con la descripción de las características técnicas y funcionales del producto o servicio a contratar Los conceptos que aparecen entre corchetes son optativos dependiendo de los componentes de la solución contratada 

Antecedentes de contexto: describir el ambiente en donde debe operar la solución propuesta (Ej.: infraestructura informática y de comunicaciones disponible, cantidad de personal, organigrama, debilidades funcionales a solucionar, etc.)



Objetivos generales y específicos: detallar los objetivos del proyecto que se satisfarán con la presente solución.



Alcance de los bienes y servicios a contratar: las soluciones pueden tener distintos niveles que deberán especificarse claramente (Ej.: se solicita provisión sin instalación)



Resultados esperados: son los hitos que deben alcanzar el Adjudicatario y que servirán como puntos de control de que las tareas han sido realizadas satisfactoriamente.



Actividades: se enunciarán las actividades mínimas que se les requiere al Adjudicatario, independientemente de la metodología propuesta. El Oferente deberá acompañar un plan detallado de trabajo en el que cite las actividades enunciadas y que se deberá correlacionar con el plan de entregas.



[Especificaciones funcionales y técnicas del software aplicativo]: se desarrollarán cada una de las características exigidas al software aplicativo a nivel general y de cada módulo. Objetivo: describir los objetivos esenciales del sistema de información, los procesos y funciones a cubrir, los beneficios que se pretenden obtener y la visión del entorno transformado una vez que el sistema esté implementado. Los sistemas complejos se dividirán en subsistemas, en cuyo caso deberá distinguirse el objetivo general de los objetivos específicos de cada subsistema. Alcance: describir el alcance de la solución respecto de los aspectos funcionales (procesos, segmentos, eventos), dispersión geográfica (Administración Central,


Página 194


Fecha 20/05/98


Delegación XX, Escuelas zona ZZ, etc.) y las unidades organizativas incluidas (Dirección e Personal, Juntas de Clasificación, Juntas de Disciplina, Delegaciones Administrativas, etc.) . Restricciones Generales: referenciar las limitaciones específicas técnicas (Ej.: infraestructura de comunicaciones, limitaciones de espacio, etc.) o de gestión (Ej: nivel de capacitación del personal, normativa restrictiva, etc.) que afecten al proyecto en cuestión. Requerimientos Funcionales Generales y Específicos: a nivel general se determinarán las condiciones operativas básicas que el sistema de información deberá proveer (Ej.: manejo de esquemas descentralizados, trazabilidad, etc.) y a nivel específico, por cada uno de los subsistemas, la descripción de los eventos incluidos, las alimentaciones, las salidas y las funciones principales. Modelo de datos: si existe un diseño preliminar de las entidades que el sistema debe administrar, será útil incluirlas, sin que ello condicione el diseño físico de las bases de datos de la solución a proponer, pero sí para que el Oferente disponga de información respecto del esfuerzo del ajuste de diseño que deberá realizar. Se sugiere la presentación de diagramas de entidad-relación. Requisitos de ejecución y de performance: se brindará información de volúmenes de datos, número de usuarios, tiempos máximos de respuesta, caudal de tráfico, grado de crecimiento y cualquier otra información que describa la calidad del ambiente operativo deseado. Características técnicas de la solución a diseñar: se consignarán las restricciones en el diseño e implantación relacionadas, principalmente, con el soporte tecnológico de la solución a proveer. Entre otros, los aspectos a considerar son: interfaz de usuario, tecnología en hardware y software de base soportada, niveles de performance, modalidad de manejo de esquemas descentralizados portabilidad, integridad, flexibilidad, ambiente de desarrollo, estándares de la industria que deberán respetarse y auditabilidad del sistema. Productos que debe entregar el Oferente: se identificarán los productos que el Oferente deberá entregar, tales como módulos del software desarrollado (programas fuente y objeto), documentación de diseño, documentación de uso, documentación de operación, documentación de fallas rutinarias (trouble shooting), mantenimiento del usuario, etc. Si el contrato incluyese la prestación de servicios adicionales a los de desarrollo e instalación, tales como mantenimiento adaptativo y/o correctivo, formación de usuarios y operadores, consultoría, etc., deberán igualmente especificarse en este apartado. Parámetros de seguridad: describir el esquema de seguridad a nivel operación del sistema respecto de las funciones y acceso a datos. 

[Especificaciones funcionales, técnicas y de soporte del hardware]: se desarrollarán las características exigidas a nivel general (Ej.: alimentación 220, manuales en castellano, tecnología INTEL compatible, garantía mínima 12 meses, etc.) y específicas por cada uno de los elementos que integran el equipamiento (Ej.: servidores de aplicaciones, servidores de datos, puestos de trabajo, impresoras de escritorio, etc.).


Página 195


Fecha 20/05/98


Salvo condiciones muy particulares, los requerimientos funcionales y técnicos exigidos serán los mínimos por cada uno de los conceptos a evaluar (Ej.: configuración, expansión, performance, nivel de compatibilidad con equipamiento existente, confiabilidad, facilidad de administración, tolerancia a fallas, mantenimiento, garantía, soporte técnico, documentación, entrenamiento, etc.). Para que el Oferente pueda proponer una configuración se le aportarán datos relacionados con volúmenes y frecuencias de eventos para estimar capacidades, expansiones y rendimientos. Cuando se solicite la instalación del equipamiento para que quede en condiciones operativas, se brindarán especificaciones de los sitios de instalación y las obras que deberán realizar. Solicitar la presentación de manuales, diagramas y eventualmente, demos. 

[Especificaciones funcionales y técnicas del software de base]: se desarrollarán cada una de las características exigidas al software de base y servicios conexos. Debe correlacionarse con la grilla de calificación. Salvo condiciones muy particulares, los requerimientos funcionales y técnicos exigidos serán los mínimos por cada uno de los conceptos a evaluar. Solicitar folletería actualizada en español o traducida.



[Especificaciones funcionales y técnicas de las comunicaciones]: se especificarán los objetivos y el alcance de la solución de comunicaciones, las características generales (Ej.: normas y homologaciones admitidas, protocolos, señalizaciones, escalabilidad, manuales, etc.) y las características específicas de cada uno de los componentes (Ej.: vínculos WAN, cableado horizontal, cableado vertical, equipos de distribución, software de administración, etc.) . Se describirán las normas de trabajo del personal y las condiciones en que deberán quedar los inmuebles y las instalaciones en caso de roturas. Se sugiere que se acompañen planos de las plantas con distribución tentativa de bocas. Exigir el conocimiento de los lugares de trabajo y solicitar memorias descriptivas de la solución a proponer.



[Capacitación]: describir los requerimientos mínimos de formación por área, el lugar de dictado, el material a proveer y la cantidad de personas a capacitar por tema. Solicitar descripción del contenido de los cursos y el material a proveer.



[Cuestionario Técnico]: los principales aspectos técnicos requeridos en cada uno de los componentes de la solución se desarrollarán a nivel del cuestionario para que sea contestado expresamente por el Oferente. La redacción del cuestionario deberá evitar respuestas vagas y será, junto con la descripción de la propuesta técnica, la base de calificación de los Oferentes.


Página 196

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Fase Segmento Actividad II – DISEÑO DE SOLUCIONES II.d. Planificación de la II.d.2. Especificación implantación de la implantación 

Fecha 20/05/98


Plan de entregas: el Comprador indicará por cada uno de los productos y servicios solicitados el tiempo máximo de entrega. El Oferente especificará el tiempo comprometido de entrega que será considerado para evaluar dicho concepto.

Aspectos relacionados con las condiciones generales y particulares Las cláusulas incluidas en este capítulo explicitan las condiciones generales y particulares que regularán la relación entre el Adjudicatario y el Comprador desde la iniciación del vínculo contractual hasta su finalización. Algunas cláusulas específicas serán completadas luego de haberse definido el alcance de la adjudicación; no obstante, su inclusión dentro de las bases permite anticipar al Oferente las condiciones que acepta tácitamente al momento de firmar los pliegos. Las principales cláusulas a incluir son: 

Definiciones: incluir un glosario con todos los términos utilizados en el contrato (Ej.: proveedor, adjudicatario, Comprador, BIRF, BID, producto, servicios, etc.)



Leyes aplicables: especifica la legislación que regulará el contrato.



Alcance de la contratación: se transcribirán los bienes y servicios que resulten adjudicados con indicación de cantidades, valores unitarios y totales, condiciones de pago, planes de entrega y especificaciones de condiciones financieras especiales. Deberá ser copia fiel del acta de adjudicación.



Normas de calidad: los bienes y/ servicios suministrados o prestados de conformidad con el contrato se ajustarán a las normas de calidad mencionadas en las Especificaciones técnicas ,o en su defecto a las normas ofíciales de aplicación en el país de origen de los bienes. Esas normas deberán ser las más recientes adoptadas por la institución que corresponda.



Confidencialidad: el proveedor deberá mantener la confidencialidad de la información con la que tome contacto durante la relación contractual, la que podrá ser utilizado para fines distintos del contrato solamente con la autorización expresa del Comprador. Se podrá prever que el Proveedor entregue al Comprador toda la información generada y utilizada al término de la relación contractual.



Derechos de patente: el Proveedor indemnizará al Comprador en caso de reclamaciones de terceros relacionadas con transgresiones de derechos de patente, marca registrada o diseño industrial causadas por la utilización de los bienes o parte de ellos en el país del Comprador.



Garantía de fiel cumplimiento del contrato: se especificará el plazo, monto y forma en que el proveedor deberá hacer efectiva la garantía de adjudicación. Se indicará las situaciones en que se procederá a su ejecución y su devolución.



Inspecciones y pruebas: se especificarán los derechos que le asisten al Comprador de realizar verificaciones periódicas a fin de constatar si los bienes y servicios cumplen con las especificaciones funcionales y técnicas requeridas, los lugares de inspección, el deber del proveedor de asumir todos los costos y las acciones en caso de comprobar que las entregas no satisfacen los requisitos de calidad exigidos.


Página 197


Fecha 20/05/98




Embalaje: se establecerán las condiciones que deben cumplir los embalajes externos e internos de los bultos para minimizar los riesgos de rotura.



Entregas y documentos: se especificará la documentación que deberá poner a disposición el proveedor con cada entrega y los lugares en donde entregarán los productos o ejecutarán los servicios. Se establecerá el hito que transfiere la responsabilidad del proveedor al Comprador.



Seguros: se establecerán los contratos de seguro que deberá contratar el proveedor para cubrir contingencias en los bienes y servicios comprometidos o respecto del personal afectado.



Servicios conexos: se especificarán los servicios accesorios que están incluidos en la propuesta (Ej.: montaje, puesta en funcionamiento, etc.)



Pago: se reglamentará las condiciones, moneda y formas en que se efectivizarán los pagos.



Precios: la regla general es no aceptar ajustes de precios.



Garantías de los bienes y servicios: El proveedor garantizará que todos los bienes suministrados en virtud del contrato son nuevos sin uso, están libres de defectos, corresponden al último modelo, incorporan todas las mejoras recientes en diseño y materiales salvo que se haya previsto otra cosa que el Contrato. Se establecerán la vigencia de la garantía, los procedimientos de reclamos, la forma de subsanar los desperfectos sin costo para el Comprador y las acciones en caso de no ser solucionados.



Garantía Año 2000: el proveedor garantizará el correcto funcionamiento del software de base, sistemas aplicativos y hardware a partir del año 2000, siendo este evento totalmente transparente. Cualquier modificación procedente quedará a exclusivo cargo del proveedor.



Ordenes de cambio: se establecerán las situaciones en que se podrán alterar cantidades solicitadas, lugares de entrega o diseños sin modificar precios.



Cesión: se indicará la imposibilidad de que el proveedor ceda total o parcialmente el contrato, sin la autorización expresa del Comprador.



Subcontratos: el proveedor deberá notificar al Comprador por escrito todos los subcontratos que adjudique en virtud del contrato si no lo hubiera hecho ya en su oferta. La notificación, realizada en la oferta original o con posterioridad, no eximirá al proveedor de ninguna de las responsabilidades u obligaciones que le incumben con arreglo al contrato.



Demoras del proveedor: se establecerán los mecanismos que entrarán en vigencia cuando se compruebe que el proveedor no puede cumplir con las entregas a fin de determinar si le cabe responsabilidad y la forma de compensación.



Fuerza mayor: se explicitarán las situaciones generales que serán consideradas de fuerza mayor y eximirán al proveedor. Se declararán las situaciones particulares que no sean consideradas de fuerza mayor y que sean de dudosa interpretación si se rigen por los conceptos generales.


Página 198


4.




Rescisión: se establecerán las situaciones que expresamente den lugar a la rescisión (Ej: incumplimiento de calidades, plazos, cantidades; revocación por conveniencia, rescisión por insolvencia, etc.). En cada caso se determinarán las acciones y formas de compensación del Comprador.



Liquidación por daños y perjuicios: se especificarán las condiciones en que además de la ejecución de las garantías de fiel cumplimiento sea necesario una compensación adicional, estableciendo las formas de efectivización.



Solución de controversias: se establecerán los mecanismos de resolución de problemas antes de llegar a la instancia judicial.



Notificaciones: se declararán los mecanismos formales de comunicación cierta.



Impuestos y derechos: se indicarán los impuestos y derechos que son responsabilidad de cada parte.



Los términos de referencia y pliegos de contrataciones se someterán a consideración de la Alta Conducción para ser aprobados y poder continuar con la fase de Implantación .

Insumos principales               

5.

Fecha 20/05/98

Matriz de oportunidades de mejora y recomendaciones. Esquemas de actividades y eventos de procesos rediseñados. Diagrama de dependencia entre procesos. Especificaciones técnico-funcionales del sistema de información. Informe de especificaciones técnico-funcionales Informe software de terceros preseleccionado Informe de alternativas de infraestructura informática y de comunicaciones Diagrama de flujo de datos Diagramas de entidad-relación Organigrama rediseñado. Cuadro de necesidades de personal. Matriz de correlación de Actividades/Tareas-Estructura Organizacional (Procesos rediseñados). Matriz de transición de cargos. Informe de estrategias de cambio. Matriz costos y beneficios.

Productos principales  Resumen Ejecutivo de implantación para la Alta Conducción.  Matriz de evaluación económica de beneficios y costos.


Página 199


   

6.

Fecha 20/05/98


Plan de trabajo de Implantación . Diagrama Gantt de Implantación Términos de Referencia proyectos de implantación . Pliego de condiciones generales, particulares y técnicas .


Técnicas de evaluación de proyectos. Técnicas de asignación de prioridades. Procesadores de palabra con plantillas de licitaciones. Recomendaciones de la SIGEN (Sindicatura General de la Nación) respecto de auditoría de contratos informáticos.  Estándares publicados por la Secretaría de la Función Pública.


Página 200

Primus


III.a. LANZAMIENTO

III.a.1. Organización

III.a.2. Contratación de bienes y servicios

III.c.2. Instalación de software de base

III.c. INSTALACION DE HARDWARE, COMUNICACIONES Y SOFTWARE DE BASE

III.c.1. Instalación de hardware y comunicaciones

III.d.2. Programación a medida

III.b.3. Ajuste de diseño del SW aplicativo a medida III.b. DISEÑO DETALLADO III.d. CONFIGURACION DE PAQUETES Y PROGRAMACION

III.d.1. Configuración del SW aplicativo preprogramado

III.b.1. Ajuste de diseño de procesos

IIII.f.2. Capacitación del personal

III.e. Preparación de la conversión

III.e.2. Preparación de la prueba integral y de aceptación

III.e.1. Desarrollo de los procedimientos de conversión

III.f. Evaluación y capacitación

III.f.1. Evaluación del personal

IIII.b.2. Ajuste de diseño de SW aplicativo preprogramado

FASE 3: IMPLANTACION

III.g.2. Conversión

III.g. PRUEBA FINAL Y CONVERSION

III.g.1. Prueba final

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Compendio ----------------Fecha 20/05/98 Versión Recomendado

III. Implantación

Página 201

Fase III – IMPLANTACION

1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Compendio -----------------

Fecha 20/05/98


Objetivo  Completar el diseño técnico de detalle del nuevo proceso y sus sistemas de apoyo a fin de prepararlo para el esfuerzo de conversión.  Identificar y capacitar el personal que tendrá responsabilidades en la transición hacia el proceso rediseñado y en su administración posterior.  Dejar en operación el nuevo proceso y sus sistemas de apoyo luego de verificar que es la realización más próxima a la visión que le dio origen y que satisface las especificaciones funcionales y operativas del diseño de detalle.

2.

Segmentos       

III.a. III.b. III.c. III.d. III.e. III.f. III.g.

Lanzamiento. Diseño detallado. Instalación de hardware, comunicaciones y software de base. Configuración de paquetes y programación. Preparación de la conversión. Evaluación y capacitación. Prueba final y conversión.

3. Enfoque del desarrollo La fase Implementación es la etapa del proyecto dónde proporcionalmente se producen más fracasos, no tanto por errores de estimación de las actividades planificadas como por la ausencia de planificación. Las preguntas claves que se contestan en esta etapa son:  ¿Cuáles son las actividades críticas y productos que deben generarse para realizar la visión?  ¿Cómo podemos asegurarnos que la transición sea exitosa y satisfaga las expectativas generadas?  ¿Cómo se organiza la implantación y quienes son las personas que deben participar para minimizar los riesgos del fracaso?  ¿Qué aspectos del diseño global deben llevarse a un nivel de detalle para permitir la conversión del sistema?  ¿ Qué debe preverse para que la infraestructura informática y de comunicaciones esté en funcionamiento al momento de la conversión?  ¿ Cuáles son las variables a controlar en los desarrollos de software aplicativo tanto en la programación a medida como en la contratación de soluciones pre-programadas?  ¿ Cuáles son los requerimientos de capacitación del personal que participará en la conversión y del que administrará el nuevo proceso?  ¿ Con qué información se iniciará el nuevo sistema, como se la incorporará y de qué forma se la validará?  ¿ Qué mecanismos se deben desarrollar para mantener los cambios controlados?


Página 202


       


Fecha 20/05/98


¿Quiénes están capacitados para cubrir los nuevos perfiles? ¿ Qué procedimientos se seguirán para evaluar al personal y seleccionar los candidatos? ¿ Qué estrategia se seguirá con quienes queden desafectados? ¿Cuáles son los documentos básicos que se deben generar y bajo qué procedimientos se difundirán? ¿ Qué procedimientos de prueba deben aplicarse para asegurar la satisfacción del usuario y el cumplimiento de las especificaciones técnicas y operativas desarrolladas durante el diseño de detalle? ¿ Cuáles serán los procedimientos de conversión? ¿ Qué procedimientos se ejecutarán si al momento de la conversión las cosas no suceden como se esperaban? ¿Quién tomará la decisión de discontinuar el proceso viejo o volver atrás si el nuevo falla? ¿Cómo se puede asegurar que después de la conversión se genere un clima favorable para continuar mejorando el nuevo proceso ?

La contestación a las preguntas planteadas se desarrollará en los siguientes segmentos:  Lanzamiento Constituye el segmento de organización del proyecto. Se selecciona el personal que conformará el equipo de trabajo bajo la dirección del Gerente de Implantación y se designa el Dueño o Gerente del Proceso como responsable máximo del nuevo proceso. Se establecen los estándares de trabajo que conduzcan a un desempeño eficiente y faciliten la comunicación. La documentación generada en las fases anteriores servirán de insumo para el desarrollo de la presente fase. Se concluye con la preparación del programa de trabajo en base al plan de implantación preparado durante la fase de Diseño de Soluciones, el que deberá someterse a la revisión y aprobación del Gerente de Proyectos Provincial y la Alta Conducción, a fin de habilitar el inicio de las tareas. Se considerará como actividad especifica la revisión y ejecución de la estrategia de sensibilización a fin de “recordar” la visión de los nuevos procesos a implementar, los beneficios a obtener y los focos potenciales de problemas durante la fase de transición, atento a que es en este momento dónde se producen las principales resistencias. Por último, se contratarán las soluciones informáticas y de comunicaciones más los soportes específicos de implantación.

 Diseño detallado Las especificaciones funcionales y técnicas desarrolladas en la fase de Diseño de soluciones se revisan y modifican, a fin de modelar el proceso al máximo nivel de detalle en los siguientes componentes: circuitos administrativos, software aplicativo desarrollado a medida, parametrización y configuración de las soluciones pre-programadas y estrategias de conversión.


Página 203



Fecha 20/05/98


El proceso rediseñado se especificará a nivel de circuitos administrativos y procedimientos con el correspondiente rediseño de comprobantes y estandarización de rúbricas. El software aplicativo a medida y pre-programado se revisará y ajustará, según sea necesario, a fin de completar el diseño detallado de la base de datos, las entradas y salidas, las reglas de funcionamiento, las unidades de programación, los procedimientos de seguridad, privacidad y control, y los procesos de migración del sistema legado al nuevo.

 Instalación de hardware, comunicaciones y software de base La instalación de la infraestructura básica de hardware, software de base y comunicaciones que brindará soporte al proceso debe ser realizada con anterioridad a la realización de las pruebas del software aplicativo. El segmento comprende: la preparación de los sitios en donde se instalará el equipamiento y las facilidades de comunicaciones; la instalación , puesta en marcha y verificación de funcionamiento; y la identificación y adquisición de los suministros necesarios. Posteriormente, se instalará el software de base y se procederá a realizar una prueba integrada junto con el hardware y comunicaciones, para verificar el correcto funcionamiento de todos los componentes.

 Configuración de paquetes y programación Comprende en forma paralela la parametrización y configuración de las soluciones preprogramadas y la codificación del software aplicativo a medida, respectivamente. El tiempo que absorbe el presente segmento puede representar la parte principal del esfuerzo total de la implantación. Previo a comenzar con las tareas de codificación debe prepararse el ambiente de trabajo, detallarse las especificaciones de cada programa y agrupar éstos en unidades de trabajo de programación que serán distribuidos entre los distintos responsables. La utilización de metodologías de ingeniería de software en la programación y el control de cambios aseguran la calidad del proceso, facilitan el trabajo entre los distintos equipos y reducen los tiempos. Las unidades de programación se codifican y se revisan eliminándose los errores de sintaxis. Previo a la prueba de cada unidad se repasa la codificación para asegurar que ésta satisface los requisitos de las especificaciones del programa. Las pruebas unitarias y de semi-integración debe estar apoyadas en un plan de pruebas.  Preparación de la conversión Las principales funciones son: preparar el programa de trabajo de conversión, especificar los procedimientos y preparar la prueba integral del proceso rediseñado. La participación de los usuarios es esencial en esta etapa del proyecto.


Página 204



Fecha 20/05/98


La estrategia de conversión seleccionada condicionará el tipo de prueba integral a realizar. La preparación de la conversión producirá: el cronograma de conversión con definición de fases y fechas de corte, los procedimientos de conversión del personal, el plan de contingencias, la planificación de la prueba integral, los archivos de conversión y el modelo de prueba.

 Evaluación y capacitación En el presente segmento se evalúa el perfil del personal a fin de identificar los candidatos potenciales para cubrir los puestos de trabajo del proceso rediseñado. De la comparación de la dotación necesaria con la disponible surgirán faltantes y excesos. Los faltantes podrán cubrirse con la incorporación de personal externo o la capacitación de aquellos con aptitudes. El personal excedido está compuesto por aquellos que no satisfacen el perfil del cargo o que satisfaciéndolo no resultaron favorecidos en orden de mérito por existir más candidatos que puestos disponibles. La Organización determinará la estrategia a seguir con los excedentes: desde reubicarlos previa capacitación para los casos en que la Organización esté en expansión hasta su despido por producirse una situación de contracción. Deberá tenerse especial precaución en no despedir personal que luego se descubre es necesario en otras áreas de la Organización. El proceso de capacitación del personal seleccionado comenzará con la determinación de los requerimientos de capacitación. Luego se confeccionará el plan de capacitación, se seleccionarán los capacitadores y se prepararán los manuales y materiales de apoyo. Por último se ejecutará la capacitación. La capacitación debe estar concluida antes de la ejecución de la prueba integral y ser “justo a tiempo”: ni muy anticipada de modo que olviden los que se les enseñó, ni muy tardía que provoque demoras en la implantación efectiva o bien afronten la conversión sin los suficientes conocimientos.

 Prueba final y conversión Este segmento representa el hito más importante del proyecto ya que tiene por objetivo realizar la visión del proceso con la mínima cantidad de errores y en un clima que favorezca la mejora continua. Se divide en dos momentos: la prueba final (de integración y aceptación de usuario ) y la efectiva conversión. La prueba de integración del software aplicativo tiene por objetivo verificar que las funciones individuales de cada programa responden a las especificaciones que han sido documentadas y que los distintos programas cuando interactúan funcionan correctamente. Los componentes manuales y automatizados del proceso serán sometidos a pruebas bajo condiciones normales y exigencias especiales. Las pruebas bajo condiciones normales incluyen la verificación del cumplimiento de las especificaciones funcionales corrientes del proceso y las operaciones especiales como la inicialización de los archivos, los procedimientos de resguardo, la depuración de archivos y los


Página 205



Fecha 20/05/98


procedimientos de recuperación. Durante la prueba se podrá adoptar el enfoque de modificación o el de regresión. Las pruebas bajo situaciones especiales tienen como propósito analizar la respuesta del proceso y sistemas ante situaciones de excepción que, incluso, puedan producir su colapso. De esta forma se podrá anticipar si el proceso y sus sistemas de apoyo están en una situación servicio normal, de prevención o críticas. La última prueba y más concluyente es la de aceptación del usuario. A este fin se simulan condiciones de trabajo reales en un ambiente limitado. La prueba alcanza a todo el proceso y su aprobación es el hito que autoriza la conversión definitiva. Concluidas la prueba final y realizadas las modificaciones se verifica que estén presentes las condiciones mínimas para proceder a la conversión: personal capacitado, posiciones críticas ocupadas, infraestructura informática y de comunicaciones funcionando, documentación terminada y distribuida, muebles e insumos instalados y adecuada difusión de las fechas y ciclos de conversión. El proceso de conversión durará generalmente varias semanas y representa un importante esfuerzo que concluye efectivamente cuando se verifica que el nuevo proceso se transfiere a estado operativo de rutina. A partir de la conversión, se trabajará en la generación de un clima favorable para producir mejoras incrementales.

Los aspectos críticos a considerar para el éxito de la fase de Implantación son:  Mantener los cambios bajo control Durante la Implantación es usual que se produzcan cambios en los diseños que impactan en la programación, en la capacitación dictada y en los tiempos de finalización del proyecto. Dichos cambios deben vigilarse estrechamente a fin de determinar cuáles son relevantes o no.

 Planificar la prueba y elaborar buenos modelos La prueba no puede ser al azar porque seguramente omitirá la comprobación de aspectos importantes que cuando se produzcan pueden hacer colapsar el sistema. Las pruebas deben partir de una detallada planificación que establezca los ciclos, los distintos escenarios en que el proceso se ejecutará y los mecanismos de avance/corrección.

 Considerar el enlace con otros sistemas de información Es frecuente que no se le de la importancia debida a verificar que el nuevo sistema se integre a otros sistemas existentes.


Página 206


4.


Fecha 20/05/98


Productos principales            

Programa de trabajo de la fase de Implantación. Contratos de bienes y servicios firmados y en ejecución. Infraestructura de hardware, software de base y comunicaciones instalada y probada. Paquetes de software: unidades de programación configuradas y probadas. Desarrollos propios: unidades de programación codificadas y probadas. Plan de conversión detallado. Plan de contingencia. Software aplicativo en producción. Circuitos administrativos y procedimientos nuevos implantados. Manuales distribuidos. Personas asignadas a sus nuevos puestos. Sugerencias documentadas para mejorar el proceso.

5. Puntos de control Los principales eventos que deben controlarse para asegurar la eficacia de la fase son:  La selección del personal del equipo del proyecto.  La preparación de un detallado programa de trabajo con definición precisa de los hitos de control, productos a entregar y responsabilidades.  La ejecución de procesos de adjudicación consensuados en base a méritos que puedan ser medidos.  La redacción de contratos de bienes y servicios justos y equitativos que contemplen las probables contingencias.  La calidad del diseño de los circuitos administrativos, del software aplicativo a medida y de los desarrollos pre-programados, participando de una solución integrada que refleje la visión del nuevo proceso.  La revisión de los aspectos críticos de las estrategias de implantación de cada una de los componentes de la solución.  La confección del plan de instalación integrado que comprenda la preparación de los sitios; la instalación y verificación del hardware, software de base y comunicaciones; y la contratación de los insumos.  Las fechas y condiciones entrega de cada uno de los elementos conforme al cronograma incluido en el contrato.  La documentación detallada y clara de todas las especificaciones técnicas y funcionales de detalle.  La distribución equilibrada de los esfuerzos de programación.


Página 207



Fecha 20/05/98


 La identificación de todos los puntos de calidad que deben cumplir las unidades de programación y su verificación durante las sesiones de pruebas.  La confección de un plan detallado de conversión que respete las estrategias y enfoques aprobados.  La preparación del plan de contingencias.  La preparación de un modelo de pruebas completo y consistente con las situaciones que se verificarán en la realidad.  La ejecución de un plan de capacitación que concluya a tiempo para que el personal pueda intervenir en la prueba integral y para no retrasar la conversión.  La prueba integral del proceso respecto de sus nuevos circuitos y sistemas de información manuales y automatizados con participación efectiva y comprometida de los usuarios.


Página 208


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento Compendio

Fecha 20/05/98


III.a. Lanzamiento 1. Objetivo    

2.

Organizar el equipo de trabajo que ejecutará la fase de Implantación. Elaborar el programa de trabajo de la fase. Ajustar la estrategia de sensibilización interna. Contratar los bienes y servicios conforme a las especificaciones funcionales y técnicas determinadas en la fase de Diseño de Soluciones.

Actividades  III.a.1. Organización.  III.a.2. Contratación de bienes y servicios.

3.

Desarrollo  La primera tarea será seleccionar los miembros de la Oficina de Proyectos Provincial y del Equipo Funcional que conformarán la fuerza de trabajo responsable de la implantación bajo la dirección y coordinación del Gerente de Implantación, quién al final del proyecto ocupará un puesto jerárquico importante en la cadena del proceso rediseñado. Adicionalmente, se designará el Dueño o Gerente del Proceso como responsable máximo del nuevo proceso, quién tendrá la responsabilidad de facilitar el proceso de implantación utilizando mecanismos de sensibilización a fin de lograr la aceptación por parte de toda la Organización. Las etapas de Diseño de Soluciones e Implantación son las que requieren la mayor participación de los recursos humanos de las áreas funcionales directa e indirectamente afectadas. El patrocinio de la Alta Conducción debe quedar claramente explicitado y comunicado a toda la Organización ya que es durante la presente fase que se producirán las mayores resistencias al cambio. La selección de consultores o especialistas se hará en base a los términos de referencia que fueron confeccionados durante la actividad Planificación de la implantación.  Posteriormente, se establecerán los estándares de trabajo, a fin de lograr un desempeño eficiente y una comunicación fluida entre los miembros del equipo, principalmente, respecto de las metodologías requeridas para tareas específicas, estrategias formales e informales de comunicación, presentación de informes, calidad de los productos a entregar y mecanismos de resolución de conflictos. Durante esta etapa se recopilarán y revisarán los antecedentes generados en las fases anteriores que sirvan de insumo para el desarrollo de la presente fase. Si se detectara que existen tareas que no fueron realizadas o se ejecutaron en forma incompleta, se contemplarán dentro del plan de trabajo a confeccionar. Se revisarán las estrategias de implantación a fin de realizar los ajustes necesarios.


Página 209


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento Compendio

Fecha 20/05/98


 El paso final de la organización del equipo de trabajo será desarrollar el programa de trabajo en base al plan de implantación preparado durante la fase de Diseño de Soluciones. Los pasos se definirán detalladamente, se revisarán las habilidades necesarias del personal y se harán las asignaciones correspondientes de responsabilidad. El plan de trabajo terminado deberá ser aprobado por el Gerente de Proyectos Provincial y la Alta Conducción, a fin de habilitar el inicio de las tareas.  Durante la actividad de Lanzamiento se desarrollará la estrategia de sensibilización interna constituida, principalmente, por la difusión de mensajes claros y sencillos, que “recuerden” la visión de los nuevos procesos a implementar, los beneficios a obtener y los focos potenciales de problemas durante la fase de transición. Es durante la Implantación que saldrán a la luz las principales resistencias: ha llegado el momento de producir el efectivo cambio. De allí que es fundamental el patrocinio de la Alta Conducción a través de una intensa campaña de comunicación que explique a toda la Organización, y principalmente a las áreas funcionales afectadas, qué se va a hacer, qué se espera lograr, en qué tiempo se hará y cómo se llevará a cabo.  Por último, se contratarán las soluciones informáticas y de comunicaciones más los soportes específicos de implantación, en base a los pliegos de condiciones y especificaciones técnicas desarrollados durante la actividad Especificar la implantación.. Se ejecutarán las siguientes fases del ciclo de vida contractual: a) convocatoria de los oferentes, que comprende desde la invitación hasta la apertura de sobres según las distintas instancias que se especifiquen, b) selección del proveedor, que cubre desde la apertura de ofertas hasta la adjudicación, y c) firma de contrato, como última etapa en la que se formalizan las obligaciones y derecho de cada una de las partes. Es crítico que se definan los indicadores de cumplimiento y las medidas compensatorias en el caso de que estos sean insatisfactorios. 4.

Productos principales  Equipo de trabajo conformado y capacitado.  Programa de trabajo de la fase de Implantación.  Contratos de bienes y servicios firmados y en ejecución.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La selección del personal del equipo del proyecto.  La integración de los empleados de la Organización que conformarán el equipo funcional del proyecto.  La preparación de un detallado programa de trabajo con definición precisa de los hitos de control, productos a entregar y responsabilidades.  La ejecución de procesos de adjudicación consensuados en base a méritos que puedan ser mensurados.  La redacción de contratos justos y equitativos que contemplen las probables contingencias.

Primus


Página 210

Primus


III.a. LANZAMIENTO



III.a.1.1. Seleccionar los miembros del equipo de trabajo


III.a.1.2. Organizar el equipo de trabajo















III.a.1.4. Desarrollar la estrategia de sensibilización interna

III.a.1.3. Preparar el programa de trabajo





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento III.a.1. Organización Fecha 20/05/98 Versión Recomendado


Página 211


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento III.a.1. Organización

Fecha 20/05/98


1.Objetivo    

Seleccionar y organizar el equipo de trabajo responsable de la implantación. Revisar y ajustar las estrategias de implantación. Sensibilizar a la Organización.. Elaborar el programa de trabajo de implantación.

2. Tareas    

III.a.1.1. III.a.1.2. III.a.1.3. III.a.1.4.

Seleccionar los miembros del equipo de trabajo. Organizar el equipo de trabajo. Preparar el programa de trabajo. Desarrollar las estrategia de sensibilización interna.

3.| Desarrollo III.a.1.1. Seleccionar los miembros del equipo de trabajo La primera tarea es conformar el equipo de trabajo mediante la selección de los miembros que se ajusten a los términos de referencia que fueron elaborados al finalizar la fase de Diseño de Soluciones. Durante la Implantación se produce una transformación importante del equipo del proyecto, tanto en los puestos de dirección y coordinación como en los de ejecución. Se requiere la participación de personas que conozcan íntimamente la Organización, sean respetadas como líderes y cuyo perfil principal sea el de “ejecutores natos”, aunque disciplinados y con metodologías de trabajo. Se designará como responsable de esta fase al Gerente de Implantación, quién deberá dirigir y coordinar el proceso de transformación, bajo la dirección, supervisión y asesoramiento del Gerente de Proyectos Provincial. La persona designada será alguien de la Organización o contratada, que al final del proyecto probablemente termine ocupando un puesto jerárquico importante en la cadena del proceso rediseñado. También se designará al Dueño o Gerente del Proceso como responsable máximo del futuro proceso rediseñado, quién deberá facilitar la implantación dentro de la mínima interrupción de las actividades cotidianas y apoyar los mecanismos de sensibilización que logren la máxima aceptación de los nuevos procesos. La Alta Conducción continuará patrocinando el proyecto a cuyo efecto se incentivarán los procedimientos de sensibilización y comunicaciones efectivas. Es conveniente que quienes se desempeñaron como principales responsables técnicos del diseño de soluciones continúen como integrantes del Equipo de Especialistas de la Oficina de Proyectos Provincial. En esta fase se requiere mayor participación del personal de la Organización que trabaja en las áreas funcionales directa e indirectamente afectadas, a cuyo efecto se seleccionará el personal


Página 212



Fecha 20/05/98


que integrará el Equipo Funcional del Proyecto. El grado de participación del personal de la Organización dependerá del tipo de proceso y la cantidad y perfil de los recursos humanos disponibles. Así, mientras que algunas Organizaciones ejecutan la implantación con mayoría de personal de las áreas funcionales, en otras es necesario contratar personal experimentado externo. III.a.1.2. Organizar el equipo de trabajo La presente tarea consiste en: 

Definir las responsabilidades de los distintos integrantes del equipo de trabajo, a cuyo efecto se determinarán los resultados que se pretenden obtener al término de la presente fase.



Describir las principales características de la Organización a los nuevos integrantes y repasar la contribución del proyecto a los objetivos estratégicos que fueron establecidos en la fase de Planificación. También se explican las relaciones con otros proyectos en marcha o a ejecutarse.



Explicar las características estructurales y funcionales de las soluciones técnicas y organizacionales diseñadas.



Poner a disposición del equipo de trabajo los antecedentes recopilados y elaborados durante la fase de Diseño de Soluciones.



Entrenar al equipo de trabajo en las metodologías a las que se adhiere, las estrategias formales e informales de comunicación, la presentación de informes efectivos, la calidad de los productos a entregar y los mecanismos de resolución de conflictos.



Revisar las estrategias de implantación a fin de incorporar los ajustes necesarios.

III.a.1.3. Preparar el programa de trabajo Durante la fase de Diseño de Soluciones se elaboró un plan de trabajo que aquí debe ser ajustado para concluir en un programa de trabajo que describa las actividades a realizar, su alcance, el calendario y los productos que se pretenden obtener. Los pasos se definirán detalladamente, realizando las correspondientes asignaciones de personal en función de los perfiles de cada miembro del grupo. Al asignar las responsabilidades deberán quedar claramente establecido los productos que deben entregarse, la relación de su trabajo con otros, la calidad esperada de los resultados, las fechas límites de cumplimiento, las normas especificas de desarrollo y los hitos de control. Los datos del programa de trabajo base se ingresarán en el sistema de control del proyecto a fin de facilitar su posterior seguimiento y ajuste. El programa concluído deberá ser aprobado por la Alta Conducción, previa aprobación del Gerente de Implantación y el Gerente de Proyectos Provincial.


Página 213


III.a.1.4.


Fecha 20/05/98


Desarrollar la estrategia de sensibilización interna

Durante la fase de Implantación se llevarán a la práctica los diseños desarrollados para culminar en la puesta en marcha de la visión alcanzada durante la Planificación. Es el momento de realizar “la cirugía mayor” y en consecuencia, cuando la Organización sufrirá el impacto más importante. Aquí es dónde debe ponerse de manifiesto con mayor intensidad el apoyo de la Alta Conducción como patrocinador a través del desarrollo de una efectiva campaña de comunicación que explique a toda la Organización y principalmente a las áreas funcionales afectadas, qué se va a hacer, qué se espera lograr, en qué tiempo y cómo se llevará a cabo. Las estrategias de comunicación incluirán: difusión de videos, generación y publicación de mensajes con las ideas fuerza del cambio y fundamentalmente, el contacto personal con los “afectados” a través de reuniones periódicas. Los mensajes que se elaboren deben ser claros y expresados en un lenguaje sencillo. También será útil identificar los difusores naturales de cada área funcional que, incluso, podrán ser los futuros capacitadores.

4. Insumos principales    

5.

Resumen Ejecutivo de implantación para la Alta Conducción. Plan de trabajo de implantación. Diagrama Gantt de implantación. Términos de Referencia proyectos de implantación.

Productos principales  Equipo de trabajo conformado y capacitado.  Programa de trabajo de la fase Implantación.  Informe de estrategias de comunicación.

6.

Herramientas y técnicas      

Administración de Proyectos Manejo eficiente de reuniones. Presentaciones efectivas. Formación de equipos de trabajo. Técnicas de grupos de trabajos autodirigidos. Software de administración de proyectos.


Página 214

Primus


III.a.2.2. Seleccionar el Proveedor

III.a. LANZAMIENTO

















III.a.2.3. Firmar el contrato


III.a.2.1. Convocar los Oferentes





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento III.a.2. Contratación de bienes y servicios Fecha 20/05/98 Versión Recomendado


Página 215


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.a. Lanzamiento III.a.2. Contratación de bienes y servicios

Fecha 20/05/98


Objetivo  Gestionar la tramitación los bienes y servicios necesarios para la implantación del proceso rediseñado.  Seleccionar la oferta más conveniente.  Probar y aceptar los productos y servicios entregados.

2. Tareas  III.a.2.1. Convocar los Oferentes.  III.a.2.2. Seleccionar el Proveedor.  III.a.2.3. Firmar el contrato.

3.

Desarrollo Los procedimientos usuales de auditorías de contratos definen el ciclo de vida de éstos en: 1-Requerimientos; 2-Oferta; 3-Selección, 4-Prueba de aceptación y 5-Operación y Mantenimiento. El desarrollo de las tareas descriptas a continuación se corresponden con las etapas 2, 3 y 4. III.a.2.1. Convocar los Oferentes Durante la fase Diseño de Soluciones se desarrollaron los pliegos generales, particulares y técnicos a utilizar en la contratación de los bienes y servicios. Previo a iniciar la tramitación de la convocatoria, según los requerimientos exigidos por la normativa provincial y nacional de contrataciones, más las condiciones impuestas por el Organismo que financie, es recomendable que los agentes responsables de auditar el proceso realicen las revisiones necesarias, determinen las modificaciones y produzcan las autorizaciones que habiliten el proceso de adquisición. De acuerdo a los montos y restricciones legales o reglamentarias los procesos usuales de convocatoria son: compra directa por invitación, concurso privado nacional por invitación, concurso privado internacional por invitación, concurso público nacional y concurso público internacional. Salvo los casos de invitación, el primer requisito es publicar la convocatoria en uno o varios diarios de tiraje provincial, nacional o internacional; según el caso, y en el Boletín Oficial. Los principales datos de la convocatoria son: el objeto de la contratación, el procedimiento de consulta y adquisición de los pliegos; y los datos de la apertura de ofertas (fecha, hora y lugar).

III.a.2.2. Seleccionar el Proveedor


Página 216



Fecha 20/05/98


La presente tarea cubre el proceso de adquisición desde la apertura de la ofertas hasta la adjudicación. La apertura, como se describió en la actividad Especificación de la implantación se puede producir en una sola instancia (Sobre único), en dos (Propuesta Técnica y de Antecedentes, en sobre uno y Propuesta Económica, en sobre dos) o en tres (Propuesta de Antecedentes, en sobre uno; Propuesta Técnica en sobre dos y Propuesta Económica en sobre tres). Los principales pasos a ejecutar a partir de la apertura son:     

     

Evaluación preliminar Atención de impugnaciones presentadas por los Oferentes durante los actos de apertura Resolución de impugnaciones presentadas por los Oferentes durante el acto de apertura. Comunicaciones con los Oferentes para aclarar dudas de la presentación. Determinación de Oferentes precalificados por haber cumplido con los requerimientos mínimos exigidos en las bases de contratación y descalificación de los que no superen dichas condiciones. Evaluación de ofertas precalificadas en base a los antecedentes presentados. Evaluación de productos y servicios. Jerarquización de propuestas en base a grilla de calificaciones. Selección del o los proveedores. Adjudicación. Comunicación de la Adjudicación al Proveedor

III.a.2.3. Firmar el contrato Los principales pasos son: 

Acordar el programa de trabajo Con el conocimiento de una fecha cierta de inicio se ajustará el plan de trabajo presentado en las propuestas para convertirlo en un programa de trabajo que permita medir el efectivo cumplimiento del contrato. En el se consignará claramente el cronograma de entregas de productos y servicios. Posteriormente, se ajustará el programa de trabajo de implantación desarrollado durante la Organización. El programa de trabajo será parte del contrato a firmar y deberá especificar tanto las obligaciones del Proveedor respecto de los bienes y servicios a entregar, su calendario y calidad; como las del Comprador respecto de la infraestructura o servicios que debe poner a disposición.



Firmar el contrato Un contrato bien diseñado permite salvaguardar los derechos del Comprador. Si bien no puede garantizar la calidad del desempeño y mantenimiento de los productos y servicios contratados, se constituyen en la protección mínima legal que debe tener el Comprador para protegerse ante la aparición de un problema.

Primus

Todo buen contrato debe contener las instancias de aceptación provisoria y aceptación


Página 217



Fecha 20/05/98


definitiva de los productos. La definición de la prueba de aceptación es un tema crítico. De allí la importancia de que las especificaciones contenidas en el contrato sean claras y completas atento a que los resultados de las pruebas serán medidos contra dichas especificaciones. El contrato debe determinar las obligaciones de cada una de las partes durante la prueba de aceptación. Ante la presentación de inconvenientes que no sean resueltos por el Proveedor, las alternativas más comunes en forma aislada o combinada, que deben estar establecidas en el contrato son:      

Ejecutar la garantía de adjudicación o fiel cumplimiento. Devolver el producto Cancelar el contrato Obtener el reembolso parcial o total de la suma pagada Obtener del segundo proponente mejor calificado o de un tercero, el producto o servicio, con cargo al Proveedor adjudicado. Aceptar el producto o servicio a un costo más bajo. Por último la realización exitosa de la prueba es la condición para iniciar la cadena de pagos o cancelar, si corresponde.

4.

Insumos principales  Términos de Referencia proyectos de implantación.  Pliego de condiciones generales, particulares y técnicas .

5.

Productos principales  Contratos firmados.  Productos y servicios recibidos y probados.

6.

Herramientas y técnicas  Técnicas de negociación.  Recomendaciones de la SIGEN (Sindicatura General de la Nación) respecto de auditoría de contratos informáticos.  Estándares publicados por la Secretaría de la Función Pública.


Página 218


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño detallado Compendio

Fecha 20/05/98


III.b. Diseño detallado 1. Objetivo  Completar el diseño técnico de detalle de todos los componentes del nuevo proceso y prepararlo para el esfuerzo de conversión.  Elaborar el diseño detallado de los circuitos administrativos y sus estrategias de conversión.  Ajustar el diseño del software aplicativo desarrollado a medida y sus estrategias de conversión.  Ajustar la parametrización y configuración de las soluciones pre-programadas, y sus estrategias de conversión.  Realizar el diseño de detallado de los procesos de migración.

2. Actividades  III.b.1. Ajuste de diseño de procesos.  III.b.2. Ajuste de diseño del software aplicativo pre-programado.  III.b.3. Ajuste de diseño del software aplicativo desarrollado a medida.

3. Desarrollo  La primera etapa consistirá en transformar el nuevo proceso en circuitos administrativos y procedimientos. El trabajo se realizará en sucesivos ciclos de ajustes hasta alcanzar el nivel de detalle requerido para el diseño técnico del software aplicativo propio y de terceros. El diseño de circuitos y procedimientos incluye la estandarización de las rúbricas, que conformarán el diccionario de rúbricas de la Organización y el rediseño de los comprobantes manuales y electrónicos, en los supuestos de aplicar tecnología Work-flow o similar. Por último, y como parte de la primera etapa, se revisarán y completarán las estrategias de cambio de los circuitos administrativos y de los sistemas de apoyo que los sustentarán. La depuración de las estrategias comprenderá , entre otras tareas, revisar y ajustar:         

Las etapas y orden en que se producirán los cambios. La oportunidad de la conversión. Las integraciones y absorciones de los sistemas informáticos existentes. Los archivos que deben convertirse. La normalización y depuración de la información. La documentación de apoyo que debe estar disponible Los procedimientos de capacitación básicos. Los mecanismos de transferencia de archivos en papel a sistemas automatizados. Los nomencladores a ser definidos e inicializados.


Página 219



Fecha 20/05/98


 Posteriormente, y como etapas concurrentes, se procederá a ajustar el diseño del software aplicativo a medida y las especificaciones de detalle de las soluciones pre-programadas.  Respecto del software aplicativo desarrollado a medida, con recursos humanos propios o contratados, las etapas a cubrir son: 

      

Verificar las especificaciones técnico-funcionales que fueron definidas en la fase Diseño de soluciones a fin de adaptarlas a los requerimientos de los circuitos administrativos y procedimientos diseñados. Completar el diseño lógico y físico de las bases de datos. Diseñar las interfaces humanas de ingreso de datos y recuperación de información. Diseñar las interfaces de integración con el software aplicativo pre-programado. Diseñar las unidades de trabajo de programación. Diseñar los procesos de ejecución de seguridad y control. Ejecutar la revisión estructurada del diseño. Diseñar los procedimientos de conversión. 

     

4.

En relación al software aplicativo pre-programado las etapas a cubrir son:

Requerir la información que permita completar y ajustar el diseño técnico. Ajustar el diseño de las bases de datos. Ajustar el diseño de las interfaces de entradas y salidas. Identificar los ajustes de parametrización y programación. Diseñar los procesos de ejecución de seguridad y control. Diseñar los procedimientos de conversión.

Productos principales             

Modelado de circuitos administrativos y procedimiento. Diccionario de rúbricas. Nomenclador de comprobantes. Matriz de comprobantes anulados, modificados y nuevos. Documento con estrategias e instructivos de conversión. Diseños de pantallas. Diseños de reportes. Diseños de bases de datos. Especificaciones de procedimientos. Informes de ajustes en programación de software pre-programado. Diagramas de estructuras de programas y narraciones de software a medida. Tablas de decisiones. Diagramas de transición de estados.


Página 220



Fecha 20/05/98


 Plantillas de algoritmos.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La calidad del diseño de los circuitos administrativos, del software aplicativo a medida y de los desarrollos pre-programados, participando de una solución integrada que refleje la visión del nuevo proceso.  La revisión de los aspectos críticos de las estrategias de implantación de cada una de los componentes de la solución.


Página 221

Primus


III.b.1.3. Rediseñar los comprobantes

III.a. LANZAMIENTO




III.b.1.1. Diseñar los circuitos administrativos y procedimientos

III.b.1.2. Estandarizar las rúbricas















III.b.1.4. Ajustar las estrategias de implantación y sistemas de apoyo





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño detallado III.b.1. Ajuste de diseño de procesos Fecha 20/05/98 Versión Recomendado


Página 222


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño detallado III.b.1. Ajuste de diseño de procesos

Fecha 20/05/98


1. Objetivo  Completar el diseño técnico de detalle de los procesos.  Diseñar la estrategia de conversión de los circuitos administrativos. 2. Tareas    

III.b.1.1. III.b. 1.2. III.b.1.3. III.b.1.4.

Diseñar los circuitos administrativos y procedimientos. Estandarizar las rúbricas. Rediseñar comprobantes. Ajustar las estrategias de implantación de los circuitos y sistemas de apoyo.

3. Desarrollo III.b.1.1. Diseñar los circuitos administrativos y los procedimientos Los circuitos administrativos y los procedimientos a aplicar, son la expresión más detallada de los distintos “caminos” e “interconexiones” que plasman el modelo estructural y funcional: responden a la preguntas: quienes intervienen?, cómo se comunican? y qué hacen?. Los procedimientos expresan “cómo se realizan las tareas”. Durante esta tarea se alcanzará el nivel de detalle que requiere la implantación, cualquiera sea la estrategia que se adopte. Los circuitos se representarán mediante cursogramas que serán apoyados por una descripción narrativa que, previo ajuste, pasará a integrar los manuales de procedimientos de los usuarios.

III.b.1.2. Estandarizar las rúbricas Las rúbricas son las denominaciones de los campos que aparecen en los comprobantes, los reportes o los ingresos por pantallas. El nombre a asignar debe ser unívoco, de forma tal que cualquier persona dentro de la Organización tenga una misma interpretación. A este efecto se deberán eliminar los sinónimos (nombres distintos que significan lo mismo) y los homónimos (nombres iguales que de acuerdo al sector o persona tienen distintos significados). Cada rúbrica debe tener un nombre extendido completo y un alías o nombre resumido que tampoco debe repetirse. En este sentido es recomendable adoptar las técnicas usuales de reducción de nombres. Las rúbricas serán compiladas en un Diccionario de Rúbricas, cuya actualización será responsabilidad de un solo sector de la Organización.


Página 223



Fecha 20/05/98


III.b.1.3. Rediseñar comprobantes Al diseñar los circuitos se determinan los comprobantes que deben ser eliminados, modificados y generados. Cada comprobante debe ser sencillo de completar y de leer. Su diseño debe respetar la jerarquía de la información, su tamaño debe facilitar la manipulación y archivo; y debe prever la ubicación de mecanismos que posibiliten su captura automática (Ej.: códigos de barra, marcas, etc.) Se considerará el impacto de la tecnología al momento del diseño de los comprobantes, ya que por ejemplo si se implementa Work-flow no será necesario desarrollar algunos comprobantes internos o de utilizarse, podrán eliminarse algunas copias que en los procedimientos manuales son imprescindibles. Se desarrollará un nomenclador de comprobantes con su identificación , denominación, cantidad de copias y destinos, instancias de generación y actualización, y criterios de archivo de recuperación. Se confeccionará una matriz que establezca por cada comprobante si es nuevo, se ha modificado o ha sido eliminado por resultar inútil o haber sido absorbido por otro. También será de utilidad la confección de una matriz de correlación de comprobantes/actividades dónde se especifique en cada intersección el tratamiento que se realiza (Ej: generado, archivado, procesado).

III.b.1.4. Ajustar las estrategias de implantación de los circuitos y sistemas de apoyo Corresponde durante esta tarea, y en base a la información nueva disponible, proceder al ajuste de las estrategias de transición definidas en la actividad II.d.1. Definición de estrategias de cambio, a fin de asegurar una migración ordenada al nuevo proceso. La depuración de las estrategias incluirán: 

Las etapas y el orden en que se irán produciendo los cambios. Estas etapas se refieren tanto a la segmentación de los circuitos que permiten implantaciones en etapas independientes, como a la descentralización en áreas geográficas. Cuando las implantaciones se realicen en forma parcial y ello implique la convivencia de los circuitos antiguos con los nuevos, se establecerán procedimientos específicos para evitar conflictos y conciliar la información.



La oportunidad del cambio: en qué momento se realizará. Son inconvenientes los períodos de fuerte actividad (Ej.: cierre de balances, inscripciones, etc.) o próximos a los recesos.



Las integraciones y absorciones de los sistemas informáticos existentes.



Los procedimientos de transición de los sistemas informáticos: pruebas pilotos conversión en una fase o procesos paralelos.


con

Página 224



Fecha 20/05/98




Los archivos que deben convertirse y el origen de los datos (Ej: carga manual desde documentación fuente, carga parcial desde sistema anterior, relevamiento, etc.).



La normalización y depuración de información.



La documentación de apoyo que debe estar disponible.



Los procedimientos para entrenamiento. Es usual que se entrene a un grupo primario que luego irán formando otros grupos de apoyo.

Los criterios comunes en cualquier conversión de circuitos son: 

Agrupar los distintos cambios a realizar en unidades de trabajo que puedan limitarse a uno o varios sectores organizativos a fin de realizar pruebas pilotos que luego se repliquen en toda la Organización.



Avanzar a la etapa siguiente solamente cuando esté consolidada la anterior (en los aspectos críticos).



Relevar y capturar nueva información solamente cuando se hayan probado los circuitos administrativos e informáticos que puedan mantenerla actualizada.

Las preguntas usuales que ayudan a establecer los procedimientos son: 

¿Qué datos históricos que hoy están residentes en archivos de papel se transferirán al nuevo sistema? No es necesario que toda la información histórica sea cargada en el nuevo sistema. Se debe elegir aquella que sea crítica y en el supuesto de que se tenga que grabar información histórica el criterio correcto es cargar desde lo más moderno hacia atrás.



¿Cómo irá absorbiendo el nuevo sistema la información que hoy está en papel y probablemente diseminada? Existen dos criterios básicos con una variedad de soluciones intermedias. Uno es realizar una carga inicial masiva que exige medir muy bien el esfuerzo ya que requerirá una participación de personal importante. Otra es ir cargando la información a medida que se presenta un evento que exige su actualización. Un ejemplo de procedimiento combinado es el utilizado para automatizar el legajo de los agentes que trabajan en las áreas educativas. La situación usual es la presencia de archivos voluminosos en dónde conviven legajos del personal que está activo con otros pertenecientes a los que no lo están, pero que en cualquier momento pueden reingresar en el sistema. El procedimiento usual es cargar los datos seleccionados de los legajos que se van moviendo porque reciben alguna actualización y en los momentos libres o mediante un grupo separado, se cargan los legajos que no han recibido movimiento desde los más modernos a los más antiguos. A medida que se carga el legajo se procede a la codificación de sus datos, a su nueva identificación y se lo separa físicamente de aquellos que están pendientes de ser cargados.


Página 225





Fecha 20/05/98


¿ Cuál será el procedimiento para depurar la información previo a cargarla o luego de transferida, si se migra de un sistema automatizado a otro? Las depuraciones se pueden ir realizando en los momentos de carga o bien mediante censos o relevamientos masivos. Existen errores de datos que podrán ser detectados y corregidos en forma automática. Y en otros casos solamente se podrán aislar, para luego ser corregidos en forma manual. Si la casuística de errores es muy compleja, otro criterio será transferir el sistema con los datos en el estado en que están para luego irlos depurando a medida que aparezcan. Esta situación debe ser comunicada en forma clara a todos los usuarios a fin de no imputarle al nuevo proceso errores que no le corresponden.



¿ Qué nomencladores deben ser generados? Determinar la información que deberá ser codificada y prever a qué área se le asignará la responsabilidad de generar y mantener los nomencladores.



¿Si la Organización está dispersa geográficamente, es posible transformar una región o Delegación que sirva de modelo para que luego se replique en toda la Provincia? En ocasiones por la dimensión de la Organización o por la dificultad de entrenar masivamente el personal , se hará necesario segmentar las implantaciones por zonas. Deberá considerarse como se mantendrán dos circuitos paralelos: los reformados y los antiguos.



¿ Si se convierte un modelo centralizado a uno descentralizado, se hará en una o varias fases? Si bien no existen “recetas” es conveniente que en Organizaciones con una fuerte cultura de procesos manuales centrales se descentralice en etapas.

4.


5.

Esquema de actividades y eventos de los procesos rediseñados. Diagrama de dependencia entre los procesos. Diagramas de entidad-relación. Modelo de datos.


Modelado de circuitos administrativos rediseñados. Diccionario de rúbricas. Nomenclador de comprobantes. Matriz de comprobantes anulados, modificados y nuevos. Listado de procedimientos.


Página 226



Fecha 20/05/98


 Documento con estrategias e instructivos de conversión.

6.


Técnicas de diseño de comprobantes. Herramientas de modelado de cursogramas. Productos de software para modelado de cursogramas (Ej.: Optima!, Orfeo, Q+Isodoc). Herramientas CASE (Ej.: System Architect, Designor, Omnis7, Erwin, Silverrun).


Página 227

Primus


III.b.2.4. Determinar los ajustes de parametrización y programación

III.b.2.3. Ajustar el diseño de las entradas y salidas

III.b.2.5. Definir la estrategia de implantación del SW aplicattivo

III.a. LANZAMIENTO







III.d. CONFIGURACION DE PAQUETES Y PROGRAMACION


III.b.3. Ajuste de diseño del SW aplicativo a medida III.b. DISEÑO DETALLADO









III.b.2. Ajuste de diseño de software aplicativo preprogramado

III.b.2.1. Completar el diseño técnico

III.b.2.2. Ajustar el diseño de las bases de datos





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño III.b.2. Ajuste de diseño detallado del software aplicativo pre-programado Fecha 20/05/98 Versión Recomendado

III.b.2. Ajuste de diseño del software aplicativo pre-programado

Página 228


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño III.b.2. Ajuste de diseño detallado del software aplicativo pre-programado

Fecha 20/05/98


Objetivo  Ajustar las especificaciones técnico-funcionales que sirvieron de base para la contratación del software aplicativo.  Ajustar el diseño detallado de la solución propuesta a las necesidades de la Organización.

2.

Tareas     

3.

III.b.2.1. III.b.2.2. III.b.2.3. III.b.2.4. III.b.2.5.

Completar el diseño técnico. Ajustar el diseño de la base de datos. Ajustar el diseño de las entradas y salidas. Determinar los ajustes de parametrización y programación. Definir la estrategia de implantación del software aplicativo.

Desarrollo III.b.2.1. Completar el diseño técnico El Proveedor verificará las especificaciones técnico-funcionales que sirvieron de base para la presentación de la propuesta. Luego completará los datos faltantes que no fueron detallados a fin de determinar los ajustes de detalle de la solución pre-programada. En base a los circuitos administrativos rediseñados se realizarán entrevistas para relevar información que permita ajustar las definiciones de:           

Las pantallas de ingreso de datos. Los reportes por video e impresora. Las consultas. Las funciones y subfunciones. Los algoritmos de cálculos de procedimientos específicos. El esquema de seguridad con las distintas combinaciones de accesos por niveles de usuarios y funciones. El esquema de auditoría. El mecanismo de manejo de errores. El esfuerzo necesario para poner en marcha el sistema. Los ajustes necesarios por los mecanismos de comunicaciones que se utilizarán. El impacto en el diseño respecto de las estrategias de implantación seleccionadas.

III.b.2.2. Ajustar el diseño de las bases de datos Se refinará el diseño físico de las bases de datos y sus vistas lógicas para adaptarse a los requerimientos detectados en la tarea anterior. Las modificaciones más comunes pueden ser de tablas (o archivos) que se agregan o suprimen ;


Página 229



Fecha 20/05/98


o modificaciones a campos de las tablas existentes en el sistema. Las modificaciones de campos podrán ser: cambios de imagen (tipo y longitud del campo); validaciones automáticas (campos cuyos contenidos deben respetar determinados parámetros) ; campos que se anulan; campos que se agregan; etc. III.b.2.3. Ajustar el diseño de las entradas y salidas Existen en el mercado soluciones de software aplicativo que contienen herramientas que automatizan los procesos de generación y modificación de diálogos, consultas y reportes. El Proveedor realizará todos los ajustes o bien, desarrollará los casos testigos que el Comprador haya seleccionado. En este último supuesto, es recomendable que el personal de la Organización que asumirá la responsabilidad del mantenimiento del sistema participe en todo el proceso de adaptación. Esta tarea también comprende el ajuste de las interfaces automáticas entre los subsistemas o módulos provistos en la solución del Proveedor o de éstos respecto de los sistemas existentes en la Organización. Las interconexiones con los sistemas, cuando son responsabilidad del Proveedor, se pueden realizar a través de: modificaciones del código del software aplicativo provisto, extensiones de interfaces de programación (Ej: API – Aplication Programming Interfaces) o mediante capacidades de integración (Ej: acceso y actualización de archivos por facilidades ODBC o RPC). III.b.2.4. Determinar los ajustes de parametrización y programación Se determinarán los ajustes requeridos en los módulos de programación para adaptarse a los requerimientos funcionales del Organismo. Al igual que para las interfaces, existen soluciones que contienen herramientas que permiten definir reglas de funcionamiento, facilitando la parametrización de la solución y brindando la máxima autonomía al Comprador. En estos casos, y dependiendo de lo previsto en la contratación, se puede establecer que el Proveedor realice la totalidad de los ajustes o solamente la de los casos de mayor complejidad.

III.b.2.5. Definir la estrategia de implantación del software aplicativo La definición de la estrategia de conversión del software aplicativo tiene que estar integrada a las estrategias globales de cambio definidas en la fase de Diseño de Soluciones y la de implantación de circuitos administrativos establecida en la actividad anterior. No obstante; es probable que algunas facilidades del software aplicativo, modifiquen las estrategias establecidas. Otros aspectos críticos a definir serán la absorción de los procesos manuales y la carga inicial.


Página 230


4.


Modelado de circuitos administrativos rediseñados. Diccionario de rúbricas. Nomenclador de comprobantes. Listado de procedimientos. Pliego de condiciones generales, particulares y técnicas . Contrato firmado.


6.

Fecha 20/05/98

Insumos principales      

5.


Diseños de pantallas. Diseños de reportes. Diseños de bases de datos. Especificaciones de procedimientos. Informes de ajustes de programación.

Herramientas y técnicas  Técnicas de relevamiento.  Herramientas de modelado de datos.  Productos de software para modelados de pantalla, generación de reportes y consultas , y modificación de reglas de funcionamiento.


Página 231

Primus


III.b.3.5. Di señar los procesos de seguri dad, privacidad y control

III.b.3.4. Diseñar las entradas y salidas

III.b.3.6. Diseñar las unidades de programación

III.a. LANZAMIENTO


















III.b.3. Ajuste de diseño de software aplicativo a medida

III.b.3.1. Completar las especificaciones técnico-funcionales

III.b.3.3. Diseñar las bases de datos

III.b.3.2. Diseñar las interfases con el SW aplicativo pre-programado





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño III.b.3. Ajuste de detallado diseño del software aplicativo a medida Fecha 20/05/98 Versión Recomendado

III.b.3. Ajuste de diseño del software aplicativo a medida

Página 232


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.b. Diseño III.b.3. Ajuste de detallado diseño del software aplicativo a medida

Fecha 20/05/98


Objetivo  Diseñar las especificaciones técnico-funcionales de detalle de los desarrollos a medida.  Diseñar las interfaces para que los sistemas existentes puedan integrarse con el software aplicativo pre-programado que se haya contratado.  Diseñar los procesos para migración de datos del sistema vigente al nuevo sistema preprogramado o programado a medida.

2. Tareas      

3.

III.b.3.1. III.b.3.2. III.b.3.3. III.b.3.4. III.b.3.5. III.b.3.6.

Completar las especificaciones técnico-funcionales. Diseñar las interfaces de integración con el software aplicativo pre-programado. Diseñar las base de datos. Diseñar las entradas y salidas. Diseñar los procesos de seguridad, privacidad y control. Diseñar las unidades de programación.

Desarrollo III.b.3.1. Completar las especificaciones técnico-funcionales Se verificarán las especificaciones técnico-funcionales explicitadas en la fase Diseño de Soluciones y se ajustarán o completarán para adaptarlas a los requerimientos de los circuitos administrativos diseñados. Se verificará que estén contemplados todos los requerimientos de los usuarios del proceso y que funcionalmente el sistema informático sirva de soporte a los objetivos estratégicos de la Organización. A continuación se presenta una guía de revisión:        

¿ Se han definido todas las funciones y subfunciones del sistema de información? ¿Se ha identificado en todo su alcance el nivel de complementariedad que el software preprogramado tiene con las soluciones desarrolladas a medida? ¿ Están identificados los requisitos de performance, de integridad, de seguridad y de control? ¿ Están definidas todas las normas de calidad que el software debe respetar? ¿ Están identificados todos los datos que el sistema debe administrar? ¿ Están definidos los diálogos del usuario con el sistema (interfaces de entrada)? ¿ Están definidos los reportes para los distintos niveles de decisión? ¿ Están definidos los criterios de consulta?


Página 233



Fecha 20/05/98


III.b.3.2. Diseñar las interfaces de integración con el software aplicativo pre-programado En esta instancia se determinarán los ajustes de diseño que la Organización debe realizar a los sistemas a medida propios vigentes o a desarrollar para que se integren con las soluciones contratadas. Se incluye el diseño de interfaces a elaborar para migrar datos del sistema o subsistema que será absorbido , o bien, para intercambiar información. Los principales ajustes que se producirán serán a nivel de definiciones de datos, diseños de bases de datos y funciones de aplicaciones.

III.b.3.3. Diseñar las bases de datos Se especificará la imagen de los datos (tipo y longitud), sus vistas lógicas y el diseño físico de los archivos ( tablas). Se diseñarán los archivos transitorios requeridos para intercambios de información con otros sistemas y para el proceso de conversión. El diseño debe asegurar que las bases de datos nuevas se integren con las existentes. De la comparación de las bases de datos rediseñadas y las existentes surgirán los archivos que se generarán, suprimirán o modificarán. III.b.3.4. Diseñar las entradas y salidas Se diseñarán los diálogos, manejos de mensajes de errores, consultas, reportes e informes. Existen en el mercado soluciones de software aplicativo que contienen herramientas que automatizan los procesos de generación y modificación de diálogos, consultas y reportes. Esta tarea también comprende el ajuste de las interfaces automáticas entre los subsistemas a programar o respecto de los sistemas existentes en la Organización.

III.b.3.5. Diseñar los procesos de ejecución de seguridad, privacidad y control La presente tarea deberá asegurar que estén identificados y diseñados los procesos que:     

Minimicen el riesgo de discontinuidad de los sistemas y pérdida de datos. Que eviten total o parcialmente el acceso al sistema de personas no autorizadas. Que agilicen los procesos de recuperación. Que monitoreen permanentemente las funciones críticas. Que faciliten la trazabilidad del sistema.


Página 234



Fecha 20/05/98


III.b.3.6. Diseñar las unidades de programación Primero se identifican las distintas funciones del sistema que brindará soporte al proceso rediseñado, clasificándolas por lugar de residencia (centralizada o distribuida) y por nivel de respuesta (en tiempo real o diferida). Posteriormente se diferenciarán las funciones comunes o utilitarias de las específicas. La documentación usual que respalda una unidad de programación es la siguiente:      

Denominación del programa Código de identificación Programas que invoca Programas en que es invocado Archivos de participan: denominación lógica y física y tipo de acceso. Detalle de diálogos: plantillas y relación cruzada de campos de consulta o exposición con zonas transitorias de memoria y campos de archivos.  Detalle de reportes: plantillas y relación cruzada de campos de consulta o exposición con zonas transitorias de memoria y campos de archivos.  Diagrama jerárquico de los módulos y procedimientos del programa (Ej: IPO - insumoproceso-salida).  Explicación de las reglas de cada módulo (Ej: seudo-castellano), Los programas a desarrollar deben incluir los procesos de prueba y conversión. Los módulos y programas se combinarán en unidades de trabajo de programación que produzca resultados que se puedan verificar en períodos no superiores a los veinte días. La unidades de trabajo de programación se asignarán, junto con la documentación producida a los distintos programadores de acuerdo a su especialidad y experiencia. Por ejemplo: se puede conformar una unidad de programación que agrupe los reportes de baja complejidad que se asignarán a un programador aprendiz o iniciado.

4.

Insumos principales         

Informe de especificaciones técnico-funcionales. Diagrama de contexto. Diagrama de flujo de datos. Diagramas de entidad-relación. Modelo de datos. Diagramas de flujos de objetos (Análisis orientado a objetos). Modelado de circuitos administrativos rediseñados. Diccionario de rúbricas. Nomenclador de comprobantes.


Página 235


5.

Fecha 20/05/98


Productos principales        

6.


Diseños de pantallas. Diseños de reportes. Diseños de bases de datos. Diagramas de estructuras de programas y narraciones. Tablas de decisiones. Diagramas de transición de estados. Especificación de métodos (Diseño orientado a objetos) Plantillas de algoritmos.


Técnicas de relevamiento. Herramientas de modelado de datos. Metodologías de análisis y diseño estructurados (Ej.: Gane-Sarson, Yourdon, etc.) Metodologías de análisis y diseño orientado a objetos (Ej.: Martin-Odell, Booch’94, OMT/Rumbaugh, Coad/Yourdon, Shlaer/Mellor, IDEF3, etc.).  Diagramas de entidad-relación (Ej.: IDEF1X).  Herramientas CASE (Ej.: System Architect, Designor, Omnis7, Erwin, Silverrun).  Productos de software para modelado de pantalla y generación de reportes.


Página 236


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de Compendio hardware, comunicaciones y software de base

Fecha 20/05/98


III.c. Instalación de hardware, comunicaciones y software de base 1.

Objetivo  Preparar los sitios en donde se instalará el equipamiento y las facilidades de comunicaciones.  Instalar y probar la infraestructura de hardware, software de base y comunicaciones que brindará soporte a los sistemas aplicativos.  Identificar y adquirir los muebles y suministros necesarios para poner en marcha y operar el sistema.

2. Actividades Comprende las siguientes actividades:  III.c.1. Instalación de hardware y comunicaciones.  III.c.2. Instalación de software de base. 3. Desarrollo  Se determinarán los requisitos de los sitios en dónde se instalará el hardware principal, periféricos, equipamiento de comunicaciones y vínculos. Las necesidades de ampliación, construcción, acondicionamiento y servicios de apoyo estarán originadas en la incorporación de nuevos equipos o la ampliación y/o traslado de los existentes. El estudio de los sitios se realizará a nivel de las instalaciones del hardware principal de procesamiento y comunicaciones - Centros de Servicio Informáticos - como así también respecto de las oficinas en dónde se instalarán los puestos de trabajo de los usuarios. Los requerimientos de espacio y ambientación pueden ser costosos e implicar trabajos importantes. El trabajo debe concluir “justo a tiempo” por lo que se requerirá la confección de cuidadosos cronogramas. Si se produjeran retrasos en la instalación de los equipos se demorará la puesta en marcha del nuevo proceso. Por otra parte, de estar listo demasiado pronto puede implicar nuevos costos de mantenimiento y arrendamiento innecesarios. Conjuntamente con la preparación de los lugares deberán determinarse los requerimientos de muebles. Los planes de entrega del mobiliario deberán coordinarse con la preparación de los lugares.

 Concluida y aprobada la preparación de los sitios, se procederá a recepcionar e instalar equipamiento, bajo las condiciones establecidas en el contrato. El equipo instalado será puesto en funcionamiento por el Proveedor. Esta instancia, que verificará y formalizará mediante la generación del Acta de Aceptación Provisoria, marca comienzo del período de prueba, durante el cuál se verificará la ausencia de fallas y cumplimiento de los indicadores de calidad y performance requeridos.


Página 237

el se el el


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de Compendio hardware, comunicaciones y software de base

Fecha 20/05/98


El período de prueba será lo suficientemente extenso para probar el funcionamiento integrado del equipamiento junto con el software de base y las comunicaciones. Usualmente, en forma concomitante, y siguiendo igual procedimiento se procederá a recepcionar, instalar y probar las facilidades de comunicaciones.  La instalación del software de base – que no haya sido preinstalado en el equipamiento – se realizará una vez verificada la configuración del hardware y comunicaciones que lo sustentará. Al igual que con el hardware y comunicaciones se procederá a la recepción provisoria a fin de ser sometido al período de prueba.  Concluido el período de prueba de los distintos elementos instalados se procederá a realizar una prueba integrada con la presencia de los distintos Proveedores. Si el Proveedor es único, esta instancia se facilitará.Pero si existen distintos Proveedores será conveniente que de presentarse problemas estén todos los responsables a fin de evitar dilaciones por “intercambio de culpas”.  Concluidas la pruebas en forma satisfactoria o resueltas las fallas detectadas dentro de los períodos establecidos en el contrato se procederá a formalizar la recepción definitiva. En el supuesto de no cumplirse las condiciones estipuladas se ejecutarán los mecanismos de resarcimiento establecidos en el contrato.  Concomitantemente con las instalaciones se identificarán y contratarán los insumos (Ej: papel, cintas, mobiliarios, etc.) que sean necesarios para la puesta en marcha de la instalación. Los insumos se inventariarán conforme a las normas de administración de bienes de consumo previstas en la Organización. 4. Productos principales     

Hardware instalado y probado. Comunicaciones instaladas y probadas. Software de base instalado y probado. Insumos adquiridos, inventariados e instalados. Actas de aceptación provisoria y definitiva.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La confección del plan de instalación integrado que comprenda la preparación de los sitios; la instalación y verificación del hardware, software de base y comunicaciones; y la contratación de los insumos.  Las fechas y condiciones entrega de cada uno de los elementos conforme al cronograma incluido en el contrato.  La confección de los checklist de prueba y su seguimiento.  La ejecución de las cláusulas previstas en caso de incumplimiento.


Página 238

Primus


III.c.1.3. Instalar y probrar las facilidades de comunicaciones

III.c.1.2. Instalar y probar el hardware

III.a. LANZAMIENTO



















III.c.1.1. Preparar el sitio

III.c.1.4. Identificar y contratar insumos





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de III.c.1. Instalación de hardware, hardware y comunicaciones y comunicaciones software de base Fecha 20/05/98 Versión Recomendado


Página 239


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de III.c.1. Instalación de hardware, hardware y comunicaciones y comunicaciones software de base

Fecha 20/05/98


Objetivo  Preparar los sitios o lugares en donde se instalará el equipamiento y las facilidades de comunicaciones.  Instalar, probar y ajustar el equipamiento y las facilidades de comunicaciones.

2.


3.

III.c.1.1. III.c.1.2. III.c.1.3. III.c.1.4.

Preparar el sitio e instalaciones. Instalar y probar el hardware. Instalar y probar las facilidades de comunicaciones. Identificar y contratar los insumos.

Desarrollo III.c.1.1. Preparar el sitio e instalaciones La incorporación de nuevo hardware y/o el traslado o ampliación del existente requerirá una prolija planificación de los requerimientos de construcción o modificación de los lugares e instalaciones a afectar. Identificados los requerimientos se procederá a realizar las obras con recursos propios o contratados. Una vez que se disponga del inventario de los requerimientos y tareas necesarias, se confeccionarán planos en dónde se especifique la distribución de los equipos principales, los puestos de trabajo, los tendidos de cableados dentro y fuera del edificio, los centros de distribución de comunicaciones y las bocas de conexión. La cantidad de trabajo que implica la preparación del sitio puede ser muy grande. Por lo tanto, se requiere un cronograma ajustado. Aunque usualmente este trabajo será realizado con recursos de terceros, vigilar su progreso es responsabilidad del Gerente de Implantación. Un retraso en la adecuación de los lugares puede demorar la instalación del equipamiento, y consecuentemente el proyecto. Por otra parte, terminarlos antes de tiempo pueden implicar costos adicionales de mantenimiento y arrendamientos. A continuación se presenta una guía de revisión de aspectos mínimos a considerar en la planificación de la preparación de sitios e instalaciones: 

¿Se disponen de las medidas y los pesos del equipamiento a incorporar a fin de planificar su ubicación y determinar si se deberán producir mudanzas o construcciones que refuercen los sitios de instalación?  ¿ Se requieren condiciones especiales en la instalación de energía que no estén contempladas dentro del edificio (Ej: puesta a tierra, instalación independiente del circuito eléctrico para el equipamiento informático y de comunicaciones, etc.).?


Página 240


        


Fecha 20/05/98


¿ Se requieren condiciones especiales de refrigeración que no existen en el edificio? ¿Se han contemplado los aspectos de seguridad en los lugares en dónde se encuentra la instalación principal y los accesos críticos? ¿ Se han considerado los espacios de mantenimiento de los equipos instalados? ¿Existen ductos que puedan ser aprovechados para las comunicaciones o se requerirán instalaciones especiales? ¿ La vinculación entre los edificios cercanos exigen la tramitación de permisos especiales (Ej: municipalidad)? ¿ Es necesario prever espacios para un obrador durante las construcciones? ¿ Es necesario contratar muebles? ¿ Es necesario alquilar nuevas instalaciones? ¿ Cuál será el impacto de las modificaciones y construcciones en la gente que está trabajando en las áreas afectadas? ¿ Es necesario trasladarla?

Algunas de las tareas mencionadas estarán a cargo del Proveedor del equipamiento si así se contrató (Ej: adquisiciones llave en mano); no obstante, si bien su ejecución no será responsabilidad del Comprador deben estar claramente identificadas para hacer una adecuada revisión y evitar que su demora o falta de realización retrasen el proyecto.

III.c.1.2. Instalar y probar el hardware El Proveedor deberá entregar el equipamiento en los lugares y bajo las condiciones especificadas en el contrato. Es importante que, previo a la instalación del hardware, se constate la correcta culminación de las obligaciones que estaban a cargo de la Organización, bajo la responsabilidad directa del Gerente del Proyecto. Debe verificarse cada entrega con las obligaciones contenidas en el contrato y dejar constancia en los remitos o Actas de Aceptación Provisoria de cualquier falla o faltante que se pueda detectar al momento de la recepción, las que serán comunicadas fehacientemente al Proveedor para que las resuelva en una fecha determinada. Cada equipo entregado debe ser instalado y puesto en funcionamiento por el Proveedor, que es el responsable de asegurar que funcione de acuerdo con las especificaciones. El Gerente del Implantación extenderá el Acta de Aceptación Provisoria que indica el comienzo del período de prueba, usualmente por un mínimo de 30 días, durante el cuál se verificará el correcto funcionamiento de los bienes provistos. La aceptación provisoria otorgará un período durante el cuál se pueda comprobar la calidad y desempeño del producto. Si se detectan problemas podrán ser solucionados por el Proveedor en un tiempo prudencial, de lo contrario se aplicarán las medidas de resarcimiento de daños y perjuicios establecidas en el contrato. La verificación del funcionamiento deberá hacerse por cada elemento en particular e integrado en el conjunto que es responsabilidad del mismo Proveedor. Se confeccionará un check-list que determine todos los aspectos a ser probados y su orden, a fin de olvidar ningún ítem.


Página 241



Fecha 20/05/98


Los bienes que usualmente están comprendidos dentro de la categoría de hardware son:        

Procesadores centrales (Ej: servidores de datos y aplicaciones juntos o separados). Impresoras masivas (Ej: impresoras láser, impresoras de impacto, etc.). Puestos de trabajo ( Ej.: terminales dumbs, PC’s, etc.). Impresoras de escritorio personales o para grupos de trabajo (Ej: láser de escritorio, inyección de tinta, etc.). Periféricos para soporte de energía (Ej.: Sistemas de energía ininterrumpidos (UPS), reguladores de tensión, motogeneradores, etc.). Scanners. Kits de multimedia. Unidad externas de almacenamiento (Ej: unidades de cartdriges, unidades de cintas, etc.).

III.c.1.3. Instalar y probar las facilidades de comunicaciones Las facilidades de comunicaciones estarán compuestas por equipamiento para administrar comunicaciones y vínculos. El contrato puede prever que el Proveedor entregue los vínculos en propiedad, los alquile o que, simplemente brinde un servicio de transporte de datos y/o voz en calidad de carrier (Ej.: satélite V-SAT, FOM-Fibra Optica Metropolitana, etc.). Una lista tentativa de elementos y servicios incluidos en las facilidades de comunicaciones son: 

Provisión e instalación de cableados horizontales simples o bajo las normas de cableados estructurado.



Provisión e instalación de cableados de montantes óptica).



Provisión e instalación de salas de cableado.



Provisión e instalación de armarios de distribución de señales.



Provisión e instalación de equipamiento de distribución de señales (Ej: procesadores de comunicaciones, procesadores de acceso remoto, hubs, routers, gateways, switchers, etc.).



Provisión e instalación de facilidades para conectar edificios (Ej: antenas satelitales, fibra óptica, radio-enlaces, micro-ondas, etc.).



Provisión de servicio de carrier (Ej: banda satelital, canales virtuales privados de fibra óptica, líneas dedicadas telefónicas, etc.)

verticales en edificios (Ej: fibra

III.c.1.4. Identificar y contratar los insumos Se identificarán los insumos que son necesarios para la puesta en marcha y funcionamiento del equipamiento durante un tiempo mínimo. Los insumos pueden haber sido contemplados dentro del contrato de equipamiento o bien deberán ser tramitados por separado.


Página 242


4.


Resumen de los requisitos del sitio. Contrato firmado. Términos de Referencia proyectos de implantación. Pliego de condiciones generales, particulares y técnicas .


6.

Fecha 20/05/98


5.


Hardware instalado y probado. Comunicaciones instaladas y probadas Insumos adquiridos e inventariados. Actas de aceptación provisoria y definitiva.


Técnicas de relevamiento Técnicas de prueba de hardware y comuniaciones Técnicas de administración de proyectos. Técnicas de negociación. Recomendaciones de la SIGEN (Sindicatura General de la Nación) respecto de auditoría de contratos informáticos.  Estándares publicados por la Secretaría de la Función Pública.


Página 243

Primus


III.a. LANZAMIENTO


















III.c.2.2. Verificar el funcionamiento integrado de la instalación





III.c.2.1. Instalar, probar y ajustar el software de base

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de III.c.2. Instalación de hardware, software de base comunicaciones y software de base Fecha 20/05/98 Versión Recomendado


Página 244


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de III.c.2. Instalación de hardware, software de base comunicaciones y software de base

Fecha 20/05/98


1. Objetivo  Instalar, probar y ajustar el software de base.  Realizar la prueba integrada del equipamiento, software de base y comunicaciones.

2. Tareas  III.c.2.1. Instalar, probar y ajustar el software de base.  III.c.2.2. Verificar el funcionamiento integrado de la instalación.

3. Desarrollo III.c.2.1. Instalar, probar y ajustar el software de base Probado el equipamiento, el Proveedor instalará el software de base que estará integrado principalmente por:    

Sistema Operativo de los equipos centrales. Sistema Operativo de los puestos de trabajo inteligentes. Sistemas de comunicaciones. Sistemas de administración de redes de comunicaciones (NOS – Network Operating Systems)  Motores de bases de datos.  Sistemas de Protección (Ej.: antivirus)  Sistemas de administración de almacenamiento (Network Storage Management) Instalado y probado el software de base, se parametrizará la instalación y ejecutarán los ajustes que puedan realizarse independientemente de los sistemas aplicativos. No obstante; el rendimiento de algunos elementos como los motores de bases de datos, solo podrá ser optimizado cuando se pruebe el software aplicativo. Debe verificarse cada entrega con las obligaciones contenidas en el contrato y dejar constancia en los remitos o Actas de Aceptación Provisoria de cualquier falla o faltante, las que serán comunicadas fehacientemente al Proveedor para que las resuelva en una fecha determinada. El Gerente de Implantación extenderá el Acta de Aceptación Provisoria que indica el comienzo del período de prueba, usualmente por un mínimo de 30 días, durante el cuál se verificará el correcto funcionamiento del producto. La aceptación provisoria otorgará un período durante el cuál se pueda comprobar la calidad y desempeño del producto. Si se detectan problemas podrán ser solucionados por el Proveedor en un tiempo prudencial, de lo contrario se aplicarán las medidas de resarcimiento de daños y perjuicios establecidas en el contrato. La verificación del funcionamiento deberá hacerse por cada elemento en particular e integrado


Página 245


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.c. Instalación de III.c.2. Instalación de hardware, software de base comunicaciones y software de base

Fecha 20/05/98


en el conjunto que es responsabilidad del mismo Proveedor. Se confeccionará un check-list que determine todos los aspectos a ser probados y su orden, a fin de olvidar ningún ítem.

III.c.2.2. Verificar el funcionamiento integrado de la instalación Con la presencia de todos los proveedores se realizará una prueba integrada de las comunicaciones y el equipamiento bajo el software instalado. Si el Proveedor es único esta instancia se facilitará, pero si existen distintos Proveedores será conveniente que de presentarse problemas estén todos los responsables a fin de evitar dilaciones por “intercambio de culpas”.

4.

Insumos principales  Contrato firmado.  Términos de Referencia proyectos de implantación.  Pliego de condiciones generales, particulares y técnicas .

5.

Productos principales  Software instalado y probado.  Actas de aceptación provisoria y definitiva.

6.


Técnicas de relevamiento Técnicas de prueba de software. Técnicas de administración de proyectos. Técnicas de negociación. Recomendaciones de la SIGEN (Sindicatura General de la Nación) respecto de auditoría de contratos informáticos.  Estándares publicados por la Secretaría de la Función Pública.


Página 246


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Fecha III.d. Configuración de Compendio 20/05/98 paquetes y programación


III.d. Configuración de paquetes y programación 1.

Objetivo  Configurar, parametrizar y modificar las estructuras y funciones del software aplicativo preprogramado conforme a las especificaciones del diseño técnico de detalle.  Codificar las unidades de trabajo de programación correspondientes a los desarrollos a medida en base a las especificaciones del diseño técnico de detalle.  Probar y depurar las unidades de programación de los desarrollos a medida y paquetes de terceros.

2. Actividades  III.d.1. Configuración del software aplicativo pre-programado.  III.d.2. Programación a medida. 3.

Desarrollo  La conversión de las especificaciones del diseño técnico en módulos de software aplicativo ejecutables es aplicable tanto a los paquetes pre-programados, que deben ser adaptados, como a los desarrollos a medida, que deben ser codificados en su totalidad. La mayoría de los pasos son comunes a ambas soluciones. La principal diferencia se produce en la ejecución del diseño: mientras que los paquetes pre-programados se pueden adaptar mediante parametrizaciones y reglas de funcionamiento en los desarrollos propios existirá un fuerte trabajo de programación.  La primera tarea común a ambas soluciones es la preparación del ambiente de programación. Las soluciones pre-programadas pueden exigir menos recursos de equipos y gente que los desarrollos a medida, e incluso pueden ser absorbidas totalmente por el Proveedor .  El software pre-programado debe contemplar mecanismos flexibles que permitan ajustar la solución contratada a las especificaciones de detalle del diseño técnico. Los ajustes menores que cubren el mayor porcentaje de la solución a proveer podrán realizarse mediante asignación de parámetros y reglas de funcionamiento. Para situaciones no contempladas se recurrirá a codificación, utilizando las alternativas de modificar o agregar código, extender el paquete mediante la utilización de interfaces de programación de aplicaciones (Aplication Programming Interfaces – API) o integrar el paquete con otro software aplicativo.  En los casos de desarrollos a medida se dividirá el trabajo de codificación en unidades de programación que puedan asignarse a distintas personas y verificarse independientemente. Cada unidad de programación se revisará en su lógica y sintaxis previo a ejecutar la prueba unitaria del módulo.  Tanto en los paquetes como en los desarrollos a medida deberán contemplarse módulos que permitan la automatización de: los eventos del proceso en los casos normales y de excepción, los procesos de migración, la generación de los datos de prueba, los eventos de intercambio de


Página 247


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad Fecha III.d. Configuración de Compendio 20/05/98 paquetes y programación


información entre los distintos sistemas aplicativos y los procesos de integración con funciones del sistema operativo (Ej.: resguardo, reconstrucción de índices, etc.).  Por último se preparará el ambiente de prueba separado del de producción a fin de verificar la lógica de cada módulo y realizar las correcciones necesarias. En esta instancia las pruebas de integración entre los módulos son mínimas, difiriéndose para el segmento de Prueba final.

4.

Productos principales  Paquetes de software: unidades de programación configuradas y probadas.  Desarrollos propios: unidades de programación codificadas y probadas.

5.

Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La documentación detallada y clara de todas las especificaciones técnicas y funcionales de detalle.  La distribución equilibrada de los esfuerzos de programación.  La identificación de todos los puntos de calidad que deben cumplir las unidades de programación y su verificación durante las sesiones de pruebas.


Página 248

Primus


III.a. LANZAMIENTO


















III.d.1.3. Codificar las unidades de programación

III.d.1.4. Ejecutar la revisión detallada del código





III.d.1.1. Preparar el ambiente de programación

III.d.1.2. Parametrizar el software aplicativo preprogramado

III.d.1.5. Preparar el ambiente de prueba y probar los módulos

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.d. Configuración III.d.1. Configuración de paquetes y del software aplicativo programación pre-programado Fecha 20/05/98 Versión Recomendado

III.d.1. Configuración del software aplicativo pre-programado

Página 249


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.d. Configuración III.d.1. Configuración de paquetes y del software aplicativo programación pre-programado

Fecha 20/05/98


Objetivo  Parametrizar el software aplicativo para adaptarlo a los requerimientos del proceso rediseñado.  Programar los módulos que no estaban contemplados en la solución pre-programada.  Probar cada unidad de programación y módulo.

2.

Tareas     

3.

III.d.1.1. III.d.1.2. III.d.1.3. III.d.1.4. III.d.1.5.

Preparar el ambiente de programación. Parametrizar el software aplicativo pre-programado. Codificar las unidades de programación Ejecutar la revisión detallada del código. Preparar el ambiente de prueba y probar los módulos..

Desarrollo III.d.1.1. Preparar el ambiente de programación El Proveedor podrá convenir realizar la parametrización utilizando las instalaciones del Comprador e incluso incorporando el personal de la Organización que se hará responsable del mantenimiento del producto. Otra opción, que no requiere preparar el ambiente de programación dentro de la Organización, es cuando el Proveedor realiza las parametrizaciones en su propia empresa, si así se convino en el contrato.

III.d.1.2. Parametrizar el software aplicativo pre-programado La mayoría de las soluciones desarrolladas por terceros tienen mecanismos que aportan flexibilidad y adaptabilidad a las distintas situaciones de la Organización, mediante la asignación de parámetros y reglas de funcionamiento que se almacenan en archivos. Dichos parámetros establecen el modo de funcionamiento del software. La parametrización no exige manejo directo de las sentencias del lenguaje. Se administra a través de herramientas incorporadas a un Case, o al lenguaje de desarrollo utilizado o a las capacidades de configuración del software aplicativo. El alcance usual de la parametrización comprende:  

La carga de nomencladores (Ej: tipos de comprobantes, códigos postales, etc.) La carga de fórmulas variables de procedimientos específicos (Ej: fórmula de cálculo por cada concepto de sueldo, etc.)


Página 250


    


Fecha 20/05/98


La carga de reglas de funcionamiento que pueden especificar el comportamiento de un objeto y luego generar en forma automática el código fuente. La generación de consultas. La generación de reportes e informes. Los generadores de diálogos (pantallas de ingresos de datos y actualizaciones) Las modificaciones de archivos a través de herramientas que generan aplicaciones automáticas para transferir el contenido de la vieja estructura a la nueva, controlando la integridad referencial.

III.d.1.3. Codificar las unidades de programación En esta instancia se convierte en sentencias de lenguaje fuente y objeto aquellos eventos no contemplados en la solución original y que no pueden ser tratados mediante parametrizaciones. Es usual que aspectos muy específicos del proceso que no responden a los estándares del mercado o las interfaces para integrar el software aplicativo a los sistemas vigentes (heredados) requieran la codificación directa en el lenguaje de programación. El nivel de automatización, rapidez y seguridad en la generación del código dependerá de la herramienta de desarrollo utilizada (Ej: lenguajes 4GL y post-4GL, ambientes de desarrollo RAD, reusabilidad de códigos, etc.).

III.d.1.4. Ejecutar la revisión detallada del código Se procede a la revisión de la sintaxis del lenguaje y de la lógica interna de los programas a fin de constatar que el programa satisface los requisitos técnico-funcionales y adhiere a los estándares determinados en el proyecto. Como resultado de la revisión pueden surgir cambios en el código o en las especificaciones de la unidad de programación. Los lenguajes modernos aceleran los procesos de revisión de sintaxis ya que detectan los errores en el momento en que se está codificando y disponen de ambientes virtuales de prueba (workbench) que facilitan el seguimiento de las sentencias y los valores cargados en las variables internas.

III.d.1.5. Preparar el ambiente de prueba y probar los módulos El alcance de la presente prueba es a nivel de cada unidad de programación. El ambiente de prueba debe estar separado del de producción. En el ambiente de prueba se reproducirán todos los archivos que deben participar en las unidades de programación a probar. No es conveniente que se tomen porciones de los archivos existentes porque no estarán necesariamente reproducidas todas las combinaciones que se pueden presentar en la realidad.


Página 251



Fecha 20/05/98


Se seleccionará el método de prueba entre las estrategias de Caja Blanca o Caja Negra. La estrategia de Caja Blanca son pruebas orientadas a la lógica interna del programa. El conjunto ideal de datos de prueba de Caja Blanca es aquel que ejecuta exhaustivamente todos los caminos de los flujos de control existentes en un módulo o programa. Los métodos más usuales son: el diagrama de flujos de control15 y el testing básico, versión Warnier Orr16.

La estrategia de la Caja Negra está orientada a probar los requerimientos funcionales del sistema. Se conoce como prueba orientada a los datos. Estas pruebas se consideran superiores a las de la Caja Blanca ya que pueden ser utilizadas bien temprano en el desarrollo. Requiere probar todos los posibles casos de entrada al módulo o programa y verificar que las salidas sean correctas.

4.


5.

Diseños de pantallas. Diseños de reportes. Diseños de bases de datos. Especificaciones de procedimientos. Informes de ajustes en programación.

Productos principales  Unidades de programación parametrizadas y probadas.

6.

Herramientas y técnicas  Lenguajes de programación.  Herramientas de Workbench y Debugg.  Tablas de verdad.

15 El diagrama de flujo de control es una red que representa la lógica del programa y emplea la técnica del número ciclomático C de McCabe (C = N° de ramas – N° de nodos + 2). Los nodos representan segmentos de programa y las ramas son los conectores desde un segmento de programa a otro 16 La versión de Warnier Orr combina las técnicas de prueba de McCabe con un técnica formalizadora como es la metodología de desarrollo de sistemas con datos estructurados de Warnier Orr (WO). Mediante esta técnica se analizan todas las combinaciones que surgen de los conjuntos de entrada de cada módulo con sus respectivas respuestas. Incluso contempla la verificación de situaciones ilógicas que se representa como un conjunto vacío que también puede ser probado para confirmar que en esas situaciones el programa no “aborte” o tome un camino incorrecto.


Página 252



Fecha 20/05/98


 Técnicas de testing (Estrategia de Caja Blanca, Estrategia de Caja Negra, Diagrama de Flujos de Control, Modelo de testing básico de Warnier Orr, etc.)


Página 253

Primus


III.a. LANZAMIENTO


















III.d.2.2. Codificar las unidades de programación





III.d.2.1. Preparar el ambiente de programación

III.d.2.3. Ejecutar la revisión detallada del código III.d.2.4. Preparar el ambiente de prueba y probar los módulos

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.d. Configuración de III.d.2. Programación paquetes y a medida programación Fecha 20/05/98 Versión Recomendado


Página 254


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.d. Configuración de III.d.2. Programación paquetes y a medida programación

Fecha 20/05/98


Objetivo  Codificar las unidades de programación.  Probar cada unidad de programación y módulo.

2. Tareas    

3.

III.d.2.1. III.d.2.2. III.d.2.3. III.d.2.4.

Preparar el ambiente de programación. Codificar las unidades de programación Ejecutar la revisión detallada del código. Preparar el ambiente de prueba y probar los módulos..

Desarrollo III.d.2.1. Preparar el ambiente de programación Se preparará el ambiente de desarrollo que permita ejecutar las tareas de programación ,compilación y prueba. La tendencia, aún en sistemas de envergadura, es que el ambiente de desarrollo esté soportado en una red de PC’s. El presente evento debe estar contemplado la preparación de los sitios e instalación de hardware y software de base.

III.d.2.2. Codificar las unidades de programación El esfuerzo de programación se dividirá en unidades de trabajo que sean fácilmente manejables y que preferiblemente no superen los veinte días para poder brindar resultados y realizar las pruebas pertinentes. En la actividad Diseño de detalle del software aplicativo a medida se prepararon las especificaciones para cada unidad de trabajo de programación. La programación estará relacionada con:    

Módulos de programas de aplicación Módulos de programas de migración Módulos de programas para generar datos de prueba Programas de cadenas de procesos (Ej.: JCL – Job Control Language)

III.d.2.3. Ejecutar la revisión detallada del código Se procede a la revisión de la sintaxis del lenguaje y de la lógica interna de los programas a fin de constatar que el programa satisface los requisitos técnico-funcionales y adhiere a los estándares determinados en el proyecto.


Página 255



Fecha 20/05/98


Como resultado de la revisión pueden surgir cambios en el código o a las especificaciones de la unidad de programación. Los lenguajes modernos aceleran los procesos de revisión de sintaxis ya que detectan los errores en el momento en que se está codificando y disponen de ambientes virtuales de prueba (workbench) que facilitan el seguimiento de las sentencias y los valores cargados en las variables internas.

III.d.4. Preparar ambiente de prueba y probar los módulos El alcance de la presente prueba, en la que no necesariamente debe intervenir personal del equipo del proyecto, es a nivel de cada unidad de programación. El ambiente de prueba debe estar separado del de producción. En el ambiente de prueba se reproducirán todos los archivos que deben participar en las unidades de programación a probar. No es conveniente que se tomen porciones de los archivos existentes porque no estarán necesariamente reproducidas todas las combinaciones que se pueden presentar en la realidad. Se seleccionará el método de prueba entre las estrategias de caja blanca o caja negra (Ver III.d.1.5. Preparar el ambiente de prueba y probar los módulos .).

4.

Insumos principales        

5.


Productos principales  Unidades de programación codificadas y probadas.

6.

Herramientas y técnicas  Lenguajes de programación.  Herramientas de Workbench y Debugg.  Tablas de verdad.


Página 256



Fecha 20/05/98


 Técnicas de testing (Estrategia de Caja Blanca, Estrategia de Caja Negra, Diagrama de Flujos de Control, Modelo de testing básico de Warnier Orr, etc.)


Página 257


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la Compendio conversión

Fecha 20/05/98


III.e. Preparación de la conversión 1.

Objetivo  Completar un plan eficaz y comprensivo de las actividades necesarias para realizar una transición exitosa que minice los riesgos y asegure el funcionamiento del proceso rediseñado y del sistema de información que lo sustente.  Desarrollar los procedimientos de conversión y generar el modelo de prueba.

2. Actividades  III.e.1. Desarrollo de los procedimientos de conversión.  III.e.2. Preparación de la prueba integral y de aceptación. 3.

Desarrollo:  La Preparación de la conversión es probable que demande un considerable tiempo por lo que debería comenzar lo antes posible dentro de la fase de Implementación.. La primer tarea será confeccionar el programa de trabajo de la conversión en el que se especifiquen la totalidad de tareas necesarias para efectivizar la conversión. No obstante, previo a detallar los pasos se revisarán y ajustarán o completarán, de ser necesario, las estrategias definidas respecto del enfoque aprobado para la conversión, la evaluación del impacto, la capacitación, la conversión del personal, las técnicas de comunicación y el control de cambios.

 Posteriormente, se traducirán los pasos definidos en el programa de trabajo en procedimientos que detallen los mecanismos de conversión de circuitos administrativos, de los sistemas de información y del personal. Los procedimientos que se desarrollen conformarán el material de entrenamiento para quienes participen de las tareas de conversión.

 Los procedimientos de conversión de los circuitos administrativos y de los sistemas de información especificarán el orden en que se irán transformando los circuitos, el diseño de los archivos de conversión, el mantenimiento de los archivos manuales o computarizados que se vayan reemplazando y las acciones a ejecutar ante situaciones de contingencia para evitar la discontinuidad del servicio.  El desarrollo de los procedimientos de conversión de personal estarán referidos a las acciones que, dentro del marco legal y normativo de la Organización, se seguirán respecto de las personas que satisfagan o no los perfiles que exigen el proceso rediseñado. Incluirán procedimientos de evaluación y según los resultados, la aplicación de mecanismos de reasignación, capacitación, retiros e incorporación de personal externo.


Página 258


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la Compendio conversión

Fecha 20/05/98


 Como paso necesario para una conversión exitosa se desarrollará el plan de prueba integral. La prueba integral está orientada principalmente a verificar que los sistemas administrativos y su soporte informático darán un soporte eficaz al proceso rediseñado. Es por ello que el plan a desarrollar debe ser lo suficientemente exhaustivo como para detectar los errores y verificar que se satisfacen los requerimientos funcionales y de performance. El plan de pruebas especificará el alcance, los requerimientos de testing, los métodos de comprobación, la oportunidad de cada test, el material a generar y el control de ejecución. Las pruebas se planificarán en ciclos. Cada ciclo avanzará en el grado de integración y complejidad pero tendrá objetivos.

 Por último se generará un modelo de prueba de sistema que simule el ambiente de producción. El modelo incluirá los archivos con datos que cubran la casuística que se puede producir y que en volumen permitan medir la performance del sistema.

4.

Productos principales         

Plan de conversión detallado. Manual de procedimientos de conversión. Definición de archivos de conversión. Plan de contingencia. Archivos de conversión. Plan detallado de prueba. Modelo de prueba del sistema. Descripción de procedimientos de prueba. Descripción de los escenarios de prueba.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La confección de un plan detallado de conversión que respete las estrategias y enfoques revisados y aprobados.  La preparación del plan de contingencias.  La capacitación del personal que participará en los procesos de prueba verificando que se incluya al personal que utilizará el sistema.  La verificación de que se hayan desarrollado planes de prueba completos con indicación de procedimientos a seguir para cuando se detecten fallas.  La preparación de un modelo de pruebas completo y consistente con el ambiente de producción.


Página 259

Primus


III.a. LANZAMIENTO


















III.e.1.4. Desarrollar el plan de contingencia

III.e.1.3. Desarrollar los procedimientos de conversión del personal





III.e.1.1. Programar la conversión

III.e.1.2. Desarrollar los procedimientos de conversión de circuitos y sistemas inform áticos

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la III.e.1. Desarrollo de conversión los procedimientos de conversión Fecha 20/05/98 Versión Recomendado


Página 260


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la III.e.1. Desarrollo de conversión los procedimientos de conversión

Fecha 20/05/98


Objetivo  Desarrollar un programa de trabajo detallado del proceso de transición.  Desarrollar procedimientos eficaces y efectivos de conversión de los circuitos administrativos, de los sistemas informáticos y del personal.  Minimizar las posibilidades de fallas en la aplicación del proceso rediseñado.

2. Tareas    

3.

III.e.1.1. III.e.1.2. III.e.1.3. III.e.1.4.

Programar la conversión. Desarrollar los procedimientos de conversión de circuitos y sistemas informáticos. Desarrollar los procedimientos de conversión del personal. Desarrollar el plan de contingencia.

Desarrollo III.e.1.1. Programar la conversión En la actividad II.d.1. Definición de estrategias de cambio se diseñaron las estrategias de transición de los procesos y de la estructura organizacional. Corresponde en esta tarea proceder a su ajuste, en base a la información disponible, a fin de asegurar una transición suave y ordenada al nuevo sistema. Previo al desarrollo del programa de conversión es conveniente revisar y ajustar, de ser necesario, las estrategias relacionadas con:          

El enfoque general de la conversión. Las fases en que se efectuará el cambio de los procesos, a nivel de circuitos administrativos y sistemas informáticos. Las fases en que se efectuará el cambio organizacional. Las técnicas de análisis de impacto. La capacitación del personal en los distintos niveles de la Organización afectados. El desarrollo de un plan de contingencia ante la eventualidad de que “algo” falle. Los mecanismos de incorporación de personal. El tratamiento que se les dará a las personas que quedarán desafectadas. Las técnicas de comunicación a utilizar para mantener el conocimiento de la Organización respecto del estado y resultados alcanzados. Las técnicas de control de cambios.

El plan de trabajo de la conversión deberá identificar los distintos pasos a ejecutar, sus responsables, los recursos necesarios, los procedimientos a utilizar , los controles de avance y las principales restricciones (Ej: límites de tiempo). Debe considerarse que el tiempo y recursos


Página 261



Fecha 20/05/98


que necesitan los procesos de conversión pueden ser importantes y que a menudo se subestiman. Otro aspecto importante es considerar el personal que llevará a cabo la implantación en el sitio en los casos de Organizaciones dispersas geográficamente a fin de determinar los requerimientos de capacitación y de documentación. Es conveniente que el personal de las área afectadas participe del proceso de planificación. Se identificarán las principales áreas problemáticas que puedan retrasar la conversión a fin de prever mecanismos de compensación o neutralización. Por último, dentro del programa se establecerá un posible plan de retirada y contingencia en el supuesto de que “las cosas no salgan como se esperaban”.

III.e.1.2. Desarrollar los procedimientos de conversión de circuitos y sistemas informáticos Los procedimientos de conversión son los instrumentos que permitirán la ejecución de los pasos definidos en el programa de conversión. Los procedimientos a especificar comprenden el momento de la conversión, que puede ser gradual o de un paso, como también el período de la transición en los que probablemente puedan coexistir el proceso “legado” y el nuevo. En esta tarea se determinarán métodos relacionados con:        

La conversión de los datos del sistema legado, sean que estén en soportes manuales o automatizados. El orden en que se irán implementando los nuevos circuitos administrativos. La selección de los datos que se pasaran del sistema legado al nuevo. La conversión de los datos del sistema legado, sean que estén en soportes manuales o automatizados. La depuración de la información migrada. La conservación de los archivos antiguos hasta que el nuevo sistema esté consolidado. El personal que participará de los procesos de prueba. La capacitación del personal que participará en el proceso de conversión.

III.e.1.3. Desarrollar los procedimientos de conversión del personal La evaluación del personal en relación al perfil requerido en los nuevos cargos del proceso rediseñado (factores formación, habilidades y aptitudes, y orientación) producirá como resultado: personas que deben ser incorporadas, retenidas o desafectadas. La selección de las personas a incorporar podrá ser efectuada por personal capacitado de la Organización o encargarse a una consultora especializada en la búsqueda de recursos humanos. En relación a las personas que deban ser conservadas se establecerá el procedimiento de capacitación. De resultar que las personas que quedan exceden los puestos a cubrir, se procederá


Página 262



Fecha 20/05/98


a calificarlas por orden de mérito a fin de determinar quienes serán retenidos y quienes desafectados o traslados a otros puestos dentro de la Organización. El personal que se desafecte de los procesos rediseñados, si la legislación y las finanzas lo permiten, podrá ser indemnizado, jubilado o incentivado para un retiro voluntario. Otra opción es capacitarlo para que pueda desempeñar otro cargo, reternerlo hasta tanto se consoliden los sistemas nuevos o promoverlo a otras áreas. Respecto de la capacitación se establecerá un plan de estudio asociado a cada cargo.

III.e.1.4. Desarrollar el plan de contingencia Siguiendo la máxima de administración de proyectos informáticos que dice “Al proyectar nuevos sistemas siempre se debe esperar lo mejor, pero planificar para lo peor” es fundamental desarrollar planes de contingencia, también llamados de continuidad de negocios. El plan de contingencia debe estar documentado y contemplar los distintos escenarios que se pueden presentar. Un primer paso es identificar dentro del proceso rediseñado las funciones críticas, vitales, sensibles y no críticas: 

Las funciones críticas son aquellas que sólo pueden llevarse a cabo mediante el reemplazo por otras de capacidades idénticas, su tolerancia es muy baja y el costo de interrupción es muy alto.



Las funciones vitales son aquellas que pueden ser reemplazadas manualmente por un período breve, generalmente 5 días o menos. Sus costos de interrupción son ligeramente menores.



Las funciones sensibles son aquellas que pueden realizarse en forma manual, con costos tolerables por un largo tiempo. Exigen mano de obra adicional.



Las funciones no críticas pueden ser interrumpidas durante un lapso largo con poco o sin costo para la Organización y exigen poco o ningún esfuerzo para ponerse al día cuando se restauren.

Para cada tipo de función se establecerá el modo de reemplazarla ante una interrupción. Dentro del plan de contingencia se establecerán los procedimientos de recuperación de información ante fallas. Debe preverse entrenamiento para que el personal que tenga que poner en funcionamiento el nuevo sistema sepa como actuar ante un imprevisto.

4.

Insumos principales  Modelado de circuitos administrativos rediseñados.


Página 263


      5.


Fecha 20/05/98


Listado de procedimientos. Documento con estrategias e instructivos de conversión. Resumen de estrategias de cambio Plan de trabajo de Implantación Modelado de circuitos administrativos rediseñados. Listado de procedimientos.


6.

Plan de conversión detallado. Manual de procedimientos de conversión. Definición de archivos de conversión. Plan de contingencia.

Herramientas y técnicas  Técnicas de administración de proyectos.  Técnicas de programación de actividades.  Recomendaciones del ISACA (Information Systems Audit and Control Association) para generar planes de contingencia. .


Página 264

Primus


III.a. LANZAMIENTO


















III.e.2.2. Generar el modelo de prueba





III.e.2.1. Planificar la prueba integral

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la III.e.2. Preparación conversión de la prueba integral y de aceptación Fecha 20/05/98 Versión Recomendado


Página 265


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.e. Preparación de la III.e.2. Preparación conversión de la prueba integral y de aceptación

Fecha 20/05/98


Objetivo  Desarrollar el plan de prueba integral que detecte los errores y verifique que se satisfacen todos los requerimientos técnicos y funcionales del proceso rediseñado.  Generar el modelo de prueba.

2. Tareas  III.e.2.1. Planificar la prueba integral.  III.e.2.2. Generar el modelo de prueba.

3.

Desarrollo III.e.2.1. Planificar la prueba integral La prueba integral está orientada a verificar que los sistemas informáticos de apoyo y circuitos administrativos interactúan de acuerdo a lo esperado bajo distintos escenarios. Respecto de los sistemas informáticos, a diferencia de las pruebas que se realizan con cada unidad de programación (prueba unitaria), en este caso el sistema deberá demostrar que los distintos módulos se integran correctamente en base a los mensajes que reciben del exterior al sistema o de otros módulos (prueba integración) y que satisface los requerimientos funcionales del usuario (prueba de aceptación). La prueba será un proceso de múltiples pasos y niveles, desde el ensayo de las unidades más pequeñas, pasando por las que se integran a otras unidades hasta llegar a la prueba de la totalidad del sistema como una unidad completa. Debido a su extensión, cuidado y complejidad es fundamental desarrollar el plan de prueba o “testing”. El plan es el medio de comunicación en el proceso de testing. Un buen plan de prueba debe permitir planificar, monitorear y controlar todas las actividades del proceso de testing, identificando claramente los puntos de control y de retoma. Cada ciclo de la prueba se dividirá en : iniciación, ejecución, detección de fallas y documentación. El contenido estándar de un plan de pruebas es el siguiente: 

Introducción Es una breve descripción del sistema a probar, incluyendo diagramas de análisis y diseños, la estrategia de prueba (Ej: caja blanca, caja negra, etc.), el alcance (Ej: prueba de funcionalidad, prueba de performance, prueba de seguridad, etc.), identificación de las funciones o aspectos que no se probarán, y los informes y documentación que se generará..


Página 266





Fecha 20/05/98


Requerimientos de testing Describe los requerimientos humanos, de equipamiento, de software y de datos para efectuar el proceso de prueba. Los requerimientos humanos consisten en determinar el perfil, responsabilidad y número del personal que participará en cada ciclo de prueba. Los requerimientos de hardware se refieren a la configuración requerida para soportar la carga exigida en las pruebas de integración y las pruebas de aceptación. Los requerimientos de software se refieren a la especificación del software de base que debe estar instalado en el equipamiento que sirva de soporte a las pruebas. Los requerimientos de datos indican los archivos que deben estar presentes en cada prueba.



Alcance de la prueba Determina el alcance de la prueba respecto de: los programas, las funciones, los rendimientos y el entorno de seguridad.



Métodos de testing Detalla las herramientas de prueba; el desarrollo de los casos de prueba, inspección y verificación; los escenarios para aislar problemas y el mecanismo de informe de problemas y resolución.



Hitos Indica el itinerario de la prueba.



Material de prueba Resume la situación inicial de la prueba, los casos a los que se someterá el sistema y los resultados que deben obtenerse.



Control de ejecución Comprende la documentación de la prueba (bitácora), las acciones a realizar si existen fallas y las autorizaciones para lanzar cada ciclo.

III.e.2.2. Generar el modelo de prueba Consiste en la preparación del ambiente que simule las características del proceso rediseñado bajo distintos escenarios y considerando las variables que estarán presentes cuando el sistema esté en producción. Es por ello que el modelo debe estar preparado para aceptar las condiciones de picos de trabajo y excesos de volúmenes de carga (pruebas de tensión) a fin comprobar como reacciona el sistema ante situaciones normales y criticas.


Página 267



Fecha 20/05/98


La generación del modelo de prueba siguiendo el procedimiento de la Caja Negra comprende como mínimo:  

La preparación de todos los archivos que utilizarán las transacciones. La carga de los archivos con todos las combinaciones de datos que comprenda la casuística que soportará el sistema en producción. Se producirá una copia de todos los archivos en su estado original antes de comenzar la prueba a fin de poder restituirlos a su estado primario.  La generación de los reportes con los resultados que deben obtenerse con la combinación de cada situación de entrada.  Los códigos ejecutables de todos los programas. Si bien se puede generar un modelo de prueba totalmente nuevo para cada conversión de sistemas, es conveniente un modelo base que se vaya ampliando de acuerdo a los requerimientos que cada conversión exige. Una vez que se verifique que modelo de prueba generado es consistente se hará un resguardo a fin de poder volver a la situación inicial en cualquier momento.

4.

Insumos principales        

5.


6.


Archivos de conversión. Plan detallado de prueba. Modelo de prueba del sistema. Descripción de procedimientos de prueba. Descripción de los escenarios de prueba (Requerimientos).

Herramientas y técnicas  Técnicas de testing (Estrategia de Caja Blanca, Estrategia de Caja Negra, Diagrama de Flujos de Control, Modelo de testing básico de Warnier Orr, etc.)


Página 268


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y Compendio capacitación

Fecha 20/05/98


III.f. Evaluación y capacitación 1. Objetivo  Identificar los excesos y escasez de personal en función los perfiles que requiere el proceso rediseñado.  Determinar los requerimientos de capacitación.  Capacitar al personal en la administración, operación y mantenimiento del proceso rediseñado. 2.

Actividades  III.f.1. Evaluación del personal.  III.f.2. Capacitación del personal.

3.

Desarrollo Durante esta etapa:  Se evaluará el personal en función de sus condiciones (formación, habilidades, aptitudes, orientación y adaptabilidad al cambio ) a fin de determinar el grado de satisfacción de su perfil respecto de los requerimientos que exige la dotación que se definió durante la fase de Diseño de soluciones.  El paso siguiente será completar la dotación. Aquí se define el destino del personal que fue evaluado. Por un lado estarán aquellos que cubren el perfil de algunos de los cargos del proceso rediseñado y otros que no lo satisfacen. A su vez, de aquellos que satisfacen el perfil puede resultar excesos o faltantes. Si se producen excesos se aplicarán los procedimientos definidos para ordenar por mérito los candidatos potenciales a fin de determinar quienes cubrirán los cargos. En los casos de escasez se optará por capacitar o tomar expertos externos. Respecto de quienes hayan quedado fuera del proceso por no cubrir el perfil o por haber resultado descalificados durante el proceso de selección de exceso de candidatos potenciales, la estrategia podrá ser reasignarlas, capacitarlas o desafectarlas de la Organización. Las decisiones respecto de conservar o desafectar el personal “sobrante” deberán ser analizadas en relación con la estrategia de la Organización, atento a la situación común de que personas que fueron despedidas durante el rediseño de un proceso deben ser reincorporadas por ser necesarias en otro sector.  El personal asignado será capacitado en la administración, operación y mantenimiento del nuevo proceso. La capacitación comenzará con el desarrollo del plan de capacitación que surgirá de relevar los requerimientos originados en procedimientos nuevos, en la necesidad de elevar el perfil del personal asignado o por aspectos administrativos y operativos que exigen los nuevos sistemas informáticos y de comunicaciones. Posteriormente se procederá a la selección de los capacitadores que pueden ser externos o


Página 269


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y Compendio capacitación

Fecha 20/05/98


internos. Si la Organización está dispersa geográficamente y/o es muy grande, podrá comenzar con la capacitación de un grupo reducido quienes posteriormente pueden ser a su vez capacitadores de otros grupos. Los capacitadores además de capacitar, serán responsables de preparar los manuales y el material. El proceso de capacitación debe ser “justo a tiempo”, ni muy anticipada de modo que olviden los que se les enseñó ni muy tardía que retrase la implementación.

4.

Productos principales          

5.

Matriz de evaluación de personal. Matriz de destinos potenciales de personal. Manuales de usuarios. Manuales de sistemas informáticos. Manuales de procedimientos administrativos. Manuales de misiones y funciones. Manuales de seguridad. Manuales de operaciones. Programas de capacitación. Personal capacitado.

Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  Los criterios de evaluación del personal y de asignación.  El plan de capacitación que debe contemplar que concluya a tiempo para que el personal pueda intervenir en la prueba integral y para no retrasar la conversión.


Página 270

Primus


III.a. LANZAMIENTO

















III.f.1.2. Completar la dotación


III.f.1.1. Evaluar al personal





Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y III.f.1. Evaluación del capacitación personal Fecha 20/05/98 Versión Recomendado


Página 271


1.

MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y III.f.1. Evaluación del capacitación personal

Fecha 20/05/98


Objetivo  Evaluar el personal en función de su perfil.  Identificar el excesos y escasez de personal.

2. Tareas  III.f.1.1. Evaluar el personal.  III.f.1.2. Completar la dotación

3.

Desarrollo III.f.1.1. Evaluar el personal Durante la actividad Diseño organizacional se definió una nueva estructura organizativa con especificación de cargos, perfiles y cantidad necesaria de personal. Posteriormente se determinaron los cargos que se generaban, anulaban y transformaban; estableciendo el esfuerzo necesario (grado de dificultad) para transformar un cargo vigente en un cargo nuevo o rediseñado. Hasta este momento, el análisis se ha realizado en base al perfil de los cargos, resta conocer ahora si las personas de la Organización tienen las aptitudes que exigen los cargos que se mantienen o los nuevos o los rediseñados. Para ello se realizará una evaluación del personal en base a los factores: Formación, Habilidades y aptitudes, Orientación y Adaptabilidad para afrontar el cambio. Por cada factor se analizarán las variables que fueron utilizadas para definir el perfil de cada cargo. De la comparación de las aptitudes de cada persona con las aptitudes de los cargos del proceso rediseñado, se generarán las siguientes situaciones: 

Que la persona cubra las aptitudes de uno o varios cargos del proceso rediseñado: se la asignará al cargo para el que califica mejor, que puede o no coincidir con el cargo que ocupa.



Que la persona no cubra las aptitudes de ningún cargo del proceso rediseñado: se analizará si se la puede reasignar a otro lugar de la Organización o bien, dejarla en disponibilidad.

III.f.1.2. Completar dotación Durante esta tarea corresponde comparar el número de potenciales candidatos con la cantidad determinada durante la actividad Determinar las necesidades de personal de la fase Diseño de soluciones. De la comparación surgirán excesos o faltantes al presentarse las siguientes situaciones:


Página 272


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y III.f.1. Evaluación del capacitación personal

Fecha 20/05/98




Que existen más candidatos que puestos de trabajo: se les otorgará un orden de mérito a cada persona, y luego se analizará si los excedentes pueden ser reasignados a otros cargos dentro de la Organización o deben ser desafectados (Ej.: indemnizaciones, retiros voluntarios, etc.).



Que existan menos candidatos que puestos de trabajo: se analizará si las personas que sobran en otros cargos de mayor exigencia pueden ser reasignados, o si personas de menor aptitud pueden ser capacitadas o, por último, si es necesario incorporar personal externo a la Organización.

Los métodos a aplicar tanto para los excesos como faltantes responderán a los procedimientos que fueron establecidos para la conversión del personal. Debe considerarse que al trabajar en reingeniería con un proceso por vez se corre el riesgo que personas que fueron desafectadas y despedidas sean re-contratadas por ser necesarias en otra parte de la Organización. Es por ello que durante esta tarea se considerará la estrategia de la Organización, dependiendo de que tienda a concentrarse (reducción ) o a expandirse. En el primer caso quizás sea apropiado disminuir plantel y en el segundo conservarlo.

4.


5.

Cuadro de correlación de cargos anteriores y cargos nuevos. Matriz de evaluación de cargos nuevos. Matriz de correlación de Actividades/Tareas- Estructura Organizacional (Procesos rediseñados) Matriz de transición de cargos Cuadro de necesidades de personal.

Productos principales  Matriz de evaluación de personal.  Matriz de destinos potenciales de personal.

6.

Herramientas y técnicas  Técnicas de evaluación de recursos humanos.  Gráfico polar de evaluaciones comparadas.  Software de evaluación de puestos (Ej.: Description Now®, High-Tech®)


Página 273

Primus


III.a. LANZAMIENTO


















III.f.2.2. Seleccionar los capacitadores




III.f.2. Capacitación del personal

III.f.2.1. Confeccionar el plan de capacitación

III.f.2.3. Preparar manuales y material de capacitación

III.f.2.4. Capacitar

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y III.f.2. Capacitación capacitación del personal Fecha 20/05/98 Versión Recomendado

III.f.2. Capacitación del personal

Página 274


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.f. Evaluación y III.f.2. Capacitación capacitación del personal

Fecha 20/05/98


1. Objetivo  Determinar los requerimientos de capacitación.  Capacitar al personal en la administración, operación y mantenimiento del proceso rediseñado.

2.


III.f.2.1. III.f.2.2. III.f.2.3. III.f.2.4.

Confeccionar el plan de capacitación. Seleccionar los capacitadores. Preparar manuales y material de capacitación. Capacitar.

3. Desarrollo III.f.2.1. Confeccionar el plan de capacitación El plan de capacitación surgirá de relevar los requerimientos originados por: 

Procedimientos nuevos o modificados establecidos en los procesos rediseñados.



Aptitudes de formación básica requeridas en las personas para elevar su perfil conforme los requerimientos del cargo que ocuparán.



Administración y operación de los sistemas informáticos soportarán el nuevo proceso.

y de comunicaciones que

Determinadas las necesidades se clasificarán en áreas temáticas estableciendo el orden de capacitación y la cantidad de personal a capacitar en cada tema. Es importante que se cubran los requerimientos del proceso en los niveles operativos, de administración, de planificación, de dirección y de control. Por cada área temática se establecerá el objetivo y alcance. Es importante que la selección de temas permita la educación del personal y no el mero entrenamiento. Mediante la educación el empleado aprende el “por qué” de hacer las cosas de determinada manera fomentando el discernimiento y el ejercicio de su propio criterio; en cambio con el entrenamiento sólo aumenta sus destrezas, perfeccionando el “como “ hacer las cosas. El plan de capacitación debe integrar los cursos dictados por personal de la Organización, los cursos provistos por las soluciones contratadas (Ej: software aplicativo, software de base, comunicaciones, etc.) y los cursos a contratar.

III.f.2.2. Seleccionar los capacitadores La selección y contratación de capacitadores externo será respecto de aquellos temas que no estén incluidos en las soluciones contratadas o para los que no existan personas dentro de la Organización que pueda asumir esta responsabilidad.


Página 275



Fecha 20/05/98


En los términos de la contratación de capacitación se deberá establecer el lugar, la metodología y material de capacitación, la cantidad de alumnos por curso y la técnica de evaluación.

III.f.2.3. Preparar manuales y material de capacitación Los procesos deben documentarse. Existen distintos medios para difundir la documentación, desde los tradicionales manuales en papel hasta publicaciones electrónicas en CD o bases de información en línea con accesos a través de redes locales o corporativas. La documentación mínima a generar y/o proveer por terceros es la siguiente: 

Manuales de misiones y funciones, comprende: organigramas y descripción de cargos (denominación, cargo de dependencia jerárquica, cargos que están subordinados, funciones y actividades principales).



Manuales de procedimientos administrativos: separados por procesos, actividades, tareas y procedimientos finales. Se utilizarán diagramas de actividades y eventos como guías generales.



Manuales de usuario del software aplicativo: incluirán desde la puesta en marcha hasta el mantenimiento, las distintas funciones soportadas por la solución desarrollada o contratada. El manual abordará los temas de menor a mayor complejidad, tratando desde las situaciones de operación normal hasta las de excepción (Ej: manejo de errores). Es conveniente que exista un manual de introducción y otro de desarrollo, como también un resumen, usualmente denominado “pocket” que sintetice las funciones principales y sirva de ayuda para usuarios que ya tienen una cierta experiencia.



Manuales de operación de sistemas: están orientados a quienes tengan la responsabilidad de operar los equipos informáticos y las comunicaciones. Incluyen elementos de hardware (Ej: mantenimientos preventivos y correctivos) y software (Ej.: sistemas operativos, sistemas de administración de redes, etc.).



Manuales de sistemas informáticos: se refiere a las especificaciones que permitan el conocimiento de la estructura y funcionamiento del software aplicativo a fin de facilitar su mantenimiento. Comprende el mapa de sistemas, diccionarios de datos, diagramas de entidad-relación, diagramas de flujos de datos, descripciones de aplicaciones, diseños de pantallas y de salidas, etc.



Manuales de seguridad: detallan las políticas que conforman el ambiente de seguridad. Comprende los controles ambientales, de acceso lógico y de confidencialidad; los procedimientos de devolución de llamadas; la identificación de violaciones; las normas de no publicidad de lugares críticos; etc.

Previo a la capacitación deberá prepararse el material (Ej.: pizarras, casos para resolución, retroproyectores, proyectores LCD, filminas, etc.), de acuerdo a la metodología a utilizar


Página 276



Fecha 20/05/98


III.f.2.4. Capacitar La capacitación debe ser “justo a tiempo”, ni muy anticipada de modo que olviden los que se les enseñó, ni muy tarde que provoque demoras en la implantación efectiva o bien afronten la conversión sin los suficientes conocimientos. Las personas capacitadas participarán en las pruebas de aceptación del nuevo sistema, por lo que es conveniente que se instruyan cuando los productos están siendo sometidos a prueba de integración, pero siempre que estén próximos a alcanzar el estado final de terminación. De otra manera se corre el riesgo que los empleados se desanimen si advierten que existen demasiados errores. En los casos de grandes Organizaciones dispersas geográficamente, la capacitación puede comenzar con un grupo reducido de empleados que una vez formados puedan ser formadores de otros grupos: es una forma económica y eficaz de capacitar.

4.

Insumos principales              

5.

Modelado de circuitos administrativos rediseñados. Diccionario de rúbricas. Nomenclador de comprobantes. Matriz de comprobantes anulados, modificados y nuevos. Listado de procedimientos. Documento con estrategias e instructivos de conversión. Diseños de pantallas. Diseños de reportes. Diseños de bases de datos. Diagramas de estructuras de programas y narraciones. Tablas de decisiones. Diagramas de transición de estados. Especificación de métodos (Diseño orientado a objetos) Plantillas de algoritmos.

Productos principales       

Manuales de usuarios. Manuales de sistemas informáticos. Manuales de procedimientos administrativos. Manuales de misiones y funciones. Manuales de seguridad. Manuales de operaciones. Programas de capacitación.


Página 277



Fecha 20/05/98


 Personal capacitado.

6.

Herramientas y técnicas  Técnicas de resolución de casos.  Técnicas de fomentación de destrezas.  Técnicas de organización de equipos.


Página 278


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.g. Prueba final y Compendio conversión

Fecha 20/05/98


III.g. Prueba final y conversión 1.

Objetivo  Verificar, previo a la conversión, que los procesos y sistemas de información de apoyo funcionan correctamente y responden a las expectativas de mejora del proceso rediseñado.  Identificar las mejoras y correcciones necesarias.  Poner en funcionamiento el proceso rediseñado.  Generar un clima favorable para la mejora contínua.

2. Actividades  III.g.1. Prueba final.  III.g.2. Conversión. 3.

Desarrollo  Se organiza el equipo de prueba verificando que se haya completado el entrenamiento y tengan disponibles los correspondientes manuales y procedimientos que se ejecutarán. Se seguirá estrictamente el protocolo de prueba elaborado durante la planificación, revisando que estén presentes todos los elementos previstos en el modelo de prueba diseñado y documentando todas las fases del testeo. Durante esta tarea participará una cantidad importante de futuros usuarios además de los especialistas y principales responsables de la Oficina de Proyectos Provincial.  Se ejecutará la prueba de integración del software aplicativo a fin de verificar el correcto funcionamiento de todos los componentes de la solución actuando en forma conjunta y que las funciones individuales de cada programa responden a las especificaciones que han sido documentadas. La prueba incluirá la verificación del cumplimiento de las especificaciones funcionales que requiere el proceso y las situaciones especiales como la inicialización de los archivos, los procedimientos de resguardo, la depuración de archivos y los procedimientos de recuperación. Durante la prueba se podrá adoptar el enfoque de modificación o el de regresión.  Luego de comprobar que el sistema responde a situaciones normales se lo expone a situaciones críticas o de excepción a fin de establecer los parámetros que configuren situaciones de servicio normales, de prevención y críticas. En estas últimas el sistema está expuesto al colapso. Las pruebas usuales se relacionan con el nivel de respuesta cuando: alcanza la capacidad máxima de actividad y datos para que fue diseñado, supera los máximos permitidos, aparecen datos “basuras” o situaciones no contempladas en el diseño y se presentan situaciones externas imprevistas (Ej: corte de energía).  La prueba final es la de aceptación del usuario . Para este fin se simulan condiciones de trabajo reales en un ambiente limitado. La prueba alcanza a todo el proceso y su aprobación es el hito que autoriza la conversión definitiva. Se analizará la factibilidad de realizar un prueba completa durante 1 o 2 meses en forma


Página 279



Fecha 20/05/98


paralela, siempre que no afecte las actividades normales de la Organización. Los errores advertidos durante las pruebas generarán las consiguientes modificaciones que según la gravedad podrán implementarse antes o después de la conversión. Cualquier cambio que afecte el diseño original debe ponerse en conocimiento de los usuarios, en cuanto se haya alterado lo recibido durante la capacitación.

 Concluidas la prueba final y realizadas las modificaciones se verifica que estén presentes las condiciones mínimas para proceder a la conversión: personal capacitado, posiciones críticas ocupadas, infraestructura informática y de comunicaciones funcionando, documentación terminada y distribuida, muebles e insumos instalados y adecuada difusión de las fechas y ciclos de conversión.  La conversión se podrá realizar en una o varias instancias. Podrá comenzar con los procedimientos diarios, semanales y mensuales mientras que los procedimientos trimestrales o de mayor periodo estén en estado de prueba. Implicará la puesta en marcha del nuevo proceso y todos los sistemas de apoyo que lo sustentan. Se seguirá cuidadosamente los pasos que fueron programados durante el segmento Preparación de la conversión. El proceso de conversión durará generalmente varias semanas y representa generalmente un importante esfuerzo que concluye efectivamente cuando se verifica que el nuevo proceso se convierte en estado operativo de rutina y es compatible con el medio operativo existente. Durante la primer etapa del proceso de conversión podrán convivir las posiciones nuevas y las legadas hasta que se produzca la absorción y eliminación de las últimas. Se deberá estar atento al impacto producido ante la normal aparición de situaciones no contempladas en la planificación como es la impredecible reacción de personas que no participaron durante el proceso. Durante el curso de la conversión se advertirán los errores y mejoras que pueden efectuarse, las que se evaluará si son de realización inmediata o pueden diferirse.

 A partir de la conversión, se generará en la Organización el clima favorable y en el personal la costumbre de observar en forma crítica el proceso rediseñado a fin de detectar las mejoras incrementales que se puedan implantar.

4.


Software aplicativo en producción. Archivos migrados.. Parámetros inicializados. Circuitos administrativos y procedimientos nuevos implantados.


Página 280



Fecha 20/05/98


 Manuales distribuidos.  Personas asignadas a sus nuevos puestos.  Sugerencias documentadas para mejorar el proceso.

5. Puntos de control Los principales aspectos que deben controlarse para asegurar la eficacia del segmento son:  La prueba integral del proceso respecto de sus nuevos circuitos y sistemas de información manuales y automatizados con participación efectiva y comprometida de los usuarios.  Personal capacitado.  Infraestructura informática y de comunicaciones en funcionamiento.  Instalaciones modificadas.  Muebles e insumos instalados.  Documentación corregida y distribuida (Manuales de: usuarios, de sistemas, de procedimientos administrativos, de misiones y funciones, de seguridad y de operaciones).  Comunicaciones de fechas y ciclos de conversión en conocimiento de todo el personal directa e indirectamente afectado al nuevo proceso.  Posiciones críticas del nuevo proceso ocupadas.  Programa de conversión revisado y respetado durante el proceso de transición.


Página 281

Primus


III.a. LANZAMIENTO



















III.g.1.3. Ejecutar la prueba de situaciones especiales

III.g.1.5. Realizar las modificaciones necesarias

III.g.1.2. Ejecutar la prueba de integración del SW aplicativo




III.g.1.1. Organizar el equipo de prueba

III.g.1.4. Ejecutar la prueba de aceptación del proceso rediseñado

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.g. Prueba final y III.g.1. Prueba final conversión Fecha 20/05/98 Versión Recomendado


Página 282


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.g. Prueba final y III.g.1. Prueba final conversión

Fecha 20/05/98


1. Objetivo  Verificar que el proceso rediseñado y los sistemas de información de apoyo contienen todas las funciones que se requieren y que estas se ejecutan correctamente.  Identificar las mejoras y correcciones necesarias antes de proceder a la conversión final. 2. Tareas     

III.g.1.1. Organizar el equipo de prueba. III.g.1.2. Ejecutar la prueba de integración del software aplicativo. III.g.1.3. Ejecutar la prueba de situaciones especiales. III.g.1.4. Ejecutar la prueba de aceptación del proceso rediseñado. III.g.1.5. Realizar las modificaciones necesarias.

3. Desarrollo III.g.1.1. Organizar el equipo de prueba Durante la actividad de prueba se produce la participación de la mayor cantidad de personal de la Organización, ya que no sólo intervienen los miembros del equipo de la Oficina de Proyectos Provincial y del Equipo Funcional; sino también los representantes de los futuros usuarios. Según vaya progresando la prueba, aumentará la extensión de la participación del usuario. Atento a que el mayor porcentaje del personal puede estar únicamente parte del tiempo, se requiere una prolija planificación a fin de asegurar que todos participen. Es requisito para iniciar la prueba final que el personal haya concluido su capacitación y estén terminados todos los manuales.

III.g.1.2. Ejecutar la prueba de integración del software aplicativo Durante la actividad Programación se puso énfasis en la prueba del código y lógica de los programas individuales y de la comunicación de algunos grupos de programas. En esta tarea, el énfasis se pondrá en la prueba de todo el sistema. Para la ejecución de la prueba de integración, que se realizará en varios ciclos, se seguirá el plan y modelo de prueba desarrollados durante la actividad Preparación de la prueba integral y de aceptación. Los ciclos deben seguir, preferentemente, la secuencia natural de actividades dentro del proceso rediseñado. Los ciclos iniciales probarán los procesos de carga de los archivos maestros y de parámetros. Los últimos ciclos probarán situaciones especiales como: procedimientos de resguardo, pasaje de datos a archivos históricos y recuperación , y depuración de archivos. Se verificará la correcta comunicación entre los programas que componen el sistema que se pondrá en marcha y la de éstos respecto del software aplicativo vigente.


Página 283



Fecha 20/05/98


En base a la metodología de la Caja Negra utilizada para construir el modelo de prueba y siguiendo los ciclos definidos en la planificación, se procesarán las entradas predefinidas a fin de producir los resultados que se compararán con los resultados predefinidos. Aunque cada ciclo tiene su propio propósito, debe emplearse un enfoque uniforme para comprobar los resultados detallados en cada ciclo. Es importante constatar como responde el sistema ante situaciones anormales. Durante la prueba pueden existir dos enfoques: el de modificación y el de regresión. El enfoque de modificación es la metodología más usada, consiste en analizar los problemas para determinar qué ciclos de prueba afectan. Luego, se verifican únicamente los ciclos afectados. Al concluir una etapa que contenga varios ciclos, se prueban entonces todos los ciclos para asegurar que un problema no haya afectado a otra función inadvertidamente. El enfoque de regresión hace que se vuelva al primer ciclo cada vez que se descubre un problema y no se requiere una prueba final de todos los ciclos. III.g.1.3. Ejecutar la prueba de situaciones especiales Durante este ciclo de prueba se expone al sistema a situaciones de excepción. Las pruebas típicas son: 

Pruebas de volumen: se verifica que el sistema pueda responder bajo criterios de performance aceptable a los valores y tamaños máximos para los cuales ha sido diseñado. Dichos valores se pueden referir a capacidades de archivos o cantidad de eventos simultáneos a atender (Ej: usuarios concurrentes activos).



Pruebas de tensión: se expone el sistema a volúmenes crecientes de datos o eventos a manejar hasta que se produzca la máxima degradación del servicio o colapso total. Esta prueba permitirá conocer hasta donde puede soportar el sistema a fin de establecer las zonas de servicio normales, de prevención y críticas.



Pruebas de datos reales: consiste en migrar datos de la realidad que usualmente contienen “basuras” o inconsistencias que no fueron contempladas como error en los diseños y que provocan resultados inesperados en el sistema que no se pueden controlar.



Pruebas de conversión: se verificarán los procesos manuales y automáticos de conversión que pueden consistir en carga inicial de archivos o migración de datos de un sistema automatizado a otro. Los procesos de conversión deben probarse tempranamente, ya que de no hacerlo pueden afectar la conversión con un problema mayor. Los procesos de conversión pueden probarse en forma paralela con el nuevo sistema; no obstante, al menos un ciclo de la prueba del sistema debe realizarse con datos creados por los procesos de conversión como entrada al nuevo sistema. La utilización de datos reales en el último ciclo de prueba de los procesos de conversión reduce la posibilidad de sorpresas.. Esta sorpresas suceden en razón de que los archivos antiguos a menudo incluyen datos no depurados que pueden ocasionar inconsistencias durante el funcionamiento del nuevo sistema.


Página 284



Fecha 20/05/98


III.g.1.3. Ejecutar la prueba de aceptación del proceso rediseñado Esta prueba está orientada a simular las condiciones operativas reales en un área limitada. Comprende la comprobación del efectivo soporte del sistema informático al proceso rediseñado desde la visión de quienes tienen que utilizarlo en los distintos niveles de la Organización. Comprueba además el cumplimiento de las especificaciones de rendimiento predeterminados. Es importante la comprobación del sistema en situaciones de contingencia provocadas, para determinar su nivel de respuesta y la capacitación del personal para afrontar dichos eventos. Si es factible en cuanto a tiempo y afectación de recursos, se realizará una prueba paralela del sistema durante un período razonable de 1 a 2 meses en dónde se determinarán inconvenientes difíciles de detectar en el banco de pruebas (Ej: tiempos de respuesta atendiendo una cola de personas, consultas frecuentes no contempladas, etc.). Uno de los principales inconvenientes para realizar pruebas en paralelo es que implica un doble trabajo para los empleados que deben procesar por el sistema vigente y por el nuevo, por ello es que no siempre es factible este tipo de comprobación. Por último, los representantes de los usuarios deben brindar su conformidad como punto de partida para la conversión definitiva del sistema.

III.g.1.4. Realizar las modificaciones necesarias Las causas comunes de errores son lógicas de programación o problemas de diseño. Los problemas de programación son, usualmente, errores de codificación o malas interpretaciones de las especificaciones de diseño. Los problemas de diseño pueden ser por malas interpretaciones de las necesidades del usuario o condiciones externas no contempladas. Las modificaciones pueden implementarse durante la prueba del sistema o diferirse hasta después de la conversión. La decisión deberá ser tomada por el Gerente de Implantación. Los aspectos a considerar para la toma de decisión son la complejidad, el impacto, la cantidad del esfuerzo y el efecto del sistema en otros procesos. El proceso de prueba deberá quedar registrado en el documento Control de Incidentes de Prueba del Sistema, en donde se identificará la causa de error, la cantidad de repeticiones realizadas y la solución aportada. La falta de control y coordinación de las correcciones pueden producir errores que provoquen importantes pérdidas de recursos o generar problemas mayores que los que se intentaba solucionar. Todos los cambios que afecten el diseño original deben ponerse en conocimiento de loa los usuarios, en cuanto se haya alterado lo recibido durante la capacitación.

4.

Insumos principales  Archivos de conversión.  Plan detallado de prueba.  Modelo de prueba del sistema.


Página 285


       

5.


Fecha 20/05/98


Descripción de procedimientos de prueba. Descripción de los escenarios de prueba (Requerimientos). Manuales de usuarios. Manuales de sistemas informáticos. Manuales de procedimientos administrativos. Manuales de misiones y funciones. Manuales de seguridad. Manuales de operaciones.

Productos principales  Sistema probado, listo para la conversión.  Personal entrenado en situaciones similares a las reales.

6.

Herramientas y técnicas  Técnicas de administración de proyectos.  Técnicas de testing (Estrategia de Caja Blanca, Estrategia de Caja Negra, Diagrama de Flujos de Control, Modelo de testing básico de Warnier Orr, etc.)  Técnicas de mesas de pruebas.


Página 286

Primus


III.a. LANZAMIENTO



















III.g.2.3 .Ejecutar el respado y mejora contínua del proceso

III.g.2.2. Evaluar el funcionamiento del proceso rediseñado




III.g.2.1. Convertir

Fase III – IMPLANTACION MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.g. Prueba final y III.g.2. Conversión conversión Fecha 20/05/98 Versión Recomendado


Página 287


MANUAL DE ADMINISTRACION DE PROYECTOS PARTE II: METODOLOGIA Segmento Actividad III.g. Prueba final y III.g.2. Conversión conversión

Fecha 20/05/98


1. Objetivo  Ejecutar la transformación del proceso rediseñado.  Refinar los detalles que aseguren el uso continuo.  Generar un clima favorable para la mejora continua.

2.

Tareas  III.g.2.1. Convertir.  III.g.2.2. Evaluar el funcionamiento del proceso rediseñado.  III.g.2.3. Ejecutar el respaldo y mejora continua del proceso.

3. Desarrollo III.g.2.1. Convertir La conversión es la instancia más importante desde la generación de la visión del nuevo proceso, ya que llevará al plano concreto y operativo la totalidad de los procedimientos manuales y automáticos diseñados. La conversión comprende, aunque no necesariamente en una única vez, la transformación de: los circuitos administrativos, los sistemas informáticos y de comunicaciones de apoyo, el marco normativo, las políticas y la estructura organizacional. Previo a la conversión deberá verificarse que como mínimo se hayan cumplimentado los siguientes eventos:     

 

Que el personal haya sido capacitado. Que las posiciones críticas hayan sido ocupadas. Que el equipamiento informático, el software de base y las facilidades de comunicaciones funcionen correctamente en forma integrada. Que el software aplicativo haya superado satisfactoriamente la prueba final en todos sus ciclos. Que estén terminados, corregidos y aprobados los manuales: de usuarios, de sistemas, informáticos, de procedimientos administrativos, de misiones y funciones, de seguridad y de operaciones. Que los muebles e insumos estén instalados. Que todos los sectores afectados y relacionados conozcan la fechas y ciclos de conversión.

Debe programarse cuidadosamente la cantidad y tiempo del personal a afectar, dado que se requerirá una fuerte participación de los usuarios de los sectores directamente afectados, quienes tendrán que trabajar gran cantidad de horas, incluso los fines de semana y las noches. Deberá considerarse especialmente aquellas personas que no han tenido un contacto previo con el sistema y que pueden reaccionar en forma impredecible. La conversión puede comenzar con los procedimientos diarios, semanales o mensuales mientras que los procedimientos trimestrales o de mayor período pueden estar en proceso de prueba .


Página 288



Fecha 20/05/98


III.g.2.2. Evaluar el funcionamiento del proceso rediseñado El objetivo de esta tarea es identificar las áreas de potenciales mejoras. Para ello deben identificarse previamente los indicadores de control a fin de no realizar revisiones al azar o simplemente, actuar cuando se hayan detectado los problemas. Debe considerarse que en los primeros meses de funcionamiento es muy probable que el proceso rediseñado no funcione tan eficientemente como se pensó, ya que el personal tendrá que acostumbrarse a los nuevos procedimientos. Es común que se cometa el error de asignar el personal más calificado al sistema vigente durante el proceso de conversión y no cubrir debidamente las posiciones claves del nuevo proceso. Las mejoras que se detecten durante la conversión no es necesario que se implementen inmediatamente. Es por ello que resulta conveniente su documentación a fin de diferirlas hasta la etapa de respaldo y mejora continua del proceso. III.g.2.3. Ejecutar el respaldo y mejora continua del proceso. La presente es una tarea que se constituye en permanente durante la vigencia del proceso rediseñado. Comprende la detección e implantación de mejoras incrementales que hagan más eficiente el proceso rediseñado. Esta mejoras no constituirán un cambio radical sino estaríamos ante un nuevo ciclo de rediseño integral de procesos. Para la realización eficaz de esta tarea deberán establecerse procedimientos que aseguren que las mejoras detectadas sean evaluadas, documentadas y puestas en funcionamiento.

4.

Insumos principales      

5.

Infraestructura informática instalada y probada. Software aplicativo probado y ajustado. Archivos convertidos. Manuales completos y ajustados. Sistema probado, listo para la conversión. Personal entrenado.

Productos principales      

Software aplicativo en producción. Archivos migrados.. Parámetros inicializados. Circuitos administrativos y procedimientos nuevos implantados. Manuales distribuidos. Personas asignadas a sus nuevos puestos.


Página 289



Fecha 20/05/98


 Sugerencias documentadas para mejorar el proceso. 6.

Herramientas y técnicas  Técnicas de administración de proyectos.  Técnicas de gestión de cambios.


Página 290

Capítulo I – BIBLIOGRAFIA

MANUAL DE ADMINISTRACION DE PROYECTOS ANEXOS Sección Subsección --------------------------------------

Fecha 20/05/98


ANEXOS Bibliografía BEL, Juan de Dios, SIGEN, “ Auditoría Especializadas de Contrataciones Informáticas”, X Congreso Argentino de Informática, Buenos Aires, 1997. BURNETT, N y otros, “Prioridades y estrategias para la educación – Examen del Banco Mundial”, Publicación del Banco Mundial, Washington -EEUU, 1996 BURTON, Celia y MICHEL, Norma, “Guía Práctica para la Gestión por Proyecto”, Paidós, Barcelona – España, 1995. DINSMORE, Paul C., “Human Factors in Project Management”, American Management Associations, EEUU,1984. HAMMER, Michael & CHAMPY, James, “Reingeniería”, Trad. J. Nannetti, Grupo Editorial Norma, Colombia, 1994. HELMER, Olaf, “Systematic use of Expert Opinions”, Clearing House for Federal Scientific and Technical Information, 1967. HERSEY, Paul y BLANCHARD, K. H.; “The Management of Change”, Training and Development Journal”, Vol 26 Nros. 1,2 y 3, 1972. INFORMATION SYSTEMS AUDIT AND CONTROL ASSOCIATION (ISACA), “CISA 1997 - Manual de Revisión Certified Information System Auditor”, Trad. José L. Herrera, ADACSI, Buenos Aires, 1997. IRELAND, L., PIKE, W. y SCHROK, J., “Ethics for Project Managers”, PMI Seminar/Symposium on Project Manager, Canadá, 1982. KERZNER, Harold, “Project Management - A systems approach to planning, scheduling and controlling”, 5 ed., Van Nostrand Reinhold, EEUU, 1995 KNOWLEDGE BASED SYSTEM LABORATORY, “IDEF 4 Object Oriented Design Method Report –Information Integration for Concurrent Engineering”, Department of Industrial Engineering, 1991. KNOWLEDGE BASED SYSTEM LABORATORY, “IDEF3 Process Description Capture Method Report – Information Integration for Concurrent Engineering”, Department of Industrial Engineering, 1995.


Página 291



Fecha 20/05/98


MANGANELLI, Raymond y KLEIN, Mark, “Cómo hacer reingeniería”, Ed. 3, Trad. J. Nannetti, Grupo Editorial Norma, Colombia, 1996. MARTIN, James, y ODELL, James, “Análisis y Diseño Orientado a Objetos”, Trad. O. Velasco, Prentice Hall Hispanoamericana, México, 1994 METZGER, Philip W., “Managing a Programming Project”, 2 ed., Prentice Hall, Inc., EEUU,1981 MICHAEL, Andrews J., “Establishing PERT Systems”, Management Accounting, EEUU, 1971. MILLER, William B., “Fundamentals or Project Planning”, Journal of Systems Management, EEUU, 1978. PEREZ, Juan F., VEIGA, Carballo, “Control de la Gestión Empresarial”, Ed.2ª ampliada, ESIC Editorial, España, 1994 PETERSEN, Perry, “Project Control Systems”, Datamation, EEUU, 1979. PORTER, Michael E. , “Competitive Advantage”, Free Press, Nueva York, 1985. RANDOLPH, W. y POSNER, B.,” Effective Project Planning and Management”, Trad. J. Bravo, Prentice Hall Englewood Cliffs, EEUU, 1988. RICO, Rubén Roberto, “Calidad Estratégica Total – Total Quality Management”, 2ª ed, Ediciones Macchi, Buenos Aires, 1992. SCOTT, George, “Principios de Sistemas de Información”, Trad. P. Francés, Mc Graw Hill Interamericana de México, México, 1990 SUBSEC. DE TECNOLOGIA PARA EL SECTOR PUBLICO, “Estándares Tecnológicos de la Administración Pública”, Subsecretaría de Tecnología para el Sector Público - Secretaría de la Función Pública, 1995. U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM), “IDEF 0 – Integration Definition for Function Modeling”, Federal Information Processing Standards Publications (FIPS 183), 1993. U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM), “IDEF1 – Integration Definition for Information Modeling”, Federal Information Processing Standards Publications (FIPS 184), 1993.


Página 292




Fecha 20/05/98


Página 293

MANUAL DE ADMINISTRACION DE PROYECTOS.pdf

Recommend Documents