nodos en la red

Un majadero haciendo data mining sigue siendo un majadero

¿A alguien le apetece compartir con el resto de los hipotéticos lectores el por qué cree que esto es una de las mayores gilip*lleces de los últimos tiempos?  Mi respuesta es fácil de imaginar, está en la línea de "incapacidad manifiesta para pensar en términos de sistemas" que lleva a una "búsqueda equivocada de óptimos locales a costa del óptimo global", etc., pero creo que se les puede despellejar desde una infinidad de perspectivas sin tener que recurrir siquiera a argumentos de índole moral o ética [por ejemplo, desde una perspectiva legal].

Por si no queda claro: no tengo nada, en absoluto, en contra del uso del data mining.  Vamos, ¿no sabéis ya lo que me gusta "crunchear" números?  Es el 'para qué' aplican la tecnología y las promesas que el proveedor del servicio hace a sus clientes con respecto de los resultados esperados lo que considero no sólo terriblemente equivocado desde un punto de vista conceptual, sino hasta peligroso para la empresa que les contrate.

¿Reducir costes o aumentar ventas?

Esta es una pequeña gran duda para debatir con un café... que es precisamente el momento en el que, charlando con un buen amigo, me ha surgido.  Para ser honestos, la pregunta me rondaba la cabeza desde hace unos días, porque se ha tratado esta semana en el foro Yahoo CMSIG.

Me dice mi amigo, emprendedor del sector de Selección de RRHH, los perfiles de marketing & ventas están totalmente a la baja, mientras que todos los relacionados, por decirlo de algún modo, con la reducción de costes [compras, operaciones, controllers...] están demandándose como un balcón en la calle Sierpes en plena Semana Santa sevillana.

La conclusión de mi amigo es que las empresas han renunciado a seguir creciendo, no creen en la posibilidad de salir de la crisis vendiendo más, que a la postre es lo que les permitiría ganar más dinero y, por lo tanto, salir adelante con menos perjuicios. Tratan a la desesperada de "eliminar grasa", algo que probablemente les venga bien, pero que tal vez no sea tan importante. ¿O sí?

Personalmente, creo que estamos perdiendo el rumbo cosa mala.  Creo que Goldratt no anda desencaminado en sus recomendaciones.  Me centraría en agilizar el flujo de operaciones al máximo, disminuyendo inventarios y liberando cash, y utilizaría ese cash para desarrollar ofertas innovadoras, mafiosas, dirigidas a mejorar los resultados del cliente.

Pero claro, el papel aguanta lo que le echen...

Prioridades

Sigo dándole vueltas al concepto de 'escasez', una idea central en la Economía, si es que hay alguna.

Los políticos [también muchos economistas] tienden a olvidar que el dinero es también un recurso limitante.  Si recordáis el sencillo algoritmo de mejora continúa definido por Goldratt, una vez identificada la limitación hay que decidir cómo explotarla.  En otras palabras, si el dinero escasea, hay que asegurarse de que se emplea de la mejor manera posible.  Suena a perogrullo, pero ¿No habéis pensado alguna vez que nuestros dirigentes tomaban las decisiones de asignación de recursos basándose más en consideraciones políticas o mediáticas que en razonamientos bien fundamentados?  Pues eso.

Una aplicación NO es un servicio

Una "aplicación" no es un servicio.
Una "plataforma", tampoco.
Para terminar, una aplicación, o una "plataforma" 'pasada a producción' a duras penas empieza a ser el germen de un servicio, si entendemos por tal algo por lo que alguien está dispuesto a pagar [ahora y en el futuro], algo que satisface [razonablemente] unas necesidades y/o expectativas [mejor o peor definidas].

Hay formas más divertidas de hundir una empresa de base tecnológica, pero pocas son tan eficaces como ignorar este simple hecho: las funciones no técnicas de la empresa - marketing, comercial, asesoría jurídica, whatever - también son responsables de conseguir que una aplicación [o una plataforma] llegue a ser el núcleo operativo de un servicio rentable de base tecnológica.  Y su trabajo comienza mucho antes de que dicha aplicación sea ni siquiera la sombra de una idea en la mente del programador que se va a picar las 250000 líneas de código en cuestión.

Si todo esto os parece de cajón, pues qué buena suerte.

Proteger la máquina [second and last... por ahora]

[En vista de que no puedo continuar esta serie de entradas sobre el tópico "proteger la máquina" al ritmo que quisiera, voy a cerrarla provisionalmente con este post]

En principio, todo se reduciría a establecer un "compás" en la entrada de peticiones a "fábrica".  En primer lugar, tomaríamos medidas para acabar con esa sangría de la productividad que es la multitarea mala.  A continuación, adoptaríamos medidas para regular el flujo de órdenes de acuerdo con la capacidad del recurso limitante (a.k.a. 'cuello de botella') y estableceríamos protecciones [buffers] allá donde más se necesitasen, es decir: justo antes de 'tocar' al cliente, para garantizar el cumplimiento de la fecha de entrega; justo antes de la limitación, para garantizar que siempre esté al 100% de ocupación y en algún otro sitio, dependiendo para empezar de si trabajamos en un entorno de proyectos o más bien en un entorno de producción.  Si la demanda supera con creces la capacidad del recurso limitante, entonces habría que romper la limitación.  Sería el momento de aplicar TRIZ, Six Sigma, BPR, Lean... whatever. Atentos al traslado del cuello de botella a otro elemento del sistema.

Proteger la máquina [first]

[A manera de introducción...] Las 76 Soluciones Estándar de TRIZ son una evidencia más de la superhumana capacidad de trabajo del 'padre' de esta disciplina, Genrich Altshuller.  Posteriores a los 40 Principios Inventivos, son, como éstos, un intento de inventariar - creo que esto le hubiera encantado a Borges - todas las posibles formas de resolver problemas en sistemas técnicos.  Su uso es inseparable de una técnica de modelado realmente cojonuda, denominada Su-Field Analysis, que permite representar cualquier sistema mediante tan solo TRES entidades - una "herramienta", un "objeto" y una interacción, denominada "campo".  Es increíble la claridad de pensamiento que aporta esta técnica de modelado [sintiéndolo mucho, no voy a extenderme en este punto por ahora].

Las 76 Soluciones no son, sin embargo, la obra mejor acabada de Altshuller, lo que convierte su empleo a menudo en algo frustrante.  Ha habido varios intentos de reorganizar esta información, principalmente para eliminar redundancias con otras herramientas de TRIZ y hacer su uso más intuitivo o, al menos, más racional.  De todos ellos, me gusta especialmente el trabajo de Xiaoming Mao, Xueqing Zhang y Simaan AbouRizk [increíble la cantidad de autores de origen chino que están publicando sobre TRIZ en los últimos años ].  Estos autores redujeron las 76 Soluciones a 7 soluciones generales.  Vamos a empezar con éstas.

Proteger la máquina [zero]

Hace unos días, con motivo de la publicación de un nuevo trabajo de investigación de Eric Wolstenholme en la Systems Dynamics Review, os hablaba en estas mismas páginas de la tendencia de muchos managers a exprimir la máquina organizativa mucho más allá de los límites de funcionamiento para los que ha sido diseñada o, más sencillamente, de su capacidad real.  El tema me interesa mucho y me gustaría explorarlo "en voz alta", desde estas páginas.  Para ello os propongo un ejercicio.

The Dance of the Blind Reflex [3 y final]

Termino con esta entrada la serie dedicada al trabajo de Barry Oshry.  Termino no porque no haya más que decir, sino porque en algún momento tengo que parar.  Recomiendo a todos los que se hayan sentido interesados por esta visión sistémica de las relaciones humanas que se hagan - legalmente, si es posible - con alguno de los títulos de Oshry, especialmente con 'Seeing Systems: Unlocking the Mysteries of Organizational Life'.  La Danza del Reflejo Ciego - en la horrorosa traducción que os he impuesto - tiene un nombre más técnico, menos ilustrativo, tal vez, pero que personalmente prefiero: ruptura sistémica de relaciones.  A continuación, mis últimas notas sobre qué formas adoptan, cómo se originan y cómo pueden corregirse estas 'patologías' de los sistemas humanos.

Dilbert on making decisions

Dilbert habla con el Barrendero Sabio:

Dilbert: ¿Por qué parece como si la mayoría de las decisiones en mi lugar de trabajo fueran tomadas por lemures borrachos?

Barrendero Sabio:  Las decisiones son tomadas por las personas que tienen tiempo para tomarlas, no por las personas que tienen talento.

D: ¿Y por qué las personas con talento no tienen tiempo para tomar decisiones?

B.S.:  Están muy ocupadas intentando arreglar los desastres provocados por las personas que sí tienen tiempo.

Algunas ideas para negocios basados en el recurso 'conocimiento'

En la línea de la ya clásica - por el número de visitas que recibe - entrada 'El Cibercafé', así como aquella otra, anterior, en la que hablaba de nuestra particular taxonomía de modelos de negocios, quiero apuntar un par de ideas para aquellos negocios que, como la consultoría, se basan en el aprovechamiento del recurso 'conocimiento'.  Aunque hablaré principalmente para mis colegas de profesión, creo que si aguantáis la chapa hasta el final, comprobaréis que son de aplicación mucho más amplia.  Para los impacientes, éste es el resumen: uno, no penséis en 'conocimiento', pensad en términos de 'contenido'; dos, pensad en 'micro', centraos en 'the long tail'.