Software Asset Management
Functional documentation
Abstract
About master data, transacting and configuration
RBG Applications (Pty) Ltd
[email protected]
Table of Contents
1
Overview ......................................................................................................................................... 3
1.1
2
3
4
Introductory note.................................................................................................................... 3
Master data ..................................................................................................................................... 4
2.1
Participant ............................................................................................................................... 4
2.2
Functional area ....................................................................................................................... 4
2.3
Functional owner .................................................................................................................... 4
2.4
Functional consultant ............................................................................................................. 4
2.5
SDLC team ............................................................................................................................... 5
2.6
Project ..................................................................................................................................... 5
2.7
Business process ID ................................................................................................................. 6
2.8
Clearance code ........................................................................................................................ 6
Transactional data........................................................................................................................... 7
3.1
Change request ....................................................................................................................... 8
3.2
Development request and request version ............................................................................ 8
3.3
Work request .......................................................................................................................... 9
3.4
Work item ............................................................................................................................... 9
3.5
Deployment unit ..................................................................................................................... 9
3.6
Technical objects................................................................................................................... 10
3.7
Time record ........................................................................................................................... 10
3.8
Activity .................................................................................................................................. 10
Configuration ................................................................................................................................ 11
4.1
Request settings .................................................................................................................... 11
Priority........................................................................................................................................... 11
Complexity .................................................................................................................................... 11
Classification ................................................................................................................................. 11
Cancellation reason....................................................................................................................... 12
4.2
Request category .................................................................................................................. 12
Change request category .............................................................................................................. 12
Work request category ................................................................................................................. 12
4.3
Request number ranges ........................................................................................................ 12
Number range for change request................................................................................................ 12
Number range for development request...................................................................................... 13
SOFTWARE ASSET MANAGEMENT | Functional documentation
Number range for composite development ................................................................................. 13
Number range for work request ................................................................................................... 13
4.4
Change request approval ...................................................................................................... 13
4.5
Application settings............................................................................................................... 14
Application behaviour ................................................................................................................... 14
Application attributes ................................................................................................................... 14
Tracking notification ..................................................................................................................... 14
Classification ................................................................................................................................. 15
Online help .................................................................................................................................... 15
Archiving ....................................................................................................................................... 16
4.6
Technology settings .............................................................................................................. 16
Systems ......................................................................................................................................... 16
Technology .................................................................................................................................... 17
Load ABAP object types ................................................................................................................ 17
4.7
Capacity period settings ........................................................................................................ 18
Capacity period ............................................................................................................................. 18
Time unit of measure .................................................................................................................... 18
4.8
Business document service settings ..................................................................................... 18
BDS document classes .................................................................................................................. 18
BDS document class descriptions ................................................................................................. 19
Relevant BDS document classes ................................................................................................... 19
4.9
Application integration ......................................................................................................... 20
Ticket system ................................................................................................................................ 20
4.10
Enhancement ........................................................................................................................ 20
Change request business add-in ................................................................................................... 20
Development request business add-in ......................................................................................... 21
Work request business add-in ...................................................................................................... 21
5
Administration .............................................................................................................................. 22
5.1
Close expired change requests ............................................................................................. 22
5.2
Reschedule open work requests ........................................................................................... 22
5.3
Mass load of parent deployment units ................................................................................. 22
5.4
Evaluate work request implementation progress against schedule..................................... 23
5.5
Update of SAP CTS+/ TMS deployment units from original system ..................................... 23
5.6
Export of time records for SDLC resources ........................................................................... 24
SOFTWARE ASSET MANAGEMENT | Functional documentation
1 Overview
During the course of IT projects and in continuous improvement thereafter substantial capital
expenditure is made for bespoke software development. The purpose of ‘Management of bespoke
Software Assets’ (‘Software Asset Management’ for short) is to ensure a transparent, well
documented outcome of bespoke software development and in that way to protect the investment
made. Software Asset Management (SAM) will orchestrate project managers, functional consultants,
team leads, testers, application support and technical resources in such way that supportable and
maintainable software is produced on time.
Application features of SAM include support of all steps of the Software Development Lifecycle
(SDLC) managed in change requests, development requests, development request versions, work
requests, work items, tasks, activities and time records.
The add-on automatically carries out SDLC team capacity planning within and across development
teams giving achievable estimated software build completion dates. A workload overview by SDLC
team and each team member provides for capacity monitoring.
Role based user interfaces provide focused workplaces for role players participating in SDLC.
Further features of Software Asset Management include amongst others storage of supporting
documents, management of technical objects as bespoke software assets, capture of deployment
units and tracking through the configured system landscape, management of SDLC participants and
authorization control including management of clearance levels, free text and attribute search for all
application objects, automated e-mail based communication to participants, audit trail of changes,
capacity planning for SDLC teams with automated calculation of estimated completion dates for
work items.
This document provides an overview of master data, transactional data, configuration options and
administration related to Software Asset Management.
1.1
Introductory note
In the following we will refer to transaction codes where required to start relevant Software Asset
Management UIs. In order to avoid having to use SAP GUI for back office features we suggest you
activate the ‘HTML GUI’ internet service on your application servers using transaction SICF (path
‘/default_host/sap/bc/gui/ sap/its/’) and use your browser to navigate to the transactions that are
being pointed out.
Transaction /MBSA/APP is a useful area menu of Software Asset Management that contains all
possible master data, configuration, administration and UI options. Insert this transaction into your
favourites in SAP GUI or bookmark the corresponding webgui URL to this transaction in your
preferred browser. To view transaction /MBSA/APP in any browser the URL is composed as follows:
<protocol http or https>://<hostname>:<port>/sap/bc/gui/sap/its/webgui?sapclient=<sapclient>&~transaction=/MBSA/APP
SOFTWARE ASSET MANAGEMENT | Functional documentation
2 Master data
Software Asset Management uses master data to keep track of people, organization and business
processes that are affected by the Software Development Lifecycle. The following is a synopsis of all
master data items that the application uses. You can access all master data by following option
‘Maintain master data’ in area menu /MBSA/APP.
2.1
Participant
Participant in the Software Development Lifecycle (SDLC)
Use
A participant is any person participating in SDLC as functional owner, project manager, team lead,
functional consultant, software developer, system administrator or tester. Depending on the role
each participant contributes different services to the implementation of bespoke software assets.
Dependencies
Depending on team membership a participant plays a technical, system administrator or functional
role in SDLC.
2.2
Functional area
Functional area of a change request or work request
Use
A functional area is an area of common business practices with similar requirements in respect of
their IT processing needs.
Dependencies
A functional area is owned by one or several functional owners. The functional owner approves or
rejects suggested business requirements in his functional area to ensure a consistent overall
approach.
2.3
Functional owner
Functional owner of a request for change
Use
The functional owner is a participant in Software Asset Management. He owns business
requirements from ideation of a solution to deployment of its implementation to the Production
system.
Dependencies
It is part of the responsibilities of the functional owner to approve change requests for
implementation. The functional owner uses his functional owner workplace for this purpose.
2.4
Functional consultant
Functional consultant
SOFTWARE ASSET MANAGEMENT | Functional documentation
Use
Functional consultants are participants in Software Asset Management. Their role in the Software
Development Lifecycle is to translate business requirements into solution proposals for technical
resources to implement as bespoke software solutions.
Dependencies
Functional consultants create development requests or new development request versions, they
upload functional specifications to document the proposed solution and accompany the
implementation, testing and deployment to the production systems. To fulfil their tasks functional
consultants can make use of the functional consultant workplace.
2.5
SDLC team
SDLC team
Use
An SDLC team is a team taking part in the Software Development Lifecycle (SDLC) for the
implementation of bespoke software solutions. An SDLC team provides technical, functional or
system administration services to the IT services organization.
Dependencies
An SDLC team has a defined capacity determined by the number of team members and allocated
percentage of time each team member spends working for the team. Work requests that are
scheduled for implementation by an SDLC team consume that team's capacity. The estimated
implementation completion date of a newly scheduled work request is calculated automatically in
light of current team capacity.
Each SDLC team has a team lead who analyses business requirements coming through change
requests or solution proposals in the form of functional specifications submitted by functional
consultants in new development request (versions). Team leads estimate implementation effort and
schedule work requests for implementation thereof. They monitor implementation progress and
manage delays or overruns with their team members. To fulfil their tasks SDLC team leads can make
use of the team lead workplace.
2.6
Project
Project for the implementation of bespoke software solutions
Use
A project in Software Asset Management serves to ring-fence budget and resources for the
implementation of bespoke software assets. A project has a project manager and team members
that all contribute to the delivery. A project goes through various project phases. Depending on the
project phase different activities are allowable.
Dependencies
During the 'Planning' phase change requests and development requests can be created and
implementation scheduled using work requests. No hours may yet be logged for implementation of
SOFTWARE ASSET MANAGEMENT | Functional documentation
work. During 'Implementation' all planning activities for scope adjustment are allowed and
implementation time may be logged against the project. During 'Debriefing' no further scope
changes are allowed but further implementation hours for closing out of the project may be logged.
Project managers manage functional consultants to ensure timeous delivery of solution proposal
documents in the form of functional specifications. They follow up with SDLC team leads for the
timeous scheduling of work requests and with software developers for completion of work within
estimated timelines. To fulfil their tasks project managers can make use of the project manager
workplace.
2.7
Business process ID
Business Process ID as context of a bespoke software asset
Use
Business process IDs can be recorded against development request use cases. A use case identifies
the user group, action, object, location and timing in which the bespoke software solution plays a
role.
Dependencies
Development requests and their related technical objects can be found with use case elements as
selection criteria. This way it is possible to find development requests e.g. by user group or location
of its use.
2.8
Clearance code
Clearance code
Use
A clearance code provides an additional level of authorization control to protect classified
information in Software Asset Management from unauthorized access.
Example
In exceptional situations project teams might engage in design and implementation of bespoke
software solutions that are subject to non-disclosure agreements. All transactional data related to
such initiative can be protected from unauthorized access by capturing an appropriate clearance
code. Clearance codes are inherited from change request to development request and request
version and from development request version to work request.
SOFTWARE ASSET MANAGEMENT | Functional documentation
3 Transactional data
Software Asset Management uses transactional data to keep track of information that originates
during the Software Development Lifecycle. One of the most important outcomes of SDLC and a
focus of the Software Asset Management application are the bespoke software assets (technical
objects) that get created during implementation of business requirements. The following is a
graphical synopsis of the transactional data items that the application uses and their relationships.
You can access all transactional data in Software Asset Management by executing



transaction ‘/MBSA/APP_INBROWSER’ from within the SAP GUI or
using one of the ‘Execute’ options (in place or in browser) in area menu /MBSA/APP or
specifying URL <protocol http or https>://<fully qualified host name>:<http port of the ABAP
web application server>/sam, e.g. http://solmanprod.co.uk:8000/sam (available only if
related post-installation activity has been carried out)
This will open the UI of Software Asset Management (SAM UI for short) in your default browser
(options 1 and 2) or the browser of your choice (option 3). Each of the above transactional data
items has its own registry that allows for selection by attributes or search by means of free text.
Apart from registries there are also dedicated workplaces for all SDLC role players. Workplaces
contextualize the above transactional data items in a way best suited for the role held by SDLC
participants. Functional owners use their functional owner workplace for change request approval,
technical and functional team leads use their workplace for work request scheduling, technical and
functional resources use their workplace for self-service including self-allocation of work items,
progress feedback with time- and activity recording, to deliver solution proposals and other
supporting documentation for development requests or to monitor deployment of approved
changes to Production. Functional testers use their workplace to pass or fail testing of bespoke
software assets. Project managers orchestrate deliverables of project team members.
SOFTWARE ASSET MANAGEMENT | Functional documentation
3.1
Change request
The change request is an optional transactional data item in Software Asset Management. Its main
purpose is to be the ‘interface’ between the holder of requirements for bespoke software solutions
in an enterprise (typically: business, facilitated by an Enterprise Helpdesk Ticketing system) on the
one and the IT delivery organization on the other. The change request is the handle to:





Approval for implementation
Effort estimation and actuals
Business requirement documentation
Organizational context of the required change
Overall implementation, test and deployment status
After submission change requests are approved by the functional owner of the affected functional
area. After approval for implementation is granted, SDLC team leads analyse the required change,
create follow-on development requests or development request versions for solution
documentation and schedule for implementation using work requests. SDLC resources pick up
scheduled work requests and implement as per functional specification provided in the development
request (version). Status and actual implementation effort of the change request are tracked based
on progress feedback provided by SDLC resources on a regular basis.
Access change requests by means of option ‘Change requests’ in SAM UI.
3.2
Development request and request version
The development request and development request version is core to the Software Asset
Management application. It collects solution documentation and implementation context of
technical objects that represent the assets as outcome of bespoke software development. A
development request can be created stand alone or from a preceding change request.
A new development request should be created whenever a new bespoke software feature is
required. A new development request version should be created when an existing software feature
is amended during continuous improvement. An example of a development request is e.g. created
for the first implementation of a BAdI for purchase order item changes. Each change to the initial
BAdI implementation thereafter is documented with a new development request version. Each
development request version is a container for solution documentation. Ideally functional
specification documents are versioned and contain a revision history.
Development request versions are scheduled for implementation by creating related work requests.
SDLC resources pick up such scheduled work requests and implement as per functional specification
provided in the development request (version). Implementation status and actual implementation
effort of development request versions are tracked based on progress feedback provided by SDLC
resources on a regular basis.
Access development requests by means of option ‘Development requests’ in SAM UI.
SOFTWARE ASSET MANAGEMENT | Functional documentation
3.3
Work request
The work request is core to scheduling, capacity planning and implementation status tracking in the
Software Asset Management application. A work request can be created standalone, from a
preceding change request or from a preceding development request version. A work request should
be created standalone or with reference to a change request e.g. for bug fixes to bespoke software
features in Production. A work request should be created with reference to a development request
version when it is for implementation of a new software feature or for a change to an existing one
that is documented in a new version of the related functional specification.
For creation of a work request the following items of interest have to be provided (amongst others):




Implementation effort estimate
Requested date of completion
SDLC team and SDLC resource
Planned specification delivery date
Using this information Software Asset Management schedules the implementation of the work
request and calculates the estimated completion date in consideration of the current workload of
the assigned SDLC team. SDLC resources pick up such scheduled work requests and implement as
per functional specification provided in the related development request (version). Implementation
status and actual implementation effort of work requests are tracked based on progress feedback
provided by SDLC resources on a regular basis.
Access work requests by means of option ‘Work requests’ in SAM UI.
3.4
Work item
A work item originates when a work request is allocated to an SDLC resource for implementation.
This occurs when the SDLC team lead assigns an SDLC resource or when the SDLC resource picks up a
work request for implementation in his or her workplace. SDLC resources provide feedback about
implementation progress for each work item regularly. Progress feedback consists of:



Open effort estimate
Actual work hours spent
Revised completion date
SDLC resources use their relevant workplaces to provide progress feedback (functional consultant,
software developer, system administrator). Their progress feedback is considered when evaluating
the implementation status in respect of schedule, when rescheduling open work requests and also
for scheduling of new work requests in the SDLC team.
3.5
Deployment unit
A deployment unit is created in Software Asset Management for the purpose of getting insight into
technical objects that were created or changed during the implementation of a work request and
also to track their deployment in the system landscape.
SOFTWARE ASSET MANAGEMENT | Functional documentation
When you choose to create a deployment unit for deployment tool ‘SAP TMS’ or ‘SAP CTS+’
Software Asset Management automatically retrieves the content of that deployment unit (in this
case: the transport request) from the original (source) system. For each entry in the transport
request a technical object is created in the application and cross-references are established to the
work request, development request, solution documentation and change request involved.
Access deployment units by means of option ‘Deployment units’ in SAM UI.
3.6
Technical objects
Technical objects are the outcome of development of bespoke software solutions. Technical objects
can be captured manually for work requests or can be created automatically by capturing related
deployment units for ‘SAP TMS’ or ‘SAP CTS+’. Technical objects like classes, methods, functions and
screens are bespoke software assets and management of those is a core purpose of Software Asset
Management. Technical objects are cross-referenced to the work requests, development requests,
solution documentation and change requests that caused the object to be created or changed.
Access technical objects by means of option ‘Technical objects’ in SAM UI.
3.7
Time record
Time records are created when SDLC resources feedback actual working time for their work items. A
time record documents the time in hours that a participant spent on a specific workday for the
implementation of a specific work request. Participants use their functional consultant, software
developer or system administrator workplaces to capture their actual working time.
Time records are rolled up into the related work request, development request version and change
request. With this the overall actual implementation effort across all participating resources involved
in a change request is available for comparison to the effort estimate.
Access time records by means of option ‘Reports->Time log’ in SAM UI.
3.8
Activity
When the granularity of time records (participant, day of work, work request) is not sufficient for
tracking of actual time spent then progress feedback may also be provided on activity level. Using
activities participants can break down further their time spent on a day for a specific work request.
As an example a software developer can document for a specific day and work request which time
he or she spent analysing the functional specification and how much time was spent writing source
code.
To provide activity level progress feedback participants have to ‘toggle’ their view in progress
feedback. When in the activity view, several activities can be captured for the same work request
and work day. Saved activity time is rolled up into time records.
Access time records by means of option ‘Reports->Activity log’ in SAM UI.
SOFTWARE ASSET MANAGEMENT | Functional documentation
4 Configuration
Software Asset Management is a configurable application. The following is a synopsis of all options
in the Implementation Guide (IMG) to configure the application to your needs. You can access the
IMG by using transaction code /MBSA/IMG in the SAP GUI or by choosing option ‘Configure
application’ in area menu /MBSA/APP.
4.1
Request settings
Priority
Use
Optional configuration setting.
Priorities indicate the importance/ urgency of requests for bespoke software development. Priority
can be specified as an attribute of a change request or work request. Priorities captured in the
change request are merely for indicative purposes. When a work request is created with reference
to a change request the change request priority is promoted into the work request. In the work
request the priority influences the calculation of the estimated completion date. When scheduled
work requests absorb developer team capacity in descending sequence of priority.
Requests can be selected by priority.
Activities
Capture priority identification and description. Assign a ranking to establish a sequence of priorities.
This will impact scheduling in the developer team capacity.
Complexity
Use
Optional configuration setting.
Complexity is an optional work request attribute. In Software Asset Management complexity is
merely captured to help the developer team lead to make an effort estimate. Work request
complexity thus only plays an indirect role for calculation of the estimated completion date.
Activities
Capture complexity identification and description.
Classification
Use
Optional configuration setting.
Classifications are used to group requests in Software Asset Management for the purpose of request
selection.
Activities
Capture classification identifications and their descriptions.
SOFTWARE ASSET MANAGEMENT | Functional documentation
Cancellation reason
Use
Optional configuration setting.
Cancellation reasons can be captured for change requests, development requests and work
requests. A cancellation reason indicates that the corresponding request is no longer required. No
follow-on activities are allowed for cancelled requests.
Activities
Capture cancellation reason identifications and their descriptions.
4.2
Request category
Change request category
Use
Optional configuration setting.
Just like classifications request categories are used to group requests in Software Asset Management
for the purpose of request selection. In addition to a request classification though the request
category has attributes that control application behaviour. With change request categories you may
configure that requests of certain categories do not (yet) require development. Change request of
such categories are e.g. captured for the purpose of investigation before release to development.
Activities
Capture request categories and their descriptions.
Work request category
Use
Optional configuration setting.
Just like classifications request categories are used to group requests in Software Asset Management
for the purpose of request selection. In addition to a request classification though the request
category has attributes that control application behaviour. With work request categories you may
configure that requests of certain categories do not appear in request listings unless specifically
requested. Work request of such categories are e.g. captured for the purpose of support activities
that need not be listed on project status reports (but do need to be listed on the timesheet for
recording of actual time worked).
Activities
Capture work request categories and their descriptions.
4.3
Request number ranges
Number range for change request
Use
Required configuration setting.
SOFTWARE ASSET MANAGEMENT | Functional documentation
The number range for change requests is used to provide numbers for change request numbering.
Activities
The application will attempt to draw change request numbers from number range '01'. Please
therefore capture the number range with identification '01'.
Number range for development request
Use
Required configuration setting.
The number range for development requests is used to provide numbers for development request
numbering.
Activities
The application will attempt to draw development request numbers from number range '01'. Please
therefore capture the number range with identification '01'.
Number range for composite development
Use
Required configuration setting.
The number range for composite developments is used to provide numbers for composite
development numbering.
Requirements
The application will attempt to draw composite development numbers from number range '01'.
Please therefore capture the number range with identification '01'.
Number range for work request
Use
Required configuration setting.
The number range for work requests is used to provide numbers for work request numbering.
Activities
The application will attempt to draw work request numbers from number range '01'. Please
therefore capture the number range with identification '01'.
4.4
Change request approval
Use
Optional configuration setting.
Configure change request approval levels by role and change request release to development
dependant on approval level. If approval levels have been configured then Software Asset
SOFTWARE ASSET MANAGEMENT | Functional documentation
Management will request change request approvals for all change requests. If you want to do away
with the need for change request approvals remove all approval level configuration.
Choose an approver role allowed to approve on a specific level. Software Asset Management
distinguishes the 'Functional owner' and 'External Approver' role. The functional owner chooses to
approve or reject in the Functional Owner workplace for his functional area. The External Approver
comes into play when a ticket is integrated with Software Asset Management and external approvals
need to be taken into account. Approvals for approver role 'External Approver' cannot be given
through the Software Management UI but only through the call of a corresponding Enterprise
Service from outside the application.
Configure development release for developer teams dependant on a specific approval level. Only the
configured teams may start development (create development requests with reference to an
approved change request on the configured level).
Activities
Capture approval levels and their descriptions. Capture developer teams that may start
development when a specific approval level has been set.
4.5
Application settings
Application behaviour
Use
Optional configuration setting.
Certain behaviour of the Software Asset Management application is configurable. Use the
configuration settings in this activity to control such application behaviour.
Activities
Configure application behaviour as per your requirements. Choose features and behaviour options
from the dropdown menus.
Application attributes
Use
Optional configuration setting.
Application attributes of change requests, development requests and work requests are
configurable in their field status and whether mass maintenance is allowable (note: mass
maintenance is only available for change requests and work requests).
Activities
Configure application attributes with regard to their field status and whether mass maintenance is
allowable. Choose the application attribute from the drop down box (note that it needs to exist in
table /MBSA/S04 first to be available in F4 help). If an attribute has been allowed for mass
maintenance it then becomes available for maintenance (by pressing 'Mass maintain' in the toolbar
when listing requests through the change request or work request register).
Tracking notification
SOFTWARE ASSET MANAGEMENT | Functional documentation
Use
Optional configuration setting.
For change requests and work requests you can request tracking notifications to be sent by the
application. A tracking notification is a PDF document sent by mail to keep a selected role player in
the software development process informed about progress made. In this activity you can influence
the form that is used to output the tracking notification.
Requirements
For Software Asset Management to be able to successfully send tracking notification by mail it is
required for SAPconnect to be set up correctly and working. Please check 'send orders' (transaction
SOST) in SAPconnect once in a while to see that the e-mails are sent successfully. Note that if a
tracking notification cannot be sent a failed transactional RFC (tRFC) will be visible in transaction
SM58.
Activities
Capture the smartform to be used to produce the tracking notification. If no configuration is
available while still a notification is requested the system will use the default form
'/MBSA/REQST_TRACKINGNOTIF' to format the information for send.
Classification
Use
Optional configuration setting.
Use classification to provide additional attributes to change requests and work requests. Request
classification is maintained in a separate tab on the request form. With the use of a BAdi
implementation you can include characteristic values in the request register for reporting purposes.
Activities
Configure characteristics and related characteristic values that you would like to be available for
classification. Allocate characteristics to the change request and/ or work request application model.
To include characteristic values in the request register output use an implementation of BAdi
/MBSA/CHREQ or /MBSA/WRKREQ, method FIND_REQUESTS. Append fields to DDIC structures
/MBSA/S_CHREQ, and /MBSA/S_CHREQ_UI or /MBSA/S_WRKREQ and /MBSA/S_WRKREQ_UI
respectively. Using the BAdI populate the additional fields with the related characteristic value.
Classification information is stored in table /MBSA/T15.
Example
To keep track whether SDLC spend for a change request is either capital expenditure or operational
expenditure configure a characteristic 'Expenditure'. Capture allowable values 'CAPEX' and 'OPEX'.
Allocate the characteristic 'Expenditure' to application model 'Change request'.
With these settings you can now classify a change request in respect of the nature of related
expenditure as CAPEX (capital expenditure) or OPEX (operational expenditure).
Online help
Use
SOFTWARE ASSET MANAGEMENT | Functional documentation
Optional configuration setting.
Online help for Software Asset Management is held in SAP's KW (Knowledge Warehouse)
component. In this activity you configure the info object in SAP KW that is to be presented for each
help topic in Software Asset Management.
Requirements
SAP KW must be configured and working on the system running the Software Asset Management
application or on a remote system. Create/ maintain RFC destination AIO_FOR_HELP_LINKS to point
to the SAP KW system.
To edit online documentation presented in the online help you may install the 'SAP Knowledge
Workbench' as part of SAP GUI installation. Choose enhancement /MBSA/ to author additional
content.
Activities
Choose a Software Asset Management help topic and the appropriate link to the SAP KW info object.
The F4 help on the info object field will guide you through selecting the info object.
Archiving
Use
Optional configuration setting.
Configure whether requests that are flagged (and ready) for archiving should still be included in
request listings.
Activities
Choose an archiving status and flag the corresponding checkbox if you would like to exclude
requests of this status from request listings. Requests in this status will then only be included in
request listings if explicitly requested.
4.6
Technology settings
Systems
Use
In this activity you define systems that will be involved in your Software Development Lifecycle. In
addition to listing systems by ID you configure system connectivity. The system connectivity settings
set here allow the Software Asset Management application to read deployment unit content and
deployment status from the systems in question.
Systems you configure in this activity will be available to define the deployment path under
'Technology' configuration.
Requirements
In order to maintain system connectivity settings you need to already have created an RFC
destination (using transaction SM59) or an eSOA port (using transaction SOAMANAGER for
consumer proxy ‘ChangeListIn’). You will need this information to make necessary connectivity
settings.
Default Settings
SOFTWARE ASSET MANAGEMENT | Functional documentation
To enable Software Asset Management to retrieve deployment unit content and status for ABAP
transport requests (deployment tool TMS and CTS+) please capture an RFC destination for each
system in the transport route.
To retrieve content for PI change lists (deployment tool CMS) please configure an eSOA port as
connection. When configuring the port of your consumer proxy in transaction SOAMANAGER please
adopt the naming convention to use the system id of your PI system as the port name.
Activities
Capture systems and connectivity settings.
Technology
Use
Required configuration setting.
Software development involves various skills of solution development. In this activity you capture
the 'technologies' used in the process of implementing bespoke software solutions. The term
'technology' is used in a broad sense referring to the skill of solution providers participating in
development.
Note that the configuration of technologies must be made in conjunction with the developer team
structure present in the organization. The application model in Software Asset Management
assumes that a developer team is providing services in exactly one technology. Due to this it is not
advisable to have too much granularity in configuring technologies. Several developer teams may
offer services of the same technology.
Configure technical object types that get created by the various implementation technologies.
Object types captured here will be used to validate content of deployment units for work requests.
Only technical object types configured here will be allowed in deployment units of the specified
implementation technology.
Configure task types related to the various implementation technologies. Only task types captured
here will be presented for activity recording in progress feedback on the developer workplace and
the functional consultant workplace.
Activities
Capture technology identifications, e.g. Java, .Net, SAP ABAP and their descriptions. Note that
Configuration of systems (as opposed to coding) are also to be considered a technology for
implementation of solutions.
Load ABAP object types
Use
Optional configuration setting (required, if you are managing development using SAP ABAP)
Upon completion of a work request the assigned developer is requested to capture deployment
unit(s) that were created during implementation. Deployment units contain reference to technical
objects (programs, forms etc.) that make up the implemented solution.
For technology 'SAP ABAP' all technical objects contained in deployment units (transport requests)
are automatically loaded from their original system. For this automatic update to be successful the
SOFTWARE ASSET MANAGEMENT | Functional documentation
ABAP technical object types need to be preloaded into configuration of Software Asset
Management.
Activities
In the program linked to this activity specify the technology configured in Software Asset
Management that represents SAP ABAP. When you execute the program the SAP ABAP technical
object types will be loaded into configuration.
Example
Technical object types for SAP ABAP are e.g. 'PROG' (Program), 'DTEL' (Data Element).
4.7
Capacity period settings
Capacity period
Use
Required configuration setting.
Software Asset Management performs capacity planning comparing team capacity with work
requests (existing and new). Capacity time slots are buckets of time that are filled up with newly
initiated work requests on a 'first come first serve' basis into the future. Once a capacity slot is
exhausted scheduling will start consuming capacity of the next slot. During capacity planning the
system calculates estimated work completion dates for all work requests. The team lead of a
developer team can automatically adjust the existing work schedule of his team to take into account
changed priorities, reconfigured developer teams, updated effort estimates etc.
Activities
Configure capacity time slots by providing an identification, description and period. Capacity time
slots must be captured without overlap and gaps to avoid unexpected scheduling results. The time
slot identification is used in lists and workload overview and should be named conclusively (like
<month>-<year>).
Time unit of measure
Use
Required configuration setting.
Effort estimates and actual time spent on implementation is recorded in Software Asset
Management. At this moment the only time unit allowed is 'Hr' (Hours).
4.8
Business document service settings
BDS document classes
Use
Required configuration setting.
In this step you need to assign document areas of Software Asset Management to document classes
in SAP Business Document Service (BDS). This configuration is required so that uploading of
SOFTWARE ASSET MANAGEMENT | Functional documentation
supporting documents for change requests, development requests, work requests, deployment units
and technical objects is possible.
Requirements
SAP Business Document Service (BDS) is a standard feature of the SAP Web Application Server.
When choosing the BDS connection as per 'Standard setup' below please ensure to choose one that
meets your requirements with regard to client dependency, delivery class and document
transportability. The following are available BDS connections and their attributes:
BDS_LOC1/BDS_POC1/BDS_REC1/BDS_CONN00 Client dependant=yes, Delivery class='A',
Transportable=no
BDS_LOC2/BDS_POC2/BDS_REC2/BDS_CONN05 Client dependant=no, Delivery class='E',
Transportable=yes
BDS_LOC6/BDS_POC6/BDS_REC6/BDS_CONN06 Client dependant=yes, Delivery class='C',
Transportable=yes
BDS_LOC7/BDS_POC7/BDS_REC7/BDS_CONN04 Client dependant=yes, Delivery class='E',
Transportable=yes
Default Settings
Please capture the following entries or activate the related Business Configuration Set:
To allow uploading of supporting documentation for change requests:
/MBSA/CHRSPEC, type: object from class library, BDS connection of your choice
To allow uploading of supporting documentation for development requests:
/MBSA/DEVSPEC, type: object from class library, BDS connection of your choice
To allow uploading of supporting documentation for work requests:
/MBSA/WRKSPEC, type: object from class library, BDS connection of your choice
To allow uploading of supporting documentation for deployment units:
/MBSA/DPLOYUN, type: object from class library, BDS connection of your choice
To allow uploading of supporting documentation for technical objects:
/MBSA/TECSPEC, type: object from class library, BDS connection of your choice
BDS document class descriptions
Use
Description of the Business Document Service (BDS) classes. This description will be shown in the
document register.
Activities
Maintain the description of the BDS classes or activate the related Business Configuration Set. This is
a prerequisite for capturing ‘relevant BDS classes’ for Software Asset Management.
Relevant BDS document classes
Use
List of Business Document Service (BDS) classes that are to be used in Software Asset Management
Requirements
SOFTWARE ASSET MANAGEMENT | Functional documentation
The document browser in the Software Asset Management UI will only consider documents whose
document classes are maintained in the present configuration table. Ensure that you capture at least
the classes specified under 'Standard setup' or activate the related Business Configuration Set.
Default Settings
Ensure that the following are present in your configuration:
/MBSA/CHRSPEC CL Business requirement specification
/MBSA/COMPOS CL Composite development specification
/MBSA/DEVSPEC CL Functional specification
/MBSA/DPLOYUN CL Deployment unit description
/MBSA/TECSPEC CL Technical specification
/MBSA/WRKSPEC CL Test instructions and results
4.9
Application integration
Ticket system
Use
Optional configuration setting.
Software Asset Management organizes processes in the Software Development Lifecycle. During the
phase of support and maintenance of an installed base the user community initiates changes to the
bespoke software solutions that were put in place. Such changes are regularly requested through a
helpdesk system. Software Asset Management provides Enterprise Services for seamless adoption of
change requests from helpdesk systems and to provide feedback programmatically.
Default Settings
Software Asset Management provides Enterprise Service Definitions for creation and update of
change requests. Use a direct connection or a brokered connection from the helpdesk ticket system
to integrate with those services. Browse with transaction SOAMANAGER on the server running
Software Asset Management to get the corresponding WSDLs.
Software Asset Management is equipped with a configurable change management service. This
service will call a configured consumer proxy to connect to the subscribing helpdesk ticket system in
order to distribute change request updates.
Activities
Configure the helpdesk ticket system identification and description.
Configure application attributes that, when changed in Software Asset Management, need to trigger
an update to the helpdesk.
4.10 Enhancement
Change request business add-in
Use
Optional activity.
SOFTWARE ASSET MANAGEMENT | Functional documentation
Use this Business Add-In to enhance the behaviour of the change request model.
Default Settings
A default implementation for BAdI '/MBSA/CHREQ_BADI' is present in the system. The default
implementation will be executed in case you do not create an implementation of your own. If you
do, then the default implementation will not be executed any longer.
The default BAdI implementation '/MBSA/CHREQ_BADI_DEFAULT' ensures that for a helpdesk ticket
id there will ever only be one change request.
Activities
Execute this customizing activity to create a BAdI implementation.
Development request business add-in
Use
Optional activity.
Use this Business Add-In to enhance the behaviour of the development request model.
Activities
Execute this customizing activity to create a BAdI implementation.
Work request business add-in
Use
Optional activity.
Use this Business Add-In to enhance the behaviour of the work request model.
Activities
Execute this customizing activity to create a BAdI implementation.
SOFTWARE ASSET MANAGEMENT | Functional documentation
5 Administration
For normal operation Software Asset Management requires a number of programs to be executed in
background at regular intervals. The following gives insight into the purpose of those programs.
5.1
Close expired change requests
Purpose
Closure of expired change requests. Transaction code /MBSA/CHREQ_CLOSE.
Prerequisites
Only change requests that are completely implemented, successfully tested and deployed to
Production will be considered for closure.
Features
All implemented and tested change requests whose deployment was on or before the specified
expiry date will be closed.
5.2
Reschedule open work requests
Purpose
Reschedule open work requests of an SDLC team. Transaction code /MBSA/WRKREQ_RESCHED.
Integration
This program reschedules work requests of an SDLC team that are not completed or cancelled (open
work requests).
Prerequisites
Rescheduling of work requests for an SDLC team requires a team capacity that is greater than the
overall time required to complete open work requests for that team. If scheduling reaches the end
of the configured capacity horizon scheduling aborts.
Selection
Depending on program selection either all open work requests are rescheduled or only those work
requests that have been flagged for rescheduling. A work request is automatically flagged for
rescheduling when its scheduling parameters change (priority, implementation sequence, planned
specification delivery date, effort estimate, requested completion date, earliest development start
date). Alternatively a work request can manually be flagged for rescheduling.
5.3
Mass load of parent deployment units
Purpose
Mass load of parent deployment units for deployment units that are layered by definition of their
technology but where the assembly is incomplete (e.g. for SAP ABAP; layer 2 = task, layer 1 =
transport request: reference to task is created while reference to transport request is missing).
Transaction code /MBSA/DPLOY_LOADPRNT.
SOFTWARE ASSET MANAGEMENT | Functional documentation
Integration
In some approach to SDLC team work, different role players are responsible for different layers of
deployment units. While developers are typically required to manage the lowest level of deployment
units, the top layer is typically subjected to approval by a Change Approval Board and generally
managed by functional owners, business analysts or functional consultants.
The present program allows to mass load parent deployment units for a specified deployment unit
layer where such deployment units have not yet been loaded by the responsible SDLC role players.
Selection
Specify a technology (as configured in your installation), original system and/or deployment unit
layer for selection of deployment units. The deployment unit layer is an obligatory selection
parameter.
Output
Parent deployment units for deployment units on the specified layer are created.
Activities
This program should be run in circumstances where the SDLC process that normally leads to
complete assembly of deployment units across all required layers is not adhered to by all role
players.
Example
A SAP ABAP developer has released a workbench task (deployment unit layer 2). The functional
consultant, who is responsible to release the related transport request (deployment unit layer 1)
fails to capture the transport request on SAM (or the ERP API is not activated for automatic creation
on SAM at time of release).
5.4
Evaluate work request implementation progress against schedule
Purpose
Evaluate implementation progress in respect of schedule. Transaction /MBSA/EVAL_SCHEDULE.
Integration
This program compares work request implementation progress at point of program execution with
the planned estimated completion date. Depending on progress, work requests are categorized as
on time, delayed (due to missing functional specification), being on the critical path or overdue.
Output
The result of schedule evaluation will be updated into affected work requests. During work request
rescheduling overdue work requests and work requests on the critical path are considered with
higher priority compared to requests in other statuses.
5.5
Update of SAP CTS+/ TMS deployment units from original system
Purpose
SOFTWARE ASSET MANAGEMENT | Functional documentation
Program to evaluate the progress of deployment units through the system landscape
Integration
This program reads the content and logs of deployment units from connected systems in order to
evaluate the progress of deployment units through the configured system landscape. The
deployment unit content is read from the original system of the deployment unit while the transport
logs are retrieved from its target systems.
Prerequisites
Only deployment units that are using deployment tool 'SAP Change and Transport System' (CTS+) or
'SAP Transport Management System' (TMS) are considered for evaluation of deployment with this
program.
For the program to work correctly, connectivity from the system running Software Asset
Management to connected deployment target systems needs to be configured first. Configuration is
located in the Implementation Guide (IMG) under heading 'Technology settings'. A two or three-tier
landscape including development, (optional: quality assurance) and production can be configured for
each original system. The IMG can be accessed using transaction code /MBSA/IMG.
Output
Deployment unit content (technical objects) and deployment logs from connected deployment
target systems are used to contextualize bespoke software assets that originated from the
implementation of work requests. Once a deployment unit has reached production its deployment
status is changed to 'In Production'. Once all deployment units that are related to a work request
have reached this status then the overall deployment status of the work request is deemed to be
completed.
5.6
Export of time records for SDLC resources
Purpose
Time record export. Transaction /MBSA/TIMEREC_EXPORT.
Integration
The time record export creates IDocs of message type CATS_INSERT either on the local system (if the
Cross Application Timesheet API function ALE_CATIMESHEETMGR_INSERT exists) or remotely on the
system responding to the RFC destination specified in the selection screen. IDocs created with this
program and exported by means of a file port can be imported to a receiver system.
Use program RSEINB00 in the receiving SAP system to post CATS_INSERT IDocs to create time
records in the Cross Application Timesheet application.
Prerequisites
A partner profile for the selected logical system and message type 'CATS_INSERT' needs to exist.
Create such partner profile with type 'Logical System' using transaction 'WE20' and specify an entry
in the 'outbound parameters' table control for message type 'CATS_INSERT'.
Selection
Specify a period of working days and SDLC resources for selection of time records.
SOFTWARE ASSET MANAGEMENT | Functional documentation
Output
IDocs of type CATS_INSERT. Depending on the ALE port you used in the ALE partner profile the IDoc
data will either be written to file or to an RFC destination.
SOFTWARE ASSET MANAGEMENT | Functional documentation