ITelco Reference Model
Now there is two different "world": "IT world" and "Telco
world". But new challenges for providers force to combine this two "world"
in one, "Itelco world". Because it is the new world, have no any practice
in this world. But there are best practices in old worlds: ITIL from CCTA
in "IT world" and TOM (Telecom operations map) from TMForum in "Telco
world". This articles goal to combine that practices in one for new "Itelco
world".
As seen from comparison that models, each of them has strengths and weakness.
Some process good describes in ITIL and some in TOM.
Strength of ITIL is technologies independence. But TOM more detailed and sometime
looks more practical. However some important processes are not defined in TOM.
As defined in ITIL, "Incident is any event which cause or may cause service
interruption or service degradation". There is not such definition in TMForum.
What results?
In ITIL - world there are exist Incident Management process which objective
"to restore Customer Services as soon as possible". In another words,
it's objective "to resolve any incident as soon as possible". It is
important that "resolve" not the same as "to find and eliminate
root case"!!!
Many incidents resolved without determined cause of SLA violation! Moreover,
determining cause and resolving SLA violation ASAP is opposite task. It is needed
some time for determining root cause for statistic gathering. User cannot work
this time!
Root case finding is completely another process, in ITIL, it is Problem Management
which objective is to prevent incidents in future. Therefore, Problem Management
is proactive versus Incident Management. ITIL recommended not mix Problem Manager
role with Incident Manager role because it's roles in conflict. If I am Incident
Manager I interested registering all incidents, but if I am Problem Manager
my objective make incident amount as little as possible. For this reason I have
temptation not register some of incidents.
Therefore it is needed to supplement TOM processes with new process - Incident
Management and modify Problem Management from TOM.
In general all processes in TOM should be modified, because it's definitions
not contained objectives.
But the greatest defect of TOM is lack of Change Management Process!
Unauthorized changes can destroy all systems!
Change Management objective is "To implement approved changes efficiently,
and with acceptable risk to the existing and to the new ITelco Services "
In TOM approach engineer can make changes although it may result for all business!
In other spheres, for example, software engineering it is clear that could not
be any changes without approving from management.
Responsibilities make change disseminate across some Processes (from SLA Management
Handbook, GB917v1, www.tmforum.org):
"4. In some cases, Service Problem Resolution will require changes to
be made to
the underlying infrastructure per contractual agreements. This requirement will
be
sent to the Network Maintenance and Restoration process for activation. In other
cases, the data will be simply reported to Service Quality Management process
for incorporation into ongoing Customer and service quality monitoring and
management.
5. Where infrastructure changes were required to resolve the Customer's problem,
the results of the changes as well as the time taken and all other infrastructure
and operational parameters are reported to the Network Data Management
process for normal reporting and tracking purposes."
For above reasons it is necessary to make new model for Itelco Service management.
My approach combines two dimensions, one is "life-cycle dimension"
and "perspective view" is another.
1. life-cycle of services
2. In "perspective" means the same as in Balanced
Scorecard Approach.
As result we have two-dimensional picture:
Below presented Itelco Reference Model. Some process described but some in development and not presented in this model. It is clear that only Draft 0.
Contact: