Vodafone's BPM project shows why automation is a problem when selling to enterprise

Derek du Preez Profile picture for user ddpreez June 8, 2015
Vodafone Germany is building a new BPM layer for its enterprise case management. But because of the complexity of enterprise sales, it's likely full integration and automation will never happen.

vodafone logo
Vodafone Germany is going through a transformation, where it is trying to differentiate and become more efficient in selling to enterprise customers. As one of the world's largest telecoms providers, it believes that its options for growth in the consumer market are limited and there are plenty more opportunities in the enterprise space.

And whilst a sim card is a sim card whether you are selling it to a consumer or an enterprise, the scale and expectations of the two customers are worlds apart. Enterprises expect special attention for the premium that they're paying for the service. And nothing is standardised.

Vodafone Germany's head of enterprise BPM, Jens Fudickar is working to build a new end-to-end overlay for the company's enterprise customer enabled business, in an attempt to make Vodafone better at enterprise sales and CRM. Speaking at Pegasysems' annual user conference in Orlando this week, Fudickar explained the complexities of the project and how Vodafone is doing its best to introduce a new enterprise business process layer on top of its legacy systems. However, this is proving to be easier said than done. He explains:

The initial situation is common for most companies, everything is legacy dominated, which for enterprise businesses is a hard thing. The problem is that we have consumer based processes, but enterprise expectations, which are different. We also have multiple and siloed systems, without automated interactions.

We are introducing a layer on top which allows us to support end to end processes – in the beginning it will be in a generic way. By enablement of the business process management we have the ability to find out the critical processes that we need to improve. The ongoing steps are decomposition, enhancing the process overlay and separating some of the core functions from legacy and bringing them into the BPM layer. If they are only for enterprise [customers] we will put them into the enterprise layer.

The benefits for us are that we have the possibility to react to urgent needs. We have a layer on top that doesn't take as much time, we limit the risk and by decoupling some of the functions, we have the possibility that when the specs below are changing, we can react much faster.

However, whilst the project has been a success, and has even gone on to win analyst awards, Fudickar still believes that full automation of the business processes and seamless integration with the legacy systems will never be 100% complete. And this is largely because of the complexity and variation behind selling to enterprise customers, where everybody wants to be treated differently. But more on that later.

The project

Vodafone Germany began working with Pega in 2011, making it its platform of choice for introducing this new business process layer. And the project has three distinct phases:

  • eTop – This was the first phase of the project that began four years ago and is essentially a technical fulfilment system for non-automated, fixed enterprise orders. Fudickar describes it as the “bridge between CRM and the network”. He added that because there are so many different products in Vodafone's enterprise division, there was no real benefit to automate all of them. The eTop phase includes project planning capabilities, including skill based routing and load dispatching. Fudickar said:

There are so often manual decisions to make that it's more effective to build a system that supports the user and what he or she has to do, not automate everything on it. The most important thing is that it's catalogue driven, so we built a catalogue to define how a product will be fulfilled.

It's a mixture of manual and automation steps, we do have integrations where it is necessary, but we have a lot of stuff that's done manually.

  • BPA – Two years later Fudickar and his team began building the BPA system, which was Vodafone
    Germany's first approach to end-to-end case management to handle all type of customer requests in the enterprise area. This includes everything from orders, to complaints, to questions. He said:

It's also catalogue driven, but we have given the business the possibility to define new request types. It is the first system in Vodafone in enterprise which is really converged, we can now handle mobile and fixed in one system. Sounds simple, but if you are migrating different companies into one, it was not so easy. The focus was also more on the process execution than on the automation.

  • Digital Order – The third and final phase, which began at the end of last year and aims to be rolled out this summer, intends to be a guided order capture process that can create a clean digital order. Fudickar said:

This sounds simple, but in enterprise you have so many variations of possibilities. For example, if you have a big company that has a contract to buy mobile devices in combination with mobile contracts – which device is allowed with which contract? To put all this into forms is not so easy. So we introduced again a product catalogue that helps us to make the definition of new products and new rules a lot faster. Business can build for themselves.


The Big T

Fudickar said that for the project he faced a challenge in that the business wanted to quickly see an end-to-end customer request management system to handle all types of requests, using a system that has nicely defined processes for each request, all of which should be automated and integrated with legacy systems. Easy, right?

Fudickar added, however, that he faced the classic IT challenge of a huge scope, a lot of pressure from the business, and not much money. In an attempt to overcome this, he developed a transition method that he calls The Big T (the pictures below should illustrate the meaning behind this).

Fudickar explained that each broadening of the 'T' – essentially an illustration for the business process layer being wrapped around all the traditional approaches – meant that he could gradually increase automation and integration with legacy systems. He said that the first step – or the first layer of the T – was about collecting data in the layer, but not about integrating with legacy.

little T

We start with a simple layer on top and try to drill down only when it is useful and really needed. And this simple layer is a generic layer, which allows us to handle all request types, but only in a generic way. It was important that we focused on all request types, not on the automation. The better word for this project would be Business Process Execution and then continue later on to the automation. In the first phase we concentrated only on the status aggregation to get the visibility.

The people had to do the work twice: the work in BPA where they get the order and they know what they have to do, then into legacy systems to do their work, then go back into BPA to say they have done it. Then go onto the next step. But with this system we have the visibility of all the cases in one place, which was an important step for us. But with no integration. The result was duplicated work, it was more work.

The second layer of the T, was about focusing on the difficult and important processes that needed some integration with legacy.

mid T

With the next step we enhanced the horizontal bar by implementing specific processes where we really needed them. We looked for the important processes, which could be based on pain, on numbers, on duration, whatever you think are important, we will pick up these processes and do the specific specifications of this process – maybe only for two or three steps.

On the other hand we look for single assignments and go in for some vertical, maybe introducing some additional interfaces into legacy, step by step. Only the important assignments. The benefit of the business process platform that we have established before, is that it helps us to establish the critical steps that are executed quite often and are taking a lot of time. Then we try to drill down for them.

And the final layer of the Big T is about taking that integration deeper where necessary. However, as Fudickar points out, it is unlikely that the T will ever be complete – because of the nature of selling to the enterprise.

Large T

The final step will be that most of the cases will have specific processes and we will have much deeper integration into legacy, partly replacing the legacy function. But the important thing is, in my view, that we will never reach full automation.

For enterprise, if I've only got a product that is sold with a certain variation twice a year, it does not make sense to fully automate this product. Or if I have a decision that is really complex, it may cost me weeks to get the definition and to get all the test procedures defined. Why not make it easy with two simple exits that can be automated, everything else send it to the best interface that we have. If you try to automate all the stuff it takes too long. But start small, grow later.

Outcomes and learnings

The project, over the course of the past four years, has delivered some real benefits for Vodafone Germany. For example, Fudickar said that the use of the new business process automation layer has meant that there has been a significant reduction in fulfilment time – he estimates that the time to fulfil orders has been reduced by as much as 30-40%.

In addition, he added, that whilst the project has been quite costly, because of the reductions in fulfilment times, it has also saved the business a significant amount of money (see graph in picture below). Not only this, but there have also been some soft benefits, which include better visibility into the status of orders, an increase in customer satisfaction and a quicker time to market.

Businessman magnifying glass Individual customer service and CRM concept © Jakub Jirsák - Fotolia.com
However, there have also been some lessons learned. The most important one being that Fudickar believes it is critical to the success of this type of project that the business is involved from the outset, as it is the business that will define the rules of the process. He said:

If you're talking about BPM, the first character is Business. It is really important if you are talking about BPM projects that you are talking about business projects. BPM projects will always have a big influence on how business is working.

The business will realise that when they execute this process for the first time, even though they've written it down, none of the users are working in this way. In Vodafone Germany we have 9 regions and if I asked them all how they do a certain process, I will get a minimum of 10 different processes.

If I then ask the users, I'd get more. And everyone has the right process. But when you introduce the BPM software, they don't have the flexibility, they have to follow the process you put into the software. So the business is really important in this project, it's a business project, not an IT project. Business needs to be integrated into the project from the earliest date and for the full runtime of the project.

A grey colored placeholder image