Mantenimiento
Nico · Especialista de producto · 35 s
Ejemplo práctico interactivo · simulación
Un aviso. Una historia completa.
Un aviso de mantenimiento se vincula a la instalación, la acción y el historial. Está explorando cómo funciona; no se procesan datos reales ni se ejecutan acciones.
01Aviso
El problema está asociado a una instalación.
Un aviso sobre una bomba de calor se vincula a la instalación correcta. El espacio y los datos de mantenimiento anteriores forman parte del mismo contexto.
Ejemplo ficticio · Bomba de calor WP-03.
02Contexto
Encuentre lo que necesita antes de la intervención.
La persona responsable consulta el manual correspondiente, las notas anteriores y la ubicación de la instalación.
Sin buscar en correos sueltos ni en un segundo expediente.
03Orden de trabajo
Deje claro el siguiente paso.
Una orden de trabajo reúne el problema, la ubicación y el proveedor correspondiente. En este ejemplo solo revisamos el seguimiento previsto.
No se contacta con ningún proveedor ni se envía ninguna orden.
04Pruebas y costes
El resultado queda registrado en su contexto.
Un informe de intervención y los costes correspondientes se vinculan al expediente existente.
Información de ejemplo, no una factura real ni una intervención realizada.
05Pasaporte del edificio
La siguiente persona responsable puede volver a encontrarlo.
El historial de mantenimiento permanece vinculado a la misma instalación y al mismo pasaporte del edificio.
Un edificio. La misma información, en el espacio de trabajo adecuado.
El mismo inmueble, otra perspectiva.
Estos ejemplos muestran la integración prevista. No demuestran que la funcionalidad esté disponible en producción.
Conoce a Nico
Mantenimiento
De una incidencia a su seguimiento, partiendo del edificio.
Ver un ejemplo práctico
Nico
Mantenimiento
Especialista de producto
Las llamadas y el chat en directo aún no están disponibles. Contacta con nosotros para más información.
ContactarMira el ejemplo práctico
Orientación del piloto: empieza con un workspace y amplía después.
ObraPad está diseñado para mantener Obra Core como base compartida mientras añades funcionalidades con el tiempo.
La activación por edificio y el acceso limitado de instaladores se están preparando para el piloto y verificando de extremo a extremo. Pregunta qué ámbitos se pueden probar actualmente.
Punto de partida previsto
La orientación del piloto es empezar con un workspace y añadir otros más adelante.
Ampliación planificada por edificio
El flujo previsto activa Construcción solo para el edificio que se reforma; los demás permanecen sin cambios.
Modelo de acceso planificado
El modelo de acceso se está desarrollando para que un instalador o colaborador use solo el edificio, la instalación o la tarea seleccionados.
Ejemplo previsto: mantenimiento de una bomba de calor
En el escenario previsto, el instalador accede únicamente a la bomba de calor, sus documentos y las tareas de mantenimiento asignadas en un edificio. Los demás edificios, los datos financieros y los documentos privados quedan fuera del ámbito. Los permisos de consulta, modificación, duración y revocación deben demostrarse en el servidor antes de estar disponibles.
El diseño mantiene un workspace adicional y el acceso de un colaborador como decisiones separadas, con el pasaporte del edificio como base común.
