Table of Contents

Introduction

Never worked with Jira before? No problem. Please first read the Jira training Basics page.
In this chapter below the Jira setup for Information Systems Jira-projects is explained.

Jira projects

Information Systems are using the following projects:

In a future state for 2023 only the Jira Projects in black text will remain for Information Systems.

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

The Change Advisory Board will be phased out completely as it will be covered by the Yamaha Portfolio Board and  Software project(s).

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 button should NOT be used for creation of a SD issue.

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

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.

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>  used to determine which team will be working on the issue.
  This field has been replaced with Yamaha Team.
  
• 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 set to Business as Usual (BAU)
  
  
• Status: Workflow status
• 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
• 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)

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.

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

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)

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

Reopened

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

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

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

Awaiting Authorization

Onboarding 
Pending linked ticket execution



Change Advisoryboard (CAB)

Awaiting Development
Awaiting Execution
Deployment validation
Ready to Close

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.

1. Awaiting Customer status can be triggered via the Workflow- 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..
   

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 Jira training for Information Systems.

CAB Issue types

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

1. Bug: Bugfix to deliver a functional/technical solution for the original SD issue. SD issue remains open until the fix has been applied.
2. Story: 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.

Under the SD issue the reporter and requested participants can be informed about the change applied/ to be applied but is also used to collect information from the requester.

CAB Workflow

Function design (FD) and Technical design (TD) documents can be found in Confluence under space  Functional Conceptional Designs.
At the main page instructions can be found how a Functional/Technical Conceptional Design document can be created (via standardized template).

Yamaha Portfolio Board (YPM)

Before work is ready for development, any idea for software development is first vetted by the portfolio management, to understand whether the proposal is of strategic value to YME.
Once it is agreed that the idea should be implemented, a selection of what to do first is made based on business case, priority, and urgency. This way we ensure that time is spent on the most valuable topics.
In Jira these ideas are created within Jira-Project Yamaha Portfolio Board (YPM)

Jira Training documentation can be found under: Jira training for Yamaha Portfolio Planning (YPM).

Software delivery projects

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. 

Yamaha IS Projects (YIS) 

Project YIS is set up as a single space to allow Information Systems and Business to align on an Agile way of working, as part of the Agile Transformation.

Together we strive to arrive at a Jira configuration that is usable for all teams, supporting all YME Information Systems processes in a comprehensive, simplified manner.

Documentation can be found on the following page: Jira training for Yamaha IS Projects (YIS) 

B2C-Apps (B2C)

 Jira SD-> B2C-Incident ticket creation

As discussed with Patrick a new functionality in Jira SD project has been created for B2C.

If a SD ticket is in progress a linked B2C-Incident ticket can now be created via Workflow-Create B2C-Incident button.

This means that CAB can now be skipped for Incidents/Bugs.

This option is only available for Consumer Applications team, not for Epam.

With this option many fields will be copied, like previously was done for CAB.
See below fields that will be copied/set:

Unfortunately it is not possible to copy all comments, but last comment and the comment entered in the comment screen that pops up if this transition is used will both be copied to the new B2C incident.

Assign a Issue to a different team

If action from a different team/department is required or of it has been wrongly addressed some settings need to be changed to address it to the correct team/department.
View of issues in a queue/dashboard is for all departments depending on 2 settings

1. Solution group
2. Yamaha Team or Yamaha Team(s)

Multi select field Yamaha Team(s) field is used in YPM project for issue type: Programme, Project, Enhancement and Epic

Single select field Yamaha Team is used for all other Jira Projects and Issue types used by Information Systems Division.

Overview Solution group and Yamaha Team / Yamaha Team(s)

Incoming ticket handling for Yamaha Application Support Desk (SD-)

Check following field selection of the correct one is selected, if not please adjust it or add:

1. Adjust Solution group if wrongly selected
2. Adjust or add correct Yamaha Team
3. Adjust if not the correct SD Classification is selected
4. Adjust the Application-Module if wrongly selected
5. Check if request includes are requires information, if not request customer for more information. 
6. Issue can be allocated to a person when starting on the request/taking care of the request.
   When issue has been assigned before then only re-assign the issue.
   Re-opened issues also need to be re-assigned via the Re-assigned-comment button. 

Moving a issue to the correct department/team

For moving a issue/ticket to a different department 

1. Select the correct Solution group
   1.  Select the Yamaha Team  corresponding to the Solution group in the second column of above overview.
   2. Select the a additional Yamaha Team(s) corresponding to the Solution group in the second column of above overview.
2. Remove yourself as assignee

The persons who are handling the queues from the department/team will take further care of the ticket and move them to the second line if needed.

Request a specific action from another department/team by moving the issue

If a issue is in progress but action is needed from a different department a issue can (temporary) be moved to a different department. 

1. Select the correct Solution group
   1. Add Yamaha Team corresponding to the Solution group in the second column of above overview form who action is required.
   2. Select the a additional Yamaha Team(s) corresponding to the Solution group in the second column of above overview.
2. Remove yourself as assignee and add yourself as requested participant or Watcher. 
   In case of updates you keep tracking of the issue and will be notified if anything is changed.
3. Add a comment to the issue with your request toward the Yamaha Team and request to reassign the ticket back to your Solution group/department.

The persons who are handling the queues from the department/team will take further care of the ticket and move them to the second line if needed and/or assign it to the correct person.

Add-ons used by Information Systems

• Agile Tools & Filters for Jira Software
• Backbone Issue Sync for Jira  Synchronization between PCW (US) Jira and YME Jira for Yamaha Next Stage (YNS) Project. This Jira project is used for the integration of SAP and Informatica. 
• Big Picture Roadmap and resource planning for Portfolio Board.
• Checklist for example used for Custom field DOD in Software projects.
• Doublecheck for Jira Service Management 
• Eazy BI
• Jenkins Integration for Jira Server and Data Center
• ProForma: Forms for Jira
• Status Time Free
• Timesheet Reports and Gadgets
  This addon is used by Information Systems, Business Applications department to log hours spend on Projects, issues. When hours are logged there is more insight in the velocity of teams and specifically projects.
  Secondly we expect to see the exact number of hours that are contract wise in place per person per month. In order to get a clear overview, we also expect hours to be registered to the correct issues.
  As you all will have time which can not be related to a issue/project directly, e.g. a meeting, you can add these to running tickets (as long as they are booked in the correct month it is correct).
  During the hour logging you can indicate in the comment it concerned a meeting or so.
  Specifically for consultants it is important the total hours in Jira correspond to the hours declared, these will be compared to the sign off hour sheet.
  We do not consider time registration limited to consultants only. It is meant for the whole B2B team.
  
• Version manager
• Xray Test Management tool (app)