...

Table of Contents

Introduction

Never worked with Jira before? No problem. Please first read the Jira training Basics page.
In this chapter This chapter is part of is part Jira training for YME Information Systems, below the Jira setup for Information Systems Jira-projects - Yamaha Applications Support Desk (SD) is explained.

...

Information Systems are using the following projects:

...

Yamaha Applications Support Desk

...

(SD

...

Jira Service management - Incident management including Customer Portal

...

Software delivery  - Cognos, TM1, Cubes

...

• Yamaha Applications Support Desk (SD) captures all requests from end-users, who experience difficulties with their day-to-day use of IT applications. These items are validated, then if valid resolved as soon as possible.
• Yamaha IS Projects (YIS) captures all work of scrum teams in the Agile Transformation. These processes are being streamlined to support scrum processes, and make Jira a tool for collaboration more than administration.
• Yamaha Portfolio Board (YPM) collects all ideas for IT initiatives, and validates the business case and expected rewards for implementing such initiatives before assigning work to development teams. It's very much about preparing work.
• Other projects capture work for teams that have not yet joined the Agile Transformation.

In due time, Information Systems teams working in Jira Software projects will be onboarded to the YIS project, so this can become our mutually agreed way of working for Software delivery.

Any team joining will be coached through the (Agile) transition and will be able to provide input on unique ways of working that will need to be integrated. Together we will make it a success.

For now, these Information Systems projects will keep on using their current of way of working. With time and proper preparation, they will migrate into YIS. 

...

J-sox compliance

J-SOX requires Japanese companies to enhance internal control reporting and demonstrate the effectiveness of their internal controls. 

To be J-SOX compliant, Yamaha Motor Europe N.V. will need to demonstrate 4 primary security controls in a yearly audit:

• Secure Access Control Management. 
• Demonstrate a Resilient Cybersecurity Framework. 
• Demonstrate Data Backup Protocols. 
• Change Management.

For Information Systems Division Controls will be integrated in the Jira workflows:

• Secure Access Control Management: new user accounts must be registered and logged in Jira. Users manager need to be informed and included in the ticket.
• Secure Access Control Management: all user authorization changes for Business applications (Ympact, SYS2000, YLS) must be logged in Jira.
  Approval for new authorization(s) is required from IT management (division manager, department manager, team lead).
• Change management: approval (SQL's) by IT management (division manager, department manager, team lead)
• Change management: Role segregation for development and testing. Developer does not test their own developed code.
• Change management: Deployment approval request by IT management (division manager, department manager, team lead).
• Change management: Deployments can only be performed by authorized roles (division manager, department manager, Team lead, Product Owner, Delivery manager).
• Change management: Agile teams must met the organizations set Definition of Done. This is done via a checklist for issues moved to ready for Deployment.

Beforehand it is not known if a database correction or program change is required, to prevent delay in resolving reported requests the users manager is automatically added to the request (Jira issue/ticket).
YME and distributor users are directly synchronized in Jira with Active directory including users manager. The users manager is added via a automation after request creation. 
Active directory is maintained by Servicedesk.

Yamaha Applications Support Desk (SD)

In Yamaha Applications Support Desk all operational support (BAU- Business As Usual) requests are registered that relates to IT Application Issues/errors for existing functionality, data correction and authorization requests.

Users can create a new issue via the Yamaha Motor Europe support portal, via this portal you can go to the YME Information Systems Support Portal to submit a IT request.
Instructions of the portal forms can be found here: YME Information Systems Support Portal Guide

The Image Removed button should NOT be used for creation of a SD issue.

SD Issuetypes

Image RemovedIncident:  Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal will have Issue type Incident.

Image RemovedService Request:  Request for information.  (This issue type is currently not used anymore)

Image RemovedAudit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.

Image RemovedAuthorization request: Elevate user rights request used for Ympact to request YMXXITS1 access to have command line access and to operate in Ympact (Branch specific) Production environment.

Image RemovedRobotJob Change: Robot Job Change request used for Ympact Job scheduling

Image RemovedDeployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.

SD Issues overview

SD Specific Fields

SD mandatory fields have been highlighted in Yellow

Image Removed

• Type: Issue type
• Priority: By default issues are set to Medium
  Image Removed
  
• Solution group *: Drop down single select list to define which department will be working on the issue.
  Image Removed
• Team Yamaha: Label field, multi select, always starting with team# <team name>  used to determine which team will be working on the issue.
  This field has been replaced with Yamaha Team.
  Image Removed
• Yamaha Team*: Mandatory Drop down single select list to define which (agile) team will be working on the issue.
  Image Removed
  
• Application-Module*:  Mandatory Drop down single select list to indicate the involved Application-Module of the reported request (issue).
• Department: Department of the reporter of the issue.
• Company: Company of the reporter of the issue.
• Epic Link: Linked epic issue if a issue is related to a Project.
• SD Classification: Drop down single select list, by default for incoming issues set to Business as Usual (BAU)
  Image Removed
  
• Status: Workflow status
• Resolution: Resolution can be set when a issue will be closed.

...

Image Removed

• Request Type: Customer portal request type
• Customer status: Status visible in the Customer portal. This does not always corresponds directly with the issue workflow status.
• Channel: Portal or e-mail request
• View customer request: link directly to the Customer portal request. This link can be shared if a customer need to access a specific issue.

SD Workflow(s)

Image Removed

Image Removed

If a (bug) fix for a application is required the Bugfix transition can be used to trigger a issue being created in a Development project.

Statuses

Filling user attributes first status for incoming tickets. Background process is running to collect user data and fill other fields automatically. No action should be taken when a ticket has this status.

Image Removed

The ticket will automatically move to next status Awaiting assignment.

Awaiting assignment  Ticket can be assigned, this need to be done via the Allocate button.
For all other statuses the Assignee field can be used directly to re-assign a ticket to yourself or a colleague (instructions below).
Image Removed

Image Removed

Assigned to do Ticket is automatically transferred to this status after using the allocate button. Ticket will appear on to do list of a assignee (Filter number 4 in the dashboard)
Image Removed

In Progress  When starting to work on a ticket use the Start progress button
Image Removed
Image Removed

Reopened
Image Removed

...

Awaiting Supplier used when more information/response from a supplier  is required.
Image Removed

Awaiting Authorization
Image Removed

...

Review Approval  Used by Infra for Issue type Audit to have J-sox change reviewed. How-to create an Infra J-SOX CHANGE issue

Awaiting manager approval   Used by Infra to request IT management approval for J-sox changes.  How-to create an Infra J-SOX CHANGE issue

Transition issue through workflow

Awaiting Customer status

The Awaiting Customer status is used when more information/response from a customer (Reporter or Requested participant) is required in order to move forward with a issue.

Please also read page How to use @mentions to tag a reporter or a commenter directly.

...

)

In Yamaha Applications Support Desk all operational support (BAU- Business As Usual) requests are registered that relates to IT Application Issues/errors for existing functionality, data correction and authorization requests.

SD Issue creation

Users can create a new issue via the Yamaha Motor Europe support portal, via this portal you can go to the YME Information Systems Support Portal to submit a IT request.
Instructions of the portal forms can be found here: YME Information Systems Support Portal Guide

The Image Added button should NOT be used for creation of a SD issue.

Sub-Task creation explanation can be found under Jira training Basics - Subtask creation

After SD issue creation this is being addressed to a Solution group and Yamaha Team for handling the customer request. Instructions can be found in Jira training for YME Information Systems under Issue assignment.

Software Delivery BUG/Incident issue creation via SD 

Anchor
Software Delivery BUG Software Delivery BUG

If a bugfix is required to deliver a functional/technical solution for the original SD issue a linked Bug and for B2C Incident can be created in the Software delivery project.

The SD issue remains open until the fix has been applied and is used to keep the reporter and participants informed or to collect information from the requester.

When a SD issue has status In Progress  select then Bugfix - XXXX via the workflow menu. This will trigger a linked issue creation in a Software delivery project. 

Image Added Triggers a linked YIS Bug for Yamaha team Wolverine

Image Added   Triggers a linked BL Bug for team B2B-Logistics

Image Added  Triggers linked a YIS Bug, team will be copied from original SD issue

For B2C a similar processes is in place but then Create B2C-Incident can be selected via the workflow menu.

Image Added Triggers linked B2C Incident for Yamaha Team B2C-EPAM-BAU

After creation of the linked Software Delivery Project BUG/Incident the SD Issue will be automatically updated to status Image Added

If the deployment issue is closed the original linked SD issue will automatically be updated to status: Image Added. Reporter and Requested participants can be informed that a fix has been applied and the SD issue can be closed with resolution: Done - Development.

SD Deployment Request issue creation

SD Deployment requests are automatically created by a trigger via a YIS Deployment ticket like a Story when as specific transition is used to move an issue from status Ready for Deployment to Done Deployment, these options are only visible for designated Business Train deployment approvers .
This process is currently only used by the Business Train for BA, OMS deployments (YAMS/YMPACT) and Logistics deployments (SYS2000/YLS) and Docker/JAVA deployments.
See for a more detailed explanation: SD Deployment Request 

SD Issuetypes 

Image AddedIncident:  Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal - YME IT Support  or YME E-Commerce support will have Issue type Incident.

Image AddedService Request:  Request for information.  (This issue type cannot be selected via the customer portal and is only visible after manual change )

Image AddedService request with approvals:  Request for application access or AWS workspace, approval option included to request approval from users manager or YME IT management.

Image AddedAudit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.

Image AddedAuthorization request: Elevate user rights request used for Ympact to request YMXXITS1 access to have command line access and to operate in Ympact (Branch specific) Production environment.

Image AddedRobotJob Change: Robot Job Change request used for Ympact Job scheduling

Image AddedDeployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.

Image Added Onboarding: Issue type used for Onboarding new Users and Admin account request

Image Added Task: A Task that needs to be done, currently used for Onboarding procedure

Image Added Sub-task: Smaller task within a larger piece of work, currently used for Onboarding procedure. A sub-task cannot being linked to a Customer portal request type and is only for internal use.

SD Issue types and Customer request type

Anchor
SD Issue types and Customer request type SD Issue types and Customer request type

Request name is the Customer Request type.

SD Issues overview

SD Mandatory Fields

SD mandatory fields have been highlighted in Yellow

Image Added Image Added

Type:  Automatically filled                                                                                                                                                                                     

Priority: By default issues are set to Low

Solution group: Automatically filled based on Yamaha Team

Yamaha Team: Determine responsible  team who will be working on this issue and is required to make it visible on a Board/ Dashboard/ Plan

Application-Module: Mandatory for SD tickets

SD Classification: By default for incoming issues it is set to Business as Usual (BAU)

YME Root Cause: Mandatory for closing an Incident

Resolution: Required when issue is closed

Request type: Automatically filled when created through portal or workflow. When moving an issue select correct Customer Request type. When not filled, issue is not visible/ accessible in the portal

SD Specific Fields

• Type: Issue type
• Priority: By default issues are set to Low
  Image Added
  
• Solution group *: Drop down single select list to define which department will be working on the issue.
  This is automatically set/changed when and issue is created via the customer portal or when a Yamaha team field value  is changed.
  Image Added
  
• Team Yamaha: Label field, multi select, always starting with team# <team name>. This field is only automatically filled for Special processes like SQL Execution, Robot Job Changes.
  Please do no not use it for team assignment but use  field "Yamaha Team" instead. 
  Image Added
• Yamaha Team*: Mandatory Drop down single select list to define which (agile) team will be working on the issue.
  Image Added
  
• Application-Module*:  Mandatory Drop down single select list to indicate the involved Application-Module of the reported request (issue).
• Department: Department of the reporter of the issue.
• Company: Company of the reporter of the issue.
• Epic Link: Linked epic issue if a issue is related to a Project.
• SD Classification: Drop down single select list, by default for incoming issues it is set to Business as Usual (BAU)
  Image Added
  
• Story Points: used to estimate (in a Fibonacci range) the complexity, effort, and risk inherent to the story. Story Points field available for issue type Change request, Task, Story, Bug, Defect, Spike. 
• Business value:  used to estimate (in a Fibonacci range) the value of that piece of development to the YME business.
• Sprint: Multi select field to link the issue to a sprint.
  
• DOR: DOR is the abbreviation forDefinition of Ready. Scrum teams generally use a Definition of Ready to clarify whether a Jira issue (Product Backlog Item, or PBI) can be taken into sprint.
  Within Jira, this process has been summarized in a field, "DoR", which allows tracking what an issue needs to become ready for development.
  Image Added
  The generalized DoR steps are:
  1. Issue created
  2. Requirements defined
  3. Prioritized against other work
  4. Refinement & estimation done
  5. Ready for work
  
  N.B. This is an optional feature. Set the field manually in refinement sessions, in case that makes sense for your team.
• Ticket group(s) Multi select field used to group stories and bugs under a YPM Programme/Project
  Image Added
  
  
• Type of work:  Field used to track type of work activated for Issue type: Incident
  Image Added
  Technical debt: Efforts spent on improving the codebase, enhancing its structure, refactoring, and optimizing it without adding new functionality. 
  New Development: Efforts dedicated to developing new features, functionalities, or significant enhancements. 
  Maintenance: Efforts involved in maintaining the system, which includes activities like routine updates, performance tuning, etcetera. 
  Bug Fixing: Efforts expended to identify and resolve defects or issues reported in the system.
  
  
• Division: (YME Division)
  Multi select field to indicate the YME Division(s) involved/affected. By default empty, value can be entered via the customer portal form or via edit button.
  Field is available for Issue type Incident and Service Request. Based on the value entered in this field stakeholders from the Business Divisions can be contacted by the YME IS teams.
  Image Added
  Image Added
  
  
• YME Root cause*: Mandatory field to be filled when closing an SD Incident, optional for other SD issue types. 
  Field is used for reporting to check where improvements can be made.
  Image Added
  
• Resolution: Resolution can be set when a issue will be closed.

* Combination of Solution group and Yamaha Team determines in which queue/board a issue is visible for non-agile teams.
   For Agile teams only Yamaha team field determines in which board the issue is visible.

Image Added

• Request Type: Customer portal request type, see for overview SD Issue types and Customer request type
• Customer status: Status visible in the Customer portal. This does not always corresponds directly with the issue workflow status.
• Channel: Portal or e-mail request
• View customer request: link directly to the Customer portal request. This link can be shared if a customer need to access a specific issue.

SD Workflow(s)

Basic information how to transition a issue through a Workflow can be found in: Jira Training Basics - Workflow

Image Added

SD Default Workflow

SD Default Workflow V6 and SD Incident workflow V6 are similar, only difference is that for Incident YME Root Cause field is mandatory when closing the issue.
This workflow is used for Issue type Incident, Audit, Deployment request, RobotJob Change and Service Request.

Image Added

Statuses SD Default Workflow

Basic workflow statuses

1. Filling user attributes first status for incoming tickets. Background process is running to collect user data and fill other fields automatically. No action should be taken when a ticket has this status.
The ticket will automatically move to next status Awaiting assignment.

2. Awaiting assignment  Ticket can be assigned to person, this need to be done via the Allocate button. Instructions for team assignment can be found in Jira training for YME Information Systems under Issue assignment.
For all other statuses the Assignee field can be used directly to re-assign a ticket to yourself or a colleague (instructions below).
Image Added

3. Assigned to do Ticket is automatically transferred to this status after using the allocate button. Ticket will appear on to do list of a assignee (Filter number 4 in the dashboard)

4. In Progress  When starting to work on a ticket use the Start progress button
Image Added

4. Closed The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.


5. Reopened Re-open issue.  Issue need to be re-assigned to a assignee and will be transitioned to status In Progress.

Other statuses

• Awaiting Customer  Used when more information/response from a customer (Reporter or Requested participant) is required in order to move forward with a issue.
  Detailed information for this status can be found further below under: Awaiting Customer status
  
  
• Awaiting Supplier Used when more information/response from a supplier is required.
  Detailed information for this status can be found further below under: Awaiting supplier status
  
  
• Awaiting Authorization Used to request B2B manager approval for Ympact user/menu/program and Jira/Confluence YPM authorization.
   SD Classification need to be manually set to: User authorization related.  After approval/decline the issue will automatically be changed back to In Progress. Manager should leave a comment if approved or not.

Workflow statuses development required 

• Pending linked ticket execution Temporary status Triggered when a linked ticket is created for Elevated user rights or RobotJob Change request
  Instructions for these procedures can be found on the following pages:
  How-to request Elevated User rights - SQL cluster access 
  How-to request Elevated User rights - YMPACT YMXXITS1 access 
  How-to request a Robotjob change
  
  
  
• Awaiting Development Status set when a linked Sofware Delivery ticket is created, see explanation under Software Delivery BUG/Incident issue creation via SD
  
  
• Awaiting Execution  Used for SQL Process for SQL execution and deployments. 
  
  
• Deployment validation Used by Enable train for AS400 morning check validations.
  
  
• Ready to Close Triggered when a linked Software Delivery issue is closed. see explanation under Software Delivery BUG/Incident issue creation via SD
  
  
• Review Approval  Used by Enable Train for Issue type Audit to have J-sox change reviewed. How-to create an Infra J-SOX CHANGE issue 
  This process has been replaced by YIS Enable Story creation in Project YIS.
  
  
• Awaiting manager approval Used by Infra to request IT management approval for J-sox changes.  How-to create an Infra J-SOX CHANGE issue

Statuses SD Default Workflow detailed explanation

Awaiting Customer status 

Anchor
Awaiting Customer status Awaiting Customer status

The Awaiting Customer status is used when more information/response from a customer (Reporter or Requested participant) is required in order to move forward with a issue.

Please also read page Jira training Basics > Mentions (tagging) to tag a reporter or a commenter directly.

1. Awaiting Customer status can be triggered via the Respond to customer button .
   Image Added
   When selecting this option a pop up frame will be opened:
   Image Added
   
   
2. Check Comment selection (see marked in red in the above screenshot).
   Default for comment is set to Internal comment. The Internal comment option can be used for only triggering a status update to Awaiting customer. 
   Use comment: Respond to customer if your message should be shared with the the reporter and requested participants.  
   1. Optional: Add comment to the comment section.  
      
3.  Select the Respond to customer button.
4. After using the Respond to customer button is pressed the comment will be added to the ticket and status will be changed to Awaiting customer. Description area is optional.
   Image Added
   
5. Response from customer received:
   
   1. Via issue: Status will automatically changed back to status In Progress.
   2. Manually: Select status In Progress.
      Image Added
      

Awaiting supplier status

Anchor
Awaiting supplier status Awaiting supplier status

The Awaiting Supplier status is used when a supplier has been contacted either via the issue directly or via other communication canals to purchase/request assistance for products/services.

Please also read page Jira training Basics > Mentions (tagging) to tag a reporter or a commenter directly.

1. Awaiting Supplier status can be triggered via the Awaiting Supplier  button .
   Image Added
   When selecting this option a pop up frame will be opened:
   Image Added
   
   
2. Check Comment selection (see marked in red in the above screenshot).
   Default for comment is set to Internal comment. The Internal comment option can be used for only triggering a status update to Awaiting Supplier 
   Use comment: Respond to customer if your message should be shared with the the reporter and requested participants.  
   1. Optional: Add comment to the comment section.  
      
3.  Select the Awaiting supplier response button.
4. After reply from the Awaiting supplier response button is pressed the comment will be added to the ticket and status will be changed to Awaiting Supplier. Description area is optional.
   Image Added
   
5. Response from supplier received:
   
   1. Via issue: Status will automatically changed back to status In Progress.
   2. Manually: Select status In Progress.
      Image Added

SD Deployment Request 

Anchor
SD_Deployment_Request SD_Deployment_Request

SD Deployment requests are automatically created by a trigger via a YIS Deployment ticket like a Story when as specific transition is used to move an issue from status Ready for Deployment to Done Deployment, these options are only visible for designated Business Train deployment approvers .
This process is currently only used by the Business Train for BA, OMS deployments (YAMS/YMPACT) and Logistics deployments (SYS2000/YLS) and Docker/JAVA deployments.

See under Generic Development Workflow via which workflow transition the SD Deployment is triggered.

When an Image Addedis created  a  Jira automation will be triggered to set the fields:  Issue Type, Customer request type, Application-Module, Yamaha team and SD Classification and Request participants (from original trigger issue and add stakeholders like B2B deployment Distribution list/ B2C deployment Distribution list) . Also the issue is automatically transitioned through the workflow from status Awaiting assignment > Assigned (To Do) > In Progress > Awaiting Deployment Approval .
An Business Train deployment approver can approve the issue by selecting the appropriate option:

• Docker deployment approval → Will trigger automatically a docker deployment and set issue to status Ready to Close
• Non-Docker deployment approval → Will trigger automatically a Jenkins deployment and set issue to status Ready to Close
• OMS deployment approval→ Will set status to Awaiting Execution, Yamaha Team iSparkle-iSeries will execute the deployment request
• Logistics deployment approval→ Will set status to Awaiting Execution, Yamaha Team same as YIS deployment issue will execute the deployment request

After SD Deployment request is set to Ready to Close or Awaiting Execution the team responsible for the deployment can execute the deployment and can afterwards use transition 'Resolve'  for setting status to Closed
When using this transition select in the pop-up screen resolution Done - Deployment. When closed automatically all in the request participant field are informed.
Image Added  
Image Added

SD: Software Authorization Workflow

The Software Authorization Workflow is triggered for Elevated User right requests: 
The process is explained on the following pages:

• How-to request Elevated User rights - SQL cluster access
• How-to request Elevated User rights - YMPACT YMXXITS1 access

Image Added

SD: Access Request Onboarding Workflow

Training material for this Onboarding Workflow can be found on the following page: Jira training for (SD) - Onboarding.
This workflow is applied for all new onboarding requests and Admin Account request.

Image Added

SD: Simple 3 step workflow

Workflow used for Issue Type Task and Sub-Task.
Task creation is only used by automatic procedures for Onboarding: Jira training for (SD) - Onboarding.
Sub-Task creation explanation can be found under Jira training Basics - Subtask creation

Image Added

Statuses SD: Simple 3 Step workflow

• To do: work has not started, issue can be assigned (work can always move back to this status);
• In progress: Issue is in Progress (work can always move back to this status);
• Done: the work is completed, resolution is automatically set to "Done";
• Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete. Resolution is automatically set to "Canceled" a comment Screen will pop up to include information why the issue has been canceled (can be selected from any status). 

If a Issue is already closed and will be moved back to status "To Do" or "In Progress" the resolution will be cleared.

SD: Service Request with Approvals Workflow 

Workflow used for Application access request and for Onboarding to request a new AWS workspace.
Instructions how to create an Application Access request can be found on the following page: Creating an Application Access request.
Instructions for AWS workspace can be found under: Jira training for (SD) - Onboarding.
 

Image Added

• Filling user attributes first status for incoming tickets. Background process is running to collect user data and fill other fields automatically. No action should be taken when a ticket has this status.
  The ticket will automatically move to next status Awaiting assignment.
  

• Awaiting assignment  Ticket can be assigned to person, this need to be done via the Allocate button. Instructions for team assignment can be found in Jira training for YME Information Systems under Issue assignment.
  For all other statuses the Assignee field can be used directly to re-assign a ticket to yourself or a colleague (instructions below).
  
  

• In Progress: When starting to work on a ticket use the Start progress button
  
  
• Waiting for Customer  Used when more information/response from a customer (Reporter or Requested participant) is required in order to move forward with a issue.
  Detailed information for this status can be found further below under: 
  
  
• Waiting for Supplier Used when more information/response from a supplier is required.
  Detailed information for this status can be found further below under: 
  
  
• Waiting for Approval  Used for requesting approval (can be selected from any status);
  Enter the approvers in the screen that will pop up when using this transition. Multiple approvers can be selected but only one is mandatory to approve/decline the request.
  Approvers can approve or decline via the e-mail notification, in the customer portal or as an agent in the ticket.  Approved or Declined ticket is set to status In Progress. 
  
  

• Validation: Check with Stakeholder/customer/requester if request is fulfilled correctly had user has access.
  
  

• Closed The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.
  
  

• Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete. Resolution is automatically set to "Canceled" a comment Screen will pop up to include information why the issue has been canceled (can be selected from any status). 

...

1. Optional: Add comment to the comment section.  
   

...

Change Advisory Board (CAB)

Change advisory Board (CAB) workflow is used for approval of fixes and creation of a functional/technical conceptional design document.

This project will be phased out as Bugfix issues can be created in the software delivery projects directly via the SD Workflow.
Changes, improvements should be requested via creation of a Project  by a YME Portfolio Board Manager via the Yamaha Applications Support Desk (SD).

CAB Issue types

One of the two following conditions must be met to create a CAB issue.

1. Image RemovedBug: Bugfix to deliver a functional/technical solution for the original SD issue. SD issue remains open until the fix has been applied.
2. Image RemovedStory: Non-bugfix for internal improvement, prevent (recurring) issues for the future. SD issue can be closed, user will be informed that current issue is fixed but there will still be worked on in the background to prevent from happening again or improvements.

...