eTOM and the process led approach

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