Pre-Implantación de un ERP (25)

En este punto se desarrolla la metodología pre-implantación y que será muy importante para conseguir la rentabilidad del proyecto. Habitualmente esta fase de pre-implantación es infravalorada y en muchas ocasiones ni se realiza este análisis llevando a implantaciones con objetivos poco definidos y con multitud de problemas.

Los principales frenos a la implantación de un ERP son: Factor cultural, Miedo al cambio en el sistema de gestión, Coste, Tiempo de implantación y Miedo al fracaso.

Muchos responsables de pymes, cuando deciden implantar un ERP en su empresa no lo hacen por convencimiento, pensando en las ventajas que ese sistema puede aportar, sino por necesidad. Por ese motivo, los expertos aseguran que al abordar la implantación de un ERP es mejor fraccionar el proyecto en distintas fases. De este modo, el cambio que sufre la empresa es menos brusco, y el temor del empresario también disminuye. De hecho, existe un gran temor al fracaso del proyecto lo que desemboca en un freno importante a la hora de optar a implantar un ERP. Es interesante subrayar que los principales frenos no son objetivos (coste, tiempo, cambios en los procesos y en la organización...) sino subjetivos (cultura, miedo al cambio y al fracaso).

Los objetivos de la pre-implantación son:

-      Reducción de los costos y tiempos de los procesos

-      Mejorar la productividad de los procesos

-      Mejorar el proceso de la toma de decisiones

-      Mejorar el servicio al cliente

-      Posibilidad de compartir información entre todas las áreas de la organización

-      Optimización de los procesos de la organización

-      Acceso a información confiable, precisa y oportuna 

El éxito o fracaso de la implantación está por 3 elementos:

1. La organización donde va a ser implantada: la estrategia, sus personas, la cultura, los procesos, etc.

2. Las consultoras que ofrezcan los servicios de pre-implantación e implantación.

3. El ERP elegido, es decir, tanto el producto en sí como el fabricante.

Es habitual encontrar organizaciones que no han desarrollado correctamente el análisis pre-implantación y por tanto no han elegido bien la solución. Por todo ello, el análisis previo debe contener al menos los siguientes apartados:

1.- Análisis inicial de la estrategia, tecnología, procesos, personas y organización.

En esta fase, se debe realizar un profundo análisis de la estrategia, personas, procesos y tecnología para así plantear la mejor solución tanto desde el punto de vista tecnológico como de gestión del cambio asociado. En esta etapa se crearán equipos de trabajo para hacer este análisis y para el trabajo posterior.

2.- Definición del alcance funcional de la implantación del ERP, es decir qué áreas y funciones comprenderá la implantación así como un primer planteamiento de calendario.

3.- Definición de objetivos de la implantación del ERP.

Habrán objetivos tangibles (reducción de costes, mejora de eficacia y eficiencia de procesos, reducción del plazo de entrega y niveles de inventario, etc.) y otros intangibles como por ejemplo disponer de más cantidad de información y conocimiento para la toma de decisiones. Obviamente, todos estos objetivos deben estar integrados dentro de la estrategia de la organización.

4.- Definición de las mejoras en los procesos y organización que aportará la implantación del ERP. Esto no debe ser una declaración de intenciones sino que se deben haber modelado los procesos de la organización y reconocer el impacto de la  implantación del  ERP. Se deben definir objetivos cuantificados de mejora para cada uno de los procesos y deben estar integrados en el calendario del proyecto.

5.- Definición del plan de gestión del cambio para conseguir el cambio de manera no traumática.

Dentro de este plan, el plan de comunicación interna es muy importante para “vender” los beneficios del proyecto a los integrantes de la organización para conseguir que todo el mundo perciba una mejora con el proyecto ERP.

6.- Elección de la solución tecnológica y del implantador más adecuado en función del análisis realizado en la primera fase así como los módulos y parametrizaciones necesarias.

7.- Definición de un calendario aproximado y presupuesto asociado.

Esta fase estará directamente relacionada con la fase anterior ya que en función de la elección tecnológica y de los desarrollos anexos, el calendario y el presupuesto variarán. Se tienen costes externos e internos.

Costes externos

- Licencias de la aplicación (software)

- Consultoría implantadora, Costes de actualizaciones y mantenimiento, Desarrollos a medida y Formación (servicios)

- Hardware, red o comunicaciones (infraestructura)

Costes externos aproximados (infraestructura técnica à 10%, software à 30%, servicios à 60%)

Costes internos

- Horas dedicadas por el personal de la organización al proyecto.

- “Problemas” que pueden aparecer debido a la implantación del ERP.

Costes internos aproximados (dedicación necesaria por parte de los recursos de la compañía à 80%, costes asociados a la aparición del ERP en la empresa à 20%)

8.- Definir el retorno de la inversión (ROI) del proyecto y los parámetros clave KPI para definir el seguimiento de la implantación así como un análisis de la sensibilidad ante la variación de determinados para metros.

ROI= (Beneficios/Costes)*100

El ROI mide el beneficio que obtenemos por cada unidad monetaria invertida durante un periodo de tiempo. Es el valor actualizado de la corriente de beneficios generada por la inversión a lo largo de su vida útil; partido por el valor actual de la inversión realizada. Cantidad de tiempo en recuperar la inversión realizada.

Para incrementar el ROI se debe: aumentar la productividad, disminuir los costes y generar ingresos.

9.-Implantacion del ERP

10.- Seguimiento y control estricto de los objetivos previamente definidos así como de los elementos críticos para la rentabilidad del proyecto.

Es muy importante que haya un estricto control del proyecto para que se cumplan los objetivos definidos en las primeras etapas.

Introducción a SEBOK (1)

SEBoK 1.0 Introduction.

Systems engineering (SE) is essential to the success of many human endeavors. As systems increase in scale and complexity, SE is increasingly recognized worldwide for its importance in their development, deployment, operation, and evolution. The purpose of the SEBoK is to provide a widely accepted, community based, and regularly updated baseline of SE knowledge. This baseline will strengthen the mutual understanding across the many disciplines involved in developing and operating systems. Shortfalls in such mutual understanding are a major source of system failures, which have increasingly severe impacts as systems become more global, interactive, and critical.

Key terms.

A good first step towards understanding is to define key terms. Four terms will suffice for this Introduction: system, engineered system, systems engineering, and systems engineer.

Here are baseline definitions of what these terms mean for the purposes of the SEBoK:

• A system is “a set of elements and a set of inter-relationships between the elements such that they form a bounded whole relative to the elements around them” (Bertalanffy 1968) and which exists in an environment which contains related systems and conditions. While there are many definitions of the word “system,” the SEBoK authors believe that this definition encompasses most of those which are relevant to systems engineering.

• An engineered system is an open system of technical or sociotechnical elements that exhibits emergent properties not exhibited by its individual elements. It is created by and for people; has a purpose, with multiple views; satisfies key stakeholders’ value propositions; has a life cycle and evolution dynamics; has a boundary and an external environment; and is part of a system-of-interest hierarchy.

• Systems engineering is “an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2012). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.

• A systems engineer is “a person who practices systems engineering” as defined above, and whose systems engineering capabilities and experience include sustained practice, specialization, leadership or authority over systems engineering activities. Systems engineering activities may be conducted by any competent person regardless of job title or professional affiliation.

Purpose of the SEBoK

The purpose of the SEBoK is to provide a widely accepted, community based, and regularly updated baseline of SE knowledge. This baseline will strengthen the mutual understanding across the many disciplines involved in developing and operating systems. Shortfalls in such mutual understanding are a major source of system failures, which have increasingly severe impacts as systems become more global, interactive, and critical. Ongoing studies of system cost and schedule failures (Gruhl-Stutzke 2005; Johnson 2006) and safety failures (Leveson 2012) have shown that the failures have mostly come not from their domain disciplines, but from lack of adequate SE.

Purpose Description

1 Inform Practice Inform systems engineers about the boundaries, terminology, and structure of their discipline and point them to useful information needed to practice SE in any application domain.

2 Inform Research Inform researchers about the limitations and gaps in current SE knowledge that should help guide their research agenda.

3 Inform Interactors Inform performers in interacting disciplines (system implementation, project and enterprise management, other disciplines) of the nature and value of SE.

4 Inform Curriculum Developers Inform organizations defining the content that should be common in undergraduate and graduate programs in SE.

5 Inform Certifiers Inform organizations certifying individuals as qualified to practice systems engineering.

6 Inform SE Staffing Inform organizations and managers deciding which competencies that practicing systems engineers should possess in various roles ranging from apprentice to expert.

The SEBoK is a guide to the body of systems engineering knowledge, not an attempt to capture that knowledge directly. It provides references to more detailed sources of knowledge, all of which are generally available to any interested reader. No proprietary information is referenced, but not all referenced material is free—for example, some books or standards must be purchased from their publishers. The criterion for including a source is simply that the authors believed it offered the best generally available information on a particular subject.

The SEBoK is global in applicability. Although SE is practiced differently from industry to industry and country to country, the SEBoK is written to be useful to systems engineers anywhere. Authors have been chosen from diverse locales and industries, and have refined the SEBoK to broaden applicability based on extensive global reviews of several drafts.

The SEBoK aims to inform a wide variety of user communities about essential SE concepts and practices, in ways that can be tailored to different enterprises and activities while retaining greater commonality and consistency than would be possible without the SEBoK. Because the world in which SE is being applied is evolving and dynamic, the SEBoK is designed for easy, continuous updating as new sources of knowledge emerge.

Scope and Context of the SEBoK

The SEBoK is one of two complementary products. The other, which uses the content of the SEBoK to define a core Body of Knowledge to be included in graduate SE curricula, is called the Graduate Reference Curriculum for Systems Engineering (GRCSE™). The GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program.

Most of the SEBoK focuses on domain-independent information—that which is universal to systems engineering regardless of the domain in which it is applied. Part 7 includes examples from real projects. These illustrate the concepts discussed elsewhere in the SEBoK, while detailing considerations relevant to domains such as aerospace, medicine, and transportation. The SEBoK also covers considerations for the disciplines of software engineering and project management, which are strongly intertwined with the practice of SE.

One summarizes the SEBoK’s definition by an international group of volunteer authors; its review by the SE community at large; its life cycle evolution management and support by the two primary international SE-related professional societies, the Institute of Electrical and Electronic Engineers (IEEE) and the International Council on Systems Engineering (INCOSE); and its use in derivative products and services by the community at large.