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.