2019 Fall Release

Change and Release ManagementPermanent link for this heading

The change and release management enables you to create and manage change processes. This allows carrying out adaptations to an IT infrastructure in a controlled, efficient and risk-minimized manner.

In addition, problem records can be managed and processed using a problem management process.

Note: Available in the Fabasoft Cloud Superior. The change and release management may have to be enabled by an organization administrator (Organization > Licenses > Editions and Apps > Change and Release Management with assignment Configured (Inactive) > “Enable” action).

DashboardPermanent link for this heading

The change and release management dashboard provides your point of access to the change and release management.

When you are added to at least one RFC or problem record shelf, a dashboard is automatically created and stored on “Home”. If you are removed again from all shelves, the dashboard is also removed.

The change and release management dashboard is divided into the following areas for users:

  • My Requests for Change
    Shows the RFCs that you created.
  • My Problem Records
    Shows the problem records that you created.
  • Track List
    Shows the objects that you have added via the “Add to
    Tracklist” context menu command.
  • Standard Change
    Shows the requests for change that have been defined as standard changes (only visible if at least one standard change exists). This allows you to efficiently request RFCs for routine tasks (“Request Standard Change” context menu command).

If you are at least a processor in a shelf, the following additional areas are available:

  • Release Packages
    Shows the release packages of the RFC shelves in which you are at least “Processor”.
  • All Requests for Change
    Shows the RFCs that you created and the RFCs of the RFC shelves in which you are at least “Processor”.
  • All Problem Records
    Shows the problem records that you created and the problem records of the problem record shelves in which you are at least “Processor”.
  • RFC Shelves
    Shows all RFC shelves. You can only view RFCs in the shelves in which you are at least “Processor”.
  • Problem Record Shelves
    Shows all problem record shelves. You can only view problem records in the shelves in which you are at least “Processor”.
  • CMDB and IT Asset Shelves
    Shows all CMDB shelves (Configuration Management Database) and IT asset shelves. You can only view the items in the shelves in which you are authorized.

You can perform the following actions:

  • Create Request for Change
    With the “Generate Request for Change” action you can create an RFC for a change to be made.
  • Create Problem Record
    With the “Create Problem Record” action you can create a problem record that documents the details of a problem.
  • Create Release Package
    With the “Create Release Package” action you can create a release package. Release packages can be referenced in RFCs and thus define the execution time.
  • Switch to Configuration
    With the “Switch to Configuration” action you can view the configuration that is associated with the dashboard.
  • Settings
    With the “Settings” action you can define common properties of the dashboard like the logo or notification setting.

ConfigurationPermanent link for this heading

In the change and release management configuration, you as app administrator can manage the shelves, artifacts and general settings.

Areas

The configuration is divided into the following areas:

  • RFC Shelves
    Shows the available RFC shelves.
  • Problem Record Shelves
    Shows the available problem record shelves.
  • CMDB Shelves
    Shows the available CMDB shelves.
  • Forms and Categories
    Shows the available forms and categories.
    Note: To be able to store forms and categories from a different context, you must adjust the Restrict Shortcuts Within Teamroom field in the configuration settings accordingly.
  • Processes
    Shows the available user-defined processes.
  • Templates
    In the create dialog (e.g. “New” context menu command in a Teamroom) the templates are displayed according to the grouping by the template categories.
  • Text Modules
    The defined text modules can be inserted into Word documents.

Actions

You can perform the following actions:

  • Create RFC Shelf
    With the “Create RFC Shelf” action you can define a new RFC shelf.
  • Create Problem Record Shelf
    With the “Create Problem Record Shelf” action you can define a new problem record shelf.
  • Create CMDB Shelf
    With the “Create CMDB Shelf” action you can define a new CMDB shelf.
  • Settings
    With the “Settings” action you can define further configuration settings.

Settings

“General Settings” tab

  • Default Category for Requests for Change
    Newly created RFCs are assigned the specified category if not defined otherwise in the RFC shelf.
  • Default Category for Release Packages
    Newly created release packages are assigned the specified category unless otherwise defined in the RFC shelf.
  • Default Category for Problem Records
    Newly created problem records are assigned the specified category if not defined otherwise in the problem record shelf.

RFC ShelvesPermanent link for this heading

RFC shelves are used to manage RFCs and to define access rights (“Team” action).

Settings

“Common Settings” tab

  • Default Category for Requests for Change
    Newly created RFCs are assigned the specified category.
  • Default Category for Release Packages
    Newly created release packages are assigned the specified category.
  • Close Shelf
    No new RFCs can be created in a closed shelf.

Access Rights

  • Full Control
    Users with full control can authorize users, manage RFCs and release packages, and edit shelf settings. They can also be selected as change or release managers.
  • Processor
    Processors can manage RFCs and release packages and can be selected as change or release managers.
  • Users
    Users can create RFCs and access the RFCs they created themselves.

CMDB ShelvesPermanent link for this heading

CMDB shelves (Configuration Management Database) are used to manage artifacts and to define access rights (“Team” action). The artifacts can be assigned to RFCs.

The artifacts can be created in the following folders: Servers, Virtual Machines/Servers, IT Services, Application Services, Network Components, Locations, Cluster and Checks.

Access rights

CMDB shelves offer the standard roles “Full Control”, “Change Access” and “Read Access”.

IT Asset ShelvesPermanent link for this heading

IT asset shelves are used to manage the inventory passed to employees and to define access rights (“Team” action). Assets can be handed over to or handed back by employees through a workflow.

The assets can be created in the following folders: Computers, Monitors, Mobile Devices, SIM Cards, Landline Telephones, Printers, Scanners, Tokens, Keys, Access Cards, Docking Stations, Cars, Others and Workspace.

Access rights

IT asset shelves offer the standard roles “Full Control”, “Change Access” and “Read Access”.

Problem Record ShelvesPermanent link for this heading

Problem record shelves are used to manage problem records and define the access rights (“Team” action).

Settings

“Common Settings” tab

  • Default Category for Problem Records
    Newly created problem records are assigned the specified category.
  • Close Shelf
    No new problem records can be created in a closed shelf.

Access rights

  • Full Control
    Users with full control can authorize users, manage problem records and edit shelf settings.
  • Processors
    Processors can manage problem records.
  • Users
    Users can create problem records and access the problem records they created themselves.

Creating a Request for ChangePermanent link for this heading

Requests for change (RFCs) are used to request a change. A request for change has the following fields (not all fields are available directly when they are created):

  • Name
    Defines the name of the RFC.
  • Initiator
    Defines the user who requests the RFC.
  • RFC Shelf
    The RFC is assigned to the specified RFC shelf.
  • Priority
    Defines the priority of the RFC.
  • Earliest Date
    Defines the earliest point in time at which the RFC can be implemented productively.
  • Latest Date
    Defines the latest point in time until which the RFC must be implemented productively.
  • Ranking
    Can be used to rank the RFCs in the list view.
  • Hotfix
    Defines whether it is a hotfix.
  • Description
    Defines the steps to be implemented.
  • Reason
    Defines the reason for the RFC.
  • Expected Result
    Defines the result after the implementation.
  • Risks
    Describes the risks.
  • Affected Systems
    Defines the systems affected by the implementation.
  • Additional Information
    Additional information can be added as objects.
  • Change Manager of the Affected Systems
    The defined user receives the workflow activities intended for the change manager.
  • Responsible for Accomplishment
    The defined user receives the workflow activities intended for the release manager.

Note:

  • As a processor, you can use the “Set as Standard Change” context menu command to define an RFC as a template for routine tasks. The request is made using the “Request Standard Change” context menu command.
  • The “Create Request for Change” action is also available for tickets, stories and defects.

Change ProcessPermanent link for this heading

A typical change process can be performed as follows:

  1. A user creates a request for change.
  2. The user executes the “Request Change” action.
  3. The responsible change manager receives the “Approve Request for Change” activity and executes the “Approve Change” step.
  4. The responsible change manager receives the "Release Planning" activity and executes the "Approve for Tests" step. A team responsible for tests must be selected.
  5. All members of the selected team receive the “Prepare Release” activity. The members can perform the “Start tests”, “Further Tests Required” and “Tests Completed” steps.
  6. After the tests have been completed, the responsible release manager receives the “Approve Release” activity and performs the “Approve Release for Implementation” step.
  7. After the release preparation has been approved, the responsible release manager receives the “Scheduling” activity and executes the “Release for Implementation” step.
  8. After the process planning has been released, the team responsible for the implementation receives the “Deployment” activity and executes the “Implementation Completed” step. The implementation can only be completed if all RFCs have the status “Implemented” or “Implementation Failed”.
  9. After the implementation has been completed, the responsible reviewer receives the “Review Release Package” activity and executes the “Close Release” step.
  10. If the release manager was not the person who performed the review, he receives the “Close Request for Change” activity and performs the “Close” step.
  11. Finally, the RFC requester, change manager and release manager receive the “Request for Change Closed” activity if they have not already received this information via another activity.

Managing IT AssetsPermanent link for this heading

The inventory handed over to employees can be managed using assets. The following use cases can be performed:

Creating and Editing IT Assets

In IT asset shelves, user with change rights can create and edit assets.

Using Fields in Word Documents

In Word documents that are stored in the Documents field of an asset, especially the following fields can be inserted of the asset: Owner, Location, Inventory Number, Manufacturer, Model, and Serial Number.

Hand Over Assets

The “Hand Over Asset” action allows users with change rights and asset owners to specify the new asset owner. The new asset owner receives the “Take Over Asset” activity in the worklist. The new asset owner can either confirm or reject the take-over.

Note:

  • If the take-over is confirmed, the status of the asset is changed to “Active” and the user in the Hand Over Asset to field is moved to the Asset Owner field.
  • If the take-over is rejected, the user is removed from the Hand Over Asset to field and the process initiator receives the “Asset Take-Over Denied” activity.

Hand Back Assets

The “Hand Back Asset” action allows users with change rights and asset owners to hand back an asset. The new asset owner receives the “Take Back Asset” activity in the worklist. The new asset owner can either confirm or reject the take-back.

Note:

  • If the take-back is confirmed, the status of the asset is changed to “In Stock” and the user in the Hand Over Asset to field is moved to the Asset Owner field.
  • If the take-back is rejected, the user is removed from the Hand Over Asset to field and the process initiator receives the “Asset Take-Back Denied” activity.

Overview of Assets

In the “Workspace” folder, users with change rights can create a search folder. Specify “IT Asset” as selection in the search pattern. If you add the Hand Over Asset to, Asset Owner and State columns, you get an overview of all assets.

Creating a Problem RecordPermanent link for this heading

Problem records are used to document the details of a problem. A problem record provides the following fields (not all fields are available when they are created):

  • Name
    Defines the name of the problem record.
  • Problem Record Shelf
    The problem record is assigned to the specified problem record shelf.
  • Priority
    Defines the priority of the problem record (low to immediate).
  • Severity
    Defines the severity of the problem (low to high).
  • State
    Shows the state of the problem record.
  • Problem Manager
    The defined user receives the workflow activities intended for the problem manager.
  • Description of Symptoms
    Defines the symptoms of the problem.
  • Solution
    Defines a possible solution to the problem.
  • Affected Systems
    Defines the systems affected by the problem.
  • Known Error Record
    Problem records that already describe the problem as known can be added as objects.
  • Related Incidents
    Incidents can be added as objects.
  • References
    Additional information can be added as objects.

Note: The “Create Problem Record” action is also available for tickets.

Problem Management ProcessPermanent link for this heading

A typical problem management process can be performed as follows:

  1. The problem management process can be started via the “Start Problem Management” action in the problem record.
  2. The responsible problem manager receives the “Classify Problem Record” activity and executes the “Assign” step.
    Note: Another problem manager can be selected with the “Redirect” step. With the “Close” step the problem record can be closed.
  3. The person defined in the “Assign” step receives the “Edit Problem Record” activity and executes the “Complete with Workaround” or “Complete with Solution” step and enters a solution proposal.
  4. The responsible problem manager receives the “Review Problem Record” activity and executes the "Close" step.
    Note: With the “Assign” step a responsible person can be selected again if necessary.