MK01 en mySAP SCM

La transacción MK01 de mySAP SCM permite crear un registro maestro de proveedor, el cual guarda información acerca de los proveedores. Esta información es mantenida por Compras y Contabilidad. Este registro tienen datos generales, de Contabilidad y de Compras.

Los datos de este registro pueden ser mantenidos de 2 maneras: (1) Centralizada: se mantienen todos los datos juntos – XK01 y (2) Descentralizada: cada departamento mantiene sus datos – MK01.

Al invocar la transacción MK01, el número de proveedor puede ser asignado por el sistema o de manera automática. Este número de proveedor es generado en base a un rango definido en el grupo de cuenta. El grupo de cuenta se asigna el proveedor y determina el tipo de número de asignación, la selección del campo y los esquemas del socio. Este grupo permite suprimir campos específicos del proveedor y se asigna en el registro maestro de proveedor. Este grupo se usa para los proveedores eventuales. Los proveedores eventuales permiten trabajar con tales proveedores una vez o raras veces. Los datos son gruadazos en los documentos relevantes y no en el registro maestro de proveedor. El registro maestro colectivo permite usar un registro maestro de proveedor para varios proveedores.

La existencia de un registro maestro de proveedor es un prerrequisito para la creación de un documento de compras externo (Solicitud de cotización, orden de compra o outline agreement).

En el registro maestro de proveedor existen datos a nivel mandante, código de compañía, planta y organización de compras. Los datos a nivel planta y a nivel almacén tienen un rol importante en el mantenimiento del registro maestro de proveedor. Los datos específicos del proveedor no son adoptados como referencia para un nuevo registro maestro de proveedor. Los datos de compras son creados a nivel planta y a nivel organización e compras.

El grupo de cuenta permite determinar el estado del campo, intervalo de rango del número, tipo de número de imputación, roles del socio y el uso de los niveles de retención de los datos. Este grupo se puede cambiar y simplificar la creación de distintos datos para los niveles de planta y/o proveedor.

Se puede interrumpir el abastecimiento de un cierto proveedor, por medio del bloqueo de proveedores. Las opciones para bloquear un proveedor son: (1) Indicador de bloqueo en el registro maestro de proveedor (las órdenes de compra no pueden ser colocadas en ese proveedor. No se pueden crear solicitudes de cotización, contratos o libros de pedido), (2) Usa la transacción MK05, lo cual determina si el proveedor es bloqueado para una organización de compras o para todas las organizaciones de compras. (3) Utilizar el libro de pedido (source list) del material por medio del indicador ‘Blocking’

El mantenimiento del interlocutor principal, en el registro maestro de proveedor, permite distribuir uno o más roles entre los registros maestro de proveedor. Siendo interlocutor principal, se puede definir un acreedor distinto para cierto proveedor.

Distintos roles pueden ser mantenidos en el registro maestro de proveedor o en cada contrato. El rol del socio facilita a comunicación y se define a nivel planta u organización de compras. Los roles se pueden definir en el registro maestro de proveedor o asignar en el contrato. Cada socio debe ser asignado a un grupo de cuenta, el cual determina cómo es utilizado el socio del negocio en el sistema. Los proveedores pueden asumir una variedad de roles en el proceso de abastecimiento.

Estrategia del Servicio - ITIL V3 (2)

Esta parte de ITIL V3 describe la estrategia del Service Management y el valor de la planeación; cómo ligar los planes y la trayectoria del negocio a las estrategias de servicio de TI; la planeación y la implementación de las estrategias de servicio; los roles y responsabilidades; los desafíos, factores críticos del éxito y los riesgos.

Los servicios que demandan los clientes cambian muy rápidamente, las áreas de TI reciben los requerimientos del director de una organización, de los usuarios o de los clientes y en base a ello se debe diseñar una estrategia adecuada para cada empresa. En el pasado lo que se hacía era diseñar la estrategia y aplicar un plan, el gran problema es que se necesita más que eso, se requiere de una eficiencia operativa y servicios a un costo competitivo en comparación con los que ofrece la competencia.

El primer paso en la definición de la estrategia consiste en conocer las fuerzas competitivas que tiene una empresa y la competencia que debe enfrentar en el mercado, que obliga a las áreas de TI a lograr un mejor desempeño. Es necesario alcanzar un alto nivel de servicio para que los clientes realmente crean que una organización de TI en particular es la única alternativa que hay en el mercado, que es la opción correcta y no hay otra superior para brindarles los servicios de calidad que demandan, esta es la esencia de la estrategia.

Para comenzar a implementar una estrategia adecuada se debe primero detener la venta de servicios, la cual es una medida dolorosa pero es la alternativa para salir de un círculo vicioso. Los clientes conocen la diferencia en la calidad de los servicios no por los costos ni por la tecnología, sino por las cualidades y beneficios que obtienen, por esto es importante reducir los costos e incrementar las cualidades de los servicios para aumentar el número de clientes para las organizaciones de TI. Para salir del círculo vicioso lo primero es detener la venta de servicios para reconstruir y reparar las áreas de TI y poder ofrecer un desempeño superior, una vez que se mejore el servicio y la organización de TI los clientes regresarán en cuanto vean las mejorías y beneficios que pueden ganar.

La estrategia se compone de 4 piezas fundamentales: patrones y planes para saber cómo competir, a lo que se suma la perspectiva y posición sobre el mercado para actuar. Los clientes deben lidiar con muchas soluciones que les ofrecen en el mercado de bajo costo pero con poca calidad, o de alta calidad a un costo mayor, sobre estas premisas se basan las negociaciones en la industria de TI. Es un reto cambiar esta forma convencional de pensar, la estrategia de servicio se puede ver a través de los elementos del ciclo de vida de la administración del servicio con el objetivo de observar la perspectiva de la estrategia y las posiciones dentro del mercado.

De esta manera se pueden conocer las opciones que se tienen disponibles para establecer políticas y los recursos que integrarán la estrategia y que impactarán directamente en los ingresos de las organizaciones. Se enfatiza la importancia de la estrategia en conjunto con el diseño del servicio, ya que ambos validarán la mezcla de las posibles soluciones a los problemas para brindar un desempeño superior.

Se busca las reglas de juego para el deseado alineamiento perfecto entre las TI y el negocio; es decir que “cada uno aporte lo mejor al otro”. Este alineamiento sólo se ha entendido en una dirección: en cómo las TI se deben adaptar al negocio, y rara vez en su totalidad, es decir, concibiendo el alineamiento como un caminar juntos.

Los conceptos que se plantean en esta parte son: - Definición del servicio. - Estrategia de la gestión de servicio y planificación del valor. - Establecimiento de la dirección y del gobierno de los servicios de las TI. - Consecución del valor. - Relación entre los planes de negocio y las estrategias de los servicios de TI. - Arquetipos de servicios. - Tipos de proveedores de servicio. - Formulación, implantación y revisión de las estrategias de negocio.

PP y REQM en CMMi ACQ V1.2 (2)

PROJECT PLANNING

El propósito de Project Planning (PP), perteneciente al Nivel de Madurez 2, consiste en establecer y mantener los planes que se definen en las actividades del proyecto. Esta área de proceso involucra lo siguiente: (1) Desarrollo del plan de proyecto, (2) Interacción con las partes interesadas, (3) Obtener la conformidad respecto del plan y (4) Mantenimiento del plan.

La planificación comienza con los requerimientos que definen el producto y el proyecto. La planificación del proyecto incluye el desarrollo y mantenimiento de los planes de todos los procesos adquiridos incluidos los procesos que requieren una interacción proveedor-cliente. También incluye establecer y mantener un plan para la transición al producto adquirido.

El plan de proyecto necesita ser revisado para poder administrar los cambios que se realizan en los requerimientos. Estos cambios pueden afectar las estimaciones de la planificación del proyecto, los presupuestos, riesgos, tareas del proyecto, recursos y confirmaciones.

PP se relaciona con las siguientes áreas de proceso: ARD, REQM, RSKM, ATM, SSAD y MA. Los objetivos específicos (SG), prácticas especificas (SP) y subprácticas de esta AP son:

SG 1 - Establish Estimates

SP 1.1 – Establish the Acquisition Strategy

1.1.1- Identify the capabilities and objectives the acquisition is intended to satisfy or provide. 1.1.2- Identify the acquisition approach. 1.1.3- Document business considerations 1.1.4- Identify major risks and which risks will be addresses jointly with the supplier 1.1.5- Identify the preferred supplier agreement type 1.1.6- Identify the product support strategy 1.1.7- Review and obtain agreement with senior management on the acquisition strategy

SP 1.2 - Estimate the Scope of the Project

1.2.1- Develop a WBS (Work Breakdown Structure) based on the product architecture. 1.2.2- Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule 1.2.3- Identify product or product components to be externally acquired. 1.2.4- Identify work products to be reused.

SP 1.3 - Establish Estimates of Work Product and Task Attributes

1.3.1- Determine the technical approach for the project. 1.3.2- Use appropriate methods to determine the attributes of the work products and tasks to be used to estimate the resource requirements 1.3.3- Estimate the attributes of the work products and tasks.

SP 1.4 - Define Project Life Cycle

SP 1.5 - Determine Effort and Cost

1.5.1- Collect models or historical data to be used to transform the attributes of the work products and tasks into estimates of labor hours and costs. 1.5.2- Include supporting infrastructure needs when estimating effort and cost. 1.5.3- Estimate effort and cost using models and/or historical data.

Productos de trabajo típicos

Acquisition strategy (SP 1.1) Task descriptions (SP 1.2) Work package descriptions (SP 1.2) WBS (SP 1.2) Technical approach (SP 1.3) Size and complexity of tasks and work products (SP 1.3) Estimating models (SP 1.3) Attribute estimates (SP 1.3) Project lifecycle phases (SP 1.4) Estimation rationale (SP 1.5) Project effort estimates (SP 1.5) Project cost estimates (SP 1.5)

SG 2 - Develop a Project Plan

SP 2.1 - Establish the Budget and Schedule

2.1.1- Identify major milestones. 2.1.2- Identify schedule assumptions. 2.1.3- Identify constraints 2.1.4- Identify task dependencies. 2.1.5- Define the budget and schedule. 2.1.6- Establish corrective action criteria.

SP 2.2 - Identify Project Risks

2.2.1- Identify risks. 2.2.2- Document risks 2.2.3- Review and obtain agreement with relevant stakeholders on the completeness and correctness of documented risks. 2.2.4- Revise risks, as appropriate.

SP 2.3 - Plan Data Management

2.3.1-Establish requirements and procedures to ensure privacy and security of data. 2.3.2- Establish a mechanism to archive data and to access archived data. 2.3.3- Determine the project data to be identified, collected, and distributed. 2.3.4- Decide which project data and plans require version control or more stringent levels of configuration control and establish mechanisms to ensure project data are controlled.

SP 2.4 - Plan the Project’s Resources

2.4.1- Determine process requirements. 2.4.2- Determine staffing requirements. 2.4.3- Determine facilities, equipment, and component requirements.

SP 2.5 - Plan Needed Knowledge and Skills

2.5.1- Identify the knowledge and skills needed to perform the project. 2.5.2- Assess the knowledge and skills available. 2.5.3- Select mechanisms for providing needed knowledge and skills. 2.5.4- Incorporate selected mechanisms into the project plan.

SP 2.6 - Plan Stakeholder Involvement

SP 2.7 – Plan Transition to Operations and Support

2.7.1- Determine the transition scope and objectives. 2.7.2- Determine transition requirements and criteria. 2.7.3- Determine transition responsibilities and resources to include post-transition support enhancements and lifecycle considerations. 2.7.4- Determine configuration management needs of the transition. 2.7.5- Determine training needs for operations and support.

SP 2.8 - Establish the Project Plan

Productos de trabajo típicos

Project schedules (SP 2.1) Schedules dependencies (SP 2.1) Project budget (SP 2.1) Identified risks (SP 2.2) Risk impacts and probability of occurrence (SP 2.2) Risk priorities (SP 2.2)

Data management plan (SP 2.3) Master list of managed data (SP 2.3) Data content and format description (SP 2.3) List of data requirements for acquirers and suppliers (SP 2.3) Privacy requirements (SP 2.3) Security requirements (SP 2.3) Security procedures (SP 2.3) Mechanisms for data retrieval, reproduction, and distribution (SP 2.3) Schedule for the collection of project data (SP 2.3) List of project data to be collected (SP 2.3)

WBS work packages (SP 2.4) WBS task dictionary (SP 2.4) Staffing requirements based on project size and scope (SP 2.4) Critical facilities and equipment list (SP 2.4) Process and workflow definitions and diagrams (SP 2.4) Program administration requirements list (SP 2.4)

Inventory of skill needs (SP 2.5) Staffing and new hire plans (SP 2.5) Databases (SP 2.5) Training Plans (SP 2.5) Stakeholder involvement plan (SP 2.6) Transition to operations and support plans (SP 2.7) Overall project plan (SP 2.8)

SG 3 - Obtain Commitment to the Plan

SP 3.1 - Review Plans that Affect the Project

SP 3.2 - Reconcile Work and Resource Levels

SP 3.3 - Obtain Plan Commitment

3.3.1- Identify needed support and negotiate commitments with relevant stakeholders. 3.3.2- Document all organizational commitments, both full and provisional, ensuring appropriate level of signatories. 3.3.3- Review internal commitments with senior management as appropriate. 3.3.4- Review external commitments with senior management as appropriate. 3.3.5- Identify commitments regarding interfaces between project elements and other projects and organizational units so that these commitments can be monitored.

Productos de trabajo típicos

Record of the reviews of plans that affect the project (SP 3.1) Revised methods and corresponding estimating parameters (SP 3.2) Renegotiated budgets (SP 3.2) Revised schedules (SP 3.2) Revised requirements list (SP 3.2) Renegotiated stakeholder agreements (SP 3.2) Documented requests for commitments (SP 3.3) Documented commitments (SP 3.3)

REQUIREMENTS MANAGEMENT

EL propósito de Requirements Management (REQM), perteneciente al Nivel de Madurez 2, es administrar los requerimientos de los productos del proyecto y de los componentes del proyecto. Permite identificar las inconsistencias entre estos requerimientos y los productos de trabajo y planes del proyecto.

Los procesos de manejo de requerimientos administran todos los requerimientos recibidos o generados en el proyecto, incluyendo los requerimientos técnicos y no técnicos. Esta área de proceso es implementada y genera requerimientos del cliente y del contrato que serán administrados por los procesos de manejo de requerimientos.

Todos los proyectos tienen requerimientos. En el caso de un proyecto de mantenimiento, los cambios del producto o de los componentes del producto están basados en los cambios de los actuales requerimientos, en el diseño o en la implementación. Los cambios de los requerimientos pueden ser documentados en las solicitudes de cambio del cliente o pueden tomar la forma de nuevos requerimientos recibidos del proceso de desarrollo de requerimientos.

REQM se relaciona con las siguientes áreas de proceso: ARD, PP, CM, PMC y RSKM. Los objetivos específicos (SG), prácticas especificas (SP) y subprácticas de esta AP son:

SG 1 - Manage Requirements

SP 1.1 – Understand Requirements

1.1.1- Establish criteria for distinguishing appropriate requirements providers. 1.1.2- Establish objective criteria for the evaluation and acceptance of requirements. 1.1.3- Analyze requirements to ensure that established criteria are met. 1.1.4- Reach an understanding of requirements with requirements provider so that project participants can commit to them.

SP 1.2 - Obtain Commitment to Requirements

1.2.1- Assess the impact of requirements on existing commitments. 1.2.2- Negotiate and record commitments.

SP 1.3 - Manage Requirements Changes

1.3.1- Document all requirements and requirements changes that are given to or generated by the project. 1.3.2- Maintain a requirements change history including the rationale for the changes. 1.3.3- Evaluate the impact of requirement changes from the standpoint of relevant stakeholders. 1.3.4- Make requirements and change data available to the project.

SP 1.4 - Maintain Bidirectional Traceability of Requirements

1.4.1- Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented. 1.4.2- Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, interfaces, objects, people, processes, and work products. 1.4.3- Generate a requirements traceability matrix.

SP 1.5 - Identify Inconsistencies between Project Work and Requirements

1.5.1- Review the project’s plans, activities, and work products for consistency with requirements and changes made to them. 1.5.2- Identify the source of the inconsistency 1.5.3- Identify changes that must be made to plans and work products resulting from changes to the requirements baseline. 1.5.4- Initiate corrective actions.

Productos de trabajo típicos

Lists of criteria for distinguishing appropriate requirements providers (SP 1.1) Criteria for evaluation and acceptance of requirements (SP 1.1) Results of analyses against criteria (SP 1.1) An agreed-to set of requirements (SP 1.1) Requirements impact assessments (SP 1.2) Documented commitments to requirements and requirements changes (SP 1.2)

Requirements change requests (SP 1.3) Requirements change impact reports (SP 1.3) Requirements status (SP 1.3) Requirements database (SP 1.3) Requirements decision database (SP 1.3) Requirements traceability matrix (SP 1.4) Requirements tracking system (SP 1.4) Documentation of inconsistencies between requirements and project plans and work products, including sources, conditions and rationale (SP 1.5) Corrective actions (SP 1.5)

Productos de trabajo del Proveedor

Supplier’s requirements impact assessments (SP 1.2) Requirements change requests (SP 1.3) Requirements change impact reports (SP 1.3) Comprehensive requirements traceability matrix managed by the supplier as required by the supplier agreement (SP 1.4)