|
Archive
Flanagan Consulting
Network Analysts and Consultants
"We Have the Experience"
-------------------------------------------------------------------------
ViewsLetter on Provisioning
10 March 2003 #18
IN THIS ISSUE:
-- DASHBOARD DANCING: Watching ALL the Network at Once
-- ILEC's Attitude and FCC Deregulation
>>Analysis
DASHBOARD DANCING
Nicole Drapeau Gillen
Principal, Greenwich Technology Partners
How often does an executive of a Service Provider--responsible for
hundreds of employees and a range of functions, constantly struggling
over
turf battles, operations, engineering, personnel, and customer
churn--receive needed reports, briefings, and analysis at just the right
time? Ironically, executives often get too much data, but not necessarily
the right data when needed. What's the answer?
Dashboards can be a very good mechanism.
A dashboard is typically an HTML page with some built-in functionality.
The dashboard is a homepage and a portal. It's a navigator and a
tool to
present data in near real-time. Data coming off a network typically
increments at five-second intervals. That's real-time enough to make
decisions. Clearly, the time increments depend on the Network Management
systems as well as the data stores, integrations, and CPU processing.
A dashboard can present data from all facets of the front and back office,
but each is tailored, depending on the executive's interests, MBO's
(Management By Objectives), and compensation metrics.
A person compensated on Operations metrics might want to watch network
up
time, Network Operations Center call volumes, trouble ticket history,
service performance, and MTTR (Mean Time To Repair). On the Engineering
side of the house, an executive could be compensated based on capacity
metrics or network performance at a device level. And yet, even
though
each executive measures performance in different ways, the data on how
well they are doing comes from the same sources: the Operational Support
Systems (OSS's) and the Network.
To deliver the data that each decision maker needs, the creation of the
dashboard requires some planning, probably some system and network
changes, development, and customization.
* Planning. What data are important? Where in your infrastructure
or
systems will you find those data? Once the sources are identified, you
will need to plan out how to scrub and synthesize the inputs; apply
OLAP;
and extract, transform, and load the data to build and deploy the
dashboard.
* System Changes (OSS) and Network massaging. The OSS of a
Service
Provider, though integrated to some degree, usually looks more like a
series of islands connected by very thin lines of sand. One major
storm,
and those islands are stranded. A fair amount of integration and
analysis
is required to must be define, aggregate, correlate, and display
data
from the various back office systems. Clearly, the development effort
to
define that data set, capture it and do the data crunching takes time
and
money. So, while the deployment of a dashboard, in and of itself,
may not
be an expensive proposition-the real meat of the cost comes often in the
data collection from the OSS layer.
* The engineering staff may face additional work to automate pulling
the
correct data off the network devices. Since the purpose of the dashboard
is to provide timely, meaningful content for decision making and
awareness, the development organizations must re-think its data
manipulation processes to remove the human element, as much as possible,
from the dashboard operation. This step becomes easier as provisioning
is
automated. Adaptations made to support flow-through provisioning
also can
make information available to a dashboard.
* Dashboard development includes defining and creating the functionality.
Areas like collaboration, virtual workspaces, portals and workflow
must
be architected and planned. A dashboard's usability will help drive
its
deployment and acceptance. When deployed properly, the dashboard
is the
heartbeat of the organization.
* Customization. To customize the dashboard, the GUI will
have to be
somewhat hard-coded. Unlike websites that change on a frequent basis,
much of the presentation layer of a dashboard will stay the same,
responding to questions such as: Will all data be presented on one
page?
Will tabs be used? It's the core data that constantly change.
After all of this work, are dashboards worth it? Clearly, this is
no
small undertaking in a Service Provider environment. However, results
are
absolutely tangible and quantifiable. For example, a dashboard reduces
information overload by distilling the important information from multiple
sources, allowing improved collaboration and information sharing at every
level of the organization. The downstream impact is to eliminate
redundant human activities and free up staff to be more productive.
By
seeing the right data at the right time, executive and managers make
better and more informed decisions, ultimately improving the business.
Last, through a common dashboard framework, Service Providers can realize
a reduction in training by providing remote availability of data and
extension of familiar productivity tools to a common audience.
Another way to use a dashboard is in allocating funding. A dashboard
filters the noise out of data and presents meaningful information.
The
dashboard removes one of the biggest obstacles executives face in
justifying requests.
Going a step further, dashboard information can be a motivator.
Applying
the MBO concept, a dashboard can track performance not only of the
network, but also of a team or individual. Triggers can be built
in to
highlight when an individual reaches a certain level of achievement or
attains an objective--a personal score card. This approach encourages
the
staff to focus on what's important for management, to improve their own
"scores," and even to compete with their teammates.
Ultimately, the dashboard could re-invent how a Service Provider does
business.
About the Author
Nicole Drapeau Gillen (ngillen@greenwichtech.com) is
a Principle at
Greenwich Technology Partners. She has over eight years of
telecommunications industry experience including advanced systems
architecture and design, Internet/IP product development, and lifecycle
system development. She was instrumental in the development of GTP's
Express Management Solutions (GEMS) OSS reference architecture.
At GTP
she applies best practice consulting skills to optimize the performance
of
IT infrastructures for Global 2000 financial services, pharmaceutical,
telecommunications, and other information-driven corporations.
>>Analysis
ILEC's Attitude and FCC Deregulation
--William A. Flanagan, Editor and Publisher, ViewsLetter
The intense lobbying of the FCC over (de)regulation of Local Exchange
Carriers went as far as heavy TV advertising in the Washington, DC area.
Statements from incumbent LECs (ILECs) stressed that they didn't want
to
invest in outside plant to support broadband services if the new
infrastructure was going to be "taken" by competitors at less than its
"cost."
"Cost" to a regulated phone company has been subject to interpretation.
For about 100 years the Bell companies worked under "cost plus"
regulation, so they've had time to learn how to maximize "cost" in order
to maximize their return. Hardly anyone I've spoken with believes
that
offering unbundled network elements actually reduces an ILEC's cash flow.
One particular change in the regulations reportedly coming from the FCC's
triennial review is that ILECs will no longer be required to share voice
copper loops with DSL (data) providers--a money loser ILECs claim.
How it
is possible to lose money by collecting extra revenue from a loop in
service has not been explained clearly--particularly when the DSL company
is also paying handsomely to rent co-location space in the central office.
Perhaps it is the habit of thinking like a "natural monopoly" for so many
decades that makes a threat and competitor of any attachment to "my"
network. But there's another term often applied to a company that
comes
to your firm and offers money, on a regular schedule, to rent something
that you can offer. We call that company a "customer."
If a deterrent to sharing is the difficulty of setting up inter-carrier
connections and getting the billing straight, the solution would be more
automation in provisioning, not the restoration of the monopoly.
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: 11 June 2003
|
