En el hilo turras de hoy, vamos a hablar de un aspecto normalmente ignorado en escenarios de complejidad, los procesos de alta variabilidad.
https://twitter.com/Recuenco/status/1527708570904678400?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
La persona que me introdujo al concepto y con la que más he hablado sobre el tema es mi sis @SylviaDM , así que todo este hilo goes to you, sis!
https://twitter.com/SylviaDM/status/1527718902951821319?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
El otro día, en @NadaQueGanarPod estuvimos hablando de un tema hot, las recientes modificaciones en USA sobre la ley Wade vs. Roe y por extensión estuvimos hablando en general de la legislación sobre la nueva ley del aborto.
https://twitter.com/NadaQueGanarPod/status/1527535254210322432?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
En un momento dado, vengo a decir que es absolutamente imposible crear una ley del aborto satisfactoria. Que tenemos la situación del infierno.
Por un lado, porque es un tema que polariza por completo a la tribu, y a partir de ahí, no hay discusiones objetivas de ninguna clase. Una cuestión de Rorschach de libro.
https://twitter.com/Recuenco/status/1527540299626586112?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
Pero por otro lado, porque es un proceso netamente contextual y la legislación en general está basada en que la sociedad se da un acuerdo sobre un tema que se aplica en general con pocos matices o atenuantes. Y cuantos más matices, más torcemos el morro.
La asunción estándar sobre este tipo de procesos es que es básicamente inviable gestionarlos como es debido, así que llegamos a una especie de solución de compromiso.
Tenemos incrustada en el cráneo una dicotomía completamente falsa en este contexto heredada del Taylorismo más básico: Podemos elegir entre tener un proceso que gestione el contexto o tener un proceso que escale.
Fijaos que a alguien como @jaime_rdes , que es el hijo del embajador suizo y de una agregada de la ONU, le sale de manera automática la definición de "problema imposible" y la búsqueda del menosmalismo.
Es decir, podemos elegir entre hacerlo bien, a mano, a costes desorbitados e imposible hacerlo a gran escala, o hacerlo a gran escala y asumir que cometeremos una serie de cagadas inevitables. La alta granularidad es básicamente inmanejable.
El core de la Personotecnia es básicamente decir que esta es una falsa dicotomía, y que realmente se pueden servir a escala respuestas acordes, relevantes, con contexto gestionado y precisas.
Visto históricamente, el problema del enfoque de la Personotecnia es que ha sido completamente Data-centric y no Process-centric.
Nuestro sesgo era obvio: Veníamos de los datos. Los datos eran el alfa y el Omega, la gestión del contexto era relevante desde un punto de vista data-centric y los procesos eran eso, temas procedurales.
Yo tenía grabado aquello de Wirth de que algoritmos + estructuras de datos = programas.
Mi vida ha sido darme cuenta de que el determinismo tranquilizador que me imbuyeron en la facultad tiene un montón de letra pequeña. De hecho, es bullshit puro. Es una simplificación. Es una vaca esférica.
https://twitter.com/Recuenco/status/1417790824402886656?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
De hecho, la propia informática en términos globales ha sufrido una transformación similar.
Ha partido de la mecánica algorítmica, que domina a la perfección, porque es una vaca esférica solo aplicable a contextos muy simples y está intentando aproximarse a como funcionamos los humanos.
Por eso a los ordenadores se les da de puta madre calcular los infinitos decimales de PI o sobarnos los morros al ajedrez, pero es incapaz de crear un sistema que emule de manera creíble a un humano todavía.
Varios ejemplos de esta transición en la informática se pueden observar en cosas como la aparición de la programación orientada a objetos.
La programación orientada a objetos difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida.
La programación estructurada prima el concepto de procedimientos o funciones sobre el de estructuras (se emplean principalmente funciones que procesan datos).
La programación orientada a objetos, en cambio, primero se definen los objetos o estructuras para posteriormente solicitar la ejecución de sus métodos.
Los conceptos de la POO tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo Noruego en Oslo.
En este centro se trabajaba en simulaciones de naves, y se encontraron con que la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras hacia impracticable usar la aproximación procedural estándar.
La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus "propios" datos y comportamientos.
Fascinante, no? Tenemos una herramienta que nos sirve hasta que encontramos una situación para la que se revela insuficiente, y procedemos a crear otra nueva que soluciona esa limitación. La historia de la evolución humana in a nutshell.
En su momento, yo me había salido de la carretera diciendo que los datos no están escritos en piedra, que los datos son software, que el Human Data Model es necesario porque necesitamos actualizar nuestra aprehensión de la realidad.
https://twitter.com/Recuenco/status/1378251722246742017?s=20&t=-h4PyeOhOjWDcWZXJOl1xg
Fue llegar a la complejidad y la primera hostia en toda la boca fue darme cuenta de que a los procesos/algoritmos les pasa exactamente igual.
Por un lado, la determinación de que el algoritmo no mana de las ubres de Afrodita pristino e inmaculado, sino que tiene más sesgo que la hostia. Y que "All models are wrong".
Y por otro lado, percatarte de la existencia de conceptos como la alta variabilidad, que no tenía mapeados en mis ámbitos de competencia históricos.
La alta variabilidad es una piedra angular de los procesos fabriles e industriales, por ejemplo.
La variación del proceso se produce cuando los procesos no siguen un patrón preciso. Es una de las principales causas de problemas de calidad tanto en los procesos transaccionales como en los de producción.
La consistencia facilita la replicación, y la replicación es a menudo la clave del crecimiento y la expansión, ya sea para el propietario de una franquicia o la escala global masiva de empresas como McDonald's o Starbucks.
Un Big Mac sabe (más o menos) igual dondequiera que vayas, y el "Venti Latte" es una lingua franca en más de 55 países.
En pocas palabras, nuestro objetivo es realizar los procesos de tal manera que los resultados sean repetibles. Si no sabemos cómo hemos llegado hasta ahí, no necesariamente podremos conseguir el mismo resultado de forma predecible. De hecho, es probable que no lo hagamos.
Cuando surgen problemas de calidad, a menudo el problema sólo se identifica una vez que el problema se ha convertido en un desastre en toda regla. Los gestores que se dan cuenta de la excepción o la anomalía deben rastrear el origen del problema.
Y no sólo eso, sino que un gestor inteligente también debe determinar en qué punto se han estropeado las cosas y tomar las medidas necesarias para evitar que el problema vuelva a surgir.
Si la variación del proceso es excesiva, resulta mucho más difícil determinar las áreas de mejora.
La variación del proceso es un concepto de importancia en las metodologías de mejora empresarial como el método Six Sigma. es.wikipedia.org/wiki/Seis_Sigma
La variación del proceso es un concepto de importancia en las metodologías de mejora empresarial como el método Six Sigma. es.wikipedia.org/wiki/Seis_Sigma
La madre que me matriculó en Estructura de Datos y de la Información. Turra Limit hits. Ni he empezado a rascar la superficie. A recoger el petate e ir cerrando el kiosko.
Los procesos de alta variabilidad (PAV) son un subconjunto de procesos que lidian con aspectos críticos en los que hay máxima granularidad y la aproximación procedural básica es insatisfactoria e incompleta.
Los procesos que interactúan con humanos, como regla general, suelen ser PAVs dado que el humano es por regla general el Sistema Complejo Primigenio.
Cuando tu abordas un PAV desde una aproximación procedural, ya estás intentando encajar una forma circular en un agujero cuadrado.
Cuando piensas que una plataforma procedural (CRM, App de cliente o similar) puede albergar un PAV (Gestión de la relación cliente/marca), ya estás cometiendo un error de base.
Cuando el PAV involucra temas humanos/emocionales como es el caso por ejemplo de atencion al cliente, y se abordan de manera procedural clásica, aparecen los procesos Golem, en terminología de Sylvia:
https://twitter.com/AtlasTec/status/1515585860267384833?s=20&t=aVljG9wchYDKxtQRXmdYtQ
El modelado/diseño de PAVs requiere herramientas específicas (Personotecnia, Diseño Artifact-Centric, Abstracción procedural...) que no corresponden al arsenal clásico de las compañías a las que se suele encargar éstas tareas (Design Thinking y similares)
Quien lo iba a pensar, los PAVs son un problema complejo que demanda de una aproximación Orquestada y Multidisciplinar. Sorpresón en el Bellaggio. #finhilo
P.D I: Obviamente, mil libros sobre la materia, pero si tengo que coger uno, el que abrió la lata de gusanos para mi, cortesía también de Sylvia: goodreads.com/book/show/1820…
P.D II: Procesos de cambio Cultural? PAV de libro. shows.acast.com/thework/episod…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
