Page History

...

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 

Incident:  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.

...

SD Issues overview

SD

...

Mandatory Fields

SD mandatory fields have been highlighted in Yellow

Image Added Image AddedImage Removed

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

...

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

...