¿Es la gestión de proyectos un mito?
Hay un conjunto de razones que están cambiando en muchas empresas la manera de ver la gestión de proyectos y la gestión de las TI en su totalidad. Desde el lado de la demanda: la presión de los clientes internos (los líderes de negocio) por el tiempo de respuesta (el time-to-market), las TI de en la sombra (el shadow IT) y las soluciones de usuario final y autoservicio, entre otras. Desde el lado de la oferta: los modelos de entrega continua (continuous delivery y DevOps), la construcción ágil, las nuevas fórmulas de subcontratación (outsourcing), la interdependencia de las plataformas de software y las nuevas arquitecturas de componentes, entre otros.
Según Gartner, las empresas vienen a gastar un 77% del presupuesto de informática en el funcionamiento ordinario de las operaciones (el run), un 13% en el mantenimiento y evolución del parque de activos (el grow) y sólo un 10% en la transformación y creación de nuevos productos (el transform).
A mí (que he dedicado una parte de la carrera a la gestión de proyectos en la docencia, en la consultoría y en la gestión, y sobre la que he publicado algunos libros (1, 2), artículos, materiales y un montón de entradas en este blog) estos datos y tendencias me hacen dudar y me provocan. Y quiero compartir esta provocación con vosotros. Puede que alguno de los principios de oro en que se basó la gestión de proyectos estén ahora en cuestión y, con ellos, la profesión. Comencemos hoy y, si os interesa y me voy animando, seguiremos otros días.
Un proyecto es una entidad única, distinta y separada de las operaciones. Creo que hoy esto no es ya así. La mayoría de los proyectos son una evolución o una variación de un activo existente. Una parte muy importante de las actividades del proyecto, si no la mayoría a veces, son cambios de estado del software e integraciones con otras aplicaciones, que nos cuesta prever y medir dentro del proyecto. Y un número grande de proyectos, sobre todo los basados en producto estándar, son más o menos replicables (excepto precisamente la customización y la integración).
Una cosa es la gestión del proyecto y otra cosa es la ejecución y producción de software. Creo que esto no es así, si lo fue alguna vez. La ejecución representa la mayoría del esfuerzo (en duración y coste) y cuesta pensar que, después de la planificación, eso se pueda delegar en el equipo de desarrollo y luego ponerse a contar horas, hacer actas y encender semáforos. El software ya no se hace de esta manera, o se hace pocas veces. Y si no queremos que el jefe de proyecto se remangue y baje a la arena, entonces necesitamos alguien que lo haga y debemos sustituir al jefe de proyecto por un controller.
Un proyecto tiene un principio y un final. Por desgracia, esto no es verdad. En el mejor de los casos, tiene un principio. Actualmente los proyectos no se acaban o, cuando se acaban, es porque hemos decidido administrativamente darlos por acabados y pasárselos a otra gente, que no participó en su creación y que no sabe muy bien qué hacer, porque no tiene el conocimiento funcional y técnico. ¿Por qué? Sólo para poder decir que lo hemos acabado. Pero esto no tiene que ver con lo que el cliente necesita y, muy frecuentemente, tampoco con lo que pidió.
El triángulo de hierro: alcance, tiempo y coste. Esta es otra de las reglas de oro. Si se toca el alcance o el tiempo, se afecta el coste. Si se reduce el coste o el tiempo, se reduce el alcance. Alargamos los anteproyectos, para desesperación del cliente y de los equipos, porque suponemos que sabremos mejor lo que hay que hacer y cuánto cuesta. Como consecuencia, a veces el anteproyecto es más largo y más caro que el propio proyecto. También nos pasa con el análisis funcional, que a veces se come todo el presupuesto. Y con todo esto, por desgracia, no sabemos mucho mejor lo que se hará o, si lo sabemos, cambiará enseguida.
Otro día podemos hablar de la ilusión de la predictibilidad, del valor “ganado”, del famoso PDCA, del reporting, de la gestión de riesgos y, al final, de la misma figura del jefe de proyecto… E incluso aportar, en medio de las frustraciones, algunas vías de solución.
José Ramón Rodríguez es profesor de dirección de las TIC en diferentes programas de la UOC y consultor independiente. Investiga la planificación y gestión de proyectos de transformación empresarial facilitados por los sistemas y tecnologías de la información.
III Fórum Industria 4.0
El pasado viernes 1 de junio se celebró en el Espacio Endesa de Barcelona la tercera edición del Fórum Industria 4.0. Para aquellos que no lo conozcáis, el Fórum Industria 4.0 es una cita anual impulsada por la Comisión Industria 4.0, una organización integrada por los cinco colegios de ingeniería de Catalunya (Agrónomos, Caminos, Industriales, Informáticos y de Telecomunicación), donde se presentan las últimas tendencias en el ámbito industrial con el objetivo de potenciar su desarrollo y adopción por parte de las empresas de nuestro territorio.
El acto, al que asistieron unas 400 personas, lo inauguraron Joan Carles Casas, presidente de la Comisión Industria 4.0, y Joan Romero, consejero delegado de ACCIÓ, la oficina de promoción económica de la Generalitat de Catalunya. De la intervención de este último cabe destacar la promesa, por parte de ACCIÓ, que Catalunya estaría presente en la próxima edición de Hannover Messe con el objetivo de aumentar la visibilidad internacional de la industria local.
Misión inversa de conocimiento en la Hannover Messe
La jornada siguió con las presentaciones de los diferentes grupos de trabajo de la Comisión Industria 4.0 (robótica, fabricación aditiva, sistemas embebidos y software) donde se presentaron las observaciones de la misión inversa de conocimiento realizada en la Hannover Messe de este año.
Carles Soler, del grupo de trabajo de robótica, empezó destacando la generalización en la utilización de sistemas en la nube para la monitorización de la base de robots instalada, y la consolidación de China como actor de relevancia mundial en el sector. Además, también mencionó la incorporación de sistemas de realidad aumentada para la interacción con los robots y la aparición de exoesqueletos que amplían las capacidades físicas del operario.
Por su parte, Felip Fenollosa, del grupo de trabajo de fabricación aditiva, destacó la relevancia de la comunidad local en el campo de la fabricación aditiva en los avances a nivel internacional. También apuntó que en el futuro inmediato la actividad del sector se centrará en el desarrollo de nuevos materiales que permitan crear nuevas soluciones más que nuevas iniciativas de maquinaria para fabricación aditiva –impresoras–.
A continuación Xavier Pi, del grupo de trabajo de sistemas embebidos, explicó la evolución de los buses de campo industrial hacia las tecnologías de comunicación deterministas y los protocolos de comunicación integrados. Tal como explicó, actualmente, en la práctica, hay dos estándares predominantes: Time Sensitive Networks (TSN) y OPC-UA. En caso de OPC-UA ya existen implementaciones completas en el mercado, pero para TSN las implementaciones son parciales debido a que los estándares no están finalizados.
Finalmente, Michael Loughlin, del Grupo de Software, destacó la entrada de interesantes start-ups en el ámbito industrial con propuestas que permiten aplicar la inteligencia artificial a los datos de planta para facilitar la toma de decisiones. Además, también remarcó que en esta nueva era de la industria digital, la decisión de proveedor/partner de software es tan importante como la decisión de la estrategia digital de la planta.
La jornada fue también el marco elegido para presentar el nuevo grupo de trabajo de Agricultura 4.0 de la mano de Fran García, que ahondó en el impacto que las tecnologías 4.0 en la agricultura: sensores para dar seguimiento al ganado, polinización a través de microdrones y visión artificial para detectar los cultivos que necesitan productos fitosanitarios, entre otros. Tal y como explicó, el agrícola es un sector que tiene maquinaria inteligente pero le falta conectividad para sacar provecho a los datos que se generan. Además, la conformación de las empresas –un 90% son microempresas– plantea un desafío a los proveedores para dar soluciones escalables.
Reflexiones sobre la industria y su digitalización
Después de la pausa para el café, Carles Soler, del grupo de trabajo de robótica, Pere Tuset, director académico del Máster en Industria 4.0 de la UOC-TecnoCampus, y Xavier Pi, codirector académico del Máster en Industria 4.0 de la Universitat Politécnica de Catalunya, compartieron la mesa redonda “Reflexiones en voz alta sobre la Industria 4.0”.
Fue una conversación distendida, conducida por Carles Soler, que arrancó con la constatación que el avance tecnológico en el ámbito industrial se está produciendo en tres ejes: un eje de “átomos” que se corresponde al mundo de los sistemas físicos; otro de “bits” que se corresponde con el mundo de los sistemas informáticos y, finalmente, otro de “electrones” que se corresponde al mundo de los sistemas de telecomunicación. El avance de las soluciones en estos ejes es asimétrico en tiempo e intensidad, por lo que no todas las soluciones aportan el mismo valor a los diferentes verticales.
Así pues, vemos cómo hoy en día las empresas tienen tres estrategias de digitalización: aquellas que están a la espera que las propuestas se consoliden (una estrategia “arriesgada” en opinión de los expertos), empresas que están en una fase de evaluación (realizando pruebas a nivel de piloto con diferentes tecnologías) y, finalmente, aquellas que apuestan por asumir el paradigma 4.0 de manera radical y ya han implantado soluciones en producción.
Premio Industria 4.0
La segunda parte de la jornada estuvo dedicada a presentar los proyectos finalistas del Premio Industria 4.0 que otorga la Comisión Industria 4.0: Data-Driven Steel 4.0 de CELSA Barcelona Group, MICO24 Nano de Effitronix y InPicker de Infaimon. El ganador fue Effitronix con el proyecto “Principio del formulario Productividad, eficiencia y mantenimiento predictivo con MICO24 Nano”, mientras que el primer accésit fue para Infaimon y el segundo para Celsa Group.
Tal y como detallaron desde Effitronix, una de las principales barreras en el proceso de digitalización de las plantas es la duración y la inversión de los proyectos de implantación de soluciones digitales. Así pues, el dispositivo MICO24 Nano es el resultado de un proyecto de alrededor de dos años que tuvo como objetivo eliminar dos de las principales barreras con las que se topan las empresas industriales a la hora de acometer un proyecto 4.0: el tiempo de puesta en marcha y la inversión. A través de diferentes señales capturadas, el MICO24 Nano realiza un control del proceso (para producción), del producto (para control de calidad) y de la máquina (para mantenimiento predictivo) las 24 horas del día los 7 días de la semana, obteniendo un control total de la maquinaria.
El beneficio aportado por la propuesta es claro: los primeros clientes que han apostado por el MICO24 Nano en sus máquinas han constatado que en los seis primeros meses de uso han eliminado en un 100% sus paradas imprevistas, han aumentado entre un 10% y un 15% sus ratios de producción, han reducido entre un 8% y un 10% el consumo energético, han reducido entre un 5% y un 10% los costes de fabricación, y en todos los casos, han destacado su rápida puesta en marcha, la total personalización de la plataforma así como su facilidad de uso, e inmediatez de los resultados.
Finalmente Sílvia Burés, Degana del Col·legi d’Enginyers Agrònoms, clausuró el acto haciendo incidencia en el carácter transversal de la cuarta revolución industrial y en la oportunidad y reto de aumentar la participación de la mujer en los nuevos perfiles profesionales que ésta ya está requiriendo.
Esta noticia es un extracto de la crónica publicada en la revista digital InfoPLC++.
Xavier Pi es Ingeniero Industrial por la Universitat Politècnica de Catalunya (UPC) y consultor de la UOC.
Pere Tuset-Peiró es doctor en Tecnologías de la Información y las Comunicaciones por la Universitat Oberta de Catalunya. Es profesor lector de los Estudios de Informática, Multimedia y Telecomunicación, e investigador del Grupo Wine (Wireless Networks) en el Internet Inter-disciplinary Institute, ambos de la Universitat Oberta de Catalunya. Su actividad docente e investigadora se centra en el ámbito de los sistemas ciberfísicos aplicados a la industria, incluyendo los sistemas empotrados, las redes de comunicaciones y el procesamiento de la señal.
Introducción a Cypher
Ahora que ya conocemos las características de las bases de datos NoSQL en grafo, y tenemos Neo4j instalado y funcionando, es el momento de empezar con Cypher.
Cypher es un lenguaje declarativo, inspirado en SQL, que permite manipular datos en Neo4j. Es aconsejable tener a mano la guía de referencia de Cypher siempre que estemos trabajando con Neo4j. Esta guía recoge la sintaxis y la semántica de las sentencias y funciones disponibles en Cypher. Hay que tener en cuenta que existe una guía de referencia (refcard) para cada versión de Neo4j (nosotros hemos elegido la guía de referencia para Neo4j versión 3.4).
Antes de continuar os animamos a que abráis el browser de la base de datos que creamos en la segunda entrada. En el siguiente vídeo mostramos cómo abrir el browser y explicamos los elementos básicos del entorno de trabajo de Neo4j.
Ahora que ya conocemos la interfaz es el momento de empezar a trabajar con datos. Lo primero que vamos a hacer es aprender a crear nodos y relaciones en Neo4j. Para ello tendremos que usar la cláusula CREATE. Por ejemplo, empezamos ejecutando la siguiente sentencia:
¿Qué es lo que se ha creado? Podemos averiguarlo mediante la siguiente consulta:
La sentencia anterior nos devuelve todos los nodos de la base de datos. En este caso nos ha devuelto un nodo, el que acabamos de crear. Pero, ¿qué información tiene ese nodo? Pues la verdad es que ninguna, es un nodo vacío. Sin tipo y sin propiedades (o atributos). Un nodo sin información por lo general no tiene mucho sentido, por lo que vamos a aprender cómo añadir atributos (propiedades) a un nuevo nodo.
Para añadir un conjunto de propiedades a un nuevo nodo, se indica el conjunto de propiedades y sus valores en formato JSON. Por lo tanto, si quisiéramos crear un nodo para almacenar los datos de Jordi Conesa, deberíamos incluir en la definición del nodo los siguientes atributos y valores:
Ahora crearemos un nodo con esta información asociada.
Una vez creado, si volvemos a ejecutar la sentencia:
Obtendremos los dos nodos creados hasta ahora. Puede parecer que los dos nodos son iguales, pero no es así. Si hacéis click en uno de los nodos (como en la siguiente figura), veréis que uno de ellos contiene algunas propiedades (ver la parte inferior izquierda de la pantalla). El otro nodo, en cambio, está vacío.
Ahora crearemos un nodo con la siguiente información asociada:
Pero, ¿cómo podemos indicar a Neo4j que queremos que nos muestre por pantalla el nodo que acabamos de crear? La manera de hacerlo es mediante variables. En Cypher, se pueden utilizar variables para identificar los elementos que aparecen en las cláusulas CREATE. Si queremos mostrar por pantalla alguno de los nodos que aparece en la cláusula CREATE, podemos asignarle un nombre de variable y luego referenciar esa variable en una cláusula RETURN. Las variables se asignan a los nodos indicando un nombre de variable antes de la definición de sus propiedades. En la siguiente sentencia definimos la variable p en la sentencia CREATE. Después, al hacer un RETURN p, estamos indicando a Neo4j que el nodo a mostrar es el que contiene los datos que acabamos de crear. Probad a ejecutar la siguiente sentencia:
Si hacéis click sobre el nodo resultante, veréis que tiene los datos de María Elena.
El uso de variables en Cypher es necesario cuando hay que utilizar los datos que definimos en la cláusula CREATE en otra parte de la sentencia. En ejemplo previo, si os fijáis, necesitamos referenciar el nodo que estamos creando en la cláusula RETURN (con el objetivo de consultarlo), de aquí la necesidad de usar la variable p.
Bien, ya sabemos crear nodos, pero ¿cuál es el tipo de los nodos? Vaya, no lo sabemos. No hemos indicado el tipo de los nodos cuando los hemos creado… Eso quiere decir que los nodos creados no tienen ningún tipo, es decir, carecen de semántica (o si preferís, carecen de significado). Si pobláramos de esta manera la base de datos, no tendríamos manera de saber qué personas hay en la base de datos. La pregunta es ¿cómo creamos un nodo con tipo?
Muy fácil, hay que indicar el tipo del nodo en la cláusula CREATE antes de sus propiedades (en caso de que haya) y después de su variable (en caso de que se haya indicado). Vamos a crear un nuevo nodo para Jordi Conesa pero, en este caso, indicando que Jordi Conesa es una persona:
La sentencia anterior crea un nodo de tipo persona (:Person) con las propiedades name, age y city. Tal y como comentamos en la anterior entrada, los nombres de etiqueta siempre tienen “:” como prefijo en Cypher.
Si observamos el nodo devuelto por Neo4j, vemos que el formato es más atractivo con un color asociado a su tipo. En la parte superior izquierda se puede ver el nombre de la etiqueta. Si hacemos click encima de dicha etiqueta podemos cambiar el color y el tamaño de los nodos de ese tipo y también qué propiedad queremos utilizar como caption (el valor que se muestra dentro de los nodos). A continuación podéis ver el nodo original y el nodo después de cambiar su color y tamaño.
Como podéis imaginar, el hecho de cambiar el color, el tamaño y el caption de los nodos es meramente estético, pero ayuda a la interpretación de los datos, especialmente a medida que la base de datos se hace más y más compleja.
Si quisiéramos crear más de un nodo, podríamos añadir los distintos nodos a crear dentro de una misma cláusula CREATE, separados por comas. Por ejemplo, en la siguiente sentencia se crean dos nodos (uno para María Elena Rodríguez y uno para la editorial Auca Digital) y una relación entre ellos para indicar que a María Elena le gustan los libros de Auca Digital.
Podemos ver que la cláusula CREATE tiene tres elementos, con los siguientes nombres de variable er (para el nodo de María Elena), ad (para el nodo de Auca Digital) y un tercer elemento que tiene la forma (er)-[:LIKES]->(ad).
Cypher intenta representar textualmente patrones gráficos que nos encontramos en los grafos. Por ejemplo, en Cypher se podría representar que un nodo a está relacionado con un nodo b mediante el siguiente texto: (a)–(b). En este caso se indica que hay dos nodos relacionados (si preferís, conectados a través de una relación), pero no se indica ni el sentido ni el tipo de la relación. Si queremos indicar el sentido de la relación podemos poner un < o un > en uno de sus extremos. Así, tendríamos que (a)–>(b) indica que hay una relación que va de a a b y (a)<–(b) indica que hay una relación que va de b a a. Si queremos, además, indicar que la relación debe ser de un tipo concreto, tenemos que poner su tipo entre corchetes [] dentro de la relación. Por ejemplo (a)-[:LIKES]-(b) indicaría que hay una relación de tipo LIKES que va de a a b.
Teniendo en cuenta lo que acabamos de explicar, puede verse que el tercer elemento ─(er)-[:LIKES]->(ad)─ de nuestra sentencia CREATE, indica que debe haber una relación de tipo LIKES que va del nodo de María Elena Rodríguez (porque a la izquierda de la relación hay la variable del nodo de María Elena) al nodo de Auca Digital (ya que a la derecha de la relación hay la variable del nodo Auca Digital). Como este elemento está en una cláusula CREATE, estamos diciendo que queremos crear esta relación entre los dos nodos. Como consecuencia, se crearía el nodo de María Elena, el nodo de Auca Digital y la relación LIKES, tal y como se ve en la siguiente figura:
Como se ve en la figura, el resultado muestra los nodos y la relación creada. Quizás os preguntéis por qué se muestra la relación si en la cláusula RETURN sólo se referenciaban los nodos creados. El hecho es que el entorno de Neo4j, por defecto, cuando muestra un conjunto de nodos “pinta” todas las relaciones que hay entre estos nodos automáticamente.
Pues bien, ya somos capaces de añadir nodos y relaciones en Cypher. Ahora os proponemos un reto. La sentencia que os indicamos a continuación añade un nodo para Jordi, otro para María Elena, otro para una entrada del blog de Informática++, y relaciones que indican que Jordi y María Elena han escrito una determinada entrada. Os pedimos que cambiéis los <…> (marcados en negrita en la sentencia suministrada) por fragmentos en Cypher para añadir un nodo que os describa (como :Person), y una relación que indique que habéis leído la entrada con variable myPost. Además, deberéis añadir un nombre de variable en la cláusula RETURN para devolver el nodo creado (el nodo que os representa).
En el caso de que os resulte difícil, os animamos a estudiar atentamente la sentencia de ejemplo que había al final de la entrada anterior. Facilitará mucho las cosas 😉
Hasta aquí esta tercera entrada sobre Neo4j. En ella hemos aprendido cómo crear nodos y relaciones entre nodos en Cypher. Con lo que hemos visto hasta ahora, cuando queramos crear una relación deberemos crear a la vez los nodos. Para crear relaciones sobre nodos que ya existen en la base de datos deberéis esperar hasta la siguiente entrada, ya que para ello hace falta conocer cómo funcionan las consultas. Y las consultas las trataremos la próxima semana.
En el caso de que queráis obtener más información e ir avanzando, podéis visualizar el siguiente vídeo. Una vez sepamos cómo realizar consultas, cargaremos una base de datos de películas proporcionada en Neo4j y aprenderemos a realizar consultas más complejas y de forma eficiente.
Jordi Conesa es profesor de los Estudios de Informática, Multimedia y Telecomunicación en la UOC y coordinador del ámbito de data science del eHealth Center. Su docencia se enfoca a las áreas de bases de datos, ciencia de datos e ingeniería del software y su investigación en el análisis de datos y el eLearning.
M. Elena Rodríguez es profesora de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y forma parte del proyecto TeSLA, participando en tareas que se centran en el diseño del sistema TeSLA y en el desarrollo de pruebas piloto en la UOC. Licenciada en Informática por la Universitat Politècnica de Catalunya y doctora por la Universidad de Alcalá, sus áreas de conocimiento e investigación incluyen las bases de datos y la ingeniería de ontologías para el desarrollo de sistemas de e-learning basados en estándares.
Introducción a Neo4j
Ahora que ya conocemos las principales características de las bases de datos NoSQL en grafo y del modelo de datos que utilizan es el momento de ver, mediante ejemplos prácticos, cómo almacenar y manejar datos en estas bases de datos. En esta entrada comentaremos las principales características de Neo4j, veremos cómo instalar Neo4j en nuestro ordenador y cómo crear una base de datos y empezar a “jugar” con ella.
Actualmente, Neo4j es la base de datos en grafo más popular según el ranking de db-engines.com. A fecha 2018, también es el número 21 de 295 en el ranking general de bases de datos.
El modelo de datos utilizado por Neo4j es un grafo de propiedades etiquetado. Por tanto, las unidades básicas de procesamiento en Neo4j son las mismas que explicamos en la entrada anterior: nodos, relaciones entre nodos, propiedades (definidas sobre nodos o relaciones) y etiquetas que permiten definir el tipo de los nodos y de las relaciones.
En Neo4j se utilizan los dos puntos “:” para representar las etiquetas. Por lo tanto, :Book, :Person y :HAS_READ, representarán las etiquetas Book, Persony HAS_READ. Por otro lado, para distinguir fácilmente las etiquetas de nodo de las de relación, en Neo4j se escriben las etiquetas de relación en mayúsculas y las etiquetas de nodo con la primera letra en mayúscula y el resto en minúsculas. Así pues, Book y Person serían etiquetas de nodo y HAS_READ una etiqueta de relación que representa qué libros (nodos de tipo :Book) ha leído una persona (nodo de tipo :Person). Las propiedades acostumbran a representarse en minúsculas.
Neo4j es una base de datos schemaless. Esto no quiere decir que la base de datos no utilice un esquema sino que este esquema es flexible y no es necesario que esté prefijado ni definido antes de la introducción de nuevos datos, lo cual permite que las modificaciones (o alteraciones) del esquema se puedan realizar fácilmente. Por lo tanto, los nodos de un mismo tipo pueden tener propiedades distintas (un nodo que representa a una persona de España podría tener una propiedad para representar el DNI, y otra con nacionalidad de EEUU no tendría la propiedad DNI sino una llamada driverLicense).
Aun siendo schemaless, en Neo4j, el esquema tiene bastante protagonismo. Por un lado, las etiquetas permiten indicar el tipo de los nodos y las relaciones. Esto obliga a que los diseñadores deban pensar con detenimiento, antes de crear la base de datos, qué tipos de nodo y de relación se van a tener que representar, cuáles son sus principales propiedades, y escoger una etiqueta para cada uno de ellos. Por otro lado, en Neo4j, el esquema puede utilizarse para indicar algunas restricciones de integridad. A día de hoy (junio de 2018) las restricciones de integridad soportadas son las siguientes:
- Unicidad: permite indicar que el valor de una propiedad debe ser único para todos los nodos del mismo tipo. Por ejemplo, se podría indicar que no pueden haber dos libros con el mismo ISBN (en otras palabras, no existen dos nodos de tipo :Book con el mismo valor para la propiedad isbn).
- Existencia: permite indicar que una propiedad (o un conjunto de ellas) debe existir para todos los nodos de un tipo. Por ejemplo, se podría indicar que todo libro debe tener un ISBN y un título (todos los nodos de tipo :Book deben tener las propiedades isbn y title).
- Clave: permite indicar que una propiedad es clave para todos los nodos de un determinado tipo, es decir, que todos sus nodos deben tener definida la propiedad y que el valor de la propiedad es único. Por ejemplo, la propiedad isbn es una clave para los nodos de tipo :Book. La diferencia entre la restricción de integridad de unicidad y clave es que la primera no requiere que la propiedad se defina pero, si se hace, el valor asociado no puede repetirse. Para aquellos que estéis familiarizados con las bases de datos relacionales, la restricción de unicidad se corresponde con la restricción de UNIQUE, mientras que la de clave se corresponde con la restricción de PRIMARY KEY.
Neo4j permite acceder a sus datos de diversas formas y usando distintos lenguajes de consulta. Se puede acceder a sus datos desde una consola de texto, un entorno web gráfico (el que utilizaremos en estas entradas) y mediante APIs. Respecto a sus lenguajes de consulta, destacamos Cypher, que es un lenguaje declarativo que permite consultar y manipular grafos, y Gremlin, que es un lenguaje específico de dominio para la gestión de grafos.
En Neo4j, para identificar un conjunto de datos sobre los que aplicar una operación, se realiza lo que se denomina graph traversing. Podríamos traducir este concepto como “navegación por el grafo” y es la acción de navegar por el grafo -a partir de un punto de inicio (o un conjunto de puntos de inicio)- lo que permite obtener los resultados deseados (es decir, obtener los elementos sobre los cuales realizar la operación).
Bien, ahora que ya tenemos las nociones básicas de Neo4j es el momento de instalarlo y empezar a practicar. Para ello os animamos a instalar Neo4j desde la siguiente página web: https://neo4j.com/download/. En el siguiente vídeo tenéis un pequeño tutorial, paso a paso, que explica cómo instalar y empezar a utilizar Neo4j.
Una vez hayáis creado vuestra base de datos (tal y como se explica en el vídeo), os animamos a copiar y pegar la siguiente sentencia Cypher en la interfaz de Neo4j para que veáis lo fácil que es crear nodos, relaciones y visualizarlos. No os preocupéis si no entendéis completamente el código: en las siguientes entradas “destriparemos” Cypher y aprenderemos a hacer sentencias como esta y otras más complejas.
¡Felicidades! Habéis creado vuestra primera base de datos en Neo4j. Os debería haber salido algo parecido al siguiente grafo:
Hasta aquí esta segunda entrada sobre Neo4j. En el caso de que queráis obtener más información e ir avanzando, podéis visualizar este vídeo. En la próxima entrada veremos cómo funciona el lenguaje Cypher y crearemos una nueva base de datos (ya siendo conscientes de lo que estáis haciendo en cada momento). Más adelante cargaremos una base de datos de películas proporcionada en Neo4j y aprenderemos a realizar consultas más complejas y de forma eficiente.
Jordi Conesa es profesor de los Estudios de Informática, Multimedia y Telecomunicación en la UOC y coordinador del ámbito de data science del eHealth Center. Su docencia se enfoca a las áreas de bases de datos, ciencia de datos e ingeniería del software y su investigación en el análisis de datos y el eLearning.
M. Elena Rodríguez es profesora de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y forma parte del proyecto TeSLA, participando en tareas que se centran en el diseño del sistema TeSLA y en el desarrollo de pruebas piloto en la UOC. Licenciada en Informática por la Universitat Politècnica de Catalunya y doctora por la Universidad de Alcalá, sus áreas de conocimiento e investigación incluyen las bases de datos y la ingeniería de ontologías para el desarrollo de sistemas de e-learning basados en estándares.
Estrategia de SI: ¿qué evaluamos cuando evaluamos?
Estamos dedicando una temporada a la formación de la estrategia de sistemas de información, o sea, los procesos sociales y organizativos mediante los cuales las empresas hacen estrategia, que pueden incluir o no procesos más o menos explícitos de formulación y ejecución de la estrategia.
De lo poco que sabemos, los principales problemas relacionados con la implantación tienen que ver avasalladoramente con la ausencia de soporte sostenido de la alta dirección, la dificultad de medir los resultados y beneficios del plan, la falta de flexibilidad para adaptarse a las nuevas estrategias de la empresa, problemas de dedicación, calidad y compromiso de los recursos del negocio y de TI, el complicado diálogo entre ambas partes y cuestiones políticas y organizacionales. Os recomiendo la lectura de los papeles más clásicos de Wilson, Teo y Ang y Luftman y Brier.
Hablemos hoy de la evaluación. Si vale mi experiencia, la evaluación es una buena oportunidad para recrear el ciclo de planificación y dirección estratégica de los sistemas y aumentar o, al menos, mantener la tensión (el momentum, que dicen los anglosajones) del plan y el compromiso de la dirección. Es un ejercicio tanto de planificación como de gobernanza.
El problema es que la medición de resultados, en la informática y en la vida, tiene muchas dimensiones y para cada contexto y nivel de madurez de la organización tenemos que elegir entre un repertorio. Y encima, disponer del tiempo, de los datos y del compromiso de la gente para hacer un ejercicio que no suele ser cómodo.
1. Lo primero que deberíamos medir es si hemos conseguido el famoso alineamiento estratégico, o sea hasta qué punto la ejecución de la estrategia de TI ha contribuido a las estrategias de empresa (crecimiento, diferenciación, eficiencia, foco, entrada en nuevos mercados…) y cómo se ha adaptado a los cambios. Las métricas son complicadas, por indirectas o por cualitativas.
Se pueden establecer matrices de impacto para relacionar los proyectos de TI con los ejes estratégicos del negocio y sus variaciones y establecer un análisis del gap; y se pueden negociar luego los resultados en entrevistas individuales o grupos enfocados con la alta dirección. Insisto: importa más el proceso y la creación de un espacio de reflexión común que la precisión del resultado.
2. Lo segundo debería ser medir el rendimiento operativo, o sea, la efectividad del uso de la informática en términos financieros o, al menos económicos: mayores ingresos, menores costes, mayor rotación de los activos, mayor retorno de la inversión, etc., lo que hemos llamado aquí realización de beneficios. Existen unas cuantas bibliotecas científicas o profesionales que proponen una taxonomía de indicadores y de cómo calcularlos.
De nuevo lo más importante es la oportunidad de abrir un diálogo, en este caso con las direcciones funcionales y el middle-management: si se hace bien, a partir de entonces, el reporting de proyectos nunca más será de la oficina de tecnología, sino que estará compartido entre el negocio y la oficina.
3. Satisfacción y adherencia al plan. Si uno de los objetivos de la planificación estratégica de sistemas es precisamente aumentar el nivel de adhesión y compromiso de la dirección con los planes y su ejecución, yo creo que la evaluación debe medir si esto se ha conseguido. Un sistema de encuestas y entrevistas a lo largo del tiempo es un mecanismo sencillo. La formación y ejecución de la estrategia tiene mucho que ver con la comprensión, el análisis y la gestión de las expectativas y las percepciones de los interesados.
4. Es interesante analizar la efectividad de los mecanismos de distribución de los derechos de decisión sobre la inversión, seguimiento y autorización de cambios, o sea, el gobierno del plan. Se puede analizar la composición de los órganos de gobierno, los temas que se trabajan, la frecuencia de sus reuniones y la calidad y el impacto de las decisiones que se toman. Frecuentemente, como resultado de la evaluación, aparece la necesidad de establecer o cambiar los órganos y procedimiento de gobernanza.
5. Todo esto no omite el análisis de la ejecución de proyectos, en el “triángulo de hierro” de alcance, coste y tiempo y en otras dimensiones relevantes, como es la gestión de riesgos o los mecanismos de comunicación. No lo olvidemos: la Informática se gana una parte de la adhesión de sus clientes y socios de negocio por su capacidad de cumplir sus promesas y ejecutar adecuadamente. El análisis debe mostrar y explicar el gap, la diferencia, entre lo que se prometió y lo que realmente se ha ejecutado.
José Ramón Rodríguez es profesor de dirección de las TIC en diferentes programas de la UOC y consultor independiente. Investiga la planificación y gestión de proyectos de transformación empresarial facilitados por los sistemas y tecnologías de la información.
