ORGANIZACIÓN ESTRUCTURAL DEL CENTRO DE PROCESAMIENTO

DE DATOS

Una de las condiciones previas más importantes para una gestión eficiente del
CPD es que la organización estructural del departamento sea transparente y flexible.
En su arquitectura, este centro debe estructurarse de forma que sean claramente
visibles sus dependencias jerárquicas y técnicas, que los canales de información sean
cortos y que se posibilite una rápida acomodación al cambio de tareas.
Debe procurarse especialmente que la estructura organizativa no dificulte la
agrupación de colaboradores en proyectos de acuerdo a las exigencias de éstos.
Un punto de vista fundamental en la estructura organizativa del CPD es una clara
y amplia separación entre competencias jerárquicas y técnicas. Mientras que la
responsabilidad jerárquica debe quedar en manos de un reducido número de directivos
del nivel superior de la gestión de CPD. Podrá concederse responsabilidades técnicas a
jefes de proyecto en el marco de una distribución, temporal, de tareas.
Los principales puntos críticos de la estructura organizativa del CPD son los
siguientes:

- Agrupación del personal de análisis y desarrollo de sistemas según los

principios de clasificación por tareas o por objetos.
- integración de las actividades de mantenimiento en la estructura organizativa.
- Ambito y organización de los puestos de staff y servicio.

Sobre todo, las dos últimas cuestiones se han agudizado mucho en los últimos
años. Hay que sopesar cuidadosamente las ventajas e inconvenientes de las diversas
alternativas de organización y de integración del departamento cuando se trata de
reorganizarlo.

3.1. FUNCIONES DE LA GESTION DEL CPD

Si queremos conseguir una moderna estructura organizativa del CPD, en primer

lugar será preciso determinar los grupos funcionales que actúan en él.
En el CPD pueden distinguirse cuatro grandes grupos de funciones o campos de
tareas:

- Desarrollo y mantenimiento de sistemas de aplicación

- Producción de servicios en el centro de cálculo
- Dirección y coordinación
- Servicios existentes para otras personas

La estructura de un CPD debe permitir que dichas tareas centrales sean

claramente perceptibles. En especial, debe procurarse que no se ejecuten
paralelamente servicios análogos en varios campos de tareas (3.4, p.2/2).

3.1.1 Grupo de funciones: desarrollo y mantenimiento de aplicaciones

 Este grupo de actividades abarca el análisis de sistemas (organización del
proceso de datos), la programación y la organización convencional (también
denominada organización de oficinas u organización general). En el desarrollo de
proyectos deben participar todos estos puestos. Por esa razón debe procurarse ya en la
misma estructura organizativa garantizar la mayor coordinación entre ellos.
La tarea del (Analista de Sistemas) figura junto con la programación en el centro
del desarrollo de sistemas. El concepto mismo de (Análisis de Sistemas) no es
realmente afortunado, sólo se refiere literalmente a una de las funciones parciales de
esta tarea, a la del análisis. Las tareas reales de esta función son más amplias. En
algunas empresas bajo este mismo epígrafe se engloban los conceptos de
planificación, creación y desarrollo de sistemas.
El (Analista de Sistemas) se ocupa de cuatro grupos centrales de tareas:

- Análisis de sistemas
- Desarrollo de sistemas
- Creación de concepciones generales de sistemas
- Mantenimiento de los sistemas existentes

A esto deben añadirse otras tareas especiales. Entre ellas hay que mencionar la
selección de hardware y software y los cálculos de rentabilidad (3.4,pp.2/3 s).

Después de haberse instalado un sistema electrónico de organización de datos

cada vez va adquiriendo una mayor importancia el problema del mantenimiento de
sistemas (atención a los sistemas de aplicación), es decir, el mantenimiento tanto
organizativa como técnico de los programas y el servicio de cambios y adaptaciones de
los sistemas en funcionamiento. En general, las empresas subestiman la importancia de
esta tarea y no sorprende que los cálculos de rentabilidad apenas tengan en cuenta
este renglón de costes.

Las tareas de (programación) se clasifican en programación de sistemas y

programación de aplicaciones. Son distintas y casi siempre las atienden distintos
grupos de colaboradores.
La principal tarea de la programación de sistemas consiste en la adaptación y
atención a los sistemas en funcionamiento así como en la unión de los programas de
sistemas menores, el programador de aplicaciones podrá ocuparse también de esta
tarea. Al aumentar la magnitud y complicación de los sistemas de proceso de datos
aumenta también el campo de funciones del programador de sistemas y se convierte
finalmente en un campo autónomo de trabajo.
El programador de aplicaciones prepara sus propios programas o se ocupa de la
acomodación del software de aplicaciones. Junto a los nuevos programas debe poner
cada vez mayor dedicación.
Recientemente se va acentuando la tendencia hacia el llamado programador
analista, es decir, al desempeño por la misma persona de las tareas de análisis de
sistemas y de programación de aplicaciones. Así desaparece la anterior separación
entre analista y programadores y se crean grupos comunes. Los distintos colaboradores
tienen ocasión de adquirir nuevos conocimientos que les permitirán (cabalgar en ambas
sillas) en el futuro.
La ola de agrupamiento de funciones tiene diversas causas. En primer lugar está
el grado de madurez alcanzado por los otros departamentos técnicos. Hoy mucho más
que hace unos años, éstos pueden articular claramente sus deseos y trabajar en el
desarrollo de proyectos de aplicación del CPD como socios inteligentes. Estos ha
contribuido a la pérdida de importancia del área de conexión entre CPD y
departamentos especializados, que actuaban antes de mediador entre programación y
usuarios.
También la tendencia al programador-analista ha sido robustecida por la forma
de pensar en la organización estructurada, actualmente se exige ya desde muy pronto
la presentación de un concepto técnico del programa. Esto ha influido en la progresiva
reducción del papel de un intermediario como el análisis de sistemas entre
departamentos usuarios y programación de aplicaciones.
Antes se daba ya esta agrupación de funciones en departamentos pequeños de
CPD, donde sólo se disponía de 4 a 6 analistas. Hoy se encuentra también en
empresas mayores.
La agrupación de análisis de sistemas y programación aporta ventajas al reducir
el campo de tensiones entre ambos sectores. Pero un inconveniente de esta solución
es que el personal debe poseer conocimientos de análisis y de técnica de programas.
Se ha constatado en la práctica que precisamente los programadores de aplicaciones
tienen que esforzarse mucho para adquirir los conocimientos básicos necesarios en
análisis.
La organización de Oficinas (también denominada organización general) tiene
que cumplir dos tipos de tareas:

- Desarrollo autónomo de proyectos de organización exteriores al CPD.

- Cooperación en proyectos del CPD en la medida en que en ellos deben
realizarse tareas organizativas que caen fuera del análisis de sistemas (3.4
págs. 2/4).

3.1.2 Grupo funcional de trabajos del Centro de Cálculo

La estructura organizativa del Centro de Cálculo se asemeja cada vez más a una
sección de producción industrial. En la mayoría de los Centros de Cálculos aparece una
estructura organizativa muy similar. Distinguimos aquí los siguientes campos de tareas:

- Dirección de la producción del CPD

- Preparación de trabajos
- Servicio de máquinas (operating)
- Control y elaboración posterior de datos
- Archivo y almacén de papel
- Puesto de entrada de datos

En algunos casos la programación de sistemas se encuentra en el mismo Centro

de Cálculo. Dada la complejidad de las tareas de este puesto. Sólo pueden
recomendarse en casos muy especiales esta conexión entre ambos campos de tareas
bajo la dirección del jefe del Centro de Cálculo.

3.1.3 Funciones de dirección en la gestión del CPD

En el departamento de organización y proceso de datos, es necesaria una mayor

actividad de dirección y coordinación que en los otros sectores. La razón es la intensa
actividad creativa propia de estas tareas. Por este motivo, el abanico de control directo
de un directivo de CPD no debe superar la cifra de 5 a 8 colaboradores.

3.1.4 Servicios propios del CPD

En departamentos de proceso de datos de cierta magnitud son necesarias

ciertas funciones de servicio. Las principales funciones que deben mencionarse son:

- Ingeniería de hardware
- Ingeniería de software
- Administración del banco de datos
- Métodos y sistemas
- Formación y entrenamiento
- Control de calidad

Según la dimensión del departamento, estas funciones serán desempeñadas por

grupos especializados de colaboradores o por personal que realiza paralelamente otras
tareas.
La ingeniería de hardware es responsable de la observación del desarrollo de
innovaciones técnicas, de la comparación entre productos y de la planificación del
futuro empleo de estos productos. En grandes empresas es ya habitual una separación
entre el campo de la planificación y selección de sistemas de proceso de datos
(unidades centrales) y el de los aparatos de periferia. Entre estos debe citarse el sector
de telemática y el de entrada de datos por terminales.
La ingeniería de software se articula en dos grupos: el de planificación y
mantenimiento de sistemas en funcionamiento y el de la observación del mercado,
selecciones y valoración del software para aplicaciones. Dada la frecuente falta de
especialistas, esta última tarea se confía muchas veces a consultores externos o , como
ocupación secundaria, a analistas y programadores generales.
Hoy se ha hecho necesaria la función de administrador del banco de datos, pues
la concepción y mantenimiento de un banco de datos supera ya el campo de tareas de
proyectos de realización. Con frecuencia es necesario planificar y desarrollar nuevos
banco de datos. Las exigencias planteadas a estos bancos de datos vienen
caracterizadas por los proyectos de aplicación.
Todavía se halla poco difundida la función de planificación de métodos. Sobre
ésta recae la responsabilidad de elaborar métodos racionales de trabajos, de decisión
y de documentación en las secciones de organización General, de análisis de sistemas
de programación y de explotación.
 Finalmente, entre las funciones de servicios hay que contar el entrenamiento del
mismo personal del departamento y la formación/instrucción en proceso de datos en
otros departamentos de la empresas.
En algunos casos, entre las funciones de servicios se encuentra la importante
tarea del control de calidad. La misión de este puesto de trabajo que alguna vez es
denominado de control de programación es vigilar constantemente y aplicar los
métodos y técnicas prescritas así como lograr una amplia documentación de los
productos de software. En un gran banco de datos esta función es asumida p.e. por dos
colaboradores. Los directivos del CPD y los otros colaboradores de dicha firma valoran
positivamente este tipo de actividad.
Después de largas discusiones en seminarios sobre la gestión del CPD se ha
llegado a la conclusión de que para una cifra de unos 25 colaboradores dedicados a
sistemas se necesitan 1-2 colaboradores para servicios.
En un CPD con unos 100 analistas y programadores se ocupan en cambio 8-15
personas en las siguientes funciones de staff:

2-3 especialistas en banco de datos

2-3 especialistas en explotación de sistemas
1-2 colaboradores para formación y métodos
1 especialistas en hardware
1 colaborador en planificación y control de programas
1 dibujante de formularios (eventualmente)

En cuanto jefe del CPD, procure usted los staffs. De su centro no se incrementen
por meros motivos ocasionales. Sólo debe reclutarse más personal cuando existen
tareas permanentes que no pueden ser asumidas por los demás colaboradores.

Se conocen ya varios casos en que ha habido que restringir drásticamente un

staff hinchado artificialmente. Había olvidado que su tarea primordial era el apoyo al
resto de los colaboradores.
Tareas que sólo exigen temporalmente algún colaborador más p.e. trabajos de
evaluación, etc. Podrían ser desempañadas más racionalmente por un comité
provisional en lugar de emplear un nuevo miembro en el staff del CPD.
Los circuitos de trabajo, en lugar de instituciones permanentes, son
recomendables cuando:

- Se trata de resolver tareas provisionales

- Se necesita contrastar opiniones de distintas personas a las que hay que
coordinar en su trabajo
- No basta los conocimientos especiales de un individuo para enjuiciar
determinados problema

Pero con frecuencia aparecen posibles inconvenientes en los equipos y

comisiones cuyos miembros sólo se ocupan ahí con carácter secundario:

- Falta de esfuerzo en conseguir los objetivos

- Falta de tiempo para estas tareas, no son las principales de su puesto.
 - Falta de delimitación de responsabilidades
- Dificultades en poner en práctica las resoluciones, pues no tienen
competencia definida en la materia.

Sin embargo, es posible superar estas desventajas cuando se toman las

siguientes medidas:

- Designación de un jefe de equipo

- Planificación de objetivos y de forma de proceder
- Control, vigilancia sobre la consecución de objetivos
- Obligación de los colaboradores a ejecutar las resoluciones

3.2 PRINCIPIOS PARA LOGRAR UNA ESTRUCTURA ORGANIZATIVA

ADECUADA

Una estructura organizativa adecuada deberá cumplir las exigencias siguientes:

 Debe determinar claramente la posición jerárquica y el campo de tareas de

cada colaborador.
 Debe ser sencilla y transparente.
 Debe poseer canales de información cortos.
 Debe articularse según funciones. Las funciones similares deben estar
próximas unas a otras. No deben desempeñarse las mismas funciones en
puestos distintos.
 La estructura organizativa debe ser fácil de modificar y permitir flexibilidad en
el empleo de unos a otros colaboradores.
 Debe facilitar la actividad de los especialistas y esto debe quedar claramente
formulado en sus normativas.
 Deben existir centros con responsabilidad propias bien delimitadas.
 Debe existir una sana proporción entre colaboradores dedicados a tareas
productivas de desarrollo y ejecución y otros, con aporte indirecto, dedicados
a tareas de staff.
 El abanico de control y dirección debe adaptarse al grado de dificultad de la
gestión de personal en este sector.
 Debe haber quedado resuelto el problema de las sustituciones también en
grupos funcionales menores.
 La organización estructural debe permitir un estilo participativo de dirección.
 Debe ser posible una estrecha colaboración entre desarrollo de sistemas y los
departamentos usuarios CPD.

Una organización estructural óptima de este departamento intentará adecuarse a

estas exigencias utilizando:
 - Una gestión de proyectos para mejorar la planificación y control de trabajos
de proceso de datos.
- Estructuras de equipos orientados al tipo de problema en el personal de
desarrollo de sistemas (orientándose a los trabajos a realizar o a los objetivos
en que se trabaja).
- Un claro control de costes y rendimiento
- Creación de un CPD como organismo superior de planificación, control y
coordinación
- Creación de grupos centrales de servicios para tareas de planificación,
coordinación y control, o para actividades especiales.

3.3 FORMAS MODERNAS DE ESTRUCTURACION DEL CPD

La articulación estructural puede orientarse según competencias jerárquicas o de

cualificación técnica. En primer lugar debe considerarse la articulación según
subordinaciones jerárquicas. En este párrafo se describen pues articulaciones
estructurales bajo el punto de vista del principio de dirección jerárquica.
Luego se exponen las formas de subordinación técnica tal como resultan en la
gestión por proyectos. Pueden divertir esencialmente de las de la organización
jerárquica y en parte se superponen a ellas.

3.3.1 Observaciones Generales

En las modernas organizaciones del CPD suelen encontrarse las siguientes

funciones centrales:

- Organización general
- Análisis de sistema
- Programación
- Centro de cálculo

A éstas hay que sumar, al nivel de staff, funciones de servicios que se ejercen
frente a las fundamentales, las funciones de análisis y de programación pueden
fundirse en un grupo. Eventualmente puede darse una separación suplementaria según
las actividades de desarrollo y de mantenimiento de sistemas.
La separación de organización general o la del centro de cálculo no supone
ninguna modificación sustancial de al estructura organizativa tal como se expone a
continuación.
La subdivisión de análisis de sistemas y de programación puede orientarse o a
tipos de actividades (principio de organización según trabajos), o a áreas de la empresa
(principio según objetivos), en teoría el principio de organización según tareas supone
una mayor flexibilidad así como un rendimiento más alto por lo demás, se encuentra
muy difundida una organización orientada a grupos de objetivos o áreas (p.e.
contabilidad, comercial, gestión de materias, etc.).

Un principio de toda organización estructural-prescindiendo de que además se

articule según trabajos u objetos- es minimizar en lo posible el número de niveles de la
estructura. Así se facilita la más estrecha cooperación posible entre directivos y
colaboradores.

El número de niveles depende del número de colaboradores. En lo que concierne

a competencias jerárquicas, un directivo puede abarcar hasta unos 30 colaboradores
(límite del abanico de dirección y control), así pues, hasta esta cifra podrá quedar
subordinado todo el personal del departamento a su jefe. Si el fiar un parte de los
colaboradores al próximo nivel de dirección. Habitualmente el personal del centro de
cálculo queda subordinado al jefe de dicha sección cuando lo pide la amplitud de estas
tareas, un jefe de desarrollo de sistemas puede también asumir competencia jerárquica
sobre sus colaboradores.
La articulación según competencias técnicas es mucho más fuerte que al
aspecto jerárquico. Sólo en los niveles superiores coinciden ambos tipos de
competencias. En general los mandos de nivel inferiores sólo tienen competencias
técnicas.

3.3.2 Estructura organizativa según el principio de articulación por tareas

En este tipo de articulación se realiza una separación en secciones según las

funciones esenciales del departamento de organización y proceso de datos. El cuadro
siguiente muestra la subdivisión fundamental en los tres pilares del departamento de
proceso de datos en esta descripción global todavía no se distinguen el principio de
organización por actividad o por objetos.

DIRECCION
ORGANIZACIÓN Y
PROCES DE DATOS

PUESTO DE STAFF

DESARROLLO Y MANTENIMIENTO CENTRO DE CALCULO

Fig. 3.1 organigrama básico de la organización del departamento de proceso de datos.

Si se aplica consecuentemente el principio de ordenación por tareas, la

estructura organizativa sigue articulándose al siguiente nivel de precisión según se
presenta en el cuadro de la página siguiente.

El punto de vista fundamental al emplear el principio de articulación según tareas

es una separación estricta de las distintas funciones según su ordenación jerárquica y
técnica. por lo demás si se da una organización en sistema de proyectos en lo que
concierne a la subordinación del personal en lo técnico puede llegarse a una mezcla de
distintas categoría o tipos de colaboradores.
En la práctica es rara una estricta articulación según el principio de tareas. Lo
corriente es que pasado cierto tiempo se articule en dirección al principio de
ordenación por objetos.

DIRECCION
ORGANIZACIÓN Y
PROCESO DE DATOS

SECRETARIA
SERVICIO DE PUESTO DE STAFF
MECANOGRAFICA ETC.

INGENIERIA DE HARDWARE
INGENIERIA DE SOFTWARE
PLANIFICACION Y CONTROL
DE PROYECTOS
PLANIFICACION DE METODOS
FORMACION
PLANIFICACION A LARGO PLAZO

ORGANIZACIÓN ANALISIS DE PROGRAMACION MANTENIMIENTO CENTRO DE

GENERAL SISTEMAS DE SISTEMAS CALCULO

ORGANIZACIÓN DESARROLLO COOPERACION EN PREPARACION DE

SEGÚN ESTRUCTURAS DE TRABAJOS PROYECTOS O EN TRABAJOS
ORGANIZACIÓN EN PROYECTOS GRUPOS FIJOS SERVICIO DE
SEGÚN PROCESOS MAQUINAS
ORGANIZACIÓN DE CONTROL DE DATOS
MEDIOS/INSTRUMENTOS ENTRADA DE DATOS
ARCHIVO

Fig. 3-2 forma típica de articulación según el principio de ordenación por tareas

3.3.3 Articulación según el principio de ordenación por objetos

En lugar de una articulación según tareas, las funciones de organización, análisis

de sistemas y programación pueden ordenarse según el principio de ordenación por
objetos. Como objetos se consideran aquí las áreas fundamentales de una empresa u
organismos administrativos público.
DIRECCION
ORGANIZACIÓN Y
PRECESO DE DATOS

DIRECCION DIRECCION
ORGANIZACIÓN Y ORGANIZACIÓN Y
PRECESO DE DATOS PRECESO DE DATOS

DIRECCION DIRECCION DIRECCION DIRECCION

ORGANIZACIÓN Y ORGANIZACIÓN Y ORGANIZACIÓN Y ORGANIZACIÓN Y
PRECESO DE DATOS PRECESO DE DATOS PRECESO DE DATOS PRECESO DE DATOS

ORGANIZADORES
ANALISIS DE SISTEMAS
PROGRAMADORES DE
ESTE GRUPO
Fig. 3-3 configuración típica de una estructura organizativa de CPD según el principio
de ordenación por objetos (sólo se presentan las diferencias con la ordenación por
tareas)

Ejemplos bancos:
Servicio de libretas de ahorros
Hipotecas
Valores
Contabilidad
Etcétera

Ejemplos seguros:
Seguros de vida
Daños materiales
Daños a terceros
Contabilidad
Etcétera

Ejemplos industria:
Finanzas y contabilidad
Gestión de materiales
Control de fabricación
Comercialización
Etcétera

El punto de vista básico al aplicar el principio de ordenación por objetos es que

dentro de una misma agrupación estable pueden trabajar distintas categorías de
personal. Dado que los colaboradores trabajan permanentemente en el mismo sector
de la aplicación del CPD, puede conseguirse la subordinación jerárquica puede hacerse
o con respeto al jefe del grupo de objetos o al jefe del departamento superior.

3.3.4 Valoración práctica de ambos principios de estructuración

En la medida en que el principio expuesto de ordenación por tareas, en lo

esencial sólo presenta la subdivisión jerárquica, es algo teórica y prácticamente
utilizable. Por lo demás es una forma racional de trabajo que se practica en el marco
de la gestión por proyectos.
Cuando la estructura organizativa según competencias técnicas responde a la
jerárquica, la aplicación del principio de ordenación según tareas lleva, sobre todo el
análisis de sistemas y programación, a un tipo de organización horizontal en equipos es
decir a una separación y programación si sólo trabaja en el proyecto análisis de
sistemas y programación sigue trabajando la forma rutinaria, pueden producir
fácilmente tensiones y descontentos.
 Un problema bastante frecuente en una estructura organizativa según el principio
de ordenación por tareas, es el que plantea el mantenimiento de las aplicaciones. Sólo
se le puede resolver satisfactoriamente cuando se logra una buena documentación del
análisis y de los programas de forma que el encargado de mantenimiento no tenga que
poseer conocimiento sobre el problema. Sin embargo, esta situación ideal es algo que
rara vez se encuentra realizando en la práctica. En general es pues mejor intentar
resolver la cuestión del mantenimiento dentro del marco de una organización por
objetos, donde un equipo pueda realizar no sólo el desarrollo sino también el
mantenimiento de sistemas.

Posibles inconvenientes de una organización por objetos son:

- La capacidad total de rendimiento de un grupo organizado según objetos

puede ser menor si no se logra distribuir equilibradamente la carga de trabajo
entre todos los participantes.
- Otra dificultad puede seguir al presentarse nuevos bloques de tareas.
Organizando según el principio de ordenación por objetos es más fácil
conseguir colaboradores para las nuevas tareas de entre los grupos
existentes.
En conjunto, lo más práctico parece ser una organización mixta en que, principio,
se siga la ordenación por objetos (estructuración vertical de equipos). Pero
deberán introducirse garantías organizativas que permitan un empleo flexible
del personal disponible. Esto puede lograrse mediante una organización según
gestión de proyectos estructurada según las necesidades.

3.4 SEPARACION DE COMPETENCIAS JERARQUICAS Y TECNICAS

Uno de los aspectos esenciales de los grupos de desarrollo de sistemas en el

CPD es la separación de competencias jerárquicas y técnicas. Esta separación
estrechamente ligada a los principios que garantizan la eficacia del trabajo en régimen
de proyecto. Es deseable, incluso parcialmente necesaria, la separación de ambos tipos
de competencias por los motivos siguientes:

 El abanico de control en el marco de competencias técnicas es esencialmente

menor que en el orden jerárquico en las actividades de análisis de sistemas,
un supervisor sólo puede atender a 5-7 personas.
 La separación facilita una mayor flexibilidad en el empleo de los
colaboradores en proyectos.

Si el número de analistas y programadores no supera la cifra de 5-7 bastará un

único escalón entre el jefe de organización y proceso de datos y sus subordinados.

JEFE DE ORGANIZACIÓN Y PROCESO DE DATOS

 PROGRAMADORES DE ORGANIZACION

Fig. 3-4 articulación sencilla del departamento de proceso de datos según competencia
técnica
En departamentos de hasta 20-25 colaboradores puede bastar articular en dos
escalones de competencias técnicas al personal de Análisis de Sistemas y
Programación.
JEFE DE ORGANIZACIÓN Y PROCESO DE DATOS

JEFE DE PROYECTOS RESPONSABLES DE PROYECTOS DE

MANTENIMIENTO COLABORAODRES INDIVIUDALES

COLABORADORES EN PROYECTOS

Fig. 3-5 Articulación en dos escalones de competencias del Departamento de

Proceso de Datos.

JEFE DE ORGANIZACIÓN Y
PROCESO DE DATOS

JEFES DE GRUPO DE
PROYECTOS

JEFES/RESPONSABLES
DE PORYECTOS

COLABORADORES EN
PROYECTOS

Fig. 3-6 Articulación en varios niveles del Departamento de Proceso de Datos

según competencias técnicas

En este coso. Sólo tiene que informar directamente el jefe del departamento de
encargados de proyectos y los colaboradores subordinados inmediatamente a la
dirección del CPD si algunos colaboradores trabajan bajo un encargado de proyecto,
estarán sujetos a él todas las cuestiones técnicas mientras dure el encargo.
Cuando se supera la cifra unas 25 personas en tareas de análisis, organización
de sistemas y programación será aconsejable crear un nuevo nivel técnico intermedio
en este se situará los responsables de los grupos de proyectos. También denominados
jefes de grupos, de concepción o de sección. A cada jefe de grupo de proyectos se
subordinan 8-12 colaboradores. Estos trabajan en parte bajo un encargado de
proyectos que informa al jefe del grupo, en parte directamente bajo un jefe de grupo.

En el ordenamiento según grupos de proyectos, un directivo de CPD puede

dirigir jerárquicamente hasta 35-40 colaboradores. Si aumenta esta cifra, designará
para 2-3 grupos de proyectos un jefe de sección que asuma también competencias
jerárquicas con frecuencia se trata del jefe de grupos de proyectos con mayor
experiencias que desempeña suplementariamente esta tarea, pero también puede
tratarse de un mando dedicado exclusivamente a esta función. Además del control
técnico de los jefes de grupos de proyectos subordinados a él y de la dirección
jerárquica un jefe de este nivel tiene que dirigir al staff. Los miembros del staff. Quedan
directamente subordinados a este jefe, casi siempre de forma inmediata. El personal de
staff realiza o trabajo autónomos de staff. o participa directamente en las actividades de
los proyectos.
El encargado de un grupo de proyectos, aparte de la responsabilidad técnica
puede asumir las llamadas competencias de disposiciones. Estas pueden extenderse,
por ejemplo al ajuste de fechas de vacaciones. También puede participar en decisiones
concernientes a la valoración del personal, fijación de sueldos, etc. Pues conoce mejor
a cada colaborador que el responsable de la parte meramente técnica.
La parte subdivisión en grupos de proyectos referidos a objetos y dentro de ellos,
en equipos de proyectos, tiene ventajas para el trabajo en proyectos:

- El jefe del grupo de proyectos es sujeto permanente de experiencias y

responsabilidades.
- El jefe del grupo de proyectos a pesar de su cargo no se convierte en jefe
jerárquico estable de ciertos colaboradores y puede enviarlos a trabajar en
otros grupos de proyectos según convenga.
- La formación de los grupos de proyectos se realiza de acuerdo a motivos
funcionales o de racionalización del trabajo. En general, cada grupo
corresponde a un campo funcional de la empresa.
- En los grupos existen 3-5 equipos de proyectos y colaboradores individuales
que pueden asumir flexiblemente las tareas que van surgiendo.
- En los grupos de proyectos se realizan también trabajos de mantenimiento y
otras tareas menores, su posible ámbito queda definido por la capacidad
existente y por la urgencia, y es controlado por el jefe de grupo de proyectos.
- En cada grupo hay además 1-3 colaboradores que pueden pasar en cualquier
momento a otro grupo si se les precisa allí.
- En conjunto esta articulación organizativa está cortada a la medida de los
principios de una gestión participativa, contiene un mínimo de red jerárquica y
posee la mayor flexibilidad posible.

Un punto de vista esencial en el trabajo por proyectos consiste en la preparación

de claras descripciones de los puestos de trabajo, donde se determinan
inequívocamente tareas y atribuciones de cada jefe de grupo de proyectos o de cada
jefe de equipo de proyecto. Esta delimitación se basará en un estilo participativo de
dirección. Todo nivel de dirección debe atenderse estrictamente a las reglas de juego
formulado en la descripción de puestos de trabajo.
3.5 QUE DIMENSION PUEDE ALCANZAR EL DEPARTAMENTO DE
PROCESO DE DATOS

Frecuentemente, en seminarios de gestión los directores de empresa y los jefes

de CPD plantean la siguiente cuestión qué dimensión puede llegar a obtener un
departamento de proceso de datos en una firma de determinada magnitud existen
acaso normativas o pautas que permitan enjuiciar el tamaño adecuado de este
departamento.
Uno debe evitar ofrecer, precipitadamente, cifras orientadoras sobre este
dominio, pues podrían dar una visión totalmente falsa de la situación no tiene mucho
sentido referirse, como suele hacerse, a la proporción de 1 colaborador en el CPD por
cada 100 personas empleadas en la firma. Lo que podría ser adecuado en una
empresa industrial, será suficiente en una firma comercial con mucho trabajo en
proceso de datos, o será claramente excesivo de datos. En este campo existe la
misma variabilidad que la que muestran las cifras de relación entre costes del CPD e
ingresos totales, tal como ocasionalmente se usan por vendedores, de ordenadores
ante ingenuas firmas, para justificar naturalmente una elevada inversión en
ordenadores.
En la tabla de las páginas 62-63 encontrará usted una panorámica sobre las
tendencias de desarrollo de personal de CPD con respecto a otros factores.

DIMENSIONES TIPICAS DE LOS DEPARTAMENTOS DE PROCESO DE DATOS

Las cifras que exponen aquí sólo quieren ofrecer valores orientativos muy
generales tal como se presentan en la práctica. En general se refieren a empresas
industriales. En firmas comerciales y en organismos de la administración pública hay
que contar con una mayor cifra de personal dado el también mayor campo de tareas
desempeñadas.
La cifra justificable de personal sólo puede deducirse de un análisis individual de
necesidades hecho a partir del espectro de tareas de un empresa u organismo público.

- EMPRESA DE 100 A 400 EMPLEADOS

En empresas industriales, la cifra del personal de CPD suele ser de 1-2 cuando
se dispone de un miniordenador de tipo interactivo.

- EMPRESAS DE 600 A 800 EMPLEADOS

Las empresas de este tamaño tienen casi siempre un ordenador en que se

desarrolla sucesivamente los encargados (proceso batch) y eventualmente también
pueden ejecutarse proceso interactivo. Se necesita más personal. Aquí puede oscilar la
cifra de colaboradores del CPD entre 6 y 10.

- EMPRESAS DE 1.200 A 2.000 EMPLEADOS

 Al crecer la dimensión de la empresa aumentan las exigencias al ordenador.
Crece el número de programas a medida frente al de los standard, como sucedía en
empresas menores. Cifras típicas de colaboradores en el CPD: 15-30.

Dependencia de la cifra de personal en un departamento de Proceso de Datos

Criterio Repercusiones en la cifra de personal Tendencia
1. Relación entre empleados y Al aumentar la cifra de personal de oficinas suelen aumentar los
personal productivo en la campos de aplicaciones del CPD y de dimensión de los
empresa departamentos
2. Magnitud de aplicaciones El número de colaboradores en el CPD depende de ellas en
actuales y de programas especial del número de proyectos realizados paralelamente

3. Integración de las aplicaciones En aplicaciones con grandes interconexiones se necesita más

personal para desarrollo y asistencia a sistemas que en el caso de
soluciones asiladas
4. Todos los puestos de Si el departamento de proceso de datos incluye también la
organización de un organización general aumentará la cifra del personal en él, otra
departamento posibilidad separar la organización general o suprimirla
5. Nivel muy elevado de Se puede seguir esta política menos colaboradores calificados o n
remuneración y colaboradores número mayor de personal mediocre
cualificados
6. Sistematización exagerada Al contrario de un jefe orientado al beneficio bajo el tecnócrata es
debida a tecnócratas, fácil un exceso de plantilla
consecuencia gran número de
puestos de servicios y de staff
7. Personal fuerte en un Puede realizarse rápidamente el análisis e introducción de nuevos
departamento maduro sistemas se necesita menos colaboradores en trabajo de análisis

8. Muchos tipos de hardware. De Hay que apoyar varios sistemas de explotación esto lleva a un
diversos fabricantes dispendio mayor de programadores de sistemas y de aplicación

9. Predominio de empleo de Menos analistas y programadores de sistemas

software externo (paquetes de
aplicaciones)
10. Tamaño de la empresa Expansión desproporcionada del CPD en las grandes empresas

11. Turnos de trabajo en el centro Aumenta consecuentemente el número de los operadores

de cálculo

12. Empleo masivo de fichas También se necesitan más operadores en el centro de cálculo y
perforadas de cintas archivo de cintas
magnéticas

13. Fuerte presión de costes sobre Es necesario orientarse según prioridades en la ejecución de
el jefe del CPD tareas separase del personal menos capaz de rendimiento

Fig. 3-7 de qué depende la cifra de personal de un departamento de proceso de datos?

- EMPRESAS DE 5.000 A 8.000 EMPLEADOS

El departamento de proceso de datos abarca aquí unos 70-120 colaboradores

- EMPRESAS DE 12.000 A 20.000 EMPLEADOS

Si se conserva todavía un CPD central, suelen emplearse en él 180-350

colaboradores.
Si se considera la relación entre los distintos grupos de colaboradores, se
registra por término el siguiente porcentaje:

Centro de Cálculo 40%

Programación 35%
Organización/Análisis de sistemas 15%
Dirección y staffs 10%

La dimensión que llega a obtener el centro de cálculo depende mucho del

personal necesario para entrada de datos, al irse introduciendo el tipo de ordenador
interactivo se advierte ya una fuerte baja de personal en este campo.
La evolución de la cifra de personal en los centros de Cálculos es muy diversa,
está influida principalmente por los siguientes factores:

- Cambios en los métodos de entrada de datos

- Tendencia a periféricos que necesitan menos servicio (p.e. discos de gran
capacidad, abandono de fichas perforadas, etc.).
- Descentralización y procesos interactivos.

La tendencia de personal en los departamentos de proceso de datos puede

resumirse en la tabla de la página siguiente.

3.6 MEDIDAS PARA REDUCIR PERSONAL EN EL CPD

Los cinco puntos siguientes ordenados según importancia decreciente muestran

los puntos que inciden con mayor importancia en una reducción del personal del CPD:

Tendencias en la evolución de la categorías de personal de un departamento de

proceso de datos
Grupo de colaboradores Tendencia

Organización General/organizadores de oficina

Analistas de sistemas (sin programación)

Programadores de sistemas

Programadores de aplicaciones

Puestos de staff y servicios

Personal de centro de cálculo (sin entrada de datos en la

misma forma de proceso)

Entrada de datos en centro de cálculo

Fig. 3-8 Tendencias de personal según categorías de colaboradores

 La mayor influencia sobre la cifra de personal se logra mediante una

descentralización como empleo de miniordenadores en los departamentos
especializados; limitación de los procesos tipo batch programación de
aplicaciones menores con software externo (paquetes standard);
repercusiones sobren personal de desarrollo de sistemas del CPD y del
centro de cálculo.
 Entrada de datos en terminales descentralizados, directamente en los
departamentos usuarios, incluyendo las modificaciones; así, reducción de
empleados en entidad central de datos y en menor medida de operadores.
 Mayor empleo posible de software de aplicaciones en los departamentos más
importantes; así menores necesidades de personal de desarrollo y
mantenimiento
 Introducción de bancos de datos sencillos y de fácil mantenimiento; así menor
demanda de personal de asistencia a bancos de datos y de desarrollo
 Mayor empleo posible de software de programación de documentación para
nuevos desarrollos y para mantenimiento; así menores necesidades de
personal de desarrollo.
 Mayor activación posible de los departamentos usuarios; así menor demanda
de analistas de sistemas y de organizadores de oficinas (organización
general).

3.7 DIALOGO DE ENTRENAMIENTO; ALTERNATIVAS DE SOLUCION AL

PROBLEMA DEL MANTENIMIENTO DE LAS APLICCIONES DEL CPD

Existen muchos departamentos de proceso de datos, en los que el 80-90 % de

los analistas y programadores se dedican exclusivamente al mantenimiento de los
sistemas de aplicación en uso. Hay que considerar esta situación como un destino
inevitable al que camina fatalmente todo CPD.

 Indudablemente la tendencia actual es que el trabajo en la asistencia y

mantenimiento de sistemas instalados aumenta en proporción al dedicado a
nuevos desarrollos. Paro el porcentaje de personal ligado al mantenimiento
depende mucho de la forma como se defina el mantenimiento.

Debe concebirse como mantenimiento todo desarrollo posterior de una aplicación

de proceso de datos en uso yo, por ejemplo no lo consideraría como trabajo típico de
mantenimiento. O habla usted de un caso de mantenimiento cuando hace que le
instalen en su auto una platina para cassettes.

 En muchas empresas, debido a los pecados del pasado el mantenimiento ha

crecido tanto que realmente apenas si queda tiempo para desarrollos
posteriores o nuevos.

Quisiera volver a su última observación. Pero primero deberíamos definir

exactamente el concepto de mantenimiento (maintenance). Cuáles son los puntos que
considera usted esenciales en él?

 Yo considero que el trabajo típico de mantenimiento de programas

comprende los puntos siguientes:
- Cambios en programas y archivos de datos motivados por corrección de
errores en el nuevo programa de aplicaciones.
- Ampliaciones o trabajos para completar programas que no supongan más de
10-20 días-persona.
- Adaptación de programas de un nuevo hardware (ejemplo; discos
magnéticos).
- Adaptación de programas a un nuevo software (ejemplo cambios den los
sistemas operativos)
- Adaptación de programas a sistemas vecinos (integración posterior a la
instalación de varios sistemas inicialmente inconexos).

Este punto quedaría pues claro. Volviendo a su observación de que un elevado

porcentaje de mantenimiento reflejaría los pecados del pasado y que hay que pagarlos
a qué se refiere usted aquí?

 Todo el maintenance sería mucho más sencillo si las aplicaciones de antes

hubieran sido construidas de una forma que permitieran una fácil
manipulación posterior cuando aparece un error en un programa, en general
se necesitan casi siempre tres días para encontrar la causa en una
programación estilo spaghetti y mediodía más para que el programador la
corrija. Lo mismo pasa cuando hay que hacer modificaciones y ampliaciones
menores.

Podría usted enumerar brevemente los principales principios que rigen en el

mandamiento?

 Lo que voy a exponer son realmente perogrulladas pero ya se sabe que los
errores que se comenten con mayor frecuencia son de sentido común en
primer lugar habría que mencionar:

- Utilización de una metodología estructurada y modular en Análisis de

Sistemas y Programación.
 - Empleo de métodos claros de programación y uso más amplio de lenguajes
de programación más perfectos.
- Renuncias a trucos en la programación
- Empleo de listas de cross reference de tablas externas de programas y de
tablas de decisión.
- Comentarios y documentación basándose en encargos y en valoración de
costes/beneficios.
- Agrupamiento de trabajos de mantenimiento sobre la base de una asignación
de prioridades.

Creo que estas indicaciones bastan para mostrar la dirección que hay que tomar
para reducir los trabajos de mantenimiento.

Debemos tratar todavía el aspecto de personal de mantenimiento de programas.

Según su experiencia es mejor organizar un grupo de mantenimiento junto al de los
proyectos o es preferible integrar el mantenimiento dentro de las actividades de los
grupos de proyectos?.

 Aquí debemos distinguir entre el ideal y la consideración realista

indudablemente la solución óptima sería separar plenamente nuevos
desarrollos y mantenimiento. Pues es peligroso confiar el mantenimiento a
los que han desarrollado el sistema y convertir esta tarea en algo
dependiente de una o más personas, a la larga no puede atar a un
colaborador en la empresa. Qué si se despide o es ascendido a otro puesto?,
Así pues, como objetivo a largo plazo habría que tender a que no sólo la
programación, sino también el mantenimiento se estructuraran
despersonalizadamente ya he mencionado aquí las condiciones previas.

Existen empresas que hayan logrado ya el objetivo de un puesto independiente

de mantenimiento?

 Conozco algunas que han vuelto a trabajar recientemente con un grupo

independiente de mantenimiento. Entre ellas, algunos grandes bancos y
algunas empresas industriales.

Por lo demás la labor del puesto de mantenimiento se limita a sistemas bien

estructurados y claramente documentados. Además el personal de mantenimiento no
está peor pagado que sus colegas de desarrollo en un caso incluso reciben un
suplemento por monotonía.

Existen pues en esa empresa dos grupos separados de colaboradores de CPD

de desarrollo y de mantenimiento?

 No. Esto no funcionaría o que más bien sucede es que cada programador,
después de 1-2 años de actividad en nuevos desarrollos pasa por un cierto
periodo a la etapa de mantenimiento de sistemas. La mayoría considera este
 período como de recuperación ante el stress derivado de los nuevos
desarrollos.

Por desgracia estas observaciones sólo valen para sistemas nuevos, Qué
podemos hacer con la gran cantidad de programas antiguos y mal
documentados?

 Su mantenimiento seguirá exigiendo mucho trabajo de berá quedar

forzosamente a cargo de los antiguos programadores cuando pueda
disponerse de ellos pero en algún momento estos programas dejarán de
utilizarse. Por lo menos para entonces nos queda una chispa de esperanza.