|
|
|
TNSConnect Historical Info
What problem are we
trying to solve/what opportunity are we trying to take
advantage of by installing a new system?
The current FMS was
originally developed to manage telephone services which are only a
part of our business. The vendor has provided several custom
enhancements to assist in tracking data connections and other
services but it is all based on the telephone service management
layer which does not account for or track data network
infrastructure properly. In addition, the data is stored in flat
files, not a relational database. Therefore the data is not readily
available to other University systems and is not easily accessed for
reporting internally or externally. So the broad problems we are
trying to solve are:
-
Increase our ability to accurately track information
about our infrastructure and services.
-
Increase our reporting and accessibility to the data
that is tracked to improve TNS efficiency and ability to manage the
services, and the customers’ ability to access and provide
information about their services.
A requirement of the
new FMS is an open architecture for data access, reporting and “bolt
on” customized functions not provided with the purchased software.
Tracking the information is only part of the solution. While getting
a true relational database is a major factor in the need to replace
the current system, getting the information to a reportable format
that meets the needs of all types of users requires a system that
incorporates a multi-function reporting tool and allows appropriate
accessibility to the reports and data.
Our 30,000 ft.
strategy is as follows:
-
First, replace the functionality of the current FMS. We are not
married to the processes we use but we must, at a minimum, maintain
current functionality.
-
Next, add functionality in terms of the information
tracked, integration to and from other systems, better reporting on
that information, and more accessibility to that information. This
would include new features like web based reports.
-
Then, continually improve by tracking more information
as necessary, and increasing the scope of the reporting available
and the sphere of those who have access to the information.
The idea is not to purchase a solution
that does “everything” since one is not available, but instead
to purchase one that can track what we need, allow us to
integrate it with other systems as needed, and to make
the information easy to understand and accessible.
What
functionality will the new system provide?
-
•Work orders
-
•Trouble tickets
-
•Cable plant management
-
•Warehouse inventory (including asset management)
-
•Component (data gear) tracking
-
•Phone number, IP address, and subnet tracking
-
•Port-to-jack mappings
-
•Costing/Billing
-
•Business process workflow
-
•Time accounting
-
•Reporting
-
•Customer portal (Phase 2)
-
•And more!
What is the
Project Time Frame?
Phase 1 - Planned
completion December 2007 |
| |
Internal TNS
Processes |
Phase 2
- Planned completion December 2008 |
| |
Warehouse System |
| |
Data Component |
| |
Customer Portal |
Phase 3
- Planned completion "not scheduled" |
| |
Best Practices |
| |
Process
Re-Engineering |
| |
Probable Integration
with other University Systems |
| |
|
Remedy |
| |
|
Work-Flow |
| |
|
ISIS |
In the old FMS the organization of the information or
hierarchy, was based on a billing number like an
extension (telephone number). Because the system was
developed for telephones, TNS had to devise a numbering
scheme for other services tracked by the system like
data and direct circuits. This numbering system used a
letter code and a sequence number to identify the type
of service it represented. Users or owners of the
services were not really part of the information tracked
by the system.
In
TNSConnect the organization of the
information is based on a hierarchy starting with
accounts, departments and users. This is a more
intuitive structure in that services are connected to
users and no longer require an ID number for the sake of
an ID number. A telephone service is still identified
under the user with the extension, but a data service no
longer requires a fake number to exist and be easily
accessible.
This user-centric verses number-centric
architecture makes locating services easier, invoices
more readable and parsing long distance billing reports
to responsible parties much more a computer task rather
than a human task.
New Customer Model
To facilitate customer integration and use of the new
system, TNS has defined a slightly new customer model.
This model involves representative from each
departmental who fill specific roles. The roles are:
| Billing Coordinator |
| |
MFK Verification |
| |
Receive monthly invoices
and billing reports |
| |
Reconcile charges |
|
Technical
Contact |
| |
Data port settings |
| |
Security |
| |
NetFolks, OUS, dept IS
contact |
|
Data
Liaison |
| |
Manage all data services |
| |
Verify data services in use |
| |
Order data services |
|
Voice
Liaison |
| |
Manage all voice services |
| |
Verify voice services in use |
| |
Order voice services |
|
Video
Liaison |
| |
Manage all video services |
| |
Verify video services in use |
| |
Order video services |
It is not a requirement that each role be filled by a
separate individual. In some departments all roles will
be filled by a single person; in others, all the liaison
roles may be filled by a single person with separate
billing coordinator and technical contact. The model is
meant to be flexible.
|
|
