Mientras que la infraestructura informática para soportar prestaciones de BI en sistemas on-premise se manejaban en departamentos informáticos especializados de manera más o menos independiente de las areas que explotaban la información, la realidad de la nube cambió de fondo el enfoque sobre el tema. En línea con artículos anteriores, el modo de entender la informática en la nube presenta una nueva forma de dividir las tareas, queriendo decir con esto que muchas funciones que se podían independizar, en la modalidad nube se solapan o hasta en muchos casos se pierden.
La esencia de estos cambios se encuentra en la desaparición de la infraestructura física desde el punto de vista de las organizaciones. Todas las cuestiones referentes a data centers, servidores físicos, instalaciones, seguridad material, alimentación ininterrumpida, y niveles de servicios básicos, etc., pasaron todas ellas a ser parte de los acuerdos de servicios con los proveedores. De esta manera solo resta administrar la plataforma desde la organización en su modo virtual, y su consecuencia directa es necesitar menos especialización de los recursos humanos implicados y simplificación de los procedimientos al punto de consistir en revisión de tableros de control, también virtuales.
La contraparte de ello consiste en que los diversos servicios necesitan configurarse con conocimiento de los desarrollos que se realizarían para satisfacer las necesidades de arquitectura de sistemas de inteligencia de negocios, algo que no se puede separar e implementar dado que se reducen a solo configuraciones entre estos servicios. Al no haber situaciones físicas implicadas, la tarea no solo es posible de realizar por los especialistas de BI, sino que se torna estrictamente necesario. Hacer equipos de creación de servicios y su conexión deja de tener sentido realizarlo con equipos mixtos, cuando todas las definiciones e implementaciones van a estar directamente definidas por esta áreas de negocio. Complementariamente se hace necesario a la par de crear estos servicios el monitorearlos y evaluar sus costos, lo que puede llevar a correcciones y hasta reformulaciones de la arquitectura de modo de cumplir con los presupuestos asignados, todas tareas administrativas complementarias que van de la mano y en la que necesariamente debe participar el equipo de BI, prácticamente con responsabilidad total.
Esta situación lleva a que un departamento de Inteligencia de Negocios deba estructurarse desde áreas de arquitectura, hasta de explotación y gestión de la demanda, pero todas coordinadas. Las áreas de servicios se reducen solamente a controlar la continuidad de las prestaciones, pero difícilmente puedan tomar alguna decisión más allá de eso que no involucre al departamento de BI. De igual forma los responsables del área de BI deben tomar la posta y comenzar a tomar esa responsabilidad que se incorporó hacia sus incumbencias básicas, algo que debe tomarse como una consecuencia positiva de la utilización de los servicios en la nube .
Hay un tópico que hace mucho que no uso en mis artículos, referente a filosofía y sistemas de información, que aplica muy bien para el tema de la inteligencia artificial. Hay mucho escrito y publicado en videos en los últimos meses sobre el tema, pero mis reflexiones no son sobre futurología ni las modificaciones que introducen los nuevos chat basados en IA asociada aplicados a campos inexplorados. Se basan solamente en mis intercambios con colegas, algunos más en tema y otros no, que me hicieron notar algunos puntos interesantes para meditarlos.
Cuando se puso a disposición del público en general la herramienta chat GPT3 en noviembre, nadie sabía muy bien de qué se trataba. Se la promocionaba como un artefacto dirigido al lenguaje que podía sostener una conversación o algo parecido. La reacción general ante algo novedoso y desconocido, sin mayor documentación que la que el mismo artefacto proporcionaba como respuestas, fue de inmediato encontrar sus límites. Los primeros artículos del tema en general versan sobre el alcance y las posibilidades de obtener respuestas contradictorias o erróneas, junto a la limitación temporal de no poder brindar respuestas sobre contenidos generados en los años más recientes.
Pero además de estos análisis, realizados muchas veces por legos en el tema, se comenzaron a expandir los experimentos. Las preguntas viraron de ser solo acertijos normales, a tratar de mantener alguna charla con sentido o poner al artefacto a resolver problemas concretos. Sin investigar a fondo del tema me empezaron a llegar entonces demasiados comentarios sobre algunos de estos experimentos, todos trascendidos sin mucho fundamento como para discriminar lo verdadero de lo falso. Para dar algunos ejemplos, desde que estos chat pudieron resolver temas de decisiones legales en base a testimonios de juicios muy difíciles de elaborar para abogados, pasando por cheats code para liberar supuestos límites de sus respuestas, hasta la resolución de código de programación a partir de algoritmos. No me consta la veracidad o resultado exitoso de todos estos casos, pero lo más importante no es la mayor o menor confiabilidad de la herramienta sino el impacto que tiene en las personas que me hacían esos comentarios, de la mano con la inseguridad o sensación de peligro indeterminado que presienten de ella.
Esa sensación que transmitían, de estar viviendo en el presente una experiencia solo atribuible a la ciencia ficción anteriormente, derivó en una idealización de estas herramientas, más allá de las evidencias ciertas. De alguna manera los chat basados en IA dejaron de ser a los ojos de todos una herramienta de asistencia a convertirse en el gurú del siglo XXI. Las expectativas de cada persona puestas sobre estos chat, la colocan en una situación de idealización más allá de la posibilidades reales. Una especie de deificación, donde las convierten en un oráculo para tomar decisiones o pedirle opiniones sobre los temas más absurdos, y entendiendo sus respuestas como opiniones y no una selección sesgada a la respuesta más probable en función de su base de conocimiento.
Esto nos trae al presente dos problemas concretos, la primera y más nociva es sumarle una carga emocional a las respuestas obtenidas, viendo más allá de las palabras que se utilizan. El problema de fondo en esto es que la ansiedad del individuo, que accede a la herramienta para obtener o interpretar un sentido más allá de la respuesta obtenida a efectos de reafirmar un prejuzgamiento subjetivo, puede manipular el sentido de la respuesta al estar dada en un contexto similar a una charla y no un extracto fiel de la información base original. La característica de estar esa respuesta única y sacada de contexto en el ámbito de un diálogo la enmarca irremediablemente a la interpretación sesgada por la metonimia por el sujeto que la recibe. En cierta manera el manejo de contexto limitado de la propia herramienta, manipulada inconscientemente por el operador, deriva en una recategorización del significado que nace de la respuesta. Si a esto le sumamos el natural tono de pontificación en las mismas respuestas, que la mayoría de las veces descartan las opciones alternativas por puntuación de la única más probable, entregan una visión sesgada por la calidad de su base de datos, y esto nos lleva directo al siguiente punto.
El segundo problema y casi inevitable es la mediocrización del conocimiento elaborado a partir de las consultas a la herramienta. Estos asistentes compilan conocimiento en una gran base de datos, que gracias a procesos basados en rutinas modernas de redes neuronales sumados a los novedosos ordenadores cuánticos, llevan a su elaboración de la respuesta más probable que entregan. Por una parte, tener la seguridad de que obtenemos una respuesta basada en la solución más probable, realimentará irremediablemente las mismas bases de conocimientos con el producto humano elaborado en base a sus respuestas previas. La flecha de uniformidad que lleva esta rutina es lo más peligroso. Perdemos la posibilidad de elaborar una respuesta más efectiva o adecuada por un modelo homogéneo elaborado en base a las experiencias previas más comunes. La excepción, lo brillante o genial, queda opacado por la respuesta más masiva, común, que resulte efectiva en la mayor parte de los casos análogos.
Estos intentos de obtener de la herramienta hoy en día una elaboración que sustituya el razonamiento particular, convierte a la herramienta en un sustituto epistemológico frente al individuo, y al individuo mismo en la herramienta que pone en práctica esta maquinaria. Teniendo en cuenta que las bases de datos que las alimentan son necesariamente sesgadas, con la visión de la historia escrita por vencedores, y administradas por las grandes corporaciones, podemos concluir que tanto desde el punto de vista de su evolución y aplicación práctica no constituyen ningún peligro para la humanidad: el peligro siguen siendo las mismas personas que trabajan con o para estas herramientas. Nos podemos preguntar entonces si el sentido común podrá prevalecer por sobre el fanatismo oscurantista de interpretar proféticamente a una enciclopedia moderna.
Al trabajar con datos geográficos, para quienes no están especializados en el tema puede llegar a ser un tema bastante oscuro, y en ciertas ocasiones puede llegar a ser frustrante no tener información conceptual clara de los conceptos básicos. Para mostrar este tema de una forma sencilla les acerco una capacitación que di recientemente, donde vemos algunas definiciones elementales de cartografía, manejo de tipos geográficos en Azure SQL, cálculos de distancias e inclusión en polígonos, además de algunos ejemplos de representación en mapas como en Azure Maps.
Llevamos un cuarto de siglo de la gran transformación del acceso de la información, inicialmente segmentada y limitada, a la llegada de la big data en forma generalizada. Suena impresionante lo del cuarto de siglo, sobre todo para quienes son de mi generación y acompañaron día a día estos cambios ahora parece demasiado tiempo, pero más impresionante es la transformación que obró dentro de las misma organizaciones a nivel operativo. Sobre este último punto, y qué tipo de decisiones toman los niveles directivos en consecuencia es de lo que trata el artículo.
Hoy cuesta imaginar una organización desconectada de la web, manejando información en ordenadores personales e intercambiándolas en soportes magnéticos físicos. Sin embargo esa situación era la que reinaba a principio del siglo XXI en organizaciones pequeñas a medianas. La llegada de internet y el reemplazo de las redes propietarias por la web se impuso rápidamente, obviamente por la economía de costos asociados al cambio, pero a la vez logró conectar por primera vez a cualquier organización montada sobre esta red universal. Los intercambios de información era prácticamente instantáneos en formato puramente electrónico, pero además de eso el costo de almacenamiento se abarató tanto o más, permitiendo que la información se acumulara históricamente en forma muy sencilla.
Para mitigar el manejo de los grandes volúmenes de información se masificó el uso de los almacenes de datos o datawarehouse, de los que hablamos ampliamente en artículos anteriores. Esto trae como consecuencia que cualquier área de una organización necesite acceder y revisar estos almacenes con frecuencia. De ahí viene la gran decisión a tomar desde el nivel Directivo de la organización: el permitir el acceso directo a los almacenes de datos, o solo manejarse en función de la reportabilidad que ofrece. Las dos corrientes tienen sus pro y sus contras, veamos por separado las principales características y diferencias.
El acceso democrático a los datos facilita que se alivien las áreas de Sistemas, dado que la característica de autoservicio permite que cada área organice la información que necesita en función de sus propias necesidades y construya sus propios informes o reportabilidad. Desde un punto de vista de costos aliviar el capital humano de Sistemas sigue en cierto modo la línea de minimizar la injerencia de las áreas de Sistemas en todos los ámbitos, tendencia que revisamos ampliamente en este articulo de recuento histórico, sin embargo obliga a que personal no relacionado a sistemas adquiera conocimientos y experiencia en herramientas de acceso y consultas a los almacenes de datos. Es decir que obliga a estudiar temas que exceden las incumbencias profesionales de los puestos diversos, como ser los contables o de ventas, para poder aprovechar los recursos de información con cierto éxito. Por otro lado, hay un conflicto en el acceso mismo a la información que por consideraciones de seguridad no puede estar disponible en su totalidad a todos los ámbitos, siempre se maneja un gran porcentual de información reservada para áreas específicas. Las soluciones de compromiso para superar estas dificultades son principalmente las siguientes:
Capacitar a personal en temas de leguaje (SQL o Python para consultas/data science principalmente) y comprender modelos de datos dimensionales. Esto trae aparejado el gran problema de tomar con liviandad un tema que de por sí es complejo dentro de carreras universitarias y ámbito laboral de los profesionales de sistemas, para preparar a personal sin conocimientos de base suficientes. Los resultados que se obtienen con esta táctica son generalmente pobres y con una curva de aprendizaje larga y costosa.
Adjuntar a las áreas auxiliares con conocimientos de informática como personal de apoyo exclusivo: esto mejora la carga operativa del personal del área en temas que no son su especialidad, pero trae un sobre costo por sumar colaboradores que no son específicos de estas áreas, que al ser auxiliares operativos tampoco tienen grandes conocimientos. Generalmente serán estudiantes o personal temporario sin compromiso, y con una alta rotación al estar asignados en áreas en las que no pueden desarrollarse o crecer profesionalmente en su especialidad.
Para restringir el acceso a la totalidad de la información, obliga a las áreas de Sistemas de Información o las que estén a cargo de los almacenes de datos a segmentar los permisos en forma minuciosa aumentando la carga administrativa de los accesos y esquemas de seguridad, cuando no debilitándola. El complemento lógico a esta rutina es generar tantos datamart como áreas necesiten acceder, para poder consolidar en forma más visual el conjunto de datos que deben manejar cada una según el área de destino, desviando la función de la arquitectura de un datawarehouse corporativo de optimizar sus esquemas de almacenamiento a replicar de manera redundante la información en los distintos datamart, desvirtuando la misión principal de los mismos por temas puramente administrativos.
Estos tres considerandos generalmente provocan que la idea original se convierta en algo desde inmanejable hasta directamente oneroso e insostenible en el tiempo. Solo pensando que la rotación de las áreas no informáticas obliguen a comenzar los ciclos de capacitaciones internas prácticamente invalida a la larga el primer punto, y las transformaciones de la misma organización que reorganicen cada cierto tiempo su organigrama provoquen situaciones de estrés administrativo sobre los almacenes segmentados, convirtiendo esta política inviable con el transcurrir del tiempo salvo contadas excepciones: en organizaciones de poca rotación y alta madurez estructural.
Veamos ahora la política alternativa, la de un almacén de datos centralizado en un área de información. Bajo este esquema, las áreas no conocen los almacenes de datos sino a través de sus reportes o extracto de datos periódicos obtenidos en forma controlada. El área que administra la información aplica la seguridad según la necesidad del volcado de reportes respectos de las diversas áreas, y no tanto en la administración de los accesos que serán internos de su área, limitados en cantidad y roles mejorando el gobierno de la información. Las áreas no necesitan contar con personal especializado en manejo de modelos de datos o lenguajes de consulta, pudiendo utilizar las herramientas más tradicionales de oficina para operar sin problemas. Este esquema tiene el inconveniente que cada área queda limitada al manejo de datos en cantidades que sean manejables por sus herramientas, no teniendo la oportunidad de explorar en profundidad los datos por fuera de reportes estandarizados históricos, o trabajar con la big data. Veamos cuales son las consecuencias de lidiar o mitigar estas dificultades.
El área de Información (sea una Gerencia de Sistemas o como en mi caso una dedicada a BI) debe tener la capacidad suficiente para poder proveer de reportabilidad oportuna a toda la organización. Es decir que deberá contar con un número de colaboradores que exploten la información a medida de la demanda que tenga de reportabilidad nueva o eventual que surja a través del tiempo. Sí implica hacer crecer en personal el área, pero la ventaja del esquema anterior es que estarán mejor aprovechados dado que satisfacen necesidades en forma transversal y no son dedicados a una área específica cada uno. Mejora la sinergia de equipo y minimizarán los tiempos muertos entre requerimientos. Asimismo al pertenecer a un área de información mejorará la calidad profesional de los colaboradores, bajando además su rotación por estar más incentivados.
Concentrará las tareas de data science, o creará los modelos a explotar por las áreas de negocio. Esto implica que necesitará personal especializado en técnicas emergentes de Machine Learning, IA, o modelos neuronales/cuánticos, lo que alivia a las áreas de negocio a incorporar estas especialidades cada vez más alejadas de sus funciones específicas. Como contrapartida de ello es que los profesionales dedicados a explotar la información por estas técnicas deban comprender muy bien las necesidades de las disciplinas a las que abastecerán con sus modelos, lo que excede las funciones de profesionales de sistemas convirtiendo el área de Información en un ámbito multidisplinario. Esto último no debe sorprender, en gran medida es la culminación de un proceso que se viene dado de hace largo tiempo.
Se perderá en gran parte la opción para las áreas de negocio de hacer su propio “data mining” o exploración intuitiva de datos, salvo para conjuntos de información parciales y perdiendo mucho del contexto general. El estudio de los comportamientos desde la información interna y externa de la organización adquiridas en los almacenes de datos residirá principalmente en el equipo de data science, que deberá dividir sus tareas en satisfacer los requerimientos programados y el apoyo en el estudio eventual de información junto a las áreas de negocio sin necesidad de anticipar un entregable definido. Esto obliga a tener una perfecta administración de los tiempos de proyectos y los de servicio adicional, para no atrasar unos no desatender los otros.
En definitiva, si un área dedicada de Información atiende estas necesidades el rendimiento general, y los resultados obtenidos, mejorarán ostensiblemente respecto a la política analizada previamente. La gran desventaja es que necesita de una gran inversión inicial en tiempo y personal para concretarla, mucho más visible a niveles de presupuestos involucrados en un sector que aparentemente otorga un soporte de funcionamiento de la empresa. Esta última visión es la que llevó a disminuir la importancia de lo que eran las Gerencias de Sistemas, como vimos en el artículo previo desmembrada y minimizada prácticamente a un sector menor de servicios, y que de algún modo se van revirtiendo a medida que aparecen nuevas tecnologías de la información que necesitan de personal ultra especializado para aprovecharlas y no dejar estancada al organización en esquemas obsoletos que tenderán a desaparecer. Para ello deben reformular las incumbencias, y dividir definitivamente los que es el soporte de infraestructura y comunicaciones/redes como Gerencia de Servicios, y rescatar las Gerencias de Sistemas como esqueleto fundamental del flujo de la información de las organizaciones, y ahora también del análisis masivo de datos. Un artículo que detalla en forma completa como una unidad de este tipo se conforma en grandes estructuras organizacionales pueden leerlo en esta página.
El área de Sistemas de Información, con todas las variantes en su nombre que recibió a lo largo del tiempo, sufre una transformación constante pautada no tanto por el desarrollo tecnológico sino como las organizaciones tratan de incorporarlas. Para saber hacia donde se dirige conviene hacer un rápido recuento del tratamiento que recibió en todo este tiempo.
Como vamos hacer un poco de historia no debidamente documentada, el artículo de hoy refleja subjetivamente lo que vi y viví desde mis experiencias las de mis colegas. Al mejor estilo de la tradición oral, la historia se cuenta de boca en boca y agrega, o en algunos casos quitas, pinceladas de lo que va ocurriendo. Pero como los pueblos que mantienen sus memorias, no se dejan llevar por los discursos del momento y comprenden por analogías la situación que los enmarca mucho mejor que aquellos que las pierden o se les oculta.
Como bien sabemos, la disciplina de Sistemas nace de la mano de L. Van Bertalanffy desde el ámbito de la biología hacia los años 40 del siglo pasado, para extenderse rápidamente por todas las disciplinas imaginables. Las primeras en las que toma envergadura son las relacionadas a los Sistemas de Información, asociados generalmente a la Informática y que por un tema temporal, quizás no tan casual, se incorporan de la mano en la grandes organizaciones. Departamentos Informáticos iniciales, casi experimentales, se insertaron vertiginosamente alcanzando en menos de veinte años el estatus de Gerencias por derecho propio. El manejo de la información no es un tema de estatus, sino que implica poder y las Gerencias de Sistemas los aprovecharon para posicionarse hacia los 70 del siglo pasado como pilares de la estructura organizacional. Del mismo modo que ganaron importancia, las principales consultoras financieras incorporaron entre sus habilidades las de asesoramiento en temas informáticos, y entre los años 80 y hasta finales del siglo pasado la posición de Consultor Informático ocupaba un lugar de privilegio entre el staff de estas entidades.
Ahora bien, el crecimiento desmedido en una disciplina nueva que muy trabajosamente lograba ciertas estandarizaciones llevó a un escenario final de conflicto, donde las organizaciones más allá de los grandes mainframes (generalmente del ámbito bancario) contaban con sistemas de información básicamente propietarios, desconectados entre sí, y con un pobre mantenimiento en manos de unos pocos expertos. Lo más parecido a un caos, que no acompañaba la dinámica del cambio de siglo. El inicio del presente siglo encabezó una importante transformación para despejar la situación cada vez más inmanejable, se intentaron estandarizar mejor la mensajería de interconexión de sistemas, con el XML como gran unificador. Pero además se complementó esta política con la oportunidad de nicho que hallaron los principales desarrolladores de software en masificar los productos “enlatados” que gracias una adecuación por configuración inicial se podían adaptar a la realidad de cualquier empresa. Esta alternativa tuvo un éxito comercial increíble, la gran mayoría de las organizaciones migraron sus aplicaciones propietarias a estos productos para librarse del dolor de cabeza que les traía aparejado, cuando no el estancamiento que los inmovilizaba tecnológicamente. Una consecuencia de migrar los sistemas propios a productos trajo tres consecuencias, obligaba prácticamente en delegar la instalación y puesta en marcha en consultoras externas a falta de personal propio experimentado en los nuevos productos, los consultores experimentados se sustituyeron por personal técnico de instalación y soporte desplazando profesionales especializados en proyectos por mano de obra por servicio; y por último el papel esencial que oficiaban las Gerencias de Sistemas se vieron debilitadas y divididas en departamentos de Servicios y Comunicaciones por un lado, y Jefaturas de Proyectos Informáticos dependientes en gran medida como departamentos subordinados a las Gerencias de Finanzas, dedicados solo a la coordinación de los servicios tercerizados.
Sin embargo estos productos world- class no resultaron tampoco el paraíso, si bien aliviaron inicialmente el gran dolor, llevaron a los largo de los últimos veinte años al debilitamiento de las prácticas de Sistemas de Información internas de la empresa, y una profusión de sistemas enlatados de difícil interconexión entre ellos. Este panorama no podría ser más negativo si se le suma el gigantesco volumen de datos que proviene de la web, y el histórico acumulado por las mismas organizaciones, lo que lleva a un escenario en el que nuevamente se vislumbra una nueva crisis. La dependencia con las consultoras externas llega a niveles de costos siderales, donde la cantidad de equipo involucrado desde ambas partes hace nuevamente inmanejable y directamente convierte en pérdidas cualquier iniciativa informática, fracasando no pocas veces en el intento. Los productos enlatados que se adquirieron como una solución adaptable, en la mayoría de los casos lleva a las empresas a adaptar sus procesos internos para poder utilizar el producto. En tren de abaratar los costos, las Consultoras disminuyen la calidad de la mano de obra minimizando remuneración y márgenes de ganancia, llevando a los consultores actuales a rotar rápidamente sin llegar a tomar experiencia. Como contraparte, las áreas de Sistemas disminuidas en importancia dentro de la organización a su vez no llega a conformarse con buenos expertos, constituidas esencialmente con administradores de proyectos con poca y nada visión de completitud del flujo de la información dentro de la organización. Finalmente las decisiones sobre el mismo flujo de la información, se toman por comisiones mixtas entre personal de las Gerencias de Finanzas, que además del departamento de Sistemas también dirige las de Métodos y Procesos las que también se desnaturalizaron asimiladas a solo funciones de auditoría internas.
Si la organización en la que trabajas se asemeja en todos o en parte al último escenario descrito, no es para sorprenderse o que son parte de una excepción. la gran mayoría de las organizaciones están en este momento atravesando problemas similares. Hubiera gustado de hacer alguna conclusión más optimista de la etapa actual, pero la situación no lo permite. Aunque tampoco debemos quedarnos con la idea que todo está perdido. En general las organizaciones intentan sobrevivir, como ya lo mencioné en artículos anteriores, y reaccionan oportunamente para introducir los cambios necesarios. ¿Son estos cambios algo misterioso a lo que no tenemos acceso? Nada más lejos que eso, la solución siempre está en la teoría de los Sistemas de Información, solo se necesita rescatar estos principios y que vuelvan a tener la relevancia inicial que perdieron al asociarse casi exclusivamente a técnicas informáticas. Parte de este resucitar se viene dando inicialmente por la disciplina de Inteligencia de Negocios o BI (no confundir con sus ramas vecinas de Marketing o Comerciales), que de la mano de los Cuadro de Mandos Integral intenta unificar la gestión con el flujo dando de la información en la organización, y que tomando asimismo el rol de la Arquitectura de Datos hoy se convierte en la piedra angular para dominar el escenario inmediato. Sobre este último punto conviene leer un paper de IBM sobre el tema, que da un pantallazo donde materializa un tema que se viene dando de hecho en los sistemas de BI, y que describo con lujo de detalle al menos desde este blog desde hace más de diez años.
Si se preguntan cómo puedo atreverme a indicar la dirección de salida para esta situación, les comento que en la empresa en la que me desempeño actualmente tomamos este último camino, una misión que me encomendaron cuando ingresé hace unos tres años, ayudando no solo a transitar la pandemia con éxito sino que también ordenando y encauzando el flujo de la información interna, con grandes hitos cumplidos y con una perspectiva inmediata de lo más promisoria.
Un ejemplo genérico de esquema basado en una Arquitectura de Datos centralizada
Informática y Sistemas (β) 