02 March 2011

Actualización de CMMi ACQ v1.3 (5)

AGREEMENT MANAGEMENT -- PROJECT MANAGEMENT (ML2)

The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.

SG 1 The terms of the supplier agreement are met by both the acquirer and the supplier. SP 1.1 Perform activities with the supplier as specified in the supplier agreement. SP 1.2 Select, monitor, and analyze supplier processes. SP 1.3 Ensure that the supplier agreement is satisfied before accepting the acquired product. SP 1.4 Manage invoices submitted by the supplier.

ACQUISITION REQUIREMENTS DEVELOPMENT -- ACQUISITION ENGINEERING (ML2)

The purpose of Acquisition Requirements Development (ARD) is to elicit, develop, and analyze customer and contractual 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 into contractual requirements.

SP 2.1 Establish and maintain contractual requirements, which are based on the customer requirements. SP 2.2 Allocate contractual requirements to supplier deliverables.

SG 3 Requirements are analyzed and validated.

SP 3.1 Establish and maintain operational concepts and associated scenarios. SP 3.2 Analyze requirements to ensure they are necessary and sufficient. SP 3.3 Analyze requirements to balance stakeholder needs and constraints. SP 3.4 Validate requirements to ensure that the resulting product performs as intended in the end user’s environment.

ACQUISITION TECHNICAL MANAGEMENT - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Technical Management (ATM) is to evaluate the supplier’s technical solution and to manage selected interfaces of that solution.

SG 1 Supplier technical solutions are evaluated to confirm that contractual requirements continue to be met.

SP 1.1 Select supplier technical solutions to be analyzed and analysis methods to use. SP 1.2 Analyze selected supplier technical solutions. SP 1.3 Conduct technical reviews with the supplier as defined in the supplier agreement.

SG 2 Selected interfaces are managed.

SP 2.1 Select interfaces to manage. SP 2.2 Manage selected interfaces.

ACQUISITION VALIDATION - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Validation (AVAL) is to demonstrate that an acquired product or service 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 Selected product and 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. ACQUISITION VERIFICATION - ACQUISITION ENGINEERING (ML3)

The purpose of Acquisition Verification (AVER) 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.

SOLICITATION AND SUPPLIER AGREEMENT DEVELOPMENT -- PROJECT MGMT (ML2)

The purpose of Solicitation and Supplier Agreement Development (SSAD) is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and establish and maintain the supplier agreement.

SG 1 Preparation for solicitation and supplier agreement development is performed.

SP 1.1 Identify and qualify potential suppliers. SP 1.2 Establish and maintain a solicitation package that includes the requirements and proposal evaluation criteria. SP 1.3 Review the solicitation package with relevant stakeholders to obtain commitment to the approach. SP 1.4 Distribute the solicitation package to potential suppliers for their response and maintain the package throughout the solicitation.

SG 2 Suppliers are selected using a formal evaluation.

SP 2.1 Evaluate proposed solutions according to documented proposal evaluation criteria. SP 2.2 Establish and maintain negotiation plans to use in completing a supplier agreement. SP 2.3 Select suppliers based on an evaluation of their ability to meet specified requirements and established criteria.

SG 3 Supplier agreements are established and maintained.

SP 3.1 Establish and maintain a mutual understanding of the agreement with selected suppliers and end users based on acquisition needs and the suppliers’ proposed approaches. SP 3.2 Establish and maintain the supplier agreement.

Razones para no adoptar un ERP (3)

Por supuesto, no todas las organizaciones adoptan sistemas empresariales, aun cuando tengan uno o varios de los motivos listados en el punto anterior. Algunas compañías deciden usar sólo ciertos módulos de un sistema empresarial, dependiendo de sus sistemas heredados o de los nuevos desarrollos. Otras, por diversas razones, abandonan la implementación o uso de estos sistemas.

La falta de “adaptación de características funcionales” entre las necesidades de la compañía y la oferta disponible en el mercado es una de las razones para no adoptar, implementar parcialmente o abandonar la integración de un ERP. La incompatibilidad obedece a que la mayoría de los módulos de manufactura de los sistemas ERPs han sido desarrollados para manufactura de partes discretas, por lo que no soportan algunos procesos de ciertas industrias.

Por ejemplo, los ERPs tienen dificultad para adaptarse a los procesos de industrias como la de alimentos y papel o a proyectos de la industria aeroespacial. Esta clase de compañías deciden modificar el ERP o adoptar sólo algunos módulos. Otra razón para rechazar un ERP obedece al crecimiento de la compañía, su flexibilidad estratégica y la descentralización en la toma de decisiones. A veces el ERP no está capacitado para mantener el ritmo de crecimiento de la empresa. Asimismo, las compañías que continuamente cambian su estructura organizacional, su modelo de negocio y, particularmente, aquellas que no operan verticalmente pueden encontrar inadaptables los ERPs como una solución empresarial.

Un tercer factor para no adoptar sistemas ERPs se refiere a la disponibilidad de alternativas para integrar sistemas. El almacenamiento de datos es una suma de tecnologías que sirve para integrar datos de múltiples fuentes para su análisis. La utilidad del almacenamiento de datos como estrategia de integración está limitada por la calidad de los sistemas fuente.

Otra alternativa a los sistemas empresariales implica la re-arquitectura de los sistemas internos alrededor de capas de middleware (software que funciona como intérprete entre dos aplicaciones incompatibles), con el objeto de aislar los sistemas de aplicaciones de los almacenes de “datos maestros”.

Algunos consultores comentan que la re-arquitectura de sistemas por medio de middleware es una alternativa viable a los sistemas empresariales cuando la empresa está satisfecha con la funcionalidad de sus sistemas y quiere sólo mejorar la integración del software y enriquecer la interface del usuario. Esta estrategia es utilizada en la industria de servicios financieros, donde los sistemas empresariales han hecho pocas incursiones, a diferencia de los sistemas administrativos. Las razones para no adoptar un ERP generalmente confluyen en los puntos antes mencionados.

Asimismo, se deben agregar los costos, ventaja competitiva y resistencia al cambio. Algunos analistas refieren que el miedo a perder una ventaja competitiva es la mayor razón para no implementar un ERP. El argumento es que si una compañía está segura de que la manera en que opera es la mejor, no aceptará adaptarse a las “mejores prácticas” incluidas en el ERP. Así es que si una compañía clama que ha perdido ventaja competitiva desde la adopción de un ERP, está diciendo que hace las cosas de diferente manera –mejor-- que el ERP. La cuestión consiste en averiguar si la negativa a adaptarse refleja “valor añadido por mejores prácticas” en la organización o una costosa ineficiencia que la organización no está dispuesta a abandonar.