Libro Gestion de Proyectos de Procesos y Tecnologias - 2006 - Juan Bravo

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 este medio digital.

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

En general, la serie de libros aporta motivación, conceptos, técnicas y herramientas que han probado ser efectivas en cientos de casos narrados en los mismos textos. Observará que grandes avances fue-ron logrados justamente en alguna otra crisis. Esas soluciones 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 Lleida Presidente 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] Alameda 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 requieren actuar de bomberos.

JUAN BRAVO 6

RECONOCIMIENTOS

Agradecer a muchas personas que de una u otra forma han cooperado: Juan Carlos González, Gerardo Cerda Neumann, Guillermo Gómez, Luis Cid, Sergio Valen-zuela, Rolf Achterberg, Giancarlo Gandolini, Edmundo Leiva, Marcos Merino, Luis Hevia, Javier Cañas, Ignacio Orrego, Pere Mir, Miguel Saéz, Samuel Chávez, Limbi Ortiz, Rodrigo Baldecchi, Rodrigo Silva, Francisco Ramí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) y de GPPT (Gestión de Proyectos Procesos y Tecnología) a través de Revista Gerencia. También a mis socios del proyecto 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 muchos proyectos 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 con mis disculpas a quienes merecidamente debían estar (y que omití por error):

• BancoEstado: Loreto Farías, Nilda Mardones, Tama-ra Vilches, Alicia Garay, Fernando León, Rodrigo Collado, Arturo Barrios, Hernán Baeza, Humberto Gómez, Alfredo Correa, Carlos Montecino, Adolfo Grasset 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): Mario Troncoso, Mabel Ruiz y Eduardo Jones.

A mis colegas profesores de la Escuela de negocios IEDE Chile y compañeros del Programa de Doctorado con la UDL: Yolanda Yánez, Jorge Israel, Francois Le Calvez, Jaime Sanhuesa, Patricio Sánchez y Daniel Ka-nonitsch.

A todos agradezco y libero de cualquier responsabilidad por 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 buena parte 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ÁCTICAS TRANSVERSALES ........................................... 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 Y BIBLIOGRAFÍ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 ó 100 maneras diferentes para hacer cada elemento de

trabajo.

Frederick Winslow Taylor

JUAN BRAVO 14

PRÓLOGO

Entre 1975 y 1978 tuve el privilegio de estudiar en la Universidad Técnica Federico Santa María una carrera muy rara: IESI o Ingeniería de Ejecución en Sistemas de Información, era la primera vez que se dictaba en la USM y no había a quien preguntar. Es má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 y error 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 memoria de 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ón de 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 de Informació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 algunos años mi sesgo fue tecnológico (me desempeñé como Jefe de proyectos en NCR y luego como Gerente de Informática de una empresa comercial). Sin embar-go, con el tiempo comencé a recuperar el espíritu original de esa rara carrera: ver a la organización de manera 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 otros factores. Curioso, a veces los problemas se resolvían completamente a ese nivel, sin necesidad de ocupar mi querido martillo de la informática.

Durante esa época y hasta fines de los noventa mi formación fue más bien autodidacta (aunque partici-pando en muchos cursos breves con autores como Yourdon, 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 de Ingeniería), dirigía talleres de análisis de sistemas y guiaba alumnos memoristas. La doble experiencia de consultoría y académica fue central en la creación de conocimiento que plasmé en varios artículos (tal como “Flexibilidad de Sistemas” y “Se justifica el desarrollo 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 nombre en algunas universidades e institutos.

Durante la década de los noventa consolidé mi línea de 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 hicimos con la USM y que llegó a tener más de mil egresa-dos, el cual evolucionó incluso hasta transformarse en 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 en COBOL y luego en otros lenguajes. Se vendieron unas 300 licencias en Chile y Latinoamérica y unas 1000 fueron donadas a instituciones educacionales. Tenía alrededor de 500.000 líneas de código y lo construí 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 la visión sistémica, nueva cosmovisión en la cual se transformó la antigua teoría de sistemas y que además recoge los grandes nuevos aportes, como la teoría de comunicación de Maturana, la teoría del caos y el pensamiento sistémico de Senge, entre otros afluentes.

Más o menos con la llegada del nuevo milenio con-sideré que ya tenía la experiencia necesaria para otro ciclo de formación. Obtuve un Master en Dirección de Informática con un instituto de Madrid y luego un doctorado con la Universidad de Lleida (Cataluña, España). Durante este último período reforcé los conceptos de acercamiento integral a la organización en mi labor de consultoría y he tenido el privilegio de 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. Todo esto quedó registrado en nuevos títulos: el libro Ges-tión de Procesos (2005), base a su vez de mi tesis de doctorado realizada durante 4 años y otros libros que profundizan 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 las empresas, 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 GSP y 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ón de proyectos. Ya son muchos los avisos en la prensa que solicitan profesionales competentes o asesoría en el “proceso de gestión de proyectos”. Este es uno de los motivos para seguir trabajando en este texto. En el fondo, 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 de proyectos y “fabricar el cambio”.

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

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

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

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 al año más de 2.000 millones de dólares2 debido a fa-llas evitables en proyectos de gestión. En realidad esa ineficiencia de una u otra forma la pagamos to-dos y con creces, porque tampoco disfrutamos del beneficio 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.000 empresas en Chile en los últimos 20 años. Se pueden plantear estas cifras conservadoras: Las 10 empresas mayores gastan en total 1.000 millones de dólares al año en proyectos de gestión (promedio 100 millones de dólares cada una). Las 100 empresas mayores gastan en total 1.000 millones de 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 total 1.000 millones de dólares al año en proyectos de gestión (promedio 1 millón de dólares cada una). Las 10.000 empresas mayores gastan en 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 de gestió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 el costo de oportunidad). Otras estimaciones hablan de fallas hasta de un 80%, las más conservadoras le asignan un 50%.


Son fallas del tipo: a) el proyecto no responde a las reales necesidades de los clientes y a veces ni siquie-ra de los usuarios internos, b) los costos o plazos excedieron en mucho la estimación, provocando grandes trastornos, c) el proyecto está tan fuera de foco que conviene cancelarlo pero nadie lo asume porque 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 dificultades son ampliamente “sufridas” a diario en proyectos de todo 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 la gestió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 OTAN en Alemania se planteó adoptar un enfoque ingenie-ril en el desarrollo de software, con énfasis en maximizar la calidad del producto de software y la productividad del desarrollo de software, al mismo tiempo, minimizar los riesgos del desarrollo y explo-tación.

JUAN BRAVO 22

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

La mayor parte de los sistemas computacionales desarrollados y entregados no se utilizan (47%)

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

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

Esta realidad de los proyectos tecnológicos no ha sido 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 para abordar proyectos de procesos y tecnología. No se trata de detallar técnicas, actitudes o conocimientos específicos sino de señalar un trazo que sirva en la gestación, planificación, dirección y buena ejecución de los proyectos.

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

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

fensa, de la NASA y la Contraloría. En general la bibliografía se refiere 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ía con 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 su vez una recopilación de las mejores prácticas para la realización de proyectos.

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

En la primera parte del contenido se explica más acerca 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 se quiere llegar con un nuevo producto, un tipo de cré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étodo llama a esto: estar de acuerdo con la estrategia de la organización.

Claramente, el alcance de un proyecto es mucho mayor que solamente incorporar

alguna forma de tecnología o construir un sistema computacional.

El proyecto incluye las acciones relacionadas con la estrategia de la organización (principalmente alinear la 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 de información. A ese conjunto le llamamos modelo integral 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 la estrategia y los pilares son las personas (inclu-yendo cultura e infraestructura), procesos, estructura y tecnología. El mensaje es armonía en 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 los usuarios, destinatarios, beneficiarios, pacientes, ciu-dadanos y otras denominaciones para representar a alguien fuera de la organización y a quien servimos y nos 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 que es suficiente con realizar bien su función).

También se le llama “Visión de procesos”, porque siempre existe una doble responsabilidad, la función individual y la totalidad de asegurarse que funcione el proceso 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 de la organización).

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

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

Inicio del proyecto

Aplicando el enfoque de proyectos, todo comienza por conocer bien el problema (concepción) y así evitar crear soluciones sólo para atacar el síntoma.

Se trata de conocer el problema de fondo y luego buscar 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 un modelo integral del cambio (la mesa).

Aquí surgen los requerimientos globales del proyec-to. Esta es la base de la ingeniería de requerimientos orientados 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 las personas, estructura organizacional, tecnología y sobre el mismo detalle de la “pata” procesos.

Otra de las “patas de la mesa” es la tecnología de informació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 el análisis, se profundiza en las etapas más orientadas al desarrollo computacional propiamente tal: diseño, implementación y despliegue, siempre dentro del sistema de productividad que el método propone, donde se incluyen factores tales como: técnicas, herramientas de apoyo, hardware, incorporación del usuario, habilidad del desarrollador y normalización externa.

JUAN BRAVO 28

Luego, junto con la operación del sistema computacional, llega la mejora continua de todo el resultado del proyecto.

En la parte de ingeniería de software del sistema de información, el método considera los nuevos están-dares: UML, Orientación a Objetos, desarrollo en espiral, uso de componentes reutilizables de softwa-re, herramientas CASE y amplia orientación a la calidad (en línea con las propuestas de CMM, ISO 9000 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 proyecto

El 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 globales del método, de las etapas del proyecto y de las prácticas transversales.

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

Para elaborar el plan de proyecto se requiere conocer las 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 apoyo computacional para gestar y administrar proyectos. Se requiere una malla de actividades que permita visualizar el proyecto integral y resolver aspectos de precedencia, holgura y ruta crítica.

Visión de conjunto del método

El plan de proyecto es una integridad con contenidos mucho más allá que la ruta crítica. En realidad con-templa dos líneas de trabajo paralelas, como las vías del ferrocarril:

• Etapas del proyecto • Prácticas transversales

Tal como se aprecia en la siguiente figura:

JUAN BRAVO 30

Etapas del proyecto

Las etapas son las distinciones principales del 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 el esfuerzo promedio estimado de cada una y como a partir de la etapa de diseño se expande el trabajo incorporando 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 proyectoPlan de la etapaExposición de los planesRetroalimentaciónEl equipo de trabajoEntrevistasComunicación

InformesTé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 de proyecto. 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 y despliegue.

• MC (Mejora Continua): donde la solución ya en operación se mantiene y perfecciona. Contiene solamente la etapa de operación, la más extensa.

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

Aunque todo proyecto tiene las mismas etapas, su alcance puede diferir según las condiciones 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 de ellas.

3. Análisis

El objetivo es plantear el modelo integral del cambio de 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 integral del 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 todas sus partes.

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

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

6. Despliegue

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

7. Operación

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

Concluye un ciclo de operación con el inicio de un rediseñ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 detalladas en el plan particular para el proyecto.

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

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

Las principales prácticas transversales consideradas son 28 y han surgido del estudio de las mejores prácticas de los proyectos.

1. Dirección del proyecto 2. Plan de la etapa 3. Exposición de los planes 4. Retroalimentación 5. El equipo de trabajo 6. Entrevistas 7. Comunicación 8. Informes 9. Técnicas 10. Herramientas de apoyo 11. Trazabilidad 12. Quick Wins 13. Costos y duración 14. Gestión de riesgos 15. Gestión de la calidad


16. Responsabilidad social 17. Inserción 18. Orientación al cliente 19. Sensibilización 20. Capacitación 21. Seguimiento 22. Cuidar la solución anterior 23. Continuidad operacional 24. Plan de recursos físicos del proyecto 25. Kill time 26. Control de cambios 27. Gestión del cambio 28. Gestión de proveedores

En la tercera parte del libro se puede ver el detalle de 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 de otra 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, hacer zapatos o construir catedrales, era una iniciación en un gremio muy cerrado. El “arte” o secreto del oficio se transmitía de maestros a principiantes a través de la revelació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 sido necesario que transcurrieran 400 años para que ese arte 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 y ese 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 puede enunciar así:

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


y el fin de los procesos en que participa y aplica que tan 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 del proceso.

Las prácticas que se adquieren en la competencia método se pueden ver como un continuo que co-mienza desde la toma de conciencia de “cómo lo hacemos” (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 para todo tipo de procesos —del negocio, de apoyo y estratégicos— y proyectos de cambio organizacional.

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

• Aprendiendo: Toma conciencia de “cómo hacemos” el trabajo y lo describe, se interesa en conocer los procesos completos en que participa y quien es el cliente, domina técnicas básicas de gestión de procesos y de proyectos, cuantifica el problema y el costo de oportunidad.

• Entendiendo: Conoce el objetivo del proceso y propone mejoras para eficientarlo, aplica 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 para evitar 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 valor de Porter, elabora planes de proyecto para el cambio, 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 acuerdo con 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étodo completo de proyectos.

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

gestión de riesgos, trazabilidad y control de cambios. Motiva, lidera y retroalimenta

a 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ón de Proyectos Civiles (páginas 2 y 3): “Los buenos resultados de una administración serán el producto de condiciones personales de los responsables y de las técnicas de administración que empleen… cum-plir con las metas programadas de costo y plazo no resulta fácil y existe una alta posibilidad de arriesgar los 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 el costo 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ó al tasa 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 en este método lo que se considera realmente aplicable en las empresas de Chile y Latinoamérica, conside-rando nuestra idiosincrasia, niveles de conocimiento y avance en tecnología de información.

Es un método genérico porque la idea es conocer y seleccionar del medio las mejores 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 hacia las estandarizaciones formales o “de facto” en nuestro medio.

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

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 de Desarrollo 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 etapas de 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, amplio uso de técnicas del medio y apoyo de herramientas existentes.

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

práctica de todas las actividades incluidas en 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étodo se funda en las experiencias directas o de consultoría


de desarrollo de sistemas de información del autor y de gran cantidad de profesionales, a quienes se les agradece en los respectivos textos. Otra influencia viene desde los cientos de desarrollos guiados, nor-malmente reales, con participantes de los programas de postgrado en Análisis y Diseño de Sistemas en la Universidad Técnica Federico Santa María, Univer-sidad de Chile, Universidad de Valparaíso y Escuela de 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 el tiempo 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, modelos de UML, fichas para estudio de proyectos y recomienda el uso de herramientas en cada etapa. También considera aportes de normas de calidad tales como ISO 9000, CMM y Tick IT. Además de Técnicas de auditoría, tal como COBIT.

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

JUAN BRAVO 44

CLAVES DE LA IMPLANTACIÓN DE

MÉTODO

Son claves que guían el trabajo en la implantación de método en una organización. Previo, es necesario sincerar 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 la tecnología de Matrix, aquella donde Neo aprendía rápidamente mediante un tubo conectado directa-mente al cerebro).

Método tiene que ver con el desarrollo de competencias de las personas, con un trabajo arduo de generar estándares

internos y externos.

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

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

Clave 1. Visión de conjunto

La visión sistémica es vital, se materializa, por ejemplo, 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 y de 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 desarrollo

interno.

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

En todos los casos, los mapas deben estar disponi-bles para la organización utilizando las herramientas apropiadas. Independiente del registro de cambios de cada modelo, es vital una versión actualizada de cada 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ón de conjunto es apreciando la cultura y nivel de avance de la organización en la aplicació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 se comprometen a cumplir, no por imposición, sino por reflexió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 el 80% de avance— sino que a una negociación res-pecto a lo se considere mínimo para la organización particular.

El mínimo indispensable significa un método flexible y preciso, bien adaptado a

la realidad de la organización y de cada proyecto particular, porque su orientación

es simplicidad, flexibilidad y aplicabilidad, para que realmente sea

utilizado en las organizaciones latinoamericanas.

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ás amplia 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 la organización, pertenece a toda ella, independiente que alguien lo administre.

Lo primero es identificar los actores, por ejemplo:

• El cliente es el cliente. Está fuera de la 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 la luz de sus Intereses actuales o potenciales.

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

• Analistas o profesionales de proyectos forman el equipo 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 respecto al proyecto.

Luego definir los roles de cada uno en relación al mé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 solamente difundir el método es un proyecto en sí mismo donde aplica todo lo indicado en este 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 estar aplicando algo de método y disfrutando de los bene-ficios de proyectos mejor realizados.

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

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

La gradualidad es el concepto de fondo, es decir, implantar en base a avances sucesivos, a partir de negociaciones respecto a lo que realmente las perso-nas quieren y pueden hacer. Justamente una de las ideas centrales de este método es el buen manejo del cambio, donde se plantea que un sistema en buen funcionamiento es una joya que debe tratarse con mucho cariño, asegurándonos que lo nuevo es efec-tivamente mejor, sin el encandilamiento transitorio que tanto daño provoca.


CARACTERÍSTICAS DEL MÉTODO

El método descrito en estas páginas para la buena gestión de proyectos de procesos y tecnología tiene muchos elementos y una complejidad que no puede ser reducida artificialmente, porque corremos el riesgo de simplificar demasiado.

De todas formas, destacan estas siete 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 al comienzo y luego continuar planificando durante todo 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 por la dinámica de la realidad.

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

Es bueno tener presente la conocida afirmació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 sea en línea, es decir, en tiempo real y que los datos sean capturados en la punta del proceso, evitando redigita-ciones. Además, trabajar todo lo posible en formato digital. 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 los opuestos, 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 del tiempo hay una bifurcación mejor a la

“establecida”.

Por ejemplo, en cada etapa se puede volver a una anterior 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 hizo correctamente.

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

• Aprender a utilizar eficazmente las herramientas de 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 excepciones como excepciones, sin darles el mismo espacio visual que el curso normal de los eventos, en esto debe existir armonía con la 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 situaciones indeseables que perturban el flujo, van como texto fuera del modelo cuando son relevantes.

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

6. Adaptación a proyectos específicos

La 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 negociar las actividades que incluiría y el alcance de las prá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, aunque mantiene 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 a cada 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 la Organización

Aplicación a un proyecto

Adaptación

Método de la Organización

Aplicación a un proyecto

Adaptación

JUAN BRAVO 54

El método debe adaptarse a cada realidad porque no es 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 una especie de Fast Track en el caso de proyectos priori-tarios por alguna contingencia o por necesidades estratégicas.

7. Pasión por conocer la finalidad, el para qué

Todos los actores del proyecto deben tener claridad en objetivos, resultados y propósito alineado.

Más allá de los entregables por etapa, es vital definir y conocer lo que se quiere lograr, los objetivos finales. Tener la vista puesta en el destino ayudará a darles un sentido a todas las actividades del proyecto.

Davidson aconseja (página 33): “Al tener una idea clara del final deseado todas las decisiones que se tomen 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 depositarios del método, quienes lo actualizarán, difundirán y tendrá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 y de UTP pueden ser áreas diferentes y que

trabajan coordinadamente.

Área de estudios

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

JUAN BRAVO 56

Es un área que ayuda a generar mucha rentabilidad a la 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émica que abarca toda la organización, comenzando por aplicar 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 el mapa de necesidades en conjunto con el área de metodología (también el resto de los mapas).

También recibe la retroalimentación de los proyec-tos en desarrollo.

Por supuesto, el comité de proyectos requiere una fórmula simple para administrar los compromisos vigentes e históricos., así como definir la forma de toma 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 que señ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 del proceso, jefe del proyecto, etc...)

Esto es independiente de los entregables por cada etapa cuya aprobación depende de la estructura que el 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 las

decisiones TI con la misión de la organización.

• Dependencia de una Gerencia de Desarrollo o de una Dirección de Sistemas de Información que tiene en sus manos los principales elementos de cambio 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 de un requerimiento desde su gestación hasta la puesta en marcha

• Contar con un método de desarrollo completo.

Políticas en TI

Se trata de directrices que toda la organización se compromete 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 aplicaciones

Privilegios y responsabilidades en cuanto a la tecnología de información

• Requerimientos que puede solucionar el mismo 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 tener mejor comunicación interna y externa en las área de informática y de proyectos.

Las políticas ayudan a establecer una relació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 que de un cargo en particular (en organizaciones más pequeñ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 Modelamiento de 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 base de datos y por tanto filtra el modelo de datos de cualquier nueva aplicación. Soluciona redundancias e incorpora al modelo físico corporativo lo relevante para toda la organización (pueden existir aplicacio-nes locales que no dependen de él).

JUAN BRAVO 60

Aplica técnicas y herramientas para mantener la consistencia y eficiencia de las bases de datos. Opi-na acerca del esquema de seguridad de datos de cada aplicación.

En todo caso de agregar tablas hace un estudio de cómo impactan en el modelo corporativo y recomienda adaptaciones.

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

Componente de negocios

Desde el punto de vista de registrar a que procesos sirven los datos.

Hoy con la ayuda de herramientas de modelamiento corporativo es posible unir ambos temas porque to-dos los modelos están centralizados. Por ejemplo: WBM (Websphere Business Modeler), de IBM (de-rivó desde el M1), Corporate Modeler de CASE y ARIS, 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 de datos (puede ser más de una persona):

• Permite que la organización conozca el modelo de 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 datos y un verdadero modelo corporativo. Esto ayudará a solucionar requerimientos rápidos que pueden realizar los mismos usuarios cuando no haya creación de tablas y se puede apoyar el desarrollo de 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 automatizan el 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ácticas transversales. 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ón que 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. Este concepto de actualización permanente está recogido también en las prácticas transversales.

Sucede a veces que una etapa realiza con desfase respecto a la anterior y el simple paso del tiempo dice que algo pudo haber cambiado.

Cuantificar todo

Un aspecto central del 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ágina 54), plantea: “Una inversión informática concebida correctamente es evaluada en términos de beneficios económicos concretos y genera rentabilidad para la empresa. Esta es la única forma de aprovechar la informática para mejorar la competitividad del ne-gocio. En el momento de definir los beneficios económicos del proyecto, a veces se comete el error de pensar en «beneficios intangibles» y elementos difíciles de medir. La verdad es que si los fríos nú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 valor agregado. Por ejemplo, ¿cuánto cuesta que un niño no aprenda? o ¿cuánto gana la sociedad con una educación bien lograda?

Fase de estudios

Aquí 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ándo avanzar y cuando retroceder, practicar un

JUAN BRAVO 66

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

Ya sea para abordar la necesidad o para comenzar a esbozar proyectos son vitales las habilidades de 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 de Detecció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 generar nuevos proyectos, desde la detección de una necesi-dad hasta la definición del proyecto.


Este proceso es necesario porque la forma en que los proyectos surgen en la organización debe seguir normas estándares, evitando así que surjan desde áreas o personas con objetivos locales o en forma tan improvisada que se pierda la visión de conjunto.

Todo integrante de la organización puede detectar necesidades (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 adecuada en gestión de proyectos.

No hay problema que sean profesionales destinados transitoriamente al área de

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

Veremos brevemente las tres fichas que se utilizan en este proceso de fabricar el cambio, más el cierre del proyecto.

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

Ficha 1: Detección de la Necesidad

Nº de la necesidad

Quién detecta

Necesidad

Costo estimado

JUAN BRAVO 68

problema).

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

Todo integrante de la organización puede llenar este formulario (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 Comparativa de Soluciones, por lo que al final de este formulario se deberá consignar por parte del Comité la decisión, la prioridad asignada y el evaluador designado para completar 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 no la necesidad detectada. Si es así, se selecciona algu-na de ellas o una combinación de ellas con todas las observaciones necesarias.

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


Pueden presentar este formulario los evaluadores designados 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 estudia

Situació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 las polí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 del proceso, jefe del proyecto, etc...)

JUAN BRAVO 72

ETAPA 1. CONCEPCIÓN

Lo que da origen al trabajo en la etapa es un síntoma o 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 sabemos realmente cuál es el problema de fondo.

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

La necesidad puede tomar formas tales como una oportunidad o una dificultad.

Entregable de la etapa: una necesidad validada, cuantificada y en su contexto.

~§~

Se da inicio a esta etapa porque hay algo que se quiere solucionar o una meta que se desea alcanzar, hablamos genéricamente de “Problema”, puesto en-tre comillas porque al comienzo resulta pretencioso llamarle así, hay muchos síntomas que cuesta inter-pretar, más bien lo que se tiene es una confusión o una sensación de molestia indefinida…

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


Yendo a los fundamentos conceptuales, la visión sisté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 cuando uno descubre el verdadero problema, el de fondo… ¡la solución está incluida!.

Precisamente el objetivo de esta etapa es aclarar la confusión para obtener un enunciado validado, a eso le podemos llamar Problema, definido como una distancia, entre dónde estamos y dónde queremos 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 forma como una necesidad.

¿Es posible saltarse esta etapa cuando una necesidad proviene de un proceso de planificación estratégica o desde el mapa de necesidades? Es preferible no saltarse la etapa aunque la necesidad venga dada, porque es necesario cuantificar y dar un formato comú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). Si se aprueba lo planteado en esta ficha generalmente hay 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ón con el entregable que corresponda.

En ambos caminos recurre a profesionales especializados de dentro a fuera de la

organización.

Un informe típico de esta etapa debiera incluir los puntos siguientes, los cuales se aplicarán en forma iterativa, como en una espiral, se logra un avance en cada 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 continuo que 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 antes de pasar a la etapa de factibilidad.

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

en cuenta las oportunidades y exigencias que el medio plantea, lo primero es

conocer el ámbito de trabajo y ubicarnos en el entorno.

Normalmente el ámbito de trabajo son áreas o pro-cesos. En el primer caso, puede ser racionalizar el área de abastecimientos, la oficina comercial o la planta productiva. En el segundo caso, el proyecto puede ser 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ón de zapatillas, zapatos de varón o diseño en el caso de una 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 podemos encontrar 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 menos antigüedad. Entonces, es preferible no dar por obvio o conocido aspectos que pueden ser importantes.

Conociendo cuál es el ámbito, ahora se requiere 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 la organización: características de la industria, de la economía y demás entorno inmediato. Es decir, ¿dónde estoy?

Aplican aquí las técnicas de síntesis y análisis de la 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 en que se trabajará: identificación, descripción bre-ve, estimación de costos, nivel de urgencia por cambiar, ¿qué riesgos tiene mantener la situación actual?, 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 otras definiciones típicas.

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

6. Descripción de la estructura organizacional y relaciones: ubicación de la necesidad en una unidad organizacional, en una función y/o en un proceso. Identificar relaciones del área problema con 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 y flujogramas de información (podría no ser tan detallado 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 cuando se trata de un informe de consultoría de alguien que no conoce la organización, o breve, cuando es una presentació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ón inicial hasta un enunciado validado.

Siendo el objetivo de la concepción obtener un enunciado validado del problema, este enunciado se puede ensayar muchas veces, al mismo tiempo que se avanza en las actividades de la etapa.

Cabe señalar que un proceso como el descrito en estas páginas, junto con ayudar efectivamente a ob-tener un enunciado validado respecto a la confusión inicial, también generará nuevos cuestionamientos que 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 al mismo tiempo humildad para escribirlo, porque la probabilidad de cambiarlo es muy alta, tal vez un 99% (basado en las experiencias de consultoría y en muchos ejercicios en diferentes cursos). Esto es im-presionante, quiere decir que al no pasar por esta etapa 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 comenzar por 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 de operaciones de una empresa productiva ubicada en Curicó (distante 200 kilómetros), observa que: “En la 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 para adquirir un programa computacional... y aunque el programa funcionó… el problema subsiste.

¿Qué pasó? Qué el gerente se quedó en la confusión, con el primer enunciado. Hizo un primer diagnóstico apresurado y lanzó una solución que en otra parte habí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 existencia de 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 arman enunciados hasta que obtenemos uno que

JUAN BRAVO 80

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

¿Qué hay antes del problema? Una situación confusa que no permite el desarrollo del proceso creativo y se presta para la aplicación de recetas, es decir, “so-luciones” empaquetadas que no toman en cuenta la variedad 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 es muy bajo, podemos redefinir el enunciado cuanto queramos, sin más costo que el tiempo invertido en el 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 el tiempo de análisis hasta donde sea posible. Debemos cuidar 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 puede ser 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 el problema particular Por ejemplo: tiempo que los clientes esperan en una fila, número de exámenes que 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 que los clientes esperan en una cola para pagar en la caja.

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

Se requiere aportar datos concretos y hechos preci-sos que ayuden a la comprensión del problema y al planteamiento 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 hacer visualmente, 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 las personas?

El problema resuelto ¿tiene algún efecto de marke-ting? ¿Mejora la imagen de la empresa? ¿Realmente aporta 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 me-jor estimación.


Urgencia por solucionar

Dentro de las variables críticas también está la ur-gencia por solucionar, porque no es lo mismo un problema de renovación de vivienda que de apoyo en caso de un desastre.

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

d) Determinar las causas de fondo

En todo caso, el objetivo es identificar las causas raíces del problema, pudiendo aplicarse otras técni-cas, como las del mejoramiento continuo. Algunas son:

1. Técnica de cuestionar la existencia de cada palabra del enunciado

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

3. Búsqueda bibliográfica 4. 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ño que lo reconoce como propio y que está interesado en que se aclare y se resuelva.

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

JUAN BRAVO 84

caso de crisis se quiere ayudar a empresas pequeñas que están sufriendo especialmente los rigores. ¿Quién es el dueño del problema? ¿La repartición a cargo del subsidio y que de alguna forma representa a 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 un problema. El enunciado final del problema es lo que se anota en este punto.

1.3. Cuantificar el problema

Importa calcular el costo del problema (o de no re-solver la necesidad). Los costos de oportunidad también se incluyen, tales como clientes potenciales que no llegan, ganancias no logradas por no dispo-ner de productos en stock, personas que no salen de la 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 del servicio 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í hay varios millones de dólares como costo del problema.

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

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

VA social

El VA social son las pérdidas concretas que asumen los clientes por un mal servicio8.

Un ejemplo de VA social es el costo en tiempo de los clientes que esperan en una

fila. 20.000 clientes al mes a US $ 4 por hora es aproximadamente un millón de

dó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 la comunidad en millones de dólares.

JUAN BRAVO 86

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

En nuestro ejemplo del servicio de comercio exterior del banco, cada cliente debe concurrir al banco una vez al mes, 12 veces en un año. Hablamos de 1.200.000 viajes al banco innecesarios porque todos los trámites pueden ser electrónicos. Cada viaje sig-nifica tres horas que a los clientes de ese servicio le cuestan 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 cliente de que el servicio sea lento y no pueda contar con el resultado 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 proyecto de la solución después de un barrido

creativo de muchas soluciones y de un estudio comparativo de algunas de ellas.

Entregable final de la etapa: el plan de proyecto.

Entregables intermedios: La 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 toma de 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 realizar cada 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 alternativas de 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ómo Hacer 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 y que cuenten con las competencias necesarias.

Cada alternativa evaluada es una solución integral alineada con la estrategia que incluye acciones sobre personas, procesos, estructura y tecnología.

Usamos la palabra solución porque es más amplia y representativa que indicar solamente rediseño de procesos o aplicación computacional. Además, lo más probable es que la solución seleccionada resulte de una combinación de varias alternativas.

Creatividad aplicada

En esta etapa la creatividad e inventiva aplicada en la 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 siete por 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, por ejemplo: 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 con otras 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 trabajo

multidisciplinarios destinados directamente al proyecto.

Los integrantes de un equipo de proyecto son analis-tas de proyectos. Esta función no debiera ser una especialización profesional, sino que cualquier pro-fesional de dentro o fuera de la organización, con la debida 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 un equipo 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 de proyecto puede integrar todas esas posibilidades.

Un aspecto vital es la preparación del equipo de trabajo, no sólo en temas técnicos y de administración del cambio, sino que también en temas de comunicación, particularmente en cuanto al trabajo en equipo y el profesionalismo.

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

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

2.2. Ideal de la solución

El ideal de la solución se refiere esencialmente a plantear 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 es una práctica habitual en algunas organizaciones.


Conociendo dónde estamos, ahora se trata de saber adónde vamos… es decir, definir el alcance de la solución. ¿Qué pretendemos lograr?

Aquí debería quedar planteada la medición ideal para el ámbito de trabajo, por ejemplo, para el área de 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 usuarios de los productos

• Disminuir a cero el tiempo de duración de cada compra.

Suponemos que estas grandes directrices surgieron como solución al problema detectado en la etapa anterior.

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

También en esta fase ya es conveniente comenzar a pensar 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 lugar de 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 las variables 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, las propuestas de cambio respecto a:

• Personas: las personas pueden ser potenciadas y lograr 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 un 20% de alternativas no factibles, para abrir la mente. Los resultados son 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 posible aplicar generalización? ¿Se puede externalizar el proceso? Revisión del ciclo completo de procesos del negocio y otros de apoyo.

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

• Estructura: equilibrios en 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 de a 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. De esta forma se economizan los inventarios y bodegas intermedias, se eliminan los controladores y revisiones de calidad porque la retroa-limentación a cada integrante de la línea es inmediata. Para que este sistema funcione es indispensable que cada operario sepa realizar varias 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 tener señales visuales para la comunicación. Por ejemplo, etiquetas para productos en proceso que permiten conocer tanto lo que se hace en un determinado paso como lo que se hace en los pasos anteriores y siguientes. También se utilizan luces amarillas y rojas para indicar un problema o una detención del trabajo. Pizarras para anotar todo asunto 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ón de 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 otros lugares? ¿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 de intentar conocer a otros. El “benchmarking” comienza con una comprensió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. Si usted va a compararse con otra persona, más vale

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


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

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

La lista de soluciones es discutida y presentada a la autoridad 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 estudio de 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 recibir su producto? una forma puede ser mediante un sistema de teletransporte hacia su casa (como en la película Viaje a las Estrellas)… Es importante darse 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 una semana en un proceso de importaciones,

versus los tres meses de la situación actual, se reconoce porque disminuir más

el 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, ahora volvemos a ser “adultos”, serios: ¿qué se puede llevar a cabo?, ¿cómo se hace en otros lugares?… Aquí se trata de “negociar con la realidad” para obtener un ideal factible (desde el cual se pueden obtener los objetivos). Por ejemplo, estimamos factible disminuir desde doce a un minuto el tiempo de espera de los clientes frente a la caja.

2.4. Restricciones de la solución

Se trata de indicar con toda precisión aspectos que acotan el universo de posibilidades, por ejemplo, el costo de la solución no puede superar el costo del problema o un determinado monto, por restricciones presupuestarias o porque aparece un costo de opor-tunidad, es decir, pueden existir otros problemas de costo alto con soluciones de costo bajo para la orga-nización que darían más rentabilidad interna a la misma 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 son clientes. Estas restricciones debieran estar incluidas en el plan de proyecto. Otro ejemplo, un flujo debe mantenerse 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 ámbito de 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 el servicio se otorgue conservando un cierto nivel de beneficios.

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

• El Estado espera que se respeten las leyes y se paguen los impuestos debidos.

• Los empleados esperan que no haya despidos por motivo del rediseño.

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

JUAN BRAVO 98

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

restricciones, sino que hablamos de variables 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 en el 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 objetivos generales

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

Considerando el barrido de soluciones y las restricciones, el comité de proyectos selecciona un pequeño conjunto de alternativas (2 ó 3 generalmente) que serán evaluadas en detalle.

Asimismo, el nivel del avance ya permite definir objetivos 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 propio plan de desarrollo y mantenimiento. Además cada una debiera incluir los costos y beneficios durante todo su ciclo de vida estimado, no sólo durante el desarrollo 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 carga de trabajo en los nuevos cargos? ¿La estructura es la apropiada al proceso? ¿Existe integralidad? ¿La tec-nología es la adecuada?…

En relación a costos, es importante contemplar que en promedio las

inversiones tienden a nivelarse en los cinco elementos del modelo integral del cambio: estrategia, personas, procesos, estructura organizacional y 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ás importantes 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 propios criterios 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 propuestos Avance previo del trabajo de rediseño Aporte social del trabajo de rediseño Costo/beneficio de la solución Imagen frente a clientes

Impacto Avance Social Contribución Imagen

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 el ejemplo de procesos en un banco tomado desde el libro Gestión de Procesos.

Cada factor de decisión se evaluó con una nota de 1 a 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 cual surge de la siguiente fórmula general para cada pro-ceso:

Nota final ponderada (NF) = Σ (Nota del factor x peso 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)

Nota final

1. Apertura cuentas bipersonales

5 4 2 4 2 3.9

2. Entrega de libretas de ahorro

4 3 4 2 2 3.3

3. Apertura cuentas personales

5 2 1 3 2 3.2

4. Confección libretas de ahorro

3 1 2 5 4 2.9

5. Captación de depó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 cuentas bipersonales:

NF = 5 x 0.4 + 4 x 0.2 + 2 x 0.15 + 4 x 0.15 + 2 x 0.1 = 3.9

NF = 2 + 0 .8 + 0.3 + 0.6 + 0.2 = 3.9

Una vez realizados los cálculos, la lista se ordena de mayor a menor.

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

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

El comité de proyectos decide un camino, puede ser directamente una de las alternativas o puede ser una mezcla 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ás bien un proceso iterativo que una acción inmediata con 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 la necesidad y de las soluciones, ya se


pueden plantear además los objetivos específicos del proyecto.

Más bien, lo que concretamente se espera lograr de cada 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 proyecto

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

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

El plan de proyecto considera tanto las actividades de cada etapa como las prácticas transversales de los proyectos.

En realidad el plan de proyecto no es un plan, sino que 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 de hacer este estudio ya existe un compromiso tácito y sobre 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 incluye la primera estimación de costos del

proyecto

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

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

Durante las etapas de implementación y despliegue se calculan los costos reales y se comparan con las estimaciones, 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 identifica cuatro 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 hecho de 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ño para presupuesto.

• Estimación detallada, realizada cuando se cuenta con 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 proyecto actualizado y la autorización del inicio del comité de proyectos. Es el inicio de la ejecución del proyecto.

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

Entregable de la etapa: el modelo integral del cam-bio de la solución.

~§~

Se trata del análisis integral de la solución. También es 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 la tecnología de información.

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

sustentado en la estrategia de la organización.

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

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


y flujogramas de información, desde donde surgen las 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ísico tal como movimiento automatizado de carga. Sin embargo, nos concentraremos aquí en la TI, especí-ficamente en las actividades que tienen algún nivel de 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 y tipo de trabajo, en esta etapa el trabajo es minucioso, porque las definiciones que de aquí se obtengan darán forma definitiva a la 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 la etapa de factibilidad sigue siendo válida, de hecho sucede a veces que el trabajo de análisis comienza tiempo después del estudio de factibilidad y algo podría haber cambiado.

JUAN BRAVO 108

A veces, esto puede dar origen a un replanteamiento de 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én ocurre, por ejemplo, en las empresas constructoras, cuando el ingeniero a cargo, a quien se le acaba de asignar una obra adjudicada, ignora la propuesta que hizo antes el equipo de un departamento de estudios.

Ceremonia de inicio

Ahora sí, el proyecto se entrega al equipo designado y se pone en marcha el desarrollo con las primeras actividades del plan de proyecto.

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

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 integral de la solución. Debe estar bien sustentado en la es-trategia de la organización. Ya indicamos que se parece a una mesa…


Un proyecto de cambio puede representarse como una mesa, donde la cubierta es la estrategia y los pilares 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 integral que debe ser bien conocido por todo el equipo de proyecto.

Puede ser desde un solo analista quien, junto con un usuario, concibe el modelo hasta un equipo de traba-jo de decenas de personas donde cada uno tiene la visió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 la solució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 estar sustentado 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 la Compañía es la guía principal para

proponer el modelo integral del cambio.

3.3. Personas

¿Qué sucede con las personas en el modelo integral del cambio para este proyecto? ¿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, ambiente de trabajo, formas de interacción, etc.

Se requieren planes orientados al equipo de trabajo y a los usuarios de la solución, eventualmente incluso de los clientes.

Trabajar con las personas considera dos aspectos vitales:


• 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ón dirigido a todas las personas que ahí se desempeñan es mejor. La transparencia, honestidad, información oportuna y participación son esenciales en la crea-ción de un clima adecuado al cambio.

Es vital la participación de las jefaturas en la difusión del proyecto. Esto nos lleva a que es necesario comenzar el proceso de anticipación desde las jefaturas.

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

3.4. Gestión de Procesos

Todo comienza desde un modelamiento de los pro-cesos, suponiendo que antes se hizo algún nivel de levantamiento de lo que existe.

Se requiere la descripción del nuevo flujo de trabajo y de los procesos relacionados, ya sean del negocio o de apoyo involucrados en el ámbito de trabajo del proyecto.

JUAN BRAVO 112

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

Mapa de procesos.

Es un tema tan importante que en las organizaciones más avanzadas tienen un mapa de procesos de toda la organización. Generalmente emplean herramien-tas de apoyo bastante robustas (M1, Aris, Corporate Modeler, etc.)

Por ejemplo, para una empresa comercial, una parte del 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 la empresa.

Flujograma de Información (FI)

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

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

Sigue el criterio: SPPP (Simplificar Procesos y Potenciar Personas) dejando de 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 quienes debería ser autoexplicativo.

• No es un diagrama de flujo computacional

17 Más detalle en los anexos del libro Gestión de Procesos (si usted sabí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 alguna relación con la TI y luego dan origen a los ca-sos de uso

Por ejemplo:

CLIENTE BODEGA FINANZAS

ADMINISTRATIVO DE BODEGA DESPACHADOR

PROCESO DESPACHO INMEDIATO

GD3’

OE

GD4

GD3GD2

GD1

GD4OE

Buscarproducto

GD’s

Cliente recibey firmarecepción

GD1’

Reservar y emitir GD

Rebajarsaldo

GD2’

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

PROCESO CUADRAR

PROCESOS VENDER

Nota: los números en los recuadros punteados señalan tiempos: duración de las actividades y, entremedio, tiempos de reposo de la transacció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ía ser 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 de la espiral.

Diseño de formularios

Se debe realizar el diseño de formularios asociados al detalle de los flujogramas de información. Válido para 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 la técnica UML

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

Específicamente ese punto de encuentro está en las actividades con alguna interacción computacional del flujograma de información, las cuales dan origen a 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 en el libro Gestión de Procesos, capítulo 11.

JUAN BRAVO 116

En concreto, cada actividad de tipo computacional debe 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.

Rebajar saldo

Rebajar saldo

Usa el lector para leer elcódigo de barras decada 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 “alto nivel” 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 casos de uso de cada proceso operativo (o flujograma de informació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 o eliminar cargos (agregar, mover o sacar cajas del organigrama), alcanzan también a: planes y propues-tas detalladas de externalización, delegación, trabajo en equipo, empoderamiento, más o menos supervi-sión, JIT, Kanban, etc.

Hemos acuñado el dicho: “un pterodáctilo no es una mariposa 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ón debe contemplar otra estructura. La estructura de

JUAN BRAVO 118

mariposa permite un tamaño hasta menos de 20 centí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 las tecnologías consideradas en el proyecto, tales como elementos de comunicación, transporte, almacena-miento, construcción, despacho, automatización de oficinas, 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 veremos en 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 no existan otros profesionales para desarrollar las ramas de personas, procesos y estructura organizacional que contempla la solución integral. En tal caso, los mismos 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 la formación del analista de sistemas19.

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

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

3.8. Ingeniería de requerimientos

Habiendo planteado el modelo integral del cambio, se especifican requerimientos en cuatro ámbitos principales: 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 de desarrollo, tal como finanzas, marketing, logística, etc. Son ámbitos relacionados que deberían estar contemplados 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 la

estrategia del proyecto y de la empresa y que 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 trabajo del 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 la tecnología de información. Se efectúan medicio-nes de dimensionamiento para la incorporación del número previsto de usuarios.

Todo comienza desde la rama de los procesos.


Se incluye detalle de la rama tecnológica utilizando UML.

3.9. Definiciones de la TI

Se plantean detalladamente aquí las definiciones de la tecnología de información propias del sistema de información en desarrollo, más bien de la parte computacional 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 los aprendizajes de ITIL (ver anexo 8).

3.10. Entorno Tecnológico

Se requiere el dimensionamiento de equipos compu-tacionales, software y comunicación. Esto significa incluir 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ógico deberían venir desde la etapa de factibilidad, espe-cialmente si tenían algún impacto en el costo del sistema.

JUAN BRAVO 122

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

herramientas de software y hardware, tal como preparación de propuestas y

contratos, 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, por ejemplo:

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

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

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

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

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


cumplidos en la etapa de implementación, la cual está muy lejos todavía. Sucede a veces que las per-sonas tienen dificultades con los compromisos y al momento de implementar es necesario entrar a otro proceso de negociación. Por ejemplo, la persona que el gerente comercial había comprometido para el próximo mes fue destinada a ciertas labores urgentes y 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, porque son 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 o externos.

También los usuarios operativos, es decir, quienes deberá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 de productos de supermercado y si no es posible, con un código numérico lo más simple posible. Como última opción y si realmente se justifica (el autor no lo ha visto hasta hoy) utilizar un código compuesto.

3.14. Requerimientos computacionales

En lo que se refiere a la definición de requerimientos para 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étodo de trabajar con el mínimo indispensable,

para que efectivamente pueda ser aplicado en 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 se pueden encontrar en los anexos 2 y 3, acerca de UML y RUP, respectivamente.

Nótese que este método no trata en profundidad acerca de UML, sino que solamente toma lo necesario para aplicar en el método genérico de desarrollo de Sistemas 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ían aplicarse a representar realidades con otros fines.

En consecuencia y al igual que otras materias, la descripción de UML contenida en este método es breve.

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 en el flujograma de información.

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

JUAN BRAVO 126

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

3.16. Caso de uso de alto nivel

Los casos de uso de alto nivel incluyen a un actor o varios actores (que pueden ser personas u otros sis-temas computacionales identificados con el símbolo tipo dibujo de niño), también un dominio (en este

20 Cuando se realizan talleres del método, un ejercicio típico para este 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 del del á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 del del área de Adquisiciones (O/C=Orden de Compraárea de Adquisiciones (O/C=Orden de Compra)

Administrativo de Administrativo de

Cotizar

Terminales del área de Adquisiciones

Jefe de Adquisiciones

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 del del á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 del del á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 la narració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 el universo completo de casos de uso esté descrito en alto nivel o como diagramas de casos de uso.

Entonces, los casos de uso seleccionados para la respectiva vuelta de la espiral se transforman en ca-sos de uso expandidos.

Ejemplo de caso de uso de alto nivelEjemplo de caso de uso de alto nivelIngresar Orden de Compra (O/C)Ingresar Orden de Compra (O/C)

Ingresar O/C

Ingresa la Orden de Compra a partir de los documentos de cotización a proveedores,

La O/C queda disponible para ser enviada al proveedor luego de aprobación electrónica por el jefe de Adquisiciones

Terminal en bodega

Administrativo de Adquisiciones

Ejemplo de caso de uso de alto nivelEjemplo de caso de uso de alto nivelIngresar Orden de Compra (O/C)Ingresar Orden de Compra (O/C)

Ingresar O/C

Ingresa la Orden de Compra a partir de los documentos de cotización a proveedores,

La O/C queda disponible para ser enviada al proveedor luego de aprobación electrónica por el jefe de Adquisiciones

Terminal en bodega


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 al final 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 producto en (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


Respuesta del sistema...3. Verifica correlativo y envía respuesta en (B)5. Verifica que proveedor exista, obtiene y despliega nombre y fono en (E) y (F)Para cada línea:

8. Verifica existencia del producto, obtiene y 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 producto en (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


Respuesta del sistema...3. Verifica correlativo y envía respuesta en (B)5. Verifica que proveedor exista, obtiene y despliega nombre y fono en (E) y (F)Para cada línea:

8. Verifica existencia del producto, obtiene y 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 del sistema, las excepciones van aparte. No siempre una acción del actor tiene respuesta del sistema, como la acción 1: “Tomar la O/C desde el archivador” (que está en algún mueble cercano).

El caso de uso se complementa con una copia del documento Orden de Compra (O/C) y de la Interfaz de la pantalla, donde los campos se indican con le-tras mayúsculas.

3.18. Modelo Conceptual

El modelo conceptual define responsabilidades y el dominio del sistema computacional, al comienzo asociado a los casos de uso identificados. Es un mo-delo que se va construyendo en paralelo con los ca-sos de uso.

Identifica los conceptos más relevantes del mundo real en el dominio respectivo: roles de personas, ti-pos de documentos, elementos físicos, etc. También identifica las asociaciones entre conceptos con pala-bras de enlace: usa, registra en, almacenado en, pa-gado por, contenida en… Se trazan líneas entre los conceptos para representar este detalle.

En esta etapa, una recomendación es incorporar en el modelo el máximo de conceptos y el mínimo de asociaciones.

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ás 1..12 : de uno a doce 3 : exactamente 3 2, 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 encontiene

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 un solo encabezado de O/C.

• Un encabezado de O/C contiene un proveedor. Un proveedor existe en 0 ó más encabezados de O/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, una asociación de composición, equivalente a la relación de 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 la O/C no puede existir sin su encabezado, y viceversa.

21 Ver libro La Nueva Visión, Diseño y Construcción de Sistemas Computacionales.

JUAN BRAVO 132

En los conceptos también existen atributos, tal como se 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

unidadesprecio

Productos...

Bodega...

Encabezadode O/CNº O/CFecha

ProveedoresRut

Nombre

1

1..*

compuesta por

se asocia a

* 1

existe encontiene

* 1

contiene existe en

* 1

existe en

almacena

3.19. Diagrama de secuencia del sistema

El objetivo del diagrama de secuencia es identificar las operaciones 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, se identifican las operaciones del sistema, aquellas que obligarán al sistema computacional a hacer algo y que afectarán a uno o más conceptos de aquellos incluidos en el modelo conceptual.

En la siguiente figura se muestra la forma general del diagrama de secuencia para un caso de uso don-


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, provoca que algo suceda fuera de la frontera del caso de uso.

Al principio el sistema computacional se ve como una caja negra (todo el sistema está representado por la columna Sistema). Sin embargo, en la medida que se avanza en el detalle de los requerimientos, la 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 letrase hacen aclaracionesal diagrama

Repetir hastaque no haya más productos

Operación (o mensaje)que activa una o másfunciones 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 letrase hacen aclaracionesal diagrama

Repetir hastaque no haya más productos

Operación (o mensaje)que activa una o másfunciones 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 algo central 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án probablemente a varios conceptos (o clases).

Notas:

1. Las operaciones del sistema y el diagrama de secuencia son uno a uno con el caso de uso.

2. Tanto el diagrama de secuencia como la visión dinámica del sistema tienen las mismas operaciones, más bien lla-

22 Ver libro La Nueva Visión, Diseño y Construcción de Sistemas Computacionales.

Visión dinámica del Sistema

Sistema

Ingresar Nº de O/CIngresar código de productoIngresar cantidadDar OK a la línea

Caso de uso Ingresar O/C

Caso de uso Aprobar cotización

Ingresar Nº de cotizaciónDar OK al documento...

Ingresar Nº de O/CDar OK al documento...


Visión dinámica del Sistema

Sistema

Ingresar Nº de O/CIngresar código de productoIngresar cantidadDar OK a la línea

Caso de uso Ingresar O/C


Ingresar Nº de cotizaciónDar OK al documento...

Ingresar Nº de O/CDar OK al documento...

Caso de uso Aprobar cotizaciónCaso de uso Aprobar cotización


madas a operaciones, porque corresponden a estructura de mensajes 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 cuales tiene la estructura de atributos y funciones.

Cuando se trata del primer caso de uso que estamos desarrollando en una aplicación, el diagrama de se-cuencia y la visión dinámica son iguales, desde el segundo se diferencian porque la visión dinámica es acumulativa, va agregando las operaciones de los diferentes casos de uso.

3.21. Diagrama de estado

El diagrama de estado de los casos de uso representa grá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, hemos preferido 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án tantos como operaciones se hayan identificado en el caso 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 (talcomo 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íneaResponsabilidades: 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 ydetalle de O/C.

Se identificó, en tiempo verbal pasado, cómo fueron afectados 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 con una descripción detallada de los requerimientos de usuario 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 de interfaces, sería necesario:

• Describir los objetos de la interfaz de usuario más relevantes 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 y otras profesiones en el diseño de intefaces.

3.24. Prototipos desechables

En esta etapa solamente para ayudar en la definición detallada de funcionalidad principal e interfaces vi-suales, tales como formatos de pantallas, informes y menús. Una vez que los prototipos ha cumplido esta finalidad, 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 por otros profesionales, internos o externos.

3.26. Uso de herramientas

Especialmente para UML, existe una amplia gama de herramientas en el mercado que ayudan en los modelos indicados (Visio, Rational, UML Studio, Enterprise Architect, etc.).

En la parte tercera una de las prácticas se refiere a herramientas.

La recomendación es usar herramientas de apoyo, realmente facilitan el trabajo y si el sistema es grande, son indispensables. 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 proyecto

La 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 proyecto actualizado, 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 esta etapa.

Entregable de la etapa: el detalle técnico del modelo integral del cambio.

~§~

Se diseñan en detalle los componentes del modelo 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 el desarrollo en detalle del modelo integral del cambio.

Esto es necesario aun en proyectos pequeños, igual las 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 conjunto con 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 “se entrega o delega el trabajo a especialistas”, porque se trata de un trabajo conjunto.

En esta etapa normalmente se recurre a la asesoría especializada, porque hay que ir a los detalles, pro-bablemente empleando simbología y terminología más precisa. Algunas sugerencias son:

• Trabaje en conjunto con el especialista hasta ob-tener el resultado deseado, porque habrá mucha labor 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 alarde de sus conocimientos y tiene la capacidad de ex-plicar materias complejas con simplicidad.

• Conserve la visión de conjunto y asegúrese que los 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 procesos

En esta etapa del ciclo de desarrollo de un proceso se 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 software

Tambié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ño de 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 posibilidades concretas de ser implementado, con recursos acotados y herramientas disponibles.

Este conjunto de orientaciones son independientes de la implementación.

Intuición. El diseño es una tarea eminentemente creativa, 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é es la intuición? Hay quienes dicen que es una de las voces 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 “La Nueva Visión, diseño y construcción de Sistemas Computacionales”

JUAN BRAVO 144

vez algo cambió en la realidad o existe un problema de 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ón incompleta.

Simplicidad. Habitualmente, la elegancia va de la mano con la simplicidad, es más, se podría plantear la 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 una excelente inversión.

La simplicidad también se refleja en mantener una solución “limpia”, sin particularizaciones innecesa-rias ni ingeniosidades.

Existe simplicidad en el diseño cuando lo entienden los demás, incluyendo

especialmente al usuario y cuando se siente que es simple.

Totalidad. El diseño del proceso debe considerar todos los elementos, aun cuando algunas partes sean incorporadas sólo para conservar la visión de con-junto, sin llegar a un nivel profundo de detalle. La totalidad responde a la necesidad de una visión holística del problema. Lo importante es captar la realidad y llevarla a los modelos.

Generalización. Cada problema, apropiadamente planteado, no es más que un caso particular de un


problema general más fácil de resolver. Así se hace inversión en inteligencia, porque los nuevos pro-blemas particulares que se vislumbran ya estarán resueltos. Es un signo de inteligencia no resolver siempre los mismos problemas. Esto significa buscar el “metaproblema”, aquél que representa a todos los problemas del mismo tipo.

Transacciones presentes para la actualización de la información

En la gestión de procesos hablamos de transaccio-nes, ya sean ventas, compras, créditos, traspasos de productos, etc. En esta etapa se diseña en detalle el juego de transacciones del proceso. Por ejemplo, no es 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ón cuando se requiera corregir información (factura errónea). En este caso mediante transacciones de notas de crédito, débito o ajustes.

Lo importante aquí es la trazabilidad, que se pueda seguir la pista de cómo se van actualizando los datos, siempre mediante transacciones formales, jamás interviniendo en forma directa un archivo.

Incluso en la interacción con los especialistas de informá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 un error en la factura emitida ayer y que ya afectó a los maestros de inventarios y de cuentas contables? Una “solución” generalizada es arreglar “a mano” los maestros involucrados, significa intervenir directa-mente el resultado en el maestro; por ejemplo, in-crementar el inventario en dos unidades. Esto tiene muy 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 y los archivos quedarían inconsistentes… Es evidente que se pasan a llevar normas elementales de calidad, trazabilidad, control y auditoría.

La solución es aplicar otra transacción formal, una transacción presente que revierta la anterior; en el ejemplo, puede ser una nota de crédito. ¿Qué sucede si 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 del manejo de información en el proceso, donde existen múltiples fórmulas, ya sea aumentando oportunidad o confiabilidad, tal como al aplicar máxima validación de los datos en el momento que ingresan al computador.

4.2. El diseño del software

Específicamente en el diseño del software se trabaja en: modelos de datos, identificación de clases: mo-delos generalizados, diagrama de clases del sistema, visión interna con diagramas de clases y objetos y diagramas de colaboración, entre otros modelos.

En esta propuesta de procesos y tecnología se trabaja con 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 que se dominan técnicas de ingeniería de software, tales como:

• 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 • UML

Se utiliza la biblioteca de clases, la orientación a objetos y las herramientas de apoyo.

Aquí se define en detalle todo el sistema de 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 representar las 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 clase personas y heredan de ella sus elementos comunes.

Nace desde el modelo conceptual e incorpora las funciones necesarias para cumplir con el objetivo de los casos de uso.

Por ejemplo:

Líneas de la O/C

unidadesPrecio

Agregar línea

Productos...

Bodega...

Encabezado de O/C

Nº O/CFecha

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 la O/C

unidadesPrecio

Agregar línea

Productos...

Bodega...

Encabezado de O/C

Nº O/CFecha

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, que fueron pensados y desarrollados con ese fin, aunque también puede suceder que en el transcurso del avance 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 cabo un 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 la

misma instalación o del medio. El sueño es tener todas las clases disponibles y

solamente utilizarlas.

4.4. Diagrama de colaboración

Para cada operación del caso de uso seleccionado se presenta un diagrama de colaboración y detalles de implementació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ón tecnológica, por este motivo se prefiere avanzar en características de la 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ón de la biblioteca de clases25 (que en un esquema de orientación a objetos es un requisito), por ejem-plo, la condición de existencia. Corresponde al detalle 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 laO/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 de este 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 sistemas existentes

• 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 para construir 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ús

b) Modelo de dos o tres capas según las plataformas y definiciones de la instalación, por ejemplo, para tres 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 de datos, así como la forma de administración de los datos (para preparar código de almacenamiento de datos).

c) Describir los objetos utilizados para implementar interfases, lógica de la aplicación, interacción con otros 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ácter piloto.

Entregable de la etapa: el informe de buen funcio-namiento del piloto del proyecto.

~§~

Se trata de implementar (también construir, realizar o llevar a la práctica)

la solución completa que propone el modelo integral del cambio, aunque para

el piloto previsto.

Algunas acciones de la etapa:

• Las personas son capacitadas y reubicadas. • Se implementan las nuevas definiciones de

los procesos. • Se aplica la nueva estructura organizacional.


• Se instala la aplicación de software, proba-blemente en variadas máquinas.

En particular, veremos la implementación desde el punto de vista de procesos y Tecnología de Informa-ción (TI) las cuales normalmente avanzan de manera má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, apoyo computacional, una política acerca de las personas o el diseño de un estructura organizacional.

Implementar también implica retroalimentar el diseño sobre aspectos no contemplados con anterioridad.

Es necesario asegurar paso a paso que efectivamente la solución cumple su objetivo. La flexibilidad es fundamental para efectuar las correcciones que sean necesarias sobre el plan original. La participación y capacitación de todos los interesados, así como el manejo 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 el tiempo 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 empresas donde se han efectuado inversiones de cientos de miles de dólares en equipamiento que ha quedado abandonado… 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 que ya está comprometido? Porque la experiencia indica que este es un factor crítico. Ahora que es necesario llevar los planes a la práctica, sucede que personas con que el analista contaba están destinadas a otras labores urgentes —supongamos justificadamente—. Espacios físicos que el analista sabía que tendría, no los tiene, porque hubo otras prioridades… Un equi-po computacional prometido para cierta fecha no llegó… Estos son los supuestos realizados en las etapas de factibilidad y análisis, para los cuales de-bieran existir planes de contingencia.

Es importante aclarar que negociar los compromisos no significa permisividad ni

tolerar el incumplimiento de las tareas, sino que se trata de simple adaptación a

las contingencias del mundo.


Por lo demás, es casi seguro que muchas de esas contingencias ocurrirán.

Se puede abordar este tema de los compromisos acortando los tiempos de rediseño, es una razón por la cual empleamos la técnica de rediseño en espiral.

Otra forma es aprendiendo a negociar: reiterando la actualidad de los objetivos que dieron origen a los compromisos asumidos, escuchando, intercambiando, buscando nuevas posibilidades creativas. Nada de esto estaba en los planes, aunque sí deberíamos contar con que un porcentaje de acciones programadas no se realizará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ón de los procesos:

• Mantener comunicación con todos los actores involucrados es esencial. Buenas experiencias se han logrado con una o dos reuniones semanales con representantes de los consultores que apoyan el rediseño, el equipo asesor en metodología, el equipo interno de trabajo, el equipo de trabajo en el á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 nivel de 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 el grueso del rediseño y del apoyo computacional tiene que seguir las formalidades metodológicas (el desarrollo en espiral es recomendable)

• Tener la flexibilidad para resolver con rapidez los inevitables problemas que se producirán, es ideal tener una persona o un equipo “de acción rápida”. Es aceptar y trabajar con la complejidad26.

Que esto no se confunda con improvisación ni que sea una excusa para

una mala planificación, es simplemente responder con variedad a la variedad

natural del medio, aquella difícil de predecir.

• Tener disponibilidad de los integrantes del equipo de trabajo para con los usuarios. Es crítico en la relación con el usuario del proceso, es preferible invertir 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 de BancoEstado —ver anexo 7— donde a veces un analista destinaba varios días de su tiempo a estar

26 El libro Análisis de Sistemas aborda el tema de la complejidad de los 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 con ahorros en soluciones tecnológicas más sencillas. Los resultados fueron realmente de excelencia.

• Mantener verdaderamente “puertas abiertas” en el equipo 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 de vacaciones fuera del país justo en el momento de la 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 de información, la etapa se refiere a llevar el diseño a la realidad, en un lenguaje específico y en una máquina determinada.

Muchas veces no hay construcción propiamente tal, sino que el armado de una solución de software.

En esta etapa hay amplia utilización de código reuti-lizable. Bajo el concepto de trabajo con clases se utiliza una biblioteca de clases (que en un esquema de 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 la etapa 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 de clases. A veces llamados “desarrolladores”.

Luego otro equipo usa esas clases, y otras desarro-lladas con anterioridad para construir o referenciar el có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 en base a componentes. A veces se les llama “integra-dores” a estos profesionales.

También se podría trabajar con generación de código, utilizando una línea

de herramientas tipo Genexus o LINC, es una variante al trabajo con componentes

que 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ón debe ser probada inmediatamente. Por ejemplo, en la


construcción de una casa resulta evidente que al terminar el tendido eléctrico y antes de efectuar ter-minaciones, nos aseguremos de su correcto funcio-namiento.

Es necesario probar en detalle y con minuciosidad progresiva todos los aspectos del proceso y de la aplicación, esto se puede hacer como si fuésemos abriendo 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 interno especializado en Testing, los usuarios y empresas que ofrecen ese tipo de servicio.

Pruebas unitarias

Desde el punto de vista de TI, se realizan pruebas unitarias por los mismos programadores.

Una buena técnica que también se emplea es realizar la pruebas unitarias en forma cruzada, 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, son cada 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, en diferentes 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 integrado funciona correctamente y satisface su especificación actualizada.

Se requieren pruebas de integración, pruebas finales e 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 es comenzar a operar el proceso rediseñado en carácter de piloto, considerando un período de prueba integral con datos reales 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 contempla instalar el sistema en alguna máquina específica y comenzar 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 requerimientos explícitos y tácitos bien identificados y probados, luego se replica para todos los usuarios. El prototipo es para que el usuario vea un boceto de lo que quiere o para probar aspectos específicos de la funcionali-dad, luego se desecha.

Una recomendación es asegurarse que efectivamente 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 del sistema antiguo (manual y/o computacional) con el nuevo durante un período determinado.


• Asegurarse que existen los manuales de usuario y del 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 el proceso de paso a producción:

• En primer lugar es un proceso que debe estar bien definido 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 generalmente aceptadas 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 y sus requerimientos, el diseño (o ingeniería de deta-lle) de la solución y la implementación en carácter piloto 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 plan

de proyecto.

Entregable de la etapa: el informe de puesta en marcha completo del proyecto

~§~

Se trata de instalar la solución completa que propone el modelo integral del cambio:

• Las personas son capacitadas y reubicadas (la sensibilización y otros aspectos ya deberían estar logrados)

• Los procesos definitivos son llevados a todos los puntos donde serán utilizados.

• La nueva estructura organizacional se pone en marcha.

• Se instala la aplicación de software, proba-blemente en variadas máquinas.


En particular, veremos aquí el despliegue desde el punto de vista de procesos y tecnología.

6.1. Revisar y actualizar elementos

Se trata de asegurar la disponibilidad de todos los elementos 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 ingresar y detallar su solicitud, luego en el mismo software se puede asignar un encargado.

Se requiere una mesa de ayuda, con opciones de soporte 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 procesos y la aplicación que exige gran atención.

• Que los ejecutivos debieran estar especialmente alertas para facilitar el despliegue.

Conviene enfatizar los aspectos de comunicació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 un cajero– supervisores que deben tomar decisiones rápidas con base en una mirada global de lo que su-cede o ejecutivos que desean ver tendencias y totales en 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 de usuarios, por ejemplo:

• Revisar y actualizar el material (el cual debería estar 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 se emplea cada vez más es preparar capacitación ad-hoc en la red, e-learning, los usuarios se conectan libremente 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 porcentaje presencial)

• Reuniones ampliadas de los gerentes dando la partida al proceso.

“Capacitar a los capacitadores”. Cuidar los elementos pedagógicos. Un desarrollo impecable puede fracasar porque el especialista 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 usuarios previstos en el plan de proyecto. Requiere de la do-cumentación generada en todas las etapas.

Entregable de la etapa: mantener la solución en buen 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 mejora continua en esta etapa, así como la

aplicación computacional

El buen funcionamiento de la solución debe lograrse en todo el modelo integral del cambio de la solución (estrategia, personas, procesos, estructura organiza-cional y tecnología) Por tanto, la mejora continua opera en cada una de sus partes.

Es importante señalar que mientras se está trabajan-do en una vuelta de la espiral (suponiendo se emplea la técnica de desarrollo en espiral), no aplica todavía la mejora continua porque los casos de uso que se van desplegando están en desarrollo y todo el equipo de proyecto junto con los usuarios está atento a los cambios. 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 programado27, tal como veremos en la sección 7.6.

7.1. La mejora continua

La mejora continua opera a nivel del modelo integral de la solución (estrategia, personas, procesos, estructura y tecnología).

La mejora continua, también llamado mejoramiento continuo28 son pequeños y permanentes perfeccio-namientos de un sistema, proceso, producto, unidad organizacional 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 y económicos es una meta deseable para cualquiera empresa. Veremos aquí algunas formas efectivas de lograrlo.

Desde los fundamentos que provee la visión sistémi-ca29, aplicamos el principio de continuidad, significa una 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ón prá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ícipes del sistema.

Aporta Robert Kriegel (1994, p. 210): “una gran cantidad de pasos pequeños lo pondrá en capacidad de alcanzar sus metas más rápido y más fácilmente de 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ñe en 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 se llega.

Algunas veces el mejoramiento continuo surge des-de la implementación de un Sistema de Gestión de la Calidad, en tal caso, algunos requisitos serían (ISO 9001: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 para asegurarse de que tanto la operación como el control de estos procesos sean eficaces”.

Continúa el texto de la norma ISO 9001:2000 con asegurar la disponibilidad de recursos e información para apoyar la operación, el seguimiento, la medi-


ción, el análisis y la mejora continua de todos los procesos.

Nótese que todo gira en torno a los procesos, con inicio y término en el cliente.

Algunas herramientas del mejoramiento continuo

Algunas de las herramientas30 más efectivas de me-joramiento continuo son:

1. Benchmarking 2. Flujograma de Información 3. Estandarización interna y externa. 4. El ejemplo personal. 5. Kanban (sistema visual) 6. Compensadores de complejidad 7. El momento de la verdad 8. Seis Sigma 9. Ciclo PDCA (Plan Do Check Act). 10. Técnica de las 5-S 11. Realizar tormentas de ideas 12. Implementar círculos de calidad 13. 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 profundidad de 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 de aceptació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 del Departamento 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 APLICACIONE S COMPUTACIONALES

Asignar Analista

SUBCOMITÉ CAMBIOS

Estudiar impacto

Casos de uso

Emitirinforme

II

Plan de Desarrollo

PDPD’

USUARIO AUTORIZADO

II ’

PD’’PROCESO IMPLEMENTAR

SC

SCII’

1. Emisión de una solicitud de cambio menor por parte 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 para realizar 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 usuarios solicitantes y relacionados, el Jefe de Informática y el analista que realizó el estudio de impacto. Se toma alguna decisión de cambio.

5. El analista presenta el plan de desarrollo preciso del requerimiento, incluyendo equipo de trabajo y costos, de acuerdo con las indicaciones del 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 a una 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 de programas, 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 fundamental durante la implementación del sistema y luego durante su operación.

Puede ser parte de la mesa de ayuda central en la organización.

Con todos los elementos que se acostumbra en estos casos, por ejemplo, escalamiento de niveles según la profundidad de la ayuda y una buena formación del primer nivel para que resuelva la mayor parte de las consultas.

7.4. Buena operación de la aplicación

Se trata de trabajar sistemáticamente al menos en las siguientes prácticas:

• Mantención de una bitácora de los procesos más relevantes

• 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 calidad

Durante la operación se requiere asegurar, entre otros aspectos:

Que se continúa operando en conformidad con los requerimientos 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 del sistema 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 la espiral. Se revisa y adapta desde el modelo integral del cambio de la solución.

De esta forma, muchos de los nuevos requerimientos, mayores o menores, seguirán esta vía en lugar de la mejora.

Además, programar un ciclo de desarrollo permite resolver problemas de consistencia, de regeneración de 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 de tamaño mediano se rediseñaban con éxito una vez al año y otras, más grandes, una vez cada dos años.

Un beneficio lateral es disminuir la presión por las modificaciones 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 gran cantidad de acciones bien coordinadas que ayudan a lograr el todo, en este caso, un proyecto exitoso. Es un efecto sinérgico.

Se trata de prácticas transversales que influyen en todas o en la mayoría de las etapas del proyecto31 (de (de hecho,).

Estas prácticas se aplican en la fase de estudio y luego deben quedar

incorporadas en el plan de proyecto, en la forma de planes específicos.

Las mejores prácticas en proyectos

Estas prácticas surgen justamente de observar las mejores prácticas en buenos proyectos.

Cada una puede ser tan extensa como se desee y ha sido un esfuerzo resumirlas.

La mayoría de ellas están detalladas en los libros del autor señalados en el prólogo y hacia el final de la introducción.

31 Una pregunta habitual en evaluaciones acerca de este método es algo 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 que indudablemente deben estar presentes en todas las etapas. El resultado no señala precedencia, eso de-pende del método específico que la organización adopte.

Este criterio de ordenamiento no pretende juzgar niveles de importancia de cada práctica, porque cada una 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 existe un método para realizar este tipo de proyectos en la organización, la forma de trabajar con las prácticas transversales estará indicada en el método, en tal caso, la revisión es más general. Por ejemplo, la prá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 un proyecto 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 contenido de las políticas, porque es lo que verdaderamente aplicará 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. Ese es el resultado concreto a donde conduce la revisión de las prácticas transversales.

Por ejemplo, en el control de cambios es necesario contemplar el tiempo de negociación del jefe del proyecto con el usuario, independiente de que el cambio se realice o no.

¿Podría llegar a ser el 20% del presupuesto para los cambios? Puede ser, depende de la organización, por eso es necesario disponer de una base de datos de está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 de un cambio.

También en esta base de datos deberían incluirse estos 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ño

cero o uno de un flujo de caja. • Costos de movimientos internos y externos de

mercaderías. • Valor hora promedio de los ejecutivos, de los

profesionales, mando medio y personal operativo para efectos de cuantificar las propuestas, en par-ticular el ahorro que se puede generar (recordar multiplicar 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 del tipo de ejercicio que debería hacer un jefe de pro-yectos o un analista de estudios respecto a que prácticas incorporar en cada etapa del proyecto. Esto dependerá del proyecto mismo y de la política de cada 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 x

14 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 x

21 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 x

28 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, la práctica más relevante para el éxito del proyecto.

La dirección del proyecto es una visión y acción de conjunto de todas las

actividades necesarias para cumplir con lo prometido, particularmente en calidad,

eficiencia, eficacia, satisfacción del cliente, 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 de decisió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 el equipo 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 de

trabajo: 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ón que será necesario construir, etc...) más allá del plan de proyecto.

Se trata de comenzar cada etapa revisando el plan de la misma etapa y tal vez replantear el plan general del resto del proyecto.

Se hace una programación detallada de la etapa, con fechas precisas e incluso horarios en algunos casos. El plan de la etapa puede ser el único plan que existe, como en el caso de la factibilidad (por-que todavía no hay proyecto).

Siempre implica una revisión del plan general del proyecto. Son re-estimaciones a la luz del avance.

Es conveniente considerar que en cualquier etapa se puede cancelar el proyecto o volver a una etapa an-terior, por ejemplo, si se detectó algo no considerado o si hubo un cambio relevante en el entorno para el par problema-solución.

Una recomendación: asegúrese que lo definido en la etapa anterior sigue siendo válido, especialmente si pasó mucho tiempo entre etapa y etapa.

Por supuesto, el plan de la etapa debe ser aprobado por 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 a todos los actores relevantes, al interior y exterior del equipo de proyecto.

Es conveniente porque surgirán muchas sugerencias para lograr éxito en el proyecto. En el fondo, lo más importante es la retroalimentación que se logra.

Al exponer los planes a todos los actores relevantes se mejora la coordinación del

proyecto.

Aquí tienen especial relevancia las competencias del equipo de trabajo para exponer a un grupo de perso-nas en forma clara y precisa.

Son competencias de comunicación, personales en cuanto a desarrollar un mensaje y técnicas en cuanto al uso de herramientas, tal como un software tipo Power 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 la fuerza, 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 lo planeado para la etapa. Se comunican los resultados al 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 en grupo, en un proceso continuo. Si tuviéramos que hacer nuevamente el mismo trabajo de la etapa, ¿cómo lo haríamos?, ¿qué cambios introduciríamos?

Retroalimentar es una práctica que debe incluirse tanto al término de cada etapa como al finalizar el rediseñ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 del conocimiento, porque las conclusiones que se deri-van de las sesiones de retroalimentación deben ser compartidas y adecuadamente archivadas en medios digitales. De esta forma el aprendizaje pasa a ser patrimonio de la organización.

No existe enseñar, solamente existe aprender y en esto 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, usuarios ejecutivos y consultores —se gana el “efecto consul-tor”, una mirada externa fresca—, según el tipo de proyecto. Debe estar claro quién es el director del proyecto. 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 del equipo 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 y realizar el plan de entrevistas.


6. ENTREVISTAS

Una práctica frecuente en los proyectos es la realiza-ción de entrevistas a usuarios, ejecutivos y personas de fuera de la organización. La finalidad principal es levantar información útil al proyecto y se comple-menta con otras técnicas (encuestas, informes de consultorí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 posterior para incorporar las conclusiones al proyecto y cum-plir los compromisos adquiridos.

Durante la entrevista lo principal es crear ambiente, es decir, un clima de confianza con una actitud serena que surge de la puntualidad, preparación y presentación (las tres P de las entrevistas).

Escuchar, más que hablar. Practicar tacto, cortesía y sobre 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ál es el ideal?, ¿por qué?… este tipo de preguntas abren nuevas posibilidades y apuntan al cambio.

Evitar caer en la “trampa de la complicidad”, es de-cir, recibir secretos de los entrevistados o escuchar confidencias 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 el tipo de interlocutor (no es lo mismo comunicar a la dirección que a los funcionarios administrativos o a los clientes). Es conveniente comunicar mucho.

Esta sola actividad implica disponer de horas de es-pecialistas en comunicación, con dedicación parcial o total según la envergadura del proyecto.

Incluye la formación de diferentes tipos de mesas de ayuda según la etapa del proyecto.

Se puede comunicar a nivel de problema y a nivel de solución, es una actividad

completamente transversal.

Incluye todo el aspecto de presentación y exposición de los proyectos, desde la forma de presentar hasta el desarrollo de la competencia de saber exponer de los integrantes del equipo.

Un aspecto vital es la preparación del equipo de tra-bajo en el manejo de la emoción, particularmente al interior del equipo de trabajo. De hecho, es una práctica regular en empresas con una larga historia de proyectos exitosos realizar talleres de trabajo en equipo antes, durante y después del proyecto. Una excelente práctica es aplicar la escucha empática.

Todo comienza por comunicarse bien entre sí y una consecuencia es lograr lo mismo con los demás.


8. INFORMES

Cada etapa tiene uno o más entregables que deben quedar registrados en informes. En el plan detallado de cada etapa deben quedar resueltos aspectos tales como: ¿quién redacta qué informe?, ¿a quién se le entrega?

La práctica genérica es documentar e implica el de-sarrollo de las competencias mínimas en el equipo de trabajo (que es preferible no dar por adquiridas), por ejemplo: redacción, ortografía, capacidad de síntesis, etc. Al menos la habilidad de leer.

Por supuesto, debiera documentarse al mismo tiempo que se avanza en la etapa, evitando postergar.

La estructura debe ser parte de los estándares de la organizació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, lo cual 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 podemos disponer en cada etapa de un proyecto de

Procesos y Tecnología, sin embargo, la variedad es tan amplia que el método de

la 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 la reusabilidad, 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écnicas de comunicación

• Operación: benchmarking, mejora continua.


10. HERRAMIENTAS DE APOYO

Se trata de seleccionar herramientas de apoyo a las té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. Lo importante 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 apoyo en cada etapa, esa es hoy la realidad. Sin embargo, existe una tendencia a unificar en una sola o en un pequeñ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 de apoyo es que actúen a nivel del ciclo completo, incluyendo la generación de có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, ERWIN Data 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, donde el objetivo es que una clienta de un

supermercado en Europa pueda saber que el durazno que adquirió viene de Chile

(importador, exportador, puerto, etc.) y de un lote específico con detalle del lugar,

fertilizantes, suelos, etc.

En la trazabilidad los modelos principales deben estar permanentemente actualizados. Significa que si es necesario realizar un cambio en la solución im-plementada se actualiza toda la serie de modelos que dio origen al producto, al menos desde el análisis y eventualmente desde la misma necesidad que dio origen 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 el avance de la solución. Son entregables de acción rápida, generalmente acciones simples que fueron quedando en evidencia desde las primeras conversa-ciones.

Gracias a estas acciones tempranas se ven resultados a corto plazo y se alienta tanto a los operadores del proceso como a la dirección a continuar con el proyecto, renovándose la motivación y manteniendo la atención en el proyecto.

Un subproducto del trabajo en las etapas prelimina-res (concepción, factibilidad y análisis) es detectar Quick Wins.

La práctica transversal de la sensibilización se presta para organizar talleres donde los mismos usuarios operativos 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, para no caer en el exitismo de corto plazo y confundir al resto de la organización. Es razonable hacer cuanto antes los cambios que se pueden hacer, sin provocar la 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 como del proyecto completo. Es importante y valiente ver la realidad de lo que está sucediendo y reestimar si es necesario. No es cambiar por cambiar sino que adaptar el avance del proyecto a la realidad de hoy (imposible de predecir en su totalidad cuando se elaboró el plan de proyecto). Lo opuesto es cerrar los ojos y tratar de cumplir un plan que tal vez no tiene sentido. Ah... 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 tales como la misma planeación de la etapa, las

reuniones de coordinación y de negociació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 otros recursos. También el costo de las herramientas y licencias 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 muralla inamovible, puede negociar todo lo demás.


14. GESTIÓN DE RIESGOS

Se trata de detectar riesgos y elaborar un plan para mitigarlos y/o traspasarlos. Por ejemplo, en la con-cepción: ¿conviene abordar el problema? A veces el sentido común (y los amplios estudios de Maturana, Echeverría, Varela y otros) indica que el solo hecho de señalar un problema ya crea una expectativa. ¿Es el 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 de plazos, dejar de lado buenas soluciones, no conocer lo que el medio plantea, etc.

Cada etapa tiene sus propios riesgos que deben ser atendidos: una tecnología difícil de obtener, especia-listas escasos, cambio de prioridades, atrasos, costos excedidos, incumplimiento de proveedores, tecno-logía difícil de implementar, usuarios que no desean el nuevo proceso, apego irrestricto al plan, agota-miento, etc.

Se han identificado más de cien riesgos asociados a los proyectos de procesos y tecnología, lo mínimo es tener formas de detectar, transferir y/o neutralizar.

Una fórmula para priorizar riesgos: R = C x P. La magnitud del riesgo (R) se obtiene multiplicando el costo si ocurre (C) por la probabilidad de ocurrencia (P). Ofrece un límite a la inversión en el riesgo para mitigar 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ípicamente llamada QA— para ayudar a elaborar el plan de ca-lidad del proyecto, para la verificar el proceso de producción y validar los entregables de cada etapa.

Existe todo un aporte de la gestión de calidad aplicada a proyectos, con una

planificación, control y seguimiento.

El contenido técnico y toda forma de comunicación debe 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 Responsabilidad Social (RS) específicamente aplicada a proyectos.

Es necesario manejar bien el temor de las personas de que este tipo de proyecto las dejará sin empleo.

Establecer un pacto social o una alianza estratégica con los colaboradores es un excelente camino que han aplicado empresas exitosas. Todos cooperan con el cambio necesario y la empresa no despide por motivo de estos proyectos. No es justo ni necesario despedir sólo porque queremos hacer de otra forma las cosas. Se puede evitar generando vinculaciones con otros proyectos en un esquema de vasos comu-nicantes porque en la organización hay infinitos proyectos posibles, una parte libera recursos y la otra requiere recursos, es cuestión de unir una cosa con otra, otra aplicación de visión sistémica.

Se requiere mantener al menos el nivel de servicio previo al inicio del proyecto mientras este dure, tra-bajar con eficiencia, alinear intereses, cuidar el en-torno y la comunidad, organizar el trabajo seguro y el 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 (Valor Actual) social, que refleja el efecto del proyecto en el medio, que debe dar positivo.

JUAN BRAVO 202

17. INSERCIÓN

El problema y la solución deben insertarse en un todo mayor —área, empresa, industria o gobierno— para comprender y alinear los respectivos intereses.

Insertar es observar cómo se relaciona el problema o la solución con otros problemas o soluciones dentro y 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 mejor momento de plantear el cambio.

Se debe monitorear la contribución actualizada de la estrategia del proyecto a

la estrategia de la organización.

Es necesario identificar los impactos del proyecto a todo nivel, especialmente en los clientes, para lo cual es ideal trabajar con criterio SCM (Supply Chain Management). La recomendación es suponer que nos quedamos cortos en estimar impactos para estar preparados para efectos inesperados. Una for-ma de evitarlos al interior de la empresa es comuni-car el proyecto a todas las áreas, incluso donde creemos que no influye, así también mejoramos las estimaciones. Al exterior de la empresa también es conveniente 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 al cliente es central para lograr la conclusión exitosa del 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 en la organización.

Los usuarios internos son “socios” del equipo de proyectos 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 el rediseño. Respuesta correcta: el cliente (sin apellido para no introducir confusión).

El cliente de todos en la empresa es el cliente (aban-donamos aquí el concepto de cliente interno por las distorsiones que introduce).

Todo proyecto debe ser monitoreado en cuanto a su impacto en el cliente, aunque aparentemente sea 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 implica un plan para hacer factible el seguimiento y apreciar cuan importante es el proyecto para el cliente, desde su 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 de encantar a todas las personas de dentro y

fuera de la organización que tienen relación con el proyecto

Es diferente a comunicar y capacitar, aunque se complementa con esas prácticas. Se aplica mediante anticipación, participación, talleres —ver práctica Quick Wins—y otras formas creativas (poleras, lápi-ces, etc.)

Hay experiencias concretas de proyectos fracasados y otros que han aumentado en varias veces su presu-puesto original solamente por el mal manejo de la sensibilización, porque los usuarios no deseaban usar 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, es decir, el equipo de proyecto debe estar sensibilizado primero, para que pueda transmitir la emoción de estar participando en un proyecto tan vital…

En el anexo 7 se presenta el resumen de un proyecto bien implementado en el BancoEstado.


20. CAPACITACIÓN

La capacitación del equipo de proyecto debiera ser continua durante todo el proyecto. Además, es una excelente 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 usuarios y puede tomar variadas formas (la recomendación es una combinación de posibilidades):

• Puede ser realizada por relatores profesionales, por sicólogos preparados en los mensajes del proyecto, por el equipo de proyecto, por usuarios que 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 armonizar las variadas dimensiones del ser humano: espiritual, intelectual, emocional y corporal

JUAN BRAVO 206

21. SEGUIMIENTO

Realizar seguimiento es llevar control del avance del proyecto completo y en cada etapa. Se monitorean variables críticas del proyecto (costos, plazos, hitos, satisfacción de usuarios, calidad, etc.) Desde este punto tiene relación con el diseño de indicadores.

Es necesario que exista algún nivel de control centralizado y que el equipo de

dirección del proyecto tenga la informació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, los indicadores que efectivamente se puedan monitore-ar, por el costo y el tiempo que significan.

Ideal sería un Cuadro de Mando del proyecto donde se 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 sale de rumbo, por ejemplo, si el proyecto ya no es nece-sario para el usuario, se comienza a retrasar o los buenos resultados son mucho mejores a lo esperado.

El seguimiento sirve para corregir desviaciones, para fortalecer un buen resultado e incorporar al método de la empresa una buena nueva práctica.


22. CUIDAR LA SOLUCIÓN ANTERIOR

Cuidar la solución anterior significa que al mismo tiempo que se trabaja en la nueva solución, se aplica alguna forma de continuidad de lo existente. Incluso se sigue realizando mejora continua de la antigua solución.

En algunas experiencias incluso se designa un gerente líder de continuidad, al mismo tiempo que otro gerente líder se encarga del proyecto de cambio.

Es una “estrategia tenaza”, donde un brazo corres-ponde al corto plazo (continuidad de lo existente) y el otro al largo plazo (el nuevo proyecto).

Es recomendable porque ofrece la tranquilidad de la continuidad en caso que el proyecto de cambio tenga alguna dificultad, desafortunadamente, una situación bastante frecuente De hecho, estos proyectos son típicamente de alto riesgo, porque involucran una gran 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 en un ambiente siempre dinámico.

Enlaza este camino con la necesidad de RS de man-tener al menos el nivel de servicio previo al inicio del proyecto mientras este dure, dejando de lado la ingenuidad de desmantelar lo que se tiene porque la felicidad ya viene (la nueva solución).

JUAN BRAVO 208

23. CONTINUIDAD OPERACIONAL

Se refiere a incorporar en el proyecto los elementos que permitan una solución fuerte y robusta en lo que se refiere a la continuidad de las operaciones cuando el proyecto esté en funcionamiento, más allá de sólo tener planes de contingencia

Objetivos del plan de continuidad operacional: • Crear consciencia en el equipo de trabajo y en los

usuarios de las implicancias de una contingencia en la continuidad de los productos y servicios.

• Minimizar interrupciones a las operaciones del negocio y limitar la severidad de la 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 en este 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 por una 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 disponer oportunamente de los elementos que se requerirán en el proyecto: equipos computacionales, redes, li-cencias, escritorios, espacio físico, baños, comedo-res y otros.

Un trabajo bien hecho en materia de recursos físicos tendrá su nivel de influencia en la moral del equipo de trabajo… 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 bienes cuando 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 los recursos como de su administración, ya sea como plan A o B (el principal y el de contingencia).

Cuidar de no dejar de lado los aspectos contables y de formalización de esos recursos, especialmente la distinción entre inversión y gasto entre ellos, por el diferente 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 el proyecto, 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ón excede un 10% al tiempo asignado, si hay un cambio importante en las reglas del juego de una inversión o si 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 cancelados pero continúan porque el equipo de trabajo y ejecu-tivos temen por las represalias. El resultado es una pérdida par la organización varias veces más que el costo del proyecto33.

33 Es como la organización con cultura del terror y de búsqueda de culpables, 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 en las 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 da origen a la solución.

Si se emplea desarrollo en espiral se facilita la incorporación de los cambios porque normalmente se incluyen en la siguiente 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 de trabajo y costos.

Por supuesto, un procedimiento de este tipo depende de 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 que se llegue a un nuevo ciclo de rediseño programado de 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 las personas. 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 todos los 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 en cuanto 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 tiende a dejar las cosas tal como están, es el instinto de conservación del sistema, la homeostasis. Cuando uno 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 cambio de carácter permanente: educación, autonomía y alineamiento de intereses, además de las acciones concretas 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 ellos para el éxito del proyecto.

A veces se malentiende la gestión de proveedores, erróneamente se piensa en tener una función que optimice solamente el interés de la organización y “esquilme” a los proveedores (malos pagos, malas condiciones laborales, etc.) desconociendo que eso se volverá contra la misma empresa.

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 y de los proveedores, mucho más allá de pagos justos y oportunos y buenas condiciones laborales. Se trata de 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 claridad de los objetivos de su trabajo, establecer condiciones igualitarias 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 el marino 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 columna vertebral de la organización, la estructura en medio de

la 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 conjunto Clave 2. Mínimo indispensable Clave 3. Participación de todos los actores Clave 4. Iteración

Por supuesto, adaptar el método que se haya dado la organización a cada

proyecto particular manteniendo un tronco común.

En fin, para evitar costos innecesarios y ganar los beneficios de proyectos bien realizados, es necesario


aplicar la Visión de Proyectos de Negocios, donde es vital alinear el propósito del proyecto con la estrate-gia de la organización, cuantificar todo y orientar el proyecto 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 de causas: árbol de decisión, técnica de los por qué y otras detalladas en el texto. Veremos aquí técnica causa - efecto de Kaoru Ischikawa junto con la de-tección de prioridades de W. Pareto en una versión que 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 de pérdida de la administración del riesgo operacional y en la mejora continua.

La técnica causa – efecto se utilizaba principalmente en el ámbito industrial y las “espinas” hacían refe-rencia a los temas relacionados: materiales, almace-namiento, etc. Aquí las “espinas” son los elementos del modelos de negocios: estrategia, personas, pro-cesos, estructura organizacional y tecnología.

En este caso la aplicamos buscando el problema de fondo 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, entre otras 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 una tormenta de ideas.

Entonces, se detectan causas, se analizan y se priori-zan, indicando en que porcentaje influye cada una sobre el síntoma, riesgo o lo que sea que estemos analizando. La fórmula es Y = F(x).

Se grafican y se lleva un acumulado, cuando se llega al 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 la columna llega o pasa el 80%, hasta ahí llega la lista de causas relevantes.

El nivel de profundidad al cual se llega tiene que ver con la técnica de desarrollo en espiral y con el nivel de 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), esquema central en la técnica Six Sigma.

A propósito de Six Sigma, en su libro Análisis de la causa raíz, los autores Wilson, Dell y Anderson di-cen (1999, p. 6): “En Estados Unidos el 0.1% de fallas significa: 16.000 piezas de correo perdidas por hora, 20.000 prescripciones de medicamentos 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, su corazó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 se está 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 a objetos, los doctores Grady Booch, Jim Rumbaugh e Ivar 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 en la industria con la tecnología de objetos.

UML incluye una amplia variedad de diagramas, entre los que se encuentran:

• Modelo Conceptual, para identificar conceptos del mundo real y las asociaciones entre ellos.

• Casos de uso, para mostrar las interacciones con el usuario.

• Diagramas de estado para ilustrar el 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, es aplicable en todas las etapas del desarrollo.

En UML se usa el término artefactos para referirse a diversas agrupaciones de modelos, a modelos indi-viduales o a cualquier elemento que sea identificado individualmente. Cuando en el contexto de UML se usa la palabra sistema, es porque normalmente hace referencia al sistema computacional.

Casos de uso

Los casos de uso (use case) permiten mostrar las interacciones con el usuario. Tal como plantea Ivar Jacobson: “es una 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 punto de interacción con el computador”, principalmente detectados desde las actividades del flujograma de informació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 normal de 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 curso normal 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 requerimientos computacionales del sistema de información. Los casos 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 cliente en el terminal de una tienda minorista (dominio).

Incorpora el concepto de actor. Un actor es alguien o algo fuera del sistema que interactúa con el sistema, en este caso el vendedor.

Ejemplo de caso de uso de alto nivelEjemplo de caso de uso de alto nivel

Consultar situación del cliente

Saldo de crédito y posibilidades de cuotas.

Apoyo en realización de cálculos respecto a financiamiento

Terminal en la tienda

Vendedor

Ejemplo de caso de uso de alto nivelEjemplo de caso de uso de alto nivel

Consultar situación del cliente

Saldo de crédito y posibilidades de cuotas.

Apoyo en realización de cálculos respecto a financiamiento

Terminal en la tienda

Vendedor

JUAN BRAVO 224

ANEXO 3. RUP

Cabe agregar que los autores señalados en el anexo 2 son también creadores de Rational Software Cor-poration (adquirida por IBM en el año 2003), desde donde han propuesto el RUP (Rational Unified Pro-cess), un método completo para el desarrollo de software que rápidamente está siendo incorporado en la industria informática.

Aunque RUP está dirigido al campo de la tecnología de información, tiene muchos puntos de encuentro con la gestión de procesos, de ahí la idea de incorpo-rar algunas líneas. Por ejemplo, está basado en las seis 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 resuelven primero los casos de uso (o requerimientos) más importantes, aquellos donde el riesgo es mayor.

2. Manejo de los requerimientos. Se seleccionan, organizan y documentan los requerimientos, se establece una prioridad en base a riesgos. Se apli-ca la técnica de casos de uso, donde se establece lo 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 de construcción, esta etapa es la de arquitectura. Aquí se establece la arquitectura de la solución de software, 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 aplican aquí los modelos que provee el Unified Modeling Language (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ón tradicional de software, se propone incluir indica-dores de calidad y verificaciones en cada punto del proceso de desarrollo. Se incorpora una labor de Testing en el ciclo de vida, en cada vuelta de la espiral.

7. Control de cambios. En un ambiente de creciente complejidad: múltiples desarrolladores, equipos de trabajo, instalaciones, versiones del software, proyectos y plataformas, se requiere un control explí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 en www.omg.org, www.rational.com, www.uml.com y otros sitios relacionados.

JUAN BRAVO 226

ANEXO 4. NORMAS DE CALIDAD DEL

SOFTWARE

La idea es revisar algunas normas de calidad desde las cuales aprender buenas prácticas, además, un trabajo 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ñías de éxito en la India34 se han adherido a una o más de estas normas). Un aspecto común a todas ellas es el costo, del aprendizaje, de la certificación y de la in-fraestructura para cumplir la norma. También es comú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 como CMM en la India, donde hasta 1998 se habían certificado 89 de las 250 compañías “top” en la producción de software , otras 136 estaban en 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 es según normas reconocidas internacionalmente, tal como: CMM del SEI, 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 de software. Tiene niveles cada vez más exigentes que la organización candidata debe ir certificando.

CMM provee un detalle exhaustivo de cada nivel de madurez 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 de software, 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 esfuerzos heroicos. Existe inmadurez en el desarrollo. No existe visibilidad acerca del proceso de desarrollo ni de los resultados del producto de software (tiempos, costos, errores, etc.).

2. Nivel Repetible (Repeatable): en este nivel el proceso se puede repetir, existen técnicas y nor-mas comunes, hay seguimiento de costos, plazos y funcionalidad en los procesos.

3. Nivel Definido (Defined): el proceso de desarro-llo de software está documentado, estandarizado e integrado.

JUAN BRAVO 228

4. Nivel Gestionado (Managed): los procesos están bajo un nivel de control donde la predicción de plazos y costos es posible.

5. Nivel de optimización (Optimizing): se incorpora el mejoramiento continuo de los procesos logrado por retroalimentación y por ideas y tecnologías innovadoras.

CMM surgió en 1993 de una iniciativa del Software Engineering Institute (SEI35), con toda una historia anterior que incluyó estudiar una amplia cantidad de compañías de éxito en el desarrollo de software.

ISO 9000

ISO corresponde a la Organización Internacional de Estandarización. La serie de normas ISO 9000 son bastante conocidas. Destaca que el sector informáti-co fue de los más reacios en adherirse a ellas.

35 El Software Engineering Institute (SEI) es un Centro de inves-tigación y desarrollo —financiado con fondos federales— patro-cinado por el Departamento de Defensa de Estados Unidos, por intermedio de la Oficina del Subsecretario de Defensa para la Adquisición, Tecnología y Logística. El contrato del SEI para la investigación aplicada en el tema de la metodología de software, fue adjudicado por licitación pública a la Universidad Carnegie Mellon en Diciembre de 1984. La misión del SEI es: Promover y avanzar en la práctica de la Ingeniería de Software, porque el software de calidad, producido conforme a plazos y dentro de un presupuesto, es un componente crítico para los sistemas de defensa de Estados Unidos. Cumple esta misión promoviendo la evolución de la Ingeniería de Software desde ser una actividad “ad-hoc” de alto contenido de trabajo de personas hacia ser una disciplina bien gestionada y apoyada por tecnología.


Un punto de encuentro se está produciendo con la masiva incorporación de la gestión de procesos al desarrollo de software. Esta es una ventaja de la aplicación de las normas, su amplitud.

Actualmente se considera tan importante la gestión de procesos que incluso fue considerada en la nueva redacció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, lo cual también es pilar de este trabajo y de la gestión de 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 dentro de 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 del desarrollo y de implementar en la forma de un pro-ceso evolutivo. El encargado de realizar los estudios y patrocinar la nueva norma fue el Departamento de Industria y Comercio (DTI: Departament of Trade and Industry). Actualmente el encargado de Tick IT es el DISC, oficina dependiente del British 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 requerimientos estén bien especificados y que la organización tiene la capacidad para cumplirlos.

2. Análisis y especificación de los requerimientos del sistema asegurando que sean revisados y acordados con el cliente.

3. Planeación, control y monitoreo del avance del desarrollo respecto al plan comunicando a todas las partes afectadas y que avise oportunamente de 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 alinearla en 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 avanza en calidad, eficacia y eficiencia.

Este método está dirigido a proyectos de cambio mayor. Simplificando, también se puede aplicar a proyectos de cambio un poco menor, como en el benchmarking o la mejora, aunque resultaría un po-co forzado.

Dice Steve McConnell (1996, p. 153): “El modelo de espiral es un modelo de ciclo de vida orientado a riesgos que divide un proyecto en miniproyectos… Se parte de una escala pequeña en medio de la espi-ral, se localizan los riesgos, se genera un plan para manejarlos y a continuación, se establece una aproximación a la siguiente iteración… Se avanza un nivel en el “rollo de canela”, se comprueba que se 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 de desarrollo para el grupo de requerimientos seleccio-nados. En cada iteración la complejidad se incre-menta progresivamente y se reduce el riesgo. Por supuesto, 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% al 20% de los requerimientos.

Esta es la nueva propuesta para los proyectos menos estructurados. La forma tradicional es la técnica llamada “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 el caso de proyectos medianos.

En el desarrollo en espiral cada vuelta o ciclo es un pequeño “desarrollo en cascada”, porque pasa por todas 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 procesos en espiral. Cada vuel-ta de la espiral es un ciclo completo de trabajo para un grupo de requerimientos seleccionados.


ANEXO 6. GESTIÓN DE CALIDAD EN

PROYECTOS

Es un tema fundamental abordado por todos los métodos existentes, por ejemplo, en el PMBOK del PMI36 (Project Management Institute) dicen:

La GCP (Gestión de Calidad en Proyectos) incluye los procesos requeridos para asegurar que el pro-yecto satisfará las necesidades por las cuales fue iniciado, 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 todas las 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 Iso 9000:2000 “Calidad es la totalidad de las caracterís-ticas de una entidad que le confieren la aptitud para satisfacer las necesidades implícitas y establecidas”.

Ver también anexo 9.


ANEXO 7. CASO BANCOESTADO

Detallado en el libro Gestión de Procesos

Se seleccionó el proyecto Centralización de Proce-sos de Sucursales porque los resultados obtenidos son impresionantes:

• Fueron liberadas 1.100 personas destinadas al Back-Office, lo cual significa una importante cifra de ahorro en remuneraciones.

• La 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 mejoras que eventualmente significaban eliminar su pro-pia función.

• Se realizó un pacto social con los trabajadores para evitar el temor al despido.

• Se contó con la colaboración del sindicato de la empresa.

JUAN BRAVO 236

Para la gestión del cambio se designó a un gerente líder del proyecto de amplia ascendencia dentro de los trabajadores del Banco, quien, junto con el Sub-gerente de Ingeniería de Procesos, la encargada de comunicación y el suscrito, realizó talleres de brainstorming con funcionarios en diferentes ciuda-des de Chile buscando no sólo el apoyo sino también las ideas de los involucrados para el mejoramiento de la propuesta.

Consta al autor que en un solo evento (agosto de 2001), se generaron alrededor de 100 iniciativas, algunas de las cuales fueron Quick Wins, se vieron resultados a corto plazo y se ganó en motivación tanto de los operadores del proceso como de la di-rección.

La gran diferencia de este proyecto exitoso con otros que no lo fueron fue la aplicación sistemática de método.

También el caso es considerado un ejemplo de coor-dinación, porque para lograr el crecimiento comer-cial se optó por privilegiar la contratación interna o reconversión.


ANEXO 8. ITIL

ITIL (Information Technology Infrastructure Libra-ry) se traduce como “Biblioteca de Infraestructura de Tecnologías de Información”. Una traducción no literal es Cumplimiento de niveles de servicios en TI con base en una serie de libros (unos 60 a fines de los ochenta) con las mejores prácticas.

Todo surge de los bajos estándares de servicios TI en 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ás del 80% del total). Por lo tanto, se encargó al CCTA (Central Comunications and Telecom Agency) una propuesta. La respuesta fue ITIL, la cual poco a po-co ha ido ganando terreno como referente en el campo 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 de madurez 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 como la de administrar una base de datos de ítemes de configuració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 las mejores prácticas para la realización de proyectos y las 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 transversales del método GSP, se definen nueve áreas de conoci-miento: Integración, Alcance, Costo, Tiempo, Cali-dad, Recursos Humanos, Comunicaciones, Riesgo y Abastecimientos.

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 caso de negocios porque el beneficio debe ser positivo, para lo cual se calcula el VAN interno y social.

Sea cual sea el ámbito de la empresa, con o sin fines de lucro, es evidente que los proyectos se proponen porque tienen más beneficios que costos. En el caso de negocios se explicitan esos costos y beneficios.

El caso de negocios se realiza en la etapa de factibilidad del método GSP y es llamado Plan de Proyecto cuando está apro-bado.

Incluye, por trazabilidad, todo lo realizado a la fecha en la etapa de concepción y en la misma factibilidad, tal como el estudio de alternativas desechadas.

Parte I. Necesidad y solución

A. 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 otros antecedentes 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 necesidad insatisfecha

Costos Externos: del problema o de oportunidad por la necesidad insatisfecha, considera la cadena logística. Se refiere a costos de los grupos 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 observaciones del Comité de Estudios)

Descripción general: puede adjuntar antecedentes de la solución propuesta: 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 exploradas 2) Lista de las alternativas que fueron formalmente estudiadas y

por qué fueron desechadas. Adjunte el estudio de cada alternati-va estudiada

Restricciones de la solución

D. Detalle de cómo se ven afectadas otras áreas, procesos, sistemas computacionales y otros efectos (internos y externos)

Áreas

Procesos

Sistemas

JUAN BRAVO 242

Otros efectos

E. Detalle de costos de la alternativa

Por 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 (la integración a la cadena logística, la integralidad, el funcionamiento de procesos solamente en la Web, etc...)


Luego, cómo este concepto afecta a los medios principales para el cambio: 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 Transversales

Estas prácticas debieran surgir de políticas de la organización y 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án a la Gantt.

1. Dirección del proyecto 2. Plan de la etapa 3. Exposición de los planes 4. Retroalimentación 5. El equipo de trabajo 6. Entrevistas 7. Comunicación 8. Informes 9. Técnicas, tipo UML, MP, FI 10. Herramientas de apoyo: 11. Trazabilidad 12. Quick Wins 13. Costos y duración 14. Gestión de Riesgos: Internas y Externas 15. Gestión de Calidad 16. Responsabilidad Social 17. Inserción 18. Orientación al cliente 19. Sensibilización

JUAN BRAVO 244

20. Capacitación 21. Seguimiento 22. Cuidar la solución anterior 23. Continuidad Operacional 24. Plan de recursos físicos del proyecto 25. Kill Time 26. Control de cambios 27. Gestión del cambio 28. 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 de cumplimiento

Ciclo Nº 1 Según Informe Adjunto

Ciclo Nº 2 Según Informe Adjunto

Ciclo Nº … Según Informe Adjunto

Ejecución presupuestaria (M$)

Períodos Ppto. Gasto

Gasto Real

% Ppto. Inversión

Efectiva %

Ciclo Nº 1

Ciclo Nº 2

Ciclo Nº .

Total Proyecto

…

Nota: el ciclo aplica cuando el proyecto se ha dividido en perí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, holgura y ruta crítica.

Análisis Diseño Implementación Despliegue 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ía Aná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 en detalle.

JUAN BRAVO 246

• Pueden presentar este formulario los integrantes de la organizació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 mayor con diferentes partes, todas deberían ser coordinadas por 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, una visió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 Universidad Cató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 proceso

unificado 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ó el

queso, 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 sostenimiento

de 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, Santiago de 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 en su empresa?”, Diario Financiero, 18 de noviembre, Santiago de Chile.

VARELA, F. (1990): Conocer; las ciencias cognitivas: tendencias y perspectivas, Barcelona, Editorial Gedisa.

YOURDON, E. y Coad, P. (1991): Object-oriented Analysis. USA, Yourdon Press, Prentice Hall Inc.


LIBROS DEL AUTOR PUBLICADOS POR EDITORIAL 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 y mejora de procesos en la organización, como un medio para lograr la eficiencia y agregar valor para el cliente en una relación de con-fianza. Surge de una profunda inquietud por el despilfarro de recursos en nuestra 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 en las organizaciones. Sin embargo, es poco lo que logra realizarse por-que no se sabe cómo hacerlo, provocando grandes pérdidas en las mismas organizaciones y en la sociedad por proyectos mal planteados o fuera de costo y plazo, trámites que demoran más de la cuenta, mala atenció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 modelo integral para la gestión de procesos. Este libro complementa, aporta técnicas y muestra aplicaciones de los conceptos desarrollados en el libro Gestión de Procesos, el cual es prerrequisito 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ás difícil es cambiar nosotros mismos o que cambie nuestra organización, o la forma cómo hacemos las cosas, a las cuales podríamos llamar… procesos. La gestión de procesos nos insta a detenernos, reflexionar acerca de lo que hacemos y preguntarnos: ¿por qué?, ¿para qué?, ¿cómo?. Porque, si profesionales capaces tienen ideas brillantes que permitirán ganar o ahorrar mucho dinero, al mismo tiempo deberían inventar los nuevos empleos de las personas que serán liberadas de funciones obsoletas. Lo pueden hacer, porque son capaces. Lo deben hacer, por su condición de seres humanos. La gestión de procesos es un medio para lograr grandes metas organizacionales, como la calidad, competitividad, productividad, comunicación y rentabilidad.


GESTIÓN DE PROYECTOS


El objetivo de este libro es ofrecer un método para la gestación, evaluación, planificación, dirección y buena ejecución de los proyectos, principalmente de procesos y tecnología. Es importante hacer bien los proyectos, porque a través de ellos se materializa el cambio pro-puesto por la estrategia de la organización o por las oportunidades que el medio ofrece. El método tiene como base un amplio estudio de

las mejores prácticas de la gestión de los proyectos y del cambio en las personas. Las empresas públicas y privadas de Chile pierden anualmente 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 la pagamos todos y con creces, porque tampoco disfrutamos de los beneficios 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 17 cm.)

El objetivo de este libro es cooperar en aumentar la productividad del desarrollo y la calidad de la solución de software mediante la excelencia de su modela-ción. Comenzamos por asegurarnos que la serie de modelos (correspondientes a las etapas de análisis y diseño) efecti-vamente dan solución a una necesidad bien comprendida y evaluada.

Modelar soluciones de software es una labor bella y creativa que origina verdaderas “obras de arte”. Sin perder la belleza y creatividad, ¿será posible profesionalizar su elaboración? ¡Sí! Definitivamente el diseño de sistemas puede ser arte 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 personas que quieren comunicarse mejor con quienes les rodean para incrementar la calidad de su vida. El espíritu de este libro es que nos sirva de guía práctica en esta tarea de toda la vida destinada a relacionarnos mejor y a transformarnos. ¿Por qué? Porque la comu-nicación es cambio que podemos guiar hacia 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 único que realmente cuenta, además la mejora en las comunicaciones en las empresas tiene un efecto inmediato en la vida familiar y social de sus trabajadores.

RESPONSABILIDAD SOCIAL (RS)

Precio versión en papel: US$ 24, Chile $16.000 (2007, 380 Págs., 24,5 x 17,3 cm.)

En los países de Latinoamérica podemos ganar miles de millones de dólares al año con 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 la riqueza de las Naciones. Se puede lograr,

tenemos ejemplos de buenos diseños que han disminuido grandes males sociales en un 80%. Es el caso, en Chile, de la disminución de la tasa de accidentabilidad de los trabajadores desde el 35% de los añ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 gran logro para toda organización y mucho más para una que se dedica a la seguridad social por el gran impacto que tiene en la comunidad. La historia del IST es a la vez parte de la historia de la seguridad del trabajo en

Chile, cuyos avances se pueden resumir en una sola palabra que bien conocen en el Instituto: prevención.

Es un avance de Responsabilidad Social que se puede proyectar a otros ámbitos para contribuir al Bien Común. Ya sabemos que una historia puede inspirar a las personas para lograr fines superiores, al menos para encontrarle sentido a su quehacer y motivarse. También permite aprender, porque de la lectura se podrá extraer una buena manera de gestionar una empresa, comenzando por una gran dosis de visión.

EMPRESAS DE ÉXITO

Precio versión en papel: US$ 15, Chile $10.000 (2005, 150 Págs., 21 x 14 cm.) Este es un libro acerca de las empresas de éxito, aquellas con una gestión que las lleva a diferenciarse. En un contexto de buenas prácticas de gestión la tesis es que las empre-sas exitosas se distinguen por algunas pocas prácticas excepcionales. Así como existe la gestión por competencias dirigida a las personas, también existe una gestión por competencias corporativa.

Además de hacer las cosas bien, las empresas exitosas se distinguen por un pequeño número de prácticas que hacen muy bien, les hemos llamado “sistema de diferenciación”. Se presentan los ejemplos de IST, 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 la gestión de las empresas, así aprendemos de experiencias concretas. La idea fue desafiante: compartir y aprender de la gestión realizada en una unidad de nego-cios de una importante organización. Se trata de la Fundición y Refinería Venta-nas de la Empresa Nacional de Minería, ENAMI. Tiene una cultura distintiva que se aprecia en la ingeniería o innovación permanente, en su contribución al bienes-

tar del país, en el sentido de honor, en la pasión por aprender, entre otras. 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 tan grande entre la excelencia de las contribucio-nes de un hombre y el pobre sitial que le hemos asignado en la historia. A Frederick W. 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 a travé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 y se 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 por el dinámico y querido periodista Atilio Mac-chiavello.

Este documento recrea la vida de muchos visionarios y podría ser la salida de su propio túnel. Es un Texto obligado para profesores, estudiantes, profesionales y público en general. Una inspiración para pequeños y grandes empresarios y orientación vivencial para nuestras autoridades.

AMBROSOLI, DESDE LOS ALPES A LOS ANDES


Coautor: Giancarlo Gandolini Ambrosoli.

Este libro es un reconocimiento a la labor de don Constantino Ambrosoli y a todos los emprendedores que ayudan a crear un mun-do más humano. Es un ejemplo inspirador que queremos compartir, porque excedió en mucho nuestras expectativas. ¿Para qué sirve una historia? Para conocer, entender y difundir la cultura de una organi-zación, establecer un vínculo entre sus inte-

grantes, comunicar una causa común, preservar las tradiciones y seguir adelante unidos. Es un gran desarrollo, inseparablemente unido a la historia de la familia Ambrosoli, así que para entender la evolució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 aprender de ellos para ayudar en el desarrollo de las organizaciones. La vieja cosmovisión me-canicista, que considera el mundo estable y predecible, abre paso a los sistemas: donde prevalecen las interacciones, lo evolutivo, el caos, la complejidad y sus compensadores, la humanidad, educación, comunicación, libertad, creatividad y otras respuestas. Si

pretendemos ignorarla, dar órdenes o sólo poner reglas, la comple-jidad 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, los cí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ón suponiendo que las condiciones ambientales se mantendrían más o menos constantes. ¡Hoy nos damos cuenta que el entorno varía con mucha rapidez! y que la velocidad del cambio sigue y sigue aumentando. Para adaptarnos a esta reali-dad, la planificación sistémica recurre a herra-mientas tales como: participación, creatividad y manejo de la incertidumbre del medio. La pla-

nificación sistémica nos ayuda a cumplir los sueños, siguiendo un camino que comienza por determinar qué es lo que queremos, en nuestra 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ón 2007, 272 Págs., 26,5 x 18,5 cm.) (1ª edición de 1996) Sólo colección.

Este libro trata sobre el desarrollo de sistemas computacionales, tales como inventarios, con-tabilidad, remuneraciones o facturación. Se busca aumentar la productividad en ese ámbito. En especial se estudia el diseño de

sistemas computacionales, una labor bella y eminentemente creativa que origina verdaderas “obras de arte”, a veces artesanales. Siempre conservando la creatividad, ¿Será posible que los métodos de traba-jos y las herramientas sean de uso general? ¡Sí! Definitivamente el diseño de sistemas dejó de ser arte para transformarse en tecnología. Esta propuesta de la ingeniería de software tiene su base en tres só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


La finalidad de la reingeniería es lograr grandes desafí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 grandes cambios en los procesos del negocio, potenciar a las personas, definir una estructura organiza-cional flexible e incorporar tecnología. Todo en sintoní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 x 18,2 cm.). Sólo colección. Da una visión de conjunto sobre el desarrollo de sistemas de información, comenzando por la planificación estratégica del negocio. En el texto se incorporan los conceptos de evaluación de proyectos informáticos, los len-

guajes de cuarta generación y la orientación a objetos. Especial relevancia tienen la Ingeniería de Software y las herramientas de apoyo 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 de sistemas también deben cambiar. Se trata de lograr el desarrollo de software 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 x 18,5 cm.) (1ª edición de 1987)

El objetivo de este libro es servir de guía práctica en el desarrollo y en la mantención de sistemas de información orientados a empresas. Está especialmente dirigido a todos quienes laboran en el área de informá-tica, y que podrían hacer uso de las materias prá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 e informática, quienes podrán ver facilitado su aprendizaje al enfren-tarse con metodologías y ejemplos concretos, sobre la base de una visió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 Responsabilidad Social.

Con más de 30 años de experiencia como ejecutivo, consultor y relator de seminarios, el Dr. Bravo ha ayudado a clientes tales como: Mutual de Seguridad, ENAMI, BancoEstado, Rolec, Transbank, Isapre Colmena, Municipalidad de Quillota, Banco Itaú, Empresa Portuaria de Valparaíso, Constructora TECSA y Termosistema.

El Dr. Bravo es profesor de programas de postgrado en la Pontificia Universidad Católica, Universidad Té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 hacer actual de consultoría:

1. Gestión Avanzada de Procesos 2. Gestión de Procesos 3. Gestión de Proyectos 4. Modelando una Solución de Software 5. El Encanto de la Comunicación 6. Responsabilidad Social

Los 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 su permanencia. En este caso aplica el rediseño, en la forma de nuevos textos que heredan contenidos reci-clados posibles de rescatar de los antiguos. Por ejemplo, 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:

1. Reingeniería de Negocios(1995) 2. Diseño de sistemas computacionales (1996) 3. Planificación Sistémica (1997) 4. Análisis de Sistemas (1998) 5. A la Salida del Túnel (2000) 6. Taylor Revisitado (2005) 7. Empresas de Éxito (2005)

Libros sólo en papel sin actualización

Estos cinco libros están disponibles sólo en papel desde las fechas que se indican:

1. Desarrollo de sistemas de información, (1996, tercera edición, primera versión de 1987)

2. Modelamiento de sistemas de información (1994) 3. Ambrosoli, desde Los Alpes a Los Andes (1998) 4. Gestión, el caso Enami Ventanas (2005) 5. Instituto de Seguridad del Trabajo, historia

(2007)

Información general

Cada texto puede ser adquirido en la forma de una versión corporativa en papel o digital.

Editorial Evolución S.A.: Av. Libertador Bernardo O’Higgins Nº171, of 307, Santiago, fono: 6389717 www.evolucion.cl, [email protected].

Libro Gestion de Proyectos de Procesos y Tecnologias - 2006 - Juan Bravo

Documents

Transcript of Libro Gestion de Proyectos de Procesos y Tecnologias - 2006 - Juan Bravo