Sistemas de Información en la Empresa (Textos Universitarios Tecnología) (Spanish Edition) [1 ed.] 8415834330, 9788415834335

Citation preview

UAH

TEXTOS UNIVERSITARIOS TECNOLOGÍA

           Sistemas de Información en la Empresa

Luis F. Díaz Domínguez Miguel A. Navarro Huerga

UAH

TEXTOS UNIVERSITARIOS TECNOLOGÍA

Sistemas de Información en la Empresa

Sistemas de Información en la Empresa

SERVICIO DE PUBLICACIONES

Luis F. Díaz Domínguez Miguel A. Navarro Huerga

El contenido de este libro no podrá ser reproducido, ni total ni parcialmente, sin el previo permiso escrito del editor. Todos los derechos reservados. © Universidad de Alcalá Servicio de Publicaciones Plaza de San Diego, s/n 28801 Alcalá de Henares www.uah.es ISBN: 978-84-15834-33-5 Depósito Legal: M-36394-2013 Impresión y encuadernación: Imprenta de la UAH Impreso en España

Para Pilar, Marta, Marcus, Amalia y Sophia. Luis Díaz A mi familia, con los que siempre cuento. Miguel A. Navarro

7

8

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA ÍNDICE PRÓLOGO

13

1 LOS SISTEMAS EN LA EMPRESA Y LA ESTRATEGIA 1.1 EL SISTEMA DE INFORMACIÓN 1.2 CICLOS DEL SISTEMA DE INFORMACIÓN 1.3 LOS PROCESOS DE EMPRESA EN LA CADENA DE VALOR

15 16 21 33

2 NIVELES DE CONCEPCIÓN DEL SISTEMA DE INFORMACIÓN 2.1 MARCO METODOLÓGICO

27 27

3 DIAGNÓSTICOS 3.1 TIPOS DE DIAGNÓSTICOS 3.2 CONTEXTO Y OBJETIVOS DEL DIAGNÓSTICO 3.3 ESTRUCTURA DE UN DIAGNÓSTICO 3.4 DIAGNÓSTICO DEL SISTEMA DE INFORMACIÓN 3.5 DIAGNOSTICO DEL SISTEMA DE DESARROLLO 3.6 DIAGNÓSTICO DEL SISTEMA DE PRODUCCIÓN 3.7 PARTICIPANTES EN UN DIAGNÓSTICO 3.8 MÉTODO PARA PLANTEAR UN DIAGNOSTICO 3.9 INDICADORES 3.10 MODELO DE REFERENCIA 3.11 OPERATIVA DE LA REALIZACIÓN DE UN DIAGNÓSTICO 3.12 DOCUMENTACIÓN DE UN DIAGNOSTICO

29 30 30 31 34 34 35 35 36 40 43 44 47

4 EL PLAN DE SISTEMAS 4.1 NECESIDAD DE UN PLAN DE SISTEMAS 4.2 OBJETIVOS DEL PLAN DE SISTEMAS 4.3 PARTICIPANTES EN EL PLAN DE SISTEMAS 4.4 ESTRUCTURA Y DESARROLLO DEL PLAN DE SISTEMAS 4.5 SEGUIMIENTO Y ACTUALIZACIÓN DEL PLAN DE SISTEMAS

49 50 53 54 55 58

5 GESTIÓN DE PROYECTOS 5.1 ¿QUE ES UN PROYECTO? 5.2 ¿QUE ES LA GESTION DE UN PROYECTO? 5.3 ENTORNO DEL PROYECTO 5.4 DOCUMENTOS DE LA GESTION DEL PROYECTO 5.5 MORFOLOGIA DE UN PROYECTO 5.6 CAUSAS DE LOS FRACASOS DE LOS PROYECTOS 5.7 ESTRUCTURA DE UN PROYECTO 5.8 INICIO DEL PROYECTO 5.9 CUALIFICACIÓN DEL PROYECTO 5.10 DESARROLLO DEL PROYECTO 5.11 CIERRE DEL PROYECTO 5.12 METODO PERT

69 69 70 72 78 81 83 84 87 88 101 140 145

9

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA 6 LA FUNCIÓN DEL ANALISTA INFORMÁTICO 6.1 EL ANALISIS EN SU ENTORNO 6.2 BASES MÉTODOLOGICAS DEL ANÁLISIS

163 165 167

7 MODELIZACION DE DATOS 7.2 MODELO LOGICO DE DATOS - (MLD). ESTUDIO DE ACCESOS 7.3 MODELO FISICO DE DATOS ( MFD )

172 172 197 207

8 MODELIZACION DE TRATAMIENTOS 8.1 DIAGRAMA DE FLUJOS

216 216

7.1 MODELO CONCEPTUAL DE DATOS ( DIAGRAMA ENTIDAD-RELACION )

9 EL PROYECTO DE ANÁLISIS INFORMÁTICO 9.1 PLAN DE SISTEMAS 9.2 ESTUDIO PREVIO 9.3 ESTUDIO DETALLADO 9.4 ESTUDIO TÉCNICO

251 251 255 279 28787

10 DOCUMENTACIÓN DEL ANÁLISIS 10.1 DICCIONARIO DEL SISTEMA 10.2 DOCUMENTACIÓN DEL ESTUDIO PREVIO 10.3 DOCUMENTACÓN DEL ESTUDIO DETALLADO 10.4 DOCUMENTACIÓN DEL ESTUDIO TÉCNICO

295 295 301 305 307

11 RECURSOS DE CAPTACIÓN Y ORGANIZACIÓN DE DATOS

310

12 MÉTODOS DE ESTIMACIÓN DE CARGAS 12.1 MÉTODO COCOMO 12.2 MÉTODO DE MARCO 12.3 MÉTODO DE PUNTOS DE FUNCIÓN 12.4 MÉTODO DE WALSTON & FELIX 12.5 MÉTODO DE RUBIN 12.6 ALGORITMO DE ESTIMACIÓN DE CARGA EN FUNCIÓN DE LOS MODELOS 12.7 ESTIMACIÓN DE LOS COSTES DE DESARROLLO 12.8 MÉTODO PMC 12.9 MÉTODO BISAD 12.10 MÉTODO BISAD (COBOL)

333 333 334 334 335 335

13 ESTIMACIÓN DEL RIESGO

351

14 RECURSOS DE DOCUMENTACIÓN 14.1 INFORMES 14.2 MANUAL DE PROCEDIMIENTOS 14.3 GUÍA DE USUARIO 14.4 GUÍA DE OPERACIÓN 14.5 GUÍA DE INSTALACIÓN Y OPERACIÓN

374 374 375 378 380 385

10

336 341 342 345 348

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA 15 RECURSOS PARA LA DIRECCIÓN DE LOS SISTEMAS DE INFORMACIÓN 15.1 FACTORES CRÍTICOS DE ÉXITO 15.2 ANALISIS COSTE-BENEFICIO 15.3 PROCEDIMIENTO DE DECISIÓN MULTICRITERIO 15.4 ÁRBOLES DE DECISIÓN 15.5 SELECCIÓN DE HARDWARE / SOFTWARE 15.6 COSTES INFORMÁTICOS ( ADMINISTRACIÓN – MANTENIMIENTO ) 15.7 PERFILES PROFESIONALES EN LA INFORMÁTICA 15.8 CONTRATACIÓN EN LA INFORMÁTICA (OUTSOURCING) 15.9 PROCEDIMIENTO DE HOMOLOGACIÓN DE PROVEEDORES 15.10 PROCEDIMIENTO BENCHMARK 15.11 SISTEMAS DE SOPORTE A LA DECISIÓN 15.12 LA SEGURIDAD DEL SISTEMA DE INFORMACIÓN 15.13 PLAN DE CALIDAD PARA EL PROYECTO 15.14 AUDITORÍA INFORMÁTICA 15.15 CÓMO PREVENIR LOS PROBLEMAS EN LOS PROYECTOS

388 388 393 396 398 400 404 406 408 409 413 415 417 422 428 429

16 BIBLIOGRAFÍA

4366

11

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

PRÓLOGO Este libro reúne una serie de Métodos, Técnicas y Recursos para la Planificación, Diseño y Construcción del Sistema de Información de la Empresa. Los autores se basan en la experiencia adquirida desde hace 25 años en Grandes Empresas y en PYMES, en el desempeño de funciones de Consultoría, Análisis, Desarrollo y Gestión de Proyectos, sin olvidar que en todo ese itinerario profesional la Docencia ha ocupado una parte destacada en cuanto a la Formación Continua de Profesionales de diversos perfiles en el ámbito de la Empresa, así como a la Formación de Estudiantes y Actualización Profesional en otros ámbitos tales como la Universidad, la Escuela de Negocios y el Instituto de Educación Secundaria y Formación Profesional El Equipo Docente del Departamento de Ciencias de la Computación del Politécnico de la Universidad de Alcalá de Henares nos animó a la redacción de esta obra y nos orientó para que el contenido de la misma fuera adecuado a los objetivos de la asignatura Sistemas de Empresa que actualmente se imparte en el Grado de Informática de la Universidad de Alcalá de Henares. A todos ellos, nuestro agradecimiento.

13

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

14

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1

LOS SISTEMAS EN LA EMPRESA Y LA ESTRATEGIA

Las empresas modernas poseen y manejan unas enormes cantidades de informaciones que les permiten analizar los resultados obtenidos, tomar decisiones con rapidez y orientar sus estrategias convenientemente. Cuanto más evoluciona la empresa y hace frente a una mayor competencia, las informaciones que trata se vuelven más complejas, por lo que la organización de su Sistema de Información no debe dejarse al azar, sino que debe basarse en un estudio realizado con máxima seriedad y acompañado de una posterior reflexión. La informatización de una empresa es una acción estratégica que trata un recurso estratégico, como es la información, y por lo tanto, debe acometerse de manera reflexiva mejorando la calidad de los procesos estudiados y proporcionando un mejor nivel de servicio a sus usuarios. La concepción del Sistema de Información y su posterior aplicación, son factores determinantes en la estrategia de la empresa. El mecanismo mediante el cual se realiza dicha concepción del Sistema de Información es el Plan de Sistemas.

EL SISTEMA DE INFORMACION

15

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1.1

EL SISTEMA DE INFORMACIÓN

La noción de Sistema de Información proviene del concepto más general de Sistema, que puede definirse como el conjunto formado por: Una estructura que rige. Una actividad que transforma. Considerando que la empresa se comporta como un sistema, que denominaremos Sistema de Información y realizando una subdivisión más precisa en sus componentes, se puede considerar que el Sistema de Información es un trinomio constituido por: -

Una estructura de decisión. Una actividad transformadora u operante, concretada en un conjunto de Reglas de Gestión. Un conjunto de Informaciones.

Dicho sistema recibe unos estímulos exteriores concretados en "Solicitudes" y utilizando el conjunto de "Informaciones" patrimonio del sistema, según indican sus "Reglas de Gestión", elabora unos "Resultados" que son enviados al exterior. Por tanto, la percepción y representación de las informaciones necesarias, así como las reglas de utilización de esas informaciones por los actores implicados, determinan para la empresa su Sistema de Información. Los componentes del trinomio anteriormente mencionado, reciben el apelativo de subsistemas, convirtiéndose de esta manera en: -

Subsistema de Decisión. Subsistema Operante. Subsistema de Información.

El Subsistema de Información de una empresa asegura la sinergia entre su Subsistema de Decisión y su Subsistema Operante. El Subsistema de Información de la empresa se puede comparar con el sistema nervioso del cuerpo humano, siendo el Subsistema de Decisión el cerebro y el Subsistema Operante los músculos. Toda empresa posee un Subsistema de Información natural o real, los comportamientos usuales transforman los elementos de conocimiento existentes. Este subsistema se apoya en medios automáticos y humanos.

16

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La primera racionalización consiste en crear, a partir del Subsistema de Información natural, un sistema artificial. Los elementos de conocimiento se convierten en informaciones y los comportamientos usuales más frecuentes y estables se representarán mediante reglas de gestión.

Subsistema de Decisión. También denominado "Subsistema de Pilotaje" es el que rige la actividad de la empresa mediante: Elaboración de "Reglas de Gestión". Toma de decisiones.

Es el encargado de tomar en cuenta las "turbulencias" provenientes del exterior, como por ejemplo: Políticas de precios de los proveedores. Avances tecnológicos producidos en el mercado. Evolución de la competencia. Nuevas peticiones del mercado. Decisiones gubernamentales. Etc. Su objetivo es manejar la complejidad de los parámetros que rigen la empresa, integrarlos y elaborar las decisiones pertinentes y los planes de acción necesarios, haciéndolos ejecutar.

17

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Subsistema Operante. Transforma las solicitudes en resultados utilizando las reglas de gestión, siendo el subsistema de producción de la empresa. Ejecuta los planes de acción elaborados por el subsistema de pilotaje y asegura el funcionamiento armonioso de la producción, tanto en volumen como en calidad. Los subsistemas operante y de pilotaje se intercambian informaciones constantemente. Ejemplo: Los pedidos son transmitidos al subsistema operante, el cual a su vez suministrará los parámetros precisos para la toma de decisiones.

Subsistema de Información. Constituye la memoria colectiva de la empresa en cuanto a la información manejada, tanto operativa como estratégica. La misión principal del Subsistema de Información es hacer circular las informaciones en el seno de la empresa, teniendo una importancia estratégica fundamental. Ejemplo de utilización del Subsistema de Información por el Subsistema Operante. El vendedor de una sociedad recibe un pedido, el Subsistema de Información le facilita: Información que le permite determinar que el peticionario es un cliente nuevo. Información del descuento que puede aplicar en la venta. Posteriormente el Subsistema Operante enriquecerá al de Información suministrándole los datos del pedido recibido.

18

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Dominios de la empresa. Dentro de la estructura de una empresa podemos considerar una serie de "dominios" o conjuntos relativamente independientes entre si, caracterizados por los procesos de gestión que se desarrollan en su seno y por las informaciones que manejan. Dicho concepto de "dominio" permite estructurar un conjunto coherente, la empresa, pero de complejo manejo a la hora de ser estudiado, en una serie de subconjuntos más simples sobre los que deben tomarse decisiones de elección de soluciones de gestión, organización y técnicas en lo referente al futuro Sistema de Información. La necesidad de conservar una coherencia de conjunto, nos lleva a que la estructuración resultante de los distintos dominios presente un mínimo de intercambio de informaciones. Para realizar la estructuración antes mencionada, efectuaremos un triple análisis: Análisis de la actividad de producción del Subsistema Operante. Análisis de la actividad de gestión del Subsistema de Decisión. Análisis de la propiedad de las informaciones del Subsistema de Información. Cada dominio constituirá en si un Sistema de Información compuesto de los Subsistemas de Decisión, Operante e Información.

19

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La técnica utilizada para estructurar a la empresa en dominios, consiste en analizar el conjunto de los flujos de información distinguiendo entre los que: -

proceden del exterior. son internos. van al exterior.

Análisis del Subsistema Operante. El análisis del Subsistema Operante consiste en identificar los distintos flujos entrantes, circulantes y salientes de la empresa. Los flujos entrantes determinarán dominios primarios, y los flujos producidos identificarán dominios secundarios. La validación de los dominios así identificados, se realizará tras el análisis de los restantes subsistemas.

Análisis del Subsistema de Decisión. Con el análisis del Subsistema de Decisión se pretende destacar las grandes funciones de control (verificación de resultados) y de producción de los recursos que han sido identificados en el análisis del Subsistema Operante. Cada función de control determina un dominio candidato, de tal modo que los dominios identificados en el doble análisis podrán ser comparados. La validación de los dominios así determinados se realizara tras el análisis del Subsistema de Información.

Análisis del Subsistema de Información. Consiste en: -

Elaborar el modelo conceptual de datos con las entidades y relaciones principales de la empresa. Desglosar el modelo por cada dominio identificado en los pasos anteriores. Detectar los posibles puntos de conflicto en cuanto a la propiedad de la información, o de interrelación entre los modelos.

20

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para resolver las situaciones de conflicto que surjan se procederá a la redefinición de los dominios establecidos en los anteriores análisis.

1.2

CICLOS DEL SISTEMA DE INFORMACIÓN

En todo Sistema de Información se distinguen tres ciclos: -

Ciclo de Vida. Ciclo de Abstracción. Ciclo de Decisión.

Ciclo de Vida. El Ciclo de Vida divide en el tiempo la elaboración de un Sistema de Información en tres subciclos o etapas: -

Concepción (especificaciones funcionales y técnicas). Realización (programación y explotación). Mantenimiento (adecuación al entorno).

Cuando la evolución experimentada por el entorno es muy importante, se iniciará un nuevo Ciclo de Vida.

21

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Ciclo de Abstracción. Se divide a su vez en tres niveles: Nivel Conceptual. Trata de las informaciones y los procesos independientemente de las particularidades referentes a la organización o los medios utilizados. Responde a las preguntas: ¿Qué?, ¿Por qué?. Define los invariantes del Sistema. Nivel Organizativo o Lógico. Define la clasificación de las actividades a realizar entre mecánicas y manuales. Establece las unidades funcionales y geográficas o de ubicación encargadas de las distintas actividades, todo ello sin tener en cuenta los medios técnicos que van a entrar en juego. Responde a las preguntas: ¿Quién?, ¿Cuándo?, ¿Cómo?. Define la organización del Sistema. Nivel Físico. Selecciona los medios técnicos tanto materiales como inmateriales. Responde a la pregunta: ¿Cómo?. Define las elecciones técnicas. Ciclo de Decisión. La concepción de un Sistema de Información requiere la elaboración de escenarios alternativos y la toma de decisiones. Dichas decisiones, obedecen a ciertas reglas que constituyen un verdadero ciclo de decisión, en el curso del cual se define cada proyecto en lo que respecta a sus grandes líneas y después se subdivide en subconjuntos cuya realización es estudiada posteriormente. El Ciclo de Decisión permite establecer, jerarquizar y planificar las decisiones a tomar en los diferentes momentos y está íntimamente relacionado con los "hitos" del sistema o validaciones a realizar, y con el nivel de calidad alcanzado. CICLOS DEL SISTEMA DE INFORMACION DE VIDA Etapas: Plan de Sistemas (Empresa) Estudio Previo (Dominio) Estudio Detallado (Aplicación) Estudio Técnico (Aplicación) Realización Mantenimiento 22

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

DE ABSTRACCION Niveles de descripción: Conceptual (¿Qué?) Organizativo (¿Quién, Cuándo Dónde?) Físico (¿Cómo?) DE DECISION Validaciones Calidad

1.3

LOS PROCESOS DE EMPRESA EN LA CADENA DE VALOR

La cadena del valor es el conjunto de procesos de negocio que se desarrollan en la empresa y que contribuyen a la generación de valor. En general, encontramos primeramente todos los procesos relativos al abastecimiento de materias primas o de materiales y medios necesarios para la actividad productiva. Seguidamente, encontramos todos los procesos productivos, que constituyen la parte operativa de la empresa. Como resultado de los productos elaborados, tenemos los procesos de distribución y venta, que constituyen la actividad comercial de la empresa. Finalmente, encontramos las actividades y procesos relativos a la promoción de la empresa en el mercado y a la realización de servicios postventa. Pero hay procesos que abarcan y recubren toda la secuencia antes comentada. Se trata de los procesos de administración de la infraestructura de la empresa, la gestión financiera y económica, la gestión de los recursos humanos y las inversiones en investigación y desarrollo.

23

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

A modo de ejemplo. Se detallan algunos ejemplos típicos que encontramos en cada sector de la cadena de valor.

De cara a la realización de un Plan de Sistemas interesa conocer: a) cómo se distribuyen los procesos de empresa en la Cadena de Valor Añadido b) cuál es la contribución de las tecnologías de la información a los procesos Se trata de conocer la incidencia de las tecnologías de la información en la empresa o el grado de informatización. A modo de ejemplo, se enumeran a continuación una serie de procesos de la gestión de un hospital, clasificados de acuerdo con los grupos de procesos que establece la Cadena del Valor. ADMISIONES PLANIFICACION Y DISTRIBUCION DE PACIENTES . GESTION DE LISTAS DE ESPERA . MEDICINA Y CIRUGIA ( producción ) PLANIFICACION TAREAS ESPECIALISTAS .

24

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

PLANIFICACION OPERACIONES QUIRURGICAS . GESTION DE HOSPITALIZACION . SEGUIMIENTO DE UCI . SEGUIMIENTO DE URGENCIAS . PLANIFICACION SERVICIOS TRATAMIENTO . SERVICIOS MEDICOS CENTRALES DIAGNOSTICOS . MEDIOS VISUALES . ENDOSCOPIAS . HEMATOLOGIA . SERVICIOS APOYO ASIST. MEDICA ASIGNACION MAT Y UTIL ESTERILIZADOS . DISTRIBUCION FARMACOS . GESTION BANCO DE SANGRE . GESTION HISTORIALES CLINICOS . SERVICIOS GENERALES GESTION FUNCIONAMIENTO LAVANDERIA . PLANIFICACION COCINA . CREACION DIETAS . GESTION SERVICIOS LIMPIEZA . MANTº EDIFICIOS INSTALACIONES . ACTUALIZACION TECNOLOGICA ACTUALIZACION S.I.. ACTUALIZACION INSTRUMENTAL Y EQUIPOS . DISEÑO/ACTUALIZACION PROCEDIMIENTOS . ADMINISTRACION COORDINACION ENTRE DIVISIONES . FINANZAS Y CONTABILIDAD . ASPECTOS LEGALES . PLANIFICACION . PROCESO DATOS . CONTROL GESTION . ABASTECIMIENTO Y PROVEEDORES APROV. MATERIALES SANITARIOS . APROV. BANCOS DE SANGRE . APROV. FARMACOS . APROV. LAVANDERIA . APROV. COCINA . APROV. MANTENIMIENTO . 25

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

APROV. LIMPIEZA . APROV. ENERGIA . ACTIVIDADES DE GESTION DE RECURSOS HUMANOS SEGUIMIENTO CURRICULA MEDICOS . SEGUIMIENTO CURRICULA ATS . SEGUIMIENTO CURRICULA AUXILIARES . GESTION COMPENSACIONES MEDICOS . GESTION COMPENSACIONES ATS . GESTION COMPENSACIONES AUXILIARES . FORMACION MEDICOS . FORMACION ATS . FORMACION AUXILIARES . CONTRATACIONES . MARKETING Y VENTAS GESTION ACUERDOS INSALUD/SERV.REG.SALUD . GESTION ACUERDOS CIAS SEGUROS . GESTION ACUERDOS MEDICOS . PROMOCION . RELACIONES PUBLICAS . B. D. BUSQUEDA CLIENTES .

26

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

2

NIVELES DE CONCEPCIÓN DEL SISTEMA DE INFORMACIÓN

El Plan de Sistemas es un instrumento de información, formulación y diagnóstico sobre la situación actual. Proporciona la oportunidad de proceder a la reformulación de las misiones y atribuciones de la organización y de los medios con los que cuenta, así como de realizar la descripción de los Sistemas de Información, de Gestión y de ayuda a la Decisión de la Empresa, revisando: -

Los Procesos fundamentales de Gestión. Los circuitos de Información entre los diferentes Departamentos. Las Aplicaciones Informáticas que tratan y estructuran las informaciones básicas.

El Plan de Sistemas es un instrumento de previsión que presenta la estrategia destinada a acompañar la política general de la Empresa, así como a satisfacer los objetivos globales fijados. Para ello, se elaboran diferentes supuestos de evolución del Sistema de Información denominados "Escenarios", y que tienen en cuenta: -

La "cultura empresarial" existente. Las necesidades y objetivos globales a alcanzar. La evolución tecnológica.

Mediante el estudio de las ventajas y riesgos relacionados con las diversas soluciones propuestas, se escoge un "Escenario" de evolución del Sistema de Información, y se planifican unos Planes de Acción. Estos planes contienen la logística y cuantifican los recursos necesarios, tanto en personal como en material, para realizar los desarrollos pertinentes, así como las prioridades, fechas de terminación, restricciones, riesgos económicos etc. Por último, el Plan de Sistemas es una herramienta viva de puesta en marcha y de seguimiento del desarrollo de los Sistemas de Información y de Gestión.

2.1

MARCO METODOLÓGICO

Dentro del marco metodológico del Sistema de Información, el Plan de Sistemas ocupa una posición central puesto que es el corazón alrededor del cual gira el resto. 27

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El marco consta de tres niveles o estratos: - Diagnósticos. - Plan de Sistemas. - Ingenierías.

- Diagnósticos. Para conocer en los distintos campos la situación actual de la empresa. Desembocan en propuestas de acción (Plan de Sistemas o Ingenierías). El diagnóstico del Sistema de Información traduce en objetivos del Sistema de Información los objetivos generales de la empresa, estudia el grado de adecuación del Sistema de Información actual a dichos objetivos y eventualmente orienta sobre la conveniencia de realizar un diagnóstico más específico o un Plan de Sistemas. El resto de los Diagnósticos trata sus temas específicos (redes, usuario final, desarrollo, producción), finalizando con un balance de puntos fuertes y débiles y con una serie de orientaciones de acción. - Plan de Sistemas. Para prever y planificar el desarrollo de los sistemas de información, definiendo a medio y largo plazo, los recursos a utilizar y la política presupuestaria correspondiente. Describe un objetivo en forma de dominios de informatización, arquitecturas técnicas, medios humanos y herramientas de desarrollo. 28

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Ingenierías. Para desarrollar las soluciones propuestas en el Plan de Sistemas o en los diagnósticos. Existen tres tipos de ingenierías: * Informática de Usuario (IU). Los proyectos IU persiguen como resultado la implantación de sistemas de información personal, y de clasificación o mensajería. * Ingeniería informática. Desarrolla los sistemas informáticos de vocación colectiva, llamados sistemas de producción. Se ejerce sobre campos definidos por el plan informático obtenidos generalmente como resultado de un Plan de Sistemas. * Ingeniería de redes. Sigue unos pasos similares a los de la ingeniería informática. Contempla los factores siguientes: . Arquitectura. . Entornos. . Software de comunicaciones. . Gestión de redes. . Prestaciones, mantenimiento, seguridad etc.

3

DIAGNÓSTICOS

Un diagnóstico es la constatación de una situación, habida cuenta la existencia de unos objetivos en la Empresa. El diagnóstico tiene como finalidades: - Identificar disfunciones en un determinado área, según determinados modelos de referencia y criterios de evaluación adecuados al mismo. - Recomendar acciones, que pueden ser la realización de un esquema director o acaso uno o varios proyectos. Conviene resaltar la diferenciación de un diagnóstico frente a otro tipo de estudios que se realizan en las empresas: Un Diagnóstico es la identificación de problemas, que permite establecer un juicio sobre una situación o estado.

29

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Mientras que: Una Evaluación consiste en la determinación del valor, precio, o importancia de algo. Una Auditoria es un procedimiento de control de la consecución de los objetivos de una empresa. También es necesario situar, en el área de la estrategia informática, al Diagnóstico con respecto al Esquema Director

FINALIDAD DE UN DIAGNOSTICO - Exploración - Identificación de problemas - Propuesta de estudios para resolverlos - No hay un verdadero plan de acción, solo orientaciones - Operativa sintética

3.1

FINALIDAD DE UN ESQUEMA DIRECTOR -Planificación - Propuesta de soluciones - Elección de una solución - Se formaliza un plan de acción - Operativa analítica

TIPOS DE DIAGNÓSTICOS

Según la extensión o las áreas funcionales de empresa que cubren, los diagnósticos pueden ser del - Sistema de Información, en un sentido amplio - Sistema de Desarrollo - Sistema de Producción - Sistema de Usuario - Sistema de Redes y Comunicaciones - Sistema Informático de Control Contable - Sistema de Seguridad del S.I.

3.2

CONTEXTO Y OBJETIVOS DEL DIAGNÓSTICO

El contexto del Diagnóstico es el propio ámbito de la Empresa; más concretamente situado en los dominios de Gestión y Realización, así como en el Sistema de Información.

30

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Se define como Dominio de Gestión el conjunto de actividades realizadas en el seno de la Empresa, encaminadas al planteamiento de la estrategia y control de la consecución de los objetivos Se define como Dominio de Realización el conjunto de actividades de desarrollo y productivas que posibilitan la consecución de los objetivos. Se define como Sistema de Información el conjunto de informaciones que entran, son tratadas y salen de la Empresa. Desempeña, por tanto, un papel imprescindible de comunicación entre los dominios de Gestión y de Realización. Los objetivos de un Diagnóstico son los de resaltar los puntos fuertes y débiles del funcionamiento de un Sistema implantado en la Empresa, con vistas a su mejora.

3.3

ESTRUCTURA DE UN DIAGNÓSTICO

Un diagnóstico se plantea de acuerdo con la siguiente estructura -Estudio de lo existente -Señalización de puntos fuertes y débiles -Recomendación de acciones

31

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Estudio de lo existente Supone, por una parte, el acopio de datos sobre la situación ideal de funcionamiento del Sistema en cuestión, con el fin de disponer de un patrón comparativo.

Por otro lado, se trata de constatar aspectos tales como: - La situación externa e interna de la empresa. Oportunidades y amenazas que existen en su entorno. - Las políticas principales de la empresa. Objetivos planteados y resultados obtenidos. - Las formas de actuación. Por ejemplo, la forma de acometer determinado sector del mercado. - Los niveles organizativos y sociales, Estructuras operativas y recursos humanos. - El Sistema de Información. Forma en la que fluye la información en el seno de la empresa. La aparición de nuevas tecnologías de la información, las condiciones organizativas de la propia empresa o su situación financiera, son puntos importantes a tener en cuenta en el estudio de la situación existente. Señalización de puntos fuertes y débiles Como resultado del estudio de la situación existente, el Diagnóstico resalta posibles disfunciones. Ejemplos de ello pueden ser: - Inadecuada gestión de peticiones y de respuestas en el diálogo con los usuarios. - Planificación incorrecta de los proyectos. - Necesidad de responder a las demandas prioritarias, aun en detrimento de la gestión racional de los procesos. - Deficiencias en la formalización y especificación de los procedimientos - Indefinición de funciones o responsabilidades - Problemas en el seguimiento de las acciones De la conjugación de puntos fuertes y débiles surge una serie de necesidades a cubrir y las correspondientes acciones a emprender

32

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

PUNTOS FUERTES

PUNTOS A M EJORAR

NECESIDADES

ACCIONES

-----------

-----------

-----------

-----------

-----------

-----------

-----------

-----------

-----------

-----------

-----------

-----------

. . . .

. . . .

. . . .

. . . .

----------

----------

----------

----------

Recomendación de acciones Como consecuencia de la elaboración de una lista de necesidades y acciones de mejora, se forman diversos escenarios o alternativas de acción, que plantean dichas mejoras en función de diferentes criterios y parámetros. De entre estos escenarios se debe elegir el óptimo, según las posibilidades y restricciones. Las acciones derivan de recomendaciones funcionales u organizativas. Pueden contemplar rediseño de procesos, planteamiento de nuevos proyectos o cambio de prioridad en la planificación de los proyectos existentes.

Habiéndose contemplado cualquier conjunto de acciones dentro de la estructura de proyecto, hay que realizar una planificación de tareas, teniendo en cuenta sus correspondientes prioridades. 33

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3.4

DIAGNÓSTICO DEL SISTEMA DE INFORMACIÓN

El Sistema de Información, definido anteriormente, se estudia a través de los recursos (materiales, lógicos, organización) necesarios para los tratamientos (recogida, transmisión, transformación, almacenaje) a los que se someten los diferentes tipos de datos manejados por la Empresa. Los datos tratados pueden ser de diferente naturaleza: Colectivos, individuales, estructurados, informales, etc. Los tratamientos pueden ser de diferentes tipos: Repetitivos, aleatorios, productivos, informativos, imprevistos, etc.

predeterminados,

Los recursos utilizados pueden ser, asimismo, de varias clases: Centralizados, descentralizados, compartidos, afectados, etc. Los objetivos contemplados en la realización de un Diagnóstico del Sistema de Información de una Empresa son: -Determinar las líneas de evolución de los dominios de actividad considerados críticos. -Determinar la capacidad de la Empresa para aceptar cambios. -Examinar la dinámica de la planificación y las estructuras de control. -Analizar el Sistema de Información actual calificándolo en relación con su adecuación a los objetivos y orientaciones estratégicas de la Empresa. -Elaborar un plan de acción para estudios posteriores, ya sean Diagnósticos específicos, Ingenierías de Proyectos, Auditorías, o un Esquema Director.

3.5

DIAGNOSTICO DEL SISTEMA DE DESARROLLO

El Sistema de Desarrollo es el conjunto de medios organizativos, humanos y técnicos que permite concebir, realizar y hacer evolucionar el sistema informático de producción. El Diagnóstico del Sistema de Desarrollo permite responder a las necesidades en materia de: - Equipo y medios de Desarrollo - Métodos de desarrollo - Métodos de Gestión de Proyectos - Organización (estudios, relación entre usuarios y producción) 34

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Productividad y calidad en el desarrollo Los objetivos de dicho diagnóstico son: - Analizar el estado del Sistema de Desarrollo - Deducir puntos fuertes y débiles por comparación con un modelo de referencia, de acuerdo con los siguientes aspectos: Organización Productividad Calidad Adecuación a objetivos Evolutividad Capacidad de gestión - Recomendar acciones 3.6

DIAGNÓSTICO DEL SISTEMA DE PRODUCCIÓN

El Sistema de Producción está constituido por el conjunto de medios y recursos (humanos, organizativos, técnicos), que aseguran la ejecución de los procesos productivos de la Empresa, a fin de obtener los productos previstos. Los objetivos del Diagnóstico de Producción son: - Hacer una composición del estado general del Sistema Informático de Producción. - Determinar sus puntos fuertes y sus puntos a mejorar - Dar recomendaciones de acciones referentes a la gestión, la evolución y la adaptación del Sistema Informático de Producción a las necesidades de la Empresa. 3.7

PARTICIPANTES EN UN DIAGNÓSTICO

Consultor (interno o externo) Realiza el estudio Propone acciones Redacta el informe del Diagnóstico Lleva a cabo el seguimiento de las recomendaciones Para ello, efectúa Evaluación de la situación existente Entrevistas Análisis de documentos 35

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Redacción y presentación del informe de diagnóstico Dirección ejecutiva Como promotor, se responsabiliza de Validación de la propuesta Anuncio a la organización Aprobación del informe de diagnóstico Decisión sobre las recomendaciones Como coordinador, se responsabiliza de Planificación de entrevistas Acopio de documentos a analizar Diálogo con el consultor Participantes de la empresa Pueden ser entrevistados, según los casos, los siguientes responsables Promotor Responsable Financiero Responsable de Organización/Métodos Responsable de Informática Jefes de Proyectos de Desarrollo Responsable de Producción Responsables de Usuarios

3.8

MÉTODO PARA PLANTEAR UN DIAGNOSTICO

Un modelo es una representación de algún aspecto del Sistema considerado, que ha de servir de medio de análisis, estudio y comunicación entre los participantes en el diagnóstico. El modelo de representación empleado en un diagnóstico de un sistema se basa en un conjunto de ejes cuantificables, cada uno de ellos asociado a un tema de estudio. En cada eje se sitúan dos medidas, la de la situación observada y la de la situación de referencia. En una primera aproximación, podemos considerar los siguientes ejes de estudio que corresponden al Sistema de Información, en su globalidad.

36

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Como cada eje es cuantificable, podemos representar en él la medida realizada para cada tema de estudio. Uniendo dichos puntos obtenemos una línea poligonal cerrada que da idea del perfil de la empresa en cuanto a la situación real observada. Utilizando el mismo procedimiento, representamos también las medidas ideales en cada eje. Uniendo los puntos obtenemos otra poligonal cerrada que representa la situación ideal en la que se debería encontrar la empresa. La superposición de las dos poligonales nos da, de forma resumida, una comparación entre ambos perfiles, destacándose los aspectos en los cuales la empresa presenta ventaja o desventaja respecto a una situación de referencia. ORGANIZAC IÓN

IDE AL FINANZ AS

TÉCNI CA

OBSERVA DO FUNCIONALIDA DES 37

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Este diagrama proporciona una visión resumida, integrando los resultados globales de unas medidas y comparaciones que se detallan por otros procedimientos. Para llegar al resultado del diagnóstico, será preciso realizar una serie de entrevistas y encuestas, recopilar información y llevar a cabo una estructuración; todo ello como paso previo al análisis de la información. Para el Sistema de Desarrollo, el conjunto de ejes sería:

ORGANIZACION

CAPACIDAD DE GESTION

EVOLUTIVIDAD

ADECUACION A OBJETIVOS

PRODUCTIVIDAD

CALIDAD

Igualmente, el Sistema Informático de Producción debe estudiarse en función de los siguientes ejes:

38

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La situación de referencia se deduce a partir de un conjunto de indicadores formados por cifras, ratios, tendencias, datos de la empresa, etc, que permite dar una medida o puntuación a cada tema de estudio representado en su correspondiente eje. La situación observada es otra medida o puntuación en los ejes del modelo de representación, de acuerdo con la realidad observada.

Las puntuaciones pueden hacerse en valores porcentuales o absolutos. En el caso de los valores absolutos se puede elegir los valores: 0 = nulo 1 = débil 2 = medio 3 = bueno 4 = fuerte Una vez situadas las medidas de las situaciones observada y de referencia en los diversos ejes, el sistema de representación nos permite deducir puntos fuertes y puntos débiles en los diferentes temas considerados. Ello permite una visión de síntesis del diagnóstico del sistema considerado y disponer de criterios que permitan juzgar la situación. 39

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3.9

INDICADORES

Seguidamente, se dan algunos indicadores que pueden orientar para los diversos temas de estudio Sistema de Información Funciones Organización Técnica Economía

Sistema de Desarrollo Organización Capacidad de gestión Evolutividad Adecuación Productividad Calidad Sistema de Producción Producción Organización Calidad de servicio Gestión Mantenibilidad Seguridad Convivialidad Adecuación Sistema de Usuarios Productividad Calidad Puestos de trabajo Sistema de Redes y Comunicaciones Adecuación Rentabilidad Fiabilidad servicio Organización Convivialidad Seguridad 40

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Prestaciones Administración Calidad de servicio Evolutividad Operabilidad Mantenibilidad Sistema Informático de Control Contable Métodos Medios de trabajo Organización Privacidad y seguridad de los datos Recursos humanos y relaciones con usuarios Entorno jurídico Sistema de Seguridad Informática Entorno Organización Utilización Soporte Comunicaciones Medios Productos Mantenimiento En el caso del Diagnóstico del Sistema de Desarrollo, las consideraciones a realizar sobre los aspectos de estudio son: - Organización Constataciones a efectuar: .Definición de objetivos, funciones. .Diferenciación entre Desarrollo y Producción .Conexión Desarrollo/Usuarios .Funcionalidades del Sistema de Desarrollo .Aptitud de la organización hacia la evolución Posibles recomendaciones: .Servicios de diagnósticos, asesorías, formación, asistencia .Procedimientos de conexión entre desarrollo y producción .Definición de cuadernos de desarrollo y producción

41

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Calidad Constataciones a efectuar: .Planificación y coherencia de los productos .Procedimientos de gestión de proyectos .Adecuación a las necesidades de los usuarios .Calidad de la documentación .Aplicación de métodos de concepción, realización y gestión de proyectos .Implicación de los usuarios en los proyectos .Normalización de los productos desarrollados Posibles recomendaciones: .Servicios de Implantación de metodologías, concepción, realización y gestión de proyectos .Asistencia a un proyecto piloto

- Productividad Constataciones a efectuar: .Empleo de herramientas de modelización de los procesos productivos, gestión de proyectos, documentación .Coherencia entre herramientas y sistemas productivos .Inversiones y costes .Herramientas de medida .Herramientas de seguimiento productivo Posibles recomendaciones: .Deducir tipos de necesidades .Asistencia a la definición e implantación de un entorno de desarrollo .Diagnóstico del sistema de producción

- Adecuación a los objetivos Constataciones a efectuar: .Adecuación del sistema de desarrollo en cuanto a objetivos de la empresa, necesidades de los usuarios, sistema de información, y cartera de desarrollo Posibles recomendaciones: .Seminario sobre el sistema de desarrollo en la estrategia de la empresa .Diagnóstico del Sistema Productivo .Realización de un Esquema Director 42

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Evolutividad Constataciones a efectuar: .Adecuación del personal a las funciones que realiza .Adecuación del personal a las funciones a realizar .Nivel de conocimientos, cultura .Nivel de formación .Aptitud para la evolución en cuanto a la técnica, organización, desarrollos, comunicación Posibles recomendaciones: .Seminario sobre el sistema de desarrollo en la empresa .Formación sobre marco metodológico, estudios de oportunidad, gestión de proyectos - Capacidad de gestión Constataciones a efectuar: .Control y seguimiento de costos de desarrollo y producción .Niveles de inversión en desarrollo Posibles recomendaciones: .Implantación de procedimientos de control de desarrollo y producción .Implantación de gestión de proyectos en cuanto a formación, métodos de estimación, planificación y seguimiento

3.10

MODELO DE REFERENCIA

Son elementos del modelo de siguientes conceptos Cifras Criterios Ratios Tendencias Situación de la empresa

referencia

A los cuales corresponden las puntuaciones 0 = nula 1 = débil 2 = media 3 = buena 4 = fuerte 43

los

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

A modo de ejemplo, se dan algunos conceptos que forman parte del modelo de referencia del sistema de desarrollo -

Mantenimiento de las aplicaciones Turn-Over de las inversiones en desarrollo Ratios de productividad del desarrollo Efectivos informáticos Censo de aplicaciones Duración de la vida de las aplicaciones Grado de informatización de la empresa Prioridades de la dirección informática Esquema Director y Plan Informático Métodos de desarrollo del sistema de información Composición del departamento de desarrollo Lenguajes y herramientas de desarrollo empleados Tendencias constatadas Presupuesto informático Gastos e inversiones

El consultor proporcionará, en todo caso, los conceptos necesarios al modelo de referencia, en función de su experiencia. 3.11

OPERATIVA DE LA REALIZACIÓN DE UN DIAGNÓSTICO

La realización de un diagnóstico, enfocada como un proyecto, se estructura en etapas, fases y actividades. Dicha estructura se resume en el siguiente diagrama. Proyecto Diagnóstico

Etapas PREPARACION

Fases PLANIFICACION Y LANZAM IENTO

ENTREVISTAS Y ANALISIS DE DOCUM ENTOS DIAGNOSTICO

DESARROLLO SINTESIS Y VALIDACION

INFORM E DEL DIAGNOSTICO CONCLUSION APROBACION SEGUIM IENTO

44

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Etapa de Preparación Fase: Planificación y lanzamiento Documentos de partida: Propuesta. Evaluaciones previas. Esquema director Tareas: -Planificación en función de objetivos .Criterios a analizar .Evaluación de Tiempos y Cargas .Participantes a entrevistar .Documentos a analizar -Elección del responsable de ejecución del diagnóstico -Lanzamiento del diagnóstico Resultados: -Cuestionario de informaciones generales -Plan de diagnóstico -Plan de entrevistas -Comunicación a la organización

Etapa de desarrollo Fase: Entrevistas y análisis de documentos Documentos de partida: -Plan de diagnóstico. Planes de entrevistas. Documentos de empresa. Tareas: -Análisis de los documentos -Realización de entrevistas -Síntesis -Controles Resultados -Síntesis de entrevistas -Síntesis del diagnóstico

45

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Fase: Síntesis y validación Documentos de partida: - Síntesis del diagnóstico Tareas: -Síntesis, incluyendo puntos fuertes, puntos débiles, necesidades y acciones de mejora -Validación por parte del promotor y del responsable del diagnóstico Resultados: -Síntesis validada del diagnóstico

Etapa de conclusión Fase: Informe del diagnóstico Documentos de partida: -Síntesis validada del diagnóstico

Tareas: -Redacción del informe de diagnóstico Resultados: -Informe de diagnóstico Fase: Aprobación y seguimiento Documentos de partida: -Informe de diagnóstico Tareas: -Validación del diagnóstico -Planificación de acciones Resultados: -Informe validado del diagnóstico

46

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3.12

DOCUMENTACIÓN DE UN DIAGNOSTICO

-Cuestionario de informaciones generales .Descripción general de la empresa .Organización de la empresa .Medios del sistema de desarrollo .Productos .Cartera de desarrollos -Documentos de referencia .Plan de negocio .Organigramas (empresa, dep. desarrollo, dep. producción, etc) .Planes de desarrollo .Configuraciones de sistemas (informática, dep. usuarios, redes) .Balance de la empresa -Plan de diagnóstico -Plan de entrevistas -Síntesis de entrevistas -Comunicación a la organización -Síntesis del diagnóstico -Informe del diagnóstico A modo de ejemplo, se indican los epígrafes del cuestionario del sistema de desarrollo, utilizado en las entrevistas con los responsables del departamento de desarrollo, a fin de recoger la información necesaria para efectuar el análisis de la situación existente

47

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

CUESTIONARIO DEL DIAGNOSTICO DEL SISTEMA DE DESARROLLO ..

..

..

..

.. ..

..

ORGANIZACION DEL CENTRO DE DESARROLLO CONTEXTO FUNCIONES COSTES DE DESARROLLO PLANIFICACION Y COHERENCIA DE PROYECTOS ESTRUCTURACION DE LOS CICLOS DE DESARROLLO OPERATIVA CUADERNOS COHERENCIA CUADERNOS/METODOLOGIAS CONCLUSION METODOS Y TECNICAS DE DESARROLLO METODOS DE DESARROLLO UTILIZADOS TECNICAS DE DESARROLLO CONCLUSION METODOS DE GESTION DE PROYECTOS DE DESARROLLO ASPECTOS TECNICOS ASPECTOS RELACIONALES RELACIONES CON EL SISTEMA DE DESARROLLO PLAN DE CALIDAD CONCLUSION HERRAMIENTAS DE INGENIERÍA DE HERRAMIENTAS LIGADAS AL CICLO DE VIDA DICCIONARIO DE TERMINOS HERRAMIENTAS DE GESTION DE PROYECTOS SISTEMAS INFORMATICOS CONCLUSION EQUIPOS PARA EL DESARROLLO CONFIGURACION DE LOS EQUIPOS DE DESARROLLO PRODUCTOS DESARROLLADOS CARACTERISTICAS COHERENCIA DE LOS PRODUCTOS DESARROLLADOS PREGUNTAS SATISFACCION COSTES DESARROLLO DE UN PRODUCTO ASPECTOS ORGANIZATIVOS HERAMIENTAS DE DESARROLLO ASPECTOS TECNICOS ADECUACION A NECESIDADES USUARIOS SEGURIDAD DEL PRODUCTO PRESTACIONES DEL PRODUCTO

48

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En la figura, un ejemplo de utilización de hoja de cálculo para integrar los datos correspondientes a uno de los criterios de análisis (organización del centro de desarrollo) del diagnóstico del sistema de desarrollo. ORGANIZACION DEL CENTRO DE DESARROLLO .. NOTA C.F. .. ORG CAL PRO ADE EVO GES .. S-ORG S-CAL S-PRO S-ADE S-EVO S-GES CONTEXTO Estructura de organización (proyectos, pool ) Tipo de organización (centralizada, distribuida ) Relación Desarrollo/Organización Relación Desarrollo/Explotación Relación Desarrollo/Usuarios Tasa de desarrollo de nuevos proyectos Tasa de mantenimiento correctivo de aplicativos Tasa de mantenimiento evolutivo de aplicativos Tasa de recurrencia al Sistema de Información Relación Desarrollo/Sistema de Información Grado de satisfación Desarrollo/Sistemas de Inform. Adecuación Desarrollo/Contexto empresa

2 2 2 2 2 2 2 2 2 2 2 2

1 1 1 1 1 1 1 1 1 1 1 1

1 1 0,7 0,3 1 1 0,7 0,7 1 1 1 1

0 0,7 0,3 0,7 0,7 0,3 0,7 1 0,7 1 0,7 0,7

0,7 0 0,3 0,7 0,7 0 0 0,7 1 0 0 0,7 1 0 0 0,7 0 0 0 0,7 0 0 0 0,7 0 0 0 0,7 0 0 0 0,7 0 0 0 0,7 0 0 0 0,7 0,7 0 0 0,7 0,3 0,3 0 0,7

2 2 1,4 0,6 2 2 1,4 1,4 2 2 2 2

0 1,4 0,6 1,4 1,4 0,6 1,4 2 1,4 2 1,4 1,4

1,4 1,4 2 2 0 0 0 0 0 0 1,4 0,6

0 0 0 0 0 0 0 0 0 0 0 0,6

0,6 0 0 0 0 0 0 0 0 0 0 0

1,4 1,4 1,4 1,4 1,4 1,4 1,4 1,4 1,4 1,4 1,4 1,4

10,4 7,5 4,4 0,3 0,3 8,4

20,8

15

8,8

0,6

0,6

16,8

41,6 30 17,6 1,2 1,2 33,6 %-ORG %-CAL %-PRO %-ADE %-EVO %-GES 50 50 50 50 50 50

La tabla sirve para comparar las puntuaciones obtenidas en las observaciones de los diversos criterios con las puntuaciones asignadas al modelo de referencia.

4

EL PLAN DE SISTEMAS

El Plan de Sistemas es el instrumento que permite establecer las bases del diseño del futuro sistema de información a partir de la situación actual y de los objetivos que ha de cumplir. Proporciona la oportunidad de proceder a la reformulación de las misiones y atribuciones de la organización y de los medios con los que cuenta, así como de realizar la descripción de los Sistemas de Información, de Gestión y de Ayuda a la Decisión de la Empresa. Para ello, revisa: Los procesos fundamentales de gestión. Los circuitos de Información entre los diferentes departamentos. Las aplicaciones informáticas que estructuran y tratan informaciones básicas.

49

las

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El Plan de Sistemas es un instrumento de previsión que presenta la estrategia destinada a acompañar la política general de la empresa, así como a satisfacer los objetivos globales fijados. Para ello, se elaboran diferentes supuestos de evolución del Sistema de Información denominados escenarios, y que tienen en cuenta: La "cultura empresarial" existente. Las necesidades y objetivos globales a alcanzar. La evolución tecnológica. Mediante el estudio de las ventajas y riesgos relacionados con las diversas soluciones propuestas, se escoge un escenario de evolución del Sistema de Información, y se establecen unos Planes de Acción. Estos planes contienen la logística y cuantifican los recursos necesarios, tanto en personal como en material, para realizar los desarrollos pertinentes, así como las prioridades, fechas de terminación, restricciones, riesgos económicos etc. Por último, el Plan de Sistemas es una herramienta viva de puesta en marcha y de seguimiento del desarrollo de los Sistemas de Información y de Gestión.

4.1

NECESIDAD DE UN PLAN DE SISTEMAS

Las empresas se enfrentan a una serie de desafíos impuestos por el entorno que las rodea y entre los que podemos citar: El avance experimentado por las tecnologías de la información. La reducción de costes para mejorar el grado de competitividad. La necesidad de conseguir diferenciarse de la competencia. Tecnologías de la información: Las informaciones que fluyen en el seno de la empresa han sufrido una espectacular evolución, de tal modo que se encuentran presentes en prácticamente todas las actividades desarrolladas, habiendo adquirido una importancia estratégica por lo que su gestión no puede ser patrimonio exclusivo de la Dirección de Informática, sino que la responsabilidad de su puesta en marcha debe de ser compartida por otros estamentos y principalmente por la Dirección General. Estas tecnologías, siempre en evolución, sirven para manejar y dominar, de una manera más completa, las informaciones necesarias para el correcto 50

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

funcionamiento de la empresa. Asimismo muchas de estas tecnologías han surgido como respuesta a nuevas necesidades que han ido apareciendo. Algunas de estas necesidades se ponen de manifiesto al analizar la evolución experimentada por las aplicaciones informáticas. Se observa una disminución en las aplicaciones de tipo operativo caracterizadas por tareas repetitivas y un aumento de las aplicaciones de ayuda a la gestión (relacionadas con controles, organización etc.) y de ayuda a la decisión. Por otro lado, las aplicaciones evolucionan cada vez más rápidamente para adaptarse a las modificaciones experimentadas por el entorno y el mercado, por lo que el trabajo de mantenimiento a realizar es cada vez mayor llegando a colapsar las posibilidades del Dpto. de Informática. Esto significa que puede atenderse a un porcentaje muy bajo de las necesidades de informatización expresadas por los usuarios. Todo ello se traduce en unos requerimientos de documentación muy detallada, modularidad de sistemas y programas con objeto de poder reutilizar partes de ellos, independencia de programas y datos, mayor autonomía de los usuarios a la hora de poder satisfacer sus demandas etc. La mayor parte de los problemas enunciados pueden ser solventados mediante la adopción de diversas tecnologías informáticas de creciente implantación. Aumento de productividad del Dpto. de Desarrollo. Tecnologías relacionadas con herramientas de ayuda al análisis, diseño desarrollo y productoras de documentación basadas en metodologías de análisis. Autonomía de los usuarios. Tecnologías relacionadas con la informática personal, distribuida y de ayuda a la decisión, que permitan a los usuarios el acceso directo a la información y su posterior manipulación de forma autónoma. Seguimiento detallado de los proyectos en ejecución. Mediante la utilización de alguna herramienta de planificación de tareas y recursos que permita un seguimiento exhaustivo de la marcha de los proyectos para poder corregir sus desviaciones antes de que sea demasiado tarde.

51

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Reducción de costes: La batalla por la reducción de los costes resulta fundamental para la competitividad de las empresas, e incluso para su supervivencia. Esta reducción se puede intentar por varias vías: Mejorar la productividad del personal mediante la eliminación de circuitos de información redundantes o ineficaces. Mejorar la productividad financiera mediante la agilización de los circuitos de envíos-facturación, reagrupamiento de las compras, seguimiento puntual del curso de las materias primas etc. Optimizar el nivel de stocks. Optimizar y flexibilizar las instalaciones. Uso de energía, logística, medios de producción, útiles informáticos (tanto máquinas, como redes, aplicativos etc.). Minimizar los riesgos mediante la mejora de la calidad de concepción, fabricación, control de las desviaciones, detección del riesgo de los clientes etc.). Optimizar las tareas de control, seleccionando las inversiones en I+D, controlando el circuito de: previsiones de ventas-programa de compras-aprovisionamientos-fabricación-distribución-venta, mejorando la gestión de los recursos humanos, realizando simulaciones estratégicas etc.).

Diferenciación respecto a la competencia: Siendo la competencia en los distintos sectores cada vez más enconada, resulta necesario conseguir alguna seña de identificación diferenciadora del resto de empresas competidoras con objeto de presentar un valor añadido para la clientela. Este valor puede consistir en una reducción de sus costes, un aumento de prestaciones etc. obtenidos mediante: Mejora en la rapidez de reacción. Presupuestos-contratos, pedidossuministradores-fabricación-distribución. Relaciones con los clientes. Incremento y mejora de la información suministrada a los clientes, mejora en la atención de sus peticiones y quejas etc. Personalización de los productos o servicios. Flexibilizarlos, tarificaciones diferenciadas, servicios post-venta mejorados etc. 52

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Habida cuenta que un Plan de Sistemas tiene por misión actualizar los puntos fundamentales en los que se asienta la política informática de la empresa y definir los dominios de realización con sus interconexiones, todo ello integrando las tecnologías de la información, podemos resumir las razones que aconsejan emprender su elaboración, en las siguientes: Cambios importantes en el entorno. Cambios internos en el seno de la empresa. Inadaptación del Sistema de Información a los objetivos de la empresa. Necesidad de justificar las inversiones. Ausencia de planificación del Sistema de Información. 4.2

OBJETIVOS DEL PLAN DE SISTEMAS

Concebir un Sistema de Información está íntimamente relacionado con diseñar la organización. Las relaciones entre las diferentes unidades organizativas suponen el transporte de información y por tanto exigen la existencia de una cierta organización social y técnica que permita dichos intercambios. La concepción del Sistema de Información pasa por la previa reorganización de los circuitos de información, por la redefinición de las actividades desarrolladas, por el diseño de nuevos documentos, e incluso por la inversión en nuevos medios tecnológicos, por lo que afectará de manera importante a la productividad de la organización y del sistema. Teniendo en cuenta los objetivos estratégicos de la empresa, el Plan de Sistemas trata de: Definir los ejes de desarrollo del Sistema de Información de la empresa a corto y medio plazo. Prever los medios necesarios para efectuar dicha evolución, así como los costes que conllevan. Definir el impacto de las medidas propuestas sobre la gestión y la organización de la empresa, destacando las ventajas a obtener y los riesgos a afrontar. En definitiva, el Plan de Sistemas coloca al Sistema de Información en el lugar que le corresponde integrándolo en la infraestructura de la empresa.

53

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4.3

PARTICIPANTES EN EL PLAN DE SISTEMAS

- Comité Informático. Estará compuesto por Dirección General y las Direcciones Departamentales. Entre sus competencias podemos destacar las siguientes:

Definir la política general. Definir los tratamientos de la información. Fijar las prioridades de desarrollo. Fijar los presupuestos. Control del desarrollo del estudio. Validación de los informes de las etapas. Seguimiento de la implantación del Plan de Sistemas. - Equipo del Proyecto. Estará integrado por las siguientes personas: Jefe del Proyecto. Ejercerá las misiones propias de su cargo, entre las que se encuentran: Responsabilizarse de la marcha del Proyecto en lo referente a: Técnicas. Presupuestos. Fecha de terminación. Calidad de los resultados obtenidos. Asignar tareas a los componentes del equipo. Revisar la ejecución de dichas tareas. Responder ante el Comité de Informática. -Consultor interno o externo. Efectuará labores de consultoría en lo referente a la realización del estudio y a la metodología utilizada. Asimismo ejercerá de coordinador entre las diversas personas implicadas, pudiendo asumir también las responsabilidades de Jefe del Proyecto. Expertos organizativos y técnicos. Tendrán por misión la realización de determinadas tareas. Grupos de Usuarios. Actuarán en la definición de dominios o en temas concretos de estudio.

54

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4.4

ESTRUCTURA Y DESARROLLO DEL PLAN DE SISTEMAS

La estructura del Plan de Sistemas se articula alrededor de cinco etapas, las cuales a su vez se subdividen en fases y éstas en tareas. El criterio seguido para realizar dichas divisiones está contenido en las definiciones de etapa, fase y tarea, las cuales pasamos a exponer: Etapa. Distancia que separa dos pausas consecutivas en la realización del estudio, y que se caracteriza por una progresión armoniosa de los tres ciclos (vida, abstracción, decisión). Cada etapa termina con una formalización de decisiones que han de ser validadas antes de comenzar la siguiente etapa, por lo que tienen que realizarse de manera secuencial. En el esquema organizativo que sigue, los nombres de las etapas van precedidos de una letra mayúscula ( ej. A-Preparación) Fase. Subdivisiones de las etapas que persiguen objetivos concretos. En el esquema organizativo que sigue, los nombres de las fases van precedidos de una letra mayúscula seguida de un dígito (ej. A1-Lanzamiento del Plan de Sistemas) Tarea. Subdivisiones de las fases que se corresponden con la menor unidad de trabajo controlable. En el esquema organizativo que sigue, los nombres de las fases van precedidos de una letra mayúscula seguida de dos dígitos (ej. A11-Elección del equipo de proyecto)

Entonces, la estructuración del Plan de Sistemas, en cuanto a etapas, fases y tareas es: A-Preparación: A1-Lanzamiento Plan de Sistemas: A11-Delimitación campo del estudio. A12-Elección equipo del proyecto. A2-Conocimiento general de la empresa: A21-Estructura y organización. A22-Objetivos estratégicos. A23-Recolección de información. B-Estudio de lo existente: B1-Análisis de la situación actual: B11-Entrevistas por departamentos. B12-Síntesis y validación. B13-Opinión agentes externos. B14-Opinión usuarios informáticos. 55

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

B2-Redacción y validación informe: B21-Redacción informe de la etapa. B22-Validación del informe. C-Balance de necesidades: C1-Recolección y evaluación de necesidades: C11-Recogida de necesidades. C12-Evaluación de necesidades. C2-Balance de necesidades: C21-Subdivisión en dominios. C22-Informe de la etapa. C23-Validación del informe. D-Construcción de escenarios: D1-Lanzamiento de la etapa. D2-Diseño de soluciones: D21-Búsqueda general de soluciones. D22-Solución organizativa. D23-Solución técnica. D3-Elaboración de escenarios: D31-Definición de escenarios. D32-Escenario preferencial. D4-Redacción y validación informe: D41-Redacción informe de la etapa. D42-Validación del informe.

E-Planes de acción: E1-Planificación de acciones: E11-Subdivisión en proyectos. E12-Planificación de tareas. E13-Impacto sobre la organización. E2-Redacción y validación informe: E21-Redacción informe de la etapa. E22-Validación del informe.

Lo cual se resume, con los hitos significativos, en el siguiente gráfico:

56

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Etapa A "Preparación" El objetivo perseguido por esta etapa consiste en sentar las bases sobre las que se realizará el Plan de Sistemas. Más concretamente se trata de: -Definir el tipo de empresa. -Conocer los objetivos estratégicos y las motivaciones de la Dirección General. -Conocer la estructura de la empresa y definir el equipo del proyecto. -Recoger informaciones generales de la empresa (flujos de información, actividades principales, servidores utilizados, estudios anteriormente realizados etc.). Para poder realizar dichas labores se llevarán a cabo una serie de entrevistas con la Dirección General y las Direcciones Departamentales y se procederá a recopilar documentación sobre los flujos de información emitidos y recibidos por cada Departamento, las actividades principales efectuadas y los servidores de datos y aplicaciones utilizados.

57

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En resumen:

Etapa B "Estudio de lo existente" Los objetivos de la presente etapa son los siguientes: Comprender perfectamente la organización de la empresa. Comprender los mecanismos de circulación de la información y ser capaz de modelizarlos. 58

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Censar las actividades de la empresa enumerando los problemas encontrados.

Los métodos que usaremos para llegar a cumplir los objetivos marcados, serán la realización de entrevistas con los responsables departamentales con objeto de completar las informaciones recopiladas en la etapa anterior y la posterior reflexión sobre los problemas o disfunciones detectados, con lo cual elaboraremos un diagnóstico de la situación actual del Sistema de Información de la empresa.

59

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En resumen:

Etapa C "Balance de necesidades" La etapa B nos ha permitido realizar una fotografía de la situación actual de la empresa. En esta etapa adoptaremos una actitud más creativa que nos permita ir definiendo el Sistema de Información futuro, para ello partiremos de una evaluación correcta de los objetivos perseguidos y de las necesidades constatadas, sometiéndolos a una jerarquización en función de su importancia. Subdividiremos la empresa en dominios de actividad, los cuales serán estudiados de manera individual.

60

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En la figura, un ejemplo de los dominios funcionales de una empresa, que no tienen por qué corresponderse con los departamentos, desde el punto de vista organizativo. En el estudio de los dominios se tendrá en cuenta sus interrelaciones.

En la tabla, el cruce de algunas aplicaciones existentes (seguimiento de pedidos, envío de pedidos, etc) con los procesos característicos del dominio Comercial.

En esta etapa utilizaremos la técnica de los Factores críticos de éxito para constatar el grado de relación de las necesidades detectadas con la consecución de los objetivos estratégicos de la empresa. 61

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Asimismo utilizaremos el concepto de Dominio que consiste en la agrupación de conjuntos de actividades que comparten datos comunes y que tienen escasos intercambios de información con otros conjuntos de actividades, y que al mismo tiempo comprenden el mayor número posible de factores críticos de éxito encontrados anteriormente. En resumen:

62

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Etapa D "Construcción de escenarios" Hasta el momento, conocemos el funcionamiento del Sistema de Información actual de la empresa, sus problemas, los objetivos a nivel empresa, y las necesidades (objetivos a nivel local), a satisfacer. Nos queda concebir el paisaje informático futuro, los diferentes escenarios escogidos para los diferentes Dominios considerados. Para ello constituiremos una serie de equipos de trabajo por Dominio para la búsqueda de soluciones específicas a esos Dominios y posteriormente se hará la puesta en común de las diversas soluciones diseñadas para asegurar su coherencia. Las soluciones se diseñarán en forma de Escenarios que tienen por misión imaginar la evolución del Sistema de Información desde la situación actual hasta la situación elegida como solución idónea. Por tanto un Escenario puede definirse como el conjunto formado por la solución elegida y la trayectoria seguida para alcanzarla.

63

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

A modo de ejemplo, se incluyen las descripciones breves de algunos escenarios correspondientes a la realización de un Plan de Sistemas en una universidad privada. - Escenario 1: Privilegia la lógica de construcción del sistema organizativo - Escenario 2: Privilegia la facilidad de realización del proyecto piloto. Escenario 3: Privilegia la satisfacción de las necesidades/prioridades

Escenario 1

Orden de realización e implantación 1) Cursos e Investigación (Proyecto piloto) 2) Certificados y títulos 3) Matrículas 4) Expedientes de alumnos 5) Personal 6) Cuadro de control de Rectorado

Escenario 2

Orden de realización e implantación 1) Expedientes de alumnos (Proyecto piloto) 2) Personal 3) Cursos e Investigación 4) Certificados y títulos 5) Matrículas 6) Cuadro de control de Rectorado

Escenario 3

Orden de realización e implantación 1) Matrículas (Proyecto piloto) 2) Cursos e Investigación 3) Certificados y títulos 4) Expedientes de alumnos 5) Cuadro de control de Rectorado 6) Personal

Una vez construidos los escenarios, se evaluan aspectos relativos al mismo, en cuanto al mayor o menor impacto organizativo, el tipo de proyecto piloto representativo de dicho escenario y el grado de cumpliento de las prioridades 64

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En resumen.

65

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Etapa E "Planes de acción" Tiene por objetivo situar las conclusiones del Plan de Sistemas en la realidad de la empresa dando una visión cuantitativa y planificada de los escenarios definidos en la etapa anterior. Para ello subdividiremos cada dominio en uno o varios proyectos de acuerdo con una serie de características: Las funcionalidades ofrecidas deben formar un todo coherente. Las informaciones manejadas deben constituir un conjunto coherente. El proyecto debe ser manejable en cuanto a su tamaño, costes y plazo de ejecución. Posteriormente procederemos a planificar las tareas principales a considerar en cada proyecto, realizando una primera estimación de sus duraciones, así como de los recursos precisos para desarrollarlas. Finalmente se establecerán unas normas para efectuar el seguimiento y posible puesta al día del Plan de Sistemas.

66

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En definitiva, el Plan de Sistemas tiene como resultado operativo, la implantación de: Las aplicaciones informáticas que se planifican, diseñan y desarrollan corporativamente en el seno de la empresa. Los sistemas que se adquieren externamente En los casos anteriores, la administración informática se ocupará del mantenimiento, seguimiento y evolución.

En resumen:

67

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4.5

SEGUIMIENTO Y ACTUALIZACIÓN DEL PLAN DE SISTEMAS

Para efectuar el seguimiento del Plan de Sistemas, lo primero que hay que hacer es asegurarse de que sus conclusiones son aplicadas correctamente, lo cual comprobaremos a lo largo del tiempo observando cómo van desapareciendo los problemas relacionados con las diferentes actividades consignadas en una de las tablas utilizadas en el transcurso del estudio y que hace referencia a los problemas detectados en cada actividad. Como el Sistema de Información de una empresa es un ente vivo y dinámico, va a sufrir una serie de transformaciones durante el período de vigencia del Plan de Sistemas, por lo que el comité de seguimiento debe encargarse de su supervisión y actualización y han de establecerse cauces para que las diferentes personas componentes de la empresa sean capaces de expresar nuevas ideas y recomendaciones cuando una situación se degrade. Lo primero que habrá que hacer será fijar los indicadores concretos que permitan medir el desarrollo del Plan de Sistemas. Estos indicadores deberán permitir apreciar que: Los objetivos fijados siguen siendo válidos. Las fechas planificadas en el plan de acción son respetadas. Los costes prefijados son igualmente respetados. Posteriormente se definirán los procedimientos de seguimiento a utilizar, de acuerdo con las siguientes definiciones: La estructura de seguimiento del Plan de Sistemas global (compuesta por el comité de seguimiento con la inclusión de los jefes de los proyectos planificados). La estructura de seguimiento de cada dominio. Los procedimientos de seguimiento propiamente dichos: Puntos de control. Periodicidad del seguimiento. Indicadores a examinar en cada punto de control. Los procedimientos de control de calidad de las aplicaciones (satisfacción de los usuarios, fiabilidad, facilidad de explotación, etc.). Los procedimientos de actualización del Plan de Sistemas.

68

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5 5.1

GESTIÓN DE PROYECTOS ¿QUE ES UN PROYECTO?

Un proyecto es un conjunto de tareas, actividades, limitadas en el tiempo, encaminadas a alcanzar un objetivo bien definido, en un plazo determinado, con unos medios dados (recursos humanos, presupuestarios, materiales, etc). Un proyecto se caracteriza por un conjunto de factores que influyen en los procesos de concepción y gestión. Dichos factores son: -Tangibilidad (un proyecto es concreto): El problema que da lugar al proyecto debe estar perfectamente identificado, así como la solución que lleva consigo. Dicha solución debe concretarse en la entrega de un producto perfectamente tangible cuya eficacia y calidad son perfectamente evaluables. -Excepción (un proyecto es único): Un proyecto es siempre un conjunto de actividades realizadas a título excepcional para responder a una demanda puntual en el tiempo. -Aproximación matricial: El dominio de aplicación de un proyecto cubre habitualmente varios departamentos solicitantes o usuarios; de ahí la necesidad de concebir su gestión desde la perspectiva matricial en lugar de jerárquica. -Flexibilidad: Un proyecto requiere habitualmente recursos que deben ser movilizados rápidamente y puestos en funcionamiento según procedimientos particulares, complementarios a los de la organización existente. -Duración limitada: El concepto de tiempo está íntimamente ligado a la noción de proyecto. Los objetivos y los plazos van emparejados frecuentemente, dada la importancia y la urgencia de la operativa. El proyecto debe terminarse cuando los objetivos se alcanzan y ello dentro de un espacio de tiempo generalmente corto. Cada proyecto tendrá, pues, un objetivo bien definido y se subdividirá en TAREAS. Además, se apropiará de un determinado número de RECURSOS: personas, tiempos-maquina, equipos, subcontrataciones, etc; y será dotado de un PRESUPUESTO que incluya el coste de los recursos, costes fijos, reservas financieras (pagos,...), gastos de desplazamiento y dietas, gastos de formación y de documentación, así como un PLAZO. 69

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5.2

¿QUE ES LA GESTION DE UN PROYECTO?

Un proyecto es una estructura provisional. No puede disponer de sus recursos definitivamente. Un proyecto vive. Nace, se desarrolla y termina. El objetivo principal de la Gestión del Proyecto es conducir el proyecto a su término, en los plazos acordados, con el presupuesto previsto. La Gestión del Proyecto nos permite saber a dónde nos dirigimos (objetivo), cómo ir (planificación de recursos y tareas) y nos indica en todo momento dónde estamos situados (seguimiento). La Gestión del Proyecto sigue un ciclo que comprende cuatro grandes etapas: 1) Iniciación del proyecto: Da vida al proyecto y fija los objetivos que debe alcanzar. 2) Calificación del proyecto: Permite evaluar globalmente la carga de trabajo necesaria a la realización del proyecto. Esta etapa puede ser subdividida en diversas actividades: a) Estimación de la carga y los costes. b) Estimación de riesgos. c) Decisión de emprender el proyecto y negociaciones. 3) Desarrollo del proyecto: O más exactamente, el control del desarrollo del proyecto, que comprende cuatro actividades: a) Planificación y subdivisión en fases: Se trata de la organización en el tiempo y en el espacio de los recursos necesarios para la realización del proyecto. b) Lanzamiento de fase. Da cuerpo a la estructura del proyecto y sitúa su organización. c) Seguimiento y control del proyecto: Mide las desviaciones entre lo planificado y lo realizado y permite tomar medidas correctivas. d) Cierre de una fase. 4) Cierre del proyecto: Permite hacer balance sobre la realización del proyecto y libera definitivamente los recursos. Un proyecto no es un fenómeno aislado en el seno de la Empresa. Está íntimamente ligado al Plan Estratégico del Sistema de Información. Es el complemento de la concreción y el análisis de un sistema.

70

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Un proyecto nace dentro del Plan de Sistemas y por lo tanto sigue las directrices que éste marca. Pero se realiza paralelamente a la actualización de dicho Plan. La decisión de modificar el contenido del Plan de Sistemas no puede, en ningún caso, perturbar el proyecto en curso. De ahí que la noción de subdivisión en fases sea tan importante. Las modificaciones aportadas al Plan de Sistemas no afectarán al proyecto en curso ya que le podrían desestabilizar, sino más bien a las fases ulteriores, o sea en las entregas sucesivas. De acuerdo con el Plan, el proyecto acompaña al Análisis del Sistema. Los dos fenómenos son complementarios. El análisis determina la conducción del proyecto, el cómo hacerlo. La gestión del proyecto controla la buena marcha del mismo. Entre el análisis y la gestión del proyecto encontraremos los siguientes paralelismos: 1) La iniciación del proyecto corresponde al anuncio realizado por el promotor. 2) La cualificación del proyecto forma parte integrante del Estudio Previo, que da bases estables al proyecto por medio de una concepción general rigurosa. 3) El control del desarrollo del proyecto se realiza en el Estudio Detallado, Estudio Técnico y la Realización. Cada fase de un proyecto se corresponde a una Aplicación determinada, cuando describimos la trayectoria. 4) El cierre del proyecto marca el comienzo de la fase de Mantenimiento. El proyecto termina y otro equipo toma el relevo. El mantenimiento no está caracterizado como un proyecto.

71

S I S T E M A S D E I N F O R M A C I Ó N E N L A E MFigura P R E1-R SA

Carta de Anuncio

Elección Jefe de Proyecto

Estudio Previo

CALIFICACION PROYECTO

Recepción

Estudio Detallado

Estudio Técnico

PLANIFICACION

Realización

Mantenimiento

SEGUIMIENTO y CONTROL

LANZAMIENTO

CIERRE PROYECTO

Figura 1

5.3

ENTORNO DEL PROYECTO

Los factores clave del éxito de un proyecto son la disponibilidad de la información, el seguimiento y la coordinación de las actividades. La naturaleza matricial de la organización de la cual dispone el jefe de proyecto complica singularmente el trabajo. En un proyecto, la autoridad no se basa en órdenes jerárquicos. El jefe de proyecto sólo dispone de instrucciones y de recomendaciones técnicas. Por ello, si quiere poder planificar, seguir y controlar el proyecto que tiene asignado, debe adoptar una actitud diferente e implantar una serie de procedimientos particulares, propios de la gestión del proyecto. Como un proyecto implica la colaboración de diversos personajes, el aspecto psicológico es muy importante. Más que la planificación y el control, la comunicación juega un papel preponderante en el desarrollo de un proyecto. Podemos distinguir dos tipos de personas entre las que van a estar implicadas en el proyecto: aquellas que viven el proyecto desde el exterior (que constituyen la estructura de explotación del material informático) y las

72

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

que viven el proyecto desde el interior (que están agrupadas temporalmente por el proyecto. El primer tipo comprende el promotor, el comité informático, los especialistas técnicos y el consultor en gestión de proyectos. El segundo tipo comprende el comité de seguimiento (proviene del comité informático), el jefe de proyecto y el equipo, que está formado por efectivos del departamento de Estudios y Desarrollos.

Promotor Es la persona que inicia el proyecto. Solicita la realización, fija los objetivos. El promotor es responsable del proyecto hasta el fin de la cualificación, momento en el que puede nombrar al jefe de proyecto que toma el relevo.

Comité informático Es responsable Define el paisaje informático de Frecuentemente suele ser el mismo promotor del proyecto.

la

Empresa.

El comité informático es una estructura estable en la Empresa, al contrario del comité de seguimiento. Se ocupa de los aspectos aplicativos de los proyectos respecto de la estrategia informática., mientras que el comité de seguimiento se ocupa de los aspectos de trayectoria del proyecto. El comité informático cumple las funciones siguientes: 1) 2) 3) 4) 5)

Comunicación entre organizaciones. Planificación a largo plazo Decisiones a nivel Empresa. Coordinación de las diferentes funciones. Innovaciones (Investigación y Desarrollo)

Por vocación, el comité informático supervisa un cierto número de comisiones que influyen en el desarrollo del proyecto: a) Es responsable del control de las modificaciones y adaptaciones solicitadas por los usuarios durante el desarrollo del proyecto. El comité informático solo juzga desde el punto de vista funcional. Decide si las modificaciones son necesarias y si concuerdan con los cuadernos de cargas. Les asigna prioridades. El comité informático juzgará la viabilidad y la tendrá en cuenta en la planificación de las realizaciones. 73

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El aspecto del control sobre las modificaciones es muy importante en un proyecto. Tendremos ocasión más adelante de volvernos a referir al mismo asunto. b) Es responsable de la recepción del software. Al final de cada fase del proyecto, el software producido debe ser recibido. Dicha recepción cierra formalmente la fase. Ello incumbe, no solamente al equipo de desarrollo, sino también a los usuarios. El comité informático designará a las personas participantes en la recepción, las modalidades de la misma y la calidad que deberá poseer el producto para ser admitido. c) Es responsable de la formación de los usuarios sobre el nuevo producto. Dicha formación la puede impartir algún miembro del proyecto, siempre bajo el control del comité informático. Especialistas técnicos Aunque sea un fenómeno excepcional, un proyecto no está aislado del resto de la sociedad. Se comunica con las estructuras fijas, como los especialistas en las diversas técnicas informáticas (lo que llamamos especialistas técnicos en bases de datos, redes, sistemas, lenguajes, herramientas, etc. ). Dichos especialistas técnicos dan su opinión sobre aspectos técnicos del proyecto, o sobre la disponibilidad de herramientas. Crean eventualmente un interfaz técnico para resolver los problemas potenciales cuando el proyecto comporta un alto riesgo técnico. Sitúan el entorno del proyecto (máquinas, terminales, software y procedimientos). Esta actividad es primordial para una utilización eficaz de los recursos. Actualmente, demasiados proyectos fracasan desde el principio por defectos relativos a la propia estructura del proyecto. Un proyecto no se improvisa, se planifica. Consultor de gestión de proyectos En las grandes Empresas, es interesante crear tal función, pues todos los estudios serios muestran que una estimación correcta no se puede hacer nada más que basándose en la experiencia, y que sin estimación correcta, la gestión del proyecto es engorrosa. Sin embargo, la experiencia no se adquiere sin medir sistemáticamente todo lo que puede ser medido. Tom DE MARCO, en su libro Controlling Software Projects explica bien esta situación: "Se puede gestionar lo que se puede medir, y aquello que no se puede medir se halla fuera de control". 74

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Dirigiendo uno o dos proyectos por año, los jefes de proyecto no pueden adquirir suficiente experiencia, máxime cuando al ser juez y parte no están en disposición de efectuar medidas "objetivas". Esta responsabilidad puede ser confiada a un consultor en gestión de proyectos, cuyas funciones son: 1) Aconseja sobre la cualificación del proyecto, estima los riesgos y da una indicación sobre el perfil del jefe de proyecto necesario. 2) Ayuda y aconseja a los jefes de proyectos durante la planificación de las tareas, sobre todo para definir las duraciones y la subdivisión en fases. 3) Durante el seguimiento del proyecto, recopila informaciones objetivas para afinar la técnica de estimación. Mide, con la ayuda del jefe de proyecto, el avance del proyecto para efectuar revisiones sobre el riesgo del mismo. 4) Garantiza los métodos y los procedimientos. Se ocupa de que los mismos sean utilizados. Previene la entropía, degradación que se presenta con el paso del tiempo. Figura 2-R DIRECCION INFORMATICA

ESTUDIOS Y DESARROLLOS

COMITE DE SEGUIMIENTO

JEFE DE PROYECTO

EXPLOTACION

ESPECIALISTAS TECNICOS

MANTENIMIENTO

EQUIPO

- Figura 2 -

Comité de seguimiento Para luchar contra la entropía, no basta con ocuparse de la aplicación de los métodos y procedimientos. Es preciso también motivar su empleo. 75

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta función es realizada por el comité de seguimiento, ante el cual el jefe de proyecto justifica los resultados de su proyecto. El comité de seguimiento es el centro de decisión de la gestión del proyecto. El comité de seguimiento es un órgano de control del proyecto. Tiene carácter temporal y solo existe mientras existe el proyecto. Es presidido por un representante de la Dirección General, con plenos poderes para decidir sobre la orientación a dar al proyecto: afectación de recursos, abandono del proyecto, asignación de prioridades, concurso de servicios exteriores, etc. Colabora estrechamente con el comité informático. Realiza las funciones siguientes: 1) Gestión de los problemas. 2) Afectación de recursos. 3) Elecciones técnicas. 4) Comunicación entre los grupos de trabajo. 5) Comunicación con los miembros de los grupos. 6) Gestión diaria de los grupos. 7) Desarrollo del sistema.

Jefe de proyecto El jefe de proyecto es responsable del proyecto desde el punto de vista de la técnica, presupuesto, plazos, y calidad del servicio ofrecido. El jefe de proyecto no interviene, necesariamente, en las primeras etapas del proyecto, ya que es definitivamente nombrado sobre la base de los riesgos del proyecto. Es imperativo que tenga posibilidad de rechazar la responsabilidad que se le propone si no está de acuerdo con ciertas restricciones. Una vez que ha tomado conocimiento de las restricciones, estimaciones de tiempo, recursos y riesgos que figuran en el expediente del proyecto, la primera tarea que acomete el jefe de proyecto es la planificación en detalle. Constituirá y motivará a su equipo. Realizará el control del proyecto, presentando regularmente informes sobre el avance al comité de seguimiento. En su función de responsable del presupuesto del proyecto, debe establecer un plan de desembolsos e ingresos, que debe respetar.

76

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Es su responsabilidad constituir un EXPEDIENTE del PROYECTO que refleje la vida del mismo. Dicho expediente normalizado debe ponerse a disposición del promotor, del equipo y del comité de seguimiento.

Funciones fundamentales del jefe de proyecto

1) Asegurarse de que el promotor del proyecto ha definido claramente los objetivos del proyecto. 2) Definir las diferentes fases del proyecto, y planificarlas. 3) Procurar la disponibilidad de los recursos (humanos, técnicos y presupuestarios. 4) Establecer procedimientos estándar para el control, los informes y validación. 5) Evaluar cargas. Distribuir el trabajo entre los miembros del equipo. 6) Procurar la formación a los miembros del equipo, tanto en aspectos técnicos (herramientas) como administrativos (procedimientos y normas). 7) Supervisar y coordinar la realización de tareas. 8) Controlar el desarrollo del proyecto y poner en conocimiento del comité de seguimiento la marcha del proyecto, los problemas que se puedan presentar para la toma de decisiones. 9) Procurar la calidad y el cumplimiento de los plazos establecidos. 10) Procurar la rentabilidad del proyecto según la planificación inicial. 11) Cerrar oficialmente el proyecto una vez alcanzado los objetivos asignados.

77

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Equipo de proyecto Es el conjunto de participantes que realizan las diversas tareas de un proyecto. El equipo es un elemento esencial para el éxito de un proyecto. Barry BOEHM considera que un mal equipo puede cuadriplicar el plazo de realización de un proyecto. Tom DE MARCO estima que cuando un proyecto se retrasa, es preferible prescindir de los miembros del equipo menos eficaces que incorporar nuevos miembros. El jefe de proyecto es responsable de su equipo. Dicha responsabilidad no es un concepto vago. El jefe de proyecto debe motivar a su equipo, hacerlo solidario, que trabaje en bloque. El aspecto de comunicación que comentábamos al principio tiene enorme importancia. Para ello, el jefe de proyecto informa personalmente a cada miembro de su equipo sobre: - la estructura del proyecto, el papel de todos los participantes. -las tareas de su incumbencia, los plazos a los que ha de ceñirse (deben ser aprobados por el equipo), los objetivos personalizados y los objetivos generales, las dificultades previstas, las acciones correctivas a efectuar, etc. -el circuito de las informaciones y procedimientos a respetar. El jefe de proyecto se ocupa también de la formación de su equipo, ya sea en los métodos y herramientas como en los procedimientos, estándares a respetar, etc.

5.4

DOCUMENTOS DE LA GESTION DEL PROYECTO

Una buena comunicación de la información entre los diferentes actores de la gestión del proyecto pasa por la definición precisa de los documentos de trabajo y de los circuitos de información. Sin embargo, la gestión de un proyecto no se debe encorsetar, y por lo tanto no se puede convertir en un formalismo burocrático. Por ello se debe limitar al mínimo el número de documentos y de circuitos, empleando siempre que sea posible las técnicas informáticas.

78

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Anuncio del proyecto El anuncio es un documento formal que permite iniciar el proyecto. Dicha iniciación se materializa por la atribución de un número de referencia al proyecto, la apertura de un expediente del proyecto y la designación de un jefe de proyecto. El anuncio inicia de hecho el Estudio Previo. Define 6 atributos del proyecto: -Quién hace qué. Cuáles son los recursos necesarios para realizar las actividades necesarias. -Para qué. Quién es el solicitante. En qué apartado presupuestario han de imputarse las prestaciones del servicio. -En qué marco. Cuáles son los objetivos perseguidos. Cuáles son los proyectos en relación con éste. Cuáles son las prioridades relativas a los proyectos. -Cuál es la carga de trabajo. Cuál es la carga de los recursos demandados. -Qué calendario. Cómo distribuir en el tiempo la carga de trabajo de los recursos necesarios. Diagrama de actividades del proyecto Una etapa esencial en la gestión de todo proyecto es la identificación y descripción de las diversas actividades que va a ser necesario desarrollar para llevar a cabo la operación. El documento de descripción de actividad incluirá los siguientes datos: - Quién es el responsable de la actividad. - Qué resultados debe aportar. - Su duración estimada. - Qué recursos se prevé emplear (naturaleza, cantidad y tiempo). - Costes estimados. - Fechas previstas para su ejecución. La descripción de actividades será normalmente realizada por el jefe de proyecto, aunque podrá contar con la ayuda de los responsables de ejecutar las tareas, así como con el asesoramiento de consultores o grupos de apoyo técnico. 79

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Informe de actividades Este documento será entregado por el jefe de proyecto a cada miembro del equipo para ser posteriormente, cumplimentado por cada uno. Su contenido es el siguiente: - Descripción de las tareas a realizar por cada recurso. - Duración estimada. - Fecha inicio y fin previstos. A cumplimentar por cada miembro del equipo: - Duración real. - Fecha inicio y fin. Este documento es de gran interés para la calidad de la planificación a efectuar, así como, el punto de partida para las tareas posteriores de seguimiento y control. La utilización del mismo, no debe impedir al jefe de proyecto controlar por contacto individual, a los miembros de su equipo y el estado de avance del proyecto. No olvidemos que el aspecto psicológico es muy importante para una buena gestión. Por otro lado, el jefe de proyecto es responsable no solamente de la cantidad de trabajo efectuado, lo que puede ser controlado con el informe de actividad, sino de la calidad de dicho trabajo. Informe técnico y económico de seguimiento y control del proyecto La tarea de seguimiento y control del proyecto compete principalmente al jefe de proyecto, que ha de responder de la consecución de los objetivos y ha de tomar las medidas correctoras convenientes. Pero el jefe de proyecto no es la única persona interesada en la marcha del proyecto. Por ello, una de sus misiones es rendir cuentas sobre la evolución del proyecto, informando periódicamente a sus superiores, al cliente y a los grupos de control que pudiesen haber sido instituidos para ese fin. Es conveniente que esa información tenga una periodicidad prefijada, normalmente mensual. El contenido de la situación del proyecto es el siguiente: - Datos generales del proyecto. - Resumen de la situación desde el informe anterior. - Actividades previstas y realizadas en el periodo. - Reuniones efectuadas. - Modificaciones solicitadas. - Incidencias habidas en el periodo. 80

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Asuntos pendientes de resolución. - Situación actual del proyecto. - Costes e importes facturados. - Problemas potenciales. - Actividades previstas para el siguiente periodo. - Costes y facturación estimada hasta final del proyecto. Carpeta del proyecto Una vez que el proyecto ha comenzado a existir se abre una carpeta que contiene el expediente del mismo. La custodia de dicho expediente es responsabilidad del jefe de proyecto. Contiene la descripción de la situación del cliente en el momento de iniciar el proyecto, así como los cambios más significativos ocurridos durante su realización. Globalmente, la carpeta del proyecto contiene: -Descripción general del proyecto, objetivos, límites, y restricciones. -Estructura del proyecto. Subdivisión en etapas, fases, y tareas. -Estimaciones iniciales desde el punto de vista de cargas, costes y riesgos. -Planificación del proyecto. O más exactamente , las diversas planificaciones del proyecto, tanto a nivel de calendario (diagrama de Gantt), como a nivel de los recursos y de los costes: . Planificación inicial ( referencia ) . Planificación en curso, -Acta de reuniones del Comité de Seguimiento. -Avance del proyecto. Recopilación de documentos de seguimiento y control utilizados a lo largo del proyecto. -Documentos relativos a la recepción del producto. Dicho expediente debe estar a disposición del promotor y de los miembros del equipo.

5.5

MORFOLOGIA DE UN PROYECTO

Un proyecto no es un fenómeno fijo, sino dinámico. No es un fenómeno lineal, sino un movimiento en espiral. Toda estimación no es exacta, todo plan deberá ser revisado. Los controles efectuados regularmente sobre el terreno tendrán por objetivo medir correctamente el error, estudiar las repercusiones sobre la planificación y retocar la estimación y el plan inicial. Los informes al comité de seguimiento 81

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

se hacen en base a una comparación entre lo que se había planificado (inicialmente), lo que estaba previsto (después de las modificaciones) y lo que se ha realizado. Si esta noción de evolución de planificación es importante, no se debe perder de vista que el entorno del proyecto en sí evoluciona. Lo que era cierto al comienzo del proyecto, ya no lo es hoy. Es preciso organizarse para vivir con el cambio, y nos preguntamos cómo. Una de las condiciones esenciales para absorber, sin muchas dificultades, los cambios, es subdividir el proyecto en etapas, estas en fases, y estas en tareas (también denominadas actividades). Una etapa, es cada uno de los pasos principales que hay que dar para la realización de un proyecto. Las etapas de un proyecto suponen la primera subdivisión del mismo, por lo que su desarrollo ha de ser secuencial. Cada fase constituye una unidad de realización, tiene unos objetivos y entrega unos resultados concretos por lo cual puede ser objeto de una facturación. Así pues, si el proyecto termina prematuramente a causa de cambio de objetivos, el trabajo ( parcial ) efectuado, habrá producido una remuneración. Es el aspecto financiero de la subdivisión por lotes. Cada fase constituye de hecho un subproyecto con objetivos precisos, pero con una duración de vida más limitada. El desarrollo de las fases en que se subdivide una etapa puede ser de forma secuencial o simultánea. Además, cada comienzo de fase nos obliga a replantearnos una serie de cuestiones: -Redefinir los objetivos de la nueva fase. Estudiar las nuevas restricciones. -Evaluar las alternativas y analizar los riesgos inherentes a las diversas posibilidades. -Eventualmente, simular la situación o realizar un prototipo antes de hacer elecciones. -Elegir una solución y replanificar en función de la misma. Este aspecto recursivo de un proyecto debe ser rigurosamente aplicado, y la elección final discutida con el comité de seguimiento. Por último, llegamos a la más pequeña subdivisión del proyecto. La tarea es la unidad de trabajo controlable. Debe tener asociado un responsable, una duración y unos recursos.

82

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5.6

CAUSAS DE LOS FRACASOS DE LOS PROYECTOS

Existen más ejemplos de fracasos de proyectos que ejemplos de proyectos llevados a buen término. Haciendo un muestreo, se pueden distinguir dos grupos de fracasos: los debidos a errores de gestión por parte del jefe de proyecto y los que son achacables al proyecto en si. Fallos personales Se han llevado a cabo estudios que han censado las principales causas de fallos en la gestión. Todos los casos están ligados a un problema de comunicación. -Incapacidad de delegar. El jefe de proyecto no hace participar a los miembros del equipo en las decisiones. -Desconocimiento de los objetivos. El Estudio Previo no ha sido efectuado correctamente. Dicho estudio es la única ocasión para COMPRENDER el significado del proyecto, para CONCEBIR un nuevo sistema y para TOMAR DECISIONES. -Mal análisis del problema. La concepción general no es correcta, la subdivisión del proyecto es inadecuada o los límites del proyecto no han sido definidos. -Mala evaluación de las personas. Los conocimientos, la competencia y la formación de los miembros del equipo han sido mal evaluados. -Falta de colaboración entre los participantes. -Falta de espíritu de decisión. Demasiadas preguntas quedan sin respuesta., lo que obliga a trabajar con hipótesis o bien a detener momentáneamente la progresión del proyecto.

Fallos externos -Mala definición de los objetivos. -Responsabilidades diluidas. Nadie es capaz de discernir quién es realmente responsable no solamente de las tareas sino también de la planificación, del proyecto. Nadie puede decir exactamente cuáles son los límites del proyecto. 83

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

-Ignorancia sobre el comienzo del proyecto. No es posible obtener los recursos planificados, pues nadie sabe que el proyecto ha comenzado. -Indefinición de prioridades cuando varios proyectos se desarrollan simultáneamente ( Se encuentra a menudo este problema cuando hay subcontrataciones implicadas en el proyecto. Tendremos ocasión de volver sobre ello ). -Mala definición del fin del proyecto. El proyecto continúa indefinidamente pues se ha confundido el proyecto con su mantenimiento. Un proyecto informático puede terminar, y sus recursos quedar desafectados, pero seguir persistiendo problemas de detalle a nivel de los programas. Se suscribe entonces un acuerdo verbal de recepción con ciertas reservas, y el proyecto entra en su fase de mantenimiento.

5.7

ESTRUCTURA DE UN PROYECTO

Hemos dividido la gestión de un proyecto en 4 etapas, que totalizan 9 fases. Dichas etapas son: . Inicio del proyecto. . Cualificación del proyecto. . Control del desarrollo del proyecto. . Cierre del proyecto.

Inicio del proyecto Es la etapa en la cual se definen, si bien de una manera muy general, los objetivos, los límites y restricciones del proyecto. Se le da una prioridad en relación con los otros proyectos de la cartera. Etapa con un fuerte componente administrativo en la cual se asigna a alguien la función de emprender el estudio de un sistema o la cualificación de un proyecto. En teoría, el nombramiento del jefe de proyecto solo tendrá lugar después de la etapa de cualificación del proyecto. En la práctica, es la persona encargada de emprender la cualificación del proyecto ( Estudio Previo ) la que será designada como jefe de proyecto. Cualificación del proyecto A) Estimación de cargas y costes. Esta fase permite darse cuenta muy rápidamente de a dónde se va. 84

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La estimación se referirá al coste total, el plazo de realización y la distribución de los efectivos en el tiempo. B) Estimación de los riesgos. El análisis del riesgo de un proyecto es capital para asegurar una gestión sana. Permite: -determinar qué tipos de riesgos se han de temer y tratar, si no se puede eliminarlos, al menos minimizarlos. -elegir el jefe de proyecto capaz de llevar el proyecto a término.

Se distinguen tres tipos de riesgos en un proyecto: -el tamaño del proyecto. Cuanto más largo es un proyecto, menos oportunidad hay de que se desarrolle sin influencias aleatorias. -la estructura del proyecto. Cuantas más personas y entidades implicadas hay, mayor es el riesgo de conflictos de objetivos que puedan ocurrir. -la tecnología. Cuantas más innovaciones técnicas haya ( hardware o software ), menos se domina realmente el proyecto. A estos factores es preciso añadir las sobre (o sub) responsabilidades (gaps y overlaps) y los impactos principales que tendrá el no alcance de los objetivos. El riesgo no debe ser considerado como un freno, sino que debe animar a encontrar la mejor aproximación a la gestión del proyecto. C) Decisión seguir adelante o no. En función de los proyectos actualmente en cartera, y de los recursos disponibles, se decide realizar el proyecto, posponerlo o rechazarlo. Estas tres fases del Estudio Previo desembocan en el nombramiento de un jefe de proyecto. Las cinco fases que siguen se sitúan en la responsabilidad del mismo.

85

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Control del desarrollo del proyecto 1) Planificación. Las estimaciones iniciales eran globales. Ahora, en función de las restricciones, el jefe de proyecto subdivide el proyecto en fases (lotes) y cada fase en actividades (tareas). Afecta recursos y calcula costes. El jefe de proyecto crea la planificación inicial (llamada simplemente PLAN). Dicho PLAN debe ser conservado tal cual durante todo el proyecto, para que sirva como referencia. 2) Lanzamiento del proyecto. Esta actividad particular es una fase en si, y puede ser la más importante. Si el lanzamiento del proyecto se hace mal, hay pocas posibilidades de que el proyecto se desarrolle correctamente. 3) Seguimiento y control del proyecto. El objetivo de esta fase es rendir cuentas acerca de la situación en la que se encuentra el proyecto., comparando lo que debería haberse hecho y lo que se ha hecho en realidad. Las desviaciones con el plan son comentadas por el comité de seguimiento, y se establece una nueva planificación, que llamaremos PLANIFICACION ACTUALIZADA. Se mide entonces las desviaciones entre el PLAN y la PLANIFICACION ACTUALIZADA. El PLAN no se modifica nunca. Por el contrario, la PLANIFICACION ACTUALIZADA será adaptada en función de la situación real. Se convierte entonces en la previsión. Se obtienen así tres planificaciones: 1) PLAN, planificación inicial, planificación de referencia inmutable. 2) FORECAST, nueva planificación presentada seguimiento, quien tratará de realizarla.

al

comité

de

3) PLANIFICACION ACTUALIZADA. La que verdaderamente se realiza. Mide las desviaciones entre el FORECAST y la situación a la fecha. Después de la reunión del comité de seguimiento, la PLANIFICACION ACTUAL se convierte en FORECAST. 4) Fin de una fase. Es el momento de los primeros balances. 86

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Después va a comenzar una nueva fase. El proceso recursivo que hemos descrito en la "Morfología del proyecto" debe ser aplicado.

Cierre del proyecto Cuando se han terminado todas las fases, o cuando el proyecto es abandonado, se procede a las conclusiones. Esta fase es tan importante como el lanzamiento del proyecto, tanto desde el punto de vista psicológico como material. Hay recursos que deben desafectarse, y pensar en futuras acciones. DIRECCION PROYECTOS

INICIO

5.8

DESARROLLO

CALIFICACION

CIERRE

INICIO DEL PROYECTO - Figura 3 -

Para realizar un servicio eficaz, es preciso que los recursos sean gestionados sobre bases sanas. El conocimiento de la cartera de proyectos permite planificar la utilización de los recursos. Es una de las razones que exige que cada demanda de iniciación de un proyecto figure oficialmente en un acta. Un mejor conocimiento de los proyectos permitirá realizar un mejor seguimiento de los servicios prestados, efectuar una medida mas precisa de las actividades y conducirá a una gestión de previsión de efectivos. La demanda de iniciación de un proyecto es administrativo. Se materializa por un anuncio oficial.

un

procedimiento

La iniciación de un proyecto debe responder a las cuestiones siguientes: -Cuál es el nivel de prioridad que se concede al proyecto teniendo en cuenta los fines globales que persigue la Empresa, y cuál es su lugar en el Plan de Sistemas del Sistema de Información. 87

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

-Cuáles son los objetivos específicos del proyecto. Objetivos medibles y mejoras contempladas. -Cuáles son los límites del proyecto. -Cuáles son las restricciones que se deben tener en cuenta.

INICIO DEL PROYECTO

DIRECCION PROYECTOS

INICIO

NIVEL DE PRIORIDAD

5.9

DESARROLLO

CALIFICACION

OBJETIVOS

LIM ITES

CIERRE

RESTRICCION

CUALIFICACIÓN DEL PROYECTO - Figura 4 -

El objetivo de esta fase es determinar rápidamente, si es posible, después de la recepción del cuaderno de cargas, si el proyecto es rentable y realizable. Ello va acompañado de un estudio del impacto sobre los recursos y los beneficios. No hay que perder de vista que una estimación no es una medida objetiva. Toda estimación es falsa. De ahí se desprende la necesidad de controlar el desarrollo del proyecto, medir el error inducido por la estimación y organizarse en consecuencia.

88

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La gestión del proyecto utilizada en nuestro sector de actividad difiere muy poco de la gestión empleada en la industria ( para gestionar la producción ) o en la construcción ( para realizar el seguimiento de una obra ). La única diferencia, sin tener en cuenta el tamaño, es que no disponemos de referencias en materia de estimación de cargas. En la construcción, se conoce el rendimiento de cada albañil (en ladrillos/día) y el número total de ladrillos necesarios para construir una casa. Por ello es fácil planificar la construcción y fijar un coste. En Informática, no conocemos el rendimiento de los participantes ( entran en juego demasiados parámetros, la mayor parte desconocidos ). Incluso no conocemos el tamaño de la aplicación que debemos realizar. ¿ Cómo estimar en esas condiciones, de forma honesta, la carga y el coste del desarrollo de una solución?. Estimación de cargas Figura5

DIRECCION PROYECTOS

INICIO

ESTIM ACION DE CARGAS

CARGA EN HORAS

CALIFICACION

ESTIM ACION DE RIESGOS

COSTOS

DESARROLLO

CIERRE

DECISION

RECURSOS

- Figura 859 -

ESTUDIO TECNICO

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Diversos investigadores han trabajado sobre este problema. En el capítulo de Técnicas de Estimación se describen los métodos -

COCOMO DE MARCO PUNTOS DE FUNCIÓN WALSTON & FELIX RUBIN

El consultor de gestión de proyectos es el responsable de esta tarea. Le ayuda en su realización el promotor y el jefe de proyecto que ha dirigido la cualificación del proyecto. La utilización de una herramienta informática permite efectuar simulaciones y poner en evidencia factores que influyen en la estimación. Estudio financiero Con la ayuda de un especialista financiero, el consultor en gestión de proyectos calcula el coste global (estimado) del proyecto. Es la base de la negociación que efectuará con el promotor. Dicha negociación, a la luz de los factores que influyen en el coste, llevará esencialmente a los objetivos del proyecto. Afectación de recursos La estimación de la carga se hace en horas. Aunque es posible desarrollar tareas en paralelo, y trabajar simultáneamente, la carga no da indicación de plazo. Este debe ser calculado en función de los recursos disponibles. Dicha tarea es responsabilidad del consultor en gestión de proyectos. Estudio técnico Esta tarea, que incumbe a los especialistas técnicos, se desarrolla en paralelo con otras actividades y estudia el impacto técnico del proyecto y su factibilidad Herramientas Toda la fase de estimación y de simulación, cualquiera que sea la carga, del coste y de los plazos, es realizada por herramientas informáticas, en base a las informaciones suministradas por el promotor y el jefe de proyecto. Dichas 90

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

informaciones, que impactan en el presupuesto del proyecto, tienen que figurar en el cuaderno de cargas. Las informaciones proporcionadas por herramientas informáticas son: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13)

Número de servicios implicados en la Empresa. Número de ubicaciones a visitar durante el análisis. Número aproximado de personas implicadas en el sistema. Experiencia del personal de desarrollo en el dominio de la aplicación. Conocimiento de los objetivos reales. Impacto de los desplazamientos en el proyecto. Composición de los equipos ( usuarios-informáticos ). Número de personas que se tiene que desplazar. Número de subsistemas de la aplicación. Número de flujos entrantes ( entradas al sistema ). Número de flujos salientes ( salidas de la aplicación ). Número de entidades principales ( ficheros maestros ). Número de tipos de consultas on-line.

Hay que señalar que solo 5 preguntas ( 9 a 13 ) se refieren a los aspectos técnicos de la aplicación y que dichas informaciones son las que se encuentran en el modelo de Function Points de Albrecht. 14) 15) 16) 17) 18) 19) 20) 21) 22) 23) 24) 25)

Conocimientos informáticos de los usuarios. Conocimiento de la aplicación por el usuario. Grado de automatización de la aplicación actual. Conocimiento del sistema por el equipo de desarrollo. Complejidad del entorno Hardware/Software. Disponibilidad del sistema de pruebas. Necesidad de backup. Necesidad de procedimientos de Restart/Recovery. Aspectos críticos de las prestaciones. Tipo de aplicación ( on-line, tiempo real, batch ) Complejidad de los tratamientos. Tratamiento de las excepciones.

El sistema produce la distribución del esfuerzo, basándose en algoritmos preestablecidos. Existen 5 algoritmos estándar que se pueden sumar a los algoritmos propios. Los algoritmos estándar cubren los siguientes casos: - Ciclo de vida tradicional. - Adquisición de un paquete. - Modificación de un paquete. - Utilización de un generador de programas. 91

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Utilización de la técnica de prototipaje. Para cada algoritmo, el esfuerzo es distribuido en varias fases. Así pues, para el ciclo de vida tradicional, tenemos 6 fases: - Definición de necesidades - Análisis detallado - Diseño de la aplicación ( subdivisión y ficheros ) - Programación - Pruebas - Instalación del producto Basándose en estimaciones de carga, las herramientas informáticas proporcionan diversos escenarios para estimar la duración real del proyecto, según fijemos el equipo o la duración. La estimación de la duración se completa con el cálculo de coste, basados en los costes de gestión de proyectos, análisis y programación, así como sobre el rendimiento esperado del equipo. Todas las estimaciones pueden dar lugar a simulaciones con comparación de resultados. Carpeta del proyecto Esta fase del proyecto forma parte integrante del análisis. Es la parte del estudio previo que se ocupa del estudio de la trayectoria. En el Carpeta del proyecto, debemos encontrar: La carga global del proyecto (plazo). Lista de los factores que influyen en la carga Estudio financiero comparado con el presupuesto del promotor. Distribución de las cargas en el tiempo, con diversas simulaciones si fuera necesario. Lista de los factores que influyen en la carga Estudio financiero comparado con el presupuesto del promotor. Distribución de las cargas en el tiempo, con diversas simulaciones si fuera necesario. Estudio técnico, con comentarios sobre la disponibilidad de las herramientas. Restricciones impuestas por el promotor.

92

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

CARGA GLOBAL DEL PROYECTO Carga

Carga-r

Estimación del riesgo El análisis del riesgo de un proyecto es esencial para asegurar una gestión sana. Permite: -Determinar que tipo(s) de riesgo(s) hay que temer más en un proyecto e intentar, si no se puede eliminar, proponer otras aproximaciones para minimizar su efecto. -Elegir el jefe de proyecto capaz de llevar a término el proyecto. El análisis del riesgo permite clasificar los proyectos en 8 grandes tipos cada uno de los cuales exige un tipo definido de jefe de proyecto. El riesgo no debe ser considerado como un factor insalvable y debe animar a una mejor aproximación de la gestión del proyecto. El riesgo de un proyecto se divide en tres partes: 1)Tamaño del proyecto. Cuanto más largo es el proyecto, menos oportunidades hay de terminar sin influencias aleatorias. 2) Estructura y entorno del proyecto. Cuantos mas departamentos hay implicados, mayor es el riesgo de conflictos de objetivos. 3)Tecnología. Cuantas más innovaciones técnicas hay (hardware y software), menos se domina el proyecto. A estos tres elementos hay que añadir: 93

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

sobre (o sub) responsabilidades ( overlaps y gaps ) impactos principales que tendrá el no alcanzar los objetivos El riesgo es calculado asignando pesos a una serie de factores para cada categoría de riesgo. Se mide entonces el porcentaje de riesgos potenciales.

ESTIMACION DEL RIESGO Figura5 Titulo

DIRECCION PROYECTOS

INICIO

DESARROLLO

CALIFICACION

ESTIM ACION DE CARGAS

ESTIM ACION DE RIESGOS

DE ESTRUCTURA

TECNOLOGICOS

CIERRE

DECISION

DE TAM AÑO

La estimación de riesgos de un proyecto a sido modelizada por Warren Mc - Figura 6 Farlan y se describe en su publicación titulada Risk Assessment Method. En este libro, se describe detalladamente el Método de McFarlan en el capítulo dedicado a Técnicas de Estimación Los factores que influyen en el riesgo son los siguientes: 1) Riesgos estructurales: - Interés de la Dirección por el proyecto - Actitud del usuario 94

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Impacto sobre el plan de negocio del departamento del usuario - Interés de la Dirección del usuario por el proyecto - Nombramiento del jefe de proyecto - Tipo de proyecto ( nuevo, sustituyente,..) - Impacto sobre la organización establecida - Dependencia entre proyectos - Sustitución de un sistema manual - Modificación de los procedimientos del usuario - Formación de los usuarios - Actitud del analista - Número de departamentos implicados - Quién define las necesidades de los usuarios - Quién desarrollará el nuevo sistema - Quién implantará el nuevo sistema - Quién realizará las pruebas - Tipo de control del proyecto - Importancia de las modificaciones que serán solicitadas 2) Riesgos tecnológicos - Necesidad de ampliaciones de hardware - Innovación técnica del hardware ampliado - Hardware específico para el proyecto - Conocimiento de la fecha de entrega del hardware necesario - Conocimiento del hardware por el proveedor - Número de proveedores implicados en el mercado - Dependencia del proyecto por comparación al hardware - Valor del soporte de software del proveedor - Necesidad de distribución de funciones - Tipo de aplicación (batch, on-line, tiempo real) - Tipo de lenguaje de programación utilizado - Novedad del software utilizado ( DB, ... ) - Necesidad de modificación de un paquete - Complejidad de los tratamientos/interfaces - Experiencia del usuario en informática - Conocimiento de la aplicación por los informáticos - Posibilidad de constituir un equipo competente - Ubicación de las personas que efectúan pruebas - Estimación del tiempo de pruebas - Existencia de un plan de pruebas aprobado

3) Riesgos de tamaño: - Carga estimada - Duración estimada - Número de subsistemas a desarrollar 95

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Número de programas a desarrollar - Plazo de ingreso de beneficios - Importancia de los desplazamientos - Número de interfaces con los sistemas existentes - Tasa de transacciones / hora - Número de entidades importantes ( ficheros maestros ) - Utilización de la DB ( batch o on-line ) - Tiempo necesario para realizar un recovery completo - Necesidad de convertir los datos - Número de departamentos implicados - Número de usuarios impactados por el proyecto - Número de categorías de personas impactadas - Quién ha elegido el equipo de proyecto - Posibilidad de conflicto de prioridad con otro proyecto - Comparación entre el presupuesto estimado y el disponible El análisis de estos diferentes factores permite determinar el tipo de proyecto que vamos a afrontar: Risk Type A B C D E F G H

Size

Tech

Struct

L H L H L H L H

L L L L H H H H

L L H H L L H H

Ext. Integ L L H H L L H H

Int. Integ L M L M H H H H

Plan M H M H L M L L

Control H H H H L M L L

L = low ( bajo ), M = Medium ( medio ), H = High ( alto ) El estudio del riesgo a determinado 8 tipos de proyectos (A a H). Cada tipo necesita una gestión particular, caracterizada por cuatro parámetros: (Ext. Integ) indica que el proyecto requiere buenos contactos con el mundo exterior, es decir con los usuarios. Así pues, un proyecto fuertemente influido por este parámetro tendrá las características siguientes: -Conexión constante con los usuarios. El comité de seguimiento DEBE incluir a usuarios. -Incorporación de uno o varios usuarios en el equipo de proyecto. -Información regular de la gestión sobre el avance del proyecto. 96

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

-Aprobación de las especificaciones y de toda modificación aportada a la aplicación por los usuarios. En este caso, se aconseja realizar prototipo de la aplicación. -Contactos entre el equipo de proyecto y los usuarios (Int. Integ) indica que el proyecto requiere buenos contactos en el equipo. Asi pues, un proyecto fuertemente influido por este parámetro tendrá las características siguientes: - Constitución de un comité técnico en el seno del equipo. Se aconseja trabajo en grupo (responsabilidad en común). -

El jefe de proyecto debe tener buenos conocimientos técnicos. Se precisa utilizar metodología rigurosa. Necesidad de revisiones periódicas del avance técnico. Asegurarse de la la perennidad del equipo. Eventualmente, hacer concurrir asistencia exterior.

(Plan) indica la necesidad de dotar de herramientas de planificación. Un proyecto fuertemente influido por este parámetro tendrá las características siguientes: -Utilización de herramientas de planificación -Descripción precisa de las especificaciones funcionales, tanto a nivel de entradas ( volumen, origen, modo de captura, formato, etc ) como de salidas ( formato, frecuencia, distribución, seguridad, etc ). Se aconseja el prototipaje, para evitar sorpresas desagradables. -La concepción general del sistema debe ser rigurosa, completa y no dar pié a la discusión. (Control) indica que el proyecto requiere procedimientos estrictos de control. Un proyecto fuertemente influido por este parámetro tendrá las características siguientes: -

Seguimiento riguroso de la planificación y los costes. Control regular del proyecto por el comité de seguimiento. Utilización de pruebas de calidad del producto desarrollado. Control permanente sobre las modificaciones solicitadas.

El estudio del riesgo de un proyecto guía en las decisiones correctas del jefe de proyecto y en la forma de organizar la gestión.

97

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta tarea es responsabilidad del consultor en gestión de proyectos, que se entrevista con el promotor y el jefe de proyecto para obtener las informaciones necesarias para el cálculo de los riesgos del proyecto y la determinación de los factores que mas influyen en el proyecto. El consultor en gestión de proyectos hace una serie de recomendaciones sobre la forma de dirigir el proyecto y sobre los problemas potenciales. Sus recomendaciones servirán para renegociar el proyecto y para designar al jefe de proyecto, si no se hubiera decidido con anterioridad. La estimación del riesgo no debe pasar por alto los problemas de responsabilidad en la Organización: conflictos de influencia (overlap de responsabilidad) y carencias de responsabilidad (gaps). Sobre la base de las recomendaciones que proceden de la tarea precedente, el jefe de proyecto ( actual ) puede renegociar el conjunto del proyecto con el promotor. Se pueden revisar las restricciones, los objetivos, las mejoras a aportar, los plazos, los límites del sistema, etc. Herramientas Se pueden utilizar en esta fase herramientas informáticos del tipo de los utilizados para la estimación de la carga y los costes. Utilizan el modelo de Mc Farlan (simplificado) y permiten efectuar simulaciones. Carpeta del proyecto En la Carpeta del proyecto, debemos tener: -Resultados del estudio del riesgo: el gráfico del riesgo, el resultado de las simulaciones y los factores principales que influyen en el proyecto.

98

riesgo-r riesgo

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

NIVEL DE RIESGO

Alto

Medio

Bajo TAMAÑO

ENTORNO

TECNOLOGICO

MEDIA

-Las recomendaciones del consultor en gestión de proyectos, que van a dar las máximas posibilidades al proyecto. -Las conclusiones de las negociaciones. Decisión sobre seguir adelante o no La decisión de lanzar un proyecto debe ser tomada con conocimiento de causa, razón por la cual hemos estimado el coste del proyecto, su duración, la carga y la inversión que representa así como las incertidumbres que son susceptibles de encontrar durante la vida del proyecto. Partiendo de ese conocimiento, el comité informático podrá tomar una decisión objetiva sobre la oportunidad de aceptar el proyecto. La decisión se basará en el pre-estudio que se ha hecho, que es tanto técnico como financiero o psicológico (análisis de responsabilidades). La decisión final atañe al comité informático que puede solicitar informaciones complementarias sobre objetivos fijados, inversiones necesarias, rentabilidad del proyecto, disponibilidad de los recursos previstos, experiencias, estudios de alternativas, etc. Cuando se ha tomado la decisión, solo queda designar al jefe de proyecto.

99

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

LA DECISION : SEGUIR ADELANTE – NO SEGUIR ADELANTE DIRECCION PROYECTOS

INICIO

ESTIMACION DE CARGAS

CALIFICACION

DESARROLLO

ESTIMACION DEL RIESGO

CIERRE

DECISION

SEGUIR O NO

ELECCION DEL J.P.

- Figura 7 -

La decisión propiamente dicha Es el comité informático el que toma la decisión final a la vista del Carpeta constituido por el jefe de proyecto o el responsable de realizar el Estudio Previo. Elección del jefe de proyecto En base al estudio de riesgos que se ha realizado, y las propuestas efectuadas hechas por el consultor en dirección de proyectos, el comité informático designa oficialmente al jefe de proyecto. Esta designación es oficial en el sentido de que es anunciada a las diversas personas interesadas.

100

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Los estudios de Mc. Farlan nos han mostrado que hay tres tipos de jefes de proyecto: los que tienen un excelente contacto con el usuario, los que son capaces de dirigir un equipo y los que son técnicamente competentes. A partir de estos tipos básicos podemos hallar toda una variedad de posibles jefes de proyecto. Veremos seguidamente que un jefe de proyecto no puede tener a su cargo eficazmente más de 7 personas. Quizá sea útil nombrar varios jefes de proyecto, de perfiles diferentes, responsables cada uno de una parte del proyecto. Si ese es el caso, el comité de seguimiento deberá supervisar especialmente dicho proyecto, pues podrían darse conflictos de responsabilidad. Se impone, en ese caso, que el comité de seguimiento tome las decisiones. Herramientas No existen en la actualidad herramientas informáticos de decisión, sino de ayuda a la decisión. Mediante las informaciones aportadas y las simulaciones realizadas se puede tomar la decisión. Carpeta del proyecto La Carpeta del proyecto se enriquece con una copia del cuaderno de cargas del sistema.

5.10

DESARROLLO DEL PROYECTO

Es la realización de las tareas en que se dividen las atapas y fases de un proyecto. Es decisión del jefe de proyecto el subdividir un proyecto en lotes (subdivisión financiera) o en fases con el fin de poder realizar una planificación , seguimiento, control y recepción coherente de los mismos.

101

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

DIRECCION PROYECTOS

INICIO

CALIFICACION

PLANIFICACION

LANZAMIENTO

DESARROLLO

CIERRE

SEGUIMIENTO Y CONTROL

CIERRE DE FASE

- Figura 8 -

PLANIFICACIÓN DEL PROYECTO Existe una estrecha relación entre: - los resultados esperados de un proyecto - la importancia de los costos asociados para alcanzarlos - los plazos necesarios para llevar a término la operación La secuencia según la cual estos tres elementos deben ser definidos es la siguiente: resultados esperados, recursos necesarios y plazos. Esta confrontación entre estos tres elementos primordiales es la primera tarea del jefe de proyecto. Se materializa mediante la planificación del proyecto, su ordenamiento. Hasta este momento, solo se había trabajado con estimaciones. La estimación de la duración del proyecto nos ha sido útil para determinar el costo del proyecto, pero solo tenía un valor indicativo. La planificación persigue otros objetivos: - analizar el proyecto, subdividirlo en etapas, fases, tareas. - elaborar un plan de acción que permita realizar el proyecto teniendo en cuenta las restricciones: disponibilidad de recursos, vacaciones, etc. - preparar el marco que permita controlar el desarrollo del proyecto. La planificación es la base esencial del éxito del proyecto

102

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

PLANIFICACION DEL PROYECTO

PLANIFICACION

Titulo DIRECCION

PLANIFICACION-R

PROYECTOS

INICIO

CALIFICACION

PLANIFICACION

LANZAMIENTO

DESARROLLO

SEGUIMIENTO Y CONTROL

FASES Y TAREAS

ACTIVIDADES

CIERRE

CIERRE DE FASE

CONSTITUCION EQUIPO

COSTOS

Subdivisión del proyecto

GANTT Y PERT

RECURSOS

- Figura 9 -

Un proyecto debe subdividirse en tareas para poder ser controlado y en fases para poder ser entregado y facturado. La fase es la unidad lógica del proyecto que puede ser realizada independientemente de otras fases. Su entrega no necesita esperar al fin del proyecto, ni el abandono del proyecto invalida dicha fase.

103

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Es esencial que el proyecto sea subdividido en fases. Dicha responsabilidad recae en el jefe de proyecto. La subdivisión recibe el nombre de Diagrama de Subdivisión. La tarea es la unidad de trabajo y de control en un proyecto. El afino y subdivisión en tareas depende esencialmente de la periodicidad del seguimiento del proyecto. Así pues, si el jefe de proyecto decide controlar la terminación de tareas todas las semanas, será preciso subdividir el proyecto en tareas que tengan una duración mas o menos igual a la semana. A esta restricción de duración se añade otra: una tarea no puede tener nada más que un solo responsable, aunque tenga varios ejecutores. Es preciso ocuparse de que cada tarea esté completamente definida, especificada y que se conozcan las modalidades de validación ( como decidir si ha terminado o no ). A cada tarea se le asocia identificación, duración, responsable, recursos, así como un lugar en el proyecto. Una tarea no puede ejecutarse, en la mayoría de los casos, en cualquier momento. Hay que plantear dos preguntas a propósito del encadenamiento de tareas: - cuándo se puede comenzar la tarea, y qué tareas la preceden. - cuáles son las tareas que le siguen. La respuesta a estas preguntas nos permitirá diseñar una red de tareas independientes en la cual todo retraso va a tener repercusiones en las tareas siguientes. La sucesión de tareas puede revestir diversas formas: - la tarea puede tener una fecha de comienzo fijada con antelación. Es el caso de una reunión, un curso, el comienzo del proyecto, etc. En caso de que la tarea dependa de otras, y se retrase, provocarán la actualización de la tarea fija. As pues, si una reunión se supedita al fin de una parte del análisis, todo retraso en dicho análisis llevará consigo el retraso de la reunión. - la tarea puede empezar tan pronto como sea posible después de una o una serie de tareas (En inglés ASAP: as soon as posible). La fecha del comienzo de esta tarea está condicionada por la terminación de todas las tareas de las cuales depende. 104

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Es la manera corriente de trabajar cuando se conoce la fecha de comienzo del proyecto. - la tarea puede comenzar lo más tarde posible, sin perturbar cualquier fecha posterior fijada de antemano ( en inglés ALAP: as late as posible ). De esa forma se puede planificar un prototipo a entregar en la fecha fijada para su validación. Se conoce la fecha del fin del proyecto ( día de la validación ) y se determina la fecha ( lo más tarde posible ) en la que se debe comenzar su preparación. Es la manera corriente de trabajar cuando se conoce la fecha de fin del proyecto. Además del caso del prototipo, se pueden citar otros: una mudanza, un viaje, la preparación de un curso, etc. La dependencia entre dos tareas puede ser parcial. De esa forma, podemos decir que una tarea debe ser ejecutada lo más tarde posible antes de la validación del prototipo, pero con un margen de seguridad de dos días entre la tarea y la fecha fatídica de la validación. Se comprende que la planificación de un proyecto se convierte, a causa de las múltiples dependencias; en un ejercicio particularmente complejo para poner en funcionamiento y complicado de mantener. Por esa razón se aconseja el empleo de útiles. Para completar, digamos que una tarea puede tener una duración nula. en ese caso se llama "hito" ( milestone ), y se utiliza como punto de referencia, como jalón de la planificación. Es aconsejable comenzar ( y terminar ) todas las fases de un proyecto por medio de hitos de los cuales dependan las primeras ( y últimas ) tareas. Así pues, una sola modificación de la fecha de un hito permite replanificar el conjunto del proyecto. Resultado de la ordenación de un proyecto No entramos en el detalle de los mecanismos de ordenación de un proyecto, ya que hemos decidido confiar esta fastidiosa tarea a una herramienta. Los dos resultados principales de la ordenación son: - El diagrama de Gantt, que representa las tareas en el seno de un calendario. Es la representación más legible. - La red PERT, que muestra la interdependencia de las tareas. ( véase el capítulo de descripción detallada del Método PERT ) 105

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Pero lo que también es importante es la interpretación de los resultados. La ordenación hace surgir dos tipos de tareas: las críticas y las que no lo son. Las tareas críticas no tienen ningún margen de maniobra. Deben comenzar en la fecha calculada y terminar en los plazos previstos, sin que pongan en peligro el proyecto en conjunto. Todo retraso en una tarea crítica repercute en la totalidad del proyecto. El conjunto de las tareas críticas constituye el camino crítico. Para disminuir el plazo de un proyecto solo hay una solución: reducir el camino crítico, desarrollar simultáneamente dos tareas críticas o afectar recursos extra a una tarea crítica para disminuir su duración. Recíprocamente: Todo avance logrado en una tarea crítica repercute positivamente en el conjunto del proyecto. Además de las tareas críticas, existen tareas no críticas que tienen un margen de maniobra (en inglés: slack time). Dichas tareas no tienen ninguna influencia directa en la duración del proyecto. Para dichas tareas, se determinan dos márgenes: - se puede posponer el comienzo de dichas tareas por un periodo igual a su margen libre ( free slack ) sin que ese retraso tenga repercusión sobre las otras tareas del proyecto. - si se alarga el margen total ( total slack ), a las tareas no críticas que siguen les disminuye sus márgenes, pudiéndose dar el caso de que se conviertan en tareas críticas. Si el retraso es igual al margen total, la tarea se convierte en crítica. Como vemos, es necesaria una supervisión constante del desarrollo del proyecto para que no se alteren los plazos acordados.

Utilización de los recursos La ordenación de nuestro proyecto nos ha dado un camino crítico. Todas las tareas del camino crítico están bien ordenadas y tiene su comienzo y final rigurosamente determinados.

106

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

No ocurre lo mismo con las tareas no críticas. Tenemos, pues, latitudes para las tareas, que pueden flotar ( dentro de márgenes conocidos ) por el calendario. Es preciso servirse de dichos márgenes para tratar de distribuir mejor la utilización de los recursos, con el fin de evitar conflictos en el uso de dichos recursos, y que en definitiva queden lo mas constantes posible. Distribución de los presupuestos Los presupuestos están esencialmente ligados a los recursos, a veces a las tareas ( p.e. facturación ). Son, pues, determinados automáticamente por los útiles de ordenación del proyecto. Constitución del equipo Durante la fase de ordenación del proyecto, el jefe de proyecto ha definido los recursos que le serán necesarios. Confecciona una descripción de tarea COSTO_R para cada actividad censada y elige los miembros de su equipo.

Titulo

EQUIPO Un equipo no debe estar constituido por más de 5 personas. Una de las razones de esta restricción la observamos en el gráfico siguiente:

Costos

1

2

3

4

5

6

7

8

9

10

Tiempo

107

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Si se constituye un equipo con menos de 5 personas, existen de hecho cinco individualidades. Cada una tenderá a imponer sus ideas y no se puede llegar a ningún consenso por mayoría. Además el valor global de la experiencia es débil, y el riesgo de error en las decisiones es más grande. Si hay más de 7 personas no hay equipo sino grupo, en el seno del cual los problemas de comunicación se producirán. Así pues, cuando un proyecto se retrasa, se trata de reflotarlo inyectando más personal. Ello puede frenar tanto o más el proyecto. Los que ya están trabajando deben formar a los que llegan y cada reunión se eternizará por haber más opiniones diferentes. Un equipo bien elegido y estable es un aval de éxito en un proyecto. Si hay más de 7 personas en un equipo existe la posibilidad de que se desdoble en más de un equipo, y que cada uno de los equipos así surgidos se asigne subproyectos diferentes. La práctica indica que cada proyecto debe implicar de 5 a 7 personas y durar entre 8 y 10 meses. El aspecto psicológico Es imperativo dejarse aconsejar por las personas que van a realizar las tareas para determinar su duración. El jefe de proyecto no debe imponer tiempos, sino consensuarlos. En esta fase delicada, hay que tener en cuenta la formación y la experiencia de cada uno. A un principiante se le han de dar tareas no críticas, cortas, bien definidas y se le controlará rigurosamente. A una persona experimentada se le puede confiar un grupo de tareas (o una tarea más larga). Todo proyecto debe llegar a su término ( no definido ) con los recursos limitados. Pero alcanzará un punto por detrás del cual se arriesgará a durar eternamente. Es el punto de dejadez, de desmotivación. También hay que ocuparse de que un proyecto no dure más de 10 meses. Es una de las razones por las que se recomienda subdividir el proyecto en fases. No sirve de nada planificar un proyecto si no se efectúa ningún control serio. La planificación es una base de control, no el impulso del trabajo. El control efectivo es uno de los mejores argumentos de motivación. Todas las tareas de esta fase son responsabilidad del jefe de proyecto, que puede ser ayudado por un consultor en gestión de proyectos. Como se ha 108

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

recordado en el capítulo precedente, el jefe de proyecto solicita la opinión de los participantes para fijar la duración de las tareas. Planificación El jefe de proyecto debe: - Definir las fases del proyecto y las tareas del mismo. Recordemos que las tareas son lotes que son entregados y facturados por separado. De alguna forma son subproyectos. Una tarea solo tiene un responsable. - Definir la duración de cada tarea. La subdivisión en tareas se hace de acuerdo con el principio "Se adapta el entramado de la red de acuerdo con el tamaño del pescado que se pretende capturar". Dicho de otra forma, no hay que definir tareas demasiado pequeñas (pueden producir retrasos sin que nos demos cuenta) ni demasiado largas (siempre se terminan al 80%, y solo en la fecha límite nos damos cuenta de que no se han terminado). El resultado de la subdivisión en tareas se llama WBS ( Work Breakdown Structure ) o Diagrama de Subdivisión. - Asignar los recursos a cada tarea - Fijar los costes a los diferentes recursos y a las diferentes tareas. - Determinar los hitos (milestones): reuniones periódicas (con el comité de seguimiento) o las fechas de facturación. - Conectar las tareas entre ellas. Constitución del equipo Sobre la base de los diagramas de Gantt, el jefe de proyecto intenta constituir el equipo ideal. Herramientas La planificación se basa en los resultados de las estimaciones (realizadas preferentemente con herramientas informáticas ), y en la experiencia adquirida por el consultor en gestión de proyectos, que puede intervenir como consejero o como controlador ( en el caso de un jefe de proyecto junior ). 109

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Se continuará con check-lists, realizados a la medida del proyecto, para ayudar a la realización de dicha actividad. Carpeta del proyecto La carpeta del proyecto deberá incluir: - Diagrama de Gantt - Diagrama de PERT, en que figuren las interrelaciones complejas entre las tareas - Definición de cada tarea - Lista de recursos - Planificación de los costos y beneficios Para cada miembro del equipo, el jefe de proyecto preparará un diagrama de Gantt ( parcial o completo ), así como la lista de las tareas en las cuales debe participar cada miembro del equipo. Se puede adjuntar también el Informe de Mano de Obra que específica para cada tarea el tiempo que deben dedicar los participantes, y el MANHOUR Report por periodo, que indica el tiempo a dedicar al proyecto, por periodo de tiempo. De esa forma, cada miembro del equipo sabe cuánto tiempo debe dedicar al proyecto cada semana. LANZAMIENTO DEL PROYECTO Un proyecto que es lanzado a partir de bases sólidas, cuenta con un máximo de posibilidades de éxito en su realización Esta reflexión está plenamente justificada. El lanzamiento es una fase crucial, que implica una toma de conciencia a todos los niveles: - a nivel empresa, para desbloquear recursos y crear el entorno necesario - a nivel promotor, que debe prever una estructura de trabajo y la disponibilidad de las personas - a nivel del equipo, que debe liberarse de sus obligaciones anteriores 110

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta etapa es muy importante, pues marca claramente la separación entre la fase de iniciación y el resto de las fases del proyecto. Está caracterizada por una transferencia fundamental de responsabilidades. Antes de esta etapa, la responsabilidad correspondía al promotor. Al término, la responsabilidad del proyecto se compartirá entre: - el jefe de proyecto ( ayudado por el comité de seguimiento ), en lo que se refiere a la ejecución. - el promotor ( representante del comité informático ), en lo que se refiere a la aprobación de las fases y el control de avance del proyecto. Por todo ello, el lanzamiento del proyecto debe ser acompañado de la necesaria publicidad, tanto a nivel del comité de seguimiento como del comité informático o del equipo. Hay una serie de aspectos a considerar. Primera reunión del comité informático y del comité de seguimiento. El jefe de proyecto presenta su plan al comité informático y al comité de seguimiento. Esta presentación es capital, pues permite: 1) Confirmar los objetivos del proyecto o precisarlos si hubiera falta de rigor. 2) Recordar los compromisos de cada cual: - Cómo se hará la recepción de los entregables del proyecto. Quién es el responsable de efectuar las pruebas ( juegos de ensayo ). En principio esta tarea es responsabilidad del usuario y no del jefe de proyecto o de los programadores. - Cual es el contenido de los entregables que se deben preparar. - Cual es la responsabilidad de cada parte. Cuáles son las tareas atribuidas a cada cual y en qué fechas deben estar terminadas. 111

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Quién se ocupa de la infraestructura. 3) Situar el proyecto en la organización general, por comparación con otros proyectos, para evitar conflictos de prioridad. 4) Presentar a las personas implicadas en el proyecto. 5) Definir las normas, procedimientos de informe, frecuencia de reuniones del comité de seguimiento ( en función de los riesgos ), circuitos de información ( para no herir susceptibilidades ), etc. Como trabajar en equipo En el apartado siguiente retomamos el aspecto psicológico de la gestión de un proyecto. Resumamos este aspecto diciendo que la comunicación es el punto más importante de la motivación. Comunicar e informar continuamente permite a menudo prevenir los conflictos y las desmotivaciones.

Aspectos relacionales * ¿ Cuáles son las motivaciones en el trabajo ? Un estudio sobre las motivaciones personales saca a relucir puntos interesantes que debe tener en cuenta el jefe de proyecto. Se presentan a continuación los factores de motivación. - La realización de si mismo Es la posibilidad de hacer, de proyectarse en el trabajo, de capitalizar lo realizado y de progresar personal y profesionalmente. - El reconocimiento de los méritos Durante el proyecto, el jefe de proyecto debe apreciar los resultados obtenidos, no globalmente sino individualmente. - La naturaleza del trabajo En si, la participación en un nuevo proyecto debería ser motivante. La naturaleza del trabajo, el salir de lo rutinario, es un factor potente de motivación. Pero aisladamente, este factor es irrelevante. Es preciso combinarlo con los otros.

112

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Pensemos en esa fórmula de ordenación lexicográfica PPP > PPR , en la cual PPP = Premio por la Participación en el Proyecto PPR = Premio por la Participación en la Rutina - Las responsabilidades El jefe de proyecto debe saber delegar su poder. Contravenir a esta regla es exponerse al fracaso. - La promoción El proyecto debe servir de trampolín a los miembros del equipo. Es preciso hacerles saber qué será de ellos cuando acabe el proyecto, cuales son los puestos a los que tendrán posibilidad de acceder. - El desarrollo personal En esto, como en la naturaleza del trabajo, el proyecto lleva en si este objetivo. En todo proyecto nos formamos, nos desarrollamos. Pero el miembro de un equipo no aporta más al proyecto de lo que recibe del mismo.

La otra cara de los aspectos motivantes es la de los aspectos desmotivantes, que perturban el proyecto. He aquí la lista de ellos. - La política y los procedimientos de la Empresa Es preciso preocuparse de no trastocar los hábitos, ni transformar el trabajo administrativo en una carga burocrática. Este es uno de los factores de riesgo contemplado por Mc Farlan. Puede que algunos técnicos rechacen ciertos procedimientos, por juzgarlos inútiles. El jefe de proyecto debe convencerles de su necesidad. - El porvenir de la Empresa Todo lo que tiene de motivante el proyecto por la novedad que aporta, lo puede tener de desmotivante por el vacío que deja detrás de él. Un proyecto está, en esencia, limitado en el tiempo. ¿Qué ocurrirá después? - Las relaciones humanas En el momento de la formación del equipo, es preciso agrupar a las personas que tengan una cierta afinidad. Se les puede colocar en tareas complementarias. Pero cuidado con crear un equipo dentro de un equipo. 113

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Las condiciones de trabajo Proporcione al equipo un entorno adecuado, donde cada cual tenga el espacio vital y el aislamiento necesario para un buen trabajo intelectual. Además del ambiente, no olvide las herramientas de trabajo. Cada cual ha de disponer de las suyas. Un ordenador por persona no es un lujo, sino una necesidad.

* Responsabilidades del jefe de proyecto Todo el arte del jefe de proyecto reside en la comunicación. Comunicar no quiere decir hablar, sino más bien escuchar. El jefe de proyecto tiene una gran responsabilidad hacia cada miembro de su equipo: darle las atribuciones necesarias a la buena marcha del proyecto. Veamos en qué se traduce: - Motivar al personal El jefe de proyecto indica individualmente a cada cual lo que espera de él. Le describe sus funciones, sus objetivos personales, su nivel de autoridad ( si es jefe de equipo ) y los resultados que espera de él.

- Dar responsabilidades Se confunden a veces objetivos y responsabilidades. Dar objetivos precisos no quiere decir imponer un método ni un plazo. Cuando se dan objetivos al comienzo del proyecto, se deja al jefe de proyecto decidir la forma de realizarlos. Lo mismo hay que hacer con los miembros del equipo. El jefe de proyecto debe ayudarles a planificar las actividades y se debe sentir responsable de los resultados que deben alcanzar. - Proporcionar la asistencia necesaria Para hacer responsables a los miembros de su equipo, el jefe de proyecto debe aconsejarles y animarles. Debe así mismo percibir sus necesidades, previendo los planes de formación o sesiones de información necesarias. - Apreciar el trabajo realizado A menudo es el punto débil de los jefes de proyecto: no se atreven a juzgar. No se pretende juzgar a las personas, sino apreciar sus trabajos. ¿ No se han alcanzado los resultados esperados ? No hay nada tan desagradable como trabajar en la indiferencia, como pasar 114

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

desapercibido. No olvidemos que el reconocimiento de los méritos es el motor primero de toda acción. - Recompensar sobre la base de los resultados Es también un punto importante de la motivación. La recompensa puede ser material o no. Es preciso recordar este aspecto al comité de seguimiento.

* Responsabilidades de los miembros del equipo A su vez, los miembros del equipo se comprometen a: - contribuir a la planificación eficaz del trabajo - realizar su parte de trabajo en los plazos establecidos, que ellos mismos han aprobado - informar al jefe de proyecto de las desviaciones y las dificultades encontradas, en relación con las normas predefinidas - respetar las normas y los procedimientos de trabajo y de control definidos al comienzo del proyecto * Cómo fijar los objetivos Una reunión de fijación de objetivos motivante es una reunión en el curso de la cual se toman en cuenta las propuestas y las expectativas de los miembros del equipo. Más que imponer unilateralmente sus puntos de vista, el jefe de proyecto debe establecer un plan de diálogo, tanto de objetivos de cada uno como del plan de acción correspondiente. Se recomienda adoptar, para tal reunión, el esquema siguiente: a) Definir y clarificar los objetivos de la reunión. b) Explicar el contenido de la propuesta, los motivos en los que se basa, integrando en lo posible las sugerencias y expectativas de los colaboradores.

115

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

c) Clarificar los eventuales desacuerdos ( actividades potencialmente conflictivas, resistencias y su razón de ser ) procurando insistir en los puntos de acuerdo. d) Definir una línea de acción que sea a la vez aceptable y admitida por la mayoría y que ponga de relieve los resultados esperados, el calendario de actividades, los recursos y los parámetros de control. Al término de esta reunión, se deberá haber dado respuesta satisfactoria a las preguntas siguientes: - ¿ Qué se va a hacer ? - ¿ Quién deberá hacerlo ? - ¿ Cuándo se deberá terminar el trabajo ? - ¿ En dónde se realizará el trabajo ? - ¿ Para qué se hará el trabajo ? - ¿ Cómo serán evaluados los resultados ? * ¿ Qué tipo de gestión adoptar ? Un jefe de proyecto es jefe ante todo. Debe dirigir y aconsejar a su equipo. Pero no se dirige de la misma forma a un principiante que a un experto, las dos categorías de personas que componen los equipos de proyecto. Hay varios tipos de gestión ( ver la tabla de Blake y Mouton, Tipos del 1.1 a 9.9, en donde se clasifican los tipos de gestión ).

116

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

TABLA DE BLAKE Y MOUTON

O R I E N T A D O:

A

A

LA

TECNICA

Tipo 1,9

Tipo 9,9

Tipo 1,1

Tipo 9,1

L A S

P E R S O N A S

Podemos resumir esta teoría considerando cuatro categorías de gestión: - La delegación. El jefe confía en los demás. Delega su poder de decisión (no el control). - La participación. El jefe invita a los demás a tomar ciertas responsabilidades. Estos dos primeros grupos se encuentran a la izquierda de la tabla de Blake y Mouton, formando las columnas 1 a 4. Es la gestión orientada al individuo. Anima y no impone soluciones técnicas. Los otros dos grupos ocupan la parte derecha de la tabla, formando las columnas 5 a 9. Es la gestión técnica. Aconseja, da directrices. 117

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- La venta. El jefe vende su proyecto, su solución, a los miembros del equipo. Se muestra comunicativo. - La explicación. El jefe explica su solución. Se impone; da directrices para realizarla.

Como jefe de proyecto: ¿ Cual debemos elegir ? ¿ Qué tipo de jefe debemos ser ? No hay elección posible. Un jefe de proyecto debe ser de los cuatro tipos a la vez, en función de la situación, según conlleve: - Urgencia: si una tarea se convierte en urgente, el jefe de proyecto impone su solución. El mismo toma la dirección de las operaciones. - Riesgo: el jefe de proyecto decide en las situaciones de riesgo. No es cuestión de delegar, hay que tomar responsabilidades. - Competencia y madurez de los miembros del equipo en la tarea a realizar: para una actividad dada, se puede clasificar a los individuos en cuatro grupos correspondientes cada uno de ellos con un tipo de gestión. El jefe de proyecto debe conocer a cada miembro de su equipo y dirigirle, en función de sus competencias, para la tarea que debe acometer. Así pues, un experto en Bases de Datos no tiene necesidad de ayuda en su especialidad, se vale bien solo, y el jefe de proyecto le delega su poder. Por el contrario, debe guiar al principiante, explicándole lo que debe hacer y cómo debe proceder.

Presentación del proyecto El jefe de proyecto es recibido por el comité de seguimiento y el comité informático para presentar su proyecto, los plazos, los riesgos, los costos y los beneficios. Esta reunión es capital para el resto del proyecto. 118

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Permite definir los límites de responsabilidad de cada cual. El jefe de proyecto presenta su planificación ( únicamente los aspectos temporales y de facturación ). Define los interlocutores para los distintos niveles de actuación. Sitúa el proyecto en la organización general, asigna prioridades. Pone a punto , si fuera necesario, un plan de formación del personal y de los miembros del equipo, sobre todo si subcontrata una parte del trabajo. El jefe de proyecto define el plan de informes (cómo, cuándo, a quién). El comité informático describe los documentos normalizados para informes y para el expediente del proyecto. En esta misma ocasión, el jefe de proyecto aclara los métodos empleados para dirigir el proyecto y llevarle a buen fin. Se discuten algunos aspectos prácticos ( restricciones de los edificios, aparcamientos, pausas de café, uso de restaurante de empresa, etc. ), que pueden afectar especialmente al personal subcontratado. Cuaderno de cargas del entorno El jefe de proyecto prepara un cuaderno de cargas en el cual describe el entorno del que precisa disponer. Creación del entorno Los diferentes especialistas técnicos se ocupan de la creación de dicho entorno. El objetivo de esta actividad es permitir al equipo trabajar desde el momento en que es constituido, sin pérdida de tiempo. Lo contrario desmotiva rápidamente y hace creer que el proyecto no suelta amarras. Reunión del equipo El jefe de proyecto reúne al equipo en su totalidad. Después tendrá una entrevista personalizada con cada uno de ellos. 119

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En la reunión general, el jefe de proyecto: - define los objetivos generales, el contenido y límites del proyecto - presenta la estructura del proyecto, quién hace qué, a quién se puede recurrir en caso de necesidad, a quién se informa - define las normas - fija los modos de informe, los plazos, las informaciones que hay que incluir, cómo y por qué. - motiva e impulsa a la acción. Al entrevistarse con el personal, el jefe de proyecto explica lo que espera de cada miembro del equipo, discute los detalles ( revisa conjuntamente la planificación ), habla de los problemas particulares (desplazamientos, horarios, formación, integración en el equipo , etc. ). Cada uno debe poder situarse en el proyecto, por comparación con el resto y respecto de la organización. El jefe de proyecto motiva personalmente a cada uno y le impulsa a la acción. La siguiente figura ilustra y resume lo anteriormente comentado.

120

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

121

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Herramientas Esta fase no requiere herramientas, pues los medios a utilizar son esencialmente de orden psicológico. Carpeta del proyecto En la carpeta del proyecto, debemos incluir las actas de las reuniones. La reunión con el comité informático y el comité de seguimiento es esencial, por lo que su acta deberá ser firmada, pues de alguna forma es un contrato de realización. Encontraremos, pues: - Descripción de los documentos y entregables a suministrar - Descripción del método de seguimiento - Descripción de las normas

Es buena práctica redactar un Manual del Proyecto, con el contenido siguiente: Objetivos, ámbito, alcance y enfoque del proyecto Puntos de partida y condiciones Lista de entregables Aseguramiento de la calidad y criterios de aceptación de los trabajos Organización del Proyecto: Papeles y Responsabilidades Planificación y calendario, control e informes, presupuesto y costes Factores críticos de éxito e identificación de riesgos Normativa del proyecto. Estándares. Documentación. Recursos y herramientas Gestión del Cambio. Plan de Formación. Plan de Comunicación. Gestión de incidencias y solicitudes de cambios. El Manual del Proyecto estará a disposición de toda la comunidad del proyecto y siempre será una referencia para el correcto entendimiento de las cosas.

122

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

SEGUIMIENTO Y CONTROL DEL PROYECTO El proyecto está en ruta. Se sabe a dónde va a llegar (objetivos) y cómo debería comportarse (planificación). Queda ocuparse de que: - no tropiece - avance, de acuerdo con la planificación fijada - el servicio prestado responda a las expectativas del promotor Debemos, pues, supervisar la duración del proyecto, la utilización de los recursos, la calidad de los servicios prestados y el presupuesto concedido. Igual que no sirve de nada planificar si no se puede controlar, tampoco sirve de nada controlar si no se pueden remediar las desviaciones constatadas. Se deberá informar regularmente al comité de seguimiento, que tomará las decisiones pertinentes. El jefe de proyecto propone, el comité de seguimiento dispone. El jefe de proyecto debe, pues: - saber en todo momento en que situación se encuentra el proyecto. - recopilar los informes sobre las actividades, costos y recursos utilizados. - informar al comité de seguimiento, que a su vez lo hará al comité informático, si ha lugar. - anticipar los problemas mediante un buen conocimiento de la evolución del proyecto. - respetar los plazos - tener reuniones regulares para mantener la motivación de los miembros del equipo y dar directrices precisas. El control del proyecto se efectúa a tres niveles: - individual, que permite verificar el cumplimiento de la tarea de cada cual, tanto desde el punto de vista cuantitativo como del cualitativo. - global, sobre el avance, contrastando lo planificado respecto del plan inicial 123

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

( ACTUAL vs PLAN ). - de rentabilidad, que indica el índice de rendimiento del proyecto o medida del avance. El control solo será eficaz si los participantes saben qué lugar ocupan en la organización y si conocen sus responsabilidades diferenciadamente con respecto a las de los demás.

TAREAS A Actividad 1 Actividad 2 Actividad 3 " " "

1

B

PERSONAS IMPLICADAS C D E F 2

4

G

3

Esta matriz dispone en sus filas las tareas del proyecto, y en sus columnas las personas implicadas en cada tarea. La notación se hace por medio de un código que define la responsabilidad de la tarea considerada. Se pueden distinguir cinco categorías de responsabilidad: 1: Responsable de la tarea. Solo se puede encontrar un código determinado por línea. Si no fuera así, una tarea podría tener varios responsables, consecuencia de falta de rigor en la subdivisión de tareas. 2: Supervisor de la tarea. La persona a quién el responsable informa directamente. 3. La persona que debe ser consultada para toda información referente a la tarea. 4. Las personas que pueden ser consultadas para toda información referente a la tarea. Dichas personas son, de alguna forma, las suplentes de las personas indicadas en el punto anterior. 124

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5. Las personas que deben ser advertidas de toda modificación de estatus de una tarea: cambio de especificación, finalización correcta, retraso, etc.

Se adjunta, eventualmente, los ejecutantes. En principio, ya se habían mencionado en la lista de recursos afectados a las tareas. Esta matriz permite apreciar la cuantía de trabajo de una persona determinada. Se anotará solamente las tareas clave (key tasks), es decir ese ( aproximadamente ) 20% de actividades que acaparan el 80 % del trabajo. Se tendrá cuidado de repartir equitativamente las cargas de trabajo y las responsabilidades. Control de la realización de los programas En caso de proyectos de conversión o desarrollo, nos vamos a enfrentar con un tipo de tarea particular: la realización de programas. Dicha tarea es difícil de dominar, pues la programación es un fenómeno poco controlable, que avanza sinusoidalmente, no de forma lineal, y que está sometida a un sinfín de factores, a menudo poco conocidos. El mejor programador puede pasar varios días trabajando sobre un problema, y después recuperar el tiempo perdido. No es, pues, posible planificar la realización de cada programa, pues supone un difícil control personal. ¿ Qué debe hacer el jefe de proyecto ? Primeramente debe confeccionar el inventario de todos los programas a escribir o convertir. Distribuir el trabajo por equipos de programadores, más que individualmente. Esta práctica, muy de moda en Japón, permite: 1) responsabilizar a un equipo sobre un conjunto de programas: el más fuerte del equipo sirve de motor a los otros. Ello constituye una excepción a la regla que dice que cada tarea tenga un solo responsable. 2) paliar las ausencias de un programador. Su trabajo no queda inacabado; los otros miembros del mismo equipo deben proseguir con él. 3) distribuir mejor la carga de trabajo. Los equipos se organizan según las necesidades. 125

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El avance de los programas se anota en un tablón que muestra la actividad de cada equipo:

E

Situación del Proyecto L D C P O I R Bloqueado

Equipo 1 Programa A Programa B " Equipo 2 Programa X Programa Y " Esta tabla colectiva muestra el estado de avance de los diferentes programas. El jefe de proyecto anota allí las fases por las cuales pasa el programa: E : el análisis está a disposición del equipo. L : el análisis está en fase de estudio ( Lectura ). D : el programador realiza el diseño del programa. C : el programador codifica el programa P : el programa está en fase de pruebas O : las pruebas han sido aceptadas por el equipo de cualificación I : el programa está en fase de integración en la aplicación R : el programa está recibido y cualificado. La tabla permite: - indicar la responsabilidad de cada equipo y su contribución al avance del proyecto. - saber la situación y cuál es el camino que queda por recorrer. Es una síntesis del trabajo realizado. - poner de relieve los embotellamientos del proyecto y redistribuir el trabajo si ello fuera necesario. En esa tabla, se pueden subrayar los trabajos clave ( key jobs ). Los programas clave deben ser distribuidos equitativamente entre los equipos y el jefe de proyecto se ocupará de que comiencen en primer lugar.

126

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

SEGUIMIENTO Y CONTROL SEGUIMIENTO-R

DIRECCION PLANIFICACION PROYECTOS

seguimiento

INICIO

CALIFICACION

DESARROLLO

CIERRE

PLANIFICACION

LANZAMIENTO

SEGUIMIENTO Y CONTROL

CIERRE DE FASE

REUNION C.S.

INFORMES AVANCE PROYECTO

RECEPCION TAREAS

REEVALUACION PLANNING

- Figura 11 -

El aspecto psicológico El control de avance de un proyecto debe ser un factor de motivación de los miembros del equipo. No se debe improvisar nunca. Debe ser planificado y realizado en función de reglas establecidas previamente. 127

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El control debe realizarse vis a vis, no por procedimiento escrito. De esa forma se tiene un contacto con cada miembro del equipo, lo cual es motivante, y además permite darse cuenta de la calidad del trabajo efectuado. A veces es útil colocar públicamente el estado de avance de cada uno en particular y del proyecto en general. La curva de rendimiento del proyecto es un buen indicador para los miembros del proyecto, pues visualiza el trabajo ya efectuado. Dicha curva debería tener siempre una curvatura constante. Si señala puntos de inflexión, el proyecto da muestras de estancamiento, y es en esos puntos cuando hay que reaccionar, tal vez redistribuyendo el trabajo entre los miembros del equipo y logrando una vez más su motivación. Desarrollo de una reunión Aunque el mejor medio de comunicación con los miembros del equipo sea el diálogo, es innegable que las reuniones formales son un medio eficaz para comunicarse con los demás, respecto de un tema definido con anterioridad. Las reuniones deben observar un esquema estricto: 1) El jefe de proyecto confirma el objetivo y solicita el acuerdo de todos sobre el motivo de la reunión. En principio, la convocatoria escrita de esta reunión debería indicar el objetivo perseguido. En la reunión hay que tener en cuenta lo siguiente: - no todo lo que se dice es necesariamente oído - no todo lo que se oye es necesariamente comprendido - no todo lo que se comprende es necesariamente aprobado - no todo lo que se aprueba es necesariamente realizado 2) El jefe de proyecto debe definir el procedimiento de la reunión: - Cual es el tiempo del turno de palabra. Quién arbitra en caso de conflicto, de discusión personal, de desviación respecto al objetivo. Cuando se hace pausa Quién levanta la sesión y cuando. - Cual es el papel de cada uno. Cuál es su tarea. Qué representa cada uno.

128

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) El trabajo efectivo puede entonces comenzar. Se pide a cada asistente que se presente. La utilización del YO es preferible al término menos definido de NOSOTROS. Se discute el objetivo, los resultados obtenidos y las acciones correctivas a emprender. 4) Cuando ha pasado el tiempo asignado, el jefe de proyecto detiene las discusiones, hace una síntesis de la reunión y se asegura de que el objetivo se ha alcanzado. Se levanta acta de las decisiones tomadas. 5) Cada cual puede, entonces, brevemente y en turno de palabra, hacer sus comentarios sobre la reunión. Es el "feed-back". Esto dura alrededor de media hora. Después se cierran definitivamente los debates. 6) El jefe de proyecto levanta entonces la sesión. El jefe de proyecto tendrá que enfrentarse a diferentes tipos de reuniones, que clasificamos a continuación por orden decreciente en cuanto a ambición de su objetivo: - reuniones de información, que son un feed-back de decisiones anteriores. Tienen como objetivo definir problemas. - análisis de alternativas que conducen a tomar una decisión sobre lo que se debe hacer. - Asignación de recursos que permiten elaborar un plan de puesta en funcionamiento.

Una reunión especial: La del comité de seguimiento La reunión del comité de seguimiento tiene un objetivo preciso e inmutable: tomar decisiones en base a propuestas hechas por el jefe de proyecto, cuando hay divergencias (notables) entre la planificación y la realización. Previamente a estas reuniones, el jefe de proyecto envía el balance del proyecto y las soluciones posibles para solventar conflictos o para mejorar el rendimiento del proyecto. Dicho informe responde a cuatro cuestiones: 1) Dónde está situado el proyecto 2) A donde se desea llegar. Cuáles son los objetivos a alcanzar y cuáles son las desviaciones constatadas ( desde el punto de vista de la duración y el presupuesto ). 129

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) Como corregir las desviaciones. El jefe de proyecto explica las alternativas, las acciones y los recursos necesarios para corregir el tiro. 4) Como saber a dónde se llegará. El jefe de proyecto cita los medios puestos en funcionamiento para medir el efecto de las acciones correctivas. El proyecto está en ruta ( ha sido lanzado ). Se sabe a donde va ( se han establecido objetivos claros ). Es preciso ahora ocuparse del resto que queda en el camino ( para que no dé el patinazo ). Si es posible hay que respetar la planificación inicial. Nos permitimos recordar que hay dos grandes principios que rigen el universo : la inercia ( que impide que las cosas se muevan por ellas mismas ) y la entropía ( que es la degradación de la energía de un sistema que acaba por detenerlo ). Las acciones tomadas en el lanzamiento del proyecto intentan luchar contra la inercia. Las acciones que vamos a llevar a cabo en la fase de control van a intentar oponerse a la entropía. Recepción e iniciación de las tareas A intervalos regulares, el jefe de proyecto recibe las tareas terminadas ( p.e. el viernes a mediodía ). Recibe las tareas desde el punto de vista cualitativo y cuantitativo. Discute las tareas en curso y las dificultades encontradas por los miembros del equipo. Cada miembro del equipo le remite su informe de actividad, que es el estadillo de los trabajos efectuados. El jefe de proyecto no se contenta con recibir las tareas acabadas, inicia también nuevas tareas. Para ello se sirve de herramientas informatizadas. Reevaluación de la planificación Es poco probable que la planificación sea escrupulosamente respetada. El jefe de proyecto debe ponerla al día.

130

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Reunión del comité de seguimiento El jefe de proyecto compara la planificación actual (ACTUAL) con la planificación prevista (FORECAST). Las divergencias entre las dos deben ser justificadas al comité de seguimiento, y se deben prever medidas correctivas.

NOTA Si una actividad se retrasa, no es suficiente indicarlo en la planificación. Hay que preguntarse si la estimación inicial era correcta y en todo caso revisarla. Es mejor prever modificaciones mayores de la planificación y atenerse a ella, que tener que volver a atrás como resultado de la reunión con el comité de seguimiento.

Con motivo de la misma ocasión, el jefe de proyecto presenta un balance financiero de su proyecto. Las actividades que acabamos de describir forman el mínimo estricto. Además de ello, el jefe de proyecto puede: - establecer un gráfico de avance del proyecto que será colocado a la vista de todo el mundo. - determinar la velocidad de avance de su proyecto, la tasa de evolución, el coeficiente de utilización del equipo, la previsión de las necesidades futuras, el coeficiente de productividad,. Todas estas técnicas especiales serán explicadas en el capítulo siguiente. Herramientas El seguimiento del proyecto se puede hacer, en este momento, a partir de la función "despertador" de alguna herramienta informática, que nos advierte diariamente del estado en el cual se debería encontrar el proyecto. Estos útiles permiten un seguimiento eficaz y diario, al posibilitar la fácil reevaluación de la planificación. 131

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La comparación entre el ACTUAL y el FORECAST, así como el balance financiero se realizan automáticamente si utilizamos una herramienta informática.

Medida del avance del proyecto Para proyectos complejos, a menudo es útil conocer la velocidad de avance del proyecto, que nos permite informar sobre la tendencia del proyecto a retrasarse, y sobre la tasa de utilización de los recursos, que indica sobreevaluación o trabajo fuera de normas. Para calcular lo anterior, debemos conocer una serie de factores: P: Tiempo planificado, en horas por periodo de referencia (en principio puede ser por semana ), que es la periodicidad de control del proyecto. T: Tiempo efectivo de trabajo efectuado por el periodo de referencia. R: Trabajo realizado por comparación con el trabajo planificado (P) A: Trabajo añadido ( en horas ) por introducción de nuevas tareas. Por ejemplo, se ha planificado un trabajo de 15 horas para la semana 8. Los miembros del equipo han trabajado efectivamente 19 horas ( ver las Time Sheets ), pero solo se ha efectuado el 80 % del trabajo previsto, es decir 15 * 0,8 = 12 horas. Nuestras medidas son, pues: P=15, T=19, R=12 Ello nos va a permitir calcular un cierto número de evaluaciones cuyo fin es prever el comportamiento futuro de nuestro proyecto, y por lo tanto reaccionar más rápidamente a los acontecimientos. - carga suplementaria ( a replanificar ): C=T-R Es decir C = 19 - 12 = 7 horas - tasa de avance para el periodo de referencia: V=R/T Es decir, para la semana 8, la velocidad es 12/19 = 0,63 132

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- tasa media de avance V'= f * V + (1 - f) * V'

Donde f es un factor de rectificación que puede tomar valores entre 0 y 1. Cuanto mas cerca esté de 0, mayor es la rectificación ( se desestiman los extremos ). Cuanto más cerca esté de 1, no se tienen en cuenta las medidas más recientes. En nuestro caso, si se toma 0,1 como factor de rectificación y la media precedente es 0,98, la nueva media será: V'= 0,1 * 0,63 + (1 - 0,1) * 0,98 = 0,945 Si se quiere tener en cuenta las medidas más recientes ( el retraso actual no es accidental ), se puede tomar un valor de 0,4 como factor de rectificación,. Ello nos da: V'= 0,4 * 0,63 + (1 - 0,4) * 0,98 = 0,84 Podemos concluir que nuestro proyecto se retrasa ( la media es inferior a 1), y que comienza a estancarse ( la media baja, la curva se inflexiona ).

- coeficiente de utilización de los recursos: U=T/P Sea en nuestro caso: 19/15 = 1,27 El equipo está sobrecargado ( U > 1 ) y trabaja mas de lo previsto.

- coeficiente medio de utilización de los recursos: U'= g * U + (1 - g) * U' con g como factor de rectificación, totalmente independientemente de f, pero respondiendo a las mismas características.

133

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En nuestro caso ( g = 0,1 ), si el coeficiente medio precedente era 0,95, el nuevo coeficiente será: U' = 0,1 * 1,27 + 0,9 * 0,95 = 0,98 La planificación de recursos para este proyecto permanece correcta. Con g= 0,4, la tendencia se invierte y obtenemos: U'= 1,078 Contrariamente a lo que la sencillez de la formula podría hacernos creer, la aproximación exponencial tiene en cuenta TODAS las medidas de forma regresiva.

- la carga inicial corregida se calcula como se indica: I = I '' + A donde I'' es la carga precedente, expresada en horas.

- evolución del proyecto: E = I / I' donde I' es la carga inicial del proyecto ( el acumulado de la duración de las tareas del PLAN inicial ). Si I' es 245 horas ( constante, ya que el PLAN nunca se modifica ) e I toma el valor 260 ( por haber añadido tareas ), el factor de evolución es: E = 260 / 245 = 1,06 El proyecto crece, pues, en tamaño ( E > 1 ). - la carga remanente se calcula: Cr = C + A - R Si nos quedaran 120 horas ( de las 260 previstas ), la carga remanente sería: Cr = 120 + 0 - 12 = 108 horas - la necesidad futura se expresa: B = ( Cr * U') / V' En nuestro caso, nuestra necesidad futura será: B = ( 108 * 0,98 ) = 112 horas Se puede, entonces, prever un alargamiento de la planificación del orden de 4 horas. Teniendo en cuenta medidas más recientes ( factores de rectificación de 0,4 para f y g), notamos un alargamiento de 31 horas, es decir el 28%, lo 134

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

que corresponde a una situación en la que nada puede presagiar que la eficacia va a mejorar: B = ( 108 * 1,078 ) / 0,84 = 138,6 horas.

Carpeta del proyecto Cada reunión del comité de seguimiento debe ser anotada en el expediente del proyecto donde encontramos, para esta fase: - Informes de avance del proyecto ( Actual vs Plan ), con las soluciones propuestas para ajustarse a los plazos y decisiones tomadas por el comité de seguimiento. - Balance financiero del proyecto ( costes y beneficios ). - Estadillo de prestaciones de cada participante . El jefe de proyecto rellena los informes de actividad que el remite, con una nota explicativa, cada viernes a cada uno de los participantes. Estos indican las actividades a realizar, la duración prevista, el porcentaje de la carga de trabajo, el tipo de actividad ( si se vislumbra contabilización ), y el centro de costos al que se debe imputar la prestación, si se prevé un seguimiento analítico. Cada miembro del equipo rellena, día a día, el tiempo empleado para cada actividad, que totaliza al fin de la semana. Este informe de actividades, entonces, remitido al jefe de proyecto, que anota las observaciones eventuales del ejecutante. - Diario de a bordo del proyecto: anotación de los acontecimientos principales que pueden influir en el proyecto.

FIN DE UNA FASE La subdivisión del proyecto en lotes o fases tenía una doble finalidad: 1) Permitir una facturación y entrega escalonada del proyecto, pues cada fase forma un todo que puede ser disociado del resto, puede aportar un nivel de servicio perfectamente especificado al usuario. 135

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El abandono del proyecto no perjudica el cobro de las fases ya realizadas. 2) Dar al proyecto incentivos humanos, fragmentándolo en subproyectos que no sobrepasen los 8 o 10 meses, que constituye un periodo después del cual la motivación decrece. Cada lote, cada fase, tiene sus propios objetivos, está bien definida, limitada y es objeto de una recepción individual, prevista en el cuaderno de cargas del proyecto. El fin de una fase siempre tiene como resultado la entrega de un subproducto. El aspecto psicológico La recepción puede dar lugar a observaciones, a objeciones formuladas por el promotor. Son consignadas en el proceso verbal de recepción, pero no deben perturbar al proyecto; la fase siguiente debe comenzar. El jefe de proyecto se ocupará de que solo una pequeña parte del equipo se dedique a tratar las objeciones formuladas.

136

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

CIERRE DE FASE

Titulo

CIERRE-F CIERRE-F-R DIRECCION PLANIFICACION PROYECTOS

seguimiento

INICIO

CALIFICACION

DESARROLLO

CIERRE

PLANIFICACION

LANZAMIENTO

SEGUIMIENTO Y CONTROL

CIERRE DE FASE

CIERRE FINANCIERO

REDEFINICION OBJETIVOS

EVALUACION ALTERNATIVAS

REPLANIFICACION

ELECCION DE SOLUCION

BALANCE ACTIVIDADES

- FIGURA 12 -

Esta etapa no debe eternizarse aunque haya numerosas tareas a acometer, todas ellas por parte del jefe de proyecto. Cierre financiero La subdivisión en fases tiene como objetivo facturar y entregar separadamente partes de trabajo realizadas. El promotor recibe los lotes a medida que se van realizando. Por eso, si el proyecto cambia de objetivos o se detiene prematuramente, las prestaciones efectuadas no se pierden. 137

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para llevar a término este proyecto, es preciso prever: a) en el cuaderno de cargas, la definición de cada lote, con su objetivo, su contenido y sus restricciones. b) al comienzo de cada fase, a más tardar, los procedimientos de recepción del lote. Dichos procedimientos deben ser consignados por escrito. Determinan la naturaleza de la recepción ( que pruebas se han de efectuar ), la identidad de la persona que suministra los juegos de ensayo y la forma en la cual se debe desarrollar la recepción ( qué hacer si las pruebas dan resultados negativos ). c) la recepción de cada lote debe figurar en la planificación, justo antes de la actividad "facturación" o "entrega". Balance de las actividades El jefe de proyecto se centra en las actividades pasadas. Reflexiona sobre el rendimiento del equipo, su cohesión, su motivación. Reúne a su equipo para hacer balance cuantificado del avance de los trabajos, mostrándoles las desviaciones respecto a las previsiones y tratando de obtener consecuencias de ello. Después, se entrevista individualmente con cada miembro del equipo, para hacer un balance personal, situando a cada cual en el proyecto, por comparación con los objetivos a alcanzar. Si debe haber cambios, los comunica al comité de seguimiento, que decide la actitud a adoptar. Redefinición de objetivos En función de los objetivos esperados, los acontecimientos pasados y la enseñanza que se ha podido deducir, el jefe de proyecto y el comité informático determinan los objetivos de la nueva fase. Evaluación de alternativas En la misma reunión, se determinan todas las alternativas posibles para alcanzar los nuevos objetivos. Se estudia el riesgo que puede hacer correr al proyecto cada alternativa. Así pues, por ejemplo, decidir introducir un generador automático de programas en medio de un proyecto conlleva ciertos riesgos: pérdida de tiempo debido al aprendizaje, inadecuación de la herramienta de cara a las normas o dificultad del equipo a asimilar los nuevos procedimientos. 138

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Elección de una solución El comité de seguimiento encarga al jefe de proyecto analizar, simular, y ensayar las diferentes posibilidades y remitir un informe sobre las elecciones posibles. El comité de seguimiento, con la ayuda de estos elementos y la opinión del jefe de proyecto, toma una decisión. Planificación El jefe de proyecto vuelve a su soledad y rediseña su planificación en función de los nuevos objetivos y los nuevos medios. Informa entonces al comité de seguimiento, que da o no luz verde al avance del proyecto. La nueva planificación debe incluir un balance financiero y, si fuera necesario, un nuevo estudio de riesgos. Reunión Comité de Seguimiento En función de los objetivos esperados en esta fase y los acontecimientos pasados, el C.S. junto con el jefe de proyecto puede modificar los objetivos de las siguientes fases. Herramientas Esta fase pone en marcha los útiles informáticos de los que hemos hablado anteriormente. Ello nos va a permitir reestimar duraciones y riesgos así como reevaluar planificaciones. Durante esta fase, donde la psicología juega de nuevo un gran papel, el consultor en gestión de proyectos hace un balance cuantitativo de las actividades realizadas, objetivamente, ateniéndose a las cifras, sin realizar juicios, a no ser sobre los procedimientos empleados. Dicho balance ayudará al jefe de proyecto en su reevaluación, ya que pondrá en evidencia la productividad real del equipo.

139

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Carpeta del proyecto En la carpeta del proyecto encontramos: 1) El proceso verbal de recepción parcial del lote, con las eventuales observaciones y las objeciones. Dicho documento es firmado por el promotor. 2) Informe de las reuniones del comité informático, acerca de los nuevos objetivos y la elección de métodos que hay que adoptar. 3) Todos los informes generados con las herramientas informáticas de estimación y planificación de las que se disponía desde las etapas de análisis del riesgo y la planificación.

5.11

CIERRE DEL PROYECTO

El fin del proyecto es un momento importante desde el punto de vista CIERRE-R psicológico ( disolución del equipo ) y desde el punto de vista organizativo. El jefe de proyecto cede sus responsabilidades al equipo de explotación, que se encargará del mantenimiento de la aplicación. CIERRE-F CEC IER EN DIR CR IO PL ANIFIC CIO PR OYECATO SN

INICIO

RECEPCION

CALIFICACION

BALANCE DEL EQUIPO

seguimiento

DESARROLLO

BALANCE DEL PROYECTO

- Figura 1 4 0 13 -

PLAN DE ACCION

CIERRE

REUNIONES DE CIERRE

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El aspecto psicológico No es fácil clausurar un proyecto, pues se van levantando barreras psicológicas a medida que el proyecto avanza hacia la fase final. Por una parte aparece la laxitud en el equipo y por otra los usuarios finales comienzan a perder miedo hacia los cambios que se preparan. Peligros que vienen del equipo Una máxima que se confirma a menudo en la realidad de los medios informáticos: un proyecto avanza normalmente hasta el 90%; después se estanca ahí definitivamente. Las causas de esta situación son múltiples: - Una cierta dejadez puede aparecer. El continuo stress acaba por tener consecuencias negativas; los miembros del equipo pierden su motivación y el proyecto se estanca. Es el caso de los proyectos largos que no han sido subdivididos en fases. - Nos contentamos con éxitos parciales. Todo ha ido bien hasta ahora; no hay razón para que no siga así en el futuro. Se baja la guardia. - El fin del proyecto significa la incógnita, el retorno a una situación menos incentivante. Se trata, pues, de que la situación actual dure todo lo que se pueda. - Los miembros del equipo se sienten atraídos por algún otro proyecto. Se desinteresan por el proyecto en curso. Salvo para la última causa, solo hay un remedio: informar, comunicar, motivar. El jefe de proyecto debe dialogar continuamente con los miembros de su equipo. Es el precio del éxito. Peligros que vienen del usuario Para el usuario, el problema es diametralmente diferente. Para ellos no llega el fin, sino el comienzo. Tienen miedo de la incógnita que se perfila por el horizonte. Temen los nuevos procedimientos. Este temor se puede manifestar de dos formas: - tratan de posponer la recepción del proyecto.

141

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- tratan de desviar al proyecto de su objetivo. Los remedios son numerosos. Residen por un lado en la fijación precisa de los objetivos y modos de prueba en el cuaderno de cargas y por otro en las técnicas de análisis que privilegian la comunicación y el trabajo en equipo mixto usuarios-informáticos para realizar el prototipo de la aplicación. El objetivo primero de esta etapa está en la recepción definitiva del producto realizado. Al final del proyecto, hay que dar a cada miembro del equipo un balance sobre su comportamiento. Recepción Como hemos visto en la etapa precedente, una recepción no se improvisa; al contrario, se prepara desde el comienzo del proyecto, ya que su contenido y sus modalidades deben ser definidas en el cuaderno de cargas. La recepción de un proyecto se anuncia a todo el mundo, como se hizo con el lanzamiento. Es preciso que los mecanismos de facturación y desubicación de recursos funcionen. Balance del equipo El equipo ha hecho un buen trabajo. Cada uno de sus miembros debe saber cómo ha sido juzgado. El jefe de proyecto no debe olvidar este punto psicológico importante. Balance del proyecto Para afinar en las estimaciones futuras, el consultor en gestión de proyectos recopila un máximo de datos sobre el desarrollo del proyecto. Completa así el trabajo que se ha realizado en el curso del proyecto o al final de cada fase. Las informaciones recopiladas incluyen el tiempo realmente dedicado, las desviaciones con respecto a las previsiones iniciales (PLAN), las causas de las desviaciones, etc. Las herramientas son también juzgadas para conocer su eficacia y el rendimiento que se puede esperar de ellas. 142

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Plan de acción El jefe de proyecto y el promotor se reúnen para determinar que va a seguir al proyecto. En el transcurso de esta entrevista se debe fijar una fecha para realizar una auditoría del sistema cuando la aplicación haya alcanzado la velocidad de crucero. Dicha auditoría será sobre el hardware (eficacia), el software (cómo reacciona ante anomalías), y la aplicación de los procedimientos previstos en las especificaciones del sistema. Esta auditoria constituye, de hecho, un nuevo proyecto. Se define otra fecha para revisar los circuitos de información, cuando el sistema esté en la fase de madurez. Se estudia, entonces, la conformidad del sistema respecto a las exigencias de los usuarios. Reunión de cierre El proyecto ha comenzado con una reunión del comité de informática y del comité de seguimiento. Termina con una reunión de los mismos comités para sintetizar el balance (se subrayarán los puntos positivos) y levantar acta de las acciones futuras. Carpeta del proyecto En el expediente del proyecto encontramos ahora: 1) Proceso verbal de recepción y clausura del proyecto. 2) Balance del proyecto, con los acontecimientos clave ocurridos en el curso del proyecto y las conclusiones que puedan ser interesantes para los proyectos futuros. Los capítulos principales de dicho documento son los siguientes: a) Descripción general del proyecto. b) Éxitos obtenidos c) Principales problemas encontrados: - planificación no respetada - incumplimiento del proyecto 143

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- consideraciones sobre los miembros del equipo - relación con los usuarios - soporte por parte de la Dirección d) Retrospectiva: ¿Qué habría que hacer si hubiera que realizar un proyecto similar?

144

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5.12

METODO PERT

Dada la extensión de la explicación que requiere el Método PERT, se ha dejado en un apartado final del capítulo dedicado a la gestión de proyectos. El método PERT es un útil de ordenamiento de proyectos que muestra las concatenaciones que existen entre las actividades, a diferencia del método GANTT que muestra la disposición de dichas actividades en el tiempo. En el texto que sigue se hace referencia a los elementos necesarios y los resultados obtenidos por los software de implantación del método PERT existentes en el mercado. ¿Cuáles son los elementos que hay que suministrar a PERT, y cuáles son los resultados que obtenemos? Proporcionamos el conjunto de actividades. Obtenemos: fechas, márgenes, tablas, planificaciones, diagramas de Gantt, plazos, recursos y costos. ENTRADA DE DATOS Para obtener el grafo o red de actividades, que es el fin de la primera fase, debemos establecer la lista de tareas (o actividades) de las que consta el proyecto, y atribuirles una duración. Después se ordenarán en secuencia y se obtendrá una red de actividades interdependientes. Análisis de las tareas Este estudio se hace sin precipitación, pues es muy importante y de él depende la calidad de los resultados obtenidos. PERT no es un método infalible. Los resultados no son sino el reflejo de las informaciones que proporcionamos al método (programa), luego su bondad dependerá de la de las entradas. Es aconsejable proceder de lo general a lo particular, es decir, subdividir el proyecto en grandes fases y analizar por separado cada una de ellas. Vamos a ilustrar la explicación con un ejemplo, consistente en un proyecto informático cuyo objetivo es convertir una aplicación informática. Una parte de los programas serán convertidos tal cual y 145

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

otra parte será desarrollada sobre una base de datos. Paralelamente a la conversión de los programas se acondicionarán nuevos locales. ¿Cuáles son las etapas principales del proyecto? I II III IV V VI VII

Formación del personal Estudio de la base de datos Diseño de la nueva aplicación Desarrollo de la nueva aplicación Conversión Pruebas en paralelo Acondicionamiento de nuevos locales

El método, que va de lo general a lo particular, ofrece diversas ventajas. Permite fijar objetivos intermedios bien definidos que son al mismo tiempo puntos de control y lotes que pueden ser objeto de facturación independiente. Además, si el proyecto se extiende a un periodo largo, no siempre es posible precisar desde el comienzo las tareas a realizar hacia el final del proyecto. Este método permite una planificación del conjunto del proyecto que se podrá afinar a medida que avanzan los trabajos. Cuando se dispongan de informaciones suplementarias se podrá proceder a efectuar análisis más finos. Es el caso, por ejemplo, de la estimación del tiempo que lleva el desarrollo de aplicaciones. Hemos visto que la mejor forma de estimar dicho tiempo es confiar en la experiencia adquirida con el mismo equipo, en las mismas condiciones. En nuestro ejemplo, ese no es el caso. Vamos a detallar cada una de las etapas principales. No es preciso planificar tareas que no se vayan a poder controlar. La duración media de las tareas no debe ser inferior a la frecuencia de los controles. Si efectuamos un control semanal, no hay que detallar el proyecto al día, sino a la semana. Si no, una tarea crítica (veremos mas adelante el significado de este término) de un día podría llevar 6 días de retraso sin darnos cuenta de ello. En la subdivisión en tareas aparecen otras restricciones: -

una actividad debe tener un solo responsable una actividad se debe ejecutar en un sólo lugar 146

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

. Como el control se hace una vez a la semana, ajustamos a dicho periodo nuestro nivel de detalle. No detallamos las fases III, IV y V. Lo haremos en una fase posterior del proyecto A continuación detallamos la lista de las actividades de nuestro proyecto, y su duración en días. GRUP

Nº

O

ACT.

I

01

DURACION

5

06 07 08

Introducción Utilización MSF (Basico) JCL MSF (Extensión) Manejo de ficheros COBOL (especificaciones) P11 Conceptos ADW Programación ADW UTIL-08 JFA/EXPT JFA

09 10 11

Curso programación MSF Curso programación. ADW/Forms Curso Programación. JFA

5 5 5

01 02

Fijar objetivos Selección de datos Eliminación de datos inútiles Creación de categoría Identificación de llaves acceso Supresión de repeticiones Dependencias funcionales Dependencias transitivas Identificación de Jerarquías Ensamblaje de la red Supresión de redundancias Optimización de la estructura

5 5

02

03 04 05

II

DESCRIPCION

03

04 05

147

7 5 5 5 5 4 4 3

5

5 5

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

III

01

Diseño de la nueva aplicación

20

IV

01 02 03 04

Ordenes de las líneas RTT Orden de la biblioteca Conexión con Modem2 Desarrollo de programas

65 5 2 85

V

01 02 03

Conversión Conversión de ficheros Creación JCL

20 10 10

148

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

GRUP

Nº

DESCRIPCION

O

ACT.

VI

01 02 03 04

Pruebas en paralelo Formación de usuarios Formación de operadores Procedimientos para operadores

15 5 5 5

VII

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Solicitud de la sala Elección de la sala Edición del cuaderno de cargas Elección del contratista Demolición Modificación de fontanería Ventanas y puertas Aislamiento Falso suelo Decoración Falso techo Persianas Preparación conductos de aire Instalación conductos de aire Calorifugado Cableado conducto de aire Pruebas de arranque Puesta en marcha Cableado eléctrico Instalación del alternador Últimos retoques Detector de humo Limpieza Instalación del hardware Instalación del software Instalación del mobiliario Pruebas

2 15 10 10 5 5 5 5 5 5 5 5 10 10 5 5 10 15 5 5 5 5 5 10 5 5

149

DURACION

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Encadenamiento de las tareas Este es el punto más delicado, más largo y más difícil del método, ya que no existe nada determinado acerca de cómo actuar. Para cada tarea, debemos plantearnos dos preguntas cuyas respuestas se obtienen de la tabla precedente: -

¿Cuáles son las condiciones para empezar el proyecto?

-

¿Qué tareas deben suceder a las condiciones de comienzo?

La tarea VII/24 (instalación del hardware) sólo puede comenzar después de la limpieza de la sala (VII/23) y a su vez condiciona a la instalación del software (VII / 25). Además, para cada tarea que se pueda emprender, es preciso disponer de recursos, medios financieros, potencial humano y de informaciones. En nuestro ejemplo, hemos omitido preocuparnos de este aspecto. Ello conduce a planificar la ejecución paralela de dos tareas realizadas por la misma persona, lo cual constituye un error. Una vez que hemos encontrado respuesta a todas las tareas, se puede comenzar a trazar el grafo. Primeramente, consideramos la red en forma de tabla.

RANGO

1

2

3

4

5

6

7

8

9

10

Se clasifica las tareas según su rango, es decir, de acuerdo con sus dependencias. Las tareas de rango 1 son las que pueden comenzar inmediatamente, por no depender de otras. En nuestro ejemplo, son las tareas: I/1 II/1 IV/1 VII/1

Curso de introducción Objetivos de la base de datos Ordenes de las líneas RTT Solicitud de la sala 150

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para rellenar dicha tabla, es más fácil separar las principales etapas del proyecto. Las relaciones entre ellas serán establecidas en último lugar. Después de las tareas de rango 1, se colocan en la tabla las que son directamente dependientes y se procede así, sucesivamente, hasta que se hayan insertado todas las tareas. Se dibuja después las relaciones que existen entre las actividades. Se simbolizan dichas ligazones por flechas. A menudo es necesario ejecutar varios trazados antes de llegar a un resultado satisfactorio, es decir claro y fácil de leer. Ahora que tenemos una visión global del proyecto, podemos pasar a la elaboración de la red.

Gr. I

1

2

3

4

5

6

7

1

2

3

4

5

6

7

9

Gr.II

1

2

3

9

10 11

12 13

gpr-e7-r 11

10 4

Gr.III Gr.IV 1

8

5

1 3

4 1

Gr.V

2 3

Gr.VI

151

1

3

2

4

14

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Trazado de la red En el grafo, utilizaremos dos símbolos: -

La flecha, que simboliza la tarea. La longitud de dicha flecha no tiene significado particular, es decir, no es proporcional a la duración de la actividad.

-

el círculo, que simboliza una etapa (o un acontecimiento). La etapa marca el comienzo de cada tarea, así como su fin.

Abordamos ahora un punto importante del método PERT: toda tarea está completamente definida por dos etapas y cada tarea solo se corresponde con una flecha. Ello nos lleva a introducir un nuevo concepto, el de tarea ficticia. En efecto, para representar la siguiente relación: El diseño de la B de D (II/4) debe seguir al curso JFA/EXPT (I/7) y el estudio de las categorías de datos (II/3). Además, el curso JFA (I/8) debe suceder al curso JFA/EXPT (I/7).

152

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta representación no es satisfactoria. Expresa todas las condiciones, pero introduce una suplementaria: el curso JFA (I/8) sucede al estudio de las categorías de datos (II/3), condición no impuesta. Debemos recurrir a un artificio, introduciendo una tarea ficticia cuyo único fin es mostrar que hay una relación de encadenamiento entre dos tareas.

Estas tareas ficticias, definidas por dos etapas, tienen duración nula. Se pueden también utilizar dichas tareas para simplificar el grafo y evitar ramas demasiado largas. NOTA: En algunos programas, se pueden crear tareas ficticias de duración no nula para indicar que dos tareas se suceden después de una pausa. De esa forma, el curso de introducción (I/1) y el curso de MSF (I/2) están separados por una semana. La red se muestra de la siguiente forma:

153

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Numeración de las etapas Para PERT, como hemos visto, una tarea está definida por dos etapas. Son esas dos etapas las que hay que suministrar al programa. Debemos, pues, numerarlas. Dicha numeración es, de hecho, arbitraria, y solamente está limitada por las restricciones del programa utilizado. Ahora podemos trazar la red. Pero antes hay que recordar dos hechos importantes en un proyecto: -

todo proyecto tiene 1 fecha de comienzo todo proyecto solo contempla 1 solo objetivo

En estas condiciones, el grafo solo tendrá una etapa de comienzo (la 1 en nuestro ejemplo), y una sola etapa de fin (la 13). Por el momento, limitaremos las exigencias de PERT a tres informaciones: -

etapa del comienzo de la tarea etapa de fin de la tarea duración de la tarea

Con estos datos, PERT puede ordenar el proyecto y determinar el camino crítico, que es uno de sus fines. Estudiemos ahora los resultados obtenidos con estas tres únicas informaciones.

154

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

RESULTADOS Vamos ahora a detallar el mecanismo del programa PERT para ver cuál es el significado de las informaciones que nos proporciona: -

fecha de comienzo como pronto (Earliestá Start : ES) fecha de comienzo como tarde (Latestá Start : LS) fecha de finalización como pronto (Earliestá Finish : EF) fecha de finalización como tarde (Latestá FInish : LF) margen total (Total Float : TF) margen libre (Free Float : FF) camino crítico (Critical Path : *)

Indicamos la traducción inglesa, pues la literatura sobre este tema es fundamentalmente americana. Digamos, también, que tarea se traduce por "Work Item". Los cálculos que PERT efectúa sobre las fechas pueden ser relativos al comienzo del proyecto. Así pues, si la primera tarea dura 5 (unidades), su fecha de comienzo como pronto será 0 y su fecha de finalización como pronto será 5. Si el cálculo de fechas es absoluto, es preciso proporcionar a PERT un calendario que tenga en cuenta los días festivos, así como la fecha de comienzo del proyecto. Este es el método que hemos utilizado y cuyos resultados presentamos a continuación.

155

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

GRUPO

I

Nº ACT.

DESCR.

01

06 07 08

Intro Utiliz. MSF (B JCL MSF (E Manejo COBOL P11 ADW Pr ADW IDSUTI DDL/DM JFA

09 10 11 01 02

02

03 04 05

II

03

04

05

DUR

EF

LS

LF

5 07/01

ES

14/02

22/01

29/01

11 0

TF - FF

10 21/01

04/02

05/02

19/02

11 0

5 5 04/02 5 11/02

11/02 18/02

19/02 26/02

26/02 05/03

11 0 11 0

5 18/02

25/02

05/03

12/03

11 0

4 25/03 4 15/04 3 19/04

29/03 19/04 24/04

10/04 30/04 07/05

16/04 07/05 13/05

11 0 11 0 11 0

Cu MSF Cu Fo Cu JFA

5 04/02 5 11/04 5 24/04

11/02 18/04 02/05

03/04 11/04 13/05

11/04 18/04 21/05

42 42 0 0 11 11

Objetivos Sel dat El dat Categor Llaves Sup rep Dep fun Dep fra ld jer Jer zon Ensambl Sup red Opt est

5 07/01 5 14/01

14/01 21/02

03/04 11/04

11/04 18/04

62 0 62 0

5 21/01

28/01

18/04

25/04

62 0

5 28/01

04/02

25/04

03/05

62 0

5 04/02

11/02

03/05

13/05

62 0

III

01

Dis apl

20 18/04

21/05

0 0

IV

01 02 03 04

Lín RTT Bibliot Modem2 Des pro

65 07/01 5 2 09/04 85 21/05

09/04

0 0

11/04 19/09

0 0 0 0

156

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

GRUPO

Nº ACT.

DESCR.

V

01 02 03

Convers C fiche Cre JCL

20 10/07 07/08 22/08 19/09 10 19/09 03/10 10 19/09 03/10

30 0 0 0 0 0

VI

01 02 03 04

Pruebas F usuar F opera Pro ope

15 5 5 5

03/10 03/10 03/10 10/10

24/10 10/10 10/10 17/10

17/10 10/10 17/10

24/10 17/10 24/10

0 0 10 10 5 0 5 0

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

S sala El sala c carga contrat Demolic fontane Ventana Aislam F suelo Decorac F techo Persian Pr cond In cond Calorif Cabl Pruebas P en ma Cablead alternd retoque D humo Limpiez I hardw I softw I mobil

2 15 10 10 5 5 5 5 5 5 5 5 10 10 5 5 10 15 5 5 5 5 5 10 5 5

07/01 09/01 30/01 13/02 27/02 06/03 13/03 20/03 27/03 03/04 11/04 18/04 06/03 20/03 03/04 11/04 18/04 03/05 06/03 13/03 20/03 20/03 25/04 29/05 12/06 30/01

09/01 30/01 13/02 27/02 06/03 13/03 20/03 27/03 03/04 11/04 18/04 25/04 20/03 03/04 11/04 18/04 03/05 29/05 13/03 20/03 27/03 27/03 03/05 12/06 19/06 06/02

28/01 30/01 20/02 06/03 20/03 03/04 11/04 18/04 25/04 21/05 29/05 05/06 27/03 11/04 25/04 03/05 13/05 29/05 21/05 29/05 05/06 05/06 12/06 19/06 03/07 17/10

30/10 20/02 06/03 20/03 27/03 11/04 18/04 25/04 03/05 29/05 05/06 12/06 11/04 25/04 03/05 13/05 29/05 19/06 29/05 05/06 12/06 12/06 19/06 03/07 10/07 2410

15 0 15 0 15 0 15 0 15 0 20 0 20 0 20 0 20 0 30 0 30 0 30 0 15 0 15 0 15 0 15 0 15 0 15 0 50 0 50 0 50 20 50 20 30 15 15 0 15 15 + +

VII

DUR

ES

157

EF

LS

LF

TF - FF

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Determinación de las fechas como pronto PERT comienza por determinar, para cada actividad, las fechas como pronto. Efectúa dichos cálculos en una fase llamada "forward computation pass", que, como indica el nombre, toma desde el comienzo hasta el final, la lista de tareas que se le presenta, y procede de la siguiente forma: -

Para las tareas de rango 1, la fecha de comienzo como pronto es la fecha del comienzo del proyecto. Para obtener la fecha de terminación como pronto es suficiente con indicar la duración.

-

Para otras tareas, la fecha de comienzo como pronto es la mas tardía de todas las fechas de finalización de las tareas que la preceden.

En nuestro ejemplo, el curso ADW (I/10) para programadores, puede comenzar como pronto el 11/04, pues sigue al curso MSF (I/9) que termina como pronto el 11/02, y lo mismo ocurre con el curso ADW standard (I/5) que termina el 25/02 y también la conexión con el DPS7 de Modem2 (IV/3) que no se hace hasta el 11/04. La fecha como pronto se obtiene indicando la duración a la fecha de comienzo como pronto.

Determinación de las fechas como tarde Seguidamente, PERT calcula, para cada tarea, las fechas como tarde, en un fase llamada "backward computation pass", que va tomando la lista en orden inverso. De esa forma sabremos cuando emprender una tarea como tarde, sin modificar la fecha de finalización del proyecto. Las fechas como pronto y como tarde nos van a permitir el ordenamiento del proyecto y decidir en qué fecha real se debe comenzar cada actividad.

-

Se parte, pues, de la última etapa (la 13) y se decide que todas las actividades que pueden llegar a ella pueden terminar, como tarde, en la fecha en la que la fase precedente se había ya determinado como fecha de finalización del proyecto.

En nuestro ejemplo, la fecha de fin del proyecto es el 24/10. Las tareas VI/1 (pruebas del sistema), VI/2 (formación de los usuarios) y VI/4 158

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

(procedimientos de operadores - tarea ficticia 23-13 con duración nula) tendrán el 24/10 como fecha de finalización como tarde. Las fechas de comienzo como muy tarde se calculan llevando hacia atrás la duración de la fecha de finalización como tarde.

-

Para otras actividades, la fecha de finalización como tarde es la menor de las fechas de comienzo como tarde, de las tareas que la siguen.

La fecha de finalización como tarde de la instalación de los falsos techos es el 03/05, pues las tareas que la siguen comienzan como tarde, respectivamente, el 03/05 para el cableado del aire acondicionado (VII/16), y el 21/05 para la decoración (VII/10). La fecha de comienzo como tarde se obtiene por sustracción de la duración a la fecha de finalización como tarde.

Márgenes Mientras las fechas nos permiten ordenar el proyecto y trazar el diagrama de Gantt, los márgenes nos van a permitir un planificación mas detallada y una posibilidad de control. También nos van a ayudar en las decisiones a tomar en caso de retrasos o conflictos. En los cálculos precedentes, hemos visto aparecer tareas que tenían las fechas como pronto coincidentes con las fechas como tarde. Estas actividades son las tareas críticas, por no tener ningún margen de seguridad. El conjunto de dichas tareas forman el camino crítico. Las otras tareas tienen márgenes. ¿Cómo se calculan? ¿Cómo se interpretan?

159

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El margen total, que es la holgura máxima de la tarea, se obtiene comparando la duración de la tarea con la diferencia entre la fecha de comienzo como pronto y la fecha de finalización como tarde: TF = ( LF - ES ) - duración En el caso presentado, del 25/04 al 19/06, hay 35 días. Si se sustrae la duración de la tarea VII/23 (5 días), quedan 30 días, que es el margen total. Se puede recalcular la fecha de comienzo de una actividad de duración igual al margen total, sin recalcular la fecha de finalización del proyecto. Pero los márgenes de las tareas siguientes disminuyen y se pueden convertir en tareas críticas. El margen libre se obtiene calculando primeramente el intervalo de tiempo que separa la fecha de comienzo como pronto de la tarea y la fecha de realización como tarde de la etapa de finalización, sustrayéndole la duración: FF = ( (*) - ES ) - duración En este punto hay que prestar mucha atención. No se toma EF de la tarea VII/23, sino el EF mas pequeño hallado para la etapa 42, que es la etapa de finalización de la actividad VII/23.

160

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Dos tareas tienen la etapa 42 como etapa de finalización: VII/18 (puesta en marcha del acondicionamiento de aire) y desde luego la tarea VII/23 (limpieza). Para la actividad VII/18 la etapa 42 tiene la menor fecha de finalización como pronto (ES), el 29/05. Es, pues, dicha fecha la que interviene en los cálculos. En el ejemplo, la diferencia entre el 25/04 y el 29/05 es de 20 días laborables. Si se sustrae la duración de la tarea VII/23 (5 días), se obtiene un margen libre de 15 días. Se puede calcular la fecha de comienzo de una tarea de duración igual al margen libre sin impactar a las tareas siguientes. Ello explica por qué se busca la fecha de realización como pronto de la etapa de finalización (y no de la tarea). Las actividades siguientes no se ven impactadas por no haber cambiado la fecha de la etapa 42. Observaciones: 1) 2)

Las tareas críticas tienen siempre márgenes totales y libres iguales les a cero. Cuando se lleva hacia atrás la fecha de comienzo de una tarea de intervalo de tiempo superior al margen libre (e inferior al margen total), se debe reevaluar la red, pues se puede haber hecho aparecer un nuevo camino crítico.

RECURSOS Hasta el momento, nos hemos limitado a la noción de fecha. De hecho nos hemos circunscrito al dominio del CPM (Critical Path Method). Pero PERT va mas lejos que este método. Puede incluir la noción de recursos en la planificación. Sin embargo puede difícilmente resolver todos los problemas de ordenación, tales como: 1)

Mantener tan constante como sea posible el nivel de los recursos durante el proyecto.

2)

Impedir que varias actividades que necesitan los mismos recursos, se desarrollen simultáneamente. En nuestro ejemplo, la persona que elabora la Base de Datos debe también seguir los cursos. 161

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3)

Ordenar el proyecto en un periodo definido con anterioridad.

Además de la duración, debemos introducir una noción de recursos y de costos. Los costos son inducidos de dos fuentes: los costos fijos y el costo de los recursos. Se establece, pues, una tabla mas completa que la que hemos confeccionado al comienzo de este texto.

ACTIVIDADES

Duración

RECURSOS TIPOS UNIDADES

COSTOS FIJOS

Establecer los objetivos de la BD

5

100

1

Seleccionar datos

5

100,200

1,0,25

25,440 (1

Curso JFA

3

100

2

80,000 (2

100,110, 200,300

2,3, 1,2

Desarrollo (1ª parte)

220,000

(3

A esta tabla se adjunta un lista que recopila los costes.

TIPO 100 200 110 300

DESCRIPCION

COSTE

Analista Soporte del constructor Programador Alquiler de máquina

Interpretamos la línea Desarrollo como sigue: por día, necesitamos 2 analistas (100 - 2), 3 programadores (110 - 3), 1 soporte del constructor (200 - 1) y 2 alquileres de máquina (300 - 2) (los costos se fijan por medio día de conexión). Los gastos fijos provienen, uno de ellos de la compra de pantallas (3) y otro, del alquiler de líneas de teletransmisión (2). El fin de la asignación de recursos es ver cuáles son las necesidades en el curso del proyecto y cuáles son las decisiones a tomar para evitar las puntas, para mantener el nivel de los recursos lo mas constante posible.

162

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

6

LA FUNCIÓN DEL ANALISTA INFORMÁTICO

Antes de elaborar un Método de Análisis debemos responder a una serie de preguntas, la principal de las cuales es saber qué es un análisis. Analizar un problema es, ante todo, percibir la REALIDAD ( lo que ocurre en el mundo exterior ); es estudiar, comprender, para poder seleccionar lo que verdaderamente nos interesa. Comprender lo real no es siempre fácil. Es preciso que validemos lo que hemos percibido. Debemos confrontar nuestra percepción con la de aquellos que viven el problema cotidianamente. Debemos, pues, comunicar nuestro pensamiento. Para ello no bastan las pensamiento, modelizarlo.

palabras. Debemos

sistematizar

nuestro

Un MODELO es una representación de la REALIDAD con vistas a aprehenderla mejor, a estudiarla mejor, a comunicarla mejor. Para visualizar la casa que va a construir, el arquitecto dibuja un plano. Es el modelo de la casa. Dicho plano le permite estudiar más familiarmente todos los aspectos de la organización del hábitat y todas las técnicas de construcción. Pero ese plano, ese modelo, le sirve también para comunicar el fruto de su trabajo, de su pensamiento, a sus clientes.... para llegar a un consenso antes de emprender los trabajos. El analista debe adoptar una visión parecida. Modeliza la realidad percibida para aprehenderla y estudiarla mejor, y para comunicar su pensamiento a los usuarios. Hasta después de la validación de su reflexión, no puede acometer la tarea de la realización. Aquí también podemos establecer un paralelismo con el arquitecto. Como él, el analista no materializa los resultados de su trabajo. Confía esa tarea a otra persona: el programador. Debe, pues, elaborar un informe técnico para el uso de dicho profesional, al igual que lo hace el arquitecto. Arquitecto y analista están enfrentados a dos percepciones diferentes del mismo problema: El aspecto utilización y el aspecto realización; el aspecto cliente y el aspecto proveedor. De ahí surgen la mayoría de las dificultades: Comunicar con palabras la misma realidad, a partir de una percepción diferente. 163

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El oficio de analista es particularmente difícil e ingrato: a) Como describe Tom de Marco en su obra "System Analysis and System Specification", la dificultad de la coreografía proviene del hecho de que no sea codificable, es decir, de que no haya ningún formalismo para describir la danza. El analista se enfrenta al mismo problema. Contrariamente al arquitecto el analista emplea poco formalismo para describir la realidad que percibe. El problema es sin embargo más complejo para el analista que para el coreógrafo, en el sentido de que no existe como tal un lenguaje común entre él y los usuarios. b) Cuando el analista cree haber comprendido el problema, se da cuenta de que éste ya ha evolucionado. La idea de fijar las especificaciones es una mera ficción. Debemos aprender a vivir con el cambio, aprender a gestionar el cambio, pues éste es inevitable. No solo es que el problema evolucione debido a la presión del mundo exterior, sino que también, a consecuencia del diálogo con el analista, el usuario va modificando la percepción que tiene del mismo, mejorando su comprensión. El punto álgido se alcanzará cuando el usuario vea la materialización de su sistema. Pensará entonces en "todo lo que habría podido pedir" y el amargo ciclo del mantenimiento "evolutivo" se disparará. c) En su enorme trabajo de concepción, el analista se sirve poco de herramientas. Hasta hace poco (informatización de la Informática), la automatización de la productividad informática no era acometible. No tanto por su dificultad de realización, sino por la oposición estricta de los informáticos que afirmaban en su mayoría: "Mi trabajo es tan particular que no corresponde a ninguna norma, por lo tanto es absurdo querer automatizarlo". Esta reticencia al progreso era la causa de la mala calidad de los análisis. Cómo gestionar el cambio, cómo comunicar fácilmente si como toda herramienta solo se dispone del lápiz y del papel. d) El Analista terminó por despreciar la comunicación escrita, tan difícil de mantener. En efecto, la mayoría de los "Análisis", de los "Cuadernos de Especificaciones" no eran nada más que un amasijo de documentos dispares, poco explotables por su número y su estilo. Todavía hoy, para la

164

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

mayoría de los analistas, un cuaderno bien hecho debe ser un cuaderno voluminoso. e) Finalmente, un último escollo para el analista reside en la ausencia de política coherente en el desarrollo de las aplicaciones. A menudo se abandona un proyecto en curso de realización, para hacer frente a una nueva estrategia u orientación. Tal situación desmotiva a los ejecutores que acaban por aceptarla con resignación y algo de ironía. De la situación que acabamos de esbozar podemos deducir como habrán de ser las grandes líneas de nuestro método.

6.1

EL ANALISIS EN SU ENTORNO

El Análisis informático del que hablábamos antes no es un fin por si mismo, evidentemente, pero tampoco el comienzo de un proceso de informatización de un problema. El Análisis debe inscribirse en un contexto más general: El de la Informatización de la Empresa. Centrados en este contexto, el Análisis es el eslabón de una cadena; un momento particular en la estrategia de la Empresa. El marco más general en el cual se inscribe el análisis, es el Plan de Sistemas del Sistema de Información de la Empresa. Para los analistas tiene una importancia capital porque: a) Garantiza la política informática. Cada aplicación tiene un papel estratégico que desempeñar, ya que una aplicación empezada no se abandonar en curso de realización. b) Permite tener una visión general sobre el conjunto de informaciones de la Empresa, o sea, un desarrollo coherente de todas las aplicaciones y su integración. Este enfoque global es sistemático. La Empresa se ve como un todo coherente, con un nivel superior al de la suma de las partes que la componen. Si lo comparamos con el cuerpo humano, cada uno de sus componentes tomados por separado, tienen poco valor en comparación con la totalidad. Sin embargo, un problema en uno de sus componentes puede comprometer la eficacia del todo. La Empresa tiene un comportamiento similar al del ser humano. Todos sus componentes deben funcionar armoniosamente para alcanzar una 165

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

rentabilidad máxima. Es preciso estudiar el TODO antes de estudiar cada una de las partes. Este es el objetivo del Plan de Sistemas del Sistema de Información. Uno de los documentos producidos por el Plan de Sistemas es la subdivisión de la Empresa en Dominios a Informatizar. Cada Dominio está definido en términos de objetivos ( no solamente lo que es preciso hacer, sino POR QUE hay que hacerlo ). El conocimiento de los OBJETIVOS de cada Dominio y, por lo tanto, de cada Proyecto, nos abre nuevos horizontes. Ya no se analizará un proceso para informatizarlo, sino para mejorar la calidad, para aumentar el poder de acción del Gerente sobre el sistema. La informática participa naturalmente en el mecanismo de mejora de la calidad emprendido por numerosas compañías. La voluntad de hacer las cosas mejor nos llevará en el futuro a informatizar, no importa qué, entre ello los errores de gestión o aberraciones organizativas. Inevitablemente la introducción de técnicas informáticas en una Empresa debe desembocar en una revisión de la organización y de los métodos de trabajo de la misma. Como la dirección está comprometida con una estrategia informática por su Plan de Sistemas, ve con buenos ojos el recuperar el poder de actuación que se le había escapado. Dicho poder de actuación está relacionado también con los controles de tiempos y costes. Nadie construiría una casa sin conocer de antemano el coste y la duración de la obra. Debemos cambiar nuestros hábitos y optar por trabajar por etapas que nos permitan gestionar mejor nuestro proyecto. Según el Plan de Sistemas, una vez decidida la informatización de nuestro Dominio, vamos a estudiarla en tres etapas como lo haría un arquitecto: 1) Estudio Previo : Estudiamos "a grandes rasgos" el Dominio en su totalidad ( un Dominio es, por ejemplo, las Ventas, las Compras, etc..). Este estudio tiene como objeto saber hacia dónde se va antes de ir más lejos. Por consiguiente estudiaremos el presupuesto, las técnicas especiales que vamos a necesitar. Al final del estudio decidiremos si realizamos o no el proyecto, cual ser su presupuesto, su duración, su objetivo real, las restricciones a respetar y los medios que vamos a poner en funcionamiento. 166

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

2) Estudio Detallado : Nos concentramos en una Aplicación en particular, en una parte del Dominio ( por ejemplo, la Facturación o la Expedición ) y vamos a realizar un estudio a fondo. Es lo que hace el arquitecto cuando, abandonando los alrededores de la casa ( el jardín, por ejemplo ), se concentra en el plano de la misma, el que va a utilizar el contratista de obra y que estar a disposición del cliente. Esta es la fase activa del estudio y de la concepción, centrada en el usuario, que es nuestro interlocutor privilegiado. 3) Estudio Técnico : Cuando estemos de acuerdo sobre las grandes líneas del proyecto, el analista efectuará el estudio técnico, que se dirige a los especialistas informáticos, indicándoles, en su léxico habitual, lo que hay que hacer y, a veces, como hacerlo. En este estudio el analista puede ( como el arquitecto cuando se dirige a los especialistas en calefacción ) llamar a expertos en redes, PCs, bases de datos, etc... 4) Realización: La materialización del proyecto interesa menos al analista. Ocurre igual en la construcción: los albañiles trabajan directamente a partir del plano, sin apelar continuamente al arquitecto. Es preciso llegar a una situación similar en informática.

6.2

BASES MÉTODOLOGICAS DEL ANÁLISIS

A) SEPARAR LOS DATOS Y LOS TRATAMIENTOS En el mundo real que vamos a estudiar, vamos a encontrar elementos ESTABLES y elementos INESTABLES, sujetos al cambio y que pueden ser contradictorios. Vamos pues a separar lo estable de lo inestable, como hacía el alquimista. Para el analista, lo estable reside principalmente en el Sistema de Información de la Empresa, en la Información, en la Memoria Colectiva de nuestro sistema. Lo inestable reside en los tratamientos, las manipulaciones que se aplican a nuestra Memoria Colectiva. No se trata solo de que estos tratamientos puedan cambiar si cambia la organización de la Empresa ( nueva Dirección ), sino que además pueden ser contradictorios.

167

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El cliente X puede ser considerado como un buen cliente por el servicio de Ventas y como no rentable por el servicio Financiero. Solo los datos de dicho cliente son coherentes en este caso. Vamos pues a estudiar separadamente los datos y los tratamientos, intentando constituir una Memoria Colectiva de nuestro sistema que sea estable, completa y coherente. B) FRAGMENTAR LA DIFICULTAD Cuantos más datos tenga un problema, más complejo es. El matemático y filósofo Blaise Pascal dijo que para resolver un problema es preciso fragmentarlo y resolver por separado los diferentes subproblemas. También nosotros vamos a adoptar esta técnica. En el estudio de un problema matemático no nos lanzamos directamente a la escritura de fórmulas o a la aplicación de técnicas particulares para llegar a obtener una solución, sino que procedemos con método: 1) Tratamos de comprender la esencia del problema. ¿ Qué debemos hacer ?. 2) Seguidamente descomponemos en diversas partes la solución. 3) Solamente después, utilizaremos técnicas particulares para llegar al final de los diferentes subproblemas que hemos detectado. Vamos a analizar nuestro problema de forma idéntica : 1) Trataremos de ver lo que debemos hacer y por qué lo hacemos ( trabajo por objetivos ). Este nivel de reflexión se denomina nivel CONCEPTUAL. 2) Cuando tenemos una visión clara de la esencia de nuestro problema, podremos estudiar quién va a hacer qué, dónde lo va a hacer ( en el equipo central , en los departamentos, etc ) y cuándo lo va a hacer ( después de que se ha producido la necesidad, o después de haber acumulado un cierto número de demandas ). Dicho nivel de estudio se denomina ORGANIZATIVO o LOGICO. 3) Finalmente nos ocuparemos de la forma de realizar el trabajo, es decir, de los aspectos técnicos. Este ser el nivel OPERATIVO o FISICO. Todo ello constituye el CICLO DE ABSTRACCION del proyecto.

168

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta subdivisión por niveles se superpone a un enfoque descendente del problema, a una partición de la dificultad; no partiremos de los detalles sino del aspecto general, para descender a lo particular. No adoptamos una aproximación lineal, sino cíclica y regresiva : primero la Empresa, en la que realizaremos un Plan de Sistemas; luego un Dominio, en el que realizaremos un Estudio Previo; finalmente una Aplicación, para la cual haremos un Estudio Detallado y un Estudio Técnico. Vamos a comenzar el estudio por lo general y luego vamos a ir al detalle, es decir, la esencia del problema, su organización y su solución técnica. Todo ello constituye el CICLO DE VIDA del proyecto. Podemos fusionar ambos enfoques como sigue:

C) COMUNICAR Uno de los aspectos más complejos del Análisis es el de la comunicación. No solamente el analista debe comunicarse con diferentes interlocutores ( la dirección, los usuarios, los especialistas en informática, etc ), sino que además , cada uno emplea su propio léxico. Y por si fuera poco, esta comunicación no está formalizada, estructurada, lo que nos pone ante volúmenes inverosímiles de documentos poco explotados. Nuestro Método insiste mucho en la comunicación, ya sea verbal o escrita. Se basa en los principios siguientes: 169

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1) Formalizar el lenguaje para evitar malos entendidos. El sistema estar dotado de un Diccionario donde se encontraran definidos todos los términos utilizados. 2) La comunicación se hará con la ayuda de modelos formalizados. Tendremos tantos modelos como niveles de abstracción y elementos en nuestra percepción de la realidad, es decir, 6 modelos - El Modelo Conceptual de Tratamientos ( MCT ) que mostrar la esencia. - El Modelo Organizativo de Tratamientos ( MOT ) que indicar quién hace qué, cuándo y dónde. - El Modelo Operativo de Tratamientos ( MOpT ) que es el compendio de procedimientos, el cómo hacer las cosas. - El Modelo Conceptual de Datos ( MCD ), verdadera red semántica de los datos que constituyen nuestra Memoria Colectiva. - El Modelo Lógico, u organizativo, de Datos ( MLD ), que ser una cartografía de los accesos necesarios para localizar los datos. - El Modelo Físico de Datos ( MFD ), que es el reflejo de la implantación de nuestra Memoria Colectiva en una máquina dada. La mayoría de estos modelos, herramientas de comunicación y de reflexión, serán gráficos; un pequeño esquema vale más que un gran discurso. 3) Simplificaremos minuciosamente los informes para que sean claros, atractivos, útiles y manejables, para permitir incorporar los futuros cambios. 4) Siempre desde esta óptica de posibilidad de llevar a efecto cambios, implicaremos al máximo a los usuarios, con el fin de familiarizarles con el nuevo sistema y obligarles a reflexionar, antes de que sea demasiado tarde. Cuando el cliente del arquitecto no comprende el plano en dos dimensiones, el arquitecto le proporciona un modelo más elaborado, más costoso, más fácil de comprender: una maqueta. En informática, procedemos de la misma forma: fabricaremos un "prototipo" para todo componente no percibido claramente por el usuario. El prototipo puede servir: 170

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Para aclarar el problema, para explicarlo mejor. Es el prototipo exploratorio, que es costoso y será manipulado con cuidado. - Para hacer un esbozo de solución. Es el prototipo evolutivo, pues podrá servir de base a la realización. Se hacen prototipos, sobre todo, de los aspectos ergonómicos, de los encadenamientos de pantallas, y de la disposición de las informaciones sobre las mismas. - Para hacer validar la solución. Es el prototipo de validación. El usuario ve transformarse los flujos de información. El pedido se transforma en factura ante sus ojos. Realizado sin herramienta específica, esta clase de prototipo es muy costoso y puede no ser reflejo del análisis. - Para hacerle apreciar las prestaciones del sistema. Es el prototipo experimental. La necesidad de comunicar y validar los diversos modelos planteados en las diferentes etapas hace aparecer un tercer ciclo que se superpone en el tiempo a los dos anteriormente mencionados: el CICLO DE DECISION.

171

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

7

MODELIZACION DE DATOS

7.1 MODELO CONCEPTUAL DE DATOS ( DIAGRAMA ENTIDADRELACION ) Como hemos dicho en la introducción, la modelización, ya sea de datos o de tratamientos, tiene como objetivo principal la comunicación entre los diferentes actores del análisis: El usuario y el analista por un lado, el programador y el analista por otro. En el caso concreto de la modelización de datos por medio de un modelo entidad-relación, vamos a tratar de representar el contenido de la memoria colectiva del sistema sin hacer ninguna hipótesis sobre la "utilización" de la misma. Nuestro único criterio de elección en la elaboración de este modelo, ser el interés para el sistema, para el organismo que estudiamos. No tenemos la pretensión de modelizar el Universo. Debemos limitarnos en la modelización. Este modelo sería entonces la imagen estable de la memoria colectiva del Sistema. La imagen invariante por comparación a la utilización que se efectuará, es el modelo "semántico" de datos, o nivel "conceptual" de la modelización de los datos. La elección del modelo entidad-relación, definido por Peter Pin Shan CHEN, para representar el nivel conceptual de los datos, se explica por el hecho de que es totalmente independiente de toda implantación del modelo en un sistema informático, y que permite representar todas las formas posibles de relaciones entre los datos, lo que no es permisible por un modelo tal como el de Bachman. La ventaja de la modelización es la de poder representar el mundo real de la forma más simple y más formal. Vamos a estudiar aquí los conceptos y el formalismo del modelo entidadrelación. A) Enfoque intuitivo Tomemos un conjunto de datos elementales: Nombre del cliente Dirección del cliente Dirección del proveedor Nombre del proveedor Número del producto 172

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Precio de compra del producto Nombre del producto Cantidad pedida del producto En esta lista nos fijamos en que algunos datos no son independientes. Se les puede reagrupar en torno a un tema común. De esta forma podemos reagrupar todo lo que se refiere a : - Un cliente Su nombre y su dirección - Un proveedor Su nombre y su dirección - Un producto Su número y su nombre En esta clasificación o reagrupamiento, dos campos presentan ciertas dificultades: La cantidad pedida y el precio de compra. No dependen de una clase única. Se encuentran mezcladas en dos grupos. El precio de compra depende del proveedor y del producto. El mismo producto puede ser vendido a precios diferentes por diferentes proveedores. La cantidad pedida depende del cliente y del producto. Un mismo producto puede ser pedido en cantidades diferentes por clientes diferentes. Este enfoque intuitivo nos permite ver que hay dos clases de objetos en nuestro sistema u organización: Los que tienen existencia propia, que existen por sí solos, y los que viven dependiendo de otros, o sea, que necesitan de otros para poder ser definidos. B) Definiciones Denominamos ENTIDADES a objetos, localizaciones, conceptos, terceros; provistos de existencia propia, identificables en el sistema estudiado y con un determinado interés para el mismo. Por identificable entendemos que uno de los atributos o propiedades de la entidad, permite distinguirla en el Sistema estudiado.

173

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Así, en la clase estudiada, que es nuestro Sistema, cada alumno es identificado por su NOMBRE. Dicho identificativo es insuficiente si extendemos nuestro referencial a la población de un país. En este caso el identificador sería el número del DNI o del Pasaporte. Llamamos RELACIONES a las asociaciones entre las ENTIDADES, las cuales están desprovistas de existencia propia, y no son identificables individualmente en el sistema que se está estudiando. Las RELACIONES desaparecen cuando las ENTIDADES de las que dependen desaparecen. Por ejemplo, el precio de compra solo tiene sentido si hay proveedor que pueda servir el producto. El precio de compra no tiene existencia propia. No podemos identificarlo sin hacer referencia al proveedor Y al producto. En la exposición precedente, nos hemos referido anticipadamente a un término no definido, lo cual constituye un error en el análisis: Hemos hablado de ATRIBUTO. Tanto si el contexto permite comprender o no el sentido, debemos definir este término. Llamamos ATRIBUTO a todo dato elemental que sirve para describir y caracterizar una ENTIDAD o una RELACION. Hemos partido de atributos para introducir intuitivamente las nociones de las que hemos hablado anteriormente. De esa forma, en la ENTIDAD proveedor, el nombre y la dirección del proveedor son dos ATRIBUTOS. Igualmente en la RELACION catálogo (que conecta el proveedor y el producto), el precio de compra es un ATRIBUTO. C) Formalismo La ENTIDAD está caracterizada por un NOMBRE, que junto a la lista de atributos, se representa en el interior de un rectángulo.

Un atributo no puede pertenecer más que a una y solo una ENTIDAD; si no, debe figurar en una relación. Es preciso descartar de la lista inicial de los atributos todas las polisemias (atributos que teniendo el mismo nombre, designan realidades diferentes). 174

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Es preciso tener cuidado de que cada atributo sea suficientemente preciso. Es el caso del atributo DIRECCION. Debemos por tanto especificar que se trata de la dirección del proveedor o de la dirección del cliente. Una RELACION se caracteriza por un NOMBRE, una lista eventual de atributos, y es representada por un óvalo o un hexágono.

Debemos llamar la atención sobre tres puntos: - la dificultad de dar un nombre a una RELACION. Si en el texto que precede es evidente nombrar como Catálogo la lista de los productos que puede servir un proveedor, lista en la cual encontramos el precio de cada artículo, está lejos de ser tan evidente en la mayoría de los casos. En la práctica, es a menudo más sencillo designar a las RELACIONES por un verbo y su complemento. Esta forma de hacer es teóricamente correcta, ya que una RELACION es un "predicado" que enlaza Entidades; predicado que puede ser cierto o no. Así, nuestra Relación Catálogo, podría haberse llamado "suministrar", pues un proveedor puede o no suministrar ciertos productos. Además, podemos enunciar: un proveedor SUMINISTA un producto, y un producto ES SUMINISTRADO por un proveedor. Con ello enunciamos correctamente un predicado y su recíproco. La otra RELACION puede tomar el nombre de "Pedir un producto" pues: un cliente PIDE un producto, y un producto ES PEDIDO por un cliente. - Contrariamente a las ENTIDADES, que deben llevar consigo al menos un ATRIBUTO, una RELACION puede ser vacía. Al no tener existencia propia, es caracterizada por las entidades con las que se une. 175

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Así, las relaciones: SER PROPIETARIO, que conecta una persona y un vehículo, y SER PADRE DE, que enlaza a un padre con sus hijos, no tienen atributos. - Las relaciones vacías, que solo se refieren a dos entidades, pueden omitirse en el esquema para facilitar su lectura. El óvalo desaparece y la relación es materializada por un trazo, por la unión que crea entre las ENTIDADES a las que se conecta. El ejemplo visto anteriormente puede ser formalizado como sigue:

D) Otras definiciones: OCURRENCIA e IDENTIFICADOR a) Ocurrencia de un atributo Un atributo puede tomar un cierto número de valores. Llamaremos OCURRENCIAS del atributo al conjunto de los valores que el mismo puede tomar. Por ejemplo, el atributo "Regiones españolas" puede tomar los valores : Andalucía, Aragón, Asturias, etc., que son ocurrencias del atributo regiones. Un atributo puede tomar "n" valores diferentes. Dicho valor se conoce como la cardinalidad del conjunto. b) Ocurrencia de una entidad Por extensión, llamaremos OCURRENCIA de una entidad cada caso particular de dicha entidad, es decir, el conjunto de grupos formados por n ocurrencias de los atributos, que tenga sentido.

176

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En nuestro ejemplo del comienzo, una ocurrencia de la entidad CLIENTE sería : ( LOPEZ S.A, calle Nueva ) El número total de ocurrencias de una entidad es su cardinalidad. Si el conjunto de clientes de una empresa es 1.500, la cardinalidad de la entidad es 1.500. Hagamos algunas observaciones sobre esta noción de ocurrencia en una entidad : 1) Es importante asegurarse que TODOS los atributos de una entidad tienen sentido para TODAS las ocurrencias de la entidad. Así pues, en una entidad Personal, podríamos tener (entre otros) los siguientes atributos : Nombre de la persona Apellidos de la persona Edad Sexo etc. Esta regla es un caso particular de la primera forma normal. 2) Cada ocurrencia de una entidad debe poder ser plenamente identificada. Esta propiedad se deriva de la propia definición de entidad. Para cada ocurrencia debemos encontrar una ocurrencia de uno o varios atributos, que sea absolutamente UNICA. Este atributo ( o grupo de atributos ) se conoce como IDENTIFICADOR. El hecho de que la entidad tenga existencia propia, asegura encontrar siempre un atributo de este tipo. Si ese no es el caso, es preciso crear artificialmente ( atribuyéndole un número de cliente, por ejemplo ) o es preciso renunciar a esa entidad, que de hecho no lo es. El corolario de la introducción de la noción de IDENTIFICADOR, es que no es preciso enunciar todos los atributos de un ocurrencia de una entidad, para definirla. Basta con citar el valor de su IDENTIFICADOR. c) Ocurrencia de una relación Como la relación, por definición, no tiene existencia propia, una ocurrencia de una relación no puede ser completamente definida nada m s que con respecto a las ocurrencias de las entidades que une. Así pues, una ocurrencia de la relación CATALOGO podría ser : ( Almacenes GARCIA, Grabadora Vídeo PANASONIC G38, 400 Euros.) 177

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Una ocurrencia de una relación queda definida: -

Por el identificador de cada ocurrencia de las entidades que enlaza. Esta simplificación proviene del hecho antes enunciado de que un identificador de una entidad, es suficiente para definir completamente una ocurrencia de la misma - . Podemos decir también que una ocurrencia de una relación es definida por "una y solo una" ocurrencia de cada entidad con la que se une. Esta proposición es primordial para la comprensión del modelo, y hablaremos de ello en un próximo capítulo. - Por la ocurrencia de los atributos de la relación, correspondiente a las ocurrencias de las entidades conectadas. De la definición que precede podemos deducir ya, para la relación Catálogo que hemos descrito anteriormente: 1) Que para un proveedor dado, un producto solo puede tener un y solo un precio. En caso contrario una nueva entidad debería precisar las condiciones de elección del precio ( una fecha de validez, por ejemplo ), pues es esencial que una ocurrencia de una asociación, sea única y completamente definida por la concatenación de los identificadores de las entidades que une. 2) Ciertos productos pueden no estar en el Catálogo de todos los proveedores. 3) Ciertos productos pueden no encontrarse ya en el Catálogo de proveedores. En este caso, no se pueden servir. 4) Finalmente, puede ser que un proveedor no está‚ aún asociado a un producto o que no está‚ ya en disposición de servir productos que interesen a nuestra compañía. Estos tres últimos casos no están actualmente contemplados en nuestro modelo conceptual. Por lo tanto éste no es completo. Precisamos aún introducir otras nociones, como las conectividades mínimas y máximas.

178

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

SINTESIS 1) ENTIDAD : Todo objeto, tercero, ubicación, concepto, provisto de existencia propia e identificable en el referencial elegido. Toda entidad tiene al menos un atributo: su identificador. 2) RELACION : Asociación, desprovista de existencia propia, entre dos entidades. Una relación puede estar vacía, sin atributos. Es identificable por la concatenación de los identificadores de las entidades que une. 3) ATRIBUTO : Dato elemental que sirve para describir una entidad o una relación. Un atributo solo puede pertenecer a una entidad o a una relación. 4) IDENTIFICADOR : Atributo(s) que tiene(n) valor diferente para cada ocurrencia de una entidad dada.

E) CONECTIVIDADES Hemos visto, en el apartado precedente, que el modelo que vamos a construir actualmente es incompleto, pues permite interpretaciones diferentes. Por ello, lo vamos a enriquecer. Para hacerlo debemos introducir una noción suplementaria, la de CONECTIVIDAD de una entidad. La CONECTIVIDAD mide el grado de participación de la entidad en la relación. Por definición, la CONECTIVIDAD indica, para cada par ENTIDADRELACION, el número mínimo y número máximo de ocurrencias de la relación, que pueden existir para una ocurrencia de la ENTIDAD. Este concepto puede comprenderse más fácilmente si se estudia una relación entre dos entidades (Relación de grado 2 o relación binaria).

179

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Tomemos un ejemplo simple : la relación propietario-vehículo, que formalizamos como sigue :

Imaginemos cuantas veces el Señor X (que es una ocurrencia de la entidad PROPIETARIO) puede aparecer en la relación. Para ello estudiaremos los pares (propietario, vehículo). El Señor X, modesto empleado, solo tiene un vehículo. Solo lo encontramos en un par único : ( Señor X, 2CV, No. chasis XYZ1234 ) La participación del Señor X en la relación SER PROPIETARIO DE UN VEHICULO es, pues, 1. Estudiaremos el caso del Señor Y, que es propietario de una sociedad de taxis, que posee una flota de 12 vehículos. Aparecerá , pues, en 12 pares ( propietario-vehículo ). Podemos deducir de ello que la participación mínima de PROPIETARIOS en la relación, es de 1 (excluimos las personas que no poseen coche, ya que solamente nos interesan los propietarios de los vehículos ), y la participación máxima es 12. La conectividad de la entidad PROPIETARIOS es, pues, (1 ,12). En la práctica, no es útil conocer exactamente el número máximo de participación. Diremos "mucho" en lugar de 12, y diremos entonces que la conectividad de la entidad es de 1 a n, lo cual anotaremos como (1 , n). Hemos hecho la mitad del trabajo. Debemos ahora estudiar el caso del vehículo OPEL ASTRA, chasis ABC9876. Sea dicho vehículo propiedad del Señor Z. En ese caso, su participación en la relación es de 1, o bien puede ocurrir, que el vehículo está aún en el escaparate del concesionario, es decir, que aún no tiene propietario (en el sentido que entendemos en nuestro Sistema). 180

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La conectividad para la entidad VEHICULOS es entonces : 0 a 1, que anotamos como ( 0 , 1 ). Deducimos de ello que no es posible que un vehículo pueda tener varios propietarios. Igualmente, de la conectividad precedente ( 1 , n ), deducimos que si un propietario vende su vehículo y no adquiere otro, deja de interesarnos, desaparece de nuestro referencial, de nuestro Sistema. Completamos nuestro modelo entidades-relaciones, como sigue :

En lugar de un enfoque intuitivo, habríamos podido utilizar un enfoque más riguroso, un enfoque matemático, un enfoque conjuntista. En efecto, podemos representar nuestro modelo, como la relación entre dos conjuntos ( el identificador de la relación es, de hecho, el producto cartesiano de los identificadores de entidades ).

En ese caso debemos estudiar el tipo de relaciones que une a los dos conjuntos. Estas relaciones pueden ser : 1) Una INYECCION, si a un elemento del conjunto corresponde, como mucho, un elemento de otro. Es una conectividad del tipo ( 0 , 1 ). 2) Una BIYECCION, si a un elemento de un conjunto corresponde, siempre, un y solo un elemento del otro conjunto. Tenemos una conectividad ( 1 , 1 ). 3) Una SOBREYECCION, si a un elemento de un conjunto corresponde, al menos, un elemento del otro conjunto. Tenemos una conectividad ( 1 , n ). 181

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Estas tres relaciones son aplicables en el sentido matemático del término : toda ocurrencia en la entidad A tiene exactamente 1 imagen en la entidad B. 4) Finalmente, tenemos una relación de tipo general, si a un elemento de un conjunto corresponde un número cualquiera de elementos del otro conjunto. Tenemos una conectividad ( 0 , n ). Hemos contemplado todos los casos que nos interesan en la modelización de los datos de un Sistema. En la teoría de conjuntos, la relación es el GRAFO de la relación ( A, B, G ) :

( a y b ) son ocurrencias de las entidades g es ocurrencia de la relación a es la imagen de b

Esta representación matemática (grafo cartesiano) nos permite comprender mejor que la relación no tiene existencia propia, ya que es el grafo de la intersección de las ocurrencias de las entidades. Las conectividades no se inventan. Deben reflejar la situación real del referencial estudiado. Importa basarse en las reglas de gestión de la Organización y no tratar, en absoluto, de deducirlas. Las Conectividades se anotan en las líneas que unen las entidades y las relaciones. Según los casos se anotará : (0,1), (1,1), (0,n), (1,n). Se puede utilizar otro formalismo. Simboliza las participaciones como sigue : 182

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

0 es representado por un cero : 0 1 es representado por una barra vertical : l n es representado por una desigualdad : < ,o bien > Este formalismo es m s general, Puede emplearse en el modelo lógico de datos para representar las clases funcionales de los caminos de acceso, así como en el modelo organizativo de tratamientos para definir dependencias.

se puede representar como sigue:

Pero también se puede formalizar el tratamiento de un pedido como sigue:

Este encadenamiento nos indica que el pedido se refiere a un solo cliente, que puede pedir diversos productos. La valoración del Pedido solo tiene lugar una vez, al final del tratamiento de todas las líneas del pedido. F) RESTRICCIONES DE INTEGRIDAD FUNCIONAL En el modelo que vamos a concebir, vamos a encontrar relaciones entre dos entidades, pero también relaciones que unen a m s de dos entidades. Estas últimas introducen , a menudo, una complejidad de representación que no está siempre justificada por la realidad. Por temor de omitir algo, el diseñador incluye en la relación las entidades que solo participan de la relación de manera indirecta, únicamente porque esas entidades dependen de otra entidad que están , necesariamente, en la relación. Entonces, por definición, una RESTRICCION DE INTEGRIDAD FUNCIONAL entre varias entidades, unidas en la misma relación, explica que una de las entidades sea totalmente identificada por conocimiento de otras.

183

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El interés de profundizar en tales dependencias es que su detección entraña, a menudo, una simplificación del modelo. Estudiemos el caso siguiente :

En la hipótesis (verificable gracias a las reglas de gestión de la Organización) de que un pedido no pueda ser realizado más que por un y solo un cliente (el pedido solo tiene una imagen en el conjunto de clientes), podemos deducir el cliente, cuando se conoce el pedido. O sea, la entidad cliente no tiene ninguna razón para participar en la relación "PEDIR". Podemos, entonces, simplificar el modelo como sigue :

Acabamos de transformar una relación ternaria (de 3 participantes) en dos asociaciones binarias (de 2 participantes), lo que significa la comprensión actual del esquema y lo que simplificar la transformación del modelo, al pasar del nivel conceptual a un nivel más bajo, más próximo de la implantación en la máquina.

184

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta simplificación se hace siempre por la creación de una relación binaria, no portadora de atributos ( o sea, vacía), y que tenga conectividades del tipo ( 1,1 - 0,n ) o ( 1,1 -1,n), que es un caso particular del precedente. La notación (1,1) significa que la ocurrencia PEDIDO solo tiene una imagen en el conjunto CLIENTE. Estos pasos seguidos son un caso particular de la segunda forma normal aplicada a las relaciones. La regla se puede enunciar de la forma siguiente : "Los atributos de una relación no dependen nada más que de los identificadores de las entidades a las que une" En nuestro caso, la cantidad pedida queda perfectamente definida por el pedido y por el producto. El conocimiento del cliente no aporta precisión adicional.

G) PROPIEDADES DEL MODELO ENTIDAD-RELACION 1) Si en una relación no vacía (portadora de atributos) tenemos una conectividad (1,1), se puede deducir que los atributos de la relación son, de hecho, atributos de la entidad, pues para toda ocurrencia de la relación, solo corresponde una y solo una ocurrencia (imagen) de la entidad.

2) Un atributo solo puede pertenecer a una entidad o relación. 185

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) Para cada ocurrencia de la relación, solo puede existir una sola ocurrencia de cada entidad. Así pues, en el ejemplo siguiente :

No podremos encontrar las relaciones siguientes : Grabadora Vídeo SONY VHS ------ 10 -------- Almacenes López Compact-Disk JVC M20 -------Sino: Grabadora Vídeo SONY VHS10 Compact-Disk JVC M20 10

10

Almacenes López Almacenes López

Esta forma de ver las cosas, proviene de la propia definición de la identificación de una ocurrencia de la relación. 4) Para cada grupo formado por una ocurrencia de cada una de las entidades que participan en una relación, solo puede existir una sola ocurrencia de la relación. Así pues, para la misma relación del punto 3, no podemos tener: Grabadora Vídeo AKAI AM-M12 Grabadora Vídeo AKAI AM-M12

12 Almacenes García 8 Almacenes García

Si se produjera esta circunstancia, es que falta una entidad en la relación para identificar completamente cada ocurrencia. Esta entidad sería, por ejemplo, la fecha del pedido. 186

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5) Una rama de la relación no puede ser opcional. Para una ocurrencia de una relación definida por n entidades, DEBE existir una ocurrencia de cada entidad. Tomemos el ejemplo de un producto cuyo stock es mantenido por un almacén con mención de la fecha de envío. Expresemos el correspondiente esquema:

No se puede encontrar una ocurrencia de este tipo : Sodio 10/11/88 Potasio 10/11/88

Almacén de Vigo ?

10T

Esta situación indicaría que el potasio enviado el 10/11/87, no ha sido almacenado, sino que ha sido consumido en el momento de su llegada. Esta propiedad emana de la definición de relación que es el grafo de la relación entre las entidades. Un elemento del grafo solo está definido por los elementos de los conjuntos que une. La situación descrita es mucho m s compleja de modelizar, y necesita la separación de dos acciones SERVIR y ALMACENAR. De lo contrario, la representación de la realidad es parcial o falsa. Nuestro modelo se convierte en :

187

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

6) Si un atributo de una entidad depende, parcialmente del identificador de esa entidad, y parcialmente del identificador de otra entidad, debe estar situado en una relación que una las dos entidades. Es el caso del precio de compra de un producto, que depende, no solamente del producto, sino también del proveedor que lo envía.

H) OPERATIVA. CÓMO CONSTRUIR EL MODELO a) Por donde comenzar No sorprenderemos a nadie diciendo que la fase de arranque es , con mucho, la más difícil. Tanto es así, que después de haber dado este primer paso, todo se presenta más fácil, pues está codificado y formalizado, bastando para ello seguir correctamente las reglas. El principio de base de la modelización de los datos, es el no comenzar con demasiadas entidades, sino por un conjunto pequeño de ellas. La modelización de los datos no es el primer paso del Análisis; ya disponemos de: 1) El objetivo del análisis que se nos ha pedido realizar. Este objetivo es primordial para la modelización, pues comprende ya las grandes entidades que habremos de gestionar. Por lo tanto, no se contenta con objetivos vagos, sino que ha de precisar el POR QUÉ de su estudio. Así pues, el objetivo de una gestión de STOCKS, podría ser :

188

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Reestudiar la gestión de stocks para disminuir los desechos debidos a una mala utilización de fechas de caducidad, de lotes servidos a nuestros diversos almacenes. Este objetivo ya permite deducir que, además de los productos y los proveedores, debemos tener en cuenta las fechas de caducidad y los envíos a los almacenes. 2) La primera fase del análisis es el estudio de lo existente. Por ello, tendremos a nuestra disposición un DICCIONARIO DE DATOS, que comprende la lista en bruto de todos los datos utilizados en la empresa. Este diccionario se constituye al comienzo de los ficheros informáticos existentes (si la Aplicación ya está informatizada), o al comienzo de los documentos internos y externos (Factura, Orden de Pedido, Inventario, etc.). 3) En caso de que el dominio a estudiar sea completamente nuevo en la Empresa, queda documentar lo externo, o si ello es imposible (nuevo mercado o situación de competencia), estudiar el sistema en términos absolutos, como una bolsa de intercambio de objetos entre terceros. Identificar los terceros con los que intercambiar objetos portadores de cambios y, finalmente, identificar los intercambios. Los terceros pueden ser internos o externos a la Empresa.

Las transacciones se clasifican en cuatro categorías: a) La iniciación de la transacción o pedido b) La realización de la transacción o entrega c) La valoración de la transacción o facturación d) La compensación de la transacción o pago Los términos referentes a la distribución (pedido, entrega, etc.) solo figuran a modo de ejemplo; la noción de transacción puede aplicarse a todas las disciplinas. En la transacción, el que juega el papel de cliente inicia y compensa (pide y paga), el que juega el papel de proveedor (de bienes o servicios), realiza y valora (entrega y factura). De ello se deduce que las entidades útiles al organismo, responden a las cuestiones: QUIÉN hace transacciones y CÓMO.

189

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Existirán asociaciones entre los diferentes grupos (Agente, transacción y objeto), pero también en el interior de un mismo grupo, entre agentes. b) Depuración del diccionario Tenemos que empezar por depurar el diccionario de datos que hemos constituido (a partir de lo existente). En esta lista, en bruto, podemos encontrarnos con tres tipos de anomalías: a) Redundancias: Un mismo atributo (a veces bajo nombres distintos) aparece en diferentes soportes, en varios documentos o en distintos ficheros (si se parte de algo ya informatizado). b) Sinónimos: entre los atributos que quedan, nos podemos encontrar con sinónimos o atributos que, teniendo nombres distintos, designan la misma realidad. Así ocurre con el número de pedido y referencia de pedido. Los sinónimos deben desaparecer del diccionario, o ser declarados como tales. c) Polisemias: encontraremos en nuestra lista en bruto que, con un solo nombre, se designan realidades distintas. Es el caso de una cuenta de cliente, que puede designar el número de cuenta del cliente o el importe de la misma. En la vida corriente se manipulan gran número de Polisemias (café, por ejemplo), y es el contexto el que nos ayuda a determinar su sentido. Aquí, únicamente una definición clara de todos los términos encontrados puede permitirnos despejar las dudas sobre una posible polisemia. c) Las primeras entidades y el repertorio de atributos Hay que definir un cierto número de entidades; cuatro o cinco son suficientes para arrancar. No hay que olvidar que, si bien el método permite crear automáticamente nuevas entidades, no permite suprimirlas automáticamente. Estas primeras entidades, se deducen del objeto de análisis o surgen, de forma natural, del dominio elegido. Si se ha realizado previamente un Esquema Director, podemos partir de las entidades allí recogidas. Una vez hecho esto, tenemos a nuestra disposición un recipiente (vacío) que llenaremos con los atributos que se encuentran en el diccionario. Nos plantearemos la pregunta de si un atributo depende totalmente de alguna entidad (relación 1-1 con el identificador). En caso contrario 190

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

crearemos una relación que enlace las entidades de las cuales depende el atributo. Si el atributo no entra en ninguna entidad, habrá que crear una entidad suplementaria. Si no encontramos un nombre apropiado para ella, dejaremos el atributo de lado hasta que normalicemos el modelo. d) Verificación del modelo Esta primera verificación, del trabajo de modelización, se centra en los siguientes puntos : 1) ¿ Todas las entidades y todas las relaciones, tienen un nombre simple que permite deducir los atributos que contienen ? Si no es este el caso, o bien se debe a una falta de creatividad (laguna grave para un diseñador) o la entidad o relación no existen como tales. ¿ Habrá que desdoblarla ?. ¨Habrá que juntarla con otra ?. 2) ¿ Tienen identificador todas las entidades ?. ¿ Puede identificarse, formalmente, cada ocurrencia de la entidad ?. Esta identificación debe hacerse con ayuda de uno o varios atributos que pertenezcan a la entidad. e) Estudio de conectividades Una vez que hemos verificado el modelo en bruto, tenemos que determinar las conectividades. Estas no se inventan, sino que se deducen de las reglas de gestión. No hay que eternizarse en esta fase que, frecuentemente, provoca largas polémicas para saber si la conectividad es (1,n) o (0,n). De hecho, en la práctica, esto tiene muy poca importancia, y lo que hay que determinar son las grandes clases (0/1,n) y (0/1,1). Siempre Habrá momento de rectificar el modelo en función de la implantación escogida. Para ello, se pueden anotar las conectividades objeto de discusiones no resueltas, como (?,n) o (?,1). Cuando todos los atributos se han alojado, o bien en las entidades, o bien en las relaciones, nos queda crear las relaciones VACÍAS entre las entidades. Este trabajo es delicado, ya que se requiere un buen conocimiento del dominio. Se basa esencialmente en las reglas de gestión, como las conectividades. f) Simplificación del modelo Esta simplificación se refiere a las dependencias funcionales.

191

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

g) Segunda verificación del modelo Anteriormente, nos tuvimos que contentar con una verificación somera, que se fijaba, esencialmente, en la sintaxis del modelo : El control de los nombres de entidades y relaciones, y el control de identificadores. Ahora podemos ir más lejos, controlando si se respetan las propiedades del modelo. Hemos citado anteriormente las seis reglas a aplicar. h) Normalización del modelo Tenemos un modelo entidad-relación correcto, pero en bruto. Todos los atributos han quedado afectados a entidades o relaciones (salvo algunas excepciones), pero aún no estamos seguros de que sea un modelo exportable, de haber descompuesto correctamente las entidades. Este es el objetivo de la NORMALIZACION, hacer el modelo exportable (sobre una m quina virtual). Para ello tendremos que descomponer algunas entidades. Esta operación (normalización), va a tener como consecuencia (indirecta) la revelación de nuevas entidades (y relaciones), que no habíamos percibido en el primer momento. He aquí las reglas que aplicar para normalizar el modelo. Estudiaremos las tres reglas atribuidas a CODD, lo que parece suficiente. La cuarta regla, denominada de BOYCE-CODD, que es la recíproca de la segunda regla de Codd, tiene aplicaciones muy limitadas... y, m s limitadas, todavía, las de las reglas siguientes. 1) Todo atributo debe ser elemental. No puede estar repetido en una entidad o relación. Por ejemplo, no podemos permitirnos tener varios números de cuenta bancaria para un mismo proveedor. La razón es sencilla, si bien de tipo físico : si quisiéramos crear un índice (secundario) sobre este atributo, tendríamos que crear tantos como repeticiones hay del mismo (si se aceptan tres cuentas, tres índices). Esta situación es poco aceptable, además de que la mayoría de las entradas en los índices estarían vacías (la probabilidad de que toda la población de proveedores tenga tres cuentas, es pequeña). Es la misma razón por la que debemos rechazar los atributos, que no tienen valor, para todas las ocurrencias de la entidad o de la relación . ¿Cómo tratar este problema ? : Es suficiente con extraer el atributo de la entidad y crear una nueva entidad asociada a la entidad base.

192

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Un caso particular de esta regla, se refiere a la repetitividad de o y 1, y se enuncia como sigue : todo atributo debe tener un valor para cada ocurrencia de la entidad o de la relación. 2) Todo atributo debe depender, plenamente, del identificador. Esta regla solo se aplica a entidades de identificador compuesto. Si esta regla no se respeta, se introducen importantes redundancias en el modelo, repitiendo inútilmente ocurrencias de determinados atributos. En nuestro ejemplo, la designación del artículo no depende del identificador completo (almacén, número de producto) sino , únicamente, del producto. Para resolver este problema basta con crear una nueva entidad (en nuestro ejemplo producto), que encierre las características comunes, los atributos que solo dependen de un elemento del identificador.

La misma regla se aplica a las relaciones, cuyo identificador siempre es compuesto: es el resultado de la concatenación de los identificadores, de las entidades que enlazan. Hemos visto que, matemáticamente, la relación es el grafo de los enlaces entre las entidades(los conjuntos), es un sub-conjunto del producto cartesiano de dichas entidades, consideradas como conjuntos. 193

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En este caso, el problema se corrige desplazando el atributo en cuestión, de la relación hacia la entidad. Un caso particular de esta regla se denomina dependencia funcional o restricción de integridad funcional : los atributos de una relación deben depender de todos los identificadores de las entidades que enlaza. En las relaciones n-arias (n participantes) ocurre, frecuentemente, que los atributos de la relación son independientes de una o varias entidades. Hemos visto un ejemplo, en el que la cantidad pedida quedaba perfectamente definida por pedido y producto. El conocimiento del cliente (que entra en la relación ternaria), no aporta ninguna precisión suplementaria. 3) Dependencias transitivas. Se pueden eliminar aquí los atributos que , aunque aparentemente dependen del identificador, en realidad lo hacen indirectamente, vía otro atributo. El caso más clásico es el de la localidad (en un anuario ), que parece depender del identificador (la identidad el agente), pero , en realidad, depende completamente del código postal. En este caso se crea también una entidad suplementaria para albergar el atributo en cuestión, y el atributo, del cual depende, ser el identificador de la nueva entidad.

4) Para los puristas y los curiosos señalaremos, que la regla de Boyce-Codd se refiere 194

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

a las entidades cuyo identificador es compuesto (y, por tanto, por las relaciones), por los atributos que componen el identificador, y que pueden deducirse de otros atributos que no lo componen. Los ejemplos no solo son escasos, sino que no se llegan a descubrir hasta que no se conocen las reglas particulares de gestión. i) Cuantificación del modelo Las operaciones precedentes son iterativas. No olvidemos que, mientras queden atributos por casar, se repiten estas operaciones hasta la obtención de un modelo coherente, completo y correcto. Cuando se ha construido dicho modelo, se le completa con datos cuantitativos, recogidos durante el estudio de lo existente. estas informaciones se utilizan, esencialmente, para las cardinalidades (número de ocurrencias) de atributos, relaciones y asociaciones. En el caso de las relaciones, Habrá una medida suplementaria que nos ser muy útil cuando lleguemos al nivel físico (la creación de "ficheros informáticos" : el número medio y máximo de participaciones de cada entidad en la relación. El número mínimo es conocido (por las conectividades, el número máximo (n) es muy vago, y en cuanto al número medio, debe ser objeto de un estudio estadístico, sobre los datos recogidos en los ficheros actuales, o ser obtenidos por sondeo ente los usuarios : se determinará el número medio y máximo de pedidos por cliente, de pólizas por asegurado, etc.

SINTESIS DEL PROCEDIMIENTO * Partir de 4 o 5 entidades * Distribuir los atributos Si dependen enteramente de una entidad, colocarlos en ella, si no, colocarlos en una relación. Nota: Un atributo solo puede aparecer en un lugar Un atributo solo se refiere a un único concepto. * Primera verificación : 195

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Las entidades y las relaciones tienen que tener un nombre. - Las entidades tienen que tener un identificador. - Los atributos tienen que tener sentido para todas las ocurrencias. - Las ocurrencias de las relaciones están identificadas por una y solo una ocurrencia de las entidades que enlazan. * Estudiar las conectividades Deducir las relaciones vacías. * Simplificar funcionales.

el

modelo:

las

dependencias

* Segunda verificación : - Relaciones portadoras de atributos, con conectividad (0/1,1) : los atributos se sitúan en la entidad. - Por cada ocurrencia de la relación no puede existir nada más que una sola ocurrencia de la entidad... y recíprocamente. - Una rama de la relación no puede ser opcional. * Normalización del modelo : - Eliminar los atributos no elementales - Si el identificativo es compuesto, todo atributo debe depender plenamente del identificador (también para las relaciones) - Eliminar las dependencias transitivas. * Cuantificar el modelo

196

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

7.2

MODELO LOGICO DE DATOS - (MLD). ESTUDIO DE ACCESOS

El modelo conceptual de datos comprende : - El diccionario de datos, en el que se censan : - Los atributos - Las entidades - Las relaciones - Las conectividades o, más concretamente, las estadísticas de participación en las relaciones. - El modelo entidad-relación, representación gráfica y semántica del sistema de información del organismo estudiado. Como su propio nombre indica, un MODELO es una simplificación de la realidad y una herramienta de la comunicación. Debemos transformar el modelo entidad relación después de haberlo validado. La primera transformación nos va a permitir estudiar los accesos a las informaciones ( modelo lógico ), mientras que la segunda lo va a hacer aceptable por la BD escogida ( modelo físico ). En la práctica es muy difícil separar ambas operaciones. La primera transformación que hemos mencionado, nos permite definir, en función de los tratamientos, los caminos de acceso necesarios. Hasta ahora solo hemos hablado de identificativos que no son claves de acceso. Su función consiste en identificar un objeto, un agente, y asegurarse que es único en el sistema. Desde el principio, hemos rechazado la idea de establecer hipótesis sobre la utilización de los datos. La clave de acceso nos va a permitir disponer de la información. Para determinar los caminos de acceso, tendremos que "navegar" por el modelo, para lo que habrá que transformarlo en modelo lógico, forma idealizada de implantación de un modelo de datos sobre una hipotética máquina. A) ESTUDIO DE ACCESOS El estudio de accesos nos lleva a transformar el modelo conceptual, para hacer aparecer la noción de REGISTRO. El REGISTRO es la unidad lógica de comunicación entre la base de datos y los tratamientos.

197

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Este nuevo modelo, el modelo lógico de datos, representa también las estructuras de datos bajo su aspecto SEMANTICO, aunque añadiéndole los accesos. El modelo lógico de datos comprende : 1) La cartografía de los accesos ( parte gráfica ) 2) La especificación de las primitivas lógicas de acceso 3) La cuantificación, el coste de los accesos Este modelo conlleva dos nuevas nociones : 1) La noción de REGISTRO, que es una transformación de los conceptos de ENTIDAD y RELACION 2) La noción de CAMINO DE ACCESO, cuyas clases funcionales son una transformación de la noción de CONECTIVIDAD. B) CAMINOS DE ACCESO Un camino de acceso permite acceder a uno o varios registros. Cada camino está orientado en un sentido : permite, partiendo de un registro ORIGEN, llegar a un registro DESTINO. Las clases funcionales se definen en función de registros OBJETIVO , que se pueden alcanzar a partir de un registro ORIGEN, siguiendo un CAMINO. Así, distinguiremos entre cuatro clases funcionales de caminos de acceso, deducidas de las conectividades : 1) 0/1 , n : A partir de un ORIGEN se puede acceder a varios OBJETIVOS. Este es el caso del camino que enlaza Cliente y Pedido(s). 2) n, 0/1 : A partir de varios ORIGENES solo se accede a un único OBJETIVO. Este es el caso del camino que une la Línea de Pedido con Producto. 3) 0/1 , 0/1 : A partir de un ORIGEN no se puede acceder nada más que a un único OBJETIVO. 4) n , n : Un camino puede contener un número cualquiera de ORIGENES y OBJETIVOS. Es el caso del camino que une Proveedores y Productos. C) TRANSFORMACION DEL M.C.D.

198

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El Modelo Lógico de Datos conserva las propiedades del Modelo Conceptual, únicamente se transforman en REGISTROS las entidades y las relaciones. Esta transformación se lleva a cabo de la forma siguiente : - Las ENTIDADES se convierten en REGISTROS. El IDENTIFICATIVO se transforma en una CLAVE DE ACCESO, e indica la secuencia de REGISTROS. Todo ATRIBUTO es susceptible de llegar a ser una CLAVE DE ACCESO. - Las RELACIONES vacías y binarias se transforman en CAMINOS DE ACCESO, enlazando los REGISTROS correspondientes. Este Camino de Acceso puede ser de clase funcional n - n. - Las RELACIONES no vacías y binarias se transforman en un REGISTRO y dos CAMINOS DE ACCESO, enlazando este REGISTRO y los REGISTROS correspondientes a las ENTIDADES. - Las RELACIONES n - arias se transforman en un REGISTRO y en n CAMINOS DE ACCESO. Nuestro Modelo Conceptual:

se transforma en :

199

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

D) PRIMITIVAS DE ACCESO Los accesos se estudian partiendo de los tratamientos, para cada operación. Se distinguir entre las primitivas de acceso propiamente dichas ( búsquedas ) y las primitivas de modificación. La SGBD que hemos modelizado con el modelo lógico de datos, permite las siguientes primitivas : a) Primitivas de búsqueda Los accesos consisten en poner a disposición de un usuario o un programa, uno o varios registros. Estos accesos deben seleccionar todas las ocurrencias deseables y nada más que éstas. El acceso puede hacerse : - Secuencialmente (s) , permite disponer de TODOS los registros de un tipo determinado. - Por la clave de acceso ( definida por el identificativo œ ). Este acceso es, al mismo tiempo, una selección. - Por un camino de acceso (?) . En este caso se conoce el ORIGEN. - Por acceso selectivo siguiendo un camino. En este caso se conocen el ORIGEN y la CLAVE de los OBJETIVOS buscados. La selección de registros puede hacerse : - por una condición explícita (un filtro), - por la clave de acceso, - por la posición del registro en el camino de acceso (primero, siguiente, último, enésimo ). b) Las primitivas de modificación 200

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Los algoritmos de modificación son más simples, pero las primitivas son más complejas porque deben respetar las restricciones de integridad. Las primitivas de modificación de la Base de Datos son : - Creación de un registro (+) - Supresión de un registro (-) - Modificación del valor de un atributo de un registro (M) - Inserción de un registro en un camino (S+) - Eliminación de un registro en un camino (S-) - Transferencia de un registro de un camino a otro (SM) E) OPERATIVA DEL ESTUDIO DE ACCESOS 1) Por operación ( ver modelo de tratamientos) , indicamos, para cada registro, las primitivas de acceso necesarias. Utilizaremos como ejemplo en nuestára descripción, la creación de un pedido. L X

Cliente Pedido Producto Asignación Reserva

+

m

X

X

X X X

Donde L = Acceso a clave + = Creación de registro M = Modificación - = Supresión de registro S = Inserción

2) Describir la secuencia de accesos : 1. Localización del Cliente 2. Creación de un Pedido 3. Búsqueda del Producto 4a. Creación de una asignación 4b. Creación de una reserva 5. Modificación del Pedido 201

-

s

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) Para cada BUSQUEDA ( ACCESO ), describiremos : a) La selección a efectuar ( uno o varios registros ) b) Las condiciones de selección c) La clave de acceso d) El procedimiento, excepcional, en caso de fallo : - el mensaje asociado al fallo - el procedimiento: terminar la operación o llamar a otro módulo. Ejemplo: Buscar el CLIENTE por su IDENTIFICADOR ( No. CLIENTE). En caso de fallo : mensaje 12 y SALIDA. 4) Para cada CREACION ,describiremos : a) El número de registros a crear b) Las condiciones de creación c) El camino de acceso (VÍA, clave de acceso,...) Ejemplo : SI STOCK disponible CREAR una ASIGNACION Vía PEA y PRA SI NO CREAR una RESERVA Vía PER y PPR 5) Para cada MODIFICACION , Estudiaremos : a) Los atributos a modificar b) Las fórmulas de c lculo de los atributos

Ejemplo: 1. Búsqueda de CLIENTE acceso por su Identificativo (No-CLIENTE) si fallo: mensaje 12 y SALIR. 2. Si CLIENTE solvente Crear una ORDEN: identificativo (No-PEDIDO) Para cada producto pedido 3. Búsqueda PRODUCTO acceso por Identificativo (No-ART) si fallo: mensaje 13 y SALIDA. 4. Si STOCK disponible Crear una ASIGNACION vía PEA y PRA si no Crear una RESERVA vía PER y PRR. 5. Modificación del PEDIDO (VALOR) 202

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

... 6) Valoración de accesos. Este cálculo de coste de accesos, se realiza a partir de cuantificaciones recogidas durante la construcción del Modelo Conceptual de Datos. A saber, en nuestro caso : Número de Clientes : 15.000 Número de productos : 2000 Número medio de productos por pedido :10 Tasa de productos no disponibles : 2% Número medio de productos por cliente : 5 Número de pedidos en períodos punta : 50 por hora Estas cantidades nos permiten construir la tabla siguiente: No. medio accesos Búsqueda CLIENTE ................. acceso por No-CLIENTE ............ Si fallo: mensaje 12 y SALIR ..... Si CLIENTE solvente .............. Crear un PEDIDO ................ Para cada producto pedido ...... Búsqueda de PRODUCTO ........ acceso por No- ART ....... Si fallo : mensaje 13,SALIR Si STOCK disponible ......... Crear una ASIGNACION ..... Si no CREAR una RESERVA ..... Modificación del PEDIDO ........

Probabilidad NPunta

1

50 0,01 0,99

5

247

10

495

0,98 0,2 5

495 247

F) NOTAS IMPORTANTES 1) El estudio de accesos puede llevar a la creación de nuevos caminos. Por ejemplo, el atributo NOMBRE DEL CLIENTE, puede transformarse en clave de acceso, a la vista de los tratamientos necesarios. 2) El estudio de accesos puede conducir a reformular una pregunta (cuya respuesta estaba indeterminada) o a revisar el modelo conceptual de datos (ver accesos patológicos). 3) La elección de accesos no es siempre tan evidente como en el ejemplo hasta aquí expuesto. Estudiemos sobre el MCD siguiente, la operación 203

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

consistente en "visualizar la cantidad del producto entregada en una fecha determinada, en un almacén", conociendo los datos siguientes: Número de almacenes : 3 Número de productos : 10000 Hay 8000 productos por depósito, por término medio. 100 entradas en stock, de media por día. Distribución de entradas : 50% almacén A. 25% almacén B 25% almacén C Distribución de las entregas : 1% de los productos se entregan cada día. 50% de los productos se entregan 2 veces al mes. el resto se entrega todos los meses como máximo. Se guarda un histórico de dos años, es decir, la cardinalidad de la entidad FECHA es 500.

El modelo lógico de datos es el siguiente:

204

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Debemos Estudiar los accesos menos costosos. Como se conocen la fecha, el número de producto y el número de almacén, podemos elegir entre tres caminos, que tendremos que cuantificar. a) Acceso por número de producto : Búsqueda de PRODUCTO Para cada STOCK vía PS

1 acceso 500 accesos (1%) 48 accesos (50%) 24 accesos (49%)

media : (500+(48*50)+(24*49)) /100 = 40,76 accesos .... Búsqueda de FECHA vía FS 40,76 .... Búsqueda de ALMACEN vía AS 40,76

Coste total del algoritmo

123,28 accesos

b) Acceso por número de almacén : Búsqueda del ALMACEN Para cada STOCK vía AS

1 acceso 8000 accesos

Este algoritmo se abandona c) Acceso por fecha Búsqueda de la FECHA 1 acceso Para cada STOCK vía FS 100 accesos ... Búsqueda de un PRODUCTO vía PS 100 accesos ... Búsqueda de ALMACEN vía AS 100 accesos

Coste del algoritmo

301 accesos

El acceso por producto parece el mejor (estadísticamente), dada la proporción de preguntas de entrada por los productos con m s movimiento (1%). Si esta proporción fuera más importante, el mejor algoritmo sería el tercero, ya que es el que proporciona los resultados más estables, independientemente del tipo de artículo.

205

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

G) ACCESOS PATOLOGICOS Algunos caminos de acceso pueden conducir a registros no deseados; registros que no corresponden a los criterios de selección. Son TODOS aquellos caminos, en los cuales existe un acceso de clase funcional 1-n o n-n , distinto del primer acceso del camino. Esto es lo que ocurre en el camino siguiente :

Varios valores de C están asociados a B, pero ¨están también asociados a A?. En el ejemplo siguiente, no todo proveedor que proporcione el producto P, tiene que entregarlo al almacén D. En estas condiciones, la pregunta de "qué proveedores entregan el producto P al almacén D", no puede encontrar respuesta correcta en el modelo propuesto.

No por ello debemos concluir que los caminos de acceso son erróneos, sino que son patológicos, ya que pudiera ocurrir que nos proporcionaran un resultado correcto. Así :

206

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

es correcto, porque el jefe del proyecto C es responsable de TODOS los miembros del proyecto P.

Mientras que

es erróneo porque el empleado E del departamento D, no participa necesariamente en todos los proyectos en los que interviene su departamento.

El modelo correcto en este caso es :

7.3

MODELO FISICO DE DATOS ( MFD )

El modelo lógico de datos comprende : - El diccionario de datos que incluye : - Los atributos - Las entidades y las relaciones - Los registros ( que constituyen una visión distinta de los precedentes ) - Los caminos de acceso ...

207

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Las primitivas de acceso asociadas a cada tratamiento y, especialmente, a cada flujo (actualización y consulta). - El coste de los accesos - La distribución geográfica de los departamentales y locales/personales).

datos

(centralizados,

- El modelo global entidad-relación, transformado. Vamos a transformar el modelo lógico en modelo físico, es decir, explotable por una máquina. Esta transformación nos proporcionar , en función de la BD elegida : - Un modelo relacional (que no es necesario representar gráficamente)

- Un esquema CODASYL (que generalmente se representa por un diagrama de Bachman) - Ficheros convencionales (que rara vez se representan de forma gráfica) Todas estas transformaciones son sistemáticas. Es recomendable hacerlas a partir del modelo conceptual de datos, que prima el aspecto semántico. Se añadirán, a continuación, las restricciones de acceso estudiadas en la etapa precedente como, por ejemplo, un camino nuevo.

A) SISTEMA CODASYL : B de D en red Las ENTIDADES se convierten en registros-tipo. El identificativo de la entidad se transforma (en la mayoría de los casos) en clave primaria de registro-tipo. Los atributos de la entidad originan los campos de los registros y, eventualmente, claves secundarias, ateniéndose al estudio de accesos que se ha realizado. Las RELACIONES binarias y jerárquicas, que son siempre vacías (de tipo 0/1,n y 0/1,1) desaparecen para ser reemplazadas por un SET. El sentido

208

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

del SET es de jerarquía : El OWNER corresponde a la entidad cuya conectividad es el 0/1,n.

La participación de PEDIDO en el set es obligatoria, ya que se trata de una conectividad 1,1.

Las RELACIONES no jerárquicas binarias (tipo 0/1,n y 0/1,n) se transforman en dos SETS y un REGISTRO-tipo, si la relación no está vacía, o en dos SETS y un PSEUDO-registro-tipo, si la relación está vacía. Esta transformación, que genera dos SETS, viene acompañada de un empobrecimiento semántico del modelo : la propiedad 4 del modelo EntidadRelación, según la cual, a una ocurrencia de una entidad solo le corresponde una única ocurrencia de la relación, no es aplicable en el modelo CODASYL, en el que se podría tener : Grabadora Vídeo AKAI-M12 12 ALMACENES GARCIA Grabadora Vídeo AKAI-M12 8 ALMACENES GARCIA No se ha respetado el sentido del modelo; habrá que imponer una restricción a controlar por el programador: no puede existir nada m s que un único registro MEMBER para cada ocurrencia de un OWNER. Esta restricción se recoger en las primitivas de acceso.

209

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las RELACIONES n-arias se transforman en 1 REGISTRO-tipo o en un PSEUDO-registro-tipo, según que la RELACION contenga o no ATRIBUTOS, y tantos SETS como entidades estuvieran relacionadas. La transformación en modelo físico viene acompañada de una optimización para mejorar el coste de accesos o para sacar partido de la BD elegida. Así, en la relación ternaria : STOCK ( Producto, Almacén, Fecha ), es m s elegante transformar la fecha en clave secundaria de STOCK. Esta transformación, "fuera de norma", solo es posible si la Entidad contiene un único atributo, su identificativo. Este atributo pasa a ser atributo de STOCK, y la entidad FECHA puede desaparecer.

En nuestra transformación podemos incluir los modelos externos que originan los sub-esquemas.

210

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

B) MODELO RELACIONAL Transformación del vocabulario : Atributo Ocurrencia Cardinalidad Entidad/Relación

-> Columna -> Linea (Tupla) -> Número de lÍneas -> Tabla

Además, el modelo relacional utiliza varios tipos de claves de acceso, todas ellas derivadas de atributos. 1) La clave primaria, que coincidir, en la mayoría de los casos, con el identificativo (si se trata de una entidad) o los identificativos (de las correspondientes entidades, si se trata de una asociación). 2) Claves secundarias 3) Claves candidatas o claves primarias potenciales. Tienen importancia para determinar la validez de una proyección o de una unión (se ver más tarde). Se pueden citar como claves candidatas, en un fichero identificativo que tiene el número de matrícula como clave principal : el número de carnet de identidad, el número de la Seguridad Social. 4) Claves externas o extranjeras, o identificativos de tablas diferentes. Por ejemplo, en un pedido, el número de cliente es una clave externa. Veamos cómo se operan estas transformaciones : Las ENTIDADES se transforman en Tablas, cuya clave primaria es el identificativo. Como ya se ha dicho, los atributos serán las columnas de dichas Tablas. Las RELACIONES binarias y jerárquicas, que son siempre vacías (de tipo 0/1,n y 0/1,1), desaparecen para ser reemplazadas por una clave externa (añadida a la tabla de menor nivel : sentido 0/1,1). Esta clave externa es, a su vez, la clave primaria de la Tabla de mayor nivel (0/1,n). Esta transformación entraña un empobrecimiento semántico del modelo: ya que nada relaciona ahora a las dos entidades jerárquicas, habrá que precisar y controlar por programa que la clave externa referencia una línea (una ocurrencia) existente. En nuestro ejemplo, tendremos que controlar que el No. de cliente sea el No. de un cliente existente. 211

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta operación, este control, habrá de efectuarse para toda clave externa generada por esta transformación. Este control queda, repitámoslo, a cargo del programador; debe quedar recogido en las primitivas de acceso.

Las RELACIONES no JERARQUICAS binarias,( tipo 0/1,n y 0/1,n) se transforman en tablas cuya clave primaria es la concatenación de los identificativos de las entidades (ahora tablas), que enlazaban.

212

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las RELACIONES n-arias se transforman de modo semejante, creando una clave primaria..... y con el consiguiente empobrecimiento semántico. Este empobrecimiento es el mayor problema del relacional actual, ya que conduce a una ignorancia total de las restricciones de integridad referencial : en otras palabras, es posible crear, en relacional, pedidos para clientes que no existen, o para productos que no figuran en el Catálogo de la empresa. C) PROYECCIONES Y UNIONES PATOLOGICAS En una BDR, desde el punto de vista de accesos relacionales a la BD, algunas operaciones de proyección y unión resultan patológicas, incluso si el modelo es correcto y está normalizado. a) La proyección

Esta proyección es correcta si existe una relación 1 a 1 entre el número de departamento y su localización. En cualquier otro caso el resultado es impredecible. Regla : Una Tabla puede ser objeto de una proyección si - la Tabla está en 3a. forma normal - la Tabla resultante contiene la misma clave o una clave candidata (se mantiene también así el identificativo).

213

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

b) La unión

Esta unión es correcta si existe una asociación 1 a 1 entre el número de departamento y su localización: los resultados en los demás casos son indeterminados. Regla: Dos Tablas T1 y T2 pueden ser objeto de una unión si - Las Tablas están en tercera forma normal - T1.x es un atributo de T1 y T2.y es la clave de T2 o, al menos, una clave candidata (para conservar el identificativo).

D) FICHEROS CLASICOS La transformación del modelo entidad-relación en ficheros clásicos, sigue las mismas reglas, limitaciones y restricciones que la transformación hacia el modelo relacional. Las únicas mejoras posibles son: - La posibilidad de jerarquizar (subdefinir) los atributos (los campos), lo cual es imposible en el relacional en el cual los requisitos (tablas) son homogéneos: un solo nivel, el nivel 02. - La posibilidad de definir los atributos repetitivos en los ficheros clásicos (OCCURS).

214

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

E) OPTIMIZACION Cualquier transformación en modelo físico, debe venir acompañada de la optimización del modelo, respetando la semántica inicial. No abordaremos aquí este tema, excesivamente dependiente de la BD elegida.

F) CREACION DE FICHEROS La última operación sobre los datos , es la creación de "Ficheros" en un sentido amplio, esto es, agrupar físicamente registros diferentes.

215

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

8

MODELIZACION DE TRATAMIENTOS

Hemos visto cómo modelizar los datos. Hemos estudiado como representar las conexiones entre entidades (objetos, personas, etc.) y como definir su participación en las relaciones que establecen. Esta modelización, no está reservada únicamente a la representación de las informaciones manejadas por una Organización, un Sistema, sino que, según veremos con un ejemplo, podemos generalizar el modelo para Estudiar cualquier tipo de relaciones. Usaremos también esta representación para Estudiar la dependencia de los tratamientos y su carácter repetitivo. Ya hemos hecho la modelización de datos. ¿ Qué nos queda por modelizar?. Pretendemos saber cómo adquiere el Sistema, la Organización, sus informaciones, cómo las transforma y cuándo las memoriza para reutilizarlas m s tarde. Esta circulación de información en un Sistema puede modelizarse con ayuda de un Diagrama de Flujo. Este diagrama permite Estudiar cómo se operan las transformaciones, sobre las informaciones que circulan en el Sistema, lo cual nos permitiría Estudiar los tratamientos de nuestro Organismo. Estos tratamientos son un reflejo de las necesidades puntuales de nuestro Sistema, necesidades que son susceptibles de evolucionar con el tiempo, en función del organismo en cuestión. Los estudiamos separadamente de los datos, ya que no constituyen la parte estable de nuestro Sistema. Sin embargo, en los tratamientos, hay también un invariante, que tendremos que descubrir: es la esencia misma del tratamiento, del proceso; el porqué de su existencia. Este ser el primer objetivo del modelo conceptual de tratamientos, del cual hablaremos posteriormente. Este modelo nos permite Estudiar por qué vive nuestro proceso, por qué transforma las informaciones. M. Jackson , nos dice que el proceso no es sino la trama de la vida de la información. Si la información no existiera, el proceso no existiría.

8.1

DIAGRAMA DE FLUJOS

¿ Qué informaciones necesitamos para Estudiar un proceso ?. Un proceso, un tratamiento de información, consta de cuatro componentes :

216

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1) La información en movimiento, que llamaremos FLUJO (data flow) o mensaje. 2) El mecanismo de transformación de la información, el tratamiento propiamente dicho, al que llamaremos (provisionalmente) PROCESO. 3) La Información "en reposo", aquella que se acumula para consultar m s tarde, a la que llamaremos FICHERO. 4) Finalmente, los ACTORES, que son la fuente o el destino de la información. Cada uno de Estos componentes está representado por un símbolo: El flujo se representa con un vector orientado, el proceso mediante un rectángulo, el fichero por dos trazos paralelos y el actor por un círculo. Este formalismo, muy simple, es comprensible por todos los usuarios, por lo que constituye un medio de comunicación muy eficaz.

El diagrama de flujos representa la circulación de las informaciones; los caminos distintos que estas pueden seguir y las transformaciones que sufren en ellos. Es la esencia de los tratamientos. Un diagrama de flujos no describe acontecimientos, no introduce tampoco ninguna noción de secuencia ni plazo... los cuáles serán temas del nivel operativo. Además, si bien el estudio de los acontecimientos desencadenantes de procesos es importante (incluso primordial en el entorno industrial), en informática de gestión es aún más importante Estudiar la circulación de la información, ya que es la información la que desencadena el proceso. De hecho, cuando abordemos el estudio del desencadenamiento y la sincronización de procesos, solo nos interesaran de los acontecimientos, las informaciones que éstos transporten.

217

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

a) Flujos o Mensajes Los FLUJOS deben entenderse como tuberías que transportan paquetes de información. Un flujo puede representar una llamada telefónica, un documento, una pista magnética sobre una tarjeta, etc. Nosotros Estudiaremos los flujos de información, y solo nos interesaremos por los flujos de materias cuando éstos sean portadores de información. Así, por ejemplo, solo nos ocuparemos de un paquete si lleva una etiqueta que contenga información útil para el sistema que estamos estudiando. En algunos casos tenemos que considerar a las personas como flujos, como ocurre con los pacientes en un hospital, que transportan información sobre su estado de salud, grupo sanguíneo (análisis de sangre), tensión arterial, etc. A veces podemos agrupar en un único flujo informaciones diferentes, pero que viajan juntas. Este es caso de un PAGO, que reagrupa el CHEQUE y una copia de la factura.

Nótese que el proceso Controlar el Pago, desencadena un flujo con dos componentes. Esta transformación nos permite mencionar una de las propiedades de los flujos, la de la CONSERVACÍON : En un sistema, la información ni se crea ni se destruye, solo se transforma, manteniéndose los componentes elementales. ¨Cuales son los componentes elementales de los FLUJOS? Los atributos que encontramos en nuestro modelo de datos. En nuestro diccionario, un flujo vendrá descrito por sus componentes: Pago = ( Cheque + Copia de Factura ) y cada componente se describe por sus atributos : Cheque = ( Fecha, No. de Cuenta emisora, Importe )

218

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Ya tendremos ocasión de volver a hablar de estas particularidades de los flujos, que constituyen la ligazón con el modelo de datos. Hemos visto que en un flujo podemos tener varias informaciones, siempre y cuando estas se transmitan conjuntamente. Este no es el caso del ejemplo siguiente, en el que la Solicitud de Reaprovisionamiento Urgente no acompaña nunca a la lista de Stocks : Los dos flujos tienen frecuencias distintas, objetivos diferentes y, probablemente, fuentes distintas.

Todo flujo debe tener un NOMBRE que describa su contenido y lo que se sabe a través de él. Así, tendremos que hacer distinción entre Bono de Garantía o Bono de Garantía firmado. El contenido del flujo es diferente, transporta distinta información. Este nombre debe calificar a todo el flujo y no solamente a una de sus partes. En caso de que no podamos encontrar un nombre significativo, es que no existe; lo que pone de manifiesto una realidad encubierta, de varios flujos, en los que debemos descomponerle. b) Procesos Un PROCESO describe una transformación de un FLUJO. Recibe también un NOMBRE que, en principio, es fácil de asignar, ya que todo Proceso transforma un Flujo Entrante en un Flujo Saliente. En rigor, se podría denominar al proceso : Transformación del Flujo A en Flujo B. En la práctica se trata de buscar un nombre compuesto de un VERBO y de un OBJETO. El nombre debe cubrir todo el Proceso, en caso contrario habrá que subdividirlo, ya que enmascara varias transformaciones. 219

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Si el nombre del proceso es compuesto, se llega a la misma conclusión.

Distinguiremos varios tipos de procesos, en función de los flujos que transforman : Los procesos principales, las operaciones y las funciones primitivas. c) Ficheros Los FICHEROS comprenden los ficheros informáticos existentes y los ficheros manuales : los índices, los libros, los carnets e incluso, en algunos casos, la cesta de los papeles. Se trata de depósitos de almacenamiento temporal de la información. Decimos temporal, porque en algún momento debe reaparecer la información, ser consultada, ser explotada, ya que si no, no serviría para nada, estaría muerta. Por el contrario, un fichero no es un cúmulo de información a la espera de un tratamiento, una cola en la que se acumulan los flujos a continuación de un cuello de botella del Sistema, una mala sincronización en el proceso. Esta situación no se estudia en este momento, sino que ser objeto de un estudio particular, cuando se llegue al nivel organizativo. d) Actores Definiremos como ACTOR a toda fuente o destino de un flujo. Un actor está representado por su FUNCION, por el proceso que realiza. Así, en el ejemplo siguiente, el cliente solo nos interesa porque envía una Hoja de Pedido a nuestro Sistema, a nuestro Referencial. 220

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Debemos considerar como actores tanto a los agentes externos a nuestra empresa, como a los agentes internos de la misma. Dentro de este segundo grupo, distinguiremos entre los que son externos a nuestro sistema y los que existen en el mismo. Los primeros son los proveedores o clientes; los otros son agentes activos, responsables de la transformación de flujos. Estos últimos solo se Estudiaran a nivel organizativo. A ) PROPIEDADES DE LOS FLUJOS La importancia del estudio de los flujos ( a los que también se les puede llamar MENSAJES ) es evidente una vez que se conocen sus propiedades. a) Estructura de un flujo Todo flujo puede representarse de forma estructurada, en el sentido que se le da a esta expresión cuando se habla de programación estructurada. Bohm y Jacopini han demostrado que todo programa (o proceso) puede construirse partiendo de tres estructuras elementales : 1) una secuencia de instrucciones, ejecutadas una a continuación de la otra. 2) una estructura cerrada de decisión (IF-THEN-ELSE o CASEOF).

221

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) una iteración (DO WHILE o DO UNTIL). Estas tres mismas estructura s son suficientes para describir o representar un flujo de información. En efecto, un flujo es compuesto, como ya se ha mencionado, de atributos (campos elementales ), que pueden combinarse a partir de los tres elementos mencionados : 1) Secuencia: sucesión de atributos encadenados por un operador Y 2) Selección: elección entre varias posibilidades, cuyos atributos se enlazan por un operador O 3) Iteración: repetición de un Atributo.

Ilustramos esta propiedad con un ejemplo : vamos a describir una Póliza de Seguro Global de Incendio y Riesgos Diversos. Esta se representa como sigue :

No Póliza: K1234567 GARCIA, José c/ Cifuentes, 12 28016 Madrid

Fecha vencimiento: 2/10/95

Situación del riesgo: Paseo de Miralrio, 35 28003 Madrid

Índice de la suscripción: 372,00 Seguro de incendio : Edificio ........ 200.000 Contenido ....... Garantía ........ Tipo A Prima ........... 280 Seguro de robo : Importe aseg .... Garantía ........ Riesgo cubierto.. Prima ........... Este flujo (la póliza) puede representarse mediante la estructura siguiente: No. de Póliza Y Nombre del tomador del seguro Y Dirección del tomador del Seguro Y Dirección del riesgo Y Índice de la suscripción Y 222

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

PARA CADA garantía (1 a 2 riesgos cubiertos) Importes asegurados Y Tipo de garantía Y Prima El Tipo de garantía del Seguro Contra Robo, es: 1er. riesgo (100%) O valor parcial (50%) El tipo de vivienda es : Contigüidad absoluta O contigüidad parcial O edificio aislado. Como se ve, solo se han empleado las tres estructuras descritas anteriormente para describir este flujo Y los atributos que lo componen. Esta posibilidad de estructura r los flujos es utilizada para definirlos, de forma sencilla, en el diccionario de datos. b) Representación en forma de entidad-relación Los flujos no solamente pueden estructurarse, sino que, además, pueden representarse en forma de un modelo entidad-relación. Este modelo se denominar esquema externo, para hacer referencia a su naturaleza, exterior al modelo global, el cual es la representación de la memoria colectiva del sistema. El procedimiento de construcción del modelo es exactamente igual al expuesto en el capítulo precedente: cada flujo está constituido por atributos, los cuales pueden originar entidades conectadas por relaciones. Así, el flujo descrito anteriormente (la Póliza de Seguro de Incendio), puede modificarse de la forma siguiente (sin haber completado la normalización).

223

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La entidad TOMADOR comprende la identificación completa del tomador del seguro, la relación RIESGO comprende la dirección del inmueble asegurado y su tipo. La entidad POLIZA comprende: el número de póliza la fecha de vencimiento el índice de suscripción La entidad TIPO DE RIESGO comprende: la naturaleza del riesgo (incendio del edificio, incendio del contenido o robo) La relación GARANTIA comprende: la garantía: incendio : 7a garantía de base 70 7a + Permiso comercial 71 7a + 200% 72 7o + 71 robo : 80 primer riesgo 81 valor parcial importe asegurado prima el importe asegurado la prima Esta correspondencia entre el mundo de los tratamientos y el mundo de los datos ( a través del mismo formalismo ) va a permitirnos validar nuestro modelo conceptual de datos ( modelo global ). Los esquemas externos deberían poderse deducir del modelo conceptual de datos. Nota: Es tentador no hacer el modelo conceptual de datos, y construirlo posteriormente a partir de todos los esquemas externos ( reflejo de los flujos utilizados por nuestro sistema ). Esta forma de proceder va en contra de la filosofía que seguimos: construir un modelo de datos global y estable. Deduciendo el modelo conceptual de datos de los esquemas externos caemos en el mismo defecto que los análisis clásicos, que supeditan el modelo de datos a las necesidades puntuales de la organización considerada.

224

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

c) Conservación de flujos Los flujos gozan de otra propiedad: se conservan en todo el sistema. La información es como la energía, ni se crea ni se destruye, solo se transforma. Así pues, todo atributo que sale de nuestro sistema debe entrar en él ( mediante un flujo ), provenir de un fichero (flujo en reposo ) o ser el resultado de un cálculo (transformación del flujo ). Esto nos sirve para validar nuestro proceso, asegurándonos su coherencia. Todo lo que sale debe entrar. Recíprocamente, todo lo que entra debe salir, ya que de lo contrario la información es inútil. Esta propiedad se aplica no solamente al sistema que estamos estudiando sino también: - A cada proceso considerado individualmente. Un proceso no crea información, ni tampoco la pierde. Lo único que puede hacer es transformarla o almacenarla ( provisionalmente ). - A toda nuestra empresa ( nuestro universo ). Toda información ( transportada por un flujo ) que entra en nuestra empresa, debe de salir. Si el sistema, el dominio que estudiamos es VENTAS, no todo lo que contienen los flujos entrantes saldrá del mismo, sino que una parte quedar almacenada. Por el contrario, todo debe salir de nuestra empresa, por ejemplo, ciertas informaciones introducidas en el sistema VENTAS resurgirán en el sistema CONTABILIDAD. Si esto no ocurriera así, estaríamos memorizando informaciones inútiles. Si por el contrario, nosotros logramos hacer salir una información que no es deducible de un flujo entrante, es que nuestro análisis tiene enormes lagunas. Esta propiedad se utiliza para asegurar la coherencia y la completitud de nuestro sistema. d) Tipos de flujos No todos los flujos tienen la misma importancia para nuestro sistema. Algunos flujos son los estímulos del sistema, su razón de ser; mientras que otros son engendrados por la propia organización. Llamaremos flujos EXTERNOS a los que entran en nuestro sistema procedente de un ACTOR externo. Estos flujos son la esencia misma de nuestro sistema. Así, el sistema de reaprovisionamiento de stocks existe 225

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

porque nuestras fábricas (actor externo) tienen necesidad de materias primas para funcionar. Esta necesidad, que es un FLUJO EXTERNO es el estímulo de nuestro sistema. Por el contrario, un boletín de compra ( que no es sino otra manera de expresar la necesidad, y por consiguiente una transformación del flujo inicial ) no es nada más que un flujo engendrado por nuestra organización; no es inmutable, puede cambiar o desaparecer. Llamaremos a tales flujos, FLUJOS INTERNOS. La importancia de esta diferenciación es primordial para jerarquizar los tratamientos, como veremos en el apartado siguiente.

En el diagrama de flujos precedente distinguimos dos flujos externos, dos estímulos. La necesidad de materias primas procedente de la fábrica y la entrega de mercancías procedente de los proveedores. Estos dos flujos van a darnos indicaciones sobre la forma de descomponer nuestro dominio en proyectos, pudiendo desarrollarse independientemente unos de otros.

B) PROPIEDADES DEL DIAGRAMA DE FLUJOS a) Partición del diagrama de flujo Si bien solo hay una forma única de concebir el modelo entidad-relación a partir de unas reglas de gestión y de un conjunto de atributos dado, toda vez que el modelo responde a unas reglas matemáticas rigurosas, no ocurre lo mismo con el diagrama de flujos. Podemos imaginar diferentes diagramas de flujos para representar la misma realidad. 226

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Lejos de considerar este fenómeno como una laguna, vamos a sacarle partido. ¿ Qué es lo que puede ser percibido de manera diferente ? No son los flujos, que están materializados, ni los actores, por la misma razón, sino los tratamientos o procesos, como nosotros les hemos denominado. Pueden ser percibidos de diferentes formas, ya que es difícil definir donde empiezan y donde terminan, y siendo los procesos un conjunto de tareas elementales, puede no estar tan claro si debemos asignar una tarea a un proceso o a otro. Vamos a aprovechar esta situación para modelizar los tratamientos de forma TOP-DOWN, viéndoles primeramente como una caja negra ( black box ) en la cual entran y se producen las informaciones. Después, "abriendo" la caja vamos a Estudiar un conjunto de cajas mas pequeñas contenidas en la primera y, así, hasta que hayamos abierto todas las cajas y conozcamos la forma en la que reciben y transforman la información. En ese momento tenemos diversas cajas abiertas delante de nosotros. Imaginemos el trabajo tan considerable que supondría si en lugar de Estudiar progresivamente el mecanismo de cada caja intentamos construir el conjunto a partir de estos elementos. Una propiedad del diagrama de flujos es poder Estudiarlo progresivamente, por pequeños toques, comenzando por la vista general para ir hacia lo más detallado; del proceso general a las funciones primitivas. La primera vista que se tiene de un proceso, es una vista global. Se ve el proceso como un conjunto, un solo proceso (la caja negra ) que recibe informaciones del mundo exterior (flujos externos) y que produce otros flujos, después de su transformación. Llamaremos a este diagrama de flujos particular, diagrama de contexto, ya que el mismo delimita nuestro sistema, nuestro dominio de estudio, dándonos una vista general.

227

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

He aquí el contexto general de un sistema: El reaprovisionamiento de un stock, partiendo de una necesidad de materias primas, transformado en un boletín de pedido con destino a un proveedor. El diagrama de contexto es interesante por varios motivos. 1) Es una buena visión general de lo que hay que hacer. 2) Permite estimar la carga de trabajo necesaria para informatizar el sistema. En efecto, en el estudio previo, dado que no disponemos de todas las informaciones relativas a nuestro sistema, tendremos que recurrir a estimar el coste. En ese momento, los únicos par metros útiles son: el número de flujos, el número de ficheros "importantes" y el número de tipos de preguntas. Disponer únicamente de Estos elementos técnicos nos va a permitir estimar la carga de trabajo y, en consecuencia, el coste de nuestro sistema. 3) El diagrama de contexto permite controlar por primera vez la coherencia de nuestro sistema, ya que todo lo que produce nuestro organismo debe ser deducible de los flujos entrantes ( y de lo que se encuentra en la memoria colectiva del sistema ). Después de censar los flujos entrantes en nuestro sistema, vamos a dedicarnos a Estudiar las transformaciones sucesivas, con lo que descubriremos otros procesos, y las operaciones que se efectúan sobre Estos flujos. De esta forma dividiremos la dificultad que representa la aprehensión del problema en su conjunto. Daremos nombres diferentes a los procesos, en función de su importancia y de su nivel de detalle. Llamaremos PROCESO PRINCIPAL a un proceso que no puede ser interrumpido por la llegada de un flujo externo. El diagrama de contexto muestára un proceso principal. Un proceso principal puede ser subdividido en OPERACIONES. Se denomina OPERACION a un proceso que no puede ser interrumpido por la llegada de un flujo interno. Una operación puede ser subdividida en FUNCIONES PRIMITIVAS. La FUNCION PRIMITIVA es la unidad de subdivisión. Es ininterrumpible, se compone de una única acción, de una sola tarea, ejecutable por una sola persona en un único lugar. 228

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Nuestro proceso de partida se descompone en tres operaciones produciendo cada una un flujo. Nuestro proceso inicial, el proceso padre, genera tres procesos hijos: controlar el stock, controlar los pedidos y pasar un pedido. El problema todavía es complejo, ya que hay más tareas que se esconden detrás de los tres procesos hijos. Continuemos la subdivisión:

No continuamos con la subdivisión de los procesos 1 y 2 (controlar el stock y controlar los pedidos), pero la tercera operación si que engendra nuevos hijos. Podemos considerar ahora que la partición de la dificultad ha terminado. Hemos obtenido lo que denominaremos las funciones primitivas. Se plantea aquí una pregunta: ¿ Cuándo detenernos en la subdivisión ? Tom De Marco, americano pragmático, nos dice que hay que parar la subdivisión cuando se pueda describir la función primitiva en una página, o mejor, en media página de texto. La especificación de la función es, pues, breve. De hecho, se para cuándo se ha subdividido cada operación en tareas elementales, ejecutables por una sola persona en un solo lugar. La función primitiva tiene una única frecuencia, y debe poder ser expresada mediante una sola estructura elemental. Así, no se agrupar el tratamiento

229

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

de la cabecera de una factura ( 1 vez ) con el tratamiento de cada línea de factura ( múltiples valores ). Esta aproximación "top-down", esta forma de particionar, tiene propiedades destacables, y apreciables ventajas. Propiedades de la partición 1) No puede haber más diagramas hijos que procesos en el sistema padre. Así, en nuestro ejemplo, no se pueden encontrar más de tres diagramas en el nivel 2, ya que el diagrama de nivel 1 no comprende nada más que tres procesos. De hecho, no tenemos nada más que uno. 2) Los diagramas hijos no pueden ser gemelos. No puede haber dos tratamientos paralelos (sin intersección) en un diagrama hijo. Así por ejemplo, es erróneo:

De hecho, el proceso que ha engendrado tales hijos es anormal. Representa más de un proceso principal, más de un sistema, ya que tenemos dos vías paralelas, sin flujos ni procesos comunes. 3) Hay conservación de flujos entre los procesos padre y los diagramas hijos. Así, un proceso hijo no puede engendrar un flujo que no se encuentre en el diagrama padre, y viceversa, un flujo que no apareciese en el diagrama padre podría entrar en un proceso hijo.

230

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Por ello es erróneo el ejemplo siguiente:

El diagrama hijo revela dos anomalías: El flujo D no entra en ningún proceso hijo, y además el proceso 2.2 crea un flujo G que no se encuentra en el diagrama padre. Recordemos la regla de coherencia: los flujos se conservan. Por el contrario, el ejemplo siguiente es correcto: Los flujos "hoja de pedido" y "cheque" proceden de la subdivisión del flujo "pago". Este flujo está definido en el diccionario como la concatenación de los otros dos: Pago = ( Cheque + Hoja de pedido )

4) En un diagrama se puede reemplazar un proceso dado por sus procesos hijos. Esta propiedad es muy importante porque permite enfocar la atención sobre un tratamiento particular. Es muy útil como herramienta de comunicación con un usuario que puede ver todas las tareas que ejecuta en un contexto más general, el del proceso principal completo.

231

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

5) Hemos dicho que la especificación, la documentación de las funciones primitivas (diagramas de nivel más bajo) debe hacerse en una página como máximo. Pero, ¿ qué pasa con la documentación a niveles superiores ? Es muy sencillo, no se hace documentación. Los procesos padres no sirven nada más que como índice ya que, en virtud de la propiedad 4, quedan documentados automáticamente por las especificaciones de los procesos hijos. Acabamos de abordar un tema muy importante, la reducción del volumen de especificaciones y su partición, lo que simplifica la comunicación entre las partes y, sobre todo, hace más cómodo el trabajo del programador. Ventajas de la partición Nos hemos referido a ventajas importantes. ¿ Cuáles son ? 1) La aproximación TOP-DOWN permite no solamente simplificar el problema subdividiéndolo, sino también comunicarse mejor. Los diferentes actores del análisis tienen intereses distintos. El analista se comunica con ellos a varios niveles: Con la dirección, a nivel de diagrama de contexto. Con el usuario, a un nivel intermedio en cuyo contexto se detallan se detallan las operaciones que le conciernen. Con el programador, a nivel de las funciones primitivas, que ‚l puede colocar en su contexto dentro de los diagramas. 2) La partición de los diagramas permite conservar gráficos simples y legibles. Según George Miller, la mente humana es incapaz de retener mas de 7 ( +/- 2 ) objetos en un momento determinado. Esta constatación, junto con numerosas experiencias, fue desarrollada en el artículo "The Magical Number Seven: Some limits on our capacity for processing information" aparecido en la Psicological Review de abril de 1956, reeditado varias veces. 3) El trabajo de análisis puede ser distribuido Diferentes analistas pueden ocuparse de los distintos diagramas. 4) Puede enfocarse la atención sobre una serie de tratamientos particulares, estudiados en su contexto. b) Diagrama de subdivisión 232

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Hasta aquí hemos hablado de la dinámica de los tratamientos. Hemos estudiado los tratamientos como transformaciones de informaciones procedentes de flujos. Ahora vamos a ver que es posible estructura r los tratamientos, es decir, jerarquizarlos. Hemos visto que hay dos tipos de flujos: los flujos externos, que son los estímulos de nuestro organismo, y los flujos internos, que son generados por nuestra organización. Fijémonos en el ser humano como un sistema, como un organismo que reacciona frente a la llegada de estímulos exteriores (flujos, mensajes, etc) desencadenantes de procesos que generan flujos (mensajes) internos, que dependen esencialmente de la organización del propio ser. Dichos flujos circulan en el cuerpo, transformándose por aportes de informaciones almacenadas en la "memoria colectiva", hasta producir un efecto. En cualquier otro ser vivo, los mismos estímulos producir n flujos internos diferentes, que tendrán diferentes efectos que en el hombre. Llamaremos proceso principal al conjunto de procesos necesarios para hacerse cargo de un flujo externo. Téngase en cuenta que si varios flujos externos contribuyen a producir el mismo efecto, el mismo flujo de salida, les asimilaremos a un solo flujo compuesto. En el ejemplo sobre reaprovisionamiento del capítulo precedente teníamos dos procesos principales: Pedido de nuevo stock, y recepción de entregas. Estos dos procesos principales no tienen flujos ni procesos en común. Se comunican mediante ficheros. Dichos procesos pueden ser subdivididos. Se denomina OPERACION a todo tratamiento necesario para transformar los flujos de los mismos. Las operaciones de último nivel recibir n un nombre particular: FUNCIONES PRIMITIVAS, y son las únicas que se documentan. Se caracterizan por ser unidad de acción, tiempo, frecuencia, y lugar.

Se puede representar y modelizar la jerarquía que existe entre los procesos por medio del diagrama de subdivisión.

233

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Esta jerarquización de tratamientos, que no es sino una forma alternativa de representar la partición de tratamientos, da una imagen clara y precisa de lo que hay que realizar. Principalmente es una ayuda para el gerente del proyecto. Esta subdivisión le proporciona una visión, de lo general a lo detallado, de lo que su equipo ha de realizar. La primera subdivisión en procesos principales permite identificar varios proyectos ( 2 en nuestro caso ), que pueden ser llevados en paralelo. Esta identificación es primordial para evitar que un proyecto se eternice, o que se asemeje a un enjambre de personas trabajando. El proyecto ideal dura de 6 a 8 meses, y se realiza entre de 5 a 7 personas. ¿ Por qué Estos límites ? La duración aconsejada evita la desmotivación del equipo de realización y de los usuarios. Trabajar más de 8 meses en un proyecto, sin ver los resultados, conduce a la entropía, es decir la pérdida de energía. El ser humano tiene necesidad de una cierta ansiedad para trabajar. Una finalización próxima le estimula, mientras que un objetivo demasiado lejano le genera desinterés. La dimensión del equipo procede de otro análisis. Por un aparte ya hemos hablado del límite de la mente humana alrededor del 7. Aplicado a nuestro caso, se puede dirigir bien el trabajo de 7 personas, pero esta facilidad va disminuyendo a medida que aumentamos esa cifra. Un proyecto necesita un gerente que pueda comunicar y sea capaz de escuchar, no de un jefe, en sentido peyorativo y militarista del término. Además, un pequeño equipo se integra más fácilmente. Sus miembros pueden hacer camarilla, lo cual es muy importante para la consecución de un trabajo en el que los más fuertes deberán "tirar" de los más débiles.

234

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

C) ESPECIFICACIÓN DE LOS TRATAMIENTOS Solo deben ser descritas las funciones primitivas, es decir los últimos niveles de la subdivisión efectuada, es decir los hijos sin descendencia. Esta especificación debe describir la transformación del flujo, sin entrar en la técnica de cómo hacerlo. a) Los siete pecados capitales de la especificación ¿ En qué trampas pueden caer las especificaciones ? En siete, a saber: 1) El ruido Toda forma de perturbación en el texto que capte la atención del lector. Este "pecado", con mucho, es el más frecuente; oscurece el texto, forma parte de nuestros (malos) hábitos de redacción ( el ejemplo que se adjunta a continuación ). Lo que es una figura de estilo en la escritura normal, constituye un error en la redacción de un análisis.

Ejemplo ( especificación embrollada ): Operación: ENTREGA Y REPARTO DE PEDIDOS Esta operación concierne a los pedidos de mayoristas cuya identificación y control de solvencia ya han sido efectuados. Previa discusión con las direcciones afectadas, la determinación de la cantidad a entregar debe responder a los siguientes criterios: La cantidad en stock de un artículo puede corresponder, en un momento dado, a un nivel significativo, pudiendo tenerse: - nivel normal - nivel crítico: si el stock alcanza este umbral, solo se realizaran entregas a los mayoristas. - nivel discrecional: en la entrega intervendrá la decisión, sobre cada pedido, del departamento comercial. En caso de que el stock alcance el nivel crítico, el servicio comercial deber distribuir el stock disponible, de manera equitativa, entre los distintos mayoristas que han solicitado un pedido ese mismo día. Se propone el siguiente criterio: Se compara el total de pedidos de mayoristas de la jornada con el stock disponible para la entrega de ese día.

235

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Si el total de pedidos de mayoristas de la jornada es inferior al stock disponible ese día, se sirven todos ellos Si el total de pedidos de mayoristas de la jornada es superior al stock disponible, se sirve a cada mayorista un prorrateo del coeficiente de entrega. Ejemplo de aplicación de esta regla. Para la jornada J, se anotan, para el producto A, los siguientes pedidos de mayoristas: mayorista X = 100 mayorista Y = 150 mayorista Z = 120 El total es 370 El stock disponible ese dìa es 247. El coeficiente de entrega es el 67%. Se podrá entregar: al mayorista X = 67 al mayorista Y = 100 al mayorista Z = 80 Esta regla admite la siguiente excepción: Si el coeficiente de entrega es inferior al 20%, no se efectuará entrega alguna, con el fin de evitar la excesiva atomización de las mismas. Esto es aplicable al conjunto de productos cuyo stock disponible sea inferior al umbral crítico, y cuyos pedidos hayan sido ya registrados. - Si el stock crítico disponible es inferior al crítico y superior al discrecional: la cantidad servida es igual a la cantidad solicitada multiplicada por el coeficiente de entrega. - Si el stock disponible es inferior al nivel discrecional, la cantidad servida estar determinada por la decisión del servicio comercial, cliente por cliente. - En caso de que la cantidad solicitada solo se haya cubierto parcialmente con el stock, se realizar una reserva automática para completar la cantidad restante. Ejemplo ( especificación correcta ) Operación: ENTREGA Y DISTRIBUCION DE PEDIDOS PARA los pedidos del día PARA CADA ARTICULO SI Total pedidos mayoristas > Stock disponible SI Stock disponible > Stock discrecional Calcular coeficiente de entrega = Stock disponible / Total pedidos mayoristas Si coeficiente de entrega > 0,20 Cantidad entregada = Cantidad pedida * coeficiente entrega Crear RESERVA con Cantidad = Cantidad pedida - Cantidad entregada SI NO Prevenir al Departamento Comercial SI NO Prevenir al Departamento Comercial 236

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

SI NO Cantidad pedida = Cantidad entregada Cada atributo utilizado está descrito en el diccionario. En rigor, el programador no tiene por qué saber que es un Stock discrecional.

2) La referencia anticipada Consiste en mencionar una cosa que aún no está definida. No suelen faltar este tipo de errores en la redacción de libros. En la lectura normal, el contexto ayuda al lector. Esto no es tolerable en un análisis. En el ejemplo precedente se ha hecho referencia a un coeficiente de entrega que se ha definido varias líneas más tarde. Esto dificulta la comprensión y obliga a retroceder. 3) El silencio Consiste en no definir un atributo o un objeto cualquiera, o expresarse con ambigüedad en algún punto del análisis.

Ejemplo ( a no seguir ) La información Código Crédito Cliente, inscrita en el fichero de clientes permitir asegurarse de la solvencia del cliente: 1: no servir al cliente 2: cliente problemático 3: rebasar el crédito acordado Esta información permite un rechazo eventual de la consideración del pedido de un cliente dudoso. Ejemplo ( Especificación correcta ) Diccionario de datos: Código crédito valores permitidos: 1. cliente al cual no servir 2. cliente problemático 3. rebasar el crédito acordado Operación: CONTROL DE SOLVENCIA DEL CLIENTE SI Código Crédito = 1 ó 2 -- Prevenir servicio Comercial -SI Código Crédito = 3 SI Valor del pedido < Crédito acordado * 0,10 Cantidad entregada = Cantidad solicitada SI NO -- Prevenir al servicio Comercial --

237

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En este caso, a no imitar, no se ha dictado ninguna regla estricta, lo que deja la puerta abierta a la imaginación o al buen hacer del programador. 4) La contradicción Ocurre cuando en dos entornos del análisis se utiliza el mismo término con significados diferentes, o asociado a valores distintos. 5) La ambigüedad Es un forma de silencio. El caso que acabamos de ilustrar parece más una ambigüedad que un silencio, o tal vez se trata de ambas cosas a la vez ( í He aquí la ambigüedad ! ). La mayoría de las ambigüedades provienen del deseo de hacer bien las cosas; de los analistas que rehúyen de utilizar varias veces la misma palabra en frases contiguas, sembrando la duda en sus lectores por la introducción de sinónimos inconvenientes: El número de cliente se transforma en la identificación del cliente, o incluso en la referencia del cliente ( que se ha definido en otra parte como la etiqueta que el cliente desea ver aparecer en su factura ). 6) La sobre-especificación Introduce una noción organizativa o física, que explica el cómo, cuándo se debería de responder al QUE. En el ejemplo precedente ( el contencioso ), figura la frase "inscrito en el fichero cliente", que no solamente no aporta nada a la explicación sino que introduce una sobre-especificación. Esta presupone que existir un fichero (informático) de clientes, cuando en este estudio, de lo único que podemos hablar es de la entidad cliente. 7) Los deseos piadosos Es el menos grave de los pecados del analista, pero está muy extendido. Consiste en enunciar asertos, que todo el mundo ignora, sobre el futuro comportamiento del sistema, sin tener ninguna base formal. Se trata de frases del tipo: "Con el fin de aumentar la eficacia del personal encargado de la preparación de paquetes, el servicio de expediciones desea..." b) La especificación racional ¿Qué hacer para escapar de los pecados que acabamos de mencionar? ¿Cómo presentar un modelo de tratamientos legible, atractivo, completo y coherente?

238

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Nuestro modelo de tratamientos comprende: 1) Los diagramas de flujo, desde el diagrama de contexto hasta los diagramas de las funciones primitivas. Estos son fundamentalmente herramientas de comunicación. Sobre la base de Estos diagramas se establecer la discusión con los usuarios. Permiten a los programadores conocer el contexto en el que trabajan. Con ello podrán evitar incluir en la descripción de los tratamientos frases como: "esta operación concierne a los pedidos de mayoristas cuya identificación y control de solvencia ya han sido efectuados". La finalidad de estas indicaciones se solapa con la de los diagramas. Tienen el riesgo de introducir ambigüedades si se modifica el diagrama olvidando modificar el texto. 2) El diccionario de datos, al cual dedicamos un capítulo. Como su propio nombre indica, es donde se van a definir todos los objetos que se manipulan, con el fin de llegar a un consenso sobre su significado. En el diccionario encontraremos la lista de atributos con su descripción, su significado y los valores que pueden tomar sus ocurrencias ( ej. el código de cliente no puede valer más que 1, 2 ó 3 ). Encontraremos también allí la descripción de todos los flujos, en forma estructura da o en forma de modelo entidad-relación ( que no todo el mundo comprende ), incluyendo eventualmente la maqueta del documento. 3) La documentación propiamente dicha. La especificación de cada función primitiva realizada en un estilo claro y preciso. Varios estudios psicológicos han demostrado que el nivel de comprensión del ser humano varía Según cual sea el soporte de la información que debe manejar. Por orden de mayor a menor facilidad nos encontramos con: a) El dibujo y el gráfico. Un dibujo es mejor que un largo discurso. Por esta razón, cada modelo se acompaña de una parte gráfica ( diagrama de flujos, modelo entidad-relación, diagrama de contexto, maqueta de documento ). b) Las fórmulas matemáticas. Todos nosotros hemos sido educados en este tipo de formalismo, por lo cual nos resulta familiar. Resulta aberrante escribir todavía: "La cantidad entregada es igual a la cantidad pedida multiplicada por el coeficiente de entrega". c) Las tablas de decisión. Son una herramienta muy buena para medir y representar la complejidad. Probablemente hemos escuchado que las tablas de decisión no son fáciles de construir. De hecho, si nosotros no somos capaces de construir una tabla de decisión es porque no comprendemos las reglas que hemos escrito y descargamos la responsabilidad sobre otros, entre los que se encuentra el programador, que deber desentrañar y 239

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

comprender dichas reglas, cosa que no tiene por qué hacer. Su papel consiste en transcribir un análisis en un código comprensible para la máquina. d) El pseudocódigo, es decir el estilo telegráfico. Sus ventajas son innumerables. Evita la mayor parte de los 7 pecados capitales ya mencionados. Es claro, directo, conciso. Va a lo esencial, y obliga a precisar el pensamiento antes de redactarlo. Además, su vocabulario puede ser muy limitado, es decir el que está recogido en el diccionario, con algunas palabras suplementarias para formar la sintaxis del lenguaje. ¿ Cuáles son las palabras necesarias para formalizar un tratamiento ? De hecho, Böhm y Jacopini han demostrado que todo proceso puede expresarse con ayuda de tres estructura s elementales. Nos es suficiente contar con tres tipos de construcción de frases para poder expresar todas nuestras ideas. Estas estructura s son: - La secuencia, que no necesita de ningún vocabulario particular. Es suficiente con describir las frases unas debajo de otras. - La iteración, que indica una repetición hasta que se cumpla una condición. Esta estructura se puede formalizar con PARA CADA .... HASTA .... ( o MIENTRAS QUE .... ) - El Test de condiciones, que se puede formalizar con la ayuda de estructura s del tipo SI... SI NO... o para Estudiar todos los valores que pueda tomar un atributo o una expresión EVALUAR (expresión) ... PARA .... PARA ... SI NO ... Baste este vocabulario para describir cualquier tratamiento. Le falta, sin embargo, unos cuantos verbos para la manipulación de la memoria colectiva del sistema: MEMORIZAR, MODIFICAR, BUSCAR, SUPRIMIR ( referirse al modelo lógico de datos, en el que se describen las primitivas de acceso necesarias ). Por supuesto, también haremos uso de operadores lógicos ( Y, O, NO ) o aritméticos ( =, -, +, *, / ). A pesar de todas sus cualidades, el pseudocódigo desagrada. La razón principal, aunque poco reconocida, estriba en que obliga a reflexionar antes de escribir, que es lo que se espera del programador... La razón más aducida es la del rechazo del usuario. Si bien esto es comprensible, para evitarlo se puede actuar de varias formas:

240

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- hay que saber vender este producto al usuario, no imponerlo. El usuario debe comprender la riqueza de este modo de expresión, su rigor, su claridad y su coherencia. - se puede edulcorar el pseudocódigo, respetando su rigor, adornándolo con palabras "inútiles" pero atractivas, evitando los giros idiomáticos complicados. - ¿ Tiene el usuario necesariamente que leer el pseudocódigo? ¿No hay otro medio de instaurar un clima de confianza entre el usuario y el equipo informático?

c) Dominio de la complejidad Muy frecuentemente, las reglas de gestión y los algoritmos que el analista tiene que manipular son complejos, porque muchas veces están mal formulados, o poco formalizados, y son poco rigurosos ( a veces incluso ni existen ). Un analista concienzudo intentar dominar esta complejidad, mientras que uno que no lo sea la traspasar al programador, que ser quien tenga que salir del apuro. Le enunciar las reglas tal cual, sin intentar comprenderlas o estructurarlas. Por qué‚ preocuparse; ya lo hará el programador, que no podrá escapar. Este rechazo de responsabilidad por parte del analista es inaceptable. Es de su incumbencia comprender el problema, formalizarlo. ¿ Se puede dominar esta complejidad por medio de herramientas ? Antes de intentar dominar la complejidad, debemos, con respecto al método, preguntarnos: ¿Por qué existe esta complejidad? ¿Existe alguna otra razón aparte de las conocidas históricamente? ¿No hay forma de proceder de otra forma? Nos sorprendería comprobar cuantas viejas reglas se hacen añicos ante estas sencillas preguntas. í Cuantos problemas no habremos concebido para informatizar errores de gestión, aberraciones organizativas ! El papel del analista no es pasivo, sino activo, dinámico. Tiene que Estudiar los procesos a fin de mejorar su calidad, simplificarlos. Si verdaderamente no hay forma de eliminar la complejidad se puede intentar dominarla, modelizándola mediante tablas de verdad, tablas de decisión o por medio del modelo entidad-relación. Tablas de decisión Una tabla de decisión es una herramienta para dominar la complejidad. Se habrían podido dar las reglas de distribución del stock restante entre los mayoristas, por medio de una tabla de decisión, que habría tenido la forma siguiente:

241

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Coef-entrega = Stock-disponible / Total pedidos mayoristas Total ped. may. > Stock disp. ssssnnnn Stock disp. > Stock discrecc. ssnnssnn Coeficiente entrega > 0,20 snsnsnsn ----------------------------------------------------------------Cant. entr. = Cant. ped. xxxx Cant. entr. = Cant ped * Coef ent x Memorizar RESERVA resto ped. x Prevenir Dep. Comercial xxx En la parte superior izquierda situamos TODAS las condiciones posibles, jerarquizándolas. En la parte inferior izquierda, listamos TODAS las acciones posibles. En la parte superior derecha haremos el inventario de las combinaciones posibles entre las condiciones. Dicho inventario es sistemático, dependiendo el número de combinaciones del número de condiciones. Número de combinaciones = 2 ** Número de condiciones El inventario de combinaciones debe estar normalizado 1) Las "s" deben preceder a las "n". 2) El número de grupos de S debe ser decreciente en cada línea de la tabla. 3) La última línea de las condiciones debe constar de una sucesión de "s" y "n", indicando respectivamente que la condición está satisfecha o no. Nos queda indicar qué‚ acciones tomar para cada combinación de condiciones encontrada. Esta forma de hacer nos garantiza que hemos considerado todos los casos. En esta fase se puede simplificar la tabla: 1) Si en dos columnas adyacentes una condición es neutra ( no influye en el resultado ), se pueden reagrupar las columnas y marcar la condición neutra con un trazo. 2) Las columnas terminales que no sirven, para las cuales no hay acciones particulares, pueden desaparecer.

242

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La aplicación de estas reglas nos da esta tabla, normalizada y simplificada: Total Ped. mayoristas. > Stock disponible. s s s n Stock disponible > Stock discreccional ssnCoef. entrega > 0,20 sn---------------------------------------------------------------------Cant. entregada = Cant. pedida ...x Cant. entregada = Cant. pedida * Coef entr x . . . Memorizar RESERVA Saldo Pedido x... Prevenir dep. Comercial .xx.

En la parte inferior derecha, una equis indica que la acción se realiza para la combinación de condiciones representada por la columna. Un punto indica lo contrario. La tabla de decisión no solamente nos permite Estudiar todas las combinaciones de casos posibles, y expresar brevemente una situación compleja, sino que también nos permite programar esta situación de forma totalmente automática, si la tabla está normalizada. ¿Cómo proceder ? PARA CADA Columna SI es la primera columna se desciende por la columna SI se encuentra una S se escribe IF y la condición correspondiente SI NO se continúa SI NO ( caso de las otras columnas ) se remonta la columna hasta que se encuentra una N se escribe ELSE se desciende en la columna SI se encuentra una S se escribe IF y la condición correspondiente SI NO SE CONTINUA PARA CADA acción SI se encuentra una X, se escribe la acción SI NO se continúa

Este mecanismo, aplicado a nuestra tabla, nos da :

243

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

IF total pedidos mayoristas > stock disponible IF stock disponible > stock discrecional IF coeficiente entrega > 0,20 Cantidad entregada = Cantidad pedida * coef.entrega Memorizar RESERVA saldo del pedido ELSE prevenir al dep. Comercial ELSE prevenir al dep. Comercial ELSE cantidad entregada = cantidad pedida Lo cual es exactamente el enunciado de la situación que describíamos anteriormente ( ver apartado relativo al "ruido").

D) PROPIEDADES ORGANIZATIVAS El diagrama de flujos representa todos los caminos posibles que puede seguir la información, sin otra precisión. Podemos completarlo con ayuda de nociones suplementarias, tales como: - los agentes internos; los que realizan procesos - el desencadenamiento de procesos, los acontecimientos - las dependencias entre procesos, su secuencia a) Agentes internos Los nombraremos en la parte superior del rectángulo que representa el proceso. Solo utilizaremos esta representación para las OPERACIONES que responden a una unicidad de lugar.

En el capítulo reservado a la dirección del proyecto presentaremos otras formas de visualizar el trayecto (físico) de un flujo. b) Acontecimientos Representaremos los acontecimientos ( no portadores de información ) que desencadenan procesos, como un plazo, por una flecha grande incidiendo en el proceso. Este proceso será siempre una operación.

244

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

c) Dependencias entre procesos El camino seguido por los flujos a través de los distintos procesos no es indiferente. Responde a ciertas condiciones: - dos procesos pueden ser mutuamente excluyentes - dos procesos pueden realizarse en paralelo - la frecuencia de dos procesos puede ser diferente, lo que obliga a una espera, una sincronización Podemos representar Estos casos en el diagrama de flujo. 1) Caso de dos procesos mutuamente excluyentes:

El flujo ha bifurcado, y la condición de realización se ha indicado sobre la rama correspondiente (IF..THEN..ELSE o CASE OF). 2) Caso de dos procesos concurrentes paralelos:

3) Caso de dos procesos de diferentes frecuencias

245

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para ello hemos utilizado los mismos símbolos que empleamos en los modelos de datos. Este encadenamiento puede representarse en pseudocódigo de la forma siguiente: PARA CADA factura Editar la cabecera de la factura PARA CADA línea Editar la línea de factura Editar los totales de la factura El proceso "editar las líneas de factura" tiene una frecuencia distinta de la de los otros dos. La edición de totales no puede arrancar antes que el tratamiento de todas las líneas de factura. E) OPERATIVA. COMO CONSTRUIR EL MODELO a) ¿ Por dónde comenzar ? El modelo de tratamientos es una de las primeras cosas que se abordan en un análisis. Ya en el estudio de lo existente se emplea para modelizar la situación actual, con sus restricciones organizativas y técnicas. Utilizaremos casi desde el principio el diagrama de flujos. Como ocurre con todos los modelos, el principio es la parte más laboriosa. Hay dos formas de empezar, dependiendo del nivel de los interlocutores que tengamos. 1) Si uno de los usuarios es buen conocedor de los procesos que vamos a Estudiar y tiene una buena visión de conjunto, comenzaremos por el diagrama de contexto, que identifica los flujos externos ( los estímulos de nuestro sistema ) y los flujos salientes del sistema. 2) Si no, se comienza por cualquier parte, Según los interlocutores, donde haya un experto. Se modeliza durante el transcurso de las entrevistas, solicitando al usuario la validación del modelo. Se crean, de esta forma, un conjunto de microsistemas centrados alrededor de cada usuario entrevistado, considerando a todas las demás personas como actores ( exteriores ). 246

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

He aquí como el gerente del stock ve su actividad ( el conjunto de actividades de las que se ocupa ):

A continuación tendremos que ensamblar todas las piezas del rompecabezas, entrevistando a las personas, vistas como "actores externos". Cuando el rompecabezas comience a tomar cuerpo hay que confrontarlo, sometiendo el diagrama de flujo completo a la opinión de todos. Cuando seamos capaces de tener una visión de conjunto del problema, se crea el diagrama de contexto, identificando todos los flujos entrantes y salientes a nuestro sistema, considerado este como un todo. Tenemos que hacer esto para poder reestudiar, fuera del contexto organizativo y técnico actual, los tratamientos esenciales, necesarios para transformar los flujos entrantes en flujos salientes. Es conveniente señalar que son las funciones primitivas las menos impactadas por la solución organizativa y técnica actual. Cuando sea difícil clarificar los tratamientos, aprehender la esencia de los mismos, hay que reemplazar en los diagramas intermedios los procesos por sus diagramas hijos, que tendrán menos restricciones y describir en operaciones más sencillas.

b) Búsqueda de los flujos internos Los flujos internos suelen ser materiales, presentados en forma de documento. Pero no siempre es así; si el sistema ya estaba informatizado existir n flujos intangibles, generados por una m quina. También puede que existan comunicaciones telefónicas. Tenemos que buscar los flujos internos. Conociendo los flujos externos podemos dibujar el proceso al cual van a parar ( o del que parten ). A continuación nos plantearemos preguntas como: 247

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

¿Qué informaciones se necesitan para constituir un flujo ? ¿ De dónde proceden dichas informaciones ? ¿ Cuáles son los flujos que se transforman para proporcionarnos las informaciones necesarias? ¿ Qué procedimientos, que procesos realizan esta transformación ? Esto nos permitirá construir un diagrama en el cual, la mayoría de los procesos e incluso de los flujos, no tienen nombres correctos. Hay que comentar que suele ser más fácil partir de los flujos salientes, y reconstruir los flujos entrantes en función de los datos que se necesitan. c) Identificación de los flujos Vamos a poner nombre a los flujos. Si nos es imposible dar un nombre correcto a un flujo, es que no existe. Tendremos que analizarlo para descomponerlo o integrarlo en otro flujo. En cualquier caso, el nombre asignado debe calificar al flujo completo. Tendremos que evitar asignar nombres genéricos del estilo de datos o información. Asimismo buscaremos nombres que permitan identificar el flujo. Evitaremos usar "formulario E48" salvo si los contactos con el usuario nos demuestra que ese nombre le es familiar. A medida que vamos identificando los flujos los describimos en el diccionario. d) Identificación de procesos Es más fácil dar un nombre a un proceso que a un flujo. Por definición podemos denominar al proceso como "transformación del flujo IN en flujo OUT", si bien esta actuación denota falta de imaginación. Generalmente el nombre de los procesos estar compuesto de un VERBO y de un OBJETO tal como "verificar la solvencia del cliente". Como en el caso de los flujos, este nombre deber calificar a toda la actividad del proceso. Si el nombre es compuesto, es que el proceso esconde dos actividades distintas que pueden descomponerse sin engendrar procesos hijos. También aquí huiremos de apelaciones genéricas del tipo 'tratar" o "manipular". e) Validación del diagrama de flujos ¿ Es correcto nuestro diagrama ? Podremos verificar una serie de puntos, pero la cuestión fundamental de si éste refleja la realidad no puede ser solventada sino delante de los usuarios o en presencia de otros analistas. De hecho deben tener lugar las dos confrontaciones; primeramente con otros analistas y después con los usuarios. ¿ Qué se debe verificar ? 248

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1) ¿ Falta algún flujo ? ¿ Son indispensables todos los flujos ? ¿ No hay flujos vacíos ? 2) ¿ Cada flujo tiene nombre ? ¿ Se relaciona dicho nombre con el contenido ? 3) ¿ No falta ningún proceso ? ¿Todos los procesos que figuran existen realmente ? 4) ¿ Están en consonancia el nombre del proceso y sus flujos entrantes y salientes ? 5) ¿ Refleja bien el nombre del proceso las operaciones que comprende ( ver en el diagrama de nivel inferior ) ? 6) ¿ Respetamos la conservación de flujos ? ¿ No creamos información ? ¿No perdemos información ? 7) ¿ Son correctos los flujos entre los diagramas de niveles diferentes ? f) Test de legibilidad del diagrama Que nuestro diagrama sea correcto y refleje bien la realidad no presupone que nuestros usuarios puedan leerlo y comprenderlo. ¿ Hemos denominado apropiadamente los flujos y los procesos ? Tratar el pedido, manipular las entradas o hacer la mezcla indican una subdivisión muy ligera. Tener nombres correctos para todos los flujos y procesos es un indicativo de que hemos llegado al final de nuestro trabajo.

g) Documentación de funciones primitivas Solo nos queda documentar las funciones primitivas, describirlas, especificar los tratamientos. Ya nos hemos referido anteriormente a esta etapa.

SINTESIS MCT - Diagrama de flujos ( del contexto al detalle ) - Procesos generales - Operaciones - Funciones primitivas - Especificaciones de funciones primitivas - Cuantificación

249

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

MOT - Subdivisión de los tratamientos - Distribución (estudio de servidores) - Medios de implantación (estudio de tareas) - Cuaderno de procedimientos (para el usuario) - Diagrama de encadenamientos MOpT - Diseño de formatos de pantalla y documentos - Subdivisión en programas - Cuaderno de realización (para el programador)

9

EL PROYECTO DE ANÁLISIS INFORMÁTICO

Diferenciamos fundamentalmente entre DIRECCION del proyecto y GESTION del proyecto. La dirección del proyecto describe la operativa a seguir para realizar un proyecto, definiendo sus diversas etapas. Se refiere al CICLO DE VIDA del proyecto. La gestión del proyecto persigue otro objetivo: recursos, la duración y el coste de un proyecto.

Gestionar los

Esta técnica es completamente independiente de la naturaleza del proyecto (informático o de otro tipo). Constituye el CICLO DE DECISION del proyecto.

9.1

PLAN DE SISTEMAS

En este apartado no vamos a abordar la manera de realizar un Plan de Sistemas, ya que ahora no nos interesa por sí mismo sino por las informaciones que proporciona al Análisis. Vamos a estudiar un caso extraído de un proyecto real. Se trata de la sociedad VITAL S.A., laboratorio farmacéutico especializado en productos en forma de pastillas. Vamos a conocer esta Empresa: 250

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La Sociedad Anónima VITAL se fundó en el año 1910. Su principal impulsor fu‚ el el Sr A. Director, el Sr Jerónimo VITAL.

VITAL, abuelo del actual

En un principio, el Sr Alberto VITAL era un farmacéutico que poseía una oficina en el centro de Madrid. Desde el primer momento se enfrentó con el problema de la conservación y embalaje de los productos que preparaba. Se dispuso, pues, a rentabilizar su producción. Después de algunos años de investigaciones, puso a punto una técnica de fabricación de pastillas. Esta técnica era, desde luego, conocida en la ‚poca, pero él logró la manera de crear productos semielaborados que sirvieran de base a las preparaciones. Los colegas del señor VITAL se interesaron por sus investigaciones y le convirtieron en su proveedor. Muy pronto se vio desbordado de pedidos. Se especializó, entonces, en ciertas clases de productos, que comercializó bajo el nombre de VITAL. Actualmente, la sociedad VITAL realiza una cifra de negocios por valor de 600 millones de pesetas, y cubre alrededor de un 8% del mercado farmacéutico. Trabajan para ella una 200 personas y posee 1500 clientes : hospitales, farmacias, droguerías y mayoristas. La Sociedad ha abierto, recientemente una división, QUIMITAL, que fabrica una serie de productos que van, desde la laca para cabellos, hasta algunos barnices utilizados por otros fabricantes para realizar revestimientos. Sus laboratorios efectúan investigaciones que entran en el marco de una estrategia elaborada por una división MARKETING, muy activa. Este laboratorio lleva a cabo, igualmente, controles de calidad sobre los productos acabados, y puede determinar rápidamente productos de sustitución, si los productos de base faltan o si dejan de ser interesantes. El organigrama de esta sociedad es el siguiente:

251

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El Plan de Sistemas ha permitido determinar 5 grandes dominios para informatizar : - Dirección y Planificación, - Producción, - Venta, - Compras - Finanzas y Administración.

La circulación de los flujos en el interior de la Sociedad es la siguiente:

El Dominio que nos interesa es el de la VENTA. 252

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Los objetivos fijados son: 1) Lograr pedidos directos gracias a las visitas a farmacéuticos, médicos y drogueros (visitas precedidas de una campaña de publicidad). 2) Reducir los débitos, gracias a un mejor conocimiento de los clientes y a una denegación eventual de entrega. 3) No entregar más que paquetes completos (evitar las entregas parciales). 4) Rentabilizar las entregas, agrupándolas y estudiando el mejor medio de transporte, teniendo siempre en cuenta la satisfacción del cliente. 5) Reducir las devoluciones al máximo mediante una mejor gestión de la fechas de caducidad de los lotes. 6) Tratar de contentar a todos los Clientes, distribuyendo las cantidades que quedan en stock (para los mayoristas) o proporcionándoles productos similares. 7) Determinar las previsiones de venta para administrar el surtido, el ritmo de la producción y satisfacer mejor los pedidos. 8) Mejorar las estadísticas de ventas y los resultados financieros, sobre todo a nivel de los plazos. 9) Reservar los pedidos no entregables para su expedición ulterior. Las actividades censadas en este Dominio son: - Recepción de las hojas de pedido (por teléfono, por medio de los representantes o por correo). Con control sobre la exactitud del pedido. - Control de solvencia del Cliente. - Expedición de las facturas. - Recepción de la gestión de las devoluciones. - Envío de Notas de Crédito. - Puesta al día de los stocks de productos terminados. - Gestión de las distribuciones. - Estudio de mercado. - Establecimiento de los precios de ventas. 253

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Visitas a clientes : prospecciones, pedidos. Gestión de los gastos de representación. - Recepción y gestión de los pedidos de los representantes.

El diagrama de contexto del Dominio es el siguiente :

254

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

9.2

ESTUDIO PREVIO

Objetivo - Tener una vista de conjunto del Dominio estudiado. - Determinar el escenario de la puesta en marcha : qué medios emplear para llevar a cabo con éxito la realización. ¿ Es necesario recurrir a técnicas puramente informáticas, o a técnicas ofimáticas ?.¿Podemos llevarlo a cabo nosotros mismos, o hay que recurrir a sociedades exteriores?. - Conocer suficientemente el Dominio, para saber a dónde se quiere ir, antes de comenzar a caminar. - Determinar el presupuesto y los recursos necesarios para la realización del proyecto. - Definir el entorno de realización y explotación, es decir, el cuaderno de especificaciones.

redactar

En resumen, se puede decir que el Estudio Previo consiste en hacer un estudio de la viabilidad del proyecto y en describir las especificaciones funcionales. Operativa general Un Estudio Previo debe ser de corta duración, como máximo 2 ó 3 meses. Se puede lanzar después de un Plan de Sistemas para estudiar más en detalle un dominio que parezca importante o más complejo. No debe convertirse nunca en un Estudio Detallado, pero tampoco el Método debe limitarnos: si se conoce bien el dominio, si es sencillo y su posición en el conjunto está bien definida, se puede obviar esta etapa. Esta etapa de la operativa comprende tres fases importantes: A) Estudio de lo existente: recopilación de las informaciones relativas al dominio. Nótese que todas las etapas del Análisis, Plan de Sistemas incluido, comienzan por un estudio de lo existente, con el fin evidente de familiarizarse con el dominio o la aplicación. 255

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

B) Concepción: Búsqueda de tipos de soluciones. Esta etapa se realizar sobre la parte del Dominio que llamaremos el Subconjunto Representativo ( en abreviatura SCR ). La concepción comprende la elaboración de un modelo conceptual de datos, con una breve incursión hacia el modelo lógico, y la construcción del modelo conceptual de tratamientos, seguido del modelo organizativo. C) La última fase es de conclusión, de síntesis y de elección en cuanto a la implantación de la solución. Se termina con la elaboración del Cuaderno de Especificaciones y con la crítica del escenario elegido con vistas a la elección definitiva. Detallemos cada una de estas etapas. A) ESTUDIO DE LO EXISTENTE a) Objeto del estudio Deberemos responder a tres preguntas: 1) ¿ Cuál es el ámbito del estudio? Vamos a estudiar las estructuras implicadas, el dominio de actividad, las restricciones políticas, la estrategia de la Empresa en este Dominio (la Estrategia es la elección de los medios necesarios con vistas a poner en marcha una política). Deduciremos: - la estructura de la Empresa implicada, - el dominio de actividades cubierto, - las grandes funciones a estudiar y sus restricciones, - las interfaces con los otros dominios (Flujos, Ficheros). 2) ¿Cuáles son los objetivos? Queremos conocer el objetivo a priori; que ser precisado de nuevo después del Estudio Previo, cuando tengamos una mejor visión del presupuesto, de los recursos, de los problemas y de las consecuencias de la informatización. 3) ¿Cuáles son los factores de desarrollo de la etapa?

256

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Debemos tener en cuenta: los actores (las personas que intervienen), el presupuesto (si el dominio estudiado es nuevo para nuestra Sociedad, deberemos tomar contacto con otras Empresas o crear un prototipo exploratorio. Estas gestiones pueden ser costosas), el calendario de nuestro proyecto. No olvidemos que un Estudio Previo es siempre breve ( de 2 a 3 meses como máximo). los hitos, los puntos de control de nuestra misión, durante los Cuáles nuestras opciones serán validadas por la Dirección.

b) Diagnostico de la situación actual Todo estudio de mejora de un proceso y su Análisis pasa por una fase de diagnóstico de la situación existente. Vamos a estudiar el dominio para ver si es adecuado a los objetivos fijados y a las necesidades que resultan de estos objetivos. Vamos, pues, a llevar a cabo una encuesta crítica que nos dirá si la percepción del funcionamiento del Dominio por la Dirección (que es la fuente de información para el Plan de Sistemas) es adecuada o si está deformada por un sistema de información inadaptado, entre el sistema operante y el sistema de decisión. Vamos a sacar a la luz los puntos fuertes y los puntos débiles del Dominio, de los que deduciremos nuestro Subconjunto Representativo. * La encuesta La encuesta nos va a permitir recoger informaciones sobre los datos, los tratamientos efectuados (procedimientos), las funciones cubiertas por el Dominio (células), los circuitos de información (flujos), el volumen de informaciones tratadas y los plazos de realización de los procedimientos. La encuesta se hace a partir de:

257

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- consulta de la documentación existente, ya sean los documentos (cumplimentados) que se utilizan actualmente, los estudios precedentes o los manuales de procedimiento. - entrevistas acerca de un punto preciso: como se transforma la información. Se estudia procedimiento por procedimiento, la transformación de un flujo, su utilización por varias células. - entrevistas exhaustivas con cada actor : Cuál es su papel en el Dominio, cómo percibe el dominio a través de las informaciones que él trata. Se puede utilizar otra clase de informaciones muy enriquecedoras, que recuerdan el comportamiento de los Sistemas Expertos. Consiste en acompañar durante algunos días a la persona cuya función se quiera aprender. Esto no solo nos permite VER lo que hace, sino impregnarse de su VOCABULARIO. * Análisis global de Procesos Hemos visto que el mundo real está compuesto de flujos (Mensajes), procesos, actores y ficheros. La encuesta que hemos llevado a cabo no nos ha proporcionado más que estos cuatro componentes, con sus propiedades cuantitativas y Cualitativas. Podemos, pues, trazar la cartografía de los tratamientos, es decir, el diagrama de flujos de nivel 1, sin entrar en detalle de las diferentes operaciones, sin descomponerlas en funciones primitivas. Este diagrama de flujos se acompaña de matrices útiles para analizar mejor el comportamiento del dominio: la matriz de utilización de los flujos por los diferentes actores internos ( por las células de trabajo, los recursos humanos necesarios para el buen funcionamiento del dominio ). Estudiamos también el aspecto cuantitativo de los flujos y de sus tratamientos : su volumen, la duración de los tratamientos, la constitución de las células, el número de puestos de trabajo, los costes de explotación y el aspecto Cualitativo de los tratamientos : - el valor de los resultados producidos - la adaptación de las personas al cambio : para que un proyecto informático tenga éxito, es preciso que sea aceptado por las personas encargadas de ponerle en marcha, de hacerle vivir. Debemos, por lo tanto, conocer su comportamiento frente a la novedad. Hay que tener en cuenta que el dominio estudiado no está 258

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

informatizado y que las técnicas que vamos a poner en juego pueden perturbar las costumbres( introducción de técnicas de comunicación de Empresa, supresión del soporte papel, etc ). Ser prudente avanzar con pasos cortos determinando una aplicación particular y creando un proyecto piloto que implique a las personas aptas para innovar. Este proyecto piloto servir de escaparate, de publicidad, para que se acepte seguidamente el proyecto, y servir , también, al pasar revista al fin de la etapa, de validación, de demostración para reafirmar nuestras conclusiones. - las anomalías y las carencias detectadas en la comunicación del sistema operante con el sistema de decisión. Se redactar un informe particular sobre este tema. - los cuellos de botella en la circulación y el tratamiento de la información. - los puntos fuertes y débiles constatados en el sistema de información. No haremos ninguna crítica personal , salvo si un comportamiento individual pone en peligro al Sistema . No estamos autorizados para hacer modificar el comportamiento de las personas sino para mejorar la calidad de los procesos de transformación de la información y de su uso. * Balance de lo existente - Elección del SCR Hemos hecho un estudio general de lo existente, sin entrar en detalles, porque ni tenemos tiempo, ni lo necesitamos por el momento. De dicho estudio deduciremos un balance de lo existente, que no es más que la síntesis de lo que hemos señalado en la etapa precedente, síntesis destinada a la Dirección y, por tanto breve, portadora de lo esencial, de lo que verdaderamente interesa : Las disfunciones, los puntos fuertes, las sobrecargas, las inadecuaciones con los objetivos o las necesidades, los aspectos cuantitativos ( los costes y los volúmenes ), el nivel del servicio prestado( flujos entrantes/flujos tratados), los riesgos de implantación imprudente ( resistencia al cambio ),etc. Si hay que llevar a cabo un estudio más intenso, se seleccionar un Subconjunto Representativo, sobre el que vayamos a elaborar los modelos conceptuales de datos y de tratamientos, y nos haremos una idea de la manera en que vamos a organizar estos dos grandes componentes del sistema de información.

259

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La meta del SCR es hacernos una idea precisa del presupuesto, de los plazos necesarios para realizar la aplicación, y de los medios (informáticos y humanos) necesarios, trazar los planes de puesta en marcha y , eventualmente, revisar el Cuaderno de Especificaciones, que es el principal resultado del Estudio Previo. El SCR sirve de base al proyecto piloto eventual. Su elección se hace en función de cierto número de criterios: - El objetivo perseguido, - El valor de los bienes y servicios puestos en juego. Se trata de escoger un punto principal del Dominio, un punto característico del desarrollo de los procesos. Por ejemplo, en el Dominio de Compras, no tendremos en cuenta como el SCR controla las facturas de los Proveedores, sino más bien la optimización del almacenamiento (vista su complejidad) o la puesta al día de los stocks (vista la apuesta económica). - La frecuencia de los procesos. - La complejidad de los procesos. - Su coste de explotación : si el 10% de los efectivos de la Sociedad están afectados a control de las facturas de los Proveedores, este proceso se puede convertir en nuestro SCR. - El interés manifestado por la dirección por un problema particular, que puede aportar más a la imagen de marca. - El volumen de las informaciones tratadas (aunque no debe ser el único criterio examinado). - El grado de automatización deseado a priori. Es inútil tomar como SCR un proceso que quedar manual. No olvidemos que, en función del Dominio estudiado y de la resistencia al cambio manifestada por el personal, el estudio del SCR se puede transformar en un proyecto piloto. B) CONCEPCION DEL NUEVO SISTEMA En el momento actual trabajamos sobre el subconjunto representativo, que nos va a permitir elaborar una solución tipo, que esperamos se aplique a todo el dominio. Esta solución tipo, que vamos a concebir, debe ser estudiada : - en función de los objetivos determinados al comienzo del Estudio Previo, que serán redefinidos en esta etapa.

260

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- teniendo en cuenta las constataciones hechas a lo largo del estudio de lo existente y, en particular, de los puntos débiles y de las inadecuaciones. - con vistas a mejorar la calidad de los procesos y la ergonomía de los puestos de trabajo ( en un sentido amplio ). a) Redefinición de los objetivos El estudio de lo existente ha puesto en evidencia un cierto número de puntos que pueden modificar los objetivos apriorísticos o, al menos, modificar sus prioridades. Esta redefinición de los objetivos se acompaña de la fijación de restricciones o si se quiere, de los ejes de orientación que hay que tener en cuenta. Estas orientaciones son, en este estado, sobre todo, organizativas. 1) Orientación de Gestión Nuevas reglas de gestión. Modificación en el ordenamiento de las tareas.

Reglas de gestión: 1.1) Fórmulas de cálculo: una rebaja promocional no puede ser superior al 50% del margen de beneficio. Rebaja promocional < Margen de beneficio/2 1. 2) Condición de aplicación de las fórmulas: PARA CADA PRODUCTO SI Cant-Pedida > Umbral Rebaja Importe-Factura = Cant-Pedida * PVP * Rebaja Importe-Factura = Acumulado (Importe-Facturado) * Rebaja-Cliente 1. 3) Restricción administrativa de validación. Si el pedido no está asociado a un cheque, es rechazado 1.4) Plazos impuestos por los procedimientos. Pago a proveedores a 30 días

2) Orientaciones de organización. 261

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Elección entre la centralización (la consolidación) o la descentralización (la motivación). Nueva estructura interna : distribución de las competencias, creación de un nuevo servicio. Enriquecimiento de las tareas : por primera vez desde el comienzo de la era industrial, desde el advenimiento del Taylorismo, estamos en situación de invertir el curso ineludible de la distribución del trabajo que iba hacia la especialización a ultranza por la distribución de las tareas. Gracias a las técnicas de Información y Comunicación de Empresa, entre otras, podemos crear puestos de trabajo con responsabilidad de proceso completo. Modificación del circuito de las informaciones. Modificación de los plazos. 3) Orientaciones técnicas Debemos tener también en cuenta los restricciones técnicas : el hardware instalado, el software instalado (BD), el grado de portabilidad deseado, la importancia creciente de la seguridad (la información circula cada vez más , los controles de acceso se convierten en una necesidad igual que la fiabilidad de la información y del servicio).

En situaciones anteriores, la concepción de un sistema estaba ligada sobre todo a aspectos técnicos, que condicionaban el resto. Actualmente la concepción se basa en: 1) Reglas de tratamiento y memorización de las informaciones ( reglas de gestión que condicionan la modelización a nivel conceptual ). 2) Comportamiento de los individuos que, como hemos dicho, tienen la ocasión de abandonar su hiperespecialización para convertirse en responsables de un proceso 3) Estructuras organizativas implantadas, cuyas reglas influirán en el modelo organizativo.

262

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4) Finalmente, elecciones técnicas

b) Concepción de una solución El objetivo de esta fase es, evidentemente, el estudio de una solución tipo ( o de varias soluciones ) que responden a los objetivos y a las restricciones conceptuales, organizativas y técnicas. Vamos a poner en práctica la modelización que hemos visto anteriormente, respetando nuestro principio de separación de los tratamientos y de los datos. Descripción de los Tratamientos : MCT Para comenzar nuestro estudio de lo existente, vamos a elaborar el modelo conceptual de tratamientos. Recordemos que el MCT comprende, no solamente el diagrama de los flujos, sino también la descripción de dichos flujos, de los procesos, de los ficheros (en el sentido de usuario del término) y de los actores. Como su nombre indica, el modelo conceptual de tratamientos, es el reflejo de la esencia de los tratamientos (el QUE, el POR QUE de la existencia del Sistema), fuera de toda restricción organizativa y técnica. Nos vamos a centrar sobre : - Los procesos, desencadenados por la llegada de flujos externos, únicos estímulos verdaderos de nuestro sistema. - Las operaciones que describen las nuevas reglas de gestión. - La circulación y la transformación de flujos en nuestro Sistema. Para concebir un modelo conceptual de tratamientos se parte, ya sea del diagrama de contexto que, de hecho, encubre toda la parte de organización para no revelar más que los contactos del proceso con el exterior, o bien de los procesos de nivel más bajo, los menos cargados de tintes organizativos , de los que se hacen desaparecer:

263

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- las operaciones que hacen referencia a las nociones técnicas (anotar las entradas en stock sobre la lista de los pedidos). - las funciones de control (al comienzo de la operación) o de validación (al final de la operación), que son el reflejo de la organización actual. - la elaboración de listas, de flujos internos que no son transformaciones de flujos externos y que no concurren para dar origen a un flujo que sale de nuestro sistema. Concepción de los tratamientos : MOT Basándose en el MCT, diagrama depurado, reflejo de la esencia del Sistema, de los objetivos fijados y de las restricciones (orientaciones) de organización, vamos a organizar nuestros tratamientos. Esta organización tendrá en cuenta las nociones de quién hace qué, dónde y cuándo. Debemos determinar, primeramente, cuáles van a ser las operaciones a automatizar y Cuáles las que seguirán siendo manuales. A continuación, con respecto a las tareas automatizadas, las que van a interesarnos especialmente, determinaremos su frecuencia y su duración. Finalizaremos este modelo organizativo de tratamientos, con un estudio en profundidad de los puestos de trabajo. ¿ Cómo determinar las operaciones automatizables ? Deben responder a un cierto número de criterios : - El tratamiento debe ser enteramente formulable por un algoritmo (lógico o matemático). Si no es este el caso, tendremos necesidad de la experiencia apropiada para orientar la transformación o la toma de decisión. El tratamiento debe permanecer manual (incluso parcialmente) o se debe prever un SISTEMA EXPERTO. - El tratamiento debe tener una cierta importancia en volumen, en frecuencia o en dificultad. - Las informaciones que tratan deben ser identificables y memorizables en un soporte informático. Si la operación requiere un tratamiento sobre texto libre, debemos recurrir a las técnicas de Información y Comunicación de Empresa, integradas o no en el sistema informático implantado, o a la inversa, si el sistema informático no es más que una parte del sistema ofimático.

264

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Debe existir un m quina capaz de realizar el tratamiento con costes rentables. Contrariamente a lo que algunos profesan, si bien todo es posible en informática, no todo es deseable. ¿Cómo determinar la frecuencia de la operaciones? Los criterios a tener en cuenta para determinar la frecuencia de las operaciones, es decir, para distribuir las operaciones entre el tiempo real (transaccional o interactivo) y el tiempo diferido son los siguientes: - El grado de urgencia en la información del acontecimiento que desencadena la operación. - La automatización posible de las decisiones. Si estas forman parte parcialmente de las competencias de la persona, la operación solo puede realizarse en tiempo real, ya que depende de la intervención humana. - El grado de urgencia de la reacción en caso de anomalías. Los criterios de las dos listas no son independientes, sino que su combinación es la que nos va a permitir escoger. Por ejemplo:

Totalmente automatizable SSNN Urgente SNSN ------------------------------------------------------Transaccional X XX Tratamiento batch X

Hechas estas elecciones, debemos elaborar el modelo organizativo de tratamientos, que va a retomar: - El diagrama de flujos , revisado incluir las opciones organizativas que hemos tomado. Esto puede traducirse por la creación de flujos (internos) suplementarios : una operación se descompone en tareas( unidad organizativa de los tratamientos) realizados por puestos de trabajo diferentes. Se llamar TAREA a todo trabajo efectuado sin interrupción, por una persona, en un entorno determinado. Es la unidad organizativa de tratamiento.

265

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Debemos llamar la atención sobre los límites del diagrama de flujos para representar una organización : se ve bien la circulación y la transformación de las informaciones (los flujos); no se ven los agentes internos (que efectúan las tareas) y no se tiene noción de tiempo. El diagrama de flujos no da ninguna indicación del tiempo y el espacio. Debemos completar los aspectos organizativos tales como los agentes internos, el desencadenamiento de las operaciones, su dependencia y encadenamiento. Podemos recurrir también a otro modelo que permite representar de manera matricial las operaciones y sus flujos. En esa matriz vamos a representar la sucesión de las operaciones y el paso de la información (por medio de los flujos) entre los distintos agentes internos a nuestro Dominio (o por lo menos al SCR que hemos escogido). Esta matriz es puramente organizativa y no ser útil para la informatización. Sin embargo es importante para un proyecto ofimático. Se puede modelizar también la sucesión de las operaciones en un diagrama de Gantt o en un diagrama PERT. Es muy útil para estudiar la duración de los tratamientos. La noción de acontecimiento, piedra angular del Método MERISE (elaborado bajo los auspicios del Ministerio de Industria francés), es puramente organizativa. Lo utilizaremos para simular una organización, con un instrumento como IDA. Se puede hacer figurar esta organización sobre el diagrama de flujos, a nivel de organización, o en la descripción de las operaciones (especificaciones) - La descripción: especificación de las operaciones, descritas en pseudo-código. Esta especificación se acompaña de la descripción de los flujos.: El diseño de las pantallas o, más bien, la descripción de su contenido. El diseño de los documentos o, más bien, la descripción de su contenido. Estas descripciones se hacen sin tener en cuenta las restricciones técnicas, es decir, que podemos definir pantallas y documentos de

266

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

tamaño ilimitado. La subdivisión se hará en el Estudio Técnico, mucho más próximo a la máquina. - El estudio de los puestos de trabajo: el tipo de terminal necesario para que se cumplan las operaciones en tiempo real, así como la Cualificación del personal. - No hay que olvidar el aspecto seguridad, ya sea el funcionamiento de manera degradada, estudiando los riesgos que una parada de la m quina puede ocasionar, o la salvaguarda de las informaciones. - Finalmente, cuantificaremos los resultados esperados del sistema que acabamos de concebir, ya sea por las tareas manuales o automáticas. Este estudio cuantitativo se basa en las cifras recogidas al comienzo del trabajo: la frecuencia de los flujos, la duración de los tratamientos, los recursos disponibles. Si la llegada de los flujos es aleatoria, lo que suele ocurrir generalmente, ser necesario un instrumento de simulación, porque ser preciso tener en cuenta las colas de espera. Este estudio tiene por objeto definir el número de puestos de trabajo necesarios, terminales y personas. * Modelización de los datos: MCD Paralelamente a la concepción de una nueva organización de los tratamientos ( que es el objetivo del estudio de los tratamientos, del que el MCT no es más que un paso obligado), debemos estudiar el modelo conceptual de datos. No seremos exhaustivos, pero trataremos de que sea bastante significativo para poder bosquejar un estudio cuantitativo (modelo lógico) de los volúmenes y de los accesos. Creemos útil recordar, que el objetivo del Estudio Previo es saber a dónde se va. Es preciso, pues, estudiar nuestro sistema de manera cuantitativa. Nuestro modelo conceptual de datos lleva consigo: - El Modelo entidad-relación. - El diccionario de los datos que recoge la descripción de todos los atributos. - Los datos cuantitativos sobre las entidades y las relaciones.

267

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Concepción del modelo lógico de datos: MLD El modelo conceptual, que es la red semántica de las informaciones útiles a nuestro organismo, comprende todas las informaciones. El modelo lógico, que es la vía "informatizable" del MCD, puede ser depurado de las informaciones no concernientes más que a los tratamientos manuales (lo que es cada vez más raro). Nos limitaremos a estudiar aquí los accesos necesarios y a valorarlos, calculando el coste. Mediremos también el volumen necesario para memorizar todas las informaciones. Señalaremos que esta medida no se puede hacer más que teniendo en cuenta las técnicas de implantación. c) Estudio de los PUESTOS DE TRABAJO Llamaremos PUESTO DE TRABAJO a los conocimientos y equipos necesarios para realizar una operación, un conjunto de tareas. Vamos, pues, a revisar por operación (o por proceso) : - Los conocimientos necesarios para la puesta en marcha, la ejecución y realización de cada operación. Este inventario nos llevar a definir un plan de información y de formación al personal implicado. - Los procedimientos necesarios para cumplir las tareas : es la base del nuevo cuaderno de procedimientos. El Hombre debe situarse en relación a la máquina. - El equipamiento del puesto de trabajo : un terminal informático, un micro, un material gráfico, un puesto ofimático dedicado (tratamiento de texto, por ejemplo). Se puede terminar este estudio con una síntesis de los equipos : ¿Cuáles son los perfiles profesionales y servicios equipados, de cuantos puestos se dispone ?. Esta recapitulación permite detectar los sobre o sub equipamientos, debidos a los privilegios de algunos servicios o perfiles profesionales. En principio, es la carga de trabajo, estudiada en otra parte, y el reparto geográfico, que vamos a estudiar, lo que debería condicionar el equipamiento. d) Estudio de los SERVIDORES

268

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La noción de SERVIDORES permite estudiar la distribución de los datos y los tratamientos sobre los diferentes puestos de trabajo potenciales, teniendo en cuenta las funciones y los costos. Un puesto de trabajo puede ser modelizado como sigue :

Nos interesar n tres tipos de SERVIDORES : los servidores de datos, que permiten el almacenamiento de la información; los servidores de aplicaciones, que permiten la captura, transformación y restitución de la información; y, finalmente, los servidores de acceso , que permiten el transporte y el acceso a la información.

Estos servidores están en estrecha relación entre sí y con los puestos de trabajo .

Servidores de Datos La distribución de los datos se debe hacer teniendo en cuenta diversos criterios : - El tipo de información: Descentralizaremos los datos si: 269

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- No se utilizan más que en un solo entorno. - El control de validez de las informaciones esta bajo responsabilidad local. - Los ficheros son sencillos y de utilidad local, incluso si se consolidan de vez en cuando desde el puesto de trabajo central. - La tasa de modificación es demasiado elevada para un tratamiento centralizado. - El usuario emplea extractos de bases de datos centrales. Por el contrario, centralizaremos los datos si : - Se utilizan por un servidor de aplicación centralizada. - Se ponen frecuentemente al día y los usuarios, distribuidos por diferentes puestos de trabajo, tienen necesidad de información reciente. - Los usuarios se desplazan de un sitio a otro. - Se requiere un alto nivel de seguridad. - El sistema debe ser controlable por los Auditores. - La motivación : la descentralización es un potente factor de motivación del personal , que se siente más responsable. - El coste, no solamente del dispositivo de almacenamiento y de tratamiento asociado, sino también del coste de transporte de transformación y de la seguridad (salvaguarda realizada desde el puesto de trabajo). Los Servidores de Datos se reagruparan por puestos de trabajo en función de su objetivo común (por ejemplo, los datos necesarios para la Gestión de las Cuentas de los Clientes). Debemos estudiar varias propiedades de estos servidores : a) El tipo de datos que contienen: datos Cualitativos (puramente informáticos), textuales, gráficos u otros (audio, video, etc.). b) El uso que se hace de los datos memorizados : uso operativo, histórico o previsor. c) El referencial al que pertenecen los datos : empresa, departamento o colectividad (dedicados a un perfil profesional, a una profesión y a un circulo de usuarios). Los datos de tipo puramente personal no nos interesan. Entendemos por informaciones personales, no "el cuadernito en la que se anotan personalmente informaciones", sino, más bien, las

270

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

informaciones que se podrían perder sin impactar la buena marcha del departamento, o de la empresa. La utilización de la informática puede ayudar a la memorización y al tratamiento de las informaciones personales, pero sin convertirse en una restricción. Si todo es posible, no todo es deseable. d) La seguridad requerida por las informaciones: el aspecto confidencial, el carácter legal. Destaquemos que la descentralización de los datos sobre diferentes puestos de trabajo requiere una función de salvaguarda sobre cada uno de los referidos puestos. e) El volumen de datos en cada puesto de trabajo. f) La referencia a los otros servidores : ¨Cuáles son las aplicaciones que utilizan estos datos, y como se accede a ellos desde todos los puestos que lo necesitan?. El ordenador personal en una herramienta a destacar, porque puede cumplir las funciones de puesto de consulta, de captura, y además recuperar también informaciones temporales (transferidas como consecuencia de una petición) y convertirse en un servidor de datos y de aplicaciones para las operaciones particulares, sobre todo las operaciones de ayuda a la decisión. Servidores de aplicaciones Estudiaremos la distribución de las aplicaciones en los diferentes puestos de trabajo. Este estudio conlleva: a) La descentralización de las aplicaciones en relación con la descentralización de los datos. Téngase en cuenta que la aplicación (la ejecución de la operación) puede estar en un puesto y los datos en otro. El transporte de un puesto a otro se hace por transferencia de fichero o por consulta a dos niveles.

b) El volumen del tratamiento en transacciones por día. Atención: si los servidores de datos están distantes de los servidores de Aplicaciones, hay que tener en cuenta el volumen de las informaciones transportadas. c) Las relaciones entre los diferentes servidores: cómo acceder a las aplicaciones y a los datos.

271

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Los servidores de acceso Si los datos o las aplicaciones se descentralizan, debemos estudiar los servidores de acceso, que, como su propio nombre indica, permiten acceder a las aplicaciones y a los datos, a partir de los puestos de trabajo. Estudiaremos particularmente: a) El tipo de red (RLE,RLD, Externa) b) La tecnología utilizada (velocidad, protocolo, sesión, transporte, presentación, etc.). c) Las relaciones con los otros servidores, con los actores; todo ello cuantificado en volumen y consumo :

C) SINTESIS DEL ESTUDIO Se dispone de una o varias soluciones tipo para el subconjunto representativo que hemos escogido. Dichas soluciones abarcan aspectos conceptuales, organizativos y físicos (los servidores). Por extrapolación, y es aquí donde la elección del SCR es importante, vamos a sacar conclusiones sobre nuestro futuro sistema: ¿ Qué escenario de puesta en marcha y de explotación elegir, en función de los costes, de los objetivos, de las necesidades y de la motivación de los ejecutores? El objetivo final de esta síntesis es la redacción de un cuaderno de especificaciones que recoge: - la trayectoria a seguir para llevar a término el proyecto, o cómo pasar de la situación existente a la situación futura. Es el PLAN DE ACCION. - el estudio cuantitativo y Cualitativo del proyecto: el balance de nuestro estudio, los costes y los beneficios esperados. El Estudio Previo se cierra con la REVISIÓN del producto concebido, que conduce a la elección definitiva por parte de la Dirección, la decisión de proseguir el proyecto, de modificarle o de abandonarle.

272

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

a) El estudio de la trayectoria Subdivisión en aplicaciones Recordemos que el estudio previo abarca un dominio completo (ej. Ventas). Es preferible (siempre que sea posible) subdividir este dominio en aplicaciones y poner en funcionamiento las diferentes aplicaciones por separado. ¿Por qué? - Cada Aplicación es un subconjunto coherente que puede llevarse a término independientemente de las otras Aplicaciones : el fracaso de un proyecto no tiene que tener influencia sobre los otros. - Cada aplicación puede corresponder a una fase particular de la evolución del Organismo : la trayectoria se subdivide en diversas etapas, aportando cada una un nivel de servicio y una transición en el paso del sistema existente al sistema futuro. - Cada etapa tiene su propio plan financiero, lo que permite distribuir los presupuestos y adquirir progresivamente el material necesario. - La subdivisión permite fragmentar el problema y , por tanto, simplificarlo. Sin perder de vista que una partición excesiva del problema engendra una dificultad en sí misma : la multiplicación de las interfaces que realizar, para convertir el sistema en algo coherente . En nuestro caso esta multiplicación tendría como resultado un número inaceptable de estados transitorios, que necesitarían frecuentes controles del sistema, lo Cuál dificultaría su operatividad. - La subdivisión debe tener también en cuenta el factor humano: un proyecto no puede durar más de 8 meses ni emplear más de 7 personas. A menudo es más fácil subdividir a nivel del Estudio Detallado, que es la continuación del análisis.

Fijación de las prioridades Cuando se ha subdividido el dominio en aplicaciones, que ser n objeto de un estudio detallado, debemos fijar las prioridades de puesta en marcha de estas aplicaciones. Debemos recordar que si el personal se resiste al cambio, es preciso tener el recurso de un proyecto piloto, que servir de escaparate, de publicidad al conjunto del dominio . 273

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las prioridades se fijan teniendo en cuenta factores tales como: - La motivación del personal, el interés de la Dirección, no solamente en función de criterios objetivos como los beneficios obtenidos o el nivel de servicio alcanzado, sino también en función de criterios subjetivos como el carácter publicitario o la imagen de marca. - No hay que perder de vista los riesgos que el proyecto puede hacer correr al Organismo. Cualquier proyecto que tenga el favor de la Dirección, es un proyecto realizado ya a la mitad. Tendremos igualmente en cuenta otros factores, como la novedad de la aplicación, del material, e incluso el riesgo , no solo de la realización sino de la explotación : la reacción del personal, la reacción de la clientela, la dificultad de pasar de un sistema (antiguo) a otro (nuevo), en función de los volúmenes, entre otros. Etapas transitorias Para ir de un punto a otro hay varios caminos posibles. Cada uno de esos caminos constituye una trayectoria que parte de la situación existente y llega al objetivo. El conjunto trayectoria-objetivo forma un escenario. Debemos estudiar la trayectoria ideal y las etapas que la componen. Este estudio lleva consigo : - Las interfaces necesarias para pasar de una etapa a otra, la estabilidad necesaria y suficiente de los tratamientos y de los datos, en una etapa determinada. - El material necesario para cada etapa, así como los recursos que requiere, tanto de equipamientos como de conocimiento y formación del personal. - Los nuevos circuitos de información, los nuevos procedimientos, incluso si la situación es provisional. Todo debe planificarse cuidadosamente y darse a conocer a los interesados lo más rápidamente posible: la improvisación no es aconsejable. La diferencia entre un profesional y un aficionado se mide por la preparación. El profesional toma las medidas necesarias para tener éxito, pone todos los triunfos de su lado. No hay que olvidar nunca la primera ley de la gestión de proyecto : ¡ Si algo debe ir mal... irá mal !

274

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Debemos considerar en cada etapa la situación del estado actual, el direccionamiento hacia el nuevo sistema. Esto nos obliga a reflexionar sobre tres puntos : - La situación de lo existente, la transformación de los datos, de los soportes, con control de verosimilitud de los datos transformados. El control debe hacerse ANTES de la transformación. - La puesta al día de todos los datos en tránsito, para tener una situación estable. Pensemos, particularmente, en las cuentas de los clientes, en los almacenamientos, etc. - Asegurar la última parte. Si es posible, recurrir a una explotación por partida doble, con todos los problemas que esto conlleva. De Cualquier modo, asegurar que no se interrumpir el servicio. Juegos de Ensayo No es el servicio informático el que decide si el proyecto está terminado, si el producto es explotable, sino los usuarios. Es preciso poner a punto un protocolo de recepción del producto, lo que se llama el ensayo. Se fijaran pronto las modalidades, los cambios que harán que todo se transmita correctamente. Los juegos de ensayo (que son una guía apreciable para tener una idea clara del uso del producto) llevan el procedimiento de recepción propiamente dicho, las alternativas en caso de fallo. Planificación del proyecto Cuando el objetivo del proyecto está claro, cuando los riesgos y la adaptación del proyecto en curso han sido evaluados, cuando se ha realizado la división en fases, el Gestor del Proyecto establece su planificación, constituye su equipo, hace el inventario de los recursos necesarios y calcula el coste directo del proyecto de realización. Todas estas operaciones, que forman parte del Ciclo de Decisión, se facilitan por el empleo de un útil. El buen término de un proyecto, depende del rigor del Gestor de Proyecto, no solamente en la realización de su planificación, sino también en el SEGUIMIENTO eficaz del proyecto. Pero esta es otra historia, como diría Kipling. b) Balance - Cuaderno de especificaciones

275

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El cuaderno de especificaciones, que es el documento final del estudio previo, no es más que un recordatorio, una guía para el usuario y la dirección, puesto que han estado implicados durante todo el estudio. No obstante, la presentación del cuaderno de especificaciones debe cuidarse, sobre todo si trasciende el ámbito de la empresa, con vistas a un estudio sobre el coste del material complementario, o para toda o parte de la realización. Este documento no debe ser voluminoso porque nadie lo leería con interés. Es una síntesis del trabajo, no un Análisis en profundidad. No es necesario añadirle el contenido completo del diccionario (pensemos en la lista de los atributos) para hacerle importante.

Debe comprender: 1) Los elementos de decisión claros y concisos : la síntesis de las cifras, los costes, los beneficios y la planificación. 2) Para cada capítulo en detalle, una breve presentación, los elementos importantes y una conclusión. Estos capítulos son: - El objetivo definitivo. - Las restricciones y las orientaciones. - El marco general del dominio, su lugar en la Empresa, su diagrama de contexto y los circuitos de información entre los diferentes dominios. - La explicación de la elección del SCR. - El modelo conceptual de tratamientos ( el diagrama de flujos, acompañado, si es necesario, de las reglas principales de gestión ). - El modelo organizativo de tratamientos : las operaciones que hay que automatizar y, si se quiere, una reducción del coste para la realización del proyecto, la descripción de las diferentes operaciones, con la descripción de los flujos. - El modelo conceptual de datos ( el modelo entidad-relación y, eventualmente, la lista de los atributos más significativos ). - El modelo lógico de datos, las medidas de acceso y de volúmenes. - La descripción de los puestos de trabajo, con los conocimientos requeridos y los procedimientos a seguir para cada perfil profesional, si fuera necesario.

276

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- La descripción de los servidores, importante para una entrega de oferta, menos importante para una información interna. - El estudio de la trayectoria, con el plan establecido por el Gestor del proyecto. La descripción de las etapas de transición, la estimación de la carga (en persona/mes) con tasación en el tiempo. D) CONCLUSIONES Falta ahora que los licitadores remitan una oferta completa, valorizada, y, después, que la Dirección determine acerca del proyecto: - Rechazarle por demasiado costoso para el servicio que rinde, demasiado riesgo en el contexto actual. - Realizarle total o parcialmente por personal interno o externo. - Escoger un paquete existente en el mercado después de un estudio de compromiso entre las necesidades detectadas y las posibilidades del producto. -Reemprender el estudio previo sobre nuevas bases, con un nuevo objetivo más modesto o, por qué no, más ambicioso. Esta decisión no interviene nada más que después de una revisión general del producto basada en: a) La exposición general de la solución elegida: el objetivo que trata de alcanzar, el plan de acción (planificación de realización y de implantación), los costes y los beneficios.

2014 1. Beneficios esperados -Recuperación de créditos -Reducción de devoluciones 2. Costes -Gastos de desarrollo -Gastos de mantenimiento -Gastos de formación -Gastos de funcionamiento 277

2015

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Materiales - Terminales/micros - Gastos de conexión -Gastos de operación - Alquileres - Suministros - Revisiones 3. Márgenes 4. Márgenes acumulados

b) La crítica de la solución, por una comisión independiente, que tiene como finalidad: - supervisar el cumplimiento del objetivo previsto, - validar las funcionalidades, - verificar la factibilidad y la rentabilidad del proyecto. Dicha comisión estudia los riesgos del proyecto. Establece un informe por cada riesgo reconocido, con: -la naturaleza del riesgo (objetivo, marco, tecnología, experiencia, etc.). - riesgos, - consecuencias, - recomendaciones. Los riesgos se clasifican en moderados, mayores e inaceptables. Se puede sistematizar el estudio de los riesgos de un proyecto, poniendo en práctica las teorías de Mc.Farlan. c) La decisión propiamente dicha sobre el porvenir del proyecto, que no tendrá lugar hasta que el grupo del proyecto haya respondido a las "acusaciones", presentando las acciones correctivas.

278

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

9.3

ESTUDIO DETALLADO

El estudio previo nos ha permitido obtener una idea global y general del dominio seleccionado. El estudio detallado va a afinar este estudio para una aplicación particular, vista en conjunto. La duración del estudio detallado depende grandemente de la profundidad del estudio previo. Sin embargo, tendremos que terminar aquí los modelos de datos y tratamientos para poder validar nuestras elecciones. En ningún caso, y por las razones ya mencionadas, nos atrincheraremos detrás del estudio previo para congelar el Análisis : Tenemos que gestionar el cambio. Por esta razón continuaremos implicando a los usuarios, entrevistándolos, haciéndoles validar nuestras elecciones, mostrándoles el sistema vivo (prototipaje evolutivo de validación). El estudio detallado es, de hecho, la fase de concepción del nuevo sistema que interesa al usuario. La fase de concepción volcada hacia los especialistas informáticos ser el estudio técnico. Les reservaremos capítulos distintos, aunque sea más práctico tener a ambos a la vez. Esto permitir ocupar a los informáticos de forma más uniforme, hacerles participar en el estudio, implicarles. Hay que evitar, sin embargo, lanzarse a la programación mientras subsisten incertidumbres. Como dice David Parnas," las incertidumbres deben quedar aisladas en módulos particulares". El trabajo de los especialistas informáticos, durante el estudio detallado, consistir en confeccionar módulos que se ensamblen en programas, diseñar pantallas, componer documentos, etc. Nuestro estudio detallado conllevar las siguientes fases específicas: - Estudio de lo existente. De hecho esta no es una fase en sí, dado que el analista nunca abandona el contacto con el usuario, afinando progresivamente su visión de la aplicación estudiada. - La elaboración de los modelos conceptual y organizativo de tratamientos, con la descripción detallada de las distintas operaciones. - La elaboración del modelo conceptual de datos, modelo completo con el censo de todos los atributos. - Validación del modelo conceptual de datos a partir de los flujos transformados por tratamientos.

279

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Preparación de los planes de acción para la realización y la puesta en marcha del sistema. Poco tenemos que añadir sobre las diferentes etapas que ya habíamos descrito. A) ESTUDIO DE LO EXISTENTE Y DE LAS NECESIDADES El objetivo del estudio de lo existente y de las necesidades, es conocer la aplicación que se va a estudiar. Este estudio empieza por los documentos que se puedan reunir (estudios, flujos, etc) y, a continuación, por contacto directo con los usuarios a los que se entrevista. ¿Qué hay que obtener de las entrevistas? - La situación actual en materia de transformación de informaciones, en materia de tratamientos. Esta situación se modeliza mediante diagramas de flujos que constan de cuatro componentes: - Los flujos o mensajes - Los procesos - Los ficheros - Los agentes La situación actual refleja la organización en cuestión. Por consiguiente elaboraremos el MOT de lo existente, con los acontecimientos desencadenantes, el encadenamiento de tratamientos, los agentes internos. El diagrama de flujos debe verse como una herramienta de comunicación, por lo que debe dibujarse muy rápidamente, delante del usuario, para que este lo valide inmediatamente. Después se lo remitiremos para obtener su confirmación. Después de una serie de entrevistas (con diferentes personas), se establece un diagrama de flujos global, que se presenta en una reunión plenaria. Si es posible establecer un diagrama de contexto de la aplicación, las entrevistas podrán ser llevadas a cabo sistemáticamente, siguiendo la transformación de cada flujo.

280

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- El inventario de datos necesario para la aplicación. Los datos se extraen, principalmente, de los documentos y las entrevistas. Por el contrario, las restricciones, los dominios de valor asociados a los atributos, las conectividades, se obtienen mediante encuestas. - Las reglas de gestión. - La descripción de procedimientos, conocimientos, etc, necesarios para ejecutar correctamente las operaciones de transformación de los flujos. No se pretende informatizar lo existente, sino concebir un nuevo sistema, que aporte algo más, que mejore la calidad del sistema actual. Obliguemos a que se nos explique el porqué de ciertos procedimientos, sobre todo de aquellos que parecen complejos. Puede que estos reflejen una situación a la que se ha llegado a fuerza de compromisos y que nadie ha pensado revisar. ¡ Reflexionad sobre ello ! B) MODELO CONCEPTUAL DE TRATAMIENTOS La razón de ser de las cosas nos lleva a establecer el modelo conceptual de tratamientos, que refleja las acciones realmente necesarias para realizar un proceso, sin hacer referencia a la organización existente o a la técnica general presente. Este estudio permite construir el diagrama de contexto de la aplicación y, a partir de este, remontando los flujos, descomponer los tratamientos en transformaciones elementales. Se parte de los flujos salientes para determinar las transformaciones necesarias. La partición nos da, por una parte, diagramas de flujo a varios niveles, si bien solo se documentaran los niveles elementales, y, por otra, un diagrama de descomposición que es una ayuda para descomponer nuestra aplicación en proyectos aplicativos, partes más pequeñas, unidades de realización. C) MODELO ORGANIZATIVO DE TRATAMIENTOS A partir del modelo conceptual de tratamientos, que describe lo que hay que hacer, deduciremos el modelo organizativo de tratamientos, que define: - Los puestos de trabajo, las diferentes tareas a acometer por las personas. Cada puesto de trabajo se define por una operación y los flujos que manipula: la descripción de esta operación se consignar 281

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

en el cuaderno de procedimientos, que describe las reglas de trabajo. Este es el documento organizativo que describe la visión del sistema por parte del usuario. El estudio de los puestos de trabajo debe tener en cuenta un conjunto de factores, desde los costes de explotación, la motivación, el rendimiento, la ergonomía, la mejora de la calidad de trabajo: hacer mejor en lugar de hacer más , es el objetivo de la responsabilización. - Los flujos que deben ser modificados, no solo desde el punto de vista de su contenido, sino también de la ergonomía, de la circulación, del soporte. Tendremos que estudiar, asimismo, su frecuencia, su volumen, su seguridad, el tiempo que tarda el organismo en reaccionar desde su llegada. Todo este estudio puede hacerse simulado, si se dispone de un útil. - Los tratamientos que hay que describir (especificaciones) en términos claros, preciso y concisos. En esta fase se clasifican los tratamientos, en tratamientos manuales, automatizados, parcialmente automatizados, en tiempo real o en tiempo diferido. Hay que comentar que el estudio de tratamientos y la circulación de flujos, puede realizarse con ayuda de un diagrama de GANTT o uno de PERT, que permiten demostrar la sucesión de operaciones, las elecciones entre ellas y su duración. Pero estos diagramas solo proporcionan una visión está tica de la situación, no permitiendo modelizar situaciones en las Cuáles los acontecimientos (llegadas de flujo) son aleatorias y crean taponamientos. D) MODELO CONCEPTUAL DE DATOS Ya hemos dedicado un largo capítulo a su elaboración, por lo que nos remitiremos a él. E) VALIDACION DEL MODELO CONCEPTUAL DE DATOS Por definición, el modelo conceptual de datos se desea global y estable. Se trata de una red semántica de informaciones que el organismo necesita para funcionar. A menudo la realidad queda lejos de este objetivo. Vamos a estudiar ahora si el modelo es capaz de construir todas las informaciones necesarias, según las necesidades actuales. 282

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Por otra parte, la información no se crea, solo puede transformarse. Estudiaremos si verdaderamente esto es así, es decir, si las informaciones necesarias para construir los flujos de salida están presentes en los flujos de entrada, o en la memoria colectiva del sistema. El objetivo de esta primera validación (a nivel conceptual), es asegurarse de la presencia de la información con un sentido de equivalencia, y de la posibilidad de identificarle. Estudiaremos, finalmente, si las informaciones memorizadas viven, nacen (son creadas), se transforman (son modificadas), se utilizan (se consultan), y mueren (son suprimidas). La validación el MCD se realiza por operación, flujo por flujo. Utilizaremos para ello una de las propiedades de los flujos, su capacidad de transformarse en modelo entidad-relación. Llamaremos esquema o modelo externo, a la representación de un flujo bajo la forma entidad-relación. Por flujo nos referimos, no solamente a los que circulan entre procesos, sino también a los que se memorizan, a los que provienen de ficheros. Empezaremos por los flujos complejos, los que tienen más posibilidades de requerir una modificación del MCD, ya que por cada cambio realizado, hay que revisar el trabajo desde el principio y replantear las cuestiones correspondientes al objeto del MCD, que hemos modificado. Para ello se guardar la matriz de la utilización de entidades por cada operación. Los controles a efectuar son: a) El atributo tiene que existir. Si procede de un cálculo, tienen que existir los términos de la operación. b) El atributo debe ser identificable. Si pertenece a una entidad, tenemos que conocer el identificativo de la misma. Si pertenece a una asociación, las entidades que enlaza tienen que ser identificables. c) Las ENTIDADES del modelo externo son correctas si son correctos los atributos que las componen (ver las reglas precedentes).

283

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

d) Una RELACION portadora de atributos es correcta si los atributos que la componen respetan las reglas precedentes, y si las ENTIDADES que enlaza son v lidas. e) Una RELACION vacía es correcta si las ENTIDADES que enlaza son v lidas y si existe en el MCD una RELACION que tenga el mismo sentido. f) Las conectividades del modelo externo son correctas si está n incluidas (en el sentido matemático del término), en las conectividades del MCD. Si el MCD es:

Ell modelo externo siguiente contiene conectividades erróneas :

Porque si bien la conectividad (1,n) es deducible de (1,1)U(1,n), la conectividad (0,n) no es válida porque no es deducible de la unión (1,n)U(1,n), que da (1,n). F) CONCLUSION DEL ESTUDIO DETALLADO

284

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El estudio detallado no es una fase en el sentido pleno del término. Contrariamente al estudio previo, este estudio no termina con la producción de un documento. En ella no hacemos más que enriquecer el diccionario de datos. La documentación ser generada al final de la siguiente etapa: el estudio técnico. Sin embargo, tenemos que preparar planes de acciones. - Informar al personal implicado por los cambios organizativos y técnicos (nuevos hábitos de trabajo y nuevo material) Nota: Los mandos que han participado en el estudio fueron informatizados por una nota enviada por la dirección, al comienzo del estudio previo. - Montar un plan de formación sobre la utilización del nuevo sistema. Este plan de formación debe ir acoplado con la redacción de la documentación, que puede comenzar después del estudio técnico, antes de la fase de realización. - Poner a punto juegos de ensayo. El servicio del usuario ya fue avisado, al final del estudio previo, que tenía que preparar un juego de ensayo y poner a punto un protocolo de recepción. Todo esto tiene que estar preparado desde este momento. - Interesar de antemano en los medios para poner en marcha nuestra aplicación. A partir de ahora se ir n escribiendo módulos de programa. Al final del estudio técnico, cuando intervenga la descomposición en programas, podrá comenzar la realización. ¿ Con qué recursos humanos ? ¿ Sobre qué maquina ? ¿ Con qué herramienta ? ¿ En qué entorno ?. Ahora es el momento de responder a estas cuestiones, que son, de hecho, de la incumbencia del gestor del proyecto. Nota: VALIDACIÓN de trabajos. - Todas las conclusiones que extraemos de las entrevistas, es decir, nuestro trabajo de concepción, deben estar validadas por los usuarios, reunidos en un grupo de validación, constituido desde el principio del proyecto, y que siga su desarrollo hasta la recepción del producto acabado. Este grupo validar el aspecto conceptual y organizativo del análisis. - Antes de las reuniones de validación, el analista debe someter su trabajo a la opinión de otros analistas, acompañados eventualmente del responsable de estudios y métodos. Esta reunión tiene por 285

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

objeto controlar el aspecto técnico y asumir colectivamente el fruto del trabajo efectuado.

286

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

9.4

ESTUDIO TÉCNICO

Ya hemos concebido y validado la nueva forma de organización del trabajo de los usuarios. Nos queda concebir la implantación de esta organización sobre el material escogido. Es lo que llamaremos estudio técnico, que ya está muy próximo al trabajo de programación. A pesar de este aspecto técnico, no debemos olvidar al usuario, con el fin de poder reaccionar rápidamente ante cualquier cambio en las necesidades, antes de que la modificación nos cueste muy cara. Para ello, con ayuda de una serie de prototipos, no desechables sino reutilizables, le mostraremos el futuro producto. Serán los prototipos experimentales (para asegurarse de los resultados) y los prototipos evolutivos (para validar la ergonomía y las funcionalidades). Para todo lo demás, el usuario tendrá que ponerse en manos del analista ya que, normalmente, no tiene competencias técnicas. En el estudio técnico realizaremos: a) Los modelos lógico y físico de datos, que son inseparables, como lo son los modelos conceptuales y organizativos de tratamientos. b) El modelo operativo de tratamientos, que comprende la Subdivisión en programas, el diseño de pantallas y documentos, y que termina con la elaboración de un cuaderno de realización. Durante este estudio, el analista busca qué módulos de programas son reutilizables, es decir, aquellos que aparecen en varios programas. Estos módulos quedan confiados a un equipo que los desarrolle y examine independientemente. Esta búsqueda es muy importante para asegurar un mantenimiento satisfactorio del sistema; no puede ser hecha por otra persona distinta el analista, ya que es el único que tiene una visión global del sistema. A) MODELOS DE DATOS : MLD y MFD Ya se han descrito las operaciones a realizar en la concepción de estos modelos. Recordémoslas brevemente : a) Estudio de accesos Esta operación es muy importante: 287

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Permite determinar todos los caminos de acceso necesarios para la realización de los tratamientos. No quedar lugar para la réplica durante la realización: los caminos potenciales existen realmente. El programador no debe plantearse preguntas. - Permite dar directrices de optimización para disminuir el coste de los accesos. El estudio del coste puede dar lugar a la creación de nuevos caminos (claves secundarias). - Permite describir las primitivas de acceso lógicas, cuyo objetivo es independizar los tratamientos de la técnica de implantación de los datos. Esta forma de trabajar va a reducir considerablemente los costes de mantenimiento y evolución del producto.

b) Reparto de datos por servidores Los datos pueden estar repartidos entre varios servidores. Este reparto provoca el desmembramiento del modelo lógico en varios submodelos. El conjunto debe permanecer coherente, desde un punto de vista semántico, con el modelo conceptual que constituye su referencia. El reparto de datos da origen a un estudio (ya abordado) de servidores de datos, de tratamientos y de accesos. c) La transformación del modelo: el MFD El objetivo de nuestro Análisis es producir un sistema automatizado de tratamiento de las informaciones. Esta automatización pasa por la implantación, sobre una m quina, del modelo de datos. Denominaremos a este modelo modelo físico de datos. Se presenta bajo la forma de un conjunto esquema/subesquemas CODASYL, o un modelo relacional, o como un conjunto de ficheros clásicos. Cualquiera que sea su forma, este modelo se obtiene por transformación sistemática del modelo conceptual, del modelo entidad-relación. d) Optimización del modelo físico

288

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El estudio de accesos nos había dado las directrices de optimización que aplicaremos sobre el modelo físico. Estas optimizaciones, índices secundarios, redundancias, reagrupamientos, clusterización, etc, dependen completamente del modelo de implantación, por lo que quedan fuera de este curso. Las optimizaciones tienen que respetar el aspecto semántico del modelo conceptual de datos. e) Primitivas de acceso físicas Hemos elaborado, en una etapa precedente, las primitivas de acceso lógicas. Vamos a transformarlas en primitivas de acceso físicas, módulos de programa, teniendo en cuenta: - la optimización ya realizada - las restricciones de integridad referencial que se derivan de la transformación del modelo. Estas primitivas deben respetar las reglas de modularidad: - tener interfaces simples y documentadas - no acordarse de una ejecución precedente. Esta propiedad de los módulos exige un esfuerzo particular para la gestión de los registros COURANTS (CURRENCIES en CODASYL y CURSORS en SOL). B) MODELO OPERATIVO DE TRATAMIENTOS Este modelo es la base de la programación: deber contener todas las informaciones necesarias para la realización. Pero no hay que olvidar que es un modelo, es decir, un útil de comunicación y de estudio (para el programador), por lo que tendrá que ser redactado con esmero y ser elaborado dentro de las reglas de la comunicación: claridad, coherencia, precisión y concisión. Es la síntesis del trabajo de concepción. a) Subdivisión en programas Hasta ahora no hemos hablado nada más que de tratamientos, procesos, operaciones y tareas (nivel organizativo), o funciones primitivas (nivel conceptual). Tenemos que transformar todo esto en

289

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

nociones más físicas, más aptas para ser automatizadas: en programas y módulos. En principio, una operación dar lugar a un programa, o a un encadenamiento de programas, formando una transacción. Pero no hay reglas estrictas de transformación: podemos decir que un programa es un conjunto de tareas, que se realizan sin ser interrumpidas por un flujo interno, lo que coincide con la definición de operación. Un programa está compuesto por un conjunto de funciones primitivas, descritas en el diccionario, en forma de gráfico, fórmulas matemáticas, tablas de decisión o pseudo-código. El modelo físico de tratamientos va a describir cómo se encadenan sus funciones primitivas. Esta representación existía ya en los niveles superiores del diagrama de flujo. Se completa con las condiciones de desencadenamiento de las funciones primitivas. b) Transformación física de los flujos Hemos hablado de flujos, ahora tenemos que darles una representación física en forma de pantallas, de documentos, etc. Nota: Dependiendo de la duración de la realización de documentos, estos pueden diseñarse en el estudio detallado ... lo que no ocurre con las pantallas, que dependen no solamente de las características físicas de las pantallas, sino también del encadenamiento de las funciones del programa y de la ergonomía.

Algunas reflexiones sobre la ergonomía 1) Hay que considerar una fase de aprendizaje en la descripción de los tratamientos interactivos, durante la cuál hay que guiar al usuario. Sin embargo, después de un cierto tiempo, esta guías (menús) se convierten en un freno, una restricción inaceptable para el usuario. Para resolver este problema es preferible construir el sistema tal y como lo ve un usuario habitual y dotarle de ayudas (helps) a las Cuáles acudir en caso necesario. 2) La ergonomía puede prototiparse fácilmente. No es preciso poner al usuario ante el hecho consumado. Simplemente hay que mostrarle las pantallas que deber manipular. 290

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) Una información de calidad es una información reciente, bien seleccionada, es decir, una información útil. Hay que huir de la sobrecarga de pantallas so pretexto de tener miedo de olvidar alguna cosa. Hay que respetar la calidad de la información. 4) No todo es realizable en interactivo ( ver los criterios expuestos ), y además no es deseable que así sea. Piénsese en los útiles de QUERY, de DECISION, y no se dude en dejar al usuario (decisor) seleccionar y manipular por sí mismo las informaciones que le interesan. c) Principios de la modularidad El objetivo de la Subdivisión de un programa en módulos, es facilitar su mantenimiento, separando la lógica de los algoritmos y autodocumentando el programa. ¿ Qué es un módulo ? La teoría de la modularidad se debe a David PARNAS y Larry CONSTANTINE. Un módulo es una parte coherente de un programa, en principio, una función independiente, solicitable por PERFORM o CALL ( en COBOL ). El módulo tiene una estructura particular:

Un módulo comprende dos partes : 291

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1) Una parte visible compuesta de par metros, poco numerosos y explícitos, de una rutina de control de validez de los par metros y de resultados. Si los parámetros son muy numerosos, probablemente es que la función no sea elemental. Si los parámetros no son explícitos, la función no está autodocumentada. La parte visible del módulo, la interface, debe estar bien especificada, ser estable y estar completamente documentada. 2) Una parte oculta que comprende los algoritmos y la lógica del módulo, sus variables locales y la rutina de tratamientos de errores internos del módulo. No es necesario saber cómo funciona el módulo, es suficiente con saber lo que hace. Esto quiere decir que no se puede utilizar su lógica o sus variables internas para influir en su resultado. Esto destruiría la independencia programa-módulo. Los errores detectados o engendrados por el módulo no deben propagarse al exterior del mismo. En particular, no pueden afectar a ninguna ejecución precedente, no guarda ninguna indicación de las siguientes ejecuciones, no hay variables globales. Ya hemos localizado varios módulos: las primitivas de acceso, las funciones primitivas (si la Subdivisión es suficiente) y las funciones reutilizables. Además, tendremos que poner en forma de módulos todas las indecisiones que haya aún en el análisis. Aunque queramos, este tipo de situaciones son inevitables, por lo que tendremos que prepararnos para minimizar sus consecuencias, aislándolas. La modularización de un programa es un recurso del programador y del analista. Lo deseable es ver, como primera página del programa, el encadenamiento de las funciones primitivas, seguido de todas ellas. Esta primera página es una documentación en sí, refleja la arquitectura del programa. d) Cuaderno de carga

292

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Nunca insistiremos bastante en que este cuaderno es una síntesis clara, precisa y coherente. Aquí se tendrá que encontrar: 1) El objetivo del programa. Puede deducirse del diagrama de flujos, que el programador puede consultar. Además, si el programador se ha interesado por el Análisis en las fases anteriores, tendrá ya una buena visión el problema. Nos comportaremos con ‚l como el usuario hace con nosotros: nos acompaña para aprender a conocer lo que se hace. A lo largo del Análisis hay que respetar un principio básico: huir de toda redundancia. Si una información se encuentra en un sitio, es inútil repetirla. De lo contrario podremos encontrarnos con serios problemas de coherencia en las actualizaciones.

2) ¿Dónde se encuentran las informaciones a tratar? Para tratar la información hay que conocer los flujos (a transformar) y el contenido de la memoria colectiva del sistema. Proporcionaremos al programador las maquetas de documentos y pantallas, el esquema externo (eventualmente) y las primitivas de acceso que deber utilizar. La correspondencia entre este material y la manera de explotarlo, se encuentran en las funciones primitivas ( acciones : memorizar, modificar, buscar y suprimir ). Sacaremos del diccionario la descripción de los atributos cuya validez deber controlar. Los controles de validez pueden estar jerarquizados. - los controles del tipo son ejecutados por los terminales ( cuantificación, presencia, etc). - los controles semánticos, restricciones de integridad, hay que programarlos,..pero pueden incluirse en las primitivas de acceso.

293

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

3) ¿ Cómo tratar las informaciones, cómo transformar los flujos que memorizar en la memoria colectiva ?. Para cada programa habrá un "diagrama" de encadenamiento de funciones y una extracción (del diccionario) de la descripción de todas las funciones primitivas necesarias, o la referencia a un módulo utilizable. 4) En algunos casos habrá que adjuntar al cuaderno un esquema del di logo hombre-m quina. Este di logo comprende dos partes : - la actividad del usuario, que está descrita en el cuaderno de procedimientos para uso del usuario. - los algoritmos desarrollados por la máquina, en respuesta a la acción del hombre. Estos algoritmos son los que tienen que estar programados. Este diálogo no es fácil de modelizar. Se puede representar en forma de flujos organizativos, (con mención de los desencadenamientos y las secuencias), o en forma de tabla de dos columnas, donde se describen, frente a frente, las acciones del usuario y los tratamientos que desencadenan. Cuanto más se aparte el programador del análisis, más difícil ser la representación del di logo hombre-máquina. No olvidemos que dicho logo debe ser mostrado, en un prototipo que lo simule frente al usuario, el único habilitado para validarlo. Para Cualquier otra información, dirigiremos al programador hasta el diccionario de datos e, incluso, a la enciclopedia del sistema

294

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

10 10.1

DOCUMENTACIÓN DEL ANÁLISIS DICCIONARIO DEL SISTEMA

El diccionario es el lugar en el que se recoge la definición de todos los términos que se utilizan. Su existencia debe conducir a un consenso sobre la significación de los términos. Si se quiere, el diccionario es la memoria colectiva del sistema informático. Puede ser representado según la forma de un modelo entidad-relación.

Cada entidad de nuestro modelo conlleva un identificador y unos atributos. Estudiaremos con detalle la composición de todas ellas, y de algunas relaciones características. 295

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1) Atributos Datos elementales; campos de base para construir cualquier información. Identificativo: su NOMBRE. Se pueden admitir sinónimos, pero no se debe abusar. El diccionario tiene por objeto mantener la coherencia del sistema. Atributos: Descripción sucinta ( cantidad pedida ) Estructura del atributo: De entrada ( para una fecha: DD/MM/AA ) De salida ( para un importe: Z.ZZ9,9 ) Interna ( para un fecha: 9(8) COMP ) Dominio de valores ( para el código de sexo: M o F) Reglas a respetar ( existencia de una tabla, cheques de dígitos, etc ) Cardinalidad ( número de valores que pueden tener las ocurrencias ) Origen ( cuál es el flujo que crea este atributo ) Notas o texto asociado Como se puede ver, ya hemos cumplido el primer objetivo del diccionario, es decir, memorizar todo cuanto sabemos y debemos saber sobre los objetos ( en sentido amplio ) que manipulamos. Por ello, a veces se le denomina ENCICLOPEDIA, término que parece más apropiado. 2) Entidades Objetos, terceros, conceptos, localizaciones, etc, que tienen importancia para nuestro sistema, que tienen existencia propia, y que se pueden identificar. Identificativo: su NOMBRE Atributos: Descripción sucinta ( conjunto de clientes ) Atributos ( nombre del cliente : NOM-CLI ) Cardinalidad ( número de ocurrencias posibles ) Notas o texto asociado. La entidad se transformar en REGISTRO o en TABLA. 3) Relaciones Interrelación entre dos o más entidades. Matemáticamente son el grafo de la relación entre los dos ( o más ) conjuntos constituidos por las ocurrencias de las entidades. En consecuencia, las 296

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

relaciones no tienen existencia propia; solo existen en tanto que se mantienen las entidades que enlazan. Identificador: su NOMBRE, compuesto generalmente de un verbo y un objeto (pasar el pedido). Atributos: Descripción sucinta. Atributos( cantidad pedida: CANT-PED ) Cardinalidad media ( número medio de participaciones ) Notas o texto asociado. En algunos casos, la relación se transforma en REGISTRO o TABLA. En ese caso, se deben incluir atributos: Las restricciones de integridad referencial. Así, cuando la asociación LINEA DE PEDIDO se convierta en una tabla en una SGDB relacional, debemos añadirle los siguientes comentarios: - El número de pedido que figura en la tabla LINEA DE PEDIDO debe corresponder a un pedido existente y activo. - El número de producto que figura en la tabla LINEA DE PEDIDO debe corresponder a un producto existente y enviable. - No se puede suprimir un pedido mientras tenga LINEAS asociadas al mismo. - No se puede suprimir un producto mientras existan LINEAS asociadas al mismo. 4) Conectividades Las conectividades son en nuestro modelo ( la enciclopedia ) relaciones entre los tipos de entidades ENTIDADES y RELACIONES. Las conectividades miden la participación máxima y mínima de ocurrencias de una entidad en la relación. Definen el tipo de relación matemática que representa la relación. Atributos: valor mínimo ( 0 ó 1 ) valor máximo ( 1 ó n ) Las conectividades son primordiales para transformar el modelo entidad-relación en modelo físico ( CODASYL o relacional ). Nota: Si el diccionario no está informatizado, sino que está mantenido a mano, los atributos que se encuentran recogidos en las relaciones deben estar recogidos en las entidades.

297

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Así se evitar n deslices con las CONECTIVIDADES en el diccionario manual, añadiendo los dos atributos "conectividad mínima" y "conectividad máxima" a la descripción de la entidad, y en la de cada relación en la que participe. Anteriormente ya hemos procedido de esa forma en la descripción. Así hemos recogido "atributo" entre la lista de atributos de la entidad, lo cual es formalmente falso. Los atributos se conocen por medio de la relación "formar parte de la composición". Lo mismo ocurre con la frecuencia de un flujo que, estrictamente, es un atributo de la relación que enlaza flujo y actor. 5) Identificar la entidad Relación que enlaza la entidad ATRIBUTO con la entidad ENTIDAD. Esta relación está vacía. 6) Flujos Informaciones en movimiento en nuestro sistema. Identificador: su NOMBRE Atributos: Descripción sucinta (albar n de pedido) Naturaleza ( externo o interno ) Atributos ( Nombre del cliente: NOM-CLI ) Origen Frecuencia, volumen Notas o texto asociado Un flujo se transforma en FORMATO de PANTALLA, o en DOCUMENTO o en MENSAJE electrónico. 7) Componer el flujo Relación que enlaza la entidad ATRIBUTOS con la entidad FLUJOS. Atributos: Valor asociado ( en un documento de codificación de una póliza de incendios, el tipo de póliza es siempre 121) Número límite de ocurrencias ( en un vale de pedido, se pueden tener hasta 20 líneas identificando productos ). 8) Funciones primitivas Nivel inferior de la descomposición de tratamientos. Es el único nivel en el que se hacen descripciones de procedimientos y de las reglas a aplicar. Incluye también la descripción de las reglas de gestión y organización. Identificador: su NOMBRE Atributos: Número (3.2.1) Descripción sucinta 298

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Algoritmos de transformación o de control Flujo entrante Flujo saliente Operaciones sobre los "ficheros" ( entidades /relaciones) Una función primitiva se transforma en un MODULO de programa. La conectividad de las funciones primitivas hacia los flujos es en realidad (1,2) Atributo: descripción de la primitiva de acceso. Una primitiva de acceso se transforma en un MODULO de programa.

10) Mensajes de error Mensaje asociado a dominios de valores para un atributo, o a una condición de error en una función primitiva. Identificador: su NUMERO Atributos: Etiqueta de error Notas o texto explicativo Los mensajes se transforman en REGISTROS o LINEAS de una tabla. 11) Operaciones Conjunto de funciones primitivas no interrumpidas por un flujo interno. Identificador: su NOMBRE ( paso del pedido ) Atributos: Número (3.2) Descripción sucinta Condiciones de desencadenamiento ( Flujo entrante y flujo saliente ) Recursos necesarios ( quien hace que, donde ) Duración y frecuencia ( cuando ) Notas y texto asociado Si una operación está informatizada, dar lugar a un PROGRAMA. 12) Proceso principal Conjunto de operaciones no interrumpible por un flujo externo. Identificador: su NOMBRE ( reaprovisionamiento de stocks ) Atributos: Descripción sucinta. Objetivos ( estratégico ) Notas o texto asociado ( restricciones a respetar...) 13) Actores 299

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Agentes externos emisores o receptores de flujos. Identificador: su NOMBRE.

300

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

10.2

DOCUMENTACIÓN DEL ESTUDIO PREVIO

La documentación producida por el Estudio Previo, constituye el Cuaderno de Especificaciones del Sistema. Propone un sistema nuevo y analiza sus costos. a) Definición del problema Esta parte de la documentación se extrae del Esquema Director del Sistema de Información, cuando existe. - Determinar en qué medida se inscribe este Dominio en la estrategia general de desarrollo. - Definir los recursos necesarios para llevar a buen término el Estudio Previo. - Definir cuáles son las unidades organizativas impactadas : qué puestos de trabajo, qué funciones. - Determinar las mejoras esperadas, a corto, medio y largo plazo, a nivel de las funciones y de las informaciones. - Definir los objetivos que se esperan, en términos de resultados (no en términos de función) : rendimiento, eficacia, calidad del servicio, calidad de la información, ergonomía, etc. - Definir las restricciones a respetar. b) Diagnóstico del Sistema existente - Trazar el modelo organizativo de tratamientos de lo existente : 1) El diagrama de los flujos, mostrando la circulación de las informaciones entre las diferentes funciones y las responsabilidades de cada uno. 2) Dibujar el cuadro de funciones: Funciones, Responsabilidades, Flujos entrantes, Flujos salientes, Ficheros (organizativos) utilizados, 301

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Funciones de control (validación) existentes, Población (número de puestos de trabajo), Capacidad de adaptación (resistencia al cambio). 3) Establecer el cuadro de los flujos : Flujos, Origen, Destino, Frecuencia, Demora de circulación, Soporte de la información. - Evaluar lo existente : Crítica del funcionamiento del sistema actual, en función de las necesidades experimentadas : ventajas e inconvenientes, disfunciones y lagunas, degradaciones constatadas. c) Ejes futuros : la CONCEPCION - Definir los nuevos objetivos del Sistema (en términos de resultados medibles). - Emplazar el sistema en su contexto (diagrama de contexto), especificando el papel y la responsabilidad de cada unidad organizativa (diagrama de descomposición) - El modelo conceptual de tratamientos: Transformar el MOT existente en MCT teniendo en cuenta las necesidades y mejorando los procesos y circuitos existentes. - Simplificar los circuitos de información ( asignar a un solo punto de entrada cada flujo ) - Suprimir los procesos sin valor añadido ( preparación, control de flujos internos, etc. ) - Estandarizar los procedimientos eliminando los casos particulares ( preguntarse el por qué ) - Dibujar el nuevo diagrama de flujos. -Listar los objetivos y descomponer hasta nivel de operaciones, para cada proceso (función). Un actor estar afectado a cada operación. 302

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Definir las funciones de decisión, las que controlan el funcionamiento del Sistema , actuando sobre ‚l para modificar los par metros. - Definir un punto de entrada para cada flujo, describir los atributos que componen a dichos flujos y dar sus propiedades cuantitativas (frecuencia y tasa de crecimiento anual o periódico). - Actualización del diccionario : - lista de OPERACIONES, - lista de ACTORES EXTERNOS, - lista descriptiva de FICHEROS - lista descriptiva de FLUJOS. - Modelo conceptual de datos : A este nivel, retoma las entidades principales y no es m s que un MCD en bruto, no normalizado. - Dibujar el modelo entidad-relación, mostrando la interacción de las entidades con los modelos adyacentes, para definir las interfaces necesarias entre los dominios. - Definir las necesidades en información por función (por unidades organizativas y por funciones de decisión y de protección de datos (seguridad) ): - Cuadro de funciones y de atributos necesarios. Esto permite tener un panorama de las necesidades y eliminar los atributos superfluos. Cuantificar el modelo, dando el número de ocurrencias, la tasa de crecimiento esperado y las estadísticas sobre el reparto de las ocurrencias de las relaciones (mínimo, máximo y media ). - Actualización del diccionario : - lista de ENTIDADES y sus IDENTIFICADORES, - lista de RELACIONES, - lista de ATRIBUTOS d) Aspectos diversos -------------------------------------------------------303

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El estudio del dominio se limita a veces, por razones de plazos, al estudio del subconjunto representativo. -------------------------------------------------------- Orientaciones : - Resumir las orientaciones posibles (todas las alternativas conceptuales), detallando cómo responden a las necesidades, quedando en adecuación con los objetivos. - Describir las ventajas y los inconvenientes para las diversas soluciones, en términos de calidad, resultado y rentabilidad. - Dar recomendaciones. - Funcionamiento : - Citar las ideas maestras y los conceptos de base del nuevo sistema. - Dar las reglas de organización y los principios de control (decisión y seguridad). - Describir las responsabilidades de los diferentes procesos. - Arquitectura : - Describir los servidores, si fuera necesario: servidores de datos, servidores de aplicación (el papel de los micro), servidores de acceso ( cartografía de los dispositivos de comunicación ). - Trayectoria : - Subdivisión en aplicaciones, con prioridades relativas y justificación de las alternativas. - Describir los diferentes escenarios de progresión, con un planning global de realización. - Impactos : - Sobre los métodos de trabajo : cambios en las costumbres, funciones obsoletas, funciones nuevas, nuevas técnicas, nuevo entorno. 304

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Sobre la organización : Nuevos circuitos de información, nuevos procedimientos, responsabilidad de cada uno. - Sobre los efectivos : cualificación y formación necesarias. - Sobre las relaciones entre las unidades organizativas. e) Análisis de los costes

10.3

DOCUMENTACÓN DEL ESTUDIO DETALLADO

La CONCEPCION general se hace a nivel del estudio previo. En el estudio detallado vamos a analizar cada proceso, vamos a entrar en detalle, a pasar de lo general a lo particular, respetando el cuaderno de especificaciones, producido en la fase anterior. La mayor parte de los documentos que se producen en esta fase son versiones detalladas y revisadas de los documentos producidos antes. a) Modelo de datos El modelo conceptual de datos retoma, además del modelo entidadrelación completo y normalizado, obtenido al comienzo del estudio de los atributos: - La lista de los atributos, con su descripción completa (ver el diccionario de datos) y su utilización por las diferentes funciones (ver los esquemas externos). - la constitución de las diferentes entidades y relaciones. - Las reglas de integridad de las relaciones, cuando estas no se pueden deducir del modelo. - Las propiedades cuantitativas del modelo : número de ocurrencias, tasas de crecimiento, estadísticas de distribución de ocurrencias de las relaciones, estadísticas de utilización de las entidades y de las relaciones. - Actualización del diccionario : 305

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Descripción completa de los atributos. b) Modelos de tratamientos Diseñar los modelos conceptuales y organizativos para la aplicación. Estos modelos se materializan por diagramas de flujos, que detallan hasta las funciones primitivas. Además de estos diagramas de flujos(particiones), encontramos : - Las especificaciones de las funciones primitivas (tablas de decisión, pseudo-código, gráficos, etc.). - Las características de los procesos : automatizados o no, directos o diferidos, centralizados o descentralizados. Estos procesos, de características diferentes, forman operaciones diferentes. - Tabla de distribución de responsabilidades (ORC : Organizational Responsability Chart). -La descripción de los flujos (número, contenido en termino de flujos y atributos, propiedades :frecuencia, crecimiento, duración, etc. - Repertoriar los procesos comunes : se desarrollaran en primer lugar y se describir , minuciosamente su interface. - Actualización del diccionario : - Especificación de las FUNCIONES PRIMITIVAS, - Adaptación de los FLUJOS y de los FICHEROS. c) Cualidades del nuevo sistema - Calcular el rendimiento operativo esperado (volumen de transacciones por periodo y/o persona, capacidad de tratamiento cotidiano, puestos de trabajo necesarios). - Determinar la incidencia de la averías y describir todos los aspectos de seguridad de funcionamiento (modo degradado, control de las informaciones memorizadas, etc.) d) Control de la concordancia de los modelos

306

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Documentar las correcciones hechas en el modelo conceptual de datos y en el diagrama de flujos, después de la validación del MCD por los esquemas externos. Actualización del diccionario : - Adaptación de FLUJOS y FICHEROS - Adaptación de FUNCIONES PRIMITIVAS - Adaptación de MCD (atributos, identificadores, entidades, relaciones). e) Plan de acciones - Plan de información y de formación de futuros actores : primera versión de guía de operación. - Preparación de los procesos de entrada. - Elección de las técnicas de desarrollo : materiales, procedimientos, software, lenguaje y entornos informáticos para colocar en su lugar : detalle y planificación

10.4

DOCUMENTACIÓN DEL ESTUDIO TÉCNICO

a) Estudio de accesos Estudio de los accesos con modificación eventual del MCD (documentar las correcciones efectuadas). Describe las interfaces requeridas por las primitivas de acceso lógicas. Actualización del diccionario : - Descripción de los REGISTROS y de sus CAMINOS DE ACCESO, - Especificación de las Primitivas de Acceso. b) Constitución de la Base de Datos Transformar el MCD (y/o el MLD) en modelo físico. Describir todas las restricciones de integridad referencial , que debieran ser tomadas en cuenta en la programación.

307

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Optimizar el esquema , documentando todas las decisiones que se aparten del MCD. Actualización del diccionario : - Para Relacional : - Descripción de las TABLAS, de las COLUMNAS, de las CLAVES primarias, secundarias, externas y candidatas. - Transformación de las Primitivas de acceso en VIAS. - Para CODASYL : - Esquema de transformación de las Primitivas de acceso al Sub-Esquema y módulos de acceso Físicos. - Creación de AREAS. - Para Ficheros Clásicos : - Descripción de los FICHEROS y de los RECORDS (FD). c) Modelo Operativo de tratamientos - Definir los módulos reutilizables (comunes), documentando su función y su interface. - Producir la guía de operación adaptada a los usuarios del Sistema. - Reagrupar las funciones primitivas por unidad de programación. - Transformar los flujos en diseño de documentos y pantallas. Tener en cuenta las restricciones técnicas. Constituir un dosier de síntesis, para cada unidad de programación, retomando : - los objetivos de la unidad de programación, - el diagrama de flujos, haciendo aparecer su entorno, - la descripción de los flujos que recoge y que emite, acompañada del diseño de las pantallas y de los documentos que provienen de la transformación de estos flujos.

308

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- las reglas de tratamiento y de validación de los datos : la secuencia de las funciones y de las condiciones de su encadenamiento. Unir la especificación de cada función, salvo los módulos reutilizables, para los que solo es necesaria la interface. - la lista de los mensajes de error específicos a las funciones de la unidad de programación. - Eventualmente, el esquema externo (la vía local sobre los datos) de la unidad y las primitivas de accesos físicos a los que se refieren. - Actualización del diccionario : - Documentar las relaciones entre los PROGRAMAS y los RECORDS, PANTALLAS, LISTAS

309

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

11

RECURSOS DE CAPTACIÓN Y ORGANIZACIÓN DE DATOS

A lo largo de los capítulos precedentes se ha visto la necesidad de dotar a jefes de proyecto, analistas y consultores, de una serie de recursos para captar la información, en la comunicación con los usuarios organizar la información captada, con vistas a su análisis analizar la información, una vez estructurada presentar resultados a los destinatarios de los estudios informáticos Entre los recursos, se encuentran las listas de detalles ( check-lists ), métodos de realización de entrevistas y de gestión de reuniones, gráficos ( diagramas, esquemas ), tablas, matrices, etc. En las páginas que siguen se comentan algunos ejemplos y sus utilidades específicas.

A ) CHECK LIST Un check list es un documento semejante a esa lista que realizamos cuando vamos a ir a la compra, o cuando vamos a preparar los objetos que necesitamos llevar en el viaje de vacaciones, o que reúne los aspectos que no tenemos que olvidar en una negociación de compra-venta. La confección de un check-list costará mayor o menor esfuerzo en función de nuestra experiencia en un entorno determinado, o de la riqueza de detalles que hayamos logrado si elaboramos ese documento en una sesión de brain storming con otros expertos Seguidamente se dan varios ejemplos Check-List de Planteamiento de Proyecto PLAN Definición de principales actividades Tiempo necesario para movilizar al equipo de proyecto Duración del proyecto Definición de hitos 310

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Calendarios de realización Fechas de reuniones Subdivisión de tareas ESFUERZOS Estimaciones de cargas Estimación de recursos Desviaciones entre estimaciones realizadas Administración del proyecto Soporte burocrático Soporte técnico Soporte de calidad Modelización del sistema Implantación del producto Pruebas Aceptación Garantías Grado de productividad esperado METODOS Procesos de trabajo de acuerdo con lo definido Metodología de trabajo propuesta Revisiones técnicas propuestas Propuesta de plan de calidad Aceptación de normativas del usuario Procedimientos de verificación RECURSOS Personal usuario que va a participar en el proyecto Adecuación funciones - personas Diagrama organizativo del proyecto Identificación de responsabilidades Restricciones en la selección del personal Identificación de otros recursos del proyecto

Check-List de Propuesta de Subcontratación ( Outsourcing ) SUBCONTRATACION DE MERCANCIAS Identificación de posibles subcontratistas Competividad de los subcontratantes seleccionados Asesoría de personal comercial 311

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Alternativas de entrega de productos en caso de conflictos Plazo mínimo de entrega Precios y descuentos Validez de las ofertas Garantías Formas de pago Condiciones diversas ( legales, etc ) SUBCONTRATACION DE SERVICIOS Evaluación de ofertas de servicios Grado de competencia técnica de los subcontratados Grado de adecuación de los servicios a las normativas internas Fechas límite de validez de ofertas Precios Plazos de entrega de trabajos Prestaciones técnicas Calidades Condiciones comerciales Documentación y especificaciones suministradas a ofertas Plan de cada subcontratante para consecución de resultados Supervisión de los subcontratos Acuerdos de colaboración con terceros Condiciones de pago Condiciones de financiación Compensaciones en caso de conflicto Obligaciones contractuales Inspecciones Aspectos de seguridad Propiedad intelectual Confidencialidad

Check-List de Plan de Calidad de un Proyecto PLAN Adecuación del plan de calidad con las normas oficiales Adecuación del plan de calidad con las normas internas empresa Cobertura de entregas externas 312

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Cobertura de entregas internas Adecuación de métodos preventivos Estrategia de pruebas Descripción de detalles con suficiente profundidad Grado de cobertura de todos los aspectos del proyecto Acopio de normativas internas/externas sobre calidad SEGUIMIENTO DEL PROYECTO Documentación Grado de progreso del proyecto. Desviaciones. Funcionamiento de los equipos de trabajo Satisfacción del usuario con las implantaciones progresivas Riesgos del proyecto ORGANIZACION DEL PROYECTO Estructura y objetivos del proyecto Problemas funcionales Impacto en la organización de la empresa Formación prevista para los participantes Ubicaciones de trabajo de los equipos PLANIFICACION DEL PROYECTO Documentación de las tareas Estimación de las cargas de trabajo Plan de trabajo Adecuación de las competencias a la complejidad de las tareas ADMINISTRACION DEL PROYECTO Validaciones Asignaciones de recursos ASPECTOS VARIOS Estado de la documentación contractual Estado de la documentación interna Firmas de contratos Variaciones respecto a propuestas e implicaciones en costos Claridad de la documentación de la propuesta 313

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Documentación entregada por el director del programa Detalle de las estimaciones realizadas Diferenciación entre espectativas de los usuarios y objetivos Desacuerdos entre la propuesta y el plan del proyecto Conocimiento del proyecto por parte del personal participante Delimitación de responsabilidades entre destinatarios y realizadores Grado de implicación de terceros Formatos de reporting del proyecto Plan de reuniones y entrevistas Disponibilidad de recursos Revisiones de la marcha del proyecto Obstáculos iniciales que se presentan Procedimientos de lanzamiento del proyecto Estudio de riesgos Acuerdos de colaboración con terceros Acuerdos de subcontratación Posibilidad de comienzo del proyecto

Check-List del Cierre de un Proyecto Preparación para entrega del producto final Aceptación del producto final Por cada entrega -Disponibilidad de entrega -Aceptación de restricciones conocidas -Completitud de la documentación -Acciones excepcionales -Logística de entrega -Requisitos de la versión del producto Por cada servicio proporcionado con las entregas -Definición y planificación de recursos -Requisistos de actuación Implantación del producto o sistema -Adaptación a condiciones ambientales -Cumplimentación de condiciones de implantación múltiple -Documentación de implantación 314

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

-Procedimientos de prueba -Disponibilidad de medios Documentación -Disponibilidad de documentación de soporte -Documentación enviada por el usuarioi Caso de entrega parcial -Prestaciones producto no entregado respecto trabajo remanente -Factibilidad del producto entregado -Aceptación de las entregas remanentes Direcciones de entrega Instrucciones de entrega Plazos de entrega Pagos Compromisos de garantía Alternativas ante conflictos Formaciones planificadas Procedimientos de control de calidad

B ) MÉTODO DE REALIZACIÓN DE ENTREVISTAS Las entrevistas son la principal herramienta de obtención de la información necesaria para la realización de estudios tales como Diagnóstico Estudio de Viabilidad Plan de Sistemas Análisis Contrataciones de Productos y Servicios Aunque, dependiendo del interlocutor, cada una de ellas tenga un contenido específico, para facilitar el desarrollo de las mismas se propone seguir el siguiente procedimiento: 1). Acuerdo con el futuro entrevistado de la fecha, hora y lugar de realización de la entrevista. Se recomienda:

315

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Lugar : sitio habitual de trabajo del entrevistado - Hora : preferiblemente al comienzo de la jornada. 2). Envío al futuro entrevistado, al menos con un día de antelación, del plan de la entrevista, conteniendo los parámetros de la misma (fecha/hora/lugar) y los temas a tratar. Este envío tiene por objeto el que el entrevistado reflexione previamente sobre el contenido de dicha reunión, y pueda enriquecerla preparando de antemano los documentos, informes, tablas, etc., que considere convenientes. 3). Realización de la entrevista Equipo entrevistador: compuesto por dos personas, con funciones complementarias - el interlocutor, que llevará el peso dialéctico de la entrevista. - el observador, que realizará anotaciones sobre la misma, participando eventualmente en la conversación. Duración máxima : 2-3 horas Si esa duración no fuese suficiente, es aconsejable continuar la entrevista en otra sesión, en lugar de prolongar excesivamente la primera. 4). Redacción, por el equipo entrevistador, de un resumen de la entrevista ). Este resumen es confidencial; solo se presentará al entrevistado, para que éste valide o rectifique lo que considere conveniente; no figurará en el informe. Su información será utilizada, junto con la procedente del resto de las entrevistas, como punto de partida, para la descripción de las situaciones actual y futura.

5) Elaboración, por parte de los entrevistadores, de la información recabada en la entrevista (confección de tablas, fichas, etc.)

316

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

C) MÉTODO DE CONDUCCIÓN DE REUNIONES En realidad, los criterios no varían mucho de los explicados en el punto anterior, respecto de las entrevistas. Los criterios a seguir son los siguientes: a) Tema único ( siempre que sea posible) Se estudiará previamente la forma de tratarlo b) Preparación ( meticulosa) Finalidad y objetivos de la reunión Recopilación de la información necesaria Plan de la reunión ( esquema, tiempos, etc) c) Asistentes Reflexiones Libertad de expresión Anotación de las ideas expuestas d) Medios de ayuda Bloc Mural Proyector e) Conclusión Conclusiones parciales Conclusión general Decisiones Acta

D) GRÁFICOS ( DIAGRAMAS, ESQUEMAS ) Uno de los axiomas de las metodologías de construcción del Sistema de Información es el principio "Top-down", segun el cual se estudia la complejidad de un fenómeno en base a subdivisiones sucesivas que permiten manejar complejidades de índole menor. Esto es lo que permite representar y organizar los Diagramas de Subdivisión, o WBS (Work Breakdown Structure). Los WBS pueden tener, en general, estar orientados a: - funciones - productos Los WBS se aplican a: 317

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- técnicas - tiempos - recursos - costos - calidades - entregas - hitos - riesgos

Un WBS consta de una serie de objetos (rectángulos) dispuestos en varios niveles, de forma tal que se pueda ver el grado de dependencia

En el WBS de la figura, la estructura (M2) depende de la (M) y a su vez de ella dependen las estructuras (M21), (M22) y (M23). Este tipo de gráficos sirve para mostrar la subdivisión de una organización en dominios funcionales, o para mostrar los módulos en los que se divide un programa informático. Otros ejemplos se orientan a la subdivisión de un producto en sus componentes, o a la subdivisión de tareas

318

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

En la Planificación Estratégica o en el Desarrollo de Aplicaciones Informáticas es necesario conocer los conjuntos de datos principales que forman la componente estable del Sistema de Información. Los datos se agrupan formando Entidades, siendo al tiempo considerados como Atributos de las mismas. Las entidades pueden tener Relaciones con otras. La representación gráfica, con vistas a la gestión de los datos y la comunicación entre los participantes en la gestión estratégica y táctica del Sistema de Información, se realiza gracias a los DIAGRAMAS ENTIDAD-RELACION. Otros componentes del Sistema de Información susceptibles de modelización son los Tratamientos y los Recursos, aunque el interés de este tipo de modelización corresponde mas que a la Planificación Estratégica, sobre todo a las etapas de desarrollo del Sistema de Información. Existen herramientas (C.A.S.E.) que permiten representar y documentar gráficamente los modelos de datos, así como realizar la gestión del diccionario de datos, necesario en las diversas etapas del desarrollo 319

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Un DIAGRAMA DE MARKOV es una representación del comportamiento de un sistema dependiendo de circunstancias variables en el tiempo. El comportamiento del sistema se explica en base a los Estados, o conjunto de circunstancias o atributos que caracterizan el sistema en un momento dado. La evolución del referido sistema implica cambios de unos estados a otros, que se representan por arcos orientados que conectan dos estados. En los sistemas suele haber un estado inicial, identificado por un arco que llega a él procedente del exterior, y puede haber uno o varios estados finales, identificados por tener solamente arcos orientados de cambio de estado que llegan a ellos. Los cambios de estado se realizan mediante la concurrencia de circunstancias que satisfacen condiciones.

320

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las condiciones y las acciones se suelen indicar en los arcos orientados de cambio de estado. En caso de tener que estudiar sistemas muy complejos se pueden tener un número muy elevado de estados, por lo cual hay que recurrir a técnicas de representación por niveles. El paso de un estado a otro puede estar sujeto a las leyes del azar. En ese caso, tenemos un Diagrama de Markov representativo de un Proceso Estocástico, asociado al cual se pueden medir ciertas magnitudes como el tiempo medio de permanencia en un estado, o la probabilidad de paso de un estado a otro. El uso de este tipo de diagramas está orientado a sistemas de tiempo real y control de procesos. La filosofía de los Diagramas de Markov se utiliza para la descripción de procesos administrativos. Un ejemplo típico es el de la descripción de los pasos que sigue un expediente a lo largo de los departamentos implicados en su gestión. Las validaciones de los diversos pasos y los estados que se pueden presentar son objeto de los Flujos de Trabajo ( Work-Flow).

En la figura adjunta, un ejemplo de los estados de un expediente en la gestoría jurídica de una organización.

321

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Sin embargo, a veces resulta más conveniente representar el mismo fenómeno mediante un diagrama que exprese mejor las responsabilidades de los diferentes estamentos implicados. He aquí un ejemplo.

322

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La modelización de tratamientos ofrece estilos diferentes según las escuelas que se han formado entre los informáticos. En el mundo anglosajón, los diagramas tienen orientación hacia los flujos de información. Son los que hemos visto en el capítulo dedicado a la modelización de tratamientos. Sus elementos son flujos, actividades, actores y almacenes de información. Sin embargo, en el mundo francófono europeo, la modelización de los tratamientos está orientada a la secuenciación de los tratamientos y los acontecimientos (eventos) que desencadenan los procesos. En cualquier caso, será la herramienta de modelización la que nos marque qué tipos de diagramas podemos utilizar.

323

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

324

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

E) MATRICES Y TABLAS Son de utilidad varios tipos de matrices: Procesos-Entidades Entidades-Ficheros Procesos-Unidades Organizativas Sin pérdida de generalidad, vamos a centrarnos en el primer caso. Para representar la Matriz Procesos-Entidades se seguirán los pasos siguientes: 1. Identificar los procesos de la Organización. 2. Identificar las entidades de datos de la Organización. 3. Representar de forma matricial los procesos frente a las entidades de datos. 4. Reorganizar la matriz. 5. Determinar subsistemas. 6. Asignar prioridades de desarrollo.

La matriz procesos-entidades permite estudiar la existencia de .Sistemas que realizan operaciones típicas de proceso de datos; que cubren el núcleo tradicional de tratamiento de datos, con tareas predefinidas (cálculo de nóminas, sistemas de facturación, etc.) y, frecuentemente, un alto volumen de datos.

.Sistemas de gestión de la información, definidos para facilitar consultas sobre la información almacenada en el sistema, proporcionar informes y, en resumen, facilitar la gestión autónoma de la información por parte de los departamentos usuarios. .Sistemas de soporte a la toma de decisiones. Facilitan la labor de la dirección, proporcionando una presentación mejor de la información para la toma de decisiones. Se caracteriza porque son sistemas sin carga periódica de trabajo, es decir, su utilización no es predecible, al contrario que en los dos casos anteriores, cuya utilización es periódica.

325

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

.Sistemas especiales. Como sistemas expertos, sistemas de información para ejecutivos (EIS), etc. Todo ello facilita la tarea de asignación de prioridades, entornos tecnológicos, sistemas de soporte y almacenamiento de datos, etc. Asimismo, el uso de la técnica matricial permite estudiar en detalle qué sistemas son prerrequisitos para poder acometer el desarrollo de otros, evidenciar beneficios potenciales, impacto en la organización, probabilidad de éxito en la implantación demanda de los sistemas, etc.

En general, podemos hablar de MATRICES DE ASOCIACION Se pueden utilizar para crear dinámicamente las conexiones o asociaciones entre objetos. Se pueden utilizar con tipos de objetos ( p.e. procesos y colecciones de datos ), o con casos particulares de objetos (p.e. Registros de Clientes implicados en Facturas de Clientes ). Algunas asociaciones son de tipo "todo o nada" ( p.e. un conjunto de datos se subdivide o no en otro conjunto de datos ). Otras asociaciones pueden tener propiedades o mostrar grados (p.e. impacto de problemas en objetivos ). 326

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

MATRICES DE PROPIEDADES Disponen todos los objetos de un determinado tipo en filas, y en columnas las propiedades que pueden poseer. Este tipo de matrices permite : -Rellenar los datos de un diccionario con las propiedades de los objetos -Desarrollar propiedades para posibles objetos -Examinar y comparar propiedades de objetos El uso de este tipo de matrices tiene importancia en el estudio de consistencia y coherencia de datos. Por medio de útiles informáticos, se puede disponer las filas y columnas mediante diferentes criterios de clasificación. Las matrices suelen ser relacionadas con diversos modelos, tales como diagramas de datos o diagramas WBS En el caso del flujo de documentos visto anteriormente mediante un diagrama de Markov, la matriz correspondiente sería la siguiente

327

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Se añaden otros ejemplos de utilización de tablas de correlación

328

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

329

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

F) GRÁFICO DE GANTT En el capítulo dedicado a la Gestión de Proyectos se ha mencionado el Gráfico de Gantt, como instrumento de control del proyecto. Un gráfico de Gantt es una tabla en la cual relacionamos una lista de actividades con su calendario de realización. En el ejemplo que sigue, tenemos las actividades de un proyecto de investigación, que incluye el desarrollo de un software. Las actividades están agrupadas por etapas. El calendario abarca desde el comienzo del proyecto ( julio 2013 ) a su finalización ( marzo 2014 ). Las duraciones de las actividades aparecen en forma de barras horizontales.

330

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA PROYECTO ALGORITMO SINGULARIDADES ESTUDIO MEDIOAMBIENTAL jul-13 ago-13

sep-13

oct-13

nov-13

dic-13

ene-14

feb-14

revisar bibliografía de partida y dossier revisar algoritmo con caso ejemplo diseñar software para algoritmo aplicar software a caso ejemplo entrevista especialista CC Medioambientales analizar problemas medioambientales preparar argumento justificación proyecto diseñar memoria del proyecto concretar problema medioambiental concretar conjunto datos mediambientales explicar algoritmo y software empleados diseñar caso ejemplo con datos medioambientales aplicar software a caso ejemplo medioambiental análisis resultados investigación conclusiones e informe de la investigación seleccionar bibliografia a mencionar diseñar material de presentación preparar memoria del proyecto entregar memoria de proyecto

Mediante el gráfico de Gantt también podemos ver el camino critico, formado por aquellas actividades que no admiten retraso en su ejecución, so retraso total en la finalización del proyecto. En el mismo ejemplo antes visto, se señalan las tareas críticas del proyecto con unas barras más gruesas.

331

mar-14

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA PROYECTO ALGORITMO SINGULARIDADES ESTUDIO MEDIOAMBIENTAL jul-13 ago-13

sep-13

oct-13

nov-13

dic-13

ene-14

feb-14

revisar bibliografía de partida y dossier revisar algoritmo con caso ejemplo diseñar software para algoritmo aplicar software a caso ejemplo entrevista especialista CC Medioambientales analizar problemas medioambientales preparar argumento justificación proyecto diseñar memoria del proyecto concretar problema medioambiental concretar conjunto datos mediambientales explicar algoritmo y software empleados diseñar caso ejemplo con datos medioambientales aplicar software a caso ejemplo medioambiental análisis resultados investigación conclusiones e informe de la investigación seleccionar bibliografia a mencionar diseñar material de presentación preparar memoria del proyecto entregar memoria de proyecto

El gráfico de Gantt es una alternativa al gráfico PERT, herramienta de gestión de proyectos.

332

como

mar-14

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12 12.1

MÉTODOS DE ESTIMACIÓN DE CARGAS MÉTODO COCOMO

El modelo matemático puesto a punto por Barry BOEHM es el resultado del estudio de 63 grandes proyectos americanos, mas la afinación sobre otros proyectos desarrollados con posterioridad. Aparentemente, este método es muy sencillo. Da la duración del proyecto en persona-mes y el tamaño del equipo necesario para llevar a término el proyecto. La única variable de entrada es el tamaño del proyecto en "Líneas fuente programadas". Dicha noción es objeto de una definición precisa: Se entiende por línea fuente programada, cada línea de instrucción (excluidos comentarios) que se entrega con el producto ( se omiten los módulos desarrollados para pruebas ) y que ha sido desarrollada para el producto ( los módulos reutilizables no se tienen en cuenta ). Visto de cerca, apercibimos que el problema ha sido desplazado: es tan difícil estimar el tamaño de un proyecto en instrucciones que estimar su tiempo de realización. Por otro lado, el método da un valor medio que hay que ponderar por medio de diversos criterios, uno de los cuales, la aptitud del equipo, puede influir la duración con un factor 4 (!). Este modelo es muy empleado en Estados Unidos, sobre todo por el D.O.D. (Department of Defense), pero parece poco apropiado para nuestra situación, sobre todo como herramienta de estimación inicial. Por el contrario, se podría utilizar a posteriori para juzgar la eficacia del equipo de proyecto y determinar los puntos a mejorar en el futuro.

333

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12.2

MÉTODO DE MARCO

Este es un método progresivo que permite afinar su estimación en la medida de la evolución del proyecto y con tanta precisión como se quiera. Los algoritmos de cálculo son muy rigurosos, pero los datos sobre los que se basa solo se pueden adquirir con la experiencia. A lo largo de su obra Controlling Software Projects, Tom DE MARCO insiste en la necesidad de crear un equipo especializado en la medida. Es la única forma de adquirir experiencia. Preconiza no dejar a los jefes de proyecto la tarea de estimar la carga, ni medir su evolución, sino confiar todos los aspectos de medida a un equipo de especialistas.

12.3

MÉTODO DE PUNTOS DE FUNCIÓN

Otro investigador, Albrecht, ha puesto a punto un método riguroso, fácil de empleo, que consiste en medir la complejidad relativa de la aplicación, atribuyéndole de alguna forma una puntuación. Se calcula primeramente un valor bruto, basado en el número y la complejidad de las entradas, salidas, ficheros, preguntas e interfaces. La medida de la complejidad ha sido formalizada por Albrecht. Seguidamente, se tiene en cuenta el entorno de la aplicación. Se calcula un factor de ponderación, que permitirá determinar el valor neto de la aplicación. El coeficiente de ponderación es función de 14 parámetros: - Telecomunicaciones - Distribución de funciones - Incidencia de las prestaciones sobre el sistema - Carga de la configuración - Tasa de transacciones a alcanzar - Captura de datos on-line - Eficacia de los usuarios - Actualización on-line de datos - Complejidad de los tratamientos - Facilidades de instalación del sistema - Facilidades de puesta en marcha del sistema 334

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- Número de ubicaciones que utiliza el sistema - Facilidad de mantenimiento del sistema

A pesar de la simplicidad del empleo de este modelo y el formalismo en la descripción de los parámetros, es bastante inoperativo. Se puede determinar la cuantía del trabajo, pero no se conoce el rendimiento de los ejecutantes., que solo se conocerá por la experiencia.

12.4

MÉTODO DE WALSTON & FELIX

Walston y Felix han estudiado centenares de proyectos para determinar los parámetros que influyen realmente en la carga y el coste. Han deducido de ello un modelo, desgraciadamente basado en el conocimiento del número de líneas de la aplicación. Dicho modelo tiene en cuenta factores tan diversos como: Complejidad de la organización ( peso. 376 ) Participación de los usuarios en la especificación del problema (peso: 286 ) Experiencia de los actores ( peso: 278 ) Experiencia en el mismo dominio de la aplicación ( 264 ) Experiencia en el lenguaje de programación ( 263 ) Participación de los programadores en el análisis ( 238 ) En el extremo opuesto, encontramos la complejidad de la aplicación ponderada con 80 (!).

12.5

MÉTODO DE RUBIN

Este modelo , basado en los estudios de Walston y Felix, hace abstracción del número de líneas de la aplicación. Ello permite utilizar el modelo muy rápidamente en la segunda fase de la vida de un proyecto: estimación de la carga y de los costes. El modelo es soportado actualmente por herramientas informáticas.

335

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12.6 ALGORITMO DE ESTIMACIÓN DE CARGA EN FUNCIÓN DE LOS MODELOS Este algoritmo se utiliza después del Estudio Previo del sistema. Se aplica en desarrollos estandarizados: dominios no científicos, distribuciones equitativas entre programas batch y transaccionales, y utilización de un método de análisis riguroso y formal. Se calcula primeramente la carga bruta, multiplicando el número de objetos del tipo citado por el peso asociado. Ello nos da P. por cada ENTIDAD (e) ....................................................: por cada RELACION (r) ..................................................: por cada FLUJO EXTERNO entrante (i)..........................: por cada FLUJO EXTERNO saliente (o)..........................: por cada ATRIBUTO de (e) o (r), o sea (a) ....................:

9 15 18 25 1

P = 9e + 15r + 18i + 25o + a Las ENTIDADES y las RELACIONES son las que figuran en el Modelo Conceptual de Datos BRUTO, es decir, antes de la normalización. Las entidades biyectivas (conectividad 1-1 en cada rama) sólo se cuentan 1 vez. Los FLUJOS, que se toman del diagrama de contexto, son los que proceden de o que parten hacia actores externos. Solo hay que considerar los FLUJOS importantes y diferenciados. En rigor, los valores de (i) y (o) pueden ser ponderados en función de la dificultad presentada por el flujo. Para la atribución de pesos, hemos tenido en cuenta los trabajos de ALBRECHT (Function Points as a measure of productivity) y los de C.R.SYMONS (Function Point Analysis: Difficulties and Improvements). Seguidamente, debemos calcular un coeficiente de análisis, que representa el entorno en el cual se va a desarrollar el análisis. Es preciso sumar los puntos atribuidos a los diversos factores para obtener ka, el coeficiente de análisis.

336

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Favorable

Las necesidades bien definidas Hay múltiples usuarios Participación de los usuarios Conocimiento de la aplicación

0 0 (no) 0 (no) -0,15

Desfavorable

0,3 0,2 (sí) 0,2 (sí) 0,25

Las necesidades son consideradas conocidas si se han fijado objetivos precisos. Cuanto menos claros son los objetivos, más elevada es la puntuación. Se puede atribuir un peso de 0,10 o de 0,20 según el grado de definición de las necesidades. Si existe un comité informático bien organizado, contrastará los conflictos entre puntos de vista diferentes y considerará que solo hay un interlocutor. En caso contrario, los conflictos retrasarán el proyecto y se sancionará con un peso más elevado esta situación. La participación del usuario, no solamente en la definición de necesidades, sino sobre todo en las sesiones de validación, retrasa ciertamente el proyecto. Tengámoslo en cuenta en la estimación de la carga. Por el contrario, la calidad de la aplicación mejorará notablemente, pero este factor no interviene en el cálculo de la carga del desarrollo, sino mas bien en la carga de mantenimiento. Conocer la aplicación ( por parte del usuario y del analista ) es un éxito innegable. Debe intervenir en la estimación. Si el conocimiento es grande, se atribuye peso negativo. Un conocimiento medio conlleva un peso nulo, mientras que un descubierto en el curso del análisis puede llevar una puntuación que llega hasta 0,25. Una vez estimado el entorno del análisis, es preciso dar un peso a la realización, calculando kr, el coeficiente de realización.

337

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Favor _______ Potencia de las herramientas ................. -0,2 Conocimiento de las herramientas............. 0 Disponibilidad de la máquina ........... 0 Complejidad de los tratamientos ........ -0,1 Participación de los usuarios en el análisis -0,15 Participación de los progr en el análisis -0,15 Existe procedimiento estándar de RECOVERY 0

Desfav ______ 0,2 0,2 0,1 0,1 0,15 0,2 0,2

Se atribuirá una puntuación muy favorable si se dispone de generador de aplicaciones. Otra puntuación (0) sancionará la presencia de gestor de pantalla, editor, etc. Los software desprovistos de estas herramientas recibirán una puntuación desfavorable, que llegará a 0,2. El desconocimiento de los útiles puestos a disposición de los programadores puede influir negativamente al avance del proyecto. Así pues, si el equipo de realización está poco familiarizado con los útiles, se atribuirá una puntuación que va de 0 a 0,2. Por disponibilidad de máquina, se entiende la potencia de la misma, es decir la disponibilidad para las pruebas y también la fiabilidad del hardware y del software. De hecho todo lo que puede retrasar el proyecto. Si en el momento del análisis hemos considerado como freno la gran implicación de los usuarios, vamos a sacar de ello un beneficio en la fase de realización. Así pues, si los usuarios han validado el análisis, se puede deducir el efecto negativo que conlleva el análisis, atribuyendo una puntuación que va de -0,15 a 0. En caso contrario, deberemos atenernos a las frecuentes demandas de modificación y atribuir una calificación que llega hasta 0,15 por este factor. La implicación de los programadores en el análisis tiene un efecto benéfico. Tendremos ello en cuenta en la estimación de la carga de realización, dando una puntuación negativa que llega hasta -0,15. En caso contrario, los programadores sufrirán la penalización de descubrir el análisis a medida que se va haciendo el desarrollo.

338

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Finalmente, es preciso tener en cuéntalas facilidades ofrecidas por el software de base en materia de backup, recovery y restart. Si dichas funciones existen, o si no, no interesan, dar una calificación de 0. Tiempo de análisis (en días) ......................: A = (1 + kA) P / 2 Tiempo de programación (en días) .............: R = (1 + kR) P / 2 Integración / Instalación (en días) .............: I = R / 10 Tiempo total ...............................................: A+R+I

El cálculo de los coeficientes (kA y kR) está inspirado en los estudios de WALSTON y FELIX (A Method of Programming Measurement and Estimation).

Cálculo de la duración nominal El estudio de Walston & Felix da: E = 12 ( A + R ) / 230 D = 2,47 E ** 0,35 Donde D es la duración nominal (en meses) y E el esfuerzo (en persona/mes). Se estima que la duración real no puede nunca descender por debajo del 75 % del valor nominal.

Cálculo del tamaño del equipo El tamaño medio del equipo se obtiene mediante la fórmula siguiente: S = 0,54 E ** 0,6 Donde S (Staff) es el número de personas (media) necesarias para realizar el proyecto según la duración nominal y E es el esfuerzo en Personas/mes.

339

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Ejemplo de Estimación de la Carga Bases del cálculo:

230 días laborables 7,5 horas dedicadas por día 19 días por mes

Para el ANALISIS:

460 días estimados

Factor de productividad Carga (en persona/mes) Duración nomial (meses) Número medio de personas

1 24,00 7,30 3,63

Para la PROGRAMACION:

0,5 47,91 9,29 5,50

298 días estimados

Factor de productividad Carga (en persona/mes) Duración nominal (meses) Número medio de personas

1 15,55 6,27 2,80

Duración total estimada para el proyecto: 13,57

0,7 34,32 8,27 4,50

15,38

17,28

340

0,7 22,23 7,10 3,47

0,5 31,04 7,98 4,24

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12.7

ESTIMACIÓN DE LOS COSTES DE DESARROLLO

Calcular el coste del desarrollo (o de la conversión) de una aplicación implica estimar el tiempo necesario para el desarrollo. Sin embargo, este cálculo no tiene nada de sistemático. Vamos a enunciar algunos métodos, haciendo la salvedad de que el mejor, en términos de aproximación a la realidad, es el método empírico. Nos referimos con ello a la experiencia, al tiempo que ha llevado una aplicación similar, en una máquina idéntica, con un equipo equivalente. De ahí la importancia de documentar bien todo proyecto terminado. Pero tratemos de encontrar una fórmula "mágica". Se estima que , para toda aplicación, el desarrollo de un programa requiere el 40 % de análisis y el 60 % de programación. Por ello se prevé 1 analista por cada 2 programadores, o también 2 analistas por cada 3 programadores. El tiempo de programación (que no debe confundirse con el empleo del tiempo del programador), se distribuye como sigue: Para la programación solamente, los porcentajes son: -

Preparación: 25 % Dicha preparación incluye la administración, la lectura y la comprensión del análisis (apreciación y diseño) y la realización del esquema lógico del programa (flow-chart). -

Codificación: 30 %

-

Pruebas: 35 % Por pruebas entendemos la planificación de las mismas, la creación de datos, las pruebas manuales (desk checking) y las pruebas propiamente dichas: la prueba aisladamente y las pruebas de integración de la aplicación. -

Documentación: 10 %

Estos ratios son generalmente aceptados. Se verifican en la realidad y mediante los cálculos.

341

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

12.8

MÉTODO PMC

Este método se basa en el conocimiento profundo del contenido y de la función de cada programa. Por ese motivo, es poco útil para el desarrollo de nuevas aplicaciones, pero puede ser empleado para conversiones y aplicaciones conocidas. El método, de orientación técnica, está destinado al lenguaje COBOL. No tiene en cuenta útiles de ayuda al desarrollo ni de ingeniería informática. De entrada, se calculan 4 parámetros: F, T, S y C. F

designa el número de ficheros. Se cuenta 1 por fichero (o record-type IDS II) utilizado en el programa. T

designa el número de tipos de records empleados. Se cuenta 1 por tipo de record tratado 1 por tabla interna en el programa 1 por línea de detalle (diferente a otras) y por línea total en los informes

S

designa el número de procedimientos, de "cosas a hacer" en el programa. Se cuenta 1 por fichero actualizado 1 por tipo de record de salida 1 por procedimiento típico (cálculo, validación,...)

C

es el factor de complejidad del programa Puede tomar los valores:

1 ( simple ), listas o copias ).

si hay 1 ó 2 tipos de registros (

2 ( medio ),

para un listado complicado de una

sola entrada, o para una actualización simple. 3 ( difícil ), parametrable, complicada. 342

para un listado complejo o o una actualización

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4 ( complejo ), para una actualización de mas de 40 tipos de registros 5 ( software ),

para un módulo de software

Después interviene una quinta variable: la experiencia del programador. Es el parámetro P, que toma los valores: Valor 200 180 160 140 120 110 100 90 80

Experiencia 3 meses < 6 meses < 9 meses < 12 meses < 18 meses < 24 meses < 30 meses < 36 meses más de 3 años

Como la experiencia crece con la duración del proyecto, en principio se suelen tomar los valores 200 (principiante), 120 (junior), y 80 (experimentado). Se calcula entonces:

X=F+T+S

El resultado obtenido se expresa en horas, y representa la duración de la programación. Se detalla en tiempo de administración (ADM), tiempo de codificación (COD), tiempo de documentación (DOC) y tiempo de pruebas (TEST). ADM = (11 X + C X ) / 24 COD = X / 2 DOC = X / 8 En cuanto a TEST, el cálculo es bastante complicado. Es preciso, primeramente, hallar el número de pruebas a efectuar, que es función de la complejidad de la aplicación y después estimar el tiempo necesario para cada prueba. Dicho tiempo depende de la complejidad del programa y de la experiencia del programador. Vamos a simplificar todo ello considerando que el tiempo de prueba suele ser el 35 % del tiempo total, es decir : 343

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

TEST = ( ADM + COD + DOC ) * 35 / 65 Valor, por otra parte confirmado por las cifras: los valores extremos obtenidos oscilan entre el 33 y el 326,5 %.

Nos queda calcular el tiempo total para un programador medio (índice 100 ) : TOT = ADM + COD + TEST + DOC Después, hay que ponderar este resultado en función de la experiencia del programador: RES = TOT * P / 100 Veamos lo que da respecto a un programa simple (listado de un fichero), y respecto a un programa "difícil" (actualización de un fichero con impresión de resultados). a) Programa simple F = 2 (2 ficheros: entrada y salida) T = 2 (2 tipos de registros) S = 3 (3 procedimientos) X vale entonces 7 (F + T + S) El índice de complejidad es C = 1

TOT

ADM COD DOC TEST RES

3,5 3,5 0,9 4,3

TIEMPO PARA UN PRINCIPIANTE (200) 7 7 1,8 8,6 24,4

344

TIEMPO PARA UN EXPERTO (80) 2,8 2,8 0,7 3,4 9,7

RATIO

29% 29% 7% 35%

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

b) Programa difícil F = 3 ( 1 fichero actualizado, entrada e impresión ) T = 5 ( 5 tipos de registros en total ) S = 6 ( 6 procedimientos ) X vale entonces 14 y C = 3 TOT ADM COD DOC TEST RES

TIEMPO PARA UN PRINCIPIANTE (200)

8,5 7 1,8 9,2

TIEMPO PARA UN EXPERTO (80)

16,4 14 3,6 18,4 52,4

6,5 5,6 1,4 7,4 21,0

RATIO 31% 27% 7% 35%

Primera constatación: hemos hallado proporciones parecidas a las del comienzo. Al tiempo acumulado de la aplicación, es preciso añadir el 40 % de análisis. Dicho porcentaje se calcula sobre un tiempo de programador cuya experiencia se corresponda a la del analista. Conclusiones a extraer sobre este método: - Pone en evidencia el mundo que existe entre un principiante y un experto: el tiempo de desarrollo puede ser multiplicado por 2,5. Con todo, no siempre es mas ventajoso utilizar mano de obra barata. - Muestra que la codificación de un programa no se ve influenciada por la complejidad (C no interviene en el cálculo de COD). Dicho factor sólo influye en los aspectos administrativos del desarrollo y las pruebas.

12.9

MÉTODO BISAD

BISAD (Business Information System Analysis and Design) es un método completo de análisis funcional y orgánico. No es raro que, contrariamente al método precedente, el método BISAD calcule simultáneamente el tiempo de análisis y de programación. Se

345

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

considera que dicho tiempo de análisis toma el 60 % del tiempo total (20 % para el análisis funcional y el 40 % para el análisis orgánico). Dicho método exige un conocimiento menos profundo de la aplicación. De orientación menos técnica, se dirige más bien a aspectos subjetivos del problema. La fórmula es la siguiente: RES = ( A + B ) * C * ( D + E + F ) Dónde: A : experiencia en informática de programadores y analistas 1 = más de 2 años 2 = de 1 a 2 años 3 = poca experiencia B = experiencia en la aplicación 1 = alguna experiencia 2 = poca experiencia C = grado de dificultad de la aplicación 1,5 = conversión simple y documentada 1,75 = conversión parcial y/o poco documentada 2 = desarrollo de un nuevo sistema o conversión no documentada D = grado de dificultad de las entradas-salidas 2 = ficheros / listados poco numerosos 4 = numerosos ficheros / listados 6 = ficheros integrados y estados complejos Nota: si solo se consultan los ficheros, el factor toma el valor 1 ó 2, de acuerdo con la complejidad He aquí otra forma de calcular:

1 2 4 6

Informaciones pasivas Informaciones pasivas

27 -> 24 -> 54 -> Media

9,7 24,4 21 52,4

cifras

desviación 24 % " 10 % " 14 % " 3% ----" 12 %

349

con

los

tiempos

obtenidos

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Dicha desviación es aceptable. El método es facil de utilizar y tiene en cuenta factores que influyen, a menudo negativamente, al proyecto.

Se puede intentar encontrar una fórmula análoga para el análisis, y disociarla así de la programación. El analista no tiene necesariamente el mismo conocimiento de la aplicación que el programador y el grado de dificultad del analista no tiene a menudo nada que ver con la complejidad del programa. La fórmula podría ser: RES = ( A + B ) * 6C Con: A : experiencia del analista en la aplicación 1 = experiencia profunda. Ya ha analizado una situación idéntica, y habla el mismo lenguaje que su interlocutor. 1,5 = conocimiento superficial 2 = poco conocimiento. Algunos problemas con el lenguaje utilizado B : disponibilidad de los interlocutores 0 = siempre disponibles 0,5 = disponibles en la jornada 1 = disponibles 2 veces por semana C : dificultad del análisis 1 a 2 = simple a medio (p.e. pantalla simple) 3 a 4 = difícil ( pantalla complicada, o varias simples ) 5 a 6 = complejo ( entran en juego muchas informaciones; las relaciones son difíciles de captar, varias pantallas complicadas ) Vemos, pues, que un análisis simple toma 6 horas y que el mas complejo exige una inversión de 90 horas. Pero todo ello es especulativo. Las fórmulas que acabamos de ver solo sirven para un conjunto grande de programas, es decir para una aplicación completa. Mediante este último método hemos estimado que el análisis de una determinada aplicación tomaría 1080 horas y la programación 1848 horas. Encontramos la proporción 40-60 ( en este caso: 37-63 ) entre el análisis y la programación. Además, cuando se divide el 350

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

total (2928 horas) por el número de programas (53) se obtienen 55 horas por programa, lo que es una cifra realista a la vista de la complejidad de la aplicación. Empíricamente, y en función de la máquina y de la aplicación, el tiempo medio de desarrollo de un programa debe oscilar entre 40 y 55 horas. Ello sirve para una aplicación completa, compensando los programas pequeños con los más difíciles.

13

ESTIMACIÓN DEL RIESGO

El análisis del riesgo intenta determinar el potencial de un problema en ciernes. Anticipa dicho problema potencial contestando a la pregunta: ¿Qué podría ir mal?. La evaluación del riesgo cataloga como bajo, medio o alto el riesgo de un fallo potencial y el impacto de tal acontecimiento en el proyecto, en la empresa y/o en el personal. El jefe de proyecto decide como tratar el riesgo o como ajustar las técnicas de gestión para tratar dicho riesgo y de esa forma incrementar la probabilidad del éxito del proyecto. El procedimiento para revisar un proyecto con vistas a determinar el tipo y grado de riesgo se basa en un cuestionario. La metodología va dirigida a una cartera de desarrollo de aplicaciones determinada. El procedimiento es parte del proceso de análisis del problema y proporciona otro medio de revisar un proyecto, aplicando un conjunto de herramientas determinadas. También sugiere a la dirección el tipo de jefe de proyecto que debería ser asignado y un conjunto de herramientas para gestionar los diversos tipos de riesgos de proyectos. El método de evaluación de riesgo es una metodología de planificación y como tal debe entenderse. Por ello, dicha metodología no debería ser considerada como un sustituto de la experiencia, juicio y creatividad. Mas bien, debería ser una guía o un vehículo para resaltar esos elementos. RIESGO El riesgo en sí es la probabilidad de que un proyecto u objetivo falle y de las consecuencias resultantes de dicho fallo. El riesgo debe ser

351

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

siempre evaluado como si el impacto fuera para la compañía, el usuario el departamento informático o el equipo de proyecto. Antes de que las probabilidades de fallo puedan ser medidas, se debe determinar con respecto a qué estándar se va a medir dicho fallo. Es extremadamente importante identificar por medio de qué estándar se juzgará al proyecto y quién establecerá dicho estándar. Otro determinante en la medida de la probabilidad de fallo es la respuesta a la pregunta: ¿Qué se necesita?. Ya que muchas personas y grupos están implicados en esta pregunta, las "necesidades" del proyecto pueden variar. Se debe establecer la prioridad de "necesidades" previamente al comienzo del proyecto. Se debería determinar que es mínimamente aceptable de dicha lista. ¿Se puede retrasar el proyecto 2 semanas? ¿Puede el coste del proyecto sobrepasar un 10 %?. Se debe conocer la respuesta a preguntas similares a esta. Finalmente, en todos los proyectos hay un objetivo concreto que trasciende por encima de otros. Este objetivo debe ser identificado por el jefe de proyecto de forma que las técnicas de planificación y control se sujeten constantemente a dicho objetivo. Frecuentemente los proyectos fallan porque la gente no sabe qué constituye el éxito. Hay falta de habilidad en enunciar de forma precisa qué se necesita, unido ello a la falta de predisposición para tomarse el tiempo necesario para describir las características operativas del sistema con la suficiente amplitud para restringir los cambios por libre que puedan llevar a cabo tanto los diseñadores como el usuario. ESTILOS DIRECTIVOS Los estilos directivos se sitúan en la escala del riesgo desde valores muy bajos a valores muy altos. Mas adelante, se describirá en este manual como los estilos directivos corporativos varían de acuerdo con lo anterior. Los estilos directivos están influidos por muchos factores: educación recibida, entorno, edad, estado familiar, posición en la compañía, industria en la que se ha trabajado, empresas para las que se ha trabajado, juventud o vejez de la empresa, estilo directivo de los jefes, y mecanismos de beneficio de la empresa. El estilo directivo de bajo riesgo está caracterizado por la estabilidad, la ausencia de sorpresas o cambios; nada fuera de una historia de éxitos, aunque sean pequeños. Sin embargo, este tipo de director generalmente no tiene la habilidad de retener al personal dinámico y

352

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

emprendedor, y desaprovecha muchas oportunidades por el riesgo que puedan conllevar. Los directivos de alto riesgo quieren hacerse notar rápidamente. Quieren meterse en proyectos cuya renta sea el reconocimiento por el éxito logrado. Su objetivo es estar en un puesto concreto durante 2 ó 3 años como máximo. Desgraciadamente, muchas veces este tipo de director es un individuo de tipo A; un ejecutor que no puede emplear tiempo en planificar o controlar los proyectos de alto riesgo de los que se ocupa. Por ello, un jefe de alto riesgo debe delegar en un miembro de su equipo que efectúe las referidas funciones, pues de lo contrario se arriesga a no lograr los objetivos. Los directivos de alto riesgo desaprovechan proyectos pequeños y seguros u oportunidades de negocio y generalmente frustran al personal mas conservador. El directivo de riesgo medio generalmente cumplirá los objetivos de la organización en base a proyectos de poco riesgo u oportunidades de negocio y mediante proyectos de alto riesgo aceptados selectivamente. Los directivos de riesgo medio no temen los fallos, porque su éxito no depende solamente de los proyectos de alto riesgo.

FUENTES METODOLOGICAS El método de evaluación de riesgos presentado en este manual está adaptado básicamente a los estudios y conclusiones de F. Warren Mc. Farlan, del Harvard Business School. Mc Farlan examinó 25 proyectos informatizados en 4 grandes organizaciones, para determinar que tiene que ver el éxito y el fracaso de proyectos con el departamento de informática, y sugería principios para gestionar proyectos con diversos grados de riesgo. Su manual se titula Effective EDP Project Management (Hardvard College, 1973). Además, el mismo manual de Mc Farlan utiliza material del Dallas Tyre Corporation Case preparado por el profesor James I. Cash, del Harvard Business School, con licencia de copia de 1979 por el Presidente y miembros del Harvard College y distribuidos por Intercollegiate Case Clearing House, Boston, MA 02163, asi como del artículo de F. Warren Mc Farlan titulado "Portfolio Approach to Information Systems", publicado en la Harvard Business Review de Septiembre-Octubre de 1981.

353

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

BALANCE DE LA CARTERA DE PROYECTOS Una edición de la planificación estratégica de las actividades de la dirección de sistemas de información (dentro del contexto de las necesidades y objetivos de la compañía, consiste en el balance de la cartera de proyectos de aplicaciones que implican especificaciones funcionales, diseño y desarrollo de sistemas, programación e implantación. ¿Por qué queremos hacer esto? Por la misma razón por la que se debe hacer balance de la cartera de inversiones; para mejorar el beneficio potencial. Una cartera de sistemas que contenga demasiados proyectos de alto riesgo crea un escenario de fallos en el logro de los objetivos de la organización. Por otra parte, demasiado énfasis en los proyectos de bajo riesgo conduce en definitiva a la inhabilidad de captar provechosas oportunidades. Al confiar en principios y tecnologías mas seguros pero anticuados, en lugar de introducir gradualmente innovaciones, necesitamos un salto mas traumático desde la posición vieja a la nueva. En orden a aprovecharse de nuevas tecnologías, nuevos entornos, beneficios financieros de grandes sistemas, selección y retención de profesionales de calidad, se deben emprender proyectos de sistemas de alto riesgo. Por otro lado, para ayudar a conseguir el éxito en la implantación de sistemas de alto grado (en términos de cumplimiento de presupuestos y especificaciones funcionales), se deben emprender sistemas de bajo riesgo. Obviamente, ninguna organización de proceso de datos puede dedicar sus esfuerzos totales a ninguno de los dos casos. La situación ideal es lograr el equilibrio entre los proyectos de alto y bajo riesgo. Teniendo la dirección de sistemas de información la habilidad de asignar significativamente (aunque algo subjetivamente) valores de riesgo a los proyectos, posibilita mantener un equilibrio de riesgos en la cartera, para un periodo de 3 a 5 años. Mientras estemos todavía hablando de las actividades del departamento de sistemas de información, se pueden desarrollar métodos similares de evaluación de riesgos para otros tipos de proyectos o responsabilidades. EVALUACION DEL RIESGO El método de evaluación del riesgo se debería realizar en todos los proyectos de programación del departamento de sistemas de información. De igual manera que una cartera representa todas las 354

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

inversiones sin tener en cuenta el tamaño, lo mismo debe ocurrir con la cartera de sistemas. Si una organización no utiliza el método de cartera de sistema, debería aplicar evaluación de riesgos a aquellos proyectos que sean: * Complejos - por su tamaño, hardware/software o dificultad * Importancia - para la compañía o los individuos implicados en el proyecto. * Susceptibles de revisión por la Dirección - la esencia del proyecto puede ser comunicada con eficacia.

OBJETIVOS PRINCIPALES DEL PROYECTO El procedimiento de Evaluación de Riesgos identificará el grado de probabilidad con la cual podría fallar en la consecución de los objetivos principales críticos, técnicos, de tiempo y de costo. Dichos objetivos principales críticos están presentes en todos los proyectos en diversos grados. También, como se verá más adelante, hay objetivos principales y secundarios que son dependientes del proyecto. La evaluación del riesgo del proyecto debería ser efectuada en las etapas críticas del proyecto, con el fin de que engarzaran con las estrategias de la gestión. El método estima la probabilidad de que un proyecto o sistema no cumpla los siguientes objetivos: * Técnicos - Necesidades del usuario respecto a: - Especificaciones funcionales - Objetivos del sistema o proyecto - Beneficios - Formación * Tiempo - Nivel de esfuerzo - Horas-Persona - Tiempo transcurrido - Requisitos de pruebas - Documentación * Coste - Estimación del presupuesto - Acerca del presupuesto - ROI no cumplido 355

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

La evaluación del riesgo del proyecto conduce a la toma de decisión por parte de la dirección. Su finalidad es proporcionar criterios de selección que ayuden al director de sistemas de información o al jefe de proyecto a identificar, evaluar y controlar los factores que afectan al éxito del proyecto. Esta técnica está intrínsecamente unida a la gestión del proyecto porque su propósito es hacer que el proyecto alcance sus resultados (objetivos técnicos) en el periodo proyectado (objetivo temporal) al o por debajo del presupuesto concedido (objetivo de costo). La evaluación del riesgo debe ser un proceso dinámico. Ya que los riesgos cambian, se deberían hacer revisiones en las diversas etapas del proyecto y actualizaciones periódicas. FACTORES RELATIVOS QUE AFECTAN LOS VALORES DEL RIESGO El método de evaluación de riesgos toma en cuenta los siguientes criterios: * Flexibilidad

- estructura de proyecto

* Tamaño personal

- duración del proyecto, y cantidad y tipo de

* Tecnología

- complejidad del hardware y software

Antes de revisar extensamente dichos criterios se debe subrayar que, debido a determinados factores, dichos criterios varían según las organizaciones, de forma que los valores del riesgo del proyecto variarán de una empresa a otra. Dichos factores pueden causar que un proyecto similar sea evaluado por una empresa a bajo riesgo y por otra a alto riesgo. A continuación se describen los factores principales que causan las referidas variaciones. ESTILO DIRECTIVO CORPORATIVO Las empresas que se ven a si mismas como líderes tecnológicos e influyentes en las tendencias de la industria acometen los proyectos que parecen contener mayor riesgo. Frecuentemente, atacan entusiastamente lo que no se había hecho antes. 356

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Otras empresas están caracterizadas por su dirección estable y conservadora. Evidentemente dichas empresas no son líderes. Su cartera de sistemas contiene lo que a un observador neutral le parece un buen número de sistemas y proyectos de programación de bajo riesgo. Los slogans que personifican dichas empresas son: "Que se quemen los pioneros", "Solo toleramos el éxito", "Haz únicamente lo que se ha probado con éxito un número incontable de veces en otro sitio", "Los que están en el filo de la tecnología se cortarán". SECTORES El sector de un empresa puede también determinar si la cartera de sistemas tiene riesgo alto o bajo. Hay ciertos sectores que, debido a su naturaleza competitiva y los servicios o productos proporcionados, deben emprender proyectos de alto riesgo por su dependencia estratégica u operativa de dichos proyectos. Ejemplos palpables de ello son los sectores financieros, la banca y los seguros. En el mundo de la banca, las organizaciones comerciales, de ahorro, préstamo, tarjetas de crédito, etc, ofrecen servicios electrónicos competitivos para capturar y retener el mecanismo de pago de depósitos. Las empresas de este sector deben estar en la brecha frente a la competencia. El sector aeronáutico depende operativamente de los sistemas de reserva de líneas aéreas. Recientemente, los principales transportistas han intentado automatizar, con limitado éxito, su sistema de descuentos en reservas basados en el destino, horario del vuelo, plazas cubiertas, número de componentes de grupos, número de días previos al vuelo dela fecha de reserva, adelanto de pago requerido, etc. Dichos proyectos de alto riesgo se emprendieron para proporcionar mejor servicio al cliente y por lo tanto obtener una participación mayor en el mercado. Por el contrario, las empresas de otros sectores en donde hay menos dependencia de la informática tienden a tener cartera de sistemas de bajo riesgo.

PERSONAL DE LA DIRECCION DE SISTEMAS DE INFORMACION A diferentes organizaciones corresponden diferentes areas de experiencia técnica. Tanto la dirección de sistemas de información como los grupos de usuarios, que dependen del tamaño del 357

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

personal de su departamento de sistemas de información, pueden tener diferentes opiniones acerca de qué es un proyecto pequeño o grande. Hay características del personal de la dirección de sistemas de información que hacen crítico trabajar con una cartera de alto riesgo. El personal debería ser: * Estable, en lugar de recién incorporado * Experto en sistemas de desarrollo * Experto en proyectos considerados críticos respecto a entregas presentes y futuras de servicios corporativos y sistemas de soporte a las decisiones. * No implicados en fracasos de proyectos importantes, en los últimos 2 años * Trabajar con hardware y software actualizado TIEMPO También, la determinación del valor del riesgo y su posicionamiento, que se estudiará mas adelante, está basado en el estatus de una organización individual en un punto determinado del tiempo (nivel de formación, experiencia con cierto hardware y/o software, personal de proyectos, etc.). Lo que hoy, debido al nuevo hardware o software, un proyecto puede ser calificado de alta tecnología. Cuatro meses mas tarde, por haber adquirido mas formación y experiencia en el nuevo hardware o software, y por haber contratado nuevos empleados experimentados, el mismo proyecto puede no ser considerado de alta tecnología.

DIFERENTES CARTERAS Se puede llegar al equilibrio de la cartera de desarrollo de aplicaciones de las empresas, en alguna de las situaciones descritas anteriormente, por medio de diferentes perspectivas del riesgo. Para un observador imparcial, puede parecer que las instituciones financieras tienen cartera de alto riesgo y las empresas con poca o nula dependencia de los proyectos de la dirección de sistemas de información tienen cartera de bajo riesgo. Si las carteras de desarrollo de aplicaciones de los dos tipos de empresas se mezclaran y se aplicara la metodología de evaluación de riesgo a las aplicaciones de desarrollo, los valores del riesgo estarían situados a los dos extremos del espectro de riesgo y no habría equilibrio. 358

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

DIVERSIDAD DE PROYECTOS No todos los proyectos de desarrollo de sistemas son semejantes. El método de valoración de riesgos distingue entre proyectos de riesgo pequeño, medio o grande, estando el riesgo definido por criterios de tamaño tecnología y flexibilidad. La discusión del riesgo puede ser útil ya sea para quienes trabajan en un proyecto individual o bien para un departamento. No solamente puede este análisis sistemático reducir el número de fallos, sino que también sirve igualmente como potente enlace de comunicación, ayudando a los directivos de sistemas de información y ejecutivos senior a llegar a acuerdos en la aceptación de riesgos con respecto a objetivos corporativos. La moral puede mejorar bastante si tanto los usuarios como los diseñadores tienen un entendimiento común del riesgo de un proyecto dado. ELEMENTOS DE RIESGO El método de valoración de riesgos se dirige al entorno corporativo, en donde tres elementos principales determinan el nivel de riesgo de un proyecto de sistemas o de programación FLEXIBILIDAD Un proyecto de alta flexibilidad (no muy estructurado) aporta poco grado de certidumbre en lo que respecta a cómo deberían ser los resultados. En este tipo de proyecto ninguna especificación funcional tiene que ser desarrollada. En un proyecto flexible, los parámetros pueden evolucionar a medida que avanza el proyecto. Una utilidad de informática distribuida corporativa es un ejemplo de proyecto de alta flexibilidad. Un proyecto con baja flexibilidad (muy estructurado) es aquel en que hay pocas o ninguna opción de diseño abiertas al arquitecto del sistema o al usuario, porque los parámetros son conocidos y/o hay especificaciones funcionales predeterminadas. Un paquete de software, p.e., o la mejora de un sistema automático existente, podrían ser casos de baja flexibilidad por alta estructuración.

359

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

TECNOLOGIA La tecnología, tal como se entiende aquí, significa el grado de tecnología informática implícito al proyecto. Un proyecto de alta tecnología implica aspectos complejos de hardware/software con los que no se ha tratado previamente, por parte del grupo de implantación corporativo , incluso aunque otros grupos de dicha organización los utilicen cotidianamente. Decimos el "grupo de implantación", los miembros del equipo de proyecto, no la empresa o el grupo corporativo de dirección de sistemas de información. Un proyecto de baja tecnología es el que implica aspectos con los cuales está familiarizado el departamento de implantación, aunque otros departamentos no estén trabajando con ellos. Por ejemplo, un equipo instalado en la Asian Division de Citicorp puede ser considerado como de alta tecnología, porque es el primer sistema de ese tipo en ser instalado, mientras que el mismo sistema instalado en una ciudad de USA por la New York Division de Citicorp podría ser considerado de baja tecnología al existir 237 sistemas ya instalados. TAMAÑO Se refiere al total de horas-personas de esfuerzo, y a la duración del proyecto en meses, mas un número de indicadores de complejidad. La definición del tamaño viene determinada por la empresa en particular, y variará por factores tales como el personal de sistemas de información y la experiencia previa en proyectos. Una empresa ve el tamaño a partir de los siguientes ejes: * Grande más de 20.000 horas-personas o mas de 24 meses. * Medio entre 4.000 y 20.000 horas-personas o entre 13 y 23 meses. * Pequeño menos de 4.000 horas-personas o menos de 12 meses. A efectos de estimación, 2.000 horas-personas equivalen a 1 persona-año. La complejidad de un proyecto debe ser considerada a partir del elemento tamaño. La complejidad se refiere al tipo, número y variedad de habilidades requeridas en el proyecto y su duración. El tamaño, como hemos dicho, se divide en tres dimensiones. Sin embargo, con vistas al método de valoración del riesgo, sólo se utilizan dos (p.e. pequeño o grande). Lo que ha sido definido como

360

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

medio puede ser pequeño o grande dependiendo de como conciba el tamaño la propia empresa. Se dan ejemplos de dichas dimensiones con mas detalle en la sección dedicada al cuestionario. CLASIFICACION Utilizando tres divisiones, un proyecto puede ser clasificado dentro de una de las ocho categorías que van desde riesgo muy pequeño a muy grande. En general, el alto riesgo se correlaciona con la gran flexibilidad y la alta tecnología, aunque cualquier proyecto cuya duración (tamaño) sea mayor de 20 meses debería ser considerado de alto riesgo. TABLA DE VALORACION DEL RIESGO Las siguientes tablas son útiles para clasificar proyectos. Son parte integral de la metodología de evaluación de riesgos de proyectos.

bajo baja flexibilidad baja tecnología tamaño pequeño A

alto/medio alta flexibilidad baja tecnología tamaño pequeño C

medio baja flexibilidad alta tecnología tamaño pequeño E

alto alta flexibilidad alta tecnología tamaño pequeño G

baja flexibilidad baja tecnología tamaño grande B

alta flexibilidad baja tecnología tamaño grande D

baja flexibilidad alta tecnología tamaño grande F

alta flexibilidad alta tecnología tamaño grande H

A = riesgo más bajo más alto

H

361

=

riesgo

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Flexibilidad T e

b a

c n

j a

o l o g.

baja muy baja A

alta baja/media C

pequeño

baja B

baja/media D

grande

a m

a l

media E

alta G

pequeño

a ñ

t a

media F

alta H

grande

o

A = riesgo más bajo,

T

B = riesgo más alto

El uso de estas tablas reafirma el que la diversidad de proyectos requiere diferentes estilos directivos. Lo interesante de la segunda figura que hemos visto es que indica que un proyecto es de alto riesgo cuando tanto la flexibilidad como la tecnología son altas, independientemente del tamaño del proyecto. Cuando la tecnología es alta y la flexibilidad es baja el proyecto es de riesgo medio, independientemente de su tamaño. Cuando las flexibilidad es alta y la tecnología es baja, el proyecto es de riesgo medio, independientemente del tamaño. La planificación formalizada y las herramientas de control ayudan en la gestión del tamaño. El mayor riesgo inherente al tamaño es la duración del proyecto. Los proyectos de tipo D cuya duración es mayor de 20 meses son, por definición, de alto riesgo. Los proyectos de mas de 12 meses deben ser revisados para determinar si pueden ser ejecutados en proyectos mas pequeños. IMPLICACIONES DIRECTIVAS El riesgo relativo de un proyecto tiene importantes implicaciones para el jefe de proyecto. Un proyecto de alto riesgo debidamente dirigido puede lograr sus objetivos, mientras que un proyecto de bajo riesgo indebidamente dirigido puede fallar. Después de usar las tablas anteriores para clasificar proyectos en diversos tipos, el jefe puede determinar que tipo de dirección se adapta mejor a cada tipo de proyecto.

362

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El posicionamiento del proyecto en la tabla es significativo en la determinación del impacto de la planificación formalizada y/o herramientas de control y la necesidad de integración interna y externa.

HERRAMIENTAS DE GESTION DE PROYECTOS PLANIFICACION Las herramientas de planificación de proyectos deben incluir: * PERT, etc - red que permite representar gráficamente el proyecto * Especificaciones funcionales - documentación detallada en lenguaje corriente sobre las prestaciones del sistema, descripción de las entradas (volumen, origen, captura, edición, etc), proceso, y salidas (formatos, frecuencia, distribución, seguridad, etc). El documento tendrá que ser validado por los responsables de los usuarios y el jefe de proyecto. * Utilización de simulación de sistemas * Diseño de sistemas detallado * Procedimientos a seguir después de auditorías CONTROL Las herramientas de control formalizado deben incluir: * PERT, PERT-COST o CPM durante la implantación del proyecto * Procedimientos para medir, en dinero, los empleos de tiempo * Procedimientos de control de calidad * Revisión de la gestión de base * Informes periódicos de estatus, versus plan * Procedimientos de control de los cambios * Desviaciones con respecto al plan. INTEGRACION La integración se refiere a los métodos utilizados para asegurar la coordinación entre los participantes o unidades que diseñan e implantan el proyecto. La gestión del proyecto y el personal del usuario es la clave del éxito del proyecto. INTEGRACION INTERNA Implica al equipo de diseño del departamento de sistemas de información y otras unidades de dicho departamento. 363

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las técnicas directivas usadas para llevar a cabo la integración interna son: * Mantener reuniones del comité de seguimiento técnico con el personal clave * Elegir un jefe de proyecto con competencia técnica (para proyectos de cierta envergadura tecnológica) * Usar diagramas de flujo, tablas de decisión y otra documentación para resaltar los interfaces existentes entre los componentes clave del sistema. * Dirigir revisiones de estado técnico con regularidad * Utilizar asistencia técnica externa * Incluir la participación de los miembros del equipo en el desarrollo de hitos. * Asegurar (todo lo que sea posible) la continuidad de los miembros del equipo de proyecto INTEGRACION EXTERNA Implica a grupos del departamento de sistemas de información y a grupos de usuarios. Los requisitos son: * El jefe de producto debe ser enlace entre el departamento de sistemas de información y los grupos de usuarios * Reuniones periódicas con los usuarios y el comité de seguimiento de proyecto * Asignación de uno o mas usuarios como miembros del equipo de diseño de proyecto * Información sobre el proyecto distribuida periódicamente a los responsables de los usuarios * Procedimientos formalizados para que los usuarios aprueben las especificaciones funcionales, el diseño general y los cambios sucesivos * Conocimiento efectivo del jefe y del personal del proyecto por los departamentos de usuarios 364

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

* Lista de entregas programadas y sus fechas * Procedimiento de control de modificaciones para los usuarios TIPOS DE PROYECTO Y SU GESTION De acuerdo con los diferentes niveles y tipos de riesgo de proyecto tenemos diferentes tipos de gestión. Mc Farlan clasifica los proyectos de la siguiente manera: PROYECTOS DE TIPO A Poca flexibilidad, baja tecnología, tamaño pequeño. Debidamente gestionados, estos proyectos conllevan muy poco riesgo. Las herramientas de control contribuyen a ello, pero no son tan necesarias como en un proyecto grande. Los procedimientos de integración interna son relativamente poco importantes. La integración externa es válida en la fase de instalación. PROYECTOS DE TIPO B Poca flexibilidad, baja tecnología, tamaño grande. Debidamente gestionados, estos proyectos conllevan relativamente poco riesgo. Las técnicas de planificación y control son importantes para el éxito del proyecto. La integración interna es importante al coordinar la interrelación del trabajo de mucha gente. La integración externa parece tener relativamente poco significado. El impacto de la poca flexibilidad parece implicar menos necesidad de integración externa, excepto (y esto es importante) cuando el proyecto fuerza cambios significativos en los procedimientos de los departamentos de usuarios. GESTION DE PROYECTOS DE TIPO A Y B Los proyectos de tipo A y B ocurren poco frecuentemente. Son el tipo de proyecto mas fácil ya que sus técnicas usuales de control para medir costos e hitos son muy fiables. Los jefes de proyecto no necesitan competencia en sistemas de información ni tener que desarrollar procesos administrativos extensos para conseguir que los diversos grupos de usuarios acuerden y mantengan las estructuras de diseño. El personal del proyecto requiere solamente competencias técnicas medias. Este tipo de proyectos es excelente para que ganen experiencia los futuros jefes de proyecto. 365

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Una cartera repleta de este tipo de proyectos produce fastidios a los jefes de proyecto y responsables de usuarios experimentados. PROYECTOS DE TIPO C Gran flexibilidad, baja tecnología, pequeño tamaño. Debidamente gestionados, estos proyectos conllevan relativamente poco riesgo. Sin embargo, éste es un tipo de proyecto en el que pueden surgir fácilmente problemas de gestión. La integración externa es el factor mas importante. La planificación formalizada y el control pueden ser efectivos si se hace bien la integración externa. Las herramientas de planificación en los proyectos de tipo C tienen menos impacto que en los proyectos de tipo D por el menor número de personas y reducida complejidad. Los procedimientos de integración interna son relativamente poco importantes.

PROYECTOS DE TIPO D Gran flexibilidad, baja tecnología, tamaño grande. Debidamente gestionados, estos proyectos conllevan poco o mediano riesgo. En este tipo de proyectos, como los de tipo C, pueden surgir fácilmente problemas de gestión. La integración externa es el factor mas importante. Es importante el previo compromiso por parte del usuario con un diseño en particular. Si se hace mal la integración externa las herramientas de control servirán solo para constatar lo mal que se ha hecho. Si se hace bien la integración externa, las herramientas de planificación y control pueden ser efectivas para asegurar un riesgo pequeño. La integración interna es importante para coordinar las interrelaciones de trabajo de los miembros del equipo.

GESTION DE PROYECTOS DE TIPO C Y D La clave para gestionar los proyectos de tipos C y D descansa en el esfuerzo efectivo para implicar al usuario. Estos proyectos requieren una gestión agresiva de la integración externa, complementada por herramientas de planificación formalizada y control.

Es esencial para el éxito del proyecto desarrollar soporte de usuario para criterios de diseño y evitar modificaciones del usuario a dicho diseño. Las funciones críticas de este procedimiento implican:

366

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

* El usuario debe ser un miembro competente del equipo de proyecto * Establecimiento de un comité de revisión de diseño para evaluar el diseño y las opciones de selección. * Subdivisión del proyecto en pequeñas tareas como si fuera un proyecto de tipo B * Reuniones formales y aprobaciones (por escrito) de las especificaciones funcionales * Retención de los miembros del equipo de proyecto En estos proyectos, el liderazgo debe provenir del usuario mas que del grupo técnico. Una vez que el diseño se ha finalizado aumenta el liderazgo del usuario.

PROYECTOS DE TIPO E Poca flexibilidad, alta tecnología, pequeño tamaño. Debidamente gestionados, estos proyectos conllevan riesgo mediano. Las herramientas de planificación y control contribuyen en poco. La integración externa contribuye relativamente en poco, a no ser que sea en la fase de instalación. Los procedimientos de integración interna parecen ser muy críticos. La competencia técnica del jefe de proyecto es de la mayor importancia.

PROYECTOS DE TIPO F Poca flexibilidad, alta tecnología, gran tamaño. Debidamente gestionados, estos proyectos conllevan riesgo mediano. La integración interna es muy crítica. La planificación formalizada y el control, por tener que ser flexibles, requieren mas cuidado y juicio que en los proyectos de tipos A y B. Sus contribuciones, sin embargo, al éxito del proyecto, son mínimas. La integración externa contribuye en poco , excepto en la fase de instalación. GESTION DE PROYECTOS DE TIPO E Y F Los proyectos de tipos E y F requieren un jefe de proyecto con claras competencias administrativas y con un conocimiento medio sobre sistemas de información. Las competencias administrativas requeridas son proporcionales al tamaño del proyecto. La integración interna es de importancia clave, porque la tecnología seleccionada para la implantación puede ser inadecuada y las 367

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

principales revisiones del proyecto hechas por el usuario tienen que ser consideradas. Por la incertidumbre tecnológica, los métodos de planificación y control normales pueden ser algo limitados. Dichos métodos tienden a ser mas subjetivos que tangibles y deberían ser reconocidos como tal. Los jefes de sistemas de información o ejecutivos de alto nivel pueden creer que tienen planificación y control precisos sobre tales proyectos, cuando de hecho no es así.

PROYECTOS DE TIPO G Gran flexibilidad, alta tecnología, pequeño tamaño. Incluso debidamente gestionados, estos proyectos conllevan riesgo muy alto. La integración externa es particularmente crítica en lo que se refiere al compromiso del usuario copn la estructura final del sistema y resultados. La integración interna es menos crítica. La planificación formalizada y el control parecen hacer solo una pequeña contribución.

PROYECTOS DE TIPO H Gran flexibilidad, alta tecnología, gran tamaño. Incluso gestionados debidamente, estos proyectos conllevan un riesgo muy alto. La decisión puede ser crítica si el riesgo es tan grande, que requiera la ruptura del proyecto en pequeñas piezas o incluso que se abandone. Tanto la integración interna como la externa son particularmente importantes. Las herramientas de planificación y control tienen valor limitado en cuanto a la reducción del riesgo. GESTION DE PROYECTOS DE TIPO G Y H Los proyectos de tipos G y H son complejos y requieren jefes de proyecto con experiencia técnica, asi como conocimiento y habilidad para comunicar con los usuarios. Deben dirigir sus esfuerzos hacia la integración externa, porque es crítico el compromiso total del usuario con un conjunto de especificaciones. La implicación del usuario tanto a nivel político como operativo, es esencial, porque la viabilidad técnica puede verse alterada durante el proyecto, lo cual, a su vez, puede conducir a la redefinición o terminación del proyecto. Las herramientas de planificación y control son de poco valor para identificar problemas o reducir la incertidumbre en las fases iniciales 368

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

del proyecto. De hecho, son de poco valor durante el proyecto, ya que siempre aparecen nuevas tareas y las planificadas pueden variar de importancia. También es imposible predecir simultáneamente tiempo, costo y fechas con respecto a los hitos. RESUMEN SOBRE LOS TIPOS DE PROYECTOS

La Tabla 1 resume cada tipo de proyecto, su riesgo potencial, y las herramientas de gestión que se pueden usar para lograr el éxito en el proyecto.

369

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

TABLA 1. RESUMEN DE TIPOS DE PROYECTOS Tipo de proyecto

descripcion del proyecto

tipo de riesgo

integ. ext.

integ. int

planif. contro l

A

poca flexibilidad baja tecnología pequeño

muy bajo

bajo

bajo

medio

alto

B

poca flexibilidad baja tecnología grande

bajo

bajo

medio

alto

alto

C

gran flexibilidad baja tecnología pequeño

bajo/medio

alto

bajo

medio

alto

D

gran flexibilidad baja tecnología grande

bajo/medio

alto

medio

alto

alto

E

poca flexibilidad alta tecnología pequeño

medio

bajo

alto

bajo

bajo

F

poca flexibilidad alta tecnología grande

medio

bajo

alto

G

gran flexibilidad alta tecnología pequeño

alto

alto

alto

bajo

bajo

H

gran flexibilidad alta tecnología grande

alto

alto

alto

bajo

bajo

370

medio medio

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

EVALUACION Y APLICACION DEL RIESGO La evaluación del riesgo se debe llevar a cabo en las diversas etapas del proyecto, es decir: * Estudio de viabilidad * Iniciación del proyecto * Análisis y diseño previos * Análisis y diseño detallados * Implantación En la etapa del estudio de viabilidad, la evaluación se puede hacer "a ojo". Sin embargo, es importante llevar a cabo el procedimiento, porque puede revelar los pasos que habría que dar para evitar el riesgo. La evaluación del riesgo del proyecto tendrá un valor comprendido entre A y H. En cada etapa sucesiva, los principios directivos en las áreas de integración, planificación y control se deben ajustar de acuerdo con el nivel de riesgo que revela la evaluación del mismo. A medida que progresa el sistema, los valores del riesgo decrecen, lo cual indica que el sistema está progresando adecuadamente. Un incremento en el potencial de riesgo es una señal de peligro. La alta dirección debería ser informada si se desarrolla una condición excepcional. ALCANCE DEL RIESGO Los proyectos de alto riesgo deben identificar siempre si el riesgo de fallo está en el proyecto, el usuario, el jefe de proyecto, el equipo de proyecto o la empresa. Se pueden aplicar factores de ponderación a los valores del riesgo, indicando el impacto de dicho riesgo. CRITERIOS DE RIESGO ADICIONALES Los criterios de evaluación de riesgo comienzan cuando se ha llegado a un acuerdo entre el jefe de sistemas de información, los responsables de los usuarios y la alta dirección, sobre el alcance del proyecto, la fecha de terminación y los costos. Si hay desacuerdo de alguna índole, el proyecto cobra una dimensión añadida de riesgo. Los resultados del método de evaluación de riesgos deben entrar como factores en dicho riesgo adicional. 371

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

CUESTIONARIO Es de importancia crítica asegurarnos que las diferentes personas que evalúan el proyecto lleguen a las mismas conclusiones respecto de la evaluación del riesgo. Como es incierto el mejor método para hacerlo, la técnica que está ganando mas aceptación es la del uso del cuestionario que se presenta a los usuarios clave y al jefe de proyecto previamente a la aprobación e implantación del proyecto. Se reconcilian las diferencias en las respuestas. El cuestionario identifica el potencial de riesgo del proyecto, de acuerdo con su flexibilidad, tecnología y tamaño. El cuestionario consta de 69 preguntas.

PREGUNTAS, VALORES Y PONDERACIONES El cuestionario es un medio estructurado que proporciona un buen punto de partida en la dilucidación del riesgo del proyecto. No es en ningún modo perfecto, y puede ser adaptado a necesidades individuales. No hay ciencia precisa detrás de las preguntas, sus ponderaciones o valoraciones de las respuestas. Los valores y ponderaciones representan la experiencia empírica del usuario. Por ejemplo, la instalación número 38 de un sistema de telecomunicaciones en una compañía de seguros representa un riesgo bajo relativo a la estructura y tecnología, mientras que una compañía de fabricación que instala su primer sistema de captura de datos de fábrica puede presentar un riesgo alto relativo a la flexibilidad y la tecnología.

El cuestionario es flexible en cuanto a que se pueden cambiar o suprimir ponderaciones o valoraciones de respuestas, se pueden sustituir o añadir nuevas preguntas, o se pueden variar las respuestas. Si se efectúan cambios, se debe alterar el rango (máximo menos mínimo) de cada una de las tres categorías de riesgos (tamaño, flexibilidad y tecnología que van en las preguntas. El cuestionario es un patrón de reconocida eficacia para que los usuarios midan el riesgo. Se utilizan diversas versiones de este cuestionario en la mayoría de las grandes empresas. Se deben contestar todas las preguntas del cuestionario, excepto aquellas que no sean aplicables al proyecto. La ponderación 372

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

máxima y mínima se deben descontar de dichas preguntas. Las posibles respuestas a cada pregunta son: A = alto, M = medio, B = bajo. En algunos casos, el usuario debe elevar o descender la puntuación numérica de un campo concreto, de acuerdo con las características especiales de su proyecto. Por ejemplo, suponga que la respuesta a la pregunta 14 sea "actualización batch con transacción on-line", pero la transacción on-line no es relevante para el sistema. En ese caso, la puntuación de M-2 a la pregunta debería ser M-3. Es decir, el buen criterio es un factor clave para contestar a las preguntas.

373

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

14

RECURSOS DE DOCUMENTACIÓN

Los diversos proyectos de planificación, diseño, desarrollo e instalación del Sistema de Información, que tienen lugar en la Empresa, exigen la elaboración de una documentación extensa, la cual debe ser convenientemente estructurada y gestionada.

14.1

INFORMES

Una dificultad inherente a la gestión de proyectos se refiere a la redacción de informes. Dicha dificultad se refiere tanto al contenido como a la presentación. ¿Qué es preciso poner en el informe? ¿Cómo hay que presentarlo?. No hay que perder de vista que en la gestión de un proyecto, la mayoría de los informes sirven de soporte a la toma de decisiones y que son leídos por los miembros de la Dirección. Deben, pues, ser sintéticos y completos. Vamos a describir como redactar informes como el cuaderno de cargas (después del Estudio Previo), los planes de acción (después del Esquema Director) o simplemente un informe para el comité de seguimiento. Capítulos que deben contener: 1) Organización a implantar, con la lista de las tareas a efectuar, personas afectadas a cada tarea. 2) Competencias necesarias para realizar dichas tareas, tanto internas como las que se deben adquirir del exterior. 3) Calidad que debe presentar el producto, con las medidas que será preciso efectuar para poder evaluarla (recepción del producto). 4) Informaciones que serán necesarias para llevar a cabo las tareas a realizar, con los nombres de las personas que son susceptibles de proporcionarlas. 5) El impacto que la realización de las tareas tendrá sobre los usuarios, función, condiciones de trabajo, procedimientos, competencia, relaciones en el trabajo, ergonomía, etc. 374

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

6) Planificación de realización y de recursos. 7) Coste de realización de las tareas previstas, con las necesarias variantes: tareas alternativas, modificaciones en las competencias, aumento o disminución de los recursos con su impacto en la planificación, avance o retraso en la ejecución de tareas con impacto en la duración del proyecto, etc. El conjunto de todas estas informaciones permite tomar decisiones con conocimiento de causa. La completitud del expediente remitido al comité de seguimiento le hace mas plausible, facilita la decisión y permite al proyecto avanzar sin trabas administrativas. Una de las claves del éxito del proyecto está en la calidad de los informes que se producen.

14.2

MANUAL DE PROCEDIMIENTOS

El Manual de Procedimientos es la fuente de información que permite al personal de una Organización -

La ejecución de tareas normalizadas La comunicación con las diversas áreas de la empresa y con entidades externas.

El Manual de Procedimientos debe estar permanentemente actualizado La existencia de Manual de Procedimientos proporciona las siguientes ventajas

375

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El Manual de Procedimientos tiene el siguiente contenido 1 2 3

Introducción Instrucciones Terminología

A modo de ejemplo, adjuntamos el índice de un Manual de Procedimientos

376

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

377

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

14.3

GUÍA DE USUARIO

Se refiere a la utilización de un sistema. 1. OBJETIVOS DEL DOCUMENTO El Manual de Usuario debe proporcionar una comprensión general del sistema y proporcionar normas de utilización. Debe contener capítulos específicos acerca de cada tipo de actividad, para satisfacer los requisitos de todo tipo de usuarios. Asimismo debe contemplar las normas de seguridad y confidencialidad. La calidad de este tipo de manual se mide en términos de: * La facilidad con la cual se puede entender y utilizar ( claridad de estructura y contenido, relevancia de ejemplos, calidad de presentación, etc ) * Facilidad de poder ser actualizado

2 DESTINATARIOS

378

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El manual va destinado a los usuarios del sistema 3. CONTENIDO CAPITULO 1.

INTRODUCCION

1.1. Finalidad del manual 1.2. Destinatarios 1.3. Estructura del manual 1.4. Convenios 1.5. Referencias CAPITULO 2.

VISION GENERAL DE LA APLICACION

2.1. Contexto 2.2. Estructura de los datos 2.3. Funcionalidades 2.4. Relaciones con otras aplicaciones CAPITULO 3.

LENGUAJE DE USUARIO

3.1. Introducción 3.2. Descripción del teclado 3.3. Conexión 3.4. Características de operación normal 3.5. Acceso a la documentación 3.6. Desconexión 3.7. Instrucciones en caso de fallo CAPITULO 4.

DESCRIPCION DE LAS CONFIGURACIONES

4.1. Encadenamiento de procesos 4.2. Lista de configuraciones 4.3. Descripción de la configuración ( CONFIG ) ( * ) 4.4. Resumen de los procedimientos por unidad organizativa CAPITULO 5.

DESCRIPCION DE LOS DIALOGOS

5.1. Lista de los procedimientos 5.2. Descripción del procedimiento PROC CAPITULO 6. LOTES

(*)

DESCRIPCION DE LOS PROCEDIMIENTOS POR

6.1. Lista de los procedimientos 379

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

6.2. Descripción del procedimiento PROC

(*)

CAPITULO 7. MANUALES

PROCEDIMIENTOS

DESCRIPCION

DE

LOS

7.1. Lista de los procedimientos manuales 7.2. Descripción del procedimiento PROC CAPITULO 8. DESCRIPCION DEGRADADOS

DE

LOS

8.1. Lista de los procedimientos 8.2. Descripción del procedimiento PROC CAPITULO 9.

(*) PROCEDIMIENTOS

(*)

CODIFICACION

9.1. Lista de tablas 9.2. Descripción de la tabla TAB ( * ) 9.3. Reglas de codificación 9.4. Mensajes de error ( * ) Este párrafo se repite tantas veces como elementos se describen

14.4

GUÍA DE OPERACIÓN

Se refiere a la utilización de una aplicación. CAPITULO 1.

INTRODUCCION

1.1. Finalidad del manual 1.2. Destinatarios 1.3. Estructura del manual La estructura del manual puede variar de acuerdo con la naturaleza y ámbito del proyecto. Puede estar referido a un subproyecto, a un tipo de instalación, o subdividido por categorías de usuarios. 1.4. Convenios Este párrafo explica la simbología y convenios de representación utilizados. Puede contener también un glosario de términos. 380

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1.5. Referencias Evita tener que reescribir información que ya se ha documentado en otra parte ( por ejemplo, el software y hardware básicos ). Proporciona una lista de documentos de referencia que pueden ser consultados.

CAPITULO 2.

VISION GENERAL DE LA APLICACION

2.1. Contexto Este párrafo contiene una breve descripción del contexto del proyecto 2.2. Estructura de los datos No implica comentar el modelo conceptual de datos, ni el esquema de la base de datos, sino la presentación de los datos manejados por la aplicación: definiciones, ejemplos reales, conexiones entre datos, orden de creación, etc. 2.3. Funcionalidades * Identificación de las principales áreas de temas implicadas ( lista de configuraciones, etc. ). * Para cada una de las funcionalidades, descripción de: - qué hace la solución implantada - principios a partir de los cuales se ha construido - ventajas - límites de la solución 2.4. Relaciones con otras aplicaciones

CAPITULO 3.

LENGUAJE DE USUARIO

Este capítulo explica como usar el sistema. Su estructura respeta la secuencia lógica de las acciones del usuario: - conexión al sistema y selección del proceso a ejecutar - prestaciones comunes de las rutinas de proceso 381

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

ej: - descripción de campos de la pantalla - reglas de utilización de los menús - descripción de códigos de acción (encadenamiento de pantallas, almacenamiento, paginación, etc. ) 3.1. Introducción Este párrafo presenta la estructura de los subcapítulos que siguen 3.2. Descripción del teclado 3.3. Conexión 3.4. Características de operación normal Este párrafo se utiliza para describir las características generales de operación, tales como la estructura estándar de las pantallas del menú, etc. Ello puede requerir varios párrafos. 3.5. Acceso a la documentación Incluye un recordatorio de la existencia de la función de AYUDA. 3.6. Desconexión 3.7. Instrucciones en caso de fallo * coordinación con la correspondiente operación * procedimientos de comunicación y reglas implantadas

CAPITULO 4.

DESCRIPCION DE LAS CONFIGURACIONES

4.1. Encadenamiento de procesos Este párrafo presenta la secuencia de los procesos 4.2. Lista de configuraciones

382

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

El orden de presentación, por proceso, sigue el encadenamiento lógico de trabajos que es visible al usuario, de las configuraciones mas frecuentemente usadas a las menos utilizadas. 4.3. Descripción de la configuración ( CONFIG ) Este subcapítulo se repite tantas veces como configuraciones se describa. Contiene: - diagrama de encadenamiento de procedimiento - descripción del procedimiento 4.4. Resumen de los procedimientos por unidad organizativa Tabla de funciones por tipo de unidad organizativa

CAPITULO 5.

DESCRIPCION DE LOS DIALOGOS

5.1. Lista de los procedimientos El orden de presentación tiene en cuenta los siguientes elementos: - lógica de encadenamiento de trabajos - grado de dificultad ( ordenado de los procedimientos mas sencillos a los mas complicados - frecuencia de uso ( ordenado de los procedimientos mas frecuentes a los menos )

5.2. Descripción del procedimiento PROC Este subcapítulo se repite tantas veces como procedimientos se describan. Contiene: - finalidad del procedimiento - diagrama de los diálogos - diagrama de encadenamiento de módulos ( condiciones de encadenamiento de pantallas con diálogos ) - enfoque general y casos especiales - descripción de las pantallas asociadas - mensajes de error asociados 383

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

- ejemplo

CAPITULO 6. LOTES

DESCRIPCION DE LOS PROCEDIMIENTOS POR

6.1. Lista de los procedimientos El orden de presentación toma en cuenta los siguientes elementos: - lógica de encadenamiento de trabajos - grado de dificultad ( ordenado de los procedimientos mas sencillos a los mas complicados - frecuencia de uso ( ordenado de los procedimientos mas frecuentes a los menos )

6.2. Descripción del procedimiento PROC Este subcapítulo se repite tantas veces como procedimientos se describa. Contiene: - finalidad del procedimiento - descripción de los formatos de entrada y parámetros - descripción de las salidas - mensajes de error, en relación con los informes de control

CAPITULO 7. MANUALES

DESCRIPCION

DE

LOS

PROCEDIMIENTOS

7.1. Lista de los procedimientos manuales El orden de presentación toma en cuenta los siguientes elementos: - lógica de encadenamiento de trabajos - grado de dificultad ( ordenado de los procedimientos mas sencillos a los mas complicados - frecuencia de uso ( ordenado de los procedimientos mas frecuentes a los menos )

7.2. Descripción del procedimiento PROC

384

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Este subcapítulo se repite tantas veces como procedimientos se describa. Contiene: - finalidad del procedimiento - enfoque general y casos especiales

CAPITULO 8. DESCRIPCION DEGRADADOS

DE

LOS

PROCEDIMIENTOS

Este capítulo describe los procedimientos a ejecutar en caso de avería o mal funcionamiento. 8.1. Lista de los procedimientos 8.2. Descripción del procedimiento PROC Este subcapítulo se repite tantas veces como procedimientos se describa.

CAPITULO 9.

CODIFICACION

9.1. Lista de tablas 9.2. Descripción de la tabla TAB 9.3. Reglas de codificación * Recordatorio de los códigos manejados por el software, que pueden ser visualizados usando la función de AYUDA. * Reglas de codificación no manejadas por el software

9.4. Mensajes de error Los mensajes de error se clasifican de acuerdo con la naturaleza del proceso 14.5

GUÍA DE INSTALACIÓN Y OPERACIÓN

Se refiere a la instalación y manejo de una aplicación. 385

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

1. OBJETIVOS DEL DOCUMENTO La Guía de Operación contiene toda la información necesaria para instalar y operar el sistema de proceso de datos. Integra los resultados de las etapas del Diseño Técnico. Se formaliza en la tarea "Instrucciones de formación en la operación del proceso de datos" que se encuentra en la Guía de Diseño. 2 DESTINATARIOS Este documento va dirigido al personal encargado de la operación del proceso de datos, así como a los analistas y programadores que efectúen las pruebas de instalación/integración. Se utilizará por el departamento de explotación para incluir las instrucciones entregadas por cada unidad de trabajo ( preparación, operación de consola, expediciones, etc. ). 3. CONTENIDO CAPITULO 1.

PRESENTACION DE LA APLICACION

1.1. Objetivos 1.2. Principios

CAPITULO 2.

INTERLOCUTORES

2.1. Equipo de mantenimiento de la aplicación 2.2. Interlocutor de proceso de datos

CAPITULO 3. DESCRIPCION DE PERMANENTES Y BASES DE DATOS

LOS

3.1. Ficheros permanentes 3.2. Bases de Datos

CAPITULO 4.

PROCESO EN TIEMPO REAL

4.1. Monitor de TP 4.2. Transacciones 386

FICHEROS

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

CAPITULO 5.

PROCESO POR LOTES

5.1. Lista de unidades planificadas 5.2. Descripción de las unidades planificadas

387

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

15 RECURSOS PARA LA DIRECCIÓN DE LOS SISTEMAS DE INFORMACIÓN En el desempeño de su función, el analista puede tener que abordar tareas que van más allá de la responsabilidad sobre el desarrollo de aplicaciones. Nos referimos a la participación en la realización de un Plan de Sistemas, la dirección de equipos humanos dentro del departamento de Informática, la elaboración de planes de calidad o de seguridad del Sistema de Información, o la intervención en decisiones sobre contrataciones de bienes o servicios. Para todas estas actividades, mostramos algunos recursos de interés. 15.1

FACTORES CRÍTICOS DE ÉXITO

Para poder mejorar un sistema es preciso conocer sus finalidades y objetivos. Por medio de una serie de entrevistas, se trata de conocer las necesidades de cada uno de los interlocutores, sin detenerse en detalles menores sobre las particularidades del procedimiento empleado o de los medios empleados. Para ello se aplica la teoría de los Factores Críticos de Éxito, de John Rockart. Un Factor Crítico de Exito ( CSF ) es una necesidad local que se adhiere a un objetivo estratégico de la empresa. Es una mejora en el trabajo que colabora a mejorar el éxito, la productividad y la calidad del servicio que presta el departamento y la empresa. A cada CSF se asocia las informaciones necesarias para alcanzar el objetivo, para determinar el valor concedido por cada uno de los interlocutores. Procedimiento a seguir: 1) Preguntar qué se puede mejorar en las actividades para mejora el éxito, la productividad o la calidad del departamento o de la empresa. A esta pregunta deberían seguir 4 ó 5 respuestas. Ej: -Agilizar la tramitación de los pedidos para disminuir tiempos de entrega -Conocer los precios de los proveedores y las calidades de los productos de antemano 388

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

-Conocer las razones de rechazo de los productos -Mejorar las ofertas a clientes -Conocer el porcentaje de ventas en un momento dado - etc. 2) Para cada necesidad constatada, señalar qué informaciones y medios son necesarios. 3) Para cada necesidad constatada, señalar qué problemas se plantean para conseguir dichas informaciones y medios. 4) Establecer una lista asignando prioridades a cada una de las necesidades. 5) Conocer mediante la opinión del interlocutor el sentido grado de dificultad de resolución de los problemas que plantea la satisfacción de las necesidades. 6) Para cada necesidad, describir los beneficios esperados para el departamento y para la empresa. 7) Como consecuencia del acopio de datos, se construyen dos matrices * Objetivos estrategicos / Necesidades * Actividades impactadas / Necesidades La matriz Objetivos estrategicos / Necesidades muestra: - Objetivos frecuentemente citados, que indican la actividad principal de la empresa - Necesidades que tienen el mayor impacto en los objetivos estratégicos y que por tanto habrá que satisfacer con prioridad Para cada necesidad se contabiliza el número de veces que aparece marcada la columna correspondiente lo cual sirve para dar una valoración repecto a los objetivos de la empresa. La matriz Actividades impactadas / Necesidades muestra: - Actividades que son causa de problemas - Actividades que mejoran si se tiene en cuenta la necesidad constatada

389

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para medir el grado de dificultad de cada necesidad y su impacto sobre el sistema en general, se contabiliza el número de veces que aparece marcada la columna correspondiente. Del análisis anterior se deducen los CSF, sirviendo como base para asignar prioridades a las necesidades y objetivos.

390

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA ---

MATRIZ DE ACTIVIDADES AFECTADAS POR NECESIDADES

---

01 : Mejorar el acceso a los medios informáticos

12 : Disponer de retroalimentación de los servicios prestados

02 : Anticipar entradas y salidas financieras

13 : Mejorar la circulación de las informaciones

03 : Mejorar el servicio postventa

14 : Innovar productos y servicios

04 : Disponer de un balance actualizado

15 : Mejorar la oferta

05 : Crear un Club de Usuarios

16 : Conseguir una producción normalizada

06 : Disponer de colaboradores debidamente formados

17 : Calcular fiablemente los retornos de inversión

07 : LLevar bien la captación de pedidos

18 : Disponer de un útil de prospección

08 : Mejorar los controles

19 : Mejorar las informaciones sobre clientes

09 : Mejorar los plazos de entrega

20 : Disponer de estadísticas de ventas

10 : Controlar los compromisos con terceros

21 : Mejorar la gestión de impagados

11 : Mejorar las condiciones de trabajo

22 : Mejorar el seguimiento de pedidos

----------------------------------------------------------------¦ NECESIDADES ¦0000000001111111111222¦ ¦ ACTIVIDADES ¦1234567890123456789012¦ ----------------------------------------------------------------¦ FACTURAR ¦ ** ¦ ¦ GESTIONAR FICHERO DE CLIENTES ¦ * * * ¦ ¦ PERSONALIZAR PEDIDOS ¦ * ¦ ¦ CAPTAR PEDIDOS ¦ *** * ¦ ¦ PREPARAR PRODUCCION ¦ * * ¦ ¦ ADQUIRIR PRODUCTOS FINANCIEROS ¦ * * * ¦ ¦ ANALIZAR COSTOS ¦ * ¦ ¦ CONTABILIZAR ¦ * * ¦ ¦ GESTIONAR CUENTAS DE CLIENTES ¦* * * ¦ ¦ CONTROLAR FACTURAS Y PEDIDOS ¦ ** * ¦ ¦ ESTABLECER PRESUPUESTO ¦ * ¦ ¦ CONTROLAR LA PRODUCCION ¦ * * ¦ ¦ FABRICAR ¦ * * * *¦ ¦ EMPAQUETAR PRODUCTOS ¦ * ¦ ¦ ENTREGAR ¦ * *¦ ¦ PLANIFICAR PRODUCCION ¦ * ¦ ¦ PREPARAR DOCUMENTACION DE ENVIOS ¦ * ¦ ¦ PREPARAR EXPEDICIONES ¦ * ¦ ¦ PRESTAR SERVICIO POSTVENTA ¦ * *** ¦ ¦ PREPARAR OFERTAS A CLIENTES ¦ * * * * *¦ ¦ GESTIONAR FICHERO DE PROSPECTOS ¦ * ¦ ¦ PROSPECCIONAR MERCADO ¦ * * ** ** *¦ ¦ SEGUIR PEDIDOS ¦ * ¦ ¦ SEGUIR VENTAS ¦ * ¦ ¦ SEGUIR ENTREGAS A CLIENTES ¦ * ¦ ----------------------------------------------------------------391

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

---

MATRIZ DE OBJETIVOS RELACIONADOS CON NECESIDADES

---

01 : Mejorar la competitividad en el mercado

10 : Disponer de mejor visión del mercado

02 : Disponer de un balance por departamento

11 : Adaptar la oferta a la demanda

03 : Mejorar los controles

12 : Editar informes automaticamente

04 : Mejorar la fiabilidad de los servicios

13 : Reducir los impagados

05 : Mantener la clientela

14 : Mejorar el rendimiento y la eficacia

06 : Financiaciones directas

15 : Mejorar la rentabilidad

07 : Mejorar la gestión de las prospecciones

16 : Mejorar la seguridad

08 : Innovar

17 : Proporcionar mejor servicio

09 : Seleccionar los mailing

18 : Disponer de mejor especialización técnica

----------------------------------------------------------------¦ OBJETIVOS ¦000000000111111111¦ ¦ NECESIDADES ¦123456789012345678¦ ----------------------------------------------------------------¦ Mejorar el acceso a los medios informáticos ¦ * ¦ ¦ Anticipar entradas y salidas financieras ¦ * ¦ ¦ Mejorar el servicio postventa ¦ * *¦ ¦ Disponer de un balance actualizado ¦ * * ** ¦ ¦ Crear un Club de Usuarios ¦ * ¦ ¦ Disponer de colaboradores debidamente formados ¦ * * ¦ ¦ LLevar bien la captación de pedidos ¦ * * * ¦ ¦ Mejorar los controles ¦ * ¦ ¦ Mejorar los plazos de entrega ¦* * ¦ ¦ Controlar los compromisos con terceros ¦ * ¦ ¦ Mejorar las condiciones de trabajo ¦ * * ¦ ¦ Disponer de retroalim. de los serv. prestados ¦* * ¦ ¦ Mejorar la circulación de las informaciones ¦ * * ¦ ¦ Innovar productos y servicios ¦ * * * ¦ ¦ Mejorar la oferta ¦* **¦ ¦ Conseguir una producción normalizada ¦ * * ¦ ¦ Calcular fiablemente los retornos de inversión ¦* * ¦ ¦ Disponer de un útil de prospección ¦* * ** ** ¦ ¦ Mejorar las informaciones sobre clientes ¦ * * ¦ ¦ Disponer de estadísticas de ventas ¦ * * * ¦ ¦ Mejorar la gestión de impagados ¦ ** * ¦ ¦ Mejorar el seguimiento de pedidos ¦ * * ¦ -----------------------------------------------------------------

392

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

15.2

ANALISIS COSTE-BENEFICIO

La técnica de análisis coste-beneficio tiene como objetivo fundamental proporcionar una medida de los costes de la realización de un proyecto informático y comparar dichos costes previstos con los beneficios esperados de la realización de dicho proyecto. Esta medida o estimación servirá: . . .

Para valorar la necesidad y oportunidad de acometer la realización del proyecto. Para seleccionar la alternativa más beneficiosa para la realización del proyecto. Para estimar adecuadamente los recursos económicos necesarios en el plazo de realización del proyecto.

Para la realización del análisis Coste-Beneficio se seguirán los siguientes pasos: 1.2.-

Estimaciones de costes-beneficios. Determinación de la viabilidad del proyecto y su aceptación.

Estimaciones Costes - Beneficios Se realiza una lista de lo requerido para implementar el sistema y una lista de los beneficios del nuevo sistema. En un análisis de costes y beneficios se deberán considerar aquellos aspectos tangibles (medibles en valores como dinero, tiempo, etc.) y no tangibles (no ponderables de una forma objetiva). En general, los costes suelen ser medibles y estimables en unidades económicas, no así en cuanto a los beneficios, los cuales pueden ser tangibles o no tangibles. Los beneficios no tangibles pueden ser: . El aumento de cuentas debido al mejor servicio a los clientes. . La mejora en la toma de decisiones debido a una mejora en el soporte informático. En estos casos se deberá estimar de una forma subjetiva la valoración de dichos beneficios. Esta valoración será realizada por las áreas correspondientes. 393

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

A menudo es conveniente dividir los costes estimados a lo largo de las fases del proyecto, para ofrecer una información más detallada de la distribución de los recursos de cara a la Dirección. Algunos costes tangibles son: . Costes de equipo. . Costes de infraestructura: acomodación necesaria del equipo, mobiliario, etc. Costes de personal tanto para desarrollo del nuevo sistema, así como formación de todo el personal implicado. . Costes materiales. . Costes de conversión. Costes de consultoría.

Determinación de la viabilidad del proyecto Se basará en uno de los métodos siguientes: a) Retorno de la Inversión Este método consiste en calcular el coste y el beneficio anual, sabiendo el coste total al inicio del proyecto "C0. Este método permite saber en qué año se recupera el coste total inicialmente estimado. AÑO 0 1 2 … n

COSTE BENEFICIO NETO C0 C1 C2 … Cn

BENEFICIO 0 B1 B2 … Bn

B1 – C1 B2 - C2 … Bn – Cn

El año de recuperación de la inversión es cuando  Ben. Neto = C0. b) Valor Actual Este método permite tener en cuenta que un gasto invertido durante un cierto tiempo produce un beneficio. Consiste en determinar el dinero que es viable invertir inicialmente para que se recupere la inversión en un período de tiempo definido previamente. El resultado depende del interés (r) utilizando en la evaluación.

394

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Se deberá calcular, en primer lugar, el beneficio neto que se obtendrá cada año. Dicho beneficio no es real, ya que se debe estimar el valor real de dicha cantidad en el año n. Para ello se aplicará la fórmula: Valor Actual = Beneficio neto / (1 + r/100)n

n = año 1,..,i

Se deberá estudiar en cuántos años se recupera la inversión realizada inicialmente, o bien, si en un período de años fijado previamente se retorna la inversión y, por tanto, es viable el proyecto. Si la inversión es el C0, se determinará la viabilidad del proyecto consultando la siguiente tabla: AÑO COSTE 0 C0 1 C1 C1)/(1+r/100) 2 C2 C2)/(1+r/100)2 … … n Cn Cn)/(1+r/100)n

BENEFICIO 0 B1

VALOR ACTUAL 0 V.A1=(B1-

B2

V.A2=(B2…

Bn

….. V.An=(Bn-

El proyecto será viable si  VAi > C0 a lo largo del período fijado.

395

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

15.3

PROCEDIMIENTO DE DECISIÓN MULTICRITERIO

La planificación de los sistemas informáticos es un factor crítico para el éxito de la empresa. La cuestión es muy amplia y aquí vamos a tratar solamente un procedimiento multicriterio, que se puede emplear para seleccionar un sistema informático, entre varias alternativas posibles. Existen varias metodologías multicriterio, que abordan el problema de forma más o menos cuantitativa. El objetivo de un proceso de decisión multicriterio es evaluar una serie de alternativas ( Ai ) de ofertas de bienes o servicios informáticos, con vistas a seleccionar la más conveniente. Para ello, se hace uso de una serie de criterios ( Cj ), a los cuales podemos conceder ponderaciones ( Wj ) en función de la importancia que concedamos a los referidos criterios. Con ello formamos una matriz, que tiene tantas filas como alternativas y tantas columnas como criterios. Los elementos de la matriz serán las puntuaciones ( Pij ) concedidas a determinada alternativa sobre determinado criterio.

C1

C2

C3

….

Cj

….

Cm

A1 A2 A3 …. A i

Total punt os T1 T2 T3 …

P i j

T i

… .

… .

An

Tn W1

W2

W3

….

396

Wj

…..

Wm

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Las puntuaciones totales Ti, se calcularán de la siguiente forma: Ti =  Pij*Wj , para j comprendido entre 1 y m. Podemos adoptar varias formas de actuación. Entre ellas: -Elegir la alternativa que arroje mayor puntuación total, según se acaba de explicar. -Elegir la alternativa que tenga mayor puntuación en el criterio de mayor peso, y en caso de empate decidir por la siguiente o siguientes. Hay otras muchas variantes, que contemplan suavización de datos, con el fin de evitar puntuaciones muy dispersas, o que miden el grado de información que aporta un criterio con respecto a otros, etc. Tanto las ponderaciones asignadas a los criterios como las puntuaciones asignadas a las diversas alternativas en relación con los criterios llevan una indudable componente subjetiva. Hay que sopesar, por tanto, si es mejor trabajar con números absolutos ( p.e. la escala clásica de puntuación del 1 al 10 ) o con valores porcentuales que expresen mejor una evaluación relativa o comparativa. El procedimiento de decisión multicriterio es amplio y su alcance excede el de los objetivos que perseguimos en éste momento. Completamos esta nota técnica con un procedimiento de evaluación de proveedores de bienes y servicios informáticos, que puede ser ejemplo de aplicación del método multicriterio. EVALUACIÓN Y HOMOLOGACIÓN DE PROVEEDORES 1) Definir qué proveedores se va a evaluar. En principio conviene evaluar a los proveedores de productos importantes en nuestro trabajo ( p.e. no incluir a proveedores de material de oficina ) 2) Definir los criterios de evaluación que se va a utilizar solvencia prestigio tamaño plazo de entrega precio calidad etc 3) Ponderar los criterios según su importancia 397

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

4) Para cada criterio definir el sistema de medición y la escala de puntuación A, B, C; 0 - 3; 0 - 10

etc

5) Definir, para el conjunto de criterios, cuándo se considerará a un proveedor homologado aprobado en todos los criterios máxima nota en unos criterios y aprobado en el resto

etc

6) Definir cómo se va a hacer efectiva la homologación carta certificado inclusión en catálogo

etc

7) Definir la frecuencia de revisión de las puntuaciones 8) Definir, para cada una de las operaciones: responsable plazos forma de registro de los resultados herramientas a utilizar documentos a utilizar etc

15.4

ÁRBOLES DE DECISIÓN

Son estructuras ramificadas que indican las diferentes opciones que se presentan ante alternativas de decisión encadenadas y sus consecuencias, sean de tipo económico o de resultados. Seguidamente se presenta un sencillo ejemplo. El comprador prudente Vd. tiene que decidir sobre la adquisición de un determinado producto. La dificultad de la elección reside en que los productos existentes en el mercado no se adaptan del todo a sus exigencias. 398

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Recibe, sin embargo, dos ofertas interesantes ( Sean éstas A y B ) A:

Precio = 1500 $ Existe la probabilidad del 50 % de que tenga que gastar

otros 2000 $ en la adaptación del producto. Además, su consejero técnico le previene que, en caso de que el producto necesite adaptación, existe la probabilidad del 50 % de que haya que adquirir otro producto mas, que cuesta 1000 $

B:

Precio = 2500 $ Existe la probabilidad del 50 % de que tenga que gastar

1000 $ en la adaptación del producto. En ese caso no habría que adquirir ningún producto más. ¿ QUE COMPRARIA VD. ?. ¿ CUAL SERIA EL COSTE ESPERADO ?. ¿ QUE RIESGOS TENDRIA QUE ASUMIR ?

399

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Costo esperado bruto

0,5

Probab.

Costo esperado bruto

4500 $

0,25

1125

3500 $

0,25

875

1500 $

0,5

750

1000 $ 0,5

A 1500 $

2000 $

0,5

0,5

Costo neto eligiendo A

2750 $

3500 $

0,5

1750

2500 $

0,5

1250

OFERTA

2500 $

B

0,5

1000 $

0,5

Costo neto eligiendo B

15.5

3000 $

SELECCIÓN DE HARDWARE / SOFTWARE

DECISIONES EN TORNO AL SOFTWARE Alternativas existentes: a) Desarrollo propio Ventajas: adaptación a las necesidades de la empresa Inconvenientes: falta de competencias para el desarrollo y disponibilidad tiempos 400

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

b) Desarrollo por contratación externa Ventajas: no se necesita disponer de especialistas Inconvenientes: coste más elevado que el desarrollo propio c) Adquisición de programas-producto o paquetes de aplicación Ventajas: menor coste de desarrollo y facilidad de puesta en marcha Inconvenientes: puede ser inadecuado para el entorno de nuestra empresa Selección de paquetes de aplicación: habrá que asegurarse de cómo cubre las áreas de -Ayudas al desarrollo -Ayudas a la explotación -Ayudas a la gestión de datos -Gestión financiero-contable -Administración de ventas -Gestión documental y ofimática -Gestión de producción -Aplicaciones técnicas -Aplicaciones sectoriales -Gestión de recursos humanos -Cálculos matemático-estadísticos -Planificación y control de proyectos -Gestión integrada de la empresa Modalidades de contratación de programas-producto: -

Cesión de uso temporal Cesión de uso definitivo Licencia de ubicación Licencia corporativa Licencia de red

DECISIONES EN TORNO AL HARDWARE Alternativas existentes: a) Subcontratación de trabajos informáticos ( outsourcing ) Ventajas: limita los riesgos Inconvenientes: falta de control sobre los medios 401

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

b) Compra de ordenador/es Ventajas: razones de autonomía y precio Inconvenientes: riesgo de obsolescencia c) Arrendamiento de ordenador/es Ventajas: falta de presupuesto para compra o corta vida esperada para los equipos Inconvenientes: falta de flexibilidad para cambiar la configuración d) Arrendamiento de ordenador/es con opción a compra Ventajas: posibilidad de compra aplazada y menor carga financiera inicial Inconvenientes: mayor inversión que la compra directa e) Adquisición de equipos usados Ventajas: mejores precios y solución transitoria hacia mejores opciones Inconvenientes: obsolescencia más rápida Procedimiento de selección de hardware: a) análisis de especificaciones Se estudiará la adecuación de los equipos a las funcionalidades que se van a informatizar. Las especificaciones de los ordenadores comprenden: Procesador. Memoria central. Memorias auxiliares. Dispositivos de entrada / salida. Interfaces de teleproceso. Sistema operativo. Lenguajes de desarrollo soportados. b) petición de ofertas Se explicará claramente las especificaciones deseadas, así como condiciones de precio, pago y otras de tipo jurídico y contractual. c) validación de las ofertas Se controlará que las especificaciones ofertadas cumplen con las solicitadas. Un problema es la comprobación a priori de los rendimientos del nuevo sistema. Las demostraciones de los proveedores pueden ayudar al respecto. d) selección de oferta Se hará por estudio comparativo y por el método de las ponderaciones ( decisión multicriterio )

402

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Para establecer las ponderaciones, se puede partir del siguiente esquema de criterios

(i)

Constructor Entrega e instalación Experiencia en general Experiencia en el tipo de equipo ofertado Mantenimiento Formación que imparte a nuestro personal Documentación que proporciona Disponibilidad de instalaciones de respaldo

(ii) Procesador Tamaño de la memoria central Velocidad de proceso Conjunto de instrucciones Posibilidad de ampliación (iii) Equipo periférico Dispositivos de entrada y salida Memoria auxiliar (iv) Software de base Sistema operativo Procesadores de lenguajes Programas de utilidad

403

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

15.6 COSTES INFORMÁTICOS ( ADMINISTRACIÓN – MANTENIMIENTO ) La función de gestión de las instalaciones informáticas abarca la totalidad del ciclo productivo, comprendido entre el momento de la instalación del sistema ( o sistemas ) y va incorporando las diversas aplicaciones. El coste de operación de la informática se reparte entre: -Explotación -Optimización -Problemas -Cambios -Configuraciones -Recuperación -Seguridad -Informes El coste informático va a depender del servicio dado a los usuarios y por tanto del número mayor o menor de los mismos. El crecimiento de los sistemas de proceso de datos va a marcar el crecimiento del coste. Dicho crecimiento puede ser planificado o puede ser reprimido, según aumente progresivamente la capacidad de los sistemas o llegue a un nivel de saturación, dependiendo de las inversiones. En el último caso, puede existir una demanda latente que se vea desbloqueada y que provoque un aumento significativo de la capacidad de los sistemas y por tanto de los costes. Algunas métricas de complejidad, utilizadas en la estimación del esfuerzo de desarrollo de aplicaciones, tratan de estimar también los esfuerzos de mantenimiento. El método COCOMO estima que el esfuerzo de mantenimiento de una aplicación es Em = Ed * [ ( Ia + Im ) / Io ] Siendo: Em = esfuerzo de mantenimiento; Ed = esfuerzo de desarrollo; Ia = instrucciones añadidas / año; Im = instrucciones modificadas / año; Io = instrucciones iniciales en el desarrollo Este mismo método estima que el esfuerzo de desarrollo ( Ed ) es Ed = K1* Io exp K2, siendo Io = instrucciones iniciales de desarrollo y K1, K2 dos parámetros que varían según la índole del proyecto, siendo sus pares de valores:

404

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Tipo de proyecto Simple Intermedio Complejo

K1 2,4 3,0 3,6

K2 1,05 1,12 1,20

Existen baremos que establecen comparaciones entre diversos porcentajes de costes informáticos. A modo de ejemplo, la Administración Pública Española, con motivo del proyecto de implantación de un plan de gestión de recursos informáticos de la administración, publico el siguiente baremo: Item de Coste Mantenimiento Desarrollo Entrada de datos Formación Otros (incl servicios)

Porcentaje 48 % 20 % 13 % 4% 14 %

A efectos del control del coste informático, indicamos los items a tener en cuenta, para construir cuadros de mando u otros instrumentos de gestión. Coste de Organización del Centro de Proceso de Datos Infraestructura ( acomodación de equipos, mobiliario, etc. ) Adquisición de Equipos Contratación de Personal Coste de Implantación de Sistemas Salarios Formación Tiempo de ordenador Desarrollo de sistemas Herramientas de desarrollo Selección de personal Alquiler de locales Equipo de oficina Viajes Coste de Puesta en Marcha de Sistemas Formación de usuarios Conversión de datos 405

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Instalación Validaciones Pruebas Equipo de desarrollo Coste de Operación Hardware Suministros Software Personal Mantenimiento Facilidades Explotación de sistemas Coste de Fallos y Averías

15.7

PERFILES PROFESIONALES EN LA INFORMÁTICA

Se describen las características y responsabilidades de los profesionales más usuales en un departamento de informática. Director Definir el presupuesto y acuerdos contractuales Supervisar el funcionamiento de la unidad, de acuerdo con el presupuesto Decidir en cuanto a cambios en las directrices de la unidad Decidir sobre los temas que vayan surgiendo en materia funcional y organizativa Asegurar la disponibilidad y empleo adecuado de los recursos Asegurar las entregas y el soporte a los usuarios Supervisar los proyectos Jefe de proyecto Supervisar el proyecto en conjunto en términos de planificación y presupuesto Asegurar que se cumplen las normas de calidad especificadas para el proyecto Responsabilizarse de la ejecución de las tareas diarias Mantener y actualizar la planificación del proyecto Informar a dirección sobre los conflictos surgidos en el desarrollo del proyecto 406

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Responsable de soporte a usuarios Asegurar que la entrega de los equipos o sistemas a los usuarios se realiza según lo acordado Asegurar que el entorno informático de trabajo de los usuarios funciona correctamente Asegurar que los usuarios pueden participar en los proyectos de su incumbencia Facilitar las decisiones en los conflictos que se puedan presentar en el trabajo diario Preparar el entorno de los usuarios para la introducción de los nuevos sistemas Gestionar las solicitudes de cambios efectuadas por los usuarios Motivar a los usuarios y preocuparse de que reciban la formación necesaria Responsable de organización Proporcionar información a los proyectos sobre política de negocio, datos y procesos Obtener decisiones y aprobaciones a su debido tiempo en el entorno de la informática Asegurar que se cumplen las normativas de empresa y de calidad establecidas Ayudar en la resolución de conflictos Asegurar la integración de los diversos sistemas Aconsejar a la dirección en cuanto a las alternativas y evolución de la división

Analista Realizar los análisis funcionales y orgánicos de los nuevos sistemas a implantar Mantener la documentación de especificaciones de los sistemas Realizar la parametrización de los paquetes integrados que se instalen Probar, en cuanto a lo funcional, los nuevos sistemas que se implanten Definir especificaciones de programas, interfases y conversiones de datos Identificar requisitos de negocio que deben ser convenientemente informatizados Preparar la documentación de los usuarios y participar en la formación de los mismos Responsable de Sistemas

Implantar y mantener el entorno productivo y de desarrollo Gestionar los procedimientos de actualización y migraciones del sistema informático Implantar el sistema de administración de datos Mantener los perfiles y permisos de usuarios 407

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Programador Codificar los programas de acuerdo con las especificaciones funcionales y orgánicas Ejecutar las pruebas unitarias de programas y las pruebas de integración de sistemas Crear y mantener la documentación de programas Administrador de datos Gestionar la definición de los nuevos datos y estructuras de codificación y almacenamiento Responsabilizarse de la administración de los datos del sistema informático Gestionar los ficheros maestros de la organización Gestionar la documentación de las bases de datos Responsable de Seguridad Implantar los perfiles de seguridad en los entornos de desarrollo y de producción Auditar la seguridad de los sistemas Crear, mantener y ejecutar los planes de contingencia Administrador de redes Gestionar el entorno de redes, en función de las contrataciones llevadas a cabo Auditar el rendimiento del sistema de redes, para optimizar el rendimiento del mismo Mediar con los proveedores para resolver los conflictos que se puedan producir

15.8

CONTRATACIÓN EN LA INFORMÁTICA (OUTSOURCING)

Existen varios procedimientos de contratación: Concurso abierto Sin selección de ofertantes Con selección de ofertantes Adjudicación directa Con oferta previa Por urgencia Por cuantía Por prototipaje Sin oferta previa Proveedor único 408

SISTEMAS DE INFORMAC IÓN EN LA EMPRESA

Secreto Por razón de uniformidad Por razón de compatibilidad Los pliegos de condiciones podrán tener como clausulas más significativas: I. Normas generales II. Objeto principal del contrato III. Ofertas