eTOM (The Enhanced Telecom
Operations Map) is a set of process blocks with 3 levels of depth. Just like
any good model or framework, the process blocks ensure completeness, and can be
used as guidance when planning to start Greenfield operations or reviewing the existing
building blocks of your operator organization. Actually, if you start mapping your
operator organization’s building blocks to eTOM, you would have covered all the
process blocks of eTOM in some way. When organizations start, they hire experts
who have done things in the past and know in good detail what needs to be done at
management or function levels, they use existing knowledge to enable quick go
to markets. At some point in future, organizations go back to eTOM as a checklist
to verify and confirm that they are doing all the necessary things, and they
find invariably that they are, in some way, because eTOM is sufficiently generic,
as would be any standard that is agreed by operators of different types and
sizes.
eTOM does not go into details of
processes, or process flows. It provides details that can be considered as Level
1,2 and 3. Process flow details, which are typically at Levels 4 and 5 and
sometimes 6 as well, are not as generic, and hence eTOM has chosen not to
define these. Some multinational operators, however, have defined these levels
for themselves, as guidance for their various operating companies (opcos).
I have been a part of more than
one new operator launch, and have not seen processes play a central role at any
of the launches, nor have I seen them make much headroom at traditional
operators. When business users at a telecom operator provide requirements to
their technology counterparts, designs are created, process consultants are
hired to create processes based on those designs. Purpose of these processes is
to limited to providing trainings, and as documentation to track how business
processes work in the organization. Their utility is limited, and they are
rarely updated to align with the on ground realities.
Business stakeholders, however,
are logically more comfortable with process flows. A process flow show end to
end functionality, and if requirements could be captured as process flows,
rather than as requirements document, requirements can be a lot more contextual
and easy to understand. It may however, to very difficult to create process
flows from scratch before design is finalized. A possible option here is use some
industry best practice processes as baseline, something which I mentioned above
that some multinational operators are doing. Requirements capture on top of
standard processes may involve removing non relevant steps, adding steps and business
rules as per local market needs. This approach makes business processes the
center point of the requirement capture, design and development, testing and
traceability. Testing, which happens based on requirements traceability would
then happen based on business process traceability. While there are advantages
in moving away from requirements led approach to a business process led
approach, however, there are challenges as well. Creation of standard processes
is one of them, while some organizations are creating standard processes, most organizations
do not have such information. Also, the processes created till date are, by no
means, complete, as gaps exist specially with respect to non customer facing
processes. The other challenge is managing the change, as it is easy to write
off the approach in the first few days. It requires commitment from the
management and all stakeholders to make this work.
The process led approach does
provide an innovative and alternative option and there are benefits to
operators and to system integrators as well. Standard processes are typically
aligned to out of box solutions provided by major platform vendors. Staring with
standard processes anchors the degree of customization requirements towards the
lower end, ultimately speeding up delivery and go to market. On the flip side, it
does inhibit innovation to some extent, stressing on standard out of box modus
operandi. From a competitive advantage standpoint in the market, operators will
always try to distinguish themselves and will have the need for complex
customizations, and the approach to me may inhibit that at some level, but when
it comes to building the basic blocks of your operator organization, it does provides
a quicker go to market option.
Note: The process led approach
does consider that there will be requirements that cannot be captured as processes,
and hence, non functional requirements have to be captured in parallel as well.
There are other advantages to Technology
System Integrators in this approach, I will write about them in a subsequent
post or you can send me an email
