Metodología de implantación de un ERP (39)

Para lograr una implantación satisfactoria de un ERP es imprescindible dirigir todos los esfuerzos en una misma dirección. La mejor fórmula para conseguirlo es obtener un compromiso en el que la aportación del cliente sea tan importante como la del implantador. Partiendo de estas premisas, resulta clave el definir desde el primer momento, qué personas van a desempeñar las funciones necesarias dentro de la estructura organizativa de los proyectos de implantación del ERP. Dicha organización se debe definir en función de la complejidad y presupuesto de cada proyecto.

Fases de la Metodología

Una buena metodología de implantación será determinante para tener una garantía de "puesta en marcha" de la solución en los plazos previstos, pero además, nos permitirá definir claramente las responsabilidades de las partes implicadas y establecer las bases de un plan de acción conjunto. Para ello, resulta necesario seguir un patrón metodológico como el que se expone a continuación y que esté basado en las experiencia en más de un centenar de proyectos de estas características.

Fase 1: Análisis y Diagnosis

Esta fase consiste en la realización de un completo estudio de los procesos de negocio y de los futuros requisitos de la compañía, con el fin de redactar un documento en el que quedarán detalladas, tanto la correcta configuración de los procesos de negocio planteados, como el alcance de las funcionalidades no soportadas por la solución estándar sobre la que habrá que realizar desarrollos o configuraciones adicionales a medida. Asimismo, en este documento, se recogerán, en caso de necesidad, el traspaso de datos al sistema desde aplicaciones externas y deberán quedar detallados, tanto los datos a importar, como la información disponible sobre el formato de los datos fuentes. Para la correcta elaboración de éste análisis, se deberán mantener reuniones y entrevistas con los distintos responsables asignados al proyecto.

Esta primera fase, es recomendable iniciarla con una formación de usuarios en funcionalidad básica de la solución y se cerrará con la definición de particularidades, parte esta, que resulta de gran complejidad y en la que requiere más tiempo por parte del equipo de los proyectos de implementación, ya que en ella se analizan y documentan los procesos de negocio, con el fin de definir el funcionamiento presente y futuro de la organización. En esta fase también se depuraran los objetivos y alcance del proyecto y se preparará con más detalle el plan del proyecto.

Fase 2: Diseño y Desarrollos Específicos

El objetivo de esta fase, que también se podría denominar de diseño conceptual, consiste en obtener a partir del análisis de requerimientos y de los procesos de negocio de la compañía, diseñar los procesos de negocio futuros que utilizaremos al trabajar con la solución EPR. En algunos casos, esto implicará cierta reingeniería de procesos y la participación de consultores especializados será muy valiosa para poder utilizar las mejores prácticas del sector.

Además en esta fase se identifican las funcionalidades que no son cubiertas por el estándar de la solución. Estas funcionalidades deberán ser documentadas en los diseños funcionales y validadas por el usuario.

Fase 3. Implantación y Puesta en Marcha

En esta fase, que resulta crítica para el éxito final del proyecto, se deberán parametrizar los requerimientos y los procesos diseñados en la fase anterior. Para ello se prototipan una serie de escenarios de negocio con datos reales que deberán validar los usuarios. Además se programan los desarrollos identificados en la fase anterior, incluidos formularios, etiquetas e informes y se documentan con diseños técnicos. Por último y al igual que en la fase de Análisis y Diagnosis, resulta clave la formación de los usuarios, esta vez, sobre la "nueva" solución que nos permitirá estar en disposición de proceder a lo que comúnmente se conoce como "arrancada", donde es de vital importancia contar con un consultor especializado en la solución a implantar.

Fase 4. Explotación, Soporte y Mantenimiento

Constituye la última fase de la metodología de implantación y tiene como objetivo fundamental asegurar la asimilación y correcto funcionamiento de la nueva solución. En ella se deberán realizar las correcciones de posibles incidencias y se continuara apoyando a los usuarios para una óptima explotación diaria de la solución. En este sentido, el contar con un servicio Hot-Line de garantías, así como la posibilidad de asistencia vía comunicaciones asegurará la más alta disponibilidad de la solución implantada.

Y después de esta fase...¿podemos dar por concluido el proyecto?. La respuesta sería no, pues un proyecto de gestión o de implantación de un ERP no debería terminar nunca, pues todos los participantes deben tender a lo que se denomina Mejora Continua. A partir de aquí, deberemos empezar a pensar en un proyecto de Archiving, ya que el crecimiento de la base de datos nos abrumará; deberemos empezar a pensar en un cambio de versión o ampliaciones de producto que aporten nuevas funcionalidad que nos permitan seguir creando ventajas competitivas (CRM, e-business, herramientas analíticas – BSC/ABC -) o incluso en mejorar los procesos diseñados....deberemos en definitiva, ir adaptando la solución a las necesidades derivadas del crecimiento de nuestra empresa.

Complexity - SEBOK (15)

Complexity

This article is part of the Systems Fundamentals Knowledge Area (KA). It gives the background and an indication of current thinking on complexity and how it influences systems engineering (SE) practice. Complexity is one of the most important and difficult to define system concepts. Is a system's complexity in the eye of the beholder, or is there inherent complexity in how systems are organized? Is there a single definitive definition of complexity and, if so, how can it be assessed and measured? This topic will discuss how these ideas relate to the general definitions of a system given in What is a System?, and in particular to the different engineered system contexts. This article is closely related to the emergence topic that follows it.

Origins and Characteristics of Complexity

This section describes some of the prevailing ideas on complexity. Various authors have used different language to express these ideas. While a number of common threads can be seen, some of the ideas take different viewpoints and may be contradictory in nature.

One of the most widely used definitions of complexity is the degree of difficulty in predicting the properties of a system if the properties of the system's parts are given (generally attributed to Weaver). This, in turn, is related to the number of elements and connections between them. Weaver (1948) relates complexity to types of elements and how they interact. He describes simplicity as problems with a finite number of variables and interaction, and identifies two kinds of complexity:

1. Disorganized Complexity is found in a system with many loosely coupled, disorganized and equal elements, which possesses certain average properties such as temperature or pressure. Such a system can be described by “19th Century” statistical analysis techniques.

2. Organized Complexity can be found in a system with many strongly coupled, organized and different elements which possess certain emergent properties and phenomena such as those exhibited by economic, political or social systems. Such a system can not be described well by traditional analysis techniques. Weaver's ideas about this new kind of complex problem are one of the foundational ideas of systems thinking.

Later authors, such as Flood and Carson (1993) and Lawson (2010), expand organized complexity to systems which have been organized into a structure intended to be understood and thus amenable to engineering and life cycle management (Braha et al. 2006). They also suggest that disorganized complexity could result from a heterogeneous complex system evolving without explicit architectural control during its life (complexity creep).

However, "complexity" should not be confused with "complicated". Complexity is a system property related to the kinds of elements and relationships, not simply to their number. Ordered systems have fixed relationships between elements and are not adaptable.

Complex systems may evolve “to the edge of chaos”, resulting in systems which can appear deterministic but which exhibit counter intuitive behavior compared to that of more ordered systems. The statistics of chance events in a complex system are often characterized by a power-law distribution, the “signature of complexity” (Sheard 2005).

Objective complexity is an attribute of complex systems and is a measure of where a system sits on this spectrum. It is defined as the extent to which future states of the system cannot be predicted with certainty and precision, regardless of our knowledge of current state and history. Subjective complexity is a measure of how easy it is for an observer to understand a system or predict what it will do next. As such, it is a function of the perspective and comprehension of each individual. It is important to be prepared to mitigate subjective complexity with consistent, clear communication and strong stakeholder engagement (Sillitto 2009).

Due to the variability of human behavior as part of a system and the perceptions of people outside the system, the inclusion of people in a system is often a factor in their complexity. People may be viewed as observing systems or as system elements which contribute to the other types of complexity (Axelrod and Cohen 1999). The rational or irrational behavior of individuals in particular situations is a vital factor in respect to complexity (Kline 1995).

Defining System Complexity

Sheard and Mostashari (2011) synthesize many of the ideas described above to categorize complexity as follows:

1. Structural Complexity looks at the system elements and relationships. In particular, structural complexity looks at how many different ways system elements can be combined. Thus, it is related to the potential for the system to adapt to external needs.

2. Dynamic Complexity considers the complexity which can be observed when systems are used to perform particular tasks in an environment. There is a time element to dynamic complexity. The ways in which systems interact in the short term is directly related to system behavior; the longer term effects of using systems in an environment is related to system evolution.

3. Socio-political Complexity considers the effect of individuals or groups of people on complexity. People-related complexity has two aspects. One is related to the perception of a situation as complex or not, due to multiple stakeholder viewpoints within a system context and social or cultural biases which add to the wider influences on a system context. The other involves either the “irrational” behavior of an individual or the swarm behavior of many people behaving individually in ways that make sense; however, the emergent behavior is unpredicted and perhaps counterproductive. This latter type is based on the interactions of the people according to their various interrelationships and is often graphed using systems dynamics formalisms.

Thus, complexity is a measure of how difficult it is to understand how a system will behave or to predict the consequences of changing it. It occurs when there is no simple relationship between what an individual element does and what the system as a whole will do, and when the system includes some element of adaptation or problem solving to achieve its goals in different situations.

Complexity and Engineered Systems

The different perspectives on complexity are not independent when considered across a systems context. Both problem situations and potential solutions may contain subjective and objective complexity; structural complexity of a system-of-interest (SoI) may be related to dynamic complexity when the SoI also functions as part of a wider system in different problem scenarios. People are involved in most system contexts, as system elements and as part of the operating environment. People are also involved with systems throughout the lifetimes of those systems.

The main focus for systems approaches is organized complexity, the ways we choose to structure system elements to help manage and mitigate both objective and subjective complexity. Sillitto (2009) considers the link between the types of system complexity and system architecture. The ability to understand, manage and respond to both objective and subjective complexity be they in the problem situation, the systems we develop or the systems we use to develop and sustain them is a key component of the Systems Approach Applied to Engineered Systems and hence to the practice of systems engineering.