Table of Contents

Introduction

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

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.

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 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 Information Systems under Issue assignment.

Software Delivery BUG/Incident issue creation via SD 

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. 

 Triggers a linked YIS Bug for Yamaha team Wolverine

   Triggers a linked BL Bug for team B2B-Logistics

  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.

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

If the deployment issue is closed the original linked SD issue will automatically be updated to status: . 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 Issuetypes 

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

Service Request:  Request for information.  (This issue type is currently not used, only visible after manual change )

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

Authorization 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.

RobotJob Change: Robot Job Change request used for Ympact Job scheduling

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

 Onboarding: Issue type used for Onboarding new Users

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

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

Request name is the Customer Request type.

SD Issues overview

SD Specific Fields

SD mandatory fields have been highlighted in Yellow

• Type: Issue type
• Priority: By default issues are set to Medium
  
  
• Solution group *: Drop down single select list to define which department will be working on the issue.
  
  
• 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 replacement field "Yamaha Team" instead. 
  
• Yamaha Team*: Mandatory Drop down single select list to define which (agile) team will be working on the issue.
  
  
• 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)
  
  
• 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.
  
• Ticket group(s)  Multi select field used to group stories and bugs under a YPM Programme/Project
  
  
  
• 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.

• 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

SD Default Workflow

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 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).

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

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.
  
  
• Onboarding Used by Infra-SD to trigger pending linked tickets for Facility to prepare a batch and keys for new employees , this will be replaced by a new procedure: Jira training for (SD) - Onboarding

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
  
  
• Change Advisoryboard (CAB)  Triggers a CAB issue creation for approval request of fixes and creation of a functional/technical conceptional design document , this will be phased out completely as it will be covered by the Yamaha Portfolio Board and Software project(s).
  
  
• 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. 
  
  
• Deployment validation
  
  
• 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 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

Statuses SD Default Workflow detailed explanation

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.

1. Awaiting Customer status can be triggered via the  Respond to customer button .
   
   When selecting this option a pop up frame will be opened:
   
   
   
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.
   
   
5. Response from customer received:
   
   1. Via issue: Status will automatically changed back to status In Progress.
   2. Manually: Select status In Progress.
      
      

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 How to use @mentions to tag a reporter or a commenter directly.

1. Awaiting Supplier status can be triggered via the  Awaiting Supplier  button .
   
   When selecting this option a pop up frame will be opened:
   
   
   
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.
   
   
5. Response from supplier received:
   
   1. Via issue: Status will automatically changed back to status In Progress.
   2. Manually: Select status In Progress.
      

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

SD: Access Request Onboarding Workflow

Training material for this Onboarding Workflow can be found on the following page: Jira training for (SD) - Onboarding.

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

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.