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 pablo.corral@kcc.com 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
