The concept of a "Service Asset" is part of the ITIL v3 book Service Strategy. "Service assets" are a strategic concept, but not an ITIL process.
In defining an IT department's strategy, it can be helpful to understand what sorts of "assets" the department has, or could acquire. ITIL v3 groups assets into two groups, "capabilities" and "resources."
The concept of "service assets" helps in creating a department strategy, because it helps planners understand how various assets might need to be developed to underpin the strategy. Also, strategic planning is often centered around the resources needed rather than the capabilities needed--and resources can be acquired directly while capabilities require significant time and effort to develop.
Capabilities are the things an organization has that it cannot buy outright. Capabilities include what a department's culture allows it to do. A great example of a capability is a process itself: no organization can "buy ITIL"--they can hire consultants, and train people, but the department has to build the process over time. Here are ITIL's five capabilities:
Resources are the things an organization has that it can pay for directly. Here are ITIL's five resources:
People are listed in both areas, because people can be hired, but people also have capabilities that are developed.
Utility and warranty are two Service Strategy concepts. It's important to understand the concept of a service to understand utility and warranty.
Utility is whether a service is "fit for purpose"--that is, whether the service does something useful.
Warranty is whether a service is "fit for use"--that is, whether the service has an adequate quality.
In ITIL v3, warranty is broken down into four questions:
These concepts can be applied to an organization, too. An organization that does "a little bit of everything" may have a high utility and low warranty. A decentralized IT department responsible for only one small part of overall IT, on the other hand, may have a very high warranty (for its few services) and low utility.
Someone has to run IT. Often University IT shops will be pushed to have higher and higher utility--that is, to support more and more services--without being able to sacrifice warranty.
It can be difficult for Universities to make strategic decisions about utility and warranty, especially when the University expects IT to "do everything." Ideally, Service Level Agreements govern the levels of utility and warranty for each service.
ITIL v3's "Financial Management" section in Service Strategy is complex and can be difficult to understand. ITIL v2's "IT Financials Management" section in Service Delivery is another source of information on Financial Management.
Financial management requires an understanding of an IT department's services. Please see Service Catalog Management.
Services have two types of costs:
Organizations typically have two types of budgets:
Financial management helps decompose an organization's operational budget into the costs for the services in its service catalog. That is, all operational costs should be tied either directly or indirectly to the offered services.
The cost of the services in the service pipeline should then match the capital budget: all capital costs should be tied to new or re-designed services.
ITIL does not take a position on whether to charge for services. It does lay out three options: not charging, "notional" charging, or charging. "Notional" charging means that IT tells departments how much it would cost, were they to be charged. Charging is sometimes seen as "soft money" when done internally. Charging can be an effective tool for supporting Demand Management.
University IT departments are sometimes funded from student fees. In this case, Financial Management might more resemble a report explaining how student fees are spent by service provided.
Demand management and capacity management are closely related. Demand management is about understanding (and shaping) user demands--looking at the market and knowing what people want. Capacity management is about knowing what IT can provide. Demand management is a service strategy process, because it's about understanding the market. Capacity is a service design process, because it's about designing a solution (ideally, one that matches the identified demand).
Service Strategy is about identifying markets and how IT can meet those market needs within certain cost and risk parameters. Demand management supports the Service Strategy phase by understanding what the market (or markets) want, and potentially shaping that market.
For example, demand management might identify that students want fast network connections between dormitories to play networked games. It might also help point out that email is most often used between 8-9 AM and 4-5 PM. Demand management helps IT understand how customers perceive value.
Demand management may also then try to shape that demand--in this example, by making the network sufficiently fast for network games only between 10 PM and 2 AM. Demand management may work with financial management to use "differential charging" for services based on when they are used.
Universities have many cycles that fit well with demand management, for example semesters. Universities know that registration will occur at a certain time, bills will go out at a certain time, and grades will be received at a certain time. University IT staff often know the impact of these cycles already. This knowledge, if written down, can go a long ways towards a "first version" demand management process.
This video is primarily about project demand management but the concepts are similar to service demand management.
"Service Portfolio Management" is not dissimilar from Project Portfolio Management or Program Management, project management terms. However, Service Portfolio Management manages the "new stuff" and existing services.
Service Portfolio Management is the ITIL Service Strategy process concerned with managing new, current, and retired services. The Service Portfolio Manager balances the three components of the service catalog:
Service Portfolio Management works with Financial Management and other processes to reports on cost allocation, the markets being addressed by service offerings, and they facilitate decisions about how IT's service catalog should change over time.
The portfolio helps align IT with the University, but without an understanding of the University's needs and values the portfolio can become unbalanced. Having a service portfolio management process is much different from having a service portfolio management process aligned with the University's values.
| Attachment | Size |
|---|---|
| Technology Evaluation Form FV1.doc | 60 KB |
The "Four Ps of Strategy" are one technique in IT strategic planning. They are not ITIL's only recommendation on strategy. If this material is interesting please review Service Strategy, especially chapter 3, "Service strategy principles."
The four "P"s of Strategy, as described in Service Strategy, are
For example, a University IT organization may say "We will ensure students have appropriate technology for their education, and it will be available when they need it." This would be the "perspective."
From that, they may say "We need to provide a wide range of services, and partner with other service providers if we cannot provide a certain level of warranty for these services." This would be their "position"--to provide a wide variety of services and outsource the riskier services.
Then they may draw up plans for an updated service portfolio, and the associated design and transition work needed to result in a new service catalog. This would be their "plans."
As the IT shop develops habits associated with this new strategy, such as by checking the availability of services each month to determine whether they are stable enough to continue offering, those habits become "patterns."
The "perspective" should tie into the overall University's strategic plans. For example, if the University is a land grant institution, the IT department's direction should probably include outreach.
University IT departments are often "Type I" or "Type II" providers, serving a single client or a single organization. This makes it difficult for IT to think about "positioning" itself--its market stays relatively constant.