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 administracion antes de facturarse. Kanboard 1.2 ordena columnas, responsables, subtareas y adjuntos. Este caso muestra que se carga primero, quien puede mover una tarjeta y como se comprueba el cierre.
Donde 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 version 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 mas 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 donde 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, aprobacion, mano de obra o factura.
La pagina del proyecto Kanboard lo presenta como software de gestion visual de tareas. La guia de instalacion explica que el directorio data guarda base SQLite, logs, archivos y miniaturas, y que tambien 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.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, recepcion 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, diagnostico, 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 auditoria. Sexto, los permisos definen quien crea, mueve, comenta, cierra o administra proyectos. Septimo, el backup copia base, adjuntos y configuracion, y se prueba restaurando una orden con foto y comentario.
Kanboard toma tareas y entrega vista por columna, responsable y vencimiento. La documentacion de usuarios y grupos muestra como asignar personas y permisos. La pagina 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. Recepcion crea ordenes. Compras edita repuestos. Taller comenta avance. Administracion cierra factura. Gerencia lee demoras y costos. Borrar proyecto queda fuera de los usuarios diarios.
Que 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 guia de PostgreSQL cubre la conexion 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 dolar 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 restauracion en otro host. El costo incluye configuracion, permisos, carga inicial y capacitacion corta. Quedan afuera la limpieza historica del cuaderno y la integracion 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 area. 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.
Donde se rompe y como probarlo
Primer riesgo: columnas con nombres vagos. La senal aparece cuando "en proceso" contiene ordenes esperando repuesto, aprobacion y factura. La prueba abre diez tareas y exige que cada una tenga proximo responsable. Segundo riesgo: subtareas sin vencimiento. La senal es un repuesto pedido que nadie reclama. La prueba crea vencimientos y revisa alertas.
Tercer riesgo: adjuntos fuera del respaldo. La senal 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 administracion. Una orden de taller termina cuando el sistema muestra fecha, pieza, responsable y salida.