Implementación de Paquetes: Sorpresas al Abrir el Paquete

Título: Implementación de Paquetes: Sorpresas al Abrir el
Paquete
Área: Implementación de Paquetes de Software/Software ERP
Grupo: Docente
Autor: Lic. Pablo
[email protected]
Alejandro
Corral,
Tecnología
de
la
Información,
Resumen: Una de las opciones más comunes a las que las empresas recurren
a la hora de implementar nuevas aplicaciones de software es la
implementación de paquetes. Sin embargo, a pesar de sus claras ventajas,
como un menor costo de desarrollo, menores tiempos de implementación,
mayor seguridad, implementación de mejores prácticas del mercado, etc., la
implementación de paquetes, luego de más de 10 años de furor, está dando
lugar a nuevas opciones. Esto no es debido tanto a la evolución natural del
desarrollo de software como a las serias limitaciones con las que se han
encontrado las empresas que se han embarcado en su implementación
Palabras Claves: Paquetes de Software, Cadena de Valor, Procesos
Estandarizables, Sorpresas, 80% de Cobertura
Implementación de Paquetes: Sorpresas al Abrir el Paquete
Introducción
Una de las opciones más comunes a las que las empresas recurren a la hora
de implementar nuevas aplicaciones de software es la implementación de
paquetes. Sin embargo, a pesar de sus claras ventajas, como un menor costo
de desarrollo, menores tiempos de implementación, mayor seguridad,
implementación de mejores prácticas del mercado, etc., la implementación de
paquetes, luego de más de 10 años de furor, está dando lugar a nuevas
opciones. Esto no es debido tanto a la evolución natural del desarrollo de
software como a las serias limitaciones con las que se han encontrado las
empresas que se han embarcado en su implementación. Entre estas
dificultades se pueden encontrar desde fracasos rotundos (con el resultado
final del abandono del proyecto luego de varios años sin lograr terminarse),
excesos de costos (que pueden ir a más del 100% de variación respecto de la
estimación original) y graves problemas de mantenimiento (con importantes
costos ocultos). Esto es debido a una importante limitación de los paquetes de
software, fruto de su propia naturaleza de paquete, que no fueron previstos por
las empresas a la hora de planificar, tanto la compra como el proyecto de
implementación. Comprender la natural limitación de los paquetes de software,
tanto como comprender claramente los requerimientos funcionales que el
paquete debe satisfacer, facilita la gestión del proyecto y aumenta las
posibilidades de éxito.
La inversión en TICs y las ventajas competitivas
Las organizaciones se enfrentan a distintos planteos a la hora de decidir la
implementación de soluciones de software. Como en toda inversión, las
organizaciones esperan obtener beneficios de sus inversiones en tecnología de
la información que les permiten aumentar las ventajas competitivas que tienen
respecto de sus competidores. Es claro que existen dos tipos de inversiones,
aquellas que permiten diferenciarse de la competencia y aquellas que permiten
mejorar la productividad, al reducir los costos o implementar procesos más
eficientes. Tal cual plantea Guillermo Tricoci en su libro Las TICs y el
Conocimiento1, sólo las inversiones en diferenciación (algo que solo la empresa
posee, pero no su competencia, y que no es fácilmente obtenible por ella)
permiten obtener ventajas competitivas sustentables, mientras que las
inversiones en productividad (mejoras en costos o mayor eficiencia productiva)
son fácilmente imitables por la competencia y, en consecuencia, igualadas en
el corto plazo. De todas maneras, las organizaciones necesitan invertir en
productividad como requisito mínimo, innovando o imitando a la competencia.
Las inversiones en TICs no escapan a estas conclusiones, pudiendo
encontrarse inversiones que permitan bajar los costos o aumentar la
productividad de los procesos por un lado, e inversiones en TICs que permitan
innovar y diferenciar a las organizaciones de sus competidores. Procesos de
producción, estrategias comerciales, líneas de producto novedosas pueden
obtenerse de inversiones en TICs.
1
Las TICs y el Conocimiento – Un enfoque económico y de negocios - Página 73
Página 2
Implementación de Paquetes: Sorpresas al Abrir el Paquete
La Cadena de Valor
Porter2 estableció a mediados de los 80 que las empresas se organizan en
función de la creación de valor para sus clientes, desarrollando distintos
procesos que se proponen crear valor. Como contraposición Porter identifica
determinados procesos críticos que, si bien no contribuyen a la creación de
valor, son necesarios para que la empresa pueda funcionar. Los procesos que
agregan valor están identificados con abastecimiento, producción y ventas,
mientras que los necesarios, pero que no agregan valor, son las funciones
centrales de soporte, contabilidad, finanzas, recursos humanos y sistemas de
información. Dichos procesos soportan la creación de valor de los otros3.
Es posible establecer que los procesos de creación de valor le otorgan una
ventaja competitiva a las organizaciones, ya que a través de ellos es posible
entregar un valor diferenciado al cliente. Mientras tanto, los procesos de
soporte son una función de supervivencia.
Las Necesidades
Una de las opciones más comunes a las que las empresas recurren a la hora
de implementar nuevas aplicaciones de software es la implementación de
paquetes. Existen claras ventajas para ello, como un menor costo de
desarrollo, menores tiempos de implementación, mayor seguridad,
implementación de mejores prácticas del mercado, utilización de estándares
probados de programación, utilización de sólidas herramientas de desarrollo,
implementación de soluciones integradoras y globales, en comparación con el
desarrollo de aplicación domésticas (In-House). Un elemento clave que
determina que los paquetes de software sean una opción “obligada” de gran
cantidad de empresas alrededor del mundo es el hecho de tercerizar el proceso
de mantener el software actualizado y adecuado al nivel tecnológico imperante
a lo lardo del ciclo de vida del software. Es decir, el proveedor del paquete se
encarga de actualizar el software a lo largo de su vida útil, manteniéndolo al
corriente de los nuevos desarrollos tecnológicos4.
La primera etapa en el proceso de implementación de paquetes es la selección
del paquete. Distintos proveedores, distintas soluciones y distintos
requerimientos hacen que la identificación del proveedor apropiado sea muy
dificultosa. Para poder comparar claramente las opciones disponibles, las
organizaciones comienzan su proceso de selección identificando las
necesidades y la funcionalidad esperada (requerimientos). Dado que en
ocasiones, múltiples sectores requieren diferentes funcionalidades, el trabajo
de relevamiento de requerimientos es arduo y necesita el uso de una
metodología que permita estandarizar los requerimientos de todos los grupos.
Se deben tener en cuenta distintos tipos de requerimientos:
1) Funcionales: que funciones debe proveer el software requerido
2
3
4
Competitive Advantage
Sistemas de Información Gerencial – Laudon & Laudon – Página 104
Andy Kyte - Customization: The Cost That Keeps on Costing
Página 3
Implementación de Paquetes: Sorpresas al Abrir el Paquete
2) Técnicos:
a. Requerimientos de hardware
b. Requerimientos de sistema operativos y software adicional
c. Requerimientos de seguridad
d. Requerimientos de escalabilidad, integración y performance
e. Requerimientos de soporte y mantenimiento
f. Facilidad de uso
g. Etc.
Una vez identificados los requerimientos, los responsables de selección del
paquete preparan un documento estandarizado para que los distintos
proveedores lo completen con su propuesta, tanto técnica como económica. El
desarrollo de este documento estándar es de gran importancia ya que facilita el
proceso de comparación de las ofertas de los distintos proveedores.
Los equipos responsables de la selección del paquete saben que no es lógico
esperar que el paquete cubra el 100% de los requerimientos. En general, se
habla de un aceptable 80% de cobertura y orientan el proceso de selección con
ese objetivo en mente5.
El Negocio de los Fabricantes de Paquetes
El negocio de los fabricantes de paquetes de software no es sencillo. Deben
desarrollar un producto que pueda ser comercializado a un mercado amplio,
para lo cual, debe poder desarrollar un software lo suficientemente flexible para
adaptarse a cualquier tipo de empresas. Esta flexibilidad está dada por el
concepto de configuración, es decir, proveer determinados parámetros que
puedan ser configurados a la medida de las necesidades de cualquier
empresa. Es esta característica de los paquetes de ser suficientemente
estándar como para ser comercializados a cualquier empresa, pero a la vez, lo
suficientemente configurable para ser adaptado a la medida de los
requerimientos específicos de una empresa en particular, la que encierra la
trampa de los paquetes de software6.
El Desarrollo de los Proyectos de Implementación de Paquetes
Una vez seleccionado un proveedor de paquetes de software, el gerente de
proyecto comienza a desarrollar el plan de implementación. Bajo el supuesto
del 80% de cobertura, el proyecto se planifica basado en la idea de
implementar el 80% de la funcionalidad de cobertura como está (as-is) y
desarrollar adaptaciones para cubrir el 20% restante.
En los proyectos de implementación de paquetes, la etapa de análisis se
focaliza principalmente en encontrar la brecha entra la cobertura y los
requerimientos establecidos. Es aquí donde se produce la primera gran
sorpresa: la brecha es mayor a la esperada. Esto se debe a dos factores
principales:
5
6
Andy Kyte - Idem
Andy Kyte - Idem
Página 4
Implementación de Paquetes: Sorpresas al Abrir el Paquete
1) Los requerimientos utilizados para la selección del paquete no fueron
bien estimados. Esto ocurre generalmente ya que los relevamientos
orientados a preparar la selección del paquete no son lo suficientemente
rigurosos como lo son los relevamientos llevados a cabo durante la
etapa de análisis. Los requerimientos encontrados en esta etapa,
generalmente no son cubiertos por el paquete.
2) El grado de cobertura es sensiblemente inferior al 80% en los
requerimientos utilizados para la selección del paquete. Esto es debido a
que los equipos de análisis están formados por usuarios claves del
negocio, con profundos conocimientos de sus procesos. Al comparar en
detalle la funcionalidad otorgada por el paquete con los requerimientos,
se pueden vislumbrar que la configuración no alcance para adaptar el
paquete a los requerimientos.
Es el grado de desacople del segundo grupo en donde se encuentra la gran
limitación de los paquetes de software. Los paquetes tienen un alto grado de
cobertura en muchos procesos estándarizables, al incorporar las llamadas
mejores prácticas del mercado. Pero estas mejores prácticas aplican a los
procesos identificados como soporte en la cadena de valor y no a los procesos
que agregan valor. Como los procesos que agregan valor son los que le
proveen la ventaja competitiva a las organizaciones, es muy difícil que puedan
(o quieran) ser estandarizados y adaptarse a los procesos inherentes del
paquete de software. Los paquetes de software brindan gran cobertura (incluso
mayor al 80%) en los procesos de soporte y muy baja (siempre menor al 80%)
en los procesos que agregan valor.
Una vez identificada la verdadera brecha, es en la etapa de diseño en donde se
tiene que encontrar una solución para la misma. Existen varias estrategias:
1) Adaptar los procesos de negocio de la empresa a los procesos basados
en mejores prácticas que están incluidos en el paquete de software. Esta
es la opción por la que más presiona la empresa proveedora del
paquete, ya que es la que menores riesgos y costos posee. Está opción
es también la que proponen los gerentes del proyecto, quienes tienen
que velar por el alcance, el tiempo y los costos del proyecto. Sin
embargo, esta es la estrategia menos satisfactoria para los usuarios y
Stakeholders del proyecto, quienes presionan por adaptar el paquete a
las necesidades y los procesos de la organización. Esta opción es
lógica, estandarizar el proceso de producción, de comercialización o de
relacionamiento con el cliente implicaría perder esa ventaja competitiva
que tanto les había costado conseguir.
2) Adaptar el paquete a los procesos de la empresa. Esta opción consiste
en modificar el paquete al máximo posible, pudiendo utilizarse varias
opciones:
a. Explorar todas las opciones de configuración al máximo, de
manera tal de explotar la funcionalidad incluida en el paquete.
b. Modificar el código del paquete. Esta opción siempre está
disponible para poder cerrar la brecha del 20%. Consiste en
modificar el código original del paquete de manera de brindar
funcionalidad no provista originalmente. Hay distintos propósitos
Página 5
Implementación de Paquetes: Sorpresas al Abrir el Paquete
para el cual se modifica el código, normalmente identificado con
la sigla FRICE: Formularios, Reportes, Interfaces, Conversiones y
Extensiones:
i. Formularios: Si bien los paquetes cuentan con una gran
cantidad de formulario modelo (facturas, remitos, recibos,
órdenes de compra, etc.) las organizaciones requieren sus
propios diseños. El desarrollo de formularios a la medida
de los requerimientos de cada empresa forma
normalmente para del 20%.
ii. Reportes: Este rubro es más controvertido que el anterior.
De la misma manera que con los formularios, los paquetes
cuentan con un sinfín de reportes estándar que proveen la
información básica que cualquier organización puede
requerir. Sin embargo, los usuarios son muy exigentes con
sus requerimientos de reportes y solicitan numerosos
cambios a los reportes estándar. Los paquetes cuentas
con poderosas herramientas para el desarrollo de reportes
Ad-hoc, muchas de las cuáles pueden ser utilizadas por el
usuario final. Este grupo también suele formar parte del
20%
iii. Interfaces: Las interfaces son programas que permiten
conectar el paquete con un gran número de aplicaciones
que posee la empresa, normalmente llamadas aplicaciones
Legacy. Es natural que deba hacerse código especial para
poder conectar distintos tipos de aplicaciones entre sí. Sin
embargo, dado que muchos paquetes del mercado forma
parte del grupo de los software conocimos como “software
integrado”, es decir, paquetes que cubren las necesidades
de las empresas de punta a punta de la cadena de valor,
es muy discutido si se deban realizar interfaces con
software Legacy o si se debiera reemplazar ese software
por el paquete, que está “naturalmente” integrado. En este
punto vuelve a ser crucial la concepción de diferenciación:
muchos procesos son tan específicos que requieren de
software a medida para poder automatizarse. Cambiar por
los procesos incluido en el paquete estándar puede
significar perder ese factor de diferenciación, por lo que los
usuarios suelen resistirse mucho a su reemplazo. Es por
ello que las interfaces suelen estar en parte incluidas en el
20% prevista y en parte ser un excedente respecto de ese
grupo.
iv. Conversiones: Desacoplar un sistema viejo y reemplazarlo
por un sistema nuevo requiere mover una gran cantidad de
datos del sistema viejo al nuevo. Esta mudanza de datos
requiere modificar el formato de los datos en el sistema
viejo para que sea compatible con la estructura de datos
del nuevo sistema. Este proceso de manipulación y de
automatización de la carga se conoce como Conversión o
Migración y está previsto en todos los proyectos de
implementación, formando claramente parte del 20%.
Página 6
Implementación de Paquetes: Sorpresas al Abrir el Paquete
v. Extensiones: Este último grupo es el más controvertido.
Consientes de que el paquete no puede cubrir todas las
expectativas de todos los potenciales clientes, los
fabricantes de paquetes de software prevén la posibilidad
que se requiera modificaciones al código del mismo. Con
esta posibilidad se puede agregar:
1. Nueva funcionalidad
2. Nuevas pantallas
3. Nuevas tablas y campos en la base de datos
4. Cambiar el funcionamiento de funcionalidad estándar
Existen varias maneras de realizar estas adaptaciones
1. Salidas de Código: Con esta opción, los fabricantes
de paquetes crean una “puerta de entrada” en el
código estándar para que las empresas puedan
ampliar el código existente. Estas entradas
consisten en funciones vacías con determinados
parámetros de entrada y salida al código principal.
Esto permite genera cierta unidad al obligar al
programador a respetar las variables de entrada al
código y las variables que devuelve a él. De esta
manera se puede agregar funcionalidad de una
forma menos disruptiva que si se creara código de
cero.
2. Clonar parte del código estándar y hacer
modificaciones de manera tal de obtener
funcionalidad nueva o que la funcionalidad cambie
para adaptarse a los procesos de negocio de la
empresa.
3. Crear nuevo código de cero, para funcionalidad que
no existe o para integrar un sistema Legacy al
paquete
4. Crear nuevas tablas y campos en la estructura de la
base de datos y modificar los programas para que
puedan acceder/modificarlos.
5. Modificar el código estándar. Esta es la opción más
disruptiva de todas ya que las empresas que
compran el paquete modifican el código original. Los
proveedores de paquetes tratan de limitar al
máximo, sino prohibirlo ya que genera un gran
riesgo de fallos del paquete en su conjunto.
De todas las opciones mencionadas las extensiones son las que suelen
superar el 20%. Es decir, cuando las empresas deciden hacer modificaciones
sustanciales al código para poder representar sus procesos de negocios que le
otorgan ventajas competitivas, superan ampliamente el 80% de cobertura y
empiezan a transformar el paquete estándar en lo más parecido a un software
a medida. Se podría hablar de grados de adaptación, que oscilan en un 20% a
más del 50%, es decir, más del 50% de la funcionalidad instalada fue
desarrollada a medida de las necesidades modificando el código del paquete
original.
Página 7
Implementación de Paquetes: Sorpresas al Abrir el Paquete
Es en este momento en que las variaciones del plan de proyecto se empiezan
a acentuar, al requerirse más desarrolladores, más tiempo y más dinero.
El Mantenimiento
Es muy probable que los Stakeholders se pongan de acuerdo con los sponsor
del proyecto y se consigan fondos adicionales. Después de todo, el objetivo del
proyecto de implementación es mejorar los resultados de la empresa, por lo
que, dañar seriamente las ventajas competitivas al implementar procesos
estándares que todas la competencia tiene (no nos olvidemos que los paquetes
son una verdadera moda y no hay empresa grande que no tenga uno) no es
una opción. Puestos a escoger, hay dos opciones: Abortar el proyecto, en el
que ya se debe tener una gran inversión o adaptar el paquete a las
necesidades “reales” de la organización.
Es en este momento en donde se siembra la semilla de grandes problemas a lo
largo del ciclo de vida del paquete. Las mejoras y extensiones hechas al código
del paquete ponen en riesgo el proceso de mantenimiento por dos grandes
motivos:
1) Durante el proceso de mantenimiento, las distintas áreas funcionales se
van familiarizando con la funcionalidad provista por el paquete (y por la
añadida con las extensiones) y van requiriendo nuevas cosas. Si los
nuevos requerimientos se pueden cubrir con funcionalidad estándar a
través de la configuración, perfecto. Si no, los usuarios vuelven a pedir
que se usen extensiones. Como ya se hizo una vez durante la
implementación original, y si se cuenta con los fondos en el presupuesto
de mantenimiento, el área de soporte de aplicaciones vuelve a hacerlo.
Esto es agravado por la ausencia en muchas organizaciones de claras
políticas de gobierno y de gestión de cambios. A diferencia de las
extensiones hechas durante el proyecto original de implementación, los
cambios durante la etapa de mantenimiento suelen hacerse con poca
visión de conjunto y con poca rigurosidad metodológica (que incluye
pruebas incompletas, falta de documentación y poco apego de los
estándares de codificación).
2) Dado que una de las grandes ventajas del paquete consiste en que el
proveedor se encarga de mantener el paquete actualizado a lo largo de
su vida útil, cada 2 o 3 años, los proveedores presentan nuevas
versiones para:
a. Solucionar problemas detectados a lo largo de toda su cartera de
clientes. Cada cliente hace un uso particular del software y va
detectando distintos errores. El proveedor provee soluciones
(llamadas comúnmente “parches”) para ellos para toda su base
de clientes. Al liberar una nueva versión, incluye todos esos
“parches” en una versión nueva y mejorada.
b. Adaptar la tecnología a las nuevas tendencias. La evolución de
los sistemas operativos, el hardware, la tecnología de las bases
de datos y de los lenguajes de programación hacen que las
empresas de paquetes deban mejorar su software para estar
actualizados y ser competitivos.
Página 8
Implementación de Paquetes: Sorpresas al Abrir el Paquete
c. Introducir nuevas funcionalidades. Fruto de su interacción con los
clientes, las empresas de paquetes van introduciendo nueva
funcionalidad (nuevas “mejores prácticas”) para poder competir
mejor y ampliar su base de clientes.
Las nuevas versiones deben ser implementadas sin prisa, debido a que al
proveedor no le conviene seguir manteniendo una versión vieja del software
sino invertir en el desarrollo de las nuevas de manera de mantener su
competitiva posición en el mercado de los fabricantes de paquetes de software.
Es aquí en donde aparece la segunda gran sorpresa. El proyecto de
implementación de una nueva versión de un paquete, conocido como Upgrade,
suele ser mucho más complejo de lo previsto. El supuesto sobre el que se
construyen los paquetes y sus nuevas versiones es que, si se ha implementado
tal cual es (es decir, sin ningún tipo de extensiones), el proceso de Upgrade
debería ser “plug and play” es decir, instalar y a usar. Sin embargo, el alto
grado de adaptación del paquete (que supera el previsto 20%) hace que la
nueva versión no sea compatible. Esto implica que el proyecto de Upgrade
consista en un nuevo proyecto de implementación en el cuál hay que
reconstruir toda la funcionalidad añadida en la nueva versión. Esto es agravado
por la alarmante falta de documentación de las extensiones hechas luego de la
implementación original por el equipo de soporte de aplicaciones.
Es cierto que mucha funcionalidad que faltaba en la versión anterior, que fue
añadida ad-hoc durante el proyecto de implementación original, ahora esté
disponible en la nueva versión. Pero en el mejor de los casos, significa un
tiempo adicional de configuración, de pruebas y de capacitación para
reemplazar la funcionalidad añadida mediante las extensiones.
Las organizaciones se encuentran que sus presupuestos previstos para
mantenimiento se incrementan notablemente con el esfuerzo de Upgrade. En
muchos casos, las empresas eligen no pasar a la nueva versión hasta último
momento. Esto tiene un costo adicional, ya que los proveedores de paquetes
suelen cobrar tarifas especiales por el mantenimiento de versiones viejas,
como ya se ha explicado.
El saldo final de todo el proceso de implementación del paquete en una gran
mayoría de empresas de primera línea consiste en un costo total de propiedad
que supera ampliamente el originalmente estimado en la etapa de concepción
del proyecto. A lo largo del ciclo de vida del paquete, las empresas se
encuentran que el costo total del paquete supera ampliamente los beneficios
esperados, incluso en aquellas empresas en las que los beneficios obtenidos
fueron mayores a los originalmente estimados.
Conclusiones
La falta de experiencia de los equipos de selección e implementación de
paquetes ha hecho que una importante mayoría de las implementaciones
hayan fracasado. El aprendizaje desarrollado a lo largo de estos años de
reinado de los paquetes como la solución de software preferida de las grandes
empresas, hace que hoy por hoy las empresas desconfíen de los paquetes y
vuelvan a ver al software a medida como una opción altamente atractiva. Sin
embargo, no todo es negativo a la hora de utilizar un paquete de software, si se
Página 9
Implementación de Paquetes: Sorpresas al Abrir el Paquete
tiene en cuenta algunas cuestiones antes y durante y después del proyecto de
implementación de paquetes:
1) Tener en cuenta la gran limitación de los paquetes de software.
Comprender claramente qué funcionalidad estandarizar y cuál no es la
clave para poder sacar el mejor provecho del paquete. Pretender
estandarizar aquellos procesos que brindan a la organización su ventaja
competitiva sobre sus competidores es claramente una mala decisión. El
problema muchas veces reside en no conocer cuáles son. Como ya
hemos visto, los procesos de soporte son los más fácilmente
estándarizables. Para los demás procesos se pude optar por desarrollar
software a medida y conectarlo mediante interfaces o realizar
extensiones sobre el software del paquete.
2) El 80% de cobertura es irreal. Si bien es una idea atractiva desde el
punto de vista comercial de las empresas que desarrollan paquetes,
hemos visto que no era así. No existe un porcentaje ideal de cobertura.
Los equipos de selección de software tienen que comenzar por
comprender claramente los requerimientos de la organización, que
procesos pueden ser estandarizables y a partir de allí comenzar su
búsqueda. 80%, 70% o 50% pueden ser perfectamente aceptable si se
tienen presente desde el comienzo del proyecto. Saber que se tiene que
cubrir una brecha del 50% es vital a la hora de planificar el proyecto.
3) El proceso de selección de software tiene que comenzar con un
profundo análisis de los requerimientos. Esta información es la base
para construir el documento de petición de oferta (RFP – Request for
Proposal del inglés). Este documento es esencial a la hora de elaborar la
comparación de las ofertas y para seleccionar el mejor candidato.
4) Gobierno y gestión de cambio. Una vez que el paquete esta productivo,
es fundamental contar con un proceso de gobierno y de gestión de
cambios que determine qué cosas cambiar y cómo implementarlas en
productivo. Es muy común que los usuarios vayan aprendiendo las
limitaciones del paquete y vayan requiriendo cambios o mejoras. Pero
no siempre las mejoras pedidas por lo usuarios proveen valor a la
cartera de aplicaciones de la organización. Sin embargo, el lobby y la
presión de distintos grupos de usuarios hacen que se implementen
mejoras que sirven a ese grupo en particular pero que brindan valor al
conjunto de aplicaciones. Se ha invertido en cambios que no maximizan
el valor de la cartera. Contar con un claro proceso de gobierno que haga
cumplir el plan de sistemas se hace esencial.
5) Metodología. Es muy común que las mejoras realizadas durante la etapa
de mantenimiento no sigan las mejores prácticas de desarrollo de
software ni los estándares de programación. El resultado final: código
que no tiene buena performance, mal documentado y numerosas caídas
del sistema al implementar código mal probado. A su vez, estas mejoras
no documentadas van transformado al paquete en algo muy distinto al
implementado originalmente por acumulación de pequeñas mejoras. Es
decir, va sumando a la hora de complicar el proceso de cambio de
versión.
Página 10
Implementación de Paquetes: Sorpresas al Abrir el Paquete
En resumen, claras pautas de gobierno, un plan de sistemas alineado con el
plan de negocios, metodología de desarrollo de software ayudan a simplificar
el mantenimiento del paquete y reducir el TCO. Por otro lado, conocer las
limitaciones de los paquetes software, entender los procesos que agregan valor
y aquellos que son de soporte y entender qué puede aportar un paquete a la
organización se transforman en las claves para el éxito de la implementación
de paquetes.
Finalmente, no se trata de paquete vs software a medidas. Cada organización
debe encontrar la mezcla adecuada que le permita maximizar su cartera de
aplicaciones, agregando valor al negocio.
Página 11
Implementación de Paquetes: Sorpresas al Abrir el Paquete
Bibliografía
• Kyte, Andy. Customization: The Cost that Keeps on Costing. Gartner
Research. (March 2009)
• Laudon & Laudon. Sistemas de Información Gerencial. Prentice Hall.
Décima Edición (2008)
• Porter, Michael. Competitive Advantage. Free Press (1985)
• Tricoci Guillermo. Las TICs y el Conocimiento – Un enfoque económico y
de negocios- Ediciones Cooperativas. Primera Edición (2008)
Página 12