PegaWorld iNspire 2024: Brewing Excellence: Starbucks' COE Harnesses the Power of Process Automation to Fuel Business Transformation

In an era marked by rapidly evolving business needs and process complexities, Starbucks embarked on an outcome-focused process automation journey by establishing a Center of Excellence (COE). Watch this session to learn how Starbucks’ COE was formed with the vision to empower radical automation and enable business transformation across several enterprise functions globally.

Transcript:

- My name is Greg Delini. I'm the director of Enterprise Solutions and Enablement. Pronouns are he/him. I'm a 16 year Starbucks partner. You're gonna hear that word a lot. We call ourselves partners at Starbucks. You'll hear that throughout the presentation. And I lead the business-facing side of our digital process automation, COE. I'm gonna take you through our digital process automation journey. How we've gotten here to date, our center of excellence, and then I'm gonna share some learnings that we have. And then Ganesh is gonna talk about our current future capabilities. And then I'll leave you some time for Q&A. If I fall into my bad habits of talking really fast, it might leave you a lot of time for Q&A so I'll try to just leave you the right amount of time. But before I jump into our digital process automation journey, I did wanna talk a little bit about Starbucks. And probably most of you know who we are and the products we serve. So that's probably not new news to you. Last year, we did over 35 billion in revenue. We have over 38,000 stores globally in 86 markets. But what I really wanted to spend the time talking to you about today is our mission. I wanna ground you in our mission. So our mission is with every cup, with every conversation, with every community, we nurture the limitless possibilities of human connection. And what you know is absence from that is anything to do with the products we sell, the actual products we sell. And that's because we start with the human connection first and then we design the experiences and the services and the products from there. And that's how we approach the work in our support centers. And also how Ganesh and I approach the work in our digital process automation journey. So here's our journey, here's our history. And it was interesting putting this slide together because 2018 seems like a really long time ago. When you put on a slide, you're like, "Wow, we've been working on this this long." But yeah, the first 2018 was our period, we called it exploration. So we started with BPM, we signed our first agreement with Pega back in 2018. We loosely established our DPA COE, I would call it more of like a collection of like-minded individuals. We weren't necessarily formalized yet. And we launched our first BPM automation. In 2019, we spent a lot of time on our foundation. It's also the first year we started piloting RPA. So at this point now kind of a year into it, we had both RPA and BPM capabilities and our COE came to visit PegaWorld the same session in 2019. And we took learnings from sessions like these and then also meeting with like-minded companies to come back and create the successful COE and automation program that we have today. And then 2020 to 2021 was our period of adoption. So we began to evolve and expand. We did spent a lot of time on education outreach, had a lot more use cases, a lot of repeat users. And up until this point, or pretty significantly to this point, we'd really been working with primarily one or two business units that that were close that we knew that we were comfortable with. So example, as part of finance organization, we were very closely the finance organization. And then at this point, we really started evolving and going, we had more global remit and more global use cases. And then the last few years have been focused on expansion and maturity. So again, use cases continue to increase. We upgraded to Pega Infinity '23 and we had our first BPM to RPA integration. Okay, and you can see the results here. So recall back to the previous slide, 2020 was our period of adoption. So that's really when we started to see this impressive growth. We have now over 35 RPA use case. I think we're closer to 40 at this point. Over 15 BPM applications. And we've been seeing about a 2X annual growth rate over that time period in terms of savings. We capture those savings a little bit differently, whether it's RPA or BPM, I think, you know, RPA more of our save from manual processes. BPM can be a lot of different value. There's more value play there that we can have from different sources. And the really cool thing about these benefits is the number of applications or the use cases we've developed, they tend to be really sticky and stable. And so they continue to deliver value year after year after year. So I think five years down the line, they're still delivering value for that initial upfront investment. And that's great for our business users, so they love that. It's also really good for us, COE and our cost structure because the number, as the number of use cases increases, we've been able to get our cost per use case down. So it's been really great for us. Well. Yeah. So the question was, "Is this dollars or use cases?" These are the dollars. So these are the actual savings from them. Okay, I did wanna spend the next couple slides go into a lot of detail in terms of our COE and our learnings. And again, these are things that we've built over time. We're very proud of our digital process automation COE at Starbucks. It's centralized partnership between our business teams and our technology. And if you look over to the right, that's our structure. So we have executive sponsorship at the business and technology level. We meet with them quarterly, they're highly engaged. If you need that, Ganesh and I lead and our managers lead small teams to two to three partners each. Very lean teams. And that is not uncommon at Starbucks. We tend to run very lean in our teams. To give you an example, some of the roles and responsibilities on the business side, think about, you know, outreach and education for our business users, intake management requirements, gathering, reporting. And on the technology side, technology owns the statement of work. They own the technology solutions, they own the sizing. And I wanna take a brief pause in our presentation because Ganesh and I are here representing Starbucks COE. But in reality, we have the true partners that do the heavy work and make the successful back at home. Unfortunately, weren't able to travel with us, but Ganesh and I would be nowhere without those partners. So I just wanna take the moment to thank you, all. If you're watching, I really appreciate it. Ganesh really appreciates it. We couldn't do the work without you. So thank you so much for everything you do every day. Thank you. Okay. And so because we're streamlined teams, we are supported by our outsource BPM and RPSIs. And then in the middle, we have Pega. So Pega's also been very helpful for us over the years, helping us do things like enablement sessions, teaching us about new functionality, architectural guidance, connecting us with like-minded companies, giving us some ideas for new use cases. So that's been helpful for us as well. And then a couple of things before I leave this slide. We have enterprise wide global domain. So for us, that means North America, EMEA, China, Asia Pacific. We support all of our functional owners and business units. So things like finance and supply chain. Also like our retail organizations. We've got broad remit. And then the last thing I'll hit on here is funding model approach. And not because this is the way to do it, but because we've connected with a lot of different companies, and this is sort of the question that comes up a lot. So just sharing. There is not a one-size-fits-all model or approach for this funding model. This is what works for Starbucks and so we thought we'd share. So for our, we talked about we have two main tools from Pega, RPA and BPM. So, so for RPA, we actually have central funding and prioritization and that allows us to be quicker and more efficient 'cause the use cases tend to be smaller and shorter duration. On the BPM side, because the use cases are larger and have more impact, we ask the business units to fund those themselves. And then from a COE perspective, we fund the platform and enhancements and upgrades. Keeping it healthy. Okay, again, these are some things we learned over the years. Again, some of it was back in 2019 when we came to sessions like this. Also connecting with a lot of different companies. We've brought back these learnings and this is what guides us every day. And we thought we'd share. And this list is not exhaustive, right? I'm sure there's plenty of things that you all could add to this list, but you also don't want me up here for 30 minutes. So we thought these were the things that were most important for you. So I would also say these fall into kind of two categories. Some were things success strategies that we had right outta the gate that worked well for us. Other things we learned the hard way or cautionary tales. So for us, the foundation of the COE has been critical and we spent a lot of time front developing that. So think about roles, responsibilities, mission, vision, the prioritization, the intake, the funding model. That investment upfront has allowed us to really go much quicker on the backend and be more efficient on the backend. The second thing, and I've talked about this quite a few times, is the tech and business partnership. So for us, that's also been a huge unlock. This united front between tech and business has allowed us to have better engagement, has allowed us to have better funding and also better outreach. So for us, we're a very tech first, tech forward company. So my tech partners in our domain are working with tech partners within other domains who are working with their business users. And then on the business side, I'm working with different views, business users, maybe sometimes the same business views with different ones. And so we've getting kind of almost doubled outreach, double expansion, so that's been really good for us. Sponsorship's been key. Clearly, they have unlocked some funding us with us. They've also helped guide us, especially in the initial years. They've also helped us with some untapped opportunities and you know, they have visibility, some things we don't necessarily have visibility to. And so they've been able to point us in the right direction. Process improvement and change management. So we actually don't have these skill sets directly in our COE, we talked about this being a very lean COE, but we have access to these capabilities right outside of our COE. So this ensures that we're never automating a bad process. Education and outreach. Okay, so this is another one that you've heard me talk about a lot and I would not expect this to be as important for everyone else, but this is really important for Starbucks. And the reason this is so important for us is we don't have a mandate or remit that people have to use their services. I'm part of the GBS organization at Starbucks. So a lot of times that would be, you know, process and automation first. Any new process that comes in, we're not quite there yet. So for us it is all of this grassroots, bottoms up, word of mouth, really working with our business users to ideate the art of the possible. And then once they understand the art of the possible, we get a ton of repeat use. So it really only just takes one time for someone to understand what that is and then they're coming back with multiple ideas. We have two Pega tools at our disposal, RPA and VPM, along with other things like process improvement. So we're able to work with our business users to engage, assess, and recommend the right application or combination of applications for the technology. When it comes to robust governance and oversight. So we've been able to avoid a decentralized dispersed model. So that's given us much stronger robust governance and oversight. And when we started this journey, especially RPA was a very scary topic at Starbucks. Like people didn't know what it was, what is this? It's gonna have access to what? It said, non-human making these decisions. So we've spent a lot of time working with our security team, our internal controls team, our internal audit team, our data use review team to build the go robust governance and oversight we have today. And now we just, you know, we run it under the parameters, but we didn't get there overnight. Next one's pretty common. I think you all know this, don't always automate. Sometimes our business users want us to automate first. Sometimes the it's too small of a use case. Sometimes the process isn't clean so we never come in with a predetermined outcome. And then similarly for clear success metrics, if our business users can't articulate the problem they're trying to solve or they can't actually articulate the metrics and how they're gonna move, we work with them to really spend a lot of time articulating the right problem statement and metrics for two reasons. One, we wanna make sure that we're automating the right thing, we're putting the right technology in place. And then two, we also need to know what the financial payback's gonna be, right? So if we need to be able to track this stuff going forward and make sure it makes sense. For us, reusability has been key to keeping our costs down and having greater efficiency. And the last thing I'll leave with on this list that's been great for us is this application continuous improvement. So we've been able to secure some funding set aside and some resources set aside for continuous improvement of our applications. And so I mentioned earlier our applications can be sticking and stable and they deliver value year after year after year. And that's hopefully by design. You know, sometimes the technology may change or the price, the process may change, but if we can put a little effort into like just fixing those changes or addressing those changes. Also sometimes our business users may come and say, "Hey, I can make any more value out this if you just make this change?' So if we're able to do that, then we can ensure that these use cases continue to deliver value year after year after year at a much cheaper price point. It's much cheaper for us to tweak it than it is to start from ground up. So that's been important for us to make sure that we have the stable delivery of benefits ongoing. Okay, so that's the list. I'm gonna hand it over to Ganesh now, who's gonna talk about our current and future capabilities.

- Yeah, hi. Thank you, Greg for sharing our DPA journey and also highlighting some of our COE wins and key learnings that we have had over the last six years. Good afternoon, everyone. My name is Ganesh Anantharaman and thank you for joining us today. I have been with Starbucks for 11 years and my role at Starbucks is a director for engineering and I co-lead the DPA Center of Excellence with Greg and I support from a technology perspective. So over the next 15 minutes, my goal would be to share some of the BPM and RPA use case delivery that we have had over these six years and how we have leveraged the Pega platform over our journey. We'll start with the BPM here. When we started our journey with Pega on BPM, our goal was initially to leverage the workflow automation and case management capabilities of the Pega low-code platform. So that's where we started. And we typically support all of the BPM application in support of our multiple pillars. So we either deliver in support of our customers or partners or suppliers or products or stores. So that's how we map all of the intake and how we deliver for our different stakeholders. So far, we have delivered about 15 medium to complex BPM applications, primarily in support of partners, customers, suppliers, and products. And as we speak, we are working on our very first use case in support of our stores pillar. I also want to talk about just the licensing approach that we have taken as a COE. So when we started this journey, we explored two licensing approaches for BPM. We looked at the user-based licensing, which would require us to look at every BPM app and see how many internal users and external users would access the specific BPM application on the Pega platform. The other approach available to us from a licensing was look at the case or transaction-based licensing where we are able to look at every single BPM app and be able to predict how many cases or transactions we would have on this specific BPM app year over year? So I think this model for licensing based on case and transactions seemed to be a more predictable model as our COE was able to estimate what would be the year on year growth that we would need to have on the BPM platform to support all of our BPM apps. So we went with the licensing approach for case and transaction-based. I also want to start mentioning that when we started the journey, the Pega was not the only option for us, right? So we evaluated for every use case do we go with Pega as a low-code platform for the BPM app development, but we also considered some of the in-house BPM apps that were available to us and the platforms that were available to us. But however, when we started delivering the initial few apps on the Pega platform, we realized the value and then we were able to adopt Pega as a go-to platform for a lot of our process automation needs. For everything BPM, we partnered with a single SI. And the SI partner helps us with end-to-end implementation and delivery for all our BPM apps. They also support us with everything, production, support and incident management, and also help us with all of our platform upgrades and all of the regression testing associated with doing a successful platform upgrade. And they also help us partner with Pega to resolve any critical incidents that we may have or any outages that we may have on the Pega BPM SaaS platform. I also wanna touch on one additional thing from a COE perspective. When we started our journey on the Pega platform for BPM, we realized with the very first app that we are going to need to build a lot of integrations between the Pega SaaS platform and all of our enterprise systems, be it on-premise, cloud, or SaaS. So we invested time upfront with our security and architecture teams to identify the different integration patterns that we would have. What integration pattern do we follow if it's an on-prem application or a cloud or a SaaS application? And I think this has helped our COE really a lot because now we have a consistent framework which the team able to adopt to. So as we deliver more BPM apps, we know exactly which integration pattern to leverage. Now I'll just briefly walk through the four BPM apps that I have shared in the slide here just to give some context. And as I mentioned, we are delivered over 15 apps, but just showcasing some of the four apps here. So talking about the core data portal. This was our first major workflow-based app in support of multiple internal users and external users, including our global teams. And with this app, we were able to simplify and improve the process of data collection. We were also able to streamline the process of how we route work effectively across the different personas, internal, external, and global. And we were also able to build a lot more transparency into the process for the ownership and responsibility for each of the personas. Going to the second BPM app around data privacy, this was the app that we built in support of the California Consumer Privacy Act or CCPA. So this was an app where we leveraged Pega as a core backend orchestration layer and we developed several integrations between the Pega platform and all of our internal systems. And we also had a lot of automated workflows on the Pega BPM app. This is also one of our largest volume app because we continue to get a lot more requests from our California customers in support of their request to access information and request to delete information. So we have also built a lot of monitoring around the app from a compliance perspective. Going to the third BPM app, which is around product data exchange. So this was an app where we leveraged the robust UI/UX capabilities of the Pega platform. So here we built a workflow based app on top of an existing SaaS platform. So we have a SaaS platform, which is our source of truth for product data management. And we have this workflow app on top of the SaaS platform, which enables multiple personas to collaborate and manage their critical product data attributes on the Pega BPM app. We also were able to build robust cash management for this app to ensure that the UI/UX performance was always stable. Going to the last BPM app, the real estate transaction management, this was an app where we looked to see how we could consolidate transactions for a portfolio to bring all the transactions into a single BPM app and provide a single unified experience to our internal and external personas. We also built in a lot more security on this app because we had both internal and external users and we wanted to make sure we can share the context sensitive information depending on who is logging into the app. And this app also has several integrations with our reporting tools, our monitoring tools, and we also had a lot of data migration needs in support of this app. So I'll shift focus to PNO. Yeah, so shifting focus from BPM to RPA. So as Greg highlighted, we have been working on the Pega platform since the last six years, both on the BPM side and on the RPA side. So from an RPA perspective, we have delivered over 35 to 40 RPA use cases in support of our business and delivered significant value and ROI to our business teams. When we started RPA in 2019, we started with a pilot. We wanted to explore like how the bot is going to work for us. It was a new process for us. We started with couple of use cases to do a POC and a pilot with the Pega platform. And once that worked for us, we were able to continue to deliver all the 35 to 40 use cases using the Pega platform. So this cuts across several enterprise systems and a lot of automation around Excel spreadsheets, emails, SharePoint sites, flat files, but we were able to automate everything to date using the Pega platform. Even for RPA, we use a dedicated SI. Similar to BPM, we have an SI for RPA who help us with everything from implementing and delivering the RPA use case. So the typical life cycle of a use case delivery, providing production support and enhancements for everything which is delivered. And also doing the platform upgrades annually for our RPA platform and all the regression testing that is required. And also working with Pega for everything from an incident management, outage, security, anything that comes through on the platform. From a RPA perspective as Greg highlighted, so our COE team does a lot of diligence in managing the intake backlog for RPA because we get a lot of requests across our different business units, including global teams and we want to make sure we do that diligence to see what is the ROI we are going to get on every RPA use case? And we try to prioritize work based on the ROI and the value that we can get from some of these RPA use cases. I think the way we start on RPAs, we typically approach every business unit and try to deliver one RPA use case for them to begin with. But this also helps the business team realize how we are able to eliminate and reduce redundant and manual effort for that business team. So when they see this value, when they are able to divert that effort towards more value added tasks, we are able to then go back and sell them with more incremental RPA use case needs. One other thing I'll call out on the RPA side, which the COE does effectively is the load management for our bots, right? We have several bots which are running 24 hours a day, some running just periodically, but how do we effectively manage the load on the bot? How do we govern and how do we see whether the bot is optimally used or not? Because our intention is not to use one bot per RPA use case. If you're able to leverage a bot and sell multiple RPA use cases, we want to be able to do that. And the team is also currently as we speak, trying to explore the auto balancing capabilities so we have less manual governance and optimization and we can look at some of the auto balancing features for our bot. Now just coming to the couple of use cases that I shared the screen, I'm not going to the actual flow, but what I wanted to highlight here is if you look at the tax and payables, we started with this team with just one use case a few years back, but we have already delivered like six to seven use cases for this team because they could see the value in building further incrementally on what we delivered. So we started with, let's say, how they receive the invoice from the supplier. But now we are able to process the invoice, store the invoice or archive the invoice. What happens if the invoice gets rejected? And how do we also process the auditing requirements around the invoice where the user is having to go through large spreadsheets and look for specific invoice numbers to get back to the audit team. We have been able to automate all these five to six specific sub-processes or steps if I may say, for the tax and payables team, providing them significant ROI and value through robotics. The other other use case that we have for planned purchase order, this is in support of our Green Coffee team. So this is the team which buys green coffee from our suppliers. So there's a lot of work happening on the Oracle Enterprise platform in terms of the planned purchase order creation release, a lot of work which is manually navigating through multiple forms within the Oracle platform, but we were able to automate a lot of the process using the Pega bot. So we have delivered about almost seven to eight use cases for this team delivering incremental value. And this is also one of our large volume intensive process. So it helps a lot more with getting the ROI sooner. And you can also see in both the use cases, in addition to the bot taking actions within our enterprise systems, the bot is also trying to cover everything in terms of, how do we process through Excel spreadsheets? How do we process through emails? How do we process through SharePoint sites? Through flat files? This is something which we don't have to do manual work. We are able to have the bot string things together and do the end-to-end process for us. I'll go to the next slide. So I covered BPM, I covered RPA. I just wanted to briefly talk about how the end-to-end automation comes together in this slide. I think when we started our journey five to six years back, we had a couple of installation options available to us, right? Whether we go with the BPM and RPA on hosted with the Pega SaaS platform or do we do things different? We made a decision that for BPM, we are going to use the Pega SaaS platform on AWS cloud. However, for RPA, we decided to host RPA in-house. As Greg briefly touched, when we started on the RPA journey, the whole bot concept was new to us, right? How do we ensure what systems the bot should have access to? How do we ensure what responsibilities the bot should be accessing within our enterprise systems? So we spend some time working with our governance risk and compliance teams and our security teams to really put together some internal controls and governance for the bot. And that's why we wanted to host the RPA platform closer to us. I just wanted to share the installation. The second thing I wanted to highlight here is when we started our journey, for most of the journey, we always looked at RPA and BPM as two distinct capabilities with specific outcomes. We never looked at RP and BPM together. However, as we progressed through the journey, we realized there is a need for end-to-end automation. And we really need to look at both RP and BPM as a single end-to-end process automation strategy and not individual. And that is when I think we wanted to just briefly touch on this use case where we got the benefit of, this is a blanket purchase agreement use case that we have where we have multiple personas doing work across multiple systems in silos. So data is split between multiple systems, there are manual errors that happen through the process and also the end-to-end processing time is fairly large. But by bringing the BPM and RPA together, we were able to have all the personas access a single platform. So a unified experience for everyone. Now data is all consolidated in a single system. So more streamlined and less manual errors through this process. And we have also reduced the overall end-to-end processing time with this. I think we were able to leverage the capability of the Pega BPM API effectively with this where we are able to use the case management capability, leverage the Pega BPM API and are able to invoke a bot to do some of the activities within our enterprise systems as well. And even here, you would see there's a lot of steps around the Excel and SharePoint. It's a given that we are trying to use our bots effectively to streamline everything around Excel spreadsheets, email, SharePoint sites in this example. I'll go to the last slide. Yeah, so as you heard, right? So while the COE team continues to deliver a lot of value, efficiency and productivity for our business teams, the COE is also focused on learning what is next, right? So what are the new capabilities that are available to us as part of the Pega platform? So we want to continue our exploration and look at what else we could leverage in support of our business. From a Pega enablement session, so this is where we are able to partner with Pega and where for our COE team, we are able to invest time for our COE team to learn through the new capabilities. What is coming in the Pega Infinity platform? Should we plan for an upgrade? So we can leverage some more capabilities that we are not leveraging today. So that enablement sessions has definitely helped us and we definitely invest in an annual platform upgrade because we want to stay current, we want to stay supported. At the same time, we want to take benefits of what is available to us. Earlier this year, we upgraded to the Pega Infinity platform '23. So we were able to go there and now a lot of the focus is exploring the new capabilities and features available to us on the Pega Infinity platform. Be it the Constellation UI/UX. Be it some of the Gen AI capabilities. We heard a lot in the keynote today around blueprint and knowledge buddy. But something that we are just beginning to learn and see if it is relevant to us with our existing and upcoming use cases. I would also like just talk about the explore the art of the possible, right? So, so when I talked about the BPM slide, I referred to we starting on the first BPM app in support of our store pillar, right? This is big. Imagine the app in support of 10,000 plus stores per Starbucks. So we are leveraging this use case more to see, okay, what else in the Pega Infinity platform the art of possible that we can leverage for this specific BPM app? And I also put citizen development, again, I would say in the last five to six years, a lot of the work that has been delivered across both BPM and RPA has been with our partnership with our SI partners to help us deliver. The same time, we also realized the value of enabling our business teams through citizen development. Now that we have a large repository of integrations and we have a large intake within data, now we have an opportunity for our business teams to also maybe deliver smaller apps, smaller capabilities on the Pega platform. It'll be one of the focus for us on how do we expand further through citizen development for our global teams as well. I think that is something which I wanted to cover as part of my presentation. I'll request Greg to join me here and we'll be happy to take any questions that you may have. Thank you again for your time.

- [Audience Member] Is this on? I've got a few questions. First of all, let me say, I've been to a lot of these. That was a great presentation. It was exactly the right level of detail. And it was very well done indeed.

- Thank you.

- [Audience Member] So one of my first questions is about BPM and RPA. You clearly decided to have a hard cut between these two. I would've always imagined that while not all BPM activities would result in an RPA initiative, but the two were very closely connected. I've always seen, you know, BPM is the initial planning phase and then RPA is a potential outcome associated with that. But I don't know that that's the way you think of it. I think you think of them as much more distinct. Could you talk about that a little bit more and what the advantages are of treating then differently?

- Yeah, great question. I think the way how I would address this is when we started our journey on process automation, the reason why we looked at RRP and BPM as two separate capabilities with specific outcomes was we always thought of RPA as task-based, right? It's more to maybe automate a specific task for let's say a business user or a persona and just reduce the manual effort or redundant effort for that task. But we always looked at BPM as process focused. It's much bigger. Okay, we probably have to build a large process. We may have to build integrations, we may have to connect the BPM platform, which all of our enterprise applications build a lot of workflows. And also we looked at BPMs in support of multiple personas. We looked at RPA more in terms of let's say one user, one task. But we realized through the journey that it all needs to come together.

- [Audience Member] Fair enough, thank you. So one of the other things you talked about was socialization. You talked about this idea that people didn't necessarily understand whatever any of this terminology meant or what the implications were. And you ended up ultimately with a framework that allowed you to proceed with this much more expeditiously. Can you talk a little bit about how you went from initial socialization to agreed to framework within the organization and maybe from the perspective of who were the key stakeholders? You mentioned security. Who else did you have to sort of get on board with this idea?

- I'll start and then Ganesh can take on that. I think also I would put this in two different camps. The BPM application I think got quite a lot of socialization through our tech partners. I said first that we're very tech forward, tech first. They lead our strategy, right? The tech team in conjunction with business partners. So I think from that perspective, they tended to adopt the BPM capabilities much earlier than anyone else because they saw it quicker to value than a lot of these, like it doesn't take 13 months and $2 million to have this full application. It's got this thing I could do in four months. And so I think they tended to adopt it quicker. So we saw a lot of pretty quick moving in the BPM space. I would say I felt pretty, we always felt really good about that. RPA was the one that just, it took a lot longer. Like it was just a slow turning engine. We talked to a lot of people and it was just like. And the other-

- [Audience Member] What was it? Was it like a fear within the, how would you describe it?

- I just don't think people got like got, you know, got exactly what it could do until they saw it in action and then once they saw it in action, the other thing I should tell you is that you know, essentially, the hurdle should be larger for BPM for us because you're paying for it. RPA is a free service to you. So it just blew our mind that the traction wasn't there. But I'm telling you once you, I think Ganesh mentioned, once we saw a certain group, like you'd work with one group then they want five, six more, right? That's kind of what it took, right? Like it just takes that one to kinda get in the door and then we saw a lot of traction. But just a lot of different, I mean that's the value that our team brings. A lot of education outreach and there other IDing people and telling what the art of the possible is and that's really ultimately what got the traction.

- [Audience Member] Appreciate it.

- I think I'll just add to what Greg said on the RPA side, right? I think our recommendation would be that we don't focus just on RPA use cases within the enterprise systems. Look for opportunities with teams who are doing a lot of work outside of enterprise systems. Like maybe working through spreadsheets, working through legacy systems, working through SharePoint sites. A lot of work during email. I think these are the things where we were able to reach out to those specific teams and show the value that we could deliver with RPA and then just started going from there for some of those teams. And then of course, eventually we moved into a lot of the enterprise systems as well where there was a lot of work for our users to go through multiple forms to go through a process.

- [Audience Member] Sorry, and did you see it? Because it sounds like at first, what you were doing was digging into what other departments were doing to identify opportunities and sell those in as opportunities for automation of some kind. Did you see that flip eventually once you'd established the process? Were people coming to you?

- That's a great call out. I would say we had repeat customers in terms of if you have delivered a RPA or a BPM application for a team, yes they are definitely coming on their own proactively. But I think for other teams who have not been on this journey, that outreach is still there where we reach out to our teams and we look forward enablement, right? Like just how we are getting enabled through Pega for our COE team. Our COE team does the enablement for other teams within Starbucks to see how do we share what we have learned. We look for opportunities to demo some of our key use cases to them and then look for opportunities and wins with some of the newer teams as well.

- [Audience Member] Great, thanks again. Great job.

- Thank you.

- Thanks.

- [Audience Member] To start with, great presentation, I can totally relate to what you guys are doing. I have one question towards Pega Infinity upgrade and gen AI. We are in the same journey trying to upgrade our Infinity to Infinity. So what are the precautions or the steps or safeguards you guys thought about it or implemented like that Starbucks or your supplier data when you are using your AI tools that is not shared with the community and your data is safe? That's what we are trying to acertain that we have certain reservation. We are trying to internally. So if you can expand on that, I would appreciate that.

- Sure. I think so one thing to call out, right? So we are not leveraging the AI capabilities within the Pega platform yet, right? So we have been more focused on the workflow automation, the case management, and the robotic process automation. It's more just with the Infinity platform that we upgraded early this year. We want to begin exploring some of the AI capabilities. However, I think just as we are planning for this Infinity platform upgrade, we had like 15 to 16 BPM apps which have been delivered and some of them are really large in size and we also have at least three to four in progress. So it's about like, and this upgrade was going to take a lot more time than a traditional upgrade because moving into the Infinity platform, that required us to maybe spend more time and do a thorough regression testing for all the apps which we have delivered. Is there something that we need to retrofit on the new platform? There was a lot more diligence and planning around moving to Infinity 'cause with our SI partners also helping us through the what level of regression testing do we plan and how do I work with Pega. So I think the team was able to work with Pega through the steps and we also engaged them to seek support as we were going through the upgrade process. But from a journey, it's just now that, okay, now that we are on the Unity platform, we are looking at okay, what is available to us? Maybe Constellation UI/UX. Maybe Gen AI just beginning to learn about what does Blueprint and Knowledge Buddy mean to us. And we're just beginning to explore on that platform.

- [Audience Member] Okay. Thank you.

- [Audience Member] Great presentation. Thanks for taking the time to share your thoughts with us.

- Thank you.

- [Audience Member] At PREMIER Bankcard, we had the same reservations with RPA. So I understand exactly what you're talking about, but my question is, is there any complexities with RPA running on-prem and BPM running in the cloud and those two working together? Is there any technical complexities there?

- Yeah, great question. When we started on the end-to-end automation, I would say it's just probably a year, year and a half back that we realized, okay, we really need a tool to bring RPA and BPM together. And I would say we did not have to do anything additional to bring the BPM and RPA to work together. So we were able to leverage the Pega SaaS platform for BPM and leverage the Pega BPM API effectively. So through the Pega BPM API, we were able to invoke the bots on the RPA side, which is more hosted within our platform, but we did not have to build something new or additional integrations or capabilities we were able to work. So we have just what one or two end-to-end automation use cases. And I believe it has worked without a lot of effort from our side. Of course, with support from our SI and Pega, but I think the BPM and RPA works together even though they are two separate installations.

- [Audience Member] Okay, thank you.

- Thank you.

- [Audience Member] Hi, I am Pierce Antonio from Ford Motor Company. Just great presentation by the way. Just one of the slides that Greg showed is about, you know, COE having a clear problem statement and success metrics. Could you share a couple of those that you add to?

- Yeah, so it's up to the business users to, we work with them to articulate it. So it just really depends on the process. But basically, we need them for a couple reasons. So we need to help them establish what metrics they're gonna see. So, I mean, without giving you a real world example, it's kinda hard, but think about like, whatever their process is and let's say it's RPA and they're gonna pull out some manual hours, right? Let's say they have to, let's just kick a theoretical, they have to manually process POs by hand and they think that this automation could take out 20% of those. So we'll work with them to articulate the problem statement, which is drive down the number of manual POs by whatever it is. And then we know the number of manual POs and so we can basically track those and put like a time savings against those. And then our systems allow us to track those for years to come so that's how we can continue to talk about our value. "Hey, this is what they're delivering 'cause we've actually set those parameters up front. We get them to agree to it upfront." Couple nuances. Starbucks doesn't charge back for these services in any way. So it's like, it is just more for reporting and storytelling. So it's not actually, we're not pulling those costs out of the business necessarily. I mean they are, but they can kind of repurpose them or reuse them. So, but we still want that upfront engagement so that we know what we're tracking internally, what we're delivering in terms of the value we're delivering. Yeah.

- Thanks.

- Sure.

- [Audience Member] Are you also using currently or planning to use the RPA technology and other automation techs for more customer-facing use cases to improve the customer experience? Right now, I can see from the diagram that it's used more for the VPM use cases, which is procurement, sourcing, planning, right? The finance functions, but for the more frontend customer-facing functions. Is there a?

- No, that's a great question. I would say yes, you're right. The observation is correct that a lot of the RPA use cases that we have delivered to date, maybe in support of maybe end-to-end supply chain and end-to-end finance primarily. And a few other teams. In fact, we even delivered a couple for the stores, in support of the stores. But we have not received any RPA use cases in support of the customer experience, if I may say. But we are looking for opportunities how we scale further and support and enable more teams in this journey.

- Thank you, all for your time. Really appreciate it. Thank you for listening. Thank you for attending. I appreciate it.

- Thank you so much.