Economic Value of SE - SEBOK (4)

Trends Toward Increasing the Value of Systems Engineering

With traditional artifacts such as railroads, reservoirs, and refrigerators, the systems engineer faced a self-contained system, with relatively stable requirements, a sound scientific base, and numerous previous precedents. As more systems are intended to become parts within one or more evolving systems of systems (SoS) featuring rapidly increasing scale, dynamism, interdependence, human-intensiveness, sources of vulnerability, and novelty, the performance of effective SE takes on an ever-higher economic value.

Further Quantitative Evidence of the Value of Systems Engineering

Analysis of the effects of shortfalls in systems architecture and risk resolution (the results of inadequate SE) for software-intensive systems in the 161-project COnstructive COst MOdel II (COCOMO™ II) [1] database, show a statistically significant increase in rework costs as a function of project size measured in source lines of code (SLOC): averages of 18% rework for ten-thousand-SLOC projects, and 91% rework for ten-million-SLOC projects.

This result has helped major system projects to rectify initial underinvestments in SE (e.g., Boehm et al. 2004), and to determine “how much SE is enough” in general by balancing the risks of underinvesting in SE against those of overinvesting (often called “analysis paralysis”).

In general, small projects can quickly compensate for neglected SE interface definition and risk resolution, but as projects get larger, with more independently-developed components, late-rework costs rise much more rapidly than the savings in reduced SE effort. Medium-sized projects have relatively flat operating regions, but very large projects pay extremely large penalties for neglecting thorough SE.

Extensive surveys and case study analyses corroborate these results. Survey data on software cost and schedule overruns in My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader (Johnson 2006) indicate that the primary sources of the roughly 50% of the commercial projects with serious “software overruns” were actually due to shortfalls in SE (lack of user input, incomplete requirements, unrealistic expectations, unclear objectives, and unrealistic schedules). The extensive Software Engineering Institute (SEI) [2] - National Defense Industrial Association (NDIA) [3] survey of 46 government-contracted industry projects showed a strong correlation between higher project SE capability and higher project performance (Elm et al. 2007). Ongoing research combining project data and survey data reported in “Toward An Understanding of The Value of SE” (Honour 2003) and “Effective Characterization Parameters for Measuring SE”(Honour 2010) provide additional evidence of the economic value of SE, and further insights on critical SE success factors. A calibrated model for determining “how much SE is enough” has been developed in (Valerdi 2008). It estimates the number of person-months that a project needs for SE as a function of system size modified by 14 factors that affect SE effort needed. System size is defined in terms of numbers and complexity of requirements, interfaces, operational scenarios, and key algorithms. The factors that affect SE effort include architecture understanding, technology maturity, legacy-system migration, personnel capabilities, process maturity, and tool support.

Systems Engineering: Historic and Future Challenges

We can view the evolution of Systems Engineering (SE) in terms of challenges and responses. Humans have faced increasingly complex challenges and have had to think systematically and holistically in order to produce successful responses. From these responses, generalists have developed generic principles and practices for replicating success.

Evolution of Systems Engineering Challenges

From 1990 on, rapidly increasing scale, dynamism, and vulnerabilities in the systems being engineered have presented ever-greater challenges. The Internet offers efficient interoperability of net-centric systems of systems (SoS), but brings new sources of system vulnerability and obsolescence as new Internet services (clouds, social networks, search engines, geolocation services, recommendation services, and electrical grid and industrial control systems) proliferate and compete with each other.

Meanwhile, challenges come from several ways in which solution approaches have proliferated:

• While domain-specific model-based approaches offer significant benefits, reconciling many different domain assumptions to get domain-specific systems to interoperate is a challenge.

• The appearance of many competing object-oriented methods posed a problem that was addressed by the development of the Unified Modeling Language (UML) (Booch-Rumbaugh-Jacobson 1998) and the Systems Modeling Language (SysML) (Friedenthal 2008). However, the wave of UML and SysML tools that followed, along with a number of alternative requirements and architecture representations intended to compensate for shortcomings of UML and SysML, again create dilemmas around interoperability and choice.

• Among the areas that have seen a sometimes bewildering growth of alternatives are: enterprise architecture, lean and agile processes, iterative and evolutionary processes, and methods for simultaneously achieving high-effectiveness, high-assurance, resilient, adaptive, and life cycle affordable systems.

This trend towards diversity has increased awareness that there is no one-size-fits-all product or process approach that works best in all situations. In turn, determining which SE approaches work best in which situation, and how to sustain workable complex systems of systems containing different solution approaches, emerges as yet another challenge.

Similarly, assessing and integrating new technologies experiencing increasing rates of change presents further SE challenges. This is happening in such areas as biotechnology, nanotechnology, and combinations of physical and biological entities on the one hand, and mobile networking, social network technology, cooperative autonomous agent technology, massively parallel data processing, cloud computing and data mining technology on the other.

Ambitious projects to create smart services, smart hospitals, energy grids, and cities are underway. These promise improved system capabilities and quality of life, but carry risks of reliance on immature technologies or on combinations of technologies with incompatible objectives or assumptions. The advantages of creating network-centric systems of systems to “see first,” “understand first,” and “act first” are highly attractive in a globally competitive world, but carry challenges of managing complexes of hundreds of independently-evolving systems over which only partial control is possible. SE is increasingly needed but increasingly challenged in the quest to make future systems scalable, stable, adaptable, and humane. To accommodate this complexity, the SEBoK presents alternative approaches along with current knowledge of where they work best. Being a wiki allows the SEBoK to evolve quickly while maintaining stability between versions.

Scope of SE - SEBOK (3)

Scope of Systems Engineering within the Systems Domain

While considering all classes of systems, SE focuses on the domain of the engineered systems (ES). Socio technical systems are treated as a special form of engineered system. There are differences and commonalities in scope of the three overall categories of systems — engineered, natural, and social. For example, power generation and distribution systems are purely engineered systems which include software and human operators as well as hardware. Water and power safety legislation comes from the political processes of a legislature, which is a social system. The resulting water and power safety assurance and safety governance systems are sociotechnical systems whose participants work in both engineered systems and social systems.

The nature of and relationships between these system domains is discussed in Part 2, which considers the general nature and purpose of systems and how these ideas are used to ensure a better ES. Part 2 covers:

• Systems Thinking – a way of understanding complex situations by looking at them as combinations of systems

• Systems Science – a collection of disciplines that have created useful knowledge by applying systems thinking and the scientific method to different aspects of the system domains

• Systems Approach – a way of tackling real world problems which uses the tools of system science to enable systems to be engineered and used

One must understand both natural and sociotechnical systems to identify and scope the engineering of system problems or opportunities. This scoping largely determines whether engineered systems achieve their goals, without adverse impact on other outcomes, when those systems are deployed in the real world.

Scope of Systems Engineering within the Engineered Systems Domain

The scope of SE does not encompass the entire ES domain. Activities can be part of the SE environment, but other than the specific management of the SE function, not considered to be part of SE. Examples include system construction, manufacturing, funding, and general management. This is reflected in the International Council on Systems Engineering (INCOSE) top-level definition of systems engineering as, “an interdisciplinary approach and means to enable the realization of successful systems.” (INCOSE 2012) Although SE can enable the realization of a successful system, if an activity that is outside the scope of SE, such as manufacturing, is poorly managed and executed, SE cannot ensure a successful realization.

Again, a convenient way to define the scope of SE within the ES domain is to develop a Venn diagram. There is a relationship between SE, system implementation, and project/systems management. Activities, such as analyzing alternative methods for production, testing, and operations, are part of SE planning and analysis functions.

Such activities as production line equipment ordering and installation, and its use in manufacturing, while still important SE environment considerations, stand outside the SE boundary. System implementation engineering also includes the software production aspects of system implementation. Software engineering, then, is not considered a subset of SE.

Traditional definitions of SE have emphasized sequential performance of SE activities, e.g., “documenting requirements, then proceeding with design synthesis …”. (INCOSE 2012) The SEBoK authors depart from tradition to emphasize the inevitable intertwining of system requirements definition and system design in the following revised definition of SE:

Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal. (INCOSE 2012, modified)

Implantación de un ERP (27)

Aunque hoy en día las herramientas y metodologías son buenas, no se aconseja hacer la implantación en toda la empresa en una sola fase, a pesar que el coste y el tiempo es menor que si la implantación es multi-fase, ya que hay muchas posibilidades que algo salga mal.

La implantación de un ERP es un proyecto muy complejo debido a su profundo impacto en los procesos de la empresa.  La implantación se suele hacer por módulos (aprovechando la modularidad de los ERP). Se implanta un módulo, se prueba, se confirma el buen funcionamiento y se deja de utilizar esa parte del viejo sistema y se pasa al nuevo. Esta técnica es más barata que mantener el viejo sistema en funcionamiento hasta que esté totalmente implantado el nuevo.

La implementación de un sistema ERP, por lo general, es larga y compleja, ya que implica rediseñar los esquemas de trabajo. Su implementación es de alto riesgo, ya que implica complejidad, tamaño, altos costos, un equipo considerable de desarrollo, además de inversión de tiempo. En la mayoría de las empresas, se requiere reemplazar la infraestructura existente, lo que implica inversión de capital adicional, especialización y hasta la posibilidad de parar el negocio temporalmente para la implementación. Por otra parte es importante señalar que el grado de experiencia de los proveedores es un factor importante para el buen funcionamiento.

Después de la implementación es importante centrarse en el aseguramiento de la calidad y en la mejora de desempeño, para que así el sistema funcione correctamente a largo plazo. También, se debe analizar constantemente el retorno de inversión y aspectos clave como la optimización, la cual proporciona ideas que no fueron consideradas durante la implementación como por ejemplo la expansión del software implementado. Es importante ver a la optimización como un proceso de  mejora continua.

A la hora de implantar los módulos se comienza por el menos complejo y poco a poco se va pasando a los módulos con más dificultad. El orden de implantación será el siguiente:

- Elementos comunes (Sistema operativo, bases de datos, hardware, redes, etc.).

- Áreas funcionales. Subsistemas.

-          Ventas / Distribución.

-          Fabricación.

-          Finanzas.

-          Enlaces.

- Secuenciación. Recursos Humanos.

- EIS (Enterprise o Executive Information Systems. Almacén de datos: antes habían pocos datos y las decisiones se tomaban de cabeza; ahora hay mucha información e incluso en distintas plataformas e interesa tenerla junta para tomar decisiones. El EIS es una herramienta que proporciona acceso directo a la información relevante en un formato útil y navegable).

Data Warehousing (Data Warehouse: conjunto integrado de bases de datos, con orientación temática, diseñados para el Apoyo a la Toma de Decisiones. Data warehousing (Almacenamiento de Datos): proceso que facilita la creación y explotación de un Data Warehouse).

La implantación de un ERP implica un cambio en: la empresa, los procesos de  negocio, la disciplina de trabajo y la organización. También, es la base para la administración correcta del negocio y la toma de decisiones informadas

 ¿Por qué la empresa necesita un ERP?

Las razones por las que los empresarios optan por una solución ERP son:

1-Integración: las empresas que tienen un manejo aislado de la información generada en los distintos departamentos necesitan una solución global que integre y organice los datos para que de forma oportuna apoye la toma de decisiones y aporten soluciones en función de sus requerimientos particulares.

2- Competitividad: las empresas para mantenerse requieren continuas reducciones de sus costes, ya sea de producción, comercialización o administración, incrementando así constantemente su productividad. Permitiéndoles un crecimiento hacia nuevos planteamientos de negocio (CRM, e-business, etc.).

3- Control: la gerencia puede comprobar fácilmente que los parámetros más representativos de funcionamiento de la empresa se encuentran dentro de los márgenes preestablecidos. La gestión de costos y productividad quedan totalmente a su disposición.