Kanboard 1.2 en talleres: tareas, roles y cierre
Mini-caso para talleres y concesionarias: Kanboard ordena órdenes internas, responsables, permisos y cierres con una prueba de restauración simple.
Antes, el taller marcaba pedidos con fibrón sobre una hoja plastificada; después, cada tarea tuvo columna, responsable y cierre. En una concesionaria sobre la Ruta 40 en Tunuyán, el jefe de compras mira un rótulo de cartón atado a una caja de filtros y descubre que la orden figura terminada aunque el repuesto nunca llegó. Kanboard 1.2 sirve para ordenar esa rutina si el equipo define permisos, estados y prueba de respaldo desde el primer día. ## Dónde se pierde la orden antes del cierre Kanboard publica versiones 1.2.x de manera regular; su página de releases lista la 1.2.52 del 4 de abril de 2026. La documentación describe proyectos de equipo, roles por proyecto, roles personalizados, restricciones por columna y acciones automáticas. Esa combinación alcanza para un taller chico que necesita saber qué está pedido, qué llegó, qué se instaló y quién cerró la tarea. La escala global viene de GitHub Octoverse 2024: la plataforma registró más de 5.200 millones de contribuciones sobre más de 518 millones de proyectos. El número parece lejano a un galpón de Cuyo, pero explica por qué una herramienta mantenida en abierto puede resolver trabajo cotidiano si la organización la baja a una regla concreta. Una orden cerrada sin repuesto deja de ser avance y pasa a ser deuda operativa. El antagonista es el tablero blanco con imanes vencidos. Nadie lo odia; simplemente deja estados pegados aunque el trabajo cambie. En el taller, una caja con una etiqueta doblada pesa menos que la duda que genera: alguien movió la orden, nadie dejó motivo y el cliente llama antes de que compras pueda responder.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, recepción crea una tarea con cliente, vehículo, repuesto, prioridad y fecha prometida. Segundo, compras agrega proveedor, pedido y comprobante. Tercero, taller mueve la tarea entre columnas: pendiente, pedido, recibido, instalado y cerrado. Cuarto, Kanboard guarda usuario, comentario, cambio de columna y adjuntos en su base. Quinto, los permisos limitan quién puede crear, mover, cerrar o borrar. La documentación permite roles de proyecto y roles personalizados; un ayudante puede mover tareas entre columnas definidas, mientras un encargado conserva el cierre. Sexto, una acción automática avisa cuando una tarea cambia de columna o supera una fecha. La API JSON-RPC permite consultar tareas desde una pantalla de mostrador o exportar cierres a una planilla contable. Kanboard recibe tareas, comentarios, archivos y cambios de estado. Entrega un tablero por columnas, historial de actividad, filtros y datos para API. PostgreSQL puede guardar la base si el equipo prefiere una base externa; SQLite alcanza para pruebas chicas. El administrador del sistema controla usuarios, actualizaciones, plugins y respaldo. Si falla, el taller pierde visibilidad de pendientes, por eso el backup debe restaurar base, archivos y configuración.
Qué se instala o configura primero
La primera entrega verificable es un proyecto con cinco columnas, tres roles y diez tareas reales. El taller prueba una orden de service, una garantía y una compra de repuesto. Cada tarea debe mostrar responsable, fecha prometida, proveedor, archivo y motivo de cierre. El tablero público queda desactivado por defecto; gerencia ve reportes y taller ve tareas asignadas. La implementación puede tomar 3 a 8 días hábiles si el proceso ya está escrito. El costo inicial va de USD 900 a USD 2.800, unos ARS 1,4 a 4,2 millones con dólar a $ 1.510. La operación mensual puede quedar por debajo de USD 80 en servidor propio o VPS, más horas de mantenimiento. El gasto cambia si se agregan LDAP, correo saliente, proxy, capacitación y migración de históricos. UMSA suele arrancar estos casos con una regla incómoda: ninguna columna se crea si nadie puede decir qué acción habilita. Pedido significa compra emitida. Recibido significa repuesto físicamente revisado. Instalado significa trabajo firmado. Cerrado significa factura o garantía asociada. Esa definición corta discusiones y deja al software haciendo lo que mejor hace: registrar movimientos.
Dónde se rompe y cómo probarlo Primer riesgo: copiar el pizarrón sin corregir estados.
La señal aparece cuando una tarea puede pasar de pendiente a cerrado sin revisión. La prueba usa roles personalizados y bloquea movimientos directos entre columnas que saltean compras o taller. Segundo riesgo: usar comentarios como base de datos. La señal aparece cuando el proveedor, la fecha o el número de pedido quedan escritos en texto libre. La prueba agrega campos obligatorios o una plantilla de tarea y rechaza cierres incompletos. Tercer riesgo: instalar plugins sin control. Kanboard tiene un núcleo en mantenimiento y acepta contribuciones; el ChangeLog muestra arreglos y cambios de seguridad durante 2026. La prueba lista plugins, versión, responsable y plan de actualización antes de usarlos. Cuarto riesgo: olvidar la salida. La prueba exporta tareas cerradas, restaura la base en otro servidor y abre un tablero con diez órdenes. Si la concesionaria no puede reconstruir esa muestra, todavía depende del pizarrón aunque lo mire en el navegador. El taller mejora cuando una orden cerrada puede explicar quién la movió y con qué comprobante.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.