. ¿Qué esfuerzo / tiempo dedicamos en nuestro día a día a mejorar la
eficiencia de / a optimizar nuestros proceso internos?
. ¿Qué importancia le damos a estas iniciativas de optimización /
mejora?
. ¿Tenemos equipos dedicados en exclusiva a esta tarea, son las mismas
personas que llevan el día a día los que intentamos que además mejoren los
procesos?
Nicolás Rodríguez de Ferrovial indica que “Ferrovial tiene un grupo enfocado en gestionar y mejorar los proceso más operativos, los que asegurar la provisión de servicios, los que aseguran la provisión de Servicios. Considera que el Service Desk es el más crítico. Un Service Desk negativo impacta de forma dramática en la imagen de los usuarios”.
Marcos Navarro
de FCC indica que “para nosotros los procesos no son estratégicos, son una
condición necesaria. Tienen que formar parte de la cultura de la gestión TI,
pero no sólo internamente, el negocio tiene que entenderlo”, y sentencia “los
procesos son como los frenos, nos permiten ir más deprisa. Los procesos, al
igual que los frenos, te salvan la vida”.
Guillermo
Gamoneda de Enterprise Holding-Atesa indica que “El proceso tiene que ser útil
y operativo, en caso contrario, no es proceso”.
Nuria Simó CIO
de Campofrío se confiesa “enamorada de los procesos”. Indica que “son
estratégicos. En su compañía han definido 20 grupos de procesos y los han
clasificado en tres niveles: operativos, estratégicos y aquellos que permiten
la excelencia en la gestión. La receta para que triunfen los procesos; hay que
mirar al área de Sistemas como si fuera un área de negocio más, igual que
hacemos cuando planificamos un proyecto para el negocio, así deberíamos
trabajar para decidir cómo gestionarnos internamente”.
He resumido el
artículo con las 4 entradas incluidas, porque son las que más reflejan mi
opinión al respecto. Yo como NS soy un enamorado de los procesos, creo en ellos
de forma total como el medio más efectivo para conseguir mejorar nuestra gestión
interna, para conseguir una mayor eficiencia y una mayor productividad.
Pensando un poco, diría que no creo que exista otra forma.
Evidentemente
como dice GG, los procesos deben ser útiles y operativos, no se deben valorar
por el número de páginas o por su “peso”. Evidentemente su gestión, las tareas
dedicadas a crear los mismos, a mejorarlos, a explicar los mismos a todos las
personas de TI, etc, etc, debe ser una labor en la que participen los equipos implicados,
pero creo necesario que exista un equipo que no esté en el día y que sea
responsable de gobernar dichas tareas. Un equipo dependiendo del CIO, un
proyecto esponsorizado por este, y compartido por el resto de la dirección de
Sistemas.
Por último no
quiero olvidarme de uno de los pilares para el éxito de una Gestión de
Procesos: por cada proceso debe existir un responsable y el proceso debe tener
un objetivo/s. Cualquier tarea que pertenece a un proceso que se ejecute en un
área de Sistemas o en cualquier otra
área de una compañía debe tener un objetivo. Sólo teniendo un objetivo al que
llegar podemos fijarnos planes, hacer seguimiento de los mismos, saber de dónde
partimos y si estamos avanzando o no, y
lo más importante definir los procesos en pro de alcanzar dichos objetivos. No
creo que se puedan o se deba definir un proceso sino está muy claro cuál es el
objetivo que perseguimos.
Un
ejemplo “sencillo”, cuántas veces hemos oído, “vamos a mejorar el proceso de
Gestión de Incidencias”, Ok, pero vamos a mejorarlo en qué línea, ¿Cuál es
nuestro objetivo al respecto de dicho proceso?.
No es lo mismo trabajar el proceso si el objetivo es “tener menos
incidencias” que si el objetivo es “cerrarlas en menos tiempo”. Otro error
podría ser definir “n” objetivos para un proceso, todos igual de importantes, mi
opinión es que no vale. Hay que mojarse, decidir cuál es el objetivo principal
a lograr y trabajar en su obtención. Una vez conseguido, perfecto,
identificamos otro y a por ello. Os suena eso del que “mucho aprieta poco
abarca”
Saludos.
Gabriel
http://www.computing.es/cios/encuentros/1070190000201/procesos-asignatura-pendiente-cio.1.html#%21
