[31] in Tooltime
interim nicit report
daemon@ATHENA.MIT.EDU (Harold Pakulat)
Fri Feb 23 15:02:08 1996
Date: Fri, 23 Feb 96 15:01:04 EST
To: tooltime@MIT.EDU
From: Harold Pakulat <pakulat@MIT.EDU>
Hello-
NICIT has some explicit expectations for the Help Desk tool that you
probably need to be aware of.
Thanks,
Harold
>Date: Fri, 23 Feb 96 11:16:53 EST
>To: cec@MIT.EDU, rar@MIT.EDU
>From: joanne@MIT.EDU (Joanne Costello)
>Subject: interim nicit report
>Cc: nicit@MIT.EDU, support-ct@MIT.EDU
>
>NICIT Interim Report: 23 February 1996
>
>Since our last report, the team has concentrated its efforts in 3 areas:
>
>1) Identifying requirements for the Help Desk Tool
>
>2) Re-examining our original recommendations; prioritizing them and
>estimating timelines for them.
>
>3) Delving "deeper" into the boxes of the process map
>
>
>This report concentrates on the first 2 areas of activity.
>
>Section I. Requirements for the Help Desk Tool:
>
>In prioritizing our recommendations, the team was in agreement that a good
>tracking tool was critical effecting improvements in the network
>installation process. For that reason we have separated it out from the
>remaining recommendations and listed some very specific requirements for
>that tool. We have forwarded these requirements to the HD tool team.
>
>We recommend the deployment of a Help Desk tracking system which meets the
>following requirements:
>
>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 hand-offs between teams, the system should help to make these
>hand-offs as transparent and streamlined as possible. A hand-off 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 hand-off.
>
>* 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, e.g.., 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 listing his/her daily list of appointments.
>
>Section II. Other recommendations.
>
>In assigning priorities to our other recommendations the key factor was how
>much of an impact the recommendation would have on improving the process.
>For that reason there are items in the high priority list which may be
>difficult to implement and there are those in lower priority which would be
>easy to implement.
>
>High Priority
>----------------
>
>I. The development, implementation and maintenance of a jack database
>indicating the location of each jack and the use of each port on the jack.
>
>Currently no such database exists and this has led to multiple problems for
>clients and IT personnel. Such a tool would eliminate the need for most
>"site visits" to gather jack information.
>
>It would also assist the Help Desk staff in determining "non-simple"
>installations.
>
>While we recognize that the development, implementation and ongoing
>maintenance of the database is a long term recommendation we strongly
>recommend that resources be allocated to begin the data collection and
>entry as soon as possible.
>
>II. Revision of the billing process for network installations.
>
>The existing billing process for network installations and other charges is
>a cumbersome one. One-time charges are done via journal voucher. Monthly
>charges are generally done via the "non-phone equipment" Oracle database on
>TCM. The existing billing mechanisms are problematic in that they require
>rekeying of data into the billing systems, sometimes multiple times. The
>database is not designed for meaningful reporting. It is cumbersome to
>report and reconcile billing information. The billing systems must be
>revised to:
>
>1) permit better use of staff time.
>2) provide customers with coherent and complete billing reports.
>3) provide ourselves with coherent and complete billing reports.
>
>An overhaul of the billing system cannot be done independently. A redesign
>depends on the functionality of both SAP and the ICE-9 replacement, TMS.
>We need to make sure the network billing requirements are addressed by
>these two systems. While it is unclear what functionality SAP will be able
>to provide and when TMS will be implemented, we believe there is work we
>can do now to examine the billing processes. At the very least, we can
>begin to draft a list of requirements for TMS and identify some "quick
>wins" to streamline the existing processes.
>
>We recommend that a spinoff team be formed to look at the billing issues.
>Membership of this team should include
>
> Brian Shannon and/or Errol Morrison
> Cynthia Endriga
> John Henriques
> Helen O'Brien
> Lorraine Rappaport
> (anyone else?)
>
>III. Transmission Service Team staff should "complete" installation for
>clients.
>
>The team members of the Transmission Services Team, after completing wiring
>of "simple" installations, should provide to the client a bootstrap packet
>including software, documentation and IP address. If the client requests
>it, the Transmission Services team member will install the software. This
>will permit the client to be up and running sooner, meet client
>expectations that once the wiring is complete the job is complete, reduce
>hand-offs between teams, and allow for job/skill expansion for members of
>the Transmission Services team.
>
>The bootstrap disk used by Transmission staff should "get" a web browser
>and email for the client.
>
>We recommend that the current Transmission Service Team's networking skills
>on the various supported MITnet hardware platforms (including printers) be
>reviewed and upgraded.
>
>This recommendation should be implemented only after a reasonable solution
>has been implemented for the current billing and circuit documentation
>overhead.
>
>IV. The Installation meetings should continue.
>
>For the past four years (approximately), members from Network Support
>Services, Transmission Services, Network Operations, the MCC, and others
>have participated in bi-weekly meetings known as the Installation
>Meetings. This forum has been utilized to:
>
>* Review the installation queue
>* Discuss product recommendations, and related issues, such as MCC
>inventory issues
>* Discuss operating policies and procedures and revising processes
>accordingly
>* Share information about customers, technical knowledge, etc.
>
>NICIT, the Installation Meeting group members, and the I/T Service and
>Support directors unanimously agree that it is important to continue
>this tradition. The Installation Meeting forum is crucial to continuing
>communications among the various teams that support MITnet and its
>users.
>
>Membership now includes representatives of the following teams:
>
>Departmental Computing Support
>Help Desk
>Transmission Services
>MITnet Services
>Desktop Products
>MCC
>I/T Support Planning and Prevention
>Network Business Administration
>
>It is our understanding that this team will focus on the day to day
>operational issues and that they will defer strategic matters to the
>Network Coordination Team.
>
>NETWORK COORDINATION TEAM
>
>There is an additional need for a forum in which to discuss strategic
>network planning issues, such as new network services, major
>infrastructure enhancements, general customer service issues, and
>rate-setting. This forum need not convene often; monthly or quarterly
>meetings may suffice. An email list of its members may be a valuable
>tool for sharing information, discussing issues and keeping members
>informed of trends, potential problem areas, project updates, and other
>matters. In practice, this team should operate much like ACMG and OCMG.
>
>Medium Priority:
>-----------------------
>
>V. A Web form should be developed to facilitate requests for installations.
>
>Users should be able to initiate the installation process by completing a
>Web form which will then be automatically input to the Help Desk tracking
>system.
>
>Such development is currently underway.
>
>VI. Each department should designate a contact person who will complete
>ALL requests for that department. We expect this will be done by completing
>the Web form for installations. This will serve as the initial screening
>of simple vs. complex. This person will be trained by the Departmental
>Computing Staff.
>
>VII. Members of the Transmission Service Team and the Network Operations
>Team should have direct access to the current Filemaker database being used
>by the Help Desk.
>
>Currently when an installation is complete the Transmission staff sends
>email to the Help Desk staff who then update the record in the database.
>We recommend that they update the record directly.
>
>When a design is required for a network installation, the Network
>Operations hand paper to the Help Desk or DCS staff who then pass the paper
>to Transmission. Direct input of the design would eliminate these
>hand-offs.
>
>Low Priority:
>-----------------
>
>VIII. DCS should assign its own IP addresses and cut their own FOs (as
>long as they exist). This would eliminate a hand-off to Get-It and back.
>We recommend that there be resources allocated to DCS to allow for this.
>
>IX. The administration and oversight of the "Flat Rate Jack" program
>should be done by the Transmission Services team. Currently, and for
>historic reasons, the administration and oversight of the flat rate jack
>installation has been done by the 5ESS Operations area. This has led to
>confusion, implementation delays, and less than satisfactory work
>coordination. This recommendation can be implemented immediately.
>
>X. A tool should be developed which would allow for batch assignment of IP
>addresses.
>
>Currently the information for each address must be entered manually. It
>would be a big win for the DCS staff if the process for assigning a large
>number of IP addresses could be done by batch.
>
>XI. The way in which the Transmission Service Team assigns and dispatches
>jobs should be examined.
>
>Section III. A Time Line
>
>March 1:
>
>*The Installation Meetings
>*Transmission and NetOps staff to have access to current Filemaker Database
>system
>*Begin Identifying departmental contacts
>*Begin review of billing process
>*Transmissions begins "complete" installs
>* Examination of the dispatch process
>
>April 1:
>
>*Deployment of Web Form
>*Flat Rate Jack Program moves to Transmission
>*Resources allocated to DCS for assigning IP addresses/cutting FOs
>(note: this recommendation may change once we look more closely at the
>process within DCS.)
>
>May 1:
>
>*Findings from "billing process" team
>
>Implementation of other recommendations such as the jack database will
>depend on whether or not and when resources are allocated.
>
>
>
>
>
>
>
>
>
>
>===============================================================
>Joanne Costello
>Manager, Network Support Services
>Phone (617) 253-6322
>E-Mail: joanne@mit.edu
>
>
>
