Structure of the SEBOK (7)

The SEBoK is divided into seven parts, the first six of which focus on domain-independent knowledge, and the final part devoted to implementation examples.

Structure

Part 1: SEBoK 1.0 Introduction

To help you get the most out of the SEBoK, this part explains the scope, context, and structure of the SEBoK, and then turns to aspects of systems engineering (SE) itself that matter as you begin to use the SEBoK: SE's economic value, history, future, and relationship to other disciplines. An overview of who should use the SEBoK, and for what purpose, is followed by detailed use cases. This part concludes with a summary of how the SEBoK has evolved, and acknowledgments of the many individuals and organizations who have helped the SEBoK come to be.

Part 2: Systems

Stating what systems are, this section covers systems fundamentals and moves on to describe systems science in terms of history and major questions, systems thinking as a set of ideas to be used in SE, and modeling as a central process of SE. It concludes by looking at how to take a systems approach to an engineered system, which leads naturally into the next two parts, which are concerned with SE management and applications.

Part 3: Systems Engineering and Management

How systems are engineered is the subject of this part, which begins with the life cycle models common in SE, then moves on to SE management, where planning, measurement, risk, and quality are among the topics. Next is product and service life management, a distinct area of SE management that emphasizes the entire life cycle including retirement and disposal. An account of SE standards concludes this part. Focused on what many think of as the main body of SE, including best practices and common pitfalls, this part constitutes a substantial proportion of the SEBoK.

Part 4: Applications of Systems Engineering

How to apply SE as defined in the previous part is the focus of this one, which covers four major categories of systems in turn: products, services, enterprises, and systems of systems (SoS).

Part 5: Enabling Systems Engineering

How to organize to perform SE activities, at the enterprise, team, or individual level, is the subject of this part. The range of considerations extends from value proposition, business purpose, and governance, down to competency, personal development as a systems engineer, and ethics.

Part 6: Related Disciplines

How SE is intertwined with software engineering (SwE), project management (PM), industrial engineering, procurement and acquisition, and specialty engineering, is the subject of this part, which describes the various system “–ilities” (like reliability, availability, and maintainability) that SE must balance and integrate.

Part 7: Implementation Examples

A set of real-world examples of SE activities forms the natural conclusion of the SEBoK. These come in two forms: as case studies, which refer the reader to and summarize published examinations of the successes and challenges of SE programs, and vignettes, which are brief, self-contained wiki articles. This part is a key place to look within the SEBoK for lessons learned, best practices, and anti-patterns. Many links connect material in the examples to the conceptual, methodological, and other content elsewhere in the SEBoK.

Addenda

The SEBoK contains a Glossary of Terms, which provides authoritatively referenced definitions of key terms. It also contains a list of Primary References, with additional information about each reference. Quicklinks in the left margin provide additional background information, including a table of contents, a listing of articles by topic [1], and a list of Acronyms.

Inter-relationships

As you navigate the SEBoK, it may be useful to consider the relationships among the elements of the SEBoK and those found in its external environment. The figures (Scope and Context of the SEBoK) express those relationships. These figures are an outgrowth of a Systems Modeling Language (SysML) concept map whose development, application, and iteration were key activities when the SEBoK was being written.

Tiempo de implementación de un ERP (30)

Implementar un ERP no fue un proceso fácil para las compañías que lo hicieron. No se engañe cuando vendedores de ERP dicen que el tiempo de implementación, en media, es de tres o seis meses. Las implementaciones que fueron hechas en un corto tiempo (porque seis meses es un corto tiempo), fueron realizadas en pequeñas empresas, o fueron limitadas a pequeñas áreas de la empresa, o sólo usaron las partes financieras del programa (en lo cual el ERP es sólo un caro sistema de contabilidad). Para implementar un ERP correctamente, la forma en que se la empresa trabaja tendrá que cambiar, así como la forma como las personas trabajan. Y ese tipo de cambio no acontece sin dolor. A no ser que la forma en la que ud. negocia haga que le esté yendo extremadamente bien, los pedidos son embarcados en el periodo correcto, su productividad es mayor que la de su competencia, sus clientes están completamente satisfechos, si es así, en ese caso, no hay ninguna razón para pensar en instalar un ERP.

Es importante no focalizarce en el tiempo que llevará su implementación, ya que transformaciones reales con el ERP normalmente llevan entre uno y tres años de promedio, pero sí debe entender porque usted necesita un ERP y como puede utilizarlo para aumentar sus negocios.

*     Compañías pequeñas y medianas: desde unos meses hasta un año y medio

  -     mayores facilidades de coordinación

  -     posibilidad de implantar todo el sistema de una sola vez

 *    Grandes compañías: hasta cuatro años

  -   implementaciones por fases, en diferentes unidades de negocio, múltiples departamentos y elevado número de módulos

  -    gran cantidad de niveles de decisión que dificultan la coordinación

 *      Otros factores que influyen en el tiempo

 -      módulos ERP implantados

  -    necesidad de acometer proyectos de reingeniería de procesos

 -      modificaciones en el ERP

  *     no son muy habituales (la empresa se ajusta al ERP)

  *   cuando se realizan suelen provocar retrasos e incrementos significativos de costes

Igual que el precio de un ERP puede ser variable, también lo es el tiempo medio necesario para su implantación. Un producto que exija poca personalización puede implantarse en un mínimo de 2 meses, pero este tiempo sigue siendo poco habitual. Cuando se exige una mayor personalización, la adaptación del producto implica mayor tiempo de implantación. Una implantación media puede durar de 3 a 6 u 8 meses. Además en el factor tiempo no influye únicamente el producto y su complejidad sino también los recursos dedicados por la empresa a este proyecto. En efecto, mientras se está implantando el sistema, los trabajadores de la empresa deben desempeñar su labor cotidiana y además un esfuerzo añadido generado por la implantación del ERP.

Scope of the SEBOK (6)

Scope of the SEBoK The SEBoK is a large compendium of information about systems engineering. It:

• is a guide to the body of systems engineering knowledge which provides references to detailed sources for additional information; it is not a self-contained knowledge resource

• is domain-independent, with implementation examples to provide domain-specific context

• focuses on engineered systems (ES), that is, products, services, enterprises, and systems of systems (SoS), while treating social and natural systems as relevant and important environmental considerations for ESs

• recognizes that SE principles can be applied differently to different types of systems

• explores the interaction between SE and other disciplines, highlighting what systems engineers need to know about these disciplines

Each of these considerations depends upon the definition and scope of SE itself, which is the subject of the next section.

SE and Engineered Systems Project Life Cycle Context

We summarize the main agents, activities, and artifacts involved in the life cycle of SE, in the context of a project to create and evolve an ES.

For each primary project life cycle phase, we see activities being performed by primary agents, changing the state of the ES.

• Primary project life cycle phases appear in the leftmost column. They are system definition, system initial operational capability (IOC) development, and system evolution and retirement.

• Primary agents appear in the three inner columns of the top row. They are systems engineers, systems developers, and primary project-external bodies (users, owners, external systems) which constitute the project environment.

• The ES, which appears in the rightmost column, may be a product, a service, and/or an enterprise. In each row:

• boxes in each inner column show activities being performed by the agent listed in the top row of that column

• the resulting artifacts appears in the rightmost box

Arrows indicate dependencies: an arrow from box A to box B means that the successful outcome of box B depends on the successful outcome of box A.

Two-headed arrows indicate a two-way dependencies: an arrow that points both from box A to box B and from box B to box A means that the successful outcome of each box depends on the successful outcome of the other.

For example, consider how the inevitable changes that arise during system development and evolution are handled:

• One box shows that the system’s users and owners may propose changes.

• The changes must be negotiated with the systems developers, who are shown in a second box.

• The negotiations are mediated by systems engineers, who are shown in a third box in between the first two.

• Since the proposed changes run from left to right and the counter-proposals run from right to left, all three boxes are connected by two-headed arrows. This reflects the two-way dependencies of the negotiation.

An agent-activity-artifact diagram like Figure 1 can be used to capture complex interactions. Taking a more detailed view of the present example demonstrates this:

• The system’s users and owners (stakeholders) propose changes to respond to competitive threats or opportunities, or to adapt to changes imposed by independently evolving external systems, such as Commercial-off-the-Shelf COTS products, cloud services, or supply chain enablers.

• Negotiation among these stakeholders and the system developers follows, mediated by the SEs.

• The role of the SEs is to analyze the relative costs and benefits of alternative change proposals, and synthesize mutually satisfactory solutions.

SEBoK Domain Independence Context

The SEBoK uses language and concepts that are generally accepted for domain-independent SE. For example, the domain-independent conceptual foundations of SE are elaborated in Part 2, Systems. However, each of the numerous domains in which SE is practiced — including telecommunications, finance, medicine, and aerospace — has its own specialized vocabulary and key concepts. Accordingly, the SEBoK is designed to show how its domain-independent material relates to individual domains, by means of examples that tell stories of how SE is applied in particular domains.

While the main body of the SEBoK is domain-independent, all of (Part 7 ) consists of examples (case studies and vignettes), each set in a particular domain such as aerospace, medicine, or software, and featuring vocabulary and concepts special to that domain.

These examples demonstrate the effect of domain on the application of SE and complement the domain-independent information elsewhere in the SEBoK. They show how a concept works in a given domain and provide a fair opportunity for reviewers to reflect on whether there are better ways to capture application-dependent aspects of SE knowledge.

The authors recognize that case studies and vignettes add significant value to the SEBoK, and expect many more to be added as the SEBoK evolves.

SEBoK Life Cycle Context

We summarize the main agents, activities, and artifacts in the SEBoK life cycle.

The SEBoK is one of two complementary products. The other, which uses the content of the SEBoK to define a core Body of Knowledge to be included in graduate SE curricula, is called the Graduate Reference Curriculum in Systems Engineering (GRCSE) (Pyster et al 2012). GRCSE is not a standard, but a reference curriculum to be tailored and extended to meet the objectives of each university’s graduate program. These products are being developed by the Body of Knowledge and Curriculum to Advance Systems Engineering (BKCASE) project.

The BKCASE project, led by Stevens Institute of Technology and the Naval Postgraduate School, draws upon three primary resources. The U.S. Department of Defense (DoD) has provided the funding and a representative, but does has not constrain or direct the project’s approach and content. The DoD Systems Engineering Research Center (SERC), a DoD university-affiliated research center operated by Stevens Institute of Technology, supports BKCASE management and infrastructure and is the means by which DoD funding is delivered to the BKCASE project. The international author team of 70 members has been selected for expertise in SE and diversity of national origin (authors have come from 10 different countries in 5 continents), economic sector (government, industry, academia), and SE specialty area. Except for travel support in a few cases, authors have donated their time to the development of the SEBoK content.

The SEBoK content has been developed incrementally. Each of the prototype versions (0.25, 0.5, and 0.75) has undergone an open review by all interested parties. Over 200 reviewers have submitted thousands of comments, each of which has been adjudicated. Upon completion of the initial SEBoK and GRCSE development in late 2012, the Institute of Electrical and Electronic Engineers Computer Society (IEEE-CS) and the International Council on Systems Engineering (INCOSE), together with the SERC, are anticipated to become the primary stewards for both the SEBoK and the GRCSE. Interested parties will be able develop, operate, and support derivative products and services such as courseware, education, certification, and domain-specific versions of the SEBoK and the GRCSE.