Nuestro Blog

Compartiendo experiencias

Categoría: General

  • AGILE Y EL "TRIÁNGULO DE HIERRO

    Agile y el “Triángulo de hierro”

    Escrito por:

    ¡Separando lo inseparable!

    “La inteligencia es el cuestionamiento del método.”
    Jiddu Krishnamurti (1895-1986)

    Reconozco que siempre me llamó la atención todo lo relacionado con el paradigma Agile, pero llevo mucho tiempo dándole vueltas y hay algo que no acaba de convencerme. ¿Realmente estamos vendiendo/comprando desarrollo Agile? Me cuesta reconocerlo, pero la respuesta en la mayoría de los casos, es no.

    Habitualmente, nos conformamos con unas cuantas reuniones de pie, una pared plagada de post-its y alguna buena práctica más, pero ¿vale con eso para considerar un proyecto Agile? Si la respuesta vuelve a ser no, ¿qué nos falta para que los proyectos sean realmente Agile?

    Yo creo que el problema no está en cómo desarrollamos y adaptamos la metodología en nuestros proyectos, el problema está mucho antes de llegar al propio desarrollo, está en la fase de proposición/negociación/contratación del propio proyecto. Después de años de “agilismo”, seguimos empecinados en plegarnos al tradicional “El Triángulo de Hierro”, como si eso nos diese la tan buscada tranquilidad y la confianza en el éxito futuro. Nada más lejos de la realidad.

    El objetivo de esta trilogía de artículos o reflexiones (inicialmente dimensionado así en mi cabeza, aunque no descarto pueda crecer en un futuro próximo), no es otra que la de expresar sobre un folio en blanco:

    – las experiencias y frustraciones vividas en la realización de propuestas y proyectos, en teoría desarrollados bajo metodología Agile,
    – la incansable búsqueda de la utopía, de cambio de visión/realidad a través de ejemplos de la vida real, y por último,
    – la necesaria vuelta a la realidad, materializando algunas de estas ideas en alternativas concretas y viables, que aunque no sacien completamente el deseo de transformación radical de nuestro entorno de trabajo, al menos represente un giro en el día a día y en la percepción de felicidad de todos los actores que intervenimos en el campo del desarrollo de proyectos IT.

    En este primer artículo Agile y el “Triángulo de Hierro”, navegaremos por el proceso de construcción de propuestas de desarrollo bajo paradigmas Agile, analizando las variables y los procesos que se llevan a cabo en la estimación/negociación/contratación, tanto en la versión más habitual, como en la versión más comprometida con la filosofía Agile, finalizando con las alternativas de formalización de la relación/compromisos entre los participantes de esta nueva manera de construir acuerdos.

    Las variables

    ¿Qué factores intervienen a la hora de estimar un proyecto?

    Independientemente de la época, del proyecto, de la tecnología, de la metodología, las preguntas que se formulan a la hora de acometer un proyecto, siempre han sido las mismas, ¿qué? y ¿cuánto? (obviamente habrá un ¿por qué? previo, y si nos paramos a pensar detenidamente, estaremos de acuerdo que el ¿cómo?, realmente no es determinante).

    Conocemos, o creemos que conocemos, qué queremos y necesitamos saber cuánto nos va costar, tanto a nivel de tiempo como de coste.

    Estas preguntas desembocan en las variables a definir y que representan los vértices del “El Triángulo de Hierro”: Alcance, Tiempo y Coste (añadiremos Equipo y Esfuerzo que aunque son parte del ¿cómo?, nos ayudarán a entender el proceso seguido en la estimación).

    En la siguiente tabla, se definen las 5 variables principales y los elementos relacionados (subprocesos, variables, constantes, fórmulas, …), que van a permitirnos presentar una aproximación Agile de cada una de ellas.

    Alcance, esfuerzo, tiempo, equipo, coste

    La realidad

    ¿Cómo funciona habitualmente el proceso de elaboración de una oferta de Desarrollo de Software bajo el paradigma Agile?

    Como hemos comentado, lo normal es conocer el Alcance (habitualmente definido como requisitos en formato textual) y probablemente se conocerá también el Tiempo de ejecución máximo y el Coste máximo (sobre todo en Concursos Públicos).

    Con estos parámetros de entrada, el proceso que llevamos a cabo para calcular y cerrar los 3 vértices y conseguir de esta forma un contrato/acuerdo de desarrollo de un proyecto, sería el siguiente.

    PROCESO:

    1.- Como primer paso, se convierten los requisitos en Historia de Usuario / Épicas, creando el Backlog Inicial, dándole una apariencia Agile al Alcance.

    2.- Se realiza una estimación en Puntos de Historia utilizando un método de estimación Agile (Poker Scrum) para tener cuantificado el Alcance (por ejemplo utilizando la escala de Cohn).

    En este punto, a menudo se comete el error de transformar los Puntos de Historia en horas, a través de una constante que hemos denominado T2ATF, y de ahí obtener directamente el Coste en función del coste medio por hora y el número total de horas (líneas rojas).

    3.- Conocido el Tiempo, se calcula el Número de Sprints, dividiéndolo por la Duración del Sprint (variable de entrada, de valor 2 ó 3 semanas) y se calcula la Velocidad necesaria, dividiendo el Total de Puntos de Historia entre el Número de Sprints. Esta Velocidad permitirá confeccionar el Equipo necesario que tenga como propiedad intrínseca esa Velocidad.

    Si no se conoce el Tiempo, se propone un Equipo determinado, con su Velocidad asociada, y se calcula a partir del total de Puntos de Historia, la Duración del Sprint y la Velocidad de dicho Equipo.

    4.- Dicho Equipo tendrá un Coste Medio asociado por Sprint, que nos permitirá, multiplicándolo por el número de Sprints, obtener el Coste Total del Proyecto.

    Cálculo del Alcance de un proyecto Agile, en función de Coste y Tiempo

    REFLEXIONES:

    – Cierre contractual del Alcance antes de abordar el proyecto. Esta pretensión convierte esta actividad en compleja y crítica, requiriendo mucho tiempo y esfuerzo la definición concreta del mismo y complicando cualquier futura modificación por sencilla que sea.

    – Estimación temprana y con alto riesgo (no se tiene en cuenta el Cono de Incertidumbre de Cohn) y sin intervención del Equipo (de hecho en el momento de la estimación, aún no se ha definido).

    – ¿Qué sucede si el Coste resultante de este proceso no está dentro de las expectativas? La primera tentación es reducir el Coste medio del Equipo, normalmente no teniendo en cuenta que esta reducción, por lógica debería disminuir la Velocidad del Equipo, y por ende, aumentar el Tiempo necesario, manteniendo el Coste total invariable (esta consecuencia no debe ser tomada al pie de la letra, ya que no hay un 100% de proporcionalidad en la relación Velocidad y Coste medio de un Equipo, ya que intervienen diversos factores que siempre dan lugar a largas discusiones cuasi filosóficas). La única solución posible debe ir ligada a la nunca sencilla y viable reducción del Alcance.

    El deseo (aspiración, anhelo, pretensión, objetivo, utopía, …)

    ¿Cómo debería ser el proceso de elaboración de una oferta de Desarrollo de Software bajo el paradigma Agile?

    Entendiendo que no es posible, por mucho que nos empecinemos, fijar los 3 vértices y que “debemos liberar” uno de ellos variabilizándolo en función de los otros 2, lo más sencillo debería ser fijar el Coste y el Tiempo (que presupuesto se dispone para un periodo determinado).

    Con estos idílicos parámetros de entrada, el proceso que se llevaría a cabo para calcular y “cerrar” el 3er vértice (en este caso el Alcance), sería el siguiente (luego veremos cómo se puede formalizar en compromisos esta nueva forma de definir el Alcance).

    PROCESO:

    1.- A partir del Tiempo se establece el número de Sprints necesarios (en función de la Duración del Sprint).

    2.- A partir del Coste se obtiene el Coste medio del mejor Equipo que se puede proporcionar. Este Equipo tendrá asociada una Velocidad determinada.

    A menudo, se comete el error de transformar el Coste en horas, y utilizando la constante que hemos denominado T2ATF, determinar el Alcance en Puntos de Historia, sin tener en cuenta el Equipo (líneas rojas).

    3.- Con la Velocidad del Equipo y el Número de Sprints, se obtiene el número total de Puntos de Historia (Alcance) que se pueden acometer con dicho presupuesto en dicho periodo de tiempo.

    Opcionalmente, se pueden convertir los requisitos en Historia de Usuario / Épicas, creando de esta forma el Backlog Inicial. A partir de estas Historias, se realiza una estimación en Puntos de Historia utilizando un método de estimación Agile (Poker Scrum) y se define el Alcance en Historias de Usuario a desarrollar. Este punto se recomienda definirlo durante la Fase de Inception del Proyecto.

    Cálculo del Alcance de un proyecto Agile, en función de Coste y Tiempo.

    REFLEXIONES:

    Alcance abierto pudiéndose variar durante la ejecución del proyecto, sin que aparezcan los habituales problemas (con la salvedad de que no sea del del Sprint en curso).

    Estimación tardía y realizada con la intervención Equipo.

    Coste dentro de las expectativas

    El compromiso

    ¿Cómo vincular contractualmente un proyecto de Desarrollo de Software bajo el paradigma Agile?

    ¿Dónde radica la dificultad para la implementación de este nuevo proceso? La mayoría de las ocasiones, es inviable/impensable para el Owner del proyecto, abordarlo con el Alcance, es decir el qué, no suficientemente cerrado y especificado a sangre y fuego, pero, ¿realmente el proceso anterior no cierra/compromete los 3 vértices? Sí, los 3 vértices están cerrados, pero la percepción no suele ser esa, ya que este cambio en la definición del Alcance, genera muchos temores sobre las funcionalidades o requisitos reales que finalmente se implementarán bajo el acuerdo alcanzado.

    Entonces, ¿Cómo implementamos los compromisos en el acuerdo formal? Las 3 alternativas posibles en función de donde situemos el foco y los riesgos del proyecto, serían:

    Alcance cerrado definido en Historias de Usuario (MVP)

    En esta alternativa se definirá el Backlog (Alcance), incluyendo aquellas historias que sean prioritarias para conseguir el MVP y que sean compatibles con las variables Coste/Tiempo definidas. (Fase de Inception previa al comienzo del Proyecto).

    Una vez fijadas las 3 variables para este escenario, el compromiso será la realización de las historias de usuario definidas en dicho Alcance (MVP)

    Esta aproximación es ideal, pero es costosa y difícil de llevar a cabo durante el proceso de competición/selección, siendo una alternativa habitual cuando existe una relación de confianza previa.

    Alcance cerrado en Puntos de Historia

    En esta alternativa, a partir del Coste/Tiempo disponible, se establecerá el Equipo, con su velocidad asociada, calculando el Alcance a realizar definido como Puntos de Historia a realizar.

    Una vez fijadas las 3 variables para este escenario, el compromiso será la realización de los puntos de historia acordados, no siendo necesario definir las historias a desarrollar en el momento inicial, permitiendo además, definirlas/cambiarlas a lo largo del proyecto, dentro de la fase de planificación de cada Sprint.

    No quiero pecar de ingenuo, ni hacer trampas al solitario, soy consciente de que el mayor riesgo/temor de esta aproximación, es que el acuerdo depende de forma directa y crítica de la posterior estimación de las Historias de Usuario, y su conversión a Puntos de Historia. Esta labor normalmente la realiza el ofertante, convirtiéndose, durante el proceso, en juez y parte.

    Asistencia Técnica (Time&materials)

    En esta alternativa, a partir del Coste/Tiempo disponible, se establecerá el Equipo, con su Velocidad asociada, y se realizará el proyecto definiendo las historias a realizar en cada Sprint dentro de su fase de planificación.

    El compromiso será la realización del mejor producto posible, imputando solamente el esfuerzo real realizado en cada Sprint.

    Esta alternativa denota una desconfianza inicial nada recomendable a la hora de aventurarse en una próspera relación. Además, obliga a realizar tareas de control (micromanagement) nada deseables.

    La clave está en la CONFIANZA, si no se cree que se va a realizar el mejor producto posible para dicho Tiempo y Coste, lo mejor es no acometer el proyecto y buscar otras alternativas de mayor confianza.

    En el próximo artículo analizaremos un caso real de un proyecto fuera del mundo IT, enmarcado dentro de la primera alternativa definida en este artículo (MVP) y sus posibles analogías aplicables a nuestro entorno. Por último, para cerrar esta trilogía intentaremos profundidad en la difícil tarea de medir la confianza para realizar la mejor selección previa.

  • ¿QUE PASOS DAR EN LA Transformación Digital de mi EMPRESA?

    ¿Qué pasos dar en la Transformación Digital de mi empresa?

    Escrito por:

    “Cada minuto que pasa es otra oportunidad de seguir cambiando”
    Vanila Sky (2001)

    Uno de los grandes retos a los que se enfrentan hoy en día las empresas, es la de realizar la transformación digital.

    No es una moda pasajera, sino que quien no suba al ‘tren del cambio’… tiene todas las papeletas de morir ante la competencia.

    En un mundo en el que el cambio de requisitos y de necesidades por parte de los clientes evoluciona casi a diario, las empresas se han visto obligadas a amoldarse rápidamente para poder competir en un contexto tan agresivo.

    Desde hace años, se trabaja en la dirección de convertir las empresas en Ágiles, dado que se ha comprobado que arroja mejores resultados que lo conocido hasta el momento.

    Pero este proceso de cambio no es tan fácil como nos lo venden… Se debe tener mucha paciencia, valentía, constancia y, sobre todo, las ideas muy claras de hacia dónde estamos obligados a mirar para seguir complaciendo a nuestros clientes.

    De hecho, no existe una receta que asegure el éxito a la hora de realizar la transformación digital de la empresa.

    Uno de los problemas que se encuentran las empresas tradicionales (que venían gestionando proyectos mediante ‘waterfall’), es el de intentar aplicar las mismas recetas que aplican las empresas de última creación (nacieron con mentalidad Agile), pensando que les funcionará igualmente.

    ¡Craso error!

    ¿Por dónde comenzar?

    ¿Por dónde comenzar?

    Una vez decidida la transformación digital de la empresa, no debemos caer en el error de lanzarnos a intentar implantar ‘DevOps’ de la noche a la mañana. Vale que ‘DevOps’ comparte los ideales de Agile y Scrum, pero hasta llegar a poder implantar ‘DevOps’, nos queda un arduo camino de evangelización cultural dentro de la empresa (comencemos por equipos pequeños aplicando Scrum y evolucionemos después hacia DevOps)

    Se debe elaborar un plan: Sabemos que los planes fallan continuamente, pero lo que le da poder a Agile es que gracias a que somos conscientes de este hecho, también somos capaces de adaptarnos a cambios continuos.

    La Transformación Digital debe realizarse porque se desee, no por imperativo de un alto cargo que así lo haya decidido. Las personas reacias a adoptar agile, acabarán cambiando de opinión al ver que un equipo trabajando en agile, empieza a funcionar, los integrantes del equipo salen a su hora, son felicitados por su trabajo y que además, son muy productivos.

    Debe comenzarse a implantar en focos pequeños dentro de la compañía, con equipos que tengan cultura agile, introduciéndose ‘semillas’ o ‘píldoras’ mediante charlas, formaciones (por ejemplo, un coach que les enseñe sobre el cambio que supone adoptar Agile en sus compañías) y por medio de demostraciones de consecución de objetivos ágiles.

    Se debe escalar a lo largo de toda la compañía la mentalidad Agile e ir poco a poco (como hormiguitas) calando en la organización.

    Una vez hayamos decidido por dónde empezar, comenzaremos con el cambio.

    Lo ideal es utilizar la formación como bandera de cambio. Apoyarnos en un Agile Coach o un Facilitador en Agile (Scrum, Kanban, etc.) será clave para enseñar a la gente.

    Durante la fase de transformación digital, será muy importante realizar un buen seguimiento del plan, ver su estado en cada momento y sobre todo, medirlo. De este modo, conseguiremos una mejora continua.

    En la actualidad, la formación agile se ha convertido en un imprescindible para cualquier organización, de hecho, es la única alternativa posible para la mayoría de ellas.

    Implicar a todos los miembros de la compañía en el proceso de adaptación es el único camino hacia el éxito.

    De la capacidad que tenga cada empresa para adaptarse a los cambios, dependerán los éxitos para alcanzar las metas propuestas.

    Lo habitual es que, en las empresas que se embarcan en la transformación digital, se genere incomodidad o temor. No hay que ver este hecho como algo negativo, ya que ahí es donde reposa la posibilidad de obtener resultados positivos e innovaciones en la vida.

    La formación agile debe ir acompañada de una constante actualización, pro actividad e innovación, y debe ser personalizada y adaptada tanto a las necesidades de la empresa como a las novedades del mercado.

    Si buscas resultados distintos, no hagas siempre lo mismo

  • ¿QUÉ DEMONIOS ES ESO. de Scrum, Kanban, Agile, Lean, Lean IT ?

    ¿Qué demonios es eso de Scrum, Kanban, Agile, Lean, Lean IT?

    Escrito por:

    “Si no sabes a dónde vas, cualquier camino te llevará ahí”
    Alicia en el país de las maravillas (2010)

    A la hora de explicar a los equipos cual es la diferencia entre Agile, Lean, Kanban, Scrum…, expongo que, aunque todos son distintos entre sí, al profundizar en cada uno de ellos podemos observar que somos incapaces de indicar dónde termina uno y donde comienza el siguiente.

    Esto es debido a que, entre todos ellos, existe un solapamiento ineludible ya que dichas filosofías, metodologías…, se centran en encontrar la mejor forma de desarrollar software y ayudar a que otros lo hagan (aumentando la productividad, mejorando la calidad y reduciendo el coste y el tiempo empleado en el desarrollo de los productos/servicios).

    ¿Dónde comenzó todo?

    Haciendo un poco de memoria, volviendo atrás en el tiempo, encontramos a Taiichi Ohno, director y consultor de Toyota.

    Taiichi Ohno, influenciado por los avances que habían obtenido Henry Ford y Frederick Taylor en materia de productividad durante la revolución industrial, desarrolló el método Lean Manufacturing.

    Lean Manufacturing:

    Nació como una filosofía con un enfoque hacia procesos de fabricación. Es conocido como un proceso continuo y sistemático de identificación y eliminación del desperdicio o excesos, entendiendo como exceso toda aquella actividad que no agrega valor en un proceso, pero sí costo y trabajo. Pone énfasis en el sistema como un todo, tener la perspectiva del todo para comprender el sistema y poder optimizarlo.

    Lean IT:

    Es la aplicación de los principios de Lean a la gestión de las tecnologías de la información.

    Los principios son muy sencillos y tienen que ver con el sentido común. El principal de todos ellos es que hay que centrarse en aportar valor al cliente. Pero otro muy importante, y que diferencia a Lean de otras iniciativas para mejorar la eficiencia, es que se basa fundamentalmente en los equipos, que son partícipes del proceso, y que lo ejecutan y llevan a cabo. Este principio es fundamental.

    Agile:

    El término Agile se refiere a cualquier proceso que se alinea con los conceptos del Manifiesto Ágil. El 17 de febrero de 2001, diecisiete desarrolladores de software se reunieron en Utah para discutir los métodos de desarrollo ágil. Publicaron el Manifiesto Ágil para el de desarrollo de software, en la que se muestran las “mejores formas de desarrollar software haciéndolo y ayudando a que otros lo hagan” e incluyeron cuatro valores y doce principios.

    El desarrollo de software ágil, se basa en un enfoque incremental e iterativo. En lugar de una planificación en profundidad al comienzo del proyecto, las metodologías Ágiles están abiertas a cambios en los requisitos a lo largo del tiempo y fomentan la retroalimentación constante de los usuarios finales. Los equipos multidisciplinares trabajan sobre las iteraciones de un producto durante un período de tiempo, y este trabajo se organiza en un backlog que se prioriza en función del valor del negocio o del cliente. El objetivo de cada iteración es producir un producto de trabajo.

    Kanban:

    Es una herramienta de gestión visual creada por Taiichi Ohno (Lean). Palabra japonesa que significa “tarjetas visuales” (‘kan’ significa visual y ‘ban’ tarjeta).

    Gestiona específicamente que se fabriquen sólo los productos necesarios en la cantidad y tiempo necesarios, es uno de

    los pilares del sistema de producción de Toyota.

    Herramienta visual que permite gestionar de una forma rápida cualquier flujo de trabajo.

    Hasta aquí este artículo en el que he intentado dar unas nociones básicas de estos términos. En futuras entradas se ahondará en cada una de ellas –

    Referencias

    [Chin, Gary (2004)] Agile Project Management: How to Succeed in the Face of Changing Project Requirements. AMACOM.9.

    [Páez, Nicolás (2014)] Construcción de software: una mirada ágil. EDUNTREF.

  • QUIEN MEJOR TE ACONSEJA ES QUIEN MEJOR TE CONOCE

    Quien mejor te aconseja es quien mejor te conoce

    Escrito por:

    Motor de recomendaciones semántico

    Cada día miles de personas entran en tu portal web o e-commerce, no siendo para ti nada más que una IP o cookie.

    Pero detrás de esa IP hay una persona.

    Si queremos ofrecerle una eXperiencia de Usuario realmente personalizada y ofrecerle los productos, servicios o informaciones que de verdad se ajusten a esa persona en concreto, conocer su IP no es suficiente, necesitamos saber QUIEN es la persona detrás de esa IP. Conocer donde vive, sus intereses, su edad, sus amigos, sus gustos, sus aficiones, saber que le interesa, que le preocupa, que requiere de nosotros.

    Saber quién es esa persona de verdad para personalizarle mi propuesta, aumentar su satisfacción como usuario y mejorar mis cifras de conversiones, ventas y beneficios.

    Aumentar su satisfacción como usuario y mejorar mis cifras de conversiones, ventas y beneficios

    La pregunta es: ¿cómo puedo personalizar y recomendar los productos más adecuados a una persona que no conozco?

    Motores de recomendaciones

    En las web de e-commerce que nos movemos habitualmente estamos acostumbrados a que nos realicen recomendaciones del tipo “Quien compró esto… también compró…” o “productos comprados habitualmente juntos…”. Estas recomendaciones están basadas en técnicas que llamamos de clustering, para las cuales no se requiere un conocimiento del cliente, ni del producto; sino que se obtienen de analizar los comportamientos de navegación o compra de miles de usuarios anónimos.

    A pesar de que los Motores de Recomendaciones y Personalización basados en Clustering dan muy buenos resultados (no tenemos más que ver Amazon), hoy tenemos otras técnicas que nos permiten obtener mejores resultados basándonos en un conocimiento más profundo de nuestros clientes, sus gustos, aficiones, amigos, estilo de vida … lo que llamamos Insights…

    Customer Insights

    Podemos encontrar muchas definiciones de Customer Insights. Vamos a quedarnos con la siguiente de Wikipedia:

    “Commonly referred to as CI, it is the intersection between the interests of the consumer and the features of a brand. Its main purpose is to understand why the consumer cares for the brand as well as their underlying mindsets, moods, motivation, desires, aspirations, and motivates that trigger their attitude and actions.[2]”

    Lo que te estarás preguntando ahora es: ¿Cómo puedo encontrar los Customer Insights de las personas que aterrizan en mi portal y utilizarlos en mutuo beneficio?

    Desde el punto de vista del Marketing, el análisis de Customer Insights es todo un mundo. Vamos a ser humildes y únicamente te vamos a proponer unas sencillas técnicas y tecnologías que incorporadas a tu e-commerce o portal te van a permitir adecuar tu oferta de una manera más eficaz hacia tus clientes, en base a dos conceptos como son el Perfil Social y Motor de Recomendaciones Semántico.

    Bien, supongamos que tenemos un portal de e-commerce que vende productos y servicios de muy diversas categorías. ¿Qué tengo que añadir a mi web y al resto de mi infraestructura para poder ofrecer recomendaciones personalizadas a mis visitantes basadas en Customer Insights?

    Vamos a definir el proceso en 5 pasos:

    Conocer a tus visitantes.

    Conociendo solo su IP no podemos hacer nada; bueno, podemos utilizar un Motor de recomendaciones basado en Clustering como hemos comentado antes. Pero no es ese nuestro objetivo ahora, queremos ir más allá.

    Necesitamos saber quién es realmente esa persona, sus gustos, likes, aficiones etc. Para ello nos vamos a apoyar en su perfil social. Lo que vamos a encontrar de ella en todas las redes social que la persona nos permita, facebook, Twiter, Google+, Linkedln…

    La forma más común y sencilla es introducir lo que llamamos el Social Login en nuestra web.

    Social Login

    Estamos tan acostumbrados a verlo que ya no nos asusta, nos facilita la vida al no tener que pasar por complejos procesos de registro o acordarnos de mil y una claves distintas. Pero no solo eso, también aumenta el número de registros en varios órdenes de magnitud y nos permite obtener información de la persona, respetando su privacidad, para ir generando su perfil social.

    Por ejemplo, nosotros utilizamos Gigya como solución SaaS de Identity Management. Gigya nos permite no solo crear el perfil social de la persona sino que también completarlo con otras informaciones como su comportamiento, compras, comunicación etc… para ir creando lo que podemos llamar Perfil 360º.

    Perfil 360º

    Extraer el conocimiento del Perfil Social de mis visitantes.

    A medida que nuestros visitantes van aterrizando en nuestro portal y se van registrando de forma sencilla con el Social Login, vamos obteniendo sus perfiles sociales. Eso está bien… pero saber que Juan tiene en facebook likes en Nikon y le interesan los viajes no me sirve de nada si no puedo extraer conocimiento utilizable de esa información disponible.

    Para ello vamos a utilizar técnicas de Web Semántica.

    Los pasos a realizar serían:

    – Crear una ontología de “Perfil Social”

    – Anotar semánticamente todos y cada uno de los registros que definen el perfil social de cada persona en base a dicha ontología. Registros obtenidos del Identity Management System.

    Con esto podemos decir que empezamos a conocer mejor a nuestros clientes… pero de nada nos sirve si no conocemos nuestros productos.

    User ontology sin incorporar SocialMediaAccount profile

    Extraer el conocimiento de cada producto, servicio o información que tenemos en nuestro site.

    Efectivamente tenemos que entender lo que tenemos, bien sean fichas de productos de un e-commerce o noticias de un periódico online…

    Seguiremos los mismos pasos que antes:

    – Crear una ontología de “Nuestro negocio”

    – Anotar semánticamente todos y cada uno de los registros de los productos o servicios que ofrecemos en base a dicha ontología.

    Bueno, ahora podemos decir que conocemos mejor a nuestros clientes y a nuestros productos. El siguiente paso es encontrar quien está interesado en qué.

    Extraer el conocimiento de cada producto

    Procesar ambos conocimientos con un algoritmo de distancias.

    Ahora que sabemos que les gusta a nuestros clientes y como son nuestros productos nos toca desarrollar un conjunto de algoritmos que sean capaces de calcular la distancia entre cada par cliente/producto. Estos algoritmos nos deberán de dar un número normalizado para cada uno de estos pares con el que construiremos una matriz simétrica de distancias entre todos los clientes y todos los productos de nuestro catálogo.

    Esta distancia entre el cliente y el producto va a representar el grado de interés que el primero puede tener por el segundo.

    Todo el procesamiento descrito hasta ahora es muy complejo y consume gran cantidad de recursos ya que es del tipo N (número de clientes) x M (número de productos), además del coste de la extracción y anotación semántica de cientos de miles de clientes y miles de productos.

    Afortunadamente todo este procesamiento es altamente paralelizadle y puede realizar en batch, permitiéndonos utilizar tecnologías de Big Data.

    Procesar ambos conocimientos con un algoritmo de distancias

    Presentar a cada persona en cada momento, los mejores resultados extraídos del algoritmo.

    Una vez sabemos que productos pueden ser más interesantes para cada cliente, lo que nos falta es, en tiempo real, presentar aquellos que seleccionamos con mayor grado de interés. Esta selección se puede filtrar por otros parámetros como eliminar productos o productos de la misma categoría que ya el cliente haya comprado o complementar los productos a recomendar con recomendaciones basadas en clustering del tipo “estos productos se compran juntos habitualmente”…

    De esta forma seremos capaces de generar una experiencia de usuario personalizada a cada usuario en cada momento. Sorprenderle con recomendaciones de productos que ni siquiera han sido el motivo de su visita pero que cuando las ve le generen un interés de compra inesperado, porque están basadas en lo que sabemos de él, no en lo que está haciendo en ese momento en nuestro portal.

    Presentar a cada persona en cada momento, los mejores resultados extraídos del algoritmo

    Pues bien… ya tenemos en nuestra web un Motor de Recomendaciones Semántico capaz de recomendar a cada usuario los productos o servicios que sin él mismo saberlo puede que desee…Le estamos escribiendo su carta a los reyes Magos.

  • COMO MODELAR PROCESOS DE NEGOCIO SIN SABER MODELAR PROCESOS DE NEGOCIO S-BPM

    Como modelar procesos de negocio sin saber modelar procesos de negocio S-BPM

    Escrito por:

    Toda organización independientemente de su tamaño, consiste básicamente en un conjunto de personas que colaboran para realizar una serie de tareas, que dan un conjunto de resultados o productos de esas actividades. Dicho así parece muy sencillo, pero si introducimos el concepto de “Procesos de negocio” aparecen las dudas y los miedos. ¿Tengo claros y definidos mis procesos? ¿Son correctos y adecuados? ¿Están implantados en mi organización? Y sobre todo ¿Soy capaz de modelarlos correctamente y las personas involucradas serán capaces de entenderlos y seguirlos?

    Así cuando hablamos de “Procesos de Negocio” inmediatamente nos viene a la cabeza la figura del Consultor. Una persona interna o externa que es un experto en modelar procesos y que se trabajo consiste en ir entrevistándose con las personas responsables de negocio de la organización, tratando de entender de qué va el negocio, como está estructurada la organización, quién hace qué, cómo y para qué, y desarrollar unos diagramas que expongan todo ese conocimiento adquirido.

    Aquí empiezan a aparecer las quejas…

    El consultor no conoce la organización. No sabe del negocio, no entiende nuestro lenguaje ni nosotros el suyo. Pasan semanas y montones de reuniones y no vemos avance. Y sobre todo no entendemos los diagramas que nos pinta, no entendemos cómo interpretarlos, como usarlos o para que nos sirven. Resultado: otro documento precioso… a la estantería!

    Pero, ¿Y si fuéramos nosotros mismos capaces de modelar los nuestros propios procesos de negocio?, al fin y al cabo somos nosotros quien mejor conoce la organización, quien mejor conoce como trabajamos y que objetivos tenemos. Solo tenemos que seleccionar a las personas responsables de negocio involucradas en los procesos y formarlos en Modelado de procesos, lenguaje BPMN y en una herramienta de modelado.

    Si la anterior aproximación ya genera reticencias, esta ni te cuento!. Formar a personas como el responsable de operaciones, gerentes comerciales, director financiero o responsable de Recursos Humanos en teoría de procesos, nuevas y sofisticadas herramientas o en un lenguaje tan complejo como BPMN con más de 100 símbolos… inviable!

    Toda organización independientemente de su tamaño, consiste básicamente en un conjunto de personas que colaboran para realizar una serie de tareas, que dan un conjunto de resultados o productos de esas actividades. Dicho así parece muy sencillo, pero si introducimos el concepto de “Procesos de negocio” aparecen las dudas y los miedos. ¿Tengo claros y definidos mis procesos? ¿Son correctos y adecuados? ¿Están implantados en mi organización? Y sobre todo ¿Soy capaz de modelarlos correctamente y las personas involucradas serán capaces de entenderlos y seguirlos?

    Así cuando hablamos de “Procesos de Negocio” inmediatamente nos viene a la cabeza la figura del Consultor. Una persona interna o externa que es un experto en modelar procesos y que se trabajo consiste en ir entrevistándose con las personas responsables de negocio de la organización, tratando de entender de qué va el negocio, como está estructurada la organización, quién hace qué, cómo y para qué, y desarrollar unos diagramas que expongan todo ese conocimiento adquirido.

    Aquí empiezan a aparecer las quejas…

    El consultor no conoce la organización. No sabe del negocio, no entiende nuestro lenguaje ni nosotros el suyo. Pasan semanas y montones de reuniones y no vemos avance. Y sobre todo no entendemos los diagramas que nos pinta, no entendemos cómo interpretarlos, como usarlos o para que nos sirven. Resultado: otro documento precioso… a la estantería!

    Pero, ¿Y si fuéramos nosotros mismos capaces de modelar los nuestros propios procesos de negocio?, al fin y al cabo somos nosotros quien mejor conoce la organización, quien mejor conoce como trabajamos y que objetivos tenemos. Solo tenemos que seleccionar a las personas responsables de negocio involucradas en los procesos y formarlos en Modelado de procesos, lenguaje BPMN y en una herramienta de modelado.

    Si la anterior aproximación ya genera reticencias, esta ni te cuento!. Formar a personas como el responsable de operaciones, gerentes comerciales, director financiero o responsable de Recursos Humanos en teoría de procesos, nuevas y sofisticadas herramientas o en un lenguaje tan complejo como BPMN con más de 100 símbolos… inviable!

    BPMN Model

    Estamos en punto muerto. La aproximación del consultor no es óptima, mientras que la aproximación de “háztelo tu mismo” no es posible… ¿o quizás si?

    ¿Y si existiese un lenguaje de modelado de procesos suficientemente sencillo como para que nosotros mismos seamos capaces de modelar nuestros procesos sin ayuda externa y sin apenas formación previa?

    Ese lenguaje existe y se llama S-BPM

    S-BPM es un lenguaje de Modelado de Procesos de Negocio especialmente orientado a que sean las personas de negocio y no un consultor, quien modele sus propios procesos. Para ello se basa en un Toolkit de tan solo 2 tipos de diagramas, 5 símbolos y descripciones en Lenguaje Natural.

    Gusteau, en la película infantil Ratatouille decía “cualquiera puede cocinar”. Pues con S-BPM, “cualquiera puede modelar”. Quienes tengáis hijos pequeños… lo entenderéis.

    Lenguaje S-BPM

    El lenguaje de modelado S-BPM se basa en 2 reglas básicas:

    1. Cualquier proceso de negocio se puede modelar en base a un grupo de “sujetos” que realizan tareas y colaboran con otros sujetos a través de “mensajes”.

    2. Un sujeto cuando realiza sus actividades puede estar en tres estados: esperando un mensaje, realizando una tarea o enviando un mensaje.

    Esto nos lleva a que para modelar cualquier proceso de negocio con S-BPM, necesitamos crear dos diagramas:

    1. Diagrama de Sujetos

    En este diagrama se identifican quienes son los participantes en el proceso de negocio (Administración, RRHH, Operaciones, Call Center, otros procesos, otros sistemas, dispositivos IoT…) y que mensajes se mandan entre ellos. Y todo en Lenguaje Natural.

    Por lo tanto tenemos 2 símbolos básicos. Los sujetos y los mensajes.

    Ej: proceso Alta Electrica nuevo cliente residencial

    En este diagrama vamos a definir cuáles son las acciones que realiza cada uno de los sujetos dentro de su participación en el proceso, teniendo en cuenta que un sujeto puede estar esperando un mensaje (caja verde), realizando una tarea (caja amarilla) o mandando un mensaje (caja roja). Y todo ello descrito en Lenguaje Natural.

    Ej: Diagrama de Actividad del sujeto Responsable Comercial

    Bien, parece que este lenguaje de modelado es sufrientemente sencillo para que cada uno modele su parte, su participación en el proceso aprendiendo en un par de tardes 5 símbolos y un par de técnicas…

    Pero ¿y si además pudiéramos trabajar todos en grupo alrededor de una mesa para hacer los modelos?

    Metasonic GMBH, es un fabricante de software BPM bajo S-BPM que nos ofrece Metasonic® Touch (qualityobjects.com/soluciones/bpm), una mesa táctil con la que podemos trabajar modelando los procesos de forma sencilla y muy visual, lo que facilita la colaboración y los consensos.

    Metasonic® Touch

    Pero ¿y si además de modelar nuestros procesos pudiéramos implantarlos en nuestra organización de forma sencilla y barata?

    No solo se puede, además se debe. Tener un conjunto de diagramas en papel en una estantería de la oficina no sirve para nada si esos procesos no se implantan en la organización, no se conocen, no se siguen…

    Metasonic® Suite es un conjunto de herramientas que nos permiten “compilar” un modelo S-BPM y generar automáticamente una aplicación informática que desplegamos en los servidores de la organización o en cloud, y que le dicen a cada interviniente que tiene que hacer en cada momento, orquestando el trabajo de todos los participantes en el proceso, sean personas, otras aplicaciones o sistemas físicos.

    Conclusiones

    Modelar los procesos de una organización e implantarlos con un BPMS no tiene porque ser tan difícil ni tan caro. Basta con elegir las personas, lenguaje y herramientas adecuadas. Metasonic y S-BPM es una buena alternativa para ello.

Mostrando 5 de 5 entradas