Inversiones en Sistemas de Información
Causas de su pobre Rendimiento
Rodrigo Castro C., MSc
Preparado para el curso: Gestión de las Tecnologías de Información
Departamento de Ciencia de la Computación, Universidad Católica
Santiago Chile, Mayo 2008, Marzo 2009, Marzo 2010
ESTADÍSTICAS
NO SON
ALENTADORAS
Estos apuntes se refieren a proyectos en los que se compran “aplicaciones
estándares del mercado”, “de clase mundial”, que se comercializan en
varios países del mundo y su buen funcionamiento ha sido reconocido por
sus clientes. Estos hacen uso de dichas aplicaciones para implementar
Sistemas de Información apoyados por la TI. Es importante tener claro que
la aplicación no es el Sistema de Información. Ninguna Aplicación es en sí
un Sistema de Información, sí lo es el proceso que se implementa y en el
que ésta participa1.
Hay que ser cuidadoso para interpretar la jerga de marketing que están
utilizando los proveedores de Aplicaciones y sus redes de empresas
implantadoras: ninguna Aplicación tampoco es en sí una “solución” y
ninguna garantiza la adopción de las mejores prácticas.
De acuerdo con estadísticas recopiladas por IT-Cortex2 cerca del 60%
las empresas que se embarcan en proyectos para la implementación
sistemas de información consideran que esos proyectos han fracasado
cumplir con sus expectativas. El gerente que autoriza la adquisición
un Sistema de Información (el que aprueba el dinero,
de
de
en
de
no
Sistema de Información: “conjunto de procedimientos que producen
información para la toma de decisiones y el control de una organización”. H. C. Lucas Jr.
1
2
http://www.it-cortex.com/Stat_Failure_Rate.htm
necesariamente el usuario del sistema ni el área de TI) siempre pretende
mejorar los resultados del negocio, pero esto no se cumple en la medida
en que se espera ¿qué prácticas interfieren o atentan contra la obtención
de los resultados que los gerentes pretenden cuando autorizan la
adquisición de TI?
¿PORQUÉ
LOS SISTEMAS DE INFORMACIÓN NO ENTREGAN LOS
RESULTADOS ESPERADOS POR LAS PERSONAS QUE AUTORIZAN SU
PRESUPUESTO?
Ausencia del Resultado de Negocios como parte del proyecto.
Hay una máxima en la administración que dice que “lo que no se mide no
se puede controlar”, independiente de la calidad de la estrategia de
control, nada que no se mida con una métrica de buena calidad se puede
lograr (puede ocurrir, pero eso no es un logro, es casualidad). Es la
esencia de todo el movimiento de calidad total: fijar metas de
mejoramiento, medir y controlar el avance (y validar que todo lo que se
haga impacte en forma positiva la satisfacción de los clientes).
También mencionamos al principio que toda adquisición de TI en las
empresas se hace con el fin último de obtener beneficios para el negocio.
Sin embargo, si se analizan los proyectos de puesta en marcha de las
“soluciones” adquiridas, se puede comprobar fácilmente que en la mayoría
de los proyectos no se controlan los resultados de negocio que se
pretenden. La línea final de la mayoría de proyectos de puesta en marcha
de aplicaciones es generalmente “Go Live” o el momento en que culmina
alguna etapa de “refinamiento” de la configuración de la aplicación.
Obviamente, éste no es un resultado de negocios, lograr que la aplicación
funcione no es el fin de una inversión en TI.
Al final del proyecto de puesta en marcha de la aplicación, la relación con
el proveedor generalmente ha sufrido algún desgaste, la empresa siente
que se ha invertido una cantidad importante de dinero y los ánimos no
están como para llegar dónde el Gerente General a solicitarle que apruebe
fondos adicionales para un proyecto que ahora sí va a producir los
resultados que él esperaba de la inversión original en TI.
O sea, las empresas no dan a los proyectos de informática el mismo
tratamiento que le dan a los proyectos de inversión. Para éstos, las
empresas tienen una manera formal de auditar la obtención de los
resultados prometidos.
Pero ¿será necesario alargar más los proyectos para primero poner a
funcionar la aplicación (Go Live) y después dedicarse a obtener resultados
de negocio?: no, esto más bien sería un error. Veamos.
La metodología tradicional para la implantación es gobernada por los
módulos de las Aplicaciones.
Las aplicaciones siempre constan de un número de módulos que trabajan
en forma integrada y resulta, que para ponerlas a funcionar los
proveedores (consultores) organizan un plan de trabajo gobernado por los
módulos. Por ejemplo, el módulo financiero contable, luego el módulo de
ventas, luego el módulo de administración de inventarios y luego el
módulo de compras. Asimismo, trabaja cada módulo con las personas
especialistas en esos temas.
Observemos que esta es una forma de exacerbar la organización funcional,
o sea, los estamentos estancos o silos de la organización. Siendo que uno
de los aportes más importantes de los sistemas de información es la
habilitación de una orientación a procesos transversales, este enfoque por
módulos atenta contra este importante objetivo. La única forma que hoy
día se reconoce para optimizar el inventario de una organización es
logrando que el área de ventas y el área de compras trabajan como un
solo proceso integrado (y en alianza con los proveedores); no en forma
separada.
Ocurre que la mayoría de las aplicaciones estándares del mercado son
como el concreto: líquido al principio, mientras se moldea y se chorrea,
pero una vez que se seca imposible de modificar. La ausencia de un
enfoque orientado a procesos para la implantación de la aplicación, genera
estamentos estancos rígidos como el concreto. Algunos proveedores han
incorporado Work Flows a sus aplicaciones que ayudan a paliar el
problema. No lo resuelven porque el diseño de procesos transversales
óptimos no se logra uniendo partes de los procesos que funcionaban
anteriormente (un sistema es más que la suma de sus partes).
La capacitación también se aborda de acuerdo a los módulos
La capacitación en los proyectos de implantación también refuerza la
desintegración de los Sistemas de Información (“conjuntos de
procedimientos” desintegrados). En breve digamos simplemente que la
capacitación también se “modulariza”3: inventarios, contabilidad, compras,
mantenimiento… A los encargados del inventario se les capacita en
“administración de inventarios” y a los mantenedores en “administración
del mantenimiento”, como si los mantenedores no fueran responsables de
las existencias de repuestos. 4 La capacitación que se entrega en los
proyectos de Informática también está fomentando la organización
funcional.
Adicionalmente la capacitación está orientada a ayudar a comprender
como funciona la aplicación, pero no como puede la organización obtener
sus objetivos. Inclusive en las capacitaciones se cubre funcionalidad
disponible en cada módulo sin discriminar cuándo, cómo y en qué
circunstancias se va a utilizar.
En síntesis … no se capacita la obtención de beneficios de negocios.
La palabra “modulariza” no está en el Diccionario. Digamos que el proceso
está gobernado por los “módulos” de la Aplicación…que pueden ser diferentes para
diferentes proveedores del mismo tipo de Aplicación.
3
No estamos criticando las Aplicaciones de Clase Mundial. Personalmente
somos de la idea de que es preferible adquirir dichas aplicaciones que pretender
desarrollarlas… si son realmente “de clase mundial”. El problema es la metodología para
su puesta en funcionamiento.
4
PARA
OBTENER
RESULTADOS
DE
NEGOCIOS
Cambios en el enfoque de adquisición.
Cuando se invierte en Sistemas de Información no se está comprando un
producto que compite por su precio o por sus elementos diferenciadores,
hay que dejar este enfoque de Porter en el siglo pasado. Se requiere el
establecimiento de una alianza en la cual, tanto el proveedor como el
cliente se beneficien de los buenos resultados del proyecto.
Es inconcebible que este cambio entre las relaciones entre proveedores y
clientes se haya producido con creces en otros ámbitos pero no ha llegado
a la provisión de Sistemas de Información. Muchas empresas mineras ya
no compran el equipo para acarrear el mineral de la mina al chancador
primario, compran toneladas acarreadas. Las grandes cadenas de
supermercados no se molestan en llevar el control de inventarios de los
productos que venden: sus proveedores los llevan por ellos y son
responsables de colocarlos en la góndola “justo a tiempo”.
Este tipo de relaciones con los proveedores (o los consultores) distan
mucho de ser el tipo de fuerzas en oposición que describió Porter en 1979
(el Modelo de las Cinco Fuerzas de Porter). Cultura de búsqueda de
competitividad del siglo pasado que todavía subsiste. Son alianzas ganarganar en las cuales, tanto el proveedor como el cliente, se preocupan de
los clientes que están al final de la cadena de valor.
Contar con un Mapa Estratégico (Resultados de Negocio)
Lo primero que hay que hacer es explicitar los resultados de negocio que
se desea obtener. Este no es un paso trivial porque los resultados de
negocio son fáciles de formular en el nivel más alto de la pirámide
estratégica (utilidades, ingresos, gastos) pero difíciles de formular cuando
se pretende una relación causa efecto rigurosa con indicadores de nivel
operativo. Para no hacer muy largo este artículo diremos simplemente que
es necesario recurrir a las enseñanzas de Kaplan y Norton sobre la
formulación de Mapas Estratégicos en las empresas (hoy indispensables
para el diseño de Tableros de Comando).
Dejemos la tarea de la elaboración del Mapa Estratégico a los gerentes de
la organización, ellos deben a lo menos validar el conjunto de indicadores
de resultados que van a servir para verificar el beneficio de negocios que
entrega el nuevo Sistema de Información. Apoyándose en estos
indicadores será necesario identificar un subconjunto de Indicadores
Precursores5 del resultado esperado, aquéllos que estén más cercanos al
ámbito del nuevo Sistema de Información.
No hay que olvidar que la capacitación hay que enfocarla y organizarla de
acuerdo a los resultados que se desean obtener. Es factible que este
proyecto demore más tiempo que el proyecto tradicional… inclusive puede
convertirse en un proyecto permanente: siempre existirá la necesidad de
obtener nuevos resultados para los que existirá Tecnología de Información
con un rol habilitador importante. Los proveedores de Sistemas de
Información que logren desarrollar una relación con sus clientes que les
transforme en sus aliados de negocios tendrán clientes durante muchos
años.
El enfoque TIMEBOX ayuda a obtener Resultados
Las organizaciones son sistemas complejos. Si tomamos la versión más
simple que conocemos de Organización: Estructura, Proceso y
Comportamiento 6 , notamos que es imposible afectar los procesos sin
afectar la estructura de la organización y el comportamiento de las
personas. No son sencillos los proyectos para poner a funcionar nuevas
versiones de los Sistemas de Información; pero no son imposibles,
entregamos algunas recomendaciones metodológicas:
5
Necesarios pero no suficientes para garantizar un resultado posterior.
Las Organizaciones: Comportamiento Estructura Procesos, 10/e; Gibson,
Ivancevich, Donnelly; McGraw-Hill 2001
6
El enfoque Timebox es una de las herramientas metodológicas más
poderosas para obtener resultados. Se basa en el hecho de que cualquier
objetivo se formula en base a una abstracción (una simplificación de la
realidad). Todo trabajo que las personas hacen para alcanzar el objetivo lo
va haciendo más concreto y conforme se van acercando a él, van
quedando claras algunas de las simplificaciones y supuestos que se
asumieron en el momento en que se formularon. Cuando el proyecto llega
a la proximidad de su objetivo, las personas que los formularon sufren
siempre una crisis porque se dan cuenta que sus requerimientos han
cambiado (han aprendido y el entorno ha cambiado) y que el objetivo que
desean “ahora” tiene diferencias con el que formularon originalmente. Las
personas van aprendiendo en el camino y aprender significa modificar la
conducta. Este fenómeno obliga a colocar metas no muy lejanas en el
tiempo y a no pretender lograr (nunca) el 100% de la meta sino el 80%
que se logra con el 20% del esfuerzo…
En esencia, el enfoque consiste en aplicar Pareto al 100% del supuesto
RESULTADO. El 80% de ese RESULTADO que se puede lograr con el 20%
del esfuerzo requiere un TIEMPO CORTO que se fija arbitrariamente pero
con mucho CRITERIO (se necesita experiencia y olfato político).
El primer Timebox establece entonces el resultado relevante que debe
obtenerse dentro del lapso de tiempo fijado (de 4 a 6 meses para el primer
Timebox, los posteriores pueden ser inclusive más cortos) y la necesidad
de que todos los participantes en el proyecto trabajen en equipo
focalizados en la obtención de ese primer resultado. Si se encuentran
problemas en el camino es preferible negociar la definición y
caracterización del resultado que negociar el tiempo fijado. Por eso se
llama Timebox, porque es preferible negociar con toda transparencia el
alcance que el tiempo. Un resultado, aunque sea parcial, es necesario para
dar un golpe de motivación, pero hay que manejar el tema con absoluta
transparencia.
Lo más seguro es que para lograr el primer resultado de negocios sea
necesario organizar la metodología de implantación para privilegiar
conjuntos transversales de funcionalidad en lugar de la secuencia de
módulos tradicional. También será necesario reorganizar la capacitación
para orientarla a dar a conocer cuál es la forma de trabajar en equipo para
lograr dicho resultado. El aprendizaje de la operación de la Aplicación y su
funcionalidad cobrará mucho más sentido.
El primer Timebox puede alcanzar objetivos de negocios más rápidamente
si ex profeso se omite la excelencia de las metas iniciales privilegiando los
resultados rápidos, siempre que haya un compromiso y un entendimiento
por parte de todos los involucrados de que el mejoramiento (proceso
posterior) se va a hacer cargo de los bordes rugosos que se van dejando
en el camino. La excelencia siempre es una meta de segundas derivadas,
del 20% del resultado que consume el 80% del tiempo. Requiere más
profundidad de análisis e inclusive prueba y error7.
El segundo Timebox no es simplemente una continuación que parte
después del primero. El equipo de proyecto debe enfrentarlo y reevaluarlo
para capitalizar en el segundo Timebox, las cosas aprendidas durante el
primero. El hecho de que se produzcan cambios relevantes en las
especificaciones del proyecto no debe considerarse una deficiencia o una
debilidad del equipo de trabajo, más débil es que no haya habido
aprendizaje y que no cambien las especificaciones para reflejarlo.
Se aprende mucho del 20% del esfuerzo para lograr el 80% del resultado
y es esencial capitalizar este conocimiento dentro del mismo proyecto. Si
hay que “deshacer” algo de lo que ya se hizo es preferible hacerlo en este
momento que al final del proyecto cuando ya se ha construido todo el
resto sobre ese elemento insatisfactorio. No hay que demonizar la práctica
de reformular funcionalidad.
7
La excelencia es indispensable como meta pero esta nunca se logra.
Utilizar “Talleres” para la Ingeniería de Requerimientos
Cuando se acercan las personas de Informática a los usuarios a
preguntarles por sus requerimientos de información, dichos usuarios “le
sacan punta al lápiz” y producen una larga lista de necesidades. Y todas
son particulares y esenciales para su trabajo, no sirve el informe que tiene
una columna adicional que otro usuario solicitó.
La recomendación: es preferible organizar talleres con participación de
varios usuarios, inclusive de áreas diferentes, para levantar
requerimientos. Por arte de magia se produce una racionalización de las
necesidades. Unos a otros se corrigen (algo que no puede hacer el
profesional en informática pues no está empoderado para hacerlo) y se
enseñan unos a otros (tampoco la enseñanza sobre el negocio se acepta
por parte del profesional de informática) y el grupo termina aceptando un
mínimo común múltiplo que le sirve a todos.
El tema es complicado: “la construcción de la especificación de
requerimientos es inevitablemente un proceso iterativo… la tarea no puede
definirse por medio de una simple progresión a través de, o relación entre,
adquisición, expresión, análisis y especificación. Los requerimientos
evolucionan a un paso desigual y tienden a generar requerimientos más
extensos a partir de los procesos mismos de definición”8.
El uso de talleres ayuda este proceso pero deben contar con un buen
facilitador. Son una herramienta muy poderosa, pero hay que advertir que
tampoco es un ejercicio trivial. Si no se tiene experiencia moderando
grupos de discusión se pueden presentar problemas.
Metodología DoRCU para la Ingeniería de Requerimientos M.
Griselda Báez, Silvia I. Barba Brunner Instituto Superior Politécnico "José Antonio
Echeverría", La Habana, CU; Facultad de Ciencia y Tecnología, Universidad Autónoma de
Entre Ríos, AR
8
El Rol de la Gerencia es motivar
Algunas empresas consultoras hablan de “Change Management”
(Administración del Cambio) pero no hemos visto que ese movimiento
impacte la metodología con que se sigue vendiendo y poniendo a funcionar
Aplicaciones. La Administración del Cambio no es un proyecto
independiente del proyecto de implementación de un nuevo Sistema de
Información. Es consustancial y es parte del mismo. El tema es extenso y
sólo se aborda aquí en forma muy resumida. Lo más relevante es que el
cambio no debe ser “empujado” por la tecnología ni por la implementación
de nuevos procesos, el cambio deber ser “tirado” por las personas a
quienes afecta. Y ¿cómo se logra esto?, pues obviamente motivando a las
personas.
Ni la tecnología ni nuevos procedimientos motivan a las personas, al
contrario. Lo que más llama la atención es que hoy día todas las
metodologías para implementar sistemas de información basados en TI
mencionan que se requiere el compromiso de la Gerencia General.
Asimismo, ningún gerente lo niega, todos aducen que asumen su rol y su
compromiso; el problema es que esto se interpreta como que el Gerente
tiene que ejercer autoridad y ser firme para que los participantes en los
proyectos se sientan obligados a llevar a cabo las tareas que se les
encargan.
Esa es una mala interpretación, más que proyectar su autoridad se
necesita que los gerentes comprendan los cambios en roles y
responsabilidades que se requieren y que los facilite reconfigurando
incentivos. Un Sistema de Administración del Mantenimiento no ayuda al
mantenedor a hacer mejor su trabajo. Las Órdenes de Trabajo
“computarizadas” son una carga burocrática y los sistemas formalizan
obligadamente los procedimientos para solicitar herramientas, repuestos e
información y para el registro de todos los costos en que incurre el
proceso. También debe registrarse información relativa a la tarea misma
de mantenimiento que se lleva a cabo y otras observaciones que son
esenciales para la Administración del Mantenimiento.
Pero ocurre que al mantenedor, como parte del proyecto, no se le modifica
formalmente su rol, no se le prepara e incentiva adecuadamente para que
perciba que esta nueva tarea es tan valiosa como la tarea misma de
mantener el equipo funcionando y que tiene que llevarla a cabo con
calidad. El Gerente se necesita aquí comprendiendo y participando en la
reconfiguración de los incentivos de los mantenedores y midiendo y
recompensando el trabajo de calidad que los obligará a interactuar con el
sistema de información; sin ese registro no puede haber racionalización
del mantenimiento, tarea gerencial de gran trascendencia para la
empresa. Lo que el Gerente debe hacer entonces es liderar (a su nivel) el
acceso a los nuevos niveles de excelencia operacional que ahora tiene la
empresa y lograr que todos se sientan partícipes de los nuevos y mejores
resultados de negocios.
Este último punto es muy importante: el Gerente General se satisface con
los grandes números de los Estados Financieros y formula metas a los
niveles de gerencia de área. Luego estos hacen lo mismo con sus áreas
formulando metas a los niveles operativos. Pero si los sistemas de
información no permiten un análisis integrado que parta de los niveles más
agregados de datos bajando (“dril down”, “perforando para explorar”)
hasta los datos atómicos del sistema en forma continua, ininterrumpida,
no va a existir sincronización ni alineamiento estratégico en esa
organización.
El Rol de la Inteligencia de Negocios
Business Intelligence es una plataforma tecnológica y de procesos que
ofrece soporte a la obtención interactiva de información a partir de datos y
al desarrollo de conocimientos, porque también facilita el análisis de dicha
información. ¿Por qué es relevante tomar en consideración el BI dentro de
un proyecto que involucra una aplicación transaccional básica como un
ERP o un CRM?
Fundamental: el foco de dichos proyectos suele ser el soporte a los
procesos, a la operación en sí, sin tomar en consideración que
posteriormente la empresa va a necesitar BI. Entonces la base de datos
típicamente contiene solo el grado de caracterización de los eventos y las
transacciones indispensable para completar los procesos de principio a fin,
pero no para analizar y descubrir las oportunidades que se le ofrecen a la
empresa para trabajar sobre sus procesos y mejorar su rendimiento.
Tampoco podrá con facilidad detectar la forma en que se pueden
contrarrestar las amenazas externas.
Cuando se implementa un CRM (Customer Relationship Manager) para dar
soporte al proceso comercial, el no tomar en consideración el rol que
puede jugar posteriormente la Inteligencia de Negocios producirá una base
de datos débil en inteligencia de mercado. Con ausencia de atributos de
los datos que faciliten el fortalecimiento de la gestión comercial. Estos
atributos no son necesarios para el ejercicio operativo y por eso se dejan
de contemplar. Además, se le “complica menos” el proyecto al consultor a
cargo de la implantación y así protege su margen de negocios.
Si lo que se implementa es un ERP, la base de datos contable va a
contener pocos atributos asociados a los costos y a los gastos y el ejercicio
posterior de racionalización va a tener que apoyarse en medidas poco
“científicas”, basadas en hipótesis que no se pueden verificar.
El Nuevo Plan de Fases Metodológico
La Organización que quiera tomar en serio algunas de las
recomendaciones que se hacen en este ensayo debe reformular el Plan de
Fases Metodológico con que aborda los Proyectos que involucran TI (ya no
son proyectos de Informática, son Proyectos de Negocios que facilitan la
obtención de mejores resultados). Lo más importante es formular y
controlar los objetivos del proyecto (objetivos de negocios) y establecer
restricciones de tiempo, lo demás va a ir acomodándose solo.
La funcionalidad Informática completa nunca es imprescindible para
obtener el 80% de los beneficios con el 20% del esfuerzo, pero este
resultado (parcial) estimula y enseña algo muy importante: el
conocimiento de cómo lograr el 20% restante que consiste en el lustre del
pastel.