FitSM-­‐5

 Guide:  Specifying  Services  

 
 
Guide:  Specifying  Services  for  Portfolios  
and  Catalogues  
This  document  is  a  guide  for  specifying  services  for  Service  Portfolios  and  Service  Catalogues.  Version  
0.8  (2014-­‐02-­‐21])  

1. Context  
This   is   a   guide   for   specifying   services   as   part   of   a   Service   Portfolio   or   service   catalogue.   Service  
Portfolios  let  organisations  understand  what  services  they  provide  and  have  a  consistent  set  of  data  
about  them  to  support  service  management.  Service  Catalogues  contain  similar  information  but  are  a  
customer-­‐facing  view  showing  them  what  services  they  can  receive  and  under  what  conditions.    

This   guide   may   be   used   in   the   context   of   the   following   various   FitSM   components   (found   at  
www.fitsm.eu).  This  guide  related  to  the  following  components:  

• Template:  Service  Portfolio  and  Catalogue  (version  1.0)  

• Sample:  Service  Portfolio  and  Catalogue  (version  1.0)    

The  Services  to  be  specified  can  be  identified  with  the  following  FitSM  component:  

• Guide:  Identifying  Services  

Applying   this   guide   may   support   compliance   against   the   requirements   listed   in   FitSM-­‐1.   More  
specifically,  this  guide  refers  to  the  following  requirements:  

• FitSM-­‐1:2013  PR1.1:  A  Service  Portfolio  shall  be  maintained.  All  services  shall  be  specified  as  
part  of  the  service  portfolio.  
• FitSM-­‐1:2013  PR2.2:  A  service  catalogue  shall  be  maintained.  

This file is part of the FitSM series of standards for lightweight service
management in federated IT infrastructures. It is intended to support the
implementation (IT) service management following the FitSM approach or
related frameworks. This work is licensed under a
Creative Commons Attribution-
For  more  information  see  www.fitsm.eu.  
NoDerivs International License  

1   This  work  was  co-­‐funded  by  the  European  Commission  under  the  EC-­‐FP7  project  FedSM  (contract  number  312851).  
  FitSM-­‐5  Guide:  Specifying  Services  
 

2. Identifying  Services  
The  purpose  of  a  Service  Portfolio  is  to  understand,  both  internally  and  externally,  what  services  an  
organisation  provides.  This  is  necessary  for  effective  service  management  as  much  of  it  is  arranged  
and  managed  by  service.  A  Service  Portfolio  also  helps  create  an  internal  awareness  within  the  
organisation  of  the  concept  of  a  ‘Service’  from  an  ITSM  point  of  view,  rather  than  a  more  technology-­‐
orientated  point  of  view  (which  tends  to  refer  to  Service  Components  as  Services).  Services  can  be  
identified  using  the  FitSM  component  Guide:  Identifying  Services.  

The  Service  Catalogue  is  a  customer-­‐view  of  the  same  set  of  information,  showing  potential  
customers  what  services  are  available.  This  aligns  the  internal  and  external  view  on  what  customers  
are  offered,  which  eases  customer  relationship  management.  

3. Basic  Information  
Specifying  services  should  begin  with  basic  information  about  the  service:  Name,  Service  Description  
and  User  of  the  Service.    

Service  names  should  be  descriptive  from  a  customer  point  of  view,  and  should  be  quite  simple,  such  
that  someone  non-­‐technical  has  a  chance  of  understanding  what  the  service  is.  Service  descriptions  
should  be  similar,  and  consider  the  value  provided  by  the  service,  in  fairly  non-­‐technical  terms.  These  
descriptions  may  seem  obvious  but  help  everyone  within  the  organisation  understand  the  service,  
and  also  will  be  needed  for  the  Service  Catalogue,  which  will  be  shown  to  users  and  customers.    User  
of  the  Service  should  consider  the  direct  beneficiary  of  the  value  provided  by  the  service,  not  
downstream  beneficiaries  or  those  perhaps  paying  for  it.    

This  information  will  be  required  for  both  the  Service  Portfolio  and  Service  Catalogue,  though  the  
information  may  be  phrased  differently  for  the  internal  (Portfolio)  and  external  (Catalogue)  
audiences.    

4. Service  management  Information  

This  section  considers  basic  information  related  to  service  management,  specifically  related  to  
responsibilities,  contracts  and  agreements.  This  basic  information  can  be  collected  and  defined  even  
without  a  mature  IT  service  management  approach,  and  as  a  first  step  in  managing  services.    

4.1.Service  Owner  
For  each  service,  an  owner  should  be  assigned.  This  is  the  individual  who  has  accountability  for  the  
whole  service,  from  a  management  point  of  view.  They  will  have  an  understanding  of  the  service  
from  technology  through  to  user,  and  maintain  an  overview  of  the  effectiveness  and  success  of  the  
service.  They  should  sufficiently  senior  to  fulfil  this  role,  so  have  management  experience  of  some  
sort,  not  just  operational  experience.    

This  information  is  only  available  in  the  Service  Portfolio,  as  customers  do  not  need  to  know  which  
manager  is  responsible  for  each  service.    

2    
  FitSM-­‐5  Guide:  Specifying  Services  
 
 
4.2. Contact  Information  (Internal)  
This  is  the  agreed  contact  within  an  organization  for  communications,  questions  and  issues  relating  
to  the  service.  At  first  it  may  be  the  personal  contact  information  of  the  Service  Owner,  and  this  may  
be  sufficient  in  small  organizations,  but  it  is  preferable  to  move  toward  a  more  generic  email  contact  
such  as  [email protected].    Having  a  generic  or  role  based  contact  makes  it  
easier  to  cope  when  staff  are  absent,  or  when  a  role  such  as  Service  Owner  is  moved  from  one  
individual  to  another.    

This  information  is  provided  in  Service  Portfolios  but  not  in  Service  Catalogues.      

4.3. Contact  Information  (External  /  customer)    

The  agreed  contact  for  enquiries  regarding  the  service  from  an  external  or  customer  point  of  view.    
This  is  likely  to  be  used  by  those  considering  making  use  of  the  service,  rather  than  those  already  
using  the  service  who  will  use  support  contacts  (going  through  Incident  and  Service  Request  
Management)  and  customer  contacts  (going  through  Customer  Relationship  Management).  

In  general  a  generic  contact  such  as  [email protected]  (which  in  effect  

directs  enquiries  to  the  Service  Owner)  is  the  easiest  option,  though  it  could  also  direct  to  a  sales  
team  or  other  appropriate  group  within  the  service  provider.      

This  information  is  intended  to  be  in  the  Service  Catalogue,  and  while  it  can  also  be  held  in  the  
Service  Portfolio,  it  should  be  clearly  marked  as  for  external  rather  than  internal  use.    

4.4. Service  Status  

Service  Portfolios  should  include  not  only  services  current  offered,  but  also  those  offered  in  the  past,  
and  those  planned  for  the  future.  Decommissioned  services  are  included  as  some  services  may  no  
longer  be  offered,  but  may  be  still  operated  for  certain  legacy  customers.  Equally,  some  
decommissioned  services  may  still  impose  obligations  that  persist  after  the  services  are  
decommissioned  and  no  longer  used  (such  as  data  protection  obligations).    The  basic  statuses  of  
series  are  likely  to  be  some  version  of  ‘past’,  ‘present’,  and  ‘future’.    

The  Service  Status  is  only  displayed  in  the  Service  Portfolio,  as  the  Service  Catalogue  is  essentially  a  
filtered  subset  of  only  those  services  that  are  categorised  as  ‘present’  services  currently  offered  to  
customers.    

4.5. Service  Area/Category  

If  an  organisation  provides  multiple  services,  they  are  likely  to  want  to  categorise  them  in  various  
ways.  These  can  be  internal  classifications  (perhaps  related  to  departments,  or  physical  locations)  or  
external  ones  that  are  of  interest  to  a  customer.  Each  organisation  will  create  different  areas  or  
categories,  but  while  internal  classifications  may  come  first,  it  is  important  to  consider  whether  these  
are  useful  or  appropriate  for  customers  before  exposing  them.    

Service  Areas  or  Categories  are  not  obligatory  (for  instance  for  a  single  service  organisation)  and  may  
be  in  both  the  Service  Portfolio  and  Service  Catalogue,  though  they  may  be  different  categorisations,  
or  at  least  phrased  in  different  ways.    

 
3    
  FitSM-­‐5  Guide:  Specifying  Services  
 
 
4.6. Service  Agreements    
All  services  come  with  some  form  of  agreement  on  how  they  are  provided,  even  if  they  are  ‘there  is  
no  agreement,  you  use  it  as  it  is”.  More  traditionally  there  will  be  a  Service  Level  Agreement  (SLA)  
attached  to  the  service.  It  is  very  important  that  this  is  listed  for  all  services,  though  it  may  change  
over  time,  especially  as  service  management  is  initially  introduced  when  the  agreement  will  evolve  
from  ‘nothing’  to  quite  a  comprehensive  agreement  in  a  short  period  of  time.  However,  whatever  
the  current  agreement  is,  it  should  be  made  explicit.  This  is  needed  internally,  as  many  other  aspects  
of  service  management  are  aligned  to  the  agreement  –  for  instance  service  reporting  will  generate  
reports  based  on  what  is  agreed  with  customers  in  service  agreements.  If  the  agreement  is  ‘use  it  as  
you  find  it’  then  no  reports  are  promised  and  service  reporting  is  very  simple.  If  you  have  a  complex  
SLA  promising  weekly  custom  reports,  the  work  of  service  reporting  is  much  more  complicated.    

Service  Agreements  should  be  included  in  both  the  Service  Portfolio  and  Service  Catalogue,  though  
they  may  be  shown  in  different  ways.    

5. Detailed  Makeup  
This  section  looks  at  how  the  service  is  delivered  in  more  detail.  For  many  organisations  what  they  
may  previously  have  considered  ‘Services’  are  now  considered  ‘Service  Components’  from  an  IT  
Service  Management  point  of  view.    

5.1. Core  Service  building  blocks  (components,  activities  etc.)    

This  section  considers  what  activities  the  provider  must  undertake  to  make  the  service  available.  It  
will  be  a  list  of  components,  many  of  which  may  be  technical,  more  so  than  the  list  of  services,  which  
should  be  described  in  a  more  value-­‐orientated  way.    

This  will  include  generic  components  that  may  be  attached  to  every  service,  such  as  network  or  
helpdesk.  Others  may  be  more  service-­‐specific  such  as  a  particular  web  service  needed  for  a  single  
service.    This  list  tends  to  map  well  to  lists  of  activities  or  technical  services  that  many  organisations  
hold  before  they  begin  with  formal  IT  Service  Management.    

The  core  service  building  blocks  are  those  that  must  be  available  for  the  service  to  be  provided,  and  
are  at  used  or  at  least  available  to  all  customers.    

The  core  service  building  blocks  are  available  in  the  Service  Portfolio  but  not  the  Service  Catalogue.    

5.2. Additional  Service  Building  Blocks    

This  section  considers  components  that  may  be  offered  to  come  customers  but  are  additional  or  
optional  to  the  core  service.  These  may  be  value-­‐add  elements  over  and  above  the  core  service  that  
add  to  it.  An  example  might  be  that  a  storage  service  may  work  as  a  plain  network  storage  service  
using  crucial  components,  but  may  offer  an  additional  feature  of  version  control  that  is  not  required  
to  use  the  services,  but  is  a  value  adding  option  the  service  provider  offers.    

These  are  listed  separately  to  core  building  blocks  because,  for  instance,  failure  of  additional  blocks  is  
of  a  lesser  urgency  than  failure  of  core  blocks,  as  additional  blocks  are  used  by  a  subset  of  customers.  
Hence  they  are  considered  differently  in  a  service  management  context.    

 
4    
  FitSM-­‐5  Guide:  Specifying  Services  
 
 
Additional  building  blocks  are  listed  in  the  Service  Portfolio  but  not  the  catalogue,  as  the  same  
information  is  captured  in  a  different  way  in  the  Service  Catalogue,  as  Service  Packages.    

5.3. Service  Packages  

Service  packages  are  collections  of  the  core  components  with  different  sets  of  additional  
components  that  are  offered  to  customers.  To  continue  the  example  above  there  may  be  a  base  
package  called  ‘storage’  and  an  enhanced  package  called  ‘versioned  storage’,  There  may  then  be  a  
more  complex  enhanced  package  such  as  ‘versioned,  multiply  redundant  storage’  that  is  made  up  of  
the  core  components  plus  a  versioning  component  and  a  multisite  redundancy  component.    

These  Service  Packages  should  be  created  and  named  with  the  customer  point  of  view  in  mind,  so  be  
clearly  labelled  and  offer  clear  value.  Should  a  provider  require  different  descriptions  internally  these  
should  be  listed  as  additional  components  not  as  service  packages.    

Service  Packages  will  be  primarily  created  for  the  Service  Catalogue,  but  will  also  be  listed  in  the  
Service  Portfolio  such  that  the  provider  understands  which  additional  components  map  to  each  
service  package.    

5.4. Dependencies  
In  some  cases  a  service  may  be  built  up  not  only  from  components,  but  also  from  whole  other  
services  combined  with  additional  components.  In  this  case  there  is  a  dependency  between  one  
service  and  another,  and  it  makes  more  sense  to  list  the  dependency  on  the  other  service  as  a  whole  
rather  than  simply  the  components  within  it.  However,  if  there  is  a  service  listed  as  a  dependency  it  
must  also  be  listed  in  its  own  entry  in  the  Service  Portfolio.    

Dependencies  are  listed  only  in  the  Service  Portfolio  and  not  the  Service  Catalogue.    

6. Business  Case  
This  section  sets  out  factors  connected  to  the  service  in  a  business  sense,  considering  issues  of  
finance,  risk  management  and  value  delivery.  These  may  seem  quite  different  to  the  more  technical  
or  IT  Service  Management  aspects  considered  above,  but  are  important  to  consider  and  must  be  
considered  per-­‐service.  This  section  may  be  hard  to  fill  out  when  first  describing  a  service  in  terms  of  
service  management,  but  should  be  nonetheless  attempted.    

6.1. Cost  to  provide  

It  is  important  to  consider  how  much  it  costs  to  provide  a  service,  whether  or  not  you  charge  for  it.  
Having  considered  the  components  required  for  a  service,  it  is  possible  to  split  the  cost  of  providing  
the  component  such  as  a  helpdesk  (e.g.  staff,  offices,  IT  costs),  across  the  services  that  make  use  of  it.    

Cost  should  be  provided  in  a  unit  that  makes  sense  for  the  service,  such  as  €/terabyte  for  storage,  or  
€/CPU  hour  for  processing.  For  subscription-­‐based  services  it  may  be  cost  per  month  for  access.    

At  first  this  cost  may  be  a  rough  estimate,  but  this  should  be  refined  over  time,  which  will  often  be  
made  easier  by  implementing  other  aspects  of  service  management.    

This  information  is  provided  only  in  the  Service  Portfolio  and  not  the  Service  Catalogue.    

 
5    
  FitSM-­‐5  Guide:  Specifying  Services  
 
 
6.2. Funding  source  
Having  determined  the  cost  to  provide  the  service,  it  is  then  important  to  establish  where  these  
funds  will  come  from.  This  can  be  based  on  payment  from  customers,  payment  from  donors  or  
funding  bodies  or  perhaps  from  internal  resources.  This  is  important  as  to  ensure  sustainability;  costs  
and  funding  sources  must  be  aligned  and  understood.    

Options  include  pay  per  use,  subscription,  pay  per  unit,  indirect  via  a  funding  body,  or  based  on  
income  from  other  organizational  sources.    

This  information  is  provided  only  in  the  Service  Portfolio  and  not  the  Service  Catalogue.    

6.3. Pricing  
This  is  the  price  charged  to  customers,  if  one  applies.  If  offered  through  a  model  such  as  pay  per  use  
where  price  applies,  then  it  is  likely  to  be  the  cost  to  provide  plus  some  overhead  or  profit.  For  
instance  “cost  plus  10%”  would  be  a  standard  pricing  approach.  If  there  is  no  price  (if,  for  instance,  
the  service  is  indirectly  funded)  then  this  should  be  indicated.    

This  information  is  in  both  the  Service  Portfolio  (where  it  may  include  a  breakdown  of  the  
constituent  elements)  and  in  the  Service  Catalogue  (where  it  will  be  a  plain  price).    

6.4. Value  to  Customer  

This  should  capture  what  needs  this  service  meets  on  the  customer  side.  Why  it  is  beneficial  for  
them?  What  problem  does  it  solve?  Why  is  it  the  best  solution  for  them?  This  supports  marketing  
and  promotion  of  the  service.  Even  if  the  situation  involves  an  existing  technology  you  wish  to  push  
to  a  new  community,  you  should  attempt  to  capture  some  motivation  on  their  part  to  adopt  it,  
whether  it  is  utility,  ease  of  user,  cost  or  even  social  factors  such  as  desirability  or  ‘coolness’.  

Value  to  Customer  should  be  included  in  both  the  Service  Portfolio  and  Service  Catalogue,  though  
they  may  be  shown  in  different  ways  (one  internal,  one  external).    

6.5. Risks  
What  risks  are  presented  to  the  supplier  in  delivering  the  service?  While  many  risks  can  be  thought  
of,  here  you  should  list  the  major  ones.  For  a  paid  service,  this  may  be  lack  of  customers  willing  to  
pay.  For  an  indirectly  funded  service,  not  being  able  to  meet  the  promises  made  to  the  funding  body.  
Here  it  is  important  to  consider  the  bigger  picture  with  regards  to  the  service  and  the  service  
provider.  Understanding  the  risks  allows  them  to  be  balanced  against  benefits,  and  lets  the  service  
provider  understand  which  services  it  is  beneficial  to  offer.    

Risks  are  listed  in  the  Service  Portfolio,  not  in  the  Service  Catalogue.    

6.6. Competitors  
While  it  is  important  to  define  yourself  based  on  your  value  proposition,  it  is  always  necessary  to  
consider  competing  services.  Even  if  your  solution  is  better  and  cheaper,  perhaps  the  cost  for  
customers  to  switch  from  the  market  leader  to  you  is  too  high  to  make  your  service  viable.  In  this  
section  you  should  mention  the  major  competitors  to  your  service.  This  supports  decision  making  
regarding  whether  the  service  is  strategically  appropriate  to  offer.    

Competitors  are  listed  in  the  Service  Portfolio,  not  in  the  Service  Catalogue.  

 
6