Analysis and Selection between Alternative Solutions – SEBOK (26)

This topic is part of the Systems Approach Applied to Engineered Systems Knowledge Area (KA). It describes knowledge related to the analysis and selection of a preferred solution from the possible options, which may have been proposed by Synthesizing Possible Solutions. Selected solution options may form the starting point for Implementing and Proving a Solution. Any of the activities described below may also need to be considered concurrently with other activities in the systems approach at a particular point in the life of a system-of-interest (SoI).

The activities described below should be considered in the context of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).

System Analysis

System analysis is an activity in the systems approach that evaluates one or more system artifacts created during the activities involved in Synthesizing Possible Solutions, such as:

• Defining assessment criteria based on the required properties and behavior of an identified problem or opportunity system situation.

• Accessing the properties and behavior of each candidate solution in comparison to the criteria.

• Comparing the assessments of the candidate solutions and identification of any that could resolve the problem or exploit the opportunities, along with the selection of candidates that should be further explored.

The problem context for an engineered system will include a logical or ideal system solution description. It is assumed that the solution that “best” matches the ideal one will be the most acceptable solution to the stakeholders. Note, as discussed below, the “best” solution should include an understanding of cost and risk, as well as effectiveness. The problem context may include a soft system conceptual model describing the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders (Checkland 1999). This soft context view will provide additional criteria for the analysis process, which may become the critical issue in selecting between two equally effective solution alternatives. Hence, analysis is often not a one-time process of solution selection; rather, it is used in combination with problem understanding and solution synthesis to progress towards a more complete understanding of problems and solutions over time.

Effectiveness Analysis

Effectiveness studies use the problem or opportunity system context as a starting point. The effectiveness of a synthesized system solution will include performance criteria associated with both the system’s primary and enabling functions. These are derived from the system’s purpose, in order to enable the realization of stakeholder needs in one or more, wider system contexts. For a service system or enterprise system the criteria will be more directly linked to the identified user needs or enterprise goals. Typical qualities for such systems include agility, resilience, flexibility, In addition to assessments of the absolute effectiveness of a given solution system, systems engineers must also be able to combine effectiveness with the limitations of cost and timescales included in the problem context. In general, the role of system analysis is to identify the proposed solutions which can provide some effectiveness within the cost and time allocated to any given iteration of the systems approach. If none of the solutions can deliver an effectiveness level that justifies the proposed investment, then it is necessary to return to the original framing of the problem. If at least one solution is assessed as sufficiently effective, then a choice between solutions can be proposed.

Systems Principles of System Analysis

From the discussions above, the following general principles of systems analysis can be defined:

1.- Systems analysis is an iterative activity consisting of trade studies made between various solution options from the systems synthesis activity.

2.- Systems analysis uses assessment criteria based upon a problem or opportunity system description.

3.- These criteria will be based around an ideal system description that assumes a hard system problem context can be defined.

4.- The criteria must consider required system behavior and properties of the complete solution in all of the possible wider system contexts and environments.

5.- Trade studies requires equal consideration to the primary system and the enabling system working as a single sytem to address the User need. These trades need to consider system requirements for Key Performance Parameters (KPPs), systems safety, security, and affordability across the entire life cycle

6.- This idea system description may be supported by soft system descriptions from which additional “soft” criteria may be defined (e.g., a stakeholder preference for or against certain kinds of solutions and relevant social, political, or cultural conventions to be considered in the likely solution environment, etc.).

7.- At a minimum, the assessment criteria should include the constraints on cost and time scales acceptable to stakeholders.

9.- A trade study should consider a “system of assessment criteria”, designating special attention to the limitations and dependencies between individual criteria.

10.- Trade studies need to deal with both objective and subjective criteria. Care must be taken to assess the sensitivity of the overall assessment to particular criteria.

Engineer System Context - SEBOK (25)

Engineered System Context

This article is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the further expansion of the ideas of an engineered system and engineered system context that were introduced in the Systems Fundamentals KA.

The single most important principle of the systems approach is that it is applied to an engineered system context and not just to a single system (INCOSE 2012). The systems approach includes models and activities useful for the understanding, creation, use, and sustainment of engineered systems to enable the realization of stakeholder needs.

Disciplines that use a systems approach (like systems engineering (SE)) consider an engineered system context that defines stakeholder needs, and look for the best ways to provide value by applying managed technical activities to one or more selected engineered systems of interest (SoI).

Engineered System of Interest

We use the idea of an engineered system context to define an engineered SoI and to capture and agree on the important relationships between it, the systems it works directly with, and any other systems with which it work. All applications of a systems approach (and hence of SE) are applied in a system context rather than only to an individual system.

Applying the System Context

For lower-level and less-complex systems, the WSoI can represent levels of a product system hierarchy. An example of this would be an engine management unit as part of an engine, or an engine as part of a car. The WSoI in a system context may encapsulate some aspects of SoS ideas for sufficiently complex (glossary) systems. In these cases, the WSoI represents a collection of systems with their own objectives and ownership with which the NSoI must cooperate with in working towards a shared goal.

Product System Context

A product system context would be one in which the SoI is the product itself. The wider system context for a product system can be a higher level of product hierarchy, a service, or an enterprise system that uses the product directly to help provide value to the user. A significant aspect of a product systems context is the clear statement of how the product is intended to be used and the ensures that this information is given to the acquirer upon delivery. The customer will be required to accept the system, typically through a formal process, agreeing not to go against the terms of use.

If a systems approach is applied to a product context, it is done with the purpose of engineering a narrow system product to be integrated and used in a wider system product hierarchy or to enable the delivery of a wider system service directly to a user by an enterprise. This view of the relationship between product and service is specific to product systems engineering. While some engineering of the acquirer's static service system may occur, it is done with a product focus. The definition of service system in a service systems engineering context describes a more dynamic view of service systems.

Service System Context

Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (Spohrer 2008). The distinction between service and a service system is discussed in the article Types of Systems.

A service system context is one in which the SoI is the service system. This SoI contains all of the technology, infrastructure, people, resources, etc. that are needed to enable the service. The WSoI describes the enterprise providing the service as well as its relationship with other services that are impact the success of the enterprise.

If a systems approach is applied to a service system, it is done with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, all options to provide the service must be considered, providing that they fit within the constraints of the enterprise. This will include interfaces to other services, people, and resources in the enterprise. If an option for providing the service makes use of existing products or resources within or outside of the enterprise, it must be ensured that they are available for this use and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.

For a service system, and also when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. For example, to make a flight reservation using a smart phone, the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, the core Internet Protocol (IP) network, the Internet Service provider (ISP), the World Wide Web (WWW), data centers, etc. All these are necessary to enable the service. When a caller makes a reservation and then books the flight, the value has been created.

Enterprise System Context

An enterprise system context is one in which the SoI is the enterprise system. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The WSoI describes the business environment within which the enterprise sits. It is to be noted that an enterprise context is not equivalent to an organization according to this definition. An enterprise includes not only the organizations that participate in it, but also the people, knowledge, and other assets, such as processes, principles, policies, practices, doctrines, theories, beliefs, facilities, land, and intellectual property that compose the enterprise. An enterprise may contain or employ service systems along with product systems.

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.