1. YaSM® Process Map
1.1. The core of the YaSM model is a set of process diagrams in 3 levels of detail:
1.1.1. The top-level process diagram presents a high-level overview of the YaSM processes.
1.1.2. 19 overview diagrams on detail level 2 show for each YaSM main process how it is related to the other processes and what sub-processes it contains.
1.1.3. On detail level 3, 99 flowchart diagrams provide a detailed account of the process activities.
1.2. Platform-specific pages about the YaSM® Process Map
1.2.1. The YaSM® Process Map for Visio
1.2.1.1. http://yasm.com/en/products/yasm-process-map-visio
1.2.2. The YaSM® Process Map for ARIS
1.2.2.1. http://yasm.com/en/products/yasm-process-map-aris
2. Official Wiki
2.1. http://yasm.com/wiki/
3. Official website
3.1. http://yasm.com/en/
4. YaSM® data object model
4.1. The YaSM® data model presents the key relationships between the YaSM® data objects - the various documents and records which are produced by the YaSM® processes.
4.2. The YaSM process model (the "YaSM® Process Map") includes the YaSM data object model.
4.2.1. That diagram is not a complete data model as known from software engineering.
4.2.1.1. Rather, it is meant to provide an overview of the key relationships between the YaSM terms and to facilitate an understanding of each object's relevance within the YaSM framework.
4.3. Download: YaSM® Data Object Model
5. YaSM® roles (35)
5.1. Roles are used in YaSM® to illustrate the responsibilities for whole YaSM® service management processes or single process activities.
5.2. YaSM® RACI Matrix
5.2.1. The YaSM® RACI matrix, also known as "RACI model" or "responsibility matrix", provides a summary of the YaSM roles' responsibilities for whole processes or single process activities.
5.2.1.1. The YaSM® RACI matrix uses two types of responsibilities from the RACI model:
5.2.1.1.1. Responsible (R)
5.2.1.1.2. Accountable (A)
5.2.2. A RACI matrix describes the participation by various roles in completing tasks or deliverables for a business process.
5.2.2.1. It is especially useful in clarifying roles and responsibilities in cross-functional processes.
5.2.3. Download: YaSM® RACI Matrix
5.3. 1st level support
5.3.1. The responsibility of 1st level support is to register and classify received incidents and to undertake an immediate effort in order to restore a failed service as quickly as possible or to fulfill a service request. If no immediate solution can be achieved, 1st level support will transfer the incident to expert technical support agents or groups (2nd level support). 1st level support also keeps users informed about their incidents' status at agreed intervals. In some organizations, 1st level support is referred to as "help desk" or "service desk".
5.4. 2nd level support
5.4.1. 2nd Level Support takes over incidents which cannot be resolved immediately with the means of 1st level support. If necessary, it will request external support, e.g. from software or hardware manufacturers (often referred to as 3rd level support). The aim is to restore a failed service as quickly as possible.
5.5. Application / System developer
5.5.1. Developers are responsible for creating the applications and systems which support the service provider's range of services. This includes the development and maintenance of custom applications as well as the customization of products from software vendors.
5.6. Change advisory board (CAB)
5.6.1. A group of people that advises the change manager in the assessment, prioritization and scheduling of changes. The composition of this will vary depending on the nature of the changes to be assessed. It is usually made up of representatives from all areas within the service provider organization, the business, and third parties such as suppliers.
5.7. Change manager
5.7.1. The Change manager controls all changes across their lifecycle. His primary objective is to enable beneficial changes to be made, with minimum disruption to services. For important changes, the change manager will refer the authorization of changes to the change advisory board (CAB).
5.8. Change owner
5.8.1. Every change has a responsible change owner, holding the budget for its implementation. In many cases the change owner is identical with the individual submitting a request for change. Many changes are owned by service management roles (e.g. 1st or 2nd level support or a service owner).
5.9. Compliance manager
5.9.1. The compliance manager's responsibility is to ensure that standards and guidelines are followed. In particular, this role ensures compliance with internal policies and external legal requirements.
5.10. Configuration manager
5.10.1. The configuration manager is responsible for maintaining information about the infrastructure required to deliver the services. To this end he/ she maintains a logical model describing the components of the infrastructure and their associations.
5.11. Customer
5.11.1. Someone who buys services. The customer of a service provider is the person or party who agrees to use a service with specified service properties at a defined price.
5.12. Customer relationship manager
5.12.1. The customer relationship manager is responsible for maintaining a positive relationship with customers. This role identifies customer needs and makes this information available to the service provider organization, so that the service provider is able to offer an appropriate range of services.
5.13. Emergency change advisory board (ECAB)
5.13.1. A sub-set of the change advisory board that makes decisions about high-impact emergency changes. Membership of the ECAB is typically decided at the time an emergency change must be assessed and depends on the nature of the change.
5.14. Financial manager
5.14.1. The financial manager is responsible for managing the service provider's budgeting, accounting and charging requirements.
5.15. Human resources manager
5.15.1. This role ensures that the service provider employs the right balance of staff in terms of skills and experience. The human resources (HR) manager is also responsible for identifying gaps in the organization's current set of skills and for organizing any required skill development initiatives, in line with the service provider's objectives.
5.16. Incident manager
5.16.1. The incident manager is responsible for the effective implementation of the incident resolution process and carries out the corresponding reporting. He represents the first stage of escalation for incidents, should these not be resolvable within the agreed time frames in the relevant service levels.
5.17. Major incident team
5.17.1. A dynamically established team of managers and technical experts, usually under the leadership of the incident manager, set up to concentrate on the resolution of a major incident.
5.18. Operations manager
5.18.1. An operations manager will be needed to take overall responsibility for operating a service. For instance, this role will ensure that all day-to-day operational activities are carried out in a timely and reliable way.
5.19. Operator
5.19.1. Operators are the staff who perform the day-to-day operational activities. Typical responsibilities include: Performing backups, ensuring that scheduled jobs are performed, installing standard equipment in the data center.
5.20. Problem manager
5.20.1. The problem manager is responsible for managing the lifecycle of all problems, where the primary objective is to prevent incidents from happening if possible, and to minimize the impact of incidents that cannot be prevented. Apart from resolving the underlying causes of (potential) incidents, the problem manager often provides workarounds while a full solution is not yet available.
5.21. Process owner
5.21.1. This role ensures that the processes it owns are fit for purpose. The process owner’s responsibilities include the design and continual improvement of the process. In larger organizations there might be separate process owner and process manager roles, where the process manager has responsibility for the operational management of a process.
5.22. Project board
5.22.1. The project board is the decision-making body of the project. The project board typically consists of members of the management board and representatives of the different project stakeholders. It is important that the project board has real authority to take decisions.
5.23. Project manager
5.23.1. The project manager is responsible for directing a project, which includes responsibility for delivering the agreed project deliverables within the agreed time and budget.
5.24. Project owner
5.24.1. The project owner is the driving force behind a project. Typically, this role will prepare a business case and apply for a budget before a project is set up. As many projects are related to improving services, service owners will often act as project owners.
5.25. Security manager
5.25.1. The security manager is responsible for the service provider's and its customers' security. This includes responsibility for the security of information and data being processed by the service provider.
5.26. Service continuity manager
5.26.1. The service continuity manager is responsible for managing risks that could seriously impact the service provider's services. In particular, this role ensures that the service provider can provide minimum agreed service levels in cases of disaster.
5.27. Service design manager
5.27.1. The service design manager is responsible for the detailed specification of the requirements for new or changed services, as well as identifying a suitable approach for their implementation.
5.28. Service implementation manager
5.28.1. The service implementation manager is responsible for coordinating the implementation of new or significantly changed services. In particular, the service implementation manager ensures that all service infrastructure and other required capabilities are properly tested and deployed.
5.29. Service improvement manager
5.29.1. The service improvement manager is responsible for managing improvements to the service provider's range of services. In particular, this role will identify improvement potentials by analyzing service quality reports and performing service reviews.
5.30. Service owner
5.30.1. The service owner holds responsibility for delivering a particular service. In the case of a customer-facing business service, the service owner is responsible for delivering the service as specified in the customer agreement. In the case of supporting services, the service owner will often lead a team of technical specialists or an internal support unit.
5.31. Service portfolio manager
5.31.1. The service portfolio manager is responsible for managing the service provider's range of services. This includes making sure that the information in the service portfolio and any service definitions are accurate and up-to-date. The service portfolio manager will also support the steering group during strategic assessments of the service portfolio.
5.32. Service request fulfillment group
5.32.1. Service request fulfillment groups specialize in the fulfillment of certain types of service requests. Typically, 1st level support will process simpler requests, while others are forwarded to the specialized fulfillment groups.
5.33. Service strategy manager
5.33.1. The service strategy manager supports the steering group in producing and maintaining the service provider's strategy. This role is also responsible for communicating and implementing the service strategy.
5.34. SMS manager
5.34.1. The SMS manager is responsible for setting up and maintaining the service management system. This role plays a key part in managing the service management processes and policies, ensuring that all elements of the SMS cooperate in a seamless way to achieve the service provider's objectives.
5.35. Steering group
5.35.1. The steering group sets the direction and strategy for the service provider. It typically consists of members of top and middle-level management. The steering group has ultimate responsibility for the range of services offered by the service provider. As such, it also authorizes initiatives for the introduction of new or the enhancement of existing services. It is important that the steering group has real authority to take decisions.
5.36. Supplier manager
5.36.1. The supplier manager is responsible for ensuring that value for money is obtained from all suppliers. This role makes sure that the contracts with external suppliers support the service provider's needs, and that all suppliers meet their contractual commitments.
5.37. Technical domain expert
5.37.1. The technical domain expert provides technical expertise and support in various service management processes. There is typically one expert or team of experts for every key technology area or type of application or system. This role plays an important part in the technical aspects of designing, testing, operating and improving services.
5.38. Test manager
5.38.1. The test manager ensures that newly implemented services deliver the required outcomes, and verifies that all preconditions for operating a new service have been created.
6. YaSM® service lifecycle processes (LP) (5)
6.1. YaSM's service lifecycle processes are directly concerned with managing the service provider's range of services across their lifecycle.
6.2. LP1: Set the strategic direction
6.2.1. Process objective:
6.2.1.1. To decide on a strategy to serve customers. Starting from an assessment of customer needs and the market place, the strategic process determines which services the organization is to offer and what capabilities are required.
6.3. LP2: Design new or changed services
6.3.1. Process objective:
6.3.1.1. To define the expected outcomes and required properties of a new or changed service, to determine the infrastructure and other capabilities which are needed to provide the service, and to develop the approach for its implementation.
6.4. LP3: Build new or changed services
6.4.1. Process objective:
6.4.1.1. To build and deploy new or significantly changed services.
6.4.2. Coordination of development, acquisition and testing of all required service components.
6.5. LP4: Operate the services
6.5.1. Process objective:
6.5.1.1. To ensure the services are delivered effectively and efficiently, in line with the contractual commitments.
6.5.2. Fulfilling service requests, resolving incidents and problems, as well as carrying out routine operational tasks.
6.5.3. The service operation process includes two prominent sub-processes, LP4.6: Resolve incidents and service requests and LP4.7: Resolve problems.
6.6. LP5: Improve the services
6.6.1. Process objective:
6.6.1.1. To continually check if the services deliver the required outcomes and to identify potentials for improvement in the way the services are being produced.
7. YaSM® supporting service management processes (SP) (12)
7.1. YaSM's supporting service management processes provide various kinds of support to the service lifecycle processes.
7.2. SP1: Set up and maintain the service management system
7.2.1. Process objective:
7.2.1.1. To establish, operate and continually improve the service management system (SMS).
7.2.2. This process is responsible for managing the service management policies and processes as key components of the SMS.
7.3. SP2: Maintain the service portfolio
7.3.1. Process objective:
7.3.1.1. To ensure the service portfolio contains consistent and up-to-date information on the services managed by the service provider.
7.3.2. Controlling changes to the service portfolio and service definitions, as well as performing regular service portfolio reviews.
7.4. SP3: Manage customer relationships
7.4.1. Process objective:
7.4.1.1. To maintain a positive relationship with the customers.
7.4.2. In particular, the customer relationship management process identifies potential new customers and ensures that regular feedback is obtained from existing customers through customer meetings and surveys.
7.4.3. This process is also responsible for signing customer service agreements with the service provider's customers.
7.5. SP4: Manage configuration information
7.5.1. Process objective:
7.5.1.1. To maintain information about configuration items required to deliver the services, including their relationships.
7.6. SP5: Assess and coordinate changes
7.6.1. Process objective:
7.6.1.1. To control the lifecycle of all changes.
7.6.2. The primary concern of the change assessment process is to enable beneficial changes to be made, with minimum disruption to services.
7.7. SP6: Manage projects
7.7.1. Process objective:
7.7.1.1. To plan and coordinate the resources to complete a project within time, cost and scope.
7.8. SP7: Ensure security
7.8.1. Process objective:
7.8.1.1. To ensure the security of the service provider's range of services, and to align the security needs of the service provider with those of its customers.
7.8.2. Ensuring that systems and data are protected from intrusion and only accessed by authorized parties.
7.9. SP8: Prepare for disaster events
7.9.1. Process objective:
7.9.1.1. To ensure that the service provider can provide minimum agreed service levels in the case of events considered disasters.
7.9.2. This is achieved primarily by implementing mechanisms to prevent disasters from happening, and by establishing continuity plans and arrangements for the recovery of services once a disaster event has occurred.
7.10. SP9: Ensure compliance
7.10.1. Process objective:
7.10.1.1. To ensure that services, processes and systems comply with relevant legal requirements, standards, enterprise policies etc.
7.11. SP10: Manage human resources
7.11.1. Process objective:
7.11.1.1. To provide the skills and levels of staff required by the service provider to achieve its objectives.
7.12. SP11: Manage suppliers
7.12.1. Process objective:
7.12.1.1. To ensure that all agreements with suppliers support the needs of the business, and that all suppliers meet their contractual commitments.
7.13. SP12: Manage service financials
7.13.1. Process objective:
7.13.1.1. To manage the service provider's budgeting, accounting and charging requirement
8. This freeware, non-commercial mind map (aligned with the newest version of YaSM®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the YaSM® framework and as a learning tool for people wanting to know more about YaSM® model and framework. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)
8.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.
8.1.1. http://www.linkedin.com/in/miroslawdabrowski
8.1.2. https://www.google.com/+MiroslawDabrowski
8.1.3. https://play.spotify.com/user/miroslawdabrowski/
8.1.4. http://www.miroslawdabrowski.com
8.1.5. https://twitter.com/mirodabrowski
8.1.6. miroslaw_dabrowski