The primary purpose of the Business Services Specification is to document the parts or the entirety of a value stream. Business Services Specifications (BSS) is a collective term. It covers; the target business service, the information exchanged with that service and any components that make up the service.
BSS artefacts are:
customer-facing, internal, and supplier-facing
compliant with the Minimum Viable Documentation principle
can be integrated with existing practices.
The benefits of BSS are:
Written in plain language and therefore universally accessible
Quick to produce and update
Focus on why and what without dictating how it is delivered.
Designed to be shared in complex business enterprises such as supply chains.
Document important service requirements early. Such as Response to Failure, SLA, and Service Completion Criteria.
Improved visibility and performance management
Support a Service-Oriented IT environment such as Microservices or largescale Cloud Services. However, the service focus of BSS works equally well with Monolithic applications and process-oriented Operational Technology (OT) situations such as SCADA systems.
Improves alignment with the needs of the customer and the objectives of the services
Improves CAPEX/OPEX blend and cost management and procurement options
Applies to current and future services.
Provides the basis for Service Operations Procedures
Increases the opportunity for service innovation, agility, and future-proofing when used with the ACD Cycle, VIPER, Metro Maps, and Transition State Planning. This motivates service delivery teams. An example is a VIPER workshop focused on defining new services.
A business service is an abstract representation of a part of a value-steam. It always consumes and usually produces information and data. The diagram below describes how it's associated with Information Exchange Objects and Business Service Components.
The focus is on Information Systems and Operational Systems rather than technology (IT or OT). Hence, when the Information Exchange Objects refer to any format of information; data, emails, conversations, phone calls post-it notes etc.
A BSS fact sheet uses a template to document a business service. A BSS can be applied to many aspects of the enterprise. It provides a common language for describing the aspects of both business behaviour (i.e..operation and informal behaviour) and information systems service provision.
Each service and service component should develop in the BSS fact sheet. The format is the same for a service or component. The need for documenting Components usually surfaces after a few iterations.
During business service delivery, there may be information exchange between the service provider and the service receiver. The Information Exchange fact sheet describes the information being exchanged in plain language for example - Customer account
- Customer name
- Customer address.
Principles of filling in the fact sheets
The principles govern how work is to be organised, structured, and performed. They also provide a rule of thumb to go by when there is uncertainty or disagreement. The following principles have been defined for filling the Business Service Specification and Information
Exchange fact sheet:
The service owner should endorse the BSS and Information exchange fact sheets
The fact sheets should be used to document the “as-is” and “to-be” services.
The fact sheets should be:
Simple – Communicated and easily adopted
Consistent – Business & IS/IT worlds
Interactive & Inclusive – Discussion & Enrolment focus on Iterative
Iterative - avoids attempts to ‘boil the ocean’.
Details of the BSS fact sheet
A BSS fact sheet follows a template to document a business service. There are a total of sixteen key BSS fact sheet areas and fourteen out of the sixteen areas are mandatory. Remember however completing the fact-sheets is an iterative process and as such early information may be incomplete. The aim is to complete all mandatory items by the final iteration.
The sixteen key BSS fact sheet areas are divided into three sections:
• Section A – Basic information
• Section B – Context Diagram
• Section C – Detailed Information.
1. Business Service name and ID
2. Service Owner
3. Service Contact
4. Component yes/no
5. Information Exchange fact sheets
6. Context Diagram
8. Description & Purpose
9. Primary Stakeholders
11. Service failure
12. Response to failure
13. Service Chain
14. Completion Criteria & Performance Measures (SLA/KPIs):
15. Estimated Volumes Handled
Similar fact-sheets are completed for Information Exchanges. These become more important for organisations who are exploring 'Data-Driven' approaches. In this case, an understanding of data/information produced and consumed across the enterprise is vital.
Please click here or on the image below, for a short handbook on completing both types of fact-sheet.
ACD site members will get access to an editable BSS template/form if enough interest is shown.
Service/Process confusion - one man's service is another's process. The reasons we use 'Service' as the prime concept are:
service is outside in whereas process is inside out
any process, manual or automated, can be described as a service (mentally put inside a service wrapper). This gives us a consistent language across any aspect of an enterprise regardless of who or how it's delivered.
The service concept is becoming increasingly important as parts of the business become 'externalised' e.g. Cloud SaaS etc.
Partially completing or updating the fact-sheets. The best method to avoid this is to assign responsibility to a (junior) Business Analyst he/she manages the service portfolio in a spreadsheet. An Energy firm did this successfully with a portfolio of around seventy business services.
Not being rigorous enough about Information Exchanges or limiting them to IT messages and transactions. Often the most interesting exchanges are not automated understanding them can lead to innovation.
Claims that BSS fact-sheets are not required because:
They're covered by Use Cases or'
Customer Journey's or,
Agile/SCRUM methods or
Our processes are documented according to XYZ standard.
While there is partial overlap, it's exceedingly small IMO:
BSS is not focused on software development, it is focused on the end-to-end service chain -people, process, and technology.
Certain business services do not have a clear 'User' but always have a consumer (e.g. a person or entity that experiences the impact of service failure) outside and inside the business.
Process models are useful but don't serve the same purpose. However, if you have great (up-to-date) process models it shouldn't take much to create 'service' lens. In practice, they usually lack essential elements like:
Failure and Response
Unstructured information exchange
First developed by DHL for modelling services across over two hundred countries & principalities, and used with numerous other brands since. The Business Service Spec (BSS) is a concise set of ‘Fact Sheets’ (e.g. four to five A4 pages) that describe what the service does and key Non-Functional Requirements of the service, such as performance metrics.
In line with the 'Just Enough' principle, experience has shown that the Business Service Spec fulfils the Minimal Viable Documentation requirements of a service. It is used to capture the attributes of the service, regardless of its implementation (technical or non-technical) and regardless of the size (e.g. BPO service, an ERP SaaS or a Microservice).
Information Exchange Specs document any type of information (e.g. data, conversations, messages etc.) produced or consumed by the service.