Resumen técnico
Conclusiones clave:

El artículo señala que la rentabilidad del modelo de ejecución se evalúa mejor en función de la responsabilidad, las interfaces y la capacidad de gestionar los cambios que únicamente por el precio del proyecto. Los mayores costes y riesgos suelen aparecer cuando no están claros los requisitos, los límites de la máquina y el reparto de responsabilidades.

  • La decisión entre la gestión interna y la externalización influye en los plazos, las modificaciones de diseño, el riesgo del fabricante y el control sobre la conformidad.
  • La clave no es solo comparar costes, sino determinar dónde se genera y se conserva el conocimiento crítico para el ciclo de vida de la máquina.
  • La externalización puede ser una opción racional cuando el alcance está claramente definido y el número de cambios es reducido, siempre que el cliente controle los requisitos, las recepciones y la documentación.
  • La falta de un equipo por parte del cliente hace que cada cambio se convierta en un encargo independiente y que el calendario quede supeditado al proveedor.
  • Independientemente del modelo, el fabricante o la entidad que pone la máquina en servicio es responsable de la conformidad, la evaluación de riesgos y la documentación CE.

La decisión de desarrollar una oficina técnica propia o basar la construcción de máquinas en la externalización ha dejado de ser una cuestión limitada al coste de una plantilla interna o a la tarifa de un proveedor. Hoy influye directamente en el plazo de puesta en marcha, en la capacidad para introducir cambios de diseño, en el nivel de riesgo que asume el fabricante y en el control real sobre la conformidad. En proyectos en los que la mecánica, la automatización, el software, la seguridad funcional y la documentación técnica deben converger en un único punto de aceptación, un modelo organizativo equivocado suele pasar factura no al principio, sino al final del proyecto: en las recepciones, los cambios de alcance, la validación o la preparación de la documentación para el usuario y el servicio técnico. En la práctica, por tanto, la pregunta no es qué resulta «más barato», sino qué modelo permite mantener la responsabilidad, el conocimiento del proyecto y la velocidad de decisión en un nivel adecuado a la complejidad de la máquina.

La importancia de esta elección también aumenta porque la máquina actual rara vez es solo un sistema mecánico con un control sencillo. Cada vez con más frecuencia incorpora una capa de software, comunicación con los sistemas de planta, registro de eventos, trazabilidad del producto y del proceso y, además, requisitos del área de mantenimiento en materia de diagnóstico y servicio. Esto hace que la frontera entre el «proyecto de máquina» y la «organización de la colaboración entre varias competencias» se difumine muy rápido. Si ya desde el inicio se sabe que en el proyecto participarán un integrador, un proveedor de software y el equipo de mantenimiento del cliente, la decisión entre in-house y contratista externo pasa de forma natural a ser una cuestión de reparto de funciones, responsabilidad sobre las interfaces y titularidad de las decisiones técnicas. Del mismo modo, el tema se amplía cuando la máquina debe generar datos de producción o dar soporte a la trazabilidad: sin definir quién responde de la arquitectura de datos, de la validación de la lógica y del mantenimiento de los cambios, es fácil construir una solución vistosa en la demostración, pero costosa en la explotación.

En la práctica, el criterio de decisión más útil no es la simple comparación del presupuesto de ejecución, sino el lugar donde se genera y debe permanecer el conocimiento crítico para el ciclo de vida de la máquina. Si la ventaja de la empresa reside en un proceso único, en modificaciones frecuentes del producto, en la necesidad de cambios de formato rápidos o en el desarrollo de nuevas variantes sobre la misma plataforma, la falta de capacidad propia de diseño eleva el coste de cada cambio posterior. A la inversa, cuando el proyecto tiene un alcance claramente definido, un bajo nivel de modificaciones repetitivas y no constituye el núcleo de la ventaja competitiva de la empresa, un contratista externo puede ser una solución razonable, siempre que el cliente mantenga el control sobre los requisitos, las recepciones y la documentación. Una buena prueba consiste en responder a tres preguntas: quién toma la decisión cuando cambia el alcance, quién entiende las consecuencias de ese cambio para la seguridad y las funciones de la máquina y quién podrá mantener la solución tras la puesta en marcha sin depender de una sola persona o de un único proveedor. Estos son indicadores organizativos que, por lo general, predicen mejor la rentabilidad que el mero presupuesto del proyecto.

Un ejemplo típico se repite de forma muy parecida en muchas plantas. La empresa encarga externamente el diseño y la construcción de la máquina porque quiere acortar el tiempo de arranque de la inversión. Al principio gana velocidad, pero al cabo de unos meses aparecen cambios derivados de las pruebas tecnológicas, de las necesidades de producción y de los requisitos de calidad. Si no cuenta de su lado con un equipo capaz de evaluar el impacto de esos cambios en el diseño, el control, el diagnóstico y la documentación, cada corrección se convierte en un pedido independiente y el calendario empieza a depender de la disponibilidad del proveedor. En ese momento, la externalización deja de ser una compra de competencias y pasa a ser el traslado del cuello de botella fuera de la organización. Precisamente ahí el tema se conecta con la organización de la colaboración entre el integrador, el proveedor de software y mantenimiento, así como con el diseño de la trazabilidad: si estas áreas no tienen un propietario común de los requisitos, el proyecto pierde coherencia operativa incluso antes de la recepción.

Al final, la cuestión de la responsabilidad siempre vuelve. Con independencia del modelo de ejecución, es el fabricante, el importador u otra entidad que introduzca la máquina en el mercado o la ponga en servicio quien responde, en el alcance que corresponda, de la conformidad del producto, de la integridad de la documentación y de la correcta realización de la evaluación de riesgos. Por eso, la elección entre una oficina técnica propia y la externalización también debe valorarse desde la perspectiva de quién está en condiciones de justificar las bases de las decisiones de diseño, reconstruir el historial de cambios y preparar el material necesario desde el proyecto hasta la certificación y el marcado CE, cuando el caso lo requiera. Si la organización no puede garantizarlo, el aparente ahorro en la fase de proyecto se transforma con mucha facilidad en el coste de un retraso, de una disputa con el contratista o de un problema en la recepción técnica y en la explotación.

Dónde suele aumentar el coste o el riesgo

En la disyuntiva entre contar con una oficina técnica propia o recurrir al outsourcing, el coste rara vez se dispara donde todos miran al principio: en la tarifa del proyectista o en el presupuesto del paquete de trabajos. Lo más habitual es que el problema empiece antes, con una definición incompleta de los límites de la máquina, las interfaces, la responsabilidad sobre las hipótesis de partida y la forma de aprobar los cambios. Si estos elementos no quedan cerrados desde el inicio, el equipo interno consume tiempo en coordinaciones y correcciones, mientras que el proveedor externo diseña sobre sus propias suposiciones, que después hay que deshacer. En la práctica, esto no solo implica horas de trabajo adicionales, sino también retrasos en la compra de componentes, interferencias durante el montaje y discusiones sobre si el error se debe a un diseño defectuoso o a un pedido impreciso. Por eso, el primer criterio de decisión no debería ser quién «lo hará más barato», sino quién es capaz, en ese modelo de trabajo, de mantener la coherencia de los requisitos técnicos, de seguridad y de explotación desde el concepto hasta la recepción.

El segundo punto en el que aumenta el riesgo es la separación de competencias sin una separación equivalente de responsabilidades. Una oficina técnica propia puede parecer una opción segura, porque el conocimiento permanece dentro de la organización, pero si el proyecto lo llevan personas que al mismo tiempo atienden el soporte a producción, el mantenimiento y los cambios del día a día, el proyecto empieza a depender de la disponibilidad de las personas y no de la lógica técnica. Por su parte, la externalización de ingenieros permite acceder más rápido a recursos, pero sin una supervisión madura por parte del cliente es fácil llegar a una situación en la que el proveedor entrega una documentación suficiente para cerrar y facturar una fase, pero insuficiente para el servicio, la modernización o para justificar las bases de las decisiones de diseño. El coste de esa carencia aparece después: en una avería, al cambiar de contratista, al ampliar la línea o cuando hay que comprobar si la máquina es segura no de forma declarativa, sino a partir de las soluciones realmente aplicadas y de la trazabilidad de las decisiones.

Los errores más costosos suelen tener un carácter acumulativo. Un ejemplo típico es el de un proyecto en el que la mecánica, el control y las medidas de reducción del riesgo se desarrollan en distintas áreas de la organización o por distintos contratistas. El mecánico da por supuesto un determinado modo de acceso a la zona de trabajo, el especialista en automatización define la lógica de parada con datos incompletos y compras pide los elementos según el plazo de entrega, no según los criterios de seguridad y mantenimiento. En la puesta en marcha se descubre que el resguardo dificulta el cambio de formato, que el sensor no dispone de condiciones de trabajo estables y que el procedimiento de trabajo manual ni siquiera se ha descrito. Entonces el proyecto vuelve a rediseñarse, aumenta el número de cambios en la documentación y hay que volver a acordar el alcance con el contratista. Aquí el criterio práctico de evaluación es simple: si la organización no puede identificar en una sola revisión al responsable de los requisitos, al responsable de la evaluación de riesgos y al responsable de la decisión de cambio, entonces, con independencia del modelo de ejecución, existen condiciones para que aumenten el coste y la responsabilidad.

Este asunto entra en el ámbito del trabajo sobre el riesgo de proceso antes de lo que muchas empresas suponen. Si el proyecto afecta a una instalación con interacciones relevantes del proceso, secuencias operativas y estados peligrosos que dependen de la organización del trabajo, limitarse a «añadir protecciones» llega tarde. En ese caso, no solo importa la experiencia del diseñador, sino también si el equipo sabe realizar un análisis estructurado de peligros y desviaciones. No se trata de formalismo por el formalismo, sino de la capacidad de detectar los puntos en los que la decisión tecnológica, operativa y de seguridad se influyen mutuamente. Si esa capacidad no existe dentro de la empresa, el outsourcing puede estar justificado; si tampoco existe del lado del proveedor, el riesgo simplemente se desplaza fuera de la organización.

Solo al final se hace visible la dimensión del cumplimiento. Cuando el proyecto llega a la recepción, la modernización o la entrega para su uso, la pregunta ya no es quién hizo el modelo 3D o quién escribió el programa, sino si puede demostrarse que las soluciones adoptadas estaban justificadas, que el riesgo fue evaluado y que la documentación corresponde a la ejecución real. En este punto, la elección entre una oficina propia y una externa se conecta ya de forma directa con la preparación de la máquina, desde el proyecto hasta la certificación y el marcado CE de máquinas, cuando el caso lo exige. Si el material de evidencia está incompleto, el coste deja de ser un coste de proyecto y pasa a ser un coste de responsabilidad: puesta en marcha retrasada, retrabajos adicionales, una recepción complicada o limitaciones en la explotación. Por eso, una comparación sensata entre modelos de ejecución conviene basarla en indicadores medibles: número de cambios tras congelar las hipótesis de partida, tiempo de aceptación de decisiones entre disciplinas, integridad de la documentación final de obra y capacidad de reconstruir por qué una determinada solución se consideró admisible.

Cómo abordar el tema en la práctica

En la práctica, la pregunta sobre contar con una oficina de ingeniería propia o recurrir al outsourcing no debería plantearse en términos de tarifas por hora, sino en términos de control de la decisión técnica y de responsabilidad por sus consecuencias. El modelo rentable es el que permite tomar antes decisiones de diseño justificadas, mantener la coherencia entre mecánica, automatización y seguridad, y pasar de la concepción a la puesta en marcha sin pérdidas. Si el equipo interno conoce bien el proceso, las limitaciones de la planta y el historial de implantaciones similares, normalmente gana en tiempo y en calidad de las decisiones acordadas. Sin embargo, si no dispone de recursos para dirigir el proyecto, verificar las hipótesis y revisar la documentación, mantenerlo todo dentro de la empresa puede ser solo un ahorro aparente. En ese caso, el coste aparece después: en cambios tras el montaje, en disputas sobre el alcance de la responsabilidad o en una documentación que no permite demostrar por qué una determinada solución se consideró admisible.

Por eso conviene basar la decisión en un criterio práctico: dónde se encuentra dentro de la organización la capacidad para tomar y defender decisiones límite. Se trata de esos momentos en los que hay que resolver si una función debe ejecutarse por hardware o por software, si una modificación ya afecta a la seguridad, si puede aceptarse una desviación respecto a las hipótesis iniciales y también quién aprueba un cambio que influye en la explotación y el mantenimiento. Si la empresa cuenta internamente con la competencia necesaria para conducir este tipo de decisiones, la externalización de ingenieros puede limitarse a la ejecución de parte de los trabajos sin perder el control del proyecto. Si esa competencia no existe, el contratista externo debe asumir no solo el diseño, sino también el orden de toma de decisiones, y eso exige definir con claridad los puntos de aceptación, el alcance de los datos de entrada y las reglas de aprobación de cambios. Sin ello, el outsourcing no acorta el proceso, sino que crea una capa adicional de coordinaciones.

Un ejemplo típico es la modernización de una máquina en la que el cliente externaliza la mecánica y el control, dejando internamente solo el mantenimiento y la aceptación final. Al principio parece razonable, porque el contratista declara una ejecución integral. El problema empieza cuando, durante los trabajos, se pone de manifiesto que el nuevo sistema de alimentación cambia la forma de acceso a la zona peligrosa y, al mismo tiempo, el programa del controlador debe compensar las limitaciones derivadas de la implantación física. Si nadie por parte del cliente es capaz de evaluar las consecuencias de ese cambio para el conjunto de la máquina, las decisiones se tomarán de forma reactiva y bajo la presión del plazo. Como resultado, puede recibirse un equipo que funciona desde el punto de vista tecnológico, pero que exige modificaciones posteriores en resguardos, enclavamientos, lógica de control o documentación. Es precisamente en ese punto donde la cuestión del coste pasa al terreno de la evaluación práctica de si la máquina es segura y, después —si el alcance del proyecto así lo requiere—, a la preparación del material necesario para demostrar la conformidad.

Desde el punto de vista del responsable, esto significa que no solo hay que medir la eficiencia del contratista, sino también la calidad de la conducción del proyecto. Si, una vez congeladas las hipótesis, aumenta el número de cambios que afectan a la seguridad, si la aceptación de decisiones entre disciplinas se prolonga o si la documentación final no sigue el ritmo de la ejecución real, es una señal de que el modelo de realización está mal planteado. Una oficina de ingeniería propia aporta ventaja allí donde cuentan la continuidad del conocimiento sobre el producto y la rapidez de respuesta al cambio. El outsourcing tiene sentido cuando el alcance está bien definido, las interfaces están cerradas y la responsabilidad por el resultado se ha distribuido sin lagunas. Cuando en el proyecto participan además un integrador, un proveedor de software y el departamento de mantenimiento, la simple decisión de «hacerlo internamente o subcontratarlo» deja de ser suficiente; igual de importante pasa a ser ordenar la colaboración entre estas partes mediante una gestión de proyectos adecuada, porque es eso lo que en última instancia determina el tiempo de puesta en marcha, el coste de los cambios y la posibilidad de una aceptación rigurosa.

La dimensión normativa y formal no aparece al final, sino exactamente allí donde una decisión de diseño afecta a una función de seguridad, al modo de uso o al alcance de la modificación de la máquina. Esto no siempre dará lugar a la misma obligación por parte de la organización, porque importan la naturaleza del proyecto y el papel de cada entidad. Sin embargo, debe asumirse una regla simple: si no es posible reconstruir la base de las decisiones técnicas, la evaluación de riesgos y los cambios introducidos durante los trabajos, la elección entre un modelo in-house o de outsourcing deja de ser una cuestión de eficiencia y pasa a ser una cuestión de responsabilidad. En ese momento, la conversación se desplaza de forma natural hacia dos ámbitos adicionales: cómo comprobar, mediante una auditoría de seguridad de máquinas y líneas de producción, si la máquina es segura en su ejecución real, y cuándo el proyecto exige ya ordenar el camino desde el diseño hasta la demostración de conformidad y el marcado CE de máquinas.

Qué tener en cuenta durante la implantación

Durante la implantación, la diferencia entre una oficina de ingeniería propia y el outsourcing deja de ser una discusión sobre la tarifa por hora de trabajo. La rentabilidad depende de quién controla en la práctica los cambios, quién entiende las limitaciones del proceso y quién es capaz de defender las soluciones adoptadas cuando surge un problema en la puesta en marcha o en la aceptación. Lo que más cuesta no son los errores de diseño en sí, sino los errores detectados demasiado tarde: interferencias entre mecánica y control, interfaces insuficientemente definidas, falta de datos de entrada por parte del usuario final o una lógica incoherente en el reparto de responsabilidades sobre la seguridad. Si la organización opta por el outsourcing sin capacidad de supervisión técnica por su parte, normalmente no compra solo un proyecto, sino también una dependencia del contratista para cada cambio. Si, por el contrario, todo se mantiene dentro de la empresa, pero el equipo no tiene tiempo para llevar la documentación de decisiones y las revisiones entre disciplinas, el coste reaparecerá en la fase de correcciones, aceptaciones y servicio.

La trampa más habitual consiste en elegir el modelo de ejecución en función de la disponibilidad de recursos, y no del tipo de riesgo del proyecto. No se evalúa igual una máquina repetitiva, desarrollada a partir de un estándar propio, que un puesto nuevo, con una cinemática no convencional, una gran intervención en el proceso o una alta presencia de funciones de seguridad. El criterio práctico es sencillo: hay que comprobar si, por parte del cliente, existe la capacidad para aprobar los supuestos técnicos, los cambios de diseño y la arquitectura de control, y no solo para recepcionar el resultado final. Si esa capacidad no existe, la externalización de ingenieros puede parecer más barata, pero aumenta el riesgo de disputas sobre el alcance, alarga las validaciones y dificulta determinar si un retraso se debe a un error del contratista o a unos requisitos de partida incompletos. Por eso conviene medir no solo el presupuesto y el plazo, sino también el número de cambios tras congelar el concepto, el tiempo de aprobación de la documentación, el número de no conformidades abiertas después de la puesta en marcha y el tiempo necesario para cerrarlas.

En la práctica, esto se aprecia claramente en la modernización de una máquina existente o en la construcción de una línea con la participación de varias partes. Un departamento de ingeniería interno suele comprender mejor las limitaciones de la planta, el acceso para servicio, los estándares de mantenimiento y la forma real de utilización del equipo. En cambio, un contratista externo puede ser más rápido al preparar el proyecto y más eficaz en cuestiones especializadas, pero puede no tener una visión completa del entorno de trabajo. Si en la fase de implantación resulta necesario modificar el sistema de resguardos, la secuencia de trabajo o la forma de rearme tras una parada, la pregunta ya no es quién hará el plano o corregirá el programa. La pregunta es quién evaluará el impacto de ese cambio en la seguridad, la función de la máquina y la integridad de la documentación. En ese punto, la cuestión de la rentabilidad pasa de forma natural a una valoración práctica de cómo comprobar, mediante una auditoría de seguridad de máquinas y líneas de producción, si la máquina es segura en su ejecución real y no solo en los supuestos de diseño.

Solo desde esta perspectiva se entiende la dimensión formal. No todos los cambios en un proyecto darán lugar a las mismas obligaciones, pero toda intervención relevante en la función, el modo de uso o las soluciones relacionadas con la seguridad exige dejar claras las responsabilidades y la trazabilidad de las decisiones. Si no se sabe quién aprobó el cambio, sobre qué base se evaluó el riesgo y si la documentación refleja el estado real, el modelo in-house o de outsourcing deja de tener importancia económica, porque aparece un problema de responsabilidad sobre la conformidad. En ese momento, el asunto entra ya en el ámbito de la preparación de la máquina, desde el proyecto hasta la demostración de la conformidad y el marcado CE. Desde el punto de vista de la gestión del proyecto, esto significa una cosa: la implantación debe planificarse de modo que, junto con la máquina, se recepcione también el conjunto completo de decisiones técnicas, resultados de verificación y documentos necesarios para la explotación posterior, la modernización y una eventual defensa en la recepción o en caso de disputa, incluida la certificación CE de máquinas.

Oficina técnica propia frente a externalización: preguntas frecuentes

Depende principalmente de dónde deba permanecer el conocimiento crítico para el ciclo de vida de la máquina. El precio del proyecto, por sí solo, rara vez determina la rentabilidad tan claramente como la rapidez en la toma de decisiones, la capacidad de adaptación y el control sobre la conformidad.

Cuando una empresa desarrolla un proceso único, introduce cambios con frecuencia, necesita cambios de formato rápidos o crea nuevas variantes de la misma plataforma. En ese caso, la falta de competencias internas eleva el coste de cada modificación posterior.

En un proyecto con un alcance claramente definido, un número reducido de cambios repetitivos y cuando la máquina no constituye el núcleo de la ventaja competitiva de la empresa. La condición es que el cliente mantenga el control sobre los requisitos, la recepción y la documentación.

Lo más habitual es que el problema no esté en la tarifa del proyectista, sino en unos límites de la máquina poco claros, en las interfaces, en la asignación de responsabilidades y en el procedimiento de aprobación de los cambios. Esto da lugar a correcciones, retrasos, conflictos y problemas durante la recepción y la explotación.

Independientemente del modelo de ejecución, la responsabilidad, en el alcance que corresponda, sigue recayendo en el fabricante, el importador u otra entidad que comercialice la máquina o la ponga en servicio. Por ello, es necesario poder reconstruir el historial de cambios, los fundamentos de las decisiones de diseño y preparar la documentación para la evaluación de riesgos y el marcado CE, cuando sea exigible.

Compartir: LinkedIn Facebook