libro gppt 2009-5 juan bravo

7/31/2019 Libro GPPT 2009-5 Juan Bravo

http://slidepdf.com/reader/full/libro-gppt-2009-5-juan-bravo 1/261

GESTIÓN DE PROYECTOS DE PROCESOS Y TECNOLOGÍA 1



JUAN BRAVO 2

Estimado lector:

Hemos visto cómo este libro agrega valor para la

humanidad a través del conocimiento que aporta, por lo tanto, con mucho agrado empleo también estemedio digital.

Esta es una versión completa y actualizada del libroen 2009, sin costo durante este año como forma decontribuir en la solución de la crisis que nos afectaa nivel mundial.

En general, la serie de libros aporta motivación,conceptos, técnicas y herramientas que han probadoser efectivas en cientos de casos narrados en losmismos textos. Observará que grandes avances fue-ron logrados justamente en alguna otra crisis. Esassoluciones tuvieron siempre, al menos, algo de co-

nocimiento y una dosis de esfuerzo personal sereno,responsable y con fe.

Le saluda cordialmente,

Juan Bravo C. Doctor por la Universidad de LleidaPresidente Evolución Centro de Estudios Avanzados

www.evolucion.cl




GESTIÓN de PROYECTOS de PROCESOS y TECNOLOGÍA

JUAN BRAVO CARRASCO



JUAN BRAVO 4

© JUAN BRAVO CARRASCO, 2006

Inscripción Nº 154.082, 10 de abril de 2006

ISBN Nº 956-7604-12-6, 10 abril de 2006 Derechos reservados, [email protected]

Edición revisada y actualizada en mayo de 2009

Valor versión digital: $ 5.000 (Chile) ó US$ 7 (sin costo en 2009)Puede complementar bajando los Modelos de la Gestión de Proce-

sos y la Revista de Responsabilidad social (www.evolucion.cl).

EDITORIAL EVOLUCIÓN S.A.www.evolucion.cl, [email protected] 171 Of. 307. Fono 6389717

SANTIAGO DE CHILE




Dedicado a los profesionales anónimos que planean y ejecutan bien sus proyectos…

ellos pasan desapercibidos porque no requierenactuar de bomberos.



JUAN BRAVO 6

RECONOCIMIENTOS

Agradecer a muchas personas que de una u otra formahan cooperado: Juan Carlos González, Gerardo CerdaNeumann, Guillermo Gómez, Luis Cid, Sergio Valen-zuela, Rolf Achterberg, Giancarlo Gandolini, EdmundoLeiva, Marcos Merino, Luis Hevia, Javier Cañas, IgnacioOrrego, Pere Mir, Miguel Saéz, Samuel Chávez, LimbiOrtiz, Rodrigo Baldecchi, Rodrigo Silva, FranciscoRamírez, Alberto Neira, Raúl Prado Baldratti y otros.

Agradecer a José Kaffman la oportunidad de dictar cur-sos del método GSP Gestión Sistémica de Proyectos) yde GPPT (Gestión de Proyectos Procesos y Tecnología)a través de Revista Gerencia. También a mis socios delproyecto GSP y a Juan Costella Montt por su apoyo.

A Carlos Pinto, director del Centro de desarrollo de la

Vicerrectoría de Investigación y Desarrollo de la Univer-sidad de Chile, desde donde hemos realizado muchosproyectos de postgrado, tales como el Diploma de Ges-tión de Proyectos Procesos y Tecnología en el BancoEs-tado, agradezco en forma especial a los participantes enéste.

Mi agradecimiento a las organizaciones, sus ejecutivos y

colaboradores, donde hemos realizado consultoría o ca-pacitación orientada a los proyectos de GPPT: Termosis-tema, Integramédica, IST, Hospital San Borja Arriarán,Codelco, Enami Ventanas (actual Codelco), Banco San-tander Santiago y HUAP (Posta Central).

En particular, por el impacto en este texto, quisiera des-tacar las experiencias de consultoría y capacitación en

tres empresas.




Agradeciendo a todos, señalo algunos nombres junto conmis disculpas a quienes merecidamente debían estar (yque omití por error):

• BancoEstado: Loreto Farías, Nilda Mardones, Tama-ra Vilches, Alicia Garay, Fernando León, RodrigoCollado, Arturo Barrios, Hernán Baeza, HumbertoGómez, Alfredo Correa, Carlos Montecino, AdolfoGrasset y Héctor Ponce.

• Rolec S.A.: Gabriel Rodríguez, Luis Contreras, Ra-miro Santibáñez, Marcelo Guerra y Fernando Pérez.

• Empresa Portuaria de Valparaíso (EPV): MarioTroncoso, Mabel Ruiz y Eduardo Jones.

A mis colegas profesores de la Escuela de negociosIEDE Chile y compañeros del Programa de Doctoradocon la UDL: Yolanda Yánez, Jorge Israel, Francois LeCalvez, Jaime Sanhuesa, Patricio Sánchez y Daniel Ka-nonitsch.

A todos agradezco y libero de cualquier responsabilidadpor los errores de este texto.

La portada es diseño de mi hijo Juan Pablo.

A mi esposa e hijos, el importante trabajo en metodolog-ía ha permitido estar más cerca de ellos porque buenaparte de trabajo ha sido en la oficina de mi casa, enrique-ciéndose así este trabajo.

JBC



JUAN BRAVO 8

CONTENIDO

RECONOCIMIENTOS ............................................................... 6

CONTENIDO ........................................................................... 8 PRÓLOGO ............................................................................. 14 PRÓLOGO A LA VERSIÓN 2009 ............................................. 19 INTRODUCCIÓN .................................................................... 20

Objetivo del libro ........................................................... 22 Visión estratégica de proyectos ..................................... 24 El modelo integral del cambio ....................................... 25 Orientación al cliente..................................................... 25

Inicio del proyecto ......................................................... 26 Desarrollo del proyecto ................................................. 27 El plan de proyecto ........................................................ 28 Visión de conjunto del método ....................................... 29 Etapas del proyecto ........................................................ 30 Prácticas transversales .................................................. 33

PRIMERA PARTE. MÉTODO ......................... 36 INTRODUCCIÓN .................................................................... 38

¿Qué es método?… ........................................................ 38 Las mejores prácticas .................................................... 41 Fundamento conceptual: la visión sistémica ................. 42

Método GSP ................................................................... 42 CLAVES DE LA IMPLANTACIÓN DE MÉTODO ........................ 44

Clave 1. Visión de conjunto ........................................... 44 Clave 2. Mínimo indispensable ...................................... 46 Clave 3. Participación de todos los actores .................. 47 Clave 4. Circularidad .................................................... 48

CARACTERÍSTICAS DEL MÉTODO ......................................... 49 1. Adhesión a estándares y normas de calidad .............. 49 2. Actualización .............................................................. 49 4. Información de calidad .............................................. 50 3. Pragmatismo .............................................................. 51 5. Curso normal de los Eventos y SPPP ........................ 52 6. Adaptación a proyectos específicos ........................... 52 7. Pasión por conocer la finalidad, el para qué ............ 54




ESTRUCTURA PARA LA GPPT .............................................. 55 Área de metodología o UTP ........................................... 55 Área de estudios ............................................................. 55 Comité de Proyectos ...................................................... 56

Área de gestión TI .......................................................... 57 Arquitecto de Datos ....................................................... 59

SEGUNDA PARTE.ETAPAS DEL PROYECTO ............................... 62 INTRODUCCIÓN .................................................................... 64

Cuantificar todo ............................................................. 64 Fase de estudios ............................................................. 65 Proceso Fabricar el cambio .......................................... 66

ETAPA 1. CONCEPCIÓN ........................................................ 72 1.1. Ámbito del problema ............................................... 74 1.2. ¿Cuál es el problema? ............................................ 78 1.3. Cuantificar el problema .......................................... 84

ETAPA 2. FACTIBILIDAD ...................................................... 87 2.1. Conformar el equipo de trabajo .............................. 89 2.2. Ideal de la solución ................................................. 90 2.3. Planteamiento libre de alternativas ........................ 92 2.4. Restricciones de la solución .................................... 96 2.5. Selección de alternativas y objetivos generales ..... 98 2.6. Evaluación de cada alternativa .............................. 99 2.7. Evaluación comparativa ....................................... 100 2.8. Decide la opción y objetivos específicos .............. 102 2.9. El plan de proyecto ............................................... 103

ETAPA 3. ANÁLISIS ............................................................ 106 3.1. El Modelo integral del cambio.............................. 108 3.2. Estrategia .............................................................. 109 3.3. Personas ................................................................ 110 3.4. Gestión de Procesos .............................................. 111 3.5. Estructura .............................................................. 117 3.6. Tecnología ............................................................. 118 3.7. Visión global de la solución .................................. 118 3.8. Ingeniería de requerimientos ................................ 119 3.9. Definiciones de la TI ............................................. 121



JUAN BRAVO 10

3.10. Entorno Tecnológico ........................................... 121 3.11. Supuestos ............................................................. 122 3.12. Identificación de los usuarios ............................. 123 3.13. Sistema de codificación ....................................... 124 3.14. Requerimientos computacionales ....................... 124 3.15. Diagrama de casos de uso .................................. 125 3.16. Caso de uso de alto nivel .................................... 126 3.17. Caso de uso expandido........................................ 128 3.18. Modelo Conceptual ............................................. 129 3.19. Diagrama de secuencia del sistema .................... 132 3.20. Visión dinámica del sistema ................................ 134 3.21. Diagrama de estado ............................................ 135 3.22. Contratos ............................................................. 136 3.23. Interfaces usuario – sistema ............................... 137 3.24. Prototipos desechables ....................................... 138 3.25. Revisión de los modelos ....................................... 138 3.26. Uso de herramientas ........................................... 139 3.27. Costo del proyecto .............................................. 139

ETAPA 4. DISEÑO ............................................................... 140 4.1. Diseño de procesos ............................................... 142 4.2. El diseño del software ........................................... 147 4.3. Diagrama de Diseño de Clases ............................. 148 4.4. Diagrama de colaboración ................................... 150 4.5. Visión externa ....................................................... 152 4.6. Entorno de la aplicación ....................................... 152 4.7. Costo del proyecto ................................................ 153

ETAPA 5. IMPLEMENTACIÓN.............................................. 154 5.1. Negociar los compromisos .................................... 156 5.2. Implementar los procesos ..................................... 157 5.3. Implementar la TI .................................................. 159 5.4 Probar .................................................................... 160 5.5. Instalar el piloto .................................................... 163

ETAPA 6. DESPLIEGUE........................................................ 166 6.1. Revisar y actualizar elementos ............................. 167 6.2. Incorporar a cada usuario ..................................... 168 6.3. Capacitar a los usuarios ....................................... 168

ETAPA 7. OPERACIÓN ........................................................ 170




7.1. La mejora continua ............................................... 171 7.2. Control de cambios ............................................... 174 7.3. Una mesa de ayuda ............................................... 176 7.4. Buena operación de la aplicación ........................ 176 7.5. Gestión de la calidad ............................................ 177 7.6. Rediseño programado de la solución .................... 178

TERCERA PARTE. PRÁCTICASTRANSVERSALES ........................................... 179 INTRODUCCIÓN .................................................................. 181

Las mejores prácticas en proyectos ............................. 181 Ordenamiento de las prácticas .................................... 182

Definir una política por cada práctica ........................ 182 Llevar a la Carta Gantt ................................................ 183 Base de datos de estándares numéricos ....................... 183 ¿Cuáles prácticas incorporar en un proyecto? ........... 184

1. DIRECCIÓN DEL PROYECTO............................................ 186 2. PLAN DE LA ETAPA......................................................... 187 3. EXPOSICIÓN DE LOS PLANES .......................................... 188 4. RETROALIMENTACIÓN ................................................... 189 5. EL EQUIPO DE TRABAJO ................................................. 190 6. ENTREVISTAS................................................................. 191 7. COMUNICACIÓN ............................................................. 192 8. INFORMES ...................................................................... 193 9. TÉCNICAS....................................................................... 194 10. HERRAMIENTAS DE APOYO .......................................... 195 11. TRAZABILIDAD............................................................. 196 12. QUICK WINS ................................................................ 197 13. COSTOS Y DURACIÓN ................................................... 198 14. GESTIÓN DE RIESGOS ................................................... 199 15. GESTIÓN DE LA CALIDAD ............................................. 200 16. RESPONSABILIDAD SOCIAL .......................................... 201 17. INSERCIÓN.................................................................... 202 18. ORIENTACIÓN AL CLIENTE ........................................... 203 19. SENSIBILIZACIÓN ......................................................... 204 20. CAPACITACIÓN ............................................................ 205 21. SEGUIMIENTO............................................................... 206



JUAN BRAVO 12

22. CUIDAR LA SOLUCIÓN ANTERIOR................................. 207 23. CONTINUIDAD OPERACIONAL ...................................... 208 24. PLAN DE RECURSOS FÍSICOS DEL PROYECTO ............... 209 25. KILL TIME .................................................................... 210 26. CONTROL DE CAMBIOS ................................................ 211 27. GESTIÓN DEL CAMBIO.................................................. 212 28. GESTIÓN DE PROVEEDORES.......................................... 213 PARTE FINAL. CONCLUSIONES, ANEXOS YBIBLIOGRAFÍA ............................................... 214 CONCLUSIONES.................................................................. 216 ANEXO 1. RELACIÓN CAUSAL............................................ 218 ANEXO 2. UML ................................................................. 221

Casos de uso ................................................................. 222 ANEXO 3. RUP ................................................................... 224 ANEXO 4. NORMAS DE CALIDAD DEL SOFTWARE .............. 226

CMM ............................................................................ 227 ISO 9000 ....................................................................... 228 Tick IT .......................................................................... 229

ANEXO 5. DESARROLLO EN ESPIRAL DEL PROYECTO ........ 231 ANEXO 6. GESTIÓN DE CALIDAD EN PROYECTOS .............. 233 ANEXO 7. CASO BANCOESTADO ....................................... 235 ANEXO 8. ITIL ................................................................... 237 ANEXO 9. PMI ................................................................... 239 ANEXO 10. MODELO PARA CASO DE NEGOCIOS ................ 240 BIBLIOGRAFÍA.................................................................... 247




Los que conocen íntimamente un oficio saben perfectamente que lo que menos se encuentra es la

uniformidad en los métodos usados. En lugar de haber una sola manera de trabajar aceptada generalmente

como modelo, se usan diariamente, digamos, 50 ó 100maneras diferentes para hacer cada elemento de

trabajo.Frederick Winslow Taylor



JUAN BRAVO 14

PRÓLOGO

Entre 1975 y 1978 tuve el privilegio de estudiar enla Universidad Técnica Federico Santa María unacarrera muy rara: IESI o Ingeniería de Ejecución enSistemas de Información, era la primera vez que sedictaba en la USM y no había a quien preguntar. Esmás, no había a quien preguntar en todo Chile por-que las demás universidades también estaban recién

iniciando sus propias carreras cercanas a la compu-tación. Como es natural, hubo mucho de prueba yerror en esa época (ahora también).

Bueno, la carrera tenía efectivamente un fuerte énfa-sis en la computación (Fortran, Cobol, tarjetas perfo-radas, equipos de un millón de dólares con memoriade 32KB, grandes unidades de disco de 2 MB, mu-cho trabajar de noche y otros componentes del para-digma de entonces), sin embargo, también profundi-zaba en la teoría de sistemas y en la administraciónde empresas, de hecho, fue un doble privilegio estu-diar en esa época porque también conocí la Univer-sidad Adolfo Ibáñez (UAI), más bien a varios de sus

profesores, porque se incluyó toda una serie de asig-naturas de administración que ellos dictaban. Se pre-tendía dar a la carrera un enfoque de solucionar pro-blemas, de mirar a la organización en forma integral,como un sistema. Así, aprendí que un Sistema deInformación no es solamente computación sino tam-bién estrategia, personas, estructura organizacional,

procesos y mucho más.




Ocurrió que de los pocos que egresamos en los pri-meros años de existencia de la carrera (probable-

mente una docena) todos derivamos hacia la compu-tación, o informática como se le comenzaba a lla-mar. Por lo tanto, la carrera cambió a Informática.

Mi propio proceso fue similar, también por algunosaños mi sesgo fue tecnológico (me desempeñé comoJefe de proyectos en NCR y luego como Gerente deInformática de una empresa comercial). Sin embar-

go, con el tiempo comencé a recuperar el espírituoriginal de esa rara carrera: ver a la organización demanera integral. Ya trabajando como consultor in-dependiente hacia fines de los ochenta, esto se mate-rializó en asesorías de más amplio alcance, conside-rando la estrategia, las personas, procesos y otrosfactores. Curioso, a veces los problemas se resolvíancompletamente a ese nivel, sin necesidad de ocuparmi querido martillo de la informática.

Durante esa época y hasta fines de los noventa miformación fue más bien autodidacta (aunque partici-pando en muchos cursos breves con autores comoYourdon, Jacobson, Drucker, Peters y otros). Como

una forma de mantenerme actualizado cooperé tam-bién por 15 años como profesor de cátedra Part Ti-me en la Universidad de Chile (DCC, Escuela deIngeniería), dirigía talleres de análisis de sistemas yguiaba alumnos memoristas. La doble experienciade consultoría y académica fue central en la creaciónde conocimiento que plasmé en varios artículos (tal

como “Flexibilidad de Sistemas” y “Se justifica eldesarrollo de un sistema computacional”, 1984 y



JUAN BRAVO 16

1985, respectivamente) y en dos productos: el libro Desarrollo de Sistemas de Información, una visión

práctica (1988) y el Generador de aplicaciones Bra-vo2/L4G (1989).

El libro ya expresaba la idea de solucionar proble-mas con una visión amplia, más que solamente apli-car el paradigma informático y poco a poco se trans-formó en un método bastante aplicado en las empre-sas y en el texto guía habitual en asignaturas de sis-

temas de información. El Bravo2/L4G1 —mis dis-culpas 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 nombreen algunas universidades e institutos.

Durante la década de los noventa consolidé mi líneade asesoría integral a las empresas y seguí coope-rando con las universidades, cabe destacar un pro-grama de análisis y diseño de sistemas que hicimoscon la USM y que llegó a tener más de mil egresa-dos, el cual evolucionó incluso hasta transformarseen un diploma. La experiencia se materializó en

nuevos títulos: Reingeniería de Negocios (1995), La Nueva Visión, Diseño y Construcción de Sistemas

1 El generador tenía un módulo de modelamiento de datos y funcio-nes con orientación a objetos desde donde se generaba el código enCOBOL y luego en otros lenguajes. Se vendieron unas 300 licenciasen Chile y Latinoamérica y unas 1000 fueron donadas a instituciones

educacionales. Tenía alrededor de 500.000 líneas de código y loconstruí durante varios años (1986-9), mientras me dedicaba a des-arrollar sistemas computacionales para empresas.




Computacionales (1996), Planificación Sistémica(1997), Análisis de Sistemas (1998) y El Encanto de

la Comunicación (1998), centrados más bien en lavisión sistémica, nueva cosmovisión en la cual setransformó la antigua teoría de sistemas y queademás recoge los grandes nuevos aportes, como lateoría de comunicación de Maturana, la teoría delcaos y el pensamiento sistémico de Senge, entreotros afluentes.

Más o menos con la llegada del nuevo milenio con-sideré que ya tenía la experiencia necesaria para otrociclo de formación. Obtuve un Master en Direcciónde Informática con un instituto de Madrid y luego undoctorado con la Universidad de Lleida (Cataluña,España). Durante este último período reforcé losconceptos de acercamiento integral a la organizaciónen mi labor de consultoría y he tenido el privilegiode participar ampliamente en la formación de post-grado (Diplomas y MBA’s) que ofrecen institucio-nes como UV, IEDE, USM, UCH, UC y otras. Todoesto quedó registrado en nuevos títulos: el libro Ges-tión de Procesos (2005), base a su vez de mi tesis dedoctorado realizada durante 4 años y otros libros queprofundizan en temas de estrategia e inteligencia,me refiero a: Empresas de Éxito (2005) y Responsa-bilidad Social (en versión preliminar).

Lo menciono porque los últimos años han sido in-tensos en interpretar las necesidades reales de lasempresas, más todavía con la creciente competitivi-

dad que existe y las nuevas siglas que surgen a velo-cidad insospechada: UML, RUP, OOA, OOD,



JUAN BRAVO 18

CMM, SCM, CRM, ERP, BI, ITIL, PMI, CASE,TIC’s y muchas otras.

En fin, ha sido una búsqueda de las mejores prácti-cas que van quedando plasmadas en el método GSPy en libros como este que tiene en sus manos.

Le deseo una feliz y provechosa lectura.

JBC




PRÓLOGO A LA VERSIÓN 2009

Poco a poco comienza a tomarse conciencia de la ne-cesidad de tener un proceso bien definido de gestiónde proyectos. Ya son muchos los avisos en la prensaque solicitan profesionales competentes o asesoría enel “proceso de gestión de proyectos”. Este es uno delos motivos para seguir trabajando en este texto. En elfondo, es creciente la importancia de la gestión de

proyectos.Algunos cambios relevantes en esta versión:

1. Se enriqueció lo que se refiere a evaluación deproyectos y “fabricar el cambio”.

2. Se incluyo tabla con las prácticas transversalescomo ejemplo para cada proyecto.

3. Se incluyo flujograma de información de ejemplopara formalizar los cambios menores.

Además de muchos detalles de corrección y actuali-zación. Un mensaje es ver este libro integrado en unaserie donde también están los dos textos de procesosy los de tecnología que se pueden observar al final deltexto.

Mucho éxito.

Juan Bravo



JUAN BRAVO 20

INTRODUCCIÓN

“Un concepto de erizo [la estrategia de la compañía]no es una meta de ser los mejores, ni es una estrategia para ser los mejores, ni es la intención o plan de ser los

mejores. Es entender en que puede uno ser mejor”.

Jim Collins en “Empresas que sobresalen” (p. 155)

Las empresas públicas y privadas de Chile pierden alaño más de 2.000 millones de dólares2 debido a fa-llas evitables en proyectos de gestión. En realidadesa ineficiencia de una u otra forma la pagamos to-dos y con creces, porque tampoco disfrutamos delbeneficio del proyecto si hubiera sido bien hecho.

2 Es fácil estimar esta cifra con base en nuestro relacionamiento(desde Evolución, Centro de Estudios Avanzados) con más de 1.000empresas en Chile en los últimos 20 años. Se pueden plantear estascifras conservadoras:Las 10 empresas mayores gastan en total 1.000 millones de dólaresal año en proyectos de gestión (promedio 100 millones de dólarescada una). Las 100 empresas mayores gastan en total 1.000 millonesde dólares al año en proyectos de gestión (promedio 10 millones de

dólares cada una). Las 1.000 empresas mayores gastan en total1.000 millones de dólares al año en proyectos de gestión (promedio1 millón de dólares cada una). Las 10.000 empresas mayores gastanen total 1.000 millones de dólares al año en proyectos de gestión(promedio 100 mil dólares cada una). Las 100.000 empresas mayo-res gastan en total 1.000 millones de dólares al año en proyectos degestión (promedio 10 mil dólares 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 sería una cifra mucho mayor si agregáramos elcosto de oportunidad). Otras estimaciones hablan de fallas hasta deun 80%, las más conservadoras le asignan un 50%.




Son fallas del tipo: a) el proyecto no responde a lasreales necesidades de los clientes y a veces ni siquie-

ra de los usuarios internos, b) los costos o plazosexcedieron en mucho la estimación, provocandograndes trastornos, c) el proyecto está tan fuera defoco que conviene cancelarlo pero nadie lo asumeporque en la compañía prevalece el criterio de bus-car culpables, d) poca confiabilidad del producto, e)grandes diferencias entre las facilidades del produc-

to y lo que efectivamente se requería…Para que seguir, estas y muchas otras dificultadesson ampliamente “sufridas” a diario en proyectos detodo tipo: tecnológicos, de cambio organizacional,de procesos, etc...

Es dramático que son fallas fáciles de

subsanar empleando algún método para lagestión de proyectos.

No es un tema nuevo en la gestión de proyectos tec-nológicos, ya en 1968 en la conferencia de la OTANen Alemania se planteó adoptar un enfoque ingenie-ril en el desarrollo de software, con énfasis en

maximizar la calidad del producto de software y laproductividad del desarrollo de software, al mismotiempo, minimizar los riesgos del desarrollo y explo-tación.



JUAN BRAVO 22

Esto a raíz de diversos estudios3 que daban cuentade la conocida “Crisis del Software”, algunas cifras:

La mayor parte de los sistemascomputacionales desarrollados y

entregados no se utilizan (47%)

• Sistemas de software encargados y nunca entre-gados (29%)

• Sistemas de software que solamente se pudieronutilizar después de grandes cambios (19%)

Esta realidad de los proyectos tecnológicos no hasido tan diferente en el ámbito de los procesos, don-de se reportaban niveles de fallas graves en el 80%de los proyectos de reingeniería.

La respuesta es trabajar con método.

Objetivo del libro

El objetivo de este libro es ofrecer un método paraabordar proyectos de procesos y tecnología. No setrata de detallar técnicas, actitudes o conocimientos

específicos sino de señalar un trazo que sirva en lagestación, planificación, dirección y buena ejecuciónde los proyectos.

La visión global, sistémica, es lo importante.

3Solamente en Estados Unidos: estudios del departamento de De-

fensa, de la NASA y la Contraloría. En general la bibliografía serefiere a cifras similares.




Si el lector quiere profundizar en estos conceptos,puede hacerlo revisando estos libros del mismo au-

tor, referenciados dentro del texto:• Desarrollo de Sistemas de Información, una vi-

sión práctica• La Nueva Visión, Diseño y Construcción de Sis-

temas Computacionales• El Encanto de la Comunicación• Planificación Sistémica• Análisis de Sistemas• Gestión de Procesos

Adicionalmente se presenta una amplia bibliografíacon otros autores.

El libro tiene como base el método GSP4, original-mente llamado MG-DSI (Método genérico de Desa-rrollo de Sistemas de Información) el cual es a suvez una recopilación de las mejores prácticas para larealización de proyectos.

El método GSP es una guía para abordar en forma completa un proyecto. Es uncamino, no es el camino, porque en cadaetapa siempre habrá variantes que puedenaplicarse.

En la primera parte del contenido se explica másacerca del método.

4 Recuérdese que GSP significa Gestión Sistémica de Proyectos.



JUAN BRAVO 24

Visión estratégica de proyectos

Un proyecto materializa el cambio que surge de nece-

sidades concretas en la sociedad y en las organizacio-nes

Los proyectos siempre sirven a un cliente, a quien sequiere llegar con un nuevo producto, un tipo decrédito, un proceso más ágil, una casa o un curso.

Todo proyecto sirve a la misión de la organización, lo

cual incluye alinear intereses. Veremos que el métodollama a esto: estar de acuerdo con la estrategia de laorganización.

Claramente, el alcance de un proyecto esmucho mayor que solamente incorporar

alguna forma de tecnología o construir un

sistema computacional.

El proyecto incluye las acciones relacionadas con laestrategia de la organización (principalmente alinearla estrategia corporativa con la del proyecto), las per-sonas (incluyendo cultura e infraestructura), el redi-seño de los procesos, la estructura organizacional y la

tecnología en general, incluyendo la tecnología deinformación. A ese conjunto le llamamos modelointegral del cambio.

Es una propuesta integral.




El modelo integral del cambio

Son cinco factores de cambio —representados en la

figura como una mesa— que deben ser sistemática-mente revisados, al interior y exterior de la organi-zación, para lograr una buena solución.

Modelo integral del cambio. Se puede repre-

sentar como una mesa, donde la cubierta es laestrategia y los pilares son las personas (inclu-yendo cultura e infraestructura), procesos,estructura y tecnología. El mensaje es armoníaen estos medios para el cambio.

Orientación al cliente

Desde el punto de vista de proyectos, todos en la or-ganización deben estar orientados al cliente. Son losusuarios, destinatarios, beneficiarios, pacientes, ciu-dadanos y otras denominaciones para representar aalguien fuera de la organización y a quien servimos ynos debemos (son las personas que pagan nuestro

sueldo, no el “cliente interno”, metáfora que sólo

Estructura

Personas

Procesos

Personas

Procesos

Tecnología

Estrategia



JUAN BRAVO 26

agrega confusión cuando algunas personas creen quees suficiente con realizar bien su función).

También se le llama “Visión de procesos”, porquesiempre existe una doble responsabilidad, la funciónindividual y la totalidad de asegurarse que funcione elproceso completo, del cual nuestra función es parte.

¿Cuál es el cliente del área de RRHH? El cliente.

En ambos casos y en muchos otros, es circunstancial

otorgar un servicio interno, lo más importante es co-mo ese servicio impactará en el cliente (la misión dela organización).

¿Cuál es el cliente del área deinformática? El Cliente.

¿Cuál es el cliente para todos los funcionarios de unministerio? Los ciudadanos.

Inicio del proyecto

Aplicando el enfoque de proyectos, todo comienza por conocer bien el problema (concepción) y así

evitar crear soluciones sólo para atacar el síntoma.Se trata de conocer el problema de fondo y luegobuscar y evaluar soluciones en el más amplio espec-tro posible, para evitar la dependencia de la “única”solución (factibilidad).

Una vez seleccionada una solución, el enfoque de

proyectos de negocios sigue por proponer un con-




cepto, una idea fuerza que luego se materializa en unmodelo integral del cambio (la mesa).

Aquí surgen los requerimientos globales del proyec-to. Esta es la base de la ingeniería de requerimientosorientados a toda “la mesa”.

Una de las “patas de la mesa” es la Gestión de pro-cesos, esta es la que da origen a la definición de re-querimientos en las otras patas. Desde el rediseño de

procesos de compras, ventas, producción o de cual-quier otro tipo, surgen los requerimientos sobre laspersonas, estructura organizacional, tecnología ysobre el mismo detalle de la “pata” procesos.

Otra de las “patas de la mesa” es la tecnología deinformación (suponiendo que el proyecto la contem-pla) y aquí ya se emplean técnicas tales como UML,

modelamiento de datos, diseño de Interfaces y otras.

Desarrollo del proyecto

Disponiendo de los requerimientos planteados en elanálisis, se profundiza en las etapas más orientadasal desarrollo computacional propiamente tal: diseño,

implementación y despliegue, siempre dentro delsistema de productividad que el método propone,donde se incluyen factores tales como: técnicas,herramientas de apoyo, hardware, incorporación delusuario, habilidad del desarrollador y normalizaciónexterna.



JUAN BRAVO 28

Luego, junto con la operación del sistemacomputacional, llega la mejora continua

de todo el resultado del proyecto.En la parte de ingeniería de software del sistema deinformación, el método considera los nuevos están-dares: UML, Orientación a Objetos, desarrollo enespiral, uso de componentes reutilizables de softwa-re, herramientas CASE y amplia orientación a la

calidad (en línea con las propuestas de CMM, ISO9000 y Tick IT).

Se orienta a profesionales de áreas de informática,auditoría, gestión de procesos y ejecutivos que requie-ren administrar proyectos de TI, entre otros.

El plan de proyectoEl aspecto más representativo de la

gestión de proyectos es el plan de proyecto, el cual, en realidad, es un

conjunto de planes.

Son planes que surgen de las definiciones globalesdel método, de las etapas del proyecto y de lasprácticas transversales.

Para efectos de la programación de actividades, todoconverge en una carta Gantt (o en otra técnica deprogramación de proyectos).

Para elaborar el plan de proyecto se requiere conocerlas políticas que se haya dado la organización, por




ejemplo, si se trabajará con desarrollo secuencial(cascada) o iterativo (espiral).

Es aconsejable el uso de herramientas de apoyocomputacional para gestar y administrar proyectos.Se requiere una malla de actividades que permitavisualizar el proyecto integral y resolver aspectos deprecedencia, holgura y ruta crítica.

Visión de conjunto del métodoEl plan de proyecto es una integridad con contenidosmucho más allá que la ruta crítica. En realidad con-templa dos líneas de trabajo paralelas, como las víasdel ferrocarril:

• Etapas del proyecto

• Prácticas transversalesTal como se aprecia en la siguiente figura:



JUAN BRAVO 30

Etapas del proyecto

Las etapas son las distinciones principalesdel trabajo en el proyecto, son:

concepción, factibilidad, análisis, diseño,implementación, despliegue y operación.

En la figura (como una punta de flecha) se aprecia elesfuerzo promedio estimado de cada una y como a

partir de la etapa de diseño se expande el trabajoincorporando la especialización de otros actores.

Prácticas transversalesPrácticas transversales

ConcepciónFactibilidad

AnálisisDiseño ImplementaciónDespliegueOperación /

Mejora Continua

Etapas del proyecto

Dirección del proyecto

Plan de la etapaExposición de los planesRetroalimentaciónEl equipo de trabajoEntrevistasComunicación

Informes

TécnicasHerramientas de apoyoTrazabilidadQuick Wins... y las otras 16...




Se aprecia también que las etapas están agrupadas

en tres grandes fases:• Estudio: donde se detectan necesidades y se pro-

ponen soluciones, el entregable es un plan deproyecto. Incluye las etapas de concepción y fac-tibilidad.

• Desarrollo: donde se plan se materializa. Incluye

las etapas de análisis, diseño, implementación ydespliegue.• MC (Mejora Continua): donde la solución ya en

operación se mantiene y perfecciona. Contienesolamente la etapa de operación, la más extensa.

Cada fase es realizada generalmente por equipos yáreas diferentes.

Aunque todo proyecto tiene las mismasetapas, su alcance puede diferir según lascondiciones particulares del proyecto.

Son siete etapas que veremos en detalle en la segun-da parte de este texto, a continuación los objetivos

de cada una:

C F A D I D O

Estudio Desarrollo MC

C F A D I D O

Estudio Desarrollo MC



JUAN BRAVO 32

1. Concepción

El objetivo es concebir un problema, el cual puede

tomar diferentes formas: una necesidad, una oportu-nidad o una dificultad específica, entre otras. Se en-trega en la forma de un enunciado validado, cuanti-ficado y su contexto.

2. Factibilidad

El objetivo es obtener el plan de proyecto de la solu-ción después de un barrido creativo de muchas solu-ciones y de un estudio comparativo de algunas deellas.

3. Análisis

El objetivo es plantear el modelo integral del cambiode la solución (estrategia, personas, procesos, estruc-tura y tecnología) y los requerimientos correspon-dientes. El qué.

4. Diseño

El objetivo es obtener la ingeniería de detalle de la

solución completa que propone el modelo integraldel cambio. El cómo.

Comienza la parte ancha de la flecha porque se in-corpora con mayor fuerza el aporte de los especialis-tas en cada parte del modelo integral del cambio.




5. Implementación

El objetivo es llevar a la práctica la solución com-

pleta que propone la solución, armonizando todassus partes.

Continúa con el aporte de los especialistas en la im-plementación de cada parte del modelo integral delcambio.

Se concluye en una aplicación real aunqueen carácter piloto.

6. Despliegue

El objetivo es replicar o expandir la solución gene-rada hasta ser bien utilizada por todos los usuariosprevistos en el plan de proyecto.

7. Operación

El objetivo de esta etapa es mantener la solución enbuen funcionamiento hasta que cumpla con su vidaútil o sea reemplazada por otra solución. La mejoracontinua es una actividad central.

Concluye un ciclo de operación con el inicio de unrediseño programado de la solución.

Prácticas transversales

El plan de proyecto contempla prácticas transversales

que tienen mayor o menor impacto en cada etapa.



JUAN BRAVO 34

Las acciones a que den lugar deben quedar detalladasen el plan particular para el proyecto.

Se puede ver las etapas como pilares y las prácticas de administración como líneashorizontales que “cruzan” cada etapa,impactando en mayor o menor medida acada una.

Son prácticas que deberían estar contempladas tantoen el plan de proyecto global como en el detalle decada etapa. Por supuesto, con diferente alcancesegún cada proyecto.

Las principales prácticas transversales consideradasson 28 y han surgido del estudio de las mejoresprácticas de los proyectos.

1. Dirección del proyecto2. Plan de la etapa3. Exposición de los planes4. Retroalimentación5. El equipo de trabajo6. Entrevistas7. Comunicación8. Informes9. Técnicas10. Herramientas de apoyo11. Trazabilidad12. Quick Wins13. Costos y duración

14. Gestión de riesgos15. Gestión de la calidad




16. Responsabilidad social17. Inserción

18. Orientación al cliente19. Sensibilización20. Capacitación21. Seguimiento22. Cuidar la solución anterior23. Continuidad operacional24. Plan de recursos físicos del proyecto

25. Kill time26. Control de cambios27. Gestión del cambio28. Gestión de proveedores

En la tercera parte del libro se puede ver el detallede cada una de ellas.



JUAN BRAVO 36

PRIMERA PARTE.MÉTODO




Sin importar el tipo de empresa, el analista trabaja en problemas comerciales. Sería un error distinguir entre problemas del negocio en sí y de sistemas; o dicho deotra forma, no existen problemas de sistemas que no

hayan sido primero del negocio.

James A. Senn



JUAN BRAVO 38

INTRODUCCIÓN

En la Edad Media, la incorporación a un oficio, hacerzapatos o construir catedrales, era una iniciación enun gremio muy cerrado. El “arte” o secreto del oficio se transmitía de maestros a principiantes a través de larevelación de los misterios.

De la misma forma comenzó el desarrollo de proyec-tos de procesos y tecnología, con iniciados que co-nocían los secretos del arte y que parecían estar jura-mentados para no revelarlo. Sin embargo, no ha sidonecesario que transcurrieran 400 años para que esearte se transformara en tecnología, tal como ocurriócon la mayoría de los oficios de la Edad Media.

En la gestión de procesos y tecnología han bastado

sólo 40 años para que la situación cambiara drástica-mente.

Hoy sabemos cómo hacer gestión de procesos y construir software de calidad yese conocimiento está al alcance de todos.

¿Qué es método?…

Antes de continuar, es importante aclarar que se en-tiende por método… Claramente es una competencia—básica para todo profesional— que se puedeenunciar así:

Guía su trabajo del día a día de acuerdo con normasy procedimientos definidos, logra visualizar el inicio




y el fin de los procesos en que participa y aplica quetan importante es su función específica dentro del

proceso como el cumplimiento de todo el proceso.Trabaja en equipo con todos los demás partícipes delproceso.

Las prácticas que se adquieren en la competenciamétodo se pueden ver como un continuo que co-mienza desde la toma de conciencia de “cómo lohacemos” (ya sea un proceso operativo o un proyec-

to) hasta aplicar mejora continua, mejores prácticas,rediseño e innovación sobre esa secuencia.

Trabajar metodológicamente aplica paratodo tipo de procesos —del negocio, deapoyo y estratégicos— y proyectos decambio organizacional.

Se pueden enunciar mediante esta secuencia (utili-zada en procesos de Gestión por Competencias):

• Aprendiendo: Toma conciencia de “cómohacemos” el trabajo y lo describe, se interesa enconocer los procesos completos en que participay quien es el cliente, domina técnicas básicas degestión de procesos y de proyectos, cuantifica elproblema y el costo de oportunidad.

• Entendiendo: Conoce el objetivo del proceso ypropone mejoras para eficientarlo, aplica herra-mientas para el desarrollo y seguimiento de pro-cesos y proyectos, una Carta Gantt. Trabaja bien

en equipo, motiva para el cambio y negocia paraevitar las resistencias. Cuantifica las soluciones.



JUAN BRAVO 40

• Aplicando: compara el método con otros simila-res dentro y fuera de su organización, emplea

técnicas de benchmarking y de la cadena de valorde Porter, elabora planes de proyecto para elcambio, es coherente (cambio personal y organi-zacional a la vez), aplica gradualidad y sabe cal-cular un VAN (Valor Actual Neto).

• Guiando: Propone cambios radicales de acuerdocon la estrategia de la organización, aplica técni-

cas de idealización para aumentar la competitivi-dad, usa técnicas de Visión sistémica y métodocompleto de proyectos.

En el nivel guiando, también empleaherramientas de gestión del conocimiento,

gestión de riesgos, trazabilidad y control

de cambios. Motiva, lidera y retroalimentaa los demás en sus propios procesos de

cambio.

Refiriéndose a la buena gestión de proyectos, Cam-pero y Alarcón señalan en su libro Administraciónde Proyectos Civiles (páginas 2 y 3): “Los buenos

resultados de una administración serán el productode condiciones personales de los responsables y delas técnicas de administración que empleen… cum-plir con las metas programadas de costo y plazo noresulta fácil y existe una alta posibilidad de arriesgarlos beneficios y costos esperados. Un estudio reali-zado por Thompson y Perry usando un gran número

de proyectos del Banco Mundial , indica que, de




1.778 proyectos revisados, en el 63% de los casos elcosto final superó el presupuesto, de 1.627 proyectos

revisados, el 88% terminó con atraso; y de 42 pro-yectos controlados, el 70% de ellos no alcanzó altasa interna de retorno (TIR) esperada”.

Las mejores prácticas

El Método propuesto surge de revisar y practicar

sistemáticamente las propuestas de lenguajes, nor-mas de calidad y herramientas que el mercado ofre-ce, aprendiendo de tales opciones e incorporando eneste método lo que se considera realmente aplicableen las empresas de Chile y Latinoamérica, conside-rando nuestra idiosincrasia, niveles de conocimientoy avance en tecnología de información.

Es un método genérico porque la idea esconocer y seleccionar del medio lasmejores técnicas5 (causa-efecto,creatividad, mapa de procesos,Flujograma de información , UML, ITIL,PMI, orientación a objetos, modelo

integral del cambio, etc.) avanzando hacialas estandarizaciones formales o “de facto” en nuestro medio.

5 Las técnicas que no están desarrolladas en el texto se explican enanexos.



JUAN BRAVO 42

Fundamento conceptual: la visión sistémica

La visión de proyectos de negocios del método pro-

puesto en estas páginas ofrece una visión integrado-ra, actualizada y práctica de todas las etapas inclui-das de su ciclo de vida.

Tiene su base conceptual en la visión sistémica,también conocida como pensamiento sistémico,aceptación del caos y de la complejidad, visión aé-

rea, etc. (ver libro Análisis de Sistemas)

Método GSP

Conocido inicialmente como Método Genérico deDesarrollo de Sistemas de Información (MG-DSI,año 2000), el Método GSP es una base de conoci-

mientos que ofrece una guía para el desarrollo com-pleto de un proyecto, pasando por todas las etapasde su ciclo de vida: concepción, factibilidad, análi-sis, diseño, implementación, despliegue y operación.Es un método abierto, con etapas genéricas, ampliouso de técnicas del medio y apoyo de herramientasexistentes.

El Método GSP tiene por objetivo ofrecer una visión integradora, actualizada y

práctica de todas las actividades incluidasen el ciclo de vida de un proyecto.

El método GSP tiene su base en los libros del autor

de este texto (ver bibliografía). También el métodose funda en las experiencias directas o de consultoría




de desarrollo de sistemas de información del autor yde gran cantidad de profesionales, a quienes se les

agradece en los respectivos textos. Otra influenciaviene desde los cientos de desarrollos guiados, nor-malmente reales, con participantes de los programasde postgrado en Análisis y Diseño de Sistemas en laUniversidad Técnica Federico Santa María, Univer-sidad de Chile, Universidad de Valparaíso y Escuelade Negocios IEDE Chile, entre otros, ofrecidos por

el suscrito con la cooperación de destacados profe-sionales señalados en los agradecimientos.

El método se ha perfeccionado con eltiempo desde la propuesta del primer libro(Desarrollo de Sistemas de Información,una visión práctica, 1988) y actualmente

considera orientación a objetos, modelosde UML, fichas para estudio de proyectos y recomienda el uso de herramientas encada etapa. También considera aportes denormas de calidad tales como ISO 9000,CMM y Tick IT. Además de Técnicas deauditoría, tal como COBIT.

Cómo método completo, la primera versión data delaño 2000.



JUAN BRAVO 44

CLAVES DE LA IMPLANTACIÓN DE

MÉTODO

Son claves que guían el trabajo en la implantaciónde método en una organización. Previo, es necesariosincerar hasta dónde la organización trabaja en for-ma métodológica.

Método no es algo que solamente se compre y apli-

que, como una máquina, tampoco se puede interna-lizar mediante pastillas (ni disponemos todavía de latecnología de Matrix, aquella donde Neo aprendíarápidamente mediante un tubo conectado directa-mente al cerebro).

Método tiene que ver con el desarrollo de

competencias de las personas, con untrabajo arduo de generar estándaresinternos y externos.

Hemos detectado 4 claves, son recursivas, es decir,también aplican para los proyectos que utilizarán elmétodo en la organización.

Clave 1. Visión de conjuntoClave 2. Mínimo indispensableClave 3. Participación de todos los actoresClave 4. Circularidad

Clave 1. Visión de conjunto

La visión sistémica es vital, se materializa, porejemplo, en los planes y en un conjunto de mapas:




• Mapa de Necesidades• Mapa de Proyectos

• Mapa de Procesos• Mapa de Eventos se refiere a llevar registros de

retroalimentación del término de los proyectos yde sucesos que es bueno conocer.

• Mapa de Sistemas computacionales existentes.• Mapa de elementos de la instalación (EI): hard-

ware, software.

• Mapa de Clases, válido cuando hay desarrollointerno.

Por supuesto, cada mapa tiene los atributos de cadacomponente y su propia base de datos.

En todos los casos, los mapas deben estar disponi-bles para la organización utilizando las herramientas

apropiadas. Independiente del registro de cambiosde cada modelo, es vital una versión actualizada decada uno de ellos.

Estos mapas deberían crearse como parte de la im-plantación del método.

Otra forma en que se materializa la visiónde conjunto es apreciando la cultura ynivel de avance de la organización en laaplicación de formalidades y construir desde ahí.



JUAN BRAVO 46

Clave 2. Mínimo indispensable

Se trata de negociar el alcance de la implantación

del método bajo el criterio del mínimo indispensa-ble, es decir, el mínimo que todos los interesados secomprometen a cumplir, no por imposición, sino porreflexión o toma de conciencia. Aplica aquí la técni-ca de W. Pareto, su ley de los pocos críticos y mu-chos triviales

No se refiere exactamente a la interpretación de Ju-ran del 80-20 —con el 20% del esfuerzo se logra el80% de avance— sino que a una negociación res-pecto a lo se considere mínimo para la organizaciónparticular.

El mínimo indispensable significa un

método flexible y preciso, bien adaptado ala realidad de la organización y de cada proyecto particular, porque su orientación

es simplicidad, flexibilidad yaplicabilidad, para que realmente sea

utilizado en las organizacioneslatinoamericanas.

Es importante considerar que este mínimo indispen-sables estará influido por la cultura de la organiza-ción en cuanto a disciplina y sensibilidad a la estan-darización. Por ejemplo, en una organización certifi-cada en normas de calidad, es probable que sea másamplia y fluida la implantación de método debido a

que ya están sensibilizados en normas, procedimien-tos y calidad.




Clave 3. Participación de todos los actores

La implantación de método es una tarea de todos, el

método no puede ser propiedad de una parte de laorganización, pertenece a toda ella, independienteque alguien lo administre.

Lo primero es identificar los actores, por ejemplo:

• El cliente es el cliente. Está fuera de la organiza-ción, es quien paga los sueldos de todos en la or-

ganización y a quién en definitiva sirven los pro-yectos. Es necesario validar cada proyecto a laluz de sus Intereses actuales o potenciales.

• El usuario es quién hace uso de los sistemas paraservir a los clientes. Se pueden identificar usua-rios ejecutivos y usuarios operativos.

• Analistas o profesionales de proyectos forman elequipo de trabajo: gerente de proyecto, especia-listas en procesos y tecnología, además de con-sultores.

• La alta dirección, gerencia o simplemente autori-dad se encarga de la toma de decisiones respectoal proyecto.

Luego definir los roles de cada uno en relación almétodo y la forma en que se abordará su incorpora-ción, habitualmente es una combinación de sensibi-lización, capacitación y coaching.

Es interesante observar que solamentedifundir el método es un proyecto en sí

mismo donde aplica todo lo indicado eneste texto.



JUAN BRAVO 48

Clave 4. Circularidad

La implantación de método puede seguir la forma de

desarrollo en espiral presentada en el anexo 5. Así,en un par de meses la organización ya podría estaraplicando algo de método y disfrutando de los bene-ficios de proyectos mejor realizados.

Con el desarrollo en cascada laimplantación puede ser muy larga, ¿dos

años? ¡Demasiado!, podría decir elgerente.

La gradualidad es el concepto de fondo, es decir,implantar en base a avances sucesivos, a partir denegociaciones respecto a lo que realmente las perso-nas quieren y pueden hacer. Justamente una de las

ideas centrales de este método es el buen manejo delcambio, donde se plantea que un sistema en buenfuncionamiento es una joya que debe tratarse conmucho cariño, asegurándonos que lo nuevo es efec-tivamente mejor, sin el encandilamiento transitorioque tanto daño provoca.




CARACTERÍSTICAS DEL MÉTODO

El método descrito en estas páginas para la buenagestión de proyectos de procesos y tecnología tienemuchos elementos y una complejidad que no puedeser reducida artificialmente, porque corremos elriesgo de simplificar demasiado.

De todas formas, destacan estas siete características:

1. Adhesión a estándares y normas de calidad

Además de cumplir con la normativa interna y ex-terna obligatoria, el método GSP se orienta a traba-

jar con estándares formales o de facto, tales como:MP (Mapa de Procesos) y FI (Flujograma de Infor-mación), OO (Orientación a Objetos), UML, CMM,ISO 9000, ITIL, PMI y otros que veremos en el tex-to (las siglas indicadas se pueden ver en los anexos).

El método es abierto y permite trabajar con esos y otros estándares. Es más,veremos que “aprende” de ellos, los

incluye y se potencia.

2. Actualización

Un elemento conceptual importante es planificar alcomienzo y luego continuar planificando durantetodo el proyecto, por la imperiosa necesidad de man-

tener actualizadas las definiciones, porque si sólo



JUAN BRAVO 50

existe el plan inicial, rápidamente pierde sentido porla dinámica de la realidad.

Tenemos que aprender a elaborar buenos planes ymantenerlos actualizados, considerar los riesgos,prevenir y confeccionar planes de contingencia.

Es bueno tener presente la conocidaafirmación de Murphy: “si algo puede

fallar, fallará”.

4. Información de calidad

En el enfoque de proyectos se reconoce la importan-cia de la información, y sus atributos: oportuna, con-fiable, creíble y de calidad.

El ideal es que todo el manejo de la información seaen línea, es decir, en tiempo real y que los datos seancapturados en la punta del proceso, evitando redigita-ciones. Además, trabajar todo lo posible en formatodigital. Una buena idea es un programa del tipo Pa-

perless que están impulsando muchas organizaciones,se trata de fomentar trabajar sin papeles.

Información de calidad significa, entre otras carac-terísticas además de las ya indicadas: exactitud, tota-lidad, relevancia, consistencia y detalle (la profundi-dad necesaria).

Hablamos aquí de información en lugar de datos por-que ya existe un nivel de procesamiento para lograr

los atributos indicados.




3. Pragmatismo

Pragmatismo es hacer lo mejor que se pueda hacer

para lograr los objetivos de un proyecto, es lo opues-to al fundamentalismo, más bien sería el comple-mento como en el Yin y Yang (la armonía de losopuestos, lo femenino y masculino, etc.).

No es sinónimo de improvisación ni significa livian-dad en la disciplina para seguir un método.

Es darse cuenta que en un momento deltiempo hay una bifurcación mejor a la

“establecida”.

Por ejemplo, en cada etapa se puede volver a unaanterior para efectuar cambios o cancelar el proyec-to. No hay problema en la medida que sea por adap-tación a nuevas circunstancias. Hay problema cuan-do el motivo es porque la etapa anterior no se hizocorrectamente.

A propósito, Jeff Davidson, en su libro La Gestiónde Proyectos, ofrece siete sugerencias para triunfaren la gestión de proyectos (páginas 21 a 23):

• Aprender a utilizar eficazmente las herramientasde gestión

• Saber hacer y recibir críticas• 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



JUAN BRAVO 52

5. Curso normal de los Eventos y SPPP

Es un nuevo criterio de la teoría de modelos y es

central en la nueva generación de técnicas visuales.

La idea general es tratar las excepcionescomo excepciones, sin darles el mismoespacio visual que el curso normal de loseventos, en esto debe existir armonía conla realidad, donde lo más habitual

aparece más y lo menos, menos.

Se aplica especialmente en flujogramas de informa-ción y casos de uso expandido.

Las excepciones se definen aquí como situacionesindeseables que perturban el flujo, van como textofuera del modelo cuando son relevantes.

El SPPP (Simplificar Procesos y Potenciar Personas)deja completamente de lado la antigua, peyorativa einútil pretensión de “construir sistemas a prueba detontos”.

6. Adaptación a proyectos específicosLa idea es adaptar el método a cada proyecto parti-cular, donde se considera que lo esencial es no sal-tarse ninguna etapa. Aunque sí es factible negociarlas actividades que incluiría y el alcance de lasprácticas transversales.

Esa es la idea de la siguiente figura, donde el méto-do de la organización es una base de conocimiento




que se adapta a cada proyecto particular, aunquemantiene un tronco común.

Las claves de la implantación de método del capítulo

anterior también son válidas para aplicar el método acada proyecto particular dentro de la organización.

El método se puede aplicar en todos los proyectos,aunque es necesario hacer ajustes según su tamaño.

El tamaño del proyecto

Trabajaremos con estas distinciones (en conocimien-to que la complejidad del mundo producirá excep-ciones y que los límites entre tramos son difusos):

• Proyecto pequeño: hasta US$ 100.000• Proyecto mediano: más de US $ 100.000 y

hasta US$ 1.000.000• Proyecto grande: más de US$ 1.000.000

Método de laOrganización

Aplicación aun proyecto

Adaptación

Método de laOrganización

Aplicación aun proyecto

Adaptación



JUAN BRAVO 54

El método debe adaptarse a cada realidad porque noes lo mismo un proyecto pequeño que uno grande.

También influyen otros factores, tales como el avan-ce previo y la prioridad, que puede llevar a tener unaespecie de Fast Track en el caso de proyectos priori-tarios por alguna contingencia o por necesidadesestratégicas.

7. Pasión por conocer la finalidad, el para quéTodos los actores del proyecto deben tener claridaden objetivos, resultados y propósito alineado.

Más allá de los entregables por etapa, esvital definir y conocer lo que se quierelograr, los objetivos finales. Tener la vista

puesta en el destino ayudará a darles unsentido a todas las actividades del

proyecto.

Davidson aconseja (página 33): “Al tener una ideaclara del final deseado todas las decisiones que setomen respecto al proyecto irán en el mismo sentido

con más probabilidad de lograr el final deseado”.




ESTRUCTURA PARA LA GPPT

La buena gestión de proyectos de procesos y tecno-logía también tiene que ver con una serie de instan-cias de estructura organizacional o funciones.

Esto es lo se denomina “incorporar” a la organiza-ción, es decir, llevar al cuerpo, a la estructura.

Algunas de estas instancias son:

Área de metodología o UTP

En el área de metodología laboran los depositariosdel método, quienes lo actualizarán, difundirán ytendrán la responsabilidad por los mapas de apoyo.

Puede tener además la forma de una UTP (Unidad

Técnica de proyectos) que se asegure de la formali-dad metodológica de cada proyecto, es decir, se in-corpora aquí una labor más bien operativa.

Eventualmente las área de metodología yde UTP pueden ser áreas diferentes y que

trabajan coordinadamente.

Área de estudios

Un área de estudios equivale a un área de estudiosde propuestas. La diferencia es que el área de estu-dios se dedica a procesar propuestas internas para

necesidades y soluciones.



JUAN BRAVO 56

Es un área que ayuda a generar mucha rentabilidad ala empresa, porque deja en evidencia la gran canti-

dad de proyectos que se pueden realizar.

Comité de Proyectos

Considerando que la tecnología sirve a procesos es-tratégicos, del negocio y de apoyo en la organiza-ción, la figura del Comité de Informática ha ido

cambiando hacia un comité de proyectos que unifi-que procesos y tecnología con una mirada sistémicaque abarca toda la organización, comenzando poraplicar las definiciones estratégicas.

El comité de proyectos guía el Proceso de Detección de Necesidades y Formulación

de Proyectos (etapas de concepción y factibilidad del método) administra elmapa de necesidades en conjunto con elárea de metodología (también el resto delos mapas).

También recibe la retroalimentación de los proyec-

tos en desarrollo.Por supuesto, el comité de proyectos requiere unafórmula simple para administrar los compromisosvigentes e históricos., así como definir la forma detoma de decisiones en casos de emergencia.




Cierre del Proyecto

Al finalizar el proyecto, se cierra la carpeta del pro-

yecto en el comité de proyectos con un informe queseñale como fueron resueltas las necesidades origi-nales (y actualizadas) y como se comportaron el pla-zo, costo y otras variables respecto al plan.

Se requiere la firma de todos los actores (dueño delproceso, jefe del proyecto, etc...)

Esto es independiente de los entregables por cadaetapa cuya aprobación depende de la estructura queel mismo comité de proyectos aprobó.

Área de gestión TI

El objetivo es aportar con algunas orientaciones a la

mejor organización de la gestión TI:

Lo más fundamental: tener la visión puesta en el cliente (implica escuchar

sistemáticamente) y alinear todas lasdecisiones TI con la misión de la

organización.

• Dependencia de una Gerencia de Desarrollo o deuna Dirección de Sistemas de Información quetiene en sus manos los principales elementos decambio en la organización.

• Gestión interna de elementos:: versiones, inventa-rio de productos TI, cambios, planes de contin-gencia, etc...



JUAN BRAVO 58

• Estrategia TI alineada con la estrategia corporati-va. La visión de negocios es central en la estrate-

gia (el cliente de informática es el cliente).• Tener alguna forma de aseguramiento de calidad.

• Trazabilidad en el desarrollo de los proyectos:significa que es posible hacer el seguimiento deun requerimiento desde su gestación hasta lapuesta en marcha

• Contar con un método de desarrollo completo.

Políticas en TI

Se trata de directrices que toda la organización secompromete a cumplir, por ejemplo:

• Estándares con los que se trabajará (XML,

UML, etc...)• Artefactos mínimos del diseño de las aplica-

ciones (modelo conceptual, diseño de clases,etc...)

• Interfaces visuales estándares (pantallas, in-formes, etc.)

•

Control de calidad de aplicacionesPrivilegios y responsabilidades en cuantoa la tecnología de información

• Requerimientos que puede solucionar elmismo usuario

• Aspectos metodológicos de análisis e imple-

mentación de aplicaciones• Delegación y trabajo en equipo




¿Por qué las políticas?

Las políticas se consideran centrales para el mejor

funcionamiento de la empresa porque ayudan a tenermejor comunicación interna y externa en las área deinformática y de proyectos.

Las políticas ayudan a establecer unarelación más formal para la toma de

decisiones en el día a día de la TI.

Arquitecto de Datos

Se trata de una función de la organización más quede un cargo en particular (en organizaciones máspequeñas es uno o un conjunto de cargos).

Componente técnica

En el responsable del modelo de datos corporativo.Esto significa que su preparación en Modelamientode datos es de primer nivel. El opina a nivel del di-seño de datos de cada aplicación y mantiene el mo-delo conceptual de la organización.

Es responsable también del diseño físico de la basede datos y por tanto filtra el modelo de datos decualquier nueva aplicación. Soluciona redundanciase incorpora al modelo físico corporativo lo relevantepara toda la organización (pueden existir aplicacio-nes locales que no dependen de él).



JUAN BRAVO 60

Aplica técnicas y herramientas para mantener laconsistencia y eficiencia de las bases de datos. Opi-

na acerca del esquema de seguridad de datos de cadaaplicación.

En todo caso de agregar tablas hace unestudio de cómo impactan en el modelocorporativo y recomienda adaptaciones.

Interactúa con el DBA (Data Base Administrador).

Componente de negocios

Desde el punto de vista de registrar a que procesossirven los datos.

Hoy con la ayuda de herramientas de modelamientocorporativo es posible unir ambos temas porque to-dos los modelos están centralizados. Por ejemplo:WBM (Websphere Business Modeler), de IBM (de-rivó desde el M1), Corporate Modeler de CASE yARIS, de SAP.

También esto se logra con herramientas más senci-llas tal como Erwin, System Architect, Visio y mu-

chas otras. Beneficios de contar con la función de arquitecto dedatos (puede ser más de una persona):

• Permite que la organización conozca el modelode datos de cada aplicación. Aunque la aplica-ción sea externa se debe indicar con precisión la

estructura física de los datos que la sustenta.




• Permite tener una visión de conjunto de los datosy un verdadero modelo corporativo. Esto ayudará

a solucionar requerimientos rápidos que puedenrealizar los mismos usuarios cuando no hayacreación de tablas y se puede apoyar el desarrollode aplicaciones más eficientes y efectivas.

• Permite más seguridad e integridad de los datos.

Con este conocimiento se puede apoyar de mejor

forma la estrategia tecnológica.



JUAN BRAVO 62

SEGUNDA PARTE.ETAPAS DEL

PROYECTO




Todo el mundo conoce la historia de los hijos del zapa-tero: el zapatero está tan ocupado haciendo zapatos para otros que sus hijos van descalzos. Durante losúltimos 20 años, muchos ingenieros de software han

sido “los hijos del zapatero”. Aunque estos profesiona-les han construido sistemas complejos que automatizanel trabajo de otros, ellos mismos no han aplicado estas

técnicas.Roger S. Pressman



JUAN BRAVO 64

INTRODUCCIÓN

Cada etapa consta de actividades: algunas son pro-pias de la etapa y otras provienen de las prácticastransversales. En todos los casos han surgido de ob-servar las mejores prácticas del medio.

Veremos que cada etapa tiene entradas y salidas.

Lo más fundamental en todo proyecto es

no saltarse ninguna etapa. La negociaciónque debería hacerse es respecto al alcance

de la etapa dada la envergadura del proyecto y otros factores.

Al iniciar cada etapa una actividad común es actua-lizar el trabajo de las etapas anteriores, especialmen-

te cuando ha pasado tiempo entre etapa y etapa. Esteconcepto de actualización permanente está recogidotambién en las prácticas transversales.

Sucede a veces que una etapa realiza con desfaserespecto a la anterior y el simple paso del tiempodice que algo pudo haber cambiado.

Cuantificar todo

Un aspecto central del método GPPT es cuantificar:

• El problema y las soluciones• Costos reales y ocultos• Beneficios directos y costos de oportunidad




Carlos Toloza, Director del Programa Competitor para la Rentabilidad de Proyectos Informáticos, en

un artículo para el Diario Financiero (2005, página54), plantea: “Una inversión informática concebidacorrectamente es evaluada en términos de beneficioseconómicos concretos y genera rentabilidad para laempresa. Esta es la única forma de aprovechar lainformática para mejorar la competitividad del ne-gocio. En el momento de definir los beneficios

económicos del proyecto, a veces se comete el errorde pensar en «beneficios intangibles» y elementosdifíciles de medir. La verdad es que si los fríosnúmeros no dan, no se justifica invertir”.

Lo mismo es válido para rentabilidad social de pro-yectos, ya sea en reparticiones del Estado u organi-zaciones de la sociedad civil. Todo debe ser cuanti-ficado, es el mensaje, porque es la manera de dis-criminar en el impacto y buscar el máximo valoragregado. Por ejemplo, ¿cuánto cuesta que un niñono aprenda? o ¿cuánto gana la sociedad con unaeducación bien lograda?

Fase de estudiosAquí están las etapas de Concepción y factibilidad,ambas forman lo que podríamos llamar fase de estu-dio de proyectos.

Es vital la prudencia, saber cuándoavanzar y cuando retroceder, practicar un



JUAN BRAVO 66

poco de lobby e ir logrando consensorespecto a la forma del proyecto.

Ya sea para abordar la necesidad o para comenzar aesbozar proyectos son vitales las habilidades de co-municación y de negociación, por ejemplo, para:

• Formar alianzas• Presentar el caso de negocios en diversos niveles

de avance (borradores sucesivos cada vez más

afinados)• Recopilar el máximo de información disponible

y cuantificar todo.• Aclarar objetivos del proyecto• Identificar a todos los actores, precisar sus inter-

eses y alinearlos.• Aplicar o definir estándares de gestión y deter-

minar como se cumplen.• Presentar en variadas instancias: dirección de la

empresa, usuarios, sindicatos, etc.

Proceso Fabricar el cambio

Durante esta fase se establece un Proceso formal deDetección de Necesidades y Formulación de Proyec-tos dirigido por el comité de proyectos u otra instan-cia que represente el interés global de la organiza-ción.

El objetivo es implementar un proceso para generarnuevos proyectos, desde la detección de una necesi-

dad hasta la definición del proyecto.




Este proceso es necesario porque la forma en que losproyectos surgen en la organización debe seguir

normas estándares, evitando así que surjan desdeáreas o personas con objetivos locales o en formatan improvisada que se pierda la visión de conjunto.

Todo integrante de la organización puede detectarnecesidades (con algunas horas de capacitación).

Luego, para profundizar en la misma necesidad e

iniciar el estudio de soluciones se requiere de profe-sionales dedicados y con una preparación adecuadaen gestión de proyectos.

No hay problema que sean profesionalesdestinados transitoriamente al área de

estudios desde otras áreas, lo importantees que tenga las competencias necesarias.

Veremos brevemente las tres fichas que se utilizanen este proceso de fabricar el cambio, más el cierredel proyecto.

Ficha 1: Detección de la Necesidad (oportunidad o

Ficha 1: Detección de la Necesidad

Nº de la necesidad

Quién detecta

NecesidadCosto estimado



JUAN BRAVO 68

problema).

El objetivo del formulario es ayudar al Comité deProcesos y Tecnología a decidir si corresponde o noestudiar con mayor detalle una detección de necesi-dad.

Todo integrante de la organización puede llenar esteformulario (con la capacitación correspondiente) el

cual sería presentado por el encargado de área co-rrespondiente.

Si se aprueba lo planteado en esta ficha se solicitaráel desarrollo de la Ficha de Evaluación Comparativade Soluciones, por lo que al final de este formulariose deberá consignar por parte del Comité la decisión,la prioridad asignada y el evaluador designado paracompletar el segundo formulario.

Ficha 2: Evaluación comparativa de soluciones

El objetivo del formulario es ayudar al comité de

tecnología a decidir si las soluciones satisfacen o nola necesidad detectada. Si es así, se selecciona algu-na de ellas o una combinación de ellas con todas lasobservaciones necesarias.

El Comité puede solicitar replantear el estudio o en-cargar al mismo u otro evaluador la confección de laFicha Plan de Proyecto.




Pueden presentar este formulario los evaluadoresdesignados para ello por el comité de proyectos.

Ficha 3: Plan de Proyecto

Contiene todos los detalles necesarios para una bue-na ejecución del proyecto.

Se presenta al comité de proyectos para su aproba-ción e inicio, asignando las personas y recursos co-rrespondientes.

Ficha 2: Estudio Comparativo

Nº de la necesidad

Quién estudiaSituación actual de la necesidad

Detalle de cada solución propuesta

Estudio Comparativo

Recomendación



JUAN BRAVO 70

De acuerdo con lo indicado en el mismo plan y laspolíticas de la organización al respecto, se define el

seguimiento del proyecto.

Cierre del Proyecto

Se trata de un informe de cierre al momento de con-cluir señalando como fueron resueltas las necesida-

des originales (y actualizadas) detectadas.

Ficha 3: Plan de Proyecto

Nº de la necesidad

Quién estudia

Situación actual de la necesidad

Explicación de la solución

Aporte estratégico y VAN

Revisión de cada etapa

Revisión de cada práctica transversal(desde las políticas)

Carta Gantt y planes detallados




Se requiere la firma de todos los actores (dueño delproceso, jefe del proyecto, etc...)



JUAN BRAVO 72

ETAPA 1. CONCEPCIÓN

Lo que da origen al trabajo en la etapa es un síntomao una serie de síntomas que producen molestias(pérdidas, atrasos, molestias de clientes, costos ex-cedidos y mucho más).

Decimos que es una confusión porque no sabemosrealmente cuál es el problema de fondo.

El objetivo de la etapa de concepción es concebiruna necesidad, o un problema que pertenece a unapersona o área que lo reconoce como tal.

La necesidad puede tomar formas tales como unaoportunidad 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 sequiere solucionar o una meta que se desea alcanzar,hablamos genéricamente de “Problema”, puesto en-

tre comillas porque al comienzo resulta pretenciosollamarle así, hay muchos síntomas que cuesta inter-pretar, más bien lo que se tiene es una confusión ouna sensación de molestia indefinida…

Entonces, la solución de la confusión es el problema.




Yendo a los fundamentos conceptuales, la visiónsistémica tiene especial predilección por invertir

tiempo en la adecuada definición de los problemas,antes de hablar de las soluciones.

De hecho, en teoría de sistemas se dice que cuandouno descubre el verdadero problema, el de fondo…¡la solución está incluida!.

Precisamente el objetivo de esta etapa esaclarar la confusión para obtener unenunciado validado, a eso le podemosllamar Problema, definido como unadistancia, entre dónde estamos y dóndequeremos estar.

Fruto del análisis de los síntomas y de la confusión,se llegará a un problema de fondo6.

Esta salida también puede provenir desde las defini-ciones estratégicas o desde el mapa de necesidades de la organización, en ambos casos, se le da formacomo una necesidad.

¿Es posible saltarse esta etapa cuando una necesidadproviene de un proceso de planificación estratégicao desde el mapa de necesidades? Es preferible nosaltarse la etapa aunque la necesidad venga dada,porque es necesario cuantificar y dar un formatocomún para pasar a la siguiente etapa.

6 La técnica de enfoque al problema se presenta en detalle en el libro Análisis de Sistemas.



JUAN BRAVO 74

La propuesta de GSP es utilizar una ficha para ayu-dar en la detección preliminar de necesidades o pro-

blemas.De acuerdo con el proceso de detección de necesi-dades y formulación de proyectos, todo integrante7 de la organización puede detectar necesidades (ojaláen un formulario sencillo, no más de una página). Sise aprueba lo planteado en esta ficha generalmentehay dos caminos que sigue el comité de proyectos:

a) Solicita un estudio más detallado de la nece-sidad.

b) Solicita el cierre de la etapa de concepcióncon el entregable que corresponda.

En ambos caminos recurre a profesionalesespecializados de dentro a fuera de la

organización.

Un informe típico de esta etapa debiera incluir lospuntos siguientes, los cuales se aplicarán en formaiterativa, como en una espiral, se logra un avance encada punto y luego en una segunda vuelta se perfec-cionan 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 “Análisis de Sistemas”, tercera y cuarta parte, se pue-den encontrar mayores alcances acerca de la importancia de la parti-cipación y de su impacto positivo en los resultados.




Es necesario ver esta descripción como un continuoque se inicia como una descripción breve en la pri-

mera “vuelta de la espiral” —lo mínimo para com-prender el problema— hasta un mayor detalle antesde pasar a la etapa de factibilidad.

Entonces, con base en las orientacionesestratégicas de la organización y tomando

en cuenta las oportunidades y exigencias

que el medio plantea, lo primero esconocer el ámbito de trabajo y ubicarnosen el entorno.

Normalmente el ámbito de trabajo son áreas o pro-cesos. En el primer caso, puede ser racionalizar elárea de abastecimientos, la oficina comercial o laplanta productiva. En el segundo caso, el proyectopuede ser rediseñar el proceso de: créditos de con-sumo, créditos hipotecarios u operaciones cambia-rias, si se trata de un banco. O podría ser fabricaciónde zapatillas, zapatos de varón o diseño en el caso deuna empresa productora de zapatos. También pue-den ser los servicios de exámenes de laboratorio, las

atenciones ambulatorias y la contratación de perso-nal en un hospital.

¿Por qué comenzar por esa área o proceso de nego-cio y no por otro ámbito? La respuesta la podemosencontrar en las orientaciones estratégicas de la or-ganización.



JUAN BRAVO 76

Descripción de la situación actual

Conocer dónde estamos es importante porque en un

proyecto de rediseño participarán muchas personas,algunas externas, otras internas con más o menosantigüedad. Entonces, es preferible no dar por obvioo conocido aspectos que pueden ser importantes.

Conociendo cuál es el ámbito, ahora serequiere saber dónde estamos.

A veces se le llama “descripción de la situación ac-tual” e incluye:

1. Descripción del medio en el cual se encuentra laorganización: características de la industria, de laeconomía y demás entorno inmediato. Es decir,¿dónde estoy?

Aplican aquí las técnicas de síntesis y análisis dela visión sistémica (libro Análisis de Sistemas).

2. Descripción de la organización: historia, produc-tos y mercados principales, estructura organiza-cional, tamaño y cualquier aspecto significativo.Es decir, ¿quién soy?

3. Descripción cuantitativa de las situaciones enque se trabajará: identificación, descripción bre-ve, estimación de costos, nivel de urgencia porcambiar, ¿qué riesgos tiene mantener la situaciónactual?, etc. Es decir, ¿qué sucede?

4. Descripción de la estrategia: para saber cuál es

la dirección en que camina la empresa. Es decir,¿qué queremos?




Principalmente en términos de visión,misión, valores, programa de acción,

factores de diferenciación y otrasdefiniciones típicas.

5. Rol de las personas: Cuál es el perfil de cargosen torno al problema, ¿las personas tienen lascompetencias necesarias? ¿cuál es nivel de pre-paración? ¿cómo está la motivación?…

6. Descripción de la estructura organizacional yrelaciones: ubicación de la necesidad en unaunidad organizacional, en una función y/o en unproceso. Identificar relaciones del área problemacon otras áreas, qué y a quiénes provee, de quié-nes recibe qué, etc.

El contenido y profundidad de estas descripcio-nes dependen de cada situación

7. Revisión de los procesos: mapa de procesos yflujogramas de información (podría no ser tandetallado en esta etapa, ver sección 3.5).

8. Tecnología que se aplica: revisión de la actual

situación en cuanto a redes, hardware, software,herramientas de apoyo, ERP y todo lo demás re-levante.

A veces la descripción será detallada, como cuandose trata de un informe de consultoría de alguien queno conoce la organización, o breve, cuando es unapresentación interna de un ámbito conocido por to-dos y documentado.



JUAN BRAVO 78

1.2. ¿Cuál es el problema?

Se trata de avanzar desde la confusióninicial hasta un enunciado validado.

Siendo el objetivo de la concepción obtener unenunciado validado del problema, este enunciado sepuede ensayar muchas veces, al mismo tiempo quese avanza en las actividades de la etapa.

Cabe señalar que un proceso como el descrito enestas páginas, junto con ayudar efectivamente a ob-tener un enunciado validado respecto a la confusióninicial, también generará nuevos cuestionamientosque darán origen a enunciados de otros problemas.

a) Exponer la confusión

Es el primer enunciado, no validado, lo que da ori-gen al trabajo de la etapa. Se requiere valentía y almismo tiempo humildad para escribirlo, porque laprobabilidad de cambiarlo es muy alta, tal vez un99% (basado en las experiencias de consultoría y enmuchos ejercicios en diferentes cursos). Esto es im-

presionante, quiere decir que al no pasar por estaetapa el problema que se solucionará tiene esa pro-babilidad de estar equivocado…

b) Ensayar enunciados

Se trata de proponer variados enunciados

del problema hasta encontrar el que parece más apropiado.




En cada situación específica, la idea es comenzarpor trabajar en el problema hasta obtener un enun-

ciado validado. Por ejemplo, en una visita a la bode-ga de distribución en Santiago, el nuevo gerente deoperaciones de una empresa productiva ubicada enCuricó (distante 200 kilómetros), observa que: “Enla bodega de la empresa existen problemas de ma-nejo de la información (errores y saldos atrasados)debido a la gran cantidad de transacciones”, y

aprovechó inmediatamente su visita a la capital paraadquirir un programa computacional... y aunque elprograma funcionó… el problema subsiste.

¿Qué pasó? Qué el gerente se quedó en la confusión,con el primer enunciado. Hizo un primer diagnósticoapresurado y lanzó una solución que en otra partehabía 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 técnicas,por ejemplo, causa efecto, cuestionar la existenciade cada palabra del enunciado o preguntar ¿por qué?

Así, algunas preguntas en relación al caso de la bo-

dega serían: ¿debe existir la bodega en la empresa?,¿debe existir la empresa?, ¿conviene venderla?, ¿re-almente existen esos problemas de manejo de infor-mación?, ¿existe gran cantidad de transacciones?,etc.

Con ese tipo de preguntas se armanenunciados hasta que obtenemos uno que



JUAN BRAVO 80

nos resuena, y que “resiste” las pruebas ycuestionamientos que le hacemos.

¿Qué hay antes del problema? Una situación confusaque no permite el desarrollo del proceso creativo yse presta para la aplicación de recetas, es decir, “so-luciones” empaquetadas que no toman en cuenta lavariedad del problema. Sabemos que cualquier solu-ción a un problema confuso solamente incrementará

los costos. Por eso, la solución de la confusión es el problema… bien enunciado y estudiado.

Una ventaja es que a este nivel el costo del error esmuy bajo, podemos redefinir el enunciado cuantoqueramos, sin más costo que el tiempo invertido enel análisis. Si se avanza hasta implementar una solu-ción sobre un problema errado, lo más probable es

que hacer todo de nuevo tenga un costo alto.Antes de seguir, convengamos en que llegar a la cla-ridad total de la confusión es imposible. Los siste-mas son caóticos e indescriptibles, el enunciado per-fecto no existe, lo que hacemos es trabajar con nive-les tolerables de incerteza.

A veces, hay presiones que obligan a reducir eltiempo de análisis hasta donde sea posible. Debemoscuidar que ese nivel no llegue a cero. La idea es des-tinar algo de tiempo a aclarar la confusión y enun-ciar el problema antes de lanzarnos a las soluciones.

Hay una cantidad de tiempo “razonable” en el estu-

dio de la confusión, único para cada caso. No puedeser mucho, porque corremos el riesgo de quedarnos




“dentro del cuadrado” de lo que se ha hecho previa-mente. No puede ser poco, porque el problema arras-

traría más confusión de la que puede soportar la so-lución.

Entonces, nuestra meta es llegar a tener un problema bien planteado, con

mediciones de las variables críticas.

c) Identificar y medir las variables críticas del pro-blema

Se requiere identificar las variables críticas para elproblema particular Por ejemplo: tiempo que losclientes esperan en una fila, número de exámenesque se pierden, clientes que reclaman y cualquier

otra relevante para el problema en estudio. Mejor todavía, identificar la variable

crítica más importante y trabajar con ella.Eso focaliza y enriquece el esfuerzo.

Por ejemplo, la variable crítica puede ser tiempo quelos clientes esperan en una cola para pagar en lacaja.

Luego se requiere medir el estado actual de esas va-riables y de ser posible comparar contra un estadodeseado o estándares de la industria.

Se requiere aportar datos concretos y hechos preci-sos que ayuden a la comprensión del problema y alplanteamiento del enunciado.



JUAN BRAVO 82

El volumen de algo cambia drásticamente la con-cepción de un problema. No es lo mismo manejar el

stock de pocos productos, lo cual se puede hacervisualmente, que de miles, para lo cual el computa-dor es indispensable.

Si se trata de un problema de inventarios:

• ¿Cuántas transacciones de cada tipo existen?• ¿Cuántos metros cuadrados y cúbicos ocupan las

existencias?• ¿Cuál es la rotación?• Cuál es el tiempo promedio de despacho?• ¿Cuál es el tiempo de demora de un pedido a los

proveedores? ¿Cómo varía entre diferentes pro-veedores?

Costos más difíciles de cuantificar ¿La existencia del problema afecta el ánimo de laspersonas?

El problema resuelto ¿tiene algún efecto de marke-ting? ¿Mejora la imagen de la empresa? ¿Realmenteaporta a la organización? ¿Aporta indirectamente?

Si visualizamos el problema resuelto:¿cómo 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 estimación.




Urgencia por solucionar

Dentro de las variables críticas también está la ur-

gencia por solucionar, porque no es lo mismo unproblema de renovación de vivienda que de apoyoen caso de un desastre.

Este análisis es vital para las soluciones en la etapade factibilidad.

d) Determinar las causas de fondoEn todo caso, el objetivo es identificar las causasraíces del problema, pudiendo aplicarse otras técni-cas, como las del mejoramiento continuo. Algunasson:

1. Técnica de cuestionar la existencia de cada palabradel enunciado

2. Técnica de Benchmarking, o cómo otras organiza-ciones han planteado problemas similares

3. Búsqueda bibliográfica4. Ishikawa y Pareto (ver anexo 1, relación causal)5. Consultores u otros profesionales familiarizados con

el tema

e) Identificar al dueño del problema

Puede ser una persona, un equipo o un área, lo im-portante es que cada problema debe tener un dueñoque lo reconoce como propio y que está interesadoen que se aclare y se resuelva.

A veces esto puede obligar a plantear facetas delproblema para más de un dueño. Por ejemplo, en un



JUAN BRAVO 84

caso de crisis se quiere ayudar a empresas pequeñasque están sufriendo especialmente los rigores.

¿Quién es el dueño del problema? ¿La repartición acargo del subsidio y que de alguna forma representaa la comunidad? ¿Es la empresa pequeña que de al-guna forma debe empoderarse?

f) Enunciado validado

Ahora sí, aclaramos la confusión y obtuvimos unproblema. El enunciado final del problema es lo quese anota en este punto.

1.3. Cuantificar el problema

Importa calcular el costo del problema (o de no re-solver la necesidad). Los costos de oportunidadtambién se incluyen, tales como clientes potencialesque no llegan, ganancias no logradas por no dispo-ner de productos en stock, personas que no salen dela pobreza en el caso de un proyecto social, etc.

VA del Problema

Lo más concreto es calcular un VA (Valor Actual)del problema.

Por ejemplo, en un banco el problema es lo lento delservicio de comercio exterior, con 100.000 clientes.

El costo del problema se puede medir, por ejemplo,en términos de imagen: 10.000 clientes se han ido en

los últimos cinco años, cada uno generaba una ren-




tabilidad al banco por US$ 1.000 al año. Aquí hayvarios millones de dólares como costo del problema.

También se observa que hay ahorros que se puedenlograr. Se estima que 50 personas pueden liberarsede procesos obsoletos, con rentas bruto promediomensual de US$ 2.000, más el espacio físico, super-visión y otros recursos, nuevamente son millones dedólares al año.

Otro costo es el de oportunidad , se estima que elbanco podría duplicar la cantidad de clientes con unbuen servicio, entonces, está “perdiendo” o dejandode ganar la rentabilidad de esos 100.000 clientes porno hacer las cosas bien. En el ejemplo, son US$ 100millones anuales.

VA socialEl VA social son las pérdidas concretas que asumenlos clientes por un mal servicio8.

Un ejemplo de VA social es el costo entiempo de los clientes que esperan en una fila. 20.000 clientes al mes a US $ 4 por

hora es aproximadamente un millón dedólares al año que asumen los clientes, es

fabricar pobreza.

8 En el libro Gestión de Procesos hay un análisis detallado al respec-to. Se presenta un caso en una Municipalidad, donde su diseño del

proceso de renovación de licencias de conducir, hace que los usua-rios vayan tres veces y pierdan seis horas, lo cual empobrece a lacomunidad en millones de dólares.



JUAN BRAVO 86

Hemos utilizado US $ 4 por hora para medir el costosocial, solamente considerando promedios de renta.

En nuestro ejemplo del servicio de comercio exteriordel banco, cada cliente debe concurrir al banco unavez al mes, 12 veces en un año. Hablamos de1.200.000 viajes al banco innecesarios porque todoslos trámites pueden ser electrónicos. Cada viaje sig-nifica tres horas que a los clientes de ese servicio lecuestan en promedio US$ 5. Son US $ 18 millones

de dólares perdidos solamente en trámites.También deberíamos calcular el costo para el clientede que el servicio sea lento y no pueda contar con elresultado en la mitad del tiempo si las cosas se hicie-ran bien. Ese cálculo se lo dejamos al lector…




ETAPA 2. FACTIBILIDAD

Lo que da origen al trabajo en la etapa es una nece-sidad de la organización.

El objetivo es obtener el plan de proyectode la solución después de un barrido

creativo de muchas soluciones y de unestudio comparativo de algunas de ellas.

Entregable final de la etapa: el plan de proyecto.

Entregables intermedios: La investigación de solu-ciones y la evaluación comparativa de alternativas

de solución seleccionadas.

~§~

La etapa de factibilidad9

tiene tres entregables se-cuenciales, se accede al siguiente después de la tomade decisión por parte de la autoridad correspondien-te. Puede ser un gerente o un comité de proyectos(suponemos esta opción de estructura en lo que si-gue). La toma de decisión sería después de realizarcada una de estas acciones:

a) Una investigación creativa de muchas solu-ciones y propuesta de alternativas a estudiar.

b) Una evaluación comparativa de alternativasde solución seleccionadas.

9 Un buen apoyo es el libro “Desarrollo de sistemas de información,

una visión práctica”, páginas 50 a 58.También el libro “Análisis de Sistemas”, Quinta parte: ¿CómoHacer Análisis de Sistemas?



JUAN BRAVO 88

c) Un plan de Proyecto de la alternativa selec-cionada.

Por supuesto, en cualquiera de esas acciones, el co-mité de proyectos puede solicitar replantear el estu-dio. Pueden presentar este formulario los evaluado-res designados para ello por el comité de proyectos yque cuenten con las competencias necesarias.

Cada alternativa evaluada es una solución integral

alineada con la estrategia que incluye acciones sobrepersonas, procesos, estructura y tecnología.

Usamos la palabra solución porque es más amplia yrepresentativa que indicar solamente rediseño deprocesos o aplicación computacional. Además, lomás probable es que la solución seleccionada resultede una combinación de varias alternativas.

Creatividad aplicada

En esta etapa la creatividad e inventiva aplicada enla búsqueda de soluciones es vital.

Se exploran amplias posibilidades de

solución al problema hasta decidir por la fórmula que se considere más apropiada.

Así evitamos la rigidez paradigmática que se produ-ce cuando desde el principio alguien cree que tiene“la solución”.

¿Qué técnica es buena para la invención? Existen

muchas: una noche de sueño, meditación, los sietepor qué, tormenta de ideas, los seis sombreros para




pensar, comparación con otras organizaciones,búsqueda bibliográfica, consultoría, etc.

Por otra parte, existe un amplio abanico de técni-cas10 que pueden ayudar a generar soluciones, porejemplo: cadena de valor, just-in-time, flujos tensa-dos, Kanban, producción flexible, costo objetivo,nuevas reglas del juego, salir del pensamiento di-cotómico, armonizar las economías de escala conotras opciones, logística y muchas otras.

2.1. Conformar el equipo de trabajo

El trabajo en la etapa de factibilidad queda enco-mendado a un equipo de proyecto.

¿Pueden los mismos operadores de un

proceso ser parte del equipo de trabajo?Sí, en la línea de mejoramiento continuo o

como parte de equipos de trabajomultidisciplinarios destinados

directamente al proyecto.

Los integrantes de un equipo de proyecto son analis-

tas de proyectos. Esta función no debiera ser unaespecialización profesional, sino que cualquier pro-fesional de dentro o fuera de la organización, con ladebida preparación, puede asumir ese rol en un mo-mento dado.

10 Detalladas en el libro Gestión de Procesos.



JUAN BRAVO 90

Entonces, cada proyecto específico se aborda con unequipo de proyecto formado por analistas de proyec-

tos y usuarios, éstos pueden ser profesionales inter-nos destinados completamente al proyecto, consulto-res11 u operadores de los procesos. Un equipo deproyecto puede integrar todas esas posibilidades.

Un aspecto vital es la preparación delequipo de trabajo, no sólo en temas

técnicos y de administración del cambio,sino que también en temas decomunicación, particularmente en cuantoal trabajo en equipo y el profesionalismo.

De hecho, es una práctica regular en empresas conuna larga historia de proyectos exitosos realizar ta-lleres de trabajo en equipo antes, durante y despuésdel proyecto.

Por su importancia, destacan variadas facetas de lacomunicación formal: liderazgo, entrevistas, exposi-ciones, escuchar, coaching, retroalimentación, etc.(son facetas tan importantes que alrededor de untercio de las prácticas transversales las abordan).

2.2. Ideal de la solución

El ideal de la solución se refiere esencialmente aplantear la medición ideal de la variable crítica se-leccionada. Un gran “qué queremos” o desafío.

11 Se gana el “efecto consultor” una mirada externa fresca, lo cual esuna práctica habitual en algunas organizaciones.




Conociendo dónde estamos, ahora se tratade saber adónde vamos… es decir, definir

el alcance de la solución. ¿Qué pretendemos lograr?

Aquí debería quedar planteada la medición idealpara el ámbito de trabajo, por ejemplo, para el áreade abastecimientos, puede ser:

• Disminuir a cero los costos de cada transacción.

• Disponer de inmediato de los insumos.

• Llegar a cero stock de productos en inventario.

• Reducir a cero el tiempo de entrega a los usuariosde los productos

• Disminuir a cero el tiempo de duración de cadacompra.

Suponemos que estas grandes directrices surgieroncomo solución al problema detectado en la etapaanterior.

También surgen de las directrices estratégicas paraun área o de los indicadores que la organización quese ha dado, por ejemplo, en el Balance Scorecard (oBSC, traducido como Cuadro de Mando Integral).

También en esta fase ya es conveniente comenzar apensar en riesgos, por ejemplo: ¿y si nos equivoca-mos? ¿qué riesgos tiene lograr esos objetivos?

Es evidente la importancia de que la dirección parti-cipe en la elaboración de estas directrices.



JUAN BRAVO 92

La idealización juega un rol central porque es conveniente plantearse grandes

sueños.Preguntarnos ¿cuál es la realidad deseable?, en lugarde intentar mejorar lo que existe.

Plantear grandes ideales se puede definir como Lle-var la medición al extremo más positivo de la o lasvariables críticas.

2.3. Planteamiento libre de alternativas

Todavía sin restricciones, la idea es lograr una in-vestigación lo más amplia posible de soluciones po-sibles, pueden ser tan creativas como se quiera, in-cluso no factibles12.

Aquí se deben explorar, entre otras posibilidades, laspropuestas de cambio respecto a:

• Personas: las personas pueden ser potenciadas ylograr así aumentos espectaculares en la producti-vidad. Con liderazgo, educación, colaboración,motivación, autonomía, disciplina, trabajo de

equipo, incentivos, etc...

12 En el método GSP es incluso una obligación plantear al menos un20% de alternativas no factibles, para abrir la mente. Los resultadosson extraordinarios, en el libro Análisis de Sistemas se puede ver

más detalle. Aunque igual son soluciones efectivas que por costo,tecnología, política u otra causa se dejan fuera o se congelan.




• Procesos: ¿debe existir el proceso? ¿Es posibleaplicar generalización? ¿Se puede externalizar el

proceso? Revisión del ciclo completo de procesosdel negocio y otros de apoyo.

Algunas preguntas:¿Una persona puede hacer el procesocompleto?¿Un equipo de personas lo puede hacer?

• Estructura: equilibrios en centralización y des-centralización, cambio y control, funciones y pro-cesos, servicios internos y externalización, espe-cialización y generalización.

También revisión de técnicas: Just-in-time, Kan-ban13, Rightsizing (tamaño justo), etc...

13 Kanban es una forma de modelo inventado en Japón donde, man-teniendo una estructura semiespecializada del proceso, se trabaja dea una pieza a la vez en toda la línea. Si hay una falla, todas las per-sonas en la cadena se detienen y ayudan a corregir el problema. Deesta forma se economizan los inventarios y bodegas intermedias, seeliminan los controladores y revisiones de calidad porque la retroa-

limentación a cada integrante de la línea es inmediata. Para que estesistema funcione es indispensable que cada operario sepa realizarvarias actividades, especialmente las más cercanas a su especialidad.Kanban es un sistema visual que combina la simpleza con la practi-cidad, donde los resultados de cualquier operación se manejan gráfi-ca y manualmente en el mismo puesto de trabajo. Se trata de tenerseñales visuales para la comunicación. Por ejemplo, etiquetas paraproductos en proceso que permiten conocer tanto lo que se hace enun determinado paso como lo que se hace en los pasos anteriores y

siguientes. También se utilizan luces amarillas y rojas para indicarun problema o una detención del trabajo. Pizarras para anotar todoasunto de interés y, sobre todo, tener una visión de conjunto del



JUAN BRAVO 94

• Tecnología: ¿de qué tipo? Por ejemplo, de comu-nicaciones, transporte, almacenamiento, construc-

ción, procesamiento de imágenes, automatizaciónde oficinas, identificación de personas y, por su-puesto, tecnología de información,

¿Es realmente necesario desarrollar software? (es saludable cuestionarse

paradigmas).

Considerar también:

• Revisión del entorno: ¿cómo lo hacen en otroslugares? ¿En otras organizaciones similares?¿Existen soluciones normalizadas (por ejemplo,software de uso generalizado)? Es importante re-visar lo que existe en el medio mediante bench-

marking, publicaciones, ferias, etc.

Conózcase a usted mismo antes deintentar conocer a otros. El“benchmarking” comienza con unacomprensión total de sus propios

productos y procesos organizacionales.

En la mayoría de los casos, someter a “benchmar-king” las actividades de otros cuando usted mis-mo no se entiende, es una pérdida de tiempo. Siusted va a compararse con otra persona, más vale

proceso, para prevenir eventuales problemas en una actividad quellevaran a detenerlo.




que antes se forme un buen juicio de su propiodesempeño14.

• Autosolución: ¿podría el mismo usuario resolversu necesidad? ¿Cuánta capacitación requiere?¿Existe software básico de apoyo?

La lista de soluciones es discutida y presentada a laautoridad para la toma de decisión de cuáles alterna-tivas estudiar en detalle. Normalmente el equipo de

trabajo recomienda algo.Asimismo, recomienda ideales factibles para las va-riables contempladas.

El comité de proyectos decide como sigue el estudiode soluciones.

Aplicar la técnica de visionar Aquí trabajamos con ideales que luego se transfor-man en “ideales factibles”.

Ya en la fase anterior se asociaron valores idealiza-dos a las variables críticas.

a) Por ejemplo, ¿cómo lograr el ideal de que los

clientes tengan cero tiempo de espera para recibirsu producto? una forma puede ser mediante unsistema de teletransporte hacia su casa (como enla película Viaje a las Estrellas)… Es importantedarse permiso para soñar en este paso.

14 SPENDOLINI (1994), p. 244.



JUAN BRAVO 96

Los valores ideales deben ser estudiados para cada caso, por ejemplo, en el caso

del tiempo, puede que el ideal sea unasemana en un proceso de importaciones,versus los tres meses de la situación

actual, se reconoce porque disminuir másel tiempo ya no agrega valor para el

cliente.

b) Obtener un ideal factible para cada variable. Des-de el ideal discutido en la fase anterior, ahoravolvemos a ser “adultos”, serios: ¿qué se puedellevar a cabo?, ¿cómo se hace en otros lugares?…Aquí se trata de “negociar con la realidad” paraobtener un ideal factible (desde el cual se puedenobtener los objetivos). Por ejemplo, estimamos

factible disminuir desde doce a un minuto eltiempo de espera de los clientes frente a la caja.

2.4. Restricciones de la solución

Se trata de indicar con toda precisión aspectos queacotan el universo de posibilidades, por ejemplo, el

costo de la solución no puede superar el costo delproblema o un determinado monto, por restriccionespresupuestarias o porque aparece un costo de opor-tunidad, es decir, pueden existir otros problemas decosto alto con soluciones de costo bajo para la orga-nización que darían más rentabilidad interna a lamisma inversión.




También existirán restricciones estéticas,estratégicas, técnicas, de estandarización

y de otra índole.Surgen en parte de los grupos de interés que no sonclientes. Estas restricciones debieran estar incluidasen el plan de proyecto. Otro ejemplo, un flujo debemantenerse de tal manera porque existe una disposi-ción legal que lo exige.

Existen restricciones tácitas y otras explícitas. Am-bas son igualmente válidas. Por ejemplo, una res-tricción tácita es generar rentabilidad en el ámbitode trabajo del proyecto.

Prácticamente todo grupo de interés puede dar ori-gen a restricciones, por ejemplo:

• La dirección de la organización: espera que elservicio se otorgue conservando un cierto nivel debeneficios.

• La comunidad espera que el rediseño respete elambiente.

• El Estado espera que se respeten las leyes y se

paguen los impuestos debidos.• Los empleados esperan que no haya despidos por

motivo del rediseño.

Hay que armonizar esas restricciones, no sólo en laetapa de factibilidad, sino también a nivel del plande proyecto completo.



JUAN BRAVO 98

Existe un grupo de interés, llamadoclientes, a cuyos intereses no les llamamos

restricciones, sino que hablamos devariables críticas.

Es necesario preguntar ¿qué desean los clientes?Las respuestas pueden ser a nivel de procesos indi-viduales o por grupos de procesos, por ejemplo enel otorgamiento de créditos, el cliente requiere ra-

pidez y baja tasa. La idea es obtener estas respues-tas preguntando directamente y no suponiendo.

De las restricciones a la solución surgen Factores de Decisión.

Á Según libro “Desarrollo de sistemas de informa-ción, una visión práctica”, sección 2.2.

2.5. Selección de alternativas y objetivosgenerales

El objetivo es afinar objetivos y seleccionar una listacorta de soluciones factibles.

Considerando el barrido de soluciones y

las restricciones, el comité de proyectosselecciona un pequeño conjunto dealternativas (2 ó 3 generalmente) queserán evaluadas en detalle.

Asimismo, el nivel del avance ya permite definirobjetivos generales del proyecto (un avance más

desde los ideales factibles propuestos).




El comité de proyectos encarga a un equipo la eva-luación detallada de cada alternativa seleccionada.

Incluso podría encargar a personas o equipos dife-rentes cada opción y ganar el efecto de competencia(aunque con el riesgo que ganar resulte más impor-tante que tener la mejor alternativa).

2.6. Evaluación de cada alternativa

Cada alternativa evaluada debiera llevar su propioplan de desarrollo y mantenimiento. Además cadauna debiera incluir los costos y beneficios durantetodo su ciclo de vida estimado, no sólo durante eldesarrollo del proyecto.

Á En el libro Desarrollo de sistemas de información,una visión práctica, sección 2.2 y anexo 2 se in-cluye una forma de realizar la evaluación econó-mica. También en el libro Gestión de Procesos,etapa de factibilidad .

Algunas consideraciones: ¿está balanceada la cargade trabajo en los nuevos cargos? ¿La estructura es laapropiada al proceso? ¿Existe integralidad? ¿La tec-

nología es la adecuada?…En relación a costos, es importante

contemplar que en promedio lasinversiones tienden a nivelarse en los

cinco elementos del modelo integral delcambio: estrategia, personas, procesos,estructura organizacional y tecnología



JUAN BRAVO 100

2.7. Evaluación comparativa

Para cooperar en hacer una buena decisión conviene

aplicar los factores de decisión.

Identificación de factores de decisión

Esta es una forma de hacer visible los criterios másimportantes para la toma de decisiones, por ejemplo,los factores de decisión pueden ser:

• Impacto en los objetivos propuestos• Avance previo• Aporte social• Costo/beneficio de la solución• Imagen frente a clientes

Estos factores de decisión son sólo un ejemplo, por-

que cada organización debe determinar sus propioscriterios para fijar prioridades.

Asignar un peso a cada factor de decisión

Se trata de asignar un “peso” a cada factor de deci-sión, un porcentaje que indique su grado de influen-

cia en la decisión final, por ejemplo:Factor de decisión Palabra clave “Peso”Impacto en los objetivos propuestosAvance previo del trabajo de rediseñoAporte social del trabajo de rediseñoCosto/beneficio de la soluciónImagen frente a clientes

ImpactoAvanceSocialContribuciónImagen

40 %20 %15 %15 %10 %

TOTAL 100 %




Evaluación comparativa entre procesos

Luego se procede a un estudio comparativo entre las

soluciones propuestas, tal como se muestra en elejemplo de procesos en un banco tomado desde ellibro Gestión de Procesos.

Cada factor de decisión se evaluó con una nota de 1a 5 en cada proceso. Asignar 1 es baja prioridad(quedaría hacia el final de la lista) y 5 es alta priori-

dad.Luego se calcula la nota final ponderada, la cualsurge de la siguiente fórmula general para cada pro-ceso:

Nota final ponderada (NF) = Σ (Nota del factor xpeso del factor)

Procesos segmen-tados

Factores de decisión

Im-pacto(.4)

Avan-ce

(.2)

So-cial(.15)

Contri-bu-ción

(.15)

Ima-gen(.1)

Notafinal

1. Apertura cuentasbipersonales

5 4 2 4 2 3.9

2. Entrega de libretasde ahorro

4 3 4 2 2 3.3

3. Apertura cuentaspersonales

5 2 1 3 2 3.2

4. Confecciónlibretas de ahorro

3 1 2 5 4 2.9

5. Captación dedepósitos

1 2 1 1 2 1.3



JUAN BRAVO 102

Más simple, para cada proceso y en este caso especí-fico:

NF = nota impacto x .4 + nota avance x .2 + nota social x .15+ nota contribución x .15 + nota imagen x .1

Para mayor claridad, veamos el cálculo para el pro-ceso que quedó en primer lugar, apertura de cuentasbipersonales:

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 cálculos, la lista se ordena demayor a menor.

El informe de Evaluación comparativa de solucioneses una exigencia en este método.

2.8. Decide la opción y objetivos específicos

El comité de proyectos decide un camino, puede serdirectamente una de las alternativas o puede ser unamezcla que además incorpore elementos no contem-plados en ninguna de las opciones.

Lo más probable es que la toma de decisión sea másbien un proceso iterativo que una acción inmediatacon base en la primera versión del estudio compara-tivo de soluciones. Es frecuente que se pidan preci-siones, nuevas alternativas y cambios.

Con el mayor conocimiento de lanecesidad y de las soluciones, ya se




pueden plantear además los objetivosespecíficos del proyecto.

Más bien, lo que concretamente se espera lograr decada variable crítica (o indicador relevante).

El comité de proyectos encarga a un equipo la elabo-ración del plan de proyecto.

2.9. El plan de proyectoEl plan de proyecto es el detalle de todas las activi-dades del proyecto.

No confundir el plan de la etapa de factibilidad conel plan de proyecto, el cual se refiere a las activida-des de todo el proyecto, desde el análisis hasta laoperación.

El plan de proyecto considera tanto las actividadesde cada etapa como las prácticas transversales de losproyectos.

En realidad el plan de proyecto no es un plan, sinoque es un conjunto de planes, cuyo objeto más visi-ble es la Carta Gantt detallada.

Lo aprueba el comité de proyectos y los usuarios.

Luego, sólo faltaría poner de fecha de inicio y com-prometer los recursos (aunque por el solo hecho dehacer este estudio ya existe un compromiso tácito ysobre todo una expectativa, no realizar el proyecto a



JUAN BRAVO 104

estas alturas tendría altos costos para la organiza-ción15).

Costo del proyecto

Por supuesto, el plan de proyecto incluyela primera estimación de costos del

proyecto

Por otra parte, la estimación del costo fue perfeccio-nado desde la evaluación individual y comparativade la alternativa.

Las siguientes estimaciones se obtienen al final delas etapas de análisis y de diseño.

Durante las etapas de implementación y desplieguese calculan los costos reales y se comparan con lasestimaciones, esto será parte del informe de retroa-limentación de estas etapas y del proyecto completo.

Es similar a lo que plantea Hernán de Solminihac16 en su clase de gestión de costos, donde identificacuatro estimaciones de costos:

• Estimación preliminar o de orden de magnitud ,realizada durante la etapa de evaluación econó-mica.

15 Tiene que ver con el rol del observador, quién, por el sólo hechode observar, cambia el sistema observado (en el libro Análisis de

Sistemas mayor detalle).16 Clase ejecutiva de El Mercurio, “La gestión de costos de proyec-tos” (B11, 13/10/2005)




• Estimación conceptual, realizada por el dueñopara presupuesto.

• Estimación detallada, realizada cuando se cuentacon un diseño detallado.• Estimación definitiva, es una actualización de la

estimación detallada con énfasis en costos actua-les más que en costos proyectados.



JUAN BRAVO 106

ETAPA 3. ANÁLISIS

Lo que da origen a esta etapa es el Plan de proyectoactualizado y la autorización del inicio del comité deproyectos. Es el inicio de la ejecución del proyecto.

El objetivo es plantear el modelo integral del cambioy los requerimientos correspondientes, el Qué .

Entregable de la etapa: el modelo integral del cam-

bio de la solución.~§~

Se trata del análisis integral de la solución. Tambiénes llamada Ingeniería Básica, Ingeniería Conceptual o Arquitectura de la solución.

En particular para los proyectos de GPPT, desde

aquí surgen las definiciones de los procesos y de latecnología de información.

El modelo integral del cambio es la visiónintegral de la solución y se apoya en unconcepto o idea fuerza. Debe estar bien

sustentado en la estrategia de la

organización.

Se trabaja en el modelo integral del cambio de lasolución. Recuérdese la metáfora de una mesa: lacubierta es la estrategia y las 4 patas son: personas,procesos, estructura organizacional y tecnología.

Se comienza por el modelamiento de procesos, enparticular empleando las técnicas mapa de procesos




y flujogramas de información, desde donde surgenlas demás definiciones, hacia las personas, la estruc-

tura y la tecnología.Los requerimientos hacia la tecnología son de dife-rente tipo, desde comunicaciones hasta apoyo físicotal como movimiento automatizado de carga. Sinembargo, nos concentraremos aquí en la TI, especí-ficamente en las actividades que tienen algún nivelde apoyo de TI, por eso desde esta etapa se habla

también de “aplicación” o “sistema computacional”,donde comienzan a aparecer elementos tales como:entorno tecnológico, identificación de usuarios, sis-tema de codificación, diagramas de casos de uso,modelo conceptual y otros modelos.

A diferencia del trabajo en la etapa de

factibilidad, más bien general y destinado principalmente a cuantificar el volumen ytipo de trabajo, en esta etapa el trabajo esminucioso, porque las definiciones que deaquí se obtengan darán forma definitiva ala solución.

Inicio de la etapa

Tal como indican varias de las prácticas transversa-les, se revisa si la solución que se obtuvo desde laetapa de factibilidad sigue siendo válida, de hechosucede a veces que el trabajo de análisis comienzatiempo después del estudio de factibilidad y algopodría haber cambiado.



JUAN BRAVO 108

A veces, esto puede dar origen a un replanteamientode la solución y una nueva aprobación, especialmen-

te si es necesario replantear costos y plazos.Es importante el trabajo minucioso en esta revisión,porque un riesgo con una probabilidad alta de ocu-rrencia es comenzar de cero, como si nada se hubie-ra hecho antes. No se trata solamente de un proble-ma en el contexto de los proyectos GPPT, tambiénocurre, por ejemplo, en las empresas constructoras,

cuando el ingeniero a cargo, a quien se le acaba deasignar una obra adjudicada, ignora la propuesta quehizo 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 primerasactividades del plan de proyecto.

Una de ellas es la ceremonia de inicio,que ojalá cuente con la presencia de las

más 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 visión integralde la solución. Debe estar bien sustentado en la es-trategia de la organización. Ya indicamos que separece a una mesa…




Un proyecto de cambio puede representarse comouna mesa, donde la cubierta es la estrategia y lospilares son las personas, procesos, estructura y tec-nología. El mensaje es armonía en estos medios.

El modelo integral del cambio es un todo integralque debe ser bien conocido por todo el equipo deproyecto.

Puede ser desde un solo analista quien, junto con unusuario, concibe el modelo hasta un equipo de traba-

jo de decenas de personas donde cada uno tiene lavisión de este todo.

3.2. Estrategia

Por estrategia nos referimos a:

• Un concepto o idea fuerza que guíe la solu-ción. Tal como la integralidad en el caso de lasolución Vendedor Integral de grandes tien-das, la transparencia en una solución arqui-tectónica o el humor y personificar en la

campaña comercial ¿Se te apareció marzo?

Estructura

Personas

Procesos

Personas

Procesos

Tecnología

Estrategia



JUAN BRAVO 110

• Existencia de definiciones estratégicas corpo-rativas y para el proyecto específico.

• Existencia de una estrategia de la solución.• Detalles de alineamiento de la solución con la

estrategia de la organización.

Es importante destacar que el proyecto debe estarsustentado en la estrategia de la Compañía (fue fun-damental en la etapa anterior para darle el pase al

proyecto).

En esta etapa la estrategia de laCompañía es la guía principal para

proponer el modelo integral del cambio.

3.3. Personas¿Qué sucede con las personas en el modelo integraldel cambio para este proyecto? ¿Cómo aportan?¿Cómo se capacitan? ¿Cuál es la gestión del cam-bio?

Hablamos de competencias del equipo de trabajo y

de quienes usarán la solución en: sensibilización,capacitación, anticipación, participación, ambientede trabajo, formas de interacción, etc.

Se requieren planes orientados al equipo de trabajo ya los usuarios de la solución, eventualmente inclusode los clientes.

Trabajar con las personas considera dos aspectosvitales:




• La cultura de la organización (lo que no se ve):formas de relación, comunicación, tradiciones,

creencias, etc.• La infraestructura (lo que se ve): edificios, colo-res, aromas, etc.

Anticipación

Cuanto antes se inicie un proceso de comunicacióndirigido a todas las personas que ahí se desempeñanes mejor. La transparencia, honestidad, informaciónoportuna y participación son esenciales en la crea-ción de un clima adecuado al cambio.

Es vital la participación de las jefaturasen la difusión del proyecto. Esto nos llevaa que es necesario comenzar el proceso deanticipación desde las jefaturas.

En esta etapa temprana del proyecto, el objetivo nosólo es comunicar, sino que también solicitar elaporte de los involucrados en la forma de ideas.

3.4. Gestión de ProcesosTodo comienza desde un modelamiento de los pro-cesos, suponiendo que antes se hizo algún nivel delevantamiento de lo que existe.

Se requiere la descripción del nuevo flujo de trabajoy de los procesos relacionados, ya sean del negocio

o de apoyo involucrados en el ámbito de trabajo delproyecto.



JUAN BRAVO 112

Las técnicas principales que se emplean son el mapade procesos y el flujograma de información.

Mapa de procesos.

Es un tema tan importante que en las organizacionesmás avanzadas tienen un mapa de procesos de todala organización. Generalmente emplean herramien-tas de apoyo bastante robustas (M1, Aris, CorporateModeler, etc.)

Por ejemplo, para una empresa comercial, una partedel mapa de procesos se vería así:

CuadrarDespacharVender

Programar Entregar

Inmediato

A Crédito

Al Contado

A domicilio

Vender al detalle

Mapa de Procesos Venta Integral. Se aprecia que el macropro-cesos: vender al detalle se abre en una jerarquía donde hay otros

macroprocesos y procesos operativos. Y así sucesivamente.

Todo mapa de procesos debe iniciarse con los requi-

sitos que impone el cliente y debe finalizar conside-rando el grado de satisfacción logrado por ellos a




través de la implementación de los procesos de laempresa.

Flujograma de Información (FI)

Junto con el mapa de procesos se emplea la técnicade flujogramas de información17 para detallar losprocesos operativos más relevantes de la organiza-ción cuando la descripción está centralizada o sonparte del proyecto de solución.

Es importante contemplar algunas características delflujograma de información:

Sigue el criterio: SPPP (Simplificar Procesos y Potenciar Personas) dejandode lado la antigua, peyorativa e inútil

pretensión 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, principal-

mente a los usuarios operativos, para quienesdebería ser autoexplicativo.• No es un diagrama de flujo computacional

17 Más detalle en los anexos del libro Gestión de Procesos (si ustedsabía acerca de procesos pero no ha renovado su conocimiento,

digamos los últimos cinco años, es conveniente una nueva inmer-sión, el cambio ha sido grande en esta materia).



JUAN BRAVO 114

• Debe caber en una página con letra de tama-ño legible.

• Las actividades con doble línea tienen algunarelación con la TI y luego dan origen a los ca-sos de uso

Por ejemplo:

CLIENTE BODEGA FINANZAS

ADMINISTRATIVO DE BODEGA DESPACHADOR

PROCESO DESPACHOINMEDIATO

GD3’

OE

GD4

GD3GD2

GD1

GD4OE

Buscarproducto

GD’s

Clienterecibey firmarecepción

GD1’

Reservar yemitir GD

Rebajarsaldo

GD2’

OE: Orden de Entrega, GD: Guía de Despacho

PROCESOCUADRAR

PROCESOSVENDER

Nota: los números en los recuadros punteados señalan tiempos:

duración de las actividades y, entremedio, tiempos de reposo de latransacción.

OE: Orden de Entrega, GD: Guía de Despacho

Si se está utilizando el desarrollo en espiral, el deta-lle a nivel de los flujogramas de información podríaser parte de cada iteración. El mapa de procesos de-bería estar construido desde el principio y solamente




se realizarían perfeccionamientos en cada vuelta dela espiral.

Diseño de formularios

Se debe realizar el diseño de formularios asociadosal detalle de los flujogramas de información. Válidopara formularios manuales o computacionales.

El diseño de formularios18 sigue algunas normas:

• Numeración• Facilidad de uso• Orientación al cliente• Cantidad de información requerida• Normalización y estandarización• Posiciones fijas

Relación del Flujograma de Información con latécnica UML

Uno de los aspectos metodológicos y de investiga-ción más interesantes es el hecho de buscar un puntode encuentro entre dos técnicas de amplio uso: losFlujogramas de Información y UML.

Específicamente ese punto de encuentro está en lasactividades con alguna interacción computacionaldel flujograma de información, las cuales dan origena los casos de uso del sistema computacional.

18

El diseño de formularios es una materia incluida en el libro Desa-rrollo de sistemas de información, una visión práctica. También enel libro Gestión de Procesos, capítulo 11.



JUAN BRAVO 116

En concreto, cada actividad de tipo computacionaldebe dar origen a uno y sólo un caso de uso.

En la figura se aprecia este punto de encuentro, don-de se tomó como ejemplo la actividad Rebajar saldo del FI recién propuesto.

En la figura:

• El actor es el despachador, nombre tomado desde

el encabezado de la columna donde está la acti-vidad del FI.

Reba ar saldo

Rebajar saldo

Usa el lector para leer elcódigo de barras de

cada producto que sale.

En el sistema se rebajael saldo del producto.

Terminal en BodegaDespachador

Relación del FI con el caso de uso. La actividad rebajar saldo

del flujograma de información se transforma en un caso de uso de

alto nivel, uno de los modelos del estándar UML.




• El caso de uso es “Rebajar saldo”, puesto en in-finitivo porque refleja una acción.

• El caso de uso de esta figura es del tipo “altonivel” porque la descripción es general.• La situación ocurre en un dominio, el terminal de

la bodega en este caso, e incluye los accesorios,tal como el lector de código de barras.

Una recomendación metodológica es unir en un“Diagrama de casos de uso” (una forma de agrupa-ción de casos de uso que veremos luego) los casosde uso de cada proceso operativo (o flujograma deinformación).

3.5. Estructura

Se refiere a la definición de la nueva estructura or-ganizacional desde la mirada que aporta el modela-miento de los procesos. También a los requerimien-tos de infraestructura física.

Los cambios van más allá que solamente crear oeliminar cargos (agregar, mover o sacar cajas delorganigrama), alcanzan también a: planes y propues-

tas detalladas de externalización, delegación, trabajoen equipo, empoderamiento, más o menos supervi-sión, JIT, Kanban, etc.

Hemos acuñado el dicho: “un pterodáctilo no es unamariposa grande”, en el sentido que tienen una es-tructura muy diferente y apropiada a su tamaño.

Quiere decir que al crecer o cambiar, la organizacióndebe contemplar otra estructura. La estructura de



JUAN BRAVO 118

mariposa permite un tamaño hasta menos de 20centímetros porque no hay huesos, solamente liga-

mentos, el pterodáctilo tiene toda una estructuraósea que ya sabemos lo fuerte que es, porque se con-serva hasta hoy la de algunos ejemplares que vivie-ron 100 millones de años atrás.

No se trata de agregar más personas a procesos que crecen, son diferentes.

En este texto no se profundiza en la estructura orga-nizacional, lo cual no significa que sea menos im-portante.

3.6. Tecnología

En cuanto a la tecnología no informática, se requie-ren planes para la incorporación o adaptación de lastecnologías consideradas en el proyecto, tales comoelementos de comunicación, transporte, almacena-miento, construcción, despacho, automatización deoficinas, telefonía interna, etc. Debiera incluir preci-siones de propuestas, contratos, capacitación y, en

general, formas de implementación.Respecto a la tecnología de información, lo veremosen los siguientes puntos.

3.7. Visión global de la solución

El modelo integral del cambio aporta una solución

integral, la mesa.




Sucede a veces que el punto de partida de un proyec-to es la definición de una necesidad computacional.

En tal caso ocurre con bastante frecuencia que noexistan otros profesionales para desarrollar las ramasde personas, procesos y estructura organizacionalque contempla la solución integral. En tal caso, losmismos analistas encargados del desarrollo compu-tacional del sistema de información deberían encar-garse del desarrollo completo del modelo integral

del cambio… entonces cobra especial relevancia laformación del analista de sistemas19.

Un analista de sistemas debiera tener lacapacidad de trabajar en “la mesa”completa.

Otro aspecto es la necesaria coordinación entre lasactividades de cada elemento de la solución, se re-quiere una malla completa (CPM, Gantt o algunaherramienta computacional de apoyo en administra-ción de proyectos) que permita visualizar el proyectointegral y resolver aspectos de precedencia, holguray ruta crítica.

3.8. Ingeniería de requerimientos

Habiendo planteado el modelo integral del cambio,se especifican requerimientos en cuatro ámbitosprincipales: personas, procesos, estructura organiza-cional y tecnología, porque serán los que llevarán

19 Ver libro Análisis de Sistemas.



JUAN BRAVO 120

adelante el cambio. Son diferentes ramas de la solu-ción. Por supuesto, trabajar en estos ámbitos no ex-

cluye el trabajo en otras materias funcionales o dedesarrollo, tal como finanzas, marketing, logística,etc. Son ámbitos relacionados que deberían estarcontemplados en el proyecto. Es vital la coordina-ción entre los equipos de trabajo que los aborden.

El inicio del planteamiento de

requerimientos supone conocida laestrategia del proyecto y de la empresa yque ambas están alineadas.

Se definen requerimientos para:

1. Personas: Planes detallados de selección, prepa-ración, capacitación, anticipación, participación,

ambiente de trabajo, formas de interacción, etc.2. Procesos: Descripción del nuevo flujo de trabajodel o los procesos relacionados.

3. Estructura: Detalle de la nueva estructura organi-zacional, planes y propuestas detalladas de exter-nalización, delegación, trabajo en equipo, etc.

4. Tecnología: definiciones de procesamiento de

datos, comunicación, transporte, almacenamiento,construcción, despacho, automatización de ofici-nas, telefonía interna, etc. y, en especial, con latecnología de información. Se efectúan medicio-nes de dimensionamiento para la incorporacióndel número previsto de usuarios.

Todo comienza desde la rama de los procesos.




Se incluye detalle de la rama tecnológica utilizandoUML.

3.9. Definiciones de la TI

Se plantean detalladamente aquí las definiciones dela tecnología de información propias del sistema deinformación en desarrollo, más bien de la partecomputacional del sistema de información, por eso

desde esta fase en adelante se habla también de sis-tema computacional.

Es recomendable incorporar aquí algunos de losaprendizajes de ITIL (ver anexo 8).

3.10. Entorno Tecnológico

Se requiere el dimensionamiento de equipos compu-tacionales, software y comunicación. Esto significaincluir mapas de la arquitectura de redes y de comu-nicación.

Es cierto que el análisis y el diseño son independien-tes de la implementación tecnológica, también es

cierto que los sistemas se ubican en un cierto con-texto.

Las definiciones principales del entorno tecnológicodeberían venir desde la etapa de factibilidad, espe-cialmente si tenían algún impacto en el costo delsistema.



JUAN BRAVO 122

El entorno tecnológico contempla todo lorelativo a la disponibilidad de las

herramientas de software y hardware, talcomo preparación de propuestas ycontratos, plan de adquisición,

financiamiento, etc.

Debe revisarse al menos:

• Arquitectura de software

• Arquitectura de hardware• Herramientas de programación• Herramientas de verificación de código• Herramientas de control de versiones

3.11. Supuestos

Indicar aquellas cosas cuya verdad se supone, porejemplo:

• La gerencia de personal asignará espacio físicopara la realización de la capacitación.

• El departamento de informática proveerá losequipos necesarios en el plazo convenido.

• La gerencia comercial tendrá disponible a unapersona clave en tal fecha.

En el fondo, se trata de identificar afirmaciones quetienen algún nivel de riesgo, para tomar las medidascorrespondientes. Recuérdese que “si algo puedefallar, fallará”.

En esta etapa el nivel de negociación es amplio. Selogran consensos, acuerdos y compromisos para ser




cumplidos en la etapa de implementación, la cualestá muy lejos todavía. Sucede a veces que las per-

sonas tienen dificultades con los compromisos y almomento de implementar es necesario entrar a otroproceso de negociación. Por ejemplo, la persona queel gerente comercial había comprometido para elpróximo mes fue destinada a ciertas labores urgentesy ya no está disponible… Y también al exterior, co-mo cuando se ofrece un producto o una tecnología

para tal fecha y no llega…En la etapa de análisis debemos hacer explícitos los acuerdos logrados, porqueson parte integral de la solución.

En fin, esta es la realidad del trabajo en las organi-zaciones y para facilitar las negociaciones es prefe-rible dejar explícitos los supuestos y tener algún ni-vel de plan de contingencia.

3.12. Identificación de los usuarios

Se debe identificar a todos los usuarios, sean directos

o indirectos. Ejecutivos o Profesionales. Internos oexternos.

También los usuarios operativos, es decir, quienesdeberán hacer cambios en sus rutinas de trabajo, los“afectados” con la aplicación.



JUAN BRAVO 124

3.13. Sistema de codificación

Es totalmente aplicable lo indicado en el libro Desa-

rrollo de sistemas de información, una visión prácti-ca, páginas 68 a 72. Esencialmente trabajar con códi-gos estándares como el RUT o el código de barras deproductos de supermercado y si no es posible, con uncódigo numérico lo más simple posible. Como últimaopción y si realmente se justifica (el autor no lo havisto hasta hoy) utilizar un código compuesto.

3.14. Requerimientos computacionales

En lo que se refiere a la definición de requerimientospara un sistema computacional, utilizaremos aquí varios diagramas de UML (Unified Modeling Lan-guage / lenguaje unificado de modelamiento):

Planteados en el espíritu de este métodode trabajar con el mínimo indispensable,

para que efectivamente pueda ser aplicadoen la mayoría 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• Visión dinámica del sistema• Diagrama de estado• Contrato




Á Mayor información y otros diagramas de UML sepueden encontrar en los anexos 2 y 3, acerca deUML y RUP, respectivamente.

Nótese que este método no trata en profundidad acerca de UML, sino quesolamente toma lo necesario para aplicar en el método genérico de desarrollo deSistemas de Información aquí expuesto.

Su uso se restringe a la especificación de requeri-mientos para fines del desarrollo de sistemas compu-tacionales, aún conociendo que también podríanaplicarse a representar realidades con otros fines.

En consecuencia y al igual que otras materias, ladescripción de UML contenida en este método esbreve.

Los modelos indicados se describen a continuación:

3.15. Diagrama de casos de uso

El diagrama de casos de uso representa una agrupa-ción de casos de uso, por ejemplo, todos los casos de

uso que tienen relación con un proceso incluido enel flujograma de información.

En él cada actor puede interactuar con más de uncaso de uso.



JUAN BRAVO 126

En el ejemplo se presenta un Diagrama de Casos deUso para un ámbito de adquisiciones20.

3.16. Caso de uso de alto nivelLos casos de uso de alto nivel incluyen a un actor ovarios actores (que pueden ser personas u otros sis-temas computacionales identificados con el símbolotipo dibujo de niño), también un dominio (en este

20 Cuando se realizan talleres del método, un ejercicio típico paraeste diagrama es solicitar construir un FI y un Mapa de Procesos.

Ejemplo de un Diagrama de Casos de UsoEjemplo de un Diagrama de Casos de Uso deldel

área de Adquisiciones (O/C=Orden de Compraárea de Adquisiciones (O/C=Orden de CompraEjemplo de un Diagrama de Casos de UsoEjemplo de un Diagrama de Casos de Uso deldel

área de Adquisiciones (O/C=Orden de Compraárea de Adquisiciones (O/C=Orden de Compra)

Administrativo deAdministrativo de

Cotizar

Terminales del área de Adquisiciones

Jefe deAdquisiciones

Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C

Cotizar



Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C

Ejemplo de un Diagrama de Casos de UsoEjemplo de un Diagrama de Casos de Uso deldel

área de Adquisiciones (O/C=Orden de Compraárea de Adquisiciones (O/C=Orden de CompraEjemplo de un Diagrama de Casos de UsoEjemplo de un Diagrama de Casos de Uso deldel

área de Adquisiciones (O/C=Orden de Compraárea de Adquisiciones (O/C=Orden de Compra)


Cotizar



Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C

Cotizar



Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C


Cotizar



Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C

Cotizar



Adquisiciones

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C

Cotizador

Aprobarcotización

Enviar O/C

AprobarO/C

Ingresar O/C




caso el terminal en bodega), una acción con un ver-bo en infinitivo en el óvalo y una descripción breve

de la situación bajo el óvalo..El caso de uso de alto nivel se caracteriza porque lanarración es breve. Permite conocer un poco del re-querimiento, algo de la acción, actor(es) y dominio.

Al trabajar con desarrollo en espiral, se espera que eluniverso completo de casos de uso esté descrito enalto nivel o como diagramas de casos de uso.

Entonces, los casos de uso seleccionados para larespectiva vuelta de la espiral se transforman en ca-sos de uso expandidos.

Ejemplo de caso de uso de alto nivelEjemplo de caso de uso de alto nivel

Ingresar Orden de Compra (O/C)Ingresar Orden de Compra (O/C)

Ingresar O/C

Ingresa la Orden de Compra apartir de los documentos decotización a proveedores,

La O/C queda disponible paraser enviada al proveedor luegode aprobación electrónica por el

jefe de Adquisiciones

Terminal en bodega

Administrativo deAdquisiciones


Ingresar Orden de Compra (O/C)Ingresar Orden de Compra (O/C)

Ingresar O/C

Ingresa la Orden de Compra apartir de los documentos decotización a proveedores,

La O/C queda disponible paraser enviada al proveedor luegode aprobación electrónica por el

jefe de Adquisiciones

Terminal en bodega

Administrativo deAdquisiciones



JUAN BRAVO 128

3.17. Caso de uso expandido

El caso de uso expandido incluye una narración en

todo detalle e incluye las interfaces visuales. Re-cuérdese que se usa aquí el concepto de “curso nor-mal de los eventos”, las excepciones se anotan alfinal para no romper la secuencia de la historia.

Por ejemplo, “Ingresar O/C” (Orden de Compra):

Las letras (A, B…) entre paréntesis identifican la ubicación

del respectivo campo en la interfase visual.

Acción del actor:1. Tomar la O/C desde el archivador2. Ingresar Nº O/C en (A)

3. Ingresar Rut en (D)6...Para cada línea:

7. Ingresar el código de productoen (H)

9. Ingresar las unidades en (K)10. Dar OK a la línea

...

Ingresar O/C

Caso de uso expandido Terminal del Administrativo de Adquisiciones

Administrativo de

Adquisiciones

Respuesta del sistema...3. Verifica correlativo y envía respuesta en (B)5. Verifica que proveedor exista, obtiene ydespliega nombre y fono en (E) y (F)Para cada línea:

8. Verifica existencia del producto, obtieney despliega la descripción y el precio en (I)

y (J)10. Calcula el subtotal y despliega en (L)11....

...

Resumen: (el mismo del caso de uso de alto nivel). Funciones relacionadas: ...Curso Normal de los eventos

Excepciones: 1. Si el número de O/C ya existe, vea caso de uso “Corregir Correlativo”. 2...Adjunta: Interfaces detalladas de E/S

Acción del actor:1. Tomar la O/C desde el archivador2. Ingresar Nº O/C en (A)

3. Ingresar Rut en (D)6...Para cada línea:

7. Ingresar el código de productoen (H)

9. Ingresar las unidades en (K)10. Dar OK a la línea

...

Ingresar O/C

Caso de uso expandido Terminal del Administrativo de Adquisiciones

Administrativo de

Adquisiciones

Respuesta del sistema...3. Verifica correlativo y envía respuesta en (B)5. Verifica que proveedor exista, obtiene ydespliega nombre y fono en (E) y (F)Para cada línea:

8. Verifica existencia del producto, obtieney despliega la descripción y el precio en (I)

y (J)10. Calcula el subtotal y despliega en (L)11....

...

Resumen: (el mismo del caso de uso de alto nivel). Funciones relacionadas: ...Curso Normal de los eventos

Excepciones: 1. Si el número de O/C ya existe, vea caso de uso “Corregir Correlativo”. 2...Adjunta: Interfaces detalladas de E/S




Tiene dos columnas: acción del actor y respuesta delsistema, las excepciones van aparte. No siempre una

acción del actor tiene respuesta del sistema, como laacción 1: “Tomar la O/C desde el archivador” (queestá en algún mueble cercano).

El caso de uso se complementa con una copia deldocumento Orden de Compra (O/C) y de la Interfazde la pantalla, donde los campos se indican con le-tras mayúsculas.

3.18. Modelo Conceptual

El modelo conceptual define responsabilidades y eldominio del sistema computacional, al comienzoasociado a los casos de uso identificados. Es un mo-delo que se va construyendo en paralelo con los ca-sos de uso.

Identifica los conceptos más relevantes del mundoreal en el dominio respectivo: roles de personas, ti-pos de documentos, elementos físicos, etc. Tambiénidentifica las asociaciones entre conceptos con pala-bras de enlace: usa, registra en, almacenado en, pa-

gado por, contenida en… Se trazan líneas entre losconceptos para representar este detalle.

En esta etapa, una recomendación es incorporar enel modelo el máximo de conceptos y el mínimo deasociaciones.

Las características del modelo conceptual son muy

similares al modelamiento tradicional de datos.



JUAN BRAVO 130

En las asociaciones entre los conceptos se da multi-plicidad o cardinalidad.

Se expresa de la siguiente forma:* : cero o más (muchos)1..* : uno o más1..12 : de uno a doce3 : exactamente 32, 4, 9 : exactamente 2, 4 ó 9

Siguiendo con nuestro ejemplo de la Orden de com-pra, el modelo conceptual tendría esta forma:

Ejemplo de Modelo Conceptual,Ejemplo de Modelo Conceptual,

conceptos y asociacionesconceptos y asociaciones

Encabezadode O/C

Proveedores

Líneas de laO/C

Productos

* 1

* 1

1

1..*

Bodega

*

1

compuesta por

se asocia a

contiene

existe en contiene

existe en

existe en

almacena




Se puede apreciar que:

• Una O/C está compuesta por 1 ó más líneas de

O/C. A su vez, una línea de O/C se asocia a unsolo encabezado de O/C.

• Un encabezado de O/C contiene un proveedor.Un proveedor existe en 0 ó más encabezados deO/C.

• Una línea de O/C contiene un producto. Un pro-

ducto existe en 0 ó más líneas de O/C.• Un producto existe en 1 bodega. Una bodega

almacena 0 ó más productos.

Obsérvese que aparece, con un rombo negro, unaasociación de composición, equivalente a la relaciónde pertenencia (que se marca con una línea más

gruesa) del modelamiento de datos21. En la compo-sición, también llamada unicidad, una línea de laO/C no puede existir sin su encabezado, y viceversa.

21 Ver libro La Nueva Visión, Diseño y Construcción de SistemasComputacionales.



JUAN BRAVO 132

En los conceptos también existen atributos, tal comose aprecia en el siguiente modelo:

Ejemplo de Modelo Conceptual,Ejemplo de Modelo Conceptual,

conceptos, asociaciones y atributosconceptos, asociaciones y atributos

Líneas de laO/C

unidades

precio

Productos...

Bodega...

Encabezadode O/CNº O/C

Fecha

ProveedoresRut

Nombre

1

1..*

compuesta por

se asocia a

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena

3.19. Diagrama de secuencia del sistema

El objetivo del diagrama de secuencia es identificar lasoperaciones del sistema, las que luego darán origen a

los mensajes y en general, al protocolo del sistema.Con base en la narración realizada en el caso de uso, seidentifican las operaciones del sistema, aquellas queobligarán al sistema computacional a hacer algo y queafectarán a uno o más conceptos de aquellos incluidosen el modelo conceptual.

En la siguiente figura se muestra la forma generaldel diagrama de secuencia para un caso de uso don-




de se está ingresando una Orden de Compra (O/C).Suponemos que se obtuvieron esas operaciones des-

de la narración del caso de uso.

¿Qué es una operación? Una operación es un men-

saje, un mandato para que algo se ejecute, provocaque algo suceda fuera de la frontera del caso de uso.

Al principio el sistema computacional se ve comouna caja negra (todo el sistema está representado porla columna Sistema). Sin embargo, en la medida quese avanza en el detalle de los requerimientos, la co-lumna Sistema se abre en otras: los conceptos, pro-

duciéndose una estructura de mensajes.

A

Diagrama de Secuencia para el caso de uso Ingresar O/C

Ingresar Nº de O/C

Dar OK a la línea

Ingresar código de prod.

Sistema como una caja negra

Actor

Administrativo Sistema

Nota: con esta letra se hacen aclaraciones

al diagrama

Repetir hastaque no haya másproductos

Operación (o mensaje)que activa una o más

funciones en el sistema

Ingresar cantidad

A

Diagrama de Secuencia para el caso de uso Ingresar O/C

Ingresar Nº de O/C

Dar OK a la línea

Ingresar código de prod.

Sistema como una caja negra

Actor

Administrativo Sistema

Nota: con esta letra se hacen aclaraciones

al diagrama

Repetir hastaque no haya másproductos

Operación (o mensaje)que activa una o más

funciones en el sistema

Ingresar cantidad



JUAN BRAVO 134

3.20. Visión dinámica del sistema

Este diagrama es un resumen de las operaciones del

sistema, la gráfica sugiere que al unir esta funciona-lidad con el modelo conceptual, lograremos algocentral de la orientación a objetos22: el encapsula-miento, es decir, tener en un sólo todo (clase u obje-to) tanto los atributos como los métodos. Está bien,pero estas son llamadas o mensajes que llegaránprobablemente a varios conceptos (o clases).

Notas:

1. Las operaciones del sistema y el diagrama de secuenciason uno a uno con el caso de uso.

2. Tanto el diagrama de secuencia como la visión dinámicadel sistema tienen las mismas operaciones, más bien lla-

22

Ver libro La Nueva Visión, Diseño y Construcción de SistemasComputacionales.

Visión dinámica del Sistema

Sistema

Ingresar Nº de O/C

Ingresar código de productoIngresar cantidadDar OK a la línea

Caso de usoIngresar O/C

Caso de usoAprobar cotización

Ingresar Nº de cotizaciónDar OK al documento...

Ingresar Nº de O/C

Dar OK al documento...

Caso de uso

Aprobar cotización

Visión dinámica del Sistema

Sistema

Ingresar Nº de O/C

Ingresar código de productoIngresar cantidadDar OK a la línea

Caso de usoIngresar O/C

Caso de usoAprobar cotización

Ingresar Nº de cotizaciónDar OK al documento...

Ingresar Nº de O/C

Dar OK al documento...

Caso de uso

Aprobar cotización

Caso de uso

Aprobar cotización




madas a operaciones, porque corresponden a estructura demensajes del diagrama de clases (que ya veremos).

3. La nomenclatura es la de Orientación a objetos

4. Los mensajes de la visión dinámica del sistema son men-sajes que llegarán a varias clases, cada una de las cualestiene la estructura de atributos y funciones.

Cuando se trata del primer caso de uso que estamosdesarrollando en una aplicación, el diagrama de se-cuencia y la visión dinámica son iguales, desde elsegundo se diferencian porque la visión dinámica es

acumulativa, va agregando las operaciones de losdiferentes casos de uso.

3.21. Diagrama de estado

El diagrama de estado de los casos de uso representagráficamente el estado del caso de uso antes y des-pués de cada una de sus operaciones.

Ejemplo de Diagrama de EstadoEjemplo de Diagrama de Estado. Caso de uso INGRESAR O/C

Ingresar Nº de O/C

Terminar la O/C

Ingresar línea de O/C

En espera de la O/C Introducción de líneas

En espera del cierreImprimir la O/C

Son diagramas poco utilizados en el ámbito de la

gestión de proyectos de procesos y tecnología.



JUAN BRAVO 136

No los usaremos en el método, sin embargo, hemospreferido incorporarlos por si en alguna implemen-

tación particular se les considera de beneficio.

3.22. Contratos

Los contratos detallan cada operación y existirántantos como operaciones se hayan identificado en elcaso de uso y detalladas en el diagrama de secuen-

cia. Tienen la siguiente estructura:Contrato

Identificación: nombre de operación y parámetrosResponsabilidades: descripción informal de lasresponsabilidades u objetivos de la operaciónTipos de datos: conceptos que afecta o clasesReferencias cruzadas: enlaces con otras funcionesdel sistema o casos de uso.Notas: indicaciones para diseño, algoritmos (tal

como el cálculo de dígito verificador) y otros datos.Excepciones: ¿qué sucede si...? y otros casosexcepcionales.Salida: Mensajes o registros que se envían fueradel sistema.Precondiciones: Supuestos acerca del estado delsistema antes de ejecutar la operación.Poscondiciones: Indicación de como quedó elsistema después de la operación.

• Poscondición 1 ...• Poscondición 2 ...

• Poscondición n ...

Una clave para entender los contratos son las pos-condiciones, es decir, como quedó el sistema des-

pués que se ejecutó la operación. Es como la foto-grafía que se toma después de un suceso. Veamos el

siguiente ejemplo:




Ejemplo de Contrato

Identificación: Dar OK al ingreso de la línea

Responsabilidades: con cada ingreso de línea losconceptos deben ser consistentes.Tipos de datos: afecta a los conceptos Encabezadode O/C y Detalle de O/C.Referencias cruzadas: no hayNotas: nada especialExcepciones: la no existencia de la línea en elsistema ya fue validada con el ingreso de O/C.Salida: no hayPrecondiciones: no existe la línea.Poscondiciones:

•Se creó una línea en el concepto detalle.• Se actualizó el contador de líneas en elencabezado.• Se actualizó la asociación entre encabezado y

detalle de O/C.

Se identificó, en tiempo verbal pasado, cómo fueronafectados los conceptos tras la operación (poscondi-ciones). Un contrato sin poscondiciones es una aler-ta de error, tal vez en la definición de la operación.

3.23. Interfaces usuario – sistema

Se trata de incluir una descripción de formularios,informes, pantallas y menús. Así como se cuenta conuna descripción detallada de los requerimientos deusuario en base a la técnica casos de uso, lo mismo

ocurre con el diseño de la interfaz.



JUAN BRAVO 138

Como una visión de conjunto de la definición deinterfaces, sería necesario:

• Describir los objetos de la interfaz de usuario másrelevantes de la aplicación, tales como: Calenda-rios (tipo cartas Gantt), barras de disponibilidad(0% al 100%), parrillas (grid), combo-boxes, me-nu-bars, scroll-bars, push-buttons, etc.

• Preparar el esquema de pantallas según estándares• Diseñar las interfaces según el tipo de usuario• Diseñar la jerarquía de opciones• Ordenar los procesos• Preparar ayudas en línea

Es importante el apoyo que pueden prestar profesionales de marketing,

diseño, periodismo, sicología, sociología yotras profesiones en el diseño de intefaces.

3.24. Prototipos desechables

En esta etapa solamente para ayudar en la definicióndetallada de funcionalidad principal e interfaces vi-

suales, tales como formatos de pantallas, informes ymenús. Una vez que los prototipos ha cumplido estafinalidad, son eliminados.

3.25. Revisión de los modelos

Con la finalidad de avanzar en el aseguramiento de la

calidad, es recomendable que el trabajo de modela-




miento sea revisado por los pares del analista o porotros profesionales, internos o externos.

3.26. Uso de herramientas

Especialmente para UML, existe una amplia gamade herramientas en el mercado que ayudan en losmodelos indicados (Visio, Rational, UML Studio,Enterprise Architect, etc.).

En la parte tercera una de las prácticas se refiere aherramientas.

La recomendación es usar herramientasde apoyo, realmente facilitan el trabajo ysi el sistema es grande, sonindispensables. Además, tienen la ventaja

de generar algunas partes del sistema en forma automática, por ejemplo, el código.

Son además vitales para la comunicación de los mo-delos (generalmente en XML, eso es interno…).

3.27. Costo del proyectoLa etapa concluye con la segunda estimación de cos-tos del proyecto.



JUAN BRAVO 140

ETAPA 4. DISEÑO

Lo que da origen a esta etapa es el Plan de proyectoactualizado, el modelo integral del cambio y sus re-querimientos.

El objetivo es obtener el detalle de la solución com-pleta que propone el modelo integral del cambio,especialmente personas, procesos, estructura organi-zacional y tecnología. Es el Cómo.

También se denomina Ingeniería de Detalle a estaetapa.

Entregable de la etapa: el detalle técnico del modelointegral del cambio.

~§~

Se diseñan en detalle los componentes delmodelo integral del cambio.

El diseño detallado consiste en dibujar planos, pre-parar modelos, identificar los encargados, dimensio-nar los recursos financieros, definir el espacio físico,conocimientos requeridos, interacciones con el en-

torno, elaborar licitaciones y contratos, etc. Es eldesarrollo en detalle del modelo integral del cambio.

Esto es necesario aun en proyectos pequeños, iguallas personas que construirán o implementarán nece-sitan de una guía.

Se incorpora en esta etapa formalmente el aporte de

las especialidades en la forma de un trabajo conjuntocon los analistas del proyecto.




Trabajo conjunto con los especialistas

Durante esta etapa se trabaja con profesionales es-

pecialistas en cada ámbito de la solución. Principal-mente lo relacionado con personas, procesos, estruc-tura organizacional y tecnología.

Nótese que “se trabaja con” y no “seentrega o delega el trabajo aespecialistas”, porque se trata de untrabajo conjunto.

En esta etapa normalmente se recurre a la asesoríaespecializada, porque hay que ir a los detalles, pro-bablemente empleando simbología y terminologíamás precisa. Algunas sugerencias son:

• Trabaje en conjunto con el especialista hasta ob-tener el resultado deseado, porque habrá muchalabor de afinamiento y perfeccionamiento sucesi-vo, además, una vez que el especialista se retire,usted deberá seguir manteniendo la solución.

• Evite la dependencia total y no se deje amedren-

tar por la erudición, las sofisticaciones o la espe-cialización. Un buen profesional no hace alardede sus conocimientos y tiene la capacidad de ex-plicar materias complejas con simplicidad.

• Conserve la visión de conjunto y asegúrese quelos equipos de trabajo dedicados a diferentes par-tes de la solución estén plenamente coordinados.



JUAN BRAVO 142

Más importante que una supercreación tecnológica,de estructura o de flujos de procesos, es desarrollar

armónicamente la solución. Muchos proyectos han fracasado porque

cada ámbito de acción fue tomado por separado.

4.1. Diseño de procesosEn esta etapa del ciclo de desarrollo de un procesose trabaja en la preparación detallada de cada ele-mento de la solución y la forma de implementar,esencialmente el diseño de:

• El nuevo flujo del proceso con nombres de encar-

gados y recursos• Procedimientos en detalle.• El plan de capacitación y de implementación• Las nuevas labores a realizar• El ambiente físico y cultural• La nueva estructura organizacional• La red de comunicación

• El detalle de equipamiento y softwareTambién desde el punto de vista de los riesgos:

• ¿Cuál es el costo futuro de un mal diseño?• ¿Cuál es el costo futuro de no hacer diseño?




Algunas características del buen diseño

Las características prácticas del buen diseño fueron

pensadas para las partes más técnicas del rediseñode procesos, sin embargo, veremos que son aplica-bles en toda la gama de ámbitos del diseño23.

Digamos primero que existen características univer-sales del diseño de productos y servicios, por lo de-más evidentes, como abstracción, amistosidad,

flexibilidad, portabilidad, impersonalidad, factibili-dad, etc... Se supone que ellas son conocidas.

En particular, el diseño que se estárealizando debe tener posibilidadesconcretas de ser implementado, conrecursos acotados y herramientasdisponibles.

Este conjunto de orientaciones son independientesde la implementación.

Intuición. El diseño es una tarea eminentementecreativa, por lo tanto, la intuición juega un rol pre-ponderante. Esto se puede interpretar como de

acuerdo con el sentido común o percepción. ¿Qué esla intuición? Hay quienes dicen que es una de lasvoces de la conciencia... Es esa sensación de inco-modidad, de que algo sobra o algo falta en el mode-lo. Si hacemos caso de la intuición, veremos que tal

23 Más detalle de las características de buen diseño en el libro “LaNueva Visión, diseño y construcción de Sistemas Computacionales”



JUAN BRAVO 144

vez algo cambió en la realidad o existe un problemade enfoque que verdaderamente afecta al diseño.

También la intuición se manifiesta en nuestra habi-tual práctica de tomar decisiones con informaciónincompleta.

Simplicidad. Habitualmente, la elegancia va de lamano con la simplicidad, es más, se podría plantearla siguiente regla: si el diseño se ve complicado,

hágalo otra vez. Solamente hay que darse por satis-fecho cuando el diseño es y se ve fácil de entender,lo cual puede llevar bastante esfuerzo, pero es unaexcelente inversión.

La simplicidad también se refleja en mantener unasolución “limpia”, sin particularizaciones innecesa-rias ni ingeniosidades.

Existe simplicidad en el diseño cuando loentienden los demás, incluyendo

especialmente al usuario y cuando sesiente que es simple.

Totalidad. El diseño del proceso debe considerar

todos los elementos, aun cuando algunas partes seanincorporadas sólo para conservar la visión de conjunto, sin llegar a un nivel profundo de detalle. Latotalidad responde a la necesidad de una visiónholística del problema. Lo importante es captar larealidad y llevarla a los modelos.

Generalización. Cada problema, apropiadamenteplanteado, no es más que un caso particular de un




problema general más fácil de resolver. Así se haceinversión en inteligencia, porque los nuevos pro-

blemas particulares que se vislumbran ya estaránresueltos. Es un signo de inteligencia no resolversiempre los mismos problemas. Esto significa buscarel “metaproblema”, aquél que representa a todos losproblemas del mismo tipo.

Transacciones presentes para la actualización de la

informaciónEn la gestión de procesos hablamos de transaccio-nes, ya sean ventas, compras, créditos, traspasos deproductos, etc. En esta etapa se diseña en detalle el

juego de transacciones del proceso. Por ejemplo, noes suficiente con diseñar la forma en que se realizarála venta y la factura correspondiente, también es vi-tal considerar como se actualizará la informacióncuando se requiera corregir información (facturaerrónea). En este caso mediante transacciones denotas de crédito, débito o ajustes.

Lo importante aquí es la trazabilidad, quese pueda seguir la pista de cómo se vanactualizando los datos, siempre mediantetransacciones formales, jamásinterviniendo en forma directa un archivo.

Incluso en la interacción con los especialistas deinformática, es importante para efectos de la seguri-dad e integridad de la información que ellos no ten-gan privilegios especiales.



JUAN BRAVO 146

La forma más habitual del procesamiento computa-cional de transacciones es actualizar “maestros”, de

clientes, proveedores, productos, etc. Éstos van mo-dificando sus datos en la medida que las transaccio-nes los afectan. ¿Qué sucede cuando se descubre unerror en la factura emitida ayer y que ya afectó a losmaestros de inventarios y de cuentas contables? Una“solución” generalizada es arreglar “a mano” losmaestros involucrados, significa intervenir directa-

mente el resultado en el maestro; por ejemplo, in-crementar el inventario en dos unidades. Esto tienemuy altos costos, porque, si fuera necesario reproce-sar a raíz de una “caída del sistema”, todos los arre-glos efectuados a mano no se podrían reproducir ylos archivos quedarían inconsistentes… Es evidenteque se pasan a llevar normas elementales de calidad,

trazabilidad, control y auditoría.La solución es aplicar otra transacción formal, unatransacción presente que revierta la anterior; en elejemplo, puede ser una nota de crédito. ¿Qué sucedesi la corrección está incorrecta? Se hace una tran-sacción de ajuste. Esto significa definir el siguiente

juego de operaciones: transacción original, contra-transacción y ajuste.

Así, se da una línea continua en el tiempo y nunca se “vuelve al pasado”.

Todo esto debe estar contemplado en el diseño, así como aspectos de auditoría, seguridad, integridad y

recuperación del proceso.




Calidad de la información

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 dueño,• se almacena en forma no redundante,• siguiendo modelos por todos conocidos y

• la puede usar cualquier usuario autorizado.

Un aspecto crítico del trabajo a realizar en diseño, es asegurar la calidad delmanejo de información en el proceso,donde existen múltiples fórmulas, ya seaaumentando oportunidad o confiabilidad,

tal como al aplicar máxima validación delos datos en el momento que ingresan alcomputador.

4.2. El diseño del software

Específicamente en el diseño del software se trabajaen: modelos de datos, identificación de clases: mo-delos generalizados, diagrama de clases del sistema,visión interna con diagramas de clases y objetos ydiagramas de colaboración, entre otros modelos.

En esta propuesta de procesos y tecnología se trabajacon UML.



JUAN BRAVO 148

Se trabaja en paralelo con las otras ramas del mode-lo integral del cambio, por los mismos u otros profe-

sionales según la envergadura del proyecto.Suponemos como punto de entrada a esta etapa quese dominan técnicas de ingeniería de software, talescomo:

• Planificación informática• Modelamiento de datos• Modelamiento de funciones• Auditoría computacional• Características de buen diseño• Modos de procesamiento• Calidad y productividad en el desarrollo de

software• Orientación a objetos

• UMLSe utiliza la biblioteca de clases, la orientación aobjetos y las herramientas de apoyo.

Aquí se define en detalle todo el sistemade seguridad, integridad y recuperación

de la información.

4.3. Diagrama de Diseño de Clases

El modelo de UML que se emplea para representarlas relaciones entre las clases es el Diagrama de Di-seño de Clases. Corresponde a la visión interna de la

aplicación.




Clase es una abstracción que no tiene una imple-mentación tecnológica. Se aplica a nivel del mode-

lamiento y sirve para identificar y darle sus elemen-tos a los objetos que de ella derivan; por ejemplo,los objetos clientes y proveedores derivan de la clasepersonas y heredan de ella sus elementos comunes.

Nace desde el modelo conceptual e incorpora lasfunciones necesarias para cumplir con el objetivo delos casos de uso.

Por ejemplo:

Líneas de laO/C

unidadesPrecio

Agregar línea

Productos...

Bodega

...

Encabezado deO/C

Nº O/C

Fecha

Crear líneaImprimir

Proveedores

RutNombre

Crear proveed.Modificar Rut

Modificar nom.

1

1..* se asocia a

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena

Líneas de laO/C

unidadesPrecio

Agregar línea

Productos...

Bodega

...

Encabezado deO/C

Nº O/C

Fecha

Crear líneaImprimir

Proveedores

RutNombre

Crear proveed.Modificar Rut

Modificar nom.

1

1..* se asocia a

* 1

existe en contiene

* 1

contiene existe en

*

1

existe en

almacena



JUAN BRAVO 150

Identificación de clases

Esencialmente se trata de modelos generalizados.

La idea general en el desarrollo de sistemas de in-formación es reutilizar componentes validados, quefueron pensados y desarrollados con ese fin, aunquetambién puede suceder que en el transcurso delavance en un proyecto específico un módulo particu-lar sea candidato a generalizarse, es decir, a trans-

formarse en una clase.Igual en ambos casos se aplica el proceso de genera-lización, como un desarrollo paralelo a las aplica-ciones específicas y que probablemente lleva a caboun equipo de desarrollo ad-hoc, validando e incorpo-rando clases a una… biblioteca de clases.

En particular, se trata de responder a¿qué clases podemos utilizar? Ya sea de lamisma instalación o del medio. El sueño

es tener todas las clases disponibles ysolamente utilizarlas.

4.4. Diagrama de colaboraciónPara cada operación del caso de uso seleccionado sepresenta un diagrama de colaboración y detalles deimplementación24 (¿cómo implementar?).

24 En este método de desarrollo aplicamos la técnica de espiral,

donde se diluye un poco la independencia de la implementacióntecnológica, por este motivo se prefiere avanzar en características dela implementación a nivel del diseño.




• Diagrama de colaboración: cada operación deta-llada en un contrato se desarrolla en detalle seña-

lando las solicitudes (o pedidos) entre objetos(principalmente del modelo de datos y pantallas).

• Detalles de implementación: se responde a ¿quéclases podemos utilizar? Ya sea de la misma ins-talación o del medio, es decir, hacer una revisiónde la biblioteca de clases25 (que en un esquema deorientación a objetos es un requisito), por ejem-

plo, la condición de existencia. Corresponde aldetalle de cada clase e instancias (objetos) especí-ficas en una tabla de diferencias.

Por ejemplo:

Ingresar producto

(cód, cant, pre)

Diagrama de Colaboración

Operación: Dar OK al Ingreso de la línea de O/C

Encabezadode O/C

Líneas de la

O/C

Terminal deladministrativo

1: Crear linea de O/C

(cod, cant, pre)

1.1: Crear (cod, cant, pre)

25 Se supone la existencia de la biblioteca de clases para efectos deeste método.



JUAN BRAVO 152

4.5. Visión externa

Es la arquitectura del sistema, incluye:

• Diseño de la Interacción con los otros sistemasexistentes

• Definir el flujo de transacciones: matriz maestros-transacciones

• Modelo de datos normalizado y generalizado(clases)

• Modelo funcional generalizado (clases): con deta-lle de atributos, métodos y operaciones.

La forma general del diseño quedaría así:sólo con clases y mensajes. Aquí el trabajo

sería de integración de clases paraconstruir la aplicación y un indicador

clave es el % de uso de código reutilizable(desde la biblioteca de clases).

4.6. Entorno de la aplicación

Es fundamental ofrecer definiciones acerca de:

a) Menúsb) Modelo de dos o tres capas según las plataformasy definiciones de la instalación, por ejemplo, paratres capas:

• Forma de manejo de la interfaces con el usuario(para preparar código de presentación).

• Forma de incorporación de la lógica del negocio(para preparar código de procesamiento de datos).




• Verificar consistencia y completitud de la base dedatos, así como la forma de administración de los

datos (para preparar código de almacenamientode datos).

c) Describir los objetos utilizados para implementarinterfases, lógica de la aplicación, interacción conotros sistemas computacionales o formas de acce-so a la información.

4.7. Costo del proyecto

La etapa concluye con la tercera estimación de cos-tos del proyecto.



JUAN BRAVO 154

ETAPA 5. IMPLEMENTACIÓN

Esta etapa nace desde el Plan de proyecto actualiza-do, el modelo integral del cambio y sus requerimien-tos y el diseño (o ingeniería de detalle) de la solu-ción.

El objetivo es llevar a la práctica la solución com-pleta que propone el modelo integral del cambio,armonizando todas sus partes (estrategia, personas,procesos, estructura organizacional y tecnología).

Se concluye en un aplicación real aunque en carácterpiloto.

Entregable de la etapa: el informe de buen funcio-namiento del piloto del proyecto.

~§~

Se trata de implementar (tambiénconstruir, realizar o llevar a la práctica)

la solución completa que propone elmodelo 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.




• Se instala la aplicación de software, proba-blemente en variadas máquinas.

En particular, veremos la implementación desde elpunto de vista de procesos y Tecnología de Informa-ción (TI) las cuales normalmente avanzan de maneramás bien en paralelo que secuencialmente.

Llevar a la realidad

Implementar significa llevar “a la realidad” el dise-ño, ya sean planos de un edificio, plan de capacita-ción, flujos de información, formularios, apoyocomputacional, una política acerca de las personas oel diseño de un estructura organizacional.

Implementar también implica

retroalimentar el diseño sobre aspectos nocontemplados con anterioridad.

Es necesario asegurar paso a paso que efectivamentela solución cumple su objetivo. La flexibilidad esfundamental para efectuar las correcciones que seannecesarias sobre el plan original. La participación y

capacitación de todos los interesados, así como elmanejo del cambio son vitales en esta etapa.

Otras actividades de esta etapa son:

• Completar la documentación.• Comunicar el avance a todas las personas relacio-

nadas con el cambio en los procesos.

• Capacitar por niveles en forma oportuna, cuidan-do de no recargar a las personas en esta actividad,



JUAN BRAVO 156

es necesario dimensionar apropiadamente eltiempo de las personas.

Una forma de motivar la capacitación es fomen-tando el equilibrio de costos entre todos los facto-res de incidencia en un proyecto. Hay empresasdonde se han efectuado inversiones de cientos demiles de dólares en equipamiento que ha quedadoabandonado… debido a que el proyecto no con-templaba gastar algunos miles de dólares en ca-

pacitación.

5.1. Negociar los compromisos

Parece un contrasentido, ¿por qué negociar algo queya está comprometido? Porque la experiencia indicaque este es un factor crítico. Ahora que es necesariollevar los planes a la práctica, sucede que personascon que el analista contaba están destinadas a otraslabores urgentes —supongamos justificadamente—.Espacios físicos que el analista sabía que tendría, nolos tiene, porque hubo otras prioridades… Un equi-po computacional prometido para cierta fecha nollegó… Estos son los supuestos realizados en lasetapas de factibilidad y análisis, para los cuales de-bieran existir planes de contingencia.

Es importante aclarar que negociar loscompromisos no significa permisividad ni

tolerar el incumplimiento de las tareas,sino que se trata de simple adaptación a

las contingencias del mundo.




Por lo demás, es casi seguro que muchas de esascontingencias ocurrirán.

Se puede abordar este tema de los compromisosacortando los tiempos de rediseño, es una razón porla cual empleamos la técnica de rediseño en espiral.

Otra forma es aprendiendo a negociar:reiterando la actualidad de los objetivosque dieron origen a los compromisosasumidos, escuchando, intercambiando,buscando nuevas posibilidades creativas.

Nada de esto estaba en los planes, aunquesí deberíamos contar con que un

porcentaje de acciones programadas no serealizarán, porque así es la vida y no es

por falta de voluntad de las personas.

5.2. Implementar los procesos

Algunas recomendaciones para la implementaciónde los procesos:

• Mantener comunicación con todos los actoresinvolucrados es esencial. Buenas experiencias sehan logrado con una o dos reuniones semanalescon representantes de los consultores que apoyanel rediseño, el equipo asesor en metodología, elequipo interno de trabajo, el equipo de trabajo enel ámbito tecnológico, los usuarios, la dirección

de la organización y proveedores especializados



JUAN BRAVO 158

de elementos de comunicación o infraestructura,solo por nombrar algunos interesados.

• Mostrar resultados pronto para mantener el nivelde entusiasmo —los Quick Wins, una de las

prácticas transversales— aunque con la precau-ción de no abusar de esa vía rápida porque elgrueso del rediseño y del apoyo computacionaltiene que seguir las formalidades metodológicas(el desarrollo en espiral es recomendable)

• Tener la flexibilidad para resolver con rapidez losinevitables problemas que se producirán, es idealtener una persona o un equipo “de acción rápida”.Es aceptar y trabajar con la complejidad26.

Que esto no se confunda conimprovisación ni que sea una excusa para

una mala planificación, es simplementeresponder con variedad a la variedad

natural del medio, aquella difícil de predecir.

• Tener disponibilidad de los integrantes del equipode trabajo para con los usuarios. Es crítico en larelación con el usuario del proceso, es preferibleinvertir en disponibilidad de personas que en ma-yor equipamiento técnico (si se puede ambas co-sas a la vez, mejor) tal como fue la experiencia deBancoEstado —ver anexo 7— donde a veces unanalista destinaba varios días de su tiempo a estar

26 El libro Análisis de Sistemas aborda el tema de la complejidad delos sistemas.




con el usuario hasta que éste se sentía tranquilo(mucho más allá de solamente capacitar).

En este caso se compensó ese mayor costo conahorros en soluciones tecnológicas más sencillas.Los resultados fueron realmente de excelencia.

• Mantener verdaderamente “puertas abiertas” en elequipo de trabajo. Todos los medios de comuni-cación son necesarios aquí, así como la disponibi-lidad (ojalá rotativa a diversas horas).

• En un caso donde el líder del proyecto se fue devacaciones fuera del país justo en el momento dela implementación el fracaso estuvo muy cerca.

• Aplicar la estrategia tenaza comentada, corto pla-zo y largo plazo a la vez.

5.3. Implementar la TI

Si la solución contempla una faceta de tecnología deinformación, la etapa se refiere a llevar el diseño a larealidad, en un lenguaje específico y en una máquinadeterminada.

Muchas veces no hay construcción

propiamente tal, sino que el armado deuna solución de software.

En esta etapa hay amplia utilización de código reuti-lizable. Bajo el concepto de trabajo con clases seutiliza una biblioteca de clases (que en un esquemade orientación a objetos es un requisito) herramien-

tas de apoyo y variadas técnicas.



JUAN BRAVO 160

También se realizan mediciones de dimensiona-miento para la incorporación del número previsto de

usuarios (complementando las estimaciones de laetapa de factibilidad).

Construcción de la aplicación

En este método, el grueso del trabajo de construc-ción se orienta a codificar las nuevas clases,comúnmente realizado por un equipo de especialis-tas dedicados exclusivamente a la generación declases. A veces llamados “desarrolladores”.

Luego otro equipo usa esas clases, y otras desarro-lladas con anterioridad para construir o referenciar elcódigo específico que requiere la aplicación. Debi-era ser un trabajo de integración de clases más que

realmente de codificación. Es la forma de trabajo enbase a componentes. A veces se les llama “integra-dores” a estos profesionales.

También se podría trabajar congeneración de código, utilizando una línea

de herramientas tipo Genexus o LINC , es

una variante al trabajo con componentesque también exploran las empresas

5.4 Probar

Hay una palabra que siempre acompaña a la imple-mentación, probar. Cada parte de la construccióndebe ser probada inmediatamente. Por ejemplo, en la




construcción de una casa resulta evidente que alterminar el tendido eléctrico y antes de efectuar ter-

minaciones, nos aseguremos de su correcto funcio-namiento.

Es necesario probar en detalle y con minuciosidadprogresiva todos los aspectos del proceso y de laaplicación, esto se puede hacer como si fuésemosabriendo cajas negras, es decir, desde menor a ma-yor profundidad y complejidad. ¿Quién prueba? Hay

amplia variedad de posibilidades: las mismas perso-nas que construyen, los analistas, un equipo internoespecializado en Testing, los usuarios y empresasque ofrecen ese tipo de servicio.

Pruebas unitarias

Desde el punto de vista de TI, se realizan pruebasunitarias por los mismos programadores.

Una buena técnica que también se empleaes realizar la pruebas unitarias en formacruzada, es decir, por los pares.

Pruebas generales del sistema

Son pruebas sistemáticas de módulos de la aplica-ción y del sistema completo. Normalmente las reali-zan profesionales diferentes a quienes construyeron,puede ser una labor externalizada (de hecho, soncada vez más las empresas del área de software que

ofrecen este servicio específico).



JUAN BRAVO 162

Actualmente existe un amplio abanico de herramien-tas de apoyo para las pruebas.

Para un caso de uso lo mínimo a probar debiera ser:• El curso normal de los eventos y cada opción.• Cada excepción definida en el sistema.• Cada iteración, recorriéndola las veces especifi-

cadas y más de una si es n.• Cada restricción de frontera.

Algunas labores que se realizan aquí son:• Preparación de datos de prueba y enlace con

herramientas de ayuda.• Pruebas por módulos.• Integración de todos los módulos y pruebas del

sistema completo.

Análisis de impacto en los bordes

Se trata de estresar la aplicación y probar las condiciones que menor probabilidad

de ocurrencia en la realidad, aquellas que“botarán” la aplicación años después si

no se detectan ahora.

Aceptación de las pruebas

La aceptación de las pruebas por parte de los usua-rios y encargados de explotación, en conjunto, con-siste en responder a:

• ¿Resuelve el requerimiento actualizado?




• ¿Qué sucede en caso de caídas del sistema, endiferentes puntos?

• ¿Cómo se mantiene la consistencia de la infor-mación?• ¿Qué sucede con la privacidad y recuperación?

Entre otras verificaciones.

Pruebas finales

El objetivo es demostrar que el sistema integradofunciona correctamente y satisface su especificaciónactualizada.

Se requieren pruebas de integración, pruebas finalese inspecciones de aceptación del sistema para de-mostrar al cliente que el sistema satisface sus reque-rimientos.

Se incluye también el manejo de no conformidades.

5.5. Instalar el piloto

Una actividad vital de esta etapa escomenzar a operar el proceso rediseñadoen carácter de piloto, considerando un

período de prueba integral con datosreales y en la práctica.

Al mismo tiempo se avanza en:

• Capacitación de usuarios piloto, quienes luego

pueden hacer de instructores para los demás usua-



JUAN BRAVO 164

rios. Es importante la dedicación completa de es-tas personas al proyecto.

• Comunicación del avance.

Desde el punto de vista de TI, la etapa contemplainstalar el sistema en alguna máquina específica ycomenzar el uso real también en carácter de instala-ción piloto.

Es importante no confundir la instalación piloto con

un prototipo. El piloto es para certificar en la prácti-ca que la aplicación cumple con los requerimientosexplícitos y tácitos bien identificados y probados,luego se replica para todos los usuarios. El prototipoes para que el usuario vea un boceto de lo que quiereo para probar aspectos específicos de la funcionali-dad, luego se desecha.

Una recomendación es asegurarse queefectivamente se usa lo nuevo… Y si lo

nuevo no se usa, tal vez sea por razones fundamentadas, lo que llevaría a

modificar el proyecto.

Algunas tareas propias de la implementación:• Crear las tablas o archivos de las bases de datos• Poblar las tablas del sistema• Realizar paralelo cuando sea posible. El “parale-

lo” consiste en comparar el funcionamiento delsistema antiguo (manual y/o computacional) con

el nuevo durante un período determinado.




• Asegurarse que existen los manuales de usuario ydel sistema (ojalá en línea).

• La capacitación de los especialistas de explota-ción y de usuarios piloto.

Especiales comentarios requiere en esta etapa elproceso de paso a producción:

• En primer lugar es un proceso que debe estar biendefinido y aprendido por todos los partícipes.

• Debe ser fluido y simple.• Es un requisito que el ambiente de explotación

sea diferente al de desarrollo, al menos en servi-dores diferentes.

• Debe ser seguro y seguir reglas generalmenteaceptadas de auditoría computacional.



JUAN BRAVO 166

ETAPA 6. DESPLIEGUE

La etapa de despliegue nace desde el Plan de pro-yecto actualizado, el modelo integral del cambio ysus requerimientos, el diseño (o ingeniería de deta-lle) de la solución y la implementación en carácterpiloto de la solución completa.

El objetivo es replicar o expandir la

solución generada hasta ser bien utilizada por todos los usuarios previstos en el plande proyecto.

Entregable de la etapa: el informe de puesta enmarcha completo del proyecto

~§~

Se trata de instalar la solución completa que proponeel modelo integral del cambio:

• Las personas son capacitadas y reubicadas (lasensibilización y otros aspectos ya deberíanestar logrados)

• Los procesos definitivos son llevados a todoslos puntos donde serán utilizados.

• La nueva estructura organizacional se poneen marcha.

• Se instala la aplicación de software, proba-

blemente en variadas máquinas.




En particular, veremos aquí el despliegue desde elpunto de vista de procesos y tecnología.

6.1. Revisar y actualizar elementos

Se trata de asegurar la disponibilidad de todos loselementos para difundir la solución tecnológica:

• Documentación: manuales de usuario, del siste-ma, ayudas en línea, etc.

• Disponibilidad de equipamiento computacional• Disponibilidad del software necesario• Disponibilidad de licencias del software• Disponibilidad de dispositivos de comunicación.• Una base de datos con las respuestas a preguntas

típicas del despliegue. También de cada atención

a usuarios, quizá el mismo usuario pueda ingresary detallar su solicitud, luego en el mismo softwarese puede asignar un encargado.

Se requiere una mesa de ayuda, conopciones de soporte telefónico, Intranet,visitas en terreno, etc.

Acerca de capacitación:• Programas detallados de capacitación de usuarios

piloto y monitores• Programas detallados de capacitación según tipos

de usuarios• Comunicación directa con los proveedores de

tecnología.



JUAN BRAVO 168

6.2. Incorporar a cada usuario

Aquí al menos es necesario considerar los siguientes

elementos:• La instalación personalizada en cada máquina.• Qué elementos del sistema se instalan en el com-

putador del usuario y cuales en un servidor.• Que los dispositivos de comunicación están en

funcionamiento

• Un mapa de instalación, para conocer configura-ciones físicas, de software y de comunicación.• Dedicación completa de analistas, al igual que los

instructores. Son tantas las facetas de los procesosy la aplicación que exige gran atención.

• Que los ejecutivos debieran estar especialmentealertas para facilitar el despliegue.

Conviene enfatizar los aspectos decomunicación, en todo sentido.

6.3. Capacitar a los usuarios

Capacitación según tipos de usuarios: usuarios ope-rativos que interactúan con el cliente –tal como uncajero– supervisores que deben tomar decisionesrápidas con base en una mirada global de lo que su-cede o ejecutivos que desean ver tendencias y totalesen un sistema computacional.

Para realizar el despliegue debemos recurrir a mu-

chas instancias de comunicación rápida y efectiva,




sobre todo si se trata de llegar a cientos o miles deusuarios, por ejemplo:

• Revisar y actualizar el material (el cual deberíaestar preparado desde las etapas de diseño e im-plementación.)

• Desarrollar algún video explicativo cuando co-rresponda.

• Utilizar Internet. Al respecto, un método que seemplea cada vez más es preparar capacitación ad-hoc en la red, e-learning, los usuarios se conectanlibremente y existen niveles de evaluación y mo-nitoreo. Hay experiencias de preparación de caje-ros y de muchos otros tipos de usuarios operati-vos con esta técnica, con buenos resultados (me-

jor cuando se complementa con algún porcentajepresencial)

• Reuniones ampliadas de los gerentes dando lapartida al proceso.

“Capacitar a los capacitadores”. Cuidar los elementos pedagógicos. Un desarrolloimpecable puede fracasar porque elespecialista en informática no sabe

transmitir el uso del software.



JUAN BRAVO 170

ETAPA 7. OPERACIÓN

La etapa de operación nace cuando la solución gene-rada está siendo bien utilizada por todos los usuariosprevistos en el plan de proyecto. Requiere de la do-cumentación generada en todas las etapas.

Entregable de la etapa: mantener la solución enbuen funcionamiento hasta que cumpla con su vidaútil o sea reemplazada por otra solución. La mejora

continua es una actividad central.

~§~

Los procesos requieren de mejoracontinua en esta etapa, así como la

aplicación computacional

El buen funcionamiento de la solución debe lograrseen todo el modelo integral del cambio de la solución(estrategia, personas, procesos, estructura organiza-cional y tecnología) Por tanto, la mejora continuaopera en cada una de sus partes.

Es importante señalar que mientras se está trabajan-

do en una vuelta de la espiral (suponiendo se empleala técnica de desarrollo en espiral), no aplica todavíala mejora continua porque los casos de uso que sevan desplegando están en desarrollo y todo el equipode proyecto junto con los usuarios está atento a loscambios. Es decir, mientras la solución está en desa-rrollo existe la infraestructura para abordar el cam-

bio mayor y menor.




Cuando la solución completa está desplegada co-mienza la mejora continua, la cual es compatible con

el rediseño programado

27

, tal como veremos en lasección 7.6.

7.1. La mejora continua

La mejora continua opera a nivel delmodelo integral de la solución (estrategia,

personas, procesos, estructura ytecnología).

La mejora continua, también llamado mejoramientocontinuo28 son pequeños y permanentes perfeccio-namientos de un sistema, proceso, producto, unidadorganizacional y cualquier otro elemento de la orga-

nización. La mejora continua de procesos producti-vos o administrativos para obtener productos y ser-vicios flexibles, adaptables, de buena calidad yeconómicos es una meta deseable para cualquieraempresa. Veremos aquí algunas formas efectivas delograrlo.

Desde los fundamentos que provee la visión sistémi-ca29, aplicamos el principio de continuidad, significauna adaptación permanente de la solución a las nue-vas exigencias del medio. Destaquemos algo funda-

27 En el libro “Desarrollo de sistemas de información, una visiónpráctica” hay alcances adicionales bajo el título “Sistemas en Acti-

vidad”.28 Resumen desde el libro “Gestión de Procesos”, capítulo 15.29 Ver libro Análisis de Sistemas.



JUAN BRAVO 172

mental y que a veces no se percibe claramente: todo proceso debe estar en mejoramiento continuo, labor

realizada principalmente por los mismos partícipesdel sistema.

Aporta Robert Kriegel (1994, p. 210): “una grancantidad de pasos pequeños lo pondrá en capacidadde alcanzar sus metas más rápido y más fácilmentede lo que creyó posible. Toyota utiliza esta mentali-dad para hacer innovaciones. Mientras que muchas

otras empresas luchan por avances espectaculares,Toyota se mantiene realizando gran cantidad de co-sas pequeñas y haciéndolas cada vez mejor… Sueñeen grande, pero dé muchos pasos pequeños”.

¿Ha intentado subir un cerro corriendo? Lo más probable es quedar exhausto a

poco camino. Sin embargo, paso a paso sellega.

Algunas veces el mejoramiento continuo surge des-de la implementación de un Sistema de Gestión de laCalidad, en tal caso, algunos requisitos serían (ISO9001:2000, p. 2): “identificar los procesos necesa-

rios para el sistema de gestión de la calidad… de-terminar la secuencia e interacción de estos proce-sos… determinar criterios y métodos necesarios paraasegurarse de que tanto la operación como el controlde estos procesos sean eficaces”.

Continúa el texto de la norma ISO 9001:2000 con

asegurar la disponibilidad de recursos e informaciónpara apoyar la operación, el seguimiento, la medi-




ción, el análisis y la mejora continua de todos losprocesos.

Nótese que todo gira en torno a los procesos, con inicio y término en elcliente.

Algunas herramientas del mejoramiento continuo

Algunas de las herramientas30 más efectivas de me-

joramiento continuo son:1. Benchmarking2. Flujograma de Información3. Estandarización interna y externa.4. El ejemplo personal.5. Kanban (sistema visual)6. Compensadores de complejidad

7. El momento de la verdad8. Seis Sigma9. Ciclo PDCA (Plan Do Check Act).10. Técnica de las 5-S11. Realizar tormentas de ideas12. Implementar círculos de calidad13. Diagramas causa-efecto (ver anexo 1)14. Diagramas de Pareto (ver anexo 1)

Además de una amplia gama de herramientas cerca-nas a la estadística.

30

Se presentan aquí solamente como una muestra de la profundidadde la mejora continua, están detalladas en el libro Gestión de Proce-sos, capítulo 15.



JUAN BRAVO 174

7.2. Control de cambios

Se trata de establecer un procedimiento deaceptación de requerimientos menores en

el ámbito de la TI.

¿Obtención de nuevos informes, consultas y adapta-ciones menores? Es necesario resolver acerca de

esto y tal vez seguir el procedimiento general delDepartamento de Informática en cuanto a requeri-mientos menores, por ejemplo:

Abreviaturas:

SC: Solicitud de Cambio

II: Informe de Impacto

PD: Plan de Desarrollo

DEPARTAMENTO DE INFORMÁTICA ÁREA DESARROLLO

JEFE INFORMÁTICA ANALISTA

PROCESO: EMITIR UNA SOLICITUD DE CAMBIO MENOR EN APLICACIONES COMPUTACIONALES

AsignarAnalista

SUBCOMITÉ CAMBIOS

Estudiarimpacto

Casos deuso

Emitirinforme

II

Plan deDesarrollo

PD

PD’

USUARIO AUTORIZADO

II’

PD’’PROCESOIMPLEMENTAR

SC

SC

II’

1. Emisión de una solicitud de cambio menor porparte de un usuario autorizado (podrían ser inte-grantes del mismo departamento de informática).

2. Recibe la solicitud el Jefe de Informática




3. El Jefe de Informática asigna a un analista pararealizar un estudio de impacto:

• Lo presenta como un caso de uso• Determina impacto en la aplicación y en

otros sistemas• Calcula costo y recursos• Determina duración• Entrega informe al Jefe de Informática

4. Se presenta al requerimiento al subcomité de in-formática encargado de los requerimientos meno-res, con la participación especial de los usuariossolicitantes y relacionados, el Jefe de Informáticay el analista que realizó el estudio de impacto. Setoma alguna decisión de cambio.

5. El analista presenta el plan de desarrollo precisodel requerimiento, incluyendo equipo de trabajo ycostos, de acuerdo con las indicaciones del Sub-comité de Informática.

6. Aprueba el Jefe de Informática.

7. Se realiza el trabajo, incluyendo lo mismo indica-do en las secciones anteriores del ciclo de desa-

rrollo, desde análisis hasta despliegue, aunque auna escala menor.

Por lo menos contempla:• Participación del usuario en forma continua• Actualización de documentación• Búsqueda de programas, bibliotecas, docu-

mentación, etc...



JUAN BRAVO 176

• Ordenamiento de manuales, versiones deprogramas, cambios en archivos, etc...

• Análisis, diseño e implementación• Pruebas• Reentrenamiento

8. Retroalimentación

7.3. Una mesa de ayuda

Una mesa de ayuda es fundamentaldurante la implementación del sistema yluego durante su operación.

Puede ser parte de la mesa de ayuda central en laorganización.

Con todos los elementos que se acostumbra en estoscasos, por ejemplo, escalamiento de niveles según laprofundidad de la ayuda y una buena formación delprimer nivel para que resuelva la mayor parte de lasconsultas.

7.4. Buena operación de la aplicaciónSe trata de trabajar sistemáticamente al menos en lassiguientes prácticas:

• Mantención de una bitácora de los procesos másrelevantes

• Control de funcionamiento correcto




Optimización de recursos, permanente,tales como verificación de recorridos en la

navegación por bases de datos o el uso de procesador, memoria y espacio en disco.

• Revisión de la necesidad de imprimir informes

• Reiniciar el sistema en caso de caídas del sistema

• Reconstrucción de archivos

• Seguridad e integridad de la información• Recuperación de la información

• Auditoría computacional

• Documentación actualizada en todo momento

7.5. Gestión de la calidadDurante la operación se requiere asegurar, entreotros aspectos:

Que se continúa operando en conformidad con losrequerimientos del cliente o usuario.

Que existe soporte a clientes de acuerdo con lo es-pecificado en el contrato.

Que existe un procedimiento de modificación delsistema en cuanto a requerimientos mayores (redise-ño) y menores (mejora).



JUAN BRAVO 178

7.6. Rediseño programado de la solución

Se trata de realizar un nuevo ciclo de desarrollo en

fechas programadas, como si fuera otra vuelta de laespiral. Se revisa y adapta desde el modelo integraldel cambio de la solución.

De esta forma, muchos de los nuevosrequerimientos, mayores o menores,seguirán esta vía en lugar de la mejora.

Además, programar un ciclo de desarrollo permiteresolver problemas de consistencia, de regeneraciónde estructuras de datos frente a cambios, de integra-ción del proyecto, aplicar lo aprendido para optimi-zación del funcionamiento, etc.

En experiencias personales del autor, soluciones detamaño mediano se rediseñaban con éxito una vez alaño y otras, más grandes, una vez cada dos años.

Un beneficio lateral es disminuir la presión por lasmodificaciones menores al existir una fecha conoci-da por todos para el rediseño de la solución.




TERCERA PARTE.PRÁCTICAS

TRANSVERSALES



JUAN BRAVO 180

Sencillez, claridad y elegancia son los sellos de los bue-nos programas; oscuridad, ingeniosidad y complejidad son indicaciones de un diseño inadecuado y un pensa-

miento mal orientado.

Richard Fairley




INTRODUCCIÓN

La administración del proyecto considera una grancantidad de acciones bien coordinadas que ayudan alograr el todo, en este caso, un proyecto exitoso. Esun efecto sinérgico.

Se trata de prácticas transversales que influyen entodas o en la mayoría de las etapas del proyecto31 (de(de hecho,).

Estas prácticas se aplican en la fase deestudio y luego deben quedar

incorporadas en el plan de proyecto, en la forma de planes específicos.

Las mejores prácticas en proyectosEstas prácticas surgen justamente de observar lasmejores prácticas en buenos proyectos.

Cada una puede ser tan extensa como se desee y hasido un esfuerzo resumirlas.

La mayoría de ellas están detalladas en los libros delautor señalados en el prólogo y hacia el final de laintroducción.

31 Una pregunta habitual en evaluaciones acerca de este método esalgo así: ¿Cómo aplicaría una práctica transversal en cada etapa?…



JUAN BRAVO 182

Ordenamiento de las prácticas

Las prácticas se han ordenado de acuerdo con el cri-

terio de mayor uso, comenzando por aquellas queindudablemente deben estar presentes en todas lasetapas. El resultado no señala precedencia, eso de-pende del método específico que la organizaciónadopte.

Este criterio de ordenamiento no pretende juzgar

niveles de importancia de cada práctica, porque cadauna tiene su espacio y quizá aunque su uso sea aco-tado a pocas etapas, es vital en ellas.

Definir una política por cada práctica

Cuando se trata de proyectos aislados y

no hay un método en la organización,cada práctica debería revisarse una por una para cada etapa.

Cuando hay una rutina de realizar proyectos y existeun método para realizar este tipo de proyectos en la

organización, la forma de trabajar con las prácticastransversales estará indicada en el método, en talcaso, la revisión es más general. Por ejemplo, lapráctica “definir herramientas para la etapa” proba-blemente estará definida como estándares corporati-vos o, al menos, como una política…

Es importante considerar que:




• La aplicación de cada práctica transversal a unproyecto debería ser una particularización de la

políticax correspondiente.• La política de cada práctica debe estar siempre

actualizada.

• La participación de todos es vital en el contenidode las políticas, porque es lo que verdaderamenteaplicará la organización

Llevar a la Carta Gantt

Fruto del análisis de cada práctica,surgirán múltiples acciones a realizar que

deberán incluirse en la Carta Gantt. Esees el resultado concreto a donde conduce

la revisión de las prácticas transversales.

Por ejemplo, en el control de cambios es necesariocontemplar el tiempo de negociación del jefe delproyecto con el usuario, independiente de que elcambio se realice o no.

¿Podría llegar a ser el 20% del presupuesto para loscambios? Puede ser, depende de la organización, poreso es necesario disponer de una base de datos deestándares numéricos.

Base de datos de estándares numéricos

Desde la base de datos de estándares numéricos ob-tenemos el dato de cuánto tiempo y costo presupues-



JUAN BRAVO 184

tar, por ejemplo, para el tiempo de negociación deun cambio.

También en esta base de datos deberían incluirseestos estándares:

• Plazo máximo de proyectos.• Tasa de descuento y plazo para evaluación de

proyectos.• Valor hora de los clientes (US $ 4 dólares pro-

medio hemos usado en algunas organizaciones)• Rutina acerca de cuáles ítemes incluir en el añocero o uno de un flujo de caja.

• Costos de movimientos internos y externos demercaderías.

• Valor hora promedio de los ejecutivos, de losprofesionales, mando medio y personal operativo

para efectos de cuantificar las propuestas, en par-ticular el ahorro que se puede generar (recordarmultiplicar por un factor también estándar res-pecto al valor que cada persona agrega, conser-vadoramente unas 5 veces la renta bruta).

Y muchos más…

¿Cuáles prácticas incorporar en un proyecto?

La tabla de la siguiente página es un ejemplo deltipo de ejercicio que debería hacer un jefe de pro-yectos o un analista de estudios respecto a queprácticas incorporar en cada etapa del proyecto. Esto

dependerá del proyecto mismo y de la política decada práctica.




Etapas Método GSP

Prácticas Transversal C F A D I D O

1 Dirección del proyecto x x x x x x x

2 Plan de la etapa x x x x x x x

3 Exposición de los planes x x x

4 Retroalimentación x x x x

5 El equipo de trabajo x x x x x x x

6 Entrevistas x x x

7 Comunicación x x x x x x x

8 Informes x x x x x

9 Técnicas x x x x x

10 Herramientas de apoyo x x x x

11 Trazabilidad x x x x

12 Quick Wins x x x x x

13 Costos y Duración x x x x x x x14 Gestión de Riesgos x x x x x x

15 Gestión de la calidad x x x x

16 Responsabilidad Social x x

17 Inserción x x x

18 Orientación al Cliente x x x x

19 Sensibilización x x x

20 Capacitación x x x x21 Seguimiento x x x x x

22 Cuidar la solución anterior x x

23 Continuidad operacional x x

24 Plan de recursos físicos del proyecto x x x

25 Kill Time x x x x

26 Control de cambios x x x x

27 Gestión del cambio x x x x28 Gestión de proveedores x x x x



JUAN BRAVO 186

1. DIRECCIÓN DEL PROYECTO

La buena dirección del proyecto es, tal vez, lapráctica más relevante para el éxito del proyecto.

La dirección del proyecto es una visión yacción de conjunto de todas las

actividades necesarias para cumplir conlo prometido, particularmente en calidad,

eficiencia, eficacia, satisfacción delcliente, plazos y costos.

Motivar, comunicar, liderar y alinear intereses resul-tan esenciales.

Facilitadores del trabajo del líder del proyecto :• Que tenga dedicación completa y una visión cla-

ra de los objetivos del proyecto.• El apoyo de la alta dirección, el nivel de auto-

nomía y la facilidad para acceder a la toma dedecisión fluida en relación al proyecto.

• Su competencia en trabajo en equipo y liderazgo.• Desarrollar el espíritu de equipo y el profesiona-

lismo de su gente.• Gestionar los riesgos.• Comunicar el proyecto con frecuencia y dentro y

fuera de la organización, integrando a todo elequipo de trabajo, así se perfecciona el mensaje,se aclara a sí mismo y gana en retroalimentación.

• Reencantar cada cierto tiempo a su equipo.

• Cambiar las creencias limitantes en el equipo detrabajo: no se puede, el gerente no quiere, etc.




2. PLAN DE LA ETAPA

Una vez que está decidido realizar una etapa, es ne-cesario detallar el plan de la misma (duración, en-cargado, costo de la etapa, documentos de licitaciónque será necesario construir, etc...) más allá del plande proyecto.

Se trata de comenzar cada etapa

revisando el plan de la misma etapa y talvez replantear el plan general del resto del proyecto.

Se hace una programación detallada de la etapa,con fechas precisas e incluso horarios en algunoscasos. El plan de la etapa puede ser el único plan

que existe, como en el caso de la factibilidad (por-que todavía no hay proyecto).

Siempre implica una revisión del plan general delproyecto. Son re-estimaciones a la luz del avance.

Es conveniente considerar que en cualquier etapa sepuede cancelar el proyecto o volver a una etapa an-

terior, por ejemplo, si se detectó algo no consideradoo si hubo un cambio relevante en el entorno para elpar problema-solución.

Una recomendación: asegúrese que lo definido en laetapa anterior sigue siendo válido, especialmente sipasó mucho tiempo entre etapa y etapa.

Por supuesto, el plan de la etapa debe ser aprobadopor la instancia de decisión que corresponda.



JUAN BRAVO 188

3. EXPOSICIÓN DE LOS PLANES

Se trata de exponer y discutir el plan de trabajo atodos los actores relevantes, al interior y exterior del equipo de proyecto.

Es conveniente porque surgirán muchas sugerenciaspara lograr éxito en el proyecto. En el fondo, lo másimportante es la retroalimentación que se logra.

Al exponer los planes a todos los actoresrelevantes se mejora la coordinación del

proyecto.

Aquí tienen especial relevancia las competencias delequipo de trabajo para exponer a un grupo de perso-nas en forma clara y precisa.

Son competencias de comunicación, personales encuanto a desarrollar un mensaje y técnicas en cuantoal uso de herramientas, tal como un software tipoPower Point, un proyector, un puntero láser, etc. .

La exposición es uno mismo. Al comienzo la aten-ción está puesta en cómo uno se ve, habla, mueve,

gesticula, viste, entona, etc. es el efecto de la prime-ra impresión. Para comenzar: hay que disfrutarlo,sino, ¿para qué estamos ahí? Es indispensable lafuerza, la pasión y la energía en lo que se transmite.

Algunas recomendaciones: 1) preparación del tema,2) presentación personal, 3) buena dicción, 4) len-guaje formal, 5) manejo del tiempo, 6) llegar al me-nos media hora antes, 7) cumplir los tiempos.




4. RETROALIMENTACIÓN

Se trata de revisar el resultado logrado respecto a loplaneado para la etapa. Se comunican los resultadosal resto del equipo y las conclusiones quedan dispo-nibles para toda la organización.

Practicar la retroalimentación es preguntarnos, ¿quéaprendimos?, ¿qué aprendí?… individualmente o engrupo, en un proceso continuo. Si tuviéramos quehacer nuevamente el mismo trabajo de la etapa,¿cómo lo haríamos?, ¿qué cambios introduciríamos?

Retroalimentar es una práctica que debe incluirsetanto al término de cada etapa como al finalizar elrediseño de cada proceso y al completar el proyecto.

También contempla preguntarnos si se están resol-

viendo las necesidades originales actualizadas.

El espíritu de este punto es detenernos,reflexionar… aprender y seguir.

Esta es una práctica que enlaza con la gestión delconocimiento, porque las conclusiones que se deri-

van de las sesiones de retroalimentación deben sercompartidas y adecuadamente archivadas en mediosdigitales. De esta forma el aprendizaje pasa a serpatrimonio de la organización.

No existe enseñar, solamente existe aprender y enesto ya sabemos que la emoción juega un rol funda-mental, el aprendizaje debe darse en el afecto, esta-bleciendo vínculos con las personas y con las ideas.



JUAN BRAVO 190

5. EL EQUIPO DE TRABAJO

La práctica más habitual es formar un equipo de tra-bajo por cada etapa, manteniendo un núcleo de par-ticipantes “permanentes” durante el proyecto.

Se trata de formar un equipo integrado por especia-listas en rediseño de procesos, informática, usuariosejecutivos y consultores —se gana el “efecto consul-tor”, una mirada externa fresca—, según el tipo deproyecto. Debe estar claro quién es el director delproyecto. La participación de los ejecutivos es vital.

Normalmente se designa un usuario líder (represen-tante de los demás usuarios) y usuarios clave de ca-da área a rediseñar. El usuario líder trabaja coordi-nadamente con el jefe del proyecto.

Es probable que cambien integrantes delequipo de trabajo según sus competencias

para la etapa.

Algunas claves:• Crear espíritu de equipo y fomentar el profesiona-

lismo con acciones concretas.• Asegurarse de la disponibilidad de tiempo de ca-da integrante para este equipo.

• Revisar la asignación de elementos de apoyo: PC,licencias, lugar físico, escritorios y otros.

• Revisar roles, por ejemplo, para: redactar infor-mes y coordinar su entrega, coordinar la retroali-

mentación y entrega de los resultados, definir yrealizar el plan de entrevistas.




6. ENTREVISTAS

Una práctica frecuente en los proyectos es la realiza-ción de entrevistas a usuarios, ejecutivos y personasde fuera de la organización. La finalidad principal eslevantar información útil al proyecto y se comple-menta con otras técnicas (encuestas, informes deconsultoría, de auditoría, etc.).

Al comenzar la etapa debe elaborarse el plan de en-trevistas. Luego debe prepararse cada entrevista,anticipando lo que se pueda utilizar. Vital es el pre-paración, la buena ejecución y el análisis posteriorpara incorporar las conclusiones al proyecto y cum-plir los compromisos adquiridos.

Durante la entrevista lo principal es crear

ambiente, es decir, un clima de confianzacon una actitud serena que surge de la

puntualidad, preparación y presentación(las tres P de las entrevistas).

Escuchar, más que hablar. Practicar tacto, cortesía ysobre todo, naturalidad. Hacer preguntas en positivo,

por ejemplo, ¿cómo le gustaría que fuera?, ¿quéquiere usted para la empresa?, ¿cómo sería el fun-cionamiento del proceso que usted propone?, ¿cuáles el ideal?, ¿por qué?… este tipo de preguntasabren nuevas posibilidades y apuntan al cambio.

Evitar caer en la “trampa de la complicidad”, es de-

cir, recibir secretos de los entrevistados o escucharconfidencias que no se pueden comunicar.



JUAN BRAVO 192

7. COMUNICACIÓN

Se trata de comunicar el proyecto al interior y exte-rior de la empresa, con mensajes adaptados según eltipo de interlocutor (no es lo mismo comunicar a ladirección que a los funcionarios administrativos o alos clientes). Es conveniente comunicar mucho.

Esta sola actividad implica disponer de horas de es-pecialistas en comunicación, con dedicación parcialo total según la envergadura del proyecto.

Incluye la formación de diferentes tipos de mesas deayuda según la etapa del proyecto.

Se puede comunicar a nivel de problema ya nivel de solución, es una actividad

completamente transversal.Incluye todo el aspecto de presentación y exposiciónde los proyectos, desde la forma de presentar hastael desarrollo de la competencia de saber exponer delos integrantes del equipo.

Un aspecto vital es la preparación del equipo de tra-

bajo en el manejo de la emoción, particularmente alinterior del equipo de trabajo. De hecho, es unapráctica regular en empresas con una larga historiade proyectos exitosos realizar talleres de trabajo enequipo antes, durante y después del proyecto. Unaexcelente práctica es aplicar la escucha empática.

Todo comienza por comunicarse bien entre sí y unaconsecuencia es lograr lo mismo con los demás.




8. INFORMES

Cada etapa tiene uno o más entregables que debenquedar registrados en informes. En el plan detalladode cada etapa deben quedar resueltos aspectos talescomo: ¿quién redacta qué informe?, ¿a quién se leentrega?

La práctica genérica es documentar e implica el de-sarrollo de las competencias mínimas en el equipode trabajo (que es preferible no dar por adquiridas),por ejemplo: redacción, ortografía, capacidad desíntesis, etc. Al menos la habilidad de leer.

Por supuesto, debiera documentarse almismo tiempo que se avanza en la etapa,evitando postergar.

La estructura debe ser parte de los estándares de laorganización, una propuesta del método GSP es:

A) Resumen ejecutivo. Es la primera parte del in-forme y contiene los resultados centrales, es de-seable que tenga solamente una página de exten-

sión. Se sugiere: objetivo, resumen de antece-dentes, conclusiones y recomendaciones.B) Detalle de Antecedentes. Se incluyen los docu-

mentos relevantes, el plan original, los antece-dentes de la ejecución y de la retroalimentación.

Es importante el registro ordenado de los hechos, locual facilita la trazabilidad, el aprendizaje y la cali-

dad. La extensión es cuestión de estándar y de crite-rio, el Justo Medio está bien, ni mucho ni poco.



JUAN BRAVO 194

9. TÉCNICAS

Se trata de seleccionar las técnicas a emplear en ca-da etapa del proyecto, por ejemplo, la forma de rea-lizar la ingeniería de requerimientos.

Sabemos de que técnicas podemosdisponer en cada etapa de un proyecto de

Procesos y Tecnología, sin embargo, la

variedad es tan amplia que el método dela organización debe pronunciarse.

Algunas técnicas en cada etapa:• Concepción: planificación estratégica, diagnósti-

co, mapa de procesos, FI, técnica de los por qué,causa efecto de Ishikawa y Pareto. Idealización.

• Factibilidad: evaluación financiera, CPM, PERT,Carta Gantt, técnicas de creatividad.• Análisis: UML, gestión de procesos, enfoque

sistémico, análisis estructurado, análisis orienta-do al objeto, modelo conceptual y de datos.Técnicas de creatividad.

• Diseño: diseño clásico, diseño estructurado, di-

seño orientado al objeto y aplicación amplia de lareusabilidad, estándares.

• Implementación: programación orientada a obje-tos, Testing, generación automática de código,programación, XP, HTML y XML

• Despliegue: instalación automatizada y técnicasde comunicación

• Operación: benchmarking, mejora continua.




10. HERRAMIENTAS DE APOYO

Se trata de seleccionar herramientas de apoyo a lastécnicas que se usarán en cada etapa. También lla-madas CASE (desarrollo apoyado por computador),por ejemplo, de tipo32: MS Project, Visio, Aris, Cor-porate Modeler, M1, Z4, Rational, ERWIN, etc. Loimportante es que la organización tenga una defini-ción al respecto.

Pueden ser ayudas en la construcción de prototipos,flujo de un proceso, interfaz visual, modelo concep-tual, casos de uso y cualquier otro tipo de modelo.También para cooperar en la planificación estratégi-ca, el control de costos y la evaluación financiera,entre otras posibilidades.

Se pueden emplear diferentes herramientas de apoyoen cada etapa, esa es hoy la realidad. Sin embargo,existe una tendencia a unificar en una sola o en unpequeño conjunto de herramientas bien integradas,la ventaja es la facilidad para acceder a los modelos,su actualización y la trazabilidad.

Una aspiración de las herramientas deapoyo es que actúen a nivel del ciclocompleto, incluyendo la generación decódigo cuando corresponda.

32 MS Project y Visio de Microsoft, Aris de SAP, Corporate Mode-ler de Case Wise, M1 y Rational de IBM, Z4 de Tuxpan, ERWINData Modeler de Computer Associates.



JUAN BRAVO 196

11. TRAZABILIDAD

Trazabilidad se entiende en dos sentidos:a) Trazabilidad de las transacciones, donde se pue-

de seguir la pista de cómo se va actualizando in-formación, siempre mediante transacciones for-males y presentes, desde la creación de un dato,por ejemplo, un saldo de inventario.

b) Trazabilidad del desarrollo, donde se pueda se-guir la pista a cada requerimiento implementado,cómo fue diseñado, el análisis que le dio forma,quién lo gestó, por qué, etc.

Es como la trazabilidad de la fruta, dondeel objetivo es que una clienta de un

supermercado en Europa pueda saber queel durazno que adquirió viene de Chile(importador, exportador, puerto, etc.) y de

un lote específico con detalle del lugar, fertilizantes, suelos, etc.

En la trazabilidad los modelos principales deben

estar permanentemente actualizados. Significa que sies necesario realizar un cambio en la solución im-plementada se actualiza toda la serie de modelos quedio origen al producto, al menos desde el análisis yeventualmente desde la misma necesidad que dioorigen al requerimiento.

Lo cual no es lo mismo que llevar un registro histó-

rico de todos los cambios a la solución (también ne-cesario) un simple repositorio.




12. QUICK WINS

Se llama Quick Wins —literalmente ganancias rápi-das— o Hits a cambios de breve diseño e implemen-tación y que tengan un buen nivel de impacto en elavance de la solución. Son entregables de acciónrápida, generalmente acciones simples que fueronquedando en evidencia desde las primeras conversa-ciones.

Gracias a estas acciones tempranas se venresultados a corto plazo y se alienta tantoa los operadores del proceso como a ladirección a continuar con el proyecto,renovándose la motivación y manteniendola atención en el proyecto.

Un subproducto del trabajo en las etapas prelimina-res (concepción, factibilidad y análisis) es detectarQuick Wins.

La práctica transversal de la sensibilización se prestapara organizar talleres donde los mismos usuariosoperativos proponen ideas de cambio en los proce-

sos (ver anexo 7, caso BancoEstado)Una precaución es no abusar de esta vía rápida, parano caer en el exitismo de corto plazo y confundir alresto de la organización. Es razonable hacer cuantoantes los cambios que se pueden hacer, sin provocarla expectativa de que lo siguiente será igual de fácil

o rápido.



JUAN BRAVO 198

13. COSTOS Y DURACIÓN

Se calculan costos y duración tanto de la etapa comodel proyecto completo. Es importante y valiente verla realidad de lo que está sucediendo y reestimar sies necesario. No es cambiar por cambiar sino queadaptar el avance del proyecto a la realidad de hoy(imposible de predecir en su totalidad cuando seelaboró el plan de proyecto). Lo opuesto es cerrar

los ojos y tratar de cumplir un plan que tal vez notiene sentido. Ah... asegúrese que los fondos existen.

Se calculan costos cada vez más precisos del proyec-to en tres etapas: factibilidad, análisis y diseño.

Es necesario incluir costos ocultos talescomo la misma planeación de la etapa, las

reuniones de coordinación y denegociación y las exposiciones de avance,

entre otros.

Normalmente el costo mayor son horas profesiona-les, internas y/o externas. Se da una relación de de-pendencia entre costo y duración. Se requiere asig-

nar elementos computacionales, lugar físico y otrosrecursos. También el costo de las herramientas ylicencias de productos de software. Diferenciar in-versiones y gastos para efectos contables.

La duración de la etapa depende del proyecto especí-fico. Lo importante es que se encuentre acotada.

Considere el plazo de entrega como una murallainamovible, puede negociar todo lo demás.




14. GESTIÓN DE RIESGOS

Se trata de detectar riesgos y elaborar un plan paramitigarlos y/o traspasarlos. Por ejemplo, en la con-cepción: ¿conviene abordar el problema? A veces elsentido común (y los amplios estudios de Maturana,Echeverría, Varela y otros) indica que el solo hechode señalar un problema ya crea una expectativa. ¿Esel momento adecuado? ¿Y si no se llega a una con-

clusión? ¿Y si excede los plazos o costos?En la etapa de factibilidad: malas estimaciones deplazos, dejar de lado buenas soluciones, no conocerlo que el medio plantea, etc.

Cada etapa tiene sus propios riesgos que deben seratendidos: una tecnología difícil de obtener, especia-

listas escasos, cambio de prioridades, atrasos, costosexcedidos, incumplimiento de proveedores, tecno-logía difícil de implementar, usuarios que no deseanel nuevo proceso, apego irrestricto al plan, agota-miento, etc.

Se han identificado más de cien riesgos

asociados a los proyectos de procesos ytecnología, lo mínimo es tener formas dedetectar, transferir y/o neutralizar.

Una fórmula para priorizar riesgos: R = C x P. Lamagnitud del riesgo (R) se obtiene multiplicando elcosto si ocurre (C) por la probabilidad de ocurrencia

(P). Ofrece un límite a la inversión en el riesgo paramitigar o traspasar (libro Gestión de Procesos)



JUAN BRAVO 200

15. GESTIÓN DE LA CALIDAD

Cada etapa del proyecto debe llevar el sello de ges-tión de la calidad, al menos en:• Planeación, aseguramiento y control de calidad

(ver anexo 6).• Aplicar o definir estándares de gestión y deter-

minar como se cumplen.

Tan importante es la calidad que a veces se crea unárea de aseguramiento de la calidad —típicamentellamada QA— para ayudar a elaborar el plan de ca-lidad del proyecto, para la verificar el proceso deproducción y validar los entregables de cada etapa.

Existe todo un aporte de la gestión decalidad aplicada a proyectos, con una planificación, control y seguimiento.

El contenido técnico y toda forma de comunicacióndebe ser impecable. Se emplean fórmulas de exter-nalización de Testing cuando hay desarrollo de TI,por ejemplo, que el trabajo en el proyecto sea revisa-do por los pares del analista o por otros profesionales,

internos o externos, antes de presentarlo al mandante(quien lo encargó para tomar una decisión).

Se requiere la revisión del ciclo completo de activi-dades, así como el cumplimiento de los compromi-sos adquiridos con el cliente.

La Gestión de la Calidad exige fomentar al interior

de la empresa una cultura de calidad.




16. RESPONSABILIDAD SOCIAL

Veremos algunos elementos de la ResponsabilidadSocial (RS) específicamente aplicada a proyectos.

Es necesario manejar bien el temor de las personas de que este tipo de proyecto lasdejará sin empleo.

Establecer un pacto social o una alianza estratégica con los colaboradores es un excelente camino quehan aplicado empresas exitosas. Todos cooperan conel cambio necesario y la empresa no despide pormotivo de estos proyectos. No es justo ni necesariodespedir sólo porque queremos hacer de otra formalas cosas. Se puede evitar generando vinculaciones

con otros proyectos en un esquema de vasos comu-nicantes porque en la organización hay infinitosproyectos posibles, una parte libera recursos y la otrarequiere recursos, es cuestión de unir una cosa conotra, otra aplicación de visión sistémica.

Se requiere mantener al menos el nivel de servicioprevio al inicio del proyecto mientras este dure, tra-

bajar con eficiencia, alinear intereses, cuidar el en-torno y la comunidad, organizar el trabajo seguro yel buen trato, tanto de los profesionales internos co-mo de contratistas, evitando discriminar entre ellos,evitar la improvisación, hacernos responsables, pre-venir en todo los riesgos y calcular el VA (ValorActual) social, que refleja el efecto del proyecto enel medio, que debe dar positivo.



JUAN BRAVO 202

17. INSERCIÓN

El problema y la solución deben insertarse en untodo mayor —área, empresa, industria o gobierno—para comprender y alinear los respectivos intereses.

Insertar es observar cómo se relaciona el problema ola solución con otros problemas o soluciones dentroy fuera de la organización para, por ejemplo, transfe-rir recursos, alinear intereses, optimizar adquisicio-nes y manejar el aspecto político en cuanto al mejormomento de plantear el cambio.

Se debe monitorear la contribuciónactualizada de la estrategia del proyecto a

la estrategia de la organización.

Es necesario identificar los impactos del proyecto atodo nivel, especialmente en los clientes, para locual es ideal trabajar con criterio SCM (SupplyChain Management). La recomendación es suponerque nos quedamos cortos en estimar impactos paraestar preparados para efectos inesperados. Una for-ma de evitarlos al interior de la empresa es comuni-

car el proyecto a todas las áreas, incluso dondecreemos que no influye, así también mejoramos lasestimaciones. Al exterior de la empresa también esconveniente comunicar a una lista extensa.

En la inserción se trabaja con mapas, por ejemplo,de necesidades, procesos y proyectos, para identifi-

car interacciones (ver clave 1 de “Claves de la im-plantación de método en una organización”).




18. ORIENTACIÓN AL CLIENTE

Ya sea en el problema o la solución, la orientación alcliente es central para lograr la conclusión exitosadel proyecto.

Es vital escuchar y apreciar lo que es realmente im-portante para el cliente.

Ya indicamos que por cliente hablamos

del cliente externo, quien paga a todos enla organización.

Los usuarios internos son “socios” del equipo deproyectos en esta misión de servir mejor al cliente.Esto es central, ¿quién es el cliente del área de ges-tión de procesos? Respuesta incorrecta: la gerencia

de producción o de ventas a quien se atiende para elrediseño. Respuesta correcta: el cliente (sin apellidopara no introducir confusión).

El cliente de todos en la empresa es el cliente (aban-donamos aquí el concepto de cliente interno por lasdistorsiones que introduce).

Todo proyecto debe ser monitoreado en cuanto a suimpacto en el cliente, aunque aparentemente sea so-lamente interno, tal como una evaluación del des-empeño o la mejora de los procesos de compras.

Al igual que en el resto de las prácticas, esto implicaun plan para hacer factible el seguimiento y apreciarcuan importante es el proyecto para el cliente, desdesu inicio al término.



JUAN BRAVO 204

19. SENSIBILIZACIÓN

Es el manejo del cambio en lo que se refiere a emo-ción y sensibilización. El objetivo es encantar a los“afectados”.

La idea es aplicar lo aprendido acerca deencantar a todas las personas de dentro y

fuera de la organización que tienen

relación con el proyectoEs diferente a comunicar y capacitar, aunque secomplementa con esas prácticas. Se aplica medianteanticipación, participación, talleres —ver prácticaQuick Wins—y otras formas creativas (poleras, lápi-ces, etc.)

Hay experiencias concretas de proyectos fracasadosy otros que han aumentado en varias veces su presu-puesto original solamente por el mal manejo de lasensibilización, porque los usuarios no deseabanusar el sistema y hacían resistencia pasiva.

La declaración es muy precisa: los usuarios deben

querer usar la solución. Luego viene estar capacita-dos para su operación.

Una faceta de la sensibilización es la coherencia, esdecir, el equipo de proyecto debe estar sensibilizadoprimero, para que pueda transmitir la emoción deestar participando en un proyecto tan vital…

En el anexo 7 se presenta el resumen de un proyectobien implementado en el BancoEstado.




20. CAPACITACIÓN

La capacitación del equipo de proyecto debiera sercontinua durante todo el proyecto. Además, es unaexcelente oportunidad para coordinar lograr acuer-dos en los múltiples detalles de la necesidad..

El diseño de la actividad es central: lugar,objetivos, duración, relator, extensión y

muchos otros aspectos deben estar bien pensados.

La capacitación de los usuarios es vital en el proyec-to. Por supuesto, es diferente según tipos de usuariosy puede tomar variadas formas (la recomendación esuna combinación de posibilidades):

• Puede ser realizada por relatores profesionales,por sicólogos preparados en los mensajes delproyecto, por el equipo de proyecto, por usuariosque actúan como monitores, por ejecutivos, etc.

• Puede emplear variados medios creativas: Intra-net, e-learning, Internet, clases presenciales, vi-deos, teleconferencia, etc...

• Puede comenzar en etapas tempranas del proyec-to, se programa en detalle en cada etapa.

No tiene que ser extensa, aunque sí bien realizada,con preparación en pedagogía de quienes van a ca-pacitar. En especial, lo que ya sabemos de armonizarlas variadas dimensiones del ser humano: espiritual,

intelectual, emocional y corporal



JUAN BRAVO 206

21. SEGUIMIENTO

Realizar seguimiento es llevar control del avance delproyecto completo y en cada etapa. Se monitoreanvariables críticas del proyecto (costos, plazos, hitos,satisfacción de usuarios, calidad, etc.) Desde estepunto tiene relación con el diseño de indicadores.

Es necesario que exista algún nivel de

control centralizado y que el equipo dedirección del proyecto tenga lainformación inmediata del avance.

Como es sabido, es indispensable que la informa-ción para el seguimiento sea oportuna y confiable.Esto significa invertir en el seguimiento para tener

en todo momento la información actualizada, losindicadores que efectivamente se puedan monitore-ar, por el costo y el tiempo que significan.

Ideal sería un Cuadro de Mando del proyecto dondese viera “en línea” el avance del proyecto.

El sueño es una sala de control donde “se vea” el

avance de todos los proyectos de la organización,con las alertas correspondientes cuando algo se salede rumbo, por ejemplo, si el proyecto ya no es nece-sario para el usuario, se comienza a retrasar o losbuenos resultados son mucho mejores a lo esperado.

El seguimiento sirve para corregir desviaciones, parafortalecer un buen resultado e incorporar al método

de la empresa una buena nueva práctica.




22. CUIDAR LA SOLUCIÓN ANTERIOR

Cuidar la solución anterior significa que al mismotiempo que se trabaja en la nueva solución, se aplicaalguna forma de continuidad de lo existente. Inclusose sigue realizando mejora continua de la antiguasolución.

En algunas experiencias incluso se

designa un gerente líder de continuidad, almismo tiempo que otro gerente líder seencarga del proyecto de cambio.

Es una “estrategia tenaza”, donde un brazo corres-ponde al corto plazo (continuidad de lo existente) yel otro al largo plazo (el nuevo proyecto).

Es recomendable porque ofrece la tranquilidad de lacontinuidad en caso que el proyecto de cambio tengaalguna dificultad, desafortunadamente, una situaciónbastante frecuente De hecho, estos proyectos sontípicamente de alto riesgo, porque involucran unagran cantidad de variables, no todas fáciles de con-trolar: personas, procesos, estructura organizacional

y tecnología por un lado, costos y plazos por otro enun ambiente siempre dinámico.

Enlaza este camino con la necesidad de RS de man-tener al menos el nivel de servicio previo al iniciodel proyecto mientras este dure, dejando de lado laingenuidad de desmantelar lo que se tiene porque la

felicidad ya viene (la nueva solución).



JUAN BRAVO 208

23. CONTINUIDAD OPERACIONAL

Se refiere a incorporar en el proyecto los elementosque permitan una solución fuerte y robusta en lo quese refiere a la continuidad de las operaciones cuandoel proyecto esté en funcionamiento, más allá de sólotener 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 contingenciaen la continuidad de los productos y servicios.

• Minimizar interrupciones a las operaciones delnegocio y limitar la severidad de la interrupción.

• Minimizar pérdidas financieras.• Agilizar la restauración de los servicios y reiniciar

operaciones críticas en un tiempo breve.• Asegurar a los clientes la protección de sus inter-eses y mantener la buena imagen de la empresa.

La continuidad operacional estárelacionada con la seguridad de las

operaciones y la calidad de la información(La Superintendencia de Bancos e

Instituciones Financieras ha normado eneste sentido en Chile).

La Administración del Riesgo Operacional (ARO)es la guía. Según Basilea, el riesgo operacional es el“Riesgo de pérdida directa o indirecta causada poruna insuficiencia o falla de los procesos, gente y

sistemas internos o por un acontecimiento externo”.




24. PLAN DE RECURSOS FÍSICOS DEL

PROYECTO

El plan de recursos físicos se refiere a disponeroportunamente de los elementos que se requeriránen el proyecto: equipos computacionales, redes, li-cencias, escritorios, espacio físico, baños, comedo-res y otros.

Un trabajo bien hecho en materia derecursos físicos tendrá su nivel deinfluencia en la moral del equipo detrabajo… y en los plazos.

El plan considera no solamente indicar el requeri-miento sino también la forma de lograr el recurso

físico.También contempla quien se hace cargo de bienescuando corresponde, la administración de los recur-sos durante el proyecto y que sucede con ellos cuan-do este concluye.

Una buena alternativa es tener convenida alguna

forma de externalización tanto de la provisión de losrecursos como de su administración, ya sea comoplan A o B (el principal y el de contingencia).

Cuidar de no dejar de lado los aspectos contables yde formalización de esos recursos, especialmente ladistinción entre inversión y gasto entre ellos, por eldiferente tratamiento que implica.



JUAN BRAVO 210

25. KILL TIME

Un Kill time se define como “momento de cancela-ción del proyecto”.

Es decir, bajo qué condiciones conviene cancelar elproyecto, lo cual queda definido en el plan de pro-yecto y se revisa al inicio de cada etapa.

Por ejemplo, el proyecto se cancela si se consume el

presupuesto completo más un 10%, si la duraciónexcede un 10% al tiempo asignado, si hay un cambioimportante en las reglas del juego de una inversión osi una tecnología fundamental no estará disponible.Se aplica la sabiduría de que si el proyecto no ter-minó cuando debía o gastó más allá del presupuesto,lo más probable es que nunca termine.

Asumir los costos a tiempo acota las pérdidas a niveles que las organizaciones pueden soportar. Esperar puede poner en

riesgo su existencia.

La organización debe revisar las políticas al respecto

porque hay proyectos que deberían ser canceladospero continúan porque el equipo de trabajo y ejecu-tivos temen por las represalias. El resultado es unapérdida par la organización varias veces más que elcosto del proyecto33.

33

Es como la organización con cultura del terror y de búsqueda deculpables, con lo cual logran que todas las personas callen las defi-ciencias que observan (sobre todo las propias).




26. CONTROL DE CAMBIOS

El control de cambios tiene dos interpretaciones:durante el desarrollo y durante la operación.

Durante el desarrollo del proyecto son cambios enlas especificaciones. No hay problema si son necesa-rios, el método debe contemplar la facilidad de in-corporación cambiando la serie de modelos que daorigen a la solución.

Si se emplea desarrollo en espiral se facilita la incorporación de los cambios porque normalmente se incluyen en lasiguiente vuelta de la espiral.

Durante la operación de la solución se refiere a un

procedimiento para cambios menores, del tipo:• Emisión de una solicitud de cambio.• Recepción, autorización y estudio de impacto:• Se presenta el requerimiento al comité respectivo

con el plan de desarrollo, incluyendo equipo detrabajo y costos.

Por supuesto, un procedimiento de este tipo dependede muchos factores y actores (una mesa de ayuda,usuarios, dueños de la solución, etc.

Se realiza mejora continua de la aplicación hasta quese llegue a un nuevo ciclo de rediseño programadode la solución, recomendable cada dos años en pro-medio. Muchos cambios menores no fundamentales

pueden esperar hasta entonces.



JUAN BRAVO 212

27. GESTIÓN DEL CAMBIO

Esta práctica se refiere a la gestión del cambio en laspersonas. Está más al final porque varios de los ele-mentos de la buena gestión del cambio están con-templados en las practicas anteriores, tal como RS,sensibilización, capacitación, dirección del proyecto,exposiciones y entrevistas, entre otros.

Vital es incorporar en forma personalizada a todoslos actores relevantes —tal como predicaba F. W.Taylor con su administración científica, tipo Coa-ching hoy— distinto a la capacitación masiva.

La coherencia del equipo interno encuanto a su propia disposición al cambio

es vital para lograr la disposición al

cambio de los usuarios.

En todo sistema existe una fuerza natural que tiendea dejar las cosas tal como están, es el instinto deconservación del sistema, la homeostasis. Cuandouno reconoce la existencia de las fuerzas de resis-tencia al cambio, deja de criticar y efectuar luchas

estériles, ahora puede orientar su energía al cambiode carácter permanente: educación, autonomía yalineamiento de intereses, además de las accionesconcretas antes y durante la realización de un pro-yecto específico: anticipación y participación.

Otro elemento es la negociación, es decir, una con-

versación creativa destinada a lograr la más alta sa-tisfacción de los intereses mutuos.




28. GESTIÓN DE PROVEEDORES

Cada vez es más frecuente que en los proyectos par-ticipen personas y empresas externas a la organiza-ción. Es indispensable una buena gestión de ellospara el éxito del proyecto.

A veces se malentiende la gestión de proveedores, erróneamente se piensa en

tener una función que optimice solamenteel interés de la organización y “esquilme”a los proveedores (malos pagos, malascondiciones laborales, etc.) desconociendoque eso se volverá contra la mismaempresa.

Una verdadera gestión de proveedores va por el oro,como se enseña en los buenos cursos de negocia-ción, donde se maximiza el interés de la empresa yde los proveedores, mucho más allá de pagos justosy oportunos y buenas condiciones laborales. Se tratade lograr la mayor armonía en los intereses buscan-do aplicarse todos con el mayor entusiasmo y creati-

vidad al éxito del proyecto.Como parte de la buena gestión debe está la claridadde los objetivos de su trabajo, establecer condicionesigualitarias para trabajadores propios y de contratis-tas y requerimientos precisos (puede ser que el re-querimiento sea definir requerimientos).

Es ideal establecer alguna forma de alianza que ca-pitalice el aprendizaje en beneficio mutuo.



JUAN BRAVO 214

PARTE FINAL.CONCLUSIONES,

ANEXOS Y BIBLIOGRAFÍA




El que se enamora de la práctica sin ciencia es como elmarino que sube al navío sin timón ni brújula, sin saber

con certeza hacia donde va.

Leonardo da Vinci (Montaner, 2002, p. 83)



JUAN BRAVO 216

CONCLUSIONES

Los procesos de negocios constituyen la columnavertebral de la organización, la estructura en medio dela espontaneidad de la práctica.

Seely y Duguid (2001, p. 91)

En pocas palabras, es indispensable:

• Seguir método.

• Tener al menos instancias internas para estu-dios, metodología y toma de decisión.• No saltarse etapas.• Desarrollar políticas corporativas para aplicar

con la mayor eficiencia las prácticas transver-sales.

• Aplicar mejora continua del método (etapas y

prácticas transversales).Se requiere implantar correctamente el método, con-templando sus claves:

Clave 1. Visión de conjuntoClave 2. Mínimo indispensableClave 3. Participación de todos los actores

Clave 4. Iteración

Por supuesto, adaptar el método que sehaya dado la organización a cada

proyecto particular manteniendo untronco común.

En fin, para evitar costos innecesarios y ganar losbeneficios de proyectos bien realizados, es necesario




aplicar la Visión de Proyectos de Negocios, donde esvital alinear el propósito del proyecto con la estrate-

gia de la organización, cuantificar todo y orientar elproyecto al cliente.

Mucho éxito en la gestión de sus proyectos.

Le agradezco su lectura,

JBC



JUAN BRAVO 218

ANEXO 1. RELACIÓN CAUSAL

Existen varias técnicas asociadas a la detección decausas: árbol de decisión, técnica de los por qué yotras detalladas en el texto. Veremos aquí técnicacausa - efecto de Kaoru Ischikawa junto con la de-tección de prioridades de W. Pareto en una versiónque hemos venido utilizando en la detección de pro-blemas (de gestión de procesos y seis sigma), en la

detección de los riesgos de fondo en eventos depérdida de la administración del riesgo operacional yen la mejora continua.

La técnica causa – efecto se utilizaba principalmenteen el ámbito industrial y las “espinas” hacían refe-rencia a los temas relacionados: materiales, almace-namiento, etc. Aquí las “espinas” son los elementosdel modelos de negocios: estrategia, personas, pro-cesos, estructura organizacional y tecnología.

En este caso la aplicamos buscando el problema defondo de uno o más síntomas.

Estrategia TecnologíaEstructura

ProcesosPersonas

Síntoma(s)

Por ejemplo, para un síntoma de descuadraturas de

caja, en la línea “personas” se podría anotar, entreotras causas:




— Falta de capacitación— Escasa motivación

— Personas no idóneas— Dificultades entre colaboradores y jefe

Anotando más causas en las otras líneas nos acerca-remos poco a poco al problema real.

Lo habitual es anotar muchas causas, como en unatormenta de ideas.

Entonces, se detectan causas, se analizan y se priori-zan, indicando en que porcentaje influye cada unasobre el síntoma, riesgo o lo que sea que estemosanalizando. La fórmula es Y = F(x).

Se grafican y se lleva un acumulado, cuando se llegaal 80% se tiene el conjunto de causas más relevan-tes, los pocos críticos.

Se usa generalmente un gráfico acumulati-vo, donde el porcentaje de la siguiente cau-sa suma al acumulado anterior. Cuando lacolumna llega o pasa el 80%, hasta ahí llega la lista de causas relevantes.

El nivel de profundidad al cual se llega tiene que vercon la técnica de desarrollo en espiral y con el nivelde error aceptable para la organización en algún ni-vel de sigma.

Esta forma de trabajo es recursiva, puede ser necesa-

rio que una causa tenga a su propio análisis causal y



JUAN BRAVO 220

así sucesivamente. Es decir, X1 = F(x1), esquemacentral en la técnica Six Sigma.

A propósito de Six Sigma, en su libro Análisis de lacausa raíz, los autores Wilson, Dell y Anderson di-cen (1999, p. 6): “En Estados Unidos el 0.1% defallas significa: 16.000 piezas de correo perdidas porhora, 20.000 prescripciones de medicamentos inco-rrectas por año, 500 operaciones quirúrgicas inco-rrectas por semana, 50 bebés recién nacidos se les

caen a los médicos por día, 22.000 cheques deduci-dos de cuentas corrientes equivocadas por hora, sucorazón no late 32.000 veces por año”.




ANEXO 2. UML

UML es la sigla de “Unified Modeling Language”,literalmente: “Lenguaje Unificado de Modelamien-to”, aunque la idea queda mejor expresada al decir:

Modelamiento Visual del Software, expresión que seestá utilizando cada vez más en español.

UML está orientado a la especificación, visualiza-ción, construcción y documentación de los produc-tos de software. Se le considera como parte del desa-rrollo tecnológico de un modelo integral del cambio.

UML surgió de los aportes combinados de tres pio-neros en el campo del modelamiento orientado aobjetos, los doctores Grady Booch, Jim Rumbaugh eIvar Jacobson, a petición de la OMG (Object Mana-

gement Group), organización creada por las empre-sas líderes mundiales de la industria del software(entre las cuales se encuentran IBM, Unisys, Alcatel,Toshiba y Microsoft) destinada a fijar estándares enla industria con la tecnología de objetos.

UML incluye una amplia variedad de diagramas,entre los que se encuentran:

• Modelo Conceptual, para identificar conceptosdel mundo real y las asociaciones entre ellos.

• Casos de uso, para mostrar las interacciones conel usuario.

• Diagramas de estado para ilustrar el funciona-miento (la lógica de un caso de uso).



JUAN BRAVO 222

• Diagramas de instalación ( Deployment ) para mos-trar el mapeo del software en la configuración del

hardware.• Diagramas de interacción, tales como de colabo-ración (mensajes entre clases u objetos) y de di-seño de clases.

• Glosario: incluye la definición de todos los térmi-nos que se emplean en los modelos de UML, esaplicable en todas las etapas del desarrollo.

En UML se usa el término artefactos para referirse adiversas agrupaciones de modelos, a modelos indi-viduales o a cualquier elemento que sea identificadoindividualmente. Cuando en el contexto de UML seusa la palabra sistema, es porque normalmente hacereferencia al sistema computacional.

Casos de uso

Los casos de uso (use case) permiten mostrar lasinteracciones con el usuario. Tal como plantea IvarJacobson: “es una narración que describe la secuen-cia de eventos de un actor (agente externo) que utili-za un sistema computacional para completar un pro-

ceso”. También se puede ver como “cualquier puntode interacción con el computador”, principalmentedetectados desde las actividades del flujograma deinformación.

El caso de uso describe lo que importa al usuario,desde su perspectiva, es un ítem específico de fun-

cionalidad. El caso de uso describe el curso normalde los eventos, las excepciones son incorporadas




como observaciones al final del texto. Por ejemplo,si la narración dice: se ingresa la identificación del

cliente, no explicamos que sucede si esa identifica-ción es inválida, simplemente seguimos el cursonormal de los sucesos. En algunos casos, las excep-ciones podrían dar origen a otros casos de uso.

Se aplican a la definición de los requerimientoscomputacionales del sistema de información. Loscasos de uso pueden ser llamados:• De alto nivel, explicados en dos o tres oraciones.• Expandidos, pueden contener cientos de oracio-

nes, se incorpora una descripción minuciosa des-tinada a la implementación computacional.

Por ejemplo:

Un vendedor consulta por la información de un clienteen el terminal de una tienda minorista (dominio).

Incorpora el concepto de actor. Un actor es alguien oalgo fuera del sistema que interactúa con el sistema, eneste caso el vendedor.


Consultar situación

del cliente

Saldo de crédito y

posibilidades de cuotas.

Apoyo en realización decálculos respecto afinanciamiento

Terminal en la tienda

Vendedor


Consultar situación

del cliente

Saldo de crédito y

posibilidades de cuotas.

Apoyo en realización decálculos respecto afinanciamiento

Terminal en la tienda

Vendedor



JUAN BRAVO 224

ANEXO 3. RUP

Cabe agregar que los autores señalados en el anexo2 son también creadores de Rational Software Cor-poration (adquirida por IBM en el año 2003), desdedonde han propuesto el RUP (Rational Unified Pro-cess), un método completo para el desarrollo desoftware que rápidamente está siendo incorporadoen la industria informática.

Aunque RUP está dirigido al campo de la tecnologíade información, tiene muchos puntos de encuentrocon la gestión de procesos, de ahí la idea de incorpo-rar algunas líneas. Por ejemplo, está basado en lasseis mejores prácticas del desarrollo de software,muy cercanas a las propuestas de la tesis (en particu-lar los capítulos octavo a decimoquinto):

1. Desarrollo Iterativo (o en espiral). Se resuelvenprimero los casos de uso (o requerimientos) másimportantes, aquellos donde el riesgo es mayor.

2. Manejo de los requerimientos. Se seleccionan,organizan y documentan los requerimientos, seestablece una prioridad en base a riesgos. Se apli-

ca la técnica de casos de uso, donde se establecelo que importa para el usuario, incluyendo la in-terfaz.

3. Uso de una arquitectura de componentes. Esta-bleciendo una comparación con la ingeniería deconstrucción, esta etapa es la de arquitectura.

Aquí se establece la arquitectura de la solución desoftware, debe cumplir que el software sea fácil




4. de usar, funcional, de buen rendimiento, reusable,entendible, económico, factible, estético y elegan-

te.5. Modelamiento visual del software. Se aplicanaquí los modelos que provee el Unified ModelingLanguage (UML), el cual está orientado a la es-pecificación, visualización, construcción y docu-mentación de los productos de software.

6. Verificación de la calidad . Siendo la calidad uno

de los más graves problemas de la construccióntradicional de software, se propone incluir indica-dores de calidad y verificaciones en cada puntodel proceso de desarrollo. Se incorpora una laborde Testing en el ciclo de vida, en cada vuelta de laespiral.

7. Control de cambios. En un ambiente de crecientecomplejidad: múltiples desarrolladores, equiposde trabajo, instalaciones, versiones del software,proyectos y plataformas, se requiere un controlexplícito de requerimientos, configuración y me-diciones.

En este método, cada iteración acerca más el sistema

a lo que desea el usuario y a su plena funcionalidad,por otra parte, cada “versión” va quedando en fun-cionamiento real.

Mayor información puede encontrarse enwww.omg.org, www.rational.com, www.uml.com yotros sitios relacionados.



JUAN BRAVO 226

ANEXO 4. NORMAS DE CALIDAD DEL

SOFTWARE

La idea es revisar algunas normas de calidad desdelas cuales aprender buenas prácticas, además, untrabajo en gestión de procesos puede ser comple-mentario con la certificación.

Se revisarán brevemente las normas CMM, ISO

9000 y Tick IT (como ejemplo, muchas compañíasde éxito en la India34 se han adherido a una o más deestas normas). Un aspecto común a todas ellas es elcosto, del aprendizaje, de la certificación y de la in-fraestructura para cumplir la norma. También escomún el beneficio:

Que el proyecto se sitúe dentro de los plazos y cos-

tos previstos.Que el desarrollo sea de calidad.Que se pueda rastrear y que se pueda hacer una audi-toría de su cumplimiento.Que el desarrollo sea eficiente y eficaz.

34 En OECD (2000, p. 140) se aprecia el impacto de tecnologías comoCMM en la India, donde hasta 1998 se habían certificado 89 de las250 compañías “top” en la producción de software , otras 136 estabanen proceso de certificarse y sólo 25 compañías, el 10%, no tenía pla-

nes al respecto. Luego (ibid, p. 139) se precisa que la certificación essegún normas reconocidas internacionalmente, tal como: CMM delSEI, ISO 9000 y/o TickIT, una norma inglesa”.




CMM

CMM (Capabilitiy Maturity Model), traducido fre-

cuentemente como “Modelo de Madurez de Capaci-dades”, es la norma preferida en el desarrollo desoftware. Tiene niveles cada vez más exigentes quela organización candidata debe ir certificando.

CMM provee un detalle exhaustivo de cada nivel demadurez y no es difícil de interpretar. Incorpora todo

un sistema de mediciones a la madurez de la organi-zación respecto de las capacidades del desarrollo desoftware, lo cual facilita los procesos de evaluación.

Los niveles de madurez que señala CMM son cinco:

1. Nivel Inicial ( Initial): por omisión todas las em-presas están en esta categoría. Aquí se describe la

pseudoanarquía presente en el desarrollo. El pro-ceso de desarrollo es prácticamente inexistente.Se trabaja “apagando incendios” con esfuerzosheroicos. Existe inmadurez en el desarrollo. Noexiste visibilidad acerca del proceso de desarrolloni de los resultados del producto de software(tiempos, costos, errores, etc.).

2. Nivel Repetible ( Repeatable): en este nivel elproceso se puede repetir, existen técnicas y nor-mas comunes, hay seguimiento de costos, plazosy funcionalidad en los procesos.

3. Nivel Definido ( Defined ): el proceso de desarro-llo de software está documentado, estandarizado e

integrado.




Un punto de encuentro se está produciendo con lamasiva incorporación de la gestión de procesos al

desarrollo de software. Esta es una ventaja de laaplicación de las normas, su amplitud.

Actualmente se considera tan importante la gestiónde procesos que incluso fue considerada en la nuevaredacción de normas ISO, en las denominadas Nor-mas ISO 9000:2000. De hecho, la principal diferen-cia con las normas de la versión 1994 es la introduc-

ción del concepto de gestión por procesos interrela-cionados. En estas nuevas normas la gestión de cali-dad tiene un enfoque más integral y sistémico, locual también es pilar de este trabajo y de la gestiónde procesos en general. Incluso, se incorpora la me-

jora continua. Dice la nueva Norma ISO 9001:2000(p. vi): “Para que una organización funcione de ma-nera eficaz, tiene que identificar y gestionar numero-sas actividades relacionadas entre sí… Frecuente-mente el resultado de un proceso constituye directa-mente el elemento de entrada del siguiente proce-so… La aplicación de un sistema de procesos dentrode la organización, junto con la identificación e in-teracciones de estos procesos, así como su gestión,puede denominarse como «enfoque basado en pro-cesos»”.

Tick IT

Surgió en Gran Bretaña por las carencias que se de-

tectaron en las normas ISO 9000 orientadas a la in-dustria del software, tales como difícil interpretación



JUAN BRAVO 230

y aplicación, inexistencia de aspectos críticos deldesarrollo y de implementar en la forma de un pro-

ceso evolutivo. El encargado de realizar los estudiosy patrocinar la nueva norma fue el Departamento deIndustria y Comercio (DTI: Departament of Tradeand Industry). Actualmente el encargado de Tick ITes el DISC, oficina dependiente del British Stan-dards Institution (BSI) Standards Division.

Típicamente, un sistema de calidad Tick IT sigue

pautas como las enumeradas a continuación (las cua-les serían sujetos de revisión en una auditoría):

1. Elaboración de propuestas y revisión de contra-tos asegurando que todos los requerimientosestén bien especificados y que la organizacióntiene la capacidad para cumplirlos.

2. Análisis y especificación de los requerimientosdel sistema asegurando que sean revisados yacordados con el cliente.

3. Planeación, control y monitoreo del avance deldesarrollo respecto al plan comunicando a todaslas partes afectadas y que avise oportunamentede problemas potenciales.

4. Planeación de la calidad del proyecto, especifi-cando las inspecciones, revisiones y pruebas re-queridas durante el desarrollo.

5. Establecer políticas y objetivos de calidad gene-rales de la organización que sirvan para alinearlaen todas sus actividades, procedimientos y polí-ticas específicas.

6. Implantar y mantener un sistema de asegura-miento de calidad.




ANEXO 5. DESARROLLO EN ESPIRAL

DEL PROYECTO

El desarrollo en espiral es una técnica donde el pro-yecto de negocios abarca una porción cada vez ma-yor de los requerimientos y en cada iteración avanzaen calidad, eficacia y eficiencia.

Este método está dirigido a proyectos de cambio

mayor. Simplificando, también se puede aplicar aproyectos de cambio un poco menor, como en elbenchmarking o la mejora, aunque resultaría un po-co forzado.

Dice Steve McConnell (1996, p. 153): “El modelode espiral es un modelo de ciclo de vida orientado ariesgos que divide un proyecto en miniproyectos…

Se parte de una escala pequeña en medio de la espi-ral, se localizan los riesgos, se genera un plan paramanejarlos y a continuación, se establece unaaproximación a la siguiente iteración… Se avanzaun nivel en el “rollo de canela”, se comprueba quese tiene lo que se desea y después se comienza a tra-bajar en el siguiente nivel”.

Cada vuelta de la espiral es un ciclo completo dedesarrollo para el grupo de requerimientos seleccio-nados. En cada iteración la complejidad se incre-menta progresivamente y se reduce el riesgo. Porsupuesto, y al igual que en un proyecto tradicional,un desarrollo de esta naturaleza exige amplio esfuer-

zo de gestión y operación.



JUAN BRAVO 232

Se espera que una vuelta de la espiral demore entre

dos y diez semanas, para un rango de entre el 5% al20% de los requerimientos.

Esta es la nueva propuesta para los proyectos menosestructurados. La forma tradicional es la técnicallamada “desarrollo en cascada”, en la cual se pre-tende avanzar en cada etapa con todos los requeri-

mientos a la vez, en consecuencia, recién se ven re-sultados al término del proyecto, tal vez un año en elcaso de proyectos medianos.

En el desarrollo en espiral cada vuelta o ciclo es unpequeño “desarrollo en cascada”, porque pasa portodas las etapas, aunque para un número relativa-mente pequeño del total de requerimientos.

Al término del proyecto (después de todos los ci-clos) se recomienda incorporar la mejora continua(ver etapa 7 del método).

Rediseño de procesosen espiral. Cada vuel-

ta de la espiral es unciclo completo detrabajo para un grupode requerimientosseleccionados.




ANEXO 6. GESTIÓN DE CALIDAD EN

PROYECTOS

Es un tema fundamental abordado por todos losmétodos existentes, por ejemplo, en el PMBOK delPMI36 (Project Management Institute) dicen:

La GCP (Gestión de Calidad en Proyectos) incluyelos procesos requeridos para asegurar que el pro-

yecto satisfará las necesidades por las cuales fueiniciado, contempla: planificación de la calidad,aseguramiento de la calidad y control de calidad.

• La Planificación de la calidad implica identifi-car qué estándares de calidad son relevantes pa-ra el proyecto y luego determinar como satisfa-cerlos.

• El Aseguramiento de la calidad consiste de todaslas actividades, planificadas y sistemáticas, im-

plementadas en el marco del sistema de calidad,requeridas para brindar confianza en que el

proyecto va a satisfacer los estándares de cali-dad relevantes.

• El Control de Calidad implica verificar los re-sultados específicos del proyecto para determi-nar si estos cumplen con los estándares de cali-dad relevantes e identificar maneras de eliminar las causas de los resultados insatisfactorios.

36 Ver también el anexo 9.



JUAN BRAVO 234

Se complementa con la definición en la Iso9000:2000 “Calidad es la totalidad de las caracterís-

ticas de una entidad que le confieren la aptitud parasatisfacer las necesidades implícitas y establecidas”.

Ver también anexo 9.




ANEXO 7. CASO BANCOESTADO

Detallado en el libro Gestión de ProcesosSe seleccionó el proyecto Centralización de Proce-sos de Sucursales porque los resultados obtenidosson impresionantes:

• Fueron liberadas 1.100 personas destinadas al Back-Office, lo cual significa una importante cifra

de ahorro en remuneraciones.• La aplicación de responsabilidad social es amplia,ninguna de estas personas fue despedida, se rea-lizó una reconversión en gran escala que permitióreforzar grandemente el área comercial y de ser-vicio al cliente. Un dato puede bastar para enten-der la magnitud del esfuerzo: las colocaciones en

el mercado chileno de créditos de consumo pasa-ron 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 por-centaje superior al 80%.

• Se trató de un proceso ampliamente participativo,

donde los mismos trabajadores señalaban mejorasque eventualmente significaban eliminar su pro-pia función.

• Se realizó un pacto social con los trabajadorespara evitar el temor al despido.

• Se contó con la colaboración del sindicato de laempresa.




ANEXO 8. ITIL

ITIL (Information Technology Infrastructure Libra-ry) se traduce como “Biblioteca de Infraestructurade Tecnologías de Información”. Una traducción noliteral es Cumplimiento de niveles de servicios en TI con base en una serie de libros (unos 60 a fines delos ochenta) con las mejores prácticas.

Todo surge de los bajos estándares de servicios TIen el Reino Unido (similares a los de otras latitu-des), principalmente los que se refieren a los servi-cios a usuarios durante la etapa de operación (másdel 80% del total). Por lo tanto, se encargó al CCTA(Central Comunications and Telecom Agency) unapropuesta. La respuesta fue ITIL, la cual poco a po-co ha ido ganando terreno como referente en elcampo de los servicios TI.

El objetivo es la mejora en la atención de los clien-tes y usuarios y la reducción de costos y riesgos.

ITIL documenta buenas prácticas para lo que deno-mina los 6 componentes del Soporte del Servicio:

• Gestión de Configuración• Mesa de Servicios• Gestión de Incidencias• Gestión de Problemas• Gestión de Cambios• Gestión de Difusión

Tiene cierto parecido con CMM en los niveles demadurez respecto a la calidad de los servicios TI:



JUAN BRAVO 238

existencia de pre-requisitos mínimos, intento de ges-tión, capacidad de proceso, integración interna, pro-

ductos, control de calidad, información de gestión,integración interna e interfaz.

Son propuestas de amplio sentido común, tal comola de administrar una base de datos de ítemes deconfiguración: elementos de software, hardware,documentación, etc. Incluyendo su estado y relacio-nes, base a su vez del análisis de incidencias y pro-

blemas.




ANEXO 9. PMI

PMI son las siglas del Project Management Institute,una organización de clase mundial que recoge lasmejores prácticas para la realización de proyectos ylas presenta en documentos, uno de los más relevan-tes es el PMBOX.

El PMI define 5 grandes fases para todo proyecto:• Iniciación• Planificación• Ejecución• Control• Cierre

En forma equivalente a las prácticas transversalesdel método GSP, se definen nueve áreas de conoci-

miento: Integración, Alcance, Costo, Tiempo, Cali-dad, Recursos Humanos, Comunicaciones, Riesgo yAbastecimientos.

Son grupos de criterios generales para la buena ges-tión y administración de proyectos.

Existe una organización local en la mayoría de los

países de Latinoamérica, son llamados “Capítulos”.Es posible lograr la certificación del PMI.

Más en www.pmi.cl ó www.pmi.com ówww.pmi.org.

Ver también anexo 6.



JUAN BRAVO 240

ANEXO 10. MODELO PARA CASO DE

NEGOCIOS

Este es un modelo para plantear un proyecto, se le llama casode negocios porque el beneficio debe ser positivo, para locual 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 másbeneficios que costos. En el caso de negocios se explicitan

esos costos y beneficios.El caso de negocios se realiza en la etapa de factibilidad delmétodo GSP y es llamado Plan de Proyecto cuando está apro-bado.

Incluye, por trazabilidad, todo lo realizado a la fecha en laetapa de concepción y en la misma factibilidad, tal como elestudio de alternativas desechadas.

Parte I. Necesidad y soluciónA. Respecto a la necesidad (oportunidad o problema)

Enunciado de la necesidad: se refiere al problema de fondo

Proceso: dónde se detecta la necesidad

Dueño:

Quién Detecta:

Descripción de la situación: puede adjuntar textos, gráficos y otrosantecedentes para entender la necesidad

Análisis de causa – efecto: exponer acerca de los síntomas, el pro-blema de fondo y sus causas

Costos Internos: del problema o de oportunidad por la necesidadinsatisfecha

Costos Externos: del problema o de oportunidad por la necesidad

insatisfecha, considera la cadena logística. Se refiere a costos de losgrupos de interés por la existencia del problema, por ejemplo, el




costo que asume el cliente cuando se le hace esperar o el del provee-dor cuando se la paga tardíamente

B. Impacto estratégico del problema o necesidad

Cómo afecta a las definiciones estratégicas de la organización:

C. Descripción de la solución seleccionada (con las observacionesdel Comité de Estudios)

Descripción general: puede adjuntar antecedentes de la soluciónpropuesta: planos, folletos, etc.

Beneficios y costos internos: VAN

Beneficios y costos externos: puede ser llamado VAN social

Aporte estratégico: Principalmente respecto de la definiciones es-tratégicas de la empresa y en particular de procesos y tecnología

Imagen: mayor o menor aporte a la imagen de la empresa

Duración del proyecto

Beneficios laterales: (internos y externos)

Solución completa: Si resuelve o no íntegramente la necesidad

Alternativas estudiadas: Incluya aquí:1) Lista de opciones creativas que fueron exploradas2) Lista de las alternativas que fueron formalmente estudiadas y

por qué fueron desechadas. Adjunte el estudio de cada alternati-va estudiadaRestricciones de la solución

D. Detalle de cómo se ven afectadas otras áreas, procesos, sistemascomputacionales y otros efectos (internos y externos)

Áreas

Procesos

Sistemas



JUAN BRAVO 242

Otros efectos

E. Detalle de costos de la alternativaPor ejemplo:

Infraestructura

Hardware y Software

Implementación

Recursos Internos (RRHH,

Insumos, Otros)Detalle todos los costos

F. Alcance de la alternativa de solución

(lo que incluye y lo que deja afuera)

G. Objetivos específicos del proyecto y metas

Por ejemplo:

Objetivos Específicos Metas

1.

2.

Para cada objetivo específico podría haber más de una meta

H. Requerimiento principales del Modelo integral del cambio

Situación Actual:

Estado deseado:

I. Concepto detrás de la solución

Generalmente una solución responde a una conceptualización (laintegración a la cadena logística, la integralidad, el funcionamientode procesos solamente en la Web, etc...)




Luego, cómo este concepto afecta a los medios principales para elcambio: personas, procesos, estructura organizacional y tecnología.

J. Actores del proyecto (detalle de la estructura del proyecto). Inclu-ye, dentro de lo posible, los nombres de los actores

Encargados técnicos del proyecto

Gestor de la demanda

Prestador del servicio (interno o externo)

Parte II: Prácticas TransversalesEstas prácticas debieran surgir de políticas de la organizacióny del análisis de las mejores experiencias, internas y externas(ver parte 3, libro Gestión de proyectos de procesos y tecno-logía). Desde aquí surgen muchas actividades que luego irána la Gantt.

1. Dirección del proyecto

2. Plan de la etapa3. Exposición de los planes4. Retroalimentación5. El equipo de trabajo6. Entrevistas7. Comunicación8. Informes9. Técnicas, tipo UML, MP, FI

10. Herramientas de apoyo:11. Trazabilidad12. Quick Wins13. Costos y duración14. Gestión de Riesgos: Internas y Externas15. Gestión de Calidad16. Responsabilidad Social17. Inserción

18. Orientación al cliente19. Sensibilización



JUAN BRAVO 244

20. Capacitación21. Seguimiento22. Cuidar la solución anterior

23. Continuidad Operacional24. Plan de recursos físicos del proyecto25. Kill Time26. Control de cambios27. Gestión del cambio28. Gestión de proveedores

Parte III. Forma de abordar las actividades

Puede ser desarrollo en espiral por ejemplo. De ésta defini-ción dependerán los ciclos.

Estado de avance global

Etapa o Hito(global)

Producto / resultado

Fecha de cum-plimiento

Fecha real decumplimiento

Ciclo Nº 1 Según InformeAdjunto

Ciclo Nº 2 Según InformeAdjunto

Ciclo Nº … Según InformeAdjunto

Ejecución presupuestaria (M$)

Períodos Ppto.

Gasto

Gasto

Real

% Ppto.

Inversión

Efectiva %

Ciclo Nº 1

Ciclo Nº 2

Ciclo Nº .

TotalProyecto

…

Nota: el ciclo aplica cuando el proyecto se ha dividido enperíodos y fases, como en el desarrollo en espiral




Carta Gantt

Se requiere una malla de actividades que permita visualizar el

proyecto integral y resolver aspectos de precedencia, holguray ruta crítica.

AnálisisDiseño

ImplementaciónDespliegue

Mejora continua

En algunos proyectos aplica desarrollo en espiral, en otros no,si aplica, cada vuelta de la espiral sería una fase que tendríaAnálisis, diseñó, implementación y despliegue.

Compromiso

Firmas de Jefe de Proyecto, Dueño y Gerente de Área

A llenar por el Comité de Procesos y Tecnología

Decisión:

Proyecto

Designa Jefe de Proyecto Designa Usuario líder

(La estructura necesaria)

Fecha inicio del proyecto Fecha de término del proyecto

Prioridad Fuente de fondos

(alta media baja)

Firma en representación del Comité de Proyectos

Fecha

Notas:

• El objetivo del formulario es planear el proyecto endetalle.



JUAN BRAVO 246

• Pueden presentar este formulario los integrantes de laorganización (con la formación correspondiente) de-signados para ello por el Comité de Procesos y Tec-

nología• El número del proyecto es el mismo de la detección

de la necesidad, porque el proyecto existe para resol-verla (puede suceder que surja un proyecto mayorcon diferentes partes, todas deberían ser coordinadaspor el mismo jefe o líder del proyecto).

Adjunte todo documento generado en el proyecto o en el es-

tudio de la necesidad.




BIBLIOGRAFÍA

BOOCH, G. (1991): Object Oriented Design with Applications.USA, The Benjamin/Cummings Publishing.BRAVO, J. (1984): “Flexibilidad de Sistemas”, Revista Informática,

Santiago de Chile, vi-9, pp. 26-28.BRAVO, J. (1985): “¿Se justifica el desarrollo de un sistema com-

putacional”, Revista Informática, Santiago de Chile, vii-2,pp. 8-11.

BRAVO, J. (1988): Desarrollo de sistemas de información, unavisión práctica, Santiago, Evolución.

BRAVO, J. (1996): La nueva visión, diseño y construcción de sis-temas computacionales, Santiago de Chile, Evolución.BRAVO, J. (1997): Planificación sistémica, Santiago de Chile,

Evolución.BRAVO, J. (1998): Análisis de sistemas, Santiago de Chile, Evolu-

ción.BRAVO, J. (2005): Gestión de Procesos, Santiago de Chile, Evolu-

ción.BRAVO, J. (1995-2005): “Cartas” , Santiago, www.evolucion.cl.

CAMPERO, M. y ALARCÓN, L. (1999): Administración de Pro- yectos Civiles, Santiago de Chile, Pontificia UniversidadCatólica.

DAVIDSON, J. (2001): La Gestión de Proyectos, Madrid, Pearson.DRUCKER, P. (1993): Administración y futuro, Buenos Aires,

Sudamericana.ECHEVERRÍA, R. (1998): Ontología del lenguaje, 5ª ed., Chile,

Dolmen Ediciones.FAIRLEY, R. (1987): Ingeniería de Software. México, McGraw-

Hill.JACOBSON, I., BOOCH, G., RUMBAUGH, J. (2000): El procesounificado de desarrollo de software, Madrid, Pearson Educa-ción S.A.

KRIEGEL, R. (1994): Si no está roto, rómpalo, Bogotá, Norma.MATURANA, H. (1991): El sentido de lo humano, Santiago de

Chile, Dolmen.McCONNELL, S. (1996): Desarrollo y gestión de proyectos in-

formáticos, Madrid, McGraw-Hill.

MONTANER, R. (2002): Leonardo, el primero que se comió elqueso, Barcelona, Gestión 2000.



JUAN BRAVO 248

OECD (2000): Information Technology Outlook 2000, Unión Euro-pea.

PETERS, T. (2004): Re-imagina, Madrid, Pearson.

PORTER, M. (1992): Ventaja competitiva, creación y sostenimientode un desempeño superior , México, Continental.PRESSMAN, R. (1993): Ingeniería de Software, tercera edición,

España, Editorial McGraw-Hill.SEELY, J. y DUGUID, P. (2001): La vida social de la información,

Buenos Aires, Prentice-Hall.SENGE, P. (1992): La Quinta Disciplina, Buenos Aires, Granica y

Vergara.SENN, J. (1987): Análisis y diseño de sistemas de información,

México, McGraw-Hill.SOLMINIHAC, H. (2005): “La gestión de costos de proyectos”,Clase ejecutiva de El Mercurio, 13 de octubre, B11, Santiagode Chile.

TAYLOR, F. W. (1969, original de 1911) , Principios de la adminis-tración científica, Buenos Aires, El Ateneo.

TOLOZA, C. (2005): “¿Cuál es la rentabilidad de la informática ensu empresa?”, Diario Financiero, 18 de noviembre, Santiagode 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.




LIBROS DEL AUTOR PUBLICADOS POREDITORIAL EVOLUCIÓN S.A.

GESTIÓN AVANZADA DE PROCESOS Precio versión en papel: US$ 15, Chile $10.000

(2009, 190 Págs., 21 x 14 cm.)

El objetivo del libro es aportar métodos concretos para el rediseño ymejora de procesos en la organización, como un medio para lograrla eficiencia y agregar valor para el cliente en una relación de con-fianza.Surge de una profunda inquietud por el despilfarro de recursos ennuestra sociedad y, sobre todo, por la subutilización del enorme po-tencial de las personas.La gestión de procesos es un deseo que se intuye como importante enlas organizaciones. Sin embargo, es poco lo que logra realizarse por-que no se sabe cómo hacerlo, provocando grandes pérdidas en lasmismas organizaciones y en la sociedad por proyectos mal planteadoso fuera de costo y plazo, trámites que demoran más de la cuenta, malaatención de clientes, productos defectuosos, entregas con retraso,equivocaciones médicas, errores, pérdidas de clientes y tanto más…En el libro se enseña cómo incorporar a la organización un modelointegral para la gestión de procesos.Este libro complementa, aporta técnicas y muestra aplicaciones de losconceptos desarrollados en el libro Gestión de Procesos, el cual esprerrequisito para éste.



JUAN BRAVO 250

GESTIÓN DE PROCESOS

GESTIÓN DE PROCESOS Precio versión en papel: US$ 24, Chile $16.000(2006, 2ª edición, 400 Págs., 24,5 x 17,2 cm.)

(1ª edición de 2005)

Es fácil aceptar la necesidad de cambio en nuestro mundo. Másdifícil es cambiar nosotros mismos o que cambie nuestraorganización, o la forma cómo hacemos las cosas, a las cualespodríamos llamar… procesos.La gestión de procesos nos insta a detenernos, reflexionar acerca delo que hacemos y preguntarnos: ¿por qué?, ¿para qué?, ¿cómo?.Porque, si profesionales capaces tienen ideas brillantes quepermitirán ganar o ahorrar mucho dinero, al mismo tiempo deberían

inventar los nuevos empleos de las personas que serán liberadas defunciones obsoletas. Lo pueden hacer, porque son capaces. Lodeben hacer, por su condición de seres humanos.La gestión de procesos es un medio para lograr grandes metasorganizacionales, como la calidad, competitividad, productividad,comunicación y rentabilidad.




GESTIÓN DE PROYECTOS

Precio versión en papel: US$ 15, Chile$10.000 (2006, 260 Págs., 21 x 14 cm.)

El objetivo de este libro es ofrecer un métodopara la gestación, evaluación, planificación,dirección y buena ejecución de los proyectos,principalmente de procesos y tecnología. Esimportante hacer bien los proyectos, porque através de ellos se materializa el cambio pro-puesto por la estrategia de la organización opor las oportunidades que el medio ofrece. El

método tiene como base un amplio estudio delas mejores prácticas de la gestión de los proyectos y del cambio enlas personas. Las empresas públicas y privadas de Chile pierdenanualmente más de 2.000 millones de dólares debido a fallas evita-bles en proyectos de gestión. De una u otra forma esa ineficiencia lapagamos todos y con creces, porque tampoco disfrutamos de losbeneficios del proyecto si hubiese sido bien hecho.

MODELANDO UNA SOLUCIÓN DE SOFTWARE Precio versión en papel: US$ 24, Chile$16.000 (2008, 392 Págs., 24,5 x 17cm.)

El objetivo de este libro es cooperar enaumentar la productividad del desarrolloy la calidad de la solución de software

mediante la excelencia de su modela-ción. Comenzamos por asegurarnos quela serie de modelos (correspondientes alas etapas de análisis y diseño) efecti-vamente dan solución a una necesidadbien comprendida y evaluada.

Modelar soluciones de software es unalabor bella y creativa que origina verdaderas “obras de arte”. Sinperder la belleza y creatividad, ¿será posible profesionalizar suelaboración? ¡Sí! Definitivamente el diseño de sistemas puede serarte y tecnología a la vez.



JUAN BRAVO 252

EL ENCANTO DE LA COMUNICACIÓN

Precio versión en papel: US$ 15, Chile$10.000 (2007, 2ª edición 230 Págs., 18,5 x

13 cm., 1ª edición de 1998).

Es un libro orientado a todas las personasque quieren comunicarse mejor con quienesles rodean para incrementar la calidad de suvida. El espíritu de este libro es que nossirva de guía práctica en esta tarea de todala vida destinada a relacionarnos mejor y atransformarnos. ¿Por qué? Porque la comu-

nicación es cambio que podemos guiarhacia la superación personal.

Estamos vivos y lo más característico de la vida es la transforma-ción. Y porque el vínculo con nuestros seres queridos es lo únicoque realmente cuenta, además la mejora en las comunicaciones enlas empresas tiene un efecto inmediato en la vida familiar y social desus trabajadores.

RESPONSABILIDAD SOCIAL (RS)

Precio versión en papel: US$ 24, Chile$16.000 (2007, 380 Págs., 24,5 x 17,3cm.)

En los países de Latinoamérica podemosganar miles de millones de dólares al añocon la RS. Surgen de dejar de perder evi-tando la Irresponsabilidad Social (acciden-tes, delincuencia, corrupción, mala educa-

ción, etc.) y de ganar fomentando la Res-ponsabilidad Social (investigación, inno-vación, emprendimiento, comunicación,etc.). Por eso la RS es la nueva causa de lariqueza de las Naciones. Se puede lograr,

tenemos ejemplos de buenos diseños que han disminuido grandesmales sociales en un 80%. Es el caso, en Chile, de la disminución dela tasa de accidentabilidad de los trabajadores desde el 35% de losaños 60 al actual 7%. Por supuesto, el énfasis ha estado en la pre-

vención.




HISTORIA DEL IST, 50 AÑOS

Precio versión en papel: US$24, Chile $16.000. (2007, 164

Págs., 25 x 25 cm.)

Cumplir 50 años es un granlogro para toda organización ymucho más para una que sededica a la seguridad social porel gran impacto que tiene en lacomunidad. La historia del ISTes a la vez parte de la historia

de la seguridad del trabajo enChile, cuyos avances se pueden resumir en una sola palabra que bienconocen en el Instituto: prevención.

Es un avance de Responsabilidad Social que se puede proyectar aotros ámbitos para contribuir al Bien Común. Ya sabemos que unahistoria puede inspirar a las personas para lograr fines superiores, almenos para encontrarle sentido a su quehacer y motivarse. Tambiénpermite aprender, porque de la lectura se podrá extraer una buenamanera de gestionar una empresa, comenzando por una gran dosisde visión.

EMPRESAS DE ÉXITO


Este es un libro acerca de las empresas deéxito, aquellas con una gestión que las lleva adiferenciarse. En un contexto de buenasprácticas de gestión la tesis es que las empre-sas exitosas se distinguen por algunas pocasprácticas excepcionales.Así como existe la gestión por competenciasdirigida a las personas, también existe unagestión por competencias corporativa.

Además de hacer las cosas bien, las empresas exitosas se distinguenpor un pequeño número de prácticas que hacen muy bien, les hemosllamado “sistema de diferenciación”. Se presentan los ejemplos deIST, ENAMI Ventanas, Termosistema e Integramédica.



JUAN BRAVO 254

GESTIÓN, EL CASO ENAMI VENTANAS

Precio versión en papel: US$ 24, Chile$16.000 (2005, 224 Págs., 25,5 x 19,5

cm.)Es importante destacar lo positivo de lagestión de las empresas, así aprendemosde experiencias concretas. La idea fuedesafiante: compartir y aprender de lagestión realizada en una unidad de nego-cios de una importante organización. Setrata de la Fundición y Refinería Venta-nas de la Empresa Nacional de Minería,ENAMI. Tiene una cultura distintiva quese aprecia en la ingeniería o innovaciónpermanente, en su contribución al bienes-

tar del país, en el sentido de honor, en la pasión por aprender, entreotras.Se identificaron varios factores relevantes, por ejemplo: liderazgo,productividad, entorno y personas

TAYLOR REVISITADO

Precio versión en papel: US$ 15, Chile$10.000 (2005, 140 Págs., 21 x 14 cm.)Pocas veces se ha visto una distancia tangrande entre la excelencia de las contribucio-nes de un hombre y el pobre sitial que lehemos asignado en la historia. A FrederickW. Taylor los países ricos le deban su condi-ción de tales, dice Peter Drucker. Taylor

sigue aportando a la creación de riqueza através de la mayor productividad. Fue precur-sor del entrenamiento o capacitación y de la

gestión por competencias. Buscó evitar el derroche de materiales yse le reconoce como padre de la ingeniería industrial y de la ergo-nomía. Buscó que se compartieran los beneficios de la mayor pro-ductividad, entre empresarios, trabajadores y la sociedad. ¿Por quées tan actual su mensaje? Porque su mensaje de fondo está orienta-do a la superación de la pobreza y porque sus propuestas, debida-

mente actualizadas, podrían generar grandes beneficios en la eco-nomía de Latinoamérica.




A LA SALIDA DEL TÚNEL


Es un libro creado con las entrevistas realiza-das a los participantes del programa de televi-sión del mismo nombre en donde se extraje-ron sus mejores ideas, propuestas y mensajes.Fue un programa de UCV TV, conducido porel dinámico y querido periodista Atilio Mac-chiavello.

Este documento recrea la vida de muchosvisionarios y podría ser la salida de su propio túnel. Es un Textoobligado para profesores, estudiantes, profesionales y público engeneral. Una inspiración para pequeños y grandes empresarios yorientación vivencial para nuestras autoridades.

AMBROSOLI, DESDE LOS ALPES A LOS ANDES

Precio versión en papel: US$ 24, Chile$16.000 (1998, 133 Págs., 26,5 x 18,5 cm.)

Coautor: Giancarlo Gandolini Ambrosoli.

Este libro es un reconocimiento a la laborde don Constantino Ambrosoli y a todos losemprendedores que ayudan a crear un mun-do más humano. Es un ejemplo inspiradorque queremos compartir, porque excedió enmucho nuestras expectativas.¿Para qué sirve una historia? Para conocer,entender y difundir la cultura de una organi-zación, establecer un vínculo entre sus inte-

grantes, comunicar una causa común, preservar las tradiciones yseguir adelante unidos. Es un gran desarrollo, inseparablementeunido a la historia de la familia Ambrosoli, así que para entender laevolución de este negocio, necesitamos conocer la rica tradición

acumulada en esta familia.



JUAN BRAVO 256

ANÁLISIS DE SISTEMAS

Precio versión en papel: US$ 24, Chile$16.000. (1998, 415 Págs., 26,5 x 18,5

cm.).Debemos descubrir los sistemas y aprenderde ellos para ayudar en el desarrollo de lasorganizaciones. La vieja cosmovisión me-canicista, que considera el mundo estable ypredecible, abre paso a los sistemas: dondeprevalecen las interacciones, lo evolutivo, elcaos, la complejidad y sus compensadores,la humanidad, educación, comunicación,libertad, creatividad y otras respuestas. Si

pretendemos ignorarla, dar órdenes o sólo poner reglas, la complejidad se abrirá paso igual, como las aguas de un río que se preten-den frenar con un “prohibido el paso”.¿Cómo hacer análisis de sistemas? Con un enfoque al problema-solución que pasa por comprender la confusión. Algunas herramien-tas sistémicas son: la teoría del caos, la teoría de la catástrofe, loscírculos virtuosos, la orientación al cliente, etc.

PLANIFICACIÓN SISTÉMICA

Precio versión en papel: US$ 24, Chile $16.000(1997, 240 Págs., 26,5 x 18,5 cm.).

Tradicionalmente, hemos hecho planificaciónsuponiendo que las condiciones ambientales semantendrían más o menos constantes. ¡Hoy nosdamos cuenta que el entorno varía con mucharapidez! y que la velocidad del cambio sigue ysigue aumentando. Para adaptarnos a esta reali-dad, la planificación sistémica recurre a herra-mientas tales como: participación, creatividad ymanejo de la incertidumbre del medio. La pla-

nificación sistémica nos ayuda a cumplir los sueños, siguiendo uncamino que comienza por determinar qué es lo que queremos, ennuestra empresa o… en nuestra vida. Luego, establecemos un siste-ma de diferenciación y un plan.




LA NUEVA VISIÓN, DISEÑO Y CONSTRUCCIÓN DE SISTEMAS

COMPUTACIONALES

Precio versión en papel: US$ 24, Chile

$16.000, (contenido actualizado en libro Mode-lando una solución de software) (2ª edición2007, 272 Págs., 26,5 x 18,5 cm.) (1ª ediciónde 1996) Sólo colección.

Este libro trata sobre el desarrollo de sistemascomputacionales, tales como inventarios, con-tabilidad, remuneraciones o facturación.Se busca aumentar la productividad en ese

ámbito. En especial se estudia el diseño desistemas computacionales, una labor bella y eminentemente creativaque origina verdaderas “obras de arte”, a veces artesanales. Siempreconservando la creatividad, ¿Será posible que los métodos de traba-

jos y las herramientas sean de uso general? ¡Sí! Definitivamente eldiseño de sistemas dejó de ser arte para transformarse en tecnología.Esta propuesta de la ingeniería de software tiene su base en tressólidos pilares: La planificación estratégica en informática, el dise-ño orientado al objeto y las herramientas de productividad.

REINGENIERÍA DE NEGOCIOS

Precio versión en papel: US$ 24, Chile $16.000(1995, 300 Págs., 26,5 x 18,5 cm.)

La finalidad de la reingeniería es lograr grandesdesafíos, por ejemplo: aumentar la productivi-dad de las personas, las ventas o la producción,no en un 30%, sino en 400% y más.

¿Cómo lograrlo? A través de efectuar grandescambios en los procesos del negocio, potenciara las personas, definir una estructura organiza-cional flexible e incorporar tecnología. Todo ensintonía con la cultura y estrategia de la organi-

zación.¿Para qué hacer reingeniería? Para cumplir con la misión de la or-ganización, tarea en la que deben estar empeñadas todas las perso-nas que ahí laboran, sirviendo los intereses de los clientes en ar-

monía con los valores de la empresa y de la comunidad.



JUAN BRAVO 258

MODELAMIENTO DE SISTEMAS DE INFORMACIÓN

Precio versión en papel: US$ 24, Chile $16.000(contenido actualizado en libro Modelando una

solución de software) (1994, 250 Págs., 24,4 x18,2 cm.). Sólo colección.

Da una visión de conjunto sobre el desarrollode sistemas de información, comenzando por laplanificación estratégica del negocio.En el texto se incorporan los conceptos deevaluación de proyectos informáticos, los len-

guajes de cuarta generación y la orientación a objetos. Especialrelevancia tienen la Ingeniería de Software y las herramientas deapoyo en cada etapa del desarrollo del sistema de información.En las últimas décadas la “computación” ha sido un agente de cam-bio al interior de la organización, hoy las áreas de informática o desistemas también deben cambiar. Se trata de lograr el desarrollo desoftware de calidad, económico y en plazos convenidos.

DESARROLLO DE SISTEMAS DE INFORMACIÓN

Precio versión en papel: US$ 24, Chile$16.000 (1996, 3ª edición, 204 Págs., 26,5 x18,5 cm.) (1ª edición de 1987)

El objetivo de este libro es servir de guíapráctica en el desarrollo y en la mantenciónde sistemas de información orientados aempresas. Está especialmente dirigido atodos quienes laboran en el área de informá-tica, y que podrían hacer uso de las materiasprácticas, que buscan mejorar el rendimiento,mediante la aplicación de pautas simples y

lógicas, donde el criterio predomina sobre la reglamentación.También se orienta a estudiantes de carreras del área computación einformática, quienes podrán ver facilitado su aprendizaje al enfren-tarse con metodologías y ejemplos concretos, sobre la base de unavisión de conjunto del desarrollo de sistemas de información.El libro ha sido de gran ayuda para académicos de las áreas mencio-nadas.




ACERCA DEL AUTOR:

Juan Bravo Carrasco

Doctor por la Universidad de Lleida (España). Mas-ter en Dirección de Informática (Ide Cesem, España)e Ingeniero de Ejecución en Sistemas de Informa-ción (USM, Chile).

Es Presidente de Evolución, Centro de Estudios Avanzados y editor de la Revista ResponsabilidadSocial.

Con más de 30 años de experiencia como ejecutivo,consultor y relator de seminarios, el Dr. Bravo haayudado a clientes tales como: Mutual de Seguridad,ENAMI, BancoEstado, Rolec, Transbank, IsapreColmena, Municipalidad de Quillota, Banco Itaú,Empresa Portuaria de Valparaíso, Constructora

TECSA y Termosistema.El Dr. Bravo es profesor de programas de postgradoen la Pontificia Universidad Católica, UniversidadTécnica Federico Santa María (Chile y Ecuador),Universidad de Chile y otras instituciones.

Publicó los 18 libros indicados.



JUAN BRAVO 260

LA SERIE DE LIBROS

A mayo de 2009 todos los libros están disponibles

en papel.Su disponibilidad en digital y actualización se expli-ca a continuación.

Libros en digital y actualizados

Estos seis textos están disponibles y actualizados en

digital. Son los libros más relacionados con el haceractual de consultoría:

1. Gestión Avanzada de Procesos2. Gestión de Procesos3. Gestión de Proyectos4. Modelando una Solución de Software5. El Encanto de la Comunicación

6. Responsabilidad SocialLos siguientes doce libros no tienen actualización:

Seis son históricos (A la salida del Túnel, Ambroso-li, Enami, Taylor, IST y Empresas de éxito).

Otros seis (Desarrollo, Modelamiento, Reingeniería,Diseño, Planificación y Análisis) perdieron tanta

vigencia que no basta con la actualización para supermanencia. En este caso aplica el rediseño, en laforma de nuevos textos que heredan contenidos reci-clados posibles de rescatar de los antiguos. Porejemplo, el libro Modelando una Solución de Softwa-re heredó algunos contenidos de los textos Modela-miento y Diseño.




Libros en digital sin actualización

Estos siete libros están disponibles en digital en su

versión original del año que se indica:

libro gppt 2009-5 juan bravo

Documents