Actrualización de CMMi DEV v1.3 (4)

SUPPLIER AGREEMENT MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products and services from suppliers.

SG 1 Agreements with the suppliers are established and maintained.

SP 1.1 Determine the type of acquisition for each product or product component to be acquired. SP 1.2 Select suppliers based on an evaluation of their ability to meet the specified requirements and established criteria. SP 1.3 Establish and maintain supplier agreements.

SG 2 Agreements with suppliers are satisfied by both the project and the supplier.

SP 2.1 Perform activities with the supplier as specified in the supplier agreement. SP 2.2 Ensure that the supplier agreement is satisfied before accepting the acquired product. SP 2.3 Ensure the transition of acquired products from the supplier.

TECHNICAL SOLUTION -- ENGINEERING (ML3)

The purpose of Technical Solution (TS) is to select, design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate.

SG 1 Product or product component solutions are selected from alternative solutions.

SP 1.1 Develop alternative solutions and selection criteria. SP 1.2 Select the product component solutions based on selection criteria.

SG 2 Product or product component designs are developed.

SP 2.1 Develop a design for the product or product component. SP 2.2 Establish and maintain a technical data package. SP 2.3 Design product component interfaces using established criteria. SP 2.4 Evaluate whether the product components should be developed, purchased, or reused based on established criteria.

SG 3 Product components, and associated support documentation, are implemented form their designs.

SP 3.1 Implement the designs of the product components. SP 3.2 Develop and maintain the end-use documentation.

VALIDATION -- ENGINEERING (ML3)

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

SG 1 Preparation for validation is conducted.

SP 1.1 Select products and product components to be validated and validation methods to be used. SP 1.2 Establish and maintain the environment needed to support validation. SP 1.3 Establish and maintain procedures and criteria for validation.

SG 2 The product or product components are validated to ensure they are suitable for use in their intended operating environment.

SP 2.1 Perform validation on selected products and product components. SP 2.2 Analyze results of validation activities.

VERIFICATION -- ENGINEERING (ML3)

The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

SG 1 Preparation for verification is conducted.

SP 1.1 Select work products to be verified and verification methods to be used. SP 1.2 Establish and maintain the environment needed to support verification. SP 1.3 Establish and maintain verification procedures and criteria for the selected work products.

SG 2 Peer reviews are performed on selected work products.

SP 2.1 Prepare for peer reviews of selected work products. SP 2.2 Conduct peer reviews of selected work products and identify issues resulting from these reviews. SP 2.3 Analyze data about the preparation, conduct, and results of the peer reviews.

SG 3 Selected work products are verified against their specified requirements.

SP 3.1 Perform verification on selected work products. SP 3.2 Analyze results of all verification activities.

GENERIC GOALS

GG 1 Achieve Specific Goals

The specific goals of the process area are supported by the process by transforming identifiable input work products into identifiable output work products.

GP 1.1 Perform the specific practices of the process area to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize a Managed Process

The process is institutionalized as a managed process.

GP 2.1 Establish and maintain an organizational policy for planning and performing the process. GP 2.2 Establish and maintain the plan for performing the process. GP 2.3 Provide adequate resources for performing the process, developing the work products, and providing the services of the process. GP 2.4 Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process. GP 2.5 Train the people performing or supporting the process as needed. GP 2.6 Place selected work products of the process under appropriate levels of control. GP 2.7 Identify and involve the relevant stakeholders of the process as planned. GP 2.8 Monitor and control the process against the plan for performing the process and take appropriate corrective action. GP 2.9 Objectively evaluate adherence of the process and selected work products against the process description, standards, and procedures, and address noncompliance. GP 2.10 Review the activities, status, and results of the process with higher level management with the appropriate visibility into the process.

GG 3 Institutionalize a Defined Process

The process is institutionalized as a defined process.

GP 3.1 Establish and maintain the description of a defined process. GP 3.2 Collect process related experiences derived from planning and performing the process to support the future use and improvement of the organization’s processes and process assets.

Actualización de CMMi DEV v1.3 (3)

PROJECT MONITORING AND CONTROL -- PROJECT MANAGEMENT (ML2)

The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.

SG 1 Actual project performance and progress are monitored against the project plan.

SP 1.1 Monitor actual values of project planning parameters against the project plan. SP 1.2 Monitor commitments against those identified in the project plan. SP 1.3 Monitor risks against those risks identified in the project plan. SP 1.4 Monitor the management of project data against the project plan. SP 1.5 Monitor stakeholder involvement against the project plan. SP 1.6 Periodically review the project’s progress, performance, and issues. SP 1.7 Review the project’s accomplishments and results at selected project milestones.

SG 2 Corrective actions are managed to closure when the project’s performance or results deviate significantly from the plan.

SP 2.1 Collect and analyze issues and determine corrective actions to address them. SP 2.2 Take corrective action on identified issues. SP 2.3 Manage corrective actions to closure.

PROJECT PLANNING -- PROJECT MANAGEMENT (ML2)

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

SG 1 Estimates of project planning parameters are established and maintained.

SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. SP 1.2 Establish and maintain estimates of work product and task attributes. SP 1.3 Define project lifecycle phases on which to scope the planning effort. SP 1.4 Estimate the project’s effort and cost for work products and tasks based on estimation rationale.

SG 2 A project plan is established and maintained as the basis for managing the project.

SP 2.1 Establish and maintain the project’s budget and schedule. SP 2.2 Identify and analyze project risks. SP 2.3 Plan for the management of project data. SP 2.4 Plan for resources to perform the project. SP 2.5 Plan for knowledge and skills needed to perform the project. SP 2.6 Plan the involvement of identified stakeholders. SP 2.7 Establish and maintain the overall project plan.

SG 3 Commitments to the project plan are established and maintained.

SP 3.1 Review all plans that affect the project to understand project commitments. SP 3.2 Adjust the project plan to reconcile available and estimated resources. SP 3.3 Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

PROCESS AND PRODUCT QUALITY ASSURANCE -- SUPPORT (ML2)

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

SG 1 Adherence of the performed process and associated work products to applicable process descriptions, standards, and procedures is objectively evaluated.

SP 1.1 Objectively evaluate selected performed processes against applicable process descriptions, standards, and procedures. SP 1.2 Objectively evaluate selected work products against applicable process descriptions, standards, and procedures.

SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured.

SP 2.1 Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers. SP 2.2 Establish and maintain records of quality assurance activities.

QUANTITATIVE PROJECT MANAGEMENT -- PROJECT MANAGEMENT (ML4)

The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project to achieve the project’s established quality and process performance objectives.

SG 1 Preparation for quantitative management is conducted.

SP 1.1 Establish and maintain the project’s quality and process performance objectives. SP 1.2 Using statistical and other quantitative techniques, compose a defined process that enables the project to achieve its quality and process performance objectives . SP 1.3 Select subprocesses and attributes critical to evaluating performance and that help to achieve the project’s quality and process performance objectives. SP 1.4 Select measures and analytic techniques to be used in quantitative management.

SG 2 The project is quantitatively managed.

SP 2.1 Monitor the performance of selected subprocesses using statistical and other quantitative techniques. SP 2.2 Manage the project using statistical and other quantitative techniques to determine whether or not the project’s objectives for quality and process performance are being satisfied. SP 2.3 Perform root cause analysis of selected issues to address deficiencies in achieving the project’s quality and process performance objectives.

REQUIREMENTS DEVELOPMENT -- ENGINEERING (ML3)

The purpose of requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements.

SG 1 Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.

SP 1.1 Elicit stakeholder needs, expectations, constraints and interfaces for all phases of the product lifecycle. SP 1.2 Transform stakeholder needs, expectations, constraints and interfaces into prioritized customer requirements.

SG 2 Customer requirements are refined and elaborated to develop product and product component requirements.

SP 2.1 Establish and maintain product and product component requirements, which are based on the customer requirements. SP 2.2 Allocate the requirements for each product component. SP 2.3 Identify interface requirements.

SG 3 The requirements are analyzed and validated.

SP 3.1 Establish and maintain operational concepts and associated scenarios. SP 3.2 Establish and maintain a definition of required functionality and quality attributes. SP 3.3 Analyze requirements to ensure that they are necessary and sufficient. SP 3.4 Analyze requirements to balance stakeholder needs and constraints. SP 3.4 Validate requirements to ensure the resulting product will perform as intended in the user’s environment.

REQUIREMENTS MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

SG 1 Requirements are managed and inconsistencies with plans and work products are identified.

SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements. SP 1.2 Obtain commitment to requirements from project participants. SP 1.3 Manage changes to requirements as they evolve during the project. SP 1.4 Maintain bidirectional traceability among requirements and work products. SP 1.5 Ensure that project plans and work products remain aligned with the requirements.

RISK MANAGEMENT -- PROJECT MANAGEMENT (ML3)

The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

SG 1 Preparation for risk management is conducted.

SP 1.1 Determine risk sources and categories. SP 1.2 Define parameters used to analyze and categorize risks and to control the risk management effort. SP 1.3 Establish and maintain the strategy to be used for risk management.

SG 2 Risks are identified and analyzed to determine their relative importance.

SP 2.1 Identify and document risks. SP 2.2 Evaluate and categorize each identified risk using defined risk categories and parameters, and determine its relative priority.

SG 3 Risks are handled and mitigated as appropriate to reduce adverse impacts on achieving objectives.

SP 3.1 Develop a risk mitigation plan in accordance with the risk management strategy. SP 3.2 Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

Razones para adoptar un ERP (2)

Dada la riqueza de los sistemas empresariales en términos de funcionalidad y beneficios potenciales, no debe sorprendernos que algunas organizaciones los adopten. Unas compañías plantean razones técnicas para invertir en sistemas empresariales. Y otras, tienen razones de negocio para la adopción de un sistema ERP. Sea cual sea la razón que las impulsa, tanto las pequeñas como las grandes empresas pueden beneficiarse técnica y estratégicamente de la inversión en sistemas empresariales. Al fin y al cabo, a pesar de las diferencias, las necesidades y oportunidades tecnológicas de las pequeñas empresas son derivaciones de las que enfrentan sus contrapartes de mayor tamaño.

Las grandes compañías también tienen dolores de cabeza debido al mantenimiento de diferentes tipos de sistemas del mismo tipo de aplicación. Boeing, por ejemplo, tenía 14 sistemas para facturación de materiales y 30 sistemas de control de almacén antes de adquirir un ERP.

Razones de negocio

(1) Adecuarse al crecimiento del negocio (2) Adquirir TI con capacidad para manejar multi-lenguajes y multi-monedas (3) Mejorar los procesos informales e ineficientes (4) Ordenar datos y registros por medio de la estandarización (5) Reducir gastos operativos y administrativos del negocio (6) Reducir costos de traslado y falta de inventario (7) Eliminar demoras y errores en completar órdenes de los clientes en negocios emergentes

Además de las mencionadas, las PyMEs tienen las siguientes razones de negocio:

(1) Proveer un apoyo integrado de TI (2) Estandarizar esquemas múltiples de numeración, etiquetación y codificación (3) Estandarizar procedimientos a través de diferentes localizaciones geográficas (4) Presentar una sola cara al cliente (5) Adquirir la capacidad global de capacitado para cumplir (6) Modernizar y agilizar las consolidaciones financieras (7) Mejorar la capacidad global de decisión de la compañía

Razones Técnicas

(1) Solucionar problemas como Y2K y similares (2) Integrar aplicaciones trans funcionales (3) Reemplazar interfaces difíciles de mantener (4) Reducir el mantenimiento de software (5) Eliminar entradas de datos redundantes y errores concurrentes (6) Mejorar el análisis de datos (7) Mejorar la arquitectura de TI (8) Desahogar restricciones de capacidad tecnológica (9) Disminuir costos operativos de TI

Es importante que una empresa considere estas variantes al momento de explicar las motivaciones, impactos y consecuencias de adoptar un ERP.