De procesos a pantallas: cómo se modela la empresa en el sistema

Libro El ERP completo, capítulo 3 (parte I: Fundamentos). Anteriores: qué es un ERP completo y datos y única fuente de verdad. Índice en la Escuela.

Al terminar este capítulo vas a poder:

1. Descomponer cualquier proceso de tu empresa en sus cuatro ingredientes: estados, responsables, reglas y controles.
2. Diseñar la cadena de estados de un pedido, con la regla y el responsable de cada transición.
3. Distinguir una pantalla bien diseñada de un formulario, y saber qué validar en el origen.
4. Reconocer los errores de modelado más caros y decidir qué hacer con las excepciones.

El caso: Vidriería Ancona

Vidriería Ancona corta, templa y coloca vidrio para obras y comercios: 16 personas, dos mesas de corte, un horno de templado, tres camionetas. Factura unos USD 70.000 por mes. Hace dos años compró un sistema "con módulo de producción" y hoy casi nadie lo usa: tiene cuarenta campos por pantalla, la mitad vacíos; permite entregar sin que nadie haya controlado la medida; y las órdenes de producción se cargan a fin de día, de memoria, porque la pantalla "tarda más que el cuaderno".

El mes pasado se templaron 38 paños con una medida equivocada (USD 3.100 de vidrio tirado) porque el sistema aceptó una orden sin que el plano estuviera aprobado. Y un cliente comercial esperó dos semanas una vidriera porque la orden quedó "en producción" cuando en realidad estaba terminada y nadie cambió el estado: el sistema decía una cosa y la planta otra.

Ancona no tiene un problema de software ni de gente. Tiene un problema de modelado: sus procesos nunca se tradujeron bien al sistema, y un proceso mal modelado se abandona o se usa de adorno. Este capítulo muestra cómo se hace la traducción.

1. De dónde viene la idea de modelar procesos

En el libro de administración definimos un proceso como una secuencia de pasos que convierte una entrada en una salida, siempre igual, con responsable, registro y control en cada paso. La idea de mirar la empresa por sus procesos, y no por sus departamentos, tiene una historia que vale la pena conocer.

Deming y la mejora del proceso. W. Edwards Deming sostenía que la mayor parte de los problemas de calidad están en el sistema de trabajo (los métodos, los materiales, las máquinas, la información) y no en la voluntad de las personas, y que mejorar es mejorar el proceso, no exhortar a la gente (Out of the Crisis, 1986). Si el 38 paños salieron mal, la pregunta no es quién se equivocó sino qué paso del proceso permitió que una orden sin plano aprobado llegara al horno.

Hammer y la reingeniería. Michael Hammer y James Champy mostraron en los años noventa que informatizar un proceso malo lo hace malo más rápido, y que el valor aparece cuando se rediseña el flujo completo de un pedido, de punta a punta, en lugar de automatizar cada escritorio por separado (Reengineering the Corporation, 1993). Ancona informatizó sus escritorios; el pedido sigue cruzando la planta como antes, con los mismos agujeros.

El flujo de trabajo (workflow) y la máquina de estados. De la informática viene la herramienta para describir un proceso con precisión: la máquina de estados. Un objeto (un pedido, una orden, una factura) está en un estado; ciertos eventos lo hacen pasar a otro; cada transición tiene condiciones. Es un modelo viejo y simple, y es exactamente lo que un sistema de gestión hace con cada documento: el pedido está en un estado, y solo puede pasar al siguiente si se cumple la regla.

Las tres ideas juntas dan el método de este capítulo: mirar el proceso completo (Hammer), buscar los problemas en el sistema y no en la gente (Deming), y describirlo como una cadena de estados con reglas (la máquina de estados).

2. Los cuatro ingredientes

Con cuatro ingredientes se modela cualquier proceso de la empresa.

1. Estados. Un pedido no "está": está cotizado, aceptado, en producción, listo, entregado, facturado, cobrado. El estado dice en qué paso del proceso está y quién tiene la pelota. Los estados tienen que ser los que la gente distingue de verdad en la operación; ni uno más.
2. Responsables. Cada cambio de estado lo hace un rol: el vendedor acepta, producción libera, calidad aprueba, expedición entrega, administración factura. El sistema registra quién y cuándo. Rol, no persona: cuando cambia la persona, el proceso sigue.
3. Reglas. Condiciones para pasar de un estado a otro: no se produce sin pedido aceptado; no se acepta sin precio con margen mínimo; no se entrega sin control de calidad; no se factura sin remito firmado. La regla es lo que convierte la política de la empresa en algo que el sistema no deja saltear.
4. Controles y excepciones. Qué pasa cuando algo no encaja: un cliente sin crédito, un insumo sin stock, un margen por debajo del mínimo, un plano que no llega. El sistema no se traba: avisa, pide autorización a quien corresponde y deja rastro.

Modelar un proceso con estos cuatro ingredientes obliga a decidirlo. Muchas empresas descubren al implementar que nunca habían definido quién autoriza un descuento, cuándo un trabajo está "terminado" o qué pasa si el cliente cambia la medida después de cortar. Esas decisiones no las toma el sistema ni el programador: las toma el dueño con su equipo, y el sistema las hace cumplir.

3. Un proceso completo, paso a paso

Tomemos "llega un pedido" en Vidriería Ancona, modelado como corresponde.

Dos cosas que no existían en el sistema que Ancona compró: el estado plano aprobado como condición para producir (habría evitado los 38 paños) y el cambio de estado en producción → listo hecho por quien termina el trabajo, desde la planta (habría evitado las dos semanas de espera). No eran funciones que faltaban: eran decisiones que nadie había tomado.

Cada fila es un registro que queda en el momento, con fecha y responsable. Al final, el sistema sabe cuánto costó el trabajo de verdad, cuánto tardó cada etapa, si se entregó en fecha y cuántos días tardó en cobrarse. Nadie armó un reporte: es la consecuencia de haber trabajado dentro del proceso.

4. Lo que es una pantalla, y lo que no

Una pantalla no es un formulario para llenar: es un paso del proceso. Tiene los datos que hacen falta en ese paso y ninguno más, los campos obligatorios para que el registro sirva después, y las validaciones que evitan el error en el origen.

Cinco principios de diseño que separan una pantalla que se usa de una que se abandona:

1. Un paso, una pantalla. La pantalla de "terminar etapa" en Ancona pide tres cosas: horas, metros cuadrados consumidos, observación. Nada más. La de cotizar pide otras. El formulario de cuarenta campos intenta servir a todos los pasos y no sirve a ninguno.
2. Obligatorio solo lo que sirve después. Un campo es obligatorio si otro paso lo necesita (la fecha comprometida la necesita producción; el teléfono del contacto lo necesita expedición). Lo que nadie usa después, no se pide; lo que se pide y nadie carga, se saca.
3. Validar en el origen. Fecha de entrega anterior a hoy, cantidad negativa, cliente inactivo, medida fuera del rango del horno: la pantalla lo rechaza antes de guardar. Cada error frenado en el origen son diez corregidos después.
4. Proponer, no preguntar. El sistema sabe el estado y propone el siguiente paso con los datos que ya tiene: al terminar el corte, propone "pasar a templado" con las medidas de la orden. La persona confirma o corrige.
5. Usar donde pasa la cosa. Una tablet en la mesa de corte, el celular del colocador, el lector en el depósito. La pantalla que se llena en la oficina a fin de día registra recuerdos, no hechos.

La prueba final es una sola: la persona que usa la pantalla la termina en menos tiempo que el que le llevaba anotar lo mismo en papel. Si no, va a volver al papel, y con razón.

5. Reglas rígidas, reglas blandas y excepciones

Las reglas son lo que hace que el sistema sostenga la política de la empresa. Pero una regla sin excepción prevista es una invitación a trabajar afuera del sistema.

• Demasiado rígidas. Si no se puede entregar sin control de calidad firmado y el cliente está esperando en la puerta con el camión, alguien va a entregar igual y a "arreglar el sistema después". La regla no se cumplió y, peor, el registro quedó falso.
• Demasiado blandas. Si todo se puede saltear con un clic, el sistema es un cuaderno caro: las reglas existen en el manual y no en la operación.
• La excepción autorizada. El camino del medio: la regla se mantiene, pero existe una excepción explícita, con quien la autoriza (rol), con motivo obligatorio y con registro. "Entrega sin control de calidad: autoriza el jefe de planta, motivo: urgencia cliente X, queda marcado para control posterior". La regla sigue vigente, la operación no se traba, y la empresa sabe cuántas excepciones hubo y por qué.

El número de excepciones por mes es, además, un indicador precioso: si una regla se exceptúa veinte veces, la regla está mal o el proceso tiene un cuello de botella que hay que resolver.

6. La huella de auditoría

Cada cambio de estado, cada edición de un dato importante y cada autorización queda registrada con usuario, fecha y valor anterior. No es para desconfiar de la gente: es para que, cuando un trabajo salió mal, se pueda ver dónde y por qué, y para que las normas de calidad encuentren lo que piden sin armar carpetas.

En Ancona, la huella habría mostrado que la orden de los 38 paños pasó a producción a las 17:40 de un viernes, cargada por el vendedor, sin plano aprobado, y que el cliente había mandado una medida corregida por WhatsApp a las 16:10 que nadie cargó. Con esa información, la corrección no es "tener más cuidado": es la regla plano aprobado como condición, y el canal de cambios del cliente dentro del pedido, no en el teléfono del vendedor.

7. Los errores de modelado que cuestan caro

• Estados que no existen en la realidad. Si el sistema tiene siete estados y la gente distingue tres, los cuatro de más quedan desactualizados y el tablero miente. Se modelan los estados que la operación usa.
• Copiar el proceso viejo tal cual. La implementación es el momento de sacar los pasos que existían por desconfianza o por costumbre (la triple firma, la planilla de control que nadie lee). Hammer lo decía en 1993: automatizar el desorden es desorden más rápido.
• Modelar la excepción como regla. Un cliente especial no justifica un flujo entero; justifica una autorización. Si cada caso raro tiene su camino, el sistema tiene cuarenta caminos y nadie sabe cuál es el normal.
• Reglas sin dueño. "El sistema no me deja" es la frase de una regla que nadie sabe quién puso ni para qué. Cada regla tiene un motivo escrito y un rol que puede exceptuarla.
• Pantallas de oficina para trabajo de planta. Si el dato nace en la máquina y la pantalla está en el escritorio del encargado, el dato llega tarde o no llega.
• Modelar todo el primer día. Se modelan primero los procesos donde más plata se pierde (en Ancona, de plano a producción), se ponen en marcha, se corrigen, y recién después los demás.

Ejemplo resuelto: remodelar el pedido en Vidriería Ancona

Diagnóstico con los cuatro ingredientes. Estados: el sistema tenía nueve, la planta usaba tres (pendiente, en producción, entregado); faltaba plano aprobado y listo. Responsables: cualquier usuario podía cambiar cualquier estado. Reglas: ninguna; todo se podía saltear. Excepciones: inexistentes, porque no había reglas que exceptuar. Pantallas: un formulario de cuarenta campos para todo.

Rediseño. Seis estados (cotizado, aceptado, plano aprobado, en producción, listo, entregado) más facturado y cobrado del lado administrativo. Roles: vendedor, técnico, producción, calidad, expedición, administración. Reglas en las transiciones de la Figura 2, con dos excepciones autorizadas: entregar sin control (autoriza el jefe de planta, con motivo) y producir con plano "aprobado por teléfono" (autoriza el técnico, exige la firma en 48 horas). Pantallas: cinco, una por paso de planta, en dos tablets en las mesas de corte y en el celular de los colocadores.

Lo que costaba el modelado anterior, por mes. Vidrio tirado por órdenes sin plano aprobado: USD 3.100 el mes del caso; promedio de los últimos seis meses, USD 1.400. Esperas por estados desactualizados: dos entregas por mes demoradas una semana, con un descuento promedio de USD 250 y una cancelación cada dos meses (margen USD 600): USD 800. Retipeo del formulario de cuarenta campos cargado a fin de día: 25 órdenes por semana × 12 minutos × 4,3 semanas = 21,5 horas a USD 9: USD 194, más la baja calidad del dato, que ya está contada arriba. Total: unos USD 2.400 por mes.

Lo que costó remodelar. Tres reuniones de dos horas con la dueña, el técnico, el encargado de planta y el administrativo para definir estados, reglas y excepciones (24 horas de personas: USD 250), la configuración del sistema (una semana de trabajo de implementación, dentro del contrato) y dos tablets (USD 500). Y una decisión que ningún software toma: que el plano aprobado es condición para producir, aunque el vendedor proteste por la demora.

Resultado a tres meses. Paños templados con medida equivocada: cero. Órdenes en estado falso: cero (el estado lo cambia quien termina, en la mesa). Excepciones autorizadas: cuatro por mes, todas con motivo, dos de ellas del mismo cliente, lo que abrió una conversación comercial con ese cliente. Tiempo de carga por orden: 90 segundos en la tablet contra 12 minutos en la oficina.

Ejercicios

Ejercicio 1 · Diseño: la máquina de estados de un reclamo en Distribuidora Lamas

Distribuidora Lamas recibe reclamos de clientes (producto equivocado, faltante, dañado). Hoy llegan por WhatsApp al vendedor y "se resuelven". Diseñá el proceso de reclamo con los cuatro ingredientes: estados, responsable de cada transición, regla para avanzar y al menos una excepción autorizada.

Solución

Reglas: un reclamo no se puede resolver sin verificar; una nota de crédito por encima de USD 200 la autoriza el responsable comercial; ningún reclamo queda abierto más de 72 horas sin que el sistema avise. Excepción autorizada: reponer antes de verificar para un cliente del segmento mayorista (autoriza el responsable comercial, con motivo). Lo que gana Lamas: el reclamo deja de vivir en el teléfono del vendedor, cada uno tiene causa raíz registrada, y la cuenta de "cuántos reclamos por error propio" aparece sola.

Ejercicio 2 · Diagnóstico: cuatro reglas de Taller Ferreyra

Taller Ferreyra implementó estas reglas en su sistema. Para cada una, decí si es demasiado rígida, demasiado blanda o correcta, y cómo la ajustarías.

1. "No se puede entregar un vehículo sin que la factura esté pagada." Sin excepción.
2. "Cualquier usuario puede modificar el precio de una orden en cualquier estado."
3. "No se puede cerrar una orden sin cargar horas y repuestos."
4. "El diagnóstico puede saltearse si el cliente tiene apuro."

Solución

1. Demasiado rígida. Los clientes de flota pagan a 30 días por contrato; la regla obliga a trabajar fuera del sistema. Ajuste: "sin pagar, salvo clientes con condición de pago a plazo y crédito disponible; excepción autorizada por Marta con motivo".
2. Demasiado blanda. El precio se decide al cotizar; modificarlo después sin control destruye el margen y la auditoría. Ajuste: solo el vendedor hasta el estado aceptado; después, solo con autorización del responsable y motivo.
3. Correcta. Es la regla que sostiene el costo real por orden. Lo único que hay que cuidar es que la pantalla de carga sea de 60 segundos en el celular del técnico.
4. Demasiado blanda, y peligrosa. Sin diagnóstico no hay repuestos correctos ni presupuesto. Ajuste: el diagnóstico es obligatorio; el "apuro" se modela como prioridad (el sistema lo pone primero en la cola), no como salto de paso.

Ejercicio 3 · Diseño: la pantalla de "terminar etapa" en Plásticos Carranza

Plásticos Carranza quiere que cada operario registre, al terminar una etapa de inyección, lo que hizo. Diseñá la pantalla con los cinco principios de la sección 4: qué campos tiene, cuáles son obligatorios, qué valida, qué propone y dónde se usa. Después decí qué reporte sale solo de esos datos.

Solución

Campos: orden de trabajo (preseleccionada: el sistema sabe qué orden está en esa máquina), etapa (propuesta: la siguiente a la última terminada), piezas buenas (obligatorio), piezas rechazadas con motivo (obligatorio si hay), kilos de resina consumidos (propuestos por la fórmula de la pieza; el operario corrige si difiere), horas (calculadas entre inicio y fin; editables con motivo), observación (opcional).

Validaciones: piezas buenas más rechazadas no mayores que la cantidad de la orden más un 5 %; resina consumida no menor que el 90 % de la teórica sin motivo; no se puede terminar una etapa que no empezó.

Propone: la etapa siguiente, el consumo teórico, el estado listo si era la última etapa.

Dónde: una tablet en cada máquina, con el operario identificado por su credencial.

Reporte que sale solo: consumo real contra teórico por orden y por máquina (el desperdicio de resina), productividad por operario y por máquina, y el costo real de cada orden, que es lo que Carranza nunca pudo calcular.

Ejercicio 4 · Para tu empresa

Tomá el proceso donde más plata se pierde en tu empresa (si no sabés cuál, el del pedido). Escribí sus estados reales, los que la gente distingue hoy; para cada transición, el rol que la hace y la regla que debería cumplirse; y dos excepciones que hoy ocurren "por fuera" y cómo las autorizarías con registro. Después, para el paso que hoy se carga más tarde, diseñá la pantalla con los cinco principios. Esa hoja es la especificación de tu sistema para ese proceso, y vale lo mismo si lo construís a medida o lo configurás en uno genérico.

Errores comunes

• Pedirle al programador que "haga el proceso". El programador modela lo que la empresa decide; si la empresa no decidió, el sistema tendrá los procesos del programador.
• Confundir muchos estados con mucho control. El control viene de reglas en pocas transiciones, no de estados que nadie actualiza.
• Dejar las excepciones para después. Aparecen la primera semana y, sin camino previsto, destruyen el registro.
• Medir el éxito por campos cargados. Se mide por decisiones que antes no se podían tomar: el margen por orden, el estado real, el desperdicio por máquina.
• Implementar todos los procesos a la vez. El de más pérdida primero, en marcha en semanas; el resto, después.

Cómo se conecta con el resto del libro

Los estados y las reglas de este capítulo son el esqueleto de cada módulo: el CRM es la máquina de estados de una oportunidad; el cotizador, la de un presupuesto; pedidos, la de una orden de venta; producción, la de una orden de trabajo; expedición, la de un remito; cuentas corrientes, la de una factura. El capítulo 4 abre la caja para ver dónde viven esos estados (la base de datos), quién puede cambiarlos (usuarios, roles y permisos) y cómo queda la huella (auditoría). Y en el libro de administración (capítulo 21) está el mismo proceso visto desde el lado del dueño: una hoja con pasos, responsable, registro, control y excepciones, que es exactamente lo que el sistema necesita para ser construido.

Resumen en cinco líneas

1. Un sistema de gestión es los procesos de la empresa escritos en software: cada paso una pantalla, cada registro queda solo, cada control es una regla.
2. Todo proceso se modela con cuatro ingredientes: estados, responsables (roles), reglas de transición y controles con excepciones autorizadas; modelarlo obliga a decidirlo.
3. Una pantalla es un paso del proceso, no un formulario: pide lo que hace falta, valida en el origen, propone el siguiente paso y se usa donde pasa la cosa.
4. Las reglas demasiado rígidas se saltean por fuera; las demasiado blandas no existen; la excepción autorizada con motivo y registro es el camino del medio, y su cantidad es un indicador.
5. La huella de auditoría convierte cada error en una corrección del proceso, no en una búsqueda de culpables (Deming), y es lo que las normas piden.

Preguntas de repaso

1. ¿Por qué Hammer diría que Ancona "informatizó sus escritorios" y no su proceso? Porque cada área cargaba su parte en el sistema sin que el flujo del pedido, de la cotización a la entrega, estuviera modelado de punta a punta con reglas entre los pasos; el sistema reproducía el desorden anterior, más rápido.

2. ¿Qué diferencia hay entre un estado y un campo? Un campo es un dato (la fecha, la cantidad); un estado es la posición del documento en el proceso, que determina quién tiene la pelota y qué se puede hacer a continuación. Un sistema sin estados es una base de datos de formularios.

3. Una regla se exceptúa veinte veces por mes. ¿Qué dice eso? Que la regla está mal definida o que el proceso tiene un cuello de botella (por ejemplo, el control de calidad no da abasto). El indicador de excepciones sirve para corregir el proceso, no para castigar a quien autorizó.

4. ¿Por qué la pantalla de "terminar etapa" tiene que estar en la máquina y no en la oficina? Porque el dato (horas, consumo, piezas) nace en la máquina; cargado en la oficina a fin de día es un recuerdo, y el costo real por orden que depende de él es una estimación.

5. ¿Qué habría cambiado en Ancona con la huella de auditoría? Habría mostrado cuándo y por quién pasó a producción la orden sin plano aprobado, y que la corrección del cliente llegó por un canal fuera del sistema; la corrección sería una regla (plano aprobado) y un canal (cambios dentro del pedido), no un reto al vendedor.

Conceptos clave

• Proceso: secuencia de pasos que convierte una entrada en una salida, siempre igual, con responsable, registro y control.
• Máquina de estados: modelo en el que un documento está en un estado y pasa a otro solo cuando se cumple una condición; base de todo sistema de gestión.
• Estado: posición de un documento (pedido, orden, factura) en su proceso; dice quién tiene la pelota y qué sigue.
• Transición y regla: el paso de un estado a otro y la condición que debe cumplirse para hacerlo.
• Rol: conjunto de responsabilidades dentro del proceso, independiente de la persona que lo ocupa.
• Excepción autorizada: salida prevista de una regla, con rol que autoriza, motivo obligatorio y registro.
• Validación en el origen: rechazar el dato inválido antes de guardarlo, en la pantalla donde nace.
• Huella de auditoría: registro de quién cambió qué, cuándo y desde qué valor.
• Reingeniería: rediseñar el flujo completo de un proceso antes de informatizarlo (Hammer y Champy).

Referencias

• Deming, W. Edwards. Out of the Crisis. MIT Press, 1986.
• Hammer, Michael y Champy, James. Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness, 1993.
• ISO 9001:2015. Sistemas de gestión de la calidad. Requisitos. Organización Internacional de Normalización.

Lo que sigue

El capítulo 4 abre la caja: módulos, base de datos, usuarios y permisos; qué hay adentro de un sistema, explicado sin código, para que sepas qué estás comprando o construyendo. Si querés modelar con alguien el proceso donde más plata perdés, Alex lo hace con vos en una conversación.