Plataformas de fabricación: ¿Construir o comprar?

Cuando se trata de plataformas de fabricación, las decisiones de compra son complicadas.

Podría pensar que esto se debe a que hay muchos proveedores que ofrecen una gran variedad de soluciones, y estaría en lo cierto.

Pero las decisiones de compra no sólo se complican por un campo de juego abarrotado. Para muchos fabricantes, la decisión no es en qué proveedor depositar su confianza. En su lugar, es si deben o no construir una solución internamente.

En resumen, las decisiones de compra a menudo se reducen a una vieja pregunta: ¿construir o comprar?

He aquí las siete preguntas que debe plantearse:

1. ¿Es caro construir en casa?
2. ¿Tiene en cuenta los costes corrientes?
3. ¿Será escalable?
4. ¿Cómo gestionará la complejidad?
5. ¿Comprende el departamento de TI sus operaciones de fabricación?
6. ¿Será lo suficientemente sencillo de utilizar?
7. ¿Hasta qué punto será flexible?

Sin más preámbulos, profundicemos en cada pregunta.

1. ¿Es caro construir en casa?

Si su organización cuenta con un equipo de desarrolladores de software, la construcción interna podría ser la solución lógica.

Trabajar con un equipo interno puede permitir una mayor precisión en el alcance del proyecto, un mayor control sobre la ejecución y puede aliviar muchas de las dificultades de gestión del proyecto que conlleva la compra a un proveedor.

Sin embargo, eso no significa que vaya a ser el más rentable. También puede que no sea el más rápido.

Para hacerse una idea de los costes basta con hacer unas simples cuentas.

Dependiendo de la fuente que consulte, el proyecto de software medio tarda aproximadamente 10 meses en completarse. Los proyectos más pequeños pueden rondar los cuatro meses, mientras que los más grandes pueden superar fácilmente el año.

Si un desarrollador medio gana entre 60 y 100 dólares la hora, eso eleva el coste de un proyecto de software a unos 107.400 - 179.000 dólares para un proyecto de un año de duración. Para un desarrollador.

Además, quizá quiera tener en cuenta el coste de oportunidad del tiempo que sus ingenieros de software dedican a un proyecto. ¿Qué proyectos está dejando en suspenso mientras sus ingenieros crean aplicaciones para el taller?

2. ¿Incluyó su cálculo los costes corrientes?

Según nuestra experiencia, los costes del software no terminan con la entrega inicial. (Más adelante contaré una historia sobre la experiencia de un fabricante que incurre en costes de soporte continuos, así que permanezca atento).

A menudo, las aplicaciones de fabricación propias deben modificarse y actualizarse para tener en cuenta los cambios en los procesos de fabricación.

Si la solución se construye internamente, eso significa que cada modificación requiere el envío de tickets, el cumplimiento y la redistribución. Si se tarda dos semanas (suponiendo que los cambios requieran un sprint) en impulsar un cambio, eso son dos semanas de tiempo de ingeniería de software que facturar, además de los ingresos perdidos por el retraso en las mejoras del proceso.

3. ¿Escalará?

La gran ventaja de una solución propia, hecha a medida, es que puede tener en cuenta las necesidades únicas de una línea de producción, célula o proceso.

Pero, ¿funcionará su solución personalizada para varias líneas? ¿Funcionará para todas las líneas de una planta? ¿Puede extenderse a toda una región o a escala internacional?

Una de las preocupaciones de las soluciones a medida es que no se amplíen. Transferir la solución a un nuevo contexto puede acarrear costes de proyecto y plazos similares a los de la solución inicial.

4. ¿Cómo gestionará la complejidad?

A medida que los sistemas autóctonos se expanden, existe un compromiso entre el alcance y la complejidad.

A medida que los sistemas abarcan una gama más amplia de procesos y operaciones, se vuelven más complejos.

Aunque esto no es una ley natural, es un hecho en la fabricación desde hace décadas.

Así pues, a medida que su solución interna crece en alcance, ¿crecerá también en complejidad?

5. ¿Construirá la TI los procesos de fabricación más eficaces?

Cuando son encuestados por los consultores, los ingenieros esbozan un mensaje recurrente: "¡El departamento de TI no entiende los problemas de OT!".

A menudo, esto exige la formación interna de un grupo informático de fabricación, lo que en sí mismo puede resultar costoso.

Sólo las operaciones de fabricación (ingenieros) saben qué tipos de soluciones necesitan realmente en su taller.

El departamento de TI suele actuar como proveedor de servicios para el grupo de operaciones de fabricación. Con cualquier acuerdo de servicios, el éxito depende de unas relaciones de trabajo sólidas y de una comunicación clara.

Sin embargo, cuando el grupo de TI se encarga de desarrollar la solución en nombre del grupo de OT, a menudo se malinterpretan los requisitos o se pasan por alto por completo.

Esto puede crear una tensión innecesaria entre TI y OT. Y la tensión puede conducir a resultados de proyecto subóptimos.

6. ¿Podrán utilizarlo los trabajadores que lo necesiten?

Muchas interfaces de usuario (UI) en el taller parecen haber sido diseñadas para la era Windows 95/98.

Como resultado, los operarios, supervisores y nuevos ingenieros de procesos suelen tener dificultades con la introducción de datos y deben recibir una formación exhaustiva para utilizar estos sistemas.

En 2020, estamos acostumbrados a experiencias de usuario altamente optimizadas.

Nos demos cuenta o no, las interfaces de los consumidores están diseñadas para facilitar nuestros objetivos e intenciones.

En el trabajo, deberíamos poder interactuar con soluciones que permitan experiencias tan fluidas como las que encontramos en los teléfonos inteligentes.

7. ¿Hasta qué punto será flexible su solución interna?

Los procesos de fabricación cambian. Quizá sólo sutilmente. Pero a medida que cambian las líneas de productos, la demanda de los clientes y las tecnologías, también lo hacen los procesos de fabricación.

¿Su solución interna será capaz de adaptarse?

¿Cuánto tardarán sus desarrolladores en introducir los cambios? ¿La gestión de pequeñas variaciones en el producto creará enormes quebraderos de cabeza?

Esta última pregunta sobre la flexibilidad me lleva a una historia que creo que resume muy bien los puntos de este post.

Recientemente tuve la oportunidad de escuchar a un ejecutivo de un gran fabricante multinacional describir el proceso de pensamiento que subyace a su decisión de trabajar con Tulip en lugar de construir una solución internamente.

Aquí lo tiene:

El ejecutivo comenzó describiendo el compromiso de su organización con los principios lean. Todas sus plantas perseguían la mejora continua de forma agresiva.

Esto significaba que la disposición de las células de trabajo y el diseño del proceso eran muy flexibles.

Cada vez que un ingeniero sugería una nueva configuración de la célula de trabajo o la empresa actualizaba sus líneas de productos, el departamento de TI tenía que realizar sutiles pero laboriosas actualizaciones del software. Esto significaba codificar cada cambio en C++.

Este estado de cosas pronto se hizo insostenible. Los trabajadores de primera línea estaban descontentos porque las pequeñas mejoras de los procesos requerían un largo ir y venir con el departamento de TI. El departamento de TI se sintió frustrado porque los pequeños cambios en el taller suponían horas agotadoras para sus desarrolladores de software.

En última instancia, el ejecutivo de fabricación decidió que era más fácil trabajar con un proveedor de plataformas de fabricación que construir una solución internamente.

Cuando los ingenieros necesitan realizar un pequeño cambio en una aplicación, ahora hacerlo es tan sencillo como realizar un cambio en un Powerpoint, sin necesidad de soporte informático.

La principal ventaja de crear una solución internamente es que puede desarrollarse a medida para satisfacer una necesidad específica.

Encargarse internamente de un proyecto de software puede dar a una organización de fabricación un mayor control sobre el producto final. Trabajar internamente puede eliminar muchas dificultades de la gestión de proyectos

Y, sin embargo, estas ventajas potenciales son también la fuente de los mayores inconvenientes del software a medida: costes desorbitados, requisitos hinchados y falta de configurabilidad.

En última instancia, lo que funcione para usted es una cuestión de requisitos del proyecto, presupuesto y recursos.