You are on page 1of 279

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

JUAN BRAVO

Estimado lector:
Este libro en versin digital no es gratis. El valor es
de US$ 15 ( $ 7.500 pesos chilenos). Justificado
por el indispensable retorno econmico para
continuar estas investigaciones y por el
comportamiento tico de respeto a la propiedad
ajena.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

GESTIN de
PROYECTOS
de PROCESOS y TECNOLOGA

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

GESTIN de
PROYECTOS
de PROCESOS y TECNOLOGA

JUAN BRAVO CARRASCO

JUAN BRAVO

JUAN BRAVO CARRASCO, 2006


Inscripcin N 154.082, 10 de abril de 2006
ISBN N 956-7604-12-6, 10 abril de 2006
Derechos reservados, jbravo@vtr.net
Versin digital actualizada en 2011.

EDITORIAL EVOLUCIN S.A.


www.evolucion.cl, info@evolucion.cl
Santiago de Chile

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

Dedicado a los profesionales annimos que planean


y ejecutan bien sus proyectos
ellos pasan desapercibidos porque no requieren
actuar de bomberos.

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

RECONOCIMIENTOS
Agradecer a muchas personas que de una u otra forma
han cooperado: Juan Carlos Gonzlez, Gerardo Cerda
Neumann, Guillermo Gmez, Luis Cid, Sergio Valenzuela, Rolf Achterberg, Giancarlo Gandolini, Edmundo
Leiva, Marcos Merino, Luis Hevia, Javier Caas, Ignacio
Orrego, Pere Mir, Miguel Saz, Samuel Chvez, Limbi
Ortiz, Rodrigo Baldecchi, Rodrigo Silva, Francisco
Ramrez, Alberto Neira, Ral Prado Baldratti y otros.
Agradecer a Jos Kaffman la oportunidad de dictar cursos del mtodo GSP Gestin Sistmica de Proyectos) y
de GPPT (Gestin de Proyectos Procesos y Tecnologa)
a travs de Revista Gerencia. Tambin a mis socios del
proyecto GSP y a Juan Costella Montt por su apoyo.
A Carlos Pinto, director del Centro de desarrollo de la
Vicerrectora de Investigacin y Desarrollo de la Universidad de Chile, desde donde hemos realizado muchos
proyectos de postgrado, tales como el Diploma de Gestin de Proyectos Procesos y Tecnologa en el BancoEstado, agradezco en forma especial a los participantes en
ste.
Mi agradecimiento a las organizaciones, sus ejecutivos y
colaboradores, donde hemos realizado consultora o capacitacin orientada a los proyectos de GPPT: Termosistema, Integramdica, IST, Hospital San Borja Arriarn,
Codelco, Enami Ventanas (actual Codelco), Banco Santander Santiago y HUAP (Posta Central).
En particular, por el impacto en este texto, quisiera destacar las experiencias de consultora y capacitacin en
tres empresas.

JUAN BRAVO

10

Agradeciendo a todos, sealo algunos nombres junto con


mis disculpas a quienes merecidamente deban estar (y
que omit por error):

BancoEstado: Loreto Faras, Nilda Mardones, Tamara Vilches, Alicia Garay, Fernando Len, Rodrigo
Collado, Arturo Barrios, Hernn Baeza, Humberto
Gmez, Alfredo Correa, Carlos Montecino, Adolfo
Grasset y Hctor Ponce.
Rolec S.A.: Gabriel Rodrguez, Luis Contreras, Ramiro Santibez, Marcelo Guerra y Fernando Prez.
Empresa Portuaria de Valparaso (EPV): Mario
Troncoso, Mabel Ruiz y Eduardo Jones.

A mis colegas profesores de la Escuela de negocios


IEDE Chile y compaeros del Programa de Doctorado
con la UDL: Yolanda Ynez, Jorge Israel, Francois Le
Calvez, Jaime Sanhuesa, Patricio Snchez y Daniel Kanonitsch.
A todos agradezco y libero de cualquier responsabilidad
por los errores de este texto.
La portada es diseo de mi hijo Juan Pablo.
A mi esposa e hijos, crear este libro ha permitido estar
ms cerca de ellos porque buena parte de trabajo ha sido
en la oficina de mi casa, enriquecindose as el trabajo.
JBC

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

11

CONTENIDO
RECONOCIMIENTOS ............................................................... 9
CONTENIDO ......................................................................... 11
PRLOGO ............................................................................. 19
PRLOGO A LA VERSIN 2009 ............................................. 24
INTRODUCCIN .................................................................... 25
Objetivo del libro ........................................................... 27
Visin estratgica de proyectos ..................................... 29
El modelo integral del cambio ....................................... 30
Orientacin al cliente..................................................... 30
Inicio del proyecto ......................................................... 31
Desarrollo del proyecto ................................................. 32
El plan de proyecto ........................................................ 33
Visin de conjunto del mtodo ....................................... 34
Etapas del proyecto ........................................................ 35
Prcticas transversales .................................................. 38

PRIMERA PARTE. MTODO ......................... 41


INTRODUCCIN .................................................................... 45
Qu es mtodo? ........................................................ 45
Las mejores prcticas .................................................... 48
Fundamento conceptual: la visin sistmica ................. 49
Mtodo GSP ................................................................... 49
CLAVES DE LA IMPLANTACIN DE MTODO ........................ 51
Clave 1. Visin de conjunto ........................................... 51
Clave 2. Mnimo indispensable ...................................... 53
Clave 3. Participacin de todos los actores .................. 54
Clave 4. Circularidad .................................................... 55
CARACTERSTICAS DEL MTODO ......................................... 57
1. Adhesin a estndares y normas de calidad .............. 57
2. Actualizacin .............................................................. 57
4. Informacin de calidad .............................................. 58
3. Pragmatismo .............................................................. 59
5. Curso normal de los Eventos y SPPP ........................ 60
6. Adaptacin a proyectos especficos ........................... 60
7. Pasin por conocer la finalidad, el para qu ............ 62

12

JUAN BRAVO

ESTRUCTURA PARA LA GPPT .............................................. 63


rea de metodologa o UTP ........................................... 63
rea de estudios ............................................................. 63
Comit de Proyectos ...................................................... 64
rea de gestin TI .......................................................... 65
Arquitecto de Datos ....................................................... 67

SEGUNDA PARTE.
ETAPAS DEL PROYECTO............................... 71
INTRODUCCIN .................................................................... 75
Cuantificar todo ............................................................. 75
Fase de estudios ............................................................. 76
Proceso Fabricar el cambio .......................................... 77
ETAPA 1. CONCEPCIN ........................................................ 83
1.1. mbito del problema ............................................... 85
1.2. Cul es el problema? ............................................ 89
1.3. Cuantificar el problema .......................................... 95
ETAPA 2. FACTIBILIDAD ...................................................... 99
2.1. Conformar el equipo de trabajo............................ 101
2.2. Ideal de la solucin ............................................... 102
2.3. Planteamiento libre de alternativas ...................... 104
2.4. Restricciones de la solucin .................................. 108
2.5. Seleccin de alternativas y objetivos generales ... 110
2.6. Evaluacin de cada alternativa ............................ 111
2.7. Evaluacin comparativa ....................................... 112
2.8. Decide la opcin y objetivos especficos .............. 114
2.9. El plan de proyecto ............................................... 115
ETAPA 3. ANLISIS ............................................................ 119
3.1. El Modelo integral del cambio.............................. 121
3.2. Estrategia .............................................................. 122
3.3. Personas ................................................................ 123
3.4. Gestin de Procesos .............................................. 124
3.5. Estructura.............................................................. 130
3.6. Tecnologa ............................................................. 131
3.7. Visin global de la solucin .................................. 131
3.8. Ingeniera de requerimientos ................................ 132
3.9. Definiciones de la TI ............................................. 134

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

13

3.10. Entorno Tecnolgico ........................................... 134


3.11. Supuestos ............................................................. 135
3.12. Identificacin de los usuarios ............................. 136
3.13. Sistema de codificacin ....................................... 137
3.14. Requerimientos computacionales ....................... 137
3.15. Diagrama de casos de uso .................................. 138
3.16. Caso de uso de alto nivel .................................... 139
3.17. Caso de uso expandido........................................ 141
3.18. Modelo Conceptual ............................................. 142
3.19. Diagrama de secuencia del sistema .................... 145
3.20. Visin dinmica del sistema ................................ 147
3.21. Diagrama de estado ............................................ 148
3.22. Contratos ............................................................. 149
3.23. Interfaces usuario sistema ............................... 150
3.24. Prototipos desechables ....................................... 151
3.25. Revisin de los modelos ....................................... 151
3.26. Uso de herramientas ........................................... 152
3.27. Costo del proyecto .............................................. 152
ETAPA 4. DISEO ............................................................... 153
4.1. Diseo de procesos ............................................... 155
4.2. El diseo del software ........................................... 160
4.3. Diagrama de Diseo de Clases ............................. 161
4.4. Diagrama de colaboracin ................................... 163
4.5. Visin externa ....................................................... 165
4.6. Entorno de la aplicacin ....................................... 165
4.7. Costo del proyecto ................................................ 166
ETAPA 5. IMPLEMENTACIN .............................................. 167
5.1. Negociar los compromisos .................................... 169
5.2. Implementar los procesos ..................................... 170
5.3. Implementar la TI .................................................. 172
5.4 Probar .................................................................... 173
5.5. Instalar el piloto .................................................... 176
ETAPA 6. DESPLIEGUE ........................................................ 179
6.1. Revisar y actualizar elementos ............................. 180
6.2. Incorporar a cada usuario ..................................... 181
6.3. Capacitar a los usuarios ....................................... 181
ETAPA 7. OPERACIN ........................................................ 183

14

JUAN BRAVO

7.1. La mejora continua ............................................... 184


7.2. Control de cambios ............................................... 187
7.3. Una mesa de ayuda ............................................... 189
7.4. Buena operacin de la aplicacin ........................ 189
7.5. Gestin de la calidad ............................................ 190
7.6. Rediseo programado de la solucin.................... 191

TERCERA PARTE. PRCTICAS


TRANSVERSALES........................................... 193
INTRODUCCIN .................................................................. 197
Las mejores prcticas en proyectos ............................. 197
Ordenamiento de las prcticas .................................... 198
Definir una poltica por cada prctica ........................ 198
Llevar a la Carta Gantt ................................................ 199
Base de datos de estndares numricos ....................... 199
Cules prcticas incorporar en un proyecto? ........... 200
1. DIRECCIN DEL PROYECTO ............................................ 202
2. PLAN DE LA ETAPA ......................................................... 203
3. EXPOSICIN DE LOS PLANES .......................................... 204
4. RETROALIMENTACIN ................................................... 205
5. EL EQUIPO DE TRABAJO ................................................. 206
6. ENTREVISTAS ................................................................. 207
7. COMUNICACIN ............................................................. 208
8. INFORMES ...................................................................... 209
9. TCNICAS ....................................................................... 210
10. HERRAMIENTAS DE APOYO .......................................... 211
11. TRAZABILIDAD............................................................. 212
12. QUICK WINS ................................................................ 213
13. COSTOS Y DURACIN ................................................... 214
14. GESTIN DE RIESGOS ................................................... 215
15. GESTIN DE LA CALIDAD ............................................. 216
16. RESPONSABILIDAD SOCIAL .......................................... 217
17. INSERCIN.................................................................... 218
18. ORIENTACIN AL CLIENTE ........................................... 219
19. SENSIBILIZACIN ......................................................... 220
20. CAPACITACIN ............................................................ 221
21. SEGUIMIENTO ............................................................... 222

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

15

22. CUIDAR LA SOLUCIN ANTERIOR................................. 223


23. CONTINUIDAD OPERACIONAL ...................................... 224
24. PLAN DE RECURSOS FSICOS DEL PROYECTO ............... 225
25. KILL TIME .................................................................... 226
26. CONTROL DE CAMBIOS ................................................ 227
27. GESTIN DEL CAMBIO .................................................. 228
28. GESTIN DE PROVEEDORES .......................................... 229

PARTE FINAL. CONCLUSIONES, ANEXOS Y


BIBLIOGRAFA ............................................... 230
CONCLUSIONES .................................................................. 232
ANEXO 1. RELACIN CAUSAL ............................................ 234
ANEXO 2. UML ................................................................. 237
Casos de uso ................................................................. 238
ANEXO 3. RUP................................................................... 240
ANEXO 4. NORMAS DE CALIDAD DEL SOFTWARE .............. 242
CMM ............................................................................ 243
ISO 9000....................................................................... 244
Tick IT .......................................................................... 245
ANEXO 5. DESARROLLO EN ESPIRAL DEL PROYECTO ........ 247
ANEXO 6. GESTIN DE CALIDAD EN PROYECTOS .............. 249
ANEXO 7. CASO BANCOESTADO ....................................... 251
ANEXO 8. ITIL ................................................................... 253
ANEXO 9. PMI ................................................................... 255
ANEXO 10. MODELO PARA CASO DE NEGOCIOS ................ 256
BIBLIOGRAFA.................................................................... 263

16

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

17

Los que conocen ntimamente un oficio saben


perfectamente que lo que menos se encuentra es la
uniformidad en los mtodos usados. En lugar de haber
una sola manera de trabajar aceptada generalmente
como modelo, se usan diariamente, digamos, 50 100
maneras diferentes para hacer cada elemento de
trabajo.
Frederick Winslow Taylor

18

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

19

PRLOGO
Entre 1975 y 1978 tuve el privilegio de estudiar en
la Universidad Tcnica Federico Santa Mara una
carrera muy rara: IESI o Ingeniera de Ejecucin en
Sistemas de Informacin, era la primera vez que se
dictaba en la USM y no haba a quien preguntar. Es
ms, no haba a quien preguntar en todo Chile porque las dems universidades tambin estaban recin
iniciando sus propias carreras cercanas a la computacin. Como es natural, hubo mucho de prueba y
error en esa poca (ahora tambin).
Bueno, la carrera tena efectivamente un fuerte nfasis en la computacin (Fortran, Cobol, tarjetas perforadas, equipos de un milln de dlares con memoria
de 32KB, grandes unidades de disco de 2 MB, mucho trabajar de noche y otros componentes del paradigma de entonces), sin embargo, tambin profundizaba en la teora de sistemas y en la administracin
de empresas, de hecho, fue un doble privilegio estudiar en esa poca porque tambin conoc la Universidad Adolfo Ibez (UAI), ms bien a varios de sus
profesores, porque se incluy toda una serie de asignaturas de administracin que ellos dictaban. Se pretenda dar a la carrera un enfoque de solucionar problemas, de mirar a la organizacin en forma integral,
como un sistema. As, aprend que un Sistema de
Informacin no es solamente computacin sino tambin estrategia, personas, estructura organizacional,
procesos y mucho ms.

20

JUAN BRAVO

Ocurri que de los pocos que egresamos en los primeros aos de existencia de la carrera (probablemente una docena) todos derivamos hacia la computacin, o informtica como se le comenzaba a llamar. Por lo tanto, la carrera cambi a Informtica.
Mi propio proceso fue similar, tambin por algunos
aos mi sesgo fue tecnolgico (me desempe como
Jefe de proyectos en NCR y luego como Gerente de
Informtica de una empresa comercial). Sin embargo, con el tiempo comenc a recuperar el espritu
original de esa rara carrera: ver a la organizacin de
manera integral. Ya trabajando como consultor independiente hacia fines de los ochenta, esto se materializ en asesoras de ms amplio alcance, considerando la estrategia, las personas, procesos y otros
factores. Curioso, a veces los problemas se resolvan
completamente a ese nivel, sin necesidad de ocupar
mi querido martillo de la informtica.
Durante esa poca y hasta fines de los noventa mi
formacin fue ms bien autodidacta (aunque participando en muchos cursos breves con autores como
Yourdon, Jacobson, Drucker, Peters y otros). Como
una forma de mantenerme actualizado cooper tambin por 15 aos como profesor de ctedra Part Time en la Universidad de Chile (DCC, Escuela de
Ingeniera), diriga talleres de anlisis de sistemas y
guiaba alumnos memoristas. La doble experiencia
de consultora y acadmica fue central en la creacin
de conocimiento que plasm en varios artculos (tal
como Flexibilidad de Sistemas y Se justifica el
desarrollo de un sistema computacional, 1984 y

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

21

1985, respectivamente) y en dos productos: el libro


Desarrollo de Sistemas de Informacin, una visin
prctica (1988) y el Generador de aplicaciones Bravo2/L4G (1989).
El libro ya expresaba la idea de solucionar problemas con una visin amplia, ms que solamente aplicar el paradigma informtico y poco a poco se transform en un mtodo bastante aplicado en las empresas y en el texto gua habitual en asignaturas de sistemas de informacin. El Bravo2/L4G1 mis disculpas por el uso de mi apellido, fue bautizado as
por clientes que quisieron disponer de este producto,
el cual constru como de uso personal se emple
en empresas y fue una asignatura del mismo nombre
en algunas universidades e institutos.
Durante la dcada de los noventa consolid mi lnea
de asesora integral a las empresas y segu cooperando con las universidades, cabe destacar un programa de anlisis y diseo de sistemas que hicimos
con la USM y que lleg a tener ms de mil egresados, el cual evolucion incluso hasta transformarse
en un diploma. La experiencia se materializ en
nuevos ttulos: Reingeniera de Negocios (1995), La
Nueva Visin, Diseo y Construccin de Sistemas
1

El generador tena un mdulo de modelamiento de datos y funciones con orientacin a objetos desde donde se generaba el cdigo en
COBOL y luego en otros lenguajes. Se vendieron unas 300 licencias
en Chile y Latinoamrica y unas 1000 fueron donadas a instituciones
educacionales. Tena alrededor de 500.000 lneas de cdigo y lo
constru durante varios aos (1986-9), mientras me dedicaba a desarrollar sistemas computacionales para empresas.

22

JUAN BRAVO

Computacionales (1996), Planificacin Sistmica


(1997), Anlisis de Sistemas (1998) y El Encanto de
la Comunicacin (1998), centrados ms bien en la
visin sistmica, nueva cosmovisin en la cual se
transform la antigua teora de sistemas y que
adems recoge los grandes nuevos aportes, como la
teora de comunicacin de Maturana, la teora del
caos y el pensamiento sistmico de Senge, entre
otros afluentes.
Ms o menos con la llegada del nuevo milenio consider que ya tena la experiencia necesaria para otro
ciclo de formacin. Obtuve un Master en Direccin
de Informtica con un instituto de Madrid y luego un
doctorado con la Universidad de Lleida (Catalua,
Espaa). Durante este ltimo perodo reforc los
conceptos de acercamiento integral a la organizacin
en mi labor de consultora y he tenido el privilegio
de participar ampliamente en la formacin de postgrado (Diplomas y MBAs) que ofrecen instituciones como UV, IEDE, USM, UCH, UC y otras. Todo
esto qued registrado en nuevos ttulos: el libro Gestin de Procesos (2005), base a su vez de mi tesis de
doctorado realizada durante 4 aos y otros libros que
profundizan en temas de estrategia e inteligencia,
me refiero a: Empresas de xito (2005) y Responsabilidad Social (en versin preliminar).
Lo menciono porque los ltimos aos han sido intensos en interpretar las necesidades reales de las
empresas, ms todava con la creciente competitividad que existe y las nuevas siglas que surgen a velocidad insospechada: UML, RUP, OOA, OOD,

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

23

CMM, SCM, CRM, ERP, BI, ITIL, PMI, CASE,


TICs y muchas otras.
En fin, ha sido una bsqueda de las mejores prcticas que van quedando plasmadas en el mtodo GSP
y en libros como este que tiene en sus manos.
Le deseo una feliz y provechosa lectura.
JBC

JUAN BRAVO

24

PRLOGO A LA VERSIN 2009


Poco a poco comienza a tomarse conciencia de la necesidad de tener un proceso bien definido de gestin
de proyectos. Ya son muchos los avisos en la prensa
que solicitan profesionales competentes o asesora en
el proceso de gestin de proyectos. Este es uno de
los motivos para seguir trabajando en este texto. En el
fondo, es creciente la importancia de la gestin de
proyectos.
Algunos cambios relevantes en esta versin:
1. Se enriqueci lo que se refiere a evaluacin de
proyectos y fabricar el cambio.
2. Se incluyo tabla con las prcticas transversales
como ejemplo para cada proyecto.
3. Se incluyo flujograma de informacin de ejemplo
para formalizar los cambios menores.
Adems de muchos detalles de correccin y actualizacin. Un mensaje es ver este libro integrado en una
serie donde tambin estn los dos textos de procesos
y los de tecnologa que se pueden observar al final del
texto.
Mucho xito.
Juan Bravo

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

25

INTRODUCCIN
Un concepto de erizo [la estrategia de la compaa]
no es una meta de ser los mejores, ni es una estrategia
para ser los mejores, ni es la intencin o plan de ser los
mejores. Es entender en que puede uno ser mejor.
Jim Collins en Empresas que sobresalen (p. 155)

Las empresas pblicas y privadas de Chile pierden al


ao ms de 2.000 millones de dlares2 debido a fallas evitables en proyectos de gestin. En realidad
esa ineficiencia de una u otra forma la pagamos todos y con creces, porque tampoco disfrutamos del
beneficio del proyecto si hubiera sido bien hecho.

Es fcil estimar esta cifra con base en nuestro relacionamiento


(desde Evolucin, Centro de Estudios Avanzados) con ms de 1.000
empresas en Chile en los ltimos 20 aos. Se pueden plantear estas
cifras conservadoras:
Las 10 empresas mayores gastan en total 1.000 millones de dlares
al ao en proyectos de gestin (promedio 100 millones de dlares
cada una). Las 100 empresas mayores gastan en total 1.000 millones
de dlares al ao en proyectos de gestin (promedio 10 millones de
dlares cada una). Las 1.000 empresas mayores gastan en total
1.000 millones de dlares al ao en proyectos de gestin (promedio
1 milln de dlares cada una). Las 10.000 empresas mayores gastan
en total 1.000 millones de dlares al ao en proyectos de gestin
(promedio 100 mil dlares cada una). Las 100.000 empresas mayores gastan en total 1.000 millones de dlares al ao en proyectos de
gestin (promedio 10 mil dlares cada una).
En total US $ 5.000 millones, de los cuales se considera que el 40%
de los proyectos era preferible no haberlo hecho, es decir, US $
2.000 millones (y sera una cifra mucho mayor si agregramos el
costo de oportunidad). Otras estimaciones hablan de fallas hasta de
un 80%, las ms conservadoras le asignan un 50%.

26

JUAN BRAVO

Son fallas del tipo: a) el proyecto no responde a las


reales necesidades de los clientes y a veces ni siquiera de los usuarios internos, b) los costos o plazos
excedieron en mucho la estimacin, provocando
grandes trastornos, c) el proyecto est tan fuera de
foco que conviene cancelarlo pero nadie lo asume
porque en la compaa prevalece el criterio de buscar culpables, d) poca confiabilidad del producto, e)
grandes diferencias entre las facilidades del producto y lo que efectivamente se requera
Para que seguir, estas y muchas otras dificultades
son ampliamente sufridas a diario en proyectos de
todo tipo: tecnolgicos, de cambio organizacional,
de procesos, etc...
Es dramtico que son fallas fciles de
subsanar empleando algn mtodo para la
gestin de proyectos.
No es un tema nuevo en la gestin de proyectos tecnolgicos, ya en 1968 en la conferencia de la OTAN
en Alemania se plante adoptar un enfoque ingenieril en el desarrollo de software, con nfasis en
maximizar la calidad del producto de software y la
productividad del desarrollo de software, al mismo
tiempo, minimizar los riesgos del desarrollo y explotacin.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

27

Esto a raz de diversos estudios3 que daban cuenta


de la conocida Crisis del Software, algunas cifras:
La mayor parte de los sistemas
computacionales desarrollados y
entregados no se utilizan (47%)
Sistemas de software encargados y nunca entregados (29%)
Sistemas de software que solamente se pudieron
utilizar despus de grandes cambios (19%)
Esta realidad de los proyectos tecnolgicos no ha
sido tan diferente en el mbito de los procesos, donde se reportaban niveles de fallas graves en el 80%
de los proyectos de reingeniera.
La respuesta es trabajar con mtodo.

Objetivo del libro


El objetivo de este libro es ofrecer un mtodo para
abordar proyectos de procesos y tecnologa. No se
trata de detallar tcnicas, actitudes o conocimientos
especficos sino de sealar un trazo que sirva en la
gestacin, planificacin, direccin y buena ejecucin
de los proyectos.
La visin global, sistmica, es lo importante.

Solamente en Estados Unidos: estudios del departamento de Defensa, de la NASA y la Contralora. En general la bibliografa se
refiere a cifras similares.

28

JUAN BRAVO

Si el lector quiere profundizar en estos conceptos,


puede hacerlo revisando estos libros del mismo autor, referenciados dentro del texto:
Desarrollo de Sistemas de Informacin, una visin prctica
La Nueva Visin, Diseo y Construccin de Sistemas Computacionales
El Encanto de la Comunicacin
Planificacin Sistmica
Anlisis de Sistemas
Gestin de Procesos
Adicionalmente se presenta una amplia bibliografa
con otros autores.
El libro tiene como base el mtodo GSP4, originalmente llamado MG-DSI (Mtodo genrico de Desarrollo de Sistemas de Informacin) el cual es a su
vez una recopilacin de las mejores prcticas para la
realizacin de proyectos.
El mtodo GSP es una gua para abordar
en forma completa un proyecto. Es un
camino, no es el camino, porque en cada
etapa siempre habr variantes que pueden
aplicarse.
En la primera parte del contenido se explica ms
acerca del mtodo.

Recurdese que GSP significa Gestin Sistmica de Proyectos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

29

Visin estratgica de proyectos


Un proyecto materializa el cambio que surge de necesidades concretas en la sociedad y en las organizaciones
Los proyectos siempre sirven a un cliente, a quien se
quiere llegar con un nuevo producto, un tipo de
crdito, un proceso ms gil, una casa o un curso.
Todo proyecto sirve a la misin de la organizacin, lo
cual incluye alinear intereses. Veremos que el mtodo
llama a esto: estar de acuerdo con la estrategia de la
organizacin.
Claramente, el alcance de un proyecto es
mucho mayor que solamente incorporar
alguna forma de tecnologa o construir un
sistema computacional.
El proyecto incluye las acciones relacionadas con la
estrategia de la organizacin (principalmente alinear
la estrategia corporativa con la del proyecto), las personas (incluyendo cultura e infraestructura), el rediseo de los procesos, la estructura organizacional y la
tecnologa en general, incluyendo la tecnologa de
informacin. A ese conjunto le llamamos modelo
integral del cambio.
Es una propuesta integral.

JUAN BRAVO

30

El modelo integral del cambio


Son cinco factores de cambio representados en la
figura como una mesa que deben ser sistemticamente revisados, al interior y exterior de la organizacin, para lograr una buena solucin.
E strategia

P ersonas

T ecnologa

P rocesos

E structura

Modelo integral del cambio. Se puede representar como una mesa, donde la cubierta es la
estrategia y los pilares son las personas (incluyendo cultura e infraestructura), procesos,
estructura y tecnologa. El mensaje es armona
en estos medios para el cambio.

Orientacin al cliente
Desde el punto de vista de proyectos, todos en la organizacin deben estar orientados al cliente. Son los
usuarios, destinatarios, beneficiarios, pacientes, ciudadanos y otras denominaciones para representar a
alguien fuera de la organizacin y a quien servimos y
nos debemos (son las personas que pagan nuestro
sueldo, no el cliente interno, metfora que slo

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

31

agrega confusin cuando algunas personas creen que


es suficiente con realizar bien su funcin).
Tambin se le llama Visin de procesos, porque
siempre existe una doble responsabilidad, la funcin
individual y la totalidad de asegurarse que funcione el
proceso completo, del cual nuestra funcin es parte.
Cul es el cliente del rea de RRHH? El cliente.
En ambos casos y en muchos otros, es circunstancial
otorgar un servicio interno, lo ms importante es como ese servicio impactar en el cliente (la misin de
la organizacin).
Cul es el cliente del rea de
informtica? El Cliente.
Cul es el cliente para todos los funcionarios de un
ministerio? Los ciudadanos.

Inicio del proyecto


Aplicando el enfoque de proyectos, todo comienza
por conocer bien el problema (concepcin) y as
evitar crear soluciones slo para atacar el sntoma.
Se trata de conocer el problema de fondo y luego
buscar y evaluar soluciones en el ms amplio espectro posible, para evitar la dependencia de la nica
solucin (factibilidad).
Una vez seleccionada una solucin, el enfoque de
proyectos de negocios sigue por proponer un con-

32

JUAN BRAVO

cepto, una idea fuerza que luego se materializa en un


modelo integral del cambio (la mesa).
Aqu surgen los requerimientos globales del proyecto. Esta es la base de la ingeniera de requerimientos
orientados a toda la mesa.
Una de las patas de la mesa es la Gestin de procesos, esta es la que da origen a la definicin de requerimientos en las otras patas. Desde el rediseo de
procesos de compras, ventas, produccin o de cualquier otro tipo, surgen los requerimientos sobre las
personas, estructura organizacional, tecnologa y
sobre el mismo detalle de la pata procesos.
Otra de las patas de la mesa es la tecnologa de
informacin (suponiendo que el proyecto la contempla) y aqu ya se emplean tcnicas tales como UML,
modelamiento de datos, diseo de Interfaces y otras.

Desarrollo del proyecto


Disponiendo de los requerimientos planteados en el
anlisis, se profundiza en las etapas ms orientadas
al desarrollo computacional propiamente tal: diseo,
implementacin y despliegue, siempre dentro del
sistema de productividad que el mtodo propone,
donde se incluyen factores tales como: tcnicas,
herramientas de apoyo, hardware, incorporacin del
usuario, habilidad del desarrollador y normalizacin
externa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

33

Luego, junto con la operacin del sistema


computacional, llega la mejora continua
de todo el resultado del proyecto.
En la parte de ingeniera de software del sistema de
informacin, el mtodo considera los nuevos estndares: UML, Orientacin a Objetos, desarrollo en
espiral, uso de componentes reutilizables de software, herramientas CASE y amplia orientacin a la
calidad (en lnea con las propuestas de CMM, ISO
9000 y Tick IT).
Se orienta a profesionales de reas de informtica,
auditora, gestin de procesos y ejecutivos que requieren administrar proyectos de TI, entre otros.

El plan de proyecto
El aspecto ms representativo de la
gestin de proyectos es el plan de
proyecto, el cual, en realidad, es un
conjunto de planes.
Son planes que surgen de las definiciones globales
del mtodo, de las etapas del proyecto y de las
prcticas transversales.
Para efectos de la programacin de actividades, todo
converge en una carta Gantt (o en otra tcnica de
programacin de proyectos).
Para elaborar el plan de proyecto se requiere conocer
las polticas que se haya dado la organizacin, por

34

JUAN BRAVO

ejemplo, si se trabajar con desarrollo secuencial


(cascada) o iterativo (espiral).
Es aconsejable el uso de herramientas de apoyo
computacional para gestar y administrar proyectos.
Se requiere una malla de actividades que permita
visualizar el proyecto integral y resolver aspectos de
precedencia, holgura y ruta crtica.

Visin de conjunto del mtodo


El plan de proyecto es una integridad con contenidos
mucho ms all que la ruta crtica. En realidad contempla dos lneas de trabajo paralelas, como las vas
del ferrocarril:
Etapas del proyecto
Prcticas transversales
Tal como se aprecia en la siguiente figura:

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

35

E ta p a s d e l p ro ye c to
C oncepcin
F actibilidad
A nlisis

D iseo

Im plem entacin
D espliegueO peracin /
M ejora C ontinua

P rcticas tran sversales


D ireccin del proy ecto

Inform es

P lan de la etapa

T cnicas

E xposicin de los planes

H erram ientas d e apoy o

R etroalim entacin

T razabilidad

E l equipo de trabajo

Q uick W ins

E ntrevistas

... y las otras 16...

C om unicacin

Etapas del proyecto


Las etapas son las distinciones principales
del trabajo en el proyecto, son:
concepcin, factibilidad, anlisis, diseo,
implementacin, despliegue y operacin.
En la figura (como una punta de flecha) se aprecia el
esfuerzo promedio estimado de cada una y como a
partir de la etapa de diseo se expande el trabajo
incorporando la especializacin de otros actores.

JUAN BRAVO

36

E stu d io

D esarrollo

MC

Se aprecia tambin que las etapas estn agrupadas


en tres grandes fases:
Estudio: donde se detectan necesidades y se proponen soluciones, el entregable es un plan de
proyecto. Incluye las etapas de concepcin y factibilidad.
Desarrollo: donde se plan se materializa. Incluye
las etapas de anlisis, diseo, implementacin y
despliegue.
MC (Mejora Continua): donde la solucin ya en
operacin se mantiene y perfecciona. Contiene
solamente la etapa de operacin, la ms extensa.
Cada fase es realizada generalmente por equipos y
reas diferentes.
Aunque todo proyecto tiene las mismas
etapas, su alcance puede diferir segn las
condiciones particulares del proyecto.
Son siete etapas que veremos en detalle en la segunda parte de este texto, a continuacin los objetivos
de cada una:

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

37

1. Concepcin
El objetivo es concebir un problema, el cual puede
tomar diferentes formas: una necesidad, una oportunidad o una dificultad especfica, entre otras. Se entrega en la forma de un enunciado validado, cuantificado y su contexto.
2. Factibilidad
El objetivo es obtener el plan de proyecto de la solucin despus de un barrido creativo de muchas soluciones y de un estudio comparativo de algunas de
ellas.
3. Anlisis
El objetivo es plantear el modelo integral del cambio
de la solucin (estrategia, personas, procesos, estructura y tecnologa) y los requerimientos correspondientes. El qu.
4. Diseo
El objetivo es obtener la ingeniera de detalle de la
solucin completa que propone el modelo integral
del cambio. El cmo.
Comienza la parte ancha de la flecha porque se incorpora con mayor fuerza el aporte de los especialistas en cada parte del modelo integral del cambio.

JUAN BRAVO

38

5. Implementacin
El objetivo es llevar a la prctica la solucin completa que propone la solucin, armonizando todas
sus partes.
Contina con el aporte de los especialistas en la implementacin de cada parte del modelo integral del
cambio.
Se concluye en una aplicacin real aunque
en carcter piloto.
6. Despliegue
El objetivo es replicar o expandir la solucin generada hasta ser bien utilizada por todos los usuarios
previstos en el plan de proyecto.
7. Operacin
El objetivo de esta etapa es mantener la solucin en
buen funcionamiento hasta que cumpla con su vida
til o sea reemplazada por otra solucin. La mejora
continua es una actividad central.
Concluye un ciclo de operacin con el inicio de un
rediseo programado de la solucin.

Prcticas transversales
El plan de proyecto contempla prcticas transversales
que tienen mayor o menor impacto en cada etapa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

39

Las acciones a que den lugar deben quedar detalladas


en el plan particular para el proyecto.
Se puede ver las etapas como pilares y las
prcticas de administracin como lneas
horizontales que cruzan cada etapa,
impactando en mayor o menor medida a
cada una.
Son prcticas que deberan estar contempladas tanto
en el plan de proyecto global como en el detalle de
cada etapa. Por supuesto, con diferente alcance
segn cada proyecto.
Las principales prcticas transversales consideradas
son 28 y han surgido del estudio de las mejores
prcticas de los proyectos.
1. Direccin del proyecto
2. Plan de la etapa
3. Exposicin de los planes
4. Retroalimentacin
5. El equipo de trabajo
6. Entrevistas
7. Comunicacin
8. Informes
9. Tcnicas
10. Herramientas de apoyo
11. Trazabilidad
12. Quick Wins
13. Costos y duracin
14. Gestin de riesgos
15. Gestin de la calidad

40

JUAN BRAVO

16. Responsabilidad social


17. Insercin
18. Orientacin al cliente
19. Sensibilizacin
20. Capacitacin
21. Seguimiento
22. Cuidar la solucin anterior
23. Continuidad operacional
24. Plan de recursos fsicos del proyecto
25. Kill time
26. Control de cambios
27. Gestin del cambio
28. Gestin de proveedores
En la tercera parte del libro se puede ver el detalle
de cada una de ellas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

PRIMERA PARTE.
MTODO

41

42

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

43

Sin importar el tipo de empresa, el analista trabaja en


problemas comerciales. Sera un error distinguir entre
problemas del negocio en s y de sistemas; o dicho de
otra forma, no existen problemas de sistemas que no
hayan sido primero del negocio.
James A. Senn

44

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

45

INTRODUCCIN
En la Edad Media, la incorporacin a un oficio, hacer
zapatos o construir catedrales, era una iniciacin en
un gremio muy cerrado. El arte o secreto del oficio
se transmita de maestros a principiantes a travs de la
revelacin de los misterios.
De la misma forma comenz el desarrollo de proyectos de procesos y tecnologa, con iniciados que conocan los secretos del arte y que parecan estar juramentados para no revelarlo. Sin embargo, no ha sido
necesario que transcurrieran 400 aos para que ese
arte se transformara en tecnologa, tal como ocurri
con la mayora de los oficios de la Edad Media.
En la gestin de procesos y tecnologa han bastado
slo 40 aos para que la situacin cambiara drsticamente.
Hoy sabemos cmo hacer gestin de
procesos y construir software de calidad y
ese conocimiento est al alcance de todos.

Qu es mtodo?
Antes de continuar, es importante aclarar que se entiende por mtodo Claramente es una competencia
bsica para todo profesional que se puede
enunciar as:
Gua su trabajo del da a da de acuerdo con normas
y procedimientos definidos, logra visualizar el inicio

46

JUAN BRAVO

y el fin de los procesos en que participa y aplica que


tan importante es su funcin especfica dentro del
proceso como el cumplimiento de todo el proceso.
Trabaja en equipo con todos los dems partcipes del
proceso.
Las prcticas que se adquieren en la competencia
mtodo se pueden ver como un continuo que comienza desde la toma de conciencia de cmo lo
hacemos (ya sea un proceso operativo o un proyecto) hasta aplicar mejora continua, mejores prcticas,
rediseo e innovacin sobre esa secuencia.
Trabajar metodolgicamente aplica para
todo tipo de procesos del negocio, de
apoyo y estratgicos y proyectos de
cambio organizacional.
Se pueden enunciar mediante esta secuencia (utilizada en procesos de Gestin por Competencias):
Aprendiendo: Toma conciencia de cmo
hacemos el trabajo y lo describe, se interesa en
conocer los procesos completos en que participa
y quien es el cliente, domina tcnicas bsicas de
gestin de procesos y de proyectos, cuantifica el
problema y el costo de oportunidad.
Entendiendo: Conoce el objetivo del proceso y
propone mejoras para eficientarlo, aplica herramientas para el desarrollo y seguimiento de procesos y proyectos, una Carta Gantt. Trabaja bien
en equipo, motiva para el cambio y negocia para
evitar las resistencias. Cuantifica las soluciones.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

47

Aplicando: compara el mtodo con otros similares dentro y fuera de su organizacin, emplea
tcnicas de benchmarking y de la cadena de valor
de Porter, elabora planes de proyecto para el
cambio, es coherente (cambio personal y organizacional a la vez), aplica gradualidad y sabe calcular un VAN (Valor Actual Neto).
Guiando: Propone cambios radicales de acuerdo
con la estrategia de la organizacin, aplica tcnicas de idealizacin para aumentar la competitividad, usa tcnicas de Visin sistmica y mtodo
completo de proyectos.
En el nivel guiando, tambin emplea
herramientas de gestin del conocimiento,
gestin de riesgos, trazabilidad y control
de cambios. Motiva, lidera y retroalimenta
a los dems en sus propios procesos de
cambio.
Refirindose a la buena gestin de proyectos, Campero y Alarcn sealan en su libro Administracin
de Proyectos Civiles (pginas 2 y 3): Los buenos
resultados de una administracin sern el producto
de condiciones personales de los responsables y de
las tcnicas de administracin que empleen cumplir con las metas programadas de costo y plazo no
resulta fcil y existe una alta posibilidad de arriesgar
los beneficios y costos esperados. Un estudio realizado por Thompson y Perry usando un gran nmero
de proyectos del Banco Mundial , indica que, de

48

JUAN BRAVO

1.778 proyectos revisados, en el 63% de los casos el


costo final super el presupuesto, de 1.627 proyectos
revisados, el 88% termin con atraso; y de 42 proyectos controlados, el 70% de ellos no alcanz al
tasa interna de retorno (TIR) esperada.

Las mejores prcticas


El Mtodo propuesto surge de revisar y practicar
sistemticamente las propuestas de lenguajes, normas de calidad y herramientas que el mercado ofrece, aprendiendo de tales opciones e incorporando en
este mtodo lo que se considera realmente aplicable
en las empresas de Chile y Latinoamrica, considerando nuestra idiosincrasia, niveles de conocimiento
y avance en tecnologa de informacin.
Es un mtodo genrico porque la idea es
conocer y seleccionar del medio las
mejores tcnicas5 (causa-efecto,
creatividad, mapa de procesos,
Flujograma de informacin , UML, ITIL,
PMI, orientacin a objetos, modelo
integral del cambio, etc.) avanzando hacia
las estandarizaciones formales o de
facto en nuestro medio.

Las tcnicas que no estn desarrolladas en el texto se explican en


anexos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

49

Fundamento conceptual: la visin sistmica


La visin de proyectos de negocios del mtodo propuesto en estas pginas ofrece una visin integradora, actualizada y prctica de todas las etapas incluidas de su ciclo de vida.
Tiene su base conceptual en la visin sistmica,
tambin conocida como pensamiento sistmico,
aceptacin del caos y de la complejidad, visin area, etc. (ver libro Anlisis de Sistemas)

Mtodo GSP
Conocido inicialmente como Mtodo Genrico de
Desarrollo de Sistemas de Informacin (MG-DSI,
ao 2000), el Mtodo GSP es una base de conocimientos que ofrece una gua para el desarrollo completo de un proyecto, pasando por todas las etapas
de su ciclo de vida: concepcin, factibilidad, anlisis, diseo, implementacin, despliegue y operacin.
Es un mtodo abierto, con etapas genricas, amplio
uso de tcnicas del medio y apoyo de herramientas
existentes.
El Mtodo GSP tiene por objetivo ofrecer
una visin integradora, actualizada y
prctica de todas las actividades incluidas
en el ciclo de vida de un proyecto.
El mtodo GSP tiene su base en los libros del autor
de este texto (ver bibliografa). Tambin el mtodo
se funda en las experiencias directas o de consultora

50

JUAN BRAVO

de desarrollo de sistemas de informacin del autor y


de gran cantidad de profesionales, a quienes se les
agradece en los respectivos textos. Otra influencia
viene desde los cientos de desarrollos guiados, normalmente reales, con participantes de los programas
de postgrado en Anlisis y Diseo de Sistemas en la
Universidad Tcnica Federico Santa Mara, Universidad de Chile, Universidad de Valparaso y Escuela
de Negocios IEDE Chile, entre otros, ofrecidos por
el suscrito con la cooperacin de destacados profesionales sealados en los agradecimientos.
El mtodo se ha perfeccionado con el
tiempo desde la propuesta del primer libro
(Desarrollo de Sistemas de Informacin,
una visin prctica, 1988) y actualmente
considera orientacin a objetos, modelos
de UML, fichas para estudio de proyectos
y recomienda el uso de herramientas en
cada etapa. Tambin considera aportes de
normas de calidad tales como ISO 9000,
CMM y Tick IT. Adems de Tcnicas de
auditora, tal como COBIT.
Cmo mtodo completo, la primera versin data del
ao 2000.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

51

CLAVES DE LA IMPLANTACIN DE
MTODO
Son claves que guan el trabajo en la implantacin
de mtodo en una organizacin. Previo, es necesario
sincerar hasta dnde la organizacin trabaja en forma mtodolgica.
Mtodo no es algo que solamente se compre y aplique, como una mquina, tampoco se puede internalizar mediante pastillas (ni disponemos todava de la
tecnologa de Matrix, aquella donde Neo aprenda
rpidamente mediante un tubo conectado directamente al cerebro).
Mtodo tiene que ver con el desarrollo de
competencias de las personas, con un
trabajo arduo de generar estndares
internos y externos.
Hemos detectado 4 claves, son recursivas, es decir,
tambin aplican para los proyectos que utilizarn el
mtodo en la organizacin.
Clave 1. Visin de conjunto
Clave 2. Mnimo indispensable
Clave 3. Participacin de todos los actores
Clave 4. Circularidad

Clave 1. Visin de conjunto


La visin sistmica es vital, se materializa, por
ejemplo, en los planes y en un conjunto de mapas:

52

JUAN BRAVO

Mapa de Necesidades
Mapa de Proyectos
Mapa de Procesos
Mapa de Eventos se refiere a llevar registros de
retroalimentacin del trmino de los proyectos y
de sucesos que es bueno conocer.
Mapa de Sistemas computacionales existentes.
Mapa de elementos de la instalacin (EI): hardware, software.
Mapa de Clases, vlido cuando hay desarrollo
interno.
Por supuesto, cada mapa tiene los atributos de cada
componente y su propia base de datos.
En todos los casos, los mapas deben estar disponibles para la organizacin utilizando las herramientas
apropiadas. Independiente del registro de cambios
de cada modelo, es vital una versin actualizada de
cada uno de ellos.
Estos mapas deberan crearse como parte de la implantacin del mtodo.
Otra forma en que se materializa la visin
de conjunto es apreciando la cultura y
nivel de avance de la organizacin en la
aplicacin de formalidades y construir
desde ah.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

53

Clave 2. Mnimo indispensable


Se trata de negociar el alcance de la implantacin
del mtodo bajo el criterio del mnimo indispensable, es decir, el mnimo que todos los interesados se
comprometen a cumplir, no por imposicin, sino por
reflexin o toma de conciencia. Aplica aqu la tcnica de W. Pareto, su ley de los pocos crticos y muchos triviales
No se refiere exactamente a la interpretacin de Juran del 80-20 con el 20% del esfuerzo se logra el
80% de avance sino que a una negociacin respecto a lo se considere mnimo para la organizacin
particular.
El mnimo indispensable significa un
mtodo flexible y preciso, bien adaptado a
la realidad de la organizacin y de cada
proyecto particular, porque su orientacin
es simplicidad, flexibilidad y
aplicabilidad, para que realmente sea
utilizado en las organizaciones
latinoamericanas.
Es importante considerar que este mnimo indispensables estar influido por la cultura de la organizacin en cuanto a disciplina y sensibilidad a la estandarizacin. Por ejemplo, en una organizacin certificada en normas de calidad, es probable que sea ms
amplia y fluida la implantacin de mtodo debido a
que ya estn sensibilizados en normas, procedimientos y calidad.

54

JUAN BRAVO

Clave 3. Participacin de todos los actores


La implantacin de mtodo es una tarea de todos, el
mtodo no puede ser propiedad de una parte de la
organizacin, pertenece a toda ella, independiente
que alguien lo administre.
Lo primero es identificar los actores, por ejemplo:
El cliente es el cliente. Est fuera de la organizacin, es quien paga los sueldos de todos en la organizacin y a quin en definitiva sirven los proyectos. Es necesario validar cada proyecto a la
luz de sus Intereses actuales o potenciales.
El usuario es quin hace uso de los sistemas para
servir a los clientes. Se pueden identificar usuarios ejecutivos y usuarios operativos.
Analistas o profesionales de proyectos forman el
equipo de trabajo: gerente de proyecto, especialistas en procesos y tecnologa, adems de consultores.
La alta direccin, gerencia o simplemente autoridad se encarga de la toma de decisiones respecto
al proyecto.
Luego definir los roles de cada uno en relacin al
mtodo y la forma en que se abordar su incorporacin, habitualmente es una combinacin de sensibilizacin, capacitacin y coaching.
Es interesante observar que solamente
difundir el mtodo es un proyecto en s
mismo donde aplica todo lo indicado en
este texto.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

55

Clave 4. Circularidad
La implantacin de mtodo puede seguir la forma de
desarrollo en espiral presentada en el anexo 5. As,
en un par de meses la organizacin ya podra estar
aplicando algo de mtodo y disfrutando de los beneficios de proyectos mejor realizados.
Con el desarrollo en cascada la
implantacin puede ser muy larga, dos
aos? Demasiado!, podra decir el
gerente.
La gradualidad es el concepto de fondo, es decir,
implantar en base a avances sucesivos, a partir de
negociaciones respecto a lo que realmente las personas quieren y pueden hacer. Justamente una de las
ideas centrales de este mtodo es el buen manejo del
cambio, donde se plantea que un sistema en buen
funcionamiento es una joya que debe tratarse con
mucho cario, asegurndonos que lo nuevo es efectivamente mejor, sin el encandilamiento transitorio
que tanto dao provoca.

56

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

57

CARACTERSTICAS DEL MTODO


El mtodo descrito en estas pginas para la buena
gestin de proyectos de procesos y tecnologa tiene
muchos elementos y una complejidad que no puede
ser reducida artificialmente, porque corremos el
riesgo de simplificar demasiado.
De todas formas, destacan estas siete caractersticas:

1. Adhesin a estndares y normas de calidad


Adems de cumplir con la normativa interna y externa obligatoria, el mtodo GSP se orienta a trabajar con estndares formales o de facto, tales como:
MP (Mapa de Procesos) y FI (Flujograma de Informacin), OO (Orientacin a Objetos), UML, CMM,
ISO 9000, ITIL, PMI y otros que veremos en el texto (las siglas indicadas se pueden ver en los anexos).
El mtodo es abierto y permite trabajar
con esos y otros estndares. Es ms,
veremos que aprende de ellos, los
incluye y se potencia.

2. Actualizacin
Un elemento conceptual importante es planificar al
comienzo y luego continuar planificando durante
todo el proyecto, por la imperiosa necesidad de mantener actualizadas las definiciones, porque si slo

58

JUAN BRAVO

existe el plan inicial, rpidamente pierde sentido por


la dinmica de la realidad.
Tenemos que aprender a elaborar buenos planes y
mantenerlos actualizados, considerar los riesgos,
prevenir y confeccionar planes de contingencia.
Es bueno tener presente la conocida
afirmacin de Murphy: si algo puede
fallar, fallar.

4. Informacin de calidad
En el enfoque de proyectos se reconoce la importancia de la informacin, y sus atributos: oportuna, confiable, creble y de calidad.
El ideal es que todo el manejo de la informacin sea
en lnea, es decir, en tiempo real y que los datos sean
capturados en la punta del proceso, evitando redigitaciones. Adems, trabajar todo lo posible en formato
digital. Una buena idea es un programa del tipo Paperless que estn impulsando muchas organizaciones,
se trata de fomentar trabajar sin papeles.
Informacin de calidad significa, entre otras caractersticas adems de las ya indicadas: exactitud, totalidad, relevancia, consistencia y detalle (la profundidad necesaria).
Hablamos aqu de informacin en lugar de datos porque ya existe un nivel de procesamiento para lograr
los atributos indicados.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

59

3. Pragmatismo
Pragmatismo es hacer lo mejor que se pueda hacer
para lograr los objetivos de un proyecto, es lo opuesto al fundamentalismo, ms bien sera el complemento como en el Yin y Yang (la armona de los
opuestos, lo femenino y masculino, etc.).
No es sinnimo de improvisacin ni significa liviandad en la disciplina para seguir un mtodo.
Es darse cuenta que en un momento del
tiempo hay una bifurcacin mejor a la
establecida.
Por ejemplo, en cada etapa se puede volver a una
anterior para efectuar cambios o cancelar el proyecto. No hay problema en la medida que sea por adaptacin a nuevas circunstancias. Hay problema cuando el motivo es porque la etapa anterior no se hizo
correctamente.
A propsito, Jeff Davidson, en su libro La Gestin
de Proyectos, ofrece siete sugerencias para triunfar
en la gestin de proyectos (pginas 21 a 23):
Aprender a utilizar eficazmente las herramientas
de gestin
Saber hacer y recibir crticas
Ser receptivo a los nuevos procedimientos
Gestionar adecuadamente el tiempo
Ser eficaz al organizar reuniones
Perfeccionar la capacidad de tomar decisiones
Conservar el sentido del humor

60

JUAN BRAVO

5. Curso normal de los Eventos y SPPP


Es un nuevo criterio de la teora de modelos y es
central en la nueva generacin de tcnicas visuales.
La idea general es tratar las excepciones
como excepciones, sin darles el mismo
espacio visual que el curso normal de los
eventos, en esto debe existir armona con
la realidad, donde lo ms habitual
aparece ms y lo menos, menos.
Se aplica especialmente en flujogramas de informacin y casos de uso expandido.
Las excepciones se definen aqu como situaciones
indeseables que perturban el flujo, van como texto
fuera del modelo cuando son relevantes.
El SPPP (Simplificar Procesos y Potenciar Personas)
deja completamente de lado la antigua, peyorativa e
intil pretensin de construir sistemas a prueba de
tontos.

6. Adaptacin a proyectos especficos


La idea es adaptar el mtodo a cada proyecto particular, donde se considera que lo esencial es no saltarse ninguna etapa. Aunque s es factible negociar
las actividades que incluira y el alcance de las
prcticas transversales.
Esa es la idea de la siguiente figura, donde el mtodo de la organizacin es una base de conocimiento

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

61

que se adapta a cada proyecto particular, aunque


mantiene un tronco comn.
M todo de la
O rganizacin

A daptacin

A plicacin a
un proyecto

Las claves de la implantacin de mtodo del captulo


anterior tambin son vlidas para aplicar el mtodo a
cada proyecto particular dentro de la organizacin.
El mtodo se puede aplicar en todos los proyectos,
aunque es necesario hacer ajustes segn su tamao.
El tamao del proyecto
Trabajaremos con estas distinciones (en conocimiento que la complejidad del mundo producir excepciones y que los lmites entre tramos son difusos):
Proyecto pequeo: hasta US$ 100.000
Proyecto mediano: ms de US $ 100.000 y
hasta US$ 1.000.000
Proyecto grande: ms de US$ 1.000.000

62

JUAN BRAVO

El mtodo debe adaptarse a cada realidad porque no


es lo mismo un proyecto pequeo que uno grande.
Tambin influyen otros factores, tales como el avance previo y la prioridad, que puede llevar a tener una
especie de Fast Track en el caso de proyectos prioritarios por alguna contingencia o por necesidades
estratgicas.

7. Pasin por conocer la finalidad, el para qu


Todos los actores del proyecto deben tener claridad
en objetivos, resultados y propsito alineado.
Ms all de los entregables por etapa, es
vital definir y conocer lo que se quiere
lograr, los objetivos finales. Tener la vista
puesta en el destino ayudar a darles un
sentido a todas las actividades del
proyecto.
Davidson aconseja (pgina 33): Al tener una idea
clara del final deseado todas las decisiones que se
tomen respecto al proyecto irn en el mismo sentido
con ms probabilidad de lograr el final deseado.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

63

ESTRUCTURA PARA LA GPPT


La buena gestin de proyectos de procesos y tecnologa tambin tiene que ver con una serie de instancias de estructura organizacional o funciones.
Esto es lo se denomina incorporar a la organizacin, es decir, llevar al cuerpo, a la estructura.
Algunas de estas instancias son:

rea de metodologa o UTP


En el rea de metodologa laboran los depositarios
del mtodo, quienes lo actualizarn, difundirn y
tendrn la responsabilidad por los mapas de apoyo.
Puede tener adems la forma de una UTP (Unidad
Tcnica de proyectos) que se asegure de la formalidad metodolgica de cada proyecto, es decir, se incorpora aqu una labor ms bien operativa.
Eventualmente las rea de metodologa y
de UTP pueden ser reas diferentes y que
trabajan coordinadamente.

rea de estudios
Un rea de estudios equivale a un rea de estudios
de propuestas. La diferencia es que el rea de estudios se dedica a procesar propuestas internas para
necesidades y soluciones.

64

JUAN BRAVO

Es un rea que ayuda a generar mucha rentabilidad a


la empresa, porque deja en evidencia la gran cantidad de proyectos que se pueden realizar.

Comit de Proyectos
Considerando que la tecnologa sirve a procesos estratgicos, del negocio y de apoyo en la organizacin, la figura del Comit de Informtica ha ido
cambiando hacia un comit de proyectos que unifique procesos y tecnologa con una mirada sistmica
que abarca toda la organizacin, comenzando por
aplicar las definiciones estratgicas.
El comit de proyectos gua el Proceso de
Deteccin de Necesidades y Formulacin
de Proyectos (etapas de concepcin y
factibilidad del mtodo) administra el
mapa de necesidades en conjunto con el
rea de metodologa (tambin el resto de
los mapas).
Tambin recibe la retroalimentacin de los proyectos en desarrollo.
Por supuesto, el comit de proyectos requiere una
frmula simple para administrar los compromisos
vigentes e histricos., as como definir la forma de
toma de decisiones en casos de emergencia.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

65

Cierre del Proyecto


Al finalizar el proyecto, se cierra la carpeta del proyecto en el comit de proyectos con un informe que
seale como fueron resueltas las necesidades originales (y actualizadas) y como se comportaron el plazo, costo y otras variables respecto al plan.
Se requiere la firma de todos los actores (dueo del
proceso, jefe del proyecto, etc...)
Esto es independiente de los entregables por cada
etapa cuya aprobacin depende de la estructura que
el mismo comit de proyectos aprob.

rea de gestin TI
El objetivo es aportar con algunas orientaciones a la
mejor organizacin de la gestin TI:
Lo ms fundamental: tener la visin
puesta en el cliente (implica escuchar
sistemticamente) y alinear todas las
decisiones TI con la misin de la
organizacin.
Dependencia de una Gerencia de Desarrollo o de
una Direccin de Sistemas de Informacin que
tiene en sus manos los principales elementos de
cambio en la organizacin.
Gestin interna de elementos:: versiones, inventario de productos TI, cambios, planes de contingencia, etc...

JUAN BRAVO

66

Estrategia TI alineada con la estrategia corporativa. La visin de negocios es central en la estrategia (el cliente de informtica es el cliente).
Tener alguna forma de aseguramiento de calidad.
Trazabilidad en el desarrollo de los proyectos:
significa que es posible hacer el seguimiento de
un requerimiento desde su gestacin hasta la
puesta en marcha
Contar con un mtodo de desarrollo completo.
Polticas en TI
Se trata de directrices que toda la organizacin se
compromete a cumplir, por ejemplo:
Estndares con los que se trabajar (XML,
UML, etc...)
Artefactos mnimos del diseo de las aplicaciones (modelo conceptual, diseo de clases,
etc...)
Interfaces visuales estndares (pantallas, informes, etc.)
Control de calidad de aplicaciones
Privilegios y responsabilidades en cuanto
a la tecnologa de informacin
Requerimientos que puede solucionar el
mismo usuario
Aspectos metodolgicos de anlisis e implementacin de aplicaciones
Delegacin y trabajo en equipo

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

67

Por qu las polticas?


Las polticas se consideran centrales para el mejor
funcionamiento de la empresa porque ayudan a tener
mejor comunicacin interna y externa en las rea de
informtica y de proyectos.
Las polticas ayudan a establecer una
relacin ms formal para la toma de
decisiones en el da a da de la TI.

Arquitecto de Datos
Se trata de una funcin de la organizacin ms que
de un cargo en particular (en organizaciones ms
pequeas es uno o un conjunto de cargos).
Componente tcnica
En el responsable del modelo de datos corporativo.
Esto significa que su preparacin en Modelamiento
de datos es de primer nivel. El opina a nivel del diseo de datos de cada aplicacin y mantiene el modelo conceptual de la organizacin.
Es responsable tambin del diseo fsico de la base
de datos y por tanto filtra el modelo de datos de
cualquier nueva aplicacin. Soluciona redundancias
e incorpora al modelo fsico corporativo lo relevante
para toda la organizacin (pueden existir aplicaciones locales que no dependen de l).

68

JUAN BRAVO

Aplica tcnicas y herramientas para mantener la


consistencia y eficiencia de las bases de datos. Opina acerca del esquema de seguridad de datos de cada
aplicacin.
En todo caso de agregar tablas hace un
estudio de cmo impactan en el modelo
corporativo y recomienda adaptaciones.
Interacta con el DBA (Data Base Administrador).
Componente de negocios
Desde el punto de vista de registrar a que procesos
sirven los datos.
Hoy con la ayuda de herramientas de modelamiento
corporativo es posible unir ambos temas porque todos los modelos estn centralizados. Por ejemplo:
WBM (Websphere Business Modeler), de IBM (deriv desde el M1), Corporate Modeler de CASE y
ARIS, de SAP.
Tambin esto se logra con herramientas ms sencillas tal como Erwin, System Architect, Visio y muchas otras.
Beneficios de contar con la funcin de arquitecto de
datos (puede ser ms de una persona):
Permite que la organizacin conozca el modelo
de datos de cada aplicacin. Aunque la aplicacin sea externa se debe indicar con precisin la
estructura fsica de los datos que la sustenta.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

69

Permite tener una visin de conjunto de los datos


y un verdadero modelo corporativo. Esto ayudar
a solucionar requerimientos rpidos que pueden
realizar los mismos usuarios cuando no haya
creacin de tablas y se puede apoyar el desarrollo
de aplicaciones ms eficientes y efectivas.
Permite ms seguridad e integridad de los datos.
Con este conocimiento se puede apoyar de mejor
forma la estrategia tecnolgica.

70

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

SEGUNDA PARTE.
ETAPAS DEL
PROYECTO

71

72

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

73

Todo el mundo conoce la historia de los hijos del zapatero: el zapatero est tan ocupado haciendo zapatos
para otros que sus hijos van descalzos. Durante los
ltimos 20 aos, muchos ingenieros de software han
sido los hijos del zapatero. Aunque estos profesionales han construido sistemas complejos que automatizan
el trabajo de otros, ellos mismos no han aplicado estas
tcnicas.
Roger S. Pressman

74

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

75

INTRODUCCIN
Cada etapa consta de actividades: algunas son propias de la etapa y otras provienen de las prcticas
transversales. En todos los casos han surgido de observar las mejores prcticas del medio.
Veremos que cada etapa tiene entradas y salidas.
Lo ms fundamental en todo proyecto es
no saltarse ninguna etapa. La negociacin
que debera hacerse es respecto al alcance
de la etapa dada la envergadura del
proyecto y otros factores.
Al iniciar cada etapa una actividad comn es actualizar el trabajo de las etapas anteriores, especialmente cuando ha pasado tiempo entre etapa y etapa. Este
concepto de actualizacin permanente est recogido
tambin en las prcticas transversales.
Sucede a veces que una etapa realiza con desfase
respecto a la anterior y el simple paso del tiempo
dice que algo pudo haber cambiado.

Cuantificar todo
Un aspecto central del mtodo GPPT es cuantificar:
El problema y las soluciones
Costos reales y ocultos
Beneficios directos y costos de oportunidad

76

JUAN BRAVO

Carlos Toloza, Director del Programa Competitor


para la Rentabilidad de Proyectos Informticos, en
un artculo para el Diario Financiero (2005, pgina
54), plantea: Una inversin informtica concebida
correctamente es evaluada en trminos de beneficios
econmicos concretos y genera rentabilidad para la
empresa. Esta es la nica forma de aprovechar la
informtica para mejorar la competitividad del negocio. En el momento de definir los beneficios
econmicos del proyecto, a veces se comete el error
de pensar en beneficios intangibles y elementos
difciles de medir. La verdad es que si los fros
nmeros no dan, no se justifica invertir.
Lo mismo es vlido para rentabilidad social de proyectos, ya sea en reparticiones del Estado u organizaciones de la sociedad civil. Todo debe ser cuantificado, es el mensaje, porque es la manera de discriminar en el impacto y buscar el mximo valor
agregado. Por ejemplo, cunto cuesta que un nio
no aprenda? o cunto gana la sociedad con una
educacin bien lograda?

Fase de estudios
Aqu estn las etapas de Concepcin y factibilidad,
ambas forman lo que podramos llamar fase de estudio de proyectos.
Es vital la prudencia, saber cundo
avanzar y cuando retroceder, practicar un

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

77

poco de lobby e ir logrando consenso


respecto a la forma del proyecto.
Ya sea para abordar la necesidad o para comenzar a
esbozar proyectos son vitales las habilidades de comunicacin y de negociacin, por ejemplo, para:
Formar alianzas
Presentar el caso de negocios en diversos niveles
de avance (borradores sucesivos cada vez ms
afinados)
Recopilar el mximo de informacin disponible
y cuantificar todo.
Aclarar objetivos del proyecto
Identificar a todos los actores, precisar sus intereses y alinearlos.
Aplicar o definir estndares de gestin y determinar como se cumplen.
Presentar en variadas instancias: direccin de la
empresa, usuarios, sindicatos, etc.

Proceso Fabricar el cambio


Durante esta fase se establece un Proceso formal de
Deteccin de Necesidades y Formulacin de Proyectos dirigido por el comit de proyectos u otra instancia que represente el inters global de la organizacin.
El objetivo es implementar un proceso para generar
nuevos proyectos, desde la deteccin de una necesidad hasta la definicin del proyecto.

JUAN BRAVO

78

Este proceso es necesario porque la forma en que los


proyectos surgen en la organizacin debe seguir
normas estndares, evitando as que surjan desde
reas o personas con objetivos locales o en forma
tan improvisada que se pierda la visin de conjunto.
Todo integrante de la organizacin puede detectar
necesidades (con algunas horas de capacitacin).
Luego, para profundizar en la misma necesidad e
iniciar el estudio de soluciones se requiere de profesionales dedicados y con una preparacin adecuada
en gestin de proyectos.
No hay problema que sean profesionales
destinados transitoriamente al rea de
estudios desde otras reas, lo importante
es que tenga las competencias necesarias.
Veremos brevemente las tres fichas que se utilizan
en este proceso de fabricar el cambio, ms el cierre
del proyecto.
Ficha 1: Deteccin de la Necesidad (oportunidad o

F ich a 1: D eteccin d e la N ecesid ad


N de la necesidad
Q uin detecta
N ecesidad
C osto estim ado

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

79

problema).
El objetivo del formulario es ayudar al Comit de
Procesos y Tecnologa a decidir si corresponde o no
estudiar con mayor detalle una deteccin de necesidad.
Todo integrante de la organizacin puede llenar este
formulario (con la capacitacin correspondiente) el
cual sera presentado por el encargado de rea correspondiente.
Si se aprueba lo planteado en esta ficha se solicitar
el desarrollo de la Ficha de Evaluacin Comparativa
de Soluciones, por lo que al final de este formulario
se deber consignar por parte del Comit la decisin,
la prioridad asignada y el evaluador designado para
completar el segundo formulario.

Ficha 2: Evaluacin comparativa de soluciones


El objetivo del formulario es ayudar al comit de
tecnologa a decidir si las soluciones satisfacen o no
la necesidad detectada. Si es as, se selecciona alguna de ellas o una combinacin de ellas con todas las
observaciones necesarias.
El Comit puede solicitar replantear el estudio o encargar al mismo u otro evaluador la confeccin de la
Ficha Plan de Proyecto.

80

JUAN BRAVO

Pueden presentar este formulario los evaluadores


designados para ello por el comit de proyectos.

F ich a 2: E stu d io C om p arativo


N de la necesidad
Q uin estudia
S ituacin actual de la necesidad
D etalle de cada solucin propuesta
E studio C om parativo
R ecom endacin

Ficha 3: Plan de Proyecto


Contiene todos los detalles necesarios para una buena ejecucin del proyecto.
Se presenta al comit de proyectos para su aprobacin e inicio, asignando las personas y recursos correspondientes.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

81

De acuerdo con lo indicado en el mismo plan y las


polticas de la organizacin al respecto, se define el
seguimiento del proyecto.

F ich a 3: P lan d e P royecto


N de la necesidad
Q uin estudia
S ituacin actual de la necesidad
E xplicacin de la solucin
A porte estratgico y V A N
R evisin de cada etapa
R evisin de cada prctica transversal
(desde las polticas)
C arta G antt y planes detallados

Cierre del Proyecto


Se trata de un informe de cierre al momento de concluir sealando como fueron resueltas las necesidades originales (y actualizadas) detectadas.

82

JUAN BRAVO

Se requiere la firma de todos los actores (dueo del


proceso, jefe del proyecto, etc...)

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

83

ETAPA 1. CONCEPCIN
Lo que da origen al trabajo en la etapa es un sntoma
o una serie de sntomas que producen molestias
(prdidas, atrasos, molestias de clientes, costos excedidos y mucho ms).
Decimos que es una confusin porque no sabemos
realmente cul es el problema de fondo.
El objetivo de la etapa de concepcin es concebir
una necesidad, o un problema que pertenece a una
persona o rea que lo reconoce como tal.
La necesidad puede tomar formas tales como una
oportunidad o una dificultad.
Entregable de la etapa: una necesidad validada,
cuantificada y en su contexto.
~~
Se da inicio a esta etapa porque hay algo que se
quiere solucionar o una meta que se desea alcanzar,
hablamos genricamente de Problema, puesto entre comillas porque al comienzo resulta pretencioso
llamarle as, hay muchos sntomas que cuesta interpretar, ms bien lo que se tiene es una confusin o
una sensacin de molestia indefinida
Entonces, la solucin de la confusin es el
problema.

84

JUAN BRAVO

Yendo a los fundamentos conceptuales, la visin


sistmica tiene especial predileccin por invertir
tiempo en la adecuada definicin de los problemas,
antes de hablar de las soluciones.
De hecho, en teora de sistemas se dice que cuando
uno descubre el verdadero problema, el de fondo
la solucin est incluida!.
Precisamente el objetivo de esta etapa es
aclarar la confusin para obtener un
enunciado validado, a eso le podemos
llamar Problema, definido como una
distancia, entre dnde estamos y dnde
queremos estar.
Fruto del anlisis de los sntomas y de la confusin,
se llegar a un problema de fondo6.
Esta salida tambin puede provenir desde las definiciones estratgicas o desde el mapa de necesidades
de la organizacin, en ambos casos, se le da forma
como una necesidad.
Es posible saltarse esta etapa cuando una necesidad
proviene de un proceso de planificacin estratgica
o desde el mapa de necesidades? Es preferible no
saltarse la etapa aunque la necesidad venga dada,
porque es necesario cuantificar y dar un formato
comn para pasar a la siguiente etapa.
6

La tcnica de enfoque al problema se presenta en detalle en el libro


Anlisis de Sistemas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

85

La propuesta de GSP es utilizar una ficha para ayudar en la deteccin preliminar de necesidades o problemas.
De acuerdo con el proceso de deteccin de necesidades y formulacin de proyectos, todo integrante7
de la organizacin puede detectar necesidades (ojal
en un formulario sencillo, no ms de una pgina). Si
se aprueba lo planteado en esta ficha generalmente
hay dos caminos que sigue el comit de proyectos:
a) Solicita un estudio ms detallado de la necesidad.
b) Solicita el cierre de la etapa de concepcin
con el entregable que corresponda.
En ambos caminos recurre a profesionales
especializados de dentro a fuera de la
organizacin.
Un informe tpico de esta etapa debiera incluir los
puntos siguientes, los cuales se aplicarn en forma
iterativa, como en una espiral, se logra un avance en
cada punto y luego en una segunda vuelta se perfeccionan los avances de cada uno.

1.1. mbito del problema


El objetivo es ubicar el problema en su contexto.
De esta forma podremos entenderlo mejor.
7

En el libro Anlisis de Sistemas, tercera y cuarta parte, se pueden encontrar mayores alcances acerca de la importancia de la participacin y de su impacto positivo en los resultados.

86

JUAN BRAVO

Es necesario ver esta descripcin como un continuo


que se inicia como una descripcin breve en la primera vuelta de la espiral lo mnimo para comprender el problema hasta un mayor detalle antes
de pasar a la etapa de factibilidad.
Entonces, con base en las orientaciones
estratgicas de la organizacin y tomando
en cuenta las oportunidades y exigencias
que el medio plantea, lo primero es
conocer el mbito de trabajo y ubicarnos
en el entorno.
Normalmente el mbito de trabajo son reas o procesos. En el primer caso, puede ser racionalizar el
rea de abastecimientos, la oficina comercial o la
planta productiva. En el segundo caso, el proyecto
puede ser redisear el proceso de: crditos de consumo, crditos hipotecarios u operaciones cambiarias, si se trata de un banco. O podra ser fabricacin
de zapatillas, zapatos de varn o diseo en el caso de
una empresa productora de zapatos. Tambin pueden ser los servicios de exmenes de laboratorio, las
atenciones ambulatorias y la contratacin de personal en un hospital.
Por qu comenzar por esa rea o proceso de negocio y no por otro mbito? La respuesta la podemos
encontrar en las orientaciones estratgicas de la organizacin.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

87

Descripcin de la situacin actual


Conocer dnde estamos es importante porque en un
proyecto de rediseo participarn muchas personas,
algunas externas, otras internas con ms o menos
antigedad. Entonces, es preferible no dar por obvio
o conocido aspectos que pueden ser importantes.
Conociendo cul es el mbito, ahora se
requiere saber dnde estamos.
A veces se le llama descripcin de la situacin actual e incluye:
1. Descripcin del medio en el cual se encuentra la
organizacin: caractersticas de la industria, de la
economa y dems entorno inmediato. Es decir,
dnde estoy?
Aplican aqu las tcnicas de sntesis y anlisis de
la visin sistmica (libro Anlisis de Sistemas).
2. Descripcin de la organizacin: historia, productos y mercados principales, estructura organizacional, tamao y cualquier aspecto significativo.
Es decir, quin soy?
3. Descripcin cuantitativa de las situaciones en
que se trabajar: identificacin, descripcin breve, estimacin de costos, nivel de urgencia por
cambiar, qu riesgos tiene mantener la situacin
actual?, etc. Es decir, qu sucede?
4. Descripcin de la estrategia: para saber cul es
la direccin en que camina la empresa. Es decir,
qu queremos?

88

JUAN BRAVO

Principalmente en trminos de visin,


misin, valores, programa de accin,
factores de diferenciacin y otras
definiciones tpicas.
5. Rol de las personas: Cul es el perfil de cargos
en torno al problema, las personas tienen las
competencias necesarias? cul es nivel de preparacin? cmo est la motivacin?
6. Descripcin de la estructura organizacional y
relaciones: ubicacin de la necesidad en una
unidad organizacional, en una funcin y/o en un
proceso. Identificar relaciones del rea problema
con otras reas, qu y a quines provee, de quines recibe qu, etc.
El contenido y profundidad de estas descripciones dependen de cada situacin
7. Revisin de los procesos: mapa de procesos y
flujogramas de informacin (podra no ser tan
detallado en esta etapa, ver seccin 3.5).
8. Tecnologa que se aplica: revisin de la actual
situacin en cuanto a redes, hardware, software,
herramientas de apoyo, ERP y todo lo dems relevante.
A veces la descripcin ser detallada, como cuando
se trata de un informe de consultora de alguien que
no conoce la organizacin, o breve, cuando es una
presentacin interna de un mbito conocido por todos y documentado.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

89

1.2. Cul es el problema?


Se trata de avanzar desde la confusin
inicial hasta un enunciado validado.
Siendo el objetivo de la concepcin obtener un
enunciado validado del problema, este enunciado se
puede ensayar muchas veces, al mismo tiempo que
se avanza en las actividades de la etapa.
Cabe sealar que un proceso como el descrito en
estas pginas, junto con ayudar efectivamente a obtener un enunciado validado respecto a la confusin
inicial, tambin generar nuevos cuestionamientos
que darn origen a enunciados de otros problemas.
a) Exponer la confusin
Es el primer enunciado, no validado, lo que da origen al trabajo de la etapa. Se requiere valenta y al
mismo tiempo humildad para escribirlo, porque la
probabilidad de cambiarlo es muy alta, tal vez un
99% (basado en las experiencias de consultora y en
muchos ejercicios en diferentes cursos). Esto es impresionante, quiere decir que al no pasar por esta
etapa el problema que se solucionar tiene esa probabilidad de estar equivocado
b) Ensayar enunciados
Se trata de proponer variados enunciados
del problema hasta encontrar el que
parece ms apropiado.

90

JUAN BRAVO

En cada situacin especfica, la idea es comenzar


por trabajar en el problema hasta obtener un enunciado validado. Por ejemplo, en una visita a la bodega de distribucin en Santiago, el nuevo gerente de
operaciones de una empresa productiva ubicada en
Curic (distante 200 kilmetros), observa que: En
la bodega de la empresa existen problemas de manejo de la informacin (errores y saldos atrasados)
debido a la gran cantidad de transacciones, y
aprovech inmediatamente su visita a la capital para
adquirir un programa computacional... y aunque el
programa funcion el problema subsiste.
Qu pas? Qu el gerente se qued en la confusin,
con el primer enunciado. Hizo un primer diagnstico
apresurado y lanz una solucin que en otra parte
haba funcionado. En lo inmediato, el gerente culp
al supervisor y a los bodegueros de Santiago por su
resistencia al cambio.
Para validar el enunciado podemos aplicar tcnicas,
por ejemplo, causa efecto, cuestionar la existencia
de cada palabra del enunciado o preguntar por qu?
As, algunas preguntas en relacin al caso de la bodega seran: debe existir la bodega en la empresa?,
debe existir la empresa?, conviene venderla?, realmente existen esos problemas de manejo de informacin?, existe gran cantidad de transacciones?,
etc.
Con ese tipo de preguntas se arman
enunciados hasta que obtenemos uno que

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

91

nos resuena, y que resiste las pruebas y


cuestionamientos que le hacemos.
Qu hay antes del problema? Una situacin confusa
que no permite el desarrollo del proceso creativo y
se presta para la aplicacin de recetas, es decir, soluciones empaquetadas que no toman en cuenta la
variedad del problema. Sabemos que cualquier solucin a un problema confuso solamente incrementar
los costos. Por eso, la solucin de la confusin es el
problema bien enunciado y estudiado.
Una ventaja es que a este nivel el costo del error es
muy bajo, podemos redefinir el enunciado cuanto
queramos, sin ms costo que el tiempo invertido en
el anlisis. Si se avanza hasta implementar una solucin sobre un problema errado, lo ms probable es
que hacer todo de nuevo tenga un costo alto.
Antes de seguir, convengamos en que llegar a la claridad total de la confusin es imposible. Los sistemas son caticos e indescriptibles, el enunciado perfecto no existe, lo que hacemos es trabajar con niveles tolerables de incerteza.
A veces, hay presiones que obligan a reducir el
tiempo de anlisis hasta donde sea posible. Debemos
cuidar que ese nivel no llegue a cero. La idea es destinar algo de tiempo a aclarar la confusin y enunciar el problema antes de lanzarnos a las soluciones.
Hay una cantidad de tiempo razonable en el estudio de la confusin, nico para cada caso. No puede
ser mucho, porque corremos el riesgo de quedarnos

92

JUAN BRAVO

dentro del cuadrado de lo que se ha hecho previamente. No puede ser poco, porque el problema arrastrara ms confusin de la que puede soportar la solucin.
Entonces, nuestra meta es llegar a tener
un problema bien planteado, con
mediciones de las variables crticas.
c) Identificar y medir las variables crticas del problema
Se requiere identificar las variables crticas para el
problema particular Por ejemplo: tiempo que los
clientes esperan en una fila, nmero de exmenes
que se pierden, clientes que reclaman y cualquier
otra relevante para el problema en estudio.
Mejor todava, identificar la variable
crtica ms importante y trabajar con ella.
Eso focaliza y enriquece el esfuerzo.
Por ejemplo, la variable crtica puede ser tiempo que
los clientes esperan en una cola para pagar en la
caja.
Luego se requiere medir el estado actual de esas variables y de ser posible comparar contra un estado
deseado o estndares de la industria.
Se requiere aportar datos concretos y hechos precisos que ayuden a la comprensin del problema y al
planteamiento del enunciado.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

93

El volumen de algo cambia drsticamente la concepcin de un problema. No es lo mismo manejar el


stock de pocos productos, lo cual se puede hacer
visualmente, que de miles, para lo cual el computador es indispensable.
Si se trata de un problema de inventarios:
Cuntas transacciones de cada tipo existen?
Cuntos metros cuadrados y cbicos ocupan las
existencias?
Cul es la rotacin?
Cul es el tiempo promedio de despacho?
Cul es el tiempo de demora de un pedido a los
proveedores? Cmo vara entre diferentes proveedores?
Costos ms difciles de cuantificar
La existencia del problema afecta el nimo de las
personas?
El problema resuelto tiene algn efecto de marketing? Mejora la imagen de la empresa? Realmente
aporta a la organizacin? Aporta indirectamente?
Si visualizamos el problema resuelto:
cmo influye eso en el clima laboral? Y
sobre los clientes? Y los proveedores? Y
los accionistas?
En todos los casos, medir, al menos logrando la mejor estimacin.

94

JUAN BRAVO

Urgencia por solucionar


Dentro de las variables crticas tambin est la urgencia por solucionar, porque no es lo mismo un
problema de renovacin de vivienda que de apoyo
en caso de un desastre.
Este anlisis es vital para las soluciones en la etapa
de factibilidad.
d) Determinar las causas de fondo
En todo caso, el objetivo es identificar las causas
races del problema, pudiendo aplicarse otras tcnicas, como las del mejoramiento continuo. Algunas
son:
1. Tcnica de cuestionar la existencia de cada palabra
del enunciado
2. Tcnica de Benchmarking, o cmo otras organizaciones han planteado problemas similares
3. Bsqueda bibliogrfica
4. Ishikawa y Pareto (ver anexo 1, relacin causal)
5. Consultores u otros profesionales familiarizados con
el tema

e) Identificar al dueo del problema


Puede ser una persona, un equipo o un rea, lo importante es que cada problema debe tener un dueo
que lo reconoce como propio y que est interesado
en que se aclare y se resuelva.
A veces esto puede obligar a plantear facetas del
problema para ms de un dueo. Por ejemplo, en un

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

95

caso de crisis se quiere ayudar a empresas pequeas


que estn sufriendo especialmente los rigores.
Quin es el dueo del problema? La reparticin a
cargo del subsidio y que de alguna forma representa
a la comunidad? Es la empresa pequea que de alguna forma debe empoderarse?
f) Enunciado validado
Ahora s, aclaramos la confusin y obtuvimos un
problema. El enunciado final del problema es lo que
se anota en este punto.

1.3. Cuantificar el problema


Importa calcular el costo del problema (o de no resolver la necesidad). Los costos de oportunidad
tambin se incluyen, tales como clientes potenciales
que no llegan, ganancias no logradas por no disponer de productos en stock, personas que no salen de
la pobreza en el caso de un proyecto social, etc.
VA del Problema
Lo ms concreto es calcular un VA (Valor Actual)
del problema.
Por ejemplo, en un banco el problema es lo lento del
servicio de comercio exterior, con 100.000 clientes.
El costo del problema se puede medir, por ejemplo,
en trminos de imagen: 10.000 clientes se han ido en
los ltimos cinco aos, cada uno generaba una ren-

96

JUAN BRAVO

tabilidad al banco por US$ 1.000 al ao. Aqu hay


varios millones de dlares como costo del problema.
Tambin se observa que hay ahorros que se pueden
lograr. Se estima que 50 personas pueden liberarse
de procesos obsoletos, con rentas bruto promedio
mensual de US$ 2.000, ms el espacio fsico, supervisin y otros recursos, nuevamente son millones de
dlares al ao.
Otro costo es el de oportunidad, se estima que el
banco podra duplicar la cantidad de clientes con un
buen servicio, entonces, est perdiendo o dejando
de ganar la rentabilidad de esos 100.000 clientes por
no hacer las cosas bien. En el ejemplo, son US$ 100
millones anuales.
VA social
El VA social son las prdidas concretas que asumen
los clientes por un mal servicio8.
Un ejemplo de VA social es el costo en
tiempo de los clientes que esperan en una
fila. 20.000 clientes al mes a US $ 4 por
hora es aproximadamente un milln de
dlares al ao que asumen los clientes, es
fabricar pobreza.
8

En el libro Gestin de Procesos hay un anlisis detallado al respecto. Se presenta un caso en una Municipalidad, donde su diseo del
proceso de renovacin de licencias de conducir, hace que los usuarios vayan tres veces y pierdan seis horas, lo cual empobrece a la
comunidad en millones de dlares.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

97

Hemos utilizado US $ 4 por hora para medir el costo


social, solamente considerando promedios de renta.
En nuestro ejemplo del servicio de comercio exterior
del banco, cada cliente debe concurrir al banco una
vez al mes, 12 veces en un ao. Hablamos de
1.200.000 viajes al banco innecesarios porque todos
los trmites pueden ser electrnicos. Cada viaje significa tres horas que a los clientes de ese servicio le
cuestan en promedio US$ 5. Son US $ 18 millones
de dlares perdidos solamente en trmites.
Tambin deberamos calcular el costo para el cliente
de que el servicio sea lento y no pueda contar con el
resultado en la mitad del tiempo si las cosas se hicieran bien. Ese clculo se lo dejamos al lector

98

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

99

ETAPA 2. FACTIBILIDAD
Lo que da origen al trabajo en la etapa es una necesidad de la organizacin.
El objetivo es obtener el plan de proyecto
de la solucin despus de un barrido
creativo de muchas soluciones y de un
estudio comparativo de algunas de ellas.
Entregable final de la etapa: el plan de proyecto.
Entregables intermedios: La investigacin de soluciones y la evaluacin comparativa de alternativas
de solucin seleccionadas.
~~
La etapa de factibilidad9 tiene tres entregables secuenciales, se accede al siguiente despus de la toma
de decisin por parte de la autoridad correspondiente. Puede ser un gerente o un comit de proyectos
(suponemos esta opcin de estructura en lo que sigue). La toma de decisin sera despus de realizar
cada una de estas acciones:
a) Una investigacin creativa de muchas soluciones y propuesta de alternativas a estudiar.
b) Una evaluacin comparativa de alternativas
de solucin seleccionadas.
9

Un buen apoyo es el libro Desarrollo de sistemas de informacin,


una visin prctica, pginas 50 a 58.
Tambin el libro Anlisis de Sistemas, Quinta parte: Cmo
Hacer Anlisis de Sistemas?

JUAN BRAVO

100

c) Un plan de Proyecto de la alternativa seleccionada.


Por supuesto, en cualquiera de esas acciones, el comit de proyectos puede solicitar replantear el estudio. Pueden presentar este formulario los evaluadores designados para ello por el comit de proyectos y
que cuenten con las competencias necesarias.
Cada alternativa evaluada es una solucin integral
alineada con la estrategia que incluye acciones sobre
personas, procesos, estructura y tecnologa.
Usamos la palabra solucin porque es ms amplia y
representativa que indicar solamente rediseo de
procesos o aplicacin computacional. Adems, lo
ms probable es que la solucin seleccionada resulte
de una combinacin de varias alternativas.
Creatividad aplicada
En esta etapa la creatividad e inventiva aplicada en
la bsqueda de soluciones es vital.
Se exploran amplias posibilidades de
solucin al problema hasta decidir por la
frmula que se considere ms apropiada.
As evitamos la rigidez paradigmtica que se produce cuando desde el principio alguien cree que tiene
la solucin.
Qu tcnica es buena para la invencin? Existen
muchas: una noche de sueo, meditacin, los siete
por qu, tormenta de ideas, los seis sombreros para

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

101

pensar, comparacin con otras organizaciones,


bsqueda bibliogrfica, consultora, etc.
Por otra parte, existe un amplio abanico de tcnicas10 que pueden ayudar a generar soluciones, por
ejemplo: cadena de valor, just-in-time, flujos tensados, Kanban, produccin flexible, costo objetivo,
nuevas reglas del juego, salir del pensamiento dicotmico, armonizar las economas de escala con
otras opciones, logstica y muchas otras.

2.1. Conformar el equipo de trabajo


El trabajo en la etapa de factibilidad queda encomendado a un equipo de proyecto.
Pueden los mismos operadores de un
proceso ser parte del equipo de trabajo?
S, en la lnea de mejoramiento continuo o
como parte de equipos de trabajo
multidisciplinarios destinados
directamente al proyecto.
Los integrantes de un equipo de proyecto son analistas de proyectos. Esta funcin no debiera ser una
especializacin profesional, sino que cualquier profesional de dentro o fuera de la organizacin, con la
debida preparacin, puede asumir ese rol en un momento dado.

10

Detalladas en el libro Gestin de Procesos.

102

JUAN BRAVO

Entonces, cada proyecto especfico se aborda con un


equipo de proyecto formado por analistas de proyectos y usuarios, stos pueden ser profesionales internos destinados completamente al proyecto, consultores11 u operadores de los procesos. Un equipo de
proyecto puede integrar todas esas posibilidades.
Un aspecto vital es la preparacin del
equipo de trabajo, no slo en temas
tcnicos y de administracin del cambio,
sino que tambin en temas de
comunicacin, particularmente en cuanto
al trabajo en equipo y el profesionalismo.
De hecho, es una prctica regular en empresas con
una larga historia de proyectos exitosos realizar talleres de trabajo en equipo antes, durante y despus
del proyecto.
Por su importancia, destacan variadas facetas de la
comunicacin formal: liderazgo, entrevistas, exposiciones, escuchar, coaching, retroalimentacin, etc.
(son facetas tan importantes que alrededor de un
tercio de las prcticas transversales las abordan).

2.2. Ideal de la solucin


El ideal de la solucin se refiere esencialmente a
plantear la medicin ideal de la variable crtica seleccionada. Un gran qu queremos o desafo.
11

Se gana el efecto consultor una mirada externa fresca, lo cual es


una prctica habitual en algunas organizaciones.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

103

Conociendo dnde estamos, ahora se trata


de saber adnde vamos es decir, definir
el alcance de la solucin. Qu
pretendemos lograr?
Aqu debera quedar planteada la medicin ideal
para el mbito de trabajo, por ejemplo, para el rea
de abastecimientos, puede ser:

Disminuir a cero los costos de cada transaccin.


Disponer de inmediato de los insumos.
Llegar a cero stock de productos en inventario.
Reducir a cero el tiempo de entrega a los usuarios
de los productos
Disminuir a cero el tiempo de duracin de cada
compra.
Suponemos que estas grandes directrices surgieron
como solucin al problema detectado en la etapa
anterior.
Tambin surgen de las directrices estratgicas para
un rea o de los indicadores que la organizacin que
se ha dado, por ejemplo, en el Balance Scorecard (o
BSC, traducido como Cuadro de Mando Integral).
Tambin en esta fase ya es conveniente comenzar a
pensar en riesgos, por ejemplo: y si nos equivocamos? qu riesgos tiene lograr esos objetivos?
Es evidente la importancia de que la direccin participe en la elaboracin de estas directrices.

104

JUAN BRAVO

La idealizacin juega un rol central


porque es conveniente plantearse grandes
sueos.
Preguntarnos cul es la realidad deseable?, en lugar
de intentar mejorar lo que existe.
Plantear grandes ideales se puede definir como Llevar la medicin al extremo ms positivo de la o las
variables crticas.

2.3. Planteamiento libre de alternativas


Todava sin restricciones, la idea es lograr una investigacin lo ms amplia posible de soluciones posibles, pueden ser tan creativas como se quiera, incluso no factibles12.
Aqu se deben explorar, entre otras posibilidades, las
propuestas de cambio respecto a:
Personas: las personas pueden ser potenciadas y
lograr as aumentos espectaculares en la productividad. Con liderazgo, educacin, colaboracin,
motivacin, autonoma, disciplina, trabajo de
equipo, incentivos, etc...

12

En el mtodo GSP es incluso una obligacin plantear al menos un


20% de alternativas no factibles, para abrir la mente. Los resultados
son extraordinarios, en el libro Anlisis de Sistemas se puede ver
ms detalle. Aunque igual son soluciones efectivas que por costo,
tecnologa, poltica u otra causa se dejan fuera o se congelan.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

105

Procesos: debe existir el proceso? Es posible


aplicar generalizacin? Se puede externalizar el
proceso? Revisin del ciclo completo de procesos
del negocio y otros de apoyo.
Algunas preguntas:
Una persona puede hacer el proceso
completo?
Un equipo de personas lo puede hacer?
Estructura: equilibrios en centralizacin y descentralizacin, cambio y control, funciones y procesos, servicios internos y externalizacin, especializacin y generalizacin.
Tambin revisin de tcnicas: Just-in-time, Kanban13, Rightsizing (tamao justo), etc...

13

Kanban es una forma de modelo inventado en Japn donde, manteniendo una estructura semiespecializada del proceso, se trabaja de
a una pieza a la vez en toda la lnea. Si hay una falla, todas las personas en la cadena se detienen y ayudan a corregir el problema. De
esta forma se economizan los inventarios y bodegas intermedias, se
eliminan los controladores y revisiones de calidad porque la retroalimentacin a cada integrante de la lnea es inmediata. Para que este
sistema funcione es indispensable que cada operario sepa realizar
varias actividades, especialmente las ms cercanas a su especialidad.
Kanban es un sistema visual que combina la simpleza con la practicidad, donde los resultados de cualquier operacin se manejan grfica y manualmente en el mismo puesto de trabajo. Se trata de tener
seales visuales para la comunicacin. Por ejemplo, etiquetas para
productos en proceso que permiten conocer tanto lo que se hace en
un determinado paso como lo que se hace en los pasos anteriores y
siguientes. Tambin se utilizan luces amarillas y rojas para indicar
un problema o una detencin del trabajo. Pizarras para anotar todo
asunto de inters y, sobre todo, tener una visin de conjunto del

JUAN BRAVO

106

Tecnologa: de qu tipo? Por ejemplo, de comunicaciones, transporte, almacenamiento, construccin, procesamiento de imgenes, automatizacin
de oficinas, identificacin de personas y, por supuesto, tecnologa de informacin,
Es realmente necesario desarrollar
software? (es saludable cuestionarse
paradigmas).
Considerar tambin:
Revisin del entorno: cmo lo hacen en otros
lugares? En otras organizaciones similares?
Existen soluciones normalizadas (por ejemplo,
software de uso generalizado)? Es importante revisar lo que existe en el medio mediante benchmarking, publicaciones, ferias, etc.
Conzcase a usted mismo antes de
intentar conocer a otros. El
benchmarking comienza con una
comprensin total de sus propios
productos y procesos organizacionales.
En la mayora de los casos, someter a benchmarking las actividades de otros cuando usted mismo no se entiende, es una prdida de tiempo. Si
usted va a compararse con otra persona, ms vale

proceso, para prevenir eventuales problemas en una actividad que


llevaran a detenerlo.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

107

que antes se forme un buen juicio de su propio


desempeo14.
Autosolucin: podra el mismo usuario resolver
su necesidad? Cunta capacitacin requiere?
Existe software bsico de apoyo?
La lista de soluciones es discutida y presentada a la
autoridad para la toma de decisin de cules alternativas estudiar en detalle. Normalmente el equipo de
trabajo recomienda algo.
Asimismo, recomienda ideales factibles para las variables contempladas.
El comit de proyectos decide como sigue el estudio
de soluciones.
Aplicar la tcnica de visionar
Aqu trabajamos con ideales que luego se transforman en ideales factibles.
Ya en la fase anterior se asociaron valores idealizados a las variables crticas.
a) Por ejemplo, cmo lograr el ideal de que los
clientes tengan cero tiempo de espera para recibir
su producto? una forma puede ser mediante un
sistema de teletransporte hacia su casa (como en
la pelcula Viaje a las Estrellas) Es importante
darse permiso para soar en este paso.

14

SPENDOLINI (1994), p. 244.

JUAN BRAVO

108

Los valores ideales deben ser estudiados


para cada caso, por ejemplo, en el caso
del tiempo, puede que el ideal sea una
semana en un proceso de importaciones,
versus los tres meses de la situacin
actual, se reconoce porque disminuir ms
el tiempo ya no agrega valor para el
cliente.
b) Obtener un ideal factible para cada variable. Desde el ideal discutido en la fase anterior, ahora
volvemos a ser adultos, serios: qu se puede
llevar a cabo?, cmo se hace en otros lugares?
Aqu se trata de negociar con la realidad para
obtener un ideal factible (desde el cual se pueden
obtener los objetivos). Por ejemplo, estimamos
factible disminuir desde doce a un minuto el
tiempo de espera de los clientes frente a la caja.

2.4. Restricciones de la solucin


Se trata de indicar con toda precisin aspectos que
acotan el universo de posibilidades, por ejemplo, el
costo de la solucin no puede superar el costo del
problema o un determinado monto, por restricciones
presupuestarias o porque aparece un costo de oportunidad, es decir, pueden existir otros problemas de
costo alto con soluciones de costo bajo para la organizacin que daran ms rentabilidad interna a la
misma inversin.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

109

Tambin existirn restricciones estticas,


estratgicas, tcnicas, de estandarizacin
y de otra ndole.
Surgen en parte de los grupos de inters que no son
clientes. Estas restricciones debieran estar incluidas
en el plan de proyecto. Otro ejemplo, un flujo debe
mantenerse de tal manera porque existe una disposicin legal que lo exige.
Existen restricciones tcitas y otras explcitas. Ambas son igualmente vlidas. Por ejemplo, una restriccin tcita es generar rentabilidad en el mbito
de trabajo del proyecto.
Prcticamente todo grupo de inters puede dar origen a restricciones, por ejemplo:
La direccin de la organizacin: espera que el
servicio se otorgue conservando un cierto nivel de
beneficios.
La comunidad espera que el rediseo respete el
ambiente.
El Estado espera que se respeten las leyes y se
paguen los impuestos debidos.
Los empleados esperan que no haya despidos por
motivo del rediseo.
Hay que armonizar esas restricciones, no slo en la
etapa de factibilidad, sino tambin a nivel del plan
de proyecto completo.

JUAN BRAVO

110

Existe un grupo de inters, llamado


clientes, a cuyos intereses no les llamamos
restricciones, sino que hablamos de
variables crticas.
Es necesario preguntar qu desean los clientes?
Las respuestas pueden ser a nivel de procesos individuales o por grupos de procesos, por ejemplo en
el otorgamiento de crditos, el cliente requiere rapidez y baja tasa. La idea es obtener estas respuestas preguntando directamente y no suponiendo.
De las restricciones a la solucin surgen Factores de
Decisin.
Segn libro Desarrollo de sistemas de informacin, una visin prctica, seccin 2.2.

2.5. Seleccin de alternativas y objetivos


generales
El objetivo es afinar objetivos y seleccionar una lista
corta de soluciones factibles.
Considerando el barrido de soluciones y
las restricciones, el comit de proyectos
selecciona un pequeo conjunto de
alternativas (2 3 generalmente) que
sern evaluadas en detalle.
Asimismo, el nivel del avance ya permite definir
objetivos generales del proyecto (un avance ms
desde los ideales factibles propuestos).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

111

El comit de proyectos encarga a un equipo la evaluacin detallada de cada alternativa seleccionada.


Incluso podra encargar a personas o equipos diferentes cada opcin y ganar el efecto de competencia
(aunque con el riesgo que ganar resulte ms importante que tener la mejor alternativa).

2.6. Evaluacin de cada alternativa


Cada alternativa evaluada debiera llevar su propio
plan de desarrollo y mantenimiento. Adems cada
una debiera incluir los costos y beneficios durante
todo su ciclo de vida estimado, no slo durante el
desarrollo del proyecto.
En el libro Desarrollo de sistemas de informacin,
una visin prctica, seccin 2.2 y anexo 2 se incluye una forma de realizar la evaluacin econmica. Tambin en el libro Gestin de Procesos,
etapa de factibilidad .

Algunas consideraciones: est balanceada la carga


de trabajo en los nuevos cargos? La estructura es la
apropiada al proceso? Existe integralidad? La tecnologa es la adecuada?
En relacin a costos, es importante
contemplar que en promedio las
inversiones tienden a nivelarse en los
cinco elementos del modelo integral del
cambio: estrategia, personas, procesos,
estructura organizacional y tecnologa

JUAN BRAVO

112

2.7. Evaluacin comparativa


Para cooperar en hacer una buena decisin conviene
aplicar los factores de decisin.
Identificacin de factores de decisin
Esta es una forma de hacer visible los criterios ms
importantes para la toma de decisiones, por ejemplo,
los factores de decisin pueden ser:

Impacto en los objetivos propuestos


Avance previo
Aporte social
Costo/beneficio de la solucin
Imagen frente a clientes

Estos factores de decisin son slo un ejemplo, porque cada organizacin debe determinar sus propios
criterios para fijar prioridades.
Asignar un peso a cada factor de decisin
Se trata de asignar un peso a cada factor de decisin, un porcentaje que indique su grado de influencia en la decisin final, por ejemplo:
Factor de decisin
Impacto en los objetivos propuestos
Avance previo del trabajo de rediseo
Aporte social del trabajo de rediseo
Costo/beneficio de la solucin
Imagen frente a clientes
TOTAL

Palabra clave
Impacto
Avance
Social
Contribucin
Imagen

Peso
40 %
20 %
15 %
15 %
10 %
100 %

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

113

Evaluacin comparativa entre procesos


Luego se procede a un estudio comparativo entre las
soluciones propuestas, tal como se muestra en el
ejemplo de procesos en un banco tomado desde el
libro Gestin de Procesos.
Cada factor de decisin se evalu con una nota de 1
a 5 en cada proceso. Asignar 1 es baja prioridad
(quedara hacia el final de la lista) y 5 es alta prioridad.
Luego se calcula la nota final ponderada, la cual
surge de la siguiente frmula general para cada proceso:
Nota final ponderada (NF) =
peso del factor)
Procesos segmentados

1. Apertura cuentas
bipersonales
2. Entrega de libretas
de ahorro
3. Apertura cuentas
personales
4. Confeccin
libretas de ahorro
5. Captacin de
depsitos

(Nota del factor x

Factores de decisin
Impacto
(.4)

Avance
(.2)

Social
(.15)

Contribu-cin
(.15)

Imagen
(.1)

Nota
final

3.9

3.3

3.2

2.9

1.3

JUAN BRAVO

114

Ms simple, para cada proceso y en este caso especfico:


NF = nota impacto x .4 + nota avance x .2 + nota social x .15
+ nota contribucin x .15 + nota imagen x .1

Para mayor claridad, veamos el clculo para el proceso que qued en primer lugar, apertura de cuentas
bipersonales:
NF = 5 x 0.4 + 4 x 0.2 + 2 x 0.15 + 4 x 0.15 + 2 x 0.1 = 3.9
NF = 2 + 0 .8 + 0.3

+ 0.6 + 0.2 = 3.9

Una vez realizados los clculos, la lista se ordena de


mayor a menor.
El informe de Evaluacin comparativa de soluciones
es una exigencia en este mtodo.

2.8. Decide la opcin y objetivos especficos


El comit de proyectos decide un camino, puede ser
directamente una de las alternativas o puede ser una
mezcla que adems incorpore elementos no contemplados en ninguna de las opciones.
Lo ms probable es que la toma de decisin sea ms
bien un proceso iterativo que una accin inmediata
con base en la primera versin del estudio comparativo de soluciones. Es frecuente que se pidan precisiones, nuevas alternativas y cambios.
Con el mayor conocimiento de la
necesidad y de las soluciones, ya se

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

115

pueden plantear adems los objetivos


especficos del proyecto.
Ms bien, lo que concretamente se espera lograr de
cada variable crtica (o indicador relevante).
El comit de proyectos encarga a un equipo la elaboracin del plan de proyecto.

2.9. El plan de proyecto


El plan de proyecto es el detalle de todas las actividades del proyecto.
No confundir el plan de la etapa de factibilidad con
el plan de proyecto, el cual se refiere a las actividades de todo el proyecto, desde el anlisis hasta la
operacin.
El plan de proyecto considera tanto las actividades
de cada etapa como las prcticas transversales de los
proyectos.
En realidad el plan de proyecto no es un plan, sino
que es un conjunto de planes, cuyo objeto ms visible es la Carta Gantt detallada.
Lo aprueba el comit de proyectos y los usuarios.
Luego, slo faltara poner de fecha de inicio y comprometer los recursos (aunque por el solo hecho de
hacer este estudio ya existe un compromiso tcito y
sobre todo una expectativa, no realizar el proyecto a

JUAN BRAVO

116

estas alturas tendra altos costos para la organizacin15).


Costo del proyecto
Por supuesto, el plan de proyecto incluye
la primera estimacin de costos del
proyecto
Por otra parte, la estimacin del costo fue perfeccionado desde la evaluacin individual y comparativa
de la alternativa.
Las siguientes estimaciones se obtienen al final de
las etapas de anlisis y de diseo.
Durante las etapas de implementacin y despliegue
se calculan los costos reales y se comparan con las
estimaciones, esto ser parte del informe de retroalimentacin de estas etapas y del proyecto completo.
Es similar a lo que plantea Hernn de Solminihac16
en su clase de gestin de costos, donde identifica
cuatro estimaciones de costos:
Estimacin preliminar o de orden de magnitud,
realizada durante la etapa de evaluacin econmica.

15

Tiene que ver con el rol del observador, quin, por el slo hecho
de observar, cambia el sistema observado (en el libro Anlisis de
Sistemas mayor detalle).
16
Clase ejecutiva de El Mercurio, La gestin de costos de proyectos (B11, 13/10/2005)

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

117

Estimacin conceptual, realizada por el dueo


para presupuesto.
Estimacin detallada, realizada cuando se cuenta
con un diseo detallado.
Estimacin definitiva, es una actualizacin de la
estimacin detallada con nfasis en costos actuales ms que en costos proyectados.

118

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

119

ETAPA 3. ANLISIS
Lo que da origen a esta etapa es el Plan de proyecto
actualizado y la autorizacin del inicio del comit de
proyectos. Es el inicio de la ejecucin del proyecto.
El objetivo es plantear el modelo integral del cambio
y los requerimientos correspondientes, el Qu.
Entregable de la etapa: el modelo integral del cambio de la solucin.
~~
Se trata del anlisis integral de la solucin. Tambin
es llamada Ingeniera Bsica, Ingeniera Conceptual
o Arquitectura de la solucin.
En particular para los proyectos de GPPT, desde
aqu surgen las definiciones de los procesos y de la
tecnologa de informacin.
El modelo integral del cambio es la visin
integral de la solucin y se apoya en un
concepto o idea fuerza. Debe estar bien
sustentado en la estrategia de la
organizacin.
Se trabaja en el modelo integral del cambio de la
solucin. Recurdese la metfora de una mesa: la
cubierta es la estrategia y las 4 patas son: personas,
procesos, estructura organizacional y tecnologa.
Se comienza por el modelamiento de procesos, en
particular empleando las tcnicas mapa de procesos

120

JUAN BRAVO

y flujogramas de informacin, desde donde surgen


las dems definiciones, hacia las personas, la estructura y la tecnologa.
Los requerimientos hacia la tecnologa son de diferente tipo, desde comunicaciones hasta apoyo fsico
tal como movimiento automatizado de carga. Sin
embargo, nos concentraremos aqu en la TI, especficamente en las actividades que tienen algn nivel
de apoyo de TI, por eso desde esta etapa se habla
tambin de aplicacin o sistema computacional,
donde comienzan a aparecer elementos tales como:
entorno tecnolgico, identificacin de usuarios, sistema de codificacin, diagramas de casos de uso,
modelo conceptual y otros modelos.
A diferencia del trabajo en la etapa de
factibilidad, ms bien general y destinado
principalmente a cuantificar el volumen y
tipo de trabajo, en esta etapa el trabajo es
minucioso, porque las definiciones que de
aqu se obtengan darn forma definitiva a
la solucin.
Inicio de la etapa
Tal como indican varias de las prcticas transversales, se revisa si la solucin que se obtuvo desde la
etapa de factibilidad sigue siendo vlida, de hecho
sucede a veces que el trabajo de anlisis comienza
tiempo despus del estudio de factibilidad y algo
podra haber cambiado.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

121

A veces, esto puede dar origen a un replanteamiento


de la solucin y una nueva aprobacin, especialmente si es necesario replantear costos y plazos.
Es importante el trabajo minucioso en esta revisin,
porque un riesgo con una probabilidad alta de ocurrencia es comenzar de cero, como si nada se hubiera hecho antes. No se trata solamente de un problema en el contexto de los proyectos GPPT, tambin
ocurre, por ejemplo, en las empresas constructoras,
cuando el ingeniero a cargo, a quien se le acaba de
asignar una obra adjudicada, ignora la propuesta que
hizo antes el equipo de un departamento de estudios.
Ceremonia de inicio
Ahora s, el proyecto se entrega al equipo designado
y se pone en marcha el desarrollo con las primeras
actividades del plan de proyecto.
Una de ellas es la ceremonia de inicio,
que ojal cuente con la presencia de las
ms altas autoridades para que con su
presencia validen la importancia del
proyecto.

3.1. El Modelo integral del cambio


El modelo integral del cambio es la visin integral
de la solucin. Debe estar bien sustentado en la estrategia de la organizacin. Ya indicamos que se
parece a una mesa

JUAN BRAVO

122

E strategia

P ersonas

T ecnologa

P rocesos

E structura

Un proyecto de cambio puede representarse como


una mesa, donde la cubierta es la estrategia y los
pilares son las personas, procesos, estructura y tecnologa. El mensaje es armona en estos medios.
El modelo integral del cambio es un todo integral
que debe ser bien conocido por todo el equipo de
proyecto.
Puede ser desde un solo analista quien, junto con un
usuario, concibe el modelo hasta un equipo de trabajo de decenas de personas donde cada uno tiene la
visin de este todo.

3.2. Estrategia
Por estrategia nos referimos a:
Un concepto o idea fuerza que gue la solucin. Tal como la integralidad en el caso de la
solucin Vendedor Integral de grandes tiendas, la transparencia en una solucin arquitectnica o el humor y personificar en la
campaa comercial Se te apareci marzo?

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

123

Existencia de definiciones estratgicas corporativas y para el proyecto especfico.


Existencia de una estrategia de la solucin.
Detalles de alineamiento de la solucin con la
estrategia de la organizacin.
Es importante destacar que el proyecto debe estar
sustentado en la estrategia de la Compaa (fue fundamental en la etapa anterior para darle el pase al
proyecto).
En esta etapa la estrategia de la
Compaa es la gua principal para
proponer el modelo integral del cambio.

3.3. Personas
Qu sucede con las personas en el modelo integral
del cambio para este proyecto? Cmo aportan?
Cmo se capacitan? Cul es la gestin del cambio?
Hablamos de competencias del equipo de trabajo y
de quienes usarn la solucin en: sensibilizacin,
capacitacin, anticipacin, participacin, ambiente
de trabajo, formas de interaccin, etc.
Se requieren planes orientados al equipo de trabajo y
a los usuarios de la solucin, eventualmente incluso
de los clientes.
Trabajar con las personas considera dos aspectos
vitales:

124

JUAN BRAVO

La cultura de la organizacin (lo que no se ve):


formas de relacin, comunicacin, tradiciones,
creencias, etc.
La infraestructura (lo que se ve): edificios, colores, aromas, etc.
Anticipacin
Cuanto antes se inicie un proceso de comunicacin
dirigido a todas las personas que ah se desempean
es mejor. La transparencia, honestidad, informacin
oportuna y participacin son esenciales en la creacin de un clima adecuado al cambio.
Es vital la participacin de las jefaturas
en la difusin del proyecto. Esto nos lleva
a que es necesario comenzar el proceso de
anticipacin desde las jefaturas.
En esta etapa temprana del proyecto, el objetivo no
slo es comunicar, sino que tambin solicitar el
aporte de los involucrados en la forma de ideas.

3.4. Gestin de Procesos


Todo comienza desde un modelamiento de los procesos, suponiendo que antes se hizo algn nivel de
levantamiento de lo que existe.
Se requiere la descripcin del nuevo flujo de trabajo
y de los procesos relacionados, ya sean del negocio
o de apoyo involucrados en el mbito de trabajo del
proyecto.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

125

Las tcnicas principales que se emplean son el mapa


de procesos y el flujograma de informacin.
Mapa de procesos.
Es un tema tan importante que en las organizaciones
ms avanzadas tienen un mapa de procesos de toda
la organizacin. Generalmente emplean herramientas de apoyo bastante robustas (M1, Aris, Corporate
Modeler, etc.)
Por ejemplo, para una empresa comercial, una parte
del mapa de procesos se vera as:
Vender al detalle

Vender

Cuadrar

Despachar

Al Contado

Inmediato

A Crdito

A domicilio

Programar

Entregar

Mapa de Procesos Venta Integral. Se aprecia que el macroprocesos: vender al detalle se abre en una jerarqua donde hay otros
macroprocesos y procesos operativos. Y as sucesivamente.

Todo mapa de procesos debe iniciarse con los requisitos que impone el cliente y debe finalizar considerando el grado de satisfaccin logrado por ellos a

JUAN BRAVO

126

travs de la implementacin de los procesos de la


empresa.
Flujograma de Informacin (FI)
Junto con el mapa de procesos se emplea la tcnica
de flujogramas de informacin17 para detallar los
procesos operativos ms relevantes de la organizacin cuando la descripcin est centralizada o son
parte del proyecto de solucin.
Es importante contemplar algunas caractersticas del
flujograma de informacin:
Sigue el criterio: SPPP (Simplificar
Procesos y Potenciar Personas) dejando
de lado la antigua, peyorativa e intil
pretensin de construir sistemas a
prueba de tontos
Sigue el criterio Curso Normal de los Eventos
(al igual que los casos de uso de UML).
Tiene temporalidad
Est orientado a seres humanos, principalmente a los usuarios operativos, para quienes
debera ser autoexplicativo.
No es un diagrama de flujo computacional

17

Ms detalle en los anexos del libro Gestin de Procesos (si usted


saba acerca de procesos pero no ha renovado su conocimiento,
digamos los ltimos cinco aos, es conveniente una nueva inmersin, el cambio ha sido grande en esta materia).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

127

Debe caber en una pgina con letra de tamao legible.


Las actividades con doble lnea tienen alguna
relacin con la TI y luego dan origen a los casos de uso
Por ejemplo:
PROCESO DESPACHO INMEDIATO
CLIENTE
OE

PROCESOS
VENDER

BODEGA
ADMINISTRATIVO DE BODEGA

Reservar y
emitir GD
GD4

FINANZAS
DESPACHADOR

GD3
GD2
GD1

GDs

Buscar
producto

GD4
OE

Rebajar
saldo
Cliente
recibe
y firma
recepcin

GD2
GD1

GD3
PROCESO
CUADRAR

OE: Orden de Entrega, GD: Gua de Despacho

Nota: los nmeros en los recuadros punteados sealan tiempos:


duracin de las actividades y, entremedio, tiempos de reposo de la
transaccin.
OE: Orden de Entrega, GD: Gua de Despacho

Si se est utilizando el desarrollo en espiral, el detalle a nivel de los flujogramas de informacin podra
ser parte de cada iteracin. El mapa de procesos debera estar construido desde el principio y solamente

128

JUAN BRAVO

se realizaran perfeccionamientos en cada vuelta de


la espiral.
Diseo de formularios
Se debe realizar el diseo de formularios asociados
al detalle de los flujogramas de informacin. Vlido
para formularios manuales o computacionales.
El diseo de formularios18 sigue algunas normas:

Numeracin
Facilidad de uso
Orientacin al cliente
Cantidad de informacin requerida
Normalizacin y estandarizacin
Posiciones fijas

Relacin del Flujograma de Informacin con la


tcnica UML
Uno de los aspectos metodolgicos y de investigacin ms interesantes es el hecho de buscar un punto
de encuentro entre dos tcnicas de amplio uso: los
Flujogramas de Informacin y UML.
Especficamente ese punto de encuentro est en las
actividades con alguna interaccin computacional
del flujograma de informacin, las cuales dan origen
a los casos de uso del sistema computacional.
18

El diseo de formularios es una materia incluida en el libro Desarrollo de sistemas de informacin, una visin prctica. Tambin en
el libro Gestin de Procesos, captulo 11.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

129

En concreto, cada actividad de tipo computacional


debe dar origen a uno y slo un caso de uso.
En la figura se aprecia este punto de encuentro, donde se tom como ejemplo la actividad Rebajar saldo
del FI recin propuesto.

R e b a ja r
s a ld o

T e rm in a l e n B o d e g a
D e sp a ch a d o r

R e b a ja r sa ld o

U sa e l le cto r p a ra le e r e l
c d ig o d e b a rra s d e
ca d a p ro d u cto q u e sa le .
E n e l siste m a se re b a ja
e l sa ld o d e l p ro d u cto .

Relacin del FI con el caso de uso. La actividad rebajar saldo


del flujograma de informacin se transforma en un caso de uso de
alto nivel, uno de los modelos del estndar UML.

En la figura:
El actor es el despachador, nombre tomado desde
el encabezado de la columna donde est la actividad del FI.

130

JUAN BRAVO

El caso de uso es Rebajar saldo, puesto en infinitivo porque refleja una accin.
El caso de uso de esta figura es del tipo alto
nivel porque la descripcin es general.
La situacin ocurre en un dominio, el terminal de
la bodega en este caso, e incluye los accesorios,
tal como el lector de cdigo de barras.
Una recomendacin metodolgica es unir en un
Diagrama de casos de uso (una forma de agrupacin de casos de uso que veremos luego) los casos
de uso de cada proceso operativo (o flujograma de
informacin).

3.5. Estructura
Se refiere a la definicin de la nueva estructura organizacional desde la mirada que aporta el modelamiento de los procesos. Tambin a los requerimientos de infraestructura fsica.
Los cambios van ms all que solamente crear o
eliminar cargos (agregar, mover o sacar cajas del
organigrama), alcanzan tambin a: planes y propuestas detalladas de externalizacin, delegacin, trabajo
en equipo, empoderamiento, ms o menos supervisin, JIT, Kanban, etc.
Hemos acuado el dicho: un pterodctilo no es una
mariposa grande, en el sentido que tienen una estructura muy diferente y apropiada a su tamao.
Quiere decir que al crecer o cambiar, la organizacin
debe contemplar otra estructura. La estructura de

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

131

mariposa permite un tamao hasta menos de 20


centmetros porque no hay huesos, solamente ligamentos, el pterodctilo tiene toda una estructura
sea que ya sabemos lo fuerte que es, porque se conserva hasta hoy la de algunos ejemplares que vivieron 100 millones de aos atrs.
No se trata de agregar ms personas a
procesos que crecen, son diferentes.
En este texto no se profundiza en la estructura organizacional, lo cual no significa que sea menos importante.

3.6. Tecnologa
En cuanto a la tecnologa no informtica, se requieren planes para la incorporacin o adaptacin de las
tecnologas consideradas en el proyecto, tales como
elementos de comunicacin, transporte, almacenamiento, construccin, despacho, automatizacin de
oficinas, telefona interna, etc. Debiera incluir precisiones de propuestas, contratos, capacitacin y, en
general, formas de implementacin.
Respecto a la tecnologa de informacin, lo veremos
en los siguientes puntos.

3.7. Visin global de la solucin


El modelo integral del cambio aporta una solucin
integral, la mesa.

132

JUAN BRAVO

Sucede a veces que el punto de partida de un proyecto es la definicin de una necesidad computacional.
En tal caso ocurre con bastante frecuencia que no
existan otros profesionales para desarrollar las ramas
de personas, procesos y estructura organizacional
que contempla la solucin integral. En tal caso, los
mismos analistas encargados del desarrollo computacional del sistema de informacin deberan encargarse del desarrollo completo del modelo integral
del cambio entonces cobra especial relevancia la
formacin del analista de sistemas19.
Un analista de sistemas debiera tener la
capacidad de trabajar en la mesa
completa.
Otro aspecto es la necesaria coordinacin entre las
actividades de cada elemento de la solucin, se requiere una malla completa (CPM, Gantt o alguna
herramienta computacional de apoyo en administracin de proyectos) que permita visualizar el proyecto
integral y resolver aspectos de precedencia, holgura
y ruta crtica.

3.8. Ingeniera de requerimientos


Habiendo planteado el modelo integral del cambio,
se especifican requerimientos en cuatro mbitos
principales: personas, procesos, estructura organizacional y tecnologa, porque sern los que llevarn
19

Ver libro Anlisis de Sistemas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

133

adelante el cambio. Son diferentes ramas de la solucin. Por supuesto, trabajar en estos mbitos no excluye el trabajo en otras materias funcionales o de
desarrollo, tal como finanzas, marketing, logstica,
etc. Son mbitos relacionados que deberan estar
contemplados en el proyecto. Es vital la coordinacin entre los equipos de trabajo que los aborden.
El inicio del planteamiento de
requerimientos supone conocida la
estrategia del proyecto y de la empresa y
que ambas estn alineadas.
Se definen requerimientos para:
1. Personas: Planes detallados de seleccin, preparacin, capacitacin, anticipacin, participacin,
ambiente de trabajo, formas de interaccin, etc.
2. Procesos: Descripcin del nuevo flujo de trabajo
del o los procesos relacionados.
3. Estructura: Detalle de la nueva estructura organizacional, planes y propuestas detalladas de externalizacin, delegacin, trabajo en equipo, etc.
4. Tecnologa: definiciones de procesamiento de
datos, comunicacin, transporte, almacenamiento,
construccin, despacho, automatizacin de oficinas, telefona interna, etc. y, en especial, con la
tecnologa de informacin. Se efectan mediciones de dimensionamiento para la incorporacin
del nmero previsto de usuarios.
Todo comienza desde la rama de los
procesos.

134

JUAN BRAVO

Se incluye detalle de la rama tecnolgica utilizando


UML.

3.9. Definiciones de la TI
Se plantean detalladamente aqu las definiciones de
la tecnologa de informacin propias del sistema de
informacin en desarrollo, ms bien de la parte
computacional del sistema de informacin, por eso
desde esta fase en adelante se habla tambin de sistema computacional.
Es recomendable incorporar aqu algunos de los
aprendizajes de ITIL (ver anexo 8).

3.10. Entorno Tecnolgico


Se requiere el dimensionamiento de equipos computacionales, software y comunicacin. Esto significa
incluir mapas de la arquitectura de redes y de comunicacin.
Es cierto que el anlisis y el diseo son independientes de la implementacin tecnolgica, tambin es
cierto que los sistemas se ubican en un cierto contexto.
Las definiciones principales del entorno tecnolgico
deberan venir desde la etapa de factibilidad, especialmente si tenan algn impacto en el costo del
sistema.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

135

El entorno tecnolgico contempla todo lo


relativo a la disponibilidad de las
herramientas de software y hardware, tal
como preparacin de propuestas y
contratos, plan de adquisicin,
financiamiento, etc.
Debe revisarse al menos:

Arquitectura de software
Arquitectura de hardware
Herramientas de programacin
Herramientas de verificacin de cdigo
Herramientas de control de versiones

3.11. Supuestos
Indicar aquellas cosas cuya verdad se supone, por
ejemplo:
La gerencia de personal asignar espacio fsico
para la realizacin de la capacitacin.
El departamento de informtica proveer los
equipos necesarios en el plazo convenido.
La gerencia comercial tendr disponible a una
persona clave en tal fecha.
En el fondo, se trata de identificar afirmaciones que
tienen algn nivel de riesgo, para tomar las medidas
correspondientes. Recurdese que si algo puede
fallar, fallar.
En esta etapa el nivel de negociacin es amplio. Se
logran consensos, acuerdos y compromisos para ser

136

JUAN BRAVO

cumplidos en la etapa de implementacin, la cual


est muy lejos todava. Sucede a veces que las personas tienen dificultades con los compromisos y al
momento de implementar es necesario entrar a otro
proceso de negociacin. Por ejemplo, la persona que
el gerente comercial haba comprometido para el
prximo mes fue destinada a ciertas labores urgentes
y ya no est disponible Y tambin al exterior, como cuando se ofrece un producto o una tecnologa
para tal fecha y no llega
En la etapa de anlisis debemos hacer
explcitos los acuerdos logrados, porque
son parte integral de la solucin.
En fin, esta es la realidad del trabajo en las organizaciones y para facilitar las negociaciones es preferible dejar explcitos los supuestos y tener algn nivel de plan de contingencia.

3.12. Identificacin de los usuarios


Se debe identificar a todos los usuarios, sean directos
o indirectos. Ejecutivos o Profesionales. Internos o
externos.
Tambin los usuarios operativos, es decir, quienes
debern hacer cambios en sus rutinas de trabajo, los
afectados con la aplicacin.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

137

3.13. Sistema de codificacin


Es totalmente aplicable lo indicado en el libro Desarrollo de sistemas de informacin, una visin prctica, pginas 68 a 72. Esencialmente trabajar con cdigos estndares como el RUT o el cdigo de barras de
productos de supermercado y si no es posible, con un
cdigo numrico lo ms simple posible. Como ltima
opcin y si realmente se justifica (el autor no lo ha
visto hasta hoy) utilizar un cdigo compuesto.

3.14. Requerimientos computacionales


En lo que se refiere a la definicin de requerimientos
para un sistema computacional, utilizaremos aqu
varios diagramas de UML (Unified Modeling Language / lenguaje unificado de modelamiento):
Planteados en el espritu de este mtodo
de trabajar con el mnimo indispensable,
para que efectivamente pueda ser aplicado
en la mayora de las organizaciones.

Diagrama de casos de uso


Caso de uso de alto nivel
Caso de uso expandido
Modelo conceptual
Diagrama de secuencia del sistema
Visin dinmica del sistema
Diagrama de estado
Contrato

JUAN BRAVO

138

Mayor informacin y otros diagramas de UML se


pueden encontrar en los anexos 2 y 3, acerca de
UML y RUP, respectivamente.

Ntese que este mtodo no trata en


profundidad acerca de UML, sino que
solamente toma lo necesario para aplicar
en el mtodo genrico de desarrollo de
Sistemas de Informacin aqu expuesto.
Su uso se restringe a la especificacin de requerimientos para fines del desarrollo de sistemas computacionales, an conociendo que tambin podran
aplicarse a representar realidades con otros fines.
En consecuencia y al igual que otras materias, la
descripcin de UML contenida en este mtodo es
breve.
Los modelos indicados se describen a continuacin:

3.15. Diagrama de casos de uso


El diagrama de casos de uso representa una agrupacin de casos de uso, por ejemplo, todos los casos de
uso que tienen relacin con un proceso incluido en
el flujograma de informacin.
En l cada actor puede interactuar con ms de un
caso de uso.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

139

En el ejemplo se presenta un Diagrama de Casos de


Uso para un mbito de adquisiciones20.
E je m p lo d e u n D ia g ra m a d e C a so s d e U so d e l
re a d e A d q u isicio n e s (O /C = O rd e n d e C o m p ra )

C o tiza d o r

T e rm in a le s d e l re a d e A d q u isicio n e s

C o tiza r

A p ro b a r
co tiza ci n

Je fe d e
A d q u isicio n e s

A d m in istra tiv o d e
A d q u isicio n e s
In g re sa r O /C

A p ro b a r
O /C

E n v ia r O /C

3.16. Caso de uso de alto nivel


Los casos de uso de alto nivel incluyen a un actor o
varios actores (que pueden ser personas u otros sistemas computacionales identificados con el smbolo
tipo dibujo de nio), tambin un dominio (en este
20

Cuando se realizan talleres del mtodo, un ejercicio tpico para


este diagrama es solicitar construir un FI y un Mapa de Procesos.

JUAN BRAVO

140

caso el terminal en bodega), una accin con un verbo en infinitivo en el valo y una descripcin breve
de la situacin bajo el valo..
El caso de uso de alto nivel se caracteriza porque la
narracin es breve. Permite conocer un poco del requerimiento, algo de la accin, actor(es) y dominio.

E je m p lo d e ca so d e u so d e a lto n ive l
In g re sa r O rd e n d e C o m p ra (O /C )
T e rm in a l e n b o d e g a

A d m in istra tiv o d e
A d q u isicio n e s

In g re sa r O /C

In g re sa la O rd e n d e C om p ra a
p a rtir d e lo s d o cum en to s d e
co tiza ci n a p ro ve e d o re s,
L a O /C q u e d a d isp o n ib le p a ra
se r e n via d a a l p ro ve e d o r lu e g o
d e a p ro b a ci n e le ctr n ica p o r e l
je fe d e A d q u isicio n e s

Al trabajar con desarrollo en espiral, se espera que el


universo completo de casos de uso est descrito en
alto nivel o como diagramas de casos de uso.
Entonces, los casos de uso seleccionados para la
respectiva vuelta de la espiral se transforman en casos de uso expandidos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

141

3.17. Caso de uso expandido


El caso de uso expandido incluye una narracin en
todo detalle e incluye las interfaces visuales. Recurdese que se usa aqu el concepto de curso normal de los eventos, las excepciones se anotan al
final para no romper la secuencia de la historia.
Por ejemplo, Ingresar O/C (Orden de Compra):
C aso de uso expandido

T erm inal del A dm inistrativo de A dquisiciones

A dm inistrativo de
A dquisiciones

Ingresar O /C

R esu m en : (el m ism o del caso de uso de alto nivel). F u n cio n es relacio n ad as: ...
C u rso N o rm al d e lo s e ven to s
A cci n d el acto r:
1. T om ar la O /C desde el archivador
2. Ingresar N O /C en (A )
3. Ingresar R ut en (D )
6...
P ara cada lnea:
7. Ingresar el cdigo de producto
en (H )
9. Ingresar las unidades en (K )
10. D ar O K a la lnea
...

R esp u esta d el sistem a


...
3. V erifica correlativo y enva respuesta en (B )
5. V erifica que proveedor exista, obtiene y
despliega nom bre y fono en (E ) y (F )
P ara cada lnea:
8. V erifica existencia del producto, obtiene
y despliega la descripcin y el precio en (I)
y (J)
10. C alcula el subtotal y despliega en (L)
11....
...

E xcep cio n es: 1. S i el nm ero de O /C ya existe, vea caso de uso C orregir C orrelativo. 2...
A d ju n ta: Interfaces detalladas de E /S

Las letras (A, B) entre parntesis identifican la ubicacin


del respectivo campo en la interfase visual.

142

JUAN BRAVO

Tiene dos columnas: accin del actor y respuesta del


sistema, las excepciones van aparte. No siempre una
accin del actor tiene respuesta del sistema, como la
accin 1: Tomar la O/C desde el archivador (que
est en algn mueble cercano).
El caso de uso se complementa con una copia del
documento Orden de Compra (O/C) y de la Interfaz
de la pantalla, donde los campos se indican con letras maysculas.

3.18. Modelo Conceptual


El modelo conceptual define responsabilidades y el
dominio del sistema computacional, al comienzo
asociado a los casos de uso identificados. Es un modelo que se va construyendo en paralelo con los casos de uso.
Identifica los conceptos ms relevantes del mundo
real en el dominio respectivo: roles de personas, tipos de documentos, elementos fsicos, etc. Tambin
identifica las asociaciones entre conceptos con palabras de enlace: usa, registra en, almacenado en, pagado por, contenida en Se trazan lneas entre los
conceptos para representar este detalle.
En esta etapa, una recomendacin es incorporar en
el modelo el mximo de conceptos y el mnimo de
asociaciones.
Las caractersticas del modelo conceptual son muy
similares al modelamiento tradicional de datos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

143

En las asociaciones entre los conceptos se da multiplicidad o cardinalidad.


Se expresa de la siguiente forma:
*
: cero o ms (muchos)
1..* : uno o ms
1..12 : de uno a doce
3
: exactamente 3
2, 4, 9 : exactamente 2, 4 9
Siguiendo con nuestro ejemplo de la Orden de compra, el modelo conceptual tendra esta forma:

E je m p lo d e M o d e lo C o n ce p tu a l,
co n ce p to s y a so cia cio n e s
E n ca b e za d o
d e O /C
c o m p u e s ta p o r

s e a s o c ia a

c o n tie n e

e x is te e n

P ro ve e d o re s

1 ..*

L n e a s d e la
O /C

c o n tie n e

e x is te e n

P ro d u cto s

1
e x is te e n

a lm a c e n a

Bodega

JUAN BRAVO

144

Se puede apreciar que:


Una O/C est compuesta por 1 ms lneas de
O/C. A su vez, una lnea de O/C se asocia a un
solo encabezado de O/C.
Un encabezado de O/C contiene un proveedor.
Un proveedor existe en 0 ms encabezados de
O/C.
Una lnea de O/C contiene un producto. Un producto existe en 0 ms lneas de O/C.

Un producto existe en 1 bodega. Una bodega


almacena 0 ms productos.

Obsrvese que aparece, con un rombo negro, una


asociacin de composicin, equivalente a la relacin
de pertenencia (que se marca con una lnea ms
gruesa) del modelamiento de datos21. En la composicin, tambin llamada unicidad, una lnea de la
O/C no puede existir sin su encabezado, y viceversa.

21

Ver libro La Nueva Visin, Diseo y Construccin de Sistemas


Computacionales.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

145

En los conceptos tambin existen atributos, tal como


se aprecia en el siguiente modelo:
E je m p lo d e M o d e lo C o n ce p tu a l,
co n ce p to s, a so cia cio n e s y a trib u to s
E n ca b e za d o
d e O /C
N O /C
F e ch a
c o m p u e s ta p o r

s e a s o c ia a

c o n tie n e

e x is te e n

P ro ve e d o re s
Rut
N o m b re

1 ..*

L n e a s d e la
O /C
u n id a d e s
p re cio

c o n tie n e

e x is te e n

P ro d u cto s
...
e x is te e n

a lm a c e n a

Bodega
...

3.19. Diagrama de secuencia del sistema


El objetivo del diagrama de secuencia es identificar las
operaciones del sistema, las que luego darn origen a
los mensajes y en general, al protocolo del sistema.
Con base en la narracin realizada en el caso de uso, se
identifican las operaciones del sistema, aquellas que
obligarn al sistema computacional a hacer algo y que
afectarn a uno o ms conceptos de aquellos incluidos
en el modelo conceptual.
En la siguiente figura se muestra la forma general
del diagrama de secuencia para un caso de uso don-

JUAN BRAVO

146

de se est ingresando una Orden de Compra (O/C).


Suponemos que se obtuvieron esas operaciones desde la narracin del caso de uso.
D ia g ra m a d e S e c u e n c ia p a ra e l c a s o d e u s o In g re s a r O /C
A c to r

A d mA
in is tra tiv o

S is te m a
S is te m a c o m o u n a c a ja n e g ra

In g re s a r N d e O /C

In g re s a r c d ig o d e p ro d .
R e p e tir h a s ta
q u e n o h a ya m s
p ro d u c to s

In g re s a r c a n tid a d

D a r O K a la ln e a
O p e ra c i n (o m e n s a je )
q u e a c tiv a u n a o m s
fu n c io n e s e n e l s is te m a

N o ta : c o n e s ta le tra
s e h a c e n a c la ra c io n e s
a l d ia g ra m a

Qu es una operacin? Una operacin es un mensaje, un mandato para que algo se ejecute, provoca
que algo suceda fuera de la frontera del caso de uso.
Al principio el sistema computacional se ve como
una caja negra (todo el sistema est representado por
la columna Sistema). Sin embargo, en la medida que
se avanza en el detalle de los requerimientos, la columna Sistema se abre en otras: los conceptos, producindose una estructura de mensajes.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

147

3.20. Visin dinmica del sistema


Este diagrama es un resumen de las operaciones del
sistema, la grfica sugiere que al unir esta funcionalidad con el modelo conceptual, lograremos algo
central de la orientacin a objetos22: el encapsulamiento, es decir, tener en un slo todo (clase u objeto) tanto los atributos como los mtodos. Est bien,
pero estas son llamadas o mensajes que llegarn
probablemente a varios conceptos (o clases).
V isi n d in m ica d e l S iste m a
S iste m a

C a so d e u so
A p ro b a r co tiza ci n

In g re sa r N d e co tiza ci n
D a r O K a l d o cu m e n to
...

C a so d e u so
In g re sa r O /C

In g re sa r N d e O /C
In g re sa r c d ig o d e p ro d u cto
In g re sa r ca n tid a d
D a r O K a la ln e a

C a so d e u so
A p ro b a r co tiza ci n

In g re sa r N d e O /C
D a r O K a l d o cu m e n to
...

Notas:
1. Las operaciones del sistema y el diagrama de secuencia
son uno a uno con el caso de uso.
2. Tanto el diagrama de secuencia como la visin dinmica
del sistema tienen las mismas operaciones, ms bien lla22

Ver libro La Nueva Visin, Diseo y Construccin de Sistemas


Computacionales.

JUAN BRAVO

148

madas a operaciones, porque corresponden a estructura de


mensajes del diagrama de clases (que ya veremos).
3. La nomenclatura es la de Orientacin a objetos
4. Los mensajes de la visin dinmica del sistema son mensajes que llegarn a varias clases, cada una de las cuales
tiene la estructura de atributos y funciones.

Cuando se trata del primer caso de uso que estamos


desarrollando en una aplicacin, el diagrama de secuencia y la visin dinmica son iguales, desde el
segundo se diferencian porque la visin dinmica es
acumulativa, va agregando las operaciones de los
diferentes casos de uso.

3.21. Diagrama de estado


El diagrama de estado de los casos de uso representa
grficamente el estado del caso de uso antes y despus de cada una de sus operaciones.
E je m p lo d e D ia g ra m a d e E sta d o . C a so d e u so IN G R E S A R O /C

In g re sa r ln e a d e O /C

E n e sp e ra d e la O /C

In g re sa r N d e O /C

In tro d u cci n d e ln e a s

T e rm in a r la O /C

Im p rim ir la O /C

E n e sp e ra d e l cie rre

Son diagramas poco utilizados en el mbito de la


gestin de proyectos de procesos y tecnologa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

149

No los usaremos en el mtodo, sin embargo, hemos


preferido incorporarlos por si en alguna implementacin particular se les considera de beneficio.

3.22. Contratos
Los contratos detallan cada operacin y existirn
tantos como operaciones se hayan identificado en el
caso de uso y detalladas en el diagrama de secuencia. Tienen la siguiente estructura:
C o n tra to
Id en tificacin : nom bre de operacin y parm etros
R esp on sab ilid ad es : descripcin inform al de las
responsabilidades u objetivos de la operacin
T ip os d e d atos: conceptos que afecta o clases
R eferen cias cru zad as : enlaces con otras funciones
del sistem a o casos de uso.
N otas: indicaciones para diseo, algoritm os (tal
com o el clculo de dgito verificador) y otros datos.
E xcep cion es: qu sucede si...? y otros casos
excepcionales.
S alid a : M ensajes o registros que se envan fuera
del sistem a.
P recon d icion es: S upuestos acerca del estado del
sistem a antes de ejecutar la operacin.
P oscon d icion es: Indicacin de com o qued el
sistem a despus de la operacin.
P oscondicin 1 ...
P oscondicin 2 ...
P oscondicin n ...

Una clave para entender los contratos son las poscondiciones, es decir, como qued el sistema despus que se ejecut la operacin. Es como la fotografa que se toma despus de un suceso. Veamos el
siguiente ejemplo:

JUAN BRAVO

150

E je m p lo d e C on tra to
Id en tificacin : D ar O K al ingreso de la lnea
R esp on sab ilid ad es : con cada ingreso de lnea los
conceptos deben ser consistentes.
T ip os d e d atos: afecta a los conceptos E ncabezado
de O /C y D etalle de O /C .
R eferen cias cru zad as : no hay
N otas: nada especial
E xcep cion es: la no existencia de la lnea en el
sistem a ya fue validada con el ingreso de O /C .
S alid a : no hay
P recon d icion es: no existe la lnea.
P oscon d icion es:
S e cre una lnea en el concepto detalle.
S e actualiz el contador de lneas en el
encabezado.
S e actualiz la asociacin entre encabezado y
detalle de O /C .

Se identific, en tiempo verbal pasado, cmo fueron


afectados los conceptos tras la operacin (poscondiciones). Un contrato sin poscondiciones es una alerta de error, tal vez en la definicin de la operacin.

3.23. Interfaces usuario sistema


Se trata de incluir una descripcin de formularios,
informes, pantallas y mens. As como se cuenta con
una descripcin detallada de los requerimientos de
usuario en base a la tcnica casos de uso, lo mismo
ocurre con el diseo de la interfaz.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

151

Como una visin de conjunto de la definicin de


interfaces, sera necesario:
Describir los objetos de la interfaz de usuario ms
relevantes de la aplicacin, tales como: Calendarios (tipo cartas Gantt), barras de disponibilidad
(0% al 100%), parrillas (grid), combo-boxes, menu-bars, scroll-bars, push-buttons, etc.
Preparar el esquema de pantallas segn estndares
Disear las interfaces segn el tipo de usuario
Disear la jerarqua de opciones
Ordenar los procesos
Preparar ayudas en lnea
Es importante el apoyo que pueden
prestar profesionales de marketing,
diseo, periodismo, sicologa, sociologa y
otras profesiones en el diseo de intefaces.

3.24. Prototipos desechables


En esta etapa solamente para ayudar en la definicin
detallada de funcionalidad principal e interfaces visuales, tales como formatos de pantallas, informes y
mens. Una vez que los prototipos ha cumplido esta
finalidad, son eliminados.

3.25. Revisin de los modelos


Con la finalidad de avanzar en el aseguramiento de la
calidad, es recomendable que el trabajo de modela-

152

JUAN BRAVO

miento sea revisado por los pares del analista o por


otros profesionales, internos o externos.

3.26. Uso de herramientas


Especialmente para UML, existe una amplia gama
de herramientas en el mercado que ayudan en los
modelos indicados (Visio, Rational, UML Studio,
Enterprise Architect, etc.).
En la parte tercera una de las prcticas se refiere a
herramientas.
La recomendacin es usar herramientas
de apoyo, realmente facilitan el trabajo y
si el sistema es grande, son
indispensables. Adems, tienen la ventaja
de generar algunas partes del sistema en
forma automtica, por ejemplo, el cdigo.
Son adems vitales para la comunicacin de los modelos (generalmente en XML, eso es interno).

3.27. Costo del proyecto


La etapa concluye con la segunda estimacin de costos del proyecto.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

153

ETAPA 4. DISEO
Lo que da origen a esta etapa es el Plan de proyecto
actualizado, el modelo integral del cambio y sus requerimientos.
El objetivo es obtener el detalle de la solucin completa que propone el modelo integral del cambio,
especialmente personas, procesos, estructura organizacional y tecnologa. Es el Cmo.
Tambin se denomina Ingeniera de Detalle a esta
etapa.
Entregable de la etapa: el detalle tcnico del modelo
integral del cambio.
~~
Se disean en detalle los componentes del
modelo integral del cambio.
El diseo detallado consiste en dibujar planos, preparar modelos, identificar los encargados, dimensionar los recursos financieros, definir el espacio fsico,
conocimientos requeridos, interacciones con el entorno, elaborar licitaciones y contratos, etc. Es el
desarrollo en detalle del modelo integral del cambio.
Esto es necesario aun en proyectos pequeos, igual
las personas que construirn o implementarn necesitan de una gua.
Se incorpora en esta etapa formalmente el aporte de
las especialidades en la forma de un trabajo conjunto
con los analistas del proyecto.

154

JUAN BRAVO

Trabajo conjunto con los especialistas


Durante esta etapa se trabaja con profesionales especialistas en cada mbito de la solucin. Principalmente lo relacionado con personas, procesos, estructura organizacional y tecnologa.
Ntese que se trabaja con y no se
entrega o delega el trabajo a
especialistas, porque se trata de un
trabajo conjunto.
En esta etapa normalmente se recurre a la asesora
especializada, porque hay que ir a los detalles, probablemente empleando simbologa y terminologa
ms precisa. Algunas sugerencias son:
Trabaje en conjunto con el especialista hasta obtener el resultado deseado, porque habr mucha
labor de afinamiento y perfeccionamiento sucesivo, adems, una vez que el especialista se retire,
usted deber seguir manteniendo la solucin.
Evite la dependencia total y no se deje amedrentar por la erudicin, las sofisticaciones o la especializacin. Un buen profesional no hace alarde
de sus conocimientos y tiene la capacidad de explicar materias complejas con simplicidad.
Conserve la visin de conjunto y asegrese que
los equipos de trabajo dedicados a diferentes partes de la solucin estn plenamente coordinados.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

155

Ms importante que una supercreacin tecnolgica,


de estructura o de flujos de procesos, es desarrollar
armnicamente la solucin.
Muchos proyectos han fracasado porque
cada mbito de accin fue tomado por
separado.

4.1. Diseo de procesos


En esta etapa del ciclo de desarrollo de un proceso
se trabaja en la preparacin detallada de cada elemento de la solucin y la forma de implementar,
esencialmente el diseo de:
El nuevo flujo del proceso con nombres de encargados y recursos
Procedimientos en detalle.
El plan de capacitacin y de implementacin
Las nuevas labores a realizar
El ambiente fsico y cultural
La nueva estructura organizacional
La red de comunicacin
El detalle de equipamiento y software
Tambin desde el punto de vista de los riesgos:
Cul es el costo futuro de un mal diseo?
Cul es el costo futuro de no hacer diseo?

156

JUAN BRAVO

Algunas caractersticas del buen diseo


Las caractersticas prcticas del buen diseo fueron
pensadas para las partes ms tcnicas del rediseo
de procesos, sin embargo, veremos que son aplicables en toda la gama de mbitos del diseo23.
Digamos primero que existen caractersticas universales del diseo de productos y servicios, por lo dems evidentes, como abstraccin, amistosidad,
flexibilidad, portabilidad, impersonalidad, factibilidad, etc... Se supone que ellas son conocidas.
En particular, el diseo que se est
realizando debe tener posibilidades
concretas de ser implementado, con
recursos acotados y herramientas
disponibles.
Este conjunto de orientaciones son independientes
de la implementacin.
Intuicin. El diseo es una tarea eminentemente
creativa, por lo tanto, la intuicin juega un rol preponderante. Esto se puede interpretar como de
acuerdo con el sentido comn o percepcin. Qu es
la intuicin? Hay quienes dicen que es una de las
voces de la conciencia... Es esa sensacin de incomodidad, de que algo sobra o algo falta en el modelo. Si hacemos caso de la intuicin, veremos que tal

23

Ms detalle de las caractersticas de buen diseo en el libro La


Nueva Visin, diseo y construccin de Sistemas Computacionales

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

157

vez algo cambi en la realidad o existe un problema


de enfoque que verdaderamente afecta al diseo.
Tambin la intuicin se manifiesta en nuestra habitual prctica de tomar decisiones con informacin
incompleta.
Simplicidad. Habitualmente, la elegancia va de la
mano con la simplicidad, es ms, se podra plantear
la siguiente regla: si el diseo se ve complicado,
hgalo otra vez. Solamente hay que darse por satisfecho cuando el diseo es y se ve fcil de entender,
lo cual puede llevar bastante esfuerzo, pero es una
excelente inversin.
La simplicidad tambin se refleja en mantener una
solucin limpia, sin particularizaciones innecesarias ni ingeniosidades.
Existe simplicidad en el diseo cuando lo
entienden los dems, incluyendo
especialmente al usuario y cuando se
siente que es simple.
Totalidad. El diseo del proceso debe considerar
todos los elementos, aun cuando algunas partes sean
incorporadas slo para conservar la visin de conjunto, sin llegar a un nivel profundo de detalle. La
totalidad responde a la necesidad de una visin
holstica del problema. Lo importante es captar la
realidad y llevarla a los modelos.
Generalizacin. Cada problema, apropiadamente
planteado, no es ms que un caso particular de un

158

JUAN BRAVO

problema general ms fcil de resolver. As se hace


inversin en inteligencia, porque los nuevos problemas particulares que se vislumbran ya estarn
resueltos. Es un signo de inteligencia no resolver
siempre los mismos problemas. Esto significa buscar
el metaproblema, aqul que representa a todos los
problemas del mismo tipo.
Transacciones presentes para la actualizacin de la
informacin
En la gestin de procesos hablamos de transacciones, ya sean ventas, compras, crditos, traspasos de
productos, etc. En esta etapa se disea en detalle el
juego de transacciones del proceso. Por ejemplo, no
es suficiente con disear la forma en que se realizar
la venta y la factura correspondiente, tambin es vital considerar como se actualizar la informacin
cuando se requiera corregir informacin (factura
errnea). En este caso mediante transacciones de
notas de crdito, dbito o ajustes.
Lo importante aqu es la trazabilidad, que
se pueda seguir la pista de cmo se van
actualizando los datos, siempre mediante
transacciones formales, jams
interviniendo en forma directa un archivo.
Incluso en la interaccin con los especialistas de
informtica, es importante para efectos de la seguridad e integridad de la informacin que ellos no tengan privilegios especiales.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

159

La forma ms habitual del procesamiento computacional de transacciones es actualizar maestros, de


clientes, proveedores, productos, etc. stos van modificando sus datos en la medida que las transacciones los afectan. Qu sucede cuando se descubre un
error en la factura emitida ayer y que ya afect a los
maestros de inventarios y de cuentas contables? Una
solucin generalizada es arreglar a mano los
maestros involucrados, significa intervenir directamente el resultado en el maestro; por ejemplo, incrementar el inventario en dos unidades. Esto tiene
muy altos costos, porque, si fuera necesario reprocesar a raz de una cada del sistema, todos los arreglos efectuados a mano no se podran reproducir y
los archivos quedaran inconsistentes Es evidente
que se pasan a llevar normas elementales de calidad,
trazabilidad, control y auditora.
La solucin es aplicar otra transaccin formal, una
transaccin presente que revierta la anterior; en el
ejemplo, puede ser una nota de crdito. Qu sucede
si la correccin est incorrecta? Se hace una transaccin de ajuste. Esto significa definir el siguiente
juego de operaciones: transaccin original, contratransaccin y ajuste.
As, se da una lnea continua en el tiempo
y nunca se vuelve al pasado.
Todo esto debe estar contemplado en el diseo, as
como aspectos de auditora, seguridad, integridad y
recuperacin del proceso.

160

JUAN BRAVO

Calidad de la informacin
Algunos principios respecto al manejo de datos:

se ingresa una sola vez,


con todas las validaciones necesarias,
en el punto de origen,
por su mismo dueo,
se almacena en forma no redundante,
siguiendo modelos por todos conocidos y
la puede usar cualquier usuario autorizado.

Un aspecto crtico del trabajo a realizar


en diseo, es asegurar la calidad del
manejo de informacin en el proceso,
donde existen mltiples frmulas, ya sea
aumentando oportunidad o confiabilidad,
tal como al aplicar mxima validacin de
los datos en el momento que ingresan al
computador.

4.2. El diseo del software


Especficamente en el diseo del software se trabaja
en: modelos de datos, identificacin de clases: modelos generalizados, diagrama de clases del sistema,
visin interna con diagramas de clases y objetos y
diagramas de colaboracin, entre otros modelos.
En esta propuesta de procesos y tecnologa se trabaja
con UML.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

161

Se trabaja en paralelo con las otras ramas del modelo integral del cambio, por los mismos u otros profesionales segn la envergadura del proyecto.
Suponemos como punto de entrada a esta etapa que
se dominan tcnicas de ingeniera de software, tales
como:

Planificacin informtica
Modelamiento de datos
Modelamiento de funciones
Auditora computacional
Caractersticas de buen diseo
Modos de procesamiento
Calidad y productividad en el desarrollo de
software
Orientacin a objetos
UML
Se utiliza la biblioteca de clases, la orientacin a
objetos y las herramientas de apoyo.
Aqu se define en detalle todo el sistema
de seguridad, integridad y recuperacin
de la informacin.

4.3. Diagrama de Diseo de Clases


El modelo de UML que se emplea para representar
las relaciones entre las clases es el Diagrama de Diseo de Clases. Corresponde a la visin interna de la
aplicacin.

JUAN BRAVO

162

Clase es una abstraccin que no tiene una implementacin tecnolgica. Se aplica a nivel del modelamiento y sirve para identificar y darle sus elementos a los objetos que de ella derivan; por ejemplo,
los objetos clientes y proveedores derivan de la clase
personas y heredan de ella sus elementos comunes.
Nace desde el modelo conceptual e incorpora las
funciones necesarias para cumplir con el objetivo de
los casos de uso.
Por ejemplo:
E n ca b e za d o d e
O /C
N O /C
F e ch a

P ro v e e d o re s
c o n tie n e
*

e x is te e n
1

Rut
N o m b re
C re a r p ro v e e d .
M o d ifica r R u t
M o d ifica r n o m .

C re a r ln e a
Im p rim ir
1

s e a s o c ia a

1 ..*

L n e a s d e la
O /C
u n id a d e s
P re cio

c o n tie n e
*

e x is te e n
1

P ro d u cto s
...

e x is te e n

A g re g a r ln e a
a lm a c e n a

*
1

Bodega
...

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

163

Identificacin de clases
Esencialmente se trata de modelos generalizados.
La idea general en el desarrollo de sistemas de informacin es reutilizar componentes validados, que
fueron pensados y desarrollados con ese fin, aunque
tambin puede suceder que en el transcurso del
avance en un proyecto especfico un mdulo particular sea candidato a generalizarse, es decir, a transformarse en una clase.
Igual en ambos casos se aplica el proceso de generalizacin, como un desarrollo paralelo a las aplicaciones especficas y que probablemente lleva a cabo
un equipo de desarrollo ad-hoc, validando e incorporando clases a una biblioteca de clases.
En particular, se trata de responder a
qu clases podemos utilizar? Ya sea de la
misma instalacin o del medio. El sueo
es tener todas las clases disponibles y
solamente utilizarlas.

4.4. Diagrama de colaboracin


Para cada operacin del caso de uso seleccionado se
presenta un diagrama de colaboracin y detalles de
implementacin24 (cmo implementar?).
24

En este mtodo de desarrollo aplicamos la tcnica de espiral,


donde se diluye un poco la independencia de la implementacin
tecnolgica, por este motivo se prefiere avanzar en caractersticas de
la implementacin a nivel del diseo.

JUAN BRAVO

164

Diagrama de colaboracin: cada operacin detallada en un contrato se desarrolla en detalle sealando las solicitudes (o pedidos) entre objetos
(principalmente del modelo de datos y pantallas).
Detalles de implementacin: se responde a qu
clases podemos utilizar? Ya sea de la misma instalacin o del medio, es decir, hacer una revisin
de la biblioteca de clases25 (que en un esquema de
orientacin a objetos es un requisito), por ejemplo, la condicin de existencia. Corresponde al
detalle de cada clase e instancias (objetos) especficas en una tabla de diferencias.

Por ejemplo:
D ia g ra m a d e C o la b o ra ci n
O p e ra ci n : D a r O K a l In g re so d e la ln e a d e O /C
In g re sa r p ro d u cto
(c d , ca n t, p re )

T e rm in a l d e l
a d m in istra tivo

1 : C re a r lin e a d e O /C
(co d , ca n t, p re )

E n ca b e za d o
d e O /C

1 .1 : C re a r (co d , ca n t, p re )

L n e a s d e la
O /C

25

Se supone la existencia de la biblioteca de clases para efectos de


este mtodo.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

165

4.5. Visin externa


Es la arquitectura del sistema, incluye:
Diseo de la Interaccin con los otros sistemas
existentes
Definir el flujo de transacciones: matriz maestrostransacciones
Modelo de datos normalizado y generalizado
(clases)
Modelo funcional generalizado (clases): con detalle de atributos, mtodos y operaciones.
La forma general del diseo quedara as:
slo con clases y mensajes. Aqu el trabajo
sera de integracin de clases para
construir la aplicacin y un indicador
clave es el % de uso de cdigo reutilizable
(desde la biblioteca de clases).

4.6. Entorno de la aplicacin


Es fundamental ofrecer definiciones acerca de:
a) Mens
b) Modelo de dos o tres capas segn las plataformas
y definiciones de la instalacin, por ejemplo, para
tres capas:
Forma de manejo de la interfaces con el usuario
(para preparar cdigo de presentacin).
Forma de incorporacin de la lgica del negocio
(para preparar cdigo de procesamiento de datos).

166

JUAN BRAVO

Verificar consistencia y completitud de la base de


datos, as como la forma de administracin de los
datos (para preparar cdigo de almacenamiento
de datos).
c) Describir los objetos utilizados para implementar
interfases, lgica de la aplicacin, interaccin con
otros sistemas computacionales o formas de acceso a la informacin.

4.7. Costo del proyecto


La etapa concluye con la tercera estimacin de costos del proyecto.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

167

ETAPA 5. IMPLEMENTACIN
Esta etapa nace desde el Plan de proyecto actualizado, el modelo integral del cambio y sus requerimientos y el diseo (o ingeniera de detalle) de la solucin.
El objetivo es llevar a la prctica la solucin completa que propone el modelo integral del cambio,
armonizando todas sus partes (estrategia, personas,
procesos, estructura organizacional y tecnologa).
Se concluye en un aplicacin real aunque en carcter
piloto.
Entregable de la etapa: el informe de buen funcionamiento del piloto del proyecto.
~~
Se trata de implementar (tambin
construir, realizar o llevar a la prctica)
la solucin completa que propone el
modelo integral del cambio, aunque para
el piloto previsto.
Algunas acciones de la etapa:
Las personas son capacitadas y reubicadas.
Se implementan las nuevas definiciones de
los procesos.
Se aplica la nueva estructura organizacional.

JUAN BRAVO

168

Se instala la aplicacin de software, probablemente en variadas mquinas.


En particular, veremos la implementacin desde el
punto de vista de procesos y Tecnologa de Informacin (TI) las cuales normalmente avanzan de manera
ms bien en paralelo que secuencialmente.
Llevar a la realidad
Implementar significa llevar a la realidad el diseo, ya sean planos de un edificio, plan de capacitacin, flujos de informacin, formularios, apoyo
computacional, una poltica acerca de las personas o
el diseo de un estructura organizacional.
Implementar tambin implica
retroalimentar el diseo sobre aspectos no
contemplados con anterioridad.
Es necesario asegurar paso a paso que efectivamente
la solucin cumple su objetivo. La flexibilidad es
fundamental para efectuar las correcciones que sean
necesarias sobre el plan original. La participacin y
capacitacin de todos los interesados, as como el
manejo del cambio son vitales en esta etapa.
Otras actividades de esta etapa son:
Completar la documentacin.
Comunicar el avance a todas las personas relacionadas con el cambio en los procesos.
Capacitar por niveles en forma oportuna, cuidando de no recargar a las personas en esta actividad,

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

169

es necesario dimensionar apropiadamente el


tiempo de las personas.
Una forma de motivar la capacitacin es fomentando el equilibrio de costos entre todos los factores de incidencia en un proyecto. Hay empresas
donde se han efectuado inversiones de cientos de
miles de dlares en equipamiento que ha quedado
abandonado debido a que el proyecto no contemplaba gastar algunos miles de dlares en capacitacin.

5.1. Negociar los compromisos


Parece un contrasentido, por qu negociar algo que
ya est comprometido? Porque la experiencia indica
que este es un factor crtico. Ahora que es necesario
llevar los planes a la prctica, sucede que personas
con que el analista contaba estn destinadas a otras
labores urgentes supongamos justificadamente.
Espacios fsicos que el analista saba que tendra, no
los tiene, porque hubo otras prioridades Un equipo computacional prometido para cierta fecha no
lleg Estos son los supuestos realizados en las
etapas de factibilidad y anlisis, para los cuales debieran existir planes de contingencia.
Es importante aclarar que negociar los
compromisos no significa permisividad ni
tolerar el incumplimiento de las tareas,
sino que se trata de simple adaptacin a
las contingencias del mundo.

170

JUAN BRAVO

Por lo dems, es casi seguro que muchas de esas


contingencias ocurrirn.
Se puede abordar este tema de los compromisos
acortando los tiempos de rediseo, es una razn por
la cual empleamos la tcnica de rediseo en espiral.
Otra forma es aprendiendo a negociar:
reiterando la actualidad de los objetivos
que dieron origen a los compromisos
asumidos, escuchando, intercambiando,
buscando nuevas posibilidades creativas.
Nada de esto estaba en los planes, aunque
s deberamos contar con que un
porcentaje de acciones programadas no se
realizarn, porque as es la vida y no es
por falta de voluntad de las personas.

5.2. Implementar los procesos


Algunas recomendaciones para la implementacin
de los procesos:
Mantener comunicacin con todos los actores
involucrados es esencial. Buenas experiencias se
han logrado con una o dos reuniones semanales
con representantes de los consultores que apoyan
el rediseo, el equipo asesor en metodologa, el
equipo interno de trabajo, el equipo de trabajo en
el mbito tecnolgico, los usuarios, la direccin
de la organizacin y proveedores especializados

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

171

de elementos de comunicacin o infraestructura,


solo por nombrar algunos interesados.
Mostrar resultados pronto para mantener el nivel
de entusiasmo los Quick Wins, una de las
prcticas transversales aunque con la precaucin de no abusar de esa va rpida porque el
grueso del rediseo y del apoyo computacional
tiene que seguir las formalidades metodolgicas
(el desarrollo en espiral es recomendable)
Tener la flexibilidad para resolver con rapidez los
inevitables problemas que se producirn, es ideal
tener una persona o un equipo de accin rpida.
Es aceptar y trabajar con la complejidad26.
Que esto no se confunda con
improvisacin ni que sea una excusa para
una mala planificacin, es simplemente
responder con variedad a la variedad
natural del medio, aquella difcil de
predecir.
Tener disponibilidad de los integrantes del equipo
de trabajo para con los usuarios. Es crtico en la
relacin con el usuario del proceso, es preferible
invertir en disponibilidad de personas que en mayor equipamiento tcnico (si se puede ambas cosas a la vez, mejor) tal como fue la experiencia de
BancoEstado ver anexo 7 donde a veces un
analista destinaba varios das de su tiempo a estar

26

El libro Anlisis de Sistemas aborda el tema de la complejidad de


los sistemas.

172

JUAN BRAVO

con el usuario hasta que ste se senta tranquilo


(mucho ms all de solamente capacitar).
En este caso se compens ese mayor costo con
ahorros en soluciones tecnolgicas ms sencillas.
Los resultados fueron realmente de excelencia.
Mantener verdaderamente puertas abiertas en el
equipo de trabajo. Todos los medios de comunicacin son necesarios aqu, as como la disponibilidad (ojal rotativa a diversas horas).
En un caso donde el lder del proyecto se fue de
vacaciones fuera del pas justo en el momento de
la implementacin el fracaso estuvo muy cerca.
Aplicar la estrategia tenaza comentada, corto plazo y largo plazo a la vez.

5.3. Implementar la TI
Si la solucin contempla una faceta de tecnologa de
informacin, la etapa se refiere a llevar el diseo a la
realidad, en un lenguaje especfico y en una mquina
determinada.
Muchas veces no hay construccin
propiamente tal, sino que el armado de
una solucin de software.
En esta etapa hay amplia utilizacin de cdigo reutilizable. Bajo el concepto de trabajo con clases se
utiliza una biblioteca de clases (que en un esquema
de orientacin a objetos es un requisito) herramientas de apoyo y variadas tcnicas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

173

Tambin se realizan mediciones de dimensionamiento para la incorporacin del nmero previsto de


usuarios (complementando las estimaciones de la
etapa de factibilidad).
Construccin de la aplicacin
En este mtodo, el grueso del trabajo de construccin se orienta a codificar las nuevas clases,
comnmente realizado por un equipo de especialistas dedicados exclusivamente a la generacin de
clases. A veces llamados desarrolladores.
Luego otro equipo usa esas clases, y otras desarrolladas con anterioridad para construir o referenciar el
cdigo especfico que requiere la aplicacin. Debiera ser un trabajo de integracin de clases ms que
realmente de codificacin. Es la forma de trabajo en
base a componentes. A veces se les llama integradores a estos profesionales.
Tambin se podra trabajar con
generacin de cdigo, utilizando una lnea
de herramientas tipo Genexus o LINC, es
una variante al trabajo con componentes
que tambin exploran las empresas

5.4 Probar
Hay una palabra que siempre acompaa a la implementacin, probar. Cada parte de la construccin
debe ser probada inmediatamente. Por ejemplo, en la

174

JUAN BRAVO

construccin de una casa resulta evidente que al


terminar el tendido elctrico y antes de efectuar terminaciones, nos aseguremos de su correcto funcionamiento.
Es necesario probar en detalle y con minuciosidad
progresiva todos los aspectos del proceso y de la
aplicacin, esto se puede hacer como si fusemos
abriendo cajas negras, es decir, desde menor a mayor profundidad y complejidad. Quin prueba? Hay
amplia variedad de posibilidades: las mismas personas que construyen, los analistas, un equipo interno
especializado en Testing, los usuarios y empresas
que ofrecen ese tipo de servicio.
Pruebas unitarias
Desde el punto de vista de TI, se realizan pruebas
unitarias por los mismos programadores.
Una buena tcnica que tambin se emplea
es realizar la pruebas unitarias en forma
cruzada, es decir, por los pares.
Pruebas generales del sistema
Son pruebas sistemticas de mdulos de la aplicacin y del sistema completo. Normalmente las realizan profesionales diferentes a quienes construyeron,
puede ser una labor externalizada (de hecho, son
cada vez ms las empresas del rea de software que
ofrecen este servicio especfico).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

175

Actualmente existe un amplio abanico de herramientas de apoyo para las pruebas.


Para un caso de uso lo mnimo a probar debiera ser:
El curso normal de los eventos y cada opcin.
Cada excepcin definida en el sistema.
Cada iteracin, recorrindola las veces especificadas y ms de una si es n.
Cada restriccin de frontera.
Algunas labores que se realizan aqu son:
Preparacin de datos de prueba y enlace con
herramientas de ayuda.
Pruebas por mdulos.
Integracin de todos los mdulos y pruebas del
sistema completo.
Anlisis de impacto en los bordes
Se trata de estresar la aplicacin y probar
las condiciones que menor probabilidad
de ocurrencia en la realidad, aquellas que
botarn la aplicacin aos despus si
no se detectan ahora.
Aceptacin de las pruebas
La aceptacin de las pruebas por parte de los usuarios y encargados de explotacin, en conjunto, consiste en responder a:
Resuelve el requerimiento actualizado?

176

JUAN BRAVO

Qu sucede en caso de cadas del sistema, en


diferentes puntos?
Cmo se mantiene la consistencia de la informacin?
Qu sucede con la privacidad y recuperacin?
Entre otras verificaciones.
Pruebas finales
El objetivo es demostrar que el sistema integrado
funciona correctamente y satisface su especificacin
actualizada.
Se requieren pruebas de integracin, pruebas finales
e inspecciones de aceptacin del sistema para demostrar al cliente que el sistema satisface sus requerimientos.
Se incluye tambin el manejo de no conformidades.

5.5. Instalar el piloto


Una actividad vital de esta etapa es
comenzar a operar el proceso rediseado
en carcter de piloto, considerando un
perodo de prueba integral con datos
reales y en la prctica.
Al mismo tiempo se avanza en:
Capacitacin de usuarios piloto, quienes luego
pueden hacer de instructores para los dems usua-

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

177

rios. Es importante la dedicacin completa de estas personas al proyecto.


Comunicacin del avance.
Desde el punto de vista de TI, la etapa contempla
instalar el sistema en alguna mquina especfica y
comenzar el uso real tambin en carcter de instalacin piloto.
Es importante no confundir la instalacin piloto con
un prototipo. El piloto es para certificar en la prctica que la aplicacin cumple con los requerimientos
explcitos y tcitos bien identificados y probados,
luego se replica para todos los usuarios. El prototipo
es para que el usuario vea un boceto de lo que quiere
o para probar aspectos especficos de la funcionalidad, luego se desecha.
Una recomendacin es asegurarse que
efectivamente se usa lo nuevo Y si lo
nuevo no se usa, tal vez sea por razones
fundamentadas, lo que llevara a
modificar el proyecto.
Algunas tareas propias de la implementacin:
Crear las tablas o archivos de las bases de datos
Poblar las tablas del sistema
Realizar paralelo cuando sea posible. El paralelo consiste en comparar el funcionamiento del
sistema antiguo (manual y/o computacional) con
el nuevo durante un perodo determinado.

178

JUAN BRAVO

Asegurarse que existen los manuales de usuario y


del sistema (ojal en lnea).
La capacitacin de los especialistas de explotacin y de usuarios piloto.
Especiales comentarios requiere en esta etapa el
proceso de paso a produccin:
En primer lugar es un proceso que debe estar bien
definido y aprendido por todos los partcipes.
Debe ser fluido y simple.
Es un requisito que el ambiente de explotacin
sea diferente al de desarrollo, al menos en servidores diferentes.
Debe ser seguro y seguir reglas generalmente
aceptadas de auditora computacional.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

179

ETAPA 6. DESPLIEGUE
La etapa de despliegue nace desde el Plan de proyecto actualizado, el modelo integral del cambio y
sus requerimientos, el diseo (o ingeniera de detalle) de la solucin y la implementacin en carcter
piloto de la solucin completa.
El objetivo es replicar o expandir la
solucin generada hasta ser bien utilizada
por todos los usuarios previstos en el plan
de proyecto.
Entregable de la etapa: el informe de puesta en
marcha completo del proyecto
~~
Se trata de instalar la solucin completa que propone
el modelo integral del cambio:
Las personas son capacitadas y reubicadas (la
sensibilizacin y otros aspectos ya deberan
estar logrados)
Los procesos definitivos son llevados a todos
los puntos donde sern utilizados.
La nueva estructura organizacional se pone
en marcha.
Se instala la aplicacin de software, probablemente en variadas mquinas.

180

JUAN BRAVO

En particular, veremos aqu el despliegue desde el


punto de vista de procesos y tecnologa.

6.1. Revisar y actualizar elementos


Se trata de asegurar la disponibilidad de todos los
elementos para difundir la solucin tecnolgica:
Documentacin: manuales de usuario, del sistema, ayudas en lnea, etc.
Disponibilidad de equipamiento computacional
Disponibilidad del software necesario
Disponibilidad de licencias del software
Disponibilidad de dispositivos de comunicacin.
Una base de datos con las respuestas a preguntas
tpicas del despliegue. Tambin de cada atencin
a usuarios, quiz el mismo usuario pueda ingresar
y detallar su solicitud, luego en el mismo software
se puede asignar un encargado.
Se requiere una mesa de ayuda, con
opciones de soporte telefnico, Intranet,
visitas en terreno, etc.
Acerca de capacitacin:
Programas detallados de capacitacin de usuarios
piloto y monitores
Programas detallados de capacitacin segn tipos
de usuarios
Comunicacin directa con los proveedores de
tecnologa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

181

6.2. Incorporar a cada usuario


Aqu al menos es necesario considerar los siguientes
elementos:
La instalacin personalizada en cada mquina.
Qu elementos del sistema se instalan en el computador del usuario y cuales en un servidor.
Que los dispositivos de comunicacin estn en
funcionamiento
Un mapa de instalacin, para conocer configuraciones fsicas, de software y de comunicacin.
Dedicacin completa de analistas, al igual que los
instructores. Son tantas las facetas de los procesos
y la aplicacin que exige gran atencin.
Que los ejecutivos debieran estar especialmente
alertas para facilitar el despliegue.
Conviene enfatizar los aspectos de
comunicacin, en todo sentido.

6.3. Capacitar a los usuarios


Capacitacin segn tipos de usuarios: usuarios operativos que interactan con el cliente tal como un
cajero supervisores que deben tomar decisiones
rpidas con base en una mirada global de lo que sucede o ejecutivos que desean ver tendencias y totales
en un sistema computacional.
Para realizar el despliegue debemos recurrir a muchas instancias de comunicacin rpida y efectiva,

182

JUAN BRAVO

sobre todo si se trata de llegar a cientos o miles de


usuarios, por ejemplo:
Revisar y actualizar el material (el cual debera
estar preparado desde las etapas de diseo e implementacin.)
Desarrollar algn video explicativo cuando corresponda.
Utilizar Internet. Al respecto, un mtodo que se
emplea cada vez ms es preparar capacitacin adhoc en la red, e-learning, los usuarios se conectan
libremente y existen niveles de evaluacin y monitoreo. Hay experiencias de preparacin de cajeros y de muchos otros tipos de usuarios operativos con esta tcnica, con buenos resultados (mejor cuando se complementa con algn porcentaje
presencial)
Reuniones ampliadas de los gerentes dando la
partida al proceso.
Capacitar a los capacitadores. Cuidar
los elementos pedaggicos. Un desarrollo
impecable puede fracasar porque el
especialista en informtica no sabe
transmitir el uso del software.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

183

ETAPA 7. OPERACIN
La etapa de operacin nace cuando la solucin generada est siendo bien utilizada por todos los usuarios
previstos en el plan de proyecto. Requiere de la documentacin generada en todas las etapas.
Entregable de la etapa: mantener la solucin en
buen funcionamiento hasta que cumpla con su vida
til o sea reemplazada por otra solucin. La mejora
continua es una actividad central.
~~
Los procesos requieren de mejora
continua en esta etapa, as como la
aplicacin computacional
El buen funcionamiento de la solucin debe lograrse
en todo el modelo integral del cambio de la solucin
(estrategia, personas, procesos, estructura organizacional y tecnologa) Por tanto, la mejora continua
opera en cada una de sus partes.
Es importante sealar que mientras se est trabajando en una vuelta de la espiral (suponiendo se emplea
la tcnica de desarrollo en espiral), no aplica todava
la mejora continua porque los casos de uso que se
van desplegando estn en desarrollo y todo el equipo
de proyecto junto con los usuarios est atento a los
cambios. Es decir, mientras la solucin est en desarrollo existe la infraestructura para abordar el cambio mayor y menor.

184

JUAN BRAVO

Cuando la solucin completa est desplegada comienza la mejora continua, la cual es compatible con
el rediseo programado27, tal como veremos en la
seccin 7.6.

7.1. La mejora continua


La mejora continua opera a nivel del
modelo integral de la solucin (estrategia,
personas, procesos, estructura y
tecnologa).
La mejora continua, tambin llamado mejoramiento
continuo28 son pequeos y permanentes perfeccionamientos de un sistema, proceso, producto, unidad
organizacional y cualquier otro elemento de la organizacin. La mejora continua de procesos productivos o administrativos para obtener productos y servicios flexibles, adaptables, de buena calidad y
econmicos es una meta deseable para cualquiera
empresa. Veremos aqu algunas formas efectivas de
lograrlo.
Desde los fundamentos que provee la visin sistmica29, aplicamos el principio de continuidad, significa
una adaptacin permanente de la solucin a las nuevas exigencias del medio. Destaquemos algo funda27

En el libro Desarrollo de sistemas de informacin, una visin


prctica hay alcances adicionales bajo el ttulo Sistemas en Actividad.
28
Resumen desde el libro Gestin de Procesos, captulo 15.
29
Ver libro Anlisis de Sistemas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

185

mental y que a veces no se percibe claramente: todo


proceso debe estar en mejoramiento continuo, labor
realizada principalmente por los mismos partcipes
del sistema.
Aporta Robert Kriegel (1994, p. 210): una gran
cantidad de pasos pequeos lo pondr en capacidad
de alcanzar sus metas ms rpido y ms fcilmente
de lo que crey posible. Toyota utiliza esta mentalidad para hacer innovaciones. Mientras que muchas
otras empresas luchan por avances espectaculares,
Toyota se mantiene realizando gran cantidad de cosas pequeas y hacindolas cada vez mejor Suee
en grande, pero d muchos pasos pequeos.
Ha intentado subir un cerro corriendo?
Lo ms probable es quedar exhausto a
poco camino. Sin embargo, paso a paso se
llega.
Algunas veces el mejoramiento continuo surge desde la implementacin de un Sistema de Gestin de la
Calidad, en tal caso, algunos requisitos seran (ISO
9001:2000, p. 2): identificar los procesos necesarios para el sistema de gestin de la calidad determinar la secuencia e interaccin de estos procesos determinar criterios y mtodos necesarios para
asegurarse de que tanto la operacin como el control
de estos procesos sean eficaces.
Contina el texto de la norma ISO 9001:2000 con
asegurar la disponibilidad de recursos e informacin
para apoyar la operacin, el seguimiento, la medi-

186

JUAN BRAVO

cin, el anlisis y la mejora continua de todos los


procesos.
Ntese que todo gira en torno a los
procesos, con inicio y trmino en el
cliente.
Algunas herramientas del mejoramiento continuo
Algunas de las herramientas30 ms efectivas de mejoramiento continuo son:
1. Benchmarking
2. Flujograma de Informacin
3. Estandarizacin interna y externa.
4. El ejemplo personal.
5. Kanban (sistema visual)
6. Compensadores de complejidad
7. El momento de la verdad
8. Seis Sigma
9. Ciclo PDCA (Plan Do Check Act).
10. Tcnica de las 5-S
11. Realizar tormentas de ideas
12. Implementar crculos de calidad
13. Diagramas causa-efecto (ver anexo 1)
14. Diagramas de Pareto (ver anexo 1)
Adems de una amplia gama de herramientas cercanas a la estadstica.

30

Se presentan aqu solamente como una muestra de la profundidad


de la mejora continua, estn detalladas en el libro Gestin de Procesos, captulo 15.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

187

7.2. Control de cambios


Se trata de establecer un procedimiento de
aceptacin de requerimientos menores en
el mbito de la TI.

Obtencin de nuevos informes, consultas y adaptaciones menores? Es necesario resolver acerca de


esto y tal vez seguir el procedimiento general del
Departamento de Informtica en cuanto a requerimientos menores, por ejemplo:
PROCESO: EMITIR UNA SOLICITUD DE CAMBIO MENOR EN APLICACIONES COMPUTACIONALES
USUARIO AUTORIZADO

SC

REA DESARROLLO
DEPARTAMENTO DE INFORMTICA
JEFE INFORMTICA
ANALISTA
SUBCOMIT CAMBIOS

Asignar
Analista
Estudiar
impacto
Casos de
uso
Emitir
informe

Abreviaturas:
II

SC: Solicitud de Cambio

II: Informe de Impacto


PD: Plan de Desarrollo

Plan de
Desarrollo
PD

PD

II

SC
II

PROCESO
IMPLEMENTAR

PD

1. Emisin de una solicitud de cambio menor por


parte de un usuario autorizado (podran ser integrantes del mismo departamento de informtica).
2. Recibe la solicitud el Jefe de Informtica

JUAN BRAVO

188

3. El Jefe de Informtica asigna a un analista para


realizar un estudio de impacto:
Lo presenta como un caso de uso
Determina impacto en la aplicacin y en
otros sistemas
Calcula costo y recursos
Determina duracin
Entrega informe al Jefe de Informtica
4. Se presenta al requerimiento al subcomit de informtica encargado de los requerimientos menores, con la participacin especial de los usuarios
solicitantes y relacionados, el Jefe de Informtica
y el analista que realiz el estudio de impacto. Se
toma alguna decisin de cambio.
5. El analista presenta el plan de desarrollo preciso
del requerimiento, incluyendo equipo de trabajo y
costos, de acuerdo con las indicaciones del Subcomit de Informtica.
6. Aprueba el Jefe de Informtica.
7. Se realiza el trabajo, incluyendo lo mismo indicado en las secciones anteriores del ciclo de desarrollo, desde anlisis hasta despliegue, aunque a
una escala menor.
Por lo menos contempla:
Participacin del usuario en forma continua
Actualizacin de documentacin
Bsqueda de programas, bibliotecas, documentacin, etc...

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

189

Ordenamiento de manuales, versiones de


programas, cambios en archivos, etc...
Anlisis, diseo e implementacin
Pruebas
Reentrenamiento
8. Retroalimentacin

7.3. Una mesa de ayuda


Una mesa de ayuda es fundamental
durante la implementacin del sistema y
luego durante su operacin.
Puede ser parte de la mesa de ayuda central en la
organizacin.
Con todos los elementos que se acostumbra en estos
casos, por ejemplo, escalamiento de niveles segn la
profundidad de la ayuda y una buena formacin del
primer nivel para que resuelva la mayor parte de las
consultas.

7.4. Buena operacin de la aplicacin


Se trata de trabajar sistemticamente al menos en las
siguientes prcticas:
Mantencin de una bitcora de los procesos ms
relevantes
Control de funcionamiento correcto

JUAN BRAVO

190

Optimizacin de recursos, permanente,


tales como verificacin de recorridos en la
navegacin por bases de datos o el uso de
procesador, memoria y espacio en disco.
Revisin de la necesidad de imprimir informes
Reiniciar el sistema en caso de cadas del sistema
Reconstruccin de archivos
Seguridad e integridad de la informacin
Recuperacin de la informacin
Auditora computacional
Documentacin actualizada en todo momento

7.5. Gestin de la calidad


Durante la operacin se requiere asegurar, entre
otros aspectos:
Que se contina operando en conformidad con los
requerimientos del cliente o usuario.
Que existe soporte a clientes de acuerdo con lo especificado en el contrato.
Que existe un procedimiento de modificacin del
sistema en cuanto a requerimientos mayores (rediseo) y menores (mejora).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

191

7.6. Rediseo programado de la solucin


Se trata de realizar un nuevo ciclo de desarrollo en
fechas programadas, como si fuera otra vuelta de la
espiral. Se revisa y adapta desde el modelo integral
del cambio de la solucin.
De esta forma, muchos de los nuevos
requerimientos, mayores o menores,
seguirn esta va en lugar de la mejora.
Adems, programar un ciclo de desarrollo permite
resolver problemas de consistencia, de regeneracin
de estructuras de datos frente a cambios, de integracin del proyecto, aplicar lo aprendido para optimizacin del funcionamiento, etc.
En experiencias personales del autor, soluciones de
tamao mediano se rediseaban con xito una vez al
ao y otras, ms grandes, una vez cada dos aos.
Un beneficio lateral es disminuir la presin por las
modificaciones menores al existir una fecha conocida por todos para el rediseo de la solucin.

192

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

TERCERA PARTE.
PRCTICAS
TRANSVERSALES

193

194

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

195

Sencillez, claridad y elegancia son los sellos de los buenos programas; oscuridad, ingeniosidad y complejidad
son indicaciones de un diseo inadecuado y un pensamiento mal orientado.
Richard Fairley

196

JUAN BRAVO

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

197

INTRODUCCIN
La administracin del proyecto considera una gran
cantidad de acciones bien coordinadas que ayudan a
lograr el todo, en este caso, un proyecto exitoso. Es
un efecto sinrgico.
Se trata de prcticas transversales que influyen en
todas o en la mayora de las etapas del proyecto31
(de hecho,).
Estas prcticas se aplican en la fase de
estudio y luego deben quedar
incorporadas en el plan de proyecto, en la
forma de planes especficos.

Las mejores prcticas en proyectos


Estas prcticas surgen justamente de observar las
mejores prcticas en buenos proyectos.
Cada una puede ser tan extensa como se desee y ha
sido un esfuerzo resumirlas.
La mayora de ellas estn detalladas en los libros del
autor sealados en el prlogo y hacia el final de la
introduccin.

31

Una pregunta habitual en evaluaciones acerca de este mtodo es


algo as: Cmo aplicara una prctica transversal en cada etapa?

198

JUAN BRAVO

Ordenamiento de las prcticas


Las prcticas se han ordenado de acuerdo con el criterio de mayor uso, comenzando por aquellas que
indudablemente deben estar presentes en todas las
etapas. El resultado no seala precedencia, eso depende del mtodo especfico que la organizacin
adopte.
Este criterio de ordenamiento no pretende juzgar
niveles de importancia de cada prctica, porque cada
una tiene su espacio y quiz aunque su uso sea acotado a pocas etapas, es vital en ellas.

Definir una poltica por cada prctica


Cuando se trata de proyectos aislados y
no hay un mtodo en la organizacin,
cada prctica debera revisarse una por
una para cada etapa.
Cuando hay una rutina de realizar proyectos y existe
un mtodo para realizar este tipo de proyectos en la
organizacin, la forma de trabajar con las prcticas
transversales estar indicada en el mtodo, en tal
caso, la revisin es ms general. Por ejemplo, la
prctica definir herramientas para la etapa probablemente estar definida como estndares corporativos o, al menos, como una poltica
Es importante considerar que:

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

199

La aplicacin de cada prctica transversal a un


proyecto debera ser una particularizacin de la
polticax correspondiente.
La poltica de cada prctica debe estar siempre
actualizada.
La participacin de todos es vital en el contenido
de las polticas, porque es lo que verdaderamente
aplicar la organizacin

Llevar a la Carta Gantt


Fruto del anlisis de cada prctica,
surgirn mltiples acciones a realizar que
debern incluirse en la Carta Gantt. Ese
es el resultado concreto a donde conduce
la revisin de las prcticas transversales.
Por ejemplo, en el control de cambios es necesario
contemplar el tiempo de negociacin del jefe del
proyecto con el usuario, independiente de que el
cambio se realice o no.
Podra llegar a ser el 20% del presupuesto para los
cambios? Puede ser, depende de la organizacin, por
eso es necesario disponer de una base de datos de
estndares numricos.

Base de datos de estndares numricos


Desde la base de datos de estndares numricos obtenemos el dato de cunto tiempo y costo presupues-

200

JUAN BRAVO

tar, por ejemplo, para el tiempo de negociacin de


un cambio.
Tambin en esta base de datos deberan incluirse
estos estndares:
Plazo mximo de proyectos.
Tasa de descuento y plazo para evaluacin de
proyectos.
Valor hora de los clientes (US $ 4 dlares promedio hemos usado en algunas organizaciones)
Rutina acerca de cules temes incluir en el ao
cero o uno de un flujo de caja.
Costos de movimientos internos y externos de
mercaderas.
Valor hora promedio de los ejecutivos, de los
profesionales, mando medio y personal operativo
para efectos de cuantificar las propuestas, en particular el ahorro que se puede generar (recordar
multiplicar por un factor tambin estndar respecto al valor que cada persona agrega, conservadoramente unas 5 veces la renta bruta).
Y muchos ms

Cules prcticas incorporar en un proyecto?


La tabla de la siguiente pgina es un ejemplo del
tipo de ejercicio que debera hacer un jefe de proyectos o un analista de estudios respecto a que
prcticas incorporar en cada etapa del proyecto. Esto
depender del proyecto mismo y de la poltica de
cada prctica.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

201

Etapas Mtodo GSP


Prcticas Transversal

1 Direccin del proyecto

2 Plan de la etapa

3 Exposicin de los planes

x
x

x
x

4 Retroalimentacin

5 El equipo de trabajo

6 Entrevistas

7 Comunicacin

10 Herramientas de apoyo

11 Trazabilidad

12 Quick Wins

13 Costos y Duracin

8 Informes
9 Tcnicas

14 Gestin de Riesgos

15 Gestin de la calidad
16 Responsabilidad Social

17 Insercin

19 Sensibilizacin

x
x

21 Seguimiento
22 Cuidar la solucin anterior

18 Orientacin al Cliente
20 Capacitacin

x
x

24 Plan de recursos fsicos del proyecto


x

23 Continuidad operacional
25 Kill Time

26 Control de cambios

x
x

27 Gestin del cambio

28 Gestin de proveedores

202

JUAN BRAVO

1. DIRECCIN DEL PROYECTO


La buena direccin del proyecto es, tal vez, la
prctica ms relevante para el xito del proyecto.
La direccin del proyecto es una visin y
accin de conjunto de todas las
actividades necesarias para cumplir con
lo prometido, particularmente en calidad,
eficiencia, eficacia, satisfaccin del
cliente, plazos y costos.
Motivar, comunicar, liderar y alinear intereses resultan esenciales.
Facilitadores del trabajo del lder del proyecto :
Que tenga dedicacin completa y una visin clara de los objetivos del proyecto.
El apoyo de la alta direccin, el nivel de autonoma y la facilidad para acceder a la toma de
decisin fluida en relacin al proyecto.
Su competencia en trabajo en equipo y liderazgo.
Desarrollar el espritu de equipo y el profesionalismo de su gente.
Gestionar los riesgos.
Comunicar el proyecto con frecuencia y dentro y
fuera de la organizacin, integrando a todo el
equipo de trabajo, as se perfecciona el mensaje,
se aclara a s mismo y gana en retroalimentacin.
Reencantar cada cierto tiempo a su equipo.
Cambiar las creencias limitantes en el equipo de
trabajo: no se puede, el gerente no quiere, etc.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

203

2. PLAN DE LA ETAPA
Una vez que est decidido realizar una etapa, es necesario detallar el plan de la misma (duracin, encargado, costo de la etapa, documentos de licitacin
que ser necesario construir, etc...) ms all del plan
de proyecto.
Se trata de comenzar cada etapa
revisando el plan de la misma etapa y tal
vez replantear el plan general del resto del
proyecto.
Se hace una programacin detallada de la etapa,
con fechas precisas e incluso horarios en algunos
casos. El plan de la etapa puede ser el nico plan
que existe, como en el caso de la factibilidad (porque todava no hay proyecto).
Siempre implica una revisin del plan general del
proyecto. Son re-estimaciones a la luz del avance.
Es conveniente considerar que en cualquier etapa se
puede cancelar el proyecto o volver a una etapa anterior, por ejemplo, si se detect algo no considerado
o si hubo un cambio relevante en el entorno para el
par problema-solucin.
Una recomendacin: asegrese que lo definido en la
etapa anterior sigue siendo vlido, especialmente si
pas mucho tiempo entre etapa y etapa.
Por supuesto, el plan de la etapa debe ser aprobado
por la instancia de decisin que corresponda.

204

JUAN BRAVO

3. EXPOSICIN DE LOS PLANES


Se trata de exponer y discutir el plan de trabajo a
todos los actores relevantes, al interior y exterior
del equipo de proyecto.
Es conveniente porque surgirn muchas sugerencias
para lograr xito en el proyecto. En el fondo, lo ms
importante es la retroalimentacin que se logra.
Al exponer los planes a todos los actores
relevantes se mejora la coordinacin del
proyecto.
Aqu tienen especial relevancia las competencias del
equipo de trabajo para exponer a un grupo de personas en forma clara y precisa.
Son competencias de comunicacin, personales en
cuanto a desarrollar un mensaje y tcnicas en cuanto
al uso de herramientas, tal como un software tipo
Power Point, un proyector, un puntero lser, etc. .
La exposicin es uno mismo. Al comienzo la atencin est puesta en cmo uno se ve, habla, mueve,
gesticula, viste, entona, etc. es el efecto de la primera impresin. Para comenzar: hay que disfrutarlo,
sino, para qu estamos ah? Es indispensable la
fuerza, la pasin y la energa en lo que se transmite.
Algunas recomendaciones: 1) preparacin del tema,
2) presentacin personal, 3) buena diccin, 4) lenguaje formal, 5) manejo del tiempo, 6) llegar al menos media hora antes, 7) cumplir los tiempos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

205

4. RETROALIMENTACIN
Se trata de revisar el resultado logrado respecto a lo
planeado para la etapa. Se comunican los resultados
al resto del equipo y las conclusiones quedan disponibles para toda la organizacin.
Practicar la retroalimentacin es preguntarnos, qu
aprendimos?, qu aprend? individualmente o en
grupo, en un proceso continuo. Si tuviramos que
hacer nuevamente el mismo trabajo de la etapa,
cmo lo haramos?, qu cambios introduciramos?
Retroalimentar es una prctica que debe incluirse
tanto al trmino de cada etapa como al finalizar el
rediseo de cada proceso y al completar el proyecto.
Tambin contempla preguntarnos si se estn resolviendo las necesidades originales actualizadas.
El espritu de este punto es detenernos,
reflexionar aprender y seguir.
Esta es una prctica que enlaza con la gestin del
conocimiento, porque las conclusiones que se derivan de las sesiones de retroalimentacin deben ser
compartidas y adecuadamente archivadas en medios
digitales. De esta forma el aprendizaje pasa a ser
patrimonio de la organizacin.
No existe ensear, solamente existe aprender y en
esto ya sabemos que la emocin juega un rol fundamental, el aprendizaje debe darse en el afecto, estableciendo vnculos con las personas y con las ideas.

206

JUAN BRAVO

5. EL EQUIPO DE TRABAJO
La prctica ms habitual es formar un equipo de trabajo por cada etapa, manteniendo un ncleo de participantes permanentes durante el proyecto.
Se trata de formar un equipo integrado por especialistas en rediseo de procesos, informtica, usuarios
ejecutivos y consultores se gana el efecto consultor, una mirada externa fresca, segn el tipo de
proyecto. Debe estar claro quin es el director del
proyecto. La participacin de los ejecutivos es vital.
Normalmente se designa un usuario lder (representante de los dems usuarios) y usuarios clave de cada rea a redisear. El usuario lder trabaja coordinadamente con el jefe del proyecto.
Es probable que cambien integrantes del
equipo de trabajo segn sus competencias
para la etapa.
Algunas claves:
Crear espritu de equipo y fomentar el profesionalismo con acciones concretas.
Asegurarse de la disponibilidad de tiempo de cada integrante para este equipo.
Revisar la asignacin de elementos de apoyo: PC,
licencias, lugar fsico, escritorios y otros.
Revisar roles, por ejemplo, para: redactar informes y coordinar su entrega, coordinar la retroalimentacin y entrega de los resultados, definir y
realizar el plan de entrevistas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

207

6. ENTREVISTAS
Una prctica frecuente en los proyectos es la realizacin de entrevistas a usuarios, ejecutivos y personas
de fuera de la organizacin. La finalidad principal es
levantar informacin til al proyecto y se complementa con otras tcnicas (encuestas, informes de
consultora, de auditora, etc.).
Al comenzar la etapa debe elaborarse el plan de entrevistas. Luego debe prepararse cada entrevista,
anticipando lo que se pueda utilizar. Vital es el preparacin, la buena ejecucin y el anlisis posterior
para incorporar las conclusiones al proyecto y cumplir los compromisos adquiridos.
Durante la entrevista lo principal es crear
ambiente, es decir, un clima de confianza
con una actitud serena que surge de la
puntualidad, preparacin y presentacin
(las tres P de las entrevistas).
Escuchar, ms que hablar. Practicar tacto, cortesa y
sobre todo, naturalidad. Hacer preguntas en positivo,
por ejemplo, cmo le gustara que fuera?, qu
quiere usted para la empresa?, cmo sera el funcionamiento del proceso que usted propone?, cul
es el ideal?, por qu? este tipo de preguntas
abren nuevas posibilidades y apuntan al cambio.
Evitar caer en la trampa de la complicidad, es decir, recibir secretos de los entrevistados o escuchar
confidencias que no se pueden comunicar.

JUAN BRAVO

208

7. COMUNICACIN
Se trata de comunicar el proyecto al interior y exterior de la empresa, con mensajes adaptados segn el
tipo de interlocutor (no es lo mismo comunicar a la
direccin que a los funcionarios administrativos o a
los clientes). Es conveniente comunicar mucho.
Esta sola actividad implica disponer de horas de especialistas en comunicacin, con dedicacin parcial
o total segn la envergadura del proyecto.
Incluye la formacin de diferentes tipos de mesas de
ayuda segn la etapa del proyecto.
Se puede comunicar a nivel de problema y
a nivel de solucin, es una actividad
completamente transversal.
Incluye todo el aspecto de presentacin y exposicin
de los proyectos, desde la forma de presentar hasta
el desarrollo de la competencia de saber exponer de
los integrantes del equipo.
Un aspecto vital es la preparacin del equipo de trabajo en el manejo de la emocin, particularmente al
interior del equipo de trabajo. De hecho, es una
prctica regular en empresas con una larga historia
de proyectos exitosos realizar talleres de trabajo en
equipo antes, durante y despus del proyecto. Una
excelente prctica es aplicar la escucha emptica.
Todo comienza por comunicarse bien entre s y una
consecuencia es lograr lo mismo con los dems.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

209

8. INFORMES
Cada etapa tiene uno o ms entregables que deben
quedar registrados en informes. En el plan detallado
de cada etapa deben quedar resueltos aspectos tales
como: quin redacta qu informe?, a quin se le
entrega?
La prctica genrica es documentar e implica el desarrollo de las competencias mnimas en el equipo
de trabajo (que es preferible no dar por adquiridas),
por ejemplo: redaccin, ortografa, capacidad de
sntesis, etc. Al menos la habilidad de leer.
Por supuesto, debiera documentarse al
mismo tiempo que se avanza en la etapa,
evitando postergar.
La estructura debe ser parte de los estndares de la
organizacin, una propuesta del mtodo GSP es:
A) Resumen ejecutivo. Es la primera parte del informe y contiene los resultados centrales, es deseable que tenga solamente una pgina de extensin. Se sugiere: objetivo, resumen de antecedentes, conclusiones y recomendaciones.
B) Detalle de Antecedentes. Se incluyen los documentos relevantes, el plan original, los antecedentes de la ejecucin y de la retroalimentacin.
Es importante el registro ordenado de los hechos, lo
cual facilita la trazabilidad, el aprendizaje y la calidad. La extensin es cuestin de estndar y de criterio, el Justo Medio est bien, ni mucho ni poco.

JUAN BRAVO

210

9. TCNICAS
Se trata de seleccionar las tcnicas a emplear en cada etapa del proyecto, por ejemplo, la forma de realizar la ingeniera de requerimientos.
Sabemos de que tcnicas podemos
disponer en cada etapa de un proyecto de
Procesos y Tecnologa, sin embargo, la
variedad es tan amplia que el mtodo de
la organizacin debe pronunciarse.
Algunas tcnicas en cada etapa:
Concepcin: planificacin estratgica, diagnstico, mapa de procesos, FI, tcnica de los por qu,
causa efecto de Ishikawa y Pareto. Idealizacin.
Factibilidad: evaluacin financiera, CPM, PERT,
Carta Gantt, tcnicas de creatividad.
Anlisis: UML, gestin de procesos, enfoque
sistmico, anlisis estructurado, anlisis orientado al objeto, modelo conceptual y de datos.
Tcnicas de creatividad.
Diseo: diseo clsico, diseo estructurado, diseo orientado al objeto y aplicacin amplia de la
reusabilidad, estndares.
Implementacin: programacin orientada a objetos, Testing, generacin automtica de cdigo,
programacin, XP, HTML y XML
Despliegue: instalacin automatizada y tcnicas
de comunicacin
Operacin: benchmarking, mejora continua.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

211

10. HERRAMIENTAS DE APOYO


Se trata de seleccionar herramientas de apoyo a las
tcnicas que se usarn en cada etapa. Tambin llamadas CASE (desarrollo apoyado por computador),
por ejemplo, de tipo32: MS Project, Visio, Aris, Corporate Modeler, M1, Z4, Rational, ERWIN, etc. Lo
importante es que la organizacin tenga una definicin al respecto.
Pueden ser ayudas en la construccin de prototipos,
flujo de un proceso, interfaz visual, modelo conceptual, casos de uso y cualquier otro tipo de modelo.
Tambin para cooperar en la planificacin estratgica, el control de costos y la evaluacin financiera,
entre otras posibilidades.
Se pueden emplear diferentes herramientas de apoyo
en cada etapa, esa es hoy la realidad. Sin embargo,
existe una tendencia a unificar en una sola o en un
pequeo conjunto de herramientas bien integradas,
la ventaja es la facilidad para acceder a los modelos,
su actualizacin y la trazabilidad.
Una aspiracin de las herramientas de
apoyo es que acten a nivel del ciclo
completo, incluyendo la generacin de
cdigo cuando corresponda.
32

MS Project y Visio de Microsoft, Aris de SAP, Corporate Modeler de Case Wise, M1 y Rational de IBM, Z4 de Tuxpan, ERWIN

Data Modeler de Computer Associates.

JUAN BRAVO

212

11. TRAZABILIDAD
Trazabilidad se entiende en dos sentidos:
a) Trazabilidad de las transacciones, donde se puede seguir la pista de cmo se va actualizando informacin, siempre mediante transacciones formales y presentes, desde la creacin de un dato,
por ejemplo, un saldo de inventario.
b) Trazabilidad del desarrollo, donde se pueda seguir la pista a cada requerimiento implementado,
cmo fue diseado, el anlisis que le dio forma,
quin lo gest, por qu, etc.
Es como la trazabilidad de la fruta, donde
el objetivo es que una clienta de un
supermercado en Europa pueda saber que
el durazno que adquiri viene de Chile
(importador, exportador, puerto, etc.) y de
un lote especfico con detalle del lugar,
fertilizantes, suelos, etc.
En la trazabilidad los modelos principales deben
estar permanentemente actualizados. Significa que si
es necesario realizar un cambio en la solucin implementada se actualiza toda la serie de modelos que
dio origen al producto, al menos desde el anlisis y
eventualmente desde la misma necesidad que dio
origen al requerimiento.
Lo cual no es lo mismo que llevar un registro histrico de todos los cambios a la solucin (tambin necesario) un simple repositorio.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

213

12. QUICK WINS


Se llama Quick Wins literalmente ganancias rpidas o Hits a cambios de breve diseo e implementacin y que tengan un buen nivel de impacto en el
avance de la solucin. Son entregables de accin
rpida, generalmente acciones simples que fueron
quedando en evidencia desde las primeras conversaciones.
Gracias a estas acciones tempranas se ven
resultados a corto plazo y se alienta tanto
a los operadores del proceso como a la
direccin a continuar con el proyecto,
renovndose la motivacin y manteniendo
la atencin en el proyecto.
Un subproducto del trabajo en las etapas preliminares (concepcin, factibilidad y anlisis) es detectar
Quick Wins.
La prctica transversal de la sensibilizacin se presta
para organizar talleres donde los mismos usuarios
operativos proponen ideas de cambio en los procesos (ver anexo 7, caso BancoEstado)
Una precaucin es no abusar de esta va rpida, para
no caer en el exitismo de corto plazo y confundir al
resto de la organizacin. Es razonable hacer cuanto
antes los cambios que se pueden hacer, sin provocar
la expectativa de que lo siguiente ser igual de fcil
o rpido.

JUAN BRAVO

214

13. COSTOS Y DURACIN


Se calculan costos y duracin tanto de la etapa como
del proyecto completo. Es importante y valiente ver
la realidad de lo que est sucediendo y reestimar si
es necesario. No es cambiar por cambiar sino que
adaptar el avance del proyecto a la realidad de hoy
(imposible de predecir en su totalidad cuando se
elabor el plan de proyecto). Lo opuesto es cerrar
los ojos y tratar de cumplir un plan que tal vez no
tiene sentido. Ah... asegrese que los fondos existen.
Se calculan costos cada vez ms precisos del proyecto en tres etapas: factibilidad, anlisis y diseo.
Es necesario incluir costos ocultos tales
como la misma planeacin de la etapa, las
reuniones de coordinacin y de
negociacin y las exposiciones de avance,
entre otros.
Normalmente el costo mayor son horas profesionales, internas y/o externas. Se da una relacin de dependencia entre costo y duracin. Se requiere asignar elementos computacionales, lugar fsico y otros
recursos. Tambin el costo de las herramientas y
licencias de productos de software. Diferenciar inversiones y gastos para efectos contables.
La duracin de la etapa depende del proyecto especfico. Lo importante es que se encuentre acotada.
Considere el plazo de entrega como una muralla
inamovible, puede negociar todo lo dems.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

215

14. GESTIN DE RIESGOS


Se trata de detectar riesgos y elaborar un plan para
mitigarlos y/o traspasarlos. Por ejemplo, en la concepcin: conviene abordar el problema? A veces el
sentido comn (y los amplios estudios de Maturana,
Echeverra, Varela y otros) indica que el solo hecho
de sealar un problema ya crea una expectativa. Es
el momento adecuado? Y si no se llega a una conclusin? Y si excede los plazos o costos?
En la etapa de factibilidad: malas estimaciones de
plazos, dejar de lado buenas soluciones, no conocer
lo que el medio plantea, etc.
Cada etapa tiene sus propios riesgos que deben ser
atendidos: una tecnologa difcil de obtener, especialistas escasos, cambio de prioridades, atrasos, costos
excedidos, incumplimiento de proveedores, tecnologa difcil de implementar, usuarios que no desean
el nuevo proceso, apego irrestricto al plan, agotamiento, etc.
Se han identificado ms de cien riesgos
asociados a los proyectos de procesos y
tecnologa, lo mnimo es tener formas de
detectar, transferir y/o neutralizar.
Una frmula para priorizar riesgos: R = C x P. La
magnitud del riesgo (R) se obtiene multiplicando el
costo si ocurre (C) por la probabilidad de ocurrencia
(P). Ofrece un lmite a la inversin en el riesgo para
mitigar o traspasar (libro Gestin de Procesos)

216

JUAN BRAVO

15. GESTIN DE LA CALIDAD


Cada etapa del proyecto debe llevar el sello de gestin de la calidad, al menos en:
Planeacin, aseguramiento y control de calidad
(ver anexo 6).
Aplicar o definir estndares de gestin y determinar como se cumplen.
Tan importante es la calidad que a veces se crea un
rea de aseguramiento de la calidad tpicamente
llamada QA para ayudar a elaborar el plan de calidad del proyecto, para la verificar el proceso de
produccin y validar los entregables de cada etapa.
Existe todo un aporte de la gestin de
calidad aplicada a proyectos, con una
planificacin, control y seguimiento.
El contenido tcnico y toda forma de comunicacin
debe ser impecable. Se emplean frmulas de externalizacin de Testing cuando hay desarrollo de TI,
por ejemplo, que el trabajo en el proyecto sea revisado por los pares del analista o por otros profesionales,
internos o externos, antes de presentarlo al mandante
(quien lo encarg para tomar una decisin).
Se requiere la revisin del ciclo completo de actividades, as como el cumplimiento de los compromisos adquiridos con el cliente.
La Gestin de la Calidad exige fomentar al interior
de la empresa una cultura de calidad.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

217

16. RESPONSABILIDAD SOCIAL


Veremos algunos elementos de la Responsabilidad
Social (RS) especficamente aplicada a proyectos.
Es necesario manejar bien el temor de las
personas de que este tipo de proyecto las
dejar sin empleo.
Establecer un pacto social o una alianza estratgica
con los colaboradores es un excelente camino que
han aplicado empresas exitosas. Todos cooperan con
el cambio necesario y la empresa no despide por
motivo de estos proyectos. No es justo ni necesario
despedir slo porque queremos hacer de otra forma
las cosas. Se puede evitar generando vinculaciones
con otros proyectos en un esquema de vasos comunicantes porque en la organizacin hay infinitos
proyectos posibles, una parte libera recursos y la otra
requiere recursos, es cuestin de unir una cosa con
otra, otra aplicacin de visin sistmica.
Se requiere mantener al menos el nivel de servicio
previo al inicio del proyecto mientras este dure, trabajar con eficiencia, alinear intereses, cuidar el entorno y la comunidad, organizar el trabajo seguro y
el buen trato, tanto de los profesionales internos como de contratistas, evitando discriminar entre ellos,
evitar la improvisacin, hacernos responsables, prevenir en todo los riesgos y calcular el VA (Valor
Actual) social, que refleja el efecto del proyecto en
el medio, que debe dar positivo.

JUAN BRAVO

218

17. INSERCIN
El problema y la solucin deben insertarse en un
todo mayor rea, empresa, industria o gobierno
para comprender y alinear los respectivos intereses.
Insertar es observar cmo se relaciona el problema o
la solucin con otros problemas o soluciones dentro
y fuera de la organizacin para, por ejemplo, transferir recursos, alinear intereses, optimizar adquisiciones y manejar el aspecto poltico en cuanto al mejor
momento de plantear el cambio.
Se debe monitorear la contribucin
actualizada de la estrategia del proyecto a
la estrategia de la organizacin.
Es necesario identificar los impactos del proyecto a
todo nivel, especialmente en los clientes, para lo
cual es ideal trabajar con criterio SCM (Supply
Chain Management). La recomendacin es suponer
que nos quedamos cortos en estimar impactos para
estar preparados para efectos inesperados. Una forma de evitarlos al interior de la empresa es comunicar el proyecto a todas las reas, incluso donde
creemos que no influye, as tambin mejoramos las
estimaciones. Al exterior de la empresa tambin es
conveniente comunicar a una lista extensa.
En la insercin se trabaja con mapas, por ejemplo,
de necesidades, procesos y proyectos, para identificar interacciones (ver clave 1 de Claves de la implantacin de mtodo en una organizacin).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

219

18. ORIENTACIN AL CLIENTE


Ya sea en el problema o la solucin, la orientacin al
cliente es central para lograr la conclusin exitosa
del proyecto.
Es vital escuchar y apreciar lo que es realmente importante para el cliente.
Ya indicamos que por cliente hablamos
del cliente externo, quien paga a todos en
la organizacin.
Los usuarios internos son socios del equipo de
proyectos en esta misin de servir mejor al cliente.
Esto es central, quin es el cliente del rea de gestin de procesos? Respuesta incorrecta: la gerencia
de produccin o de ventas a quien se atiende para el
rediseo. Respuesta correcta: el cliente (sin apellido
para no introducir confusin).
El cliente de todos en la empresa es el cliente (abandonamos aqu el concepto de cliente interno por las
distorsiones que introduce).
Todo proyecto debe ser monitoreado en cuanto a su
impacto en el cliente, aunque aparentemente sea solamente interno, tal como una evaluacin del desempeo o la mejora de los procesos de compras.
Al igual que en el resto de las prcticas, esto implica
un plan para hacer factible el seguimiento y apreciar
cuan importante es el proyecto para el cliente, desde
su inicio al trmino.

JUAN BRAVO

220

19. SENSIBILIZACIN
Es el manejo del cambio en lo que se refiere a emocin y sensibilizacin. El objetivo es encantar a los
afectados.
La idea es aplicar lo aprendido acerca de
encantar a todas las personas de dentro y
fuera de la organizacin que tienen
relacin con el proyecto
Es diferente a comunicar y capacitar, aunque se
complementa con esas prcticas. Se aplica mediante
anticipacin, participacin, talleres ver prctica
Quick Winsy otras formas creativas (poleras, lpices, etc.)
Hay experiencias concretas de proyectos fracasados
y otros que han aumentado en varias veces su presupuesto original solamente por el mal manejo de la
sensibilizacin, porque los usuarios no deseaban
usar el sistema y hacan resistencia pasiva.
La declaracin es muy precisa: los usuarios deben
querer usar la solucin. Luego viene estar capacitados para su operacin.
Una faceta de la sensibilizacin es la coherencia, es
decir, el equipo de proyecto debe estar sensibilizado
primero, para que pueda transmitir la emocin de
estar participando en un proyecto tan vital
En el anexo 7 se presenta el resumen de un proyecto
bien implementado en el BancoEstado.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

221

20. CAPACITACIN
La capacitacin del equipo de proyecto debiera ser
continua durante todo el proyecto. Adems, es una
excelente oportunidad para coordinar lograr acuerdos en los mltiples detalles de la necesidad..
El diseo de la actividad es central: lugar,
objetivos, duracin, relator, extensin y
muchos otros aspectos deben estar bien
pensados.
La capacitacin de los usuarios es vital en el proyecto. Por supuesto, es diferente segn tipos de usuarios
y puede tomar variadas formas (la recomendacin es
una combinacin de posibilidades):
Puede ser realizada por relatores profesionales,
por siclogos preparados en los mensajes del
proyecto, por el equipo de proyecto, por usuarios
que actan como monitores, por ejecutivos, etc.
Puede emplear variados medios creativas: Intranet, e-learning, Internet, clases presenciales, videos, teleconferencia, etc...
Puede comenzar en etapas tempranas del proyecto, se programa en detalle en cada etapa.
No tiene que ser extensa, aunque s bien realizada,
con preparacin en pedagoga de quienes van a capacitar. En especial, lo que ya sabemos de armonizar
las variadas dimensiones del ser humano: espiritual,
intelectual, emocional y corporal

JUAN BRAVO

222

21. SEGUIMIENTO
Realizar seguimiento es llevar control del avance del
proyecto completo y en cada etapa. Se monitorean
variables crticas del proyecto (costos, plazos, hitos,
satisfaccin de usuarios, calidad, etc.) Desde este
punto tiene relacin con el diseo de indicadores.
Es necesario que exista algn nivel de
control centralizado y que el equipo de
direccin del proyecto tenga la
informacin inmediata del avance.
Como es sabido, es indispensable que la informacin para el seguimiento sea oportuna y confiable.
Esto significa invertir en el seguimiento para tener
en todo momento la informacin actualizada, los
indicadores que efectivamente se puedan monitorear, por el costo y el tiempo que significan.
Ideal sera un Cuadro de Mando del proyecto donde
se viera en lnea el avance del proyecto.
El sueo es una sala de control donde se vea el
avance de todos los proyectos de la organizacin,
con las alertas correspondientes cuando algo se sale
de rumbo, por ejemplo, si el proyecto ya no es necesario para el usuario, se comienza a retrasar o los
buenos resultados son mucho mejores a lo esperado.
El seguimiento sirve para corregir desviaciones, para
fortalecer un buen resultado e incorporar al mtodo
de la empresa una buena nueva prctica.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

223

22. CUIDAR LA SOLUCIN ANTERIOR


Cuidar la solucin anterior significa que al mismo
tiempo que se trabaja en la nueva solucin, se aplica
alguna forma de continuidad de lo existente. Incluso
se sigue realizando mejora continua de la antigua
solucin.
En algunas experiencias incluso se
designa un gerente lder de continuidad, al
mismo tiempo que otro gerente lder se
encarga del proyecto de cambio.
Es una estrategia tenaza, donde un brazo corresponde al corto plazo (continuidad de lo existente) y
el otro al largo plazo (el nuevo proyecto).
Es recomendable porque ofrece la tranquilidad de la
continuidad en caso que el proyecto de cambio tenga
alguna dificultad, desafortunadamente, una situacin
bastante frecuente De hecho, estos proyectos son
tpicamente de alto riesgo, porque involucran una
gran cantidad de variables, no todas fciles de controlar: personas, procesos, estructura organizacional
y tecnologa por un lado, costos y plazos por otro en
un ambiente siempre dinmico.
Enlaza este camino con la necesidad de RS de mantener al menos el nivel de servicio previo al inicio
del proyecto mientras este dure, dejando de lado la
ingenuidad de desmantelar lo que se tiene porque la
felicidad ya viene (la nueva solucin).

224

JUAN BRAVO

23. CONTINUIDAD OPERACIONAL


Se refiere a incorporar en el proyecto los elementos
que permitan una solucin fuerte y robusta en lo que
se refiere a la continuidad de las operaciones cuando
el proyecto est en funcionamiento, ms all de slo
tener planes de contingencia
Objetivos del plan de continuidad operacional:
Crear consciencia en el equipo de trabajo y en los
usuarios de las implicancias de una contingencia
en la continuidad de los productos y servicios.
Minimizar interrupciones a las operaciones del
negocio y limitar la severidad de la interrupcin.
Minimizar prdidas financieras.
Agilizar la restauracin de los servicios y reiniciar
operaciones crticas en un tiempo breve.
Asegurar a los clientes la proteccin de sus intereses y mantener la buena imagen de la empresa.
La continuidad operacional est
relacionada con la seguridad de las
operaciones y la calidad de la informacin
(La Superintendencia de Bancos e
Instituciones Financieras ha normado en
este sentido en Chile).
La Administracin del Riesgo Operacional (ARO)
es la gua. Segn Basilea, el riesgo operacional es el
Riesgo de prdida directa o indirecta causada por
una insuficiencia o falla de los procesos, gente y
sistemas internos o por un acontecimiento externo.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

225

24. PLAN DE RECURSOS FSICOS DEL


PROYECTO
El plan de recursos fsicos se refiere a disponer
oportunamente de los elementos que se requerirn
en el proyecto: equipos computacionales, redes, licencias, escritorios, espacio fsico, baos, comedores y otros.
Un trabajo bien hecho en materia de
recursos fsicos tendr su nivel de
influencia en la moral del equipo de
trabajo y en los plazos.
El plan considera no solamente indicar el requerimiento sino tambin la forma de lograr el recurso
fsico.
Tambin contempla quien se hace cargo de bienes
cuando corresponde, la administracin de los recursos durante el proyecto y que sucede con ellos cuando este concluye.
Una buena alternativa es tener convenida alguna
forma de externalizacin tanto de la provisin de los
recursos como de su administracin, ya sea como
plan A o B (el principal y el de contingencia).
Cuidar de no dejar de lado los aspectos contables y
de formalizacin de esos recursos, especialmente la
distincin entre inversin y gasto entre ellos, por el
diferente tratamiento que implica.

JUAN BRAVO

226

25. KILL TIME


Un Kill time se define como momento de cancelacin del proyecto.
Es decir, bajo qu condiciones conviene cancelar el
proyecto, lo cual queda definido en el plan de proyecto y se revisa al inicio de cada etapa.
Por ejemplo, el proyecto se cancela si se consume el
presupuesto completo ms un 10%, si la duracin
excede un 10% al tiempo asignado, si hay un cambio
importante en las reglas del juego de una inversin o
si una tecnologa fundamental no estar disponible.
Se aplica la sabidura de que si el proyecto no termin cuando deba o gast ms all del presupuesto,
lo ms probable es que nunca termine.
Asumir los costos a tiempo acota las
prdidas a niveles que las organizaciones
pueden soportar. Esperar puede poner en
riesgo su existencia.
La organizacin debe revisar las polticas al respecto
porque hay proyectos que deberan ser cancelados
pero continan porque el equipo de trabajo y ejecutivos temen por las represalias. El resultado es una
prdida par la organizacin varias veces ms que el
costo del proyecto33.

33

Es como la organizacin con cultura del terror y de bsqueda de


culpables, con lo cual logran que todas las personas callen las deficiencias que observan (sobre todo las propias).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

227

26. CONTROL DE CAMBIOS


El control de cambios tiene dos interpretaciones:
durante el desarrollo y durante la operacin.
Durante el desarrollo del proyecto son cambios en
las especificaciones. No hay problema si son necesarios, el mtodo debe contemplar la facilidad de incorporacin cambiando la serie de modelos que da
origen a la solucin.
Si se emplea desarrollo en espiral se
facilita la incorporacin de los cambios
porque normalmente se incluyen en la
siguiente vuelta de la espiral.
Durante la operacin de la solucin se refiere a un
procedimiento para cambios menores, del tipo:
Emisin de una solicitud de cambio.
Recepcin, autorizacin y estudio de impacto:
Se presenta el requerimiento al comit respectivo
con el plan de desarrollo, incluyendo equipo de
trabajo y costos.
Por supuesto, un procedimiento de este tipo depende
de muchos factores y actores (una mesa de ayuda,
usuarios, dueos de la solucin, etc.
Se realiza mejora continua de la aplicacin hasta que
se llegue a un nuevo ciclo de rediseo programado
de la solucin, recomendable cada dos aos en promedio. Muchos cambios menores no fundamentales
pueden esperar hasta entonces.

228

JUAN BRAVO

27. GESTIN DEL CAMBIO


Esta prctica se refiere a la gestin del cambio en las
personas. Est ms al final porque varios de los elementos de la buena gestin del cambio estn contemplados en las practicas anteriores, tal como RS,
sensibilizacin, capacitacin, direccin del proyecto,
exposiciones y entrevistas, entre otros.
Vital es incorporar en forma personalizada a todos
los actores relevantes tal como predicaba F. W.
Taylor con su administracin cientfica, tipo Coaching hoy distinto a la capacitacin masiva.
La coherencia del equipo interno en
cuanto a su propia disposicin al cambio
es vital para lograr la disposicin al
cambio de los usuarios.
En todo sistema existe una fuerza natural que tiende
a dejar las cosas tal como estn, es el instinto de
conservacin del sistema, la homeostasis. Cuando
uno reconoce la existencia de las fuerzas de resistencia al cambio, deja de criticar y efectuar luchas
estriles, ahora puede orientar su energa al cambio
de carcter permanente: educacin, autonoma y
alineamiento de intereses, adems de las acciones
concretas antes y durante la realizacin de un proyecto especfico: anticipacin y participacin.
Otro elemento es la negociacin, es decir, una conversacin creativa destinada a lograr la ms alta satisfaccin de los intereses mutuos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

229

28. GESTIN DE PROVEEDORES


Cada vez es ms frecuente que en los proyectos participen personas y empresas externas a la organizacin. Es indispensable una buena gestin de ellos
para el xito del proyecto.
A veces se malentiende la gestin de
proveedores, errneamente se piensa en
tener una funcin que optimice solamente
el inters de la organizacin y esquilme
a los proveedores (malos pagos, malas
condiciones laborales, etc.) desconociendo
que eso se volver contra la misma
empresa.
Una verdadera gestin de proveedores va por el oro,
como se ensea en los buenos cursos de negociacin, donde se maximiza el inters de la empresa y
de los proveedores, mucho ms all de pagos justos
y oportunos y buenas condiciones laborales. Se trata
de lograr la mayor armona en los intereses buscando aplicarse todos con el mayor entusiasmo y creatividad al xito del proyecto.
Como parte de la buena gestin debe est la claridad
de los objetivos de su trabajo, establecer condiciones
igualitarias para trabajadores propios y de contratistas y requerimientos precisos (puede ser que el requerimiento sea definir requerimientos).
Es ideal establecer alguna forma de alianza que capitalice el aprendizaje en beneficio mutuo.

JUAN BRAVO

230

PARTE FINAL.
CONCLUSIONES,
ANEXOS Y
BIBLIOGRAFA

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

231

El que se enamora de la prctica sin ciencia es como el


marino que sube al navo sin timn ni brjula, sin saber
con certeza hacia donde va.
Leonardo da Vinci (Montaner, 2002, p. 83)

JUAN BRAVO

232

CONCLUSIONES
Los procesos de negocios constituyen la columna
vertebral de la organizacin, la estructura en medio de
la espontaneidad de la prctica.
Seely y Duguid (2001, p. 91)

En pocas palabras, es indispensable:


Seguir mtodo.
Tener al menos instancias internas para estudios, metodologa y toma de decisin.
No saltarse etapas.
Desarrollar polticas corporativas para aplicar
con la mayor eficiencia las prcticas transversales.
Aplicar mejora continua del mtodo (etapas y
prcticas transversales).
Se requiere implantar correctamente el mtodo, contemplando sus claves:
Clave 1. Visin de conjunto
Clave 2. Mnimo indispensable
Clave 3. Participacin de todos los actores
Clave 4. Iteracin
Por supuesto, adaptar el mtodo que se
haya dado la organizacin a cada
proyecto particular manteniendo un
tronco comn.
En fin, para evitar costos innecesarios y ganar los
beneficios de proyectos bien realizados, es necesario

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

233

aplicar la Visin de Proyectos de Negocios, donde es


vital alinear el propsito del proyecto con la estrategia de la organizacin, cuantificar todo y orientar el
proyecto al cliente.
Mucho xito en la gestin de sus proyectos.
Le agradezco su lectura,
JBC

JUAN BRAVO

234

ANEXO 1. RELACIN CAUSAL


Existen varias tcnicas asociadas a la deteccin de
causas: rbol de decisin, tcnica de los por qu y
otras detalladas en el texto. Veremos aqu tcnica
causa - efecto de Kaoru Ischikawa junto con la deteccin de prioridades de W. Pareto en una versin
que hemos venido utilizando en la deteccin de problemas (de gestin de procesos y seis sigma), en la
deteccin de los riesgos de fondo en eventos de
prdida de la administracin del riesgo operacional y
en la mejora continua.
La tcnica causa efecto se utilizaba principalmente
en el mbito industrial y las espinas hacan referencia a los temas relacionados: materiales, almacenamiento, etc. Aqu las espinas son los elementos
del modelos de negocios: estrategia, personas, procesos, estructura organizacional y tecnologa.
En este caso la aplicamos buscando el problema de
fondo de uno o ms sntomas.
P ersonas

P rocesos

S ntom a(s)

E strategia

E structura

T ecnologa

Por ejemplo, para un sntoma de descuadraturas de


caja, en la lnea personas se podra anotar, entre
otras causas:

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

235

Falta de capacitacin
Escasa motivacin
Personas no idneas
Dificultades entre colaboradores y jefe
Anotando ms causas en las otras lneas nos acercaremos poco a poco al problema real.
Lo habitual es anotar muchas causas, como en una
tormenta de ideas.
Entonces, se detectan causas, se analizan y se priorizan, indicando en que porcentaje influye cada una
sobre el sntoma, riesgo o lo que sea que estemos
analizando. La frmula es Y = F(x).
Se grafican y se lleva un acumulado, cuando se llega
al 80% se tiene el conjunto de causas ms relevantes, los pocos crticos.
Se usa generalmente un grfico acumulativo, donde el porcentaje de la siguiente causa suma al acumulado anterior. Cuando la
columna llega o pasa el 80%, hasta ah
llega la lista de causas relevantes.

El nivel de profundidad al cual se llega tiene que ver


con la tcnica de desarrollo en espiral y con el nivel
de error aceptable para la organizacin en algn nivel de sigma.
Esta forma de trabajo es recursiva, puede ser necesario que una causa tenga a su propio anlisis causal y

236

JUAN BRAVO

as sucesivamente. Es decir, X1 = F(x1), esquema


central en la tcnica Six Sigma.
A propsito de Six Sigma, en su libro Anlisis de la
causa raz, los autores Wilson, Dell y Anderson dicen (1999, p. 6): En Estados Unidos el 0.1% de
fallas significa: 16.000 piezas de correo perdidas por
hora, 20.000 prescripciones de medicamentos incorrectas por ao, 500 operaciones quirrgicas incorrectas por semana, 50 bebs recin nacidos se les
caen a los mdicos por da, 22.000 cheques deducidos de cuentas corrientes equivocadas por hora, su
corazn no late 32.000 veces por ao.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

237

ANEXO 2. UML
UML es la sigla de Unified Modeling Language,
literalmente: Lenguaje Unificado de Modelamiento, aunque la idea queda mejor expresada al decir:
Modelamiento Visual del Software, expresin que se
est utilizando cada vez ms en espaol.
UML est orientado a la especificacin, visualizacin, construccin y documentacin de los productos de software. Se le considera como parte del desarrollo tecnolgico de un modelo integral del cambio.
UML surgi de los aportes combinados de tres pioneros en el campo del modelamiento orientado a
objetos, los doctores Grady Booch, Jim Rumbaugh e
Ivar Jacobson, a peticin de la OMG (Object Management Group), organizacin creada por las empresas lderes mundiales de la industria del software
(entre las cuales se encuentran IBM, Unisys, Alcatel,
Toshiba y Microsoft) destinada a fijar estndares en
la industria con la tecnologa de objetos.
UML incluye una amplia variedad de diagramas,
entre los que se encuentran:
Modelo Conceptual, para identificar conceptos
del mundo real y las asociaciones entre ellos.
Casos de uso, para mostrar las interacciones con
el usuario.
Diagramas de estado para ilustrar el funcionamiento (la lgica de un caso de uso).

238

JUAN BRAVO

Diagramas de instalacin (Deployment) para mostrar el mapeo del software en la configuracin del
hardware.
Diagramas de interaccin, tales como de colaboracin (mensajes entre clases u objetos) y de diseo de clases.
Glosario: incluye la definicin de todos los trminos que se emplean en los modelos de UML, es
aplicable en todas las etapas del desarrollo.
En UML se usa el trmino artefactos para referirse a
diversas agrupaciones de modelos, a modelos individuales o a cualquier elemento que sea identificado
individualmente. Cuando en el contexto de UML se
usa la palabra sistema, es porque normalmente hace
referencia al sistema computacional.

Casos de uso
Los casos de uso (use case) permiten mostrar las
interacciones con el usuario. Tal como plantea Ivar
Jacobson: es una narracin que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema computacional para completar un proceso. Tambin se puede ver como cualquier punto
de interaccin con el computador, principalmente
detectados desde las actividades del flujograma de
informacin.
El caso de uso describe lo que importa al usuario,
desde su perspectiva, es un tem especfico de funcionalidad. El caso de uso describe el curso normal
de los eventos, las excepciones son incorporadas

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

239

como observaciones al final del texto. Por ejemplo,


si la narracin dice: se ingresa la identificacin del
cliente, no explicamos que sucede si esa identificacin es invlida, simplemente seguimos el curso
normal de los sucesos. En algunos casos, las excepciones podran dar origen a otros casos de uso.
Se aplican a la definicin de los requerimientos
computacionales del sistema de informacin. Los
casos de uso pueden ser llamados:
De alto nivel, explicados en dos o tres oraciones.
Expandidos, pueden contener cientos de oraciones, se incorpora una descripcin minuciosa destinada a la implementacin computacional.
Por ejemplo:
E je m p lo d e ca so d e u so d e a lto n ive l
T e rm in a l e n la tie n d a

Vendedor

C o n su lta r situ a ci n
d e l clie n te

S a ld o d e cr d ito y
p o sib ilid a d e s d e cu o ta s.
A p o yo e n re a liz a ci n d e
c lcu lo s re sp e cto a
fin a n cia m ie n to

Un vendedor consulta por la informacin de un cliente


en el terminal de una tienda minorista (dominio).
Incorpora el concepto de actor. Un actor es alguien o
algo fuera del sistema que interacta con el sistema, en
este caso el vendedor.

JUAN BRAVO

240

ANEXO 3. RUP
Cabe agregar que los autores sealados en el anexo
2 son tambin creadores de Rational Software Corporation (adquirida por IBM en el ao 2003), desde
donde han propuesto el RUP (Rational Unified Process), un mtodo completo para el desarrollo de
software que rpidamente est siendo incorporado
en la industria informtica.
Aunque RUP est dirigido al campo de la tecnologa
de informacin, tiene muchos puntos de encuentro
con la gestin de procesos, de ah la idea de incorporar algunas lneas. Por ejemplo, est basado en las
seis mejores prcticas del desarrollo de software,
muy cercanas a las propuestas de la tesis (en particular los captulos octavo a decimoquinto):
1. Desarrollo Iterativo (o en espiral). Se resuelven
primero los casos de uso (o requerimientos) ms
importantes, aquellos donde el riesgo es mayor.
2. Manejo de los requerimientos. Se seleccionan,
organizan y documentan los requerimientos, se
establece una prioridad en base a riesgos. Se aplica la tcnica de casos de uso, donde se establece
lo que importa para el usuario, incluyendo la interfaz.
3. Uso de una arquitectura de componentes. Estableciendo una comparacin con la ingeniera de
construccin, esta etapa es la de arquitectura.
Aqu se establece la arquitectura de la solucin de
software, debe cumplir que el software sea fcil

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

241

4. de usar, funcional, de buen rendimiento, reusable,


entendible, econmico, factible, esttico y elegante.
5. Modelamiento visual del software. Se aplican
aqu los modelos que provee el Unified Modeling
Language (UML), el cual est orientado a la especificacin, visualizacin, construccin y documentacin de los productos de software.
6. Verificacin de la calidad. Siendo la calidad uno
de los ms graves problemas de la construccin
tradicional de software, se propone incluir indicadores de calidad y verificaciones en cada punto
del proceso de desarrollo. Se incorpora una labor
de Testing en el ciclo de vida, en cada vuelta de la
espiral.
7. Control de cambios. En un ambiente de creciente
complejidad: mltiples desarrolladores, equipos
de trabajo, instalaciones, versiones del software,
proyectos y plataformas, se requiere un control
explcito de requerimientos, configuracin y mediciones.
En este mtodo, cada iteracin acerca ms el sistema
a lo que desea el usuario y a su plena funcionalidad,
por otra parte, cada versin va quedando en funcionamiento real.
Mayor informacin puede encontrarse en
www.omg.org, www.rational.com, www.uml.com y
otros sitios relacionados.

JUAN BRAVO

242

ANEXO 4. NORMAS DE CALIDAD DEL


SOFTWARE
La idea es revisar algunas normas de calidad desde
las cuales aprender buenas prcticas, adems, un
trabajo en gestin de procesos puede ser complementario con la certificacin.
Se revisarn brevemente las normas CMM, ISO
9000 y Tick IT (como ejemplo, muchas compaas
de xito en la India34 se han adherido a una o ms de
estas normas). Un aspecto comn a todas ellas es el
costo, del aprendizaje, de la certificacin y de la infraestructura para cumplir la norma. Tambin es
comn el beneficio:
Que el proyecto se site dentro de los plazos y costos previstos.
Que el desarrollo sea de calidad.
Que se pueda rastrear y que se pueda hacer una auditora de su cumplimiento.
Que el desarrollo sea eficiente y eficaz.

34

En OECD (2000, p. 140) se aprecia el impacto de tecnologas como


CMM en la India, donde hasta 1998 se haban certificado 89 de las
250 compaas top en la produccin de software , otras 136 estaban
en proceso de certificarse y slo 25 compaas, el 10%, no tena planes al respecto. Luego (ibid, p. 139) se precisa que la certificacin es
segn normas reconocidas internacionalmente, tal como: CMM del
SEI, ISO 9000 y/o TickIT, una norma inglesa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

243

CMM
CMM (Capabilitiy Maturity Model), traducido frecuentemente como Modelo de Madurez de Capacidades, es la norma preferida en el desarrollo de
software. Tiene niveles cada vez ms exigentes que
la organizacin candidata debe ir certificando.
CMM provee un detalle exhaustivo de cada nivel de
madurez y no es difcil de interpretar. Incorpora todo
un sistema de mediciones a la madurez de la organizacin respecto de las capacidades del desarrollo de
software, lo cual facilita los procesos de evaluacin.
Los niveles de madurez que seala CMM son cinco:
1. Nivel Inicial (Initial): por omisin todas las empresas estn en esta categora. Aqu se describe la
pseudoanarqua presente en el desarrollo. El proceso de desarrollo es prcticamente inexistente.
Se trabaja apagando incendios con esfuerzos
heroicos. Existe inmadurez en el desarrollo. No
existe visibilidad acerca del proceso de desarrollo
ni de los resultados del producto de software
(tiempos, costos, errores, etc.).
2. Nivel Repetible (Repeatable): en este nivel el
proceso se puede repetir, existen tcnicas y normas comunes, hay seguimiento de costos, plazos
y funcionalidad en los procesos.
3. Nivel Definido (Defined): el proceso de desarrollo de software est documentado, estandarizado e
integrado.

244

JUAN BRAVO

4. Nivel Gestionado (Managed): los procesos estn


bajo un nivel de control donde la prediccin de
plazos y costos es posible.
5. Nivel de optimizacin (Optimizing): se incorpora
el mejoramiento continuo de los procesos logrado
por retroalimentacin y por ideas y tecnologas
innovadoras.
CMM surgi en 1993 de una iniciativa del Software
Engineering Institute (SEI35), con toda una historia
anterior que incluy estudiar una amplia cantidad de
compaas de xito en el desarrollo de software.

ISO 9000
ISO corresponde a la Organizacin Internacional de
Estandarizacin. La serie de normas ISO 9000 son
bastante conocidas. Destaca que el sector informtico fue de los ms reacios en adherirse a ellas.
35

El Software Engineering Institute (SEI) es un Centro de investigacin y desarrollo financiado con fondos federales patrocinado por el Departamento de Defensa de Estados Unidos, por
intermedio de la Oficina del Subsecretario de Defensa para la
Adquisicin, Tecnologa y Logstica. El contrato del SEI para la
investigacin aplicada en el tema de la metodologa de software,
fue adjudicado por licitacin pblica a la Universidad Carnegie
Mellon en Diciembre de 1984. La misin del SEI es: Promover y
avanzar en la prctica de la Ingeniera de Software, porque el
software de calidad, producido conforme a plazos y dentro de
un presupuesto, es un componente crtico para los sistemas de
defensa de Estados Unidos. Cumple esta misin promoviendo la
evolucin de la Ingeniera de Software desde ser una actividad
ad-hoc de alto contenido de trabajo de personas hacia ser
una disciplina bien gestionada y apoyada por tecnologa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

245

Un punto de encuentro se est produciendo con la


masiva incorporacin de la gestin de procesos al
desarrollo de software. Esta es una ventaja de la
aplicacin de las normas, su amplitud.
Actualmente se considera tan importante la gestin
de procesos que incluso fue considerada en la nueva
redaccin de normas ISO, en las denominadas Normas ISO 9000:2000. De hecho, la principal diferencia con las normas de la versin 1994 es la introduccin del concepto de gestin por procesos interrelacionados. En estas nuevas normas la gestin de calidad tiene un enfoque ms integral y sistmico, lo
cual tambin es pilar de este trabajo y de la gestin
de procesos en general. Incluso, se incorpora la mejora continua. Dice la nueva Norma ISO 9001:2000
(p. vi): Para que una organizacin funcione de manera eficaz, tiene que identificar y gestionar numerosas actividades relacionadas entre s Frecuentemente el resultado de un proceso constituye directamente el elemento de entrada del siguiente proceso La aplicacin de un sistema de procesos dentro
de la organizacin, junto con la identificacin e interacciones de estos procesos, as como su gestin,
puede denominarse como enfoque basado en procesos.

Tick IT
Surgi en Gran Bretaa por las carencias que se detectaron en las normas ISO 9000 orientadas a la industria del software, tales como difcil interpretacin

246

JUAN BRAVO

y aplicacin, inexistencia de aspectos crticos del


desarrollo y de implementar en la forma de un proceso evolutivo. El encargado de realizar los estudios
y patrocinar la nueva norma fue el Departamento de
Industria y Comercio (DTI: Departament of Trade
and Industry). Actualmente el encargado de Tick IT
es el DISC, oficina dependiente del British Standards Institution (BSI) Standards Division.
Tpicamente, un sistema de calidad Tick IT sigue
pautas como las enumeradas a continuacin (las cuales seran sujetos de revisin en una auditora):
1. Elaboracin de propuestas y revisin de contratos asegurando que todos los requerimientos
estn bien especificados y que la organizacin
tiene la capacidad para cumplirlos.
2. Anlisis y especificacin de los requerimientos
del sistema asegurando que sean revisados y
acordados con el cliente.
3. Planeacin, control y monitoreo del avance del
desarrollo respecto al plan comunicando a todas
las partes afectadas y que avise oportunamente
de problemas potenciales.
4. Planeacin de la calidad del proyecto, especificando las inspecciones, revisiones y pruebas requeridas durante el desarrollo.
5. Establecer polticas y objetivos de calidad generales de la organizacin que sirvan para alinearla
en todas sus actividades, procedimientos y polticas especficas.
6. Implantar y mantener un sistema de aseguramiento de calidad.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

247

ANEXO 5. DESARROLLO EN ESPIRAL


DEL PROYECTO
El desarrollo en espiral es una tcnica donde el proyecto de negocios abarca una porcin cada vez mayor de los requerimientos y en cada iteracin avanza
en calidad, eficacia y eficiencia.
Este mtodo est dirigido a proyectos de cambio
mayor. Simplificando, tambin se puede aplicar a
proyectos de cambio un poco menor, como en el
benchmarking o la mejora, aunque resultara un poco forzado.
Dice Steve McConnell (1996, p. 153): El modelo
de espiral es un modelo de ciclo de vida orientado a
riesgos que divide un proyecto en miniproyectos
Se parte de una escala pequea en medio de la espiral, se localizan los riesgos, se genera un plan para
manejarlos y a continuacin, se establece una
aproximacin a la siguiente iteracin Se avanza
un nivel en el rollo de canela, se comprueba que
se tiene lo que se desea y despus se comienza a trabajar en el siguiente nivel.
Cada vuelta de la espiral es un ciclo completo de
desarrollo para el grupo de requerimientos seleccionados. En cada iteracin la complejidad se incrementa progresivamente y se reduce el riesgo. Por
supuesto, y al igual que en un proyecto tradicional,
un desarrollo de esta naturaleza exige amplio esfuerzo de gestin y operacin.

248

JUAN BRAVO

Rediseo de procesos
en espiral. Cada vuelta de la espiral es un
ciclo completo de
trabajo para un grupo
de requerimientos
seleccionados.

Se espera que una vuelta de la espiral demore entre


dos y diez semanas, para un rango de entre el 5% al
20% de los requerimientos.
Esta es la nueva propuesta para los proyectos menos
estructurados. La forma tradicional es la tcnica
llamada desarrollo en cascada, en la cual se pretende avanzar en cada etapa con todos los requerimientos a la vez, en consecuencia, recin se ven resultados al trmino del proyecto, tal vez un ao en el
caso de proyectos medianos.
En el desarrollo en espiral cada vuelta o ciclo es un
pequeo desarrollo en cascada, porque pasa por
todas las etapas, aunque para un nmero relativamente pequeo del total de requerimientos.
Al trmino del proyecto (despus de todos los ciclos) se recomienda incorporar la mejora continua
(ver etapa 7 del mtodo).

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

249

ANEXO 6. GESTIN DE CALIDAD EN


PROYECTOS
Es un tema fundamental abordado por todos los
mtodos existentes, por ejemplo, en el PMBOK del
PMI36 (Project Management Institute) dicen:
La GCP (Gestin de Calidad en Proyectos) incluye
los procesos requeridos para asegurar que el proyecto satisfar las necesidades por las cuales fue
iniciado, contempla: planificacin de la calidad,
aseguramiento de la calidad y control de calidad.
La Planificacin de la calidad implica identificar qu estndares de calidad son relevantes para el proyecto y luego determinar como satisfacerlos.
El Aseguramiento de la calidad consiste de todas
las actividades, planificadas y sistemticas, implementadas en el marco del sistema de calidad,
requeridas para brindar confianza en que el
proyecto va a satisfacer los estndares de calidad relevantes.

36

El Control de Calidad implica verificar los resultados especficos del proyecto para determinar si estos cumplen con los estndares de calidad relevantes e identificar maneras de eliminar
las causas de los resultados insatisfactorios.

Ver tambin el anexo 9.

250

JUAN BRAVO

Se complementa con la definicin en la Iso


9000:2000 Calidad es la totalidad de las caractersticas de una entidad que le confieren la aptitud para
satisfacer las necesidades implcitas y establecidas.
Ver tambin anexo 9.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

251

ANEXO 7. CASO BANCOESTADO


Detallado en el libro Gestin de Procesos

Se seleccion el proyecto Centralizacin de Procesos de Sucursales porque los resultados obtenidos


son impresionantes:
Fueron liberadas 1.100 personas destinadas al
Back-Office, lo cual significa una importante cifra
de ahorro en remuneraciones.
La aplicacin de responsabilidad social es amplia,
ninguna de estas personas fue despedida, se realiz una reconversin en gran escala que permiti
reforzar grandemente el rea comercial y de servicio al cliente. Un dato puede bastar para entender la magnitud del esfuerzo: las colocaciones en
el mercado chileno de crditos de consumo pasaron desde 5% a 13%.
Se logr invertir el orden del trabajo realizado en
las sucursales entre Back-Office y Front-Office,
desde un 20% destinado al cliente hasta un porcentaje superior al 80%.
Se trat de un proceso ampliamente participativo,
donde los mismos trabajadores sealaban mejoras
que eventualmente significaban eliminar su propia funcin.
Se realiz un pacto social con los trabajadores
para evitar el temor al despido.
Se cont con la colaboracin del sindicato de la
empresa.

252

JUAN BRAVO

Para la gestin del cambio se design a un gerente


lder del proyecto de amplia ascendencia dentro de
los trabajadores del Banco, quien, junto con el Subgerente de Ingeniera de Procesos, la encargada de
comunicacin y el suscrito, realiz talleres de
brainstorming con funcionarios en diferentes ciudades de Chile buscando no slo el apoyo sino tambin
las ideas de los involucrados para el mejoramiento
de la propuesta.
Consta al autor que en un solo evento (agosto de
2001), se generaron alrededor de 100 iniciativas,
algunas de las cuales fueron Quick Wins, se vieron
resultados a corto plazo y se gan en motivacin
tanto de los operadores del proceso como de la direccin.
La gran diferencia de este proyecto exitoso con otros
que no lo fueron fue la aplicacin sistemtica de
mtodo.
Tambin el caso es considerado un ejemplo de coordinacin, porque para lograr el crecimiento comercial se opt por privilegiar la contratacin interna o
reconversin.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

253

ANEXO 8. ITIL
ITIL (Information Technology Infrastructure Library) se traduce como Biblioteca de Infraestructura
de Tecnologas de Informacin. Una traduccin no
literal es Cumplimiento de niveles de servicios en TI
con base en una serie de libros (unos 60 a fines de
los ochenta) con las mejores prcticas.
Todo surge de los bajos estndares de servicios TI
en el Reino Unido (similares a los de otras latitudes), principalmente los que se refieren a los servicios a usuarios durante la etapa de operacin (ms
del 80% del total). Por lo tanto, se encarg al CCTA
(Central Comunications and Telecom Agency) una
propuesta. La respuesta fue ITIL, la cual poco a poco ha ido ganando terreno como referente en el
campo de los servicios TI.
El objetivo es la mejora en la atencin de los clientes y usuarios y la reduccin de costos y riesgos.
ITIL documenta buenas prcticas para lo que denomina los 6 componentes del Soporte del Servicio:

Gestin de Configuracin
Mesa de Servicios
Gestin de Incidencias
Gestin de Problemas
Gestin de Cambios
Gestin de Difusin

Tiene cierto parecido con CMM en los niveles de


madurez respecto a la calidad de los servicios TI:

254

JUAN BRAVO

existencia de pre-requisitos mnimos, intento de gestin, capacidad de proceso, integracin interna, productos, control de calidad, informacin de gestin,
integracin interna e interfaz.
Son propuestas de amplio sentido comn, tal como
la de administrar una base de datos de temes de
configuracin: elementos de software, hardware,
documentacin, etc. Incluyendo su estado y relaciones, base a su vez del anlisis de incidencias y problemas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

255

ANEXO 9. PMI
PMI son las siglas del Project Management Institute,
una organizacin de clase mundial que recoge las
mejores prcticas para la realizacin de proyectos y
las presenta en documentos, uno de los ms relevantes es el PMBOX.
El PMI define 5 grandes fases para todo proyecto:
Iniciacin
Planificacin
Ejecucin
Control
Cierre
En forma equivalente a las prcticas transversales
del mtodo GSP, se definen nueve reas de conocimiento: Integracin, Alcance, Costo, Tiempo, Calidad, Recursos Humanos, Comunicaciones, Riesgo y
Abastecimientos.
Son grupos de criterios generales para la buena gestin y administracin de proyectos.
Existe una organizacin local en la mayora de los
pases de Latinoamrica, son llamados Captulos.
Es posible lograr la certificacin del PMI.
Ms en www.pmi.cl
www.pmi.org.
Ver tambin anexo 6.

www.pmi.com

JUAN BRAVO

256

ANEXO 10. MODELO PARA CASO DE


NEGOCIOS
Este es un modelo para plantear un proyecto, se le llama caso
de negocios porque el beneficio debe ser positivo, para lo
cual se calcula el VAN interno y social.
Sea cual sea el mbito de la empresa, con o sin fines de lucro,
es evidente que los proyectos se proponen porque tienen ms
beneficios que costos. En el caso de negocios se explicitan
esos costos y beneficios.
El caso de negocios se realiza en la etapa de factibilidad del
mtodo GSP y es llamado Plan de Proyecto cuando est aprobado.
Incluye, por trazabilidad, todo lo realizado a la fecha en la
etapa de concepcin y en la misma factibilidad, tal como el
estudio de alternativas desechadas.
Parte I. Necesidad y solucin
A. Respecto a la necesidad (oportunidad o problema)
Enunciado de la necesidad: se refiere al problema de fondo
Proceso: dnde se detecta la necesidad
Dueo:
Quin Detecta:
Descripcin de la situacin: puede adjuntar textos, grficos y otros
antecedentes para entender la necesidad
Anlisis de causa efecto: exponer acerca de los sntomas, el problema de fondo y sus causas
Costos Internos: del problema o de oportunidad por la necesidad
insatisfecha
Costos Externos: del problema o de oportunidad por la necesidad
insatisfecha, considera la cadena logstica. Se refiere a costos de los
grupos de inters por la existencia del problema, por ejemplo, el

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

257

costo que asume el cliente cuando se le hace esperar o el del proveedor cuando se la paga tardamente
B. Impacto estratgico del problema o necesidad
Cmo afecta a las definiciones estratgicas de la organizacin:

C. Descripcin de la solucin seleccionada (con las observaciones


del Comit de Estudios)
Descripcin general: puede adjuntar antecedentes de la solucin
propuesta: planos, folletos, etc.
Beneficios y costos internos: VAN
Beneficios y costos externos: puede ser llamado VAN social
Aporte estratgico: Principalmente respecto de la definiciones estratgicas de la empresa y en particular de procesos y tecnologa
Imagen: mayor o menor aporte a la imagen de la empresa
Duracin del proyecto
Beneficios laterales: (internos y externos)
Solucin completa: Si resuelve o no ntegramente la necesidad
Alternativas estudiadas: Incluya aqu:
1) Lista de opciones creativas que fueron exploradas
2) Lista de las alternativas que fueron formalmente estudiadas y
por qu fueron desechadas. Adjunte el estudio de cada alternativa estudiada
Restricciones de la solucin
D. Detalle de cmo se ven afectadas otras reas, procesos, sistemas
computacionales y otros efectos (internos y externos)
reas
Procesos
Sistemas

JUAN BRAVO

258
Otros efectos

E. Detalle de costos de la alternativa


Por ejemplo:
Infraestructura
Hardware y Software
Implementacin
Recursos Internos
Insumos, Otros)

(RRHH,

Detalle todos los costos


F. Alcance de la alternativa de solucin
(lo que incluye y lo que deja afuera)
G. Objetivos especficos del proyecto y metas
Por ejemplo:
Objetivos Especficos

Metas

1.
2.
Para cada objetivo especfico podra haber ms de una meta
H. Requerimiento principales del Modelo integral del cambio
Situacin Actual:
Estado deseado:
I. Concepto detrs de la solucin
Generalmente una solucin responde a una conceptualizacin (la
integracin a la cadena logstica, la integralidad, el funcionamiento
de procesos solamente en la Web, etc...)

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

259

Luego, cmo este concepto afecta a los medios principales para el


cambio: personas, procesos, estructura organizacional y tecnologa.

J. Actores del proyecto (detalle de la estructura del proyecto). Incluye, dentro de lo posible, los nombres de los actores
Encargados tcnicos del proyecto
Gestor de la demanda
Prestador del servicio (interno o externo)

Parte II: Prcticas Transversales


Estas prcticas debieran surgir de polticas de la organizacin
y del anlisis de las mejores experiencias, internas y externas
(ver parte 3, libro Gestin de proyectos de procesos y tecnologa). Desde aqu surgen muchas actividades que luego irn
a la Gantt.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

Direccin del proyecto


Plan de la etapa
Exposicin de los planes
Retroalimentacin
El equipo de trabajo
Entrevistas
Comunicacin
Informes
Tcnicas, tipo UML, MP, FI
Herramientas de apoyo:
Trazabilidad
Quick Wins
Costos y duracin
Gestin de Riesgos: Internas y Externas
Gestin de Calidad
Responsabilidad Social
Insercin
Orientacin al cliente
Sensibilizacin

JUAN BRAVO

260

20.
21.
22.
23.
24.
25.
26.
27.
28.

Capacitacin
Seguimiento
Cuidar la solucin anterior
Continuidad Operacional
Plan de recursos fsicos del proyecto
Kill Time
Control de cambios
Gestin del cambio
Gestin de proveedores

Parte III. Forma de abordar las actividades


Puede ser desarrollo en espiral por ejemplo. De sta definicin dependern los ciclos.
Estado de avance global
Etapa o Hito
(global)

Producto
resultado

Ciclo N 1

Segn Informe
Adjunto

Ciclo N 2

Segn Informe
Adjunto

Ciclo N

Segn Informe
Adjunto

Fecha de cumplimiento

Fecha real de
cumplimiento

Ejecucin presupuestaria (M$)


Perodos

Ppto.
Gasto

Gasto
Real

Ppto.
Inversin

Efectiva

Ciclo N 1
Ciclo N 2
Ciclo N .
Total
Proyecto

Nota: el ciclo aplica cuando el proyecto se ha dividido en


perodos y fases, como en el desarrollo en espiral

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

261

Carta Gantt
Se requiere una malla de actividades que permita visualizar el
proyecto integral y resolver aspectos de precedencia, holgura
y ruta crtica.
Anlisis
Diseo
Implementacin
Despliegue
Mejora continua
En algunos proyectos aplica desarrollo en espiral, en otros no,
si aplica, cada vuelta de la espiral sera una fase que tendra
Anlisis, dise, implementacin y despliegue.
Compromiso
Firmas de Jefe de Proyecto, Dueo y Gerente de rea
A llenar por el Comit de Procesos y Tecnologa
Decisin:
Proyecto
Designa Jefe de Proyecto

Designa Usuario lder

(La estructura necesaria)


Fecha inicio del proyecto

Fecha de trmino del proyecto

Prioridad

Fuente de fondos

(alta media baja)


Firma en representacin del Comit de Proyectos
Fecha

Notas:

El objetivo del formulario es planear el proyecto en


detalle.

JUAN BRAVO

262

Pueden presentar este formulario los integrantes de la


organizacin (con la formacin correspondiente) designados para ello por el Comit de Procesos y Tecnologa
El nmero del proyecto es el mismo de la deteccin
de la necesidad, porque el proyecto existe para resolverla (puede suceder que surja un proyecto mayor
con diferentes partes, todas deberan ser coordinadas
por el mismo jefe o lder del proyecto).

Adjunte todo documento generado en el proyecto o en el estudio de la necesidad.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

263

BIBLIOGRAFA
BOOCH, G. (1991): Object Oriented Design with Applications.
USA, The Benjamin/Cummings Publishing.
BRAVO, J. (1984): Flexibilidad de Sistemas, Revista Informtica,
Santiago de Chile, vi-9, pp. 26-28.
BRAVO, J. (1985): Se justifica el desarrollo de un sistema computacional, Revista Informtica, Santiago de Chile, vii-2,
pp. 8-11.
BRAVO, J. (1988): Desarrollo de sistemas de informacin, una
visin prctica, Santiago, Evolucin.
BRAVO, J. (1996): La nueva visin, diseo y construccin de sistemas computacionales, Santiago de Chile, Evolucin.
BRAVO, J. (1997): Planificacin sistmica, Santiago de Chile,
Evolucin.
BRAVO, J. (1998): Anlisis de sistemas, Santiago de Chile, Evolucin.
BRAVO, J. (2005): Gestin de Procesos, Santiago de Chile, Evolucin.
BRAVO, J. (1995-2005): Cartas, Santiago, www.evolucion.cl.
CAMPERO, M. y ALARCN, L. (1999): Administracin de Proyectos Civiles, Santiago de Chile, Pontificia Universidad
Catlica.
DAVIDSON, J. (2001): La Gestin de Proyectos, Madrid, Pearson.
DRUCKER, P. (1993): Administracin y futuro, Buenos Aires,
Sudamericana.
ECHEVERRA, R. (1998): Ontologa del lenguaje, 5 ed., Chile,
Dolmen Ediciones.
FAIRLEY, R. (1987): Ingeniera de Software. Mxico, McGrawHill.
JACOBSON, I., BOOCH, G., RUMBAUGH, J. (2000): El proceso
unificado de desarrollo de software, Madrid, Pearson Educacin S.A.
KRIEGEL, R. (1994): Si no est roto, rmpalo, Bogot, Norma.
MATURANA, H. (1991): El sentido de lo humano, Santiago de
Chile, Dolmen.
McCONNELL, S. (1996): Desarrollo y gestin de proyectos informticos, Madrid, McGraw-Hill.
MONTANER, R. (2002): Leonardo, el primero que se comi el
queso, Barcelona, Gestin 2000.

264

JUAN BRAVO

OECD (2000): Information Technology Outlook 2000, Unin Europea.


PETERS, T. (2004): Re-imagina, Madrid, Pearson.
PORTER, M. (1992): Ventaja competitiva, creacin y sostenimiento
de un desempeo superior, Mxico, Continental.
PRESSMAN, R. (1993): Ingeniera de Software, tercera edicin,
Espaa, Editorial McGraw-Hill.
SEELY, J. y DUGUID, P. (2001): La vida social de la informacin,
Buenos Aires, Prentice-Hall.
SENGE, P. (1992): La Quinta Disciplina, Buenos Aires, Granica y
Vergara.
SENN, J. (1987): Anlisis y diseo de sistemas de informacin,
Mxico, McGraw-Hill.
SOLMINIHAC, H. (2005): La gestin de costos de proyectos,
Clase ejecutiva de El Mercurio, 13 de octubre, B11, Santiago
de Chile.
TAYLOR, F. W. (1969, original de 1911), Principios de la administracin cientfica, Buenos Aires, El Ateneo.
TOLOZA, C. (2005): Cul es la rentabilidad de la informtica en
su empresa?, Diario Financiero, 18 de noviembre, Santiago
de Chile.
VARELA, F. (1990): Conocer; las ciencias cognitivas: tendencias y
perspectivas, Barcelona, Editorial Gedisa.
YOURDON, E. y Coad, P. (1991): Object-oriented Analysis. USA,
Yourdon Press, Prentice Hall Inc.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

265

Entrenamiento
Si desea estudiar estos temas con mayor profundidad, en la pgina www.evolucion.cl puede apreciar
nuestros programas formativos de diplomados y maestras.

Comprar los libros en formato papel


En libreras o desde la misma pgina de Editorial
Evolucin puede comprar los libros en formato papel. www.evolucion.cl

Pago por el libro en formato digital


Este libro en versin digital no es gratis. El valor es
de US$ 15 ( $ 7.500 pesos chilenos). Justificado
por el indispensable retorno econmico para continuar estas investigaciones y por el comportamiento
tico de respeto a la propiedad ajena.

JUAN BRAVO

266
LIBROS DEL AUTOR
EVOLUCIN S.A.

PUBLICADOS

POR

EDITORIAL

GESTIN INTEGRAL DEL CAMBIO


(2011, 320 pginas, 24,5 x 17,2 cm.)
La gestin integral del cambio en las organizaciones es vital para el
xito de los proyectos. Puede ser disminuir el tiempo de entrega de
productos a los clientes, bajar drsticamente el nmero de errores en
el procesamiento de crditos, aumentar las ventas, implantar un
software o pagar con ms prontitud a los proveedores. En todos los
casos, la gestin integral del cambio es indispensable para llegar a
una buena implementacin y se entrelaza con la gestin sistmica de
proyectos.
Existen experiencias y mtodos concretos que revisaremos en el
libro, comenzando por el Modelo integral del cambio, compuesto
por 5 elementos: estrategia, personas, procesos, estructura y tecnologa. Todo proyecto de cambio debe lograr armona entre esos
componentes del modelo. Continuamos con el Enfoque al problema
solucin, para ayudar a iniciar un proyecto sobre bases firmes: un
estudio del problema y de muchas soluciones posibles, hasta encontrar la ms adecuada. Concluimos con las Herramientas facilitadora: el cambio en las personas, visin sistmica, gestin del riesgo,
priorizar con Pareto y el Kaizen, en la forma de una filosofa de
mejoramiento. Son herramientas orientadas a apoyar todas las etapas
de la gestin de proyectos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

267

GESTIN DE PROCESOS
(2011, 4 Edicin, 320 Pgs., 24,5 x 17,2 cm.)
(1 edicin de 2005)
Es fcil aceptar la necesidad de cambio en nuestro mundo. Ms
difcil es cambiar nosotros mismos o que cambie nuestra
organizacin, o la forma cmo hacemos las cosas, a las cuales
podramos llamar procesos.
La gestin de procesos nos insta a detenernos, reflexionar acerca de
lo que hacemos y preguntarnos: por qu?, para qu?, cmo? La
gestin de procesos es un medio para lograr grandes metas
organizacionales: como la satisfaccin del cliente y la
productividad. En el texto se revisan detalladamente las 9 fases de la
gestin de procesos:
Captulo 3. Incorporar la gestin de procesos en la organizacin
Captulo 4. Disear el mapa de procesos
Captulo 5. Representar los procesos mediante modelos visuales
Captulo 6. Gestin estratgica de procesos
Captulo 7. Mejorar procesos
Captulo 8. Redisear procesos
Captulo 9. Formalizar procesos
Captulo 10. Controlar procesos
Captulo 11. Mejora continua de procesos

JUAN BRAVO

268

LIDERAZGO
(2011, 318 Pgs., 21 x 14 cm.)
Dice el autor: Tempranamente observ una correlacin entre el
resultado exitoso de los proyectos en que participaba y el nivel de
liderazgo de quienes lo dirigan. Por lo tanto, promover ambos es la
finalidad de este libro. En el caso de los resultados, se trata de lograr
que las cosas sucedan. En cuanto al nivel de liderazgo, el objetivo es
aumentarlo mediante el proceso de convertirse en lder.
Tambin observ que la relacin entre resultados y liderazgo se
daba en todos los mbitos de la vida: familiar, laboral, personal y
social. Inevitablemente detrs de una familia exitosa, de un proyecto
de cambio en la empresa, de un emprendimiento o de los xitos de
un club deportivo, haba lderes.
Tal como en el caso de los 33 mineros atrapados, donde observamos
aflorar varios lderes entre mineros y rescatistas, en la organizacin
y en la sociedad tambin surgen lderes, algunos visibles y otros que
actan en silencio. Siempre hay ms lderes de los que uno cree.
Podemos tener todava ms si promovemos el liderazgo, comenzando por nosotros mismos.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

269

LDERES
(2011, 270 Pgs., 21 x 14 cm.)
Nuestro mundo ha sido moldeado por grandes lderes. Cierto, sorprende que son muchos y que generalmente las circunstancias de la
vida los han formado a ellos. Conoceremos a algunos de estos lderes: Walt Disney, Peter Drucker, Nelson Mandela, Konosuke Matsushita, Frederick W. Taylor, Jack Welch y otros.
Tambin conoceremos a grandes pensadores en el tema del liderazgo, Se trata de conocidos autores relacionados con el liderazgo. En
su camino de investigacin, ellos mismos se van transformando en
lderes.
Se completa esta investigacin con el detalle de experiencias cercanas de liderazgo.
El objetivo de esta obra es compartir estos aprendizajes, contiene el
detalle de la investigacin acerca de lderes, autores y experiencias
cercanas. Un resumen de la misma se presenta en el libro Liderazgo,
lograr que las cosas sucedan y el proceso de convertirse en lder,
donde se agrega conclusiones. Son libros complementarios, es importante ver a ambos como una totalidad.

JUAN BRAVO

270

GESTIN AVANZADA DE PROCESOS


(2010, 2 Edicin, 190 Pgs., 21 x 14 cm.)
(1 edicin de 2009)

El objetivo del libro es aportar mtodos concretos para el rediseo y


mejora de procesos en la organizacin, como un medio para lograr
la eficiencia y agregar valor para el cliente en una relacin de confianza.
Surge de una profunda inquietud por el despilfarro de recursos en
nuestra sociedad y, sobre todo, por la subutilizacin del enorme potencial de las personas.
La gestin de procesos es un deseo que se intuye como importante en
las organizaciones. Sin embargo, es poco lo que logra realizarse porque no se sabe cmo hacerlo, provocando grandes prdidas en las
mismas organizaciones y en la sociedad por proyectos mal planteados
o fuera de costo y plazo, trmites que demoran ms de la cuenta, mala
atencin de clientes, productos defectuosos, entregas con retraso,
equivocaciones mdicas, errores, prdidas de clientes y tanto ms
En el libro se ensea cmo incorporar a la organizacin un modelo
integral para la gestin de procesos.
Este libro complementa, aporta tcnicas y muestra aplicaciones de los
conceptos desarrollados en el libro Gestin de Procesos, el cual es
prerrequisito para ste.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

271

MODELANDO UNA SOLUCIN DE SOFTWARE


(2008, 392 Pgs., 24,5 x 17 cm.)
El objetivo de este libro es cooperar en
aumentar la productividad del desarrollo
y la calidad de la solucin de software
mediante la excelencia de su modelacin. Comenzamos por asegurarnos que
la serie de modelos (correspondientes a
las etapas de anlisis y diseo) efectivamente dan solucin a una necesidad
bien comprendida y evaluada.
Modelar soluciones de software es una
labor bella y creativa que origina verdaderas obras de arte. Sin perder la
belleza y creatividad, ser posible
profesionalizar su elaboracin? S!
Definitivamente el diseo de sistemas puede ser arte y tecnologa a
la vez.

EL ENCANTO DE LA COMUNICACIN
(2007, 2 edicin 230 Pgs., 18,5 x 13 cm.,
1 edicin de 1998)
Es un libro orientado a todas las personas
que quieren comunicarse mejor con quienes
les rodean para incrementar la calidad de su
vida. El espritu de este libro es que nos
sirva de gua prctica en esta tarea de toda
la vida destinada a relacionarnos mejor y a
transformarnos. Por qu? Porque la comunicacin es cambio que podemos guiar
hacia la superacin personal.
Estamos vivos y lo ms caracterstico de la vida es la transformacin. Y porque el vnculo con nuestros seres queridos es lo nico
que realmente cuenta, adems la mejora en las comunicaciones en
las empresas tiene un efecto inmediato en la vida familiar y social de
sus trabajadores.

JUAN BRAVO

272

RESPONSABILIDAD SOCIAL (RS)


(2007, 380 Pgs., 24,5 x 17,3 cm.)
En los pases de Latinoamrica podemos
ganar miles de millones de dlares al ao
con la RS. Surgen de dejar de perder evitando la Irresponsabilidad Social (accidentes, delincuencia, corrupcin, mala educacin, etc.) y de ganar fomentando la Responsabilidad Social (investigacin, innovacin, emprendimiento, comunicacin,
etc.). Por eso la RS es la nueva causa de
la riqueza de las Naciones. Se puede
lograr, tenemos ejemplos de buenos diseos que han disminuido grandes males
sociales en un 80%. Es el caso, en Chile, de la disminucin de la
tasa de accidentabilidad de los trabajadores desde el 35% de los
aos 60 al actual 7%. Por supuesto, el nfasis ha estado en la prevencin.

HISTORIA DEL IST, 50 AOS


(2007, 164 Pgs., 25 x 25 cm.)
Cumplir 50 aos es un gran
logro para toda organizacin y
mucho ms para una que se
dedica a la seguridad social por
el gran impacto que tiene en la
comunidad. La historia del IST
es a la vez parte de la historia
de la seguridad del trabajo en
Chile, cuyos avances se pueden
resumir en una sola palabra que
bien conocen en el Instituto: prevencin. Es un avance que se puede
proyectar a otros mbitos para contribuir al Bien Comn. Ya sabemos que una historia puede inspirar a las personas para lograr fines
superiores, al menos para encontrarle sentido a su quehacer y motivarse. Tambin permite aprender, porque de la lectura se podr
extraer una buena manera de gestionar una empresa.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

273

GESTIN DE PROYECTOS
(2006, 260 Pgs., 21 x 14 cm.)
El objetivo de este libro es ofrecer un mtodo
para la gestacin, evaluacin, planificacin,
direccin y buena ejecucin de los proyectos,
principalmente de procesos y tecnologa. Es
importante hacer bien los proyectos, porque a
travs de ellos se materializa el cambio propuesto por la estrategia de la organizacin o
por las oportunidades que el medio ofrece. El
mtodo tiene como base un amplio estudio de
las mejores prcticas de la gestin de los proyectos y del cambio en las personas. Las empresas pblicas y privadas de Chile pierden anualmente ms de 2.000 millones de dlares
debido a fallas evitables en proyectos de gestin. De una u otra
forma esa ineficiencia la pagamos todos y con creces, porque tampoco disfrutamos de los beneficios del proyecto si hubiese sido bien
hecho.

GESTIN, EL CASO ENAMI VENTANAS


(2005, 224 Pgs., 25,5 x 19,5 cm.)
Es importante destacar lo positivo de la
gestin de las empresas, as aprendemos de
experiencias concretas. La idea fue desafiante: compartir y aprender de la gestin
realizada en una unidad de negocios de
una importante organizacin. Se trata de la
Fundicin y Refinera Ventanas de la Empresa Nacional de Minera, ENAMI. Tiene
una cultura distintiva que se aprecia en la
ingeniera o innovacin permanente, en su
contribucin al bienestar del pas, en el
sentido de honor, en la pasin por aprender, entre otras.
Se identificaron varios factores relevantes, por ejemplo: liderazgo,
productividad, entorno y personas

JUAN BRAVO

274

EMPRESAS DE XITO
(2005, 150 Pgs., 21 x 14 cm.)
Este es un libro acerca de las empresas de
xito, aquellas con una gestin que las lleva a
diferenciarse. En un contexto de buenas
prcticas de gestin la tesis es que las empresas exitosas se distinguen por algunas pocas
prcticas excepcionales.
As como existe la gestin por competencias
dirigida a las personas, tambin existe una
gestin por competencias corporativa.
Adems de hacer las cosas bien, las empresas exitosas se distinguen
por un pequeo nmero de prcticas que hacen muy bien, les hemos
llamado sistema de diferenciacin. Se presentan los ejemplos de
IST, ENAMI Ventanas, Termosistema e Integramdica.

TAYLOR REVISITADO
(2005, 140 Pgs., 21 x 14 cm.)
Pocas veces se ha visto una distancia tan
grande entre la excelencia de las contribuciones de un hombre y el pobre sitial que le
hemos asignado en la historia. A Frederick
W. Taylor los pases ricos le deban su condicin de tales, dice Peter Drucker. Taylor
sigue aportando a la creacin de riqueza a
travs de la mayor productividad. Fue precursor del entrenamiento o capacitacin y de la
gestin por competencias. Busc evitar el
derroche de materiales y se le reconoce como padre de la ingeniera
industrial y de la ergonoma. Busc que se compartieran los beneficios de la mayor productividad, entre empresarios, trabajadores y la
sociedad. Por qu es tan actual su mensaje? Porque su mensaje de
fondo est orientado a la superacin de la pobreza y porque sus
propuestas, debidamente actualizadas, podran generar grandes
beneficios en la economa de Latinoamrica.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

275

A LA SALIDA DEL TNEL


(2000, 231 Pgs., 23 x 16 cm.)
Es un libro creado con las entrevistas realizadas a los participantes del programa de televisin del mismo nombre en donde se extrajeron sus mejores ideas, propuestas y mensajes.
Fue un programa de UCV TV, conducido por
el dinmico y querido periodista Atilio Macchiavello.
Este documento recrea la vida de muchos
visionarios y podra ser la salida de su propio
tnel. Es un Texto obligado para profesores, estudiantes, profesionales y pblico en general. Una inspiracin para pequeos y grandes
empresarios y orientacin vivencial para nuestras autoridades.

AMBROSOLI, DESDE LOS ALPES A LOS ANDES


(1998, 133 Pgs., 26,5 x 18,5 cm.)
Coautor: Giancarlo Gandolini Ambrosoli.
Este libro es un reconocimiento a la labor
de don Constantino Ambrosoli y a todos los
emprendedores que ayudan a crear un mundo ms humano. Es un ejemplo inspirador
que queremos compartir, porque excedi en
mucho nuestras expectativas.
Para qu sirve una historia? Para conocer,
entender y difundir la cultura de una organizacin, establecer un vnculo entre sus integrantes, comunicar una causa comn, preservar las tradiciones y seguir adelante unidos. Es un gran desarrollo, inseparablemente unido a la historia de la familia Ambrosoli, as
que para entender la evolucin de este negocio, necesitamos conocer
la rica tradicin acumulada en esta familia.

JUAN BRAVO

276

ANLISIS DE SISTEMAS
(1998, 415 Pgs., 26,5 x 18,5 cm.)
Debemos descubrir los sistemas y aprender
de ellos para ayudar en el desarrollo de las
organizaciones. La vieja cosmovisin mecanicista, que considera el mundo estable y
predecible, abre paso a los sistemas: donde
prevalecen las interacciones, lo evolutivo, el
caos, la complejidad y sus compensadores,
la humanidad, educacin, comunicacin,
libertad, creatividad y otras respuestas. Si
pretendemos ignorarla, dar rdenes o slo
poner reglas, la complejidad se abrir paso
igual, como las aguas de un ro que se pretenden frenar con un
prohibido el paso.
Cmo hacer anlisis de sistemas? Con un enfoque al problemasolucin que pasa por comprender la confusin. Algunas herramientas sistmicas son: la teora del caos, la teora de la catstrofe, los
crculos virtuosos, la orientacin al cliente, etc.

PLANIFICACIN SISTMICA
(1997, 240 Pgs., 26,5 x 18,5 cm.)
Tradicionalmente, hemos hecho planificacin
suponiendo que las condiciones ambientales se
mantendran ms o menos constantes. Hoy nos
damos cuenta que el entorno vara con mucha
rapidez! y que la velocidad del cambio sigue y
sigue aumentando. Para adaptarnos a esta realidad, la planificacin sistmica recurre a herramientas tales como: participacin, creatividad y
manejo de la incertidumbre del medio. La planificacin sistmica nos ayuda a cumplir los
sueos, siguiendo un camino que comienza por determinar qu es lo
que queremos, en nuestra empresa o en nuestra vida. Luego, establecemos un sistema de diferenciacin y un plan.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

277

LA NUEVA VISIN, DISEO Y CONSTRUCCIN DE SISTEMAS


COMPUTACIONALES
(contenido actualizado en libro Modelando una
solucin de software) (2 edicin 2007, 272
Pgs., 26,5 x 18,5 cm.) (1 edicin de 1996)
Slo coleccin.
Este libro trata sobre el desarrollo de sistemas
computacionales, tales como inventarios, contabilidad, remuneraciones o facturacin.
Se busca aumentar la productividad en ese
mbito. En especial se estudia el diseo de
sistemas computacionales, una labor bella y
eminentemente creativa que origina verdaderas obras de arte, a
veces artesanales. Siempre conservando la creatividad, Ser posible
que los mtodos de trabajos y las herramientas sean de uso general?
S! Definitivamente el diseo de sistemas dej de ser arte para
transformarse en tecnologa.
Esta propuesta de la ingeniera de software tiene su base en tres
slidos pilares: La planificacin estratgica en informtica, el diseo
orientado al objeto y las herramientas de productividad.

REINGENIERA DE NEGOCIOS
(1995, 300 Pgs., 26,5 x 18,5 cm.)
La finalidad de la reingeniera es lograr grandes
desafos, por ejemplo: aumentar la productividad de las personas, las ventas o la produccin,
no en un 30%, sino en 400% y ms.
Cmo lograrlo? A travs de efectuar grandes
cambios en los procesos del negocio, potenciar a
las personas, definir una estructura organizacional flexible e incorporar tecnologa. Todo en
sintona con la cultura y estrategia de la organizacin.
Para qu hacer reingeniera? Para cumplir con la misin de la organizacin, tarea en la que deben estar empeadas todas las personas
que ah laboran, sirviendo los intereses de los clientes en armona
con los valores de la empresa y de la comunidad.

JUAN BRAVO

278

MODELAMIENTO DE SISTEMAS DE INFORMACIN


(contenido actualizado en libro Modelando una
solucin de software) (1994, 250 Pgs., 24,4 x
18,2 cm.). Slo coleccin.
Da una visin de conjunto sobre el desarrollo
de sistemas de informacin, comenzando por la
planificacin estratgica del negocio.
En el texto se incorporan los conceptos de evaluacin de proyectos informticos, los lenguajes
de cuarta generacin y la orientacin a objetos. Especial relevancia
tienen la Ingeniera de Software y las herramientas de apoyo en cada
etapa del desarrollo del sistema de informacin.
En las ltimas dcadas la computacin ha sido un agente de cambio al interior de la organizacin, hoy las reas de informtica o de
sistemas tambin deben cambiar. Se trata de lograr el desarrollo de
software de calidad, econmico y en plazos convenidos.

DESARROLLO DE SISTEMAS DE INFORMACIN


(1996, 3 edicin, 204 Pgs., 26,5 x 18,5 cm.)
(1 edicin de 1987)
El objetivo de este libro es servir de gua
prctica en el desarrollo y en la mantencin
de sistemas de informacin orientados a
empresas. Est especialmente dirigido a todos quienes laboran en el rea de informtica,
y que podran hacer uso de las materias
prcticas, que buscan mejorar el rendimiento,
mediante la aplicacin de pautas simples y
lgicas, donde el criterio predomina sobre la
reglamentacin.
Tambin se orienta a estudiantes de carreras del rea computacin e
informtica, quienes podrn ver facilitado su aprendizaje al enfrentarse con metodologas y ejemplos concretos, sobre la base de una
visin de conjunto del desarrollo de sistemas de informacin.
El libro ha sido de gran ayuda para acadmicos de las reas mencionadas.

GESTIN DE PROYECTOS DE PROCESOS Y TECNOLOGA

279

Acerca del autor:

Juan Bravo Carrasco


Doctor por la Universidad de Lleida (Espaa), Mster en
Direccin de Informtica (IDE CESEM, Espaa) e Ingeniero
de Ejecucin en Sistemas de Informacin (USM, Chile).
Se desempea como Director de Evolucin, Centro de Estudios Avanzados, dirigiendo Maestras en Liderazgo, Gestin
de procesos, Gestin de proyectos y Metodologa de la investigacin.
Con ms de 25 aos de experiencia como consultor de empresas y relator de seminarios, el Dr. Bravo ha ayudado a clientes tales como: Mutual de Seguridad, VIDAINTEGRA, Caja
de Compensacin Los Andes, ENAMI, BancoEstado, Rolec,
Transbank, Isapre Colmena, Municipalidad de Quillota, Banco Ita, Empresa Portuaria de Valparaso, IST y Constructora
TECSA.
El Dr. Bravo es profesor de programas de postgrado en la
Pontificia Universidad Catlica, Universidad Tcnica Federico Santa Mara (Chile y Ecuador), Universidad de Chile y
otras destacadas instituciones.
Ha publicado ms de veinte libros: Gestin integral del cambio, Gestin de procesos, Responsabilidad social, Gestin de
proyectos y El encanto de la comunicacin, entre otros.

Editorial Evolucin S.A.


Fonos 6818072 09-2252004 a nombre de Silvia Bravo
Contacto: info@evolucion.cl