Organigrama

Acerca de los organigramas

Un organigrama (gráfico organizacional) mapea la estructura formal de reporte de una organización — quién gestiona a quién, qué equipos pertenecen a qué líderes, y dónde encajan los puestos vacantes y los asesores externos. Los equipos de RRHH los usan durante la planificación de personal; los fundadores los usan antes de las reuniones con el consejo; los gerentes de operaciones los distribuyen durante las reestructuraciones. A diferencia de un diagrama de flujo genérico, un organigrama trata a las personas (y posiciones) como las entidades primarias, con la jerarquía codificada por sangría o aristas explícitas.

Schematex sigue las convenciones generales de organigramas con extensiones para posiciones abiertas/vacantes, reporte matricial (línea punteada) y relaciones de asistente. No existe un único estándar ISO para organigramas; las convenciones implementadas aquí se derivan de la práctica de RRHH y las normas de la industria del software. Para el contexto académico autoritativo consulta Fayol (1916) y el artículo de Wikipedia sobre organigramas.

1. Tu primer organigrama

El organigrama más simple y útil: una jerarquía de tres niveles con un puesto vacante.

Cuatro reglas cubren el 80% de los casos de uso:

1. Comienza con la palabra clave orgchart, opcionalmente seguida de un título entre comillas.
2. Cada persona es un nodo — id: "Nombre" | "Título" | "Departamento" [props]. El | separa los campos de nombre, título y departamento.
3. La sangría determina la jerarquía — cada dos (o más) espacios adicionales mueven un nodo un nivel más profundo bajo el nodo menos sangrado más cercano por encima.
4. Declara puestos vacantes con open id: o draft id:, y asesores externos con advisor id:.

Los comentarios deben comenzar con # en su propia línea (los // en línea al final también se eliminan).

2. Nodos

Una línea de nodo tiene la forma [kind] id: fields [props]. El id debe coincidir con [A-Za-z][A-Za-z0-9_-]*.

2.1 Campos (separados por barra vertical)

La parte después de : y antes del bloque opcional [props] se divide por |:

alice: "Alice Zhang"                                # name only
alice: "Alice Zhang" | "VP Engineering"             # name + title
alice: "Alice Zhang" | "VP Eng" | "Platform"        # name + title + department
alice: "Alice Zhang" | "VP Eng" | "Platform" | "x@co.com"  # + info line

2.2 Tipos de nodos

La palabra clave de tipo opcional antes del id cambia cómo se renderiza el nodo:

2.3 Propiedades de los nodos

Las propiedades van en [key: value, …] al final de una línea de nodo.

Iconos de rol — el valor de role: se resuelve en un icono de visualización. Palabras clave aceptadas (sin distinción de mayúsculas/minúsculas):

3. Jerarquía

La jerarquía se expresa mediante sangría — el patrón más común. Cada nodo se convierte en hijo del nodo más cercano por encima con una sangría menor. Las tabulaciones se tratan como dos espacios.

ceo: "CEO"
  cto: "CTO"           # child of ceo (indent 2)
    eng: "Engineer"    # child of cto (indent 4)
  cfo: "CFO"           # child of ceo (indent 2, same level as cto)

Alternativamente, usa la propiedad reports: para establecer un padre de forma explícita independientemente de la sangría:

orgchart "Flat file"
ceo: "CEO"
cto: "CTO" [reports: ceo]
eng: "Engineer" [reports: cto]

4. Aristas

Existen dos tipos de aristas. La mayoría de las líneas de reporte provienen automáticamente de la jerarquía de sangría. También puedes escribirlas explícitamente — o agregar líneas matriciales (punteadas).

Las aristas explícitas requieren que ambos ids de nodo estén ya declarados. Una arista report creada explícitamente no se duplica si la misma relación ya está implícita por la sangría.

Se admiten etiquetas en las aristas:

pm1 -.-> design [label: "product partnership"]

5. Configuración

Las líneas config: ajustan el diseño y la orientación. Cada una va en su propia línea.

Notas de diseño:

• tree — árbol jerárquico estándar con conectores ramificados. Ideal para la mayoría de los organigramas.
• list / directory / compact — vista de directorio compacto con sangría. Bueno para listas de personal grandes donde la ramificación del árbol se vuelve complicada.

Diseño árbol (predeterminado) — tarjetas de avatar con conectores ramificados y codificación de colores por departamento. Ideal para equipos de hasta ~30 personas.

Diseño lista — filas de directorio compactas con guías de sangría. Ideal para equipos grandes donde la ramificación del árbol se vuelve complicada.

6. Etiquetas y comentarios

• Título: orgchart "Acme Corp" — solo en la primera línea.
• Campo de nombre: primer campo delimitado por barra vertical después de los dos puntos; puede estar entre comillas ("Alice Zhang") o sin ellas (Alice).
• Campos de título/departamento: segundo y tercer campos delimitados por barra vertical.
• Línea de información: cuarto campo delimitado por barra vertical, o establecido via note:, email:, phone: o location: props. Gana el primero encontrado.
• Comentarios: # al inicio de una línea (después de los espacios iniciales). Los // en línea también se eliminan.

7. Palabras reservadas y escape

Reservadas al inicio de línea: orgchart (encabezado), config:, role, open, draft, tbh, advisor, external.

Tokens de operadores reservados — evita estas secuencias dentro de los ids: ->, .->

Reglas de ID: debe coincidir con [A-Za-z][A-Za-z0-9_-]*. Los nombres con espacios van en el campo de nombre entre comillas, no en el id.

Cadenas con espacios en los valores de props (ej. department: "Platform Eng") deben ir entre comillas dobles.

8. Errores comunes

9. Gramática (EBNF)

document       = header (blank | comment | config | edge | node)*

header         = "orgchart" ( WS quoted-string )? NEWLINE
quoted-string  = '"' any-char-but-quote* '"'

config         = "config" WS ":" WS key WS "=" WS value NEWLINE
key            = "direction" | "layout"

node           = INDENT* kind? id ":" WS fields ( "[" node-attrs "]" )? NEWLINE
kind           = "role" | "open" | "draft" | "tbh" | "advisor" | "external" | "person"
fields         = field ( "|" field )*
field          = quoted-string | unquoted-text
node-attrs     = node-attr ("," node-attr)*
node-attr      = "role:" role-keyword
               | "icon:" role-keyword
               | "department:" text
               | "status:" ( "new" | "leaving" | "on-leave" )
               | "avatar-color:" quoted-hex
               | "gender:" ( "male" | "female" )
               | "note:" text
               | "email:" text
               | "phone:" text
               | "location:" text
               | "assistant-of:" id
               | "matrix:" id-list
               | "reports:" id
               | bare-flag

bare-flag      = "open" | "draft" | "tbh" | "external"

edge           = id WS edge-op WS id ( "[" edge-attrs "]" )? NEWLINE
edge-op        = "->" | ".->"  // -.-> for matrix
edge-attrs     = "label:" quoted-string

id             = [A-Za-z] [A-Za-z0-9_-]*
comment        = ( "#" | "//" ) any NEWLINE

Fuente autoritativa: src/diagrams/orgchart/parser.ts. Si esto diverge del analizador, el analizador tiene prioridad — por favor, abre un issue.

10. Hoja de ruta

Planificado — aún no se puede analizar. No uses esto en DSL generado hoy; el analizador lo rechazará o ignorará.

• Renderizado visual de assistant-of: — la propiedad se analiza y almacena en el AST pero el renderizador aún no dibuja el conector de codo de asistente.
• Config coloring — temas de colores basados en departamento (coloring: department).
• Niveles de tamaño compact de config — control explícito del tamaño de tarjeta (size: small | medium | large).
• Ancho de nodo span: — hacer que un nodo abarque varias columnas de hermanos en el diseño de árbol.
• Foto / URL de avatar — avatar: "https://…" para mostrar una foto real.
• Exportar a formatos HRIS — salida estructurada JSON/CSV junto con el SVG.

Realiza seguimiento en los issues de GitHub si necesitas alguno de estos antes.

Ejemplos relacionados

Escenarios listos para usar de la galería de ejemplos: