Kanboard 1.2 en talleres: tareas, subtareas y cierre
Caso de taller y repuestos con Kanboard: columnas, responsables, subtareas, permisos, backup y prueba de cierre de orden.
La orden de mantenimiento falla cuando el repuesto queda en una columna, el mecanico responde en otra y el cierre llega sin fecha. En talleres chicos, una tarea puede cruzar compras, deposito, servicio y administración antes de facturarse. Kanboard 1.2 ordena columnas, responsables, subtareas y adjuntos. Este caso muestra qué se carga primero, quién puede mover una tarjeta y cómo se comprueba el cierre.
Dónde se pierde una orden de taller
La cifra que corrige la libreta viene del release: Kanboard 1.2.52 fue publicado el 5 de abril de 2026. En un sistema de tareas, una versión reciente importa cuando corrige acceso publico, tokens, comentarios o permisos. La tarea de taller parece simple hasta que un repuesto queda pedido, usado y facturado con tres fechas distintas. Tres fechas para una misma orden bastan para discutir el cierre. La escala global da contexto a una rutina local. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una concesionaria sobre Ruta 40 en Tunuyan tiene menos software, pero la misma necesidad: cada cambio debe tener autor, hora y salida.
El cuaderno que nadie firma completo
El antagonista es el cuaderno de taller dónde una orden abierta queda con letra distinta, repuesto pendiente y firma incompleta. El jefe de compras puede tener un mostrador con cajas de filtros, remitos doblados y una impresora termica que corta etiquetas torcidas. El sistema debe decir si falta pieza, aprobación, mano de obra o factura. La página del proyecto Kanboard lo presenta como software de gestión visual de tareas. La guía de instalación explica que el directorio data guarda base SQLite, logs, archivos y miniaturas, y que también puede usarse base remota como PostgreSQL. Para una pyme con varios puestos, esa eleccion evita que una maquina local sea el unico punto de memoria.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, recepción crea una tarea con vehiculo, cliente, falla, fecha y prioridad. Segundo, compras agrega subtareas para repuesto, proveedor, precio y entrega. Tercero, taller mueve la tarjeta por columnas: recibido, diagnóstico, esperando repuesto, en trabajo, control y cerrado. Cuarto, Kanboard recibe cambios, comentarios, adjuntos y responsables; entrega tablero, historial y notificaciones. Quinto, PostgreSQL guarda tareas, usuarios, estados y auditoría. Sexto, los permisos definen quien crea, mueve, comenta, cierra o administra proyectos. Septimo, el backup copia base, adjuntos y configuración, y se prueba restaurando una orden con foto y comentario. Kanboard toma tareas y entrega vista por columna, responsable y vencimiento. La documentación de usuarios y grupos muestra como asignar personas y permisos. La página de subtareas permite dividir una tarjeta en acciones concretas. PostgreSQL recibe registros estructurados y entrega consultas para cierre, demora y responsable. Si falla la base, se pierde el historial. Si fallan adjuntos, desaparecen fotos de repuesto o remitos. Los roles se escriben con la rutina real. Recepción crea ordenes. Compras edita repuestos. Taller comenta avance. Administración cierra factura. Gerencia lee demoras y costos. Borrar proyecto queda fuera de los usuarios diarios.
Qué se instala o configura primero
La pila inicial usa Kanboard 1.2.52, PHP, PostgreSQL, HTTPS, correo saliente, almacenamiento de adjuntos, roles, backup diario y tablero por taller. La guía de PostgreSQL cubre la conexión de base para instalaciones que superan el piloto local. El piloto cuesta entre USD 900 y USD 2.600, entre ARS 1,27 y 3,68 millones al dólar vendedor oficial de $1.414 informado por Bluelytics. El plazo va de dos a cuatro semanas. UMSA suele pedir un entregable verificable: un proyecto, seis columnas, cuatro roles, quince ordenes reales, cinco adjuntos, reporte de vencidas y restauración en otro host. El costo incluye configuración, permisos, carga inicial y capacitacion corta. Quedan afuera la limpieza historica del cuaderno y la integración con ERP. La primera prueba conviene hacerla con una orden activa. Se crea tarea, se pide repuesto, se adjunta remito, se mueve a trabajo, se cierra con comentario y se exporta el reporte semanal. El reporte debe mostrar abiertas por columna, cerradas por responsable y vencidas por área. Ese control se repite cada viernes con diez ordenes tomadas al azar. Si una persona mueve la tarjeta sin permiso, el sistema debe rechazar el cambio.
Dónde se rompe y cómo probarlo Primer riesgo: columnas con nombres vagos.
La señal aparece cuando "en proceso" contiene ordenes esperando repuesto, aprobación y factura. La prueba abre diez tareas y exige que cada una tenga proximo responsable. Segundo riesgo: subtareas sin vencimiento. La señal es un repuesto pedido que nadie reclama. La prueba crea vencimientos y revisa alertas. Tercer riesgo: adjuntos fuera del respaldo. La señal aparece cuando la orden cerrada abre sin foto o remito. La prueba restaura una tarjeta con archivo. Cuarto riesgo: cierre sin responsable. La prueba intenta cerrar con usuario de taller y luego con administración. Una orden de taller termina cuando el sistema muestra fecha, pieza, responsable y salida.