SERVICE REQUESTS TICKETS AND CHANGE REQUESTS ........................................................1 GENERAL OVERVIEW .......................................................................................................................................

.1 What is the difference between Change request and Tickets?................................................................2 When to open a Change Request?..........................................................................................................2 When to open Ticket?..............................................................................................................................2 EVERYTHING ABOUT TICKETS.............................................................................................................................2 What is a ticket and how it works?.........................................................................................................2 Who will work on the ticket I opened?....................................................................................................2
DC_Network_Tickets.......................................................................................................................................3 DC_OracleDBA_Tickets..................................................................................................................................3 DC_System_Tickets.........................................................................................................................................3

When will somebody work on my ticket or close my ticket?...................................................................4 How to open a ticket if I do not have an account, or my account is disabled?......................................4 How to open a ticket if I have a portal account......................................................................................5 How to check the status of my ticket?.....................................................................................................7 How to reply/follow up a ticket?.............................................................................................................9 Who is working on my ticket? Ticket statuses ..................................................................................11 EVERYTHING ABOUT CHANGE REQUESTS (CRS)................................................................................................12 Why do we need to use change management?......................................................................................12 Change management basic rules..........................................................................................................12 What is the change request and how it works?.....................................................................................12 Change request statuses.......................................................................................................................14
More Info........................................................................................................................................................14 Test scheduling...............................................................................................................................................14 Testing............................................................................................................................................................14 Approval.........................................................................................................................................................14 Implementation Scheduling............................................................................................................................14 Implementation...............................................................................................................................................14 Closed / Rolled-back.......................................................................................................................................14

Change request Change Type Workflow scenarios...........................................................................15

Complete workflow CR..................................................................................................................................15 Complete self-service workflow CR...............................................................................................................15 Complete workflow CR without testing..........................................................................................................16 Complete self-service workflow CR without testing.......................................................................................16 Self approved CR............................................................................................................................................17

Teams / persons involved with Change requests..................................................................................17

Requestor........................................................................................................................................................17 Coordinator.....................................................................................................................................................17 Tester..............................................................................................................................................................17 Approval.........................................................................................................................................................17 Implementation team......................................................................................................................................18 Queue-Admins................................................................................................................................................18

Who can open a Change request?........................................................................................................18 How to open a Change request?...........................................................................................................18 How to check the status of my Change request?..................................................................................20 How to reply/follow up a Change request?..........................................................................................22 Who is working on my Change request? .............................................................................................22

Service requests Tickets and Change Requests

General overview
Under this section you can create Change Requests (CR) or Tickets. Both CRs and Tickets share common attributes such as customer, subject, description, etc. A Ticket can

be converted to Change Request and vice versa. Change Requests are basically extended tickets with extended attributes like approval, change coordinator, etc

What is the difference between Change request and Tickets?

Ticket is a simple service request. Opened ticket goes to a queue and certain teams (queue admins) can pick up that ticket, work on a ticket and close the ticket. Change requests are more complex. Change requests have much more statuses, and multiple teams (testers, approvals, coordinators, etc) might be involved during the change request testing-approving-implementation process. Note: CRs are displayed with red, while tickets are displayed with blue colour on the portal

When to open a Change Request?

Open a CR when you need to get somebody to do changes on PRODUCTION systems for customers/servers hosted in the Micros-Fidelio Frankfurt Datacenter, or you need to do changes yourself.

When to open Ticket?

Open a ticket for troubleshooting requests, reporting issues about test and production systems for customers/servers hosted in the Micros-Fidelio Frankfurt Datacenter. Use tickets also for requesting changes on test/training systems.

Everything about tickets

What is a ticket and how it works?
Ticket is basically a task request. You (as a requestor) can open tickets/cases on the datacenter portal. In a ticket you can request a specific task (like a server reboot, checking configuration, etc) or you can report issues (server is not reachable, database gives a specific error message) Every ticket has a unique ID, which is the ticket number. If you successfully open a ticket, the portal will show you the generated ticket ID. With this ID you can locate your ticket later, you can verify the status online, and you can use this for escalations.

Who will work on the ticket I opened?

It depends on which queue you selected when you opened the ticket. When you open a ticket, in the drop down list you can select the queue.

DC_Network_Tickets Team: Micros Fidelio Frankfurt Datacenter Network Team Responsibility: o Network infrastructure (switches, firewalls, routers, load balancers) o Customer routers installed in Frankfurt datacenters o Rarely customer routers onsite (only of specific customers) Examples: o Start continuous ping monitoring to specific sites o Check opened ports on the firewalls. o Provide network statistics, check network load. o Open ports on the firewalls DC_OracleDBA_Tickets Team: Micros Fidelio EAME DBA Team Responsibility: o Oracle servers (Clusters, training servers, single servers) o Opera Application Server configurations (config files, oracle client) o Oracle scripts, backups, restores, training refreshes o Opera patch/schema upgrades. Synonym schema creation Examples: o Training refresh for a specific customer. o Checking config files, oracle errors on the application servers o Troubleshoot oracle related performance issues DC_System_Tickets Team: Micros Fidelio Frankfurt Datacenter System Team Responsibility: o Hosted servers, backups, monitoring, server deployment o Storage maintenance, DR replications, server imagining o Access management, Antivirus updates, etc Examples: o Create user account, grant access to specific servers, customers o Schedule scripts on certain servers o Restore files from backups, create DR Images of servers.

o Troubleshoot system performance issues (high cpu load)

When will somebody work on my ticket or close my ticket?

This depends on the actual workload of the relevant teams (queue admins) and the type of your request. You can see the standard lead time on the following link: https://www.microsdc.com/download/Hosting_lead_times.htm

How to open a ticket if I do not have an account, or my account is disabled?

Go to www.microsdc.com Select service request on the top. Then the system will ask for your email address

Your mail address has to be verified, so the system will send you an authorization code via mail

Once your mail address has been verified, you need to type in some details for your user account

After you have done this, you can create a ticket. You can specify everything just like a signed in user, except you would not see the allowed customer list as an anonymous ticket requestor

How to open a ticket if I have a portal account

Go to www.microsdc.com , sign in a) Select Create Service Request under Service Request menu. b) Select service request. Use Service Request tab, and click on Create

Then on the next page you can create the ticket. Click on the Create Ticket button (if you want to open a ticket and not a CR)

Once you click on the Create Ticket button, you have to select a queue. (Queues are described in section Who will work on the ticket I opened?

Fill the details of the ticket:

Click on SAVE and then your ticket has been created:

How to check the status of my ticket?

For major status changes of your ticket you will receive email notifications. However it is recommended that you check the ticket status online. Go to www.microsdc.com , sign in Select Service Request

Then you have 2 options. You can enter your ticket id, and click on Go so the portal will search for that ticket, or you can use the Requested by me checkbox to get it displayed (default view might change in the future)

Then you can select the ticket and click on the View or edit button. Obviously use the Edit button if you need to change any attributes of the ticket. In Edit mode you can change the customer, clarify case, etc and you can even convert the ticket to a change request or you can close/delete the ticket if it is not relevant any more.

How to reply/follow up a ticket?

Main goal with the ticketing system is to be able to track certain task requests. If the ticket owner is off other team members can always check the status and take over a ticket. For this we have to make sure all correspondence is recorded to the ticket history. So please always use the Reply feature to add comments to the ticket, follow up the owner or queue admins. This way the history will contain all important information about the ticket. Both in View or Edit modes (see previous section) you can use the Reply feature. Using Reply will also send emails to relevant people.

And then the reply goes out in a mail + it updates the history of the ticket

Who is working on my ticket? Ticket statuses

A ticket can have 4 statuses New Ticket was created, it is sitting in the queue you selected. Nobody started to work on that ticket (there is no owner yet) or the previous owner put the ticket back to the queue. Assigned Ticket was taken by one of the queue admins. There is one owner of the ticket. Pending closed Ticket owner closed the ticket, but the requestor used Acknowledgement needed before close checkbox to open the ticket. This means only the requestor can close the ticket (if agrees that it is completed) Closed Ticket was closed, no further action required on this case. So if your ticket is still in New status, then nobody started to work on that yet. If you want to follow up, use the Reply feature and send it to the queue-admins If your ticket is in Assigned status, that means there is an owner already for this ticket. You can address any messages (Reply feature) to the owner, You can also check the owner if you View or Edit the ticket (see How to check the status of my ticket? section )

Everything about Change Requests (CRs)

Why do we need to use change management?
In mission critical production systems changes which were not prepared properly could cause downtime for customers. Worst case improperly implemented changes could cause data loss, and roll back might be very difficult or not possible at all. Based on current ITIL recommendations, and PCI DSS rules for mission critical production systems every administrator (or every user having access to the system) MUST follow change management rules.

Change management basic rules

For every change even for small changes the same rule applies: Properly plan and prepare the implementation of the changes having a Data Protection Plan and Change Risk Assessment Goals for the Change Management - Prevent unplanned downtime, and possible data loss - Fast rollback if the changes has negative affect - Tracking changes (for future references and troubleshooting) - Get approval from the responsible persons / teams for the changes

What is the change request and how it works?

Change Request (CR) is basically an extended ticket. Extended means it has more attributes, and more statuses. Just like the tickets, every Change Request has its unique ID. If you successfully open a CR, the portal will show you the generated CR ID. With this ID you can locate your CR later, you can verify the status online, and you can use this for escalations. Change Requests goes through a certain workflow process like testing, approval, implementation. This workflow is not hardcoded. Depending on the Change Type, certain CRs might skip testing phase, or they might go immediately to Implementation. Except self approved CRs (more details later) all change requests has to be approved by one or more teams/groups. Depending on the Change Type the CR will ask for approval from various teams. So it is very important that you select the correct change type. If you dont, you can expect some delays, while the non competent teams change the Change Type to the correct one, so the CR goes to the right queue, and will wait for approval from the correct teams.

Change request lifecycle and statuses

Change Request Outstandingly needs Test Declined

Reject

Schedulling (test)

Testing

Approvals

approved

Scheduling

Implementation

Close (Succes

1
Coordinator OR Queue Admin

3
Coordinator OR Queue Admin

Rolled B

Category > requires test

Requires Test

Category > No test required

More info Category > needs approval

Self approved

Category > self approved

Advantages Same starting point for the user Unique ID numbering Ability to perform the conversion Ticket <-> More info

Ticket Rejected Start/New

New

Assigned Closed

On-hold

Change request statuses

Every Change Request (CR) will go through a change management process / workflow. New You are opening the CR, the CR has not been saved yet. Requestor needs to change the CR to proceed More Info Somebody (approval for example) during the CR workflow process requested more information from the requestor. So in this state the Requestor needs to provide more information about the requested change. Test scheduling This Change Request has to be tested, and testing has to be scheduled. For self-service (more details later) CRs, the relevant team (queue admins) should take the CR from the queue, schedule it, and start the tests. For non self-service CRs, the Coordinators would need to schedule the CR for testing Testing In this status the owner of the change request is the person assigned for testing. As soon as the change is tested, the owner should submit the CR for approval Approval In this status the CR has to be approved by one or more teams/groups. Depending on the Change Type the requestor originally selected, various teams could be involved with the approval process. The CR can only be submitted for implementation if ALL one person from each approval group approved the CR. It is the approvals responsibility to check if the request is valid, verify the implementation and data protection plans. If the approvals needs more information, they can put the CR in more info status, they have the right to reject the CR. Implementation Scheduling This status is similar to the Test Scheduling status. This Change Request has to be implemented, and implementation has to be scheduled. For self-service (more details later) CRs, the relevant team (queue admins) should take the CR from the queue, schedule and implement it. For non self-service CRs, the Coordinators would need to schedule the CR for implementation. Implementation This status is similar to the Testing status. In this status the owner of the change request is the person assigned for implementation. There can be more people selected for the implementation, but only one of them can be the owner. The Owners responsibility to implement the CR in the scheduled time, and close it if the CR was successful or rolled back. Closed / Rolled-back Implementation is over, the requested change was implemented. In case the changes were not successful, and had to be rolled back, then the final status of the CR will be RolledBack. If the CR implementation was successful, then the final status of the CR is Closed

Change request Change Type Workflow scenarios

The Change Request (CR) has to go through a certain workflow. The workflow and the teams involved depend on the Change Type the requestor selected during opening the CR. Complete workflow CR
Outstandingly needs Test

Schedulling (test)

Scheduled

Testing

Test done

Approvals

approved

Scheduling

Scheduled

Implementation

1
Coordinator

3
Coordinator

4
Rolled back

More info Declined Start/New Change Request More info Rejected

Rolled Back

Closed (Successs)

Success

People/teams involved: Requestor, Coordinator, Tester, Approval, Implementation team. Change request attributes: Test needed, non self-service, non self-approved. When to use? For complex changes, where proper coordination needed between various teams, departments and the customers. Example: major application upgrades Complete self-service workflow CR
Outstandingly needs Test

Schedulling (test)

Scheduled

Testing

Test done

Approvals

approved

Scheduling

Scheduled

Implementation

1
Queue Admins

3
Queue Admins

4
Rolled back

More info Declined Start/New Change Request More info Rejected

Rolled Back

Closed (Successs)

Success

People/teams involved: Requestor, Queue-Admin, Approval team. Change request attributes: Test needed, self-service, non self-approved. Note: Queue-Admin will test and implement the CR. Depending on the change type, the CR will be placed into a certain queue, and the team responsible for that queue (queue admins) has to process the CR. When to use? For changes which will be implemented by one specific team, most likely do not require downtime.

Complete workflow CR without testing

Start/New Change Request

Opened

Approvals

approved

Scheduling

Scheduled

Implementation

1
More info Coordinator

2
Rolled back

Rolled Back Declined Rejected

People/teams involved: Requestor, Coordinator, Approval, Implementation team. Change request attributes: Test not needed, non self-service, non self-approved. When to use? For such changes which most likely requires downtime so coordination is necessary between various teams. However test is not needed as this change is a routine change tested already many times in other environments. Complete self-service workflow CR without testing

Closed (Successs)

Success

Start/New Change Request

Opened

Approvals

approved

Scheduling

Scheduled

Implementation

1
More info Queue Admins

2
Rolled back

Rolled Back Declined Rejected

People/teams involved: Requestor, Queue-Admin, Approval team. Change request attributes: Test not needed, self-service, non self-approved. Note: Queue-Admin will implement the CR. Depending on the change type, the CR will be placed into a certain queue, and the team responsible for that queue (queue admins) has to process the CR. When to use? For changes which will be implemented by one specific team, most likely do not require downtime and testing was already done on a different systems (routine change)

Closed (Successs)

Success

Self approved CR

Start/New Change Request

Approved & Opened

Scheduling

Scheduled

Implementation

2
Requestor Rolled back

Rolled Back

Closed People/teams involved: Requestor Success (Successs) Change request attributes: Test not needed, self-service, self-approved. When to use? For minor changes which are pre-approved, and the business impact is zero or almost zero. This change type is more for logging the changes rather than getting it approved. Requestor is fully responsible for the implementations, and they are allowed to implement specific changes described in the change type description

Teams / persons involved with Change requests

Change management is a complex process. During the lifecycle of the project many teams and people could be involved. Here is a summary of the teams, and their responsibility: Requestor Task: Open the change request, in case of self-approve CRs, implement the changes Responsibility: Provide the necessary information in the CR for the implementation (what to change, why to change, where it can be tested, etc), or , in case of self-approve CRs, implement the changes Coordinator Task: Schedule the change request in test and implementation scheduling status. Responsibility: Follow up various teams, customers and make sure the CR is implemented in a timely manner Tester Task: Testing the changes Responsibility: Implement the changes in a test environment, provide timing information and implementation documentation for the approvals and later for the implementation team Approval Task: Review and approve the change request Responsibility: Check if the test were not properly, verify if the changes are really necessary, and make sure there is proper data protection and implementation plan in place.

Implementation team Task: Implement the changes Responsibility: Implement the changes according to the relevant checklist or implementation plan. For major changes more teams involved with the changes. They have to coordinate the necessary steps Queue-Admins Task: Take CRs from the queues, test or implement them Responsibility: Regularly check the queue for un-taken CRs. Work on unassigned CRs test and implement the requested changes. Note: For self-serive CRs the Queue-Admin team is the same as the Implementation or Tester team.

Who can open a Change request?

Everybody can open a change request who has active account on the Frankfurt Datacenter web portal (www.microsdc.com) and the user account is assigned to at least one customer.

How to open a Change request?

Go to www.microsdc.com , sign in a) Select Create Service Request menu item under Service Request. b) Select service request from main menu. Use Service Request tab, and click on Create

Then on the next page click on the Create Change Request button

Once you click on the Create Change Request button, you have to select a Change Type. As soon as you select a CR, you can see the description for that change type and the expected workflow will be displayed as well. You can also see which group(s) are responsible for approving this CR

You can also fill in Change Risk Assessment, Data Protection Plan and Implementation Plan. Although these fields are not mandatory, please help the approvals filling in the necessary fields. Without that information the approval process might be longer, as the approvals will need to collect this information from the requestor or from other team members.

Click on SAVE and then your CR has been created:

How to check the status of my Change request?

For major status changes of your change request you will receive email notifications. However it is recommended that you check the change request status online. Go to www.microsdc.com , sign in Select Service Request

Then you have 2 options. You can enter your ticket id, and click on Go so the portal will search for that ticket, or you can use the Requested by me checkbox to get it displayed (default view might change in the future)

Then you can select the CR and click on the View or Edit button. Obviously use the Edit button if you need to change any attributes of the CR. Note: You might not have the right to change certain attributes. When you open the CR, you can see all necessary information about the request: Status, Approval groups, approval status, owner, etc. You can also view the history of the CR, you can see who did what about the request.

How to reply/follow up a Change request?

You can do this the same way as described for the tickets. Go to How to reply/follow up a ticket section

Who is working on my Change request?

This depends on the status of the CR. In each status there are different group of people responsible for the CR. This is described in Change request statuses section.