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.