Skip to main content

Posts

Showing posts with the label Service Design

Service through Knowledge Management

I believe that a service provider can improve by choosing to follow best practices from ITIL, Lean, Agile and more.  That said I also believe that Knowledge Management will be the glue that ties in all together. Knowledge is required to deliver maximum results.  Knowledge Management ensures the right knowledge to the right people at the right time.  Think about yours or your customers service provisioning model.  How much time, money and resources is spent because of the lack of knowledge at the right time?  How frequently do we need information or access to the information and it is NOT available?  Not only is information not available when we need it, but sometimes it is replicated in many ways in many different places so that there is no real way to determine the definitive source.  It is difficult to get management control over the outcomes of an organization when the knowledge is out of control.  Knowledge Management is required throughout the Service Lifecycle.  A few exampl

Service Design - Ouch!

What is hurting the capability of service providers to design and deliver service at the rate of speed and at a cost that is viable to the business?  I asked a group of IT managers and practitioners in a recent training class and all agreed on these common causes: Lack of upper management strategy and direction. Lack of   adequate or accurate information Resistance to change Cultural issues / Agenda’s Inadequate funding I am sure you can add to this list.   Many service providers are suffering from the same pain.   What is causing this?   One area that most will agree upon is the fact that a lot of challenges for a service provider to deliver come from silos.   A classic silo and division that some organizations are addressing are those that exist between development and operational teams. That will help, but it’s not only siloed teams that are hurting this industry.   It is the fact that ITSM processes are also siloed.   If your processes and data are siloed even the best

The Best of Service Design, Part 4

ITIL 2011:  Design Coordination Originally Published on September 20, 2011 The Service Design stage of the ITIL Service Lifecycle can be a powerful and beneficial set of activities and undertakings if managed, guided and coordinated in a holistic and comprehensive manner. One of the more powerful processes to emerge with the publication of the ITIL 2011 addition is the Design Coordination process. Previous editions of ITIL had the reader and practitioner assume or extrapolate the guidance provided in the Design Coordination process. ITIL 2011 formalizes the guidance and shows the need to have a method of ensuring the smooth operation of all the moving parts of Service Design.   Design Coordination has several important objectives including (SD 2011 4.1.1): Ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements

The Best of Service Design, Part 3

The Importance of Availability Management Originally Published on July 5, 2011 The Availability Management process ensures that the availability of systems and services matches the evolving agreed needs of the business. The role of IT is now integral to the success of the business. The availability and reliability of IT services can directly influence customer satisfaction and the reputation of the business. The proactive activities of Availability Management involve the proactive planning, design and improvement of availability. These activities are principally involved within design and planning roles. The proactive activities consist of producing recommendations, plans and documents on design guidelines and criteria for new and changed services, and the continual improvement of service and the reduction of risk in existing services wherever it can be cost-justified. There are several guiding principles that should underpin the Availability Management process and its focus:

The Best of Service Design, Part 2

ITSM Requirement Gathering Techniques Originally Published February 20, 2010 In a previous discussion, we talked about the three levels of requirements in Service Design: Functional, Usability and Management and Operational. There is a range of techniques that can be used to actually obtain these services requirements. It is often difficult to get your customers to verbalize what they need. It has been my experience that the customers and the business are not completely sure of what their requirements actually are. They will need assistance and prompting from the designer or requirements gatherer. This must be done in a professional and sensitive manner to ensure that it is not seen as IT dictating the business requirement. We are all familiar with the most popular techniques, interviewing and workshops. The following is a list of additional techniques which might aid you in the Service Design requirements gathering stage: Observation: Watch your customers perform a spec

The Best of Service Design, Part 1

We continue our "Best of" blog series by  moving into Service Design. The Service Design Package Originally Published in 2010 I have gotten many questions about what value does the Service Design Package provide? We first must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, clear, concise and unambiguous specifications of the requirements must be documented and agreed. The SDP is where we document and agree to Requirements – What the business wants and how they plan to use this new service. Define who all of the stakeholders are  Service Design – Functionality of this new or changed service (SOR). Service levels to be delivered (SLRs, SLAs). Operational management requirements (OLAs, Contracts). Overall design and topology. Defined outcomes and deliverables.  Organizational Readiness Assessment

Measuring Service Management Maturity

I was recently asked about how to measure service management maturity when the maturity of individual processes is not equal. Frankly, it’s a bit of chicken and egg. It can be difficult to define where your organization is as a whole compared to each individual process when the processes are at different levels. When we look at a specific process we have to judge it against a specific set of criteria. Each organization will develop this criteria based on the organizational goals and objectives. Each process may have a different set of criteria, different levels of benefit or impact so therefore a different level of need-based maturity. For example, for organizations that are highly dependent on suppliers and outsourcing, the need for a mature Supplier Management process is critical. Other organizations may not focus on Supplier Management but invest their focus and resources on other processes such as Configuration Management. The maturity of individual Service Management process

Service Acceptance Criteria

I have often been asked what value does the Service Acceptance Criteria (SAC) provide? First let’s understand what the SAC is by definition. Service Acceptance Criteria: A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT Service when it has been deployed. This set of criteria is in the form of a formal agreement that an IT Service, Process, Plan or other deliverable is complete, accurate, reliable and meets the specified requirements. We must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, we must ensure that the contents of the Service Acceptance Criteria are incorporated and the required achievements are planned into the initial design. The Service Acceptance Criteria is the document that will en

Managing Data

Data is a critical asset of every business. It needs to be managed properly in order to deliver services effectively. If we do not manage our data, we will be maintaining and collecting data that is not needed. Data quality, integrity and security of information may be compromised. We are painfully aware of identity theft and the risk of unprotected data to our business. To effectively manage our information we must be able to answer the following questions: What data do we currently have, how is it classified, what if any are the security constraints? What data needs to be collected or created to support our business? What are our current and future needs for data storage and maintenance? Who will access the data, how will they access it? What are our disposal considerations, how long does the data need to be kept?  In the ITIL Service Lifecycle, during requirements gathering, answering these questions is essential for the implementation of new or changed services.

ITIL and PMBOK

Thanks for the great question Beverly. ITIL V3 and PMBOK Project Management are both best practices that fall under the larger umbrella of IT Service Management (or really just overall Service Management). ITIL focuses on the lifecycle of services, while PMBOK focuses on the lifecycle of projects. Services are all of the things we do to deliver value to our customers. In effect services are a type of product. Projects are temporary (short term) endeavors we undertake to accomplish specific outputs. So we can look at projects as one mechanism or vehicle for establishing and delivering services, products, solutions, etc. The decision as to undertake a project will be made as a result of ITIL Service Strategy and Service Design. The project team may then use PMBOK best practices for accomplishing the goal, objective or output identified during Strategy and Design. Conceptually this places Project Management roughly equivalent to ITIL Service Transition activities (with some overlap to Ser