Certificación de Aplicaciones

¿El hombre es el único animal que tropieza dos veces con la misma piedra? Seguro que cuando se acuñó esta frase, todavía no existía la informática…

Después de más de 10 años en el mundo del desarrollo, creo que he visto casi de todo, y lo que no he visto, me lo han intentado vender. Reconozco que la revolución ha sido impresionante. Hemos visto emerger y desaparecer productos, empresas, paradigmas… sin embargo, hay un punto dentro de este mundo de constante cambio que ha seguido tozudamente constante: la cantidad de problemas que surgen, cuando temblando alguien se atreve a dar la orden final de pasar a producción una nueva versión o un parche de una aplicación.

Cuantas veces hemos escuchado “… hemos realizado un pequeño cambio antes del paso a producción que solventaba un fallo y no se sabe como, ha introducido cuatro errores sobre funcionalidades anteriores…”

Realmente, cuando decimos que una aplicación está probada:

• ¿Alguien sabe “cuanto” está probada? (30% afirmativo)
• ¿Se están probando las áreas más críticas? (10% afirmativo)
• ¿Se ha asegurado que se mantiene el diseño original? (5% afirmativo)
• ¿Sabemos si el uso de la tecnología de base que se hace es suficientemente correcto como para no implicar un consumo masivo de recursos que degrada el sistema, independientemente del “hierro” que podamos meter? (10% afirmativo)
• ¿Alguien sabe si los cambios introducidos alteran los niveles de carga objetivo? Estos niveles de carga objetivo, ¿sobre que partes del sistema se están lanzado? (30% afirmativo)
• ¿Es posible garantizar la correspondencia entre las versiones del repositorio y las versiones en producción? (30% afirmativo)

Es curioso que casi todos los responsables de tecnología, consideren que se encuentran dentro del porcentaje que responde afirmativamente a estas preguntas. Sin embargo, cuando se entra al detalle de cada una de estas preguntas, aparecen los “peros”, que desembocan en que, desde una perspectiva práctica, la cobertura a estas preguntas es casi nula.

Para saber si se encuentra en esta situación, el mejor modo, no es iniciar una ronda de contactos internos para ver nuestra situación en cada uno de estos puntos, es más sencillo. Si usted se despierta en medio de la noche, y no es capaz de volver a conciliar el sueño porque empieza a pensar en cual es el estado real de un sistema en que se encuentra inmerso, sin duda, usted pertenece al “colectivo único” de responsables de TIC que “saben que no saben como van sus proyectos de sistemas”.

Leer entrada completa...

david.garcia@aptivoconsulting.com

Sin justificar el valor de las TI, difícilmente se puede obtener más recursos...

…Tengo pocos recursos en el área de TI y, de los que tengo, no todos tienen la formación adecuada…

... Las áreas de negocio cada vez me exigen más y no encuentro la manera de justificarles el valor de los servicios que les presto...

¿Os suena?... seguro que si, son los dos principales obstáculos con que se están encontrando los directivos de tecnología y sistemas. Y no es un mal propio de las organizaciones españolas, al menos eso dice el último informe emitido por el ITGI (IT Governance Institute, entidad independiente y sin ánimo de lucro).

Los Directores Generales y Directores de Tecnología de 23 países opinan:

- El 58% que la cantidad de personal en TI es insuficiente (en el año 2005 lo opinaban el 35%)
- El 41% reconoce tener dificultades con la previsión del retorno de las inversiones y gastos de TI (en el 2005 sólo era el 30%).

Sin embargo, ya nadie duda sobre la importancia de las TI para el negocio:

- El 93% de los encuestados expresó que las TI tiene una importancia media/elevada para la estrategia corporativa de su organización.
- Para el 32% las TI siempre está en la agenda de la alta dirección.

Son muchos los que opinan que estamos ante “la pescadilla que se muerde la cola”, me explico, si no tengo recursos no puedo poner en valor las TI, pero si no justifico su valor para el negocio, difícilmente voy a obtener más recursos….

Tal vez todo pase por justificar adecuadamente el Valor Económico de toda Inversión en TI, de manera que puedan priorizarse los proyectos y así dedicar los recursos disponibles, ya sean muchos o pocos, a aquellos que más aporten al negocio….. Quizás así, una vez el valor sea medible, demostrable y, por supuesto, positivo, difícilmente la alta dirección podrá resistirse a dotar con más recursos al área de TI.

Otro dato, el 36% de los encuestados informaron que la alineación entre la estrategia de TI y la estrategia corporativa es deficiente o muy deficiente. Este tema, muy relacionado con cómo estamos gestionando la demanda de las áreas de negocio lo vamos a dejar para otro post.

Angel.gutierrez@aptivoconsulting.com

Valoración Económica de Proyectos TI

En un mercado caracterizado por las crecientes restricciones presupuestarias, cada vez se hace más necesario evaluar y justificar las inversiones en tecnología en función de su “valor” para el negocio.

Existe una creciente tendencia de mercado a proyectar el retorno de la inversión (ROI) e incluso a preparar “casos de negocio” para aquellos proyectos tecnológicos que sobrepasan un cierto umbral de inversión y/o que tengan un impacto significativo en el negocio.

Sin embargo, a pesar de haber desarrollado ciertos elementos metodológicos en el análisis de inversiones de proyectos de tecnología, el problema para muchas organizaciones radica en:

• La dificultad y falta de consistencia en la cuantificación de los denominados beneficios “tangibles”. Este tipo de beneficios se suelen cuantificar mediante una estimación económica directa, esto hace que no exista trazabilidad con los criterios de negocio que justifican dicha estimación.Tampoco suele existir una sistemática de valoración de los beneficios que aporta un proyecto para el negocio. Esto hace que el proceso de evaluación del “valor” de cada proyecto no sea consistente, al no usar los mismos principios en todos los proyectos.
  

• La imposibilidad de cuantificar los beneficios denominados “intangibles”. Con la metodología actual resulta imposible medir conceptos como “productividad”, “eficiencia”, “calidad de servicio”, “satisfacción del cliente”, etc. En muchos casos, designar un proyecto como “estratégico” se considera suficiente para justificar su ejecución.

• Asimismo, resulta imposible realizar un seguimiento de los beneficios identificados, ya que no se dispone de indicadores de desempeño medibles que los sustenten.

• Por otra parte, no se suele manejar de forma explícita el riesgo, entendido como la incertidumbre que lleva implícita toda estimación del valor económico de un proyecto.

• Tampoco suele considerarse el riesgo de no inversión. El análisis tradicional de impacto en resultados usa como “línea base” los resultados actuales.

• Por último, se hace muy difícil incorporar y ponderar debidamente consideraciones de carácter estratégico y otros aspectos no financieros que no pueden ser expresados fácilmente en términos económicos, y que, sin embargo, permiten “evaluar” el efecto de la inversión sobre la globalidad del negocio.

Generalmente, los grandes proyectos de tecnología vienen determinados por la estrategia de la organización. Sin embargo, existe una gran cantidad de peticiones de servicio y/o proyectos de mediana dimensión, que suponen un montante económico muy significativo y que, a la vez, inciden sobre la capacidad de ejecución. En este capítulo es donde es especialmente necesario discriminar entre diferentes iniciativas y decidir cómo asignar de forma eficiente los recursos económicos y humanos disponibles.

Conscientes de esta problemática, en Aptivo Consulting hemos desarrollado un servicio que permite disponer de una “herramienta” objetiva, consistente y homogénea para la medición del valor de los proyectos de tecnología, de manera que sea posible:

• Cuantificar, en términos económicos, todo tipo de beneficios, “tangibles” e “intangibles”.

• Ponderar dicha cuantificación económica con consideraciones cualitativas de carácter estratégico, en base a criterios homogéneos que sean consistentes con el modelo de cuantificación de beneficios utilizado.

• Priorizar adecuadamente inversiones y gastos en tecnología.

• Realizar un seguimiento de los beneficios identificados tras la implantación del proyecto.

angel.gutierrez@aptivoconsulting.com

Transformación de Procesos de Negocio

• Rediseño y Racionalización de Procesos de Marketing, Comerciales y Operativos.
• Gestión de la Innovación.
• Desarrollo de la Función Informática - IT Governance.
• Gestión de Programas y Proyectos - PMO: Oficina de Gestión de Proyectos.
• Estrategias de “e-business”, eMarketing y de Comercio Electrónico.
• Gestión del Cambio Organizativo y/u Operativo
• Puesta en marcha de nuevos Modelos de Relación Comercial.
• Rediseño de los servicios de Atención a Clientes.

Consultor Senior - Sector Financiero (Oferta Empleo)

Descripción del Puesto:
Consultor con experiencia y perfil funcional que tengan conocimientos del sector financiero, preferiblemente en el área de Riesgos, Control de Gestión o Contabilidad.

Su función principal sería la interacción con las diferentes áreas usuarias de una Entidad Financiera para la identificación de necesidades, cualificación de las mismas, diseño funcional, estimación de esfuerzo, seguimiento de la ejecución, trazabilidad de los requerimientos, etc. El puesto ofrecido permite una continúa evolución en los conocimientos financieros (complementada, si es necesario, con formación) y un desarrollo profesional dentro de Aptivo Consulting.

Requisitos:
Titulación media/superior, preferentemente en titulaciones económicas y carreras técnicas relacionadas con las tecnologías de la información

• Conocimientos de Sistemas de Información.
• Buen expediente académico.
• Edad menor de 30 años.
• Proactivo y capaz de trabajar en equipo.
• Disponibilidad para viajar.

Condiciones:

• Contrato Indefinido.
• Salario en función de valía y experiencia.
  

Sistema de Gestión de Precios y Comisiones

El objetivo del Sistema de Gestión de Precios y Comisiones (SGP) es permitir a una Entidad establecer, ofrecer y negociar con sus clientes, bonificaciones sobre precios (tarifas de contratación de productos y servicios) y comisiones de operación, en virtud del cumplimiento de un conjunto de requisitos, condiciones y contrapartidas derivadas de la política comercial de la Entidad o de acuerdos y convenios comerciales específicos.

Las bonificaciones ofrecidas se pueden establecer según:

• La política comercial de la Entidad (p.e., condiciones especiales para captación, crecimiento, retención, etc., para determinados segmentos, grupos de acción comercial, colectivos marketing, campañas, etc.).
• Los acuerdos con colectivos o firma de convenios (p.e., pymes, comercios, asociaciones profesionales y/o sectoriales, autónomos, etc.).
• Los acuerdos particulares con clientes individuales (o incluso, para un contrato de un cliente), para los que su gestor decide/solicita condiciones especiales.

Certificación de Aplicaciones (Art. Completo)

¿El hombre es el único animal que tropieza dos veces con la misma piedra?
Seguro que cuando se acuño esta frase, todavía no existía la informática…

Después de más de 10 años en el mundo del desarrollo, creo que he visto casi de todo, y lo que no he visto, me lo han intentado vender. Reconozco que la revolución ha sido impresionante. Hemos visto emerger y desaparecer productos, empresas, paradigmas… sin embargo, hay un punto dentro de este mundo de constante cambio que ha seguido tozudamente constante: la cantidad de problemas que surgen, cuando temblando alguien se atreve a dar la orden final de pasar a producción una nueva versión o un parche de una aplicación.

Cuantas veces hemos escuchado “… hemos realizado un pequeño antes del paso a producción que solventaba un fallo y no se sabe como, ha introducido cuatro errores sobre funcionalidades anteriores…”

Realmente, cuando decimos que una aplicación está probada:

• ¿Alguien sabe “cuanto” está probada? (30% afirmativo)
• ¿Se están probando las áreas más críticas? (10% afirmativo)
• ¿Se ha asegurado que se mantiene el diseño original? (5% afirmativo)
• ¿Sabemos si el uso de la tecnología de base que se hace es suficientemente correcto como para no implicar un consumo masivo de recursos que degrada el sistema, independientemente del “hierro” que podamos meter? (10% afirmativo)
• ¿Alguien sabe si los cambios introducidos alteran los niveles de carga objetivo? Estos niveles de carga objetivo, ¿sobre que partes del sistema se están lanzado? (30% afirmativo)
• ¿Es posible garantizar la correspondencia entre las versiones del repositorio y las versiones en producción? (30% afirmativo)

Es curioso que casi todos los responsables de tecnología, consideren que se encuentran dentro del porcentaje que responde afirmativamente a estas preguntas. Sin embargo, cuando se entra al detalle de cada una de estas preguntas, aparecen los “peros”, que desembocan en que, desde una perspectiva práctica, la cobertura a estas preguntas es casi nula.

Para saber si se encuentra en esta situación, el mejor modo, no es iniciar una ronda de contactos internos para ver nuestra situación en cada uno de estos puntos, es más sencillo. Si usted se despierta en medio de la noche, y no es capaz de volver a conciliar el sueño porque empieza a pensar en cual es el estado real de un sistema en que se encuentra inmerso, sin duda, usted pertenece al “colectivo único” de responsables de TIC que “saben que no saben como van sus proyectos de sistemas”.

Por si no fuera poco enfrentarse a una bolsa de demanda de los usuarios que recurrentemente supera nuestra capacidad de ejecución y gestión de proyectos, un backlog que crece más rápido que decrece y un martilleo constante de los usuarios reflejando su descontento con la tecnología, añadamos el factor de incertidumbre de no tener la tranquilidad de saber el estado de nuestros sistemas de cara a los siguientes pasos a producción.

Para solventar esta problemática, hemos visto soluciones de todo tipo: metodologías, guías de desarrollo, normativas, directivas, oficinas de proyecto, etc.

Todo ello forma en cierta medida parte de la solución, pero estas soluciones, para poder atacar la problemática expuesta, implican un uso intensivo de recursos humanos, que en el mejor de los casos, no llegaría a ofrecer garantías, implicarían destinar recursos con altos conocimientos (y por tanto escasos) a tareas de revisión de bajo valor que implicarían tiempos de revisión prolongados…

Una solución “real”, pasa por automatizar todo el proceso de certificación de una aplicación. Este proceso de certificación, incluiría pasos como:

• Conectarse a un repositorio de versiones.
• Obtener la última versión.
• Compilarla (obligatorio para ser SOX compliance)
• Ejecutar las pruebas de la misma (unitarias, de navegación, de carga, etc).
• Determinar cuál es el grado de cobertura ofrecido por estas pruebas.
• Obtener índices de calidad.
• Detectar automáticamente errores y malas prácticas de programación.
• Comprobar si las partes más críticas del sistema están suficientemente probadas.
• Empaquetar y desplegar versiones.

En Aptivo Consulting, hemos implantado internamente este proceso para la certificación de nuestras aplicaciones e igualmente hemos implantado este enfoque junto a algunos de nuestros clientes, bajo la fórmula de Oficina de Certificación.

Esta Oficina de Certificación es la encargada de realizar todo el proceso descrito previo a los pasos a producción. Consideramos que uno de sus factores clave de nuestro enfoque, es que los productos utilizados son en su totalidad opensource/freeware, de manera que el coste recurrente para nuestros clientes es CERO.

Esto les posibilita poner el ciclo de certificación a disposición de sus proveedores, cosa que cuando utilizan productos comerciales, no hacen normalmente por los costes de licencias implicados. Cuando los proveedores no disponen de estos entornos de certificación, lo que sucede es que se detecta un “zurrón” de errores, justo antes de los pasos a producción (porque es el momento en que se utilizan las herramientas de pago con que cuentan), lo que nos pone de nuevo a los pies de los caballos, porque no hay tiempo para la corrección de todos los errores que se hayan detectado...

En definitiva, después de más de 10 años en el desarrollo, por fin he encontrado una solución al “insomnio de los sistemas”.

Una última reflexión. Para aquellos que se crean a salvo de esta problemática porque “nosotros vamos a construir una arquitectura de referencia para nuestros sistemas/proveedores, así que este no será más nuestro problema”… agarraros a la silla con celofán, porque se va a mover y mucho…

Cuando construyes una arquitectura de referencia, no estará siempre “quieta” y más pronto que tarde, tendrás que evolucionarla y modificarla. Esto implica que, de alguna manera tendrás que dar compatibilidad hacia atrás y asegurar que las aplicaciones que la nueva versión mejora la anterior y que sobre todo, que las aplicaciones que ya la están utilizando, no harán “crack” cuando despliegues las nueva versión.

En definitiva, que la arquitectura de referencia deberá estar bajo el control de la certificación de aplicaciones y no como un objetivo más, sino como un objetivo prioritario.

Otros enlaces de interés:

http://headrush.typepad.com/creating_passionate_users/2006/03/ultrafast_relea.html

http://headrush.typepad.com/creating_passionate_users/2006/01/death_by_riskav.html

http://martinfowler.com/articles/continuousIntegration.html

david.garcia@aptivoconsulting.com

Pocket Urgency Medical Assistant (PUMA)

El servicio de Urgencias es uno de los servicios hospitalarios con mayor presión asistencial en el que la información de primera mano es fundamental para una correcta atención a los pacientes y una minimización de los riesgos sufridos por los mismos.

El proyecto PUMA debía resolver las problemáticas asociadas al servicio de Urgencias proporcionando al personal del mismo:

• Movilidad, mediante el uso de dispositivos móviles (PDA's).
• Información a medida disponible en cualquier momento.
• Información reducida para el personal no médico.
• Seguridad en el manejo de datos, dado el carácter privado y personal de los mismos.

El sistema PUMA consta de los siguientes módulos funcionales:

• Aplicación Pocket PC para personal médico: Permite la observación y modificación de todos los datos relacionados con los pacientes.
• Aplicación PC/WEB(ASP) para personal no médico: Permite al personal de administración y enfermería consultar el estado de urgencias sin mostrar datos de índole médica.
• Aplicación servidora integrada con otras aplicaciones del Hospital (Servicio de Admisión, Laboratorio, Historiales, etc).

IT Governance Vs. “el coleccionista de frameworks”.

Angel Gutiérrez. IT Governance Vs. "el coleccionista de frameworks".

Es extraordinariamente habitual que un fuerte y estremecedor escalofrío sacuda el cuerpo de la Dirección al escuchar “Departamento de Tecnología y Sistemas de Información (TI)”. Este cuadro suele ir acompañado de visión entrecortada por el efecto “saco sin fondo” y dificultades de entendimiento por continuas sensaciones de “caja negra”.

Los pacientes aquejados de tan singular patología aluden una invencible sensación de estar dedicando enormes presupuestos al Departamento TI, acompañada de una frustrante percepción de que la calidad del servicio recibido “sigue igual”.

Los motivos esgrimidos para justificar la dedicación de tan ingentes presupuestos es común a todos los pacientes: “las TI son críticas para el negocio, no podemos prescindir de ellas. La organización necesita información integra, accesible y confidencial, y para ello, requerimos sistemas, procesos y personas que gestionen y conviertan los datos en información valiosa para el negocio”.

Para aliviar tan contradictoria sensación, los “curanderos” de las TI han recurrido a un tradicional brebaje mágico, consistente en un vocablo aderezado con un conjunto de siglas. En esta ocasión el vocablo es; “IT Governance”, y las siglas: COBIT, ITIL, diversas ISOs, CMM, MOF…

La breve historia de las TI nos demuestra que la ingesta directa de este tipo de “brebajes” en escasas ocasiones resuelve la problemática para la cual han sido elaborados. En esta ocasión, y como no podía ser de otra manera, la implantación directa de COBIT o ITIL, por sí solos, no garantiza ni asegura el ansiado alineamiento de las TI con el negocio, ni la óptima gestión de la infraestructura, ni siquiera una mejora en el modelo de financiación de proyectos y gestión de la inversión. En resumen, persiste la patología junto a la mayor parte de los síntomas diagnosticados. El motivo es que estos “frameworks” (ITIL, COBIT, MOF,…) se centran en aspectos concretos de la gestión de la función informática. Por ejemplo, ITIL se focaliza en los procesos operativos de soporte y prestación de servicios informáticos (“support” y “delivery”), pero deja fuera de su ámbito “el control” de estos. COBIT, por su parte, se centra en el control de las distintas actividades de TI, pero desde una perspectiva tan enfocada a la auditoria que no incide en detallar las tareas y actividades que deben conformar los procesos, así como el modelo de interacción entre ellos.

Por tanto, la simplificación de las iniciativas de “IT Governance” a la mera elección de un “framework”, en el mejor de los casos, nos permitirá “sanar” temporalmente síntomas muy específicos del Departamento (p.e. gestión de incidencias, problemas, cambios, disponibilidad, capacity planning,…), pero nunca los grandes males, al tiempo que no debemos olvidar su aportación a fomentar los síntomas de visión entrecortada por el “saco sin fondo” (licencias, esfuerzos para su puesta en marcha, costes de administración y certificación,…).

Olvidémonos de los vocablos, siglas y las correspondientes certificaciones que conforman el “brebaje de moda” y centrémonos en lo sustancial. Existe un elemento clave común que comparten todos los Departamentos de TI que han conseguido un satisfactorio alineamiento con sus áreas de negocio y una apreciable mejora en los niveles de servicio prestados: la gestión de las TI como un negocio en sí mismo, el Departamento de TI configurado como una empresa con vocación de servir a sus clientes desde dentro de la propia organización.

Este planteamiento implica un profundo cambio en el modelo tradicional de gestión de la función informática y en cómo se estructuran y gestionan las “fábricas” de TI. En esencia, el cambio consiste en concebir la función de TI mucho más orientada a las áreas de negocio. Esto conlleva nuevos principios de gestión y, por tanto, un nuevo modelo de Gobierno de las Tecnologías de la Información:

• Más foco en el “cliente” que en las operaciones y en el soporte técnico. El “servicio y el proyecto”, es decir, la demanda del cliente, se convierten en el principal “producto” de TI. La continuidad del servicio informático tiende cada vez más a ser una “commodity”.
• Los proyectos deben ser justificados a partir de su "valor" para el negocio.
• La función de TI debe configurarse como un proveedor de los "servicios" contratados por las áreas de negocio.
• Las métricas fundamentales para evaluar la función de TI debe ser su aportación de "valor" para el negocio.
• El establecimiento de "puntos únicos" de contacto entre áreas de negocio y TI: Gestión de la Demanda, Service Desk,...
• ...
  

En definitiva, el nuevo modelo requiere que las funciones corporativas de TI se estructuren y dimensionen para gestionar el ciclo de vida completo del “servicio al cliente”, típicamente: Dirección, Gestión de la Demanda, Proyectos, Servicios, Service Desk, Oficina de Proyectos, Calidad,.. El modelo de relación entre cada una de estas, la determinación de las funciones que serán externalizadas, los procesos que conformarán cada función, las herramientas necesarias para la gestión de cada proceso, el modelo para medir el desempeño,... todos estos aspectos conforman el “núcleo duro” del Gobierno TI y, por tanto, deben ser el objetivo de la mayor parte de nuestros esfuerzos en este tipo de iniciativas.

Las TI son una importante parte del negocio y han de ser gestionadas desde el punto de vista de un negocio de prestación de servicios. Por tanto, antes de lanzarnos a la adopción de “frameworks” que mejoren aspectos concretos de nuestra función informática, es necesario que reflexionemos sobre el modelo de Gobierno TI que tenemos en la actualidad y mejoremos aquellos aspectos susceptibles de serlo (funciones y su modelo de relación, procesos, “fricciones” internas y con áreas de negocio,…). Una vez tengamos esbozado el nuevo modelo es el momento de seleccionar los “frameworks” que apliquen. Estos pueden ser estándares (ITIL, COBIT,..) o de elaboración propia (tendencia cada vez más habitual).

Es cierto que este brebaje no elimina completamente los “escalofríos”, ni las apariciones de “sacos sin fondo”, pero aquellos que lo han probado aseguran que la intensidad de estos empieza a asemejarse a los producidos por cualquier otra área de la organización; Marketing, Organización, Producción,…