- Detalles
-
By Elisabet Martí
Por qué es importante una buena URS
Tras casi 50 años fabricando posicionadores de botellas, hemos revisado cientos de Especificaciones de Requisitos de Usuario (URS) de empresas de todo el mundo.
Todas las URS se han redactado con el mismo objetivo: reducir el riesgo del proyecto y garantizar que el proveedor comprenda claramente las expectativas del cliente.
Sin embargo, a veces ocurre justo lo contrario.
En lugar de simplificar el proyecto, la URS llega a ser tan detallada que tanto el cliente como el OEM dedican semanas a revisar comentarios, discutir excepciones y evaluar cambios de ingeniería.
Nadie se beneficia de ello.
El cliente dedica más horas de ingeniería a revisar los comentarios del proveedor. El OEM dedica más tiempo a evaluar desviaciones respecto a su diseño estándar.
El proyecto resulta más caro, los plazos de entrega se alargan y, en muchos casos, la máquina final no es significativamente mejor.
Una buena URS no debería describir cómo construir una máquina.
Debería describir qué se considera un resultado satisfactorio.
El cliente y el OEM tienen conocimientos diferentes
Una de las lecciones que he aprendido a lo largo de los años es que los mejores proyectos se desarrollan cuando cada parte se centra en aquello que conoce mejor.
El cliente es el experto en sus productos, su proceso de fabricación y sus requisitos operativos.
El OEM es el experto en diseñar maquinaria de packaging fiable.
Una URS debería permitir que ambas partes aporten sus conocimientos.
En lugar de prescribir soluciones de ingeniería, debería definir claramente los objetivos de producción, las expectativas de calidad, los requisitos normativos y cualquier condicionante específico del proyecto.
A partir de ahí, el OEM puede proponer la solución técnica más adecuada utilizando tecnología probada y su experiencia previa.
Por qué especificar en exceso una URS encarece el proyecto
Las URS extensas no son un problema únicamente por su longitud. El problema es la cantidad de trabajo de ingeniería que generan para todas las partes implicadas.
Cada requisito no estándar debe revisarse, comentarse y, en muchos casos, presupuestarse por separado.
El equipo de ingeniería del cliente revisa después esos comentarios, analiza alternativas y decide si cada desviación está justificada.
Al mismo tiempo, los requisitos no estándar suelen generar ingeniería a medida, programación adicional, componentes especiales, nueva documentación y actividades de validación más largas.
El resultado suele ser más trabajo para todos, mayores costes de proyecto y plazos de entrega más largos.
Defina prioridades, no soluciones de ingeniería
En lugar de...
Especificar una marca de servomotor.
Mejor...
Definir la precisión de posicionamiento requerida y la disponibilidad global de repuestos.
En lugar de...
Especificar el modelo de PLC.
Mejor...
Definir el protocolo de comunicación requerido o la marca con la que estén familiarizados sus ingenieros de software.
En lugar de...
Copiar decenas de páginas de normativa de seguridad.
Mejor...
Exigir el cumplimiento de las Directivas de Máquinas y Seguridad aplicables más recientes.
Este enfoque proporciona al OEM suficiente flexibilidad para utilizar soluciones estándar probadas sin dejar de cumplir los objetivos del cliente.
Compruebe la máquina, no la describa
Uno de los cambios positivos de los últimos años es lo fácil que resulta compartir información de forma remota y en directo.
En lugar de intercambiar decenas de correos electrónicos para debatir diseños teóricos de máquinas, compradores y OEM pueden organizar una breve reunión online frente a una máquina similar que ya esté funcionando en las instalaciones del fabricante.
En tan solo 30 minutos, a menudo es posible revisar la accesibilidad, el mantenimiento, los cambios de formato, la ergonomía y la filosofía de funcionamiento, permitiendo al cliente decidir rápidamente qué características estándar ya cumplen sus expectativas y cuáles requieren realmente una adaptación.
Según mi experiencia, esos 30 minutos frente a una máquina real suelen aclarar más que veinte páginas de especificaciones escritas.
Incluya la información que solo conoce el cliente
Hay información que únicamente puede proporcionar el cliente y que resulta esencial para el éxito del proyecto.
Esto incluye:
- Planos de las botellas y especificaciones del producto.
- Producciones requeridas y necesidades futuras de capacidad.
- Planos de planta y espacio disponible para la instalación, así como accesos para la entrada de los equipos.
- Nivel de conocimientos técnicos de los operarios.
- Conexiones de suministros y restricciones de acceso.
- Expectativas relativas al FAT, la puesta en marcha y el SAT.
Para los equipos de manipulación de botellas, disponer de planos precisos de las botellas es especialmente importante. Pequeñas diferencias en su geometría pueden influir significativamente en el rendimiento de la máquina.
Separe los aspectos técnicos de los comerciales
Los requisitos técnicos y las condiciones comerciales no deberían mezclarse en un mismo documento.
Las condiciones de pago, garantías bancarias, requisitos de seguros y penalizaciones contractuales son importantes, pero deben tratarse dentro de la negociación comercial y no en una especificación técnica.
Mantener ambas conversaciones separadas permite que los equipos de ingeniería se concentren en diseñar la solución adecuada, mientras que los equipos comerciales gestionan de forma independiente los aspectos contractuales.
Reutilice lo que ya funciona
Uno de los enfoques más eficaces consiste en crear una URS estándar que pueda reutilizarse en distintos proyectos.
Un bloque común puede incluir estándares corporativos, requisitos de validación, normas de documentación y protocolos de comunicación preferidos.
Una segunda sección debería contener únicamente la información específica de cada proyecto: especificaciones de las botellas, producciones requeridas, planos de implantación, plazos y criterios de aceptación.
Esto ahorra tiempo tanto al cliente como al OEM y permite incorporar las mejoras de proyectos anteriores en lugar de empezar desde cero cada vez.
Conclusión
Después de revisar cientos de URS a lo largo de mi carrera, he llegado a una conclusión sencilla.
Los mejores proyectos rara vez empiezan con las especificaciones más largas.
Empiezan con las más claras. Y aquello que no esté claro debería discutirse, si es posible, conversando frente a la propia maquinaria.
Nota de transparencia: Artículo elaborado internamente por el equipo de Posimat. Las imágenes y la revisión lingüística del contenido han sido optimizadas con el apoyo de herramientas de inteligencia artificial.