Mi propia definición de blockchain!

Ok, he leído durante las ultimas semanas sobre esta arquitectura, y no sobre el caso especifico de implementacion usado para el bitcoin, pues sabemos esto es solo un caso de implementacion de este tipo de arquitectura descentralizado. Después de leer, re leer, sentirme por momentos @estupida y @desactualizada, finalmente he logrado entender medianamente como funciona, y con esto he intentado pensar en algunas aplicaciones reales que vayan mas allá del tema de transacciones @bancarias, en donde BitCoin es definitivamente el innovador y mejor de los ejemplos.
Con esto en mente, trate de identificar una necesidad real de las compañías en donde podría usarse este patrón arquitectónico de solución, que no sea algo tan fuera de un contexto corporativo tradicional como el bitcoin, y entonces como todos los momentos creativos en mi vida, una pequeña luz de suerte toco a mi cerebro mientras tenia una conversación de temas del día a día. El proceso creativo pasa por fases en donde la idea se diagrama, toma fuerza, en algunos casos se debilita y finalmente con algo de información, puede llegar a identificarse un real caso potencial que podría llegar a implementarse. Quiero compartirles algunas @platanizaciones de los conceptos de BlockChain, según mi entendimiento. Si alguien es experto en esto y puede darme su feedback NO teorico sino practico, sera mas que bienvenido. Empecemos con el caso de uso:

En un conglomerado de empresas, no se tiene la capacidad de identificar al cliente de una única manera, por lo que es difícil pensar en servicios de @cross selling, @up selling, y demás términos mercadologicos que enmarcan la capacidad de explotar el contar con distintos productos/servicios que pueden ofrecerse al mismo cliente, desde empresas independientes, o en conglomerados, o en sociedades, o en cualquier relacion entre empresas que brindan distintos servicios, y hasta en empresas del mismo servicio. Para este momento, seguramente varios se habrán desconectado de este escrito y estarán pensando, eso ya se puede hacer, existen ETL, DataWharehouses, etc. Y si todo eso es cierto, hasta existen dblinks entre bases de datos, lagos de información, un sinfín de tecnologías que nos permiten compartir información, para este caso, del cliente, entonces ¿Por qué blockchain?. Bueno, existen para mi tres conceptos fascinantes de esta arquitectura:

1. Consenso: Los distintos nodos operativos deben tener un consenso, según la mayoría de definiciones, un consenso debe ser de mas del 50%. Esto difiere tremendamente del concepto tradicional en donde las transacciones solo tienen una respuesta verdadera de un único validador, en esta arquitectura tengo a mas de uno, y puedo tener un resultado de una transacción sin que el 100% de los participantes estén en el consenso, es una democratización de una transacción entre sistemas. Increíble!!!.
2. Ledger:Entendiendo el concepto sin visitarlo mas a fondo técnicamente, es un lugar en donde residen todas estas transacciones que requieren verificación, y el blockchain no es mas que ese orden de bloques que permite hacer esas validaciones con otras entidades distribuidas, NO existe una única verdad, pero al ser una verdad validada por varios, las posibilidades de disminuir problemas de seguridad son inmensas.
3. Contrato:Este concepto, que data de arquitecturas como servicio, en mi concepto, finalmente toma un valor mas grande, pues enmarca los datos del activo que son compartidos, como se comparten, que puede hacerse con ellos, etc.

Entonces, regresemos al caso que planteaba en el principio. Identificación de un cliente dentro de un conglomerado de empresas. En el modo tradicional seguramente estaríamos pensando en hacer una conexión entre bases de datos, crear un datawhareouse en el que correremos complejos algoritmos para hacer match entre campos, o en el mejor de los casos crear un servicio web que nos permita validar ese cliente frente a otros dentro de la compañía y con alguna capacidad de acertar, solo alguna, identificar a ese cliente. Y porque digo alguna? Porque la informacion de los clientes cambia, la forma de escribir nombres y apellidos, suelen tener distintos documentos de identificación, distintos correos electrónicos, y sobre todo, debido a lo invasivo del internet y otros medios canales digitales, suelen entregarnos información incorrecta de contacto, para comprarse un momento de tranquilidad y no ser agobiados por mensajes y correos electrónicos. Seguramente esta identificación la haríamos tardía, no en linea, y seguramente TODAS nuestras bases de datos de clientes dentro de una misma empresa y ni digamos de un grupo de empresas tiene registros repetidos innimaginables de las mismas personas, lo que los aleja de esta vision de cliente, de estas tan famosas estrategias que estan de moda de girar en torno al cliente.

Bueno, he estado pensando como podríamos hacer una solución usando blockchain y se las comparto. Definamos que el activo, ósea la @transaccion  es la informacion de un cliente, su información básica, personal y de contacto. Y que el ledger no es mas que una base de datos tradicional en donde colocamos estas transacciones, y finalmente, el consenso no es mas que la verificación de esta transacción por los distintos servidores participantes de las distintas empresas que desean identificar al cliente. Se define un contrato común sobre la informacion que se compartirá y las reglas con las que el blockchain validara la transacción ejecutada sobre la informacion del cliente, miremos un ejemplo para dos operaciones del cliente, create and update information:

1. Create: En alguno de los sistemas de alguna de las empresas dentro del blockchain se crea la informacion de un nuevo cliente, o al menos un nuevo cliente de esa empresa en particular. Esta informacion se envía al blockchain con los siguientes datos según el contrato:
a. Nombre y apellido
b. Fecha de nacimiento
c. Documento de identidad
d. Teléfono
e. Correo Electrónico

Ahora, digamos que las reglas del blockchain para la transacción de @create, indican que se validara mediante algoritmos de comparación, las siguientes opciones:
f. Nombre y apellido + Correo electronico
g. Fecha de nacimiento + Nombre y apellido
h. Documento de identidad + Nombre y apellido
i. Teléfono + nombre y apellido
j. Correo Electrónico + teléfono

Estas combinaciones y muchas otras que pueden definirse como parte de las reglas del blockchain se validarían en todos los repositorios de las empresas asociadas a la transacción, y con un consenso según las definiciones de la arquitectura se identificaran distintas posibilidades y sus acciones asociadas:

2. UPDATE:
a. El cliente ya es cliente de una empresa asociada, por lo que puede dársele un trato preferencial, validar con el si es el mismo cliente y de ser así, traer informacion que puede ser relevante para la empresa, inclusive un score que puede permitir saber el valor potencial de ese cliente, comportamiento de pago, comportamientos de compra, etc.
Adicionalmente si es así, puede ser que este cliente halla entregado informacion en esa empresa distinta a la que tenia en la anterior por lo que según el consenso y las reglas puedo disparar una actualizacion de datos que me asegure tener siempre una vision lo mas cercana a única de cliente. Si se dio el consenso en que el cliente existía pero las otras empresas tienen un numero de teléfono de contacto diferente, según como se definan la reglas del blockchain puede decidirse actualizar el numero, o al menos disparar una actividad a un sistema de CRM de buscar contactar al cliente  y validar si se dio un cambio en su numero de contacto de manera pro activa.
b. El cliente no es cliente de ninguna empresa asociada, por lo que se procede a crearlo y a por ejemplo según la información que se capte de el, que puede relacionarse con data no estructura, definir ingresarlo como un LEAD en otras empresas asociadas que identifiquen según las reglas, productos/servicios que pueden ofertarse, para que ellas desde sus sistemas CRM o como estén definidas puedan incrementar su portafolio de clientes.

Me pregunto que sentirán ahora, los creadores de los negocios de puntos y millas, donde según su conveniencia le dan valor a estos @puntos que en realidad en muchas empresas son dinero con el que pueden comprarse boletos aéreos, iPads, hoteles y demás. Como usuarios no se han preguntado cuanto es el valor real de esa milla? 10.000 millas por un boleto cuanto dinero es? Y si mediante algoritmos identificáramos el valor de esa milla en distintos comercios y pudiéramos valorizarla para que supiera en realidad cuanto le esta costando esa redención según el consenso del blockchain? Lo que podemos hacer es inimaginable.

Esos son dos pequeños ejemplos, ahora pensemos en un ejemplo real y aplicado a alguna industria. Yo tengo muchos en mente, pero para no alargarme mas, debo confesarles que una vez se entiende mas a detalle lo que significa esta arquitectura, mas allá del bitcoin, es un concepto maravilloso que cambia la típica transacción computacional con respuestas de 1 y 0, a un esquema democrático de votación, es un cambio de concepto muy interesante, que permite terminar con intermediarios, con procesamientos batch, informacion duplicada y que nos puede permitir darle un verdadero trato de VALOR a nuestros activos, en mi humilde comprensión, es una arquitectura Peer2Peer en donde entidades reales pueden hacer parte de la cadena de validación y en donde todos pueden beneficiarse de la misma.

Implementando un CRM!

Algo importante que siempre quiero dejar claro en mi blog y en mi vida profesional, es que aunque haya pasado por distintas universidades y entidades académicas, y cargue varios títulos en mis paredes y en mi curriculum, jamás me he permitido escribir o dar algún tipo de asesoría sobre temas en los que no tenga experiencia real. Algo difícil cuando estamos a punto de explorar algo nuevo, es el sin fin de ofertas de proveedores, consultores, que académicamente tienen las credenciales, pero que no conocen el mundo fuera de los libros y las horas de clase. Yo me pregunto, permitiríamos que un cirujano nos operara y fuéramos su primera vez, dejaríamos todo en sus manos? Regularmente no es así, un cirujano sin experiencia pasa bastantes procedimientos acompañado de un cirujano senior que puede guiarlo. Hablemos de una experiencia mas cercana a mi conocimiento, un piloto, viaja como co/piloto y observador mucho antes de estar solo con la responsabilidad de transportar un grupo de almas por los aires. Sin embargo en mi rubro, no es así. Existen muchos consultores y profesionales, que escriben y asesoran clientes basados en su basto conocimiento teórico sin ninguna aplicación real de los conocimientos. Bueno, en mi caso les prometo que no será así.
Durante mi vida profesional me he enfrentado a  la implementación de CRMs entre muchos proyectos, y en esta entrada solo quiero compartirles el proceso de planteamiento, oportunidades de mejora, y un análisis basado en las distintas experiencias que he tenido con ese tipo de implementaciones. En esta entrada me enfocare en el CRM:

1. Arquitectura empresarial: Quiero empezar por este punto, no solo porque me apasiona sino porque me gusta iniciar por las buenas noticias. En los distintos proyectos de este estilo que he implementado siempre empece con el ejercicio de arquitectura empresarial, y esto me ha permitido caer suavemente, en errores corregibles en vez de catástrofes inmanejables. Si el ejercicio ya existía en la empresa en donde implemente este proyecto, genial, pero es importante revisarlo. Porque como les mencione al inicio de esta entrada, mucho proveedor y consultor no da trabajo de calidad y con real experiencia a las empresas, puede ser que la arquitectura que tienen tenga algunas oportunidades de mejora. Pero que exista, es una señal que estas a punto de abordar un proyecto de este nivel de madurez en una empresa que al menos comprendió que debería de tener un ejercicio de arquitectura de este nivel a lugar. Punto para la empresa.
Sino existe, es momento de pedir tiempo para no iniciar el proyecto hasta que pueda crearse una primera iteración, tal vez no con todo el detalle que puede significar años, pero si un análisis a alto nivel que tal vez repercuta en retrasas el inicio del proyecto algunos meses, si pudiera compartirles algo de esto es, iniciar un proyecto con un ejercicio arquitectónico es la mejor manera de entender la situación actual y donde quieres terminar, además de entender como tu labor asegurara el cumplimiento de la visión estratégica y la arquitectura de negocio. Siempre pide la carta de navegación, de lo contrario no continues.
2. Entendamonos: La mayoria de empresas que me han pedido implementar un CRM han tenido algunos conceptos en los que difiero. Y el mismo nombre del proyecto es para mi una mala interpretación. Un CRM no es un sistema tecnológico, CRM es una mezcla de personas a través de cultura, procesos orientados al cliente, y sistemas que lo soportan que permiten que las decisiones de negocio giren en torno al cliente. Lastimosamente muchas empresas estan hablando de esto, y la centralización en el cliente, pero les es prácticamente imposible llevarlo a la realidad y créanme no es por el sistema. NO, principalmente es por el primer componente, la cultura, la gente.
Menciono este punto porque es importante hacer el ejercicio de entender si quienes te están pidiendo un CRM entienden en realidad que te están pidiendo o solo están siguiendo alguna recomendación de un tercero que les mostró dos o tres aplicaciones y los convencío de esta necesidad o siguiendo una moda que escucharon en algún congreso o coctel de negocios.
Y si la empresa entiende lo que esta a punto de iniciar, por favor asegúrate que en tu equipo o el equipo del proyecto existan personas de las areas de negocio, de recursos humanos y que cuentes con un proyecto que contemple también los procesos y la cultura, NO solo el sistema, este es en realidad el pilar mas sencillo de la implementacion. Si encuentras todo esto en lugar, y has podido trabajar en el punto uno de la arquitectura, la factibilidad de éxito crece, frente a las cifras reales que muestran una innumerable cantidad de fallas a proyectos de implementaciones de CRM’s.
3. Vendors: Aquí me detendré a confesarles uno de mis primeros errores. Traje a los proveedores demasiado pronto a la mesa a hablar de tecnología, y sin el concepto adecuadamente entendido en los equipos de trabajo, el ejercicio de mirar las capacidades de tecnologías que podían apoyar este proyecto se convirtieron en el proyecto. Esto logre solventarlo en las empresas donde cometí el error, pero me costo tiempo y desperdicio de esfuerzo.
Adicionalmente, creció el temor sobre el cambio, se entendió que estos nuevos productos remplazarían al CORE actual corporativo que se había tardado años en desarrolladores y la mala información y mensaje equivocado hizo mas lento el proyecto, mas doloroso y estrésante. Se crearon mas detractores de los que habrían podido tenerse, si los dos primeros puntos hubieran precedido la exploracion tecnológica. Mi mente de ingeniera venció mi conocimiento del orden de atacar los problemas y me lance a pensar demasiado pronto en los @while and @for. Lección aprendida.
4. Fases y valor rápido: Un CRM tradicional te habla de habilitar distintas fases de relacionamiento con el cliente o posible cliente, desde identificar un grupo de clientes potenciales, contactarlos, ofrecerles valor, crear una relación, hasta dejarlos salir de la relación si así lo desean. Es importante entender todo lo que eso significa, pues existe una fase conocida como @lealtad, y eso es algo inmenso, puede ser un proyecto aparte que alimente el CRM. NO es posible pensar en el CRM como una implementación corta, toma tiempo, pero debes identificar procesos en donde puedes empezar a generar valor más rápido mientras trabajas en los mas complejos. En mi posicion y experiencia, los pasos de identificar clientes, tratar de generar nuevos prospectos es tal vez de lo mas sencillo a hacer, pues seguramente las personas de la empresa ya lo hacen y existen procesos, tal vez no formales, pero existen para hacerlo. De lo contrario, como es que tienen clientes hoy?. Por esa razón es un buen punto de partida, porque seguramente solo tendrás que oficializar algo ya existente, estandarizarlo y pasar mas tiempo en la tecnología. Es un buen punto de partida para dar un valor rapido, para preparar a la organización para lo que viene después y para dedicar el primer esfuerzo en vender el proyecto, en mostrar en la practica lo que significa y en seleccionar la tecnología. Con eso a lugar, dedicate los próximos entregables a los procesos mas pesados, tendrás mas sponsors, mas confianza y conocerás mejor a lo que te estas enfrentando.
5. Métricas: Siempre lo digo y en este tipo de iniciativa no será excepción, consigue todas las métricas existentes y define unas métricas objetivo, un cumplimiento o mejora que esperas, y comparte esto con los involucrados, si en tu caso, solo eres responsable de una parte (Personas, procesos o sistemas) asegúrate que la meta se comparta entre los responsables de todos los pilares.
6. Resistencia al cambio: Como siempre, todo es sobre las personas, y si he tenido resistencia en proyectos a sido en proyectos que involucran el CRM. Primero porque los empleados de las compañías sienten al CRM y el enfoque al cliente como una critica al trabajo que han realizado hasta ahora, y sobre todo porque los coloca en una posicion incomoda no de aprender, sino de desaprender la forma transacciónal en la que han trabajo hasta ese día, y como su trabajo empieza a preocuparse mas por el lado emocional del cliente. Con el punto cuatro, puedes ganar algunos sponsors que te ayudan a sobrevivir este proceso, de todas maneras, siempre existirá, es inevitable.

Solamente para concluir debo señalar que, este tipo de proyectos son de los mas emocionantes que puedes abordar, yo he participado en miles de proyectos tecnológicos, migraciones a la nube, páginas web, sistemas back, proyectos digitales, sin embargo los proyectos de CRM son de mis favoritos, son ese tipo de proyectos donde desde tecnologia en realidad sientes que estás transformando la empresa, así creo que las verdaderas areas de tecnologia deben operar.