Inicio Tecnología El problema – brecha entre IT y negocio

El problema – brecha entre IT y negocio

Uno de los principales reclamos históricos de parte de las áreas de negocio a los responsables de Tecnologías de Información (o Sistemas) es la velocidad para poder atender requerimientos. La frase de cabecera de aquellos ejecutivos que necesitan de información para hacer su trabajo de manera más efectiva es “Sistemas no se mueve a la velocidad del negocio”. Y esos ejecutivos tienen razón ya que cuando un área de negocio define un requerimiento espera que el mismo sea respondido en cuestión de días. No de semanas o de meses.

Pero intentemos profundizar nuestro análisis. El Desarrollo de un requerimiento es un proceso, y como tal cumple con ciertas etapas según la metodología que se aplique pero en la mayoría de los casos tendremos una etapa donde dicho requerimiento tiene que ser definido por el usuario, una etapa de desarrollo propiamente dicha y una etapa de testeo tanto técnico como de funcionalidad. Estas etapas podrán ser más o menos complejas pero lo cierto es que toman tiempo y generalmente involucran recursos de la propia organización como de terceras partes. Adicionalmente se debe considerar el origen y destino de los datos, la calidad de los mismos y el impacto que este nuevo desarrollo puede tener en el ecosistema de la empresa entre otros.

Por otra parte si cambiamos de zapatos con las áreas de sistemas y tecnología de información es común escuchar postulados como: “el requerimiento estaba mal definido” o “Las áreas de negocio no tienen claro que es lo que necesitan” Pero en este caso es importante considerar que en la mayoría de las oportunidades el proceso de creación de valor y de soporte a la toma de decisiones, es iterativo. -* Iteración significa el acto de repetir un proceso con el objetivo de alcanzar una meta deseada, objetivo o resultado. Cada repetición del proceso también se le denomina una “iteración”, y los resultados de una iteración se utilizan como punto de partida para la siguiente iteración.* (Wikipedia) – por lo tanto el ejecutivo que solicita un requerimiento tiene claro el punto de partida más probablemente no el punto de llegada, eso es lo que justamente está buscando y para lo cual solicita apoyo a sistemas.

LA OPORTUNIDAD – BIG DATA

La baja en el costo de almacenamiento por Terabyte , que permite almacenar grandes volúmenes de información a bajos costo y la aparición de Map Reduce – Framework de programación que proporciona un sistema de procesamiento de datos paralelo y distribuido – que permite el procesamiento y análisis de dichos datos posibilitan la reformulación del ecosistema analítico introduciendo la PLATAFORMA DE DESCUBRIMIENTO.

La plataforma de descubrimiento es un ambiente analítico independiente del Enterprise Data Warehouse que permite a las áreas de negocio testear nuevas ideas, nuevos datos y diferentes hipótesis en búsqueda de valor para la organización. (Patrones de comportamiento, afinidad de productos, análisis de sentimiento, búsqueda de variables para ajustar modelos de minería)

Las ventajas de una plataforma de Descubrimiento son entre otras, la simplificación del acceso a la información para las áreas de negocio permitiendo que el usuario pueda combinar datos tradicionales con nuevas fuentes de datos de una manera más rápida.

Para que la plataforma de descubrimiento sea eficiente debe permitir almacenar tanto datos estructurados como multi-estructurados (logs de navegación de internet o de aplicaciones móviles), debe ser flexible a la hora del acceso (SQL , Map Reduce o Herramientas de BI) y principalmente tiene que permitir que el proceso sea iterativo.

Es importante considerar que esta plataforma no debe convertirse en una isla dentro del ecosistema analítico de la organización ya que gran parte de los datos que serán utilizados en el proceso de descubrimiento y análisis ya están almacenados en algún repositorio. Con este enfoque no solo permitimos a las áreas de negocio accedan a mayor cantidad de información en el tiempo que lo necesitan sino que logramos que las áreas de sistemas dediquen recursos solo a aquellos requerimientos que ya han sido previamente analizados y testeados funcionalmente por las áreas de negocio.