UNIVERSIDAD DE CHILE FACULTAD DE ECONOMÍA Y NEGOCIOS DEPARTAMENTO CONTROL DE GESTIÓN Y SISTEMAS DE INFORMACIÓN DIPLOMADO EN GESTIÓN Y EVALUACIÓN DE PROYECTOS INFORMÁTICOS
PLANIFICACIÓN, DESARROLLO Y CONTROL DE PROYECTOS Apuntes de Curso Autor: Peter Roberts V. Versión 4.8 Diciembre 2017
Planificación, Desarrollo y Control de Proyectos
Página 1 de 86
Temario y duración: Considerando que un módulo tiene una duración de 1 hora y 20 minutos, es decir, cada sesión de 18:30 a 21:30 horas es de dos módulos. Gestión de los Recursos TICAR (un módulo) Gestión de la Planificación Estratégica en TICAR (un módulo) Gestión de los Recursos Financieros (un módulo) Gestión de los Recursos Humanos (dos módulos) Gestión de Contratos en TICAR (un módulo) Gestión de la Innovación en TICAR (un módulo) Gestión de la Seguridad (un módulo) Gestión de la Calidad (un módulo) Gestión de la Ética (un módulo) Gestión Comunicacional (un módulo) Gestión de Métricas de Control (un módulo) Evaluación (dos módulos) En total son 14 módulos que equivalen a siete sesiones.
“Al no prepararse, se está preparando para fracasar”. Benjamín Franklin
Planificación, Desarrollo y Control de Proyectos
Página 2 de 86
TABLA DE CONTENIDOS 1.- GESTIÓN DE LOS RECURSOS EN PROYECTOS DE TICAR ...................................................... 5 1.1.- ORGANIZACIÓN DEL PROYECTO .......................................................................................................... 5 1.2.- METODOLOGÍAS .................................................................................................................................. 9 1.3.- CICLO DE VIDA DEL PROYECTO .........................................................................................................10 1.4.- FASES Y APROBACIONES ....................................................................................................................11 1.5.- HITOS Y ENTREGABLES ......................................................................................................................11 1.6.- ROLES DENTRO DEL PROYECTO ..........................................................................................................11 1.7.- PROYECTOS INTERNACIONALES .........................................................................................................12 1.8.- PREGUNTAS DE REPASO .....................................................................................................................13 2.- GESTIÓN DE LA PLANIFICACIÓN ESTRATÉGICA EN TICAR ...............................................14 2.1.- DESARROLLO .....................................................................................................................................14 2.2.- IMPLEMENTACIÓN ..............................................................................................................................15 2.3.- CAPACITY PLANNING .........................................................................................................................16 2.4.- PREGUNTAS DE REPASO .....................................................................................................................16 3.- GESTIÓN DE LOS RECURSOS FINANCIEROS EN PROYECTOS TICAR ...............................17 3.1.- DISPONIBILIDAD .................................................................................................................................18 3.2.- PREGUNTAS DE REPASO .....................................................................................................................19 4.- GESTIÓN DE LOS RECURSOS HUMANOS EN PROYECTOS TICAR ......................................20 4.1.- ESTIMACIÓN DE TIEMPO Y ESFUERZOS ...............................................................................................21 4.2.- FORMACIÓN DE EQUIPOS DE TRABAJO Y RESOLUCIONES DE CONFLICTOS ...........................................22 4.3.- TELETRABAJO ....................................................................................................................................26 4.4.- PREGUNTAS DE REPASO .....................................................................................................................26 5.- GESTIÓN DE CONTRATOS EN PROYECTOS TICAR .................................................................27 5.1.- CRITERIOS DE EVALUACIÓN Y SELECCIÓN DE LOS PROVEEDORES DE SOLUCIONES TECNOLÓGICAS ....27 5.2.- PROPUESTAS DE LICITACIÓN ..............................................................................................................28 5.3.- EVALUACIÓN Y SELECCIÓN DE SOLUCIONES.......................................................................................29 5.4.- TÉCNICAS DE NEGOCIACIÓN ...............................................................................................................30 5.5.- PREGUNTAS DE REPASO .....................................................................................................................33 6.- GESTIÓN DE LA INNOVACIÓN EN TICAR ...................................................................................34 6.1.- CÍRCULO VIRTUOSO ...........................................................................................................................34 6.2.- AGENTES Y ACTORES .........................................................................................................................37 6.3.- TIPOS DE INNOVACIÓN .......................................................................................................................38 6.4.- VIGILANCIA TECNOLÓGICA O FARO TECNOLÓGICO ...........................................................................39 6.5.- PREGUNTAS DE REPASO .....................................................................................................................39 7.- GESTIÓN DE LA SEGURIDAD EN TICAR .....................................................................................40 7.1.- EVALUACIÓN Y GESTIÓN DE LOS RIESGOS E INCERTIDUMBRES ...........................................................40 7.2.- FACTORES DE RIESGO, CAUSAS DE POSIBLE FRACASO, INCORPORACIÓN DE SEGURIDAD ....................43 7.3.- SEGURIDAD FÍSICA DE TIPO PREVENTIVO ...........................................................................................47 7.4.- SEGURIDAD LÓGICA DE TIPO PREVENTIVO .........................................................................................50 7.5.- PLAN DE CONTINGENCIA (DRP, DISASTER RECOVERY PLANNING, DATA RECOVERY PLANNING) .....56 7.6.- PREGUNTAS DE REPASO .....................................................................................................................58 8.- GESTIÓN DE LA CALIDAD EN TICAR ...........................................................................................59 8.1.- ANÁLISIS IMPACTO AL MEDIO AMBIENTE O GREEN IT ......................................................................60
Planificación, Desarrollo y Control de Proyectos
Página 3 de 86
8.2.- PMO ..................................................................................................................................................61 8.3.- DEFINICIÓN DE INFORMES (DOCUMENTACIÓN) ...................................................................................62 8.4.- NIVEL DE CRITICIDAD DEL PRODUCTO ................................................................................................63 8.5.- IMPORTANCIA V/S URGENCIA .............................................................................................................65 8.6.- PREGUNTAS DE REPASO .....................................................................................................................66 9.- GESTIÓN DE LA ÉTICA EN TICAR.................................................................................................67 9.1.- PREGUNTAS DE REPASO .....................................................................................................................71 10.- GESTIÓN COMUNICACIONAL ......................................................................................................72 10.1.- GESTIÓN DE REUNIONES ...................................................................................................................72 10.2.- PREGUNTAS DE REPASO ...................................................................................................................74 11.-GESTIÓN DE MÉTRICAS DE CONTROL O INDICADORES .....................................................75 11.1.- EVALUACIÓN DE LA RUTA CRÍTICA...................................................................................................76 11.2.- MECANISMOS DE AVISO: ÍNDICES DE CONTROL, CHECK LIST............................................................76 11.3.- ANÁLISIS Y SOLUCIÓN DE DESVIACIONES .........................................................................................83 11.4.- CIERRE Y ABANDONO DEL PROYECTO (NORMAL Y ANORMAL) .........................................................84 11.5.- PREGUNTAS DE REPASO ...................................................................................................................85 REFERENCIAS ..........................................................................................................................................86
Planificación, Desarrollo y Control de Proyectos
Página 4 de 86
1.- Gestión de los Recursos en proyectos de TICAR “Hacer lo mismo una y otra vez y esperar resultados distintos es una locura”. (Einstein)
1.1.- Organización del Proyecto La gestión de Proyectos de TICAR, a veces exige ser como un camaleón: Cuando la empresa/organización está bien, para defender/justificar los proyectos usar argumentos como: para aumentar el negocio, más presencia, etc. Cuando la empresa/organización está mal, para defender/justificar los proyectos usar argumentos como: para bajar los costos, ser más rentables, etc. Recordar que la planificación, normalmente efectuada o plasmada en una carta Gantt, que supone: condiciones ideales, casi utópicas, pero es necesaria. En cambio el desarrollo del proyecto es: en la realidad y requiere gestión en ambiente de caos y además debe responder a una planificación idílica. La gestión de proyectos de TICAR, requiere: Estrategia (ver opciones) Análisis de contexto y/o de entorno Evaluar condiciones Procedimiento(s) La idea es sorprender y no ser sorprendidos. Adicionalmente la práctica tradicional de la planificación suele conducir a que el plan sea desarrollado sin estar en cabal conocimiento de lo que realmente puede ser hecho. Inicio del proyecto, y cuándo ocurre, depende de a quien se le pregunte y cuándo, es un cuándo en el tiempo, muy importante pues compromete plazos. Entre otras formas, se le denomina Kick-off, partida, definidos SOW (Statements of work), TDR (Términos de referencia), etc. Fin del proyecto, y cuándo ocurre, depende de a quien se le pregunte, hay fin normal y fin anormal, normalmente hay acuerdos en la fecha, pero no en qué significa terminado, importa inicialmente el qué significa terminar y después de ello, precisar el cuándo. Variables a administrar, plazo, alcance, costo y calidad. Basta tener el control de una de ellas para dominar las condiciones del proyecto. Un proyecto consta de actividades, objetivos, RRHH, RRTT, RRFF, planificación, rentabilidad, beneficios, tiene un plazo y costo, genera un producto Planificación, Desarrollo y Control de Proyectos
Página 5 de 86
y está inmerso en la restricción de recursos que obliga a priorizar, está sujeto a normas, políticas, seguridad, medio ambiente y ética. Existe una serie de herramientas de software (algunas de muy bajo costo o gratis) de apoyo a la gestión de un proyecto, se sugiere usarlas, son un muy buen apoyo. Es necesario entender que nunca se debe superponer el objetivo personal del líder del proyecto al objetivo del proyecto en sí. Todos los conceptos analizados, deben ser adecuados al tamaño (volumen) y envergadura (complejidad) del proyecto a desarrollar. Se parte de la base de que ya existe Estudio de Factibilidad y éste indicó que la solución es efectuar un proyecto que resuelva el problema detectado. Dicho estudio de factibilidad debe considerar: factibilidad técnica, operativa, legal, medio ambiental y económica. El proyecto que resuelve dicho problema puede ser tecnológico o no; no siempre la solución a un problema es tecnológica, puede que un simple cambio o adecuación administrativa resuelva el problema. Lo más importante es tener claro y muy bien definido cuál es el problema a resolver, pues esto definirá los pasos a seguir y los recursos necesarios. Este será el objetivo inicial, el de partida, no obstante los objetivos pueden cambiar durante el proyecto, pero es necesario conocer un objetivo a priori, en último caso, para saber si cambió en el transcurso del proyecto. Adicionalmente es conveniente distinguir si el proyecto es de solución a problemas detectados o es de innovación. En particular es necesario distinguir si el proyecto involucra personas fuera del ámbito informático, pues puede ocurrir que el proyecto a desarrollar sea de índole netamente informático, es decir, que los desarrolladores y los usuarios sean informáticos o que sean las mismas personas. Tener cuidado con la “Shadow IT”, que ocurre cuando las áreas de negocios, proceden por su cuenta y se equipan de soluciones de TICAR en forma autónoma y después piden apoyo al área de TICAR para: Implementar dicha aplicación en la plataforma de TICAR organizacional, algo que no siempre es requerido, pues a veces la aplicación se instala en equipos personales y no en servidores o equipos centrales. Resolver problemas con la aplicación ya implementada Conectar dicha aplicación con otras aplicaciones organizacionales. Otros aspectos a considerar son: La opción de subdividir el proyecto en sub-proyectos, para lograr un mejor control, estos sub-proyectos pueden ser simultáneos y/o secuenciales, en Planificación, Desarrollo y Control de Proyectos
Página 6 de 86
este caso las observaciones indicadas se aplican a cada sub-proyecto y al proyecto en sí al consolidar información. En algunos casos se puede recurrir, por ejemplo, a un mini proyecto inicial de contingencia o de contención, para resolver una emergencia vigente y esta solución se usa como escudo para contener las contingencias mientras se desarrolla la solución definitiva. Definir desde el principio que las variables claves son: plazo, costo y calidad y establecer el equilibrio entre ellas. Esto significa precisar los S.L.A. (Service Level Agreement o Acuerdo de Nivel de Servicio) con los usuarios respectivos, estos SLA serán los iniciales y no siempre los definitivos. Precisar y definir lugar de trabajo del equipo del proyecto, capital ambiental. Especificar recursos financieros, técnicos, logísticos, de infraestructura y humanos, necesarios; se debe especificar qué se requiere (precisando tipo, perfil, calidad, etc.), cuánto se requiere, cuándo se requiere, hasta cuándo se requiere de cada recurso. Temer presente que todo problema, independiente de su complejidad y/o tamaño, nace de un pequeño detalle que, si pasó inadvertido, se convirtió en problema. Al dimensionar los recursos necesarios calcular holgura por incertidumbre. No dimensionar proyectos de largo plazo, pues el nivel de incertidumbre es muy alto y el riesgo de incumplimiento también es muy alto. Dentro del recurso financiero incluir un porcentaje de libre disponibilidad para otorgar premios, cuando corresponda. Una indefinición clásica es la confusión entre Proyecto y Producto, en que el resultado de un proyecto lleva a un producto, por lo tanto puede ocurrir que, un buen proyecto no siempre conduce a un buen producto, más aún, un mal proyecto puede tener como resultado un buen producto. Tener especial cuidado con los requerimientos no funcionales del producto (por ejemplo: disponibilidad, escalabilidad), pues suben el precio del proyecto y no agregan funcionalidad al producto. Los requerimientos impuestos/requeridos a un proyecto, pueden responder a:
Planificación, Desarrollo y Control de Proyectos
Página 7 de 86
A.- Tipos de requerimientos (estudiar cuáles son aplicables al proyecto en análisis) 1. OPERACIONALES (distintos escenarios) 2. FUNCIONALES (qué debe hacer el producto (aplicación)) 3. DE DESEMPEÑO (velocidad, disponibilidad, etc.) 4. DE INTERFASE (condiciones de borde, comunicación con otros productos) 5. DE RECURSOS (humanos, servicios básicos (agua, energía, etc.), qué consume, etc.) 6. FISICOS (peso, color, tamaño, etc.) 7. DE VERIFICACIÓN (métodos, demostraciones, etc.) 8. DE ACEPTACIÓN (pruebas en fábrica, criterios, rechazos, etc.) 9. DE DOCUMENTACIÓN (manuales, garantías, certificados, etc.) 10. DE SOFTWARE (ambiente/plataforma, compatibilidad, lenguaje, etc.) 11. DE SEGURIDAD FÍSICA Y DEL PERSONAL (prevención accidentes, advertencias, etc.). 12.- MEDIOAMBIENTALES (climáticos, medioambiente) 13. DE CALIDAD (confiabilidad. mantenibilidad, intercambiabilidad, compatibilidad, reusabilidad, etc.) 14. DE DISEÑO (cómo construir el producto (aplicación), como no construirlo, etc.) 15. DE EMBALAJE Y MARCAJE (estándar de embalaje, etiquetas de transporte, etc.) 16. DE ALMACENAMIENTO, TRANSPORTE Y PORTABILIDAD (anclajes, tamaño, peso, etc.) 17. LEGALES (regulaciones, estándares, normas, etc.) 18. DE COSTOS DE CICLO DE VIDA (costo anual (O&M, Operación y Mantenimiento), costos de actualizaciones, etc.) B.- Tener cuidado con lo siguiente: 1.- Aunque el usuario entiende mejor que nadie la necesidad que espera satisfacer y tiene absoluta propiedad sobre los requerimientos, no siempre puede expresarlos con claridad y/o completamente y/o en términos entendibles, para quienes deben entenderlos. 2.- Lo que el usuario dice querer, puede que no satisfaga su necesidad. 3.- La pre-concepción del usuario sobre la solución, reflejada en sus requerimientos, puede no resolver el problema del todo, o, al menos, no en forma óptima. 4.- El lenguaje y background del usuario y quienes deben proveer el producto, normalmente es distinto, lo que conduce a malas interpretaciones y/o malos entendidos en términos de expectativas. 5.- Si el usuario no participa en el desarrollo de la solución puede sentirse a disgusto de aceptar el producto final. No olvidar que los requerimientos, con el tiempo, maduran.
Planificación, Desarrollo y Control de Proyectos
Página 8 de 86
C.- Atributos de un buen requerimiento: M edible A lcanzable T razable V erificable E valuable C uantificable No obstante todo lo antes indicado, lo más importante es el equipo de trabajo, por eso nos referiremos a ello más adelante en forma aparte y especial.
1.2.- Metodologías La existencia y uso de metodologías, por mas probadas que estén, no es garantía de éxito de un proyecto. La ventaja al usar una metodología es tener un mayor y mejor nivel de certeza de la rigurosidad, acuciosidad, exhaustividad y/o sistematicidad en el desarrollo del proyecto. Existen diversas metodologías de apoyo a proyectos tecnológicos (Por ejemplo: tradicionales: CMM, CMMI, PMI, PMO, etc., ágiles: SCRUM), es conveniente escoger alguna o si hay recursos (tiempo, plazo y apoyo financiero), desarrollar una metodología de desarrollo, pero en este caso se agrega una variable más de riesgo el proyecto y es que la metodología puede tener errores e/o incompletitudes. Además existen metodologías de apoyo al producto del proyecto y metodologías para:
Planificación, Desarrollo y Control de Proyectos
Página 9 de 86
Para aplicar una metodología no es suficiente conocerla hay que saber usarla, luego si el equipo de trabajo no tiene experiencia en el uso de la metodología es necesaria una capacitación previa que debe ser parte de la planificación del proyecto. Especificar si se usará alguna metodología de control de calidad (ISO, SIX SIGMA, etc.), que especifican un porcentaje de no error. La Biblioteca de Infraestructura de Tecnologías de Información ITIL (Information Technology Infrastructure Library) describe las prácticas óptimas para entregar servicios de calidad. ITIL se ha posicionado como un estándar de las mejores prácticas para la industria de servicios de TICAR.
1.3.- Ciclo de Vida del Proyecto Todo proyecto tecnológico o no, al igual que casi todas las actividades humanas, tiene ciclos claramente diferenciables, se inicia con un fuerte ímpetu el cual va decayendo a medida que surgen problemas, luego es necesario que el líder del proyecto, esté atento y efectúe acciones y/o actividades que permitan mantener el espíritu y la cohesión dentro del grupo de trabajo. Es conveniente distinguir las etapas del ciclo de desarrollo del proyecto de las etapas del ciclo de vida del proyecto. Entre las etapas a considerar debe estar la capacitación a todos los involucrados, técnicos, usuarios, ejecutivos, que corresponda. El ciclo del proyecto puede tener revisiones y ajustes durante el transcurso de su desarrollo, lo importante es dejar debidamente documentados dichos ajustes. Los ajustes pueden deberse a revisiones del proyecto o a cambios pedidos para el producto resultante, en este último caso se puede optar por: Incluir el cambio requerido, ajustando el plazo y/o costo del proyecto Documentar el cambio y dejarlo como parte de la bitácora de cambios, la que será analizada una vez implementado el producto. Los cambios requeridos para el producto pueden ser catalogados en: Cambios imprescindibles, Cambios esperados Cambios deseados. Efectuar cambios al proyecto y/o al producto en medio de una contingencia, no es recomendable, explicado metafóricamente es como surfear en medio de un tsunami.
Planificación, Desarrollo y Control de Proyectos
Página 10 de 86
Una vez entregado el producto y recibido a satisfacción por parte del usuario, el proyecto creado para generarlo debe terminar.
1.4.- Fases y Aprobaciones El real avance de un proyecto se logra con la identificación de las fases del mismo y con una clara definición de condiciones y requisitos de término de cada fase y la definición de prerrequisitos de inicio de cada fase, que en algunos casos serán más, y/o diferentes, a las condiciones de término de la fase anterior, es decir, el inicio de una fase puede tener como prerrequisito el término de la fase anterior, siendo este prerrequisito una condición necesaria, pero no suficiente para el inicio de la fase siguiente. Las fases previas y/o posteriores, pueden ser más de una, adicionalmente pueden ser parte del mismo proyecto y/o de otros proyectos. El éxito y aceptación del producto, que el proyecto generará, se logra con el compromiso de todos los involucrados, tanto directa como indirectamente, es por ello que es necesario definir y comprometer a quienes corresponda, que son quienes usarán el producto resultante, con las aprobaciones que sea necesario. Al término de cada fase es recomendable efectuar una pequeña evaluación de lo aprendido y compartir ello con todo el equipo del proyecto, para evitar cometer los mismos errores en fases posteriores, este procedimiento permite generar lo que se denomina Inteligencia Colectiva.
1.5.- Hitos y entregables Dependiendo de: Plazo de duración del proyecto Credibilidad del equipo de trabajo, en especial del líder del equipo Apoyo directivo Si hay terceros involucrados Será necesario definir instancias intermedias de revisión que impliquen la entrega de productos parciales del proyecto, estas entregas tienen que tener la característica de ser físicas, es decir, deben ser palpables, mostrables y evaluables, en otras palabras, deben tener un valor. Los hitos a incorporar en el transcurso del proyecto deben responder preguntas como: porqué, cuándo y cuántos.
1.6.- Roles dentro del proyecto Si bien existen varios roles dentro de un proyecto, que deben ser desempeñados por persona(s) con diferentes perfiles, es conveniente destacar tres importantes roles, estos son: Usuario, es quien usa el producto resultante del proyecto; Cliente, es quien paga lo que el proyecto cuesta y Jefe de Proyecto, s quien motiva, dirige, planifica, controla el proyecto. Planificación, Desarrollo y Control de Proyectos
Página 11 de 86
En muchas ocasiones puede ocurrir que una misma persona cumpla el rol de usuario y de cliente, lo cual es complejo de gestionar. Para quien cumple el rol del jefe de proyecto es importante que identifique qué hace y cómo lo hace y en la mayoría de los casos ocurre lo siguiente:
Qué hace
Cómo lo hace Cosas Correctas Cosas Correctas Incorrectamente Correctamente (CCC) 10% 40% Cosas Incorrectas Cosas Incorrectas Incorrectamente Correctamente 30% 20%
Las características para calificar un producto son: Bueno, Rápido y Barato; en la combinación de ellas, solo es posible escoger dos, no se puede escoger las tres, pues por ejemplo si el producto es bueno y rápido, lo mas probable es que no sea barato.
1.7.- Proyectos Internacionales Si se participa y/o de dirige y/o se gestiona un proyecto internacional, es conveniente tener en cuenta, entre otras cosas, lo siguiente: Definir el idioma en que se comunicarán los integrantes del proyecto y ver quienes dominan dicho idioma y quienes deben o pueden ser capacitados. Huso horario de los países participantes del proyecto, pues podría ser muy incómodo para poder contactarse entre los integrantes del proyecto. Este aspecto además puede condicionar algunos SLA del proyecto. Logística asociada, y duración del proyecto, aspectos que entre otras cosas, obliga a analizar aspectos asociados a los viajes (pasajes, seguros, eventuales accidentes), visas de ingreso y/o de trabajo. Adicionalmente es conveniente definir el lugar físico donde fijar la sede del proyecto. Feriados en los países participantes del proyecto, para planificar plazos y confeccionar carta Gantt, Clima meteorológico de los países participantes que en algunas ocasiones por excesiva lluvia, nieve, tormentas, etc. las personas no pueden trasladarse a su lugar de trabajo. Estos aspectos a veces obligan a renegociar SLA. Cultura e Idiosincrasia de las personas de los diferentes países participantes del proyecto, para evitar malos entendidos. Evitar o mitigar eventuales percepciones despectivas hacia/desde otras nacionalidades.
Planificación, Desarrollo y Control de Proyectos
Página 12 de 86
A nivel del proyecto y/o del producto en desarrollo, es importante saber si el equipo de trabajo de nuestro país, dentro del proyecto, es parte del mismo o lidera el proyecto, pues dependiendo de ello es el nivel de gestión y responsabilidad dentro del proyecto. Adicionalmente ello puede definir la ubicación geográfica de las instalaciones donde se efectúen las actividades del proyecto. Esta localización, sumado a la duración del proyecto, puede significar que algunas personas deban trasladarse lejos de sus hogares, lo cual puede afectar la logística del proyecto. Normalmente los proyectos internacionales persiguen abaratar y/o compartir costos, aprovechando sinergias de la organización, ello se logra por medio de, entre otras cosas: reutilizar código, efectuar mantenimiento común, administrar y compartir el know-how, SLA compartidos, creación de un producto común, con adecuaciones a la realidad local de cada país donde se instale (que no modifique el producto común), para entre otros aspectos, cumplir con aspectos regulatorios y/o legales del país. Adicionalmente es recomendable precisar los beneficios que tendrán las oficinas/sucursales/países que participarán en el desarrollo del proyecto, respecto de quienes no participen y que, sin embargo, usarán el producto resultante. El cuidado que se debe tener en estos casos es que la mantención del producto común debe tener una evolución unificada, es decir, la parte de producto común debe conservarse por la vía de implementar las mismas modificaciones en todos los países donde esté instalado el producto.
1.8.- Preguntas de Repaso ¿Variables o características que definen un proyecto? ¿Qué se puede hacer para enfrentar este desafío? ¿Uso de metodologías? ¿Componentes básicos de la carta Gantt? En los proyectos que he participado o estoy participando y/o en mi empresa: ¿Cómo se presenta lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 13 de 86
2.- Gestión de la Planificación Estratégica en TICAR “Los pocos que hacen, son la envidia de los muchos que sólo miran”.
Jim Rohn
La planificación estratégica en TICAR es un plan general para el lineamiento de todos los proyectos y actividades que se realicen en la organización, relacionados con el TICAR, se apoya en el desarrollo posterior de planes tácticos y operativos.
Planificación Estratégica
Plan Estratégico Uno o varios Planes Tácticos Uno o varios Planes Operativos
Necesita que exista un plan de negocios, para que el plan de informática lo apoye. Se debe contar con el compromiso de los ejecutivos de la empresa. Si no se cuenta con este apoyo no es conveniente hacer este plan. Es un plan de largo alcance que, a pesar de lo dinámico de la tecnología informática es altamente conveniente hacerlo. Este plan consta de dos etapas: Desarrollo Implementación.
2.1.- Desarrollo Esta etapa consta de algunos requisitos básicos:
Duración entre uno a tres meses. Apoyar específicamente a un plan de Negocios existente Este tipo de Plan tiene un inicio claro, pero no tiene fin. Contar con un compromiso gerencial. Realizar un buen manejo sobre las expectativas de las personas. Conformar un Equipo de trabajo idóneo. Formado por tres o cinco personas, nunca número par e incluir a más usuarios que personas ligadas a la tecnología.
Tipos de enfoques:
Planificación, Desarrollo y Control de Proyectos
Página 14 de 86
SW driven: Responde a la pregunta ¿Qué negocio es posible hacer con el SW de que se dispone, por disponer se entiende el que la empresa posee y/o puede adquirir?. HW driven: Responde a la pregunta ¿Qué negocio es posible hacer con el HW de que se dispone, por disponer se entiende el que la empresa posee y/o puede adquirir?. Tanto este enfoque como el anterior, están errados. Business driven: Responde a la pregunta ¿Qué tecnología se requiere para el negocio que se desea desarrollar?. Este es el enfoque correcto. La respuesta que da informática es SLA, costos y plazos. La suma de esto va a dar por finalidad el plan. Este plan está liderado por usuarios y no por informática, quienes deben de ser la minoría, al término de esta etapa hay un informe que dice que es lo qué se debe hacer, cuánto cuesta y cuánto se va a demorar.
Para la etapa de desarrollo, existen metodologías con apoyo de Software (Ej. BSP, ISCOL, LISP, etc.), éstas no son incompatibles entre sí, con lo cual se pueden mezclar, creando una metodología propia. Esta etapa del plan debe tener orientaciones tales como: Base cero, donde se asume que en la empresa no existen tecnologías informáticas, por lo cual se debe considerar todo, SW, HW, comunicaciones, etc. El plan va a mostrar que es lo que se requiere y luego se hace una comparación con lo que hay. Continuista, donde efectivamente se reconoce lo que hay, y se comienza a armar el plan, pero solo con lo que falta, lo que se puede cambiar o mejorar. Las orientaciones son incompatibles, y una vez que se eligió una, ya no se puede cambiar durante la etapa. Esta etapa requiere un muy buen manejo de las expectativas que se crean en los usuarios, así se disminuye la posibilidad de fracaso. Al término de la etapa de desarrollo se logra como resultado un informe que es el plan estratégico en tecnología especificando las necesidades de Hw, Sw, recursos humanos, etc.
2.2.- Implementación Durante esta etapa toda la empresa participa existiendo distintos equipos. Comprende entre uno y cinco años, al término de este plazo debería estar implementado todo el resultado de la etapa uno. Toda variación en el plan de negocios, implica una revisión del plan informático y un eventual cambio de éste, incluso rehacerlo.
Planificación, Desarrollo y Control de Proyectos
Página 15 de 86
El plan informático tiene comienzo, pero no tiene fin, la dinámica de la tecnología obliga a una revisión continua. Los cambios en tecnología normalmente son para mejor. En esta etapa se utilizaran todas las tecnologías que vayan de acuerdo con el Plan Estratégico en TICAR que se elaboró en la etapa anterior.
2.3.- Capacity Planning Toda empresa debería realizar un plan o estrategia de las necesidades de expansión en sus capacidades de procesamiento, almacenamiento y comunicaciones (capacidad en CPU, RAM, disco y comunicaciones), según las proyecciones de negocio, ligadas a un presupuesto determinado, que sobre las necesidades futuras de la empresa se ha realizado. El plan, que debe ser revisado periódicamente, debe considerar los contratos con terceros, las variables que los regirán, por qué se va a cobrar, las capacidades que se ocuparán en el tiempo, las necesidades de seguridad, etc., además del análisis de la infraestructura en que se va expandir las capacidades, incluyendo obras civiles. Muy relacionado con el TCO (Total Cost of Ownership). Algo muy útil en la medida que los sistemas de apoyo contable permitan registrar los gastos/inversiones efectuadas con el máximo detalle respecto de a qué unidad/equipo/parte/pieza fue asignado. Entre las variables que influyen en la confección de un capacity planning está: la plataforma de desarrollo que la empresa posea la definición de los SLA Por otro lado, los desarrollos de Software en equipos del tipo mainframe, quedan restringidos o determinados, en parte, por el ambiente/plataforma/procesador que se está utilizando. Por esto, es necesario hacer estudios de permanencia en el mercado de los proveedores, de forma de asegurar que el ambiente/plataforma/procesador con el cual cuenta la empresa, siga disponible en el mercado y no tener que enfrentar problemas de incompatibilidades con los software. El capacity planning lo debe efectuar la organización propietaria de los equipos de TICAR, pudiendo ser la misma empresa o el proveedor que brinda el servicio de procesamiento de datos vía externalización/outsourcing, SaaS.
2.4.- Preguntas de Repaso ¿Cómo se enfrente un plan estratégico en TICAR? ¿Cómo se enfrenta un Capacity Planning en TICAR? En los proyectos que he participado o estoy participando y/o en mi empresa: ¿Cómo percibo lo antes mencionado? Planificación, Desarrollo y Control de Proyectos
Página 16 de 86
3.- Gestión de los Recursos Financieros en proyectos TICAR “Tómese el tiempo para planificar, pero cuando llegue el momento de la acción, deje de pensar y actúe”. Napoleón Bonaparte. Especificar recursos financieros (dinero en si para gastos e/o inversiones, y/o dinero para técnicos, logísticos, de infraestructura y/o humanos, necesarios), se debe especificar qué se requiere (precisando tipo, perfil, calidad, etc.), cuánto(s) se requiere(n), cuándo se requiere, hasta cuándo se requiere de cada recurso. Todo Estudio de Factibilidad debe considerar lo que se denomina opción cero que es considerar la opción de seguir tal como se está. Todo estudio de factibilidad requiere definición de costos (gastos e inversiones) y de beneficios, asociados a un plazo determinado de evaluación. Por el lado de los costos, dado que la solución es la misma para todas las opciones en evaluación, entonces la calidad y el alcance es el mismo, luego quedan las variables plazo y costo, en cuyo caso se sugiere fijar un plazo igual para todas las soluciones en evaluación y luego determinar el costo de cada solución para poder decidir la mejor opción. Al dimensionar los recursos necesarios calcular holgura de incertidumbre con su costo. No dimensionar proyectos de largo plazo, pues el nivel de incertidumbre es muy alto y el riesgo de incumplimiento también es muy alto y eso tiene un costo. Dentro del recurso financiero incluir un porcentaje de libre disponibilidad para otorgar premios, cuando corresponda. Considerar moneda en la que se evaluará el recurso. Considerar costos de garantías exigidas. El presupuesto de operación que comúnmente se denomina OPEX (operational expenditures u operating expenses), en las áreas de TICAR se divide en: Gastos de operación del área Gastos asignados a nuevos proyectos del área En un proyecto, el OPEX corresponde a los gastos del proyecto, excluye las inversiones. En algunos casos cuando el plazo estimado del proyecto pasa de un año a otro o de un período de presupuesto a otro, su financiamiento puede ser compartido entre los presupuestos de ambos períodos.
Planificación, Desarrollo y Control de Proyectos
Página 17 de 86
El presupuesto de inversión que comúnmente se denomina CAPEX (capital expenditures), debe reflejar las inversiones del proyecto y en la mayoría de las organizaciones este es un fondo limitado y concursable, es decir, los proyectos deben competir entre si para lograr los fondos del tipo CAPEX (inversiones) que requieren. Por lado de los beneficios, resulta ser lo más complejo en un Estudio de Factibilidad el determinar los beneficios y el cómo medirlos, por ello es conveniente que los determine el usuario, con apoyo de datos desde las áreas que corresponda, para el plazo definido. Normalmente ocurre que la demanda de los nuevos proyectos a desarrollar, dentro de la organización, exceden las capacidades de la misma Lo anterior obliga entonces a considerar y fijarse en ciertos aspectos del proyecto a desarrollar para lograr el financiamiento del mismo, en particular el CAPEX, entre dichos aspectos se deben considerar (lista no exhaustiva): El proyecto está considerado en el plan estratégico en TICAR Posición jerárquica de la unidad de TICAR Nivel de credibilidad de la unidad de TICAR Presión de niveles superiores Disponibilidad de recursos Interés de la unidad de TICAR Impacto al mercado con el producto del proyecto Necesidad del producto del proyecto Disponibilidad de recursos de usuarios Envergadura del proyecto Además impacta constitución de la unidad de TICAR Analizar las condiciones de entorno (economía del país)
3.1.- Disponibilidad Referido a la capacidad del equipamiento de TICAR de estar funcionando cuando el usuario y/o cliente lo requieren, en especial con la masificación de la red Internet que permite que clientes o usuarios de cualquier parte del mundo accedan a las aplicaciones, si el modelo de negocio lo permite. Se habla de disponibilidad o “up-time” de hasta 24*7 (24 horas al día, los 7 días de la semana) o también se mide en porcentaje, llegando hasta el 99,995%, en ambos casos se describe como alta disponibilidad; obviamente que mientras más disponibilidad se exija, mayor es la inversión y los gastos a efectuar, en hardware, software, comunicaciones, infraestructura y personas. No olvidar evaluar los costos de todos los requerimientos planteados al producto y/o al proyecto, pues ellos también suben los costos del proyecto.
Planificación, Desarrollo y Control de Proyectos
Página 18 de 86
Adicionalmente no olvidar que existen metodologías que permiten estimar tiempo y esfuerzo lo cual ayuda a estimar costos. Finalmente los costos del proyecto dependerán, entre otras cosas de: la calidad del producto resultante el equipo de trabajo, la complejidad del proyecto, la definición de objetivos, los SLA. También influyen los cambios en los recursos técnicos, financieros y, especialmente, en el equipo de trabajo.
3.2.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta con los recursos financieros de un proyecto?.
En los proyectos que he participado o estoy participando y/o en mi empresa: ¿Se considera lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 19 de 86
4.- Gestión de los Recursos Humanos en proyectos TICAR “Debemos pensar en cosas grandes mientras hacemos cosas pequeñas, de esa forma los detalles van en la dirección correcta”. Alvin Tofler. Piense antes que su objetivo es una meta muy alta, por ejemplo subir el Everest y después analice como armar su equipo de gente de trabajo, para lograr dicha meta. Especificar recursos humanos, necesarios; se debe especificar qué se requiere (precisando tipo, perfil, calidad, etc.), cuánto se requiere, cuándo se requiere, hasta cuándo se requiere de cada recurso humano, considerar que los recursos humanos involucran recursos financieros, técnicos, logísticos y/o de infraestructura. Incluir recurso para eventual capacitación. Al dimensionar los recursos humanos necesarios calcular holgura de incertidumbre. No dimensionar proyectos de largo plazo, pues el nivel de incertidumbre es muy alto y el riesgo de incumplimiento también es muy alto y es muy difícil comprometer recursos humanos en el largo plazo. El éxito y aceptación del producto, que el proyecto generará, se logra con el compromiso de todos los involucrados, tanto directa como indirectamente, es por ello que es necesario definir y comprometer a quienes corresponda, que son quienes usarán el producto resultante, con las aprobaciones que sea necesario. Cuidado con los accidentes laborales, hay un deber de prevenirlos, de ocurrir un accidente debe investigarse para evitar su repetición y ver como impacta al proyecto. Esto último también se debe hacer con las licencias médicas. Precisar si se usará apoyo de sistemas de colaboración empresarial (SCE) o “managerial collaboration Systems” o “Entreprise Collaboration Systems” (ECS). Los SCE son aplicaciones que propician la comunicación, coordinación y colaboración entre integrantes de equipos de trabajo. Dichos integrantes pueden estar dentro o fuera de la organización (ejemplo un equipo de trabajo al cual pertenecen consultores externos). El SCE puede estar formado por: Herramientas de comunicación electrónica (mail, fax, VoIP, etc.) Herramientas de conferencia electrónica (tele-conferencia, videoconferencia, chat, foros, etc.) Herramientas de gerencia de trabajo colaborativo (workflow, KMS, repositorio de documentos y/o datos, etc.) Existe además los denominados Portal de Información Empresarial (Enterprise Information Portal (EIP)), que consisten en una aplicación Web integrada, generalmente a la Intranet de la empresa y que permite acceso a todos los usuarios y con ello dichos usuarios acceden a toda la variedad de aplicaciones y servicios que brinda el EIP.
Planificación, Desarrollo y Control de Proyectos
Página 20 de 86
Existen mecanismos de: Coordinación, por ejemplo: supervisión directa, normalización (de procedimientos, de resultados, entre otros), acuerdo directo. Impulso, por ejemplo: reuniones periódicas, visitas al lugar de trabajo, actitud positiva a la búsqueda de soluciones. El líder del proyecto tiene el liderazgo formal que le otorga el rol que cumple, dicho liderazgo es válido y reconocido mientras cumple dicho rol, es un liderazgo necesario, pero no es suficiente, pues existe además el liderazgo informal otorgado y reconocido en base a diversas características de quien cumple el rol de líder, como por ejemplo: conocimiento, prudencia, criterio, capacidad de tomar decisiones, respeto, etc.
4.1.- Estimación de tiempo y esfuerzos Existen métodos para estimar plazos y en consecuencia el costo, naturalmente que estas dos variables son proporcionales a la calidad: Exigida o que se desea entregar en el proyecto y/o en el producto resultante Del grupo de trabajo (medido en conocimiento, habilidades y destrezas) Asimismo el plazo también está asociado al grado de dificultad enfrentado y especialmente a la claridad de definición del problema y al SLA acordado inicialmente y que, a medida que el proyecto avanza y se van clarificando diversos aspectos, en algunas ocasiones, es necesario ir redefiniendo los objetivos, el SLA, etc. Otro factor a considerar es la ergonomía, funcionalidad y domótica (seguridad y gestión energética) Otro factor que influye en esta estimación son los cambios que pueden ocurrir con los recursos técnicos, financieros y/o, mas importante, con los integrantes del equipo de trabajo. Los métodos de estimación requieren de mucha práctica para lograr niveles de certeza razonables. Es muy conveniente apoyar el trabajo en herramientas de TICAR de apoyo. Considerar turnos de trabajo, si se requiere. Cuidando especialmente del buen traspaso de información de un turno a otro, pues de caso contrario puede no lograrse el beneficio de trabajar en turnos.
Planificación, Desarrollo y Control de Proyectos
Página 21 de 86
Planificar incorporando sólo los días hábiles y horas de trabajo, reales, es decir, que efectivamente las personas estén efectuando labores para el proyecto, pues en el transcurso del día, ellas efectúan algunas labores que no aportan al proyecto. Asimismo al planificar o construir la carta Gantt, considerar que los días interferiados (día hábil entre al menos dos días feriados) normalmente son de alta ausencia. En casos de proyectos internacionales incorporar los días feriados e inter-feriados de todas las oficinas/sucursales/países que participan en el proyecto.
4.2.- Formación de equipos de trabajo y resoluciones de conflictos El líder del equipo pide los recursos técnicos, financieros y humanos en la cantidad, calidad y disponibilidad que requiere de acuerdo al objetivo y SLA acordado, según los recursos que logre, deberá renegociar plazo, costo y/o calidad del producto y deberá readecuar la gestión a efectuar en el proyecto a desarrollar. El equipo de trabajo está compuesto por los integrantes directos del mismo, los terceros que participan en el proyecto, los usuarios (internos y externos) directos e indirectos y ejecutivos; de las habilidades, destrezas, desempeño y compromiso de todos ellos depende el éxito del proyecto y del producto. Para lograr el cumplimiento de objetivos y metas, es altamente conveniente identificar las personalidades de quienes conforman el equipo de trabajo, como por ejemplo:
Planificación, Desarrollo y Control de Proyectos
Página 22 de 86
Dado que el componente humano es el más importante, y que el ser humano es esencialmente variable, dinámico y además de sus cualidades profesionales tiene sentimientos y estados de ánimo, es necesario desarrollar técnicas y actividades, que permitan administrar las características de las personas (una antes mencionada) como un equipo y cada una en forma individual. El líder debe estar atento a errores que cometa y que se cometan y corregir dichos errores y enmendar el rumbo y no caer en la costosa tendencia de persistir en el error, para lograr ello, parte del liderazgo es estar consciente de que es más fácil reconocer un error cometido hace años que el error cometido hace un par de minutos. Asimismo estar atento a aquellas personas que mayoritariamente encuentran problemas o dificultades y con ello frenan/lentifican el avance del proyecto, se les denomina comúnmente como “stoppers”, la opción es tratar de que no afecten al proyecto o en último caso desvincularlos del equipo de trabajo del proyecto. El líder debe combinar la administración con el liderazgo, debe ser ambidiestro. En el proceso de liderazgo intervienen: el líder, los colaboradores (no seguidores pasivos) y el contexto. Variables como preparación académica, formación profesional, edad, experiencia, género, son relevantes al momento de formar el equipo de trabajo y de gestionar o administrar dicho equipo durante el desarrollo del proyecto. Es conveniente que el equipo de trabajo esté formado por mujeres y hombres, en todas las áreas y actividades. Estructurar el organigrama adecuado, identificando áreas o unidades y sus responsabilidades, precisando claramente responsabilidades, roles y compromisos. Recurrir a especialistas en caso de conflictos serios, por ejemplo: psicólogo, sociólogo. Gestión de conflictos Estilo Efecto Impositivo (ganar-perder)
Complaciente (perder-ganar)
Estrategia Comunicacional La persona persigue sus Comunicación propios intereses, se orienta unidireccional hacia el poder y utiliza cualquier estrategia para Escasa escucha activa imponer. La persona descuida sus Comunicación propios intereses para unidireccional satisfacer los de otros. Conlleva un elemento de Pocas preguntas
Planificación, Desarrollo y Control de Proyectos
Página 23 de 86
auto-sacrificio y carencia de convencimiento Transador Solución mutuamente (perder-perder) aceptable que parcialmente satisfaga amas partes Evitador/postergador No enfrenta el conflicto y no busca satisfacer sus intereses ni el de otros. Desvía los temas de interés y evita situaciones amenazadoras Colaborador Trabajo conjunto para (ganar-ganar) encontrar una solución que satisfaga a ambas partes. La colaboración conlleva a la exploración profunda de los intereses de ambos para comprender los distintos puntos de vista
Baja asertividad Promueve el diálogo, pero este no es profundo Pocas preguntas abiertas Evade el diálogo y las preguntas abiertas Alta comunicación verbal Diálogo, empatía
no
Preguntas abiertas Retroalimentación asertiva
La existencia o ausencia de conflictos en si no es bueno ni malo, pues esto último va a depender del tipo de conflicto y de como se resuelva. Las preguntas a responder al formar el equipo de trabajo deben ser: quiénes (perfil y cantidad), desde cuándo, hasta cuándo, para qué. Es preferible escoger en base a habilidades sociales y /o personales que por habilidades técnicas, es decir, es preferible escoger a la mejor persona que sabe de ...... que escoger el experto en......... y que tiene carencia, por ejemplo: en las habilidades de relaciones interpersonales. Pues no es posible comprar un kilo de sensatez, o un litro de respeto, o un metro de tolerancia o enviar a una persona a capacitarse en buen genio o en empatía. Si se va a contemplar premios y/o reconocimientos individuales, se debe velar porque realmente sea un merecido reconocimiento y es conveniente efectuar dicho reconocimiento en público. Por otra parte las reprimendas es muy conveniente efectuarlas en privado La opción de emitir una certificación al mejor funcionario del proyecto, es conveniente evaluar que se está trabajando en un proyecto que entre sus características está el hecho que es de corta vida. Se sugiere no efectuar una certificación al peor funcionario del proyecto. Por otra parte, existen las certificaciones técnicas en distintas áreas del conocimiento, incluir en el proyecto a personas con certificaciones de este tipo, Planificación, Desarrollo y Control de Proyectos
Página 24 de 86
potencia el equipo de trabajo, pero no es garantía de éxito, por otra parte enviar a integrantes del equipo de trabajo del proyecto a un proceso de capacitación para obtener certificaciones técnicas, es recomendable para, entre otras cosas: potenciar el equipo al obtener mas y/o mejores soluciones al enfrentar problemas técnicos, mantener e/o intensificar el compromiso de las personas. Un buen líder: Sabe diferenciar: un grupo, de un equipo de trabajo. Formula las mejores preguntas, pero no tiene todas las respuestas. Logra, en las personas que conforman el equipo de trabajo del proyecto, que cada una de ellas entienda que tiene una responsabilidad asumida y no asignada. Mas que hacer que la gente trabaje, construye un entorno en el que trabajar sea posible, sea motivante, sea agradable. Asigna tarea sabiendo que la persona la hará bien y le hará bien. Adicionalmente, un buen líder: Posee competencias: o De Conocimiento, o De Ejecución y o Personales. Complementadas con competencias de: o La Industria, y o La Organización No caer en el Síndrome de Procusto: o Prescindir de quien sobresale En un equipo de trabajo, para su buen funcionamiento se requiere, entre otras cosas, las cinco C: Complementariedad Coordinación Comunicación Confianza Compromiso Al planificar actividades tener cuidado con lo siguiente: Las actividades secuenciales, alargan plazo Las actividades simultáneas, acortan plazo, pero exigen mas recursos (mas costo), y es recomendable planificarlas o efectuarlas mientras los rendimientos no sean decrecientes, debido a la incorporación de mas recursos. Al liderar un equipo de personas, es conveniente tener presente lo siguiente, respecto de cada persona: Planificación, Desarrollo y Control de Proyectos
Página 25 de 86
El conocimiento, es lo que sabe hacer. La habilidad, es lo que es capaz de hacer. La motivación, determina lo que hará. La actitud, determina que tan bien lo hará.
Y la importancia de lo anterior, al liderar, es a la inversa. Un problema vigente es: La generación X, Y, Millennials. Como usuario/cliente y/o como integrante del equipo del proyecto Obliga a: Pasar de Jefe a Gefe (Gestor de Felicidad) Utilizar Salario Emocional Por ejemplo: horario flexible, días libres, capacitación, etc.
4.3.- Teletrabajo Es la capacidad de trabajar desde cualquier lugar del mundo conectado por medio de tecnología de telecomunicaciones. Solo algunos roles del proyecto pueden ser llevados a teletrabajo asimismo sólo algunas actividades de un rol pueden ser desempeñadas mediante teletrabajo. Además, se necesita de un cambio cultural en la organización donde se implantará. Es una modalidad utilizada para que personas minusválidas accedan al trabajo, en especial de apoyo a call center a distancia. En Chile aún no hay un marco legal adecuado que regule esta actividad. Algo similar ocurre con la modalidad de trabajo BYOD (Bring Your Own Device) en relación al marco legal para esta modalidad, que tiene una serie de ventajas y desventajas y/o cuidados para implementarla.
4.4.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta para definir y elegir los recursos humanos de un proyecto?. ¿Características de un buen líder?
En mi realidad profesional pasada y actual (proyecto, empresa): ¿Cómo he percibido o percibo lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 26 de 86
5.- Gestión de contratos en proyectos TICAR “El pesimista se queja del viento, el optimista espera que cambie y el realista, ajusta las velas”. William George Ward
5.1.- Criterios de evaluación y selección de los proveedores de soluciones tecnológicas Hay organizaciones que asesoran el proceso de la contratación de proveedores. El sistema de outsourcing o externalización de actividades/tareas es una medida efectiva, que permite acceder a recursos capacitados y/o con experiencia en muy corto plazo para apoyar o desarrollar un proyecto específico y/o para atender un aumento de demanda ante una alta cantidad de proyectos a desarrollar en un plazo determinado, pero no siempre es eficiente, es decir, la justificación de usar este sistema no es recomendable efectuarla por eficiencia. Asimismo este sistema de outsourcing o de externalización, no es un sistema que libere de problemas y/o de la responsabilidad asumida en el proyecto. Para efectos de evaluar y seleccionar proveedores es conveniente confeccionar un registro de contratistas precalificados por servicio ofrecido. Llevar a la práctica esta idea no es tan fácil, se debe partir por confeccionar un cuestionario que permita crear una base de contratistas, con factores que facilitaran el análisis de los antecedentes entregados, para una posterior decisión de adjudicación de una propuesta. Todo esto significa elaborar bases de precalificación, llamar a dicha precalificación y confeccionar la base de contratistas precalificados con segmentación, por diversos factores, entre ellos: si es proveedor local o extranjero, el servicio ofrecido, presencia en el país y la solidez técnica y financiera, esto último para determinar el número de proyectos simultáneos que puede abordar y la envergadura de los proyectos que es posible adjudicarle. Es conveniente identificar si el proveedor es nuevo en el mercado, pues puede ser un aspecto muy favorable o de mucho riesgo. La relación con proveedores extranjeros puede ser compleja debido a diversos factores entre los cuales están: idioma, idiosincrasia, huso-horario, que tenga o no representante en el país, la calidad de su representante. Para estos dos últimos casos, en algunos ocasiones, si la reglamentación de la empresa lo permite, es posible efectuar una asociación (joint venture) con el proveedor, de forma tal de obtener rentabilidad del riesgo asumido al adjudicarle un proyecto a un proveedor desconocido en el país. Adicionalmente es necesario contar con una base similar para los antecedentes de los paquetes de software del mercado, de modo de tener preseleccionados los que Planificación, Desarrollo y Control de Proyectos
Página 27 de 86
correspondan al ambiente de hardware de la organización. No se recomienda incluir como antecedente para precalificar, la funcionalidad del software dado que, como el software evoluciona y cambia o se le agregan funcionalidades, es preferible evaluarla al momento de analizar el sistema en forma específica. Es conveniente efectuar un proceso de validez legal de antecedentes recibidos, pudiendo efectuarlo a todos los antecedentes de todos los interesados o seleccionar tanto interesados como documentos a verificar, es conveniente que en el llamado a precalificar se especifique expresamente este proceso. Estos antecedentes de precalificación pueden significar la necesidad de desarrollar un sistema de apoyo, que administre estas bases, con las funciones de agregar, eliminar, modificar y consultar por diversos aspectos la información almacenada y de permitir mantener vigente los antecedentes de comportamiento de los contratistas, a medida que se desarrollen los proyectos y se adjudiquen los servicios, e incorporar los resultados del monitoreo del comportamiento de cada contratista, por cada servicio adjudicado.
5.2.- Propuestas de licitación La propuesta o llamado a licitación, que está muy bien definido a nivel de empresas del sector público, requiere la elaboración de bases de tipo genérico para el llamado a propuesta. Es conveniente dar un código de identificación al proyecto o sistema en desarrollo. Para efectos de evitar que la diversificación de empresas contratistas y de paquetes de software, produzca una imagen de desorden entre ellas a los ojos del usuario, dado que cada una de las aplicaciones está bajo el prisma del proveedor que la desarrolló, es conveniente elaborar un conjunto de normativas que regule, estandarice y uniforme las aplicaciones tecnológicas de forma tal de que, para el usuario, sea transparente qué empresa desarrolló el software o a qué empresa se le compró la licencia de uso y que la unidad de informática no tenga la necesidad de entender las diferentes formas, estilos y/o normas de trabajo de cada oferente que se adjudique una aplicación tecnológica. En este aspecto la complejidad más difícil de administrar dice relación con la adquisición de un paquete de software que no responda a la norma establecida y, esto es más problemático aún, si a este paquete se le contrata con algunas modificaciones. Asimismo es necesario normar, estandarizar y homologar los servicios requeridos, de forma tal de poder comparar lo ofrecido en las ofertas recibidas. Los factores importantes a considerar, dicen relación con el hecho de tener una metodología que apoye la modalidad de trabajar con adjudicaciones a terceros externos a la empresa. Planificación, Desarrollo y Control de Proyectos
Página 28 de 86
Otros elementos que nunca deben dejarse de lado son los referidos a la necesidad de capacitar al personal que trabajará en esta modalidad, ya que es necesario prepararse en muchísimos aspectos para los cuales el perfil típico de la gente de informática no está preparado, tales como aspecto legal, de tipo contractual, de tipo administrativo, etc. que no son los que comúnmente se requieren y se ejercitan. Al llamar a licitación es altamente conveniente incluir como parte de la documentación a entregar a los oferentes, las normativas de la empresa, el borrador de contrato (que especifique, entre otras cosas: modalidad de pago, garantías, etc.) sobre el cual se definirá el contrato definitivo, además de las especificaciones técnicas y requerimientos funcionales del proyecto y/o servicio a licitar.
5.3.- Evaluación y selección de soluciones Si la solución ofertada involucra a varias empresas, es necesario exigir y presentar a una de ellas como la que actuará como responsable de la solución presentada, siendo la encargada de coordinar a las demás y es la que será responsable del accionar de todas ellas. Las soluciones requeridas y ofertadas pueden ser tan diversas como opciones tecnológicas hay, lo cual permite confeccionar una solución efectiva y eficiente. A continuación se analizará una de estas opciones, la que posee más factores de riesgo. Cuando se está negociando un contrato, que contempla la ubicación de personas dentro de las instalaciones de la empresa, que está contratando el proyecto y/o servicio, es necesario un contrato de respaldo que especifique cláusulas que definan, por ejemplo: El procedimiento en caso de detectarse situaciones anormales, como por ejemplo en caso de que el oferente ofrezca personal poco idóneo o conflictivo o en caso de que se detecte un robo o hurto. Aspectos de tipo legal al contratar personal temporal y/o a honorarios no dejando de lado el aspecto administrativo que esto implica, que es bastante engorroso Aspectos relacionados con la ubicación física de este personal y de los elementos que requiere para su desempeño. Adicional a todo lo anterior está el hecho de que al aumentar la dotación de personal de informática, si bien es cierto que se puede avanzar más rápido, y/o atender más proyectos en forma simultánea, es hasta un punto determinado, y no es menos cierto que esto trae consecuencias que pueden ser muy graves en el rendimiento de la configuración computacional la cual no está dimensionada para atender tantos requerimientos en labores informáticas que en sí mismas son de una alta carga de trabajo para cualquier equipo. Quien primero percibe este Planificación, Desarrollo y Control de Proyectos
Página 29 de 86
problema es el usuario al no tener los tiempos de respuesta a que estaba acostumbrado y después informática al ver que lo planificado no se cumple y que, por lo tanto, peligra el cumplir los plazos comprometidos e involucra a otros servicios como operación, comunicaciones, etc. los que, si están a cargo de otras empresas, es muy complejo de administrar. Otro aspecto a considerar al contar con la posibilidad de acceder a recursos externos es que, a los usuarios (por lo general el equipo ejecutivo), se le crea la percepción o expectativa de contar con recursos infinitos, luego no existiría excusa para no atender requerimientos informáticos, para evitar esto es necesario efectuar un muy buen manejo de expectativas de los usuarios. Al incorporar recursos humanos de contratistas a los proyectos, es conveniente precisar las tarifas de cobro de acuerdo al perfil de la persona, el rol a cumplir y la ubicación física que tendrá, es decir, estará ubicado en instalaciones del cliente o de la empresa contratista. Al estar ubicados físicamente en las instalaciones del cliente, es necesario administrar y hacer gestión de recursos humanos a todo nivel, pues estarán trabajando juntos, personas de diferentes empresas, con diferentes beneficios y eso las personas lo hacen notar y se crea un clima laboral complejo de administrar. Lo que debe tratarse de evitar es la diferenciación de condiciones a personas de diferentes empresas, pero en un mismo rol o que las personas se ubiquen físicamente en dependencias de su empresa y establecer mecanismos de comunicación de alta seguridad, concentrado la información del proyecto y de todo lo desarrollado para el producto en equipos de la empresa cliente. Aunque parezca contradictorio, es altamente conveniente cuidar a los proveedores (sobre todo a los pequeños y medianos) y estar atentos a lo que están haciendo, mas allá de las labores propias del proyecto en que están trabajando, es recomendable ver en que están en términos de gestión financiera y de recursos humanos, pues el éxito del proyecto se basa en la permanencia del proveedor. En particular en este último aspecto es conveniente poner atención a que, para el proveedor, la propuesta que presente le sea rentable, de caso contrario es un gran riesgo con una alta probabilidad de fracaso.
5.4.- Técnicas de negociación Al negociar jamás improvisar, es altamente recomendable prepararse e informarse previo a iniciar un proceso de negociación. La secuencia de una negociación es como sigue: 1.- qué voy a hacer, 2.- porqué, 3.- plazo y finalmente costo 4.- ¿Hay SLA entre lo del punto 1.-, 2.- y 3.- ?. Si, negociación OK Planificación, Desarrollo y Control de Proyectos
Página 30 de 86
5.- No, se debe volver al punto 1.- Nunca volver al punto 3.-, pues el costo y el plazo son consecuencia del punto 1.- y punto 2.Al negociar un contrato es necesario tener en claro que se está negociando las mejores condiciones para ambas partes del servicio y/o proyecto a contratar y que se debe privilegiar lo que realmente se requiere por sobre lo que se esté ofreciendo. Es muy importante tener mucho cuidado con los detalles de tipo organizacional, es necesario mantener un estricto control de los acuerdos tomados, no perder nunca la formalidad acorde a la situación y al nivel de relación existente entre ambas partes y, por sobre todas las cosas, TODO DEBE quedar documentado para ambas partes. En conjunto con lo antes mencionado, esta es otra actividad, para la cual también el personal de informática, en promedio, es débil, pues negociar un contrato en las mejores condiciones para la organización y el proyecto es una tarea muy complicada de realizar que también forma parte de las actividades que diferencian modalidad de adjudicación a terceros, externalización, SaaS o “outsourcing”. Junto con esto, está el hecho de requerir un fuerte apoyo de tipo legal para negociar algunas cláusulas del contrato. Otra decisión relacionada con la negociación del contrato es, optar por la modalidad de contratación, que puede ser muy simple como en el caso de instalar un paquete de software, o muy complicada cuando se juntan condiciones múltiples, como en el caso de comprar un paquete y efectuarle modificaciones, para la cual podría ser necesario realizar dos contratos, uno para la licencia de uso y el otro contrato para la parte de las modificaciones que se le deben realizar para adecuarlo a los requerimientos de la empresa. Al especificar el contrato se sugiere incluir todas las posibles instancias de término del mismo y para cada una se esas instancias especificar las cláusulas ”fusible” o de salida, que sea necesario. En particular, dado que el contrato será utilizado principalmente en caso de que las condiciones de término del proyecto y/o servicio sean anormales, es conveniente incluir todas las condiciones negativas y definir su resolución, todo aquello que no se defina en esta ocasión (antes de la firma) será causal de serios problemas en caso de ocurrir dicha situación, siendo lo más probable la salida arbitral y/o judicial. Al término del proyecto, en especial si el anormal, es necesario proceder a la brevedad a recuperar material de la empresa en manos del contratista, con mayor razón si es material confidencial, asimismo se debe proceder a separar de la empresa al personal del contratista que esté trabajando en dependencias de la Planificación, Desarrollo y Control de Proyectos
Página 31 de 86
empresa, se debe proceder a cobrar las multas acordadas contractualmente y después luchar contra el desánimo de las personas dentro de la empresa y su sensación de fracaso e impotencia, reiniciar el proceso de búsqueda de un nuevo proveedor o de término del proyecto con recursos internos si es posible. No tratar de rebajar el costo del proyecto, que al final lo hace poco atractivo al contratista, sino que analizar la funcionalidad, y fijar un valor acorde a ella y a la oportunidad en que el producto será entregado, versus la demora en desarrollarlo internamente, que podría dar a la empresa un beneficio importante. No perder de vista que el real beneficio de esta modalidad no es bajar costos, sino que es: desarrollar en poco tiempo, acceder a conocimientos que no hay dentro de la organización, responder a un período peack y/o tener productos de calidad y todo ello tiene un valor. La mejor negociación no siempre es la de menor costo, sino en la que se logra un punto tal que haga atractivo el proyecto para ambas partes y con ello se logre un compromiso para garantizar el plazo y funcionalidad acordados; y, si durante el transcurso del proyecto surgen nuevas necesidades, identificarlas claramente y definir modalidad de atención, es decir, internalizarlas con su correspondiente valor y plazo o dejarlas para después; todo esto de acuerdo con el usuario. En todas las instancias de negociación o reuniones con los proveedores, antes, durante y después de la adjudicación, evitar situaciones que permitan faltas de ética, en particular no estar nunca solo en las negociaciones, ni en las reuniones. Hay casos en que el proceso de negociación puede estar regido por normas legales, lo cual podría provocar que el desarrollo del mismo no sea tan libre y espontáneo, pues las partes involucradas pueden verse apremiadas por plazos y/o estructuras que determinan o norman el proceso de negociación. Para negociar, en algunos casos es preferible ceder en algunos aspectos con un objetivo mayor y/o más importante, que es no dañar la relación, y nunca perder de vista que la estrategia dominante es una mezcla entre cooperación y competencia (en ese mismo orden), algo así como “coopetencia”. En momentos de tensión, es mejor utilizar la “capacidad de helicóptero”, esto es evitar que roces anteriores y/o prejuicios que se han ido generando en el tiempo (por ejemplo: la “demonización”, es decir, pensar que la otra parte es perversa y, en consecuencia, atribuirle malas intenciones), provoquen distorsiones en el proceso. La desconfianza hace muy difícil negociar, porque en un caso así, las partes suelen optar por una estrategia competitiva o confrontacional, pues la confianza, creer que la otra parte, cumplirá, es clave en un proceso de negociación. Normalmente en un proceso de negociación el poder está repartido entre las partes, el punto está en como manejarlo, no obstante, aún para el poderoso es Planificación, Desarrollo y Control de Proyectos
Página 32 de 86
mejor convencer que vencer. La mejor alternativa se denomina BATNA (Best Alternative To a Negotiated Agreement). Adicionalmente, antes de iniciar un proceso de negociación, es necesario tener claro cuál es el: PUNTO DE PARTIDA (oferta inicial), PUNTO OBJETIVO (resultado que se desea obtener, normalmente es un valor inferior al punto de partida o superior, dependiendo de la negociación) PUNTO DE RETIRADA (límite de la negociación, sobrepasado este punto la negociación no es rentable, normalmente es un valor inferior al punto objetivo o superior, dependiendo de la negociación), este punto debe ser secreto, incluso después de terminada la negociación. Se sugiere evitar negociaciones interminables o excesivas que implican altos costos a la empresa. Las causas más habituales que provocan retrasos en las negociaciones son: La complejidad y valor del acuerdo Las relaciones existentes entre las partes Las habilidades de los negociadores El nivel de planificación y compromiso Los sistemas de gestión documental Es reconocido que cualquier proceso de negociación implica gestionar un gran volumen de documentos: borradores iniciales, revisiones de los contratos, actas de las reuniones, mensajes de correo electrónico, anexos, etc. A menudo, se manejan diferentes versiones de los mismos documentos entre las partes que están negociando o dentro de la empresa. Para evitar lo antes mencionado, se puede utilizar, entre otras cosas, Software de gestión de contratos, llamados sistemas de administración de contratos (CMS, por sus siglas en inglés) o sistema de administración de contratos (SAC) en español.
5.5.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al planificar la sub-contratación de actividades/servicios/productos del proyecto?. ¿Qué cuidados se deben tener al negociar?
En los roles que desempeño actualmente en proyectos o empresa: ¿Qué puedo aportar de lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 33 de 86
6.- Gestión de la Innovación en TICAR “La innovación distingue un líder de un imitador”. Steve Jobs
6.1.- Círculo virtuoso Es necesario tener en cuenta que en muchos casos, las acciones se centran en proveer los medios (TICAR) más que en cambiar los procesos (innovación) En muchos casos el desacuerdo es el impulsor de una innovación. Las TICAR pueden actuar como palanca para la innovación, los cambios NO ocurren por si solos, es necesario planificar una estrategia en la cual las TICAR pueden ser útiles, pero que estarán al servicio de lograr las metas definidas previamente. La innovación no se relaciona necesariamente con la calidad y/o con la cantidad de TICAR disponibles, sino con usar la TICAR en el marco de una estrategia coherente y consistente en el tiempo, tanto a nivel micro como macro. Es necesario definir la cultura de la gestión del conocimiento, que permita crear conocimiento, acceder a él, almacenarlo, distribuirlo, etc. Innovación es: Una actitud, luego lo vital son las personas, en consecuencia es muy importante la educación que reciben las personas. Para ello se puede crear o incentivar una cultura de creatividad en la organización mediante el incentivo de la creatividad, la creación de un programa para la incubación de ideas, eliminado las frases asesinas de la creatividad, etc. Usar lo mejor al menor costo, el mercado exige ser innovador, la innovación depende del negocio, del mercado, de la regulación legal, etc. Hacer un uso ingenioso de los recursos que se poseen. incluida la TICAR. Resolver problemas actuales o llenar vacíos Se puede innovar sin financiamiento, revisando prácticas y procesos, la innovación se puede comprar. Hay innovación externa e interna a la organización. La innovación: No dura nada, es de muy corta vida, porque es rápidamente copiada. Se debe implementar a tiempo, es decir, ni antes ni después Reporta beneficios financieros e intangibles como lealtad, reposicionamiento, Puede requerir cambios culturales y conductuales Puede ser de una(s) persona(s) o de la empresa Planificación, Desarrollo y Control de Proyectos
Página 34 de 86
La innovación tecnológica a menudo va de la mano con la innovación organizacional dentro de la empresa. Innovación no es solamente el acto de iniciar algo nuevo. No es solo la creación de un nuevo dispositivo o proceso como resultado de estudio y experimentación, que puede ser incluso un concepto totalmente nuevo al que se ha llegado "pensando fuera de la caja". Innovación es también la introducción de mejoras en procesos productivos actuales o en dispositivos de TICAR en uso. En consecuencia hay que estar dispuestos a que exista una alta tasa de fracaso en las innovaciones que se emprendan, que es uno de los grandes riesgos al innovar. El otro gran riesgo es aquello que impide innovar y se refiere a las actitudes negativas respecto de la innovación, que se traducen en actitudes como: Auto-limitarse, Temor a equivocarse, Temor a hacer el ridículo, Dar por bueno u óptimo lo sabido, Quedarse con una sola idea (la primera) Por mencionar algunas. Pero el tipo de innovación que afecta nuestras vidas es generalmente el producto de tres componentes: creatividad humana, perspicacia y percepción empresarial, y tecnología. El proceso de innovación comienza cuando personas creativas generan y desarrollan ideas. Continúa cuando esas ideas interactúan con empresas y tecnología. En el momento que se logra algún beneficio, es cuando la verdadera innovación se cristaliza, opina Idea Connections. Según Gartner, innovación es una competencia central emergente. Empresas líderes aceptan las innovaciones de otros e impulsan el mercado con sus propias innovaciones. Ellos deben responder y digerir las innovaciones de sus competidores y socios, y además deben innovar internamente en forma continua para permanecer competitivos. Las empresas exitosas balancean ambos tipos de innovación. El CIO de Dell, Randy Mott, dice que debemos hacer un trabajo mejor en la preparación del futuro, en lugar de apuntalar tecnologías anticuadas. "Las personas reticentes a exponerse activamente a las perspectivas del futuro terminan siendo historia". Así se expresó en el año fiscal 2004, 55 por ciento de los "recursos de las personas" de Dell se dedicarán a la innovación y tiene intenciones de elevar ese porcentaje hasta un 75 por ciento en 2006. "La cultura organizativa que se necesita para innovación puede ser muy diferente de la cultura que mantiene a la empresa encaminada", expresa George Westerman, Planificación, Desarrollo y Control de Proyectos
Página 35 de 86
un científico de investigación en el Center for Information Systems Research de MIT Sloan. "Sin un foco en innovación, los innovadores se ven aplastados por aquellos que quieren usar el dinero para hacer más de lo que ya están haciendo. Por eso es que innovación a menudo requiere un esfuerzo consciente". Si bien empresas tales como IBM y Xerox (EE.UU.), Sony (Japón), Samsung (Corea del sur), Nokia (Finlandia) y Novartis (Suiza) son líderes en tecnología que han permanecido a la vanguardia de las industrias dinámicas, poseen numerosas patentes y ostentan excelentes laboratorios de R&D, ellas no tienen el monopolio en innovación. El verdadero desafío que enfrentan las empresas en las regiones en desarrollo: inestabilidad política, tarifas de intercambio volátiles, infraestructuras deficientes, relativamente pocos científicos y universidades, bajos márgenes fe beneficio y reducciones presupuestarias, las fuerza a innovar en otras áreas de su negocio, de acuerdo con un artículo reciente de Harvard Business Review . Buenos ejemplos de eso son CEMEX (México); Natura (Brasil) y Haier (China). "Lo que estas empresas tienen es un enfoque diferente a la innovación: ellos explotan estratégicamente un profundo conocimiento del modo de pensar de sus clientes, innovan alrededor de la tecnología (en lugar de a través de ella) y buscan buenas ideas por todo el globo". La innovación puede, y debe, conducir al salto tecnológico en las regiones emergentes, y la creación de nichos tecnológicos lucrativos, éstos deben llenarse de individuos creativos y con coraje que pueden beneficiar a naciones enteras. Incluso tecnologías disruptivas como la nanotecnología y el código de fuente abierta podría emerger y transformar regiones en desarrollo en esta era de investigación global, colaboración y de incubadoras enlazadas mediante la Internet. Una encuesta de IDC sobre innovaciones en TICAR descubrió que "lo mejor aún no ha llegado". El estudio predice que 75 por ciento o más de los beneficios que brinda el software se verán en el futuro, y que la industria creará más de 1.5 millones de nuevos trabajos bien pagados globalmente y generará una cantidad adicional de $290 mil millones en beneficios de impuestos globales en los próximos cuatro años. Con la innovación, las organizaciones se vuelven mas productivas y ponen en riesgo la competitividad de sus competidores, los cuales para sobrevivir, deben imitar o, mas aún, deben tratar de mejorar la innovación incorporada por su competencia. La innovación genera beneficios económicos y sociales alrededor del mundo. ¡Promueva innovación y abra el camino hacia el futuro!
Planificación, Desarrollo y Control de Proyectos
Página 36 de 86
6.2.- Agentes y Actores Existen las organizaciones innovadoras, las rápidas seguidoras (fast follower) y las seguidoras (follower), de las innovaciones. Para lograr concretar una innovación se requiere de: Innovador (puede ser un grupo de personas), lo cual presupone un ambiente de formación y educación que fomente la innovación. Normalmente posee cinco habilidades: observar, asociar, preguntar, hacer networking y experimentar. Financista (puede ser una entidad o un grupo de personas) comúnmente denominado “inversionista ángel” que provean de capital al innovador, denominados capital semilla o capital de riego. Apoyo estatal mediante primero subsidios a la investigación y/o adquisición de conocimientos, segundo un adecuado marco legal y tributario de fomento a la innovación y, tercero, protección al conocimiento logrado, por ejemplo mediante patentes. Y de una fuerte interacción cooperativa entre ellos. Como cualquier prototipo, el riesgo de una innovación (primer mito: la innovación es riesgosa) se puede contener y minimizar antes de utilizar la solución a escala completa. Es necesario entrar al mercado temprano, ensayar diferentes experimentos, ver el desempeño, hacer ajustes mientras se avanza y administrar el riesgo. Lo más importante es no dudar en terminar con un proyecto que está dando malos resultados. Puede variar el portafolio de proyectos para distribuir el riesgo, y más importante aún, siempre pensar que puede ser de mayor riesgo el no innovar. El segundo mito indica que la innovación exige romper con el pasado, sin embargo está más que comprobado que la innovación es un proceso que evoluciona y crece de las competencias centrales de la compañía y los activos estratégicos, por lo que no puede hacerse de la nada ni desconocer el pasado. También se dice siempre que la innovación es el trabajo de las unidades o áreas de Investigación y Desarrollo y algunos “locos” de la organización. Se ha demostrado con creces que la innovación es un trabajo de todos. Si se examinan los premios que se otorgan por innovaciones o mejoramientos substanciales a procesos usando el ingenio, por lo general son otorgados a personas que hasta ese momento pasaban desapercibidas en la compañía. Por último, existe la creencia que la innovación se puede generar a partir de tormentas de ideas. La innovación exitosa requiere un proceso sistemático utilizando varias lentes para mirar el mundo y poder imaginar lo que sucedería si reta las formas establecidas de hacer negocios en su industria. La innovación requiere: Planificación, Desarrollo y Control de Proyectos
Página 37 de 86
Mucho marketing, para lograr los recursos para su desarrollo y después en su implementación para lograr que, a quienes está destinada, la usen y durante el proyecto para mantener la motivación del equipo de trabajo y administrar las expectativas Administrar el cambio conductual y/o cultural asociado a la implementación de la innovación Buen manejo y administración de información confidencial, durante su desarrollo. Buen manejo de expectativas Que al implementarla, eventualmente se debe proteger por medio de patentes a la innovación en sí y a las personas que participan en el proyecto de innovación de la incredulidad de los demás. En algunos casos que se tarifique su uso o se le asigne un precio de venta
En Chile existe el Consejo Nacional de Innovación para la Competitividad que asesora al Presidente de la República.
6.3.- Tipos de innovación Se pueden clasificar desde varios puntos de vista: Según el conocimiento o desarrollo de la nación involucrada Desarrollo local, mediante la adopción de TICAR existente en el extranjero Desarrollo de TICAR nueva En los países en desarrollo el primer tipo es más relevante el segundo tipo es más común en países desarrollados Según el objeto Innovación Tecnológica Innovación Social Innovación en métodos de gestión Innovación operacional Según el efecto Adaptativa Incremental Disruptiva o Radical Según el origen Presionada por la TICAR (push) Impulsada por el Mercado (pull) Desafortunadamente nuestro país, exhibe un desempeño muy por debajo de sus potencialidades, en este momento el país se enfrenta al desafío de “Innovar o estancarse”, similar al desafió que vivió décadas atrás de “exportar o morir” del Planificación, Desarrollo y Control de Proyectos
Página 38 de 86
cual resulto el exitoso modelo exportados actual. Esto significa crear “clusters” en loa cuales innovar, dichos “clusters” deben estar en torno a las ventajas competitivas del país (recursos naturales y otros). Orientar el país hacia la economía del conocimiento.
6.4.- Vigilancia Tecnológica o Faro Tecnológico Provee de inteligencia y conocimiento para anticipar, reducir riesgos, progresar, innovar, cooperar, consiste en: Captar información de TICAR del entorno, detectando oportunidades y amenazas (vigilancia externa), y fortalezas y debilidades (vigilancia interna) Seleccionar lo que se considere relevante para el negocio, que sirva para mejorar la posición competitiva de la organización Es conveniente difundirla dentro de la organización y utilizarla como herramienta de apoyo en la creación de valor, en la cadena de valor, en el desarrollo de estrategias competitivas y/o en la toma de decisiones. Además implica desarrollar un roadmapping de TICAR: Visión retrospectiva, dónde estábamos, con qué contábamos, que hacíamos Visión actual, dónde estamos, con qué contamos, que hacemos Visión prospectiva, dónde queremos estar, con qué queremos contar, que queremos hacer, en consecuencia se puede evaluar la brecha existente, presupuestar costo y plazo y conformar el proyecto correspondiente. Lo anterior, permite desarrollar lo que se denomina Inteligencia Competitiva en TICAR, concepto que puede extenderse, y de hecho existe, para el negocio. Al efectuar innovación, es necesario equilibrar diariamente: Explotación (producción, eficiencia, formal, bajo riesgo, etc.) Exploración (innovación, tolerancia al error, adaptativa, de alto riesgo, etc.) Lo cual exige ser ambidiestro.
6.5.- Preguntas de Repaso ¿Qué consideraciones se deben tener al gestionar la innovación en un proyecto?.
En la actual actividad que desempeño: ¿Qué puedo desarrollar o aportar en innovación?
Planificación, Desarrollo y Control de Proyectos
Página 39 de 86
7.- Gestión de la Seguridad en TICAR “El que sobrevive no es el más fuerte ni el más inteligente, es el que se adapta más rápido a los cambios” Charles Darwin
7.1.- Evaluación y gestión de los riesgos e incertidumbres Al inicio del proyecto, junto con el ímpetu inicial, se tiene el mayor optimismo, motivación y compromiso, que se comparte con el, también, mayor nivel de incertidumbre del proyecto y del producto resultante; al avanzar el proyecto, las fuerzas iniciales van decayendo, lo cual implica gestionar que no continúe y la incertidumbre también, lo cual es muy beneficioso. La administración del proyecto debe contemplar como parte de su análisis las opciones de abortar el producto y finalizar el proyecto antes de su término planificado, si las condiciones de incertidumbre y/o riesgo así lo ameritan. Lo cual conduce a efectuar una administración inteligente del riesgo, o una Administración del Riesgo del Proyecto (Project Risk Management). El riesgo y la incertidumbre están presentes en todo proyecto y durante todo el proyecto, es una de las labores del líder del proyecto lograr que dicho riesgo e incertidumbre sean las mínimas posibles y con las que se encuentre debe administrarlas de forma tal que el impacto sea el mínimo posible, para ello debe estar preparado para tomar decisiones sin mucha información, ser capaz de enmendar rumbos si las condiciones cambian, eventualmente cambiar decisiones ya tomadas, sin mostrar un efecto de pánico ni de pérdida de objetivos, dado que esta situación crea más incertidumbre entre los integrantes del equipo de trabajo, aumentando el riesgo y esto puede hacer que sea imposible la conducción del proyecto. Existen diversas formas de enfrentar los riesgos, desde usar matrices de riesgo, con criterios de evaluación de cada riesgo a usar procesos como por ejemplo el Risk Breakdown Structure (RBS), o Estructura de Desglose de Riesgos (EDR). En un proyecto de TICAR existen fuentes internas y fuentes externas de riesgos. Posibles estrategias a seguir ante riesgos son: Riesgos positivos: Explotación del riesgo para asegurar que ocurra Compartir el riesgo o asignarle propiedad del mismo a un tercero Mejorar el riesgo, identificando y maximizando los inductores claves del mismo Aceptarlo Riesgos negativos: Evitarlo Planificación, Desarrollo y Control de Proyectos
Página 40 de 86
Mitigarlo Eliminarlo, si es posible Aceptarlo, transfiriendo sus consecuencias, puede ser aceptación pasiva o activa. o Una aceptación pasiva significa dejar que el riesgo suceda, sin modificar para nada la actitud durante el proyecto. o Una aceptación activa requiere la existencia de un plan de contingencia el cual se activará en caso de que el riesgo se presente. El análisis del riesgo es un proceso tanto cuantitativo como cualitativo, para estimar su grado de incertidumbre e impacto. Una secuencia propuesta de escala de riesgos (según Iván Rivera PMP) en base a probabilidad de ocurrencia e impacto, sería: Riesgo 1: Baja probabilidad y bajo impacto Riesgo 2: Probabilidad media y bajo impacto Riesgo 3: Alta probabilidad y bajo impacto Riesgo 4: Baja probabilidad e impacto medio Riesgo 5: Probabilidad media e impacto medio Riesgo 6: Alta probabilidad e impacto medio Riesgo 7: Baja probabilidad y alto impacto Riesgo 8: Probabilidad media y alto impacto Riesgo 9: Alta probabilidad y alto impacto Los riesgos con baja probabilidad y bajo impacto no suponen una gran amenaza para el proyecto, pueden ser fácilmente manejados por el Jefe de Proyecto (y su equipo) y podrían requerir supervisión o monitoreo superficial. A medida que el impacto del riesgo en un proyecto aumenta, se requerirá más tiempo, atención y gestión de riesgos detallada, no sólo por el equipo del proyecto, sino también por todos los involucrados. Un riesgo identificado con una alta probabilidad e impacto puede requerir fondos, tiempo y recursos adicionales para superarlo. Es un indicio de atención urgente necesaria. Cuando se ha asignado una puntuación de probabilidad a un riesgo, es fácil para todos los involucrados evaluar el daño que podría plantear al proyecto, y esto se convierte en parte del informe de evaluación de riesgos. Cuanto mayor sea la puntuación de probabilidad e impacto (PI), más agresivo debe ser el enfoque de gestión de riesgos.
Planificación, Desarrollo y Control de Proyectos
Página 41 de 86
Glen nos recuerda que el cálculo de riesgo estándar es: Riesgo = Probabilidad de Ocurrencia x Impacto
Esquema general de una RBS para un proyecto de TICAR
Proyecto de TICAR
Negocios
Técnico
Organizacional
Gestión del Proyecto
Competencia
Hardware
Soporte ejecutivo
Estimaciones
Proveedores s
Software
Soporte Al usuario
Comunicación
Planificación, Flujo deDesarrollo y ControlRed de Proyectos
capital
SoportePágina 42 de 86 Recursos Al equipo
7.2.- Factores de riesgo, causas de posible fracaso, incorporación de seguridad Buscar las excepciones, nada es igual a otro(a), incluso dentro del mismo proyecto. Algunos tipos de riesgo, que pueden estar presentes en mayor o menor medida, en cualquier proyecto de TICAR: De la organización (internos), de mercado (externos) Tecnológicos De las personas (del proyecto o fuera del mismo) De procesos (del proyecto o fuera del mismo) Comunicacionales Mis decisiones Todos y cada uno de ellos requieren identificación, análisis y cuantificación Los factores de riesgo y causas de posible fracaso pueden estar presentes desde el inicio del proyecto, no obstante dichas causas no siempre se perciben, mas aún un proyecto puede haber fracasado después de mucho avanzar, debido a una causa que se presentó el inicio del mismo, pero que no fue percibida, por esta razón resulta ser muy interesante y de mucho aporte, analizar la o las causas reales y profundas de fracaso de un proyecto. Normalmente ante el fracaso de un proyecto se perciben las consecuencias y se trata de resolverlas y se presume como causa algo actual, no se busca más allá de la simple explicación. Entre los factores de riesgo, que si no son debidamente administrados pueden convertirse en causas de posible fracaso, están: Dispersión geográfica, que atenta contra la obtención de información para el desarrollo del proyecto y posterior implementación del producto. Incorrecta selección de integrantes del equipo de trabajo, lo cual impide contar con las personas que se requieren en cantidad, perfil y calidad que el proyecto requiere. Iniciar el proyecto en condiciones adversas, sin definición de objetivos, sin compromiso ejecutivo y/o de usuarios, con falta de recursos técnicos y/o financieros. Deslealtad del líder del equipo consigo mismo, al iniciar en proyecto subestimando la necesidad de recursos. Proveedores que subdimensionan oferta, para poder adjudicarse la propuesta. Faltas de ética, de integrantes del equipo y/o de proveedores. Estimaciones de plazo, costo y/o calidad, incorrectas o muy optimistas Incorrecta administración del cambio, tanto cultural como organizacional Desinformación, a nivel de equipo de trabajo, hacia usuarios, ejecutivos, contratistas, ya sea porque la información entregada es incompleta y/o a Planificación, Desarrollo y Control de Proyectos
Página 43 de 86
destiempo, adicionalmente se incorpora la mala administración de la información confidencial. Incorrecta asignación de roles, que se traduce en no asumir responsabilidades o asignarlas incorrectamente. Se incluye la falta de liderazgo. Incorrecta toma de decisiones, que puede ser por indecisión, tomar decisiones equivocadas y/o a destiempo, insistir en decisiones tomadas aun cuando las circunstancias ameritan cambiarla. Estancamiento de toma de decisiones debido a la continua espera de información para tomarlas. Incorrecta contratación de terceros, adjudicando incorrectamente o no ejercer el adecuado control del desempeño del contratista. Desatender señales de riesgos, los riesgos y probables causas de fracaso dan señales cuya percepción requiere de un estado de alerta constante. Incorrecta estimación de pronósticos, inadecuada estimación de comportamiento futuro del desarrollo del proyecto, ya sea porque fue errada, incompleta y/o a destiempo. Subdimensionar impacto del cambio cultural, que impacta tanto a técnicos como usuarios y directivos, con mayor razón si el producto del proyecto es una innovación tecnológica que implica reducción de personal donde se implemente. Recordar que ante el cambio el cerebro actúa en base a una de dos formas: huye o ataca, es decir, huye del cambio y no participa o ataca y trata de anular el cambio. La incorporación de seguridad se debe administrar al: Producto a desarrollar, incorporando las medidas de seguridad que dicho producto requiera, Proyecto en sí, respecto de reducción de riesgos, fugas de información confidencial, prevenir y enfrentar contingencias. La incorporación de seguridad en un proyecto está referida a aspectos de prevención a todo nivel de riesgos asociados al mismo y no debe entenderse sólo como el concepto de seguridad asociado a auditoría. Las medidas de seguridad, tienen como objetivo principal preservar la integridad de las personas y después los bienes, para lograr estos objetivos, está la: Seguridad preventiva que reduce la probabilidad de ocurrencia de eventos no deseados y reduce las consecuencias en caso de llegar a ocurrir dicho evento, que puede ocurrir a pesar de las medidas preventivas. Seguridad reactiva, que se activa una vez ocurrido el evento no deseado, tiene como objetivo estructurar la organización para minimizar las consecuencias de lo ocurrido y permitir enfrentar el presente y futuro de la mejor forma posible, a pesar de lo ocurrido.
Planificación, Desarrollo y Control de Proyectos
Página 44 de 86
La seguridad no es un proyecto, es un proceso continuo, es necesario: Evaluar (cuál es la situación actual), Diseñar (dónde se desea estar), Implementar (cómo se llega desde donde se está hacia donde se desea estar), administrar y soportar (cómo nos mantenemos y mejoramos), Todo lo anterior dentro de políticas, estándares y normas de seguridad y la correspondiente capacitación, en la actualidad existe el hackeo ético, con el propósito de lograr una buena seguridad. La seguridad puede ser en base a equipos propios o no, o en base a un servicio local o remoto, es decir, se puede administrar mediante web, en la actualidad existen organizaciones dedicadas a seguridad, ofrecen los servicios de seguridad como un ASP, hacen hasta respaldos en forma remota y los resguardan. En seguridad se debe cubrir: Seguridad perimetral (alámbrica e inalámbrica), debe cubrir de extremo a extremo Seguridad de contenido (de datos y de software, en particular en el correo electrónico, en que a veces se burlan controles al usar zip, hay sw de seguridad que identifican y analizan archivos .zip), Seguridad de identidad (Identity Management) y Seguridad del puesto de trabajo. Debe implementarse con equipos de alta disponibilidad. La tendencia en seguridad es: a dispositivo específico (appliances), móvil, biométrica, certificado electrónico, firewall personal, antivirus en red. En el caso específico de seguridad en acceso remoto para clientes inalámbricos, "clientless" (necesario para teletrabajo y e-learning), tendencia a conectividad móvil, la seguridad no es barrera, es a veces la llave del negocio, el problema de este acceso remoto es la diversidad de dispositivos, redes, protocolos, etc., lo anterior es porque hoy en día, la conectividad es desde cualquier parte, a cualquier hora, con cualquier acceso y cualquier dispositivo, las opciones son: Instalar sw de seguridad en cada equipo lo cual es lento, largo de hacer y complejo de mantener Instalar sw de seguridad en los servidores y dar acceso central con balanceo de carga. Es más conveniente instalar software de seguridad en los servidores. En conexión inalámbrica, (Ej.: wi-fi, wlan), la seguridad física no es suficiente, pues el vecindario es parte de la red, al hacer roaming dicha seguridad puede cambiar.
Planificación, Desarrollo y Control de Proyectos
Página 45 de 86
Ante un ataque, cuyas etapas son: previo al ataque, durante y después; el antiataque debe ser de prevención, no sirve de tipo de correctivo (ej.: saber que la empresa o el equipo fue atacado ayer), algunos equipamientos permiten que la administración de seguridad en estas plataformas se pueda hacer en forma centralizada, Dentro de las políticas de seguridad (se debe tener presente que al estar distribuidos los equipos, eso implica transmitir las políticas, etc.) debe considerarse que a mayor ancho de banda los usuarios siempre encontraran en que usar dicho ancho de banda extra, actualmente existe EIM (employee internet management) que consiste en administrar el uso de acceso a internet, esto significa crear y establecer políticas al respecto, mas que restricciones, con estas políticas la organización limita la responsabilidad legal, disminuye riesgos, administra el ancho de banda, mejora la productividad de los empleados, esto significa que a cada empleado, se le otorgue una cuota de tiempo y/o se le posponga el acceso para después del trabajo, (afterwork.com), el sofware permite tener estadísticas de acceso a sitios, por ejemplo: sitios de noticias, ver su cuenta bancaria, de búsqueda de trabajo, (si aumenta, ¿estará bien el clima laboral?). En términos de seguridad, de la password se pasó a la VPN, después a la SSLVPN y ahora está IPW (Instant Private Web), que corresponde a la autentificación remota, vía token que puede ser instalado en el puerto USB o ser usado en forma independiente. Se sugiere utilizar matrices de riesgo, como por ejemplo: Riesgo, Amenaza o Vulnerabilidad (descripción, fecha y número de ocurrencia)
Grado o Involucra o Causa(s), Magnitud Impacta origen y (crítico, fuente alto, medio o bajo) en colores
Consecuencias Medida de Efecto (descripción y mitigación o valorización) Control (descripciòn y fecha)
Riesgo Residual
Su uso permite ordenar, priorizar y efectuar seguimiento a los riesgos detectados en el proyecto y/o producto. Planificación, Desarrollo y Control de Proyectos
Página 46 de 86
Para TICAR existen estos dos tipos de seguridad bastantes reconocibles, los cuales deben estar sujetos a un análisis costo beneficio antes de implementarlos, algunas de las medidas de seguridad son:
7.3.- Seguridad Física de tipo preventivo Se tiene dentro de la seguridad física, distintos aspectos que pueden brindar seguridad tanto a las personas como a los equipamientos, además de la continuidad operacional. Algunos de estos elementos se mencionan a continuación: Accesos Físicos Existen distintos controles físicos como: Guardia o portero, que significaría la primera barrera de seguridad de la empresa. Una segunda barrera serían tarjetas de visitas o magnéticas, en que indique a que piso se dirigen y les permita el acceso solamente al piso o sección indicada. Determinar zonas con accesos restringidos. Contar con circuitos cerrados de televisión (es necesario analizar dónde y cuántas cámaras de televisión instalar y qué y cuánto se grabará de lo que las cámaras filmen). Detectores de movimiento que se activan al momento de cerrar las instalaciones. Detectores de metales: ofrece ventajas sobre la palpación manual, la sensibilidad de estos detectores es regulable, permitiendo establecer un volumen metálico mínimo, a partir del cual se activará la alarma. La utilización de este tipo de detectores debe hacerse conocer a todo el personal, de manera que actúe como elemento disuasivo. Sistemas biométricos: La biometría es una tecnología que realiza mediciones en forma electrónica, guarda y compara características únicas para la identificación de personas. La forma de identificación consiste en la comparación de características físicas de cada persona con un patrón conocido y almacenado en una base de datos. Los lectores biométricos identifican a las personas por sus manos, ojos, huellas digitales y voz. Huella digital: Se basa en el principio de que no existen dos huellas iguales, este sistema está siendo utilizado desde hace mucho tiempo con excelentes resultados. Verificación de voz: la dicción de una o más frases son grabadas y en el acceso se compara con la voz (entonación diptongos. Agudeza, etc.). Verificación de controles oculares: Estos modelos están basados en los patrones del iris o de la retina y hasta el momento son los
Planificación, Desarrollo y Control de Proyectos
Página 47 de 86
considerados más efectivos (en 200 millones de personas la probabilidad de coincidencia es casi 0). Verificación automática de firmas (VAF): Mientras es posible para un falsificador producir una buena copia visual, es muy difícil reproducir las dinámicas de una persona, por ejemplo la firma genuina exacta. La VAF. Usando dimensiones acústicas toma datos del proceso dinámico de firmar o de escribir. La secuencia sonora de emisión acústica generada por el proceso de escribir constituye un patrón que es único en cada individuo, el patrón contiene información extensa sobre la manera en que la escritura es ejecutada. Existe además le verificación de la dominada firma electrónica y la denominada firma digital, que en algunos casos requiere certificados de validación entregados por un tercero o ente certificador, con un costo asociado. Seguridad con animales: de gran utilidad cuando se deben custodiar grandes terrenos y además cuentan con sentidos más sensibles. Las medidas de seguridad señaladas, siempre están restringidas por la cantidad de recursos monetarios que se dispongan, debiéndose realizar un análisis inversión v/s protección. Mientras la seguridad sea rentable, se invierte. Equipos de Prevención Como prevención, existen distintos elementos e instalaciones que cumplen con este objetivo, especialmente para prevenir incendios, por ejemplo: Extintores, se debe efectuar una planificación con respecto a la cantidad de extintores que se van a adquirir, como será la distribución, de que tipo (por ejemplo, especiales de gas para incendio en equipos de TICAR), tamaño, dado que los extintores tienen fecha de vencimiento, es necesaria una planificación logística de cuántos llevar a renovarse o llenarse y cuántos dejar en la empresa, etc. Detectores de humo, los cuales dan aviso por una concentración de humo superior a la permitida. Estos detectores se deben revisar cada cierto tiempo, además se pueden regular, según el sector en que están colocados. Deben ser instalados en altura (por las condiciones del humo, que siempre tiende a subir) y por gente capacitada. Detectores de gas, al igual que los de humo, se deben regular y revisar por gente capacitada. Su instalación debe ser a baja altura, ya que los gases suelen ser más pesados que el oxígeno, por lo que se acumulan a nivel del suelo. Mangueras y red seca. La red seca es común en edificios, son cañerías que van sin agua y se llenan en caso de incendio distribuyendo agua por todo el edificio. Por lo general, son de uso exclusivo de bomberos. Sprinkler o rociadores. Dispositivos que se instalan y se accionan generalmente por temperatura, pueden ser de agua o de gas antifuego
Planificación, Desarrollo y Control de Proyectos
Página 48 de 86
(como los extintores). En este tipo de dispositivos también debe decidirse cuántos instalar, dónde, de que tipo, etc. y su instalación debe ser efectuada por personal especializado. Además de la prevención de incendios, también se debe prevenir de otros tipos de siniestros como inundaciones, robos, terremotos, tormentas, etc. Para esto se deberá contar con el equipamiento e instalaciones especialmente adecuadas para disminuir las probabilidades de ocurrencia o disminución de las consecuencias, lógicamente de acuerdo a los recursos con que la empresa disponga y su análisis de costo/beneficio. UPS (Uninterrupted Power System) Son baterías de duración limitada, con las cuales se puede disponer de energía eléctrica en caso de corte del suministro, permitiendo continuidad y un cierre normal de los sistemas. El tamaño de la UPS depende del tiempo que desee usar, consumo de energía del equipo, etc., con esto en mente, puede llegarse a determinar la conveniencia económica y técnica de tener UPS. Otra alternativa son los equipos moto-generadores o grupos electrógenos que comienzan a funcionar una vez que la UPS se agota. Esto es necesario o más útil cuando se trata de aplicaciones críticas. El inconveniente de estos motores es principalmente la inestabilidad de energía que presentan, por lo que es necesario combinarlo con un estabilizador de voltaje. También requiere un análisis costo/beneficio, el valor de este tipo de equipos depende del consumo de energía de los equipos conectados a él. Vías de Evacuación Es necesario capacitar y entrenar a la gente sobre cuales son las vías de escape, de manera que estas sean expeditas y se llegue en el menor tiempo posible a un punto de encuentro o de seguridad, previamente definido. La ruta debe ser segura en todo el trayecto y no debe entorpecer el flujo de quienes la están usando. En el punto de encuentro se debe efectuar un proceso de revisión y conteo para determinar si están todas las personas que debieran estar. Todo lo anterior requiere de la debida y constante capacitación de las personas, tanto en cómo proceder ante un evento no deseado, como en el respectivo apoyo decisional ante la información que los dispositivos de prevención entreguen. Instalación Eléctrica Trabajar con computadores implica trabajar con electricidad. Por lo tanto es una parte importante a considerar dentro de la seguridad física, en la medida en que los sistemas se vuelven más complejos se hace más necesaria la presencia de un especialista el cual determine las condiciones de empalme de electricidad necesarias para un seguro funcionamiento de las tecnologías utilizadas.
Planificación, Desarrollo y Control de Proyectos
Página 49 de 86
De manera de facilitar la selección de un gabinete (hardware), se han establecido algunas clasificaciones de índices de protección por parte de la "National Electrical Manufacturers Association" (NEMA). Estos índices identifican la habilidad del gabinete para proveer un grado de protección del equipamiento contenido en su interior de los elementos ambientales tales como suciedad, polvo, agua y otros agentes corrosivos. Estos índices, sin embargo, sólo tienen la intención de ser utilizados como una guía. Para asegurar una elección apropiada, se recomienda realizar una evaluación de la aplicación y el ambiente antes de la selección del producto. Cableado Esto es una parte importante dentro de la seguridad de las redes. La realización de un buen cableado minimiza al riesgo de un corte u otro tipo de daño accidental. Los riesgos más comunes son: Interferencia: lo cual puede estar generada por cables de alimentación de maquinaria pesada o por equipos de radio o microondas. Los cables de fibra óptica no sufren el problema de alteración (de los datos que viajan a través de él) por acción de campos eléctricos, que si sufren los cables metálicos. Corte del cable: la conexión establecida se rompe, lo que impide que el flujo de datos circule por el cable. Daños en el cable: pueden dejar de preservar la integridad de los datos transmitidos lo que hace que las comunicaciones dejen de ser fiables. Sistemas de aire acondicionado. Se debe proveer de un sistema de calefacción, ventilación, purificación de aire y aire acondicionado, separado que se dedique a las salas de computadores y equipos de proceso de datos en forma exclusiva. Teniendo en cuenta que los aparatos de aire acondicionados son causa potencial de incendios e inundaciones por lo cual se debe contar con equipos de seguridad como los señalados
7.4.- Seguridad Lógica de tipo preventivo En algunos aspectos la seguridad lógica imita a la seguridad física, lo cual no siempre es conveniente. A continuación se describen algunas medidas de seguridad lógicas, que actúan en segundo nivel, es decir, después de las medidas de tipo físico: Perfiles de Accesos Implica el uso de ID y password. Existen distintos niveles de control, los cuales son:
Planificación, Desarrollo y Control de Proyectos
Página 50 de 86
Nivel 0: A nivel de Sistema Operativo. Todos los sistemas operativos lo traen, sólo hay que activarlo. Pide identificación y palabra clave Nivel 1: Se fijan privilegios, que es lo que se puede hacer. Los privilegios son: Read Only: sólo lectura, no permite la modificación de la información. Modify: permite a ciertos usuarios modificar la información y lo permitido en el privilegio anterior. Delete: facultad de ciertos usuarios para borrar información existente y lo permitido en el privilegio anterior. Create: máximo privilegio existente, crear archivos y lo permitido en el privilegio anterior. Nivel 2: Tiene relación con los menús de aplicaciones. Funciona sólo si el técnico lo activa. Hasta este nivel se maneja por el sistema operativo. Determina a qué aplicaciones tiene acceso el usuario. Nivel 3: corresponde a colocar protectores de pantalla con palabra clave que se activan en un determinado tiempo de inactividad del usuario y para volver a activar las aplicaciones se debe digitar la palabra clave correspondiente. Nivel 4: De aquí en adelante, los niveles son manejados por las aplicaciones. Existe un menú de opciones. Este se debe crear o instalar durante el diseño físico del sistema o verificarlo cuando se va a comprar el software. Cada aplicación, dependiendo de la misma y/o del usuario, puede pedir clave de acceso, como el nivel 0 anterior, pero sólo para dar acceso a la aplicación. Nivel 5: Permite definir acceso a funcionalidades dentro de la aplicación, a ciertos datos de la aplicación, etc. Y así en adelante. Nivel 6: Este nivel a diferencia de los anteriores no controla acceso, sino que corresponde a guardar el registro de los cambios hechos con los datos, para efectos de apoyar un futuro análisis en caso de problemas o anular el cambio y volver a como estaban los datos antes del cambio. Esto utiliza espacio de almacenamiento. Es necesario definir cuánta historia se va a almacenar. Nivel 7: Al igual que el nivel anterior, registra información, en este caso lo que se almacena es la identificación de quién efectuó cambios en los datos. Esto utiliza espacio de almacenamiento. Es necesario definir cuánta historia se va a almacenar.
Planificación, Desarrollo y Control de Proyectos
Página 51 de 86
Cada uno de los niveles de seguridad implica un uso de recursos de CPU, RAM, etc., que degrada los tiempos de respuesta, por lo que es necesario considerar este factor al evaluar la implementación de seguridad lógica. Se debe verificar todos los niveles que la aplicación o sistema requiere. Lo básico es llegar al nivel 2, pero es necesario definir hasta que nivel implementar cuando se trabaja en e-commerce. Lo cual obliga a implementar zonas protegidas (DMZ) y definir procesos de prevención de contaminación de virus (“cuarentena”). Adicional a lo anterior existe una medida de seguridad complementaria, consiste en el control de inactividad del usuario (time-out), es decir, transcurrido un determinado período de tiempo en que el usuario no ha efectuado actividad en el equipo, el sistema lo desconecta, exigiendo una reconexión, como al inicio de la conexión perdida. Administración de Password La administración de password o claves, comprende una serie de acciones tanto de construcción de las mismas, como también del control de éstas, de manera de imposibilitar el acceso al sistema, de personas no autorizadas. Por lo general, no se puede normar la construcción de una password, dado que sería muy fácil descubrirla, sólo se puede decir que se utilice la mayor cantidad de caracteres posibles, mezclando caracteres de letras (mayúsculas y minúsculas), números y signos. No usar algo fácil de adivinar (nombre propio, fecha de nacimiento, etc.), para lo cual existen como apoyo algunos mecanismos que permiten generar claves aleatorias, que son más seguras. También pueden existir frases de paso (privadas), que funcionan en caso de olvido de la clave. Se debe controlar la forma de distribución de claves, para evitar que sean interceptadas. Debe cuidarse los medios en que se almacenan las claves, ya sean en papel, algún medio magnético, etc. Se debe cambiar periódicamente (el tiempo de vida de las claves no debe ser indefinida), de acuerdo a los privilegios que tenga el usuario, ya que con períodos largos de vida, se hace más probable la captura o el descubrimiento de la clave. Es muy importante que las password sean memorizadas por el usuario, pues estando escritas en algún lugar siempre está la posibilidad de ser encontradas, de ser descubierta de este modo no sirve de nada que la clave sea de números aleatorios o alfanumérica y mixta. Al acceder a los sistemas, se debe permitir un máximo de intentos fallidos de digitar la clave o password, una vez cumplidos dichos intentos se debe bloquear el acceso y avisar de esta anomalía. Por último, también se debe tener un historial de password para no repetirlas y fijar procedimientos para la destrucción de claves. Para los accesos remotos, se crean los Calling Back. Esto se hace entregando al usuario que viaja, un dispositivo de password creadas, mientras que el usuario debe entregar un listado de todos los teléfonos en donde se le puede contactar. El dispositivo va entregando una password cada vez que el usuario necesite conectarse, sólo tiene que llamar a la empresa solicitando contactarse y el software establecerá el contacto llamando de vuelta. Planificación, Desarrollo y Control de Proyectos
Página 52 de 86
Adicionalmente existe otro mecanismo para el acceso remoto, muy usado para no tener tanta dependencia de un lugar físico, como en el caso anterior. Este mecanismo se denomina password de una vida y consiste en que la persona que viaja lleva consigo un dispositivo que al activarlo genera una password, coordinado con el equipo al cual se va a conectar para que genere la misa clave y permita el acceso, esta clave sirve para conectarse una sola vez, si la persona se desconecta, al reconectarse debe recurrir nuevamente al dispositivo para que le genere una nueva password. El dispositivo indicado de denomina “token” y puede ser de uso manual o ser conectado a alguna entrada del PC con el cual se desea establecer comunicación. Existe token estático y token dinámico. Sincronización de password Consiste en permitir que un usuario acceda con la misma password a diferentes sistemas interrelacionados y su actualización automática en cada de uno de ellos en caso de ser modificada. Caducidad y control: Este mecanismo controla cuando pueden y/o deben cambiar sus passwords los usuarios. Se define un período mínimo que debe pasar para que los usuarios puedan cambiar sus pasword y un período máximo para que estas caduquen. Adicionalmente es posible controlar que la nueva password no sea igual a cualquiera de las “x” anteriormente usadas. Encriptación Algoritmo usado para cifrar datos de forma tal que al ser enviados, si éstos son interceptados, sean indescifrables para cualquier otra persona que no sea el destinatario, que es quien tiene el mismo algoritmo para descifrar el mensaje. La encriptación puede ser variable o dinámica. La encriptación complementa a otras medidas de seguridad. El principio de la encriptación es impedir el descifrado del dato (excepto si se posee el algoritmo de encriptación), no obstante con las nuevas técnicas de análisis de encriptación efectuadas por medio de software, lo anterior no es posible, luego lo que se persigue al encriptar es buscar un algoritmo y combinación de posibilidades lo más alta posible, de forma tal que su descifrado demande mucho tiempo (años), aún usando software de apoyo. Las reglas anteriores pueden mezclarse para lograr un máximo de seguridad. Respaldos Significa tener una copia a la cual se puede recurrir si la información principal se ha dañado o no pueda usarse. Existen: Respaldo de personas: es realizar capacitación a las personas para que puedan realizar reemplazos de otras personas que por ciertas
Planificación, Desarrollo y Control de Proyectos
Página 53 de 86
circunstancias faltan. Esto se denomina Cross Posting. El respaldo de personas es un muy buen apoyo para dar continuidad a los procesos. Respaldos de software y datos históricos: se guardan datos históricos y por lo general también los software que leen dichos datos. También se debe ir adecuando los datos cada vez que se cambian los software. La periodicidad de los respaldos depende de la dinámica de actualización de lo que se desea respaldar, la cantidad de copias de respaldo depende de la importancia de lo que se respalda. El número mínimo de copias es 2 que deben estar separadas físicamente. A mayor cantidad de copias, mayor complejidad logística. Un respaldo que apoye funciones contables no puede ser destruido antes de cinco años, su eventual destrucción debe ser autorizada por las entidades regulatorias correspondientes (SII, etc.). Respaldos de software y datos de continuidad: apuntan a dar un servicio continuo, es decir, recuperar datos y/o software que un usuario haya perdido. La periodicidad es diaria y normalmente la cantidad de copias es 2. Normalmente se respalda diariamente los datos y/o software que ha sido modificado en el transcurso de tiempo que va desde el último respaldo efectuado, hasta el respaldo en proceso, una vez por semana se respalda todo. La decisión aquí es: Cuánto tiempo guardar el respaldo lo cual, en parte, va a depender de la importancia de la información y del costo de guardar los respaldos. Respaldos de hardware: en caso de que falle un servidor, se debe tratar de no afectar la continuidad, por lo que se puede reemplazar RAM, CPU, etc. Una opción es un disco nuevo y ocupar los respaldos de datos y software. Otra es colocar el disco de respaldo más actualizado si se tiene alguna copia, y aunque se recupere rápidamente la información, la del día se perderá. También se podría tener un servidor de respaldo. Para los IVRS es necesario tener un respaldo, ya que estos equipos no pueden fallar. Respaldo de Discos Magnéticos: se tiene técnicas de almacenamiento como Hot repair, Mirroning, RAID, SAN. Equipos de comunicación y otros: se refieren “códigos de barras, lector de tarjetas”, etc. Lo ideal es tener otro equipo o sobredimensionar los equipos para darle continuidad al servicio. Respaldo de documentación: para los documentos, es necesario tener al menos una copia de la información, mientras más importante sea la información, mayor cantidad de copias.
Audit-trail Al efectuar un proceso de auditoría tecnológica surge, entre otras, la siguiente duda: efectuar dicho proceso con un auditor con conocimientos en computación o un informático con conocimientos en auditoria, la otra opción es crear un equipo multidisciplinario, formado por un auditor que se apoya en expertos en diferentes áreas computacionales (SW, HW, Comunicaciones, etc.), el auditor es sólo un
Planificación, Desarrollo y Control de Proyectos
Página 54 de 86
experto en control, pero ésta alternativa es muy costosa e impracticable en empresas pequeñas, una tercera respuesta a dicha duda es el audit-trail. El audit-trail es una herramienta de apoyo al auditor que disminuye la necesidad de que el auditor sea experto en tecnología, pero es aplicable solamente a SW. Consiste en que el auditor en la etapa de diseño del SW, juega el papel de usuario, lo cual no le impide que después haga auditorías al SW, dicho auditor va a incorporar sus requerimientos, como usuario, al SW. Todos los requerimientos (controles) que el auditor, como usuario, incorpora al software, se denominan audit-trail, y su objetivo es el control de lo que el software está haciendo, el audit-trail sirve sólo para el SW en que está incorporado, pero el concepto se puede aplicar a cualquier SW. Hay que analizar la información que se entrega, más el riesgo asociado V/S el tiempo de respuesta, ya que a más audittrail se entorpece el tiempo de respuesta. Luego no es necesario que todos los sistemas o aplicaciones tengan incorporados audit. Trails, adicionalmente la cantidad de audit trail a incorporar variará de un sistema a otro. Sólo los auditores pueden tener acceso a los datos que los audit trail entreguen una vez que el sistema o aplicación está en producción, al analizar dichos datos ejerce su papel como auditor, controlando la funcionalidad y resultados del SW, analiza si se deben hacer cambios o no. El SW que tiene audit trail debe tener la aprobación tanto del usuario, como la del auditor, una vez que se obtenga esto se puede pasar a producción, si el SW no tiene audit-trail, no requiere la aprobación del auditor, basta sólo con la del usuario. Como el auditor controla la funcionalidad del SW, él decide sobre la necesidad de efectuar cambios, durante las mantenciones el auditor asume un papel de usuario. Los requerimientos del usuario pueden ser erróneos o incompletos, así como también los del auditor como usuario, por lo que después igual es necesario que se haga mantenciones tanto al software en sí como a los audit trails que tenga incorporados o que haya que incorporarle. Firewalls Controla accesos a SW y HW. El firewall actúa como filtro, determina si el mensaje entra o sale de la barrera que él maneja, complementa al antivirus que detecta si llegó un virus en los mensajes recibidos, ahora bien, un mismo equipo puede cumplir ambas funciones . Para efectos de protección de ataques, el firewall debe programarse, esto lo puede hacer el usuario, el proveedor del firewall o contratar el servicio de expertos (Ej. Hackers) que ayudan a determinar el nivel de protección contra ataques.
Planificación, Desarrollo y Control de Proyectos
Página 55 de 86
De esta forma el firewalls se transforma en un medio de protección y seguridad para ataques, tanto internos como los externos, algunos medios por donde se pueden producir estos ataques son Internet, Intranet, extranet, etc. Existe además el filtro antivirus y el filtro antispam.
7.5.- Plan de contingencia (DRP, Disaster Recovery Planning, Data Recovery Planning) Existe el BRP (Business Recovery Planning), que corresponde al plan de recuperación del negocio, el DRP es un subconjunto del BRP. Lo ideal es que una emergencia nunca ocurra, pero es necesario tener un DRP ante la probabilidad de que la emergencia ocurra dado que la prevención no fue suficiente para prevenirla. El DRP consta de dos planes: Plan de emergencia Especifica que hacer ante una emergencia en materia de TICAR, que acciones a seguir ante un imprevisto. Este plan debe especificar qué hacer ante incendios, bombas, inundación, terremoto, se debe acotar de acuerdo a la probabilidad de ocurrencia. Asociado a este plan debe existir un equipo de emergencia claramente definidos en número y rol a jugar durante la emergencia, para la elección de las personas de este equipo, tiene que predominar el perfil psicológico, no el rol que tenga dentro de la empresa. Durante la emergencia la autoridad es el jefe del equipo de emergencia y a él se le debe hacer caso si ocurre un imprevisto, las instrucciones deben ser claras y apuntar a salvar a las personas como primera prioridad, después los bienes. La cantidad de personas de este equipo debe ser la menor posible. Las funciones a cubrir deben de ser las básicas, se busca aminorar el impacto de la emergencia en las personas y resguardar SWs y HWs críticos. El plan de emergencia debe reducir al mínimo el tiempo que el proyecto está sin prestar determinados servicios, debido a la emergencia ocurrida. Para efectos de contar con equipo de TICAR, existen las siguientes opciones: El Convenio mutuo, es una modalidad donde una empresa ocupa los equipos de otra en el caso de encontrarse en contingencia, o viceversa, se debe considerar que no sean competidoras, que tengan las mismas versiones de HW y SW básicos y que no estén en el mismo lugar físico. En la práctica el convenio mutuo no funciona porque tiene muchas complicaciones.
Planificación, Desarrollo y Control de Proyectos
Página 56 de 86
Convenio de servicios con terceros, los terceros son empresas que dan servicio de equipos a usar en caso de contingencia, a cambio de una prima mensual que da el derecho a usar dichos equipos, cuando se está en contingencia se paga por días de uso, con el objetivo que la empresa se recupere de la contingencia lo antes posible, lo cual hace esta alternativa más cara que el convenio mutuo, es ideal en tipo BATCH. Site propio, la empresa instala un equipo secundario el que se usa en caso de emergencia en el equipo principal, como es de propiedad de la empresa se es más autónomo, es la alternativa más cara, pero más efectiva y crea menos problemas, es recomendable cuando hay aplicaciones en línea. En contingencia, la unidad de informática debe tratar de que las aplicaciones críticas funcionen, así también como todas las interfaces de una aplicación crítica a una no crítica. Durante la contingencia, está permitido trabajar sin seguridad, se corre un gran riesgo y se debe trabajar con mucho cuidado, se debe tener muy buenos respaldos. Existe dos modalidades el Hot site (configuración de respaldo conectada a la configuración principal) y el Cold site (configuración de respaldo no conectada a la configuración principal) Equipo a pedido, convenio con otra empresa a la cual se le paga una prima con el derecho a que en caso de contingencia, esta empresa arma un equipo con toda la configuración necesaria y lo lleve a la empresa cliente que sufrió la contingencia, esta alternativa todavía no se encuentra del todo operativa en Chile. En algunos casos la opción de entregar el CPD a un tercero en modalidad externalizar el servicio o en modalidad “cloud”, traspasa la necesidad de respaldar equipos al tercero (cloud público), existe además la opción de cloud privado y la opción de cloud híbrido (mezcla de las dos opciones previas). Cuidado al contratar un servicio fuera del país, pues ello puede implicar el pago de impuestos por contratación en el extranjero. Para poder enfrentar una contingencia, se requiere una muy buena documentación de sistemas y buena preparación del personal y respaldos, el objetivo es volver lo más pronto posible a la normalidad. Plan de recuperación o vuelta a la normalidad Comienza cuando la empresa determina que está habilitada para volver a funcionar normalmente, Por lo general demora de tres a cuatro veces lo que demora el plan de emergencia, lo demoroso es poner al día, con apoyo de TICAR, las aplicaciones no críticas, puesto que es muy complejo y lento y debe ser hecho con la máxima rigurosidad. Requiere mucho respaldo de documentos y apoyo de auditoría. Este plan termina cuando se alcanza un cierre normal con apoyo de TICAR tanto de las aplicaciones críticas como las no críticas. El equipo que se debe adquirir es el que mejor se adecue a las aplicaciones que se están utilizando. Planificación, Desarrollo y Control de Proyectos
Página 57 de 86
Este plan puede simplificarse y reducirse en tiempo si la institución define que todas las aplicaciones son críticas, evitando la complejidad logística y tecnológica que implica la separación entre aplicaciones críticas y no críticas. Esto tiene un mayor costo que la empresa debe evaluar. Plan de continuidad del negocio (BCP) Su objetivo es que el negocio nunca se interrumpa y tampoco el apoyo informático al negocio, esto implica que se invierte para ello, se apoya en los planes de contingencia (BRP, DRP). Otra opción a considerar es el DRaaS (Disaster Recovery as a Service). Adicionalmente existen herramientas de software de apoyo a un plan de recuperación de desastre por ejemplo: Veeam Backup, Altaro VM Backup, Zerto Virtual Replication, VMware’s Site Recovery Manager (SRM), por nombrar algunos. En resumen la gestión de los debería responder al siguiente esquema:
7.6.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al gestionar la seguridad de un proyecto/producto?. ¿Qué cuidados se deben tener al gestionar los riesgos de un proyecto/producto? En mi actividad actual: ¿Cuál puede ser mi aporte en este tema?
Planificación, Desarrollo y Control de Proyectos
Página 58 de 86
8.- Gestión de la Calidad en TICAR “Todos somos aficionados. La vida es tan corta que no da para más”. Charles Chaplin. Tanto la gestión de la calidad del proyecto como la del producto, requieren una dedicación similar y, además, ser consideradas con similar importancia que la gestión financiera y/o de personas. Especificar si se usará alguna metodología de control de calidad. Hay modelos que permiten manejar calidad continua como el Capability Maturity Model (CMM), Beta test, Caja blanca, caja negra, etc. Todas estas pruebas están destinadas a garantizar estándares mínimos de calidad, para el proyecto y para el producto, y ganar confianza ante los usuarios, pero ni siquiera la certificación ISO9000 garantiza que el producto y/o el proyecto esté libre de riesgos. Al implementar certificaciones de calidad lo que se logra es la herramienta para lograr dicho nivel de calidad, el paso siguiente es utilizar dicha herramienta en el proyecto, diariamente. Separar el concepto e idea de: Proyecto correcto, es el que se requiere Proyecto exitoso que es el al final cumple las variables planificadas de plazo, costo, calidad y alcance. Puede buscarse apoyo en la PMO (Project Management Office), si es que ella existe dentro de la organización. Implementar una PMO es un proyecto en sí, se verá mas adelante. La gestión de la calidad aplicada al producto final (referida a satisfacer los requerimientos del usuario), es tan importante como la gestión de la calidad del proyecto, es decir, aplicada a procedimientos de trabajo, excelencia organizacional, entre otros aspectos, que ayuda a reducir o eliminar costos innecesarios. Normalmente se cuestiona la gestión de la calidad bajo el argumento de que sube los costos del proyecto y/o entorpece la entrega a tiempo del producto, contra ello puede argumentarse que el costo de la no calidad es mucho más alto. Desde el punto de vista del proyecto es conveniente: Planificar la calidad Asegurar la calidad Controlar la calidad, en este caso es mejor buscar la excelencia, en vez de mejorar la inspección.
Planificación, Desarrollo y Control de Proyectos
Página 59 de 86
Mejorar la calidad, trae beneficios como: disminuyen los costos al haber menos reprocesos, menos errores, menos demoras y obstáculos, mejor utilización del tiempo y de los recursos disponibles y mejor clima laboral dentro del equipo del proyecto. Lo antes expuesto trae como consecuencia mejorar la productividad: El producto logra capturar más clientes, al existir mejor calidad y costos más bajos, tiene más permanencia. El proyecto es más atractivo, al ser más rentable, por incurrir en menores costos, lo cual puede conducir a que se evalúen más proyectos, y ello puede llevar a que haya más trabajo. Para lograr lo antes mencionado, se sugiere: Describir los procedimientos, es decir, “diga lo que hace” Cumpla sus procedimientos, es decir, “haga lo que dice” Utilice registros e/o indicadores, es decir, “demuéstrelo” Es conveniente identificar los: Proyectos correctos: Orientados a las estrategias y objetivos de la organización. Proyectos exitosos: Cumplen con los SLA planificados La observancia de la calidad, tanto del proyecto como del producto, en gran parte va a responder a las normativas y políticas institucionales al respecto; observancia que debe ser extendida en carácter de obligatoria a los proveedores y/o contratistas que participan en el proyecto. Adicionalmente ya está instalada en varios lugares la observancia y cumplimiento de las normativas de calidad asociadas a temas ambientales, válidas para el producto y para el proyecto, aglutinadas en lo que se denomina Green IT.
8.1.- Análisis Impacto al Medio Ambiente o Green IT En este caso, Green IT, se evalúa el impacto ambiental del: Proyecto (recursos humanos (directos e indirectos) y/o técnicos, logística, infraestructura requerida y los residuos generados) y Producto del proyecto (al implementarlo, en todos los aspectos requeridos para ser operable). A partir de lo antes indicado, es posible realizar la identificación de impactos, la que se complementa una vez conocidas las características del área de influencia (AI).
Planificación, Desarrollo y Control de Proyectos
Página 60 de 86
Para establecer si los impactos identificados son o no significativos, se requiere realizar una estimación del impacto, ya sea cualitativa y/o cuantitativamente dependiendo del elemento del medio ambiente y la información disponible. A la identificación y estimación de impactos se le denomina predicción de impactos. La significancia de todos los impactos identificados se establece en función de criterios establecidos en la Ley N° 19.300 (y modificaciones posteriores), el Reglamento del SEIA y en guías específicas, etapa identificada como evaluación de impacto. Los proyectos deben presentar las medidas de mitigación, reparación o compensación apropiadas para hacerse cargo de los efectos, características o circunstancias establecidos en el marco legal vigente (el artículo 11 de la Ley N° 19.300 y modificaciones posteriores), que generan o presentan. Tales medidas se definen de la siguiente manera: Medidas de mitigación, tienen por finalidad evitar o disminuir los efectos adversos del proyecto o actividad, cualquiera sea su fase de ejecución, y abarcan: o Las que impidan o eviten completamente el efecto adverso significativo, mediante la no ejecución de una obra o acción, o de alguna de sus partes. o Las que minimizan o disminuyen el efecto adverso significativo, mediante una adecuada limitación o reducción de la extensión, magnitud o duración de la obra o acción, o de alguna de sus partes. o Las que minimizan o disminuyen el efecto adverso significativo mediante medidas tecnológicas o de gestión consideradas en el diseño. Medidas de reparación, tienen por finalidad reponer uno o más de los componentes o elementos del medio ambiente a una calidad similar a la que tenían con anterioridad al impacto obre dicho componente o elemento o, en caso de no ser ello posible, restablecer sus propiedades básicas. Medidas de compensación, tienen por finalidad producir o generar un efecto positivo alternativo y equivalente a un efecto adverso identificado, que no sea posible mitigar o reparar. Cada una de las acciones tomadas en respuesta a estas medidas tiene costo y debe evaluarse, dicha evaluación se debe incorporar a la evaluación del proyecto.
8.2.- PMO Consideraciones a tener en cuenta al desarrollar un proyecto para implementar una PMO: Implementarla es un proyecto
Planificación, Desarrollo y Control de Proyectos
Página 61 de 86
La PMO no es un comité Conviene que el(a) encargado(a) no sea técnico. Mas que por jerarquía, actúa mejor por “redarquía”. Entregarle atribuciones, autoridad y recursos 6 a 12 meses para implementarse y 12 a 24 meses para mostrar resultados. Se puede partir por una PMO externa y después internalizarla (persona a media jornada) puede ser gradualmente. Precisar métricas que usará en los proyectos Tareas o funciones mas típicas de una PMO: Financiera: Colaboración con vinculación con el caso de negocio y disposiciones financieras dentro del contrato. Contractual: Apoyo en definición de obligaciones y SLA y posterior monitoreo. Proceso: Gestión de la demanda y priorización de proyectos, gestión de solicitudes de incidentes/problemas. Personas: apoyo en programas de inducción, monitoreo de puntos de interacción entre el cliente y proveedor y de niveles de desgaste. Organización: Dimensionamiento, metodología y métricas para evaluar recursos. Métricas: Relevancia de las SLA, incentivos. Gestión de orígenes: Prioridades para mejorar el rendimiento operativo y la calidad
8.3.- Definición de informes (documentación) No obstante que la percepción que se tiene de la documentación, es que es un componente que entraba la velocidad de desarrollo y de creatividad dentro de un proyecto, es necesario contar con ella al igual que las normativas y políticas que regulen el desarrollo del proyecto y del producto resultante. Se debe precisar los siguientes tipos de documentación: Del producto resultante Del desarrollo del proyecto Dicha documentación puede ser efectuada manualmente con apoyo tecnológico, o puede ser efectuada por software diseñado para ello. A nivel de seguridad de prevención es conveniente tener varias copias la documentación y documentar todo, pues nunca se sabe cuándo y qué se puede requerir. Incluir dentro del equipo de trabajo un integrante para esta función, que puede ser de una especialidad que no sea técnica, por ejemplo: humanista, un periodista.
Planificación, Desarrollo y Control de Proyectos
Página 62 de 86
Pueden existir normas y/o políticas de documentación, además de una gestión documental que puede ser apoyada por software. Dado que una de las características del chileno es que no lee, entonces pareciera ser que en vez de hacer manuales escritos es mas conveniente que la documentación del producto sea un video y ojalá en formato del tipo reality show. Durante el tiempo, la acumulación de datos se incrementa y dicha acumulación en ocasiones es de cada vez menos importancia en el tiempo. Ello obliga, desde el punto de vista de la calidad, a analizar la real validez de los datos acumulados en el tiempo, pues lo mas probable es que ocurra lo siguiente: Los datos no válidos, porque están duplicados, pueden regenerarse, no se sabe para qué están y/o ni porqué se guardan, pueden llegar a ser el 65%. Los datos válidos no sean más del 35% del total de datos. Ello obliga a analizar y evaluar cuantos datos considerar como parte del producto a implementar para dimensionar necesidades de almacenamiento y respaldo. Diferente es el análisis desde el punto de vista de las necesidades de datos de proyectos cuyo producto esté asociado o derivado a Inteligencia Artificial y/o proceso masivo de datos (big data).
8.4.- Nivel de criticidad del producto Normalmente en el tiempo en las organizaciones se van acumulando datos que no siempre son necesarios de acumular por lo que el indicador de impacto en el negocio se va reduciendo. De hecho en investigaciones que se han efectuado fuera de Chile, se ha logrado concluir que la cantidad de: Datos No válidos, porque están duplicados y/o pueden regenerarse y/o no se sabe para qué están y/o ni porqué se guardan, representan el 65% de los datos Datos Válidos, representan el 35% de los datos Lo anterior crea un serio problema al momento de evaluar y/o gestionar los recursos dedicados a respaldo de datos. Entonces se plantea el siguiente dilema: ¿Qué datos guardar y qué datos borrar?. Para ayudar a resolver este dilema, es necesario tener consideración en los datos a analizar, lo antes mencionado y agregar: Determinar el Valor del dato: Económico
Planificación, Desarrollo y Control de Proyectos
Página 63 de 86
De uso De pérdida Especificar la Visibilidad de los datos, en términos de: Qué hay Qué se tiene Qué se requiere Con lo anterior se determina Acción a ejecutar en cada dato, esto es precisar, los mecanismos de acceso y retención a dicho dato y los mecanismos de protección. El entorno que ayuda y/o define lo antes indicado está precisado por el Control y Validación de cada dato, definido por las reglas a cumplir (legales, normativas y/o políticas) y por el criterio de proteger a la organización de posibles conflictos y/o ataques, internos o externos. El nivel de criticidad del producto condiciona el análisis asociado a: MTTR (Mean Time To Repair), tiempo medio en reparar o recuperar un falla, el cual debe ser el mínimo posible. MTBF (Mean Time Between Failure), tiempo medio entre fallas, el cual debe ser el máximo posible, lo cual garantiza que la probabilidad de falla es mínima. Al producto generado por el proyecto es conveniente clasificarlo según su grado de criticidad, para su tratamiento posterior en la etapa de operación del mismo, para ello puede utilizarse la matriz de McFarland:
Planificación, Desarrollo y Control de Proyectos
Página 64 de 86
El producto debe ser ubicado en uno de los cuatro cuadrantes indicados.
8.5.- Importancia v/s urgencia Para la toma de decisiones del proyecto, en base a criterios de urgencia e importancia, se puede utilizar la matriz de Eisenhower: (a continuación)
URGENCIA Urgente
I M P O R T A N C I A
No urgente
I M P O R T A N T E
I
Tareas que deberíamos realizar inmediatamente y con posible asesoramiento. ACTUAR
II
Crisis Problemas apremiantes Presiones Proyecto con fecha de vencimiento
Nuevas oportunidades Planificación futura Actividades preventivas Crecimiento Personal
Cuadrante surgido por POSTERGAR o NO planificar adecuadamente
Cuadrante de la CALIDAD aumenta nuestra capacidad para ejecutar
No
III
Tareas que debemos delegar con monitoreo. DELEGAR
IV
Interrupciones Llamadas, email, algunas reuniones Algunos informes Organizar viajes
Detalles Algunos mails y/o llamadas Trivialidades Ajetreo inútil
I M P O R T A N T E
Tareas que nunca se deben delegar. PLANIFICAR
Tareas que debieramos delegar por completo. POSPONER
Cuadrante para satisfacer prioridades y Cuadrante de la PERDIDA de expectativas de los demás Tiempo
La tarea de poder discernir entre lo importante y lo urgente, obliga a ser ordenado, organizado y metódico, pues de lo contrario lo más probable es que se llegue a una situación de constante crisis, que obliga a estar en permanente estado de emergencia, lo cual es muy agotador y genera stress, es el típico perfil que se denomina Bombero, pues su gestión es estar constantemente “apagando incendios”. Adicionalmente esta labor de discernimiento obliga a vencer la procrastinación, presente en toda persona. Planificación, Desarrollo y Control de Proyectos
Página 65 de 86
8.6.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al gestionar la calidad de un proyecto/producto?. ¿Qué cuidados se deben tener al gestionar una PMO? ¿Herramienta a usar para definir nivel de criticidad? ¿Herramienta a para el dilema urgente v/s importante? En mi actual actividad: ¿En qué voy a aportar en los temas de calidad antes mencionados?
Planificación, Desarrollo y Control de Proyectos
Página 66 de 86
9.- Gestión de la Ética en TICAR “Algunas personas quieren que algo ocurra, otras sueñan con lo que pasará, otras hacen que suceda”. Michael Jordan. Trate de pertenecer al último grupo de personas.
A la potencia de la tecnología, a la dependencia de la misma, la importancia de los proyectos en tecnología, el volumen de proyectos, los montos involucrados en ellos, en consecuencia a lo vital que es la gente de TICAR en la empresa, se le agrega el enorme valor que tienen los datos que administra la unidad de TICAR de la organización. En la actualidad el valor de un equipo tecnológico no es su valor en sí, sino que los datos que almacena o a los que puede permitir acceso. Entonces el valor de los datos que la tecnología almacena o permite acceso es de alto monto, luego quienes pueden o saben acceder a dichos datos, por conocer la tecnología o los accesos a los mismos, tienen mucho poder por sobre quienes no están capacitados para ello; esto obliga a los primeros a actuar con mucha ética respecto de los datos a los cuales tienen acceso. Adicionalmente a lo anterior está el hecho de que las personas entregan sus datos en la confianza de que éstos no serán divulgados sin su consentimiento explícito, la cual también requiere de un tratamiento y comportamiento ético de quienes tienen acceso a dichos datos. Lo anterior, entonces crea un escenario que requiere y demanda una fuerte componente ética de parte de quienes actúan dentro de las TICAR, este problema ético se acentúa al momento que el acceso a la tecnología, junto con dar ventajas competitivas, provoca, también, importantes problemas de poder. En la actualidad existe ética: 1.- Empresarial, que requiere de una cultura ética al interior de la organización, la que proporciona un marco de referencia ético, normalmente la imagen o percepción ética de la organización se la dan sus ejecutivos de alto nivel, quienes a su vez deben velar porque la organización completa se empape de este código de ética. Esto se logra mediante la implementación de: 1.1.- Preceptos corporativos, que, haciendo un paralelo con la religión católica, son como los diez mandamientos 1.2.- Programas de ética, que, haciendo un paralelo con la religión católica, son como los servicios religiosos 1.3.- Códigos corporativos, que, continuando con el paralelo con la religión católica, son como la Biblia. 2.- Profesional, que requiere de un código de ética de las sociedades de profesionales. En la actualidad existen diversos códigos de ética a nivel de TICAR, entre los cuales se destacan: Código de Conducta Profesional de
Planificación, Desarrollo y Control de Proyectos
Página 67 de 86
la ACM, Código de Ética de la DPMA, Código de Ética de la ICCP, Código de Ética de la ITA, Código de Ética de ISACA. 3.- Personal, que se apoya en los valores de cada persona y lo anterior da el marco de referencia. Normalmente es la que prima al momento de decidir, por eso requiere estar presente, formada, creada y ser muy sólida. La ética no se puede regular. Además hay que distinguir los diferentes tipos de comportamiento: Moral, corresponde a las reglas de conducta que la sociedad espera que una persona siga, requieren de madurez física y mental (Ej.: siempre dar las gracias). No todas las sociedades tienen el mismo conjunto de reglas morales. Etico, corresponde a una serie de creencias, normas e/o ideales que guían y/o dominan en un individuo o una comunidad. Todos los individuos deben dar cuenta de su conducta a su comunidad. A diferencia de la moral, la ética puede variar considerablemente de una comunidad a otra. (Ej.: software pirata, compartir software en un país como Chile está penado, sin embargo hay un proverbio chino que dice: “El que comparte será recompensado y el que no comparte será condenado”). Además la ética puede ser interpretada por cada uno de los miembros de la misma comunidad. Apegado a la ley, corresponde a las reglas de conducta formales que una autoridad soberana impone a sus súbditos o ciudadanos. En este aspecto hay que reconocer que, pese a los avances legales existentes, el marco legal para la tecnología en general y para la TICAR en particular, está aún atrasado respecto del avance de la misma. El marco legal normalmente está escrito y nace después de un acto de dudosa legalidad, que obliga a normar. En base a lo anterior, se espera que las personas tengan un comportamiento profesional y social que debe ser moralmente correcto, ético y obedecer la ley. Basado en todo lo anterior, se puede concluir que es posible desarrollar tecnología que se comporte de manera ética o no ética, mas aún la tecnología permite violar derechos de las personas. Adicionalmente a que la TICAR permite actuar en forma no ética, está, por otro lado, el hecho de que la TICAR permite apoyar la detección de acciones no éticas. Al negociar un contrato con un tercero, que es ético: ¿velar por un contrato equitativo y justo o defender el mínimo valor a contratar?. O al estar negociando con personas que hablan otro idioma y no entienden el nuestro, ¿es ético que durante la negociación cada parte, hable en su idioma delante de los demás que no Planificación, Desarrollo y Control de Proyectos
Página 68 de 86
entienden lo que hablan entre ellos?. Otro caso de contrato, ¿es ético que alguno de los ofertantes efectúe lobby de su empresa durante el proceso de entrega de ofertas, antes de la adjudicación? Normalmente en TICAR ocurre que el desarrollo o habilitación de una TICAR, puede producir un daño en otro(s) aspecto(s), ¿es ético desarrollar dicha tecnología?. La ética es muy complejo de enseñar, se puede mostrar o dar el ejemplo, para apoyar el razonamiento, ello se inicia construyendo confianzas y para construir confianzas se requiere: Capacidad (estar capacitado(a)) o Demostrarla Benevolencia (desear el bien) o Ejercitarla Integridad (credibilidad) o Vivirla Todo lo anterior debe ser con hechos y obliga a tener: Coraje Tenacidad Y se logra a largo de varios años de ético comportamiento. No hacer el mal es distinto a hacer el bien. Es más fácil mirar para el lado o racionalizar lo malo. Cuidado, para que no ocurra: Comprensión, transformarla en Complicidad Afecto, transformarlo en Egoísmo Existe visión ética del: Usuario, Cliente, Sponsor, Proveedor, Pares, Subalternos Líder del proyecto. Para que exista una falta de ética debe existir: Justificación y/u Oportunidad y/o Presión. Planificación, Desarrollo y Control de Proyectos
Página 69 de 86
Estar constantemente analizando la situación de riesgo o de debilidad de las personas que aumenten su vulnerabilidad de cometer acciones no éticas, por ejemplo: su nivel de endeudamiento, sus necesidades económicas por enfermedad propia o de pariente, malos negocios, etc. y estudiar posibilidad de ayuda o apoyo para reducir la tentación de cometer acciones no éticas cuya recompensa se vislumbra como la solución al problema que aqueja a la persona. Asimismo estudiar con cierta periodicidad otras variables que ponen barreras a las acciones no éticas, como por ejemplo: mejorar clima laboral, aumentar grado de compromiso, perfeccionar la lealtad, etc. La tecnología permite la globalización, lo cual implica desplazamiento de personas desde un lugar del mundo a otro lugar, además en el mundo hay distintas sociedades con distintos conjuntos de reglas morales, eso obliga a las personas a tener que conocer dicha moralidad y adecuarse a ella. Dado que la velocidad de avance y de cambios de la tecnología es muy rápida, es posible pronosticar que el marco legal asociado a la tecnología siempre va a quedar atrás, dado que su velocidad de adaptación es más lenta, con lo cual a futuro será primordial un comportamiento moral y ético en las actividades de tecnología. Las decisiones éticas requieren ponderar el bien que se produce y el mal que resulta imposible evitar, una posible recomendación es seguir los siguientes pasos: Considerar la La motivación que se tiene para realizar una determinada acción. intención Desde el punto de vista ético, la intención es el acto de la voluntad y de la razón que ordena las cosas hacia un fin. La intención constituye el aspecto formal de un acto moral. Calificar el A) El principio ético fundamental es: “la primacía de la persona acto mismo y en virtud de su dignidad y libertad”. Cada ser humano es un fin recordar dos en si mismo que está llamado a desarrollar todas sus capacidades puntos clave en todos los ámbitos en los que se desenvuelve su vida. El ser humano no puede ser empleado como un medio para cualquier fin, por muy noble que éste sea. B) “El fin no justifica los medios”. No basta que la intención sea buena, la acción o acciones a efectuar para la consecución del objetivo también han de serlo. Examinar las Estas pueden agravar o disminuir la bondad o la malicia moral circunstancias de los actos humanos, lo mismo que atenuar o aumentar la responsabilidad del que obra. En todo caso, las circunstancias no pueden hacer ni buena ni justa una acción que en si es mala. Hacer una En la práctica, muchas decisiones bien intencionadas y sin evaluación reparos éticos, podrían tener efectos negativos sobre otros. final ¿Cómo saber si dicho efecto no empaña la bondad del acto y puedo quedarme tranquilo?, ¿Hasta dónde tolerar el mal?, Planificación, Desarrollo y Control de Proyectos
Página 70 de 86
¿Cómo mitigar el efecto negativo de nuestras decisiones? Es parte de la responsabilidad hacer el mejor esfuerzo para ayudar a las personas que se vean perjudicadas por la decisión, para que puedan enfrentar su nueva situación de la mejor forma posible.
Hay tres preguntas que pueden ayudar a decidir éticamente: ¿Me importaría que esto saliera publicado en la primera página del periódico de mañana? ¿Puedo explicarles mi conducta a mis hijos sin complicaciones? ¿Si me contarán que esto lo ha hecho un tercero, que opinión me formaría de él(ella)?. Los autores Parker, Swope y Baker recopilaron una lista de preguntas que ayudan a determinar si una actividad es ética. 1.- ¿Es honorable? ¿Hay alguien que Usted no quisiera que se enterara de la acción? 2.- ¿Es honesto? ¿Viola cualquier convenio, explícito o implícito o traiciona la confianza de alguien? 3.- ¿Evita la posibilidad de un conflicto de interés? ¿Hay otras consideraciones que pudieran predisponer su juicio? 4.- ¿Está dentro de su área de competencia? ¿Es posible que su mejor esfuerzo no sea suficiente? 5.- ¿Es justo? ¿Redundará en detrimento de los intereses legítimos de otros? 6.- ¿Es considerado? ¿Violará la confidencialidad o la intimidad o perjudicará de alguna u otra manera a alguien o a algo? 7.- ¿Es conservativo? ¿Desperdicia innecesariamente tiempo u otros recursos valiosos? Para que la acción sea ética, la respuesta a cada pregunta debe ser SI y para cada aclaración que sigue a cada pregunta, la respuesta debe ser NO.
9.1.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al gestionar la ética un proyecto?.
Como persona: ¿Qué haré de aquí en adelante en temas de ética?
Planificación, Desarrollo y Control de Proyectos
Página 71 de 86
10.- Gestión Comunicacional “Me interesa el futuro, porque es el sitio donde voy a pasar el resto de mi vida”. Woody Allen. Evitar la desinformación, ello se consigue informando adecuadamente, para ello se debe tener en cuenta: Qué informar, A quién informar, Cuándo informar y Cómo informar Cuidado para no caer en los vicios de la comunicación:
10.1.- Gestión de reuniones Todo trabajo que involucre equipos de personas, requiere de instancias de coordinación, una de esas instancias son las reuniones, que pueden ser planificadas de antemano (ello requiere que sean incluidas en la carta Gantt, como parte del proyecto) con la coordinación que ello implica o ser sorpresivas, porque las condiciones o los acontecimientos así lo indican. Las reuniones requieren de una cierta logística para lograr que cumplan su objetivo: Deben ser las justas y necesarias en periodicidad, duración y asistentes. Con citación previa a quienes corresponda, que incluya, además del lugar, hora de inicio y de término y el temario a tratar.
Planificación, Desarrollo y Control de Proyectos
Página 72 de 86
El encargado de la reunión debe emitir posteriormente la minuta correspondiente (forma parte de la documentación), en base a una norma que defina el formato de la misma, en la cual se deben especificar los temas tratados, los acuerdos tomados, compromisos con sus responsables y plazos y plan de realización de la próxima reunión. Es la única minuta válida y de ser necesario debe ser firmada por los asistentes y ser incorporada como parte del contrato vigente en el proyecto. No deben ser muy largas en duración ni muy numerosas en concurrentes No deben tratarse muchos temas disímiles Tratar de desarrollarlas en lugar y/u horario incómodo para garantizar hora de término. Sin sacrificar la calidad de los acuerdos tomados. En la medida que las reuniones son útiles y aportan al trabajo, se logra el compromiso e interés de asistencia a ellas. La reunión en sí puede ser efectuada en forma presencial o utilizando apoyos tecnológicos como teleconferencia, videoconferencia u otros, que es muy conveniente cuando existe dispersión geográfica entre los asistentes a la misma. Apoyar la coordinación de reuniones en la tecnología vigente. La reunión, presencial o no, requiere de un lugar para efectuarla, el cual debe tener disponibilidad para todos los asistentes y/o los medios tecnológicos que requieran. Para efectos de cumplir con la estimación de tiempo y de esfuerzo es conveniente no esperar las reuniones para avanzar en los compromisos, sino que dejar las reuniones como instancias de revisión, en particular cuando se trabaja con terceros, y asumir nuevos compromisos y, el avance de los mismos debe efectuarse entre una reunión y otra. La reunión puede ser usada: Como un hito en la cual se haga entrega de un resultado intermedio, Para capacitación, Para difusión de información, Para recepción y/o entrega de antecedentes Para negociaciones Al comunicar se debe tener cuidado: En el lenguaje escrito, palabras usadas, frases, ortografía, puntuación, etc. En el lenguaje verbal cuidar la entonación de las palabras y el lenguaje no verbal o gesticular que acompaña el lenguaje verbal, pues al haber una separación entre el lenguaje verbal y el no verbal, este último es el que predomina en el mensaje entregado.
Planificación, Desarrollo y Control de Proyectos
Página 73 de 86
Para que exista comunicación debe existir un emisor del mensaje, una forma de transmitir el mensaje y un receptor de dicho mensaje, si uno de ellos no existe la comunicación no se estableció, es decir, no se logró. En caso de que en el transcurso del proyecto se presente una crisis, en ese momento es necesario comunicar con: Objetividad (gestión) y Subjetividad (emoción), emoción del que escucha y/o está afectado por la crisis
10.2.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al gestionar la comunicación en un proyecto? ¿Qué cuidados se deben tener al comunicar?
En mi actividad actual: ¿Qué voy a utilizar de lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 74 de 86
11.-Gestión de Métricas de Control o Indicadores “La mayoría de las personas gastan más tiempo y energías en hablar de los problemas que en enfrentarlos”. Henry Ford Las Métricas de Control o Indicadores, entre otras cosas, permiten: Conocer y/o medir la trazabilidad del proyecto y/o del producto Objetivizar la información, reduciendo la percepción y/o juicios Comparar o efectuar benchmarking, entre proyectos homologables. Existen diferentes tipos de control: Control proactivo o preliminar, para prevenir o anticipar posibles desviaciones, se define qué controlar, qué medir y cómo Control concurrente, consiste en realizar un seguimiento de las actividades en ejecución para asegurar el logro de los objetivos planteados, se corrigen los problemas al momento de ocurrir. Control de retroalimentación, efectuar un análisis de los resultados logrados y así obtener información que permita tener elementos/información para determinar que hacer, que analizar y que indicadores utilizar a futuro. Corrige los problemas una vez que han ocurrido. Las métricas permiten medir la “salud” del proyecto. No confundir con Evaluación de Desempeño, que es individual. Las tres M Métrica, Medir, Monitorear Qué medir sin Cómo medir, no sirve Medir lo que se necesita, no sólo lo que es más fácil No olvidar las tres R Revisar, Remediar, Renegociar Efectuar solo controles es impagable, es preferible capacitar y motivar a las personas al autocontrol. Usar indicadores para el proyecto y para terceros, recordar que ellos miden la diferencia entre lo planificado o deseado en condiciones ideales y la realidad que se desenvuelve en el caos. Lo anterior obliga a evaluar la pertinencia de lo deseado o planificado y, eventualmente, a re-planificar.
Planificación, Desarrollo y Control de Proyectos
Página 75 de 86
Que hacer o medir: evaluar tendencias, indicadores cualitativos y cuantitativos, informar, ponderar, usar estadígrafos, medir antes y después de un cambio, etc. Recordar que existen indicadores de tendencia y de emergencia Que no hacer: medir todo, indicadores complejos, que usen recursos, trabajar para el indicador, continuar con los indicadores sin usar. La información de indicadores se prepara según a quien va dirigida, esto define: método de distribución, si se agregan comentarios, cómo se presenta
11.1.- Evaluación de la ruta crítica Un proyecto de tecnología normalmente tiene más de una ruta crítica, luego lo primero que se debe hacer en este aspecto es detectar las rutas críticas y a continuación efectuarles el seguimiento muy de cerca, un error muy común es que una vez encontrada una ruta crítica se le monitorea, confiando en que esa es la única y que no hay otra(s). Adicionalmente en los proyectos tecnológicos se da la particularidad de que la(s) ruta(s) crítica(s) pueden cambiar durante el desarrollo del proyecto, por lo tanto con la misma dedicación con que se monitorea(n) dicha(s) ruta(s) crítica(s) se debe monitorear si dicha(s) ruta(s) continúa(n) siendo crítica(s). El control de estas rutas críticas es muy conveniente efectuarlo con apoyo de herramientas tecnológicas orientadas a esta función. El monitoreo de factores de riesgo, causas de fracaso, seguridad, recursos, documentación, se debe privilegiar para las rutas críticas.
11.2.- Mecanismos de aviso: índices de control, Check list No es conveniente implementar solo mecanismos y/o procesos de control, porque eso normalmente exige una escala de control que es impagable por el proyecto, es preferible capacitar a las personas y motivarlas al autocontrol, Aparte de las señales indicadas en el módulo anterior, se debe poseer un conjunto de indicadores que permita controlar el estado del proyecto a cada instante que sea necesario, debiendo tener además los respectivos controles de certeza de la información recibida en dichos indicadores. Los indicadores de gestión son válidos también para aplicarlos a los terceros contratados para el proyecto. Antes que nada, estratégicamente hablando, es conveniente tener en claro lo que se desea lograr con los indicadores, previo a comenzar el desarrollo de un proyecto de implementación operacional de los mismos. Planificación, Desarrollo y Control de Proyectos
Página 76 de 86
Desde un punto de vista estratégico, los indicadores de gestión permiten medir la “brecha entre lo que se desea (objetivo estratégico, por ejemplo los definidos, en la empresa, en el Plan Informático si existe o en el proyecto) y se ha planificado y la realidad de lo logrado”, entonces el modelo instrumental a implementar tiene como primer objetivo medir la pertinencia de los objetivos estratégicos planteados y, como segundo objetivo, medir el desempeño del proyecto respecto de dichos objetivos, utilizando “métricas” cuantitativas que impidan la subjetividad en los análisis. Es así que es necesario definir inicialmente “lo que se desea”, que puede provenir de las siguientes fuentes: Un estándar previamente definido dentro de la empresa o de la unidad de informática o del proyecto. Un estándar de la industria o del rubro al cual pertenece la organización Un valor histórico aceptado, el cual debe ser corregido por los cambios en el entorno y que lo afecten. Estas fuentes no son incompatibles entre sí y se deben usar para determinar el valor de cada indicador a medir. Continuando con la visión estratégica, la confección del modelo instrumental, requiere identificar los escenarios o aspectos a considerar, al momento de desarrollarlos o implementarlos, éstos son: Comercial, identificación de servicios/productos prestados, definición de matriz cliente/servicio. Productivo, identificación de qué servicios ofrecer y cómo ofrecerlos. Financiero, identificación de rentabilidad que orienta la gestión de costos y presupuestos. Humano, identificación de productividad necesaria y cantidad y perfil de competencias y destrezas que apoyen y/o mejoren dicha productividad. Es necesario recalcar que la implementación de indicadores de gestión apunta a que la percepción del desempeño del desarrollo del proyecto, sea lo que los indicadores reflejan y para ello es conveniente destacar que el servicio se mide por medio del balance dos factores básicos: El primero es la continuidad del servicio, que se mide usando el parámetro Mean Time To Repair (MTTR), en que se debe tratar de que el valor del MTTR sea el mínimo posible, El segundo se refiere al mejoramiento del servicio, que se mide usando el parámetro Mean Time Between Failures (MTBF), en que se debe tratar de que el valor del MTBF sea el máximo posible. Desde un punto de vista táctico-operativo, entre lo que es recomendable hacer al desarrollar indicadores de gestión dentro de un proyecto, está:
Planificación, Desarrollo y Control de Proyectos
Página 77 de 86
Tener cuidado de que hay indicadores de gestión que entregan información útil en forma momentánea y otros entregan información en tendencias, es decir, requieren de un período de medición (semanal, mensual, trimestral, semestral, anual) antes de poder usarlos. Dependiendo de la duración del proyecto habrá indicadores que no será posible utilizar. Es conveniente definir indicadores para lo efectuado y para lo no efectuado, por ejemplo: llamadas sin atender. Las mediciones de indicadores de gestión deben ser complementarias a indicadores de evaluación de desempeño de las personas. Es conveniente informar y comunicar a los involucrados, el resultado de los indicadores de gestión, aceptando sugerencias de modificación y/o adecuación. A cada indicador se le debe asignar un ponderador, según su importancia relativa. Usar indicadores cuantitativos que entregan objetividad y complementar con algunos indicadores de tipo cualitativo. En algunos casos es necesario utilizar algunos estadígrafos (promedio, moda, desviación, etc.) para obtener resultados. Antes de interpretar un indicador, si este presenta alguna desviación importante respecto de mediciones previas, es necesario investigar efectos del tipo estacional o de cambio tecnológico. Es conveniente tener indicadores relacionados entre sí, de forma tal que la variación de uno afecte al otro y así sirvan de certificación, para evitar una mala medición e/o interpretación. Los indicadores y su valor se deben estar constantemente verificando, pues los avances de la tecnología pueden dejar obsoleto a algún indicador o, pueden variar sustancialmente su valor y/o umbrales de decisión. Asimismo es necesario incorporar el grado de madurez tecnológica de la empresa, pues también tiene efecto sobre los indicadores y/o su valor. Administrar umbrales de decisión en base a tendencias, no a lo momentáneo. Conservar información histórica que permita efectuar comparaciones, guardar documentación. Recordar siempre que las decisiones tomadas para mejorar un indicador (que en consecuencia es mejorar la gestión) tienen un efecto costo, medible en recursos técnicos, humanos y/o financieros. Como contraparte los indicadores permiten mostrar como se ha deteriorado la gestión y/o la calidad de la gestión del proyecto, por no efectuar las inversiones y/o tomar las decisiones requeridas, a tiempo. Al efectuar un cambio o tomar alguna decisión es altamente conveniente observar el comportamiento de los indicadores involucrados, antes, durante y después del cambio y compararlos con los valores teóricos, estimados antes de efectuar el cambio. Tratar de que la información de los indicadores sea obtenida en forma automática o como parte de un proceso, de forma tal que sea lo más fidedigna posible y se obtenga con el mínimo esfuerzo.
Planificación, Desarrollo y Control de Proyectos
Página 78 de 86
Continuando con el enfoque táctico-operativo, entre lo que no se debe hacer al desarrollar indicadores de gestión dentro de un proyecto, está: No buscar un indicador para cada cosa o actividad que se efectúe dentro de la unidad, pues se cae en el error de trabajar para la métrica, relegando a segunda prioridad otras actividades más relevantes. No generar indicadores que sean complejos en la obtención de la información requerida o en su interpretación, pues se cae en el error de tener que dedicar recursos a una actividad que no debería requerirlos y como los recursos con escasos, además se desatiende otras actividades. Finalmente el indicador resulta ser más caro que la utilidad que proporciona. No crear clima laboral de trabajar para quedar bien en el indicador de gestión, pues se cae en el error de desviar prioridades y atenciones y perder el valor de las actividades a desarrollar. Y, en el peor de los casos, a falsear información con el objetivo de mostrar el logro de alguna meta, hito o fase, antes mencionada. No acumular información por el sólo hecho de tenerla, es decir, una vez obtenida la información de los indicadores, utilizarla e informarla, para no caer en el error de desmotivar a las personas y desacreditar el indicador en sí. Instalar un indicador de gestión sin entender a cabalidad el proceso a medir, y/o definir un valor de umbral de decisión de un indicador, sin tener historia de comportamiento del indicador. Incorporar como parte de los valores ciertos, los obtenidos durante una emergencia, pues se cae en el error de buscar como óptimo lo ocurrido durante la emergencia, en la cual se trabajó con otras referencias de dedicación, presión, esfuerzo, etc. Estos valores de emergencia sólo pueden ser usados como referencia posterior. Los indicadores a usar se clasifican en los siguientes: Indicadores internos, otorgan una visión particular y/o de conjunto del proyecto o sub-proyecto a evaluar, facilitando la toma de decisiones al interior del mismo. En este caso es necesario identificar turnos de trabajo, si corresponde. Indicadores comparativos internos, entregan información de procesos o actividades comunes, que permite comparar el desarrollo de dichas actividades, en diferentes áreas o unidades dentro del mismo proyecto. Adicionalmente es necesario identificar “subsidios” entre las unidades, por ejemplo: una alta actividad de una unidad, puede reflejar una falta de calidad en otra. Indicadores comparativos externos, igual que los anteriores, sólo que permiten la comparación con las mismas áreas o unidades de otro(s) proyecto(s) dentro de la empresa, pudiendo también extenderse a otras empresas. Para esta última comparación es necesario homologar procesos y unidades para que los indicadores sean equivalentes. Indicadores referenciales, entregan información de procesos y/o actividades del proyecto que tienen una contraparte (por ejemplo: usuaria), que a su vez también tiene sus propios indicadores para medir el servicio otorgado, en este Planificación, Desarrollo y Control de Proyectos
Página 79 de 86
caso es necesario definir y acordar, previamente, con la contraparte, los SLA que permitan homologar las mediciones y tener equivalencia y consistencia en la información a intercambiar. Indicadores externos, son aquellos que requieren información que es generada externamente al proyecto (ejemplo: indicadores de gastos, inversiones, capacitación, etc.). La obtención de indicadores, su importancia relativa, los umbrales a considerar y/o los valores de los indicadores, se verán afectados por algunos efectos denominados Efectos Globales, como por ejemplo si la empresa o la Unidad de Informática está inmersa en alguna metodología de calidad (ejemplo: CMM, ITSM, ISO, etc.), el grado de madurez tecnológica de la empresa, el prestigio y/o poder la unidad de Tecnología dentro de la empresa, el rubro de la empresa, etc. A nivel táctico-operativo, se sugiere la siguiente estructura de información a tener de cada indicador: Código de Identificación Función que apoya (Desarrollo, Administración de Bases de Datos, Operaciones, Comunicaciones, Help-Desk, etc.) Nombre del Indicador Descripción del Indicador y Objetivo Elementos de Cálculo (método de obtención de la información, funciones matemáticas utilizadas, etc.) Rango de validez (entre 0 y 1, mayor que cero, etc.) Observaciones (momentáneo, con tendencia, usar estadígrafo, etc.) Clasificación (según punto anterior) Relación con otros indicadores Valores medidos indicando valor, fecha de medición y observaciones, si corresponde. La forma en que debe fluir la información obtenida de los indicadores implementados debe contemplas aspectos como: A quien va dirigida, esto queda definido por el cargo o rol de quien recibe la información y puede tener como consecuencia el hecho de que la información recolectada en los diferentes indicadores se le entregue con determinados niveles de agrupación, o de consolidación y/o en diferentes períodos o frecuencias de entrega, asimismo va a influir en si es necesario incluir información histórica de comparación. Distribución de la información, dice relación con como se entregará la información obtenida de los diferentes indicadores en uso, esto puede traducirse en las categorías de la información que el indicador entrega, por ejemplo: nivel de servicio, costos, recursos humanos, recursos materiales, eficiencia, etc., entonces es necesario analizar el tipo de información que el indicador entrega y categorizarlo para efectos de que el informe entregado tenga una estructura de fácil comprensión por parte de quien recibe dicho informe. Eventualmente puede definirse un indicador de tipo Planificación, Desarrollo y Control de Proyectos
Página 80 de 86
global que refleje el comportamiento general, para ello es necesario definir ponderadores a cada categoría de indicadores. Análisis y/o comentarios de la información, se refiere a la eventual necesidad de que junto al informe, que incluye los resultados y/o datos obtenidos de cada indicador, se incluya algún comentario de explicación y/o análisis de los resultados entregados y/o de las variaciones detectadas. Presentación de la información, está relacionado en la forma en que se entregará la información obtenida de los indicadores en el informe a entregar, se debe definir aspectos como, incluir información numérica, gráfica, colores a usar, que medio utilizar (papel, medio magnético, mail, etc.), tamaño del informe, etc. Los indicadores se deben separar entre los de tipo general, aplicables a todas las unidades o actividades, y los de tipo particular, que sólo son aplicables a una unidad o actividad específica. Establecer un cuadro de relaciones entre indicadores por unidad o actividad y entre unidades o actividades. La identificación y definición de las relaciones entre indicadores, permitirá certificar la validez de la información entregada por un indicador, si esta es válida, la relación entre los indicadores se respetará, si no es válida, la relación no se establecerá y será necesario revisar qué ocurrió. Proceso de Implementación.Algunas ideas a considerar o tener en cuenta al momento de enfrentar el proceso de evaluar o analizar qué indicadores seleccionar para el proyecto: Por su relevancia para el cumplimiento de los objetivos del proyecto Por la disponibilidad de los datos del indicador Por la capacidad de controlar el desempeño del proyecto Lo anterior se puede complementar con las siguientes preguntas (lista no exhaustiva) que permiten validar un indicador, la exigencia es que la respuesta a cada pregunta debe ser afirmativa (si): 1. ¿Se relaciona el indicador con el objetivo al cual está vinculado? 2. ¿Se relaciona el indicador con el producto al cual está vinculado? 3. ¿Es importante el indicador para el proyecto? 4. ¿El indicador tiene claramente una meta o referente para medir su resultado? 5. ¿El resultado del indicador explica de forma precisa y clara el grado de cumplimiento de la meta, es decir, el resultado no es ambiguo?. Dicho de otra forma: ¿El indicador muestra o expresa de forma clara el resultado, para poder ser analizado por el(los) responsable(s)? 6. ¿Se ha definido la frecuencia de medición del indicador? 7. ¿La unidad de medición es adecuada para la meta que se espera medir? 8. ¿Es posible recopilar datos confiables y precisos para este indicador? 9. ¿El resultado de este indicador está condicionado solo por factores internos? Planificación, Desarrollo y Control de Proyectos
Página 81 de 86
10. ¿La información de este indicador está disponible y accesible a los interesados (internos y externos)? 11. ¿El indicador fue elaborado en forma participativa? (líder y personal del proyecto) 12. ¿Es importante el indicador para el usuario, cliente, par, jefe? 13. ¿El indicador muestra o expresa de forma clara el resultado para poder ser analizado por interesados(as) externos al equipo de proyecto? Aspectos Humanos Es necesario capacitar a las personas en este tema y motivarlas para obtener su disposición y apoyo a un proyecto de este tipo. Es necesario contar con la aprobación de ejecutivos. Administración del clima laboral, en particular aspectos de tipo motivacional. Aspectos Financieros Es necesario contar con un presupuesto para desarrollar este proyecto. Aspectos Logísticos Se debe seleccionar de la matriz cliente/servicio (indicada anteriormente) el o los servicios y el o los clientes con quienes se iniciará este proceso. Es recomendable partir con un conjunto de no más de tres indicadores en alguna(s) unidad(es) o actividad(es) críticas, eligiendo los indicadores que sean más fáciles de obtener e ir creando el hábito de su medición hasta lograr que sea una actividad ms, que no entorpezca el resto de las actividades. Logrado lo anterior ir incorporando más indicadores, siguiendo el mismo proceso anterior, hasta llegar a lo requerido. Durante el proceso ir mostrando las bondades y ventajas de contar con dicha información, para crear motivación de seguir alimentando con información los indicadores y preparar para la incorporación de más indicadores. Para el caso de poder satisfacer la percepción de los usuarios, es conveniente entrevistarlos para pedirles su apreciación respecto de en qué aspectos ellos perciben el impacto del proyecto y a esos aspectos definirles indicador de gestión, aprovechar la ocasión para estructurar la encuesta de servicio a usuarios a aplicar posteriormente. Fijar metas globales a alcanzar, y metas particulares con cada indicador a implementar, y repetir este proceso cada vez que se implemente un nuevo indicador. Definir un par de períodos, en los cuales se medirán los indicadores identificados, al término de cada período, junto con analizar el valor logrado con los indicadores y su aproximación a las metas fijadas, realizar encuestas a los usuarios para conocer su percepción del impacto, en los períodos definidos. De acuerdo el resultado de los pasos anteriores, decidir las acciones futuras de este plan de implementación.
Planificación, Desarrollo y Control de Proyectos
Página 82 de 86
Es conveniente que una vez incorporados los indicadores estos no se eliminen, es decir, los indicadores una vez iniciados deben terminar junto con el proyecto. Aspectos Técnicos Para efectos de lograr el éxito, se debe administrar como cualquier otra información con todos los aspectos metodológicos que ello involucre. Como todo trabajo a efectuar este tipo de información también debe estar sometida a revisiones del tipo auditoría, por ejemplo. Incorporar, en la medida que sea necesario, en los sistemas de la empresa (sistema contable, de producción, etc.) la desagregación de información requerida para facilitar la obtención de información de algunos indicadores. Para poder incorporar la metodología de indicadores de gestión, es necesario cumplir o desarrollar algunos requerimientos, como los que se indican a continuación: Para efectos de lograr la captura de información que los indicadores requieren, y cumplir con lo indicado en las consideraciones previas, es recomendable que las solicitudes o información al proyecto tengan una única puerta de entrada, de caso contrario la información que entregue el indicador no será válida pues estará incompleta y completarla significará un enorme esfuerzo que no se justifica. Adicionalmente, para poder cumplir con lo expuesto en las consideraciones previas, es conveniente que las solicitudes internas que se plantean entre unidades del equipo del proyecto, también sean informadas a dicho única puerta de entrada para ser incorporadas al sistema y poder tener las más completa información de gestión. Adicionalmente es conveniente que para actividad se confeccione un check-list o ayuda memoria que precise las actividades, documentación, aprobaciones, etc. que es necesario efectuar para dar por aprobada la actividad o en su defecto para saber con certeza que está faltando o está pendiente de efectuarse para darla por aprobada, este check-list es parte de la documentación del proyecto, para efectos de lograr mayor seguridad y transparencia se recomienda que una persona confeccione el check-list y otra lo revise y apruebe como tal.
11.3.- Análisis y solución de desviaciones El monitoreo debe ser constante, pues las desviaciones pueden surgir en cualquier instante, en cualquier parte y de cualquier manera. Es necesario precisar qué se considerará desviación, cuál será el umbral de decisión que definirá una desviación. Ambas acciones requieren de criterios de selección.
Planificación, Desarrollo y Control de Proyectos
Página 83 de 86
Una vez obtenidas las desviaciones es necesario priorizarlas para su atención y análisis, para ello es necesario definir criterios de priorización, esto está muy relacionado con lo indicado en evaluación de riesgos y factores de riesgos. Del análisis anterior pueden presentarse los siguientes escenarios: No hay solución Hay solución: o Y es simple, se procede o E implica una serie acciones que se deben planificar y monitorear (estas acciones a su vez también pueden presentar desviaciones) o Y si se deja pendiente, se documentan las razones
11.4.- Cierre y abandono del proyecto (normal y anormal) Todo proyecto tiene inicio determinado y un fin que es pronosticado en su inicio, uno de los objetivos de todo proyecto es lograr este fin planificado, en algunas ocasiones el fin del proyecto escapa a lo planificado, pudiendo ser después o antes de lo planificado inicialmente. Dicho término, que ocurre fuera de lo esperado, puede ser un término normal o anormal, se considera normal si el término es planificado o acordado en base a las condiciones del momento, es anormal si dicho término es imprevisto. Otra forma de terminar un proyecto es por abandono de las personas integrantes o reasignación de los recursos debido a cambio de prioridades, en este caso las variables de término son exógenas al equipo del proyecto. En caso de término normal, entre otras cosas, se debe efectuar una revisión de lo ocurrido durante el transcurso del proyecto identificando aspectos positivos y por corregir y efectuar los reconocimientos que corresponda. En caso de término anormal, entre otras cosas, se pone a prueba negociación precontrato, se prueban las cláusulas “fusibles”, se debe recuperar elementos de la empresa, cobrar las multas respectivas, separar al personal del proveedor, iniciar búsqueda de otro proveedor, efectuar marketing para revertir mala imagen, asimismo se debe efectuar una revisión de lo ocurrido durante el transcurso del proyecto identificando aspectos positivos y por corregir y efectuar los reconocimientos y responsabilidades que corresponda. Como un elemento importante a gestionar se debe administrar la sensación de fracaso y de impotencia. Lo anterior exige además que se efectúe una actividad de marketing para lograr la objetivización de lo ocurrido, es decir, precisar el problema, evitar que contamine a otras actividades y aislarlo para definir las actividades asociadas a su solución y/o mitigación de sus consecuencias. Dicho marketing debe hacerse al o los niveles que corresponda de acuerdo a la siguiente lista: Planificación, Desarrollo y Control de Proyectos
Página 84 de 86
Proyectos Unidad de TICAR Personas a cargo de proyectos De la TICAR
No olvidar que están relacionados entre sí.
11.5.- Preguntas de Repaso ¿Qué consideraciones se deben tener en cuenta al usar indicadores/métricas de control en un proyecto/producto?.
En los proyectos actuales y futuros: ¿Qué aplicaré de lo antes mencionado?
Planificación, Desarrollo y Control de Proyectos
Página 85 de 86
Referencias www.cio.com www.iale.es vigifia vigiale www.techrepublic.com www.outsourcing.com www.outsourcing-alert.com www.cetiuc.cl www.cxo.com www.voypormas.com www.usability.gov www.metricnet.com www.incidents.org http://www.ongei.gob.pe/publica/metodologias/lib603/N00.htm www.deltaasesores.com www.leansight.com www.chileagil.cl manifesto.softwarecraftsmanship.org http://www.globalpmstandards.org http://ipma.ch/ www.liderdeproyecto.com http://www.mintic.gov.co/gestionti/615/articles-5482_Indicadores.pdf http://www.welivesecurity.com/la-es/hot_topics/gestion-seguridad/ http://www.csirt.gob.cl/ http://www.opendatanow.com/ http://fedesoft.org/ http://www.apesoft.org/ http://www.cuti.org.uy/portada http://cessi.org.ar/ http://www.camtic.org/ http://cig.industriaguate.com/ http://www.capatec.org.pa/ http://www.wipo.int/portal/es/ http://www.thegreengrid.org/ http://reports.weforum.org/digital-transformation/ http://www.hugeinc.com/ (Ideas) https://www.ampproject.org/es/ https://www.humanbrainproject.eu/en/ http://www.isg-one.com/ https://instapage.com/try?campaignid=10005&mbsy_source=160642da-e651-467b-ac6dc8396c8d8cd2&mbsy=hNbJb http://www.capterra.com/contract-management-software/ https://www2.iaccm.com/resources/?id=7274 www.securityroundtable.org www.cahuala.cl Planificación, Desarrollo y Control de Proyectos
Página 86 de 86