[21] in Tooltime
NICIT Requirements/Wish List for New Help Desk Tool
daemon@ATHENA.MIT.EDU (Barbara Goguen)
Tue Feb 13 13:45:55 1996
Date: Tue, 13 Feb 1996 13:45:34 -0500
To: tooltime@MIT.EDU
From: goguen@MIT.EDU (Barbara Goguen)
For the record, here is the mail that comes out of NICIT.
>Date: Mon, 12 Feb 96 09:21:01
>From: ljr@MIT.EDU (Lorraine J. Rappaport)
>To: kim@MIT.EDU
>Subject: NICIT Requirements/Wish List for New Help Desk Tool
>Cc: goguen@MIT.EDU, nicit@MIT.EDU, pakulat@MIT.EDU
>
>Kim,
>
>Following up on our conversation after the last OCMG meeting, here is a
>list of NICIT's requirements for the new Help Desk tool. We strongly
>believe that this functionality will streamline the installation
>process. The result will be better and faster service for our customers
>and less hassle and rework for ourselves. In addition, we believe that
>by having all network installation information at their fingertips, the
>HD staff will better serve their customers.
>
>Please let us know if you need clarification on any of the below items
>or if you would like to meet to discuss them.
>
>Thanks!
>
>The NICIT Team
>
>
>
>
>
>
>
>NICIT REQUIREMENTS/WISH LIST FOR NEW HELP DESK TOOL
>
>
>High Priority:
>-------------
>
> * Provide access to all teams/individuals involved in the network
>installation process
>
>The installation process spans a number of standing IS teams including
>the Help Desk, MITnet Services, Transmissions Services, Departmental
>Computing Support, and several individuals. Everyone involved in the
>process should be able to have access to the system and be able to see
>where a job stands at any given point in time. Further, as the process
>spans several teams and requires handoffs between teams, the system
>should help to make these handoffs as transparent and streamlined as
>possible. A handoff should not imply a delay in the process. We expect
>that the system will serve as a communication tool as well as a
>database.
>
>* Provide notification of events/status change
>
>The system should support a list of those who need to be notified on a
>change in status on a particular job. For instance, filling in key
>fields should trigger a message to be sent to that list. For example,
>once the IP address is assigned and Facility Order fields are filled in
>by Cynthia, the Transmission group and consultant should receive mail.
>
>* End-user initiated input/output
>
>Users should be able to complete a Web form to send a network
>installation request. This form should have certain mandatory fields.
>The Help Desk system should be able to take input from the Web form and
>place it in the appropriate fields of the database. The installation
>screen should be designed so that it conforms to the fields in the Web
>form.
>
>* Merge other Help Desk systems and databases, including the Facility
>Order and Controller databases.
>
>Process members currently share three databases for information about
>installations:
>
> 1) Network Help Desk filemaker database
> 2) Facility Order database on TCM for order generation and
> status reporting
> 3) Controller database on TCM for information about repeaters,
> phone closet locations, and drop locations
>
>The multi-database problem results in duplication of data, time-sink in
>making sure all databases are accurate, and some inconsistencies of
>data.
>
>* Produce statistical information automatically
>
>Ability to produce standard and ad hoc reports for quarterly reporting,
>tracking installation completions, and so on. Users must be able to run
>their own reports.
>
>* Required input fields
>
>* Escalation mechanism for overdue tasks
>
>Ability to send mail/report to specified individuals if installations
>are overdue or spend too much time in the queue.
>
>
>Medium Priority:
>---------------
>
>* Warnings for complex installations
>
>Ability to flag installations in departments that have other open
>installation requests or have had recent installations.
>
>* Ability to attach drawings and floorplans
>
>Ability to scan or attach annotated floorplans to an installation
>record. This will help eliminate the paper handoff.
>
>* Customer can find out status of installation request
>
>The customer need not have access to the database as a Web form query
>would suffice. For example, customer would call up a web form and enter
>in the order number. The database would be queried and return a status.
>
>* Ability to define different access (read/write) privileges to
>different users for different screens/fields
>
>* Access to other databases, eg., host table, billing database, Insite,
>yet-to-be-created jack database
>
>Ability to reference information from other databases. Read-only access
>is good; read/write to other databases is preferable for further
>reducing duplication of data entry.
>
>* Ability to execute other tools, such as hostinfo, hesinfo, and telnet
>from within the database program
>
>
>Low Priority:
>------------
>
>* Appointment option
>
>* Ability to schedule consultant and/or installer for appointment with
>customer.
>
>* Automated lookup of customer profile
>
>* Flags for special cases
>
>Flags installation request if location is problematic, controller is
>full, or other defined conditions. May hinge on whether/when/how
>controller database function is integrated in the tool.
>
>* Notification/access to daily "to do" list
>
>Important if we are able to schedule appointments for consultants and
>technicians. If so, the consultant or technician must be able to
>reference or receive mail liisting his/her daily list of appointments.
>
-barbara
goguen@mit.edu
617-253-6135
