Integración del ERP (2/2) (48)

La integración de sistemas es esencial. Sin embargo, la integración de personas es un gran desafío. Por razones de espacio esta nota está desarrollada parcialmente.

Hacia finales de los años 80 las empresas comenzaron a reconocer el valor del planeamiento de ventas y operaciones. Fundamentalmente el balance entre la demanda y el plan de capacidad operacional. Un liderazgo integrado describe el modo en que el CEO lidera la estrategia desde arriba hacia abajo (top-down) y replantea desde abajo hacia arriba (bottom up), basado en información honesta, correcta y realista.

Esto requiere que todas las personas se involucren, no solo ventas y operaciones. El desafío es que todos en la organización sean honestos con lo que entregan y que manejen un único conjunto de números. No quiere decir un juego de números de finanzas, otro de operaciones, otro de ventas, otro de marketing. En algún momento, todas las compañías necesitan una versión de la verdad”.

Asegurar que el equipo gerencial tiene entusiasmo y compromiso con el proyecto: hay ejecutivos de primer nivel creen que la implementación de un software puede sub contratarse a terceros. Pero sub contratar implementación es sub contratar responsabilidades.

Desafortunadamente la implementación es menos seductora que adquirir un negocio o lanzar un nuevo producto. Los tecnófobos no quieren involucrarse en proyectos de IT que, generalmente, son largos, aburridos y cargados de conflictos.

Asegurar que los datos de la compañía sean precisos: una causa frecuente de la falla de proyectos de ERP es la pérdida de datos precisos. Datos de inventarios, listas de materiales o asignación de rutas son tres de los culpables claves.

En un ERP integrado todo es necesario para asegurar la confiabilidad y precisión de los datos. Las cuestiones claves son limpiar los procesos que hicieron crecer los datos malos y asegurar que, luego de la entrada del sistema en producción, habrá disciplina para mantener la calidad de los datos.

Asegurar que hay una línea de responsabilidad en el negocio para el éxito del proyecto: los gerentes de la empresa (Marketing, Operaciones, Finanzas, Producción y las otras) son responsables del éxito de la implementación y funcionamiento del ERP. El equipo del proyecto debe responsabilizarse por entregar el mismo en sintonía con el negocio. La clave está en evitar que el equipo trabaje en una torre de marfil desarrollando procesos, sistemas, entrenando gente a usar el producto y demás tareas. Asegurar que el 100% de las personas del negocio hayan sido educadas (no entrenadas) en el nuevo sistema y los modos de usarlo: la diferencia entre educación y entrenamiento es crítica.

Educar es cambiar el corazón y mente para aceptar la necesidad del nuevo sistema y los procedimientos formales que implica. Esto significa, entre otras cosas, evitar prácticas pobres como operar con doble juego de números (Ejemplo: uno para el presupuesto y otro para propósitos operacionales).

Usar una prueba o simulación como un método para experimentar y validar el sistema antes que el ERP ingrese en la etapa de producción: la forma clásica para asegurar la aceptación de un sistema empresarial es ejecutar cuidadosamente guiones y rutinas piloto que prueben que las expectativas previstas para un grupo de transacciones producen los resultados esperados. Sin embargo, esto no prueba la potencia combinada del sistema, los procesos y personas trabajando todos simultáneamente y menos si la gente está preparada para realizar su trabajo en el nuevo escenario. Asegurar que el sistema está basado en funcionalidades estándar: ciertamente, los ERP modernos poseen una enorme cantidad de funcionalidad construida. Y siempre, para los usuarios, es una tentación construir funcionalidad más compleja dentro de la aplicación.

Sin embargo, en muchos productos de software hay ocasiones donde el sistema no hace lo correcto” por alguna razón. Y aquí se produce un conflicto pues pretenden que el sistema haga lo que ellos no saben explicar cómo hacer.

Types of Models - SEBOK (24)

There are many different types of models (glossary) expressed in a diverse array of modeling languages and tool sets. This article offers a taxonomy of model types and highlights how different models must work together to support broader engineering efforts.

Model Classification

There are many different types of models and associated modeling languages to address different aspects of a system and different types of systems. Since different models serve different purposes, a classification of models can be useful for selecting the right type of model for the intended purpose and scope.

Formal versus Informal Models

Since a system model is a representation of a system, many different expressions that vary in degrees of formalism could be considered models. In particular, one could draw a picture of a system and consider it a model. Similarly, one could write a description of a system in text, and refer to that as a model. Both examples are representations of a system. However, unless there is some agreement on the meaning of the terms, there is a potential lack of precision and the possibility of ambiguity in the representation. The primary focus of system modeling is to use models supported by a well-defined modeling language. While less formal representations can be useful, a model must meet certain expectations for it to be considered within the scope of model-based systems engineering (MBSE). In particular, the initial classification distinguishes between informal and formal models as supported by a modeling language with a defined syntax and the semantics for the relevant domain of interest.

Physical Models versus Abstract Models

The United States “Department of Defense Modeling and Simulation (M&S) Glossary” asserts that “a model can be [a] physical, mathematical, or otherwise logical representation of a system” (1998). This definition provides a starting point for a high level model classification. A physical model is a concrete representation that is distinguished from the mathematical and logical models, both of which are more abstract representations of the system. The abstract model can be further classified as descriptive (similar to logical) or analytical (similar to mathematical).

Descriptive Models

A descriptive model describes logical relationships, such as the system's whole-part relationship that defines its parts tree, the interconnection between its parts, the functions that its components perform, or the test cases that are used to verify the system requirements. Typical descriptive models may include those that describe the functional or physical architecture of a system, or the three dimensional geometric representation of a system.

Analytical Models

An analytical model (glossary) describes mathematical relationships, such as differential equations that support quantifiable analysis about the system parameters. Analytical models can be further classified into dynamic and static models. Dynamic models describe the time-varying state of a system, whereas static models perform computations that do not represent the time-varying state of a system. A dynamic model may represent the performance of a system, such as the aircraft position, velocity, acceleration, and fuel consumption over time. A static model may represent the mass properties estimate or reliability prediction of a system or component.

Hybrid Descriptive and Analytical Models

A particular model may include descriptive and analytical aspects as described above, but models may favor one aspect or the other. The logical relationships of a descriptive model can also be analyzed, and inferences can be made to reason about the system. Nevertheless, logical analysis provides different insights than a quantitative analysis of system parameters.

System Models

System models can be hybrid models that are both descriptive and analytical. They often span several modeling domains that must be integrated to ensure a consistent and cohesive system representation. As such, the system model must provide both general-purpose system constructs and domain-specific constructs that are shared across modeling domains. A system model may comprise multiple views to support planning, requirements, design, analysis, and verification.

Integration of Models

Many different types of models may be developed as artifacts of a MBSE effort. Many other domain-specific models are created for component design and analysis. The different descriptive and analytical models must be integrated in order to fully realize the benefits of a model-based approach. The role of MBSE as the models integrate across multiple domains is a primary theme in the International Council on Systems Engineering (INCOSE) INCOSE Systems Engineering Vision 2020 (2007).

As an example, system models can be used to specify the components of the system. The descriptive model of the system architecture may be used to identify and partition the components of the system and define their interconnection or other relationships. Analytical models for performance, physical, and other quality characteristics, such as reliability, may be employed to determine the required values for specific component properties to satisfy the system requirements. An executable system model that represents the interaction of the system components may be used to validate that the component requirements can satisfy the system behavioral requirements. The descriptive, analytical, and executable system model each represent different facets of the same system.

The component designs must satisfy the component requirements that are specified by the system models. As a result, the component design and analysis models must have some level of integration to ensure that the design model is traceable to the requirements model. The different design disciplines for electrical, mechanical, and software each create their own models representing different facets of the same system. It is evident that the different models must be sufficiently integrated to ensure a cohesive system solution.

To support the integration, the models must establish semantic interoperability to ensure that a construct in one model has the same meaning as a corresponding construct in another model. This information must also be exchanged between modeling tools. One approach to semantic interoperability is to use model transformations between different models.

Transformations are defined which establish correspondence between the concepts in one model and the concepts in another. In addition to establishing correspondence, the tools must have a means to exchange the model data and share the transformation information. There are multiple means for exchanging data between tools, including file exchange, use of application program interfaces (API), and a shared repository. The use of modeling standards for modeling languages, model transformations, and data exchange is an important enabler of integration across modeling domains.

System Model - SEBOK (23)

System models can be used for many purposes. This topic highlights some of those purposes, and provides indicators of an effective model, in the context of model-based systems engineering (MBSE).

Purpose of a Model

Models are representations that can aid in defining, analyzing, and communicating a set of concepts. System models are specifically developed to support analysis, specification, design, verification, and validation of a system, as well as to communicate certain information. One of the first principles of modeling is to clearly define the purpose of the model. Some of the purposes that models can serve throughout the system life cycle are

• Characterizing an existing system.

• Mission and system concept formulation and evaluation

• System design synthesis and requirements flowdown

• Support for system integration and verification

• Support for training

• Knowledge capture and system design evolution

Indicators of an Effective Model

When modeling is done well, a model’s purposes are clear and well-defined. The value of a model can be assessed in terms of how effectively it supports those purposes. The remainder of this section and the topics Types of Models, System Modeling Concepts, and Modeling Standards describe indicators of an effective model (Friedenthal, Moore, and Steiner 2009).

Model Scope

The model must be scoped to address its intended purpose. In particular, the types of models and associated modeling languages selected must support the specific needs to be met. For example, suppose models are constructed to support an aircraft’s development. A system architecture model may describe the interconnection among the airplane parts, a trajectory analysis model may analyze the airplane trajectory, and a fault tree analysis model may assess potential causes of airplane failure. For each type of model, the appropriate breadth, depth, and fidelity should be determined to address the model’s intended purpose. The model breadth reflects the system requirements coverage in terms of the degree to which the model must address the functional, interface, performance, and physical requirements, as well as other non-functional requirements, such as reliability, maintainability, and safety. For an airplane functional model, the model breadth may be required to address some or all of the functional requirements to power up, takeoff, fly, land, power down, and maintain the aircraft’s environment.

The model’s depth indicates the coverage of system decomposition from the system context down to the system components. For the airplane example, a model’s scope may require it to define the system context, ranging from the aircraft, the control tower, and the physical environment, down to the navigation subsystem and its components, such as the inertial measurement unit; and, perhaps down to lower-level parts of the inertial measurement unit.

The model’s fidelity indicates the level of detail the model must represent for any given part of the model. For example, a model that specifies the system interfaces may be fairly abstract and represent only the logical information content, such as aircraft status data; or, it may be much more detailed to support higher fidelity information, such as the encoding of a message in terms of bits, bytes, and signal characteristics. Fidelity can also refer to the precision of a computational model, such as the time step required for a simulation.

Indicators of Model Quality

The quality of a model should not be confused with the quality of the design that the model represents. For example, one may have a high-quality, computer-aided design model of a chair that accurately represents the design of the chair, yet the design itself may be flawed such that when one sits in the chair, it falls apart. A high quality model should provide a representation sufficient to assist the design team in assessing the quality of the design and uncovering design issues.

Model quality is often assessed in terms of the adherence of the model to modeling guidelines and the degree to which the model addresses its intended purpose. Typical examples of modeling guidelines include naming conventions, application of appropriate model annotations, proper use of modeling constructs, and applying model reuse considerations. Specific guidelines are different for different types of models. For example, the guidelines for developing a geometric model using a computer-aided design tool may include conventions for defining coordinate systems, dimensioning, and tolerances.

Integración de un ERP (1/2) (47)

Las soluciones que ofrece una empresa pretenden integrar “desde el tablero de control hasta la mesa de dirección”... y más allá: también aspiran a unir una cadena de valor desde el cliente del cliente hasta el proveedor del proveedor. No obstante, tal pretensión presenta varios obstáculos, por lo que la integración debe de trabajarse por niveles.

El primer problema que se busca resolver con la integración es comunicar el software A con el B mediante la homologación de sus códigos.

El segundo obstáculo a superar es integrar procesos, sin importar los sistemas que se usen. Los procesos deben ser transparentes, más allá de los códigos comunes. Con ese propósito, la empresa desarrolló un producto, a través del cual se pueden “mapear” los procesos, independientemente de las herramientas que estén interviniendo.

El tercer escollo a eliminar es la integración de la información. Además de que el software y los procesos estén integrados, es preciso que los directores tengan esa información en su mesa. Con el objetivo de poner disponible los datos de los diferentes procesos en un lugar único, se crea el portal de la empresa. De ese modo, el personal no tiene que entrar a las aplicaciones individuales para ver sus resultados.

El último paso de la integración se refiere al manejo productivo de los datos con los que se cuentan. Para la empresa, el final de la colaboración está englobado en su solución de Business Intelligence, que es una base de datos que captura la operación de todos los sistemas en una herramienta única de información, en tiempo real. El enorme énfasis que ha puesto la empresa en la integración se ha convertido en su ventaja competitiva.

Otra de sus ventajas competitivas es, sin duda, la velocidad del ERP para salir de la crisis. El pasado mes, la firma de este ERP estaba al borde la quiebra; ninguno de sus potenciales clientes querían escuchar las ventajas de sus nuevos productos y la competencia pensaba que ya era uno menos. Sin embargo, en esta era de competencia (una mezcla de colaboración y competencia), las firmas de software integrador tendrán que acostumbrarse a tomar en cuenta a la empresa de ERP.

Tres consultores ingleses describieron la implementación de un ERP como el equivalente a hacerse un tratamiento de conducto: es muy doloroso; es caro y a veces es preferible no hacerlo, aunque los especialistas digan que será mejor.

El ERP es un hueso duro de roer y a través de los años hay una buena cantidad de proyectos fallidos. Muchos de estos pueden atribuirse a fallas en uno o varios de los siete hábitos para una implementación exitosa. Se trata de hábitos porque muchos de los problemas subyacentes están relacionados con dificultades para afrontar cuestiones culturales dentro de la organización.

Las personas están acostumbradas a trabajar con métodos viejos y quieren continuar con esas formas. Están habituados a trabajar con datos inapropiados, fechas inválidas del sistema y otras ineficiencias. Mucha gente prefiere la informalidad a la formalidad. Tienen ciertos vicios. ¿Por qué cambiar estos hábitos a esta altura de la vida?

La implementación de un ERP trae consigo la necesidad de adoptar mayor formalidad en el trabajo y la adhesión a más procesos de los que la gente está acostumbrada. La verdad es que el mundo es más global, más competitivo y cambia muy rápido. Y en este contexto las empresas necesitan integrarse tanto en los negocios como en los países, industrias y culturas para poder sobrevivir.

Systems and Models - SEBOK (22)

Representing Systems with Models

A model (glossary) is an abstraction of a system that offers insight about one or more of the the system's aspects, such as its function, behavior, structure, properties, or cost. Modeling is a common practice that is shared by most engineering disciplines, such as (1) electrical engineering, which uses electrical circuit design models, (2) mechanical engineering, which uses three-dimensional computer-aided design models, and (3) software engineering, which uses software design models. Each of these disciplines has their own language, with its syntax and semantics, serving as a means of communication among professionals in that discipline. Analytic models are used to support power, thermal, structural, and embedded real-time analysis.

Modeling of systems as holistic, value-providing entities, has been gaining recognition as a central process of systems engineering (glossary). Modeling serves to make concepts concrete and formal, enhance quality, productivity, documentation, and innovation, as well as reduce the cost and risk of systems development. Different types of models may be needed to represent systems in support of the analysis, specification, design, and verification of systems. This knowledge area provides an overview of models used to represent different aspects of systems.

What is a Model?

This topic provides foundational concepts, such as definitions of a model and a modeling language, and expresses their relationships to modeling tools (glossary) and model-based systems engineering (MBSE).

Definition of a Model

There are many definitions of the word model. In the context of systems engineering, a model that represents a system and its environment is of particular importance to the system engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders. A variety of system models are used to represent different types of systems for different modeling purposes. The modeling standards topic refers to some of the standard system modeling languages and other modeling standards that support MBSE.

A physical model can be a mockup that represents an actual system, such as a model airplane.

A mathematical model may represent possible flight trajectories in terms of acceleration, speed, position, and orientation. A logical model may represent logical relationships that describe potential causes of airplane failure, such as how an engine failure can result in a loss of power and cause the airplane to lose altitude, or how the parts of the system are interconnected. It is apparent that many different models may be required to represent a system-of-interest (SoI).

Modeling Tools

Models are created by a modeler using modeling tools. For physical models, the modeling tools may include drills, lathes, and hammers. For more abstract models, the modeling tools are typically software programs running on a computer. These programs provide the ability to express modeling constructs using a particular modeling language.

A word processor can be viewed as a tool used to build text descriptions using natural language. In a similar way, modeling tools are used to build models using modeling languages. The tool often provides a tool palette to select symbols and a content area to construct the model from the graphical symbols or other concrete syntax. A modeling tool typically checks the model to evaluate whether it conforms to the rules of the language, and enforces such rules to help the modeler create a well-formed model. This is similar to the way a word processor checks the text to see that it conforms to the grammar rules for the natural language.

Some modeling tools are commercially available products, while others may be created or customized to provide unique modeling solutions. Modeling tools are often used as part of a broader set of engineering tools which constitute the systems development environment. There is increased emphasis on tool support for standard modeling languages that enable models and modeling information to be interchanged among different tools.

Relationship of Model to Model-Based Systems Engineering

The International Council of Systems Enginnering (INCOSE) INCOSE Systems Engineering Vision 2020 (2007) defines MBSE as “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” In MBSE, the models of the system are primary artifacts of the systems engineering process, and are managed, controlled, and integrated with other parts of the system technical baseline.

This contrasts with the traditional document-centric approach to systems engineering, where text-based documentation and specifications are managed and controlled. Leveraging a model-based approach to systems engineering is intended to result in significant improvements in system specification and design quality, lower risk and cost of system development by surfacing issues early in the design process, enhanced productivity through reuse of system artifacts, and improved communications among the system development team.

In addition to creating models, the MBSE approach typically includes methods for model management which aim to ensure that models are properly controlled and methods for model validation which aim to ensure that models accurately represent the systems being modeled.

Instalación global de un ERP (46)

Hay multinacionales que desean planificar sus recursos empresariales globales para unificar el funcionamiento a escala mundial de la compañía. Las empresas con estructuras de gestión centralizadas son candidatas ideales a la instalación de un ERP global para todas las delegaciones. Las empresas químicas, petroquímicas, fabricantes de chips, y en definitiva, aquellas cuyos productos no cambian de un país a otro son las perfectas candidatas.

Las ventajas de una implantación global son muchas, entre ellas:

- Simplifica la generación de informes.

- Sólo se mantiene una base de datos central.

- Se facilita la gestión de la tecnología.

Pero los obstáculos son muchos. Entre ellos se pueden presentar:

- Distintos husos horarios

- Demasiados usuarios. ¿Un servidor central puede soportar a tantos usuarios potenciales?.

- Distintos idiomas.

- Distinta moneda.

- Problemas en las telecomunicaciones.

- Tiempo de respuesta demasiado grande.

- Las copias de seguridad y el mantenimiento se pueden realizar cuando apenas hay actividad en la central (por las noches), pero en ese momento es una hora punta en otro lugar del mundo y se pueden encontrar con que el sistema no funciona o va muy lento.

- Con el soporte a los usuarios puede pasar lo mismo, y no tener servicio cuando más se necesita en la otra parte del mundo.

- Etc.

Pese a todo esto, se han realizado implantaciones globales con éxito, aunque siempre el coste aumenta un 20% sobre un proyecto nacional (hay que añadir al coste normal los viajes, los consultores contratados especialmente para esto, las traducciones necesarias, etc.).

Los principales beneficios que se pueden obtener son:

- Descuentos por contratos globales del ERP.

- Incremento de la facturación y recorte de costes.

- Entregas más rápidas a los clientes.

Consejos para la implantación de un ERP (3/3) (45)

El mayor factor de éxito en las implantaciones es la madurez de la organización

La experiencia previa, el conocimiento de sus propios procesos y la aplicación del sentido común en la estrategia de introducción de las TIC, en una palabra, la madurez tecnológica de una organización, es determinante para llevar a buen término un proyecto de estas características, independientemente del sector o tamaño de la empresa. Los datos del estudio nos indican claramente que las pymes tienen dificultad para saber lo que se quiere o se necesita, y que la visión estratégica de su negocio está poco desarrollada, por lo que la base de los proyectos en muchos casos es poco realista. Esto provoca la aparición de situaciones no previstas durante la ejecución, y constituye un serio factor de fracaso.

La falta de formación adecuada de las personas en las que reside la capacidad de decisión les lleva a confiar en exceso en argumentos comerciales y descuidar criterios que deberían tener mayor peso

El estudio revela que existe a nivel de dirección en las pymes cierto deslumbramiento por las características funcionales de determinados productos, y que pocas veces se realiza internamente un análisis adecuado de las tecnologías existentes y posibles formas de implantación, en relación directa con las necesidades /objetivos de la organización.

En este sentido, toma enorme importancia la figura del responsable o líder del proyecto como persona hipotéticamente conocedora tanto de la tecnología como de los objetivos de la organización, un mediador que coordine la actividad con capacidad de decisión, y un equipo de trabajo interno adecuado, pero los resultados del análisis indican que existen carencias a este nivel.

Con excesiva frecuencia se escogen tecnologías y proveedores poco conocidos por la pyme y técnicas de implementación excesivamente ambiciosas o poco graduales. Los problemas se traducen en fallos en la estrategia de la implantación, y necesidad de rediseño de procesos con alto nivel de impacto.

Las herramientas de gestión integral tienen un cierto nivel de desarrollo a título operacional, pero no pueden resolver cuestiones estratégicas o próximas al ámbito de la inteligencia de negocio

La importancia dada por las pymes a que las tecnologías sobre sistemas de gestión integral se adapten a sus necesidades o actividades es grande, tal y como ha quedado patente en el estudio realizado. Ello revela un deseo de que de alguna manera las herramientas se ajusten y sean útiles para resolver cuestiones estratégicas del negocio, muy especiales ya no sólo en cada sector de actividad, sino en cada empresa. El estudio nos ha indicado que sólo una tarea de diseño realizada desde el conocimiento de la propia empresa puede dar lugar a un sistema de gestión integral acorde con sus específicas necesidades y líneas de negocio, susceptible de ajustes y nuevas adaptaciones a la cambiante realidad.

Por lo general, la implementación de un ERP se hace por fases e inicia con el área administrativa contable, área en la cual se irán a reflejar las operaciones que se ejecutan en todas las demás áreas del sistema. A través del uso de un sistema ERP, las organizaciones logran ordenar los procesos fundamentales en su forma de operar, obteniendo grandes ventajas a través de llevar sus negocios con una integración completa de sus distintas áreas, de forma automatizada, optimizada y con los controles necesarios para poder guiar y percibir la forma en que se están desempeñando.

El máximo beneficio de la implantación de un ERP se obtiene cuando todas las áreas de la empresa están totalmente integradas y cuando esta integración se realiza en el menor plazo de tiempo posible y en forma óptima. Para lograr este beneficio, es esencial contar con una metodología adecuada, la cual garantice que el éxito del proyecto, y que tome en cuenta elementos tales como la idiosincracia del medio regional de la empresa, estructuración de equipos de trabajo de las partes involucradas en la implementación y que sea lo suficientemente flexible para que cada empresa marque el paso que más le convenga, según sus prioridades para alcanzar los objetivos y metas que se impusieron a la hora de adquirir el software.

Existen 2 variables principales implicadas entre el éxito total, el éxito parcial y el fracaso. Una es la razón por la cual e adopta el nuevo sistema en la empresa y la otra es si la compañía adopta el nuevo sistema el proceso de implementación en forma estructurada.

La tecnología suele ofrecer enormes oportunidades para remover estacas en el ámbito de los negocios, pero no siempre la introducción de una nueva tecnología viene acompañada de un replanteo de las reglas, de un cambio de nuestros hábitos y de liberar las posibilidades de ir más allá de los límites que nos fijaban las antiguas limitaciones.

El ERP es una poderosa herramienta para integrar los procesos de negocio, proveer información oportuna y segura, que contiene las mejores prácticas de administración de negocios, pero sin embargo no es suficiente para llevar adelante un proceso de transformación y obtener todos los beneficios que se podrían obtener de ella. La tecnología remueve restricciones pero no crea valor por si misma. El valor se obtiene diseñando procesos innovadores que permitan a las Empresas diferenciarse y crear verdaderas ventajas competitivas. Es en el proceso de cambio y no sólo en la herramienta donde está el verdadero desafío del empresario.

Principles of Systems Thinking - SEBOK (21)

This topic forms part of the Systems Thinking Knowledge Area (KA). It identifies systems principles as part of the basic ideas of systems thinking. Some additional concepts more directly associated with engineered systems are described, and a summary of system principles associated with the concepts already defined is provided.

Systems Principles, Laws, and Heuristics

A principle is a general rule of conduct or behavior (Lawson and Martin 2008). It can also be defined as a basic generalization that is accepted as true and that can be used as a basis for reasoning or conduct (WordWeb 2012c). Thus, systems principles can be used as a basis for reasoning about systems thinking or associated conduct (systems approaches).

Summary of Systems Principles

Regularity (glossary): Systems science should find and capture regularities in systems, because those regularities promote systems understanding and facilitate systems practice. (Bertalanffy 1968)

Holism (glossary): A system should be considered as a single entity, a whole, not just as a set of parts. (Ackoff 1979; Klir 2001)

Interaction The properties, capabilities, and behavior of a system are derived from its parts, from interactions between those parts, and from interactions with other systems. (Hitchins 2009 p. 60)

Relations A system is characterized by its relations: the interconnections between the elements. Feedback is a type of relation. The set of relations defines the network of the system. (Odum 1994)

Boundary (glossary): A boundary or membrane separates the system from the external world. It serves to concentrate interactions inside the system while allowing exchange with external systems. (Hoagland, Dodson, and Mauck 2001)

Synthesis (glossary): Systems can be created by choosing (conceiving, designing, selecting) the right parts, bringing them together to interact in the right way, and in orchestrating those interactions to create requisite properties of the whole, such that it performs with optimum effectiveness in its operational environment, so solving the problem that prompted its creation” (Hitchins 2008: 120).

Abstraction (glossary): A focus on essential characteristics is important in problem solving because it allows problem solvers to ignore the nonessential, thus simplifying the problem. (Sci-Tech Encyclopedia 2009; SearchCIO 2012; Pearce 2012)

Separation of Concerns

A larger problem is more effectively solved when decomposed into a set of smaller problems or concerns. (Erl 2012; Greer 2008)

View (glossary) Multiple views, each based on a system aspect or concern, are essential to understand a complex system or problem situation. One critical view is how concern relates to properties of the whole. (Edson 2008; Hybertson 2009)

Modularity (glossary): Unrelated parts of the system should be separated, and related parts of the system should be grouped together. (Griswold 1995; Wikipedia 2012a)

Encapsulation Hide internal parts and their interactions from the external environment. (Klerer 1993; IEEE 1990)

Similarity/Difference

Both the similarities and differences in systems should be recognized and accepted for what they are. (Bertalanffy 1975 p. 75; Hybertson 2009). Avoid forcing one size fits all, and avoid treating everything as entirely unique.

Dualism (glossary): Recognize dualities and consider how they are, or can be, harmonized in the context of a larger whole (Hybertson 2009)

Leverage (glossary): Achieve maximum leverage (Hybertson 2009). Because of the power versus generality tradeoff, leverage can be achieved by a complete solution (power) for a narrow class of problems, or by a partial solution for a broad class of problems (generality).

Change Change is necessary for growth and adaptation, and should be accepted and planned for as part of the natural order of things rather than something to be ignored, avoided, or prohibited (Bertalanffy 1968; Hybertson 2009).

Stability/ Change Things change at different rates, and entities or concepts at the stable end of the spectrum can and should be used to provide a guiding context for rapidly changing entities at the volatile end of the spectrum (Hybertson 2009). The study of complex adaptive systems can give guidance to system behavior and design in changing environments (Holland 1992).

Concepts of systems Thinking - SEBOK (20)

This article forms part of the Systems Thinking Knowledge Area (KA). It describes systems concepts (glossary), knowledge that can be used to understand problems and solutions to support systems thinking.

The concepts below have been synthesized from a number of sources, which are themselves summaries of concepts from other authors. Ackoff (1971) proposed a system of system concepts as part of general system theory (GST); Skyttner (2001) describes the main GST concepts from a number of systems science authors; Flood and Carlson (1993) give a description of concepts as an overview of systems thinking; Hitchins (2007) relates the concepts to systems engineering practice; and Lawson (2010) describes a system of system concepts where systems are categorized according to fundamental concepts, types, topologies, focus, complexity, and roles.

Wholeness and Interaction

A system is defined by a set of elements which exhibit sufficient cohesion (glossary), or "togetherness", to form a bounded whole (Hitchins 2007, Boardman and Sauser 2008).

According to Hitchins, interaction between elements is the "key" system concept (Hitchins 2009, p. 60). The focus on interactions and holism is a push-back against the perceived reductionist focus on parts and provides recognition that in complex systems, the interactions among parts is at least as important as the parts themselves.

An open system is defined by the interactions between system elements within a system boundary and by the interaction between system elements and other systems within an environment (glossary). The remaining concepts below apply to open systems.

Regularity

Regularity (glossary) is a uniformity or similarity that exists in multiple entities or at multiple times (Bertalanffy 1968). Regularities make science possible and engineering efficient and effective. Without regularities, we would be forced to consider every natural and artificial system problem and solution as unique. We would have no scientific laws, no categories or taxonomies, and each engineering effort would start from a clean slate.

Similarities and differences exist in any set or population. Every system problem or solution can be regarded as unique, but no problem/solution is in fact entirely unique. The nomothetic approach assumes regularities among entities and investigates what the regularities are. The idiographic approach assumes each entity is unique and investigates the unique qualities of entities, (Bertalanffy 1975). A very large amount of regularity exists in both natural systems and engineered systems. Patterns of systems thinking capture and exploit that regularity.

State and Behavior

Any quality or property of a system element is called an attribute. The state of a system is a set of system attributes at a given time. A system event describes any change to the environment of a system, and hence its state:

• Static - A single state exists with no events.

• Dynamic - Multiple possible stable states exist.

• Homeostatic - System is static but its elements are dynamic. The system maintains its state by internal adjustments.

A stable state is one in which a system will remain until another event occurs.

State can be monitored using state variables, values of attributes which indicate the system state. The set of possible values of state variables over time is called the "'state space'". State variables are generally continuous, but can be modeled using a finite state model (or, "state machine").

Ackoff (1971) considers "change" to be how a system is affected by events, and system behavior as the effect a system has upon its environment. A system can

• react to a request by turning on a light,

• respond to darkness by deciding to turn on the light

• act to turn on the lights at a fixed time, randomly or with discernible reasoning.

A stable system is one which has one or more stable states within an environment for a range of possible events:

• Deterministic systems have a one-to-one mapping of state variables to state space, allowing future states to be predicted from past states.

• Non-Deterministic systems have a many-to-many mapping of state variables; future state cannot be reliably predicted.

The relationship between determinism and system complexity, including the idea of chaotic systems, is further discussed in the Complexity article.

Function

Ackoff defines function as outcomes which contribute to goals or objectives. To have a function, a system must be able to provide the outcome in two or more different ways. (This is called Equifinality). This view of function and behavior is common in systems science. In this paradigm, all system elements have behavior of some kind; however, to be capable of functioning in certain ways requires a certain richness of behaviors.

The behavior of the resulting system is then assessed as a combination of function and effectiveness. In this case behavior is seen as an external property of the system as a whole and is often described as analogous to human or organic behavior (Hitchins 2009).

Hierarchy, Emergence and Complexity

System behavior is related to combinations of element behaviors. Most systems exhibit increasing variety; i.e., they have behavior resulting from the combination of element behaviors. The term "synergy", or weak emergence, is used to describe the idea that the whole is greater than the sum of the parts. This is generally true; however, it is also possible to get reducing variety, in which the whole function is less than the sum of the parts, (Hitchins 2007).

Complexity frequently takes the form of hierarchies (glossary). Hierarchic systems have some common properties independent of their specific content, and they will evolve far more quickly than non-hierarchic systems of comparable size (Simon 1996). A natural system hierarchy is a consequence of wholeness, with strongly cohesive elements grouping together forming structures which reduce complexity and increase robustness (Simons 1962).

Encapsulation (glossary) is the enclosing of one thing within another. It may also be described as the degree to which it is enclosed. System encapsulation encloses system elements and their interactions from the external environment, and usually involves a system boundary that hides the internal from the external; for example, the internal organs of the human body can be optimized to work effectively within tighly defined conditions because they are protected from extremes of environmental change.

Socio-technical systems form what are known as control hierarchies, with systems at a higher level having some ownership of control over those at lower levels. Hitchins (2009) describes how systems form "preferred patterns" which can be used to the enhanced stability of interacting systems hierarchies.

Looking across a hierarchy of systems generally reveals increasing complexity at the higher level, relating to both the structure of the system and how it is used. The term emergence describes behaviors emerging across a complex system hierarchy.

Effectiveness, Adaptation and Learning

Systems effectiveness is a measure of the system's ability to perform the functions necessary to achieve goals or objectives. Ackoff (1971) defines this as the product of the number of combinations of behavior to reach a function and the efficiency of each combination.

Hitchins (2007) describes effectiveness as a combination of performance (how well a function is done in ideal conditions), availability (how often the function is there when needed) and survivability (how likely is it that the system will be able to use the function fully).

System elements and their environment change in a positive, neutral or negative way in individual situations. An adaptive (glossary) system is one that is able to change itself or its environment if its effectiveness is insufficient to achieve its current or future objectives. Ackoff (1971) defines four types of adaptation, changing the environment or the system in response to internal or external factors. A system may also learn, improving its effectiveness over time, without any change in state or goal.

Consejos para la implantación deun ERP (2/3) (44)

El problema no que es el consultor conozca o no el sector de actividad de la empresa, sino que la empresa conozca sus propios procesos

El problema no es tanto que el consultor conozca el área, el sector (aunque no puede negarse su importancia), si no que el factor clave es que la empresa conozca lo que quiere gestionar, identificar la información que quiere controlar. Si la empresa lo tiene claro cualquier consultor experimentado puede satisfacer la necesidad de la empresa, con un software concreto, o con un desarrollo a medida.

Se ayuda poco al consultor. Las empresas, como consecuencia de la falta de profundidad del análisis previo, no son capaces de plasmar de forma meridianamente clara o documentalmente la finalidad que pretenden con el proyecto. Esto ayuda poco al consultor externo, que además, por naturaleza de actividad, obedece a determinado interés comercial.

La figura del consultor externo no puede sustituir al líder del proyecto, ni la propuesta de plan de trabajo de la consultora puede sustituir al planteamiento de proyecto que debe realizar la empresa. Se observa que los consultores más pequeños o menos conocidos tienden a realizar mayores desarrollos a medida, adecuados para proyectos de menor tamaño, y que también, en este nivel, son los que mejores resultados ofrecen.

Los consultores de mayor tamaño o más conocidos tienden a especializarse en adaptaciones de software bajo licencia y sus planteamientos encajan mejor con los proyectos de mayor importancia. Pero la adecuación a estos factores no puede sustituir el papel que tiene una definición clara de objetivos realizada por la empresa en el éxito del entendimiento con el consultor y en consecuencia, en el éxito del proyecto.

Las empresas de pequeño a mediano tamaño son las que más contentas están, las que menos problemas han detectado en la ejecución, y se observa una relación con la menor envergadura de proyecto. Si, envergadura global, al margen de que se vaya por fases.

La satisfacción disminuye al aumentar la envergadura del proyecto

Las empresas industriales son las que llevan adelante proyectos más complejos, porque son muchos procesos a gestionar y tienen un problema: integrar el proceso de producción, el control de calidad, y el control de los propios procesos. En otros sectores está más diluido. Comercio o servicios suele tener mayor diversificación de destinatarios de la información a gestionar y mayor necesidad de soluciones en las que deba tenerse en cuenta la comunicación, pero los procesos son menores. Si es una gran empresa, con delegaciones, ese aspecto cobrará de nuevo importancia, pero no supondrá por si mismo un aumento del nivel de exigencia de proyecto. Por tanto, a menor envergadura de proyecto, menores serán los procesos a gestionar, y menos personal impactado, por lo que se tendrá mayor control sobre el proyecto, y esto generará mayor satisfacción. Sin embargo, a mayor tamaño del proyecto, menor control y menor nivel de satisfacción se encuentra.

Las ayudas públicas pueden suponer un importante incentivo

Las obligaciones de pago y los costes evidentemente influyen en la marcha del proyecto. Las ayudas públicas existentes en España para incorporación de nuevas tecnologías aplicadas a la gestión empresarial, no afectan por igual sobre la decisión de las pymes. Sí las empresas de mayor tamaño parecen mantenerse al margen de su existencia, encontramos la situación contraria entre las de tamaño más reducido. A pesar de la existencia de este importante estímulo, para lograr una mayor influencia sobre las decisiones tomadas por las empresas, debe facilitarse su concordancia con la naturaleza y los plazos de los proyectos, así como con los resultados que se pretenden conseguir.

Las pymes confían en soluciones tecnológicas para solventar problemas organizativos

Los proyectos de implantación de sistemas de gestión integral se abordan desde un ámbito limitado, donde se espera de los consultores que cubran una serie de parcelas que deberían ser responsabilidad de la empresa.

La adaptación de la forma de trabajar de la organización al sistema que se implanta, como alternativa a una actividad de adaptación del sistema a la forma de trabajo de la organización, resulta un punto conflictivo.

El tipo de problemas coincide con los que pueden encontrarse en implantaciones de sistemas no tecnológicos, como ISO 9000, pero hay una consideración importante: En ISO 9000, la empresa sigue funcionando independientemente del éxito de la implantación. En un proyecto de gestión integral, si las cosas se hacen mal, la empresa puede llegar a paralizarse. La repercusión por tanto es mucho más importante, tanto en el corto plazo (a nivel del propio proyecto) como a medio/largo, por pérdida de competitividad de la organización.

Consejos para la implantación de un ERP (1/3) (43)

Los ERP son una herramienta poderosa para que una empresa pueda contar con información oportuna, exacta y relevante a todo nivel, que en el mercado actual, le llevará a incrementar y fortalecer su posición competitiva.

La apertura de los mercados y la constante evolución de la economía digital, influyen en las empresas, para quienes esta herramienta que integra y automatiza las principales área funcionales de la empresa y además dirige los procedimientos a seguir, son la base para la realización de sus labores de manera eficaz.

Los ERP son desarrollados con la finalidad de adaptarse a los procesos del giro de negocios de las empresas donde son utilizados y no a funciones de departamentos o estructuras. Es por ello, que se encuentran estructurados modularmente y cada módulo abarca los procesos propios de cada área operativa de la empresa.

La mayor parte de las implantaciones que no funcionan tanto a nivel de proyecto como de resultados se deben a una falta de previsión.

Pocas empresas se sientan seriamente a pensar y evaluar qué les interesa implantar, en qué áreas, y para qué y esto da lugar a implantaciones inadecuadas que no se corresponden con la necesidad real de la empresa y sobre todo con sus objetivos estratégicos. Hay un enorme impulso de la dirección, pero se cuenta poco con la opinión de los departamentos de las empresas, y menos aún de los usuarios, por lo que se dan habitualmente situaciones creadas por falta de previsión.

Se detecta más madurez en aquellas empresas que ya tienen un sistema de gestión implantado, y que han tenido tiempo para asimilar el anterior.

Las empresas con experiencia previa han tenido tiempo para pensar si evaluaron bien los objetivos, y se denota una mayor madurez en la decisión sobre cómo ampliar el sistema. En consecuencia, existe cierta inmadurez en implantación de sistemas nuevos, a pesar de la enorme trascendencia que tiene esa decisión para la empresa. Se observa poco estudio serio tanto de necesidades y objetivos como de opciones, conocimiento de la tecnología, y análisis de costes.

Se presta poca atención a evaluar el impacto de la implementación

A la hora de tomar la decisión de implantar un sistema nuevo o modificar el existente, no se evalúan correctamente las limitaciones existentes, ni si la empresa está preparada. La mayoría de las empresas no están suficientemente capacitadas como para asumir un cambio tan brusco en poco tiempo y no se estudia con profundidad la duración del proceso y sus implicaciones. Frente a la situación deseable, con un cumplimiento aproximado de fases previstas, nos encontramos con problemas de adaptación y retrasos, sobre todo en aquellas implantaciones donde se realiza la transición de forma rápida, abarcando varias áreas a la vez.

Los beneficios de implantar un sistema de gestión integral están claros para las empresas.

Los beneficios que proporciona el sistema parecen evidentes para las empresas, aún en el corto plazo. Lo que supone dirigir la empresa a tiempo real, tener un control de la empresa es valorado de forma muy positiva, a pesar de los problemas de implantación. Son conscientes de que cuando termina el proyecto, el resultado mejora la situación previa.

Los fallos son solventables

La empresa se puede equivocar en la decisión sobre el software, o en el tipo de implantación elegida, pero la mayoría de equivocaciones tienen solución. Probablemente los errores supondrán horas adicionales de consultoría, y más esfuerzos, pero todo en todo caso son solventables. Donde más problemas se detectan es en la ejecución del proyecto, por tanto resulta fundamental estudiar muy bien el sistema antes de implantarlo y tener claro cómo se va a gestionar el propio proyecto mientras se ejecuta, tener una actitud previsora. Al tomar la decisión hay que asumir que todo lleva un tiempo y no ponerse prisas, ni plazos poco realistas. Una buena forma de solventar problemas es pararse si es preciso a mitad de implantación para evaluar si las cosas van por donde tienen que ir.

El ritmo de implantación debe ser establecido por la empresa, así como la decisión de pasar de una fase a otra

La propia gestión debe ser iniciativa de la empresa, no de los consultores. El impulso, la iniciativa, los tiempos deben ser siempre decididos por la empresa. Y cuando eso no pasa, es signo de que la empresa no está madura para la implantación y son entonces los consultores quienes asumen ese papel. En muchas ocasiones las empresas califican este fenómeno como “confianza” en el proveedor, pero no es más que una falta de capacidad de la empresa.

Systems Thinking - SEBOK (19)

This knowledge area (KA) provides a guide to knowledge about systems thinking which is the integrating paradigm for systems science and systems approaches to practice. This is part of the wider systems knowledge which can help to provide a common language and intellectual foundation; and make practical systems concepts, principles, patterns and tools accessible to systems engineering (SE).

Systems thinking is concerned with understanding or intervening in problem situations, based on the principles and concepts of the systems paradigm. This KA offers some basic definitions of systems thinking. The following diagram summarizes how the knowledge is presented.

Systems thinking considers the similarities between systems from different domains in terms of a set of common systems concepts, principles and patterns:

• A principle is a rule of conduct or behavior. To take this further, a principle is a “basic generalization that is accepted as true and that can be used as a basis for reasoning or conduct” (WordWeb.com).

• A concept is an abstraction, or a general idea inferred or derived from specific instances.

Principles depend on concepts in order to state a “truth.” Hence, principles and concepts go hand in hand; principles cannot exist without concepts and concepts are not very useful without principles to help guide the proper way to act (Lawson and Martin 2008).

Many sources combine both concepts and the principles based on them. The Concepts of Systems Thinking topic presents concepts extracted from a variety of theory and practice sources. The Principles of Systems Thinking topic, in turn, presents a summary of important principles referring back to the concepts upon which they are based is also provided.

A pattern is an expression of observable similarities found in systems from different domains. Patterns exist in both natural and man-made systems and are used in systems science and systems engineering. A summary of the different classes of patterns and the use of patterns to support a systems approach is discussed in the final Patterns of Systems Thinking topic.

The practical application of systems thinking often employs the use of abstract system representations or models.

What is Systems Thinking?

This topic is part of the Systems Thinking Knowledge Area (KA). The scope of systems thinking is a starting point for dealing with real world situations using a set of related systems concept discussed in Concepts of Systems Thinking topic, systems principles discussed in Principles of Systems Thinking topic, and system patterns discussed in Patterns of Systems Thinking topic.

Introduction

The concepts, principles, and patterns of systems thinking have arisen both from the work of systems scientists and from the work of practitioners applying the insights of systems science to real-world problems.

Holism (glossary) has been a dominant theme in systems thinking for nearly a century, in recognition of the need to consider a system as a whole because of observed phenomena such as emergence. Proponents have included Wertheimer, Smuts, Bertalanffy, Weiss, (Ackoff, 1979), (Klir, 2001), and (Koestler, 1967) among many others.

A more detailed discussion of the most important movements in systems theory can be found in History of Systems Science.

Identifying Systems of Interest

When humans observe or interact with a system, they allocate boundaries and names to parts of the system. This naming may follow the natural hierarchy of the system, but will also reflect the needs and experience of the observer to associate elements with common attributes of purposes relevant to their own. Thus, a number of system-of-interests (SoIs) (Flood and Carson 1993) must be identified and they must be both relevant and include a set of elements which represent a system whole. This way of observing systems wherein the complex system relationships are focused around a particular system boundary is called systemic resolution.

Systems thinking requires an ongoing process of attention and adaptation to ensure that one has appropriately identified boundaries, dependencies, and relationships. Churchman (1968) and others have also considered broader ethical, political and social questions related to management science with regards to the relative power and responsibility of the participants in system interventions. These are seen by critical systems thinkers as key factors to be considered in defining problem system boundaries.

A system context can be used to define a SoI and to capture and agree on the important relationships between it, such as the systems it works directly with and the systems which influence it in some way. When this approach is used to focus on part of a larger system, a balance of reductionism and holism is applied. This balance sits at the heart of a systems approach. A systems context provides the tool for applying this balance, and is thus an essential part of any systems approach and hence, of SE as well. Approaches for describing the context of the different types of engineered systems are discussed in Engineered System Context topic within the Systems Approach Applied to Engineered Systems knowledge area.

Systems Thinking and the Guide to the Systems Engineering Body of Knowledge

From these discussions one can see systems thinking as both a set of founding ideas for the development of systems theories and practices and also as a pervasive way of thinking need by those developing and applying them. The Guide to the Systems Engineering Body of Knowledge (SEBoK) is particularly interested in how Systems Thinking can support a Systems Approach Applied to Engineered Systems.

In order to examine a SoI in more detail, to understand, use, or change them in some way, practitioners are faced with an apparent “systems thinking paradox”. One can only truly understand a system by considering all of its possible relationships and interactions, inside and outside of its boundary and in all possible future situations (of both system creation and life), but this makes it apparently impossible for people to understand a system or to predict all of the consequences of changes to it.

If this means that all possible system relationships and environmental conditions must be considered to fully understand the consequences of creating or changing a system, what useful work can be done?

In many ways this is the essence of all human endeavors, whether they are technical, managerial, social or political, the so called known knowns and unknown unknowns. The systems approach is a way of tackling real world problems and making use of the concepts, principle and patterns of systems thinking to enable systems to be engineered and used.

The systems principles of encapsulation and separation of concerns in Principles of Systems Thinking relate to this issue. Some of the detail of complex situations must be hidden to allow focus on changes to a system element. The impact must be considered of any changes that might be made across sufficient related system components to fit within the acceptable commercial and social risks that must be considered. Engineering and management disciplines deal with this by gathering as much knowledge as necessary to proceed at a risk level acceptable to the required need. The assessment of what is enough and how much risk to take can, to some extent, be codified with rules and regulations, and managed through processes and procedures; however, it is ultimately a combination of the skill and judgment of the individuals performing the work.

Systems Approaches - SEBOK (18)

This article is part of the Systems Science Knowledge Area (KA). It presents issues in the comparison and analysis of systems approaches by the systems science community. Some of these ideas contribute to basic theory and methods that are used in systems thinking discussed in the Systems Thinking KA.

What is a Systems Approach?

In Bertalanffy's introduction to his 1968 General System Theory (glossary) (GST) book, he characterizes a systems approach as: “A certain objective is given; to find ways and means for its realization requires the system specialist (or team of specialists) to consider alternative solutions and to choose those promising optimization at maximum efficiency and minimum cost in a tremendously complex network of interactions”. (Bertalanffy 1968, 4)

He goes on to list as possible elements of a systems approach: “classical” systems theory (differential equations), computerization and simulation, compartment theory, set theory, graph theory, net theory, cybernetics, information theory, theory of automata, game theory, decision theory, queuing theory, and models in ordinary language.

This description is similar to what Warren Weaver identified as the methods used successfully by “mixed teams” during World War II (WWII) on “problems of organized complexity”. However, some conditions that had contributed to success during wartime did not hold after the war, such as a clear focus on well-defined common goals that motivated participants to work across disciplinary boundaries.

By the early 1970’s, there was growing disillusionment with the promise that a systems approach would provide easy solutions for all complex problems. There was particular criticism from some, including pioneers of Operations Research and Management Science (ORMS) like Ackoff and Churchman, that reliance on rote mathematical methods to identify optimal solutions among fixed alternatives had become just as inflexible and unimaginative an approach to complex problems as whatever it had replaced. Interest grew in examining and comparing methods and methodologies to better understand what could help ensure the best thinking and learning in terms of systems in systems approaches to practice.

Issues in Systems Approaches

A systems approach is strongly associated with systems thinking and how it helps to guides systems practice. In What is Systems Thinking? the key ideas of considering a system holistically, setting a boundary for a problem/ solution of interest, and considering the resulting system-of-interest from outside its boundary are identified (Senge, 2006), (Churchman 1979), Meadows (2010).

A systems approach can view a system as a “holon” – an entity that is itself a “whole system” that interacts with a mosaic of other holons in its wider environment (Hybertson, 2009), while also being made up of interacting parts.

We can use this model recursively – each part of the system may be a system in its own right, and can itself be viewed both as an entity as seen from outside, and as a set of interacting parts. This model also applies in upwards recursion, so the original “system-of-interest” is an interacting part of one or more wider systems.

This means that an important skill in a systems approach is to identify the “natural holons” in the problem situation and solution systems and to make the partitioning of responsibilities match the “natural holons”, so as to minimize the coupling between parallel activities when applying a solution. This is the “cohesive/loose coupling” heuristic that has been around for a long time in many design disciplines.

Another consequence of the holistic nature of a systems approach is that it considers not only a problem situation and a solution system but also the system created and deployed to apply one to the other. A systems approach must consider both the boundary of the system of concern as well as the boundary of the system inquiry (or model). Real systems are always open, i.e., they interact with their environment or supersystem(s). On the other hand, real models are always “closed” due to resource constraints — a fixed boundary of consideration must be set. So there is an ongoing negotiation to relate the two in systems practice and the judgment to do so is greatly helped by an appreciation of the difference between them.

Thus, a systems approach can be characterized by how it considers problems, solutions and the problem resolution process itself:

• Consider problems holistically, setting problem boundaries though understanding of natural system relationships and trying to avoid unwanted consequences.

• Create solutions based on sound system principles, in particular creating system structures which reduce organized complexity and unwanted emergent properties.

• Use understanding, judgment and models in both problem understanding and solution creation, while understanding the limitations of such views and models.

Systems Methodologies

One topic that has received significant attention in the systems science community is the analysis and comparison of methodologies which implement a systems approach. A methodology is a body of tools, procedures, and methods applied to a problem situation, ideally derived from a theoretical framework. These describe structured approaches to problem understanding and/or resolution making use of some of the concepts of systems thinking. These methodologies are generally associated with a particular system paradigm or way of thinking, which has a strong influence on the three aspects of a systems approach described above.

The most widely used groups of methodologies are as follows, see also History of Systems Science:

• Hard System (glossary) methodologies (Checkland 1978) set out to select an efficient means to achieve a predefined and agreed end.

• Soft System (glossary) methodologies (Checkland 1999) are interactive and participatory approaches to assist groups of diverse participants to alleviate a complex, problematic situation of common interest.

• Critical Systems Thinking (glossary) methodologies (Jackson 1985) attempts to provide a framework in which appropriate hard and soft methods can be applied as appropriate to the situation under investigation.

Beneficios de la implantación de un ERP (42)

Al momento de la decisión de la implementación de un ERP, la alta gerencia debería lograr algunas respuestas: ¿cómo podría el ERP fortalecer nuestras ventajas competitivas?, ¿Son las mejores prácticas de el ERP realmente las mejores para todas las industrias?, ¿Cuáles serán los beneficios tangibles e intangibles de esta inversión?, ¿Cuál será el efecto del sistema en nuestra organización y nuestra cultura?, ¿necesitaremos extender el sistema a todas nuestras funciones o deberían implementarse solamente ciertos módulos?

La importancia de los ERPs está fundada en que por primera vez las compañías disponen de un software con el cual pueden soportar un proceso completo del negocio. Los nuevos procesos y el software que lo soporta son una enorme fuerza para democratizar la información en una organización. La gente puede comprobar que ahora, en su tarea, comparte los datos y está comunicada con la gente que participa en el proceso completo. Los funcionarios de una organización no están ya más limitados por la información a la cual tiene acceso sino por su habilidad para sacarle el mejor provecho.

A partir del estudio de un gran número de casos, Shang y Seddon (2002) han definido un esquema estructurado donde clasificaron los beneficios resultantes de la implementación de un ERP. Si bien es cierto que no todas las Empresas han obtenido beneficios en todas las dimensiones descriptas y tampoco siquiera en la misma intensidad, el estudio nos permite situarnos en el contexto de los potenciales beneficios e intentar definir los objetivos para nuestra Empresa a la hora de establecer el retorno de inversión de un proyecto de implementación de un ERP. Algunos de ellos son:

1. Beneficios Operacionales producto de:

a. Reducción de costos, derivados en general de un mejor manejo de los inventarios y de los recursos productivos

b. Reducción del ciclo abastecimiento a partir de una mejor planificación

c. Mejoras de Productividad

d. Mejoras en la calidad de los datos

e. Mejoras en el servicio al cliente, en términos de calidad del producto, mejor servicio y cumplimiento de los plazos de entrega

2. Beneficios Gerenciales derivados fundamentalmente de la posibilidad de disponer de información oportuna y de mejor calidad:

a. Mejor administración de recursos

b. Mejora la toma de decisiones

c. Mejora la eficiencia del control

3. Beneficios Estratégicos:

a. Soporta planes de crecimiento presentes y futuros

b. Soporta alianzas, cambios, innovaciones en los negocios

c. Soporta diferenciación de productos

d. Soporta vínculos con los agentes externos

e. Facilita la internacionalización de los negocios

f. Facilita el comercio electrónico

4. Beneficios en la Infraestructura de IT:

a. Mejora la flexibilidad

b. Mejora las capacidades de la infraestructura de IT

5. Beneficios Organizacionales:

a. Soporta los cambios organizacionales

b. Facilita el aprendizaje del modelo de negocios y amplía el skill de los empleados

c. Empowerment

d. Cambia la cultura a través de una visión común

e. Mejora la moral y la satisfacción de los empleados

Por último, hay que reconocer que el impacto en la organización de los beneficios de negocios esperables por la implementación de un ERP está influido también por factores externos (como ser el contexto político y económico, características del sector industrial de que se trate, etc) y por factores internos (cultura, historia, recursos disponibles, capacidades, perspectivas de los accionistas, etc).

Existen dos factores pertenecientes al contexto interno de las organizaciones que suelen tener una influencia significativa en el éxito de la implantación de un ERP y los consecuentes beneficios de negocios para la organización:

1. la disponibilidad de recursos durante la fase de post-implementación y

2. el grado de cambio en las relaciones políticas, culturales y de poder dentro de la organización debidas al nuevo sistema.

Las experiencias demuestran que los beneficios de la implementación de un ERP pueden ser determinados recién después de varios años desde su puesta en marcha. Este período de tiempo, variable de una Organización a otra, ha sido descripto por Deloitte Consulting y bautizado como “la segunda ola” de revisión y modificación de lo hecho. Willcocks y Lester apuntan a que los beneficios financieros de la tecnología informática pueden tomar varios años antes de ser logrados debido al tiempo requerido para el aprendizaje y los ajustes a los procesos y a la tecnología.

Systems Science - SEBOK (17)

This Knowledge Area (KA) provides a guide to some of the major developments in systems science which is an interdisciplinary field of science that studies the nature of complex systems in nature, society, and engineering. This is part of the wider systems knowledge which can help to provide a common language and intellectual foundation; and make practical systems concepts, principles, patterns and tools accessible to systems engineering (SE)

Topics

Each part of the Guide to the SE Body of Knowledge (SEBoK) is divided into KAs, which are groupings of information with a related theme.

Systems Science brings together research into all aspects of systems with the goal of identifing, exploring, and understanding patterns of complexity which cross disciplinary fields and areas of application. It seeks to develop interdisciplinary foundations which can form the basis of theories applicable to all types of systems, independent of element type or application; additionally, it could form the foundations of a meta-discipline unifying traditional scientific specialisms.

An article on the History of Systems Science article describes some of the important multidisciplinary fields of research of which systems science is composed.

A second article presents and contrasts the underlying theories behind some of the system approaches taken in applying systems science to real problems.

People who think and act in a systems way are essential to the success of both research and practice. Successful systems research will not only apply systems thinking to the topic being researched but should also consider a systems thinking approach to the way the research is planned and conducted. It would also be of benefit to have people involved in research who have, at a minimum, an awareness of system practice and ideally are involved in practical applications of the theories they develop.

History of Systems Science

This article is part of the Systems Science Knowledge Area. It describes some of the important multidisciplinary fields of research comprising systems science in historical context.

Systems science, is an integrative discipline which brings together ideas from a wide range of sources which share a common systems theme. Some fundamental concepts now used in systems science have been present in other disciplines for many centuries, while equally fundamental concepts have independently emerged as recently as 40 years ago (Flood and Carson 1993).

The “Systems Problem”

Questions about the nature of systems, organization, and complexity are not specific to the modern age. As International Council on Systems Enginneering (INCOSE) pioneer and former International Society for System Sciences (ISSS) President John Warfield put it, “Virtually every important concept that backs up the key ideas emergent in systems literature is found in ancient literature and in the centuries that follow.” (Warfield 2006) It was not until around the middle of the 20th Century, however, that there was a growing sense of a need for, and possibility of a scientific approach to problems of organization and complexity in a “science of systems” per se.

The explosion of knowledge in the natural and physical sciences during the 18th and 19th centuries had made the creation of specialist disciplines inevitable: in order for science to advance, there was a need for scientists to become expert in a narrow field of study. The creation of educational structures to pass on this knowledge to the next generation of specialists perpetuated the fragmentation of knowledge (M’Pherson 1973). This increasing specialization of knowledge and education proved to be a strength rather than a weakness for problems which were suited to the prevailing scientific methods of experimental isolation and analytic reduction. However there were areas of both basic and applied science that were not adequately served by those methods alone.

The systems movement has its roots in two such areas of science: the biological-social sciences, and a mathematical-managerial base stemming first from cybernetics and operations research, and later from organizational theory.

Biologist Ludwig von Bertalanffy was one of the first to argue for and develop a broadly applicable scientific research approach based on Open System Theory (Bertalanffy 1950). He explained the scientific need for systems research in terms of the limitations of analytical procedures in science.

These limitations, often expressed as emergent evolution or "the whole is more than a sum of its parts”, are based on the idea that an entity can be resolved into and reconstituted from its parts, either material or conceptual:

This is the basic principle of "classical" science, which can be circumscribed in different ways: resolution into isolable causal trains or seeking for "atomic" units in the various fields of science, etc.

He stated that while the progress of "classical" science has shown that these principles, first enunciated by Galileo and Descartes, are highly successful in a wide realm of phenomena, but two conditions are required for these principles to apply:

The first is that interactions between "parts" be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be "worked out," actually, logically, and mathematically, and then be "put together." The second condition is that the relations describing the behavior of parts be linear; only then is the condition of summativity given, i.e., an equation describing the behavior of the total is of the same form as the equations describing the behavior of the parts These conditions are not fulfilled in the entities called systems, i.e. consisting of parts "in interaction" and description by nonlinear mathematics. These system entities describe many real world situations:populations, eco systems, organizations and complex man made technologies.

The methodological problem of systems theory is to provide for problems beyond the analytical-summative ones of classical science (Bertalanffy 1968, pp. 18-19).

Bertalanffy also cited a similar argument by mathematician and co-founder of information theory Warren Weaver in a 1948 American Scientist article on “Science and Complexity”. Weaver had served as Chief of the Applied Mathematics Panel at the U.S. Office of Scientific Research and Development during WWII. Based on those experiences, he proposed an agenda for what he termed a new “science of problems of organized complexity”. Weaver explained how the mathematical methods which had led to great successes of science to date were limited to problems where appropriate simplifying assumptions could be made.

What he termed “problems of simplicity” could be adequately addressed by the mathematics of mechanics, while “problems of disorganized complexity” could be successfully addressed by the mathematics of statistical mechanics. But with other problems, making the simplifying assumptions in order to use the methods would not lead to helpful solutions. Weaver placed in this category problems such as, how the genetic constitution of an organism expresses itself in the characteristics of the adult, and to what extent it is safe to rely on the free interplay of market forces if one wants to avoid wide swings from prosperity to depression. He noted that these were complex problems which involved “analyzing systems which are organic wholes, with their parts in close interrelation.”

These problems-and a wide range of similar problems in the biological, medical, psychological, economic, and political sciences-are just too complicated to yield to the old nineteenth century techniques which were so dramatically successful on two-, three-, or four-variable problems of simplicity. These new problems, moreover, cannot be handled with the statistical techniques so effective in describing average behavior in problems of disorganized complexity [problems with elements exhibiting random or unpredictable behaviour].

These new critical global problems require science to make a third great advance,

An advance that must be even greater than the nineteenth-century conquest of problems of simplicity or the twentieth-century victory over problems of disorganized complexity. Science must, over the next 50 years, learn to deal with these problems of organized complexity [problems for which complexity “emerges” from the coordinated interaction between its parts]. (Weaver, 1948)

Weaver identified two grounds for optimism in taking on this great challenge: 1) developments in mathematical modeling and digital simulation, and 2) the success during WWII of the “mixed team” approach of operations analysis, where individuals from across disciplines brought their skills and insights together to solve critical, complex problems.

The importance of modeling and simulation and the importance of working across disciplinary boundaries have been the key recurring themes in development of this “third way” science for systems problems of organized complexity.

Problemas en la implantación de un ERP (41)

Los problemas que se pueden ocasionar en la implementación de un ERP son:

1- Lentitud a la hora de implementar un ERP

Las compañías han creado islas de información, varios sistemas que operan o manejan diferentes segmentos del negocio. Todos estos sistemas que en su mayoría son independientes requieren mantenimiento; el costo operativo y administrativo de hacerlo, la mayoría de las veces en una forma redundante, es mayor que el de implementar otro sistema nuevo. La mayoría de las compañías fracasan al implementar los sistemas ERP porque esperan beneficios financieros diferentes a los que el paquete ofrece propiamente. En otras ocasiones se tratan de implementar sistemas que aunque parecen muy innovadores no cumplen con el perfil de sus necesidades características de un desarrollo de implementación.

Falta de un equipo de administración del cambio, falta de comunicación con todos los niveles del organigrama, falta de capacitación suficiente y pobre dimensionamiento de equipo son algunos de los problemas tradicionales de los proyectos de implementación de un ERP.

2- Costos Ocultos

Los diferentes software disponibles en el mercado son increíblemente caros, además, se debe de tener en cuenta los costos de capacitación del personal, adquisición de un servidor y redes adecuadas al ERP y la cantidad de información, bases de datos, pérdidas en productividad durante la implementación, adquisición de equipo de cómputo adecuado, pérdidas por reestructuración, análisis de los datos del ERP, consultoría, mantener personal especializado, implementación continua de equipos, depresión post ERP, etc. Estos costos pueden llegar a alcanzar hasta un millón de dólares, e incluso no funcionar en la empresa y convertirse en una pérdida total.

Otros costos a tener en cuenta serían: Costos de software, Costo de Hardware, Costo de mantenimiento, Costo de oportunidad por fallas del sistema y Costo de actualizaciones periódicas del sistema.

3- Falta o insuficiencia de planificación de un ERP

Una implementación será más complicada a medida que el conjunto de gente que está involucrada no esté convencida que la labor que desempeña resultará en un beneficio común, mientras menos habilidad tengan, y su disposición al trabajar en equipo. Antes de iniciar un proyecto, es importante crear dos equipos: el equipo de implementación que estará formado por 1) usuarios “expertos” es decir, gente que tiene conocimiento a profundidad de los procesos de su área, 2) jefes de módulo, cuyo cargo les permite tomar decisiones en relación con cambios en los procesos de un departamento dado. El segundo equipo es el equipo de administración del cambio (que suele integrarse de personal del departamento de recursos humanos o relaciones industriales) que transmita lo que está sucediendo, cambios y decisiones que se tomen, así como también deben ser catalizadores del cambio, logrando la participación de los empleados en las actividades necesarias para la implementación (como recolección de la información, pruebas de proceso, entrenamiento y puesta en marcha).

4- Falta de metodología para manejar el proyecto

Antes de iniciar un proyecto, es importante crear dos equipos: el equipo de implantación que estará formado por

1) usuarios “expertos” es decir, gente que tiene conocimiento a profundidad de los procesos de su área,

2) jefes de módulo, cuyo cargo les permite tomar decisiones en relación con cambios en los procesos de un departamento dado.

5- El input por parte de los usuarios fue incompleto

Para que los sistemas ERP trabajen de forma correcta se necesita la información de parte de los usuarios. Sin esta ningún sistema ERP por más bueno que sea no tendrá éxito a nivel organizacional. Esto quiere decir que el sistema necesita recoger información de usuarios para así manejar mejor la información y saber los puntos débiles y fuertes de la organización. Cuando no se cuenta con esta retroalimentación de información de parte del usuario hacia la organización a través del sistema ERP, la organización no llegara a saber nunca si su sistema tiene éxito o está destinada al fracaso. Es por eso que esta es una razón fundamental para llevar un sistema ERP al fracaso porque no se ven los resultados esperados.

6- Falta o insuficiencia de planificación de un ERP

Una implementación será más complicada a medida que el conjunto de gente que está involucrada no esté convencida que la labor que desempeña resultará en un beneficio común, mientras menos habilidad tengan, y su disposición al trabajar en equipo.

7- Falta de apoyo por parte de la alta gerencia.

Los altos directivos, son los primeros que deben de estar totalmente implicados en la implantación de un sistema ERP, ahora estos deben de encargarse que exista comunicación interna de cada uno de los movimientos que se vayan generando durante este proceso, para que los empleados sean participes de cada una de las etapas y se sientan, una pieza fundamental en el triunfo de la misma, y con esto, sentirán que están realizando una labor que les da sentido a sus vidas, a sus capacidades, y que llena sus expectativas de desarrollo individual. Alcanzando con esto, una coherencia entre los valores explícitos y las practicas reales.

Se debe generar y alcanzar un Desarrollo Organizacional, con el cual, la empresa podrá desarrollarse, madurar, evolucionar y/o adaptarse a los cambios. Se este concepto como: “una respuesta al cambio, una estrategia educativa compleja cuya finalidad es cambiar las creencias, actitudes, valores y estructuras de las organizaciones de tal forma que estas puedan adaptarse mejor a las nuevas tecnologías, mercados y retos así como al ritmo vertiginoso del cambio mismo”.

8- El manejo en las relaciones interpersonales

La interacción humana de una empresa es lo que marca la diferencia en el tipo de servicio o atención que se brinde a los clientes. Aunque cada día es más evidente el esfuerzo por contratar personas competentes para hacer a las empresas más eficientes, las propias características de los individuos pueden hacer que esta tarea sea muy difícil.

En un contexto más amplio cuando este tipo de fenómeno se presenta a cualquier nivel, la empresa se ve afectada. Esto se refleja en el deterioro de la calidad de sus productos, mayor cantidad de errores de trabajo pérdida de materiales. También se puede encontrar mala atención al público discusiones o riñas en el peor de los casos. El conflicto interpersonal tiende a manifestarse con otras características cuando se refiere al sector gerencial. Aquí la consecuencia del conflicto puede afectar la calidad de las decisiones y la agilidad de la gestión de los involucrados en el mismo.

Afortunadamente existen un buen número de herramientas para la solución de los conflictos que se lleguen a presentar. Así mismo también existen distintos enfoques conceptuales que abarcan un gran aspecto de alternativas, la Consejería, procesos de Sensibilización, aspectos disciplinarios, rotación de puestos, Capacitación en Comunicación, Negociación etc. No obstante cualquiera de estas, deben ser manejadas por profesionales que conozcan profundamente los procesos intra-personales e interpersonales que generan tales situaciones.

9- Las estrategias y el diseño de los procesos de negocios

Los procesos de negocio pueden ser vistos como un instructivo para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Hay dos tipos principales de procesos de negocio: los procesos centrales y los procesos de soporte. Si algo de esto o la estrategia de diseño de los procesos en los negocios no va bien es una causa para que los sistemas ERP fracasen.

Muchas veces los procesos resultan complejos de entender y difíciles de organizar, dado que involucran múltiples actividades, personas, departamentos, etc. La utilización de un modelo nos permite organizarlos y documentarlos con el fin de facilitar su descripción y entendimiento. Al modelar los procesos obtenemos múltiples beneficios:

• Tener una perspectiva completa del proceso de principio a fin.

• Localizar fallas, desconexiones y problemas

• Generar Soluciones a los problemas detectados

• Reducir el tiempo de ciclo

• Comunicar

Emergency - SEBOK (16)

This topic forms part of the Systems Fundamentals Knowledge Area (KA). It gives the background to some of the ways in which emergence has been described, as well as an indication of current thinking on what it is and how it influences systems engineering (SE) practice. It will discuss how these ideas relate to the general definitions of systems given in What is a System?; in particular, how they relate to different engineered system contexts. This topic is closely related to the complexity topic that precedes it. Emergence is a consequence of the fundamental system concepts of holism and interaction (Hitchins 2007, p. 27).

System wholes have behaviors and properties arising from the organization of their elements and their relationships, which only become apparent when the system is placed in different environments. Questions that arise from this definition include: What kinds of systems exhibit different kinds of emergence and under what conditions? Can emergence be predicted, and is it beneficial or detrimental to a system? How do we deal with emergence in the development and use of engineered systems? Can it be planned for? How? There are many varied and occasionally conflicting views on emergence. This topic presents the prevailing views and provides references for others.

Overview of Emergence

As defined by Checkland, emergence is “the principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts.” (Checkland 1999, p. 314). Emergent system behavior can be viewed as a consequence of the interactions and relationships between system elements rather than the behavior of individual elements. It emerges from a combination of the behavior and properties of the system elements and the systems structure or allowable interactions between the elements, and may be triggered or influenced by a stimulus from the systems environment.

Hitchins also notes that technological systems exhibit emergence. We can observe a number of levels of outcome which arise from interaction between elements in an engineered system context. At a simple level, some system outcomes or attributes have a fairly simple and well defined mapping to their elements; for example, center of gravity or top speed of a vehicle result from a combination of element properties and how they are combined. Other behaviors can be associated with these simple outcomes, but their value emerges in complex and less predictable ways across a system.

Emergence can always be observed at the highest level of system. However, Hitchins (2007, p.7) also points out that to the extent that the systems elements themselves can be considered as systems, they also exhibit emergence. Page (2009) refers to emergence as a “macro-level property.” Ryan (2007) contends that emergence is coupled to scope rather than system hierarchical levels. In Ryan’s terms, scope has to do with spatial dimensions (how system elements are related to each other) rather than hierarchical levels.

Types of Emergence

A variety of definitions of types of emergence exists. See Emmeche et al.(1997), Chroust (2003) and O’Connor and Wong (2006) for specific details of some of the variants. Page (2009) describes three types of emergence: "simple", "weak", and "strong".

According to Page, simple emergence is generated by the combination of element properties and relationships and occurs in non-complex or “ordered” systems (see Complexity) (2009). To achieve the emergent property of “controlled flight” we cannot consider only the wings, or the control system, or the propulsion system.

Page describes weak emergence as expected emergence which is desired (or at least allowed for) in the system structure (2009). However, since weak emergence is a product of a complex system, the actual level of emergence cannot be predicted just from knowledge of the characteristics of the individual system components.

The term strong emergence is used to describe unexpected emergence; that is, emergence not observed until the system is simulated or tested or, more alarmingly, until the system encounters in operation a situation that was not anticipated during design and development.

A type of system particularly subject to strong emergence is the System of Systems (SoS) (glossary). The reason for this is that the SoS, by definition, is composed of different systems that were designed to operate independently.

When these systems are operated together, the interaction among the parts of the system is likely to result in unexpected emergence. Chaotic or truly unpredictable emergence is likely for this class of systems.

Emergent Properties

Emergent properties can be defined as follows: “A property of a complex system is said to be ‘emergent’ [in the case when], although it arises out of the properties and relations characterizing its simpler constituents, it is neither predictable from, nor reducible to, these lower-level characteristics” (Honderich 1995, pg 224).

All systems can have emergent properties which may or may not be predictable or amenable to modeling, as discussed above. Much of the literature on complexity includes emergence as a defining characteristic of complex systems.

Claves de éxito de una implantación de ERP (40)

Para lograr una implantación satisfactoria de un ERP es imprescindible dirigir todos los esfuerzos en una misma dirección. Un sistema de información para la gestión ERP se puede definir como una aplicación de gestión empresarial que integra el flujo de información, consiguiendo así mejorar los procesos en distintas áreas (financiera, de operaciones, marketing, logística, comercial, recursos humanos).

El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos de respuesta a sus problemas así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de operación.

Los objetivos principales de los sistemas ERP son:

1.Optimización de los procesos empresariales.

2.Acceso a información confiable, precisa y oportuna.

3.La posibilidad de compartir información entre todos los componentes de la organización.

4.Eliminación de datos y operaciones innecesarias.

5.Reducción de tiempos y de los costes de los procesos.

Tras ver las amplias posibilidades de un ERP, es importante señalar que la correcta implantación de un ERP conlleva incrementos radicales de productividad así como la posibilidad de tener mejor información en la toma de decisiones. La implantación de un ERP, en la mayoría de los casos, no se plantea para conseguir pequeñas mejoras sino mejoras radicales. Vistas las características y posibilidades del ERP, parece claro que el cambio organizacional necesario para la implantación de un ERP es muy importante ya que se han de remodelar los procesos y han de estar implicadas personas de distintas áreas, creando equipos multidisciplinares.

Para valorar la complejidad de una implantación de ERP, hemos de tener en cuenta que en una implantación interactúan los siguientes 6 elementos o componentes:

1.- El ERP (sistema de información para la gestión).

A priori, puede parecer la pieza más importante del proceso de implantación aunque, como veremos más adelante, no es así. La correcta gestión del cambio es más importante que el propio ERP en sí. En el mercado podemos encontrar centenares de ERPs con características y precios distintos. Por un lado, podemos encontrar ERPs horizontales (que sirven para cualquier tipo de organización de cualquier sector) y ERPs verticales (desarrollados o parametrizados para atender a las necesidades concretas de un sector). De hecho, hay ERPs que disponen de ambas soluciones: horizontal y vertical.

Lo básico es entender que cada organización tiene unas necesidades distintas y que el ERP y su parametrización dependerán de estas necesidades. Por ello, como un ERP no es una solución "tipo" y las soluciones válidas para otras organizaciones pueden no ser válidas para la nuestra. La parametrización es un proceso en el que los ERPs están creados para adaptarse a la idiosincrasia de cada empresa. Esto se logra por medio de la configuración o personalización de los procesos de acuerdo con las salidas que se necesiten de cada uno.

2.- Las personas y la gestión del cambio.

Las personas son clave en las organizaciones y el impacto de una implantación de un ERP sobre ellas es muy importante. Obviamente, la gestión del cambio es un elemento clave. Por ello, el correcto análisis de los requerimientos de los usuarios e integrarlos desde el primer momento de la implantación es clave para conseguir buenos resultados con el proyecto. Además, se deben definir exactamente las mejoras que va a obtener cada una de las personas de la organización con la implantación y definir un plan de comunicación para "vender" el proyecto a todas las personas de la organización. Además, es poco habitual que las organizaciones cuenten con personal con una visión tanto de negocio como de tecnología que consiga liderar el proyecto por lo que el trabajo de consultores externos, y en concreto del director de proyecto, es muy importante.

3.- La estrategia

El proceso “ideal” sería que el plan tecnológico, incluyendo el ERP y su hardware asociado, soporte la estrategia corporativa y no al contrario. Básicamente, la idea es que teniendo perfectamente definida la estrategia de la organización, se asocie a ella los recursos tecnológicos necesarios para que sea posible ejecutarla.

4.- El hardware

Aunque en principio el hardware no es la parte más compleja de la implantación, en algunos casos nos encontramos que la mala elección del hardware o diseño del sistema hace disminuir el rendimiento global de la implantación. En este sentido es básico definir exactamente los requerimientos del sistema y así diseñar la solución de manera que no se invierta ni más ni menos de lo necesario.

5.- Los procesos

Se ha de considerar que además de las personas, los procesos son los que definen la eficiencia y eficacia de la organización. Por ello, en el proyecto de implantación de ERP se deben redefinir los procesos para mejorar su eficiencia y eficacia.

El enfoque correcto es redefinir los procesos como un paso previo a la implantación y que los nuevos procesos sean soportados por el ERP. Sin embargo, lo habitual es encontrar implantaciones de ERPs en los que, tras la implantación, se ejecutan los procesos exactamente igual que antes del ERP. Este es un gran problema ya que no se consigue ninguna mejora en los costes o tiempos de los procesos.

Aunque tengamos el mejor ERP del mundo, si los procesos no se remodelan, seguirán siendo igual de eficientes o ineficientes como lo eran hasta el momento de la implantación y entonces, la implantación del ERP tendrá bajo o nulo impacto en la eficacia y eficiencia.

6.- El resto de aplicaciones de gestión existentes en la organización

Cada vez es más usual que las organizaciones tengan distintas aplicaciones para la gestión. Entre las aplicaciones más habituales están las herramientas propias o sectoriales (por ejemplo cálculo de presupuestos), las de Gestión de Relaciones con los clientes (CRM), Business Intelligence, Gestión de la cadena de suministro (SCM), etc. En la mayoría de las ocasiones, todas las aplicaciones han de estar conectadas con el ERP para conseguir una gestión de la información eficiente. Por ello, la integración entre las distintas aplicaciones (EAI) es una tarea cada vez más compleja y que condiciona los resultados finales de la implantación.

“Business Intelligence” se compone de un conjunto de metodologías, aplicaciones y tecnologías que permiten reunir, depurar y transformar datos de los sistemas transaccionales e información desestructurada en información estructurada, para su explotación directa o para su análisis y conversión en conocimiento soporte a la toma de decisiones sobre el negocio.

Es importante señalar que todo el planteamiento aquí desarrollado es aplicable tanto para organizaciones que se plantean por primera vez su implantación de ERP como organizaciones que ya tienen un ERP y quieren reemplazarlo o mejorar los resultados.