Jill Edmundson

My name is Jill Edmundson, and I am thrilled to be here to share with you our story of our service request transformation. The backdrop of our story today is to walk you guys through what was a very chaotic system to something that is now a lot more clear.

Before we get started, let me tell you a little bit about who we are. As Scott and Erica told you yesterday during their opening remarks, we are CSG. Does that mean anything to anybody?

Okay. Well then, let me tell you what that means. We are an industry-leading, innovative, configurable BSS solution provider. We work with the likes of Disney and Amazon, the people that we have the privilege of following here today, to solve their most complex revenue management, content monetization, CCM, and managed service challenges.

We've got about 3,300 employees around the world. We are global, and we've been doing this, and we've been doing it better than anybody else, for over 35 years.

Take a look at all these beautiful logos we have up here. We work with over 500 service providers across the world. As Scott told you yesterday, we have six billion transactions processing on our systems every single month, supporting over 61 million subscribers across the universe. 150,000 call center seats operate our software, running about 50 applications across 20 technology stacks for 1,000 practitioners.

So now you know where we came from. I'm Jill. I'm one of the Jills. My name is Jill Edmundson, and I work for CSG's Product Management department. In my role, I'm responsible for working with my business partners and my DevOps partners to craft the vision and execute and deliver value to all of those customers and subscribers I just told you about.

Jill Musil

And I'm the other Jill. I'm Jill Musil. I lead the corporate IT teams at CSG, and I am the service owner for all of the internal business systems, as well as the endpoints that our employees use to do their daily jobs.

I've been with the company for about 19 years, and this is the first time that Jill and I have had the opportunity to work on an enterprise program together. So we were leading teams that basically pulled this effort forward, and we worked with a wealth of other departments to get this job done over the course of the last 18 months.

Jill Edmundson

But we were not alone. I, being part of product management, and Jill being part of corporate IT, knew that we were going to have to go wide to make this journey that I'm about to tell you about successful.

So with the partners that you see reflected here, this went across the entire organization: accounting, our service desk partners, shared services, platform, DevOps, client business units, and our agile training. They were all critical to our story.

So let me tell you a little bit about the story we're about to tell you. Jill and I took on the transformation, but it was important that as we built this out, we partnered with the business to take on the solution.

Today we're going to tell you the problem we set out to solve, the solution we built, the DevOps methods we employed. It wouldn't be a journey if there weren't a few bumps along the way, so we'll share those with you and tell you the practices that we adopted to overcome those challenges, the future of where we're going, and then most importantly, the so-what moment, the value we delivered.

So I know CSG might be fairly new to you, but how many of you here own a car, take it in for an oil change every so often? Yeah? Yeah? Okay, I don't, but my husband does, and so I'm pretty sure this story I'm about to tell you is applicable.

Imagine driving your car into your local service shop. You're greeted, nice cup of coffee. Someone comes up to you and says, "What would you like today?" You say, "I'll take an oil change, please." They say, "Great. Fill out this form real quick for me." It's on an iPad. It looks slick.

Well, that was slick.

Next guy comes up to you. "Hi, ma'am. Welcome to the station. What can I do for you?"

"Well, I'm here to get an oil change."

"Well, I don't use the same form as the oil change guy, so could you fill out another form? Because I'm the wiper fluid guy."

Oh, seems a little inefficient, but okay, I'm down. iPad, sweet.

Uh-oh, here comes Bob. He's the tire rotation guy. Bob comes up to me and says, "Hi, welcome." It's a Groundhog Day moment. I say, "Bob, I've already met with Jim and Steve. Did you need me to fill out another form?"

"Why, yes, I do, because we're not fully integrated yet. So could you just quickly fill out the tire rotation form?"

Okay, I'm seeing a pattern here. The detailing guy, and so on. Who can agree that that customer experience would leave a bit to be desired?

Yeah. Yes. My friends at Amazon would think that that was a ridiculous fulfillment process.

So the problem we tackled is very similar, but it's for the world's largest communication service providers. Our customers would call us because they would need services. A service to CSG is any service that our customers can't perform themselves. Maybe they need data management services. Maybe they need consulting services, batch support services. They call us, and we deliver the value.

A very smart customer-facing individual at CSG typically answers that phone call, grabs that email, or maybe on a ticketing system, and then starts to navigate in an incredibly complex sea of service request management fulfillment. The person in the middle of this example is where me and my team sat for about 15 years.

Imagine being the new guy at CSG trying to figure out how to deliver that value as quickly as possible when the first person you need to engage uses a generic processing request form. Maybe they're from our DevOps partners. The next person uses a custom form that they built on SharePoint Services, intranet forms, maybe it's a ticketing application, emails, so on and so forth.

What this doesn't account for is also the drive-bys and the water cooler conversations. All of those are independent service intake processes that we looked to solve by introducing something that Gene is passionate about and that Scott is passionate about: the concept of a single pane of glass, a one-stop shop for all service request management to flow through. And while building the single pane of glass, we're going to torch all the other ones and deprecate them.

Jill Musil

So the story starts 18 months ago. Looks pretty grim if you look at the slide. I'd like to cue the tumbleweed if we could at this point. Just kidding.

So like many organizations, we had centralized technology for our intake platform. If you needed an enhancement to that system, you basically got in a line, and a work queue was long, and you waited. And while you were waiting, because we're a technology company, we have development resources, they'd build their own solutions.

So we start adding on technologies that are all doing like functions, and you start to get this sprawl. So again, long queues and lead time. We had limited visibility of the work that was coming in and then the work that was ultimately feeding into our teams. And quite frankly, the technology was developed in the mid- to late 1990s, and it was time for a change.

So we basically had a point where we were going to make some changes to that technology using some third-party packages, and actually started progressing on that roadmap when teams came together and said, "Hey, are we making the right choice for the future?"

So that crossroads was there. Do we abandon that path that we were on, ignore the sunk costs, and take steps towards leapfrogging into a transformative initiative for the future?

Jill Edmundson

So there we are. We're at the crossroads. Do we turn left and continue to invest in the old, or do we turn right and embrace the DevOps practices?

We turned right. We turned right for a few reasons. First, we knew that self-service and empowering our people was critical to our future. It would eliminate the backlog, it would eliminate the queue times, and it would allow our people to become more innovative and less dependent upon others.

We would increase the visibility of work. Without the ability to view the work, how can one measure and manage it?

And we knew that although software is amazing, software can't solve all problems. But we wanted to use the tools that we were creating to reinforce all of the desired behaviors we're learning about here at this conference and enable those DevOps practices.

So, the problem.

Jill Musil

Yeah. So let's talk about the scope of the problem.

We were processing 20,000 business service requests on an annual basis. Those initial business service requests fed into hundreds of thousands of technical service requests. And there's a big question mark next to those numbers because, quite frankly, we didn't have the systems in place to really, truly measure those counts.

We'd pull data out of systems, the ones that we were aware of, and we'd create spreadsheets and pivot points and basically try to come up with this quantifiable number. But it was kind of the startle factor that our leadership needed to say, "Hey, we need to do something about this."

So we talked about all the disparate legacy intake platforms. We think there's probably 10 to 15 of them, but to Jill's comments before, there's email and drive-by and all sorts of things that kind of feed these pipelines informally, and we knew we needed to minimize those as well.

And the other startling thing was 95% of our workforce was impacted by this process.

So what are we going to do about it? Our program team was set out with a charter to basically reduce those legacy service request management platforms. We needed to establish an enterprise service catalog. We needed to reduce the work in progress for our teams, all at the same time increasing the visibility and improving the overall time to value for our customers.

Jill Edmundson

So here's what we built. If you're from CSG, I hope this is not your first time seeing this. But this is called ASAP. It's a little tongue-in-cheek because, like Amazon has taught us, if there's a mindset that's starting to permeate the world, it's that everybody wants everything now, two hours or less. So we named it ASAP. It's a Service Accelerated Platform.

And what you see here is a pretty slick front end, especially if you could've seen the contrast of what we deprecated. And this single pane of glass, what it's showing you is that it's five independent service catalogs representing five components of our business, our BCNS, carrier, OTT, platform, and then all of the internal service requests we manage for our internal employees.

These five catalogs represent over 200 unique intake forms crossing 15 value streams. And that might not seem like a big deal, but bringing all of that work into one platform would only have been possible if we had a single focus from a dedicated transformation team.

Jill Musil

So you're probably asking yourself, well, how did we do this, right?

So 18 months ago, and all this time that has passed, there's nothing startling on these slides, right? Every session that you go to at DOES talks about continuous development, continuous deployment, continuous improvement, enabling and empowering teams.

But let's just talk about the basics that our teams employed. From a continuous development and deployment perspective, we used friendlies. We went to teams that were already using agile practices and DevOps concepts, and we said, "Hey, will you help us get started?"

They started the process for their existing forms, and quite frankly, they wanted to start putting new things in there as well. So we were growing by the fact that they loved what they were seeing.

We also strangled off that legacy technology a little bit at a time, and when we realized the value through a development effort, we went ahead and deployed it right away. So gradually, the use of those legacy systems started to deprecate.

Our continuous learning and improvement environment, we didn't want the teams to be afraid of failing. So we may make mistakes along the way, but we have the safety net of the legacy system to get us by. We're going to start simple. We'll grow from there to the more complex forms.

And again, we as a leadership team showed them that, hey, you might make decisions along the way that aren't exactly right. So we were on a path with one technology, and we decided to come back. So addressing sunk costs and moving forward very quickly.

One of the more powerful things that we did in our initiative was we enabled and empowered other parts of the organization to help us with our backlog. So we developed this concept of self-service. We gave those development resources that basically worked around us before, we gave them guidelines and guardrails to basically do their own development if they wanted to.

And what we found happened was they established a community of practice, and they're sharing their learnings now. They meet regularly. I think of the forms that have been converted to this new platform, I'd say 20 to 25 of them were actually developed by resources outside of the IT organization, and that community of practice is also growing every day. So we're hopeful that as we move forward, those resources will help us continue to bring that backlog down.

The other thing that was certainly the most important part of this was the people, the people that we engaged. We call them the team of teams because it was a team different than we had looked at it before. Within our departments, we maybe had a PM, a business analyst, and folks working on it. But this, we sought folks from all the different parts of our organization that could contribute and help us add value.

There's five folks on this slide that are sitting amongst you today. So Andrea Urban in the front row is our product owner. Scott, who could ask for a better executive sponsor through this journey? Deb Engel, Jeremy Day, Mark Fuller. These folks were our leaders, and while their titles may not say director or manager, these were the people that moved us forward.

They helped us mobilize the teams. They saw the vision from day one, and they made sure that we stayed true to that vision. So they led, they evangelized, and they ultimately executed, and we would not be where we are in our journey if it weren't for those individuals.

Jill Edmundson

So it's all sunny day, right? Every project has a sunny-day outcome. No, I would not be honest if I told you that our journey was not without its fair share of bumps along the way. So I picked a few of them here today in the interest of time, some of my favorite ones, and then I want to tell you how we overcame those with that team of leaders.

One of the things that I've heard in every session I've attended over the last two days is change is hard. That's nothing new. We've all heard it. But as Jill said, the technology and the thought around service request management had existed in effectively the same way since the late '90s at CSG.

So for this small group of people to come in and start to challenge the status quo and get people to see that we could do this better, faster, cheaper if we just started thinking in a different way, that was significant. It took a lot of passion. It took a lot of vision. It took a lot of cross-team alignment, and there was some organizational politics.

When we decided to invest in a single pane of glass, obviously, there's rarely a circumstance in most corporate cultures where everybody is aligned to that common vision. So this team needed to learn how to work sensitively and tactfully around the organizational politics and just continue to be resolved on our charter statement.

So as Jill said, we knew we couldn't scale out of the gate, so we found the most innovative and sympathetic groups we could find in the CSG. If someone gave me five minutes at their cube to talk, I took 10, and I painted the picture, and I said, "Please be an early adopter. Help me evangelize this through your organization."

And it worked. The grassroots helped us build that critical mass, and then before you know it, I'm walking down the hallway and, "There's the service request girl. What is she doing? I heard she's building something behind the scenes. It's going to change my email intake process."

But through that critical mass and that silent majority, we were then able to more independently identify who those holdouts were and then overcome the skepticism.

The next bump we encountered was tool blindness. Like I said, I love software. We're all technologists here, but I knew that there wasn't a tool that could solve all the problems that we were trying to do within CSG. Most notably, there was a pretty significant disconnect between our service request intake and fulfillment process, and then ultimately our change management and deployment process.

Absent a piece of really effective integration, I was just introducing yet another swivel-chair application that was going to create more WIP for my service practitioners and my DevOps partners. We knew we needed to create an integration point to further enable that single-pane-of-glass mentality.

So that required a lot of really complicated workflow process engineering sessions, streamlining those efforts, and really gaining an empathy. Each group had their own way of doing things, and my job was not to come and disrupt that model. My job was to come and try to create value for the business and make common-sense changes where we could.

So what we did was this tool became very agile. Through the self-service techniques that Jill was talking about, we took ourselves out of the equation, opened up the code, if you will, the application, for them to build their own forms and to map their own workflow. Getting the governance established, but empowering our people to do what they needed to do.

And the big value we delivered was we solved the problem with the change management and the service management integration. When we delivered that, we knew the rest of the business would fall in place.

And finally, although this was near and dear to my heart, and very near and dear to Jill's heart, this was by no means CSG's only initiative. I think at the time we took this on, I also managed the enterprise portfolio catalog. I think we had 143 unique enterprise epics, and this was one.

I always like to say, "I think my baby's the cutest," and so I was always there showing the pictures of my SRM baby, but it was competing for priority across the enterprise. And so we needed to continue to believe in our message. We needed to continue to remember that we were driving value, and we didn't have a lot of time to waste.

If we couldn't deliver this solution in 12 to 18 months, we knew that CSG would be off to the next thing. So we remained steadfast in that charter to deliver the value and make the work visible.

Jill Musil

So back to the program goals, right? We set out to reduce those legacy platforms, establish the service catalog, reduce the WIP, increase the visibility and time to value.

So let's talk about the value that we've seen. Since we deployed nearly 18 weeks ago, we've seen 13,104 service requests come through our system. There's been over 35,000 site visits, and we have 450 services cataloged.

Now, that number to me is striking because when we set out on this journey, we thought we had 165 services. So look at that number and how it's grown. But the more important thing here is that we've increased the visibility of the work into that single location, and now we have that one pane of glass that we desired from the outset.

So we made the work visible. With this initiative, and I talked at the beginning about the numbers that we pulled and how they were haphazardly pulled together because we didn't have sources of record that were reliable, our metrics were integral to this effort from day one.

We knew that we needed them because we were going to need to have our teams optimized for their individual organizational productivity. We wanted to make sure that we could go forward and focus on optimization of those services with automation for where we have too many processes that have human touch. We wanted to be able to identify that as a part of this process.

The self-service we've spent a lot of time talking about. The other thing is, let's look at those services and how many of them are we performing. If there are services that are only executed, are they things that we could eliminate, the low-value work?

I'm hopeful that a year from now we'll be able to present from CSG's angle some of those automation efforts that are now underway and being led by Mark Fuller in an organization that's just coming to life at CSG.

Jill Edmundson

So, being in the service industry, obviously you evaluate a couple of metrics. What do you do? How do you do it? And what are your cost margins?

One of the use cases that I wanted to highlight with you today is now that we had the services effectively cataloged, we could really see where our outliers were. For this particular example, I won't go into the nitty-gritty of what it is, but we were doing upwards of 800 of these service types every month, making no money, and really delaying the time to value for our customer.

Now that we had this view of the world, we knew that this was a prime candidate for service automation. We knew that if CSG could find a way to enable our customers to perform this service independent of us, we could reduce our WIP and get out of this model.

And in just 18 weeks, as we said with Jill's previous stat, we have seen over a 75% WIP reduction in that one use case. And as we said, hopefully a year from now, we are scaling and looking at even more examples of those automation opportunities.

Jill Musil

So this slide shows our launch happened on June 5th. Within two weeks, we saw our ASAP usage surpass that legacy application usage. So we're well on our way to completely deprecating the legacy platform and in lieu of using the new platform.

Jill Edmundson

How many forms left?

Jill Musil

Ten.

Jill Edmundson

Ten?

Jill Musil

I think there's 10 forms left.

Jill Edmundson

Eight or 10 left. So we're excited to be coming to end on that job.

So what's next? Well, now that we have the view of the world, now that we know all of this data's at our fingertips, we can now use these metrics to help increase productivity, eliminate waste, and really, truly focus on enhancing our customer's experience.

Secondly, no pressure, Mark, but service optimization. We want to scale this program bigger, broader, faster than we have now that we have the nucleus of our foundation.

And finally, customer self-service. The tool that we built was primarily designed for our internal customers, inter-business requests. Now we want to bring this to our external customers: Comcast, Charter, Time Warner. All of those slides that you saw earlier. We know that we have a value proposition to deliver to them, and that they can then impart upon their clients.

So before we turn that corner, did we mention that communication is everything? We thought this was pretty cool, but we needed to get the entire business rallied around our vision, and we knew that key to our strategy was developing an effective communication system.

So every single month, even more frequently sometimes, we developed these microlearnings. We called them the ASAP minutes, knowing that you guys have flooded inboxes, and you get about a minute's worth of time. We drove the value statement to every single one of our employees every single month.

What is ASAP? What is the value that it delivers? Why is this important to you? How will your jobs be impacted? Every single month, we were taking different use cases, different anecdotal evidence, different metrics, and getting it in front of the people.

If you turned the corner walking down the hall, you saw it on digital signage. If you came to your desk on the day of the launch, I think there was a, I don't know, a postcard sitting on your desk. We had a huge launch party.

Another big part of what I love about the DevOps transformation is that you celebrate shared successes. And so Jill and I—

Jill Musil

If you have food, they will come.

Jill Edmundson

If you have food and some happy-hour cocktails, they will come.

Jill Musil

Yeah.

Jill Edmundson

So we did it. On arguably the windiest day in Omaha this past June, we brought the entire campus outside and we celebrated. We knew that what we had delivered was something transformational, and it was setting us up for success in the future.

So this is the team that made it happen, and I couldn't be more excited to share the stage with them.

But here we are. We need your help today. We're getting ready to turn that corner. We've delivered something pretty powerful to our business, but now we want to deliver it to our customers. So we're hoping that in the following two days, throughout these breakout sessions, we can have a chance to engage with you, and you can help us understand what does that new customer experience look like? Does it differ significantly from what we created for our internal customers?

We would love to learn from you.

Jill Musil

And by nature of the fact that you're sitting in this room, there was something that intrigued you about the topic that was being discussed. So we're here to help you as well.

So if you have a similar business problem and you're not sure how to get started, or you're interested in the technologies that we used to launch this effort, let's connect. Our contact information is here, but we're happy to also have some informal conversation here at the conference over the next couple of days.

And thank you—

Jill Edmundson

Thank you.

Jill Musil

Very much for your time.

Jill Edmundson

Thank you.