Introducción

En esta primera parte vamos a revisar y analizar las áreas y actividades que la dirección debe cubrir y en las que se debe involucrar para que el desarrollo de proyectos informáticos sea el mecanismo que actúe en la gestión global de la informática de la empresa o entidad y que, al mismo tiempo, la función (la del desarrollo) sea rentable en sí misma.

Antes de seguir, debemos aclarar que la “dirección” a la que nos referimos es especialmente la de más alto nivel (consejero delegado, director general, directores funcionales), aunque sin exclusiones de ningún nivel. En particular, el grado de involucración de la dirección debe ser directamente proporcional a su nivel de responsabilidad, correspondiendo al máximo nivel de dirección el papel de patrocinador.

A través de la dirección se establecen criterios, estrategias y tácticas que pueden manejar y controlar conceptos tales como:

• La estructura organizativa de desarrollo de proyectos informáticos, asignando los recursos humanos necesarios y los económicos para subcontratación. Estos recursos, dependiendo de la estrategia que se siga, pueden estar todos centralizados en la función de sistemas de información, o pueden estar distribuidos entre esta función y las funciones usuarias.
• Los criterios y comités que regulen y controlen las prioridades y rentabilidad de los proyectos que se van a desarrollar, así como el establecimiento de un plan anual —que debe permanecer vigente— de los proyectos en curso y pendientes.
• Los planes de acción que conducen al incremento de la “industrialización”, en detrimento de la “artesanía”, del proceso de desarrollo de proyectos informáticos. Entre estos planes se incluyen:
  • Los correspondientes a la gestión y control de los recursos utilizados que, finalmente, conducirán al conocimiento de los costes.
  • Los que conducen a la predicción “a priori” y medida “a posteriori” de los beneficios y costes, tanto a nivel de proyecto como en la totalidad del plan.
  • Los que llevan a medidas “industriales” del desarrollo de proyectos, tales como productividad, calidad, cumplimiento de fechas, etc.

Todas estas estrategias y planes deberán estar soportadas por una asignación de responsabilidades a los distintos estamentos directivos de la empresa o entidad, que afecten a la dirección ejecutiva, tanto usuaria como de sistemas de información.

Son de la dirección usuaria, a todos sus niveles, responsabilidades como:

• Establecer una estrategia general de informatización de su propia función. Esta estrategia debe ser contrastada con sistemas de información y debe cubrir sus necesidades operativas o de los procesos de negocio en que participa la función.
• Determinar los beneficios que le producirá la informatización, a nivel de proyecto de desarrollo de dicho plan de informatización. Estos beneficios vendrán dados básicamente por dos parámetros: los ahorros en su presupuesto y los incrementos de productividad de sus recursos humanos.
• Comprometer la rentabilidad de su plan de proyectos de informatización, una vez conocidos los costes en los que, lógicamente, a nivel de proyecto, debe intervenir sistemas de información. Esta rentabilidad debe estar basada en criterios de oportunidad en la inversión, de la abordabilidad del coste y de la viabilidad técnica.

Son responsabilidades de la dirección de sistemas de información:

• Establecer una estrategia global de informática aprobada por el máximo nivel de dirección, que contemple aspectos tales como: centralización frente a descentralización del hardware; nivel de informática personal; redes de teleproceso; sistemas de oficina, correo electrónico; continuidad de las operaciones; etc.
• Dentro del área de desarrollo deben existir las responsabilidades de:
  • Definir un entorno técnico para pruebas de proyectos en desarrollo y para mantenimiento de las aplicaciones en producción.
  • Implantar un plan de evolución y mejora de las actividades de desarrollo en aspectos tales como costes, procedimientos y medidas, que incrementen la madurez de la organización.
  • Proponer, implantar y controlar el plan de organización de recursos humanos, centralizando o descentralizando las organizaciones de analistas funcionales o de negocio.
  • Garantizar la obtención y asignación de recursos humanos propios y subcontratados para cada proyecto de desarrollo.
  • Disponer de un plan anual, vigente y actualizado, de los proyectos de desarrollo.
  • Establecer un plan de formación técnica, y controlar su cumplimiento, para los profesionales del desarrollo.

Ahora bien, para que todas estas estrategias y responsabilidades existan y se cumplan, deben proceder directamente del máximo nivel de dirección de la empresa o entidad. Es inútil intentarlo si no se cumple esta condición.

El desglose y análisis de los distintos aspectos que hay que contemplar, los vamos a ver a lo largo de las seis subáreas en que se subdivide esta primera parte del libro.

• Gestión del Desarrollo como Negocio
• Business Case
• Generación del Plan Informático
• Realización y Control del Plan
• Involucración de la Dirección
• Normas y Herramientas Técnicas

2

Gestión del Desarrollo como Negocio

Partiendo de la base de que las aplicaciones son la polea motriz de la correa de la informática en la empresa o entidad, y de que esta correa mueve a las demás poleas de las informáticas funcionales y departamentales, analicemos cómo esta polea motriz debe gestionarse ateniéndonos a los principios de cualquier negocio.

Este negocio, se entiende, está contenido en el entorno del de la empresa o en el del servicio de la entidad, como conjuntos mayores, que engloban el del desarrollo. No es un negocio que, salvo en las empresas que se dedican a él, produzca facturas a clientes externos, pero sí lo es desde el punto de vista de que sus costes internos son, y deben ser, compensados y superados por los beneficios internos que produce, y esto es lo básico, y a esto se debe encaminar la gestión, por parte de toda la dirección y, en especial, por la de informática y desarrollo de la empresa o entidad.

Como tal negocio, los parámetros que hay que considerar, aplicables a este caso, son: los recursos y costes, tanto humanos como financieros; los beneficios y ahorros, y, por lo tanto, su balance frente a los costes; los plazos de entrega; y las prioridades y la satisfacción de los clientes o usuarios.

Este negocio debe estar, como cualquier otro, regido por un plan anual que recoja los objetivos que se cumplirán en este período de tiempo y que puede ser revisado, para mantener su vigencia, una o dos veces al año (cuatrimestralmente).

Para que se cumpla este principio de considerar el desarrollo como un negocio o una actividad rentable dentro de la empresa o entidad, es necesario que se cumplan también unas ciertas premisas en sus distintos estamentos, como son:

Definición. Es el máximo nivel de dirección quien debe definir el marco de actuación, que se resume en dos parámetros fundamentales: el primero se refiere a la estrategia y táctica informática de la empresa o entidad (centralizada o descentralizada, organización, áreas por abordar y sus prioridades, tipo de informática personal, correo electrónico, etc.); el segundo está relacionado con la táctica a corto plazo en cuanto a la inversión anual en recursos técnicos y humanos (propios y subcontratados).

Decisión. Dentro del marco de actuación definido por la alta dirección, son las direcciones funcionales las que establecen sus planes informáticos, sujetos, claro está, a la posibilidad de abordar sus costes totales y a la rentabilidad individualizada de sus proyectos.

Implantación. Es la función de informática (y la de desarrollo) quien debe establecer la consolidación, así como el control de la realización del plan de proyectos de desarrollo. Asimismo, esta función debe proponer las estructuras organizativas, que abarcan también a las funciones, y que responden a planteamientos estratégicos; estos planteamientos (aceptados por todas o algunas funciones) se plasman en organizaciones tácticas (año a año) cuyo dimensionamiento debe ser establecido y controlado por la función de informática.

Control general. Este control debe ejercitarse desde distintos comités, definidos por la alta dirección, para garantizar el cumplimiento de los límites establecidos en el marco de actuación. De entre ellos, los más destacables son: el de rentabilidad de los proyectos y el de inversiones en medios y recursos.

A estas premisas se deben añadir unos criterios claros, que todas las funciones deben cumplir, referentes a la materialización de los beneficios que se produzcan.

Esta materialización de los beneficios se apoya en el control y la comunicación. Pues bien, ambos se realizan de forma paralela cuando se trata de proyectos individualizados o de conjuntos de pequeños proyectos dedicados, normalmente, a mejoras de aplicaciones existentes.

En el caso de proyectos individualizados, se debe proceder a revisar, una vez que la aplicación está en producción, en primer lugar el cumplimiento de los requerimientos de usuario establecidos al plantear la necesidad del proyecto de mecanización; este cumplimiento, obviamente, es esencial.

En paralelo con los requerimientos, se establecieron los ahorros y los costes (esto se ve en el Capítulo 3: Business Case). Los ahorros comprometidos al tiempo que los requerimientos o especificaciones de la petición, tanto en recursos humanos como financieros, deben aplicarse, por las funciones u organizaciones responsables, a la función usuaria y, al tiempo, beneficiaria de la aplicación (que, lógicamente, es la que solicitó el proyecto).

En la revisión a que nos referimos, también se deben comparar los costes reales incurridos frente a los comprometidos en el “Business Case”. La responsabilidad de las posibles desviaciones está compartida entre la función usuaria, en cuanto al análisis (si están funcionalizados o descentralizados los analistas funcionales o de negocio), y la función de informática, en cuanto al desarrollo e implantación.

Estas informaciones de la revisión se hacen llegar, desde la función de informática, tanto a la función usuaria (para su conocimiento), como al presidente del comité u organismo de rentabilidad (para control), y a las funciones u organizaciones centrales responsables de la asignación de recursos humanos y financieros (para la materialización de los ahorros a la función usuaria).

En el caso de conjuntos de pequeños proyectos (estimamos que cada uno no llegue a los 3 meses-hombre de esfuerzo en desarrollo) dedicados a mejoras de aplicaciones, las revisiones se hacen mensualmente (o cada dos meses) informando de los totales de costes y ahorros habidos en aquellos que se han implantado en el período, a las mismas organizaciones y personas (y con las mismas finalidades) descritas en el párrafo anterior.

Por último, y, en cierto modo, como resumen del capítulo, baste decir que para que el desarrollo sea el negocio que toda la empresa o entidad necesita, es imprescindible que se cumplan las premisas y las revisiones descritas, así como que todos los proyectos de desarrollo sean rentables, es decir, sean negocio para la función que los solicita, y, por lo tanto, para la empresa.

3

Business Case

Este capítulo analiza el procedimiento que hay que seguir cuando se solicita el desarrollo de un proyecto informático, para planificar “a priori” la rentabilidad que tendrá, una vez que la aplicación está instalada y en uso.

En el “Business Case” juega un papel fundamental la función propietaria, que se concreta en el “propietario”.

El “propietario” es un director que forma parte de la Función que solicita la realización del proyecto informático. Como tal, el ‘propietario” hace de patrocinador del proyecto, y será el interlocutor —en nombre de la Función usuaria y de los usuarios finales— con la organización de desarrollo y mantenimiento de aplicaciones.

Sus principales responsabilidades, desde la propuesta de realización del proyecto informático hasta que este se convierte en una aplicación en producción, son las siguientes:

• Debe cuantificar los ahorros y beneficios que se producirán en los usuarios finales (mejora de productividad, capacidad de hacer más cosas, mejora de calidad, etc.) cuando la aplicación esté en producción.
• Debe expresar documentalmente los requerimientos y características que la aplicación debe cumplir y tener.
• Debe proveer los datos de prueba necesarios para validar que la aplicación cumplirá lo requerido.
• Debe definir los grados de confidencialidad de los distintos componentes de la futura aplicación (impresos, pantallas, ficheros, etc.).
• Debe impartir a los futuros usuarios finales, la apropiada formación para operar con la futura aplicación.
• Debe, por último, autorizar el paso a producción (supervisando la conversión de ficheros, si procede), por el que el proyecto pasa a ser una aplicación operativa.

En todas estas responsabilidades, el “propietario” debe estar ayudado y respaldado por el o los analistas funcionales.

Asimismo, los analistas funcionales deben dar soporte al propietario en sus responsabilidades después del “nacimiento” de la aplicación.

Estas responsabilidades del propietario durante el ciclo de vida de la aplicación son:

• Validar que el funcionamiento de la aplicación es acorde con los requerimientos y características que se establecieron en la propuesta del proyecto. Esta validación dará paso a la materialización de los ahorros y beneficios que acompañaron a la propuesta.
• Ser el cauce entre los usuarios finales y la Función de Sistemas de Información para tener actualizadas las listas de usuarios en vigor en cada momento, con las distinciones que procedan en cuanto a accesos de tipo confidencial.
• Controlar que las ejecuciones, realizaciones, tiradas, etc. realizadas en producción, sean correctas (entran los ficheros debidos, en contenido y fecha, y se producen las salidas debidas) y completas.
• Ser el punto focal de sus usuarios finales en cuanto a nuevas necesidades, mejoras, modificaciones, etc., de la aplicación, así como iniciar el proceso de la correspondiente petición a la organización de desarrollo y mantenimiento de aplicaciones.

En definitiva, es el que, coordinando y representando a los usuarios finales de “su” aplicación, se relaciona con la Función de Sistemas de Información, ya sea con Producción o con Desarrollo.

Esto quiere decir que cualquier proyecto de desarrollo, desde su planteamiento, por el actual o futuro propietario —y tanto si se trata de un proyecto de nuevo desarrollo como si es una modificación o mejora a una aplicación existente—, debe basarse en su rentabilidad o en una aprobación explícita de la alta dirección (o de la persona delegada).

La rentabilidad tiene como componentes básicos los costes frente a los ahorros y beneficios. Estos componentes deben planificarse en la fase de requerimientos y deben comprometerse, tanto por parte del propietario como de los desarrolladores, al final de la fase de análisis o diseño externo.

Cualquier modificación que se produzca durante el desarrollo, pruebas, integración e instalación, debe dar lugar a una revisión de la rentabilidad comprometida por el propietario. Si esta modificación produjera una rentabilidad negativa del proyecto (es decir, que los costes superan a los ahorros), es necesario recabar la oportuna autorización a la persona delegada de la alta dirección (normalmente el Controller o Interventor General) para poder seguir con el desarrollo del proyecto.

A lo largo del desarrollo es necesario ir contrastando la evolución de los costes reales incurridos, frente a los totales planificados y comparar esa relación con la correspondiente a la parte del trabajo hecho y el total por hacer.

Este contraste, que lo lleva a cabo el responsable del proyecto y que se revisa en las reuniones de seguimiento del proyecto, es básico, ya que, a unos beneficios dados, lo que debe vigilarse es que los costes no se desvíen de los comprometidos. En caso de desviación, y cuando esta haga o vaya a hacer no rentable el proyecto, los desarrolladores deben parar y solicitar autorización a la alta dirección para poder continuar. Es evidente que estos casos suelen ir acompañados de la exigencia de distintos tipos de justificaciones e informes que no son muy deseables para los desarrolladores.

En cualquier caso, dado que la rentabilidad comprometida al acometer el desarrollo de un proyecto es fundamental que se mantenga, cualquier circunstancia que la disminuya, anule o haga o pueda hacerla negativa, debe ser conocida y/o autorizada por la alta dirección, así como también debe ser informada la dirección usuaria y el propietario.

3.1. Implantación

La forma de llevar a cabo la realización y control de un “Business Case” por cada proyecto del plan anual de aplicaciones debe implicar:

• Un control mecanizado del plan de proyectos. Esto se contempla en el Capítulo 7.
• La involucración de la alta dirección, de la dirección usuaria y propietario, y de la dirección de desarrollo.

La articulación de un organismo que garantice y coordine este segundo punto está en función del tamaño de la empresa, de su dispersión o concentración geográfica, del grado de autonomía o delegación —informática— en las distintas organizaciones, de la centralización o descentralización de la informática en su concepto operativo o presupuestario, etc.

En cualquier caso, el establecimiento de este organismo es básico, ya que él es el garante, en principio, a nivel de empresa o entidad, de la rentabilidad del desarrollo de aplicaciones; buscando un paralelismo, es el comité que autoriza la fabricación y comercialización de un nuevo producto en una empresa manufacturera.

Dicho organismo puede tomar diversos nombres, como por ejemplo, de gestión informática, de informática, de rentabilidad informática o de aplicaciones, de informática de usuarios, etc. pero su objetivo básico es que la empresa tenga un plan vigente de proyectos informáticos por desarrollar y que sean rentables individualmente.

Este organismo debe reunirse con una frecuencia predefinida por su presidente (en principio, podría ser tres veces al año). Su presidente debe ser, como ya hemos apuntado, un alto directivo o ejecutivo, delegado de la más alta dirección de la empresa o entidad.

El marco de su actuación global, y su tope máximo, a nivel de costes, debe venir dado por la alta dirección, en cuanto a lo que a desarrollo de aplicaciones se refiere, es decir: recursos humanos y técnicos (Hardware y comunicaciones) existentes y su plan; presupuesto para subcontratación planificado; proyectos vitales, importantes y destacables para la alta dirección (que normalmente involucrarán a varias unidades o funciones de la organización); etc.

El secretario de este organismo debe garantizar, además de la logística y agenda de las reuniones, la existencia de actas que den continuidad a los asuntos destacables, así como el manejo y control del soporte informático que contenga los datos requeridos por proyecto. Este último requerimiento hace deseable que el secretario o su departamento sepa manejar aplicaciones informáticas y lenguajes de usuario final.

Los asistentes a las reuniones convocadas por el presidente son los directores de las funciones usuarias (que son las que solicitan los proyectos), el director de informática, el de desarrollo y el “Systems Assurance” o garante de calidad de la implantación del plan (esta responsabilidad se analiza en el Capítulo 5).

Los ponentes son los directores de los analistas funcionales (que, cuando organizativamente están en las funciones usuarias, pertenecen jerárquicamente a estas funciones, pero dependen funcionalmente de la dirección de desarrollo central) en representación de los propietarios y usuarios de sus funciones y soportados —en las presentaciones de los proyectos solicitados— por los directores de desarrollo con los que se relacionan o relacionarán en esos proyectos.

Para poder calcular la rentabilidad, o el tiempo que transcurrirá para recuperar la inversión, de un proyecto de desarrollo, es necesario conocer sus costes y sus ahorros o beneficios.

Los primeros se producirán antes de que el proyecto se convierta en una aplicación, es decir, antes de que esté en explotación o sea utilizable por los usuarios.

Los ahorros o beneficios se producirán a partir del momento en que los usuarios utilicen la aplicación en producción.

Los componentes que forman parte de los costes de un proyecto de desarrollo, de nuevo cuño o de modificación de una aplicación existente, son: las personas, la subcontratación y los equipos.

Las personas que intervienen a lo largo del desarrollo son de conocimientos y procedencias diversas, pero están ubicados, bien en la organización del usuario —solicitante y futuro propietario de la aplicación—, bien en la organización de informática.

Así, por parte de la función u organización usuaria, intervienen los futuros usuarios finales, representados por el propietario y los analistas funcionales que le dan soporte. Por parte de la organización de informática intervienen los desarrolladores (analistas orgánicos y programadores) y los profesionales de explotación o centro de procesos.

La unidad de medida elemental es la de Mes-hombre o Mes-persona, aunque hay algunos casos —más frecuentes en entornos de fabricación— en que se utiliza la semana en lugar del mes.

Esta unidad de medida es imprescindible para planificar las distintas actividades que a lo largo del proyecto llevarán a cabo los diferentes conjuntos de personas descritos; pero el coste del mes de cada tipo de persona no es el mismo, por lo que es necesario convertir en dinero el coste total de las personas (el coste del mes de cada persona debe ser calculado y debe ser actualizado por el departamento u organización que tenga esa responsabilidad —Planificación, Personal, Costes, etc.— o en último término, por la organización de informática).

La subcontratación se refiere, cuando tiene lugar, al coste de las tareas correspondientes a las distintas personas o conjuntos descritos anteriormente. La facilidad de la subcontratación disminuye, o puede disminuir, en términos generales: (1) en función del tipo de tarea, (2) de las características del subcontratista y (3) de las circunstancias de la empresa que subcontrata; normalmente esta facilidad disminuye cuando las tareas pasan del desarrollo al análisis orgánico, al funcional y a las del propietario/usuario, así como a las de explotación.

En cualquier caso, cuando procede la subcontratación, en el área que sea, es necesario conocer su coste aplicado a las áreas correspondientes. Este coste, así como el correspondiente a lo no subcontratado, debe conocerse antes de comenzar el desarrollo del proyecto.

Dentro del concepto de subcontratación cabe incluir el de la compra de una aplicación o de un conjunto o “paquete” de aplicaciones que resuelvan, aunque no al cien por cien, el problema para el que se solicitó el proyecto de desarrollo.

El tercer componente, los equipos, se refiere, cuando procede, al coste total de aquello que tenga que ser adquirido para el desarrollo, las pruebas o la explotación de la aplicación tanto Hardware como Software u otros dispositivos.

Supongamos, a modo de ejemplo, que hay un proyecto para mecanizar un almacén en cuanto al movimiento de mercancías, y resulta necesario utilizar pistolas-lectoras de códigos de barras que, por radio o por cable, transmitan la información a una unidad de control de comunicaciones. En este caso, todo el coste de lo relativo a la lectura y transmisión debería incluirse como coste del proyecto.

Este mismo criterio es aplicable cuando el proyecto, por sus características, exige una notable ampliación del Hardware y/o Software del centro de procesos, tanto para las pruebas como para la explotación.

Por último, una vez conocidos los elementos y su suma, y antes de analizar los ahorros, es necesario saber si este coste es abordable para la empresa. También es conveniente, aunque el coste no sea excesivo para el presupuesto de la empresa o entidad, examinar la posibilidad de acometer el proyecto —a ser posible en su totalidad— con herramientas e informática de usuario final en la propia función peticionaria.

3.2.2. Ahorros por Proyecto

El cálculo de los ahorros o beneficios que producirá el proyecto cuando, ya en explotación, se haya convertido en aplicación al servicio de los usuarios, pasa de ser una estimación (al dar los requerimientos) a ser un compromiso (una vez hecho el análisis funcional).

Así como en las empresas los costes de los desarrollos, en general —y no con excesivo formalismo ni rigor—, suelen ser contemplados al proponer un proyecto, los ahorros o beneficios del proyecto/aplicación suelen ser considerados con mucho menos formalismo y rigor. Precisamente esto es una causa importante que desencadena una espiral de falta de compromiso por ambas partes:

• Por los desarrolladores, en cuanto a la estimación y al control de los costes.
• Por los usuarios, en cuanto a la estimación y revisión en los beneficios.

Pues bien, la única forma de cortar esta espiral es atacando ambos puntos.

Como ahora estamos tratando de los ahorros o beneficios, debemos dejar bien claro que estos son para los desarrolladores —y por supuesto para la empresa o entidad— la garantía de que su trabajo será útil, lo que, a su vez, produce un efecto motivador tendente a que el “círculo vicioso” descrito se convierta en “círculo virtuoso”.

El desarrollador desconoce la problemática del usuario, por lo tanto, tampoco conoce la utilidad de su trabajo, y si no ve la involucración y el compromiso del usuario, pierde la incentivación de hacerlo bien y en fecha.

Los ahorros o beneficios, como es lógico, los debe dar, explícitamente, la función usuaria que solicita el desarrollo, ya que serán aplicables a sus recursos, tanto humanos como monetarios.

Pueden existir varias formas de dar los ahorros, pero hay dos parámetros básicos que se fijarán:

• Durante cuánto tiempo se van a acumular estos ahorros.
• Con qué “mezcla” de personas y/o dinero y, dentro de cada una de estas variables, con qué diferenciación entre “Reducciones” y “Evitaciones”.

Dado que los ahorros se planifican por años, la primera duda es el tiempo o los años que se van a considerar, a efectos de acumularlos de una forma simple o ponderada.

Para ello conviene tener en cuenta el tiempo estimado en que una aplicación no es modificada. Puede haber diferentes criterios al respecto, basados en informaciones o estimaciones “más o menos” estadísticas de la instalación de la empresa o entidad.

Nuestra mejor estimación es la de considerar que durante dos años, después de su puesta en producción, una aplicación no es alterada de forma que varíen los beneficios anuales previstos y comprometidos. Este criterio debe ser establecido por el organismo al que nos referíamos en el punto 3.1.

Para poder acometer la cuantificación de los ahorros es preciso determinar, en la “mezcla” o sumatorio, cuáles provienen de los recursos humanos y cuáles de los monetarios.

En cada uno de estos recursos hay que decidir cuántos son “Reducciones” y cuántos son “Evitaciones”.

Se entiende por “Reducciones” las personas —en meses-hombre— y/o el dinero —normalmente en miles de pesetas— que se dejarán de utilizar y/o gastar en la función o funciones usuarias cuando la aplicación esté en producción. Lógicamente, estos recursos serán parte de los que se dedicaban para la tarea o proceso que se propone informatizar.

Entendemos como “Evitaciones” los recursos humanos y/o monetarios (en las mismas unidades de medida de antes) que no será necesario incrementar en la función o funciones usuarias, aunque aumenten previsiblemente los volúmenes de información o de negocio que hay que tratar (nuevos productos, nuevos clientes, etc.).

3.3. Rentabilidad

Un proyecto de desarrollo, después de estar en explotación, es rentable si sus ahorros o beneficios igualan o superan a sus costes. Pero, ¿Cuándo?, ¿Nada más convertirse en aplicación o a los cinco años?

Al punto, o momento en el tiempo, en que la suma de los beneficios o ahorros anuales iguala a la de los costes o inversión, le llamamos “Recuperación de la Inversión” (R.I.). A partir de este momento la inversión empezará a ser rentable ya que los beneficios acumulados superarán a los costes.

Antes de fijar el valor del R.I. vamos a separar los proyectos de desarrollo incluidos en el plan anual en dos tipos:

• Proyectos “identificados individualmente” cuyo esfuerzo de desarrollo sea superior a tres meses-hombre.
• Proyectos no identificados individualmente, destinados generalmente a “mejorar” aplicaciones existentes en producción.

Los primeros son los que corresponden a la definición dada, y su R.I. se establece en dos años (o menos), dado que en este tiempo consideramos que se mantienen y acumulan los beneficios de una aplicación.

Los segundos son aquellos cuyo esfuerzo de desarrollo individual se estima, en principio, en menos de tres meses-hombre. La mayoría de ellos se refiere a la realización de pequeñas mejoras en aplicaciones ya existentes, por lo que se les conoce generalmente como proyectos de “mejora”.

Como resultaría excesivamente largo incluirlos en el plan anual de forma individualizada y, además, sería muy costoso su control siguiendo los mismos criterios que para el resto de los proyectos, es más práctico y operativo agrupar los esfuerzos estimados en conjuntos o bolsas por aplicación (a la que se refieran).

De esta forma se simplifica el plan anual y no se pierde el control de la rentabilidad individualizada, ya que esta responsabilidad la puede delegar el presidente del organismo o comité de rentabilidad en el director de desarrollo que lleve la aplicación referida en el plan. En cualquier caso, el director de desarrollo no podrá empezar un proyecto de “mejora” sin cerciorarse y responsabilizarse de que será rentable; si en algún caso no lo fuera, deberá recabar autorización a dicho presidente para poder comenzarlo.

Este tipo de proyectos de “mejora”, aunque son de poco esfuerzo, suelen ser muy importantes y muy urgentes porque suelen estar causados por nuevos imperativos de orden legal, comercial, de control, etc. Estos imperativos determinan una gran urgencia en su instalación y unos grandes ahorros a corto plazo.

Por todo ello, a los proyectos de “mejora”, individualizados o en conjuntos o bolsas, se le aplica un R.I. de un año (o menos).

3.4. Cálculo del Factor

Basándonos en lo expuesto hasta aquí, calculamos el cociente, al que llamamos factor, entre ahorros y costes

                                        Ahorros (dos años en Producción)

               FACTOR =  

                                            Costes (del desarrollo)

Los AHORROS se obtienen con la suma de los referidos a recursos humanos (personas) más los que se refieren a recursos monetarios (miles de pesetas – KPTAS –).

En ambos casos se aplica un coeficiente de ponderación que refleja si el ahorro proviene de “Reducciones” o de “Evitaciones”, según lo explicado en 3.2.2.

Estos coeficientes de ponderación son:

	“Reducción”	“Evitación”
En Recursos Humanos	3	1
En Recursos Monetarios	1,5	0,5

Por lo tanto, los ahorros procedentes de recursos humanos serán, si es que existen:

Coste anual del tipo de persona (administración, ventas, finanzas, personal, etc.) x número de personas al año x dos años x el coeficiente de ponderación aplicable.

En el caso de que hubiera distintos costes de persona, por tratarse de distintos tipos de trabajo, y/o distintos tipos de coeficientes de ponderación, se procede a efectuar el sumatorio correspondiente. Estos datos los facilita la función peticionaria y afectarán a sus propios recursos humanos.

De forma similar, aunque más simplificada, los ahorros procedentes de recursos monetarios se calcularán, si es que existen, del siguiente modo:

KPTAS anuales x dos años x el coeficiente de ponderación.

Estos datos los suministra la función peticionaria y se refieren a sus propios recursos monetarios, que se verán afectados, análogamente, cuando el proyecto se convierta en aplicación.

Los COSTES se obtienen sumando los planificados para el proyecto, tomando como base los meses netos de dedicación al proyecto:

Meses-persona de desarrollo + meses-persona de analistas + meses-persona de subcontratación + meses-persona de usuarios + meses-persona de centro de procesos (básicamente para el paso a producción).

A estos costes, en KPTAS, se deberán añadir, si ha lugar, los adicionales a equipos o software especial del proyecto.

Al final, habremos determinado el valor del FACTOR.

Como ya hemos expuesto, el R.I. debe ser distinto, según el tipo de proyecto.

• Para proyectos “identificados individualmente”, cuyo esfuerzo en desarrollo excede los tres meses-persona netos:

El FACTOR debe ser igual o mayor que 1. Esto significa que el R.I. es de dos años o menos, ya que en el cálculo, el denominador (costes) será igual o menor que el numerador (ahorros en dos años).

• Para proyectos de “mejora”, o conjuntos de ellos, cuyo esfuerzo individual no excede de tres meses-persona netos de desarrollo:

El FACTOR debe ser igual o mayor que 2. Esto significa que el R.I. es de un año o menos en cada proyecto de “mejora”, ya que el denominador (costes) es la mitad o menos que el numerador (ahorros en dos años).

Por último, no podemos olvidarnos que en el plan anual de proyectos existen también los proyectos de mantenimiento.

En el plan anual deben incluirse, como proyectos de mantenimiento, solamente aquellos que se refieran a Mantenimiento Correctivo, que se analiza con detalle, junto con otros tipos de mantenimiento, en los Capítulos 5 y 10.

Baste decir aquí, que este tipo de proyectos no es rentable y que, por lo tanto, en el plan anual deben especificarse con toda claridad, tanto el esfuerzo planificado para cada uno, como a qué aplicación individualizada se refiere y, evidentemente, deben ser estrictamente controlados a lo largo del tiempo para garantizar el no exceso del “gasto”, ya que los esfuerzos consumidos en este tipo de proyectos equivalen a la disipación de calor en una máquina que proviene de un consumo de energía “innecesario”, es decir, no tienen ningún beneficio o ahorro como contrapartida.

El tema de la rentabilidad que hemos visto y analizado, como la mayoría de los temas en los negocios, puede ser acometido de otras formas y con otras alternativas, en función del propio criterio de la empresa o entidad.

Una de las más conocidas —y usadas en los casos de desarrollos de sistemas operativos o aplicaciones de gran difusión— es la de ir acumulando los costes, planificados y reales, anualmente durante el desarrollo; del mismo modo, se van acumulando los beneficios o ahorros, también anualmente, a partir de la fecha de disponibilidad de la aplicación. Lógicamente, el retorno o recuperación de la inversión se produce cuando ambas cantidades se igualan.

En estos casos de grandes sistemas o aplicaciones (algunas se miden en millones de líneas de código) la recuperación de la inversión va más allá de los dos años.

Lo que sí debe quedar claro es que los proyectos de desarrollo informático, del plan de una empresa o entidad, deben basarse en la rentabilidad individualizada y, excepcionalmente, en la aprobación expresa y formal de la alta dirección; nunca en la “inspiración”, la intuición o la “habilidad dialéctica”, que se apoyan muchas veces en el poder de la jerarquía.

4

Parece obvio afirmar que cualquier empresa o entidad debe tener un plan informático anual —y nos referimos concretamente al plan de proyectos de desarrollo— que, además, esté revisado dos o tres veces al año. Estas revisiones mantienen actualizado el plan que, incluso después de revisado, podría continuar siendo el mismo.

En general, a cualquier empresa que se le pregunte si tiene un plan de proyectos de desarrollo, la respuesta es afirmativa. Efectivamente tienen un plan, mejor dicho, tienen “su” plan, con “sus” criterios que, generalmente, no son suficientes —para que sea formal y consistente—, aunque sean los mínimos necesarios para “manejarse”.

Veamos lo que, al menos, un plan de proyectos de desarrollo debe contener y debe contemplar:

• Un plan de desarrollo debe ser el único punto de referencia para saber qué se está haciendo y qué se va a hacer.
• Este plan debe servir para planificar y asignar los recursos humanos que se dedicarán a su implantación.
• Debe contener los proyectos que están en desarrollo, aunque se hayan empezado hace años, con los recursos que se han consumido hasta la fecha de vigencia del plan.
• El plan de desarrollo debe contener los proyectos pendientes de empezar, así como los recursos humanos que se van a consumir anualmente, si su duración lo necesita.
• El plan debe contener aquellos proyectos que son rentables (o tienen la autorización expresa) en principio —en fase de requerimientos—, o en firme —después del análisis funcional—.
• El plan debe contener, a nivel de proyecto, la cantidad de recursos humanos a emplear cada año, diferenciando los que son de la función usuaria —básicamente analistas funcionales— y la subcontratación prevista, así como los que se refieren a desarrolladores —básicamente analistas orgánicos y programadores— y la correspondiente subcontratación. Lógicamente estos conceptos deberán sumarse a nivel de función usuaria y totalizarse a nivel de empresa o entidad.
• El plan de desarrollo vigente debe ser el último eslabón de una cadena de planes y, por tanto, debe ser una continuidad del anterior, y este, a su vez, de su predecesor. A través de los tres o cuatro últimos planes debe existir la garantía de que no han “desaparecido” proyectos comenzados en otro momento —sin la correspondiente justificación y aprobaciones del organismo que sanciona el plan—, así como de los incrementos en esfuerzos de proyectos en desarrollo.

4.1. Secuencia del Proceso

El plan de proyectos debe ser construido “de abajo a arriba”, es decir, a partir de las necesidades informáticas de los usuarios finales. Tiene que admitirse, como punto de partida, que quienes conocen los problemas de la operativa del negocio son los usuarios y, por lo tanto, quienes pueden demandar soluciones son ellos.

Hay que entender que los problemas de los usuarios finales no son ni se limitan a los que pueden detectar los profesionales, sino también los que, detectados por su dirección, existen en las funciones para la gestión y optimización de sus objetivos de negocio, como parte de los objetivos de la empresa o entidad.

De este modo se crea la base de las necesidades informáticas, es decir, el “caldo de cultivo” del plan de las funciones usuarias.

Estas necesidades de desarrollo de proyectos informáticos se hacen llegar a los “departamentos de informática de las funciones”, que están compuestos por analistas funcionales y que tienen como primer objetivo el conocimiento y análisis de la problemática de la función, así como hacer un primer diagnóstico de viabilidad para su solución informatizada.

Estos departamentos, según comentábamos en el punto 3.1, deben estar engranados con el de informática de la empresa o entidad a través de una subordinación funcional que determina y aprueba, entre otras cosas, el tamaño de estos departamentos, las aptitudes necesarias para acceder a ellos, las categorías y los ascensos dentro de ellos y los posibles trasvases entre departamentos de informática funcional de distintas funciones.

Pues bien, estos departamentos de informática funcional constituyen el primer eslabón del proceso de generación del plan de aplicaciones de la función en la que están incardinados, ya que una vez conocidos los embriones de proyectos informáticos —que resolverán los problemas de gestión, “en el más amplio sentido de la palabra”, de su función— deben consolidarlos por las posibles áreas en que esté subdividida la función, sugiriendo quiénes serán los propietarios de las futuras aplicaciones y relacionándose con los actuales propietarios de las aplicaciones existentes.

A continuación deben consolidar las necesidades de la función pero, antes de llevar este plan previo al director de su función, deben recabar de los actuales o futuros propietarios los beneficios que reportará a la función y, por ende, a la empresa o entidad, la puesta en marcha de los proyectos.

Es necesario estimar también los esfuerzos que deberá aportar la función —tanto en analistas funcionales, como en usuarios— para el desarrollo de estos previsibles proyectos.

Antes de presentar este plan previo a la dirección de su función, es necesario reunirse con el departamento de desarrollo e intercambiar información sobre los proyectos de este plan para conocer los esfuerzos estimados de desarrollo individualizados.

Con la cuantificación previa de este plan “en bruto” es necesario que el departamento de informática se reúna con la dirección de su función para poder analizar aspectos tales como:

• Qué proyectos son, en principio, más rentables.
• Qué proyectos son más importantes, trascendentales o vitales.
• Qué esfuerzos y costes puede abordar la función, con los recursos de que dispone.

En paralelo con esta actividad funcional, en la organización de desarrollo se estudian y acoplan los esfuerzos y tiempos estimados por proyecto.

Durante esta gestación previa son necesarias distintas reuniones e intercambios de información entre los analistas funcionales y los desarrolladores para ir encajando el plan que, lógicamente, va a estar constituido por: nuevos, continuación de proyectos de desarrollo, modificaciones de cierta entidad a aplicaciones existentes, mejoras a aplicaciones o cadenas de aplicaciones, y mantenimientos correctivos.

De todos estos componentes solamente los últimos suelen ser estimados por los propios desarrolladores; el resto debe ser estimado por analistas y desarrolladores, cada uno en su área de responsabilidad.

Una vez que el plan funcional tiene los costes y ahorros previstos, y se ve abordable la realización, entonces, el departamento de informática funcional valida la rentabilidad individual y clasifica su plan con algún criterio de prioridad —normalmente el de la rentabilidad— distribuyéndolo entre las distintas áreas que componen su función.

Ahora es cuando, con la aprobación previa de la dirección funcional, el departamento de informática de cada función envía copia de su propuesta de plan al departamento del secretario del comité de rentabilidad. Este último departamento:

• Valida si existen todos los datos necesarios.
• Valora y totaliza el plan funcional.
• Incluye los proyectos de mantenimiento, que le facilitan los desarrolladores.
• Consolida los distintos planes funcionales y obtiene unos totales, previos a la celebración de la reunión del organismo o comité.

Si los totales están encuadrados en los límites establecidos por la alta dirección, básicamente en cuanto a:

• Recursos humanos, tanto funcionales como de desarrollo.
• Costes de subcontratación y costes específicos para la puesta en marcha del plan, entonces se procede a la celebración de la reunión del comité, organismo, etc. que ya hemos comentado en el capítulo anterior. En caso contrario, es decir, si los recursos o costes sobrepasan los límites establecidos, el secretario lo hace saber a la o las funciones correspondientes con el fin de que se reajuste el plan. Una vez reajustado y remitido, se procede a la reunión de revisión de rentabilidad.

En esta reunión, cada función debe comentar cada uno de sus proyectos que, como ya hemos dicho, deberán cumplir los requisitos de rentabilidad exigidos. Asimismo, la organización de desarrollo también debe comentar los proyectos de mantenimiento.

El presidente de la reunión, organismo o comité de rentabilidad debe tener criterio y autoridad para, escuchando los razonamientos funcionales y las casuísticas de los proyectos, sancionar los planes funcionales o alterarlos —cambiando las prioridades, los recursos, cuestionando el enfoque en los costes, o por otras razones de alta dirección (a la que representa o a la que pertenece)—. En el caso de alteración de los planes, aquellas funciones que se vean afectadas deben ser citadas para revisar y aprobar sus nuevos planes.

Estas posibles iteraciones deben ser de corta duración y, en casos excepcionales, si persisten las discrepancias, deberán ser llevadas a un comité o reunión con la alta dirección, en donde la función que crea verse afectada debe exponer la discrepancia y proponer la posible solución.

El secretario debe redactar un acta, que se envía a las funciones, con los eventos destacables producidos en la reunión; este acta la firmará el presidente.

Una vez aprobados los planes funcionales y, como consecuencia, el de la empresa o entidad, cada función puede establecer las prioridades entre sus proyectos —contando con los desarrolladores cuando estos tengan que intervenir—.

Este plan funcional con prioridades se consolida y distribuye a todas las funciones. Esta distribución se hace desde el departamento del secretario de la reunión de rentabilidad para:

• Que el plan de proyectos de desarrollo sea conocido en todas las funciones (directores y “departamentos de informática funcional”).
• Que el plan vigente sea el único punto de referencia para que toda la empresa pueda saber lo que se está desarrollando y lo que se va a desarrollar en informática de aplicaciones.

4.2. Alternativas y Revisiones

No cabe duda que la experiencia —y sobre todo cuando esta es positiva— induce a caer en la tentación de pontificar sobre el tema. Nada más lejos de nuestro ánimo.

De hecho, existen estudios como, por ejemplo, uno de Martin D.J. Buss donde se analiza otra alternativa en el establecimiento de prioridades a proyectos informáticos que, en nuestra opinión, no difiere mucho del descrito, aunque el proceso es más elaborado.

Además de los mencionados, muchas empresas, como decíamos, tienen “sus” procesos para generar el plan de proyectos y para asignar prioridades; unos serán mejores y otros peores, pero creemos que todos están en evolución, mejorando aspectos parciales e incluyendo aspectos nuevos.

Lo que sí es claro es que el proceso utilizado, debe cumplir unos ciertos requisitos que garanticen ante la propia empresa o entidad, así como ante cualquier eventual revisión o auditoría, aspectos tales como:

• Que el proceso en vigor esté consensuado con los involucrados en él, así como que esté respaldado por la alta dirección o alguien —con autoridad ejecutiva— en quien esta haya delegado.
• Que exista (lo debe decir el proceso, si existe) una relación de proyectos en desarrollo y otra de los pendientes de desarrollar por cualquier razón (falta de recursos, poca prioridad, etc.).
• Que cada proyecto —tanto en desarrollo como pendiente— tenga los esfuerzos, costes y ahorros estimados.
• Que se pueda demostrar que la dirección (tanto ejecutiva como de las funciones usuarias) esté involucrada, interesada y comprometida con los proyectos de desarrollo.
• Que los proyectos sean rentables y prioritarios para las funciones usuarias y para la empresa o entidad.
• Que el plan actual, si existe, tenga una continuidad con el previo, y este con el anterior.
• Que se conozcan los proyectos cancelados en el último año, después de haber comenzado el análisis y/o el desarrollo, así como el coste incurrido, las razones y aprobaciones que existieran.

5

La finalidad de la generación del plan de desarrollo de aplicaciones informáticas, como la de cualquier otro plan seriamente establecido, es su realización, acorde con él y con la mayor rigidez y exactitud posible, al tiempo que con una cierta flexibilidad —controlada al máximo—, si las circunstancias lo exigen.

Así como la generación del plan de aplicaciones, según hemos visto en el capítulo anterior, exigía algunos sincronismos entre las funciones usuarias y la organización de desarrollo, la puesta en marcha del plan exige, a lo largo del desarrollo de cada proyecto, más sincronismos —en las pruebas de cadenas, en las de sistemas, en el paso a producción, en la educación o formación de los usuarios, etc.— y, además, entre las organizaciones anteriores y el centro de procesos o centro de explotación.

Todos estos sincronismos añadidos ponen a prueba la madurez organizativa y de control que reside, durante la realización y control del plan, en la organización de desarrollo.

Esta organización de desarrollo, del mismo modo que la línea de producción en una fábrica, debe demostrar, a lo largo de la realización del plan, la excelencia en los procedimientos de trabajo, la calidad creciente de los productos y la evolución de los objetivos numéricos de control del plan. Todo ello mediante una gran transparencia de información a las funciones usuarias y con el principal objetivo de obtener la máxima eficiencia en la realización del plan.

5.1. Componentes

Los ingredientes o componentes que intervienen en la realización del plan se analizan contestando a las clásicas preguntas: qué, quién, cómo y cuándo.

5.1.1. Qué hacer

El plan de desarrollo, o de aplicaciones, o de proyectos de desarrollo —como lo queramos llamar— es la tarea a realizar, y se compone de:

• Proyectos de desarrollo nuevos (sin comenzar).
• Proyectos de desarrollo que continúan (ya comenzados).
• Modificaciones y/o Mejoras a aplicaciones existentes.
• Mantenimiento de aplicaciones existentes.
• Instalaciones en producción de cualquier cambio en este entorno que se derive de cualquiera de los cuatro puntos anteriores.

5.1.2. Quién dirige, coordina y controla

Esta cuestión es importante y su respuesta es función del tipo de organización informática de la empresa o entidad —centralizada, semi-descentralizada, etc.— y del tipo de proyecto —funcional, multifuncional, grande, pequeño, etc.—.

Para poder analizar estas posibilidades es preciso aclarar las distintas posiciones y responsabilidades, directivas y profesionales, que pueden intervenir a lo largo del desarrollo de un proyecto.

“Project Leader” o Coordinador del Proyecto, es la persona que lidera la realización de un proyecto, estableciendo el plan, acordándolo con las personas o departamentos involucrados, coordinando las interacciones entre ellos e informando a la dirección de informática y/o funcional. Esta persona no tiene el control jerárquico de ninguna de las personas o departamentos involucrados en el desarrollo. El perfil de sus aptitudes está basado más en su capacidad de organizar, planificar y coordinar, que en su formación técnica (aunque debe tener conocimientos).

El papel de “Project Leader” es difícil de desempeñar por la dificultad que entraña el coordinar (que, a veces, es una pseudodirección) a personas o departamentos que no dependen de él. Si la elección no es buena, se puede convertir en una especie de “perseguidor o de ‘acusador” que puede repercutir negativamente en el desarrollo del proyecto.

Esta figura puede ser apropiada cuando la organización informática está bien consolidada y cuando el proyecto pertenece y afecta a una sola función usuaria. En este caso, esta responsabilidad puede ser desempeñada, en principio, por un analista funcional que cumpla los requisitos expuestos.

Este tipo de organización (con un “Project Leader”) tiene la ventaja de que, si a lo largo del desarrollo, por distintas causas, se producen “baches” o “puntas” en la carga de trabajo, los departamentos involucrados pueden utilizar los recursos ociosos (baches) en otras actividades o proyectos, o, por el contrario, pueden asignar recursos adicionales (puntas). Es decir, se pueden obtener ventajas de la flexibilidad, aunque esta flexibilidad —sobre todo en el caso de “puntas”— sea más teórica que real.

“Project Manager” o Director de Proyecto, es una persona, con categoría de director —bien en la organización de desarrollo, o en la de informática, tanto funcional como central— con las mismas responsabilidades básicas que el “Project Leader”, pero con alguna diferencia fundamental.

En primer lugar tiene, al menos durante la realización del proyecto, la dirección de las personas —expresamente nominadas— que van a desarrollarlo y que, lógicamente, provienen de distintos grupos y departamentos. Esto le da mayor capacidad de decisión y maniobra a lo largo del desarrollo, aunque la nominación de los componentes del equipo no suele ser fácil y se suele negociar con ciertas dificultades.

En segundo lugar, al tener mayor autoridad delegada, tiene también mayor responsabilidad en el manejo de los recursos humanos y en el cumplimiento de los compromisos de realización del proyecto.

Este tipo de organización (con “Project Manager”) puede ser apropiada en el desarrollo de proyectos multifuncionales o de proyectos específicos (generalmente técnicos) o para conjuntos de pequeños proyectos de mejora referidos a aplicaciones concretas. En estos casos, esta responsabilidad puede desempeñarla un director de la organización de desarrollo o de la organización informática central.

Esta organización tiene la ventaja básica de que la responsabilidad es única, de cara a la función usuaria y a la dirección.

Como se ve, en función del tipo de proyecto de que se trate y de la madurez organizativa de la informática de la empresa o entidad, se puede enfocar la responsabilidad del desarrollo de distintas formas, aunque cualquiera de ellas no exime a cada departamento del ejercicio de sus responsabilidades (función usuaria, analistas funcionales y desarrolladores), así como tampoco exime de la involucración y control a la dirección de informática.

5.1.3. Cómo controlar la Realización del Plan

El sistema de seguimiento y control más rico en información es, sin duda, el de las reuniones periódicas, generalmente con frecuencia mensual, en las que el responsable del proyecto informa, documentadamente, sobre la situación a la fecha frente a la planificada y, cuando existen desviaciones, explica sus causas y los planes de acción alternativos —entre los que está el que él selecciona y recomienda— para recuperar el desajuste entre plan y real o actual.

Estas reuniones están presididas por el director de informática o el de desarrollo, asisten los directores y, a veces, los profesionales más destacados, tanto del departamento de desarrollo como del departamento de informática funcional; también puede asistir el director de la función usuaria. Normalmente, una copia del acta se envía a la persona o departamento del secretario del comité de rentabilidad (ver Cap. 4.1) para posibilitar el seguimiento del plan.

En estas reuniones, que convoca el director de desarrollo, se revisan los proyectos más críticos o problemáticos con más detalle, aunque se da un repaso general al resto de proyectos.

Como es natural, también puede existir otro tipo de reuniones de revisión que se convocan a petición de la alta dirección y que suelen ser relativas a un proyecto específico.

Otra forma de control y ayuda, en aquellos proyectos que las circunstancias lo aconsejan o exigen, son las revisiones técnicas, en general llevadas a cabo por otros profesionales de la misma empresa o entidad, que analizan y ayudan a solventar los problemas técnicos que tenga el desarrollo con el fin de evitar o corregir desviaciones, básicamente, en cuanto a los recursos que se están consumiendo o en cuanto al posible desplazamiento de la fecha de terminación.

En numerosas ocasiones estas revisiones técnicas suelen originarse en las reuniones de seguimiento mensuales o por iniciativa de “Systems Assurance” (cuyas responsabilidades veremos en el punto 5.1.4.2) y se llevan a cabo por profesionales del Centro de Soporte al Desarrollo (del que también hablaremos a continuación), o incluso por profesionales externos a la empresa o entidad.

Está claro, por último, que estas reuniones periódicas aludidas anteriormente, deben tener un soporte mecanizado a disposición de los asistentes y en el que se base el ponente, con los datos de plan y a la fecha, del proyecto que se está revisando.

Hasta aquí hemos visto el control de los proyectos a lo largo de su desarrollo, pero es necesario también conocer, una vez terminado el proyecto, es decir, una vez que se ha convertido en una aplicación en producción, cuál es el resultado real frente al plan de su etapa de desarrollo para, en primer lugar, validar o contrastar la estimación (esfuerzos, requerimientos, etc.), que se hizo antes de comenzarlo y que se revisó después del análisis funcional, y, en segundo lugar, para que, a través del análisis de las posibles causas y efectos, se puedan evitar los mismos errores o se mejoren ciertos criterios para el futuro.

Los mejores índices en un análisis “a posteriori” son los numéricos, ya que permiten compararlos con los de otros proyectos —pasados y presentes—. Estos índices, lógicamente, se deben obtener de forma homogénea, para que se garantice la validez de la comparación y sirvan de base para proyecciones futuras de optimización.

Estos índices numéricos se deben basar en una unidad de medida única. La que nosotros hemos experimentado, llamada Puntos Función (Function Points) la analizaremos en la Parte 3: Recursos.

Existen otras unidades de medida utilizadas en algunas empresas o entidades que generalmente se basan en los “miles de líneas de código”. Esta medida es de aplicación en proyectos de millones de líneas (sistemas operativos por ejemplo), pero en los casos normales de proyectos de gestión tiene una gran diversidad —o falta de acuerdo— en cuanto a los criterios que hay que seguir sobre las líneas de código que se miden: ¿son de código fuente u objeto?, ¿tienen el mismo valor en un lenguaje de alto nivel que en uno básico, tipo Assembler?, ¿se cuentan como líneas de código las sentencias de control para la ejecución en producción?, etc. Como es lógico, con estas disparidades no es posible la comparación entre empresas.

También es discutible el criterio de medir la productividad basándose en las líneas de código, es decir, ¿es más productivo un programador que usa diez sentencias para una simple suma u otro que para la misma suma usa una sentencia?

Pues bien, basándonos en la medida de los Puntos Función (ver Capítulo 17), se derivan medidas tan importantes como:

• Producción total: Puntos Función producidos al mes o año.
• Productividad: Puntos Función / mes-hombre.
• Calidad: Fallos / Puntos Función.

Otra medida es la llamada “on-target”, que es una unión del conjunto de los proyectos terminados cumpliendo la fecha comprometida y del de los proyectos terminados con el coste de recursos humanos comprometidos.

Estas medidas se verán con más detenimiento en la Parte 3: Recursos.

En cualquier caso, adelantaremos que cuando un proyecto se termina en fecha y cumple las funciones previstas en su fase de requerimientos, son imputables a la función usuaria, por las organizaciones competentes de la empresa o entidad, los ahorros que comprometieron en el “Business Case” ante el comité u organismo de rentabilidad (Capítulo 3).

5.1.4. Cómo dar Soporte a la Realización del Plan

El soporte que vamos a analizar se refiere a los aspectos técnicos o profesionales relativos a las actividades que se van a llevar a cabo para la realización del plan, así como al soporte a la dirección en el nivel técnico requerido.

Estas actividades técnicas se refieren a las de:

• Los analistas funcionales que, como ya hemos dicho, pueden pertenecer jerárquicamente a las funciones usuarias y funcionalmente a la dirección central de desarrollo; de esta relación funcional reciben soporte técnico para las actividades de las fases de requerimientos y análisis funcional.

5.1.4.1. Centro de Soporte al Desarrollo

La responsabilidad básica del departamento de soporte consiste en investigar, seleccionar, conocer, enseñar y solucionar los problemas que surjan en el uso de nuevas herramientas técnicas, controles, metodologías, productos, etc. que ayudan a conseguir el grado de excelencia en todas las actividades del desarrollo.

Dentro de los cometidos técnicos de soporte, este departamento ayuda a mejorar la productividad y la calidad de los desarrolladores en áreas tales como el análisis de errores repetitivos en pruebas (aplicando, por ejemplo, técnicas como la conocida “espina de Ishikawa” y/o los diagramas de Pareto), la optimización de las pruebas en cadena interrumpidas por errores (los conocidos “regression test”), la organización para utilización de código reutilizable, etc.

Asimismo el soporte debe proyectarse hacia la dirección, tanto de desarrollo como de las funciones usuarias, en cuanto a la dotación de recursos humanos en cada organización. En este aspecto, los recursos humanos en las funciones usuarias, en relación con los de desarrollo, son función del grado de mecanización de la empresa o entidad, y, por lo tanto, la proporción es variable.

Un modo de apreciar, aunque de forma elemental, el grado de mecanización es comparar los esfuerzos planificados para proyectos de mejora con los planificados para el resto de proyectos de desarrollo.

Si los correspondientes al primero (mejoras) son inferiores a los del resto de proyectos, entonces el grado de mecanización, en principio, no es muy alto. En este caso los analistas funcionales deben ser, aproximadamente, entre un cincuenta y un treinta por ciento de los recursos humanos de desarrollo (analistas y programadores).

Si, por el contrario, los esfuerzos planificados para proyectos de mejora igualan o superan a los correspondientes al resto de proyectos de desarrollo, podríamos decir que el grado de mecanización de la empresa o entidad es alto o muy alto, en cuyo caso los recursos humanos dedicados a análisis funcional deben ser reducidos considerablemente.

Los objetivos primarios del departamento de soporte para realizar el plan de desarrollo deben tender a la optimización de los recursos humanos y a la excelencia de las actividades a realizar, ya que, para los usuarios y para la empresa en general, la organización de desarrollo es una especie de “monopolio” al que tienen que acudir para conseguir sus necesidades informáticas.

Este departamento de soporte de desarrollo también debe llevar a cabo el establecimiento y control de las relaciones entre los desarrolladores y su “cliente inmediato” (entendiendo por cliente inmediato al siguiente eslabón en la cadena del servicio informático), que es el Centro de Procesos o Explotación.

Estas relaciones entre Desarrollo y Explotación son bidireccionales ya que, en un sentido, los desarrolladores pasan el producto o proyecto a los de explotación, pero, en sentido contrario, es el departamento u organización de explotación quien provee de los recursos necesarios de Hardware y Software a los desarrolladores para realizar sus actividades.

Por lo tanto, es importante llegar a acuerdos de servicio, gestionados entre el departamento de soporte de desarrollo y el de explotación, en los que se establezcan las características y los niveles de servicio que Desarrollo debe recibir de Explotación.

Dentro de este acuerdo de servicio —que debe ser renovado, como un contrato, cuando las condiciones cambian— deben existir “cláusulas” referentes a: independencia de los entornos de pruebas y de mantenimiento; capacidad de máquina (procesador, almacenamiento y cualquier otra característica); tiempo de respuesta en editores, transacciones, procesos batch, etc.; horario del servicio e interrupciones planificadas; disponibilidad del servicio en los terminales; número de interrupciones máximas del servicio; etc.

El departamento de soporte debe controlar el cumplimiento del acuerdo de servicio y hacer llegar a la dirección de Desarrollo las excepciones.

Este departamento, además de dar soporte técnico a la dirección al nivel adecuado (en charlas, reuniones, cursos, etc.), coordina y divulga el uso de plataformas técnicas, los métodos que se seguirán y las herramientas técnicas que usarán los distintos profesionales ya descritos.

El origen normal de los componentes del departamento o centro de soporte al desarrollo suele ser el propio departamento de desarrollo y su tamaño puede oscilar entre un cinco y un diez por ciento del de los analistas y programadores.

5.1.4.2. Systems Assurance o Garantes de Calidad y Control

Las personas que desempeñan la función de Systems Assurance (en algunos casos se les denomina “Project Assurance”), que hemos dado en llamar “Garantes de Calidad y Control” tienen el cometido básico de actuar como auditores o revisores del proceso de desarrollo, con el objetivo de servir de ayuda a los profesionales y dirección que intervienen, por medio de medidas y controles internos.

Esta importante función o cometido tiene el siguiente marco de referencia:

• Debe ser independiente de los desarrolladores (analistas funcionales, orgánicos y programadores), y su línea jerárquica puede ser, bien el director de toda la organización de desarrollo central, bien el director de informática de la empresa o entidad. Por nuestra experiencia, es aconsejable que, en principio, dependa del director de desarrollo, ya que es el garante del proceso de desarrollo.
• El número de personas que desempeña esta responsabilidad debe ser reducido, y se aconseja no sea superior al cinco por ciento del total de desarrolladores.
• Sus componentes deben tener formación técnica y experiencia en gestión y dirección de proyectos. Por lo tanto, la valoración de su responsabilidad es alta, aunque no tienen responsabilidades de dirección de personas (podría ser una posición previa a la de director de una parte del desarrollo).

En cuanto a sus áreas de actuación, las podemos separar en dos grupos: proceso de desarrollo y soporte a dirección.

Con respecto al proceso de desarrollo, Systems Assurance debe revisar o auditar, además de evaluar, los siguientes aspectos:

• La validez y coherencia de los planes de los proyectos, antes y después de aprobarse en el comité u organismo de rentabilidad. Para ello debe ser un buen interlocutor con los responsables de los proyectos y debe estar respaldado, tanto por su prestigio profesional como por el apoyo de su dirección.
• Los riesgos de los proyectos a lo largo de su desarrollo. Para ello debe disponer de algún procedimiento o herramienta que le sirva para decidir y comunicar, tanto a los involucrados como a la dirección, que un proyecto está en alto o medio riesgo. Para su detección existen unas relaciones de comprobación que, en función de ciertos síntomas, él solicita —del responsable del proyecto— su cumplimentación. Una vez revisada y valorada esta relación por Systems Assurance, este decide la calificación del riesgo, la comunica, pone en marcha el procedimiento que se seguirá y controla su evolución hasta la desaparición del riesgo o su recalificación como riesgo menor o bajo.
• El cumplimiento de los controles de la metodología establecida para el desarrollo. Para ello Systems Assurance debe:
  • Asistir a las reuniones mensuales de revisión de proyectos o, al menos, tener copia del acta que se produzca.
  • Intervenir, validar y ser el depositario de los documentos firmados por quienes corresponda, al dar por terminada una fase del desarrollo para poder comenzar la siguiente (estas fases se ven en la Parte 2: Procesos).
  • Garantizar que los aspectos de “seguridad informática” y de “auditabilidad de las aplicaciones” no solamente se han tenido en cuenta en el desarrollo de los proyectos, sino que se han implantado y probado adecuadamente (estos importantes conceptos se explican en la Parte 2: Procesos).
• Que el producto final, esto es, la aplicación, tenga la calidad requerida en cuanto a que cumple las funciones o requerimientos expresados por el usuario/propietario en su planteamiento. Esto forma parte de la debida cumplimentación y firma de las fases del Desarrollo que se han ido aprobando, ya que es una garantía de evitar sorpresas al final, tales como “esto no es lo que quería el usuario”, que crean situaciones difíciles y, sobre todo, pérdida de esfuerzos y costes por haber sido mal empleados.

En cuanto al soporte a dirección, como segunda área de actuación de Systems Assurance, este se concreta, además del que la dirección recibe con el soporte al proceso de desarrollo, en los siguientes aspectos:

• Asesora a la dirección en el establecimiento de los posibles objetivos numéricos que se deben cumplir, tales como Productividad (Puntos Función/mes-hombre), Calidad (Fallos/Punto Función), “On-target” (en fecha y esfuerzos previstos), Esfuerzos indirectos sobre esfuerzos totales, Grado de avance en etapas de subcontratación, Coste de calidad (coste de corrección de fallos y número de estos), Eficacia o madurez global del proceso de desarrollo (mediante autoevaluaciones anuales de la organización), etc.
• Asesora a la dirección también en cuanto a los planes de acción para conseguir y mejorar los objetivos numéricos establecidos, en especial el de la eficacia o madurez, ya que este engloba a todos, aunque no sea de una forma específica.
• Esta asesoría o soporte respecto a planes, se refiere no solo al establecimiento de los mismos sino también al control de su evolución, detección de las desviaciones, validación de su terminación, y comprobación de que los efectos numéricos de mejora son acordes con los planificados.
• Efectúa el seguimiento de la evolución de cada uno de los objetivos, identificando sus tendencias y haciendo un análisis previo de las mismas para que sea validado o modificado por su dirección, para establecer los planes oportunos.
• Garantiza la existencia de un programa de mejora de la calidad del proceso de desarrollo.
• Systems Assurance son las personas que, por llevar a cabo internamente una especie de auditoría o consultoría continuada, sirven de eslabón de contacto con organizaciones externas, tanto con auditores externos a la empresa o entidad, como garantizando la participación de otras organizaciones de la propia empresa (Usuarios, Dirección, Desarrolladores, etc.) en el proceso y fases del desarrollo.

5.1.4.3. Mantenimiento

Vamos a analizar y aclarar, dada su importancia, una de las actividades descritas para analistas orgánicos y programadores en 5.1.4: el MANTENIMIENTO.

El mantenimiento, en general, es un concepto poco claro, del que se usa y abusa mucho, y que ayuda —a todos los niveles— a enturbiar el buen hacer de los desarrolladores. Se dicen cosas tales como que consume el ochenta o noventa por ciento de la actividad de desarrollo, que es el cáncer que invade y colapsa el desarrollo, etc.

Lo primero que queremos analizar, para aclarar el concepto, son los distintos tipos de MANTENIMIENTO:

• Perfectivo. Es aquel que mejora o amplía lo que una aplicación hace en producción. Esto, en sí mismo, es una mejora, y como tal debe tratarse, es decir, debe ser un proyecto, que al ser generalmente pequeño, debe tener la máxima rentabilidad (o el menor tiempo de recuperación de la inversión, es decir, el R.I. debe ser igual o menor a un año). Por lo tanto, no debe considerarse como mantenimiento ya que debe producir beneficios.
• Adaptativo. Es el que consiste en las modificaciones que se deben hacer en otra u otras aplicaciones, como consecuencia de un nuevo proyecto de desarrollo. Es posible, e incluso frecuente, que al hacer el análisis o quizás en los requerimientos, un nuevo proyecto (o una mejora) exija la modificación de ciertas aplicaciones que están en producción. El tema está claro: en los costes del proyecto causante de las modificaciones debe incluirse el coste de realizar dichas modificaciones, y, como consecuencia, debe afectar a su “Business Case”. Esto equivaldría, en otro orden de cosas, al presupuesto de asfaltado de una calle, que debe incluir el coste de subir el nivel de los desagües y el de los bordillos, si también fuera necesario, con el fin de que el resto de los servicios públicos sigan funcionando igual que antes de asfaltar. Por lo tanto, no debe tampoco incluirse en el capítulo y concepto de mantenimiento.
• Correctivo. Este sí es mantenimiento, y se define como lo que hay que hacer, o lo que hay que gastar, para que las aplicaciones en producción:
  • Sigan funcionando “como antes”.
  • Sigan teniendo la misma “eficiencia” que antes; por ejemplo, que no se degrade el tiempo de respuesta.
  • En general, que vuelvan al estado en que estaban.

El coste para llevar a cabo cualquiera de estas últimas definiciones sí es coste de mantenimiento, y las causas son debidas, generalmente, a defectos en alguna de las fases del ciclo de vida del proyecto que dio lugar a la aplicación que hay que mantener.

Este coste no produce ningún beneficio adicional, ya que el beneficio lo dio en su momento para que la aplicación funcionara, y debe ser, como ya hemos dicho, estrictamente controlado porque representa la improductividad.

En cualquier caso, aplicando el criterio debidamente, no se puede hablar de cifras tan alarmantes ni de improductividades tan altas. Normalmente, este coste no debería pasar del quince por ciento del total dedicado a desarrollo.

5.1.5. Alternativa: Subcontratación

Empecemos por decir que la subcontratación podría ser el enfoque, temporal o permanente en una empresa o entidad, basado en una decisión de la alta dirección, de no tener más que un pequeño núcleo informático que gestione y subcontrate todo el proceso de desarrollo (que incluso podría abarcar también a los procesos en máquina).

Normalmente esta situación no es la más corriente, entre otras cosas, porque en el mercado no hay mucha oferta de empresas que se puedan encargar del desarrollo y del proceso (empresas de “centros de cálculo”, “oficinas de servicio”, y las llamadas de “servicios externos” u “outsourcing”).

También se da el caso, con cierta frecuencia, de que la empresa, que demanda o necesita implantar el plan de proyectos de desarrollo, no posea ninguno de los recursos humanos y técnicos porque estos están concentrados en otra empresa, bien filial o bien “fraternal”, del mismo grupo o conjunto de empresas, en el que están tanto la demandante de los servicios (de estas puede haber varias), como la suministradora de los mismos. Estos casos no estamos considerándolos como subcontratación (en realidad se trataría de una prestación de servicios entre empresas del mismo grupo), sino que el concepto de subcontratación que vamos a analizar se refiere a cuando la empresa que realiza el desarrollo necesita más recursos humanos que los que posee.

La subcontratación de servicios de desarrollo suele, pues, producirse, como alternativa y complemento para realizar el plan, cuando una empresa o entidad, para llevar a cabo el plan de proyectos aprobado, no dispone de los recursos humanos suficientes y, al mismo tiempo, necesita realizarlo (compuesto, se entiende, por proyectos rentables y urgentes).

La subcontratación debería basarse fundamentalmente en la premisa de que lo que se contrata no cueste más que si se hiciera con recursos propios. Esto nos lleva a que lo que se vaya a contratar, con independencia de la modalidad, debe ser estimado previamente desde la hipótesis de hacerlo con los propios recursos de la empresa o entidad contratante, si los tuviera.

De esta forma, y solo así, la empresa contratante obtendría ventajas, tanto en el coste (porque será igual o menor que si lo hiciese ella), como en el tiempo en que estará disponible la aplicación (ya que está contando con recursos adicionales).

Ante este planteamiento, la empresa puede abordar el problema de tres modos: por la modalidad llamada llave en mano, por contratación de personas, y por contratación de tareas.

La contratación o subcontratación, como queramos llamarla, llave en mano consiste en contratar (un proyecto o un conjunto de proyectos interconectados) a otra empresa por un precio fijo y sin casi involucración de la empresa contratante.

Esta modalidad, como cualquiera de las otras que vamos a analizar, es apropiada para ciertos casos o en ciertas circunstancias y tiene sus ventajas y sus inconvenientes, que muchas veces se interrelacionan con sus características.

La principal característica de esta modalidad es que el proyecto, o conjunto de proyectos, esté muy bien definido, al menos, a nivel de requerimientos. Además es muy necesario que esté hecho un análisis funcional coherente con los requerimientos, y, a poder ser, soportado por alguna herramienta técnica de las existentes en el mercado.

Es deseable que el proyecto tenga pocas conexiones o “interfaces” con el resto de aplicaciones ya existentes, y, aún menos, con otros proyectos en desarrollo.

En esta modalidad de contratación, normalmente el entorno de pruebas (Hardware y Software) es del contratista (y es básico que sea totalmente compatible con el del contratante), pero también se puede acordar que este entorno sea del contratante.

Asimismo, en esta modalidad es necesario transferir al contratista todos los conjuntos de datos de prueba con los que se va a aceptar el funcionamiento de la o las aplicaciones contratadas.

El cumplimiento de estas condiciones o características resulta generalmente muy difícil, y exige, por parte del que contrata, un considerable esfuerzo así como una madurez y una fijeza de criterios que, al no ser usuales, dificultan este atractivo modo de contratación.

Como inconveniente, en principio, podemos destacar que cualquier tipo de modificación o cambio en los requerimientos representa, de forma inmediata —lógicamente— un incremento del coste del contratista. Normalmente la duda de la empresa contratante ante un incremento en el coste está entre aceptarlo o seguir con las bases y coste previstos, aunque no se cumplan los requerimientos nuevos o modificados.

Este inconveniente tiene, al mismo tiempo y aunque parezca paradójico, la ventaja de que se conoce el coste y que este permanece inamovible si no existen cambios en las especificaciones de usuario (requerimientos) o funcionales o de interconexiones con otros proyectos/aplicaciones.

Esta modalidad de contratación no parece, en principio, muy aplicable a las primeras fases del desarrollo (requerimientos y análisis funcional) ya que no es posible dar un precio fijo para realizar algo cuya duración y complejidad se desconoce. Si una empresa o entidad quisiera contratar estas fases parece lógico que acuda a otro modo de contratación.

Por último debemos reseñar la importancia del mantenimiento, tanto para efectuar mejoras como para corregir fallos. La empresa que contrata con esta modalidad debe prever cómo va a enfocar este problema para no verse incapaz de hacerlo con sus propios recursos, ni tampoco verse obligada o forzada (sin haberlo previsto y valorado) a tener que seguir haciéndolo con la misma empresa que hizo el desarrollo. Una forma, de uso común, consiste en recibir formal y detalladamente la aplicación, revisando a fondo la documentación, para posibilitar e incluso facilitar, por unos u otros, las futuras modificaciones.

El segundo modo de contratación expuesto, es decir, la contratación de personas, se basa en suplementar los recursos humanos internos con otros externos (del contratista) para la realización del plan.

En realidad es el modo más simple y más usual de atacar el problema de la contratación. Es, asimismo, el más ofertado, con más o menos variantes en cuanto a contratar meros profesionales con diferentes cualificaciones, o contratar un equipo, con o sin jefe de equipo, etc.

En esta modalidad los profesionales del contratista se suelen instalar en los locales de la empresa o entidad que contrata y comparten el entorno de pruebas, para lo cual es necesario que conozcan las herramientas técnicas al uso en dicho entorno. Esta “convivencia” suele producir efectos positivos en la productividad, a costa, normalmente, de tener que pagar —como productivas— aquellas horas o jornadas que no lo han sido tanto porque la empresa contratante ha frenado el ritmo del desarrollo por cualquier causa (modificaciones, re-análisis, o bien por circunstancias imprevistas: enfermedades, viajes, cursos, urgencias de otro tipo, etc.). Asimismo, también hay que tener en cuenta que en los momentos de carga, la dedicación extra que se solicite representará un coste extra.

Este tipo de contratación tiene el inconveniente de que no suele garantizar “a priori” el coste que habrá que abonar al contratista ya que puede “contaminarse” de los posibles altibajos del ritmo, generados por el contratante, que, a su vez, pueden dar lugar a una tendencia a la “informalidad” de los procedimientos y compromisos, inducida por el hecho de disponer de más recursos. También tiene el contratante la tentación de diversificar al contratista en otras actividades o, incluso, en otros proyectos para los que no se ha realizado el contrato (estamos dando por supuesto que la contratación se concreta por proyecto); si el contratante cayera en el error de esta dispersión, el control de costes por proyecto sería casi imposible.

Existen circunstancias, como la capacidad técnica y la experiencia del contratista, o su disponibilidad de recursos, unido a la premura de tiempo y la concreción del trabajo (por parte del contratante), que hacen que este tipo de contratación sea el mejor y el más flexible.

En tercer y último lugar vamos a analizar la contratación de tareas.

Creemos que es la forma más evolucionada de contratar, y es en la que más y mejores experiencias tenemos.

Para poder abordar este tipo de contratación es necesario tener bien implantados y consolidados los procedimientos y controles que hay que seguir en el proceso del desarrollo, ya que deben ser practicados por los profesionales de la empresa o entidad que contrata y deben ser conocidos y, consecuentemente, practicados por los del contratista.

En el contexto de la decisión de contratar en cualquier modalidad es conveniente tener en cuenta ciertas características comunes, como son:

• Conocer “a priori” el coste de desarrollo, hecho con recursos propios, de cada tarea que se contratará (como hemos apuntado anteriormente). Este coste, en parte o en su totalidad, debe estar en el plan anual vigente.
• Enseñar a los profesionales del contratista los procedimientos, técnicas y características de la instalación en el entorno de pruebas.
• Tener bien separados los entornos de pruebas, mantenimiento y producción, ya que, en principio, los profesionales de los contratistas no deben tener acceso a datos confidenciales que, lógicamente, se encuentran en producción.

Pues bien, además de estas, también hay que tener en cuenta otras características específicas de esta modalidad de contratación de tareas:

• Dado que en este tipo de contratación los profesionales del contratista pueden trabajar en sus locales u oficinas, es necesario contemplar la instalación de dos líneas de teleproceso (para garantizar la continuidad del servicio), con sus unidades de control y terminales.

• Es muy conveniente establecer áreas o conjuntos de proyectos que, desde el punto de vista funcional, tengan una cierta homogeneidad o coherencia. De este modo se pueden asignar estas áreas a contratistas que, además de tener profesionales puros de informática, tengan profesionales conocedores de la gestión específica de dichas áreas (p.e. Finanzas, Administración, Personal, Servicio post-venta, etc.) para poder así contratar la parte de análisis funcional.

Esta diversidad del número de contratistas, que en cualquier caso no debe ser excesiva, tiene menores riesgos que la contratación única, y, además, al tener una especialidad por áreas, tiene la ventaja de una pronta comprensión de la mecanización o informatización de cada área.

• Este tipo de contratación exige que la empresa que contrata no pierda el control, de forma tal que, si por cualquier circunstancia, se interrumpiera o abandonara la contratación, los profesionales propios deberían asumir, al menos, las tareas de mantenimiento correctivo y mejoras de las aplicaciones hechas por/con los contratistas.

• La táctica consiste en hacer una inversión en la que llamamos primera etapa de la contratación, para recuperarla en la segunda y tercera etapas.

A través de un análisis detallado, se llegó a definir, en su momento, la matriz que ahora explicaremos, que fue validada y aceptada posteriormente como media del comportamiento empírico, después de haber sido aplicada a más de doscientos proyectos de tipo medio (entre 3 y 18 meses-persona de esfuerzo cada uno).

• Matriz para APLICACIONES EXISTENTES. La determinación de los factores o elementos de esta matriz tiene en cuenta que el conocimiento de estas aplicaciones es mayor, al principio, en la primera etapa, en los profesionales de la empresa contratante que en los del contratista.

	CONTRATANTE	CONTRATISTA
	Desarrollo	Análisis	Desarrollo	Análisis
1ª Etapa	1,0	1,0	1,0	0,9
2ª Etapa	0,5	0,6	1,0	0,9
3ª Etapa	0,2	0,34	1,0	0,9

Vamos a aclarar, con un ejemplo, cómo aplicar estos factores.

Supongamos que en el plan anual vigente existe un proyecto para modificar las aplicaciones de Previsión de Ventas, cuyo esfuerzo de análisis son 3 Meses-hombre y los de desarrollo son 10 Meses-hombre (Mes-hombre equivale a MESES-hombre/persona).

Supongamos que se acaba de decidir que se lleva a cabo la subcontratación, o bien, que lo contratamos por primera vez, y supongamos, por último, que el conjunto de aplicaciones de Previsión de Ventas, se suele modificar con cierta regularidad, debido a nuevas estrategias, nuevos Productos, nueva organización, etc.

Aplicando la matriz, en 1ª etapa, ya que es la primera vez que contratamos esta área, nos da los siguientes esfuerzos:

• Propios: 3 Meses-hombre de análisis y 10 Meses-hombre de desarrollo (ambos están afectados por el factor 1).
• Contratados: 2,7 Meses-hombre de análisis y 10 Meses-hombre de desarrollo (los factores 0,9 y 1 se multiplican por los esfuerzos del plan, que son respectivamente 3 y 10).

Está claro que en esta primera etapa alargamos el período de recuperación de la inversión del “Business Case”, ya que los costes de desarrollo se han incrementado en el importe de la contratación, debido a que en esta etapa los contratistas están ayudando y aprendiendo las aplicaciones que hay que modificar.

Si en esta área de negocio (aplicaciones de previsión de ventas) no hubiera, de forma repetitiva, actividad informática (nuevas aplicaciones, modificaciones, mejoras, etc.) no podríamos rentabilizar en el futuro (como ahora veremos) esta inversión en contratación, ya que lo abonado, básicamente para el aprendizaje de estas aplicaciones, no tendría utilidad posterior.

Por lo tanto, y antes de seguir adelante, digamos que este modo de contratación es útil para aquellas áreas donde haya actividad informática de forma repetitiva, que dicho sea de paso, son casi todas, cuando la empresa o entidad no está profundamente mecanizada o informatizada.

Sigamos, pues, con el ejemplo. El siguiente año, o antes, supongamos, por simplificar, que hay otro proyecto aprobado en esta misma área con los mismos esfuerzos.

Aplicamos la matriz en la 2ª etapa (dado que el contratista, aunque no experto, sí debe ser conocedor de las aplicaciones) y nos da los siguientes esfuerzos:

• Propios: 1,8 Meses-hombre de análisis y 5 Meses-hombre de desarrollo (los factores 0,6 y 0,5 se multiplican por los esfuerzos respectivos del plan 3 y 10).
• Contratados: 2,7 Meses-hombre de análisis y 10 Meses-hombre de desarrollo (como en la primera etapa).

En esta segunda etapa, que empieza a ser la estable, podemos destacar dos aspectos:

Rentabilidad. El retorno de la inversión (R.I.) se producirá en el mismo período previsto y aprobado en el plan siempre que el coste total (propio y contratado) no supere el coste que estaba planificado. Para que se dé esto, una vez conocido el coste del mes-persona (Mes-hombre es la notación usual, y significa Man x Month), se debe cumplir, en costes, que:

• 1 Mes-hombre propio de análisis => (0,6 Meses-hombre propios + 0,9 Meses-hombre contratados) de análisis, y
• 1 Mes-hombre propio de desarrollo => (0,5 Meses-hombre propios + 1 Mes-hombre contratados) de desarrollo.

Esto condiciona el precio del mes de contratista con respecto al coste total del propio.

Dispersión. En esta etapa, un profesional de desarrollo de la empresa contratante (propio) puede coordinar a dos profesionales de desarrollo del contratista. De igual forma, un profesional de análisis (propio) puede coordinar a 1,5 profesionales de análisis del contratista. Evidentemente esto enriquece el contenido del trabajo de los profesionales de la empresa contratante, sin que pierda el control del estado informático de las aplicaciones.

Para simplificar, supongamos que en un tercer período volviera a existir un proyecto en la misma área y con los mismos esfuerzos. En este caso, dado que el contratista debe ser conocedor de estas aplicaciones, debemos aplicar los factores de la 3ª etapa. Así pues, los esfuerzos resultantes serían:

• Propios: 1,02 Meses-hombre de análisis y 2 Meses-hombre de desarrollo (3 x 0,34 = 1,02 y 10 x 0,2 = 2).
• Contratados: 2,7 Meses-hombre de análisis y 10 Meses-hombre de desarrollo (3 x 0,9 = 2,7 y 10 x 1 = 10).

Esta tercera etapa se considera como estable, y, como tal, no evolucionan sus factores.

Veamos ahora cómo se comportan la rentabilidad y la dispersión.

Rentabilidad. Como en la segunda etapa, el R.I. se producirá en el plazo establecido en el plan, si el coste total no se incrementa. En esta etapa es más fácil que se cumplan las condiciones del coste, por ser inferiores los factores que afectan a los de los recursos propios:

• 1 Mes-hombre propio de análisis a (0,3 Meses-hombre propios + 0,9 Meses-hombre contratados) de análisis, y
• 1 Mes-hombre propio de desarrollo => (0,2 Meses-hombre propios + 1 Mes-hombre contratados) de desarrollo.

Dispersión. En la tercera etapa, un profesional de desarrollo puede coordinar a cinco profesionales de desarrollo del contratista. Asimismo, en esta etapa, un profesional de análisis propio puede coordinar a 2,6 profesionales de análisis del contratista.

En esta modalidad de contratación por tareas, en cualquiera de sus etapas, es importante que existan varios profesionales del contratista en cada área (tanto en análisis como en desarrollo) para evitar que, con la previsible movilidad de estos profesionales (a otros puestos en la misma empresa, o a otras empresas), desaparezca la “solera” existente con conocimiento de las aplicaciones, porque si no, existe el riesgo de volver a la primera etapa con el mismo contratista y en la misma área.

Los factores que se aplican a los profesionales propios en esta tercera etapa deben garantizar el control y el futuro mantenimiento de las aplicaciones que han sido objeto de contratación.

Veamos ahora la matriz de contratación para los PROYECTOS DE NUEVO DESARROLLO. Esta matriz, como se puede apreciar, es igual que la anterior, salvo que prescinde de la primera fila, que equivale a la primera etapa.

La razón es clara. La primera etapa, en la anterior matriz, se utilizaba en gran medida para que los profesionales del contratista se familiarizaran con los componentes técnicos y la estructura de la aplicación existente. Como en este caso los proyectos son nuevos, el punto de partida es el mismo para los profesionales propios y los del contratista.

	CONTRATANTE	CONTRATISTA
	Desarrollo	Análisis	Desarrollo	Análisis
2ª Etapa	0,5	0,6	1,0	0,9
3ª Etapa	0,2	0,34	1,0	0,9

La aplicación de los ejemplos anteriores sigue siendo válida, asumiendo que son aplicables a la segunda y tercera etapa.

“Cómo asignar prioridades a los proyectos informáticos”. Martin D. J. Buss, Harvard Deusto Business Review 4º Trim. 1983.