Oleksandr - Fotolia

T-Mobile succeeds the second time with SAP Fieldglass implementation

T-Mobile's first implementation of the SAP Fieldglass vendor management system for its contingent labor force didn't work, so it started over and reaped much better results.

If at first you don't succeed, try, try again. This adage is usually delivered to Little Leaguers, but it also worked well for a very large corporation in its implementation of the SAP Fieldglass vendor management system.

T-Mobile had implemented the SAP Fieldglass vendor management system (VMS) to manage its contingent labor force, but early returns on the system were not positive. The system was rife with bad data, and user adoption was less than enthusiastic. When faced with projects that go off the rails, some organizations plow ahead and make do with fixes, or they continue to force feed the lemon on reluctant users. T-Mobile, on the other hand, decided it had seen enough, so it scrapped the system as it was and reimplemented it from scratch.

Having learned from the mistakes of the first implementation, T-Mobile says the new SAP Fieldglass system is off to a much better start, with more complete buy-in and good results in helping the company manage its large contingent labor force.

Cohesive contingent labor management system lacking

Before SAP Fieldglass, T-Mobile's contingent labor management was an uncoordinated mess, according to Amber Glishke, T-Mobile's senior systems analyst of procurement systems solutions technology.

"We had a combination of manual and system-based processes that were distributed across our entire enterprise, so there wasn't a baseline for one-stop governance," Glishke said. "IT did their stuff one way, engineering did it another, and this made it difficult to track the contingent labor for any transaction from start to finish, because we had so many tools supporting all that contract labor."

The lack of a cohesive system made it a severe challenge to collect data from the various groups that required contingent workers, and to negotiate deals with suppliers. It was also very difficult for finance to track how much was spent on what, and there was no way to know if they were paying the actual negotiated rates, or if the suppliers were meeting performance metrics.

However, the biggest obstacle to coherence was that T-Mobile was using different methods to manage contingent labor for the engineering group and the IT group. The engineering group used managed service provider (MSP) TAPFIN, which used a VMS tool, while the IT group used a direct model of contracting with contingent labor suppliers.

This was not a small issue, Glishke explained, because T-Mobile, at the time, had around 3,000 contingent workers. About 40% of these were in the MSP system and were managed with its tool, but 80% of the IT contingent labor was managed directly, and was not in a VMS tool. This led to quite a bit of inefficiency and redundancy in managing the contingent labor.

T-Mobile knew it needed to get all the contingent labor workers together under one tool and, after conducting research, decided to implement SAP Fieldglass. T-Mobile was already an SAP shop, and it was also implementing SAP Ariba for procurement, so going with SAP Fieldglass made sense.

Aggressive time frame leads to trouble

The implementation process began in spring 2014 with reasonable objectives, but an aggressive time frame, Glishke said. The initial plan was to only take the contingent workers that were in the MSP system and put them in the SAP Fieldglass system because there was already a good process and solid governance in place. At one point, however, it was decided to add the unstructured process from the IT side into the system.

"We ended up mashing that piece in a little earlier than we had planned," Glishke said. "That made it a little tough because a lot of [our] initial requirements were totally driven off of our MSP replacement, so there wasn't a lot of time spent digging into that direct spend where we weren't using a tool. All of that was on what we call a 'bucket P.O.,' [purchase order] where we had four or five suppliers who got a huge bucket P.O. for a set monthly time frame, and then a manager could just call and get someone and they would book it against that P.O."

Bad data and poor adoption

The SAP Fieldglass system went live in April 2015, about a year after the implementation was started, and the immediate reviews were not good. Because the unstructured hiring process had been pushed into Fieldglass earlier than was planned, there was not enough time to gather all the requirements on the direct side, and user experience suffered, particularly for IT managers who had to go through a convoluted process to procure contingent workers, a process that had been fairly simple before.

"We had basically set up all the configuration to be one way, and then, in order to support the direct side, we needed to reconfigure things," Glishke explained. "Some of those decisions that were made in the time frame of that reconfiguring to go live weren't thought out as well as they should have been. Change management was huge because managers were used to being able to call Bob at their favorite supplier, and they had to abide by the rate cards, but other than that, they didn't have to bid against one another, so that change management piece was a lot larger than was expected, and getting that user adoption was really difficult."

Poor data quality was the other main issue with the first rollout. Much of the data was moved over from the MSP tool and was not good, according to Glishke.

"This drove a lot of data issues because that was managed in a tool that didn't have great governance -- it didn't have any dropdowns and it was all free type for most of the fields -- so that data was kind of crap " she said. "We went through that scrub beforehand, and you scrub as much as you can, but it's a moving target, and once we put that data in the SAP Fieldglass tool, we found that there were a lot of issues there."

SAP Fieldglass, take 2

Faced with a new system that was plagued with bad data and little user adoption, T-Mobile decided to scrap the first implementation and start again. There was value in going through the first implementation, however. It forced T-Mobile to examine all of its processes around contingent labor, from security, to procurement, to compliance, and to make sure that data was accurate before moving it into the second implementation.

"We decided that our best route to get to our end goal was to reimplement. So we went into a new instance of Fieldglass and spent the time scrubbing that data before moving it into the new instance," Glishke said. "Our goal was to get people into the tool and make sure the data was really accurate -- was that the rate we were actually supposed to be paying, was that the right time frame for the worker, do we have all of the workers in that were supposed to be in -- we started to find that we had pockets of workers that weren't actually transitioned over, so we did the reimplementation and focused on data and user experience."

Cloud advantage, quick reimplementation

One of the advantages of a cloud-based system like SAP Fieldglass is that scrapping it when it's not working and starting over again is not a major technical undertaking, and T-Mobile's reimplementation was completed in just 60 days. It was important, however, to have participation from all the business groups, but to have just one project owner.

"We had HR at the table, security, our MSP, some of our business owners, and all those people report up through separate structures. So having one person that owns the whole entire project on the business side, not just the IT side, was vital," Glishke said. "We had that on the IT side, but then we had a lot of chiefs in the room from all the other groups, so that's the thing that we did differently in our second implementation."

The relaunched SAP Fieldglass VMS is going much better the second time around, although it's still a work in progress. "We are in a constant state of continuous improvement for Fieldglass, so we are constantly moving, adjusting and enhancing, cleaning it up and making it work for what we need," Glishke said. "You get one goal done and you find five other things that aren't working in your business. Doing that continuous improvement ... would be another step of it."

One of the major pieces that was added was statement of work labor, a group that gets paid on a milestone basis for completed work and integration with SAP Ariba.

"Based on what I've seen, integrating Fieldglass and Ariba will absolutely make sense and, for our end goal, that's kind of why we went with Fieldglass," Glishke said. "However, we don't want to feed bad data into Fieldglass now that it's clean, so we want to make sure that we've got good data on the P2P [procure-to-pay] side established before we move toward that."

One tool for all, visibility and analytics impress

Although there was user resistance in going to the new tool, that is changing as the benefits of having a unified VMS become apparent. Financial processes are made much easier by having all hourly wage workers in one tool, and it has allowed visibility and added analytics to managing the contingent work force that was not there before.

"The visibility is fantastic. With the analytics that we're starting to get, we're giving them that opportunity to challenge cost, quality and delivery of our contingent labor, and that's going to drive our procurement business," Glishke said. "We're getting to a place now where the procurement team can pull those analytics and make good decisions for our business as far as where the spend should go and how it should look and [which] suppliers are supporting us in the way we expect them to."

Next Steps

Was the money SAP spent acquiring the Business Network pieces well spent?

SAP Ariba president Alex Atzberger on how the Ariba Network integrates with the SAP Business Network

How do workforce management software tools compare?

The on-demand economy will change employment dramatically

Dig Deeper on SAP HCM