Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Request name is the Customer Request type.

YME IT Support

Image Added

Login and Accounts

Image AddedImage Removed

YME E-Commerce Support

Hidden
Issues  with these (customer) request types are visible for customers but cannot be selected in the Customer support portal forms.
These Customer request types are set by automation rules or are triggered via a Servicedesk Workflow action.

Image Removed

Image Removed


Image RemovedImage Added




SD Issues overview

...

SD mandatory fields have been highlighted in Yellow

Image AddedImage Removed

  • 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.
    This is automatically set/changed when and issue is created via the customer portal or when a Yamaha team field value  is changed.

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


  • Type of work:  Field used to track type of work activated for Issue type: Incident

    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.



  • 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: Resolution can be set when a issue will be closed.

...

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

Image RemovedImage 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.

Image Added

Statuses SD Default Workflow

Basic workflow statuses

1

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.

...

...

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

Image Removed

This workflow is applied for all new onboarding requests and Admin Account request.

Image Added


SDSD: 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

...

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 

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 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: Awaiting Customer status

  • Waiting for 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

  • Waiting for Approval  Used for requesting approval (work can always move back to this 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).