Cómo crear un organigrama desde un CSV
Cómo convertir una exportación CSV de RR. HH. en un diagrama de la línea jerárquica: resuelve employee_id y manager_id a números de fila, invierte el sentido al que apunta la columna de responsable, y trata huérfanos y ciclos.
Una exportación de RR. HH. guarda la jerarquía como un puntero (cada fila nombra a su responsable y ninguna nombra a sus reportes), así que convertirla en un diagrama es una búsqueda de identificadores a números de fila más una inversión de sentido.
En resumen
- employee_id y manager_id son identificadores; Línea a toma números de fila en base 1. Convertir es una búsqueda.
- manager_id apunta hacia arriba en el árbol y Línea a hacia abajo en el flujo: inviértelo o todas las flechas irán al revés.
- Un manager_id sin ningún employee_id que le corresponda significa que la exportación estaba filtrada, no que esa persona no tenga jefe.
- Dos filas que se nombran entre sí son un ciclo: la subida no termina nunca. Encuéntralo en el archivo, no en el lienzo.
- La profundidad en la línea jerárquica se corresponde con la columna Carril horizontal, así que cada nivel de autoridad tiene su carril.
Qué te da en realidad una columna manager_id
Una exportación de RR. HH. es un archivo de texto plano con una fila por persona: employee_id, manager_id, un nombre, un puesto, un centro de coste y normalmente una columna o dos que describen qué puede aprobar esa persona. La jerarquía está ahí dentro, pero guardada como un puntero. Cada fila nombra a su responsable y ninguna fila nombra a sus reportes, que es la manera correcta de guardar un árbol en una tabla y el motivo por el que el archivo no se convierte en un diagrama solo con pegarlo.
Hay dos diagramas distintos a los que la gente llama «organigrama desde CSV». Uno es el árbol: una caja por persona, los responsables encima de sus reportes, que se lee para contestar quién depende de quién. QueryChart tiene un editor de organigramas dedicado a esa forma y es la mejor herramienta para ella. El otro es la línea jerárquica como recorrido (el camino que hace una solicitud mientras sube desde quien la abrió hasta quien puede firmarla) y eso es un diagrama de flujo, que es de lo que va esta página.
Convertir son dos operaciones sobre la exportación. La primera es una búsqueda: la columna Línea a toma números de fila en base 1 y no identificadores, así que un E1042 metido en una celda no conecta nada. La segunda es una inversión: manager_id apunta hacia arriba en el árbol, de un hijo a su padre, mientras que Línea a apunta hacia abajo en el flujo, de una fila a las filas a las que lleva. Dejar el archivo en una forma que sobreviva al pegado está en /es/guides/como-estructurar-un-csv-para-diagramas-de-flujo, y la versión de padre e hijo de estos mismos datos está en /es/templates/csv-a-jerarquia-padre-hijo.
El ejemplo de abajo es una cadena de aprobación construida desde una exportación exactamente de esa clase. Lleva las tres cosas que hacen incómodos los datos reales de RR. HH.: una fila sin responsable, una protección contra un solicitante que está dentro de su propia cadena de aprobación, y un aprobador ausente con un suplente nombrado en su fila. Abre el panel de la hoja de cálculo que hay debajo y lee la columna Línea a al lado del lienzo.
Una línea jerárquica como recorrido, no como árbol
La cadena de aprobación de una exportación de RR. HH. en cuatro grados de completitud. Abre el panel de la hoja de cálculo para ver qué columnas están rellenas.
Leer la fila, comprobar si hay responsable
Las primeras filas no hacen más que leer el archivo: «Abrir una solicitud contra un centro de coste», luego «Leer la fila del solicitante en el export de RR. HH.», y luego el rombo «¿La fila nombra a un responsable?». Su salida No lleva a «Pedir al equipo de Personas que corrija la línea jerárquica», porque un manager_id vacío es un problema de datos antes que un problema de enrutamiento. En esta fase solo está rellena la columna Forma, así que las filas siguen siendo una lista.
Subir por manager_id a lo largo del archivo
«Recorrer manager_id hacia arriba para construir la cadena de aprobación» es la fila que hace el trabajo, y los tres rombos que vienen después son las comprobaciones que ese recorrido necesita. «¿El solicitante está dentro de su propia cadena de aprobación?» caza el ciclo, «¿Está disponible el aprobador nombrado?» deriva a un suplente, y «¿Dentro del límite de aprobación del responsable directo?» decide si una sola firma lo cierra. Línea a guarda ya números de fila, así que las flechas existen, pero todavía nada dice qué salida es cuál.
Etiquetar las ramas de escalado
Texto de línea se empareja con Línea a por posición, así que «Dentro del límite,Por encima del límite» manda el primer número a una firma y el segundo a «Escalar al jefe de departamento». La misma pareja se repite en el jefe de departamento y otra vez en el director, que es la escalera de escalado que tu columna de límites de aprobación ya codifica. La fila 18 lo cierra con «¿Llevarlo al comité de dirección o retirarlo?».
Añadir las dos columnas de carril
La columna Carril horizontal lleva el nivel dentro de la línea jerárquica (Empleado, Responsable directo, Jefe de departamento, Director, Comité de dirección), así que la profundidad en el árbol se convierte en distancia a lo ancho del lienzo. La columna Carril vertical lleva la función: Área solicitante, Finanzas, Equipo de Personas, Oficina de dirección. Con las dos rellenas se lee que el equipo de Personas solo aparece cuando la exportación estaba mal, y Finanzas solo cuando el gasto cae en el centro de coste de otra área.
Cómo funciona
Exporta las columnas de las que depende el enrutamiento
Necesitas employee_id, manager_id y un nombre legible por persona. Añade el puesto, el centro de coste, el límite de aprobación y cualquier columna de suplente, porque son las que deciden dónde deja de subir una solicitud. Deja fuera todo lo que el diagrama no vaya a enseñar nunca (salario, dirección, fecha de alta), porque un archivo más estrecho es mucho más fácil de revisar a ojo y una columna no reconocida viaja con el pegado y se ignora de todas formas.
Lee el archivo como texto antes de que lo haga una hoja de cálculo
Abre la exportación primero en un editor de texto. Comprueba que el delimitador es una coma y no un punto y coma, que los nombres que llevan una coma van envueltos en comillas dobles, que el archivo es UTF-8 para que sobrevivan los nombres acentuados, y que el primer encabezado es de verdad employee_id y no una marca de orden de bytes seguida de employee_id. Todo esto falla en silencio: las columnas se emparejan por nombre de encabezado, así que un encabezado que no es exactamente lo que crees no se empareja con nada.
Decide cuál de los dos diagramas estás construyendo
Una caja por persona, ordenadas por quién depende de quién, es un árbol y va en el editor de organigramas. Un camino que recorre una solicitud a través de la línea jerárquica es un diagrama de flujo y va aquí: una fila por paso en lugar de una fila por persona, con la exportación aportando los niveles, los límites y los suplentes. Decide esto antes de empezar a numerar filas, porque las dos formas no se convierten la una en la otra.
Invierte manager_id en números de fila
Ordena primero las filas en el orden en que las quieres numeradas, porque Línea a se refiere a posiciones y renumerar después lo recablea todo. Después, para cada persona, reúne los números de fila de todos aquellos cuyo manager_id sea igual a su employee_id y mételos en su Línea a, separados por comas. Los reportes se convierten en flechas de salida; manager_id es solo la clave de búsqueda y no se pega nunca dentro de Línea a.
Resuelve los huérfanos y los ciclos dentro del archivo
Ordena por manager_id y confirma que todos los valores aparecen como employee_id en algún punto del mismo archivo. Los que no aparecen son huérfanos, normalmente porque la exportación estaba acotada a un departamento o solo al personal activo. Recorre después cada cadena hacia arriba y detente si vuelves a pasar por una fila: un par de filas que se nombran entre sí es un ciclo, y es o una suplencia que nadie cerró o dos filas editadas el mismo día por personas distintas.
Pégalo, y añade después formas y carriles
Suelta el .csv sobre el área de la hoja de cálculo de un diagrama nuevo, o pega dentro el texto del CSV. Pon Forma en Decisión en las filas que formulan una pregunta e Inicio, Éxito y Rechazo en los terminadores, mete las respuestas en Texto de línea en el mismo orden que los números de Línea a, y mete el nivel de autoridad en la columna Carril horizontal para que cada peldaño de la línea jerárquica tenga su propio carril.
Errores que debes evitar
manager_id apunta hacia arriba, Línea a apunta hacia abajo
La columna de responsable nombra a un padre; la columna Línea a nombra sucesores. Mete una en la otra sin cambiarla y todas las flechas irán de una persona a su jefe. La señal está en la cúspide de la organización: acaba con flechas entrando desde todas partes y ninguna saliendo.
Un employee_id no es un número de fila
Línea a lee posiciones dentro de la hoja (los números que hay a la izquierda del editor), así que una celda con E1042 o 00147 no conecta nada y no da ningún error. Haz la unión dentro de la exportación, sustituyendo identificadores por posiciones, antes de pegar. /es/guides/como-definir-las-conexiones-de-un-diagrama-de-flujo-en-csv cubre esa columna en detalle.
Responsables que la exportación no contiene
Un manager_id sin ninguna fila de employee_id que le corresponda es un huérfano, y casi nunca significa que esa persona no tenga responsable. Las exportaciones acotadas a un departamento, los filtros de solo personal activo y una baja cuyo relevo nunca se registró lo producen todos. El hueco de la cúspide de la organización es el único caso legítimo.
La hoja de cálculo reescribió los identificadores en silencio
Los números de empleado con ceros a la izquierda son la víctima clásica: abre el CSV en una hoja de cálculo y 00147 se convierte en 147, así que la mitad de las uniones por manager_id dejan de coincidir y te sale un bosque de árboles de una sola persona. Trabaja desde el texto en bruto, o importa como texto las columnas de identificador, y compara el recuento de filas de tu unión con el recuento de filas del archivo.
Abre el ejemplo de línea jerárquica
Abre el ejemplo como tu propio diagrama para ver las columnas rellenadas, y pega después encima tu propia exportación una vez resueltos employee_id y manager_id a números de fila.
Guías relacionadas
Preguntas frecuentes
¿Puede QueryChart importar directamente un CSV de organigrama?
Las filas entran soltando el .csv sobre el área de la hoja de cálculo o pegando dentro el texto del CSV, y las columnas se emparejan por nombre de encabezado y no por posición, así que el orden en que estén da igual y todo lo que no se reconozca viaja y se ignora. Lo que no va a hacer es deducir una jerarquía por ti: no hay asistente de importación, ni pantalla de emparejamiento de columnas, ni conector a un sistema de RR. HH. El archivo tiene que decir ya, en la columna Línea a, a qué números de fila se conecta cada fila.
¿Uso el editor de diagramas de flujo o el de organigramas?
Si el resultado es un árbol de plantilla (una caja por persona, los responsables encima de los reportes, que se lee para contestar quién depende de quién) usa el editor de organigramas dedicado, que está hecho para esa forma y mantiene un único padre por persona. Usa el editor de diagramas de flujo cuando la línea jerárquica sea un recorrido y no un retrato: una aprobación que sube hasta encontrar a alguien con límite suficiente, una vía de escalado, una solicitud que tiene que desviarse por Finanzas. Eso lleva decisiones y excepciones dentro, y una decisión no es algo que un árbol pueda dibujar.
¿Qué pasa si dos personas se reportan mutuamente?
El diagrama lo dibujará (un par de flechas apuntándose entre sí) pero cualquier cosa que recorra la cadena hasta arriba no terminará, y por eso los ciclos se buscan en el archivo y no después de pegar. En la práctica un ciclo es una suplencia que nadie cerró, o dos filas editadas el mismo día por personas distintas. El diagrama de ejemplo se protege de la versión de enrutamiento del mismo problema con la decisión «¿El solicitante está dentro de su propia cadena de aprobación?», que salta un nivel en lugar de dar vueltas.
Mi exportación va delimitada por punto y coma y algunos nombres llevan comas.
Las dos cosas son normales en las exportaciones de RR. HH. y las dos se arreglan dentro del archivo. Una exportación delimitada por punto y coma (habitual cuando el sistema se configuró para una región europea) hay que volver a exportarla o convertirla a comas; pégala tal cual y la fila de encabezado entera cae en una sola columna, que al menos falla de forma evidente en vez de sutil. Un valor con una coma dentro es legal siempre que vaya envuelto en comillas dobles, así que «Nakamura, Yuki» sigue siendo un campo mientras que ese mismo texto sin comillas se convierte en dos.
¿Cómo mantengo el diagrama al día cuando cambia el sistema de RR. HH.?
Volviendo a exportar y a pegar, no conectando los dos: no hay ningún enlace en vivo entre QueryChart y un sistema de RR. HH. Eso importa menos de lo que suena, porque lo que dibujaste es la regla de enrutamiento y no la plantilla: «escalar al jefe de departamento cuando el importe supere el límite del responsable directo» sobrevive a una reorganización que cambia todos los nombres del archivo. Rehaz la exportación cuando cambien los niveles o los límites y déjala en paz cuando solo cambien las personas. La versión corta de la conversión entera está en /es/guides/crear-diagrama-de-flujo-desde-csv.
