05 June 2013

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.