ESTIMACIÓN DEL ESFUERZO DE IMPLANTACIÓN EN SISTEMAS ERP

Transcripción

1 Revsta de Procesos y Métrcas de las Tecnologías de la Informacón (RPM) ISSN: VOL. 2, Nº 1, Marzo 2005, 3-16 Asocacón Española de Sstemas de Informátcos (AEMES) ESTIMACIÓN DEL ESFUERZO DE IMPLANTACIÓN EN SISTEMAS ERP Alca Cano, Javer Tuya Unversdad de Ovedo, Departamento de Informátca Campus de Vesques, s/n Gjón, Span E-Mal : alca.cano@copa.org, tuya@unov.es Abstract: The mplementaton of Enterprse Resource Plannng systems (ERP) can not be undertaken by usng the same technques that for the development of software snce ERP systems are already developed applcatons that are mplemented n an organzaton by means of parameterzaton and customzaton. Because of that, the classcal measurement methods are not fully applcable to the estmaton of the cost and effort of ths knd of projects. Ths artcle presents an estmaton model of ERP mplementatons that takes nto account the characterstcs of the standard package (functonal and parameterzaton transactons), data mgraton, customzaton, reportng, as well as the user tranng. Ths model ntegrates functon ponts and other models and adjustment factors that are used when other methods are not applcable. Resumen: Los proyectos de sstemas de Planfcacón de Recursos Empresarales o ERP (Enterprse Resource Plannng) no pueden acometerse con las msmas técncas utlzadas para el desarrollo de software puesto que se trata de aplcacones ya desarrolladas que son mplantadas en una organzacón medante su parametrzacón y personalzacón. Por ello, los métodos de medcón cláscos no son del todo aplcables para la estmacón del coste y esfuerzo de este tpo de proyectos. En este artículo se elabora un modelo para la estmacón de mplantacones ERP que tene en cuenta las característcas del paquete estándar (transaccones funconales y de parametrzacón), la mgracón de datos, la personalzacón de la aplcacón, la explotacón de nformacón, así como la formacón a los usuaros. El modelo ntegra la utlzacón de puntos de funcón y otros modelos y factores de ajuste para las característcas en las que los métodos actuales no son aplcables. Palabras clave: Estmacón de proyectos, Puntos de Funcón, ERP, SAP R/3 1. INTRODUCCIÓN La mplantacón de un software ERP (Enterprse Resource Plannng - Planfcacón de Recursos Empresarales) en una organzacón es un proyecto de gran envergadura técnca y económca y de alto mpacto en las estructuras de la empresa [Everdngen et. Al, 2000]. Las cfras que se manejan en el mundo de las mplantacones ERP, y en partcular, de SAP R/3 parecen mpresonantes. Un estudo de Meta Group [META, 2000] sobre el coste de las mplantacones de software ERP analzó los proyectos de 63 organzacones de varos tamaños, ofrecendo, entre otras, las sguentes conclusones: Este trabajo ha sdo fnancado por el Mnstero de Educacón y Cenca dentro del Plan Naconal de I+D+I, proyecto TIN C03-02 (IN2TEST). 3

2 El tempo medo de mplantacón de un software ERP es de 23 meses, pasando dos años y medo desde el comenzo del proyecto hasta que se empezan a cuantfcar benefcos El coste total de propedad de una mplantacón se mueve en torno a $15 mllones, ncluyendo dos años y medo de costes post-mplantacón. Las dferencas entre dferentes paquetes varan entre $4 y $40 mllones Los proyectos exceden los costes planfcados hasta en un 50% de lo ncalmente prevsto. El 90% de los benefcos cuantfcables se asocan a la reduccón de costes. Aunque las organzacones partcpantes en el estudo muestran un grado de satsfaccón aceptable después de la mplantacón del software ERP, tambén afrman haber encontrado problemas. Los dos fallos de más gravedad manfestados por el estudo son consderar que el resultado fnal "no es lo prometdo", que no se corresponde con lo planfcado al comenzo del proyecto, y que exste una mportante dstanca en rendmento, usabldad y caldad entre el entorno de desarrollo utlzado durante la mplantacón y el entorno productvo. Estas cfras proporconan una dea de lo que sgnfca para una organzacón entrar en un software ERP, y de la mportanca que debera darse a una estmacón objetva y sensata del esfuerzo necesaro para tener éxto. Lamentablemente, en muchas ocasones estos proyectos se ven como algo puramente nformátco y no se les dota de los recursos n del enfoque adecuados [Austn y Nolan, 1999]. Un campo poco explorado es el de en la estmacón y medcón del coste de la mplantacón de un software ERP. El térmno "coste" no se refere exclusvamente al desembolso económco que requere un proyecto así, sno a la estmacón del esfuerzo en recursos técncos y humanos, en conocmento y en tempo necesaros para llevar a puerto un cambo tecnológco de esta envergadura. Entre las técncas de medcón y estmacón del coste comúnmente utlzadas [Dolado y Fernández, 2000], se encuentran las de puntos de funcón. Sn embargo, éstas técncas se referen al desarrollo de software y no encajan del todo en la dosncrasa del ERP que, como software propamente dcho, ya está desarrollado y cuya mplantacón en un clente fnal ha de contemplarse más ben desde la óptca del mantenmento. Aunque el responsable del proyecto ERP tuvera a su alcance herramentas práctcas de medcón y estmacón del coste de la mplantacón para permtrle admnstrar los sempre escasos recursos de forma óptma, nada de esto es útl s no se tene claro qué se ha de medr. En la práctca muchos drectores y jefes de proyecto planfcan el proyecto y asgnan los recursos de forma ntutva, utlzando su conocmento de las organzacones y su experenca preva. La pregunta que se plantea es s exste una técnca o combnacón de técncas que susttuyan a la ntucón y lo más mportante, s pueden aplcarse con éxto. Para el responsable de un proyecto ERP la prmera necesdad es la vsualzacón global del proyecto, y su descomposcón en áreas, cada una de las cuales estará compuesta de un conjunto de puntos más o menos crítcos. Identfcados éstos, su nvel de crtcdad y el método de resolucón que mejor puede aplcárseles, se puede empezar a estmar el esfuerzo necesaro para ello y por tanto, sumando esfuerzos, calcular, medr, el coste del proyecto. El objetvo de este trabajo es en prmer lugar, dentfcar y delmtar el problema, analzando las partes en que se dvde un proyecto de mplantacón ERP y en concreto de SAP R/3, basada en la experenca en mplantacones en este entorno. En segundo lugar, recurrr a los trabajos sobre medcón y estmacón de software, tanto dentro como fuera del mundo ERP, para buscar métodos aplcables y proponer alternatvas allí donde se haya observado que las técncas exstentes no tenen valdez. El artículo está estructurado en las sguentes seccones además de esta presentacón: en la seccón 2 se repasan los trabajos relaconados con el tema del desarrollo y estmacón de las mplantacones SAP. La seccón 3 es una breve presentacón del marco general utlzado para la estmacón y srve de ntroduccón a las tres seccones sguentes, donde se profundza en la estmacón del esfuerzo para la mplantacón del sstema estándar (seccón 4), los desarrollos adconales (seccón 5) y la formacón de usuaros fnales (seccón 6). Fnalmente, en la seccón 7 se presentan las conclusones del trabajo y las líneas de trabajo futuro. 4

3 2. TRABAJOS RELACIONADOS A pesar del nterés que debera despertar el mundo ERP en la comundad centífca, no hay muchos trabajos publcados que relaconen la Ingenería del Software con los proyectos ERP. Sí que exsten numerosos lbros publcados por expertos de los propos fabrcantes de ERP o de las grandes consultoras que tratan sobre la gestón de proyectos ERP, la planfcacón o el control del resgo [Draeger, 1999], [Hquet et al., 1998], [Welt, 1999], orentados a los drectvos de IT que se enfrentan a la dreccón de un proyecto de este tpo, abordando la cuestón desde una perspectva práctca. Tambén se han publcado numerosos trabajos y lbros sobre los problemas recurrentes en los proyectos ERP [Davenport, 2000], [Stedman, 1999], [Dryden, 1998] aunque la mayoría de ellos no ofrecen solucones al respecto. En este sentdo es nteresante el trabajo de [Slater, 1998], que llama la atencón sobre cnco factores que en muchos proyectos recben tratamento margnal y que en realdad son parámetros crítcos de éxto o de fracaso: (1) Formacón de usuaros, (2) Integracón con terceros sstemas, (3) Mgracón de datos desde sstemas heredados, (4) Necesdades de reportng y análss de datos, y (5) Estmacón del tempo de consultoría. Este nteresante análss llama la atencón sobre dos puntos (mgracones y formacón) que habtualmente escapan a las nvestgacones en el campo de la medcón del software y que serán tratados más adelante. El hecho de que la formacón es un parámetro clave del proyecto es subrayado constantemente en numerosos artículos ([Wheatley, 2000], [Koch, 1996], [Chrste, 2000], [Stedman, 1998]). Se trata de una faceta tan vtal del proyecto que ha de ncorporarse a cualquer metodología o técnca de medcón que se ntente desarrollar. Como se verá más adelante, en general, este aspecto no es consderado en las nvestgacones, aunque exste algún estudo que propone metodología para tratar el problema de la resstenca al cambo, muy lgado a la formacón [Aladwan, 2001]. Relaconado ndrectamente con la formacón hay que ctar tambén la gestón del conocmento, la recoplacón y tratamento de toda la sabduría empresaral repartda de forma heterogénea y dspersa entre los membros de la organzacón [Stjn y Wensley, 2001]. Esta actvdad de aprendzaje de los procesos de negoco actuales de la organzacón es, de hecho, el punto de partda del proceso de mplantacón del ERP y necesta de un enfoque metodológco, como se ha empezado a desarrollar en los últmos años. En esta línea ha aparecdo el método IPP (Iteratve Process Prototypng) [Keller y Teufel, 1998] desarrollado por dos membros de SAP AG, que enfoca la mplantacón de SAP haca la defncón y formalzacón de los procesos de negoco (los requstos) y su modelado en SAP medante una técnca dscplnada de tres fases (obtencón, modelado y negocacón/valdacón) con proceso de refnamento en espral. Tambén exste un nteresante trabajo [Gess y Soltysak, 2000] que recoge el Método Dnámco de Desarrollo de Sstemas (DSDM) [Sapleton, 1997] y lo aplca a la mplantacón de SAP R/3. El DSDM aporta varos prncpos fundamentales que cumplr en un proyecto (compromso actvo del usuaro fnal y autordad del equpo de desarrollo, desarrollo teratvo e ncremental con entregas frecuentes y prueba ntegrada como parte del proceso, adecuacón a los procesos de negoco, reversbldad de los cambos). Desde la experenca se podría ndcar que estos prncpos pueden y deben aplcarse a de forma estrcta en una mplantacón de SAP: A partr de estos prncpos [Gess y Soltysak, 2000] elaboran una metodología que concde con el IPP de [Keller y Teufel, 1998] en varos puntos crucales: el enfoque del proyecto debe estar orentado a los requstos y procesos de negoco el desarrollo del proyecto ha de ser procedmental (defncón-mplementacónvaldacón) el modelo avanza de forma teratva e ncremental la cooperacón entre IT y las áreas funconales de la organzacón es fundamental. Algunas de las razones del fracaso de muchos proyectos SAP y de sus dfcultades nacen en la no aplcacón de estas metodologías (muy recentes, por otro lado). La nexstenca de un enfoque metodológco y formal en el proyecto nhablta desde un prncpo el ntento de dseñar alguna técnca de medcón [Teltumbde, 2000]. Como se afrmaba al comenzo de esta seccón exsten pocas líneas de nvestgacón abertas haca 5

4 la estmacón de proyectos SAP o ERP en general. Alguna consultora como QSM ha ntentado abrr camno en este sentdo [Ward, 2001], desarrollando un modelo de estmacón que nega la posbldad de utlzar métrcas cláscas como líneas de códgo (LOC) o puntos de funcón (PF) y defne una "undad de medda" específca para los proyectos ERP. En concreto para SAP utlza el número de transaccones de parametrzacón usadas para poner el sstema en funconamento. A partr de este tamaño base añade las líneas de códgo ABAP desarrolladas para susttur o complementar funconaldad no soportada por el estándar y pondera el resultado con unos pesos que tenen en cuenta factores ambentales como la establdad de la versón mplantada, el alcance geográfco o la complejdad de la mgracón de datos. Sn embargo este modelo es dscutble en certos aspectos debdo a que no tene en cuenta más que las transaccones de parametrzacón y no las funconales, no explca por qué tene sentdo sumar drectamente transaccones con LOC de ABAP, utlza LOC como undad de medda en un lenguaje 4GL, agrupa factores crítcos en una categoría genérca de complcacones ambentales y no hace referenca alguna al esfuerzo en la formacón). El alcance de este estudo se lmta a estmar el esfuerzo técnco del proyecto. En general, no se tene en cuenta que SAP es mucho más que un sstema nformátco, que camba la mentaldad y los hábtos de la organzacón [Brady et al., 2001], [Connolly, 1999]. Tal como se ndca en [Ward, 2001]: "el modelo no tendrá en cuenta reorganzacones del negoco o cambos de procedmentos que acompañen la mplementacón del paquete ERP, ya que no hay evdenca de que este esfuerzo sga los msmos patrones de comportamento que el proyecto de construccón del software". Por tanto, aunque nteresantes, las conclusones de este modelo tenen que ser por fuerza sesgadas, al no consderar la rengenería de procesos como el núcleo del proyecto. En esta msma línea de estmacón técnca del esfuerzo de mplantacón de SAP está [Francalanc, 2001]. Un artículo ntroductora a la aplcacón de métrcas en los proyectos SAP [Jones, 1998] consttuye uno de los mejores trabajos de posconamento en el área. En prmer lugar porque presenta el proyecto SAP como un puzzle con varas pezas: la rengenería de procesos, la parametrzacón del sstema, el desarrollo de partes a medda con ABAP 4 y la formacón de usuaros fnales. Además defende como aspectos cuantfcables tres de ellos (no comenta nada sobre la estmacón de la rengenería de procesos). Y en tercer lugar propone de hecho una métrca: los puntos de funcón [Albretch y Gaffney, 1983], aunque al no entrar al detalle de una defncón de los puntos de funcón en el entorno SAP la afrmacón debe tomarse como una declaracón de ntencones aberta a la dscusón. Precsamente [Daneva, 1999a] toma el testgo lanzado por Capers Jones al defnr y valdar la aplcacón de puntos de funcón en SAP. Establece equvalencas semántcas entre los cnco componentes de los puntos de funcón y los procesos y conceptos de modelado de datos de SAP y obtene reglas que los mapean para deducr un conteo de puntos de funcón. En un trabajo posteror se contnúa en la msma línea [Daneva, 1999b] proponendo una métrca basada en el modelo metodológco IPP [Keller y Teufel, 1998] y en los puntos de funcón, pero que se aplca sólo a la adaptacón del estándar de SAP a la organzacón (lo que Daneva denomna reuse) basada en los requstos que nacen de la rengenería de procesos. 3. PLANTEAMIENTO GENERAL DE LA ESTIMACIÓN DE LA IMPLANTACIÓN Partendo de que una mplantacón de SAP es un proyecto polfacétco y que cualquer propuesta de estmacón de esfuerzo ha de contemplar cada una de sus facetas desde un punto de vsta metodológco y global, a partr de la experenca propa y en la línea de [Slater, 1998] y [Jones, 1998] se propone como enfoque general la descomposcón de un proyecto SAP a efectos de estmacón en las sguentes áreas: 1) Parametrzacón y consultoría.- Se defne como el modelado de los procesos de negoco de la organzacón en SAP medante la adaptacón de éste rellenando las tablas de parametrzacón con la nformacón adecuada. Exge tanto un conocmento profundo del sstema SAP como de la propa organzacón, de su stuacón actual y de la stuacón a la que se quere llegar. En este área hay dos aspectos a cuantfcar separadamente: El esfuerzo de mplantar un componente SAP estándar, para lo cual hay que utlzar una métrca exstente [Jones, 1998] o dseñar una 6

5 nueva métrca que se adapte a la dosncrasa de SAP [Ward, 2001]. Este tema se tratará en la seccón 4. La rengenería de procesos. Cuantfcar este aspecto sólo será posble s el proyecto sgue una metodología como se propone en [Keller y Teufel, 1998], [Gess y Soltysak, 2000]. Dscutr las metodologías de proyectos SAP publcadas hasta la fecha, valdar su aplcacón en una métrca de rengenería de procesos y proponer dcha métrca o trabajar sobre alguna exstente [Daneva, 1999b] excede del alcance de este trabajo. 2) Desarrollos propos.- En general se defne como cualquer programa ABAP/4 no sumnstrado por SAP. Dentro de esta categoría creemos necesara la descomposcón en los sguentes tpos: a) Mgracón de datos.- Se refere a la conversón de la base de datos actual de la organzacón a SAP. El esfuerzo necesaro para mgrar la nformacón desde el sstema heredado a SAP depende fundamentalmente de: el estado de la base de datos actual en cuanto a su caldad (exacttud y complettud). la dstanca entre la organzacón de la nformacón del sstema heredado y la organzacón exgda por SAP. el nvel de conocmento del sstema heredado que tene el personal de TI de la organzacón. la necesdad de aportar nformacón nueva para darle más valor añaddo. b) Desarrollos adconales.- Se trata de aplcacones en ABAP/4 desarrolladas a medda que suplen funconaldades del estándar que no se adaptan a los procesos de la organzacón. En esta categoría se ncluyen tambén las nterfaces necesaras para conectar SAP con terceros sstemas. El esfuerzo necesaro para desarrollar el aplcatvo adconal se basa en la complejdad de éste. c) Explotacón de nformacón (Reportng).- En la práctca, el estándar de SAP no proporcona sufcentes herramentas de reportng y análss de datos, por lo que en muchas ocasones se hace mprescndble el desarrollo de utldades al efecto. Para ello es necesaro: analzar las herramentas de obtencón de nformacón actuales de la organzacón. dentfcar las necesdades cubertas por estas herramentas y las que no lo están. desarrollar en SAP las nuevas herramentas de reportng. El esfuerzo necesaro para desarrollar el reportng de una organzacón depende, como en el caso de los desarrollos adconales, de su complejdad. Sn embargo es dfícl establecer unos baremos generales en este punto, puesto que entre las necesdades de reportng de una empresa y las de otra puede haber una sgnfcatva dstanca: no es lo msmo la generacón de una sere de nformes en ABAP/4 que el desarrollo de un data warehouse que mplque la conexón de SAP con uno o varos sstemas externos. Una propuesta para la cuantfcacón de los desarrollos propos se descrbe en la seccón 5. 3) Aspectos socales del proyecto.- Se defne como las mplcacones humanas de la mplantacón: la gestón del cambo (y de la resstenca a éste) y la formacón de los usuaros. De la cuantfcacón del esfuerzo necesaro para la formacón trata la seccón ESTIMACIÓN DE LOS COMPONENTES SAP R/3 El prmer paso, se utlce una técnca exstente o se dseñe una nueva métrca es selecconar la undad de medda básca (UMB) para la estmacón, esto es, defnr qué se va a medr. Se podría empezar planteando lo adecuado de usar como UMB de SAP los puntos de funcón ntroducdos por Albretch en 1977, como proponen Jones o Daneva. Sn embargo, tratar de dvdr un componente de SAP R/3 en entradas, saldas, nterfaces, consultas y fcheros lógcos, cuando el sstema está organzado úncamente en transaccones, resulta complejo, debdo a que no exste correlacón drecta y es necesaro un mapeo de conceptos [Daneva, 1999a] que puede aceptarse como váldo, pero que puede resultar nnecesaro. SAP proporcona una undad de trabajo elemental que encaja a la perfeccón con la defncón que Charles Symons hzo de transaccón lógca, en su revsón sobre los puntos de funcón [Symons, 1988] y que do lugar a los puntos de funcón Mark II. Eso sí, en SAP exste una separacón natural entre las transaccones de parametrzacón y las funconales. A dferenca de los que propone 7

6 [Ward, 2001] creemos que la dmensón de un módulo sólo se conoce totalmente tenendo en cuenta ambas. 4.1 Estmacón de transaccones de parametrzacón TP Una transaccón de parametrzacón en SAP presenta normalmente una tabla a la que se le pueden añadr, modfcar o borrar entradas. Cada entrada consta de una clave y una sere de atrbutos. En funcón de la cantdad de atrbutos la nformacón puede estar recogda en una sola pantalla o en más de una. A pesar de que en estas transaccones de parametrzacón es donde se defne el comportamento futuro del sstema, técncamente son muy sencllas. Además se cumple que todas las transaccones de parametrzacón de cualquer módulo son práctcamente guales. Por este motvo un cálculo de puntos de funcón para cada transaccón P daría sempre un resultado smlar que no aportaría nformacón sgnfcatva. La UMB que más rápdamente se puede aplcar a la estmacón de la parametrzacón es un propo conteo de transaccones. Por tanto, el esfuerzo de parametrzacón de un módulo podría calcularse como: ESFp = TP α donde TP es el número de transaccones de parametrzacón del módulo y α es un peso que puede aplcarse para ponderar el mpacto del módulo según el tpo de organzacón. Este peso debería determnarse empírcamente desde proyectos en cada sector empresaral. Por ejemplo, en una organzacón de un sector ndustral base como el sderometalúrgco el módulo de produccón tene un peso mayor que el de marketng, mentras que en una empresa de dstrbucón de productos de consumo a usuaros fnales los pesos de ambos módulos seguramente estarán dstrbudos al revés. 4.2 Estmacón de transaccones funconales TF A dferenca de las transaccones de parametrzacón que son muy homogéneas, las transaccones funconales aun dentro de un msmo módulo presentan nveles de complejdad muy dstntos. A grandes rasgos se pueden separar los sguentes tpos de transaccones: Mantenmento de maestros.- El usuaro rellena una sere de pantallas en cada una de las cuales aparecen varos atrbutos del maestro que está actualzando. Cuando todos los atrbutos necesaros están completos se graba la actualzacón. Dependendo de la complejdad del maestro, el número de pantallas puede varar entre una y qunce. Obtencón de nformacón.- El usuaro rellena una únca pantalla con varos crteros de seleccón, pulsa la tecla de ejecucón del nforme y recbe una pantalla con los resultados de la seleccón que puede vsualzar, mprmr, envar por correo o guardar como archvo. Ejecucón de funcón.- Aquí se clasfcan la mayoría de transaccones funconales: creacón de peddos de venta, conversón de las facturas de clentes en efectos remesables, nventaros físcos, MRP, etc. Combna la entrada de datos del usuaro con la ejecucón de programas del sstema que realzan funcones adconales. La prncpal dferenca con los dos tpos anterores es que aquí el sstema realza un procesamento mucho mayor, hacendo verfcacones y actualzando tablas. Las transaccones funconales se dferencan de las de parametrzacón, por tanto, en que su complejdad es mucho mayor y mucho más varable entre sí. Aquí sí que tene sentdo utlzar una métrca de puntos de funcón que homogence las transaccones y permta compararlas. Como se ndcaba al comenzo de esta seccón, los puntos de funcón MK II basados en el concepto de transaccón lógca se adaptan muy ben a la organzacón de SAP. Para calcular los puntos de funcón de un módulo habría que analzar para cada una de sus transaccones TF: el número de elementos de entrada EE que contene; el número de elementos de salda ES que contene; el número de entdades de datos ED que actualza o consulta; Y así se obtene: ESFf = β EE + χ ES + δ ED donde β, χ y δ son pesos determnados empírcamente para ponderar las estmacones. 8

7 4.3 Ajuste de la estmacón A partr de lo anteror se tene que la estmacón del esfuerzo de un módulo se calcula como ESFp + ESFf. Pero a esta formula se le pueden hacer algunas consderacones. Aunque en prncpo se debe cumplr que un módulo con un mayor valor de ESF que otro mplca mayor esfuerzo de mplantacón, un smple conteo de transaccones P y puntos de funcón de transaccones F ofrece nformacón ncompleta, ya que no tene en cuenta otros aspectos del proyecto que en [Ward, 2001] se calfcaban de complcacones del entorno. Esto encaja con la dea del ajuste de complejdad técnca o ACT de Albrecht y Symons, utlzado para ponderar el cálculo de los puntos de funcón. Este ACT ntenta modelar aspectos del proyecto dfíclmente cuantfcables, por lo que toma aspecto de cuestonaro en que unos factores clave se puntúan en una escala. A mayor puntuacón de un factor, mayor esfuerzo repercute en el proyecto. La pregunta es s los factores defndos por Albrecht y Symons son aplcables a un proyecto SAP R/3. Dado que Symons ampló la lsta proporconada por Albrecht y además dejó opcón a defnr nuevos factores, es esta lsta la que se dscute. Los decnueve factores con sus valores pueden consultarse en [UKSMA, 1998]. Analzando esta lsta de factores se llega a las sguentes conclusones: Trece de los factores (F1, F6, F7, F8, F9, F10, F11, F12, F13, F14, F16, F18, F19) tomarán un valor constante en cualquer proyecto de mplantacón de SAP R/3 porque aluden a característcas de dseño del propo sstema, que ya está desarrollado: Cuatro de los factores (F2, F3, F4, F5) se referen a rendmento de la aplcacón, y en el caso de SAP la únca manera de mejorarlo es amplando el hardware o mejorando las comuncacones. En cualquer caso es algo fuera del ámbto de la estmacón del esfuerzo del proyecto. Dos de los factores (F15, F17) son váldos: F15 (necesdad de nterfaces) será tratado en la estmacón de los desarrollos propos y F17 (formacón) en el esfuerzo de la formacón. Es decr: los factores defndos en estas dos métrcas basadas en puntos de funcón no srven en este caso puesto que están orentadas al desarrollo de software y en SAP R/3 que es un software ya desarrollado que hay que mplantar. Por tanto aparece la necesdad de defnr un nuevo conjunto de factores para el cálculo de un ACT que sea específco del entorno SAP. Se propone la lsta de la tabla 1 como un prmer ntento de dentfcacón de factores. Esta lsta no pretende ser exhaustva o completa n ha sdo valdada; más ben debería consderarse como un punto de partda aberto a la dscusón. Respecto de dcha tabla, hay que tener en consderacón que: Los factores F2 y F3 han de calcularse para cada componente mplantado y añadr a la fórmula fnal la meda obtenda Los factores F1, F2 y F3 se calculan para cada versón de SAP R/3 y se aplcan de forma ndependente a cualquer proyecto. Los factores F4 y F5 son propos de cada proyecto. Esta relacón de factores se puede justfcar atendendo a las sguentes razones: F1 y F2 estman la probabldad de que las transaccones estándar contengan errores o haya gaps en la funconaldad tanto a nvel del paquete completo como de componentes. Cuanto menos tempo lleve la versón en el mercado menos habrá sdo probada. Análogamente un componente de marcado carácter local (como HR o en menor medda FI) habrá sdo mplantado en menos ocasones y además habrá que comprobar con especal cudado que cumple la legslacón vgente y los requstos. F4 y F5 aumentan de hecho cuanto mayor sea el tamaño del proyecto. Coordnar y gestonar la mplantacón en varas sedes dspersas geográfcamente y para un número elevado de usuaros aumenta el esfuerzo del proyecto [Francalanc, 2001]. Otra dferenca radcal con las métrcas cláscas de puntos de funcón es que en ellas se ofrecen valores medos de ACT y de los pesos, calculados a partr de proyectos ya desarrollados y se afrma que son aplcables en los nuevos proyectos, lo que plantea la pregunta de s esto se puede hacer tambén para SAP. Evdentemente no se dspone de una base de datos estadístca de proyectos realzados, pero aun cuando se dspusera de ella, pretender extrapolar valores de ACT de un proyecto SAP a otro es como comparar una organzacón a otra y por tanto no necesaramente aportará nformacón válda. ACT debe ser un 9

8 Factor 1 Antgüedad de la versón del producto 2 Establdad del componente 3 Carácter local del componente 4 Alcance organzatvo/geog ráfco del proyecto 5 Número de usuaros Descrpcón 0 más de cnco años 1 entre tres y cnco años 2 entre dos y tres años 3 entre uno y dos años 4 entre ses meses y un año 5 menos de ses meses 0 El componente pertenece al producto y no ha sufrdo cambos sgnfcatvos desde hace más de dos versones 1 El componente pertenece al producto desde hace más de dos versones y se le han añaddo mejoras funconales 2 El componente pertenece al producto desde hace más de dos versones aunque ha sufrdo cambos de dseño que han modfcado la funconaldad 3 El componente pertenece al producto desde hace dos versones 4 El componente se ntrodujo en el producto en la versón anteror 5 El componente es nuevo de esta versón 0 Nnguna transaccón es local para un país 1 Menos del 5% de las transaccones son locales para un país 2 Entre el 5% y el 10% de las transaccones son locales para un país 3 Entre el 10% y el 25% de las transaccones son locales para un país 4 Entre el 25% y el 50% de las transaccones son locales para un país 5 El componente ha sdo báscamente dseñado para la legslacón/procedmento de un país (más del 50% de las transaccones son locales) 0 Exste una sola organzacón 1 Exste una sola organzacón con varos centros de produccón/dstrbucón 2 Exsten de una a cnco organzacones con procedmentos smlares 3 Exsten de una a cnco organzacones heterogéneas (con dferencas de funconamento sgnfcatvas) 4 Exsten más de cnco organzacones heterogéneas Añadr 1 punto s el proyecto es nternaconal 0 Menos de 50 usuaros 1 Entre 50 y 100 usuaros 2 Entre 100 y 500 usuaros 3 Entre 500 y usuaros 4 Entre y usuaros 5 Más de usuaros Tabla 1. Factores de ajuste para los componentes SAP parámetro cudadosamente calculado y refnado en cada proyecto ndependente. Los pesos sí que podrían estandarzarse dentro de un sector y tamaño de organzacón, aunque de cualquer forma con mucha prudenca. En cualquer caso, el cálculo fnal del esfuerzo total de mplantacón del estándar ESFe sería: ESFe = n = 1 ( ESFp + ESFf donde es cada módulo mplantado. ) ACTe 5. ESTIMACIÓN DE LOS DESARROLLOS PROPIOS Excede del alcance de este trabajo dscutr las ventajas e nconvenentes de las métrcas cláscas de desarrollo de software, aunque cualquer métrca basada en puntos de funcón puede ser aplcada con smlares posbldades de éxto. Exsten dos clases báscas de desarrollos propos en el marco de un proyecto de mplantacón de SAP cuyo mpacto en el resultado fnal es dstnto y que deben ser analzadas por separado. Además este aspecto no ha sdo convenentemente tratado 10

9 Factor 1 Exstenca electrónca de los datos 2 Exacttud de los datos 3 Complettud de los datos 4 Dfcultad técnca de acceso a los datos 5 Crtcdad de la mgracón Descrpcón La no exstenca de los datos para la mgracón mplca un proceso de búsqueda y traspaso de éstos a un soporte nformátco temporal (una hoja de cálculo o base de datos) que se utlzará como fuente para los programas de mgracón 0 Exsten 5 No exsten, pero el conocmento está localzado en un únco soporte, un únco punto de la organzacón o una sola persona 10 No exsten. Los datos están dspersos en la organzacón, en soportes dferentes y/o el conocmento repartdo en varas personas 0 Los datos son correctos y están actualzados al 100%. No es necesara revsón 5 Los datos pueden presentar errores o nexacttudes poco relevantes. La revsón puede hacerse desde el propo programa de mgracón 10 Los datos no son fables o no están actualzados. Revsón mprescndble Dstanca entre las necesdades de SAP y los datos del sstema heredado 0 No es necesaro completar datos 5 Hay que completar datos, pero pueden deducrse del entorno 10 Hay que completar datos que oblgan a la elaboracón de fuentes complementaras a la mgracón 0 La conexón desde el programa de mgracón a la fuente de datos es drecta 5 Exsten fuentes de datos separadas con forma de conexón dferente 10 Las fuentes de datos o la dsposcón de éstos es tal que la mgracón ha de hacerse en varos pasos 0 S la mgracón no es completa o se produce con errores no se compromete el arranque del proyecto 5 S la mgracón no es completa o se produce con errores exstrán perjucos graves o problemas de funconaldad 10 S la mgracón no es completa o se produce con errores el proyecto no puede arrancar Tabla 2. Factores de ajuste para las mgracones de datos en nnguno de los trabajos consultados y que serán tratados a contnuacón: 5.1 Las mgracones Los programas de mgracón de datos poseen unas característcas defntoras que los dstnguen de otro tpo de programas: 1. Son vtales para el proyecto, aunque no forman parte del producto drectamente sumnstrado al clente. 2. El tamaño de los desarrollos no es relevante. Una estmacón basada en puntos de funcón devolvería valores smlares para cualquer programa de mgracón. El esfuerzo no depende de esto sno del estado de los datos en el sstema heredado. Por tanto que para estmar el esfuerzo necesaro para las mgracones no es váldo acudr a una métrca de puntos de funcón. A contnuacón presentamos las líneas generales de un método de estmacón del esfuerzo de la mgracón de datos basado en la dentfcacón de factores de resgo. Como punto de partda habrá que dentfcar las mgracones que serán necesaras a partr de los componentes que se van a mplantar. Este es un escenaro conocdo en cualquer proyecto. A contnuacón hay que calcular el esfuerzo que será necesaro para cada mgracón puntuando una lsta de factores clave como la propuesta en la tabla 2. Esta relacón de factores pretende ser una propuesta ncal que deberá ser completada y valdada: Puntuando cada programa de mgracón con los factores propuestos se obtendría un valor MIG y sumando la puntuacón total se llegaría a la medda del esfuerzo de la mgracón ESFm como: ESFm = n = 1 MIG 11

10 5.2 Las aplcacones adconales y el reportng Ambos tpos de desarrollos suplen o amplían la funconaldad del sstema estándar. A veces ncluso se puede susttur un componente estándar de SAP por un desarrollo a medda s la stuacón lo requere. En esta área del proyecto es en la únca en que encaja en las métrcas cláscas de desarrollo de software; por tanto parece evdente, al menos en prncpo, que se puede estmar el esfuerzo necesaro para ello a partr de una medcón basada en puntos de funcón y cuyos parámetros puedan ser ajustados y valdados utlzando dferentes técncas [Dolado, 2000] [Dolado, 2001]. Se propone utlzar los msmos puntos de funcón MKII que se utlzaron para la estmacón del estándar en su parte funconal, en parte por no ntroducr una métrca más sn justfcarlo y en parte por su facldad y adaptacón a los lenguajes 4GL como ABAP4. S se acerta o no con esta eleccón o s de hecho hay otras métrcas mejores para el desarrollo de software es una dscusón que consttuye el frente más vvo de nvestgacón en este área y excede del ámbto de este trabajo avanzar en esa línea proponéndose como trabajo futuro el estudar con datos empírcos la adecuacón real de los MKII a un lenguaje como ABAP4. La medda del esfuerzo de un desarrollo se realzará medante la sguente fórmula: ESFd = ε EE + φ ES + ϕ ED Además se calcularía un ACTd basado en los factores estándar que propone Symons como: Llegándose a: ACTd = 0,65 + 0, 005 FAC ESFd = n = 1 ESFd ACTd Es precso llamar la atencón sobre el problema de la dentfcacón de estos desarrollos. En la fase de anteproyecto será extremadamente dfícl defnr la totaldad de los desarrollos necesaros, así como especfcarlos. Suele ser habtual que un porcentaje cercano al 60% de los desarrollos propos aparezcan y sean defndos con el proyecto en fases ntermedas. Esta cfra es orentatva, nace de la experenca propa y puede tener un alto margen de error, por lo que sería nteresante hacer un estudo estadístco que dera una cfra más exacta de la ndetermnacón de desarrollos. Para dar una estmacón ncal aproxmada que cubrera esta laguna habría que estudar un número sufcente de casos y por analogía según el tpo y tamaño de la organzacón proponer un valor ncal que sería refnado a medda que la dentfcacón de desarrollos aumenta. 6. ESTIMACIÓN DE LA FORMACIÓN Esta seccón se centra exclusvamente en la estmacón del esfuerzo de la formacón de usuaros fnales. Cuantfcar y gestonar otros aspectos socales del proyecto como la resstenca al cambo exge de técncas dferentes y se propone como trabajo futuro. S se ha consegudo aplcar con éxto una métrca para estmar el tamaño de los componentes mplantados (Seccón 4) y los desarrollos propos excludas las mgracones (Seccón 5.2) como base para determnar el esfuerzo, esta msma métrca es el fundamento para calcular el esfuerzo que se ha de dedcar a la formacón de los usuaros fnales. La estmacón del esfuerzo para la rengenería de procesos y para las mgracones de datos no es relevante aquí. Sólo hay que tener en cuenta los dos valores anterormente ctados y en funcón del número de usuaros fnales calcular el esfuerzo y asgnar recursos convenentemente. Como en las fases ncales del proyecto es dfícl conocer los desarrollos adconales que serán necesaros (el problema de la dentfcacón referdo en la seccón anteror) se puede utlzar exclusvamente la medda de los componentes estándar como base para la estmacón del esfuerzo en la formacón. Por tanto el valor de partda para el esfuerzo en la formacón sería ESFe para cada módulo. Ahora ben, como en cualquer estmacón, el ajuste es fundamental, y en este área los factores de ajuste deben ponderar la estmacón con el perfl socal de la organzacón. Por tanto, al valor ESFe que ya ha sdo ajustado con una lsta de factores específca para el entorno SAP se le debe aplcar un segundo ajuste específco para la formacón que se muestra en la tabla 3. 12

11 Factor Descrpcón 1 Edad 0 Menor de 30 años 5 Entre 30 y 50 años 10 Más de 50 años 2 Dsponbldad 0 Total (más del 75% de la jornada laboral) 5 Meda (entre el 25% y el 75% de la jornada laboral) 10 Escasa (menos del 25% de la jornada laboral) 3 Formacón 0 Superor académca 5 Meda 4 Nvel jerárquco en la organzacón 5 Antgüedad en la organzacón 6 Dversdad cultural y otras dferencas 10 Sn formacón 0 Alto drectvo 5 Mando ntermedo 10 Personal de base 0 Menos de 5 años 5 Entre 5 y 15 años 10 Más de 15 años 0 No exsten 5 Exsten dferencas culturales o de otro tpo que afectan al proceso formatvo pero no tenen por qué dfcultarlo 10 Dferencas culturales sgnfcatvas u otros factores que dfcultan el proceso formatvo (domátcas, costumbres, mnusvalías...) Tabla 3. Factores de ajuste para la formacón Se justfca la eleccón de estos parámetros y sus valores analzando la experenca preva en la formacón de usuaros y dando mayor puntuacón a aquellos factores que se han encontrado consstentemente asocados a un mayor esfuerzo en ella. Sería necesaro valdar de forma empírca esta relacón para consderarla completamente aceptable, pero en general hemos constatado que se cumple lo sguente (tenendo sempre presente que mplantar SAP R/3 supone un cambo de gran mpacto en los procedmentos de la organzacón): Cuanto mayor es la edad del empleado mayor es el tempo que tarda en asmlar y aceptar nuevos conceptos. Cuanto menor es la dsponbldad del empleado más fragmentada es la formacón. La falta de contnudad ralentza el proceso de aprendzaje. En general, cuanto mayor es el bagaje cultural de una persona, más fácl resulta la comuncacón con ésta. Cuanto menor es el nvel jerárquco del empleado, mayor va a ser su nteraccón con el sstema a nvel de entrada de datos, por lo que hay que nvertr más esfuerzo en formarlo adecuadamente, de forma que se dsmnuya la tasa de errores. Cuanto mayor sea la antgüedad del empleado en la organzacón más hábto tendrá de utlzar los procedmentos antguos, pero a la vez mayor conocmento tendrá sobre ésta, por lo que aportará una realmentacón valosa sobre los detalles nternos de los procedmentos. Hay que tener en consderacón dferencas culturales, relgosas, de comportamento, así como mnusvalías, s suponen mayor dedcacón o nterferen en el proceso formatvo. Para cada futuro usuaro de SAP se calcularía por tanto un ACTu de forma que la medda global de la formacón quedaría como ESFu = ESFe n = 1 ACTu Se deben realzar dos consderacones a esta fórmula: 1. Se ha denomnado ESFu al valor obtendo aunque sólo se ha tratado parcalmente estmando la formacón. Queda pendente cuantfcar los otros aspectos socales del proyecto: resstenca al cambo e mplcacón de la organzacón, prncpalmente. 13

12 2. No se tene un valor ESFu para cada módulo mplantado, sno para la globaldad del proyecto. En la práctca normalmente los usuaros sólo utlzan una parte del sstema y por tanto no hay que formarles en todos los módulos, pero a la vez es muy dfícl segmentar la organzacón en grupos estancos asgnados a un módulo concreto. Por ello se calcula un ACTu global de la organzacón sumando el perfl de todos los usuaros y aplcarlo al valor total ESFe. 7. CONCLUSIONES Un proyecto ERP mplca consderacones relatvas a áreas muy dferentes, cada una de las cuales requere de un tratamento dferente. Sn embargo, acometer esta tarea con un enfoque global es mprescndble s queremos que el trabajo realmente tenga aplcacón práctca. Durante el desarrollo de este trabajo y la búsqueda bblográfca ha llamado la atencón la relatva escasez de trabajos centífcos publcados en el área. En segundo lugar, los trabajos que tratan el problema de forma global están orentados a la gestón del proyecto, no a la estmacón del esfuerzo y se centran en un aspecto del problema (la rengenería de procesos, la parametrzacón, o la gestón del cambo). Esto ndca que estmar el esfuerzo de un proyecto de mplantacón de SAP R/3 es una tarea tremendamente ambcosa, muy ampla y que exge por un lado gran domno de las técncas de medcón de software y por otro una gran experenca en proyectos SAP. En este trabajo se han defndo las prncpales áreas de descomposcón y medcón del proyecto y se han descrto sus atrbutos más mportantes, relaconando estas áreas del proyecto con técncas exstentes de medcón y apuntando los puntos fuertes y débles de cada una. Se han sntetzado dferentes propuestas exstentes en la lteratura junto con métodos de medcón consoldados, ntegrándolos en un modelo de medcón que tene en cuenta las peculardades de una mplantacón ERP. Como punto de partda para este trabajo futuro está en prmer lugar el tratamento de algunas áreas del proyecto que no han sdo sufcentemente desarrolladas aquí: especalmente la estmacón del esfuerzo de la rengenería de procesos y la gestón del cambo. Asmsmo, y aunque la tarea es muy compleja, se deberán completar y valdar las fórmulas aportadas con pesos a partr de datos empírcos. 8. AGRADECIMIENTOS Este trabajo ha sdo fnancado por el Mnstero de Educacón y Cenca dentro del Plan Naconal de I+D+I, proyecto TIN C03-02 (IN2TEST). REFERENCIAS Aladwan, A. M., Change management strateges for successful ERP mplementaton. Busness Process Management Journal. Albretch, A. J., Gaffney, J. E., Software functon, source lnes of code, and development effort predcton: a software scence valdaton. IEEE transactons on software engneerng. Austn, R., Nolan, R., Manage ERP ntatves as new ventures, not IT projects, Harvard Busness Revew. Brady, J. A., Monk, E. F., Wagner, B. J., Concepts n Enterprse Resource Plannng. Course Technology, Thomson Learnng Inc. Chrste, D., It's all about the tranng. Assst Pty. Ltd. Connolly, J., ERP: corporate cleanup. Computerworld. Daneva, M., 1999a. Dervng Functon Ponts from SAP Busness Process and Busness Objects. Journal of Informaton and Software Technologes. Daneva, M., 1999b. Identfyng and Quantfyng Reuse n the SAP Requrements Engneerng Process. Ffth Internatonal Workshop on Requrements Engneerng. Davenport, T. H., Msson crtcal: realzng the promse of enterprse systems. Harvard Busness School Press. Dolado, J. J., A Valdaton of the Component-Based Method for Software Sze Estmaton. IEEE Transactons on Software Engneerng. Dolado, J. J., Fernández-Sanz, L. (Eds.), Medcón para la gestón en la Ingenería del Software. RA-MA. Dolado, J. J., On the Problem of the Software Cost Functon. Informaton and Software Technology. 14

13 Draeger, E., Project management wth SAP R/3. Addson Wesley Publshng. Dryden, P., ERP falures exact hgh prce. Computerworld. Everdngen, Y. van, Hllegarsberg, J. van, Warts, E, ERP adopton by European mdsze companes. Communcatons of the ACM. Francalanc, C., Predctng the mplementaton effort of ERP projects: emprcal evdence on SAP R/3. Journal of Informaton Technology. Gess, M., Soltysak, R., Dynamc mplementaton of SAP R/3. Addson Wesley Publshng Company. Hquet, B. D., Kelley-Levey & Assocates, Kelly, A. F., SAP R/3 mplementaton gude. MacMllan Publshng Company. Jones, C., Estmatng and measurng SAP applcatons wth FP metrcs. Software Productvty Research. Keller, G., Teufel, T., SAP R/3 process orented mplementaton: Iteratve Process Prototypng. Addson Wesley Publshng. Koch, C., Surprse, surprse. CIO Forums. META Group Consultng, ERP platformrelated analyss Total Cost of Ownershp Study. Slater, D., The hdden costs of enterprse software. CIO Enterprse Magazne. Stapleton, J., Dynamc Systems Development Method: the method n practce. Addson Wesley Longman. Stedman, C., ERP user nterfaces drve workers nuts. Computerworld. Stedman, C., ERP flops pont to users' plans. Computerworld. Stjn, E. van, Wensley, A., Organzatonal memory and the completeness of process modellng n ERP systems: some concerns, methods and drectons for future research. Busness Process Management Journal. Symons, C. R., Functon pont analyss: dffcultes and mprovements. IEEE Transactons on Software Engneerng. Teltumbde, A., A framework for evaluatng ERP projects. Internatonal Journal of Producton Research Unted Kngdom Software Metrcs Assocaton (UKSMA), MK II Functon Pont Analyss Countng Practces Manual verson UKSMA Metrcs Practces Commttee. Ward, R., Estmatng ERP developments. European Software Control and Metrcs. Proceedngs. Welt, N., Successful SAP R/3 mplementaton. Addson Wesley Publshng. Wheatley, M., ERP Tranng stnks. CIO Enterprse Magazne. 15

14 16