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.