Organigramas

Los organigramas son la representacin grfica de la estructura orgnica de una empresa u organizacin
que refleja, en forma esquemtica, la posicin de las reas que la integran, sus niveles jerrquicos, lneas de
autoridad y de asesora.

Tipos de Organigramas:
Basndome en las clasificaciones planteadas por Enrique B. Franklin (en su libro "Organizacin de
Empresas") y Elio Rafael de Zuani (en su libro "Introduccin a la Administracin de Organizaciones"), pongo a
consideracin del lector la siguiente clasificacin de organigramas: 1) Por su naturaleza, 2) por su finalidad,
3) por su mbito, 4) por su contenido y 5) por su presentacin o disposicin grfica.
1. POR SU NATURALEZA: Este grupo se divide en tres tipos de organigramas:

Microadministrativos: Corresponden a una sola organizacin, y pueden referirse a ella en forma

global o mencionar alguna de las reas que la conforman.

Macroadministrativos: Involucran a ms de una organizacin.

Mesoadministrativos: Consideran una o ms organizaciones de un mismo sector de actividad o

ramo especfico. Cabe sealar que el trmino meso administrativo corresponde a una convencin
utilizada normalmente en el sector pblico, aunque tambin puede utilizarse en el sector privado.

2. POR SU FINALIDAD: Este grupo se divide en cuatro tipos de organigramas:

Informativo: Se denominan de este modo a los organigramas que se disean con el objetivo de ser
puestos a disposicin de todo pblico, es decir, como informacin accesible a personas no
especializadas. Por ello, solo deben expresar las partes o unidades del modelo y sus relaciones de
lneas y unidades asesoras, y ser graficados a nivel general cuando se trate de organizaciones de
ciertas dimensiones.

Analtico: Este tipo de organigrama tiene por finalidad el anlisis de determinados aspectos del
comportamiento organizacional, como tambin de cierto tipo de informacin que presentada en un
organigrama permite la ventaja de la visin macro o global de la misma, tales son los casos de
anlisis de un presupuesto, de la distribucin de la planta de personal, de determinadas partidas de
gastos, de remuneraciones, de relaciones informales, etc. Sus destinatarios son personas
especializadas en el conocimiento de estos instrumentos y sus aplicaciones.

Formal: Se define como tal cuando representa el modelo de funcionamiento planificado o formal de
una organizacin, y cuenta con el instrumento escrito de su aprobacin. As por ejemplo, el
organigrama de una Sociedad Annima se considerar formal cuando el mismo haya sido aprobado
por el Directorio de la S.A..

Informal: Se considera como tal, cuando representando su modelo planificado no cuenta todava
con el instrumento escrito de su aprobacin.

3. POR SU MBITO: Este grupo se divide en dos tipos de organigramas:

Generales: Contienen informacin representativa de una organizacin hasta determinado nivel

jerrquico, segn su magnitud y caractersticas. En el sector pblico pueden abarcar hasta el nivel de
direccin general o su equivalente, en tanto que en el sector privado suelen hacerlo hasta el nivel de
departamento u oficina.

4. POR SU CONTENIDO: Este grupo se divide en tres tipos de organigramas:

Integrales: Son representaciones grficas de todas las unidades administrativas de una organizacin
y sus relaciones de jerarqua o dependencia. Conviene anotar que los organigramas generales e
integrales son equivalentes.

Funcionales: Incluyen las principales funciones que tienen asignadas, adems de las unidades y
sus interrelaciones. Este tipo de organigrama es de gran utilidad para capacitar al personal y
presentar a la organizacin en forma general.

De puestos, plazas y unidades: Indican las necesidades en cuanto a puestos y el nmero de

plazas existentes o necesarias para cada unidad consignada. Tambin se incluyen los nombres de
las personas que ocupan las plazas.

5. POR SU PRESENTACIN O DISPOSICIN GRFICA: Este grupo se divide en cuatro tipos de

organigramas:

Verticales: Presentan las unidades ramificadas de arriba abajo a partir del titular, en la parte
superior, y desagregan los diferentes niveles jerrquicos en forma escalonada. Son los de uso ms
generalizado en la administracin, por lo cual, los manuales de organizacin recomiendan su empleo.

Horizontales: Despliegan las unidades de izquierda a derecha y colocan al titular en el extremo

izquierdo. Los niveles jerrquicos se ordenan en forma de columnas, en tanto que las relaciones
entre las unidades se ordenan por lneas dispuestas horizontalmente.

Mixtos: Este tipo de organigrama utiliza combinaciones verticales y horizontales para ampliar las
posibilidades de graficacin. Se recomienda utilizarlos en el caso de organizaciones con un gran
nmero de unidades en la base.

De Bloque: Son una variante de los verticales y tienen la particularidad de integrar un mayor nmero
de unidades en espacios ms reducidos. Por su cobertura, permiten que aparezcan unidades
ubicadas en los ltimos niveles jerrquicos.

Circulares: En este tipo de diseo grfico, la unidad organizativa de mayor jerarqua se ubica en el
centro de una serie de crculos concntricos, cada uno de los cuales representa un nivel distinto de
autoridad, que decrece desde el centro hacia los extremos, y el ltimo crculo, sea el ms extenso,
indica el menor nivel de jerarqua de autoridad. Las unidades de igual jerarqua se ubican sobre un
mismo crculo, y las relaciones jerrquicas estn indicadas por las lneas que unen las figuras.

Programas
Es un complejo de polticas, procedimientos, reglas, asignacin de funciones, de recursos y otros elementos
necesarios para seguir un curso de accin determinado.
Los programas son un tipo de planificacin generalizada, que tiene por objeto definir un plan de accin
completa para dar cumplimiento a los objetivos definidos y a la estrategia establecida por la empresa.

Cmo desarrollar un programa de administracin de cambio de IT

Cambio de Programa de Administracin (por sus siglas en ingls CMP),

mas comnmente conocido como Cambio de Control de Procesos
Cambio de Control de Administracin, es un proceso formal usado para
asegurar que los cambios al producto sistema son introducidos en una
manera organizada y controlada (como se define en ISO 20000). CMP no
debera ser confundido con Cambio de Administracin Organizacional
(OCM), el cual administra los impactos de procesos en negocios nuevos,
incluso los que provienen de implementaciones de sistemas e iniciativas
de TI, cambios en la estructura organizacional, cambios culturales
dentro de una empresa. En resumen, OCM administra el cambio de el
lado de la gente. El propsito de CMP, es asegurar que el impacto
negativo de los cambios al sistema de informacin de una compaa sea
minimizado al utilizar un proceso estandarizado de gestin. Algunos
cambios no son opcionales. Si por ejemplo, el estndar de los cdigos de
barra cambia, te tienes que adaptar; si la estructura de retencin de
impuestos cambia, tu tambin tienes que cambiar. Sin embargo, todos
los cambios de este tipo continan estando sujetos a gestin. Nunca
debe darse el caso de cambios ad hoc hechos a un sistema a
procedimientos sin alguna supervisin. Esta idea debe provenir de altos
directivos y ser transmitida, sin excepciones, para todos en la compaa.
Sin respaldo del mas alto nivel, el CMP es una perdida de tiempo sin
sentido y dinero. Con el debido respaldo, este programa salvar a tu
compaa de varios errores muy costosos.

Pasos

1.

Desarrolla una Peticin de Cambio (por sus siglas en ingls RFC): Esto

puede provenir de la administracin de problemas donde un problema o una serie de

problemas relacionados, es identificada y un cambio de mitigacin es necesario para
impedir (o minimizar) efectos futuros. El RFC tambin se puede originar como un
resultado de una decisin de negocios que requerir algunas modificaciones
(agregar, borrar, cambiar) a la tecnologa de soporte. Un RFC tambin puede ser
necesario debido a influencias externas (por ejemplo, regulaciones gubernamentales
o cambios hechos por los socios de la empresa).

2.

Consigue aceptacin al cambio en la empresa: La decisin de hacer un

cambio es tpicamente una decisin de negocio donde costos vs beneficios son

comparados. Incluso en situaciones donde el cambio es estrictamente
infraestructural (componente de fallo de sistema) la decisin de invertir dinero
reside en el negocio, no en el departamento de TI. Hay ocasiones en las que cuando
los procedimientos son desarrollados por adelantado a los cambios preautorizados
tales como mantenimiento de sistema de emergencia, pero independientemente de la
fecha de la autorizacin, an as la decisin recae sobre los administradores del
negocio.

3.

Inicia el Desarrollo del Proyecto: Desarrollar el cambio

(incluyendo las pruebas) es una funcin guiada por TI. En caso de un

cambio de emergencia (servidor no funciona) esas funciones son
tpicamente predeterminadas. Cuando un nuevo sistema debe ser
desarrollado, ah hay esfuerzo colaborativo entre los usuarios del

negocio y el equipo de TI. Los sistemas son diseados por por TI, el
dise;o es aprobado por los socios del negocio (usuarios), desarrollado por
TI, puesto a prueba por una combinacin TI y usuarios, y el producto
final es aprobado por ambos. Debe prestarse atencin a efectos
secundarios que el sistema nuevo pueda tener en sistemas existentes.

4. Pasa la Puerta del Cambio Administrativo: El Consejo Asesor de cambios (por

sus siglas en ingls CAB) revisa todos los cambios antes de que puedan ser puestos
en produccin. Normalmente el CAB consiste de un grupo de personas con
diferentes perspectivas, antecedentes y reas de experiencia. Su funcin es revisar el
cambio desde un punto de vista de proceso y forma para asegurar que todos los
riesgos previsibles han sido identificados y mitigados, y que tcnicas
compensatorias estn en su lugar para cualquier elemento que se exponga (cosas
que puedan salir mal). El equipo de desarrollo y el patrocinador de cambio
presentarn el cambio a el CAB. La evaluacin del riesgo ser el punto clave.
Estrategias de implementacin, comunicacin a los interesados afectados, planes de
retroceso y monitoreo posterior a la implementacin son elementos en los que el
CAB requiere concentrarse. El CAB no es responsable de determinar si el cambio es
apropiado, esa decisin ya fue hecha. El CAB tampoco es responsable de
determinar si el cambio es rentable. Otra vez, esa decisin es estrictamente de
administracin.

5.

Implementa el Cambio: Si el CAB no aprueba el cambio, se

listarn razones (esto es porque siempre ciertos riesgos no son

mitigados comunicaciones no han sido planeadas) y a el equipo de
desarrollo se le dar tiempo para solucionar esos problemas y se
programar una nueva reunin antes de el CAB. Si el cambio es
aprobado, se programar la implementacin. No es el caso normalmente
que el CAB sea representado en la implementacin aunque es posible
que algunos de los miembros del CAB Tienen conocimientos que son
necesarios durante la implementacin, pero no sern presentados como

representantes del CAB, si no como expertos en la materia (por sus

siglas en ingls SME). Como se implementa el cambio, la lista y los
pasos, estn predefinidas y fueron presentadas y aprobadas por el CAB.
El proceso completo debe estar debidamente documentado y el proceso
aprobado debe ser seguido precisamente.

6.

Reporta los Resultados: Si el cambio se implement

correctamente sin contratiempos, el cambio se implement con

problemas que fueron corregidos durante la implementacin, o el cambio
se implement con problemas que se consideran aceptables, los
problemas que surgieron eran inaceptables y se regreso, o en el peor de
los casos el cambio se implement con problemas inaceptables y no se
puede regresar. Cualquier resultado, ser documentado y regresado a el
CAB.El CAB es ahora responsable de distribuir esa informacin a las
partes interesadas y de guardar y mantener esos resultados en el
Sistema Administrador de Cambios (esto puede ser en una base de
datos automatizada en un sistema de llenado en papel, pero los
documentos se deben mantener para propsitos de auditora).

7.

Problemas de Enlace en la Administracin de Cambios:

Problemas que surjan comparadas con la documentacin de cambios del

CAB para que cualquier efecto adverso al cambio que no se anticipe
pueda ser aislado. Es un caso muy comn que efectos no deseables al
cambio no sean notados inmediatamente, pero son identificados al
surgir el problema en sistemas auxiliares. Por ejemplo, la adicin de
muchos campos a una base de datos puede no tener un efecto negativo
directo en los usuarios pero puede impactar el rendimiento de la red que
ser notado para otros usuarios que no estn relacionados directamente
con el sistema modificado.

8.

Auditoras peridicas de CMP: Por lo menos 1 auditora de CMP

cada ao debera ser conducida para asegurarse que todas la

documentacin de cambios se mantenga disponible y actualizada. Cada
documento de aprobacin de cambio debe ser examinad para asegurar
que las firmas correctas se encuentren en forma y que los resultados de
la implementacin son debidamente documentados.

Consejos

Los procedimientos deben ser sujetos a la Administracin del cambio. Si hay un

cambio en el sistema de planificacin de respaldo, que tenga que pasar por la
Administracin de Cambio. Analiza cada cambio de cualquier clase (sistema o
procedimiento) para determinar si es posible cualquier tipo de cambio.

Mantenimiento peridico debe ser aprobado con anterioridad. Si reiniciar un

servidor es un proceso normal los Domingos a las 2:00 de la maana, no es
necesario crear un RFC cada vez, pero ese proceso debe ser aprobado previamente.

Mantenimiento Ad hoc se debe apegar al CMP. Incluye dichas cosas sistemas de

supresin de incendios, limpieza del subsuelo en el centro de informacin,
inspeccin y pruebas HVAC e inclusive mantenimiento de control de plagas.
Algunas compaas van tan lejos como requerir un RFC si un foco incandescente se
cambia en el centro de informacin (la escalera se cay y da la red).