En pedir no hay engaño, pero …

En los últimos años me ha tocado analizar diferentes proyectos tecnológicos en la región, particularmente a la hora de iniciar proceso de externalización; y algo que llama la atención es el  poco cuidado a la hora de identificar los atributos que debe tener determinado sistema/plataforma en función del negocio/problema que busca resolver.

Habitualmente, las solicitudes en términos de calidad de servicio o conocidos como SLA’s, que establecen áreas informáticas para desarrollos y plataformas  no se hacen identificando claramente los atributos que estas deben tener.  Veamos algunos ejemplos, en diferentes áreas:

• Disponibilidad: Se establecen exigencias de niveles de servicio del tipo alta disponibilidad, incluso llegando en ciertas ocasiones a modelos fault-tolerant.  A mi pregunta porque un portal institucional, cuyos servicios no son de “misión crítica” se le ponen exigencias de 24×7, si jamás han operado un servicio que requiera 24×7, pocas veces he tenido una respuesta razonable.  En muchas ocasiones no se evalúa, lo que significa pedir una disponibilidad del tipo 24×7 y el costo que conlleva, en primer lugar para tener un portal con una promesa de nivel de servicio de 24×7, mi organización (operaciones, soporte, capacidad de respuesta, jornada laboral, etc) debe operar en la misma forma y en segundo lugar los costos de una operación de este tipo aumentan en forma exponencial.  Además comúnmente se confunde disponibilidad con operación 24×7, yo puedo tener una operación del tipo 8×5 y con una muy alta disponibilidad (muchos 9’s).

• Soporte: Los niveles de exigencia que se hacen a tiempos de respuesta para soporte, en muchos casos con tiempos de atención y resolución, casi inmediata siendo que no es necesario ese nivel de servicio, en muchos casos ni siquiera se discrimina por severidad el problema.  En ocasiones no se analizan los costos involucrados, por el hecho de que proveedor mantenga un servicio de este tipo.  Es bastante frecuente, que además se solicite que el personal de soporte se encuentre operando en forma local, cabe recordar que muchas compañías de software han centralizado sus proceso de soporte y mantienen operaciones centralizadas.

• Tiempos de respuesta: Otra de las exigencias que se hacen habitualmente, están asociadas a tiempos de respuesta, que no dicen relación con lo que realmente necesita el proceso, esto es, se ponen de muy alta exigencia, unos pocos segundos, sin incluir otros factores como latencia.  Se tratan todas las transacciones  con el mismo nivel de exigencia, sin considerar que algunas son mucho mñás importantes que otras.

• Escalabilidad:  exigencias asociadas a escalabilidad sin límites, recordemos que la escalabilidad tiene límites y el diseño de las soluciones deben considerar eso.

• Acceso al código fuente software base:  Se solicita que el proveedor y/o desarrollador entregue los códigos fuentes de muchas de las herramientas y software base con las cuales se ha construido la herramienta.  Esto con la idea de comprar una suerte de seguro por si el proveedor tiene algún tipo de dificultad en el futuro.

Como dicen: “En pedir no hay engaño” pero se debe asumir los costos que estas solicitudes tienen, no sólo desde un punto de vista de encarecimiento de la oferta, sino que además implican altas exigencias a la organización, las cuales muchas veces ni siquiera han sido visualizadas.

Si esto, no está presente en el análisis y por otro lado los procesos de la institución no lo requieren, se están haciendo un flaco favor al momento de definir los criterios y atributos de la solución, y por otro lado no se está obteniendo el mejor valor del gasto en el caso de externalizaciones

Imagen: https://gerant05.files.wordpress.com/2012/07/acusar.jpeg