Work Request - Work Order - Help Desk application

Goal: Produce a Work Request System to be used by Irvine, Arden and Covington, and other PROTOCOL sites

Break out Request and Assignments by divisions, sites, departments, categories, sub-categories, account
- Irvine - Software
- Covington - Hardware
- (This may be further sub-categorized after that as to, for example, Irvine - Software - FulFilPro. Covington - Hardware - Monitor.)
- Create a hierarchy
Create roles for users
- Requester
  - Employee making a request
- Approver
  - Department Head of requestor
  - Supervisor
- Assigner
  - Supervisor
  - Department Head of support
- Assignee
  - Support person responsible for performing assigned task
Email Approving Supervisor "Approver" (based on department) when a New Request is created.
Email Person when a Request is assigned to her or her group. (There could be multiple people assigned to a Request.)
After meeting, we also discussed ability to send out notification to whoever is set to be notified, so they will Look at update a particular Request.
Add to Priority a list like "temperature", Wish List. Presently there is Normal, ASAP, End of Day.
In developing, need to consider ability to breakout employee man-hours per Project, Request, or Assignment and what can be capitalized, billed or not billed. (Remember we bill to some clients also.)
Additional dates would be:
- User Request Completion Date
- Programming Projected Completion Date
- Actual Completion Date
Not discussed, but perhaps department priority and then also a priority for the person assigned the Request?
Parent Request, and then a Child Assignments.
When a Request is completed:
- Force a comment
- Record the Identity of the person completing the Assignment and Request
- Record the date and time
Use one program for both Hardware and Software
- (referred to above)
Times for Managing Programming Resources:
- Estimated Time
- Actual Time (Will be building, accumulating)
- Time Remaining (Estimated vs. Actual)
- Time for each person involved on particular work request
Request and Assignment Attachments
- allow attachments to be posted
- allow attachments to be retrieved
- allow multiple attachments per request
Reporting needs
- Itemized time statements for client accounts
- Service to Client to Rate table must be managed for billing report

Action Items to do:

We said we would put together the databases and then forward this to Irvine for their evaluation.

Sample Completion Email:

Subject: Completed WO# 5910 - DR Cookie Complication

Your request has been completed.

Work Order No.: 5910
Priority: 2_High (within 24hrs)
Requestor: bread
Technician Assigned: Tim Vasquez
Phone:
Date Due: 11/1/2002 5:15:00 PM
Completed Date: 11/1/2002 10:58:00 AM

Description:
Some Windows98 and Three NT machines fail to register
new agents that sign into the DR system in the Cookie file
thus causing calls to be credited to the preceding Agent.

Extensive testing confirms that there is no flaw in our
system that causes this problem but there may me a flaw in
the configuration of the Work Station. Timo assured me
that he will inform me when this problem occurs again so I
can evaluate the status of the cookie file at the point of
failure.
Escalated on 10/31/2002 5:49p from Tim Vasquez to
Terry Hughson

Resolution:
1) Delete existing cookie files manually & reboot the
machine. This is a short term fix but these actions will be
required periodically.

2) At shift changes make sure that the new agent signs on
to windows. This will assist the new agent in making sure
that they are starting the day using a reliable Work Station.

3) Lansing modified the DR system to retain cookies for 16
hrs rather that one week. This will reduce the number of
entries a that are saved in the cookie file (user@10.1.112[1
or 2]) thus reducing the possibility of exceeding size specifications.

Analysis Questions and Answers

Do we want to separate our work requests by Division (hoping others will come on board), then Location (i.e. Covington, Irvine, Arden), then Department (i.e. networking, software, hardware, programming, don't know) . Also, we feel it's important that we all name our departments the same, regardless of whether or not they enter work requests. Say, maybe Irvine has a database department, we don't. So, when a drop-down list comes up for our location, it would not have database listed as a department category. I just felt this was important if we were wanting to use this across divisions eventually, so things could be looked at as a total.

I would say yes, separate by Division, Location, Department. And yes to department standardization

We assign work requests here, sometimes with a client (i.e. Blue Cross-account # 4030). Should we have a client connected to a location? Or leave this open. I was just wondering, as although we may not service the client at our location, we (IS) could be doing the work.

I am not sure I am following. If you are asking should we have the ability to attach a client name to a work request? Yes, regardless of whether the client is served at our location

As far as billing for work, be it a capitalized expense or a customer being billed for work already done. We have started to bill clients for work in increments (I think), because sometimes work can take some time, and we should be getting paid for (or expensed) probably monthly. Was wondering what your thoughts were on this. We aren't wanting to write an entire accounting application for this, but I think we could handle knowing what was already billed to a client, and accumulating total time worked.

I am not clear on this question either. Yes we need to track time for billing purposes and we need to distinguish between CapEx development vs. account maintenance/setup vs. non-billable work. But all time should be tracked and yes we should be able to bill at the end of a billing cycle regardless of whether work is complete. I think this needs to be a group discussion as to whether billing is automatically "closed out" at the end of a cycle or do we do this on a manual basis.

In Track It, they have a function called Solution. It is where you can enter what was done to solve a problem, and then someone, or yourself in the future could search for the solution entered. Is this something you need to have?

Like a knowledgebase? I think that would be useful but should not slow us down to implement right away. Can be added later.

Preparations

Migrate MySQL to SQL Server

Look at Track-It , it's version as well http://10.1.69.27/tiweb50/scripts/trackit.asp

Look at Existing Work Request http://10.1.71.12/intranet

Here is a list of a few changes and suggestions made by Bill as of 1/6/3

Add a requests button to display a pop-up window of a Requestor's prior open requests in a simple list displaying:
- request number
- subject
- priority
- rank
Add title to the Person Table (done) so it can be displayed on the person info page
Change the date criteria on the Assignment and Request Query section to allow a date range instead of a single date
Add a "BH" Warning image next to the Requestor link on the ManageRequest page so that Assigner and Approver can be notified when special types of Requestors make requests.
- I figure an exclamation point should do for now, but we can change the image to whatever Bill would like later.
- We have to be able to somehow signify that this requestor is special also, perhaps an additional table that is manipulated only by an administrator role.

All materials and notes are the intellectual property of XOCOMP with expressed permission for use by PROTOCOL.