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,…