Erp a velocidad de la luz
0 recomendaciones131 vistas
El documento describe los beneficios y riesgos de una implementación rápida de ERP. Una implementación rápida puede reducir los costos y tiempos de implementación mediante la reutilización de procesos de negocio probados y plantillas. Sin embargo, también existe el riesgo de brindar poca capacitación a los usuarios y una deficiente administración de cambios si no se planifica adecuadamente. Los clientes deben equilibrar el deseo de acelerar la implementación con la necesidad de transferir conocimientos y gestionar el cambio organizacional de man
Erp a velocidad de la luz
- 1. ERP a la Velocidad de la Luz Por una Implementación Rápida que Funcione para Usted Los clientes que por primera vez implementan el software de Planificación de Recursos Empresariales suelen sentirse al principio intimidados por el tiempo y los costos de implementación e intentan acelerar la fecha de puesta en marcha. Dicha anticipación, cuando se logra con las herramientas y estrategias adecuadas, puede generar valiosos beneficios que incluyen la reducción de los costos y un menor margen de tiempo para la obtención de beneficios (TTB). No obstante, sin las herramientas ni estrategias adecuadas, la aceleración de la implementación conlleva el riesgo de brindar una limitada administración de cambios y escasa capacitación de usuarios finales; falta de planificación posterior a la implementación, excesiva ingeniería de los procesos de negocio y otros problemas que de hecho llevan a un mayor costo total de propiedad y al agotamiento de los beneficios de negocio. Para algunos, la pregunta es: ¿conviene adelantar o no la fecha de puesta en marcha? Sin la aceleración, la implementación sería más costosa pero se podrían reducir otros riesgos. Costo vs. riesgo parece ser la alternativa. De hecho, tal como lo mostramos aquí, los clientes pueden obtener ambas cosas. Breve Historial de los Métodos de Implementación ERP Antes de 1997, las metodologías implementadas por los distintos integradores de sistemas no se ajustaban adecuadamente a los requerimientos exclusivos de ERP. La mayoría confiaba plenamente en las etapas As-Is y To-Be conforme a los proyectos de aplicaciones empresariales anteriores a ERP. En la etapa As-Is, se hacía un inventario de los procesos de negocio existentes de una empresa, y se colocaban en una tabla y en un script. En la etapa To-Be, los futuros procesos de negocio de una empresa se diseñaban, colocaban en una tabla y en un script. Lo ideal es que estos pasos sean de la siguiente manera: As-Is describía el status quo de los procesos de negocio To-Be describía la transferencia directa del proceso as-is en el proceso to-be que elimina las desventajas y logra el beneficio pretendido. Las falencias clave de estas metodologías se basan en la esclavizante atención que debía dedicarse a la etapa As-Is en la cual los procesos de negocio de bajo nivel eran autorizados y utilizados como script a un costo exorbitante para los clientes y con menos o ningún beneficio para la etapa To-Be. Muchos consideraron esto como la fase para “fondos de jubilación y retiro de los partners de consultoría”, y este aspecto era uno de los impulsores clave del exceso de costos altamente divulgado a mediados de los 90.1 Al comienzo de 1997, surgieron nuevas metodologías que abordaron de manera más directa las implementaciones de software empresarial y todas hicieron hincapié en el tema de la velocidad a través de un enfoque más directo, a través del uso de pruebas piloto para salas de conferencia, la implementación de plantillas y un mayor aprovechamiento de las mejores prácticas (es decir, la reutilización de procesos de negocio que ya habían realizado el trabajo de manera manifiesta) 1 Una grave consecuencia de este exceso de costos altamente divulgado fue la antigua percepción respecto de que, con esos elevados costos de consultoría, ERP no se adaptaba correctamente a los mercados en crecimiento, algo que, como ahora sabemos, no se aplica. Copyright Performance Monitor LLC Página 1 de 9
- 2. Para abordar las preocupaciones de los clientes respecto del elevado costo de las implementaciones, muchas de estas metodologías fueron catalogadas como rápidas: algunos ejemplos son: la denominación “Fast Track” de Deloitte, “Fast Forward” de Oracle Consulting, y “Rapid Return on Investment” (también denominado R2i) de KPMG (ahora BearingPoint). Para resumir, el mercado estaba saturado de “exitosas” historias de implementación de seis meses, cuatro meses, e incluso de dos semanas. Muchos esperaban finalmente que la implementación se completara durante una larga hora de almuerzo. A pesar de ser cierto que estas nuevas metodologías disminuyeron el tiempo necesario para la implementación, la simple aceleración generó nuevos problemas, como la inadecuada transferencia de conocimientos, la limitada administración de cambios y la deficiente planificación posterior a la implementación. En los diez años subsiguientes, la mayoría de estas implementaciones han sido redefinidas con el objeto de abordar tales problemas. De todos modos, como se detallará más adelante, las implementaciones rápidas conllevan ciertos riesgos. Componentes de la Aceleración El componente más crucial de la aceleración es la reutilización de los activos probados y existentes. Como los flujos de negocio, o los procesos, o las empresas dentro de un sector son prácticamente idénticos, los procesos previamente configurados pueden implementarse con facilidad. Por ejemplo, un proceso de negocios que abarca el proceso desde el pedido hasta el pago (order to cash) que ya ha sido factiblemente probado por cientos de empresas de bienes de consumo, probablemente sea una buena opción para otras empresas de bienes de consumo. De modo similar, para una empresa que comercializa autopartes ¿cuánto diferirían los ingresos de pedidos de compra de los de una empresa que vende repuestos para aviones? La reutilización depende de la buena disposición del cliente para adaptarse a los nuevos procesos de negocio en lugar de hacer que el software se adapte a los procesos personalizados. Cuanto más se adhiera el cliente a éstos, más rápida será la implementación debido a: • Una mayor reducción en las etapas de configuración de software y de diseño de los procesos de negocio, lo cual generalmente implica más de la mitad de los esfuerzos de consultoría esperados ? • Mayor nivel de reutilización de scripts, plantillas, herramientas de configuración, informes y documentación de usuarios ? • Reducción en la administración de alcance. El aumento de las soluciones orientadas al sector ha sido el resultado de miles de implementaciones ERP que se han generado en los últimos quince años y representa un paso importante hacia la evolución de las aplicaciones de negocio. Proven Test Test Scripts Scripts Methodology Methodology Industry Best Practices Process Test Guide A User Training/ User Training/ Test Guide B Work Plans & Work Plans & Documentation Documentation Templates Templates Copyright Performance Monitor LLC Página 2 de 9
- 3. Beneficios de una Rápida Implementación Cinco beneficios clave que pueden derivar de una rápida implementación: Menor tiempo y costos Menor interrupción en las operaciones existentes del cliente Menor probabilidad de un exceso de ingeniería Menor tiempo para la obtención de beneficios Comenzamos con los tiempos y costos, que representan las mediciones tradicionales para el éxito de los acuerdos. El primer y principal objetivo de una implementación rápida es reducir el tiempo de implementación y, por consiguiente, obtener beneficios en menos tiempo. En ambos casos, una implementación rápida debería aparejar costos más bajos. El nivel de reducción de costos no es simplemente una cuestión de horas totales invertidas sino también un tema de la relación cliente - integrador de sistemas. En esta relación existen dos polos. En un extremo se encuentra la propiedad del cliente, en la cual el cliente se relaciona activamente con el integrador de sistemas para acelerar la transferencia de conocimientos y la puesta en marcha. En el otro extremo se encuentra la adquisición del cliente en la cual el integrador de sistemas completa la implementación con una mínima colaboración o inversión del cliente. Propiedad del Cliente Adquisición del Cliente Los clientes son autodependientes Menos interrupción de las operaciones después del lanzamiento y de haber existentes a través del desarrollo del Ventaja recibido la transferencia de conocimientos proyectos como experiencia práctica Menos cambios en el proyecto debido a Mínimo costo total de propiedad ya que los una mayor disponibilidad de clientes y recursos internos son mínimos recursos del proyecto Administración de cambios organizacionales y aceptación de usuarios más efectivas debido a la participación del cliente Mayor interrupción de las operaciones Los clientes son menos autodependientes Desventaja existentes en todo el proyecto después del lanzamiento y requerirán más soporte externo continuo Mayor costo total de propiedad debido a La administración de cambios una mayor participación del cliente organizacionales en cierto modo es “impuesta” debido a una menor participación de clientes En el escenario de propiedad del cliente, los miembros del equipo de clientes deben recibir una rápida transferencia de conocimientos para contribuir positivamente con el proyecto. En un escenario de adquisición del cliente, la transferencia de conocimientos se produce al final del proyecto y por lo tanto es menos “práctica”. Como es obvio, los proyectos no son 100% de propiedad ni 100% de adquisición pero tienden a adoptar alguna categoría de una u otra manera. Hemos observado que las empresas de gran envergadura (>$5000 millones de ingresos anuales) suelen adoptar la propiedad de clientes, mientras que las empresas de menor envergadura (<$500 millones) suelen apuntar a la adquisición de clientes. Cabe destacar que, en cada escenario, hay cierto nivel de interrupción en las operaciones existentes durante el transcurso del acuerdo ERP. Incluso en una instancia extrema de adquisición de clientes, se requiere que el personal del cliente participe en la toma de decisiones comerciales clave, especialmente respecto de los procesos de negocio a ser adoptados. Aclarado esto, podemos decir que existe una clara ventaja provista por la aceleración en cuanto a una menor duración y un menor nivel de interrupción en los negocios. Copyright Performance Monitor LLC Página 3 de 9
- 4. Otra ventaja de la rápida implementación es la menor posibilidad de que se produzca un exceso de ingeniería. Siguiendo los métodos de implementación estándar, las actividades de configuración de software y diseño de procesos de negocio tienden a ser reiterativas en los procesos de prueba y error ya que los integradores sistemas y los clientes buscan un proceso “ideal”. Al hacer esto, el equipo continuamente volverá a configurar el software hasta que sea “el adecuado” y a menudo el resultado es tedioso para los usuarios y difícil de mantener. Negotiation and approval: IS-BusinessBusiness Process Reengineering BusBusinesscess Busness Prriocess i Pro cess Po ness Procesign ss Procedures Training De roces P Procedu rocedureses P r Training raining Desig esign D n Production Control Production Control ? Conffiigurrattiguratio Config urafiiion Con onfiguo n ration CoC gu at on n n IntegrationrTest InteIntegrat ation g i on Test st e Prototype Unit Test Producti on Prototy rototype e P p Unit nit Test st U e Produc roductionn P t o Una de las características de una implementación rápida es la reducción de la etapa de diseño de procesos de negocio (o blueprint) debido a que los clientes aceptan procesos de negocio probados y “listos para usar”. Dichos procesos no tienen un exceso de ingeniería y a menudo se encuentran previamente configurados, lo cual también contribuye con la reducción del proceso de configuración. En todas las implementaciones, a medida que los clientes ascienden en la curva de aprendizaje ERP, descubren que pueden hacer mucho más que lo que estaba incluido en el alcance original del proyecto. La tentación es expandir el alcance e incluir nuevos beneficios, prolongando así el tiempo de puesta en marcha. El desactualizado término “scope creep” (cambios inesperados en el alcance) no aplica correctamente a ERP. A pesar de que se pueden generar “cambios inesperados de alcance” en las aplicaciones individuales, ERP es para toda la empresa, abarca un conjunto de aplicaciones, y el “alcance fuera de control” (runaway scope) siempre es un riesgo. En una implementación acelerada, el alcance del proyecto a menudo se congela antes del diseño del proceso de los negocios. Esto implica que no se obtendrán los posibles beneficios recientemente identificados. Obviamente, si dichos beneficios son verdaderamente deseados, ellos pueden obtenerse después de la puesta en marcha. En cualquier caso, se impone a los clientes adoptar una estrategia de mejoras continuas de negocio después de la puesta en marcha, en la cual se mantendrán los procesos de negocio y, como consecuencia, la configuración. Continuous Business Improvement Yes Go Go Go No Incremental TO BE Live ? Improvement Continuous Business Improvement Live Core ERP Implementation Yes AS IS Performance Go No Incremental TO BE Live ? Improvement Core ERP Implementation AS IS Copyright Performance Monitor LLC Página 4 de 9 Performance
- 5. Más allá de la reducción de costos, la mayor ventaja de una implementación acelerada es la reducción del margen de tiempo para la obtención de beneficios. Según los objetivos de negocio, esta reducción puede ser marginal o drástica. Por ejemplo, si un cliente está apuntando a un nuevo mercado que requiere software, la diferencia entre una implementación de seis meses y una de diez meses será drástica. Antes del surgimiento de las metodologías para una implementación acelerada, uno de los proyectos de implementación más exitosos que he observado fue el de una empresa que se estaba desvinculando del negocio. Para dicha empresa, la aceleración era un requisito primario obvio. Al vislumbrarse una posible bancarrota, el cliente congeló las oportunidades para focalizarse en las áreas más críticas de sus operaciones, aceptó procesos de negocio fáciles sin controversias y experimentó solo interrupciones mínimas en las operaciones de negocio ya que rápidamente pasaron a soporte ERP lo cual, finalmente, salvó a la empresa de la bancarrota. Fundamentalmente, tal vez la mayor ventaja de una implementación acelerada es el sentido de urgencia y el propósito que generará. Los Riesgos de una Implementación Acelerada Establecer un sentido de urgencia es esencial para el éxito de una implementación acelerada. No obstante, si el sentido de urgencia se transforma en una alarma debido a que los plazos o los presupuestos se acortan, la velocidad de los proyectos puede ser un caos. Los riesgos clave para un cliente que opta por una implementación acelerada son: Poca capacitación para el usuario final Poca o inadecuada administración de cambios Transferencia deficiente de conocimientos Falta de planificación posterior a la implementación Los usuarios finales cumplen con los procesos de negocio que son respaldados por el software ERP, y su capacidad, o su falta de capacidad, tiene un efecto directo sobre la eficacia de esos procesos. Desafortunadamente, la capacitación del usuario final es uno de los aspectos más discutidos de ERP y puede ser aún más discutido en un ámbito acelerado. Esta capacitación es casi siempre el penúltimo paso antes de la puesta en marcha, y si el proyecto está retrasado y/o sobrepasa el presupuesto, durante mucho tiempo la tendencia ha sido reducirlo a fin de ahorrar tiempo. Estos ahorros de tiempo luego serán dominados por la incompetencia de los usuarios finales y la incapacidad de cumplir efectivamente con los procesos de negocio previstos. Asimismo, en una implementación acelerada, la administración de cambios organizacionales a menudo es dejada de lado ya que puede haber poco tiempo para orientar al personal comercial hacia nuevos procesos de negocio. Esto puede exacerbarse aún más con el hecho de que los procesos de negocio “fáciles” pueden ser bastante distintos a los procesos de reemplazo. El resultado de una inadecuada administración de cambios organizacionales se traduce en inconvenientes de negocio después de la puesta en marcha, lo cual puede agotar los beneficios y los nervios. La aceleración de la puesta en marcha sin tener una visión a largo plazo también representa un riesgo en una implementación acelerada. Fundamentalmente, los clientes deberían ver la fase de implementación como “la boda” y la implementación de su software como “el matrimonio”. Mientras que la boda puede durar seis meses o más, el matrimonio durará veinte años. La falla en la planificación de la fase posterior a la implementación en la cual el cliente deberá estar adecuadamente posicionado para operar y mejorar su planta ERP, llevará a una conmoción más prolongada y costosa y agotará los beneficios previstos. Copyright Performance Monitor LLC Página 5 de 9
- 6. La aceleración no se trata de plazos y definitivamente no se trata de atajos. Con el fin de evitar un resultado donde el plazo de puesta en marcha se cumpla pero los usuarios finales sean incompetentes, los líderes de negocio se estén disconformes y la administración senior quiera saber qué beneficios se están obteniendo de la inversión, los siguientes factores deben cumplirse estrictamente: Por qué: Criterio visible, mensurable para el éxito Qué: Poder de alcance Cómo: Transferencia efectiva de conocimientos del especialista al cliente Cuándo: Metodología de aceleración y plantillas y herramientas asociadas Una implementación acelerada exitosa combinará la finalización a tiempo de acuerdo con los presupuestos establecidos y la capacidad de un cliente para “prosperar después de la puesta en marcha”. Mejores Prácticas para una Exitosa Implementación Acelerada Durante una implementación ERP acelerada, existen algunas mejores prácticas que deben tenerse en cuenta cuidadosamente antes de poner en marcha un proyecto. Costo de Implementación Cuando se trata de implementaciones ERP, el costo es la preocupación primordial. Como resultado, muchos proyectos tienen poca financiación desde el comienzo y están destinados a finalizar “con un exceso de presupuesto”. Una práctica recomendada en relación al control de costos es planificar con un enfoque realista en vez de hacerlo con una visión optimista. ¿Su organización ha realizado acuerdos a largo plazo exitosos con anterioridad? ¿Cuánto éxito ha tenido su organización al trabajar con consultores externos? ¿Qué niveles de experiencia interna están a disposición? Dar respuestas consistentes a estas preguntas augura un buen enfoque acelerado. Los clientes que responden negativamente a estas preguntas deberían considerar una menor aceleración que la deseada. Con respecto a esto, también se aconseja a los clientes que aseguren su buena disposición organizacional para una implementación y que fijen plazos de acuerdo con los requisitos comerciales en lugar de hacerlo como objetivos artificiales. El costo de la implementación necesariamente será un múltiplo del costo combinado de hardware & software. Históricamente, la referencia siempre ha sido una relación 2 a 1, ya que los impulsores de costo de la implementación son: Impulsores de Costo de la Implementación ¿Cuántos sitios operacionales se implementan y cuán complejas Sitios / complejidad son las interacciones entre sitios? Nivel de cambio ¿Cuán diferentes serán los nuevos procesos de negocio de los viejos? Sistemas tradicionales ¿Cuántos sistemas tradicionales deben interconectarse con el conservados nuevo ERP? Personal empleado ¿Cuál es el nivel del personal asignado al compromiso? ¿Cuán preparado está el personal interno para contribuir Disposición del personal efectivamente con el compromiso? Compromiso de la ¿Cuán comprometida está la administración senior con los administración cambios que ocasionará el compromiso? Teniendo en cuenta esto, el costo debería cuadrar con los beneficios de negocio mensurables, el “por qué” de la implementación. Los objetivos de negocio tangibles brindan al equipo de implementación directivas claras y una base para la toma de decisiones durante el transcurso del proyecto. Si los beneficios no pueden medirse, la tendencia será cuestionar el valor de la implementación incluso mientras está en progreso. Copyright Performance Monitor LLC Página 6 de 9
- 7. Dependencias de Recursos Internos / Disponibilidad Los escenarios de implementación de propiedad y adquisición fueron anteriormente planteados en este documento. Se aconseja a los clientes que optan por un escenario de propiedad que asignen su personal más eficiente al proyecto de implementación, a pesar de que al hacerlo, seguramente tengan más problemas en las actuales operaciones de negocio. Una vez más, sería prudente lograr una visión a largo plazo. Esto resulta más difícil en empresas en crecimiento ya que la masa crítica de talento máximo es menor que la de las grandes empresas. Por consiguiente, las empresas en crecimiento a menudo asignan personal al proceso de implementación sobre una base part-time. Estas asignaciones solo tendrán éxito si la administración senior permanece comprometida con ellas y resiste la tentación diaria de satisfacer las necesidades de negocio a corto plazo y, por lo tanto, dejar que el proyecto se derrumbe. Para garantizar que esto no suceda, muchas compañías han utilizado una ubicación externa para gran parte del trabajo de proyectos, haciendo que el personal clave “no esté disponible”. El tipo de personal requerido para el proyecto es de nivel administrativo o directivo; personas capaces de tener en cuenta varios departamentos y que puedan entender el flujo horizontal de negocios. Por ejemplo, una persona actualmente asignada al procesamiento de pedidos de venta puede no tener la posición adecuada para entender todo el proceso de negocios Order to Cash (OTC). Order to Cash (OTC) Verificación Aceptar/ Acuse Pedido de entrega Ingresar Seleccionar Comprar Recibir Facturación Paso Telefó- de recibo Proveedor Materiales Producción Embalaje Envío y Cobro Pedido Materiales nico /Stock Procesamiento Planificación Departamento Preventas de pedidos de venta Compra Depósito de producción Contabilidad Módulo Ventas/Distribución Administración de materiales Producción Depósito Finanzas Las asignaciones de personal deben adherirse a la siguiente jerarquía: Liderazgo: Patrocinadores del Proyecto y Miembros del Comité Directivo Entrega: Gerentes de Proyecto, Diseño/Configuración de Procesos Comerciales, y Líderes Técnicos Responsables de la Estructuración: Administración de Cambios Organizacionales, Capacitación y Garantía de Calidad Público de interés: Partes con Intereses personales en el Proceso /Proyecto Los clientes que optan por un escenario de adquisición tendrán mayor confianza en su integrador de sistemas para las categorías de entrega y responsables de estructuración. Los roles de liderazgo y público de interés deberían ser idénticamente designados a cualquiera de los dos escenarios. Facilidad de Uso (Capacitación Requerida / Disponible) No es suficiente capacitar a los usuarios finales respecto de las características y funciones de ERP. Sus roles necesariamente se expandirán, de funciones departamentales a múltiples departamentos, a medida que sus acciones contribuyan con los procesos de negocio definidos. De esta manera, la capacitación de los usuarios finales debería incluir: • Orientación referida a los objetivos de negocio de la adopción ERP • Administración de cambio básica respecto de los roles, las expectativas, los principios de procesos de negocio, y mesa de ayuda • Las características y funciones en el contexto de su rol en el cumplimiento de un proceso de negocios. A lo largo del tiempo, los usuarios finales deberían recibir capacitación adicional, no solo en respuesta a los cambios en el sistema, sino también para ofrecerles un nivel más alto de competencia e impulsar mejoras en el proceso de negocios. Copyright Performance Monitor LLC Página 7 de 9
- 8. Mejores Prácticas para Procesos de Negocio Desde el surgimiento del software para toda la empresa a principios de los 90, el antiguo paradigma de hacer que el software active los procesos que las empresas elijen ha sido bastante perturbador. En la actualidad, los clientes son incitados a adoptar los procesos de negocio inherentes al software sobre la premisa de que estos procesos son las “mejores prácticas”. Este cambio de paradigma conduce a una lucha natural de poderes entre los integradores de sistema que intentan vender las mejores prácticas y los clientes que insisten en que conocen su negocio mejor que sus competidores. Una reciente investigación de Performance Monitor confirma esto, ya que 697 encuestados tienen una opinión dividida respecto de este tema. De acuerdo En desacuerdo No Opina / No sabe 91% 92% 93% 94% 95% 96% 97% 98% 99% #### 91% 92% 93% 94% 95% 96% 97% 98% 99% #### 91% 92% 93% 94% 95% 96% 97% 98% 99% #### 81% 82% 83% 84% 85% 86% 87% 88% 89% 90% 81% 82% 83% 84% 85% 86% 87% 88% 89% 90% 81% 82% 83% 84% 85% 86% 87% 88% 89% 90% 71% 72% 73% 74% 75% 76% 77% 78% 79% 80% 71% 72% 73% 74% 75% 76% 77% 78% 79% 80% 71% 72% 73% 74% 75% 76% 77% 78% 79% 80% 61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50% 41% 42% 43% 44% 45% 46% 47% 48% 49% 50% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 31% 32% 33% 34% 35% 36% 37% 38% 39% 40% 21% 22% 23% 24% 25% 26% 27% 28% 29% 30% 21% 22% 23% 24% 25% 26% 27% 28% 29% 30% 21% 22% 23% 24% 25% 26% 27% 28% 29% 30% 11% 12% 13% 14% 15% 16% 17% 18% 19% 20% 11% 12% 13% 14% 15% 16% 17% 18% 19% 20% 11% 12% 13% 14% 15% 16% 17% 18% 19% 20% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 40% 35% 25% Copyright Performance Monitor LLC Se aconseja a los clientes “escuchar el software” y prepararse para adoptar los procesos de negocio inherentes, siempre que esos procesos cumplan con los requisitos del mercado y de negocios. Mientras esto era realmente difícil a mediados de los 90, en 2006 los procesos de negocio han sido probados cientos de veces a medida que los clientes aprenden, de proyecto en proyecto, que no son tan exclusivos como suponían. Configuración Futura y Capacidades Adicionales Futuras La agilidad de los negocios depende de la capacidad de un cliente para cambiar rápidamente los procesos de negocio a fin de dirigirse hacia las oportunidades o las amenazas. Después de la puesta en marcha, los clientes obtendrán esta agilidad, siempre y cuando: 1. El software no haya sido sobrediseñado ni personalizado durante la implementación. 2. El personal del cliente haya recibido una transferencia de conocimiento suficiente. 3. Se conserve la alineación entre IT y el negocio. Dado que el alcance de las implementaciones más aceleradas es necesariamente reducido, se pueden obtener muchos más beneficios de negocio después del lanzamiento, en pasos progresivos que no interrumpirán las operaciones de negocio. Asimismo, los clientes pueden extender sus aplicaciones al agregar capacidades como customer relationship management (CRM), supply chain management (SCM), product lifecycle management (PLM), y otras capacidades. En las implementaciones aceleradas, ciertos sistemas tradicionales clave pueden conservarse temporalmente. Estos sistemas pueden retirarse sistemáticamente después del lanzamiento con el fin de reducir la carga del mantenimiento de software. Copyright Performance Monitor LLC Página 8 de 9
- 9. Soporte de Servicio Por lo menos durante los tres primeros meses después del lanzamiento de una implementación acelerada, la mayoría de los clientes todavía dependerán de alguna manera de su integrador de sistemas, por lo tanto, debería contratarse el nivel necesario de cobertura. Además del soporte de la integración de sistemas, los clientes pueden depender del soporte de software y los servicios de la mesa de ayuda incluidos en un contrato de mantenimiento. Según el nivel de autodependencia de un cliente, pueden contratarse niveles más altos de soporte. Muchos clientes, antes y después del lanzamiento, optan por subcontratar sus operaciones de ERP. Esa subcontratación no es una propuesta “todo o nada” ya que los clientes pueden adaptar el soporte a sus necesidades: Mantenimiento de aplicaciones: Alojamiento/operación, interrupción/corrección, depuración, backup, etc. de aplicaciones básicas. En resumen, mantener ERP en funcionamiento. Administración de aplicaciones: funciones de mantenimiento (arriba) más un nivel de mejoras para aplicaciones, actualizaciones y/o transformación para procesos de negocio. Para este ultimo, hay varios niveles de administración: ·Mejora funcional de aplicaciones de acuerdo con lo necesario para garantizar la continuidad básica ·Mejoras frecuentes de aplicaciones para ofrecer optimización ·Niveles/etapas definidas de transformación para procesos de negocio Conclusión: el Fin del Principio Piense en una implementación acelerada como ERP “de nivel de ingreso”. El lanzamiento es solo el fin del principio. Después del lanzamiento, la autodependencia del cliente dependerá del nivel de aceleración. Las implementaciones altamente aceleradas dejarán al cliente en una posición vulnerable si no se hace hincapié en una continua transferencia de conocimientos y en la administración de cambios después del lanzamiento. Una exitosa implementación acelerada ofrecerá al cliente el poder de ERP de la manera más rápida posible, y causará interrupciones mínimas en las operaciones de negocio existentes. Con un núcleo activo de software ERP, las presiones de tiempo se eliminarán, y los clientes podrán volver a tratar las brechas que no podían abordar al principio. A lo largo del tiempo, el cliente llegará a un nivel más alto de desarrollo ERP y es de esperar que tenga éxito después del lanzamiento. Acerca de Performance Monitor Fundado en mayo de 2005, Performance Monitor es el proveedor líder de asesoramiento e investigación basada en hechos y focalizada en el monitoreo del desempeño de empresas de servicios profesionales. Para obtener más información, por favor contáctese con Paul Reynolds, Director de Investigación (preynolds@performancemonitor.net) o visite www.performancemonitor.net. Copyright Performance Monitor LLC Página 9 de 9