En los últimos años nos han inundado las redes sociales y la prensa con la amenaza de que los robots van a acabar con la mayoría de trabajos. Esta idea se propagó aún más cuando Donald Trump señaló a los desfavorables acuerdos comerciales de EEUU como la principal causa de la mala coyuntura para los trabajadores industriales estadounidenses. Entonces, los principales medios norteamericanos comenzaron a publicar decenas de artículos defendiendo que el principal problema del trabajo industrial en EEUU era la robotización, que estaba automatizando tareas y expulsando a las viejas profesiones.
Desde entonces han salido otros muchos artículos sobre todas esas profesiones que van a desaparecer por culpa de los robots y las máquinas, incluso los gestores de fondos van a ser sustituidos por roboadvisors. Las ideas son sencillas de reciclar, como demuestra el afán de algunos (solo algunos) entusiastas de blockchain en convencernos de que esta tecnología va a acabar con notarios, el registro de la propiedad, los abogados y los bancos centrales.
Es evidente que la mecanización de muchas actividades económicas ha permitido un crecimiento económico incuestionable durante siglos. Y también lo es que seguirá introduciéndose más y nueva tecnología en los diferentes procesos productivos. Sin embargo, la visión del principio se caracteriza por una sobresimplificación de las cosas. La sustitución de una función de un trabajador por una máquina no es sencilla, y en muchos casos es antieconómica. Las máquinas también tienen costes, sería absurdo obviarlos. Al final se trata de los costes relativos y prestaciones entre unos factores de producción y otros.
Planta de Toyota en Ohira Sendai - Imagen de Bertel Schmitt - CC BY-SA 3.0
Muchos procesos llevados a cabo por humanos no están listos para ser automatizados de forma económica, ni siquiera están cerca. La siguiente historia de Ars Technica cuenta cómo Elon Musk ha tenido que admitir que se equivocó en sus planes de introducir mucha más automatización de la que aplican los fabricantes tradicionales en la producción de vehículos, un muy buen artículo que recoge los distintos problemas que aparecen cuando se intenta algo así. Elon Musk decía en 2016 que le parecía increíble que los robots de las factorías actuales de vehículos fuesen tan lentos, y que los fabricantes de robots le aseguraron sorprendidos que ningún fabricante les había solicitado robots más rápidos.
Tras casi un año desde el comienzo de la producción del famoso Model 3, Elon Musk reconoció que se equivocó en sus plantes de aumentar la automatización de las plantas. La factoría de Tesla produce menos de la mitad de vehículos por trabajador que cuando estaba en manos de Toyota en 1997 según algunas estimaciones.
Lo más importante: esto no es algo nuevo. Ya le pasó a General Motors en los años 80 y 90 con sus proyectos de robotización para fabricar vehículos. Ars Technica recoge este párrafo del libro ‘Comeback’ de 1994 sobre el fracaso de los planes de Genaral Motors en su exceso de automatización:
As Hamtramck's assembly line tried to gain speed, the computer-guided dolly wandered off course. The spray-painting robots began spraying each other instead of the cars, causing GM to truck the cars across town to a fifty-seven-year-old Cadillac plant for repainting. When a massive computer-controlled 'robogate' welding machine smashed a car body, or a welding machine stopped dead, the entire Hamtramck line would stop. Workers could do nothing but stand around and wait while managers called in the robot contractor's technicians.
A medida que la línea de ensamblaje de Hamtramck intentaba ganar velocidad, la carretilla guiada por ordenador se desviaba por completo de su trayecto. Los robots de pintado con spray comenzaron a pintarse unos a otros en lugar de a los coches, provocando que General Motors tuviese que enviarlos a una factoría de Cadillac de 57 años de antigüedad para volver a ser pintados. Cuando un robot de soldadura guiada por ordenador golpeaba la carrocería de un vehículo, o simplemente se apagaba, la línea entera de Hamtramck se paraba. Los trabajadores no podían hacer nada más allá de quedarse mirando y esperar a que los encargados llamasen a los técnicos de la compañía que proveía los robots.
General Motors no obtuvo ni un solo rendimiento positivo de sus masivas inversiones en este proyecto, irónicamente acabó provocando que la planta de producción necesitase más trabajadores que una normal de la época. Estos eran requeridos para cubrir todos los fallos que iban produciéndose. La lección es clara: el proceso de fabricación es más complejo de lo que parece.
Otra idea muy interesante del artículo de Ars Technica es el contraste entre la cultura de Silicon Valley y la industria del software frente al conocimiento acumulado de los fabricantes industriales. John Shook, un veterano de la industria, lo explica en este podcast transcrito por el artículo mencionado anteriormente:
"Everything about Tesla is supposed to be fast, the car, the development process, the launch process" [...] “let's start to build the thing before we've actually finished designing it. Because what we're building even for cash-paying customers is actually betas."
"The idea is we can go fast by leaving out steps, and we'll just iterate our way to something really good. But what we can see is that actually creates a lot of problems."
This kind of rapid iteration works well in the software industry because a programmer can change one line of code and then re-build the entire project with the click of a button. But physical manufacturing isn't like that. Car design decisions have to be translated into physical tooling that takes months to build and fine-tune.
And rapid iteration is a nightmare for suppliers.
Se supone que todo en Tesla tiene que ser rápido, el coche, el proceso de desarrollo, el proceso de lanzamiento, etc. [...] Vamos a comenzar a construir el producto antes de que hayamos terminado de diseñarlo. Porque lo que estamos fabricando para incluso clientes que pagan son realmente betas.
La idea es que podemos ir más rápido saltándonos fases del proyecto, y simplemente iremos iterando (ajustando sobre la marcha) hasta lograr algo bueno. Pero lo que podemos ver es que esto en realidad genera muchos problemas.
Este tipo de iteración rápida funciona muy bien en la industria del software porque un programador puede cambiar una línea de código y entonces reconstruir el proyecto entero con el click de un botón. Pero la fabricación física no es así. Las decisiones de diseño del vehículo tienen que ser trasladadas a las máquinas y herramientas, las cuales requieren meses para ser construidas y puestas a punto.
Y la iteración rápida es una pesadilla para los proveedores.
La idea de que lo que ha funcionado en determinado entorno y momento va a ser la fórmula mágica para todos los problemas empresariales es arrogante y muestra un desprecio al conocimiento y experiencia acumulada por otras organizaciones establecidas. También es un error pensar que todo es automatizable de forma económica a corto plazo, no siempre merece la pena invertir gigantescos recursos en diseñar determinados robots y procesos. A veces puede salir extremadamente más caro que adoptar cambios más graduales sobre los procesos existentes. Los robots también tienen costes de mantenimiento, y sobre todo de diseño, que se disparan casi al infinito en situaciones complejas.
*Cartera Value: Si está interesado en el análisis de compañías desde una perspectiva de largo plazo, no dude en visitar la página de información de la Cartera Value.
En las próximas semanas confirmaremos las fechas y los contenidos del Curso de Análisis Fundamental en inBestia (habrá novedades con respecto a la edición anterior), el cual tengo previsto impartir por completo a partir de mayo. Si desea recibir información directa sobre el curso en su momento, puede contactar por correo electrónico: enrique.garcia@inbestia.com.
Contenidos relacionados:
