La aprobación depende del grupo de WeChat: ¿cómo convertir los flujos de aprobación, la documentación oficial y los permisos organizativos en un sistema?

Introducción: La aprobación de viajes de negocios se realiza mediante mensajes en grupos, y para localizar al responsable de la aprobación solo se pregunta

En una empresa manufacturera de aproximadamente 200 empleados, la primera solicitud de viaje después del Año Nuevo se gestionó así: el empleado menciona al jefe en el grupo; tras verlo, el jefe responde con un “OK”, y el empleado guarda la captura de pantalla. Al final del mes, cuando el departamento financiero prepara los informes de gastos de viaje, revisa uno por uno las capturas según el presupuesto; mientras tanto, el departamento de recursos humanos contabiliza a fin de año “los días de viaje de cada empleado”, pero descubre que algunas capturas están incompletas y que los datos entre departamentos no coinciden.

Esto no es un caso aislado. En numerosas empresas del país, el proceso de aprobación suele seguir este flujo:

• Buscar a la persona adecuada mediante preguntas: Durante la primera semana de trabajo, lo más frecuente que preguntan los nuevos empleados es: “¿A quién debo pedir permiso? ¿Quién revisará mi reembolso?”
• Los mensajes grupales sirven como comprobante: En WeChat o DingTalk, recibir un mensaje del tipo “@jefe aprobado” se toma como señal de aprobación, sin posibilidad de auditoría posterior.
• Los datos entre departamentos no concuerdan: El departamento de ventas considera que la visita al cliente ya fue aprobada, mientras que el departamento de marketing cree que aún no lo está; por su parte, el área financiera efectúa el pago basándose en la captura del departamento de ventas.
• Los permisos se otorgan verbalmente: Cuando un gerente abandona la empresa, sus permisos no son revocados, y el nuevo integrante desconoce a quién correspondían los contratos aprobados por el anterior.

El origen de estos problemas no radica en la complejidad del proceso de aprobación, sino en que el flujo de aprobación no ha sido incorporado al sistema. Los mensajes grupales, las instrucciones verbales y las capturas de pantalla son medios temporales; lo que falta es un soporte estructurado, con registro y trazabilidad. Un sistema OA (sistema de oficina automatizada) permite estructurar este proceso: consignar en un único flujo de aprobación “quién, qué asunto, cuándo, a quién se solicitó, bajo qué reglas se aprobó y cómo se registran los datos tras la aprobación”.

01 Cómo desglosar el negocio: la estructura en tres niveles del flujo de aprobación

Al dividir el proceso de aprobación, en realidad se conforma por tres niveles:

1. Nivel de asunto: Los empleados inician solicitudes específicas como “viaje de negocios, permiso, reembolso, contrato, uso de sellos, compras”, cada una con importe, número de días, archivos adjuntos y objetos relacionados (por ejemplo, la solicitud de viaje vinculada a un pedido de ventas, el reembolso asociado a una factura).
2. Nivel de proceso: Los asuntos fluyen de un nodo a otro; los responsables de cada etapa se determinan dinámicamente (según departamento, nivel, monto y categoría), sin ser fijos.
3. Nivel de datos: Tras la aprobación o el rechazo, los datos deben volverse a registrar en los sistemas operativos (RR.HH., finanzas, ventas, base de contratos), sin quedar únicamente en el flujo de aprobación.

La relación entre estos tres niveles es la siguiente: El asunto es la entrada, el proceso constituye la columna vertebral y los datos representan la salida. Si al desarrollar un sistema OA solo se implementa el proceso sin incluir la salida de datos, el flujo de aprobación se convierte en una isla; si solo se atiende el aspecto del asunto sin contemplar el proceso, el sistema termina reduciéndose a un “formulario”.

02 Cómo diseñar: el trío de elementos —nodos dinámicos, matriz de permisos y registro de actividades—

Diseño de nodos: los responsables de la aprobación no deben fijarse de manera rígida

Muchos sistemas OA establecen desde el principio los responsables de forma fija: “Solicitud de viaje → Gerente del departamento → RR.HH. → Director general”. Como resultado, cuando el gerente cambia de puesto, el departamento de RR.HH. se integra al de administración o el director general sale de viaje, todo el sistema queda desajustado.

La solución correcta: Los responsables de la aprobación se calculan dinámicamente según reglas. Estas reglas suelen basarse en cuatro dimensiones:

• Dimensión departamental: El departamento del solicitante se corresponde con el responsable actual de ese departamento (consultando en tiempo real el organigrama).
• Dimensión de nivel: Los montos, los días y los valores contractuales se asignan a distintos rangos, correspondientes a diferentes niveles de autorización.
• Dimensión de rol: Cuando el valor contractual supera los 500.000, el departamento jurídico debe intervenir; si un empleado viaja al extranjero, la seguridad y el cumplimiento normativo exigen la firma conjunta.
• Dimensión de apoderado: Cuando el responsable está de licencia o de viaje, la aprobación se transfiere automáticamente a un apoderado, designado según la estructura organizativa o por el departamento de RR.HH.

Combinando estas cuatro dimensiones en una “expresión reglamentaria”, el motor del proceso calcula en tiempo real los nodos según las reglas,sin fijar nombres de responsables de manera permanente. Así, cambios de puesto o reestructuraciones organizativas no requieren modificar la plantilla del proceso.

Diseño de permisos: tres niveles —menú, datos y campos—

Los permisos no se limitan a “si se puede entrar al sistema”, sino que se dividen en tres niveles:

• Nivel de menú: Si se puede ver este módulo (por ejemplo, los empleados comunes no ven “Administración de la estructura organizativa”).
• Nivel de datos: Si se puede consultar este dato (por ejemplo, el departamento de ventas solo ve los reembolsos de sus propios empleados, sin acceso a los de ventas de otros departamentos).
• Nivel de campo: Si se pueden ver ciertos campos de este dato (por ejemplo, los aprobadores ordinarios no ven el campo salarial del solicitante, pero el departamento de RR.HH. sí lo ve).

Una vez desglosados estos tres niveles de permisos, el sistema OA puede soportar estructuras organizativas complejas: grupo‑filial‑departamento‑equipo; los datos entre niveles se controlan simultáneamente siguiendo dos reglas: “puedo ver mi propia línea + soy responsable de esa línea”.

Diseño de registro de actividades: los siete elementos del historial de aprobación

Cada acción de aprobación debe dejar constancia de siete elementos:

1. Operador: Quién realizó la acción.
2. Hora de la acción: Con precisión hasta el segundo.
3. Acción realizada: Aprobar, rechazar, remitir, agregar firma, retirar.
4. Opinión sobre la acción: La opinión de rechazo es obligatoria; la de aprobación puede dejarse en blanco.
5. Posición del nodo: En qué punto del proceso se encuentra actualmente.
6. Instantánea de los datos relacionados: Los valores de los campos del objeto del negocio durante la aprobación (como importes o documentos adjuntos) se conservan tal cual, sin permitir modificaciones posteriores en el objeto mientras el registro de aprobación permanece inalterado.
7. Huella del dispositivo e IP: Desde qué dispositivo y qué IP se envió (para auditorías de cumplimiento).

Si falta alguno de estos siete elementos, surgen disputas durante la auditoría. Un error común es permitir que la “opinión sobre la acción” quede en blanco, lo que deja sin justificación el rechazo y provoca que el empleado vuelva a presentar la solicitud repetidamente, alargando el proceso de aprobación.

03 Cómo desarrollar: el trío de motores —motor de procesos, motor de formularios y bus de mensajes—

El núcleo del desarrollo de un sistema OA reside en tres motores, no en N páginas:

Motor de procesos

El motor de procesos no requiere escribir código; basta con configurarlo para ejecutar los flujos. Las características que debe soportar incluyen:

• Flujos secuenciales, paralelos, con firmas conjuntas o separadas: Cuatro tipos básicos de flujos; la solicitud de contratación es secuencial (RR.HH. → Jefe → CEO), mientras que las compras con firmas conjuntas se realizan en paralelo (finanzas y jefe de compras revisan simultáneamente).
• Bifurcaciones condicionales: Según el monto, la categoría y el nivel del solicitante, se dirigen a flujos simplificados para menos de 5.000 yuanes, a flujos con doble revisión de departamento y finanzas para entre 5.000 y 50.000 yuanes, y a flujos con intervención adicional del CEO para montos superiores a 50.000 yuanes.
• Reversión y rechazo: Se deben admitir tres tipos de rechazo: rechazar al solicitante, rechazar a cualquier nodo y rechazar al nodo anterior.
• Firma adicional y reenvío de firma: El responsable de la aprobación puede reenviar la tarea a un colega (reenvío de firma) o incluir a un colega para que participe en la revisión (firma adicional).
• Retiro y anulación: El solicitante puede retirar los asuntos pendientes de aprobación; el administrador puede anular los asuntos con anomalías.

Una vez desarrollado el motor de procesos,se añade una nueva categoría de aprobaciones que no requiere escribir código: basta con dibujar un diagrama y configurar un formulario para ponerlo en línea. Este es el punto clave que diferencia a la OA del “desarrollo externo de aprobaciones”.

Motor de formularios

Los formularios deben ser de “diseño sin código”: tipos de campos (texto, número, fecha, archivo adjunto, objeto de negocio relacionado), reglas de validación, campos obligatorios y opcionales, así como condiciones de visibilidad e invisibilidad, todo ello configurado de forma visual mediante arrastrar y soltar. De este modo, cuando el departamento de RR. HH. modifica los campos de los gastos de viaje o el departamento de ventas agrega nuevos campos para los contratos,no es necesario que el equipo de TI programe una intervención.

El motor de formularios debe soportar:

• Permisos a nivel de campo: En un mismo formulario, diferentes responsables de la aprobación ven distintos campos (por ejemplo, el responsable ordinario no ve el número de teléfono del solicitante).
• Vinculación de campos: Al seleccionar "Tipo de contrato = Contrato de servicios", se despliegan automáticamente los campos específicos de los contratos de servicios.
• Escritura de datos de vuelta: Tras la aprobación, se actualizan automáticamente en los sistemas empresariales (estado del contrato, asistencia de RR.HH., comprobantes financieros).

Bus de mensajes

Tanto si se aprueba como si se rechaza, el solicitante y los sistemas empresariales correspondientes (RR.HH., finanzas, ventas) reciben notificaciones de forma inmediata. El bus de mensajes envía de manera unificada:

• Notificaciones dentro del sistema: Mensajes internos junto con tareas pendientes.
• Notificaciones IM: Webhooks de WeChat Work, DingTalk y Feishu, que se envían a los grupos o a usuarios individuales correspondientes.
• Correos electrónicos y SMS: Notificaciones de respaldo en puntos clave (aprobación de contratos, viajes al extranjero).
• Mensajes de los sistemas empresariales: Tras la aprobación, se genera un mensaje en las tareas pendientes del sistema empresarial (finanzas recibe una tarea pendiente de reembolso, RR.HH. recibe una tarea pendiente de incorporación).

El bus de mensajes no es un mero "adorno", sino el "circuito cerrado" del flujo de aprobación: sin notificaciones, el solicitante desconoce a quién debe dirigirse en el siguiente paso, lo que bloquea todo el proceso.

Cierre: secuencia de implementación, riesgos e indicadores

La puesta en marcha del sistema OA se divide en tres etapas:

1. Primera fase (1 mes): Se incorporan tres procesos de alta frecuencia —licencias, viajes de trabajo y reembolsos—, abarcando a todos los empleados. Primero se traslada la aprobación desde los grupos de WeChat al sistema, incluso si solo se incluyen estos tres casos, los datos entre departamentos se alinean de inmediato.
2. Segunda fase (2-3 meses): Se añaden cuatro procesos de frecuencia moderada —contratos, sellado de documentos, compras y pagos—, conectando con el sistema financiero. En esta etapa se habilita la escritura de datos de vuelta (la aprobación del contrato se archiva automáticamente en la base de contratos).
3. Tercera fase (según necesidades): Se incorporan procesos completos de recursos humanos —desempeño, promociones, consolidación, reclutamiento y separación—. Esta fase está liderada por RR.HH. y requiere integrar los datos maestros de RR.HH.

Riesgos comunes:

• Reglas demasiado flexibles: La configuración del flujo de aprobación es demasiado libre, con lo que nadie sabe quién será el siguiente responsable. Principio: Los modelos de flujo no deben superar los 30 pasos, pues más de eso provoca pérdida de control.
• Falta de asignación de representantes: Cuando el responsable de la aprobación está de viaje y no se designa un sustituto, el proceso queda bloqueado durante tres días sin revisión. El sistema detecta automáticamente cuando un flujo permanece "colgado" por más de 24 horas y emite una alerta.
• No se escriben los datos de vuelta: Aunque la aprobación se ha otorgado, la asistencia en el sistema de RR.HH. no se actualiza y no aparece ningún comprobante en el sistema financiero. La escritura de datos de vuelta requiere una "verificación doble": tras completar el registro en el OA, se activa automáticamente la interfaz del sistema empresarial para confirmar la recepción.

Indicadores para evaluar si el proyecto funciona o no:

• Tiempo promedio de finalización de las aprobaciones: Antes de la puesta en marcha, el proceso tardaba tres días en el grupo; después, se cierra en un día dentro del sistema.
• Consistencia de los datos entre departamentos: La tasa de error en la conciliación entre los tres sistemas —RR.HH., finanzas y ventas— se reduce en más del 80%.
• Tasa de trazabilidad para auditorías: Al seleccionar aleatoriamente 20 aprobaciones históricas, la tasa de completitud de los siete elementos clave alcanza el 100%.

Trasladar las aprobaciones del grupo de WeChat al sistema no es simplemente "subir al sistema", sino convertir la tarea de "buscar a la persona" de una dependencia humana a una dependencia de reglas. Una vez que las reglas están escritas, independientemente de quién se vaya o cómo cambie la organización, las aprobaciones seguirán siendo estables.