Public

DESIGN SPECIFICATION

1(11)

Document number

Revision

PA2
Prepared by - IBM

Date

Contents responsible if other than preparer

Remarks

Report layout 1 and Report Layout 2

Approved by

Design Specification

TL 9000
TL 9000 BO reports

Version PA2

the responsibility of the user to ensure that they have a correct and valid version. Any outdated hard copy is invalid and must be removed from possible use.

Public
DESIGN SPECIFICATION

2(11)

Document number

Revision

PA2

Table of content
1
1.1
1.2
1.3
2
3
3.1
3.2
3.3
3.4
4
4.1
4.2
4.3
4.4
5
5.1
5.2
5.3
5.4
6
6.1
6.2

About the Project Business Blueprint

4
Purpose 4
What are the Business Blueprint deliverables?4
Updating the Overall Solution Document
4
Documentation update
5
Requirements 6
Functional requirements
6
Non-functional requirements 6
Technical requirements 7
General Assumptions 7
High-Level Design
8
Business process overview
8
Development objects required 9
Roles and Authorization 9
Master Data
9
General considerations
10
Impact on System Landscape 10
High-Level Test Considerations 10
Training requirements 10
Impact on related processes and 3rd parties 10
Glossary & abbreviations
11
Glossary 11
Abbreviations 11

Public
DESIGN SPECIFICATION

3(11)

Document number

Revision

PA2

Revision History
Version

Date

PA1
PA2

22-Sep-11

Description

Author

Creation of document

IBM

Updating of key figure list

IBM

Date

Name

Approval
Role

Public
DESIGN SPECIFICATION

4(11)

Document number

Revision

PA2

About the Project Business Blueprint

1.1

Purpose
The main purpose of this document is to provide input to IBM developers (IBM et.al.)
regarding the Business requirements and High-level design recommendations, as
assessed by IBM team together with Ericsson Solution Managers.

1.2

What are the Business Blueprint deliverables?

The Business Blueprint document is the main deliverable from the Feasibility and
Planning phase up until TG2. The blueprint document is a framework for stating the
business requirements for the project and the high-level design of the new or
changed processes for the technical solution.

1.3

Updating the Overall Solution Document

Once the project is finished and handed over to AM, the section High-Level design
should be added to the Overall Solution Document, which is part of the Solution
Documentation. This section is in this document marked with Add section to Overall
Solution Document.

Public
DESIGN SPECIFICATION

5(11)

Document number

Revision

PA2

Documentation update
The solution documentation should be maintained in Eridoc
The documentation will be verified as part of the documentation update process.

Public
DESIGN SPECIFICATION

6(11)

Document number

Revision

PA2

Requirements
This chapter describes the functional requirements, as well as non-functional and
technical requirements.
TL9000 measurements are collected from a wide area of identified source systems
and cross Ericsson business processes. The sources include PQAT, SMS, MH Web,
ISP tool and QASIS. The collection of measurements will be solved within each and
every decided source and aggregated and later loaded into BW. The aggregated
information will be base for end users analyzing measurements cross TL9000
Product Category and Customers.
The main source of information will be stored SAP Business Warehouse (BW) to
take advantage of existing roles of authorization and cleaning characteristic master
data.
If new information required, a process may be needed for adding the information
into BW.
For each report in the requirements list, the source of information should primarily
be identified in BW. New BW queries would then be created to feed B.O. universe
with the information for the reports.

3.1

Functional requirements
[List and describe requirements addressing functionality e.g. logics, processes,
integration, reporting etc. being the main batch of the requirement list]
There are a couple of report layouts suggested by the business to be delivered
through BO.
For report 1, the main functionality required is to select Product Area, Product, and
Customer and analyze measurements with tables and graphs for a set of key figures
by Product across Months. Since the ability to select KPI randomly is not possible in
BO, each key figure will be represented by one tab of report. The reports can be
grouped logically based on the key figures required to be displayed for this report
For report 2, the main functionality required is to select Product Area, Product,
Customer and Time Period and analyze data for many KPI for products for a
particular month.

3.2

Non-functional requirements
[List and describe requirements addressing performance, user
friendliness/application handiness, accessibility]
Users will be accessing BO reports through the BO Infoview. They will be using SAP
authentication to logon to BO. SAP authentication set up and cut over activities will
be done by TCS team

Public
DESIGN SPECIFICATION

7(11)

Document number

Revision

PA2

3.3

Technical requirements
[List and describe Requirements addressing landscape and architectural
requirements, security, archiving, other technical requirements and restrictions]
The data for BO reports are fed from SAP BW queries. A BW query with required
fields need to be created and tested before BO report development begins. The data
level security will be handled with BW with roles. The application security for BO, if
required, will be handled by TCS team
The layout is provided for 2 sets of reports. Both of these reports will use the
universe created out of TL9000 BW query. The variables created in BW query will be
displayed as report inputs in both the reports. If any new report input parameters are
required, it can be created in BO.
The drop down selections required in report layout will be provided as filters inside
the BO report. The selections are all single. When the reports are refreshed they
should show data for all customers the user its entitled to view. When the users
select individual customers, the report should show data for selected customer.
These are common functionalities for both reports
Report layout 1 - the report will show the months selected initially in the prompt
screen of the report. For example, if Jan 2011 to Mar 2011 is selected as calendar
year month range, then only 3 months will be shown in the report. Report layout 1
will be displayed in different tabs, each tab displaying one table and a graph for a
measure. The graph should be a line chart.
For report layout 2 the report should show only one month data at a time. It
should show all KPI along products for all customers. The data need to be
represented as Bar charts and in tabular form also. Drill filters to be provided for
Product Area, Product, Customer and Time period. The report should display the
Month for which data is displayed and the customer selected. The bar graphs for
different measures will be shown as different tabs in the report.

3.4

General Assumptions
[Assumptions, considerations and Information that is not captured in the
requirements above, but is fundamental to the solution concept]
1. Data will be available in BW during development and test phase
2. The reports will be accessed through Infoview
3. Selecting measurements / dimensions at the run time is not possible in BO, so
the reports will be developed in different tabs.
4. Data level security is implemented in BW
5. BO transports, Cut over activities and administration to be carried out by BO
admin team from TCS
6. Unit testing of BO reports will be done by cross verifying data with BW query
output.

Public
DESIGN SPECIFICATION

8(11)

Document number

Revision

PA2

High-Level Design

4.1

Business process overview

Overall description of Business processes (A Z), complemented by figure to
illustrate.

High level reporting process

Queries in BW will feed information to Business Objects (BO) universe.

In BW, if possible, existing info cubes and info objects should be used to
meet the reporting requirements.

Bases on B.O. universes detailed reports in B.O. frontend tools, e.g. WebI,
should deliver information according to business required layout.

Public
DESIGN SPECIFICATION

9(11)

Document number

Revision

PA2

4.2

Development objects required

1. Report Layout 1 - KPI analysis across calendar month & Product
2. Report Layout 2 All KPI analysis across Product

4.2.1

BW development
Please see the BW design document

4.2.2

BO development
The report layout from the business is attached below

Report layout.ppt

The set of key figures required in each layout is specified in the attached xls file
below. For each layout 2 reports need to be developed, leading to 4 BO Webi
reports

C:\Desktop Folder\
Ericsson\Deliverables\All Measurements Keyfigures in TL9000 BO.xls

4.2.3

Prototyping and sandboxing

[Reference to prototyping/sandboxing set up and results]
Possible report layouts in BO will be attached in Functional Spec

4.3

Roles and Authorization

For BW information, the user access roles are imported to business objects from
BW
List of users and user administration by admin team

4.4

Master Data
[Describe the need to create new or changed master data records. If applicable,
refer to relevant Master Data documentation.]
Not applicable

Public
DESIGN SPECIFICATION

10(11)

Document number

Revision

PA2

General considerations

5.1

Impact on System Landscape

[The Application Architect should make an assessment on the impact on the current
system landscape, and recommend to the vendors how to approach and address
this accordingly. A recommendation may include the need to introduce a new
component or a required system upgrade.
An overall assessment on how the solution will impact system performance should
also be included in this section.]
This is a new set of BO reports and no impact to existing BO landscape

5.2

High-Level Test Considerations

5.2.1

General Test Considerations

[Add relevant parts to Overall Solution Document, at go-live]
The BO report data will be reconciled against BW query, not with the actual sources
from where BW is fed the data

5.3

Training requirements
[Add relevant parts to Overall Solution Document, at go-live]
[Describe the high-level training requirements based on the project scope. New or
revised tasks in new or impacted processes should be noted in the table below.]
1. Quality data should be available in BW to test the reports during development
stage and testing stage

5.3.1

New/revised work tasks

Process tasks
Task

Description

Process

Table 1 - New/revised work tasks

5.4

Impact on related processes and 3rd parties

[Describe any impact on other internal solutions or process areas, as well as the
need to involve any 3rd parties regarding dependencies or impact on
communication efforts.]

Public
DESIGN SPECIFICATION

11(11)

Document number

Revision

PA2

Glossary & abbreviations

6.1

Glossary

Term

Explanation

Table 2 Glossary

6.2

Abbreviations

Abbreviation

Explanation

BO

SAP Business Objects

BW

SAP Business Warehouse

Table 3 Abbreviations