Post-Implantacion de un ERP (36)

Aspectos claves previos a la puesta en producción

Para garantizar el éxito de la puesta en producción de un nuevo sistema es muy importante tener en cuenta los problemas que surgirán una vez “arrancado” el sistema. Deberemos tener en cuenta los siguientes aspectos que pueden surgir con el funcionamiento diario del sistema:

• Los usuarios se encuentran ante un nuevo sistema trabajando con datos reales.

Surgen problemas y tienen dudas. Deben saber a quién acudir para solucionarlos.

• Los procesos en el sistema productivo no funcionan como se esperaba.

• El sistema responde a las acciones del usuario de una manera no contemplada en las sesiones de formación.

• El rendimiento del sistema no es el esperado

• El arranque del nuevo sistema no contempla una gestión en paralelo con los sistemas actuales por lo que no hay “marcha atrás”. Para minimizar el impacto de todos estos problemas es muy importante realizar una serie de tareas durante las semanas previas al arranque.

Es imprescindible que llegado el día de la puesta en producción del sistema se hayan realizado con éxito las siguientes actividades:

• Test del usuario.

Unas semanas antes de la puesta en marcha, y una vez se haya completado la formación de los usuarios, tanto maestros como finales, deberá procederse a realizar en el mandante de Test (mandante 015) el test del usuario.

Consistirá en un test integral por parte de cada usuario de todas las funciones que vaya a utilizar en el nuevo sistema. Por otro lado, deberá también haberse verificado la correcta conversión de los datos maestros en el mandante productivo.

• Parametrización y conversión de datos maestros en el mandante productivo.

Deberán haberse transportado todas las órdenes de transporte al mandante productivo. Tendremos así una imagen en el entorno de productivo idéntica en al mandante de test en cuanto a parametrización se refiere.

• Conversión de datos transaccionales.

Deberá procederse a la carga en el sistema productivo de aquellos datos que todavía están abiertos en los sistemas actuales (órdenes de fabricación, pedidos de cliente, pedidos de compra, etc.).

• Definición de la estrategia de soporte para el momento de la puesta en productivo

y los días siguientes.

Se establecerán qué miembros del equipo van a dar soporte a los usuarios durante los primeros días de la puesta en producción.

Una vez realizadas todas estas actividades, se procederá a la puesta en producción oficial del nuevo sistema. Será crítico en este momento:

• Un control minucioso por parte de los administradores del sistema para detectar los procesos costosos (“cuellos de botella”).

• Disponer de una estrategia de soporte para garantizar un rápido tiempo de respuesta a los problemas que puedan surgir.

Beneficios detectados en la post implementación.

-      Capacidad para reaccionar al entorno y necesidades de los clientes

-      Confiabilidad en los sistemas

-      Facilitar el acceso a la información

-      Mejorar la productividad de los procesos

-      Mejorar el proceso de toma de decisiones

-      Incrementar la eficiencia en el uso del tiempo

-      Crear una base de datos centralizada y actualizada

-      Integrar áreas de la empresa, produciendo un mayor control sobre ellas

-      Aumentar la competitividad de la empresa

-      Reducir el tiempo de producción o entrega

-      Reducir los costos operativos

Fases posteriores a la implantación

Cuando el sistema se pone en marcha comienza el momento más delicado para la empresa cliente. Aún siendo conscientes que es normal que el sistema no sea aquello que la empresa tenía en mente al comenzar el proyecto, cuesta admitir que se haya realizado tanto esfuerzo para estar peor que antes y es aquí donde cobran mayor importancia factores críticos de éxito como el apoyo de la alta dirección, el programa y cultura de gestión del cambio, la comunicación efectiva o el líder del proyecto.

Yu (2005) desarrolla un modelo más elaborado que el tradicional análisis de Factores Críticos de Éxito para analizar las causas que afectan la efectividad de las fases posteriores a la implantación de las aplicaciones ERP. El autor parte de las siguientes premisas:

- En la fases previas a la implantación, los factores que priman son los valores de la empresa (p.e.: implicación de la alta dirección o cultura del cambio) y las actitudes con que se plantea el proyecto de implantación (p.e.: orientación del proyecto o selección del equipo adecuado de proyecto), existiendo una relación causa efecto entre las primeras y las segundas.

- En la fase de implantación, priman los factores relacionados con el comportamiento del equipo de trabajo (p.e.: número de cambios), existiendo relaciones causa-efecto entre las actitudes y los comportamientos.

- En la fase posterior a la implementación, es cuando cobra mayor importancia la medición de los resultados del proyecto a lo largo de las diferentes modificaciones que se realicen para mejorar el sistema. En esta fase priman factores relacionados con la efectividad de los resultados, siendo estos factores consecuencia de los comportamientos clave de la fase de implantación.

Systems Fundamentals - SEBOK (12)

This Knowledge Area (KA) provides a guide to some of the most important knowledge about a system, which forms part of systems thinking and acts as a foundation for the related worlds of integrative 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).

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. This KA contains the following topics: What is a System? - Types of Systems - Groupings of Systems – Complexity - Emergence

Introduction

The word system is used in many areas of human activity and at many levels. But what do systems researchers and practitioners mean when they use the word system? Is there some part of that meaning common to all applications?

The concepts of open system and closed system are explored. Open systems, described by a set of elements and relationships, are used to describe many real world phenomena. Closed systems have no interactions with their environment. Two particular aspects of systems, complexity and emergence, are described in this KA. Between them, these two concepts represent many of the challenges which drive the need for systems thinking and an appreciation of systems science in SE.

Some systems classifications, characterized by type of element or by purpose, are presented.

Within the SEBoK an engineered system is defined as encompassing combinations of technology and people in the context of natural, social, business, public or political environments, created, used and sustained for an identified purpose. The application of the Systems Approach Applied to Engineered Systems requires the ability to position problems or opportunities in the wider system containing them, to create or change a specific engineered system-of-interest, and to understand and deal with the consequences of these changes in appropriate wider systems.

The concept of a system context allows all of the system elements and relationships needed to support this to be identified.

The discussions of engineered system contexts includes the general idea of groups of systems to help deal with situations in which the elements of an engineered system are themselves independent engineered systems. To help provide a focus for the discussions of how SE is applied to real world problems, four engineered system contexts are introduced in the KA:

1. Product System (glossary) context

2. Service System (glossary) context

3. Enterprise System (glossary) context

4. System of Systems (SoS) (glossary) capability context

What is a System?

This article forms part of the Systems Fundamentals Knowledge Area (KA). It provides various perspectives on systems, including definitions, scope, and context. The basic definitions in this article are further expanded and discussed in the articles Types of Systems and What is Systems Thinking?. This article provides a guide to some of the basic concepts of systems developed by systems science and discusses how these relate to the definitions to be found in systems engineering (SE) literature. The concept of an engineered system is introduced as the system context of most relevance to SE.

A Basic Systems Science View

The most basic ideas of a system whole can be traced back to the thinking of Greek philosophers such as Aristotle and Plato. Many philosophers have considered notions of holism, that ideas, people or things must be considered in relation to the things around them to be fully understood (M’Pherson, 1974). One influential systems science definition of a system comes from general system theory (GST) "A System is a set of elements in interaction." (von Bertalanffy 1968)

The elements of a system may be conceptual organizations of ideals in symbolic form or real objects. GST considers abstract systems to contain only conceptual elements and concrete systems to contain at least two elements that are real objects, e.g. people, information, software and physical artifacts, etc. GST starts with the notion of a system boundary defined by those relationships which relate to membership of the system. The setting of a boundary and hence the identification of a system is ultimately the choice of the observer.

For closed systems all aspects of the system exist within this boundary. This idea is useful for abstract systems and for some theoretical system descriptions. The boundary of an open systems (glossary) defines those elements and relationships which can be considered part of the system and those which describe the interactions across the boundary between system elements and elements in the environment (glossary).

Open Systems

The relationships between the various elements of an open system can be related to a combination of the system's structure and behavior. The structure of a system describes a set of system elements and the allowable relationships between them. System behavior refers to the effect produced when an instance of the system interacts with its environment. An allowable configuration of the relationships between elements is referred to as a system state and the set of allowable configurations as its state space.

A system may be made up of a network of system elements and relationships at a single level of detail or scale. However, many systems evolve or are designed as hierarchies of related systems. Thus, it is often true that the elements of a system can themselves be considered as open systems. A “holon” was defined by Koestler as something which exists simultaneously a whole and as a part (Koestler 1967). Natural systems are real world phenomena to which systems thinking is applied to help better understand what those systems do and how they do it. A truly natural system would be one that can be observed and reasoned about, but over which people cannot exercise direct control, such as the solar system.

Social systems are purely human in nature, such as legislatures, conservation foundations, and the United Nations Security Council. These systems are human artifacts created to help people gain some kind of control over, or protection from, the natural world.

Engineered systems may be purely technical systems, such as bridges, electric autos, and power generators. Engineered systems which contain technical and either human or natural elements, such as water and power management, safety governance systems, dams and flood control systems, water and power safety assurance systems are often called sociotechnical systems (glossary). The behavior of such systems is determined both by the nature of the engineered elements and by their ability to integrate with or deal with the variability of the natural and social systems around them. The ultimate success of any engineered system is thus measured by its ability to contribute to the success of relevant sociotechnical system contexts.

Scope of Systems - SEBOK (11)

Part 2 of the SEBoK contains a guide to knowledge about systems, which is relevant to a better understanding of SE. It does not try to capture all of this systems knowledge here; rather, it provides an overview of a number of key aspects of systems theory and practice especially relevant to SE. The organization of knowledge in Part 2 is based around the Praxis Framework. Indeed, the need to develop a clear guide to the underpinning knowledge of SE was one of the motivations behind the praxis framework. It is expected that the coverage of systems knowledge will be significantly increased in future versions of the SEBoK as this work progresses.

The diagram is divided into five sections, each describing how we have treated systems knowledge in the SEBoK.

1. The Systems Fundamentals Knowledge Area considers the question “What is a Systems? It explores the wide range of system definitions and considers open system, system types, groupings of systems, complexity, and emergence. All of these ideas are particularly relevant to engineered system and to the groupings of such systems associated with the systems approach applied to engineered systems (i.e. product system, service system, enterprise system and system of systems capability).

2. The Systems Science Knowledge Area presents some influential movements in systems science, including the chronological development of systems knowledge and underlying theories behind some of the approaches taken in applying systems science to real problems.

3. The Systems Thinking Knowledge Area describes key concepts, principles and patterns shared across systems research and practice

4. The Representing Systems with Models Knowledge Area considers the key role that abstract models play in both the development of system theories and the application of systems approaches.

5. The Systems Approach Applied to Engineered Systems Knowledge Area defines a structured approach to problem/opportunity discovery, exploration, and resolution, that can be applied to all engineered systems. The approach is based on systems thinking and utilizes appropriate elements of system approaches and representations. This KA provides principles that map directly to SE practice.

Systems Thinking is a fundamental paradigm describing a way of looking at the world. People who think and act in a systems way are essential to the success of both research and practice of system disciplines. In particular, individuals who have an awareness and/or active involvements in both research and practice of system disciplines are needed to help integrate these closely related activities.

The knowledge presented in this part of the SEBoK has been organized into these areas to facilitate understanding, the intention is to present a rounded picture of research and practice based on system knowledge. These knowledge areas should be seen together as a “system of ideas” for connecting research, understanding, and practice, based on system knowledge which underpins a wide range of scientific, management, and engineering disciplines and applies to all types of domains.

Costos de la implementación de un ERP (35)

La decisión de invertir una cantidad considerable de capital en un proceso de implementación de un ERP refleja la disponibilidad de la administración para cambiar la manera tradicional en que opera la empresa. Las organizaciones que pueden adoptar y adaptarse a un sistema de ERP integral e implementar exitosamente toda la inversión asociada con el mismo pueden aprovechar aún más las ventajas y colocarse adelante de las demás, creando una ventaja competitiva.

Los sistemas ERP generan ventajas competitivas que pueden ser capaces de dar respuesta rápida a los cambios de mercado o cualquier otro cambio, pero no se ha mencionado la dificultad de la implantación ni el costo o el tiempo que conlleva la implantación de un ERP. En el Articulo Sistemas ERP, ¿solución o dolor de cabeza?  (Claudio Valverde, octubre de 1999) se hace mención a las dificultades de la implantación de un ERP, y nos dice que Implantar un software capaz de integrar las necesidades de la empresa con las de sus clientes y proveedores no es algo sencillo, y menos cuando gran parte del costo de la adopción no es por hardware o software, sino la consultoría donde cada minuto cuesta. Lo anterior obliga a elaborar un plan de trabajo que considere puntos esenciales antes, durante y después de la adopción del ERP, no sólo para aprovechar al máximo los recursos disponibles, sino para hacer el proyecto menos complicado.

El proceso puede limitarse a 4 o 5 meses en organizaciones medianas, con una dirección que brinde todo su apoyo y personal abierto al cambio. Por otra parte, cuando la empresa es muy grande y/o el plan de trabajo es inapropiado, es posible que se extienda 1 o 2 años. No hay recetas mágicas para implantaciones exitosas, sólo trabajo y aspectos que deben cuidarse antes y al mismo tiempo que el proceso, e inclusive cuando el sistema entra en funciones en el área de producción.

Para la mediana empresa, según los parámetros de JD Edwards, se factura de $20 a $150 millones de dólares, y la implantación es de 3 a 4 meses, y en el caso de empresas grandes, su facturación es de $150 millones de dólares en adelante, y la implantación se estima es de seis a nueve meses. JD Edwards también tiene precios base con solución integrada que incluye consultoría, capacitación, equipo y la base de datos, los cuales van a partir de los $175,000 dólares y van creciendo en función del alcance y las necesidades de la empresa.

No hay recetas mágicas ni guiones explícitos para implantaciones exitosas. Solamente trabajo bien realizado, una correcta metodología y aspectos que deben cuidarse antes y durante el proceso de implantación, e inclusive cuando el sistema entra en función. Por ello, antes, durante y después de la implantación de un ERP es conveniente efectuar lo siguiente:

• Definición de resultados a obtener con la implantación de un ERP.
• Definición del modelo de negocio.
• Definición del modelo de gestión.
• Definición de la estrategia de implantación.
• Evaluación de oportunidades para software complementario al producto ERP.
• Alineamiento de la estructura y plataformas tecnológicas.
• Análisis del cambio organizativo.
• Entrega de una visión completa de la solución a implantar.
• Implantación del sistema.
• Controles de calidad.
• Auditoría del entorno técnico y del entorno de desarrollo.
• Benchmarking de la implantación. 

Análisis Costo–beneficio

La implementación exitosa de un sistema de ERP en la empresa no es la etapa final del proceso de este sistema de soporte en las decisiones de negocio. El éxito a largo plazo del proyecto descansa en la exitosa implementación de un plan de aseguramiento de calidad, o en un plan de optimización posterior a la implementación.

Para obtener beneficios completos, se necesita un completo éxito operacional y un retorno óptimo de la inversión del sistema. La organización debe ver más allá de la utilización del sistema y centrarse en mejorar el desempeño. El desempeño incremental es de particular importancia en la economía actual. El siguiente paso, después de una implementación exitosa, es la optimización midiendo cuidadosamente el retorno de inversión y acelerando la curva de aprendizaje. La optimización trae nuevas ideas que no fueron consideradas durante la implementación del proyecto o estaban fuera de su alcance, tal como la expansión del software implementado, el hardware para hacer los procesos existentes, etc.

La optimización debe ser planeada y ejecutada con el mismo cuidado con el que se ejecutaron los procesos de la propia implementación. Como regla, debemos seguir una metodología documentada, que tengan detalles del proyecto, así como fechas de compromisos y asignación de las tareas a cada miembro. Primero, deben ser establecidos los objetivos de la optimización. Para ello también se debe evaluar el estado actual del sistema ya implementado, su funcionalidad y el impacto en los procesos actuales del negocio.

El proceso de la optimización es una herramienta para mostrar los beneficios de la implementación del sistema de ERP y alcanzar la esperada eficiencia organizacional. Pero al final del día, el éxito de la implementación del sistema está definido por la habilidad de la empresa de integrar y consolidar la propia funcionalidad del sistema de ERP. Optimizar no significa un fracaso del sistema actual, este proceso sólo se debe ver como parte de una mejora continua.

La decisión de invertir una cantidad considerable de capital en un proceso de implementación de un sistema de ERP refleja la disponibilidad de la administración para cambiar la manera tradicional de cómo opera la empresa. Las organizaciones que pueden adoptar y adaptarse a un sistema de ERP tienen una ventaja competitiva superior a las que no utilizan este sistema.

QA en la implantación de un ERP (34)

La implantación de un ERP es un proceso de transformación de la forma como opera un negocio o institución, cuyos efectos e implicaciones afectan a la empresa en su conjunto. No es un proyecto o un proceso de sistemas. Las estadísticas de resultados obtenidos en este tipo de proyectos señalan que más del 70% de los proyectos de implantación no concluyen, se abandonan, terminan fuera de los tiempos establecidos o fuera del presupuesto, o bien sin cumplir con los requerimientos y expectativas de las áreas usuarias y de la Dirección.

Algunas de las principales causas detectadas por la consultora, que afectan el éxito de este tipo de proyectos, son:

• Cambios constantes de requerimientos desde el principio del proyecto motivados por expectativas poco realistas de parte de los usuarios.
• Carencia de compromiso y dirección de parte de la Alta Dirección.
• Metas y objetivos confusos para el proyecto.
• Comunicación irregular e ineficiente; las opiniones de los involucrados no son escuchadas.
• Restricciones de recursos; demasiados proyectos, todo es de alta prioridad.
• Roles poco claros: (“¿Qué va a pasar con mi empleo?”) y beneficios de los cambios (“¿En qué me va a beneficiar a mí?”).
• Estructura organizacional incompatible con las metas de los proyectos.
• Demasiadas iniciativas de cambio sucediendo al mismo tiempo sin una visión global de cómo se combinan o se integran estos cambios.

En este entorno, las empresas que entran en proyectos de implantación y, en muchos casos, las empresas proveedoras de servicios de implantación, con frecuencia no cuentan con el personal experimentado y con suficientes experiencias para llevar a cabo el proceso. Lo anterior genera graves problemas a las empresas que deciden realizar estos procesos de implantación, ya que no sólo está en juego el importante presupuesto que aplican para su realización, sino el hecho que la operación de la empresa queda en juego ante procesos que puedan ser deficientemente implantados.

Para colaborar en estos importantes proyectos, la consultora ofrece una serie de  servicios para apoyar la adecuada definición y planeación de un proyecto de implantación de ERP (pre-implantación), proporcionar el aseguramiento de la calidad del proyecto durante su desarrollo y la realización de revisiones de calidad post-implantación.

En todos los casos, la intervención de una consultora abarca aspectos desde la detección de vulnerabilidades, hasta el establecimiento de oficinas de aseguramiento de calidad y de gestión de proyectos de implantación que garanticen que la calidad, el tiempo y los costos de los proyectos se cumplan de acuerdo a lo planeado.

¿A qué clientes sirve la iniciativa QA para ERP´s?

Este servicio está orientado a todas aquéllas empresas que están por iniciar un proceso de implantación de ERP, están en el proceso de realización de la implantación o bien ya la concluyeron y desean asegurar su adecuado funcionamiento. Asimismo, es muy valioso para empresas pequeñas como para grandes corporativos que desean obtener el mayor rendimiento y eficiencia de su inversión en un ERP.

Systems - SEBOK (10)

SEBoK Part 2 is a guide to knowledge associated with systems, particularly knowledge relevant to systems engineering (SE). This knowledge is included in the Guide to the SE Body of Knowledge (SEBoK) to help systems engineers benefit from an understanding of the broader context for their discipline, in terms of theories and practices of systems science and other fields of systems practice. It is also hoped that by including the wider systems science context of SE we will make SE knowledge more accessible to a wider audience outside of its traditional domains.

Knowledge Areas in Part 2

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 2 contains the following KAs:

• Systems Fundamentals

• Systems Science

• Systems Thinking

• Representing Systems with Models

• Systems Approach Applied to Engineered Systems

Most systems engineers are practitioners, applying processes and methods that have been developed and evolved over decades. SE is a pragmatic approach, inherently interdisciplinary, yet specialized.

Systems engineers usually work within a specific domain, using processes and methods that are tailored to their domain’s unique problems, constraints, risks and opportunities. These processes and methods have been found to capture domain experts’ knowledge of the best order to tackle issues as a problem in the particular domain is approached.

Specific domains in which systems approaches are used and adapted include

• Technology products, integrating multiple engineering disciplines

• Information-rich systems, e.g. command & control, air traffic management etc

• Platforms, e.g. aircraft, civil airliners, cars, trains, etc

• Organizational and enterprise systems, which may be focused on delivering service or capability

• Civil engineering/infrastructure systems, e.g. roads networks, bridges, builds, communications networks, etc.

The specific skill-sets for each domain and system scale may be quite different. However there are certain underlying unifying principle based on systems science and systems thinking that will improve the effectiveness of the systems approach in any domain. In particular, shared knowledge of systems principles and terminology will enable communication and improve our ability to integrate complex systems that span traditional domain boundaries (Sillitto 2012). This integrated approach is increasingly needed to solve today’s complex system challenges, but as these different communities come together they can find that assumptions underpinning their world-views are not shared.

To bridge between different domains and communities of practice, we need a well-grounded definition of the “intellectual foundations of systems engineering”, and a common language to describe the relevant concepts and paradigms. We need to look beyond systems engineering to achieve this. An integrated systems approach for solving complex problems needs to combine elements of systems science, systems thinking and systems approaches to practice, ranging from the technical-systems focus that has been dominant in systems engineering to the learning-systems focus of social systems intervention. An integrated systems approach needs to provide a framework and language that allow different communities, with highly divergent world-views and skill sets, to work together for a common purpose.

The Systems Praxis Framework

The term “systems praxis” refers to the entire intellectual and practical endeavor for creating holistic solutions to today’s complex system challenges. Praxis (glossary) is defined as “translating an idea into action” (Wordnet) and the best holistic approach to a given complex challenge may require integrating appropriate theory and appropriate practice from a wide variety of sources. Systems praxis requires many communities to work together. To work together we must first communicate; and to communicate, we must first connect.

A framework for unifying systems praxis was developed by members of International Council on Systems Engineering (INCOSE) and International Society for the System Sciences (ISSS) (International Federation for Systems Research (IFSR) 2012)) as the first step towards a “common language for systems praxis”.

This Systems Praxis Framework is included here because it represents current thinking on the foundations and common language of systems engineering, making the concepts and principles of systems thinking and practice accessible to anyone applying a systems approach to engineered system problems. This framework and thinking have been used to help organize the guide to systems knowledge in the SEBoK.

In this framework, the following elements are connected:

Systems Thinking is the core integrative element of the framework. It binds the foundations, theories and representations of systems science together with the hard, soft and pragmatic approaches of systems practice. In systems praxis, as in any practical discipline underpinned by science, there is constant interplay between theories and practice, with theory informing practice and outcomes from practice informing theory. Systems thinking is the ongoing activity of assessing and appreciating the system context, and guiding appropriate adaptation, throughout the praxis cycle.

Integrative Systems Science has a very wide scope and is grouped into three broad areas:

• Foundations, which help us to organize knowledge, learning and discovery, and include: meta-theories of methodology; ontology; epistemology; axiology; praxiology (theory of effective action); teleology, semiotics & semiosis; category theory; etc.

• Theories about systems, abstracted from domains and specialisms so as to be universally applicable: general system theory; systems pathology; complexity; anticipatory systems; cybernetics; autopoiesis; living systems; science of generic design; organization theory; etc.

• Representations and corresponding theories we can use to describe, explore, analyze, and make predictions about systems and their wider contexts, whether in terms of models; dynamics; networks; cellular automata; life cycles; queues; graphs; rich pictures; narratives; games and dramas; agent-based simulations; etc.

Systems Approaches to Practice aim to act on the real world to produce desired outcomes without adverse unintended consequences so practice needs to draw on the wide range of knowledge appropriate to the system-of-interest and its wider context. No one branch of systems science or practice provides a satisfactory explanation for all aspects of a typical system “problematique”, a more pragmatic approach is needed.

• Hard approaches suited to solving well-defined problems with reliable data and clear goals, using analytical methods and quantitative techniques. Strongly influenced by “machine” metaphors, they focus on technical systems, objective complexity, and optimization to achieve desired combinations of emergent properties. They are based on “realist” and “functionalist” foundations and worldview.

• Soft approaches suited to structuring problems involving incomplete data, unclear goals, and open inquiries, using a “learning system” metaphor; focus on communication, intersubjective complexity, interpretations and roles; and draw on subjective and “humanist” philosophies with constructivist and interpretivist foundations.

Pragmatic (Pluralist or Critical) approaches judiciously select an appropriate set of tools and patterns that will give sufficient and appropriate insights to manage the issue at hand, applying multiple methodologies drawn from different foundations as appropriate to the situation. Heuristics, boundary critiques, model unfolding, etc, enable understanding of assumptions, contexts, and constraints, including complexity due to different stakeholders’ values and valuations. An appropriate mix of “hard” “soft” and custom methods draws on both systems and domain-specific traditions. Systems may be viewed as networks, societies of agents, organisms, ecosystems, rhizomes, discourses, machines, etc. The set of “clouds” that collectively represents systems praxis is part of a wider ecosystem of knowledge, learning and action. Successful integration with this wider ecosystem is key to success with real world systems. Systems science is augmented by “hard” scientific disciplines such as physics and neuroscience, and by formal disciplines such as mathematics, logic and computation; it is both enhanced by, and used in, humanistic disciplines such as psychology, culture, and rhetoric, and pragmatic disciplines, such as accounting, design, and law. Systems practice depends on measured data and specified metrics relevant to the problem situation and domain; on solicitation of local values and knowledge; and on pragmatic integration of experience, legacy practices, and discipline knowledge.

Integrative Systems Science allows us to identify, explore and understand patterns of complexity through contributions from the foundations, theories and representations of systems science and other disciplines relevant to the “problematique”.

Systems Approaches to Practice address complex problems and opportunities using methods, tools, frameworks, patterns, etc, drawn from the knowledge of integrative systems science, while observation of the results of systems practice enhances the body of theory.

Systems Thinking binds the two together through appreciative and reflective practice using systems concepts, principles, patterns, etc.

Agentes en la implantación de un ERP (33)

Se tiene conocimiento de qué productos nos proporciona el mercado y, dentro de los grandes desarrolladores de software, la alianza estratégica que establecen los proveedores con las consultoras de implantación del ERP. Pero no sólo estos grandes agentes participan en el proceso de implantación. El papel más importante debe ser asumido por la propia organización. No estamos hablando sólo de la dirección de la compañía, elemento desencadenante del proceso y, evidentemente, clave en diferentes puntos del proyecto. Nos referimos al director del proyecto. Se describirá el papel de todos estos agentes y ver cómo se interrelacionan en el proceso. La clave de una buena implementación será mantener la fluidez en la relación entre estos agentes.

1.- Dirección de la compañía

Es el “dueño” del proceso. Es quién determina qué hay que hacer y cuándo se realizará. Lanza el proyecto de implantación del ERP, determina quién de su organización participará y en qué plazos se ha de finalizar el proyecto. No es necesario que esté presente durante todas las fases del proyecto, pero deberá ser informado periódicamente y en los momentos clave del proyecto (retrasos, aumento de los costes, actividades no previstas, etc.). Elige al Director del Proyecto y delega en él las funciones del “día a día”.

2.- Director del Proyecto

El papel debería ser asumido por alguien de la propia organización, con una visión generalista y, a ser posible, con excelentes relaciones en todos los órganos de la empresa (financiero, comercial, producción). De no ser posible asumir este papel por personas de la organización, es conveniente que se delegue la función en una entidad independiente del proveedor de software o de la consultora / comercializadora del software. Ello facilitará:

• Independencia de la visión del software: el ERP debe trabajar según el modelo de negocio de la organización y no al revés

• Representación de la organización: fluidez en las comunicaciones con la dirección

• Coordinación con otros proveedores: búsqueda de las mejores soluciones de integración con otros proveedores involucrados en el proyecto.

Reportará a la dirección de la compañía y será el responsable del seguimiento del proyecto. Su trabajo estará íntimamente relacionado con el Jefe del Proyecto.

3.- Jefe del Proyecto / Consultor

Este rol es asumido por la organización que realiza la instalación y adaptación del ERP. Si en la definición del proyecto se ha establecido que no exista la figura del director del proyecto, las funciones de aquel serán asumidas por este. Debe conocer profundamente la funcionalidad del ERP y las mejores prácticas del sector de la compañía en que se está implantando la solución. Deberá huir de la “jerga” técnica, usando conceptos y nomenclatura de negocio.

Cuando la complejidad de la implantación lo requiera, el proyecto será dividido en sub-proyectos, siendo responsable de cada uno de los módulos un consultor especializado en el área. El Jefe de Proyecto coordinará a los diferentes consultores de área.

4.- Usuarios clave del negocio

El Director del Proyecto y el Jefe de Proyecto armarán una propuesta para los  usuarios clave que representarán a las diferentes áreas de la organización en diferentes fases del proyecto. Deberán ser ratificados por la dirección de la compañía. Su objetivo consiste en que el grupo de desarrollo e implantación “posea”  conocimiento de las prácticas de la organización. Para ello, el usuario clave debe aceptar la representación de la organización desde un punto de vista objetivo, eliminando las prácticas personales si éstas no son comunes en diferentes áreas de la compañía. Estos usuarios podrán solicitar “apoyo” de otros compañeros si la complejidad de la solución así lo requiere.

En la fase de formación ocupan un lugar especial. Hay experiencias en que la formación en las nuevas prácticas de negocio se facilita si son los propios usuarios quienes transmiten a sus compañeros las nuevas formas de entender la organización, sobre todo si la implantación de un ERP ha requerido procesos de reingeniería.

5.- Equipo técnico

El jefe de proyecto coordinará al equipo técnico que implantará el proyecto (técnicos de hardware, analistas y programadores de desarrollo).

Users and Uses - SEBOK (9)

The users and uses described in this article were identified based on the six SEBoK purposes described in the SEBoK 1.0 Introduction. Users can either be primary (those who use the SEBoK directly) or secondary (those who use the SEBoK with assistance from a systems engineer). Indicative, but not exhaustive, sets of example uses are shown.

Primary Users

Primary users are those who use the SEBoK directly. Hyperlinks in the second column link to the associated use case, where one has been written. The use cases are listed at the end of the topic, and may also be seen here.

Primary SEBoK Users and Common Uses. (SEBoK Original)

# Users Uses

1 Practicing systems Engineers ranging from novice up through expert

• Taking on a new SE role in a project; preparing by finding references for study

• Expanding SE expertise and specialization; preparing by finding references for study

• Seeking to understand the principles of SE; seeking the best references to elaborate on those principles

• Reviewing a project or mentoring a new SE performer; seeking to understand what best practices to look for

• Pursuing professional development through study of SE topics, including new developments in SE

2 Process engineers responsible for defining or implementing SE processes

• Maintaining a library of SE process assets; seeking to understand which SE process models and standards are most relevant

• Tailoring a process for a specific project; seeking to learn how others have tailored processes, or how a specific application domain affects tailoring

• Measuring the effectiveness of an organization’s SE processes; seeking to learn how others have done

• Defining standards for a professional society or standards organization

3 Faculty Members

• Developing a new graduate program in SE, and deciding what core knowledge all its students must master; the user should consult the GRCSE in conjunction with the SEBoK

• Developing a new SE course; seeking to identify course objectives, topics, and reading assignments

• Incorporate SE concepts in courses or curricula focused on engineering disciplines other than SE

4 GRCSE authors

• As members of the GRCSE author team, deciding what knowledge to expect from all SE graduate students

5 Certifiers

• Defining a company’s in-house SE certification program; seeking to understand what others have done, how such programs are typically structured, and how to select the knowledge that each person seeking certification should master

• Defining certification criteria for a professional society or licensure program

6 General Managers, Other Engineers, developers, testers, researchers

• Mastering basic vocabulary, boundaries, and structure of SE; seeking a few primary references

• Learning what the scope of SE is, relative to the General Manager role

• Learning what the role of the systems engineer consists of, relative to others on a project or in an organization

• Learning to effectively perform a General Manager role on an SE integrated product team

7 Customers of Systems Engineering

• Providing resources to and receiving artifacts from systems engineers; seeking to better understand what to ask for, how to request it, how much to pay for it, and how to judge the quality of what is received

8 SE managers

• Evaluating possible changes in team processes and tools proposed by systems engineers on various teams; seeking independent information with which to evaluate the proposals

• Hiring systems engineers, and developing competency-based job descriptions

9 SE researchers

• Looking for gaps are in SE knowledge to help guide a research agenda

• Getting familiarize with a research topic; seeking the most important articles about the topic

Secondary Users

Secondary users are those who use the SEBoK with assistance from a systems engineer

Secondary SEBoK Users and Common Usages. (SEBoK Original)

# Users Uses

1 Human resource development professionals

• Supporting the hiring and professional development of systems engineers

2 Non-technical managers

• Augmenting understanding of central concerns with information about relevant SE topics; e.g., a contracting manager might want to better understand SE deliverables being called out in a contract 3 Attorneys, policy makers • Defining the impact of SE performance on central concerns; e.g., understanding the liability of a systems engineer for errors in judgment on a project, or the limitations of SE in guaranteeing the success of a project against actions of sponsors, managers, or developers

List of Use Cases

At the time of version 1.0, not every class of user has a use case developed. To illustrate the major uses, the following use cases are included:

• Use Case 1: Practicing Systems Engineers. This covers the first set of users

• Use Case 2: Other Engineers. This covers the second and sixth sets of users

• Use Case 3: Customers of Systems Engineering. This covers the seventh set of users

• Use Case 4: Educators and Researchers. This covers the third, fourth, and ninth sets of users

• Use Case 5: General Managers. This covers the sixth and eighth sets of users

While not exhaustive, the use cases show the utility of the SEBoK in various applications and contexts.

SEBOK Evolution (8)

This article describes history of the SEBoK leading to version 1.0, as well as the anticipated shift in stewardship following the release of 1.0. It further describes the plans for the maintenance and revision of the SEBoK.

SEBoK Background

The Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE) was started in fall 2009 to create a community-based Guide to the Systems Engineering Body of Knowledge (SEBoK) and a Graduate Reference Curriculum for Systems Engineering (GRCSE).

It is also one of the research tasks of the Systems Engineering Research Center. Led by Stevens Institute of Technology and the Naval Postgraduate School, BKCASE is conducted in coordination with several professional societies and is funded both by the U.S. Department of Defense (DoD) and the generous volunteer efforts of 70 authors from dozens of companies, universities, and professional societies across 10 countries. For additional information on the BKCASE authors, please see the Acknowledgements article.

Previous work

Previous works on developing a guide to the Systems Engineering Body of Knowledge include an International Council on Systems Engineering (INCOSE) sponsored online version of the Guide to the Systems Engineering Body of Knowledge (INCOSE Insight 2002) and the INCOSE Handbook which has continued to evolve and is the de facto community statement of systems engineering (SE) knowledge and structure (INCOSE 2011).

Systems engineering knowledge has also been documented through the standards bodies, including ISO/IEC/IEEE 15288, Systems Engineering-System Life Cycle Processes (2008), IEEE/EIA 12207, Software Life Cycle Processes (2008), and ANSI/EIA 632, Processes for Engineering a System (1998, 2003). These efforts have provided a foundation for the SEBoK presented here; however, the goal of the SEBoK is to provide a comprehensive view of all SE knowledge and build upon the traditional approach to performing SE.

Around the world, many universities have launched undergraduate and graduate SE programs and numerous companies and government agencies have defined SE competency models and career paths. However, there are many differences in style and substance between university program curricula, career path models and competency models around the world. The SEBoK and GRCSE products will provide a framework for understanding the similarities and differences in these programs and helping to enable many arbitrary differences to gradually disappear.

Impact

The SEBoK authors believe that the scale of the effort to create the SEBoK, together with the open collaborative process used to write it, will itself have positive effects on the community. The author team includes official INCOSE representatives and Institute for Electrical and Electronics Engineers (IEEE) Computer Society and Systems Council representatives, and members of other national and international SE bodies. The effort has included extensive awareness initiatives and an open review process. Through these initiatives, the SEBoK is building consensus on the boundaries and context of systems engineering thinking, including its interfaces to three strongly related disciplines – software engineering, project management, and industrial engineering.

The SEBoK is intended not only to inform practicing systems engineers, but also to develop a common way to refer to systems engineering knowledge, facilitate communication among systems engineers, and provide a baseline for creating and evolving competency models, certification programs, educational programs, and other workforce development initiatives SEBoK Evolution around the world.

Releases

Originally, the BKCASE team anticipated three SEBoK releases, each about one year apart. But after version 0.5 was released, it was clear that another intermediate release was needed before version 1.0. Accordingly, the following versions of SEBoK have been released:

• Version 0.25 – a prototype that would create the first architecture and early content of the SEBoK for limited review and validation.

• Version 0.5 – a version suitable for early adopters.

• Version 0.75 – an interim version used to gather further community feedback and to address the most critical shortcomings identified in version 0.5.

• Version 1.0 – this version, intended for broad use.

Éxito en la implantación de un ERP (32)

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.

El éxito de una implantación de un ERP se puede medir en 4 dimensiones:

1-   Calidad del sistema

Las características que se evalúan del sistema de procesamiento se asocian a su grado de productividad, portabilidad, confiabilidad y facilidad de uso

2-   Calidad de la información

La evaluación de la calidad de esta información se asocia a que sea utilizable, concisa, comprensible, disponible, pertinente y en un formato adecuado en forma de reportes o informes.

3-   Calidad del servicio

Determinantes: tangibilidad, confiabilidad, capacidad de respuesta y seguridad

4-   Beneficios netos

Es la organización, y en particular, el logro de metas del negocio y mejoras en las capacidades operativas a partir de la implantación del ERP

Hipótesis

H1a-d: La planificación estratégica de las TI tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H2a-d: El compromiso ejecutivo tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H3a-d: La gestión de proyectos tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H4a-d: Las habilidades en TI tienen un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H5a-d: Las habilidades en procesos de negocio tienen un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H6a-d: El entrenamiento en ERP tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H7a-d: El aprendizaje tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H8a-d: La predisposición para el cambio tiene un impacto positivo en el éxito de la implantación de un ERP, medido en calidad del sistema, calidad de la información, calidad de servicio y beneficios netos

H9: La calidad del sistema tiene un impacto positivo en los beneficios netos de implantar un ERP.

H10: La calidad de la información tiene un impacto positivo en los beneficios netos de implantar un ERP.

H11: La calidad de servicio del área de SI tiene un impacto positivo en los beneficios netos de implantar un ERP.

Efectos de la implantación de un ERP (31)

Desde un punto de vista operativo las ventajas de los sistemas ERP se traducen en un conjunto de beneficios tangibles e intangibles que han puesto de manifiesto numerosos estudios a nivel internacional. Como resultado último, los sistemas ERP deberían contribuir a mejorar el desempeño empresarial. Sin embargo, la  introducción de los sistemas ERP no está exenta de efectos adversos. Nos centraremos en tres: i) la barrera de entrada que supone su alto coste; ii) la resistencia al cambio, y iii) el fracaso en la implementación.

La implantación de los sistemas ERP requiere una inversión importante en tiempo, dinero y recursos internos. Esto es debido a la necesidad de personalización de los mismos, ya que suelen incorporar un esqueleto común que debe ser adaptado al tipo de negocio. Se suele cuantificar los costes de implantación de un sistema ERP en un porcentaje que oscila entre un 0,82% y un 13,65% de las ventas, llegando, incluso al 50% en las empresas más pequeñas.

Además, es preciso contemplar una inversión adicional en la formación de los futuros usuarios de estos sistemas, formación que no solamente debe centrarse en los aspectos de manejo informático de la nueva aplicación, sino también en las nuevas responsabilidades que se adquieren y en las posibles graves consecuencias de errores que resultaban inocuos en sistemas sin ese grado de integración. No hay que olvidar que la implantación de los sistemas ERP es, ante todo, una tarea intensiva en conocimiento.

Un segundo aspecto a tener en cuenta es que la implantación de un sistema ERP no es una cuestión de tecnología solamente (software más hardware), sino también de personas. De ahí la importancia que tiene su actitud ante la implantación de los sistemas ERP. Los sistemas de contabilidad de gestión afectan a la conducta de los miembros de la organización pues, entre otras cosas, evalúan los rendimientos de su actividad, de modo que los sistemas de control inciden en el comportamiento de los individuos, a fin de motivarles o corregirles la conducta en el trabajo. Además, hay que tener presente que los empleados, una vez que aprenden a desenvolverse con el sistema de contabilidad de gestión existente, se resisten a cambios en el mismo por la incertidumbre acerca de cómo comportarse ante un nuevo sistema.

También hay que señalar que las ganancias de eficiencia y eficacia que a priori se esperan obtener pueden no verse materializadas. Se han detectado importantes desviaciones sobre las previsiones iniciales; por ejemplo, las implementaciones de proyectos ERP fueron en promedio un 178% sobre lo presupuestado, llevaron 2,5 veces más tiempo de lo pensado y permitieron sólo el 20% de los beneficios prometidos. Se revela que sólo un tercio de las implantaciones pudieron calificarse como exitosas.

En las principales razones de fracaso de las implantaciones se analizan las causas de las resistencias al cambio tomando tres niveles: el individual, el de grupo y el de la organización. Se piensa que la implantación tiene el riesgo de generar problemas de integración del sistema y falta de coordinación entre personas, procesos y la nueva tecnología. Todo ello ha generado un escepticismo asociado a la capacidad de los proyectos ERP para alcanzar los beneficios previstos. A todo lo anterior hay que añadir que los resultados sobre el desempeño no son inmediatos, sino que puede llevar años alcanzar flujos de caja positivos. La implementación de un ERP altera el equilibrio de la empresa, creando un entorno de caos durante los primeros meses de entrada en funcionamiento. Es previsible que el desempeño como consecuencia de la implementación disminuya durante los primeros meses y comience a mejorar después de un periodo.

Dado que los costes y los beneficios potenciales son elevados, no está claro cuál será el efecto conjunto. Pese a que muchos estudios están dirigidos a buscar una relación positiva entre inversión en tecnologías de información y desempeño de la empresa, la literatura relevante no es clara a la hora de predecir el impacto de los sistemas de información en el desempeño empresarial. Ello puede ser debido a que es preciso tener en cuenta un aspecto fundamental a la hora de evaluar el desempeño de las empresas adoptantes de dichas innovaciones: la paradoja de la productividad.

Las tecnologías de la información son consideradas innovadoras si facilitan mejoras en aspectos esenciales de negocio como:

1. Proporcionar información sobre la organización con mayor exactitud y oportuna, a costes mucho menores.

2. Identificar problemas y oportunidades con mayor velocidad y precisión.

3. Reducir el número de nodos humanos intermedios en el procesamiento de la información.

4. Reducir el número de niveles organizativos involucrados en el proceso de autorizar y elaborar decisiones.

5. Reducir el tiempo consumido en los procesos de toma de decisiones.