SUBSISTEMA DE REQUERIMIENTOS DE HARDWARE

,,,,,

, ", RAT~CRE_HARO , ,

" , "

,, ,, ,, ,, ,, ,

EaUUNST

Figura 9. : Diagrama de Forrester : Requerimientos de Harct.Nare

Subsistema de Recursos Humanos

Misi6n: Asegurar la optimizacion de la cantidad de ingenieros asignados a

los diferenles proyectos. versus el numero de horas asignadas a cada uno

de los mismos (rendimiento del personal).

145

Proceso biisico operacional: Esta orientado hacia, planeacion de

contrataciones, entrenamientos, terminaci6n de contratos y politicas

salariales.

Resultados Buscados: Informaci6n del personal y mimero de empleados.

Estrategia: Plan ear diferentes altemativas de reclutamiento, selecci6n,

entrenamiento y motivaci6n que Ilenen las expectativas de calidad y que

equilibren los factores inversion salarial y beneficia laboral "

UQUI'lllMIENTOS DE ING(.N1D.Os

Tl\T:f'l IEROS k lJ.c\S!t "''1Al>L1:i

,

Il llhl"HA

~ NiE.-.JIF.MOS An tAt ES EN a. Akl'.A

Figura 10. : Diagrama Causal : Recursos Humanos

146

SUBSISTEMA DE RECURSOS HUMANOS (lNGENIEROS)

", ,

,

PROD R SOFT r- -:-1

Figura 11. : Diagrama de Forrester: Recursos Humanos

Subsistema de Producci6n Efectiva de Software

Misi6n: Asegurar la producci6n optima de software para los diferentes

proyectos (productividad en el desarroll'o del area).

Proceso bAsico operacional: Ejecuci6n de proyectos informaticos del

departamento de sistemas de Tejicondor S.A.

Resultados Buscados: Producci6n efectiva de software.

Estrategia: Generar la menor cantidad de perdidas por proceso de

desarrollo y optimizando las horas asignadas para cada proyecto.

r- PROOUmONEFEC11VA ~

PERDlDA REAL PRODUCCIONI REAL DE PRODUCCION

+~ P8mO"OAS ~ PORPROCESO

DETECCION DE ERRORES

( ~.¢w"!'.tDH"~~

HORAS DE CADA PROYECTO HARDWARE

DISPO 'IDLE

Figura 12 : Diagrama Causal: Producci6n Efectiva de Software

SUBSISTEMA DE PRODUCCION EFECTIVA DE SOFTWARE

Figura 13 : Diagrama de Forrester: Producci6n Efectiva de Software

148

Subsistema de Desarrollo de Nuevos Proyectos

Misi6n: Garantizar la asignaci6n optima de horas para la ejecuci6n de cada

proyecto, balianceando las perdidas de tiempo por problemas de analisis

como tambien las ventajas de desarrollo por calidad del mismo analisis.

Proceso basico operacional: Horas reales consumidas en cada proyecto

informatico.

Resultados Buscados: Cantidad real de horas asignadas y consumidas en

cada proyecto.

Estrategia: Generar la menor cantidad de compresi6n negativa en cada

proyecto y perdidas por comunicaci6n y anal isis.

RDl: D ON EN EL AREA

\ HORAS REALES PARA HORAS SlGNADAS+\ CADAPROYECTO +" NOCON:U,DAS~ __.....

~ HORASASIG ASA ~ I ( + LOS PROYECTOS + \ PEROIDAS POR COMPRl!S10N

~~\ J~"" ~ HORASREALES PARA

A PROOOCCl N REAL DEf )c.:o PROYECID + ~ SOFtWARE \

soucrruo DE I'ROYEcros

PBRDIDAS DE TMMNODEPRODUceo LOS PROYECrOS

Figura 14: Diagrama Causal: Desarrollo de Nuevos Proyectos

149

SUBSISTEMA DE DESARROLLO DE NUEVOS PROYECTOS

r :l ----

Figura 15 Diagrama de Forrester : Desarrollo de Nuevos Proyectos

5.1.3. Presentacion y Analisis de Resultados

A partir del modelo organizacional aqui construido serfan multiples los

escenarios que podrfan construirse, no obstante, se han planteado tres a

modo de ejemplo. En los tres escenarios, que se simularon, se estableci6 un

horizonte 0 cicio de treinta y seis meses (tres arios).

150

Escenario 1 : Se obtiene en condiciones normales del modelo, es decir,

lNG_AREA =11, EQUI_INST =8, PROD_R_SOFT =2. Cuando se corre la

simulaci6n se puede representar diversas posibilidades, en el modelo

creado aqur, los niveles actuales de personal tienden a oscilar hacia nuestro

objetivo, siguiendo las pautas tfpicas de un cicio compensador con demora

(un mes de contrataci6n) : al principio demasiados ingenieros (veintiuno al

cabo de dos meses), luego logra lIegar al objetivo de numero de ingenieros

(diez y siete al cabo del mes diez), momenta en el cual tambien se estabiliza

la requisici6n de equipos necesarios (Once) para lograr una entrega de

productos efectivamente desarrollados por el area de informatica de trece

m6dulos de aplicaciones por mes,(Figura 16), con una asignaci6n de horas

para los proyectos, que oscila entre ,[1.040 - 1540] horas/mes, es decir, un

tiempo de trabajo de 5.4 hora - dra - ingeniero (Figura 17), en esta

simulaci6n ademas, podemos observar que existe una mayor productividad

de los equipos, dandose una relaci6n de 1.5 ingenieros por equipo, hay una

mayor optimizaci6n de la capacidad instalada, y el rendimiento del desarrollo

es punto ocho (0.8) m6dulos por ingeniero mes.

Escenario 2: Se genera a partir del concepto de racionalizaci6n de la

planta de cargos adscrita al departamento de informatica, el modelo asume

los siguientes parametros lNG_AREA = 14, EQUI_INST = 20,

PROD_R_SOFT =3. En la grafica, el modelo muestra una carda inmediata

151

del numero de ingenieros requeridos, como tambien la necesidad de equipos

instalados para operar, no obstante se ve que la racionalizaci6n de

computadores no decrece de la misma forma que del personal, dado que en

la practica (realidad empresarial) la salida de equipos de computo se da por

obsolescencia, danos 0 reinversiones (reconversi6n industrial), entre otros,

pero esto es mucho mas lento, en cambio para personal en algunas

ocasiones un despido puede ser mas simple.(Figura 18)

En este escenario, se puede analizar que al estabilizarse el cicio

compensador del modelo habra 1.2 equipos por ingeniero, es decir, hay mas

equipos de computo que ingenieros. Como tambien el nivel de productividad

baja a cuatro m6dulos de aplicaci6n por mes, con una asignaci6n horaria

para los proyectos, en un rango de [650, 840 ] horas mes (Figura 19), a

menos ingenieros menos horas para los proyectos 10 que da un promedio de

6.2 horas - dfa - ingeniero para poder cumplir las metas de desarrollo, se

trabaja mas pero se entregan menos aplicaciones terminadas.

Escenario 3: Se produce este a partir del concepto de crecimiento de la

planta de cargos y maximizaci6n del numero de m6dulos de aplicaciones

informaticas, el modelo asume los siguientes parametms lNG_AREA = 15,

EQUI_INST = 15, PROD_R_SOFT = 3. En la grafica, el modelo aumento de

inmediato en el numero de ingenieros estabilizandose en el cuarto mes, en

152

cambio el numero de equipos solo se estabiliza en el mes quince, donde se

empieza a dar una productividad por equipo de computo de 1.3 ingenieros

por equipo, generando una entrega ascendente de modulos de cada

aplicacion a una rata de 1.025 presentandose una asfntota alrededor de 19

ingenieros, es decir un modulo por ingeniero mes (relacion uno a uno)

(Figura 20).

La asignacion horaria para los proyectos, oscila en un range de [1400, 1600]

horas mes (Figura 20), a mas ingenieros mas horas para los proyectos 10

que da un promedio de 6.3 horas - dfa - ingeniero para poder cumplir las

metas de desarrollo, se trabaja mas pero se entregan mas aplicaciones

terminadas, en una relacion 0.93 aplicaciones par meso

Como se puede observar, evaluar la simulacion en sus tres escenarios

resulta gratificante, puesto que ocurrirfa si nos extralimitamos en un proceso

de contratacion 0 despido, 10 que puede lIegar a significar que se elimine

personal sin necesidad 0 se contrate mayor numero del necesario,

incurriendo en pagos e indemnizaciones innecesarias y costosas, e

igualmente adquiriendo equipo de computo que no se requiere y que

rapidamente se vuelve obsoleto.

MESES

Figura 16. Escenario 1. Comportamiento comparativo del: Total de ingenieros en el area vs. EI total de quipos de computo instalados vs.

Producci6n real de software en el area.

o 1 2 3 • 5 8 7 8 9 10 tI 12 13 t .. 15 18 17 '8 19 20 2' Z2 23 24 25 28 'Z7 28 29 30 31 32 13 34 35 38

MESES

Figura 17. Escenario 1. Total Horas asignadas a los proyectos