How Manhattan Associates Leverages Asymmetric Problem Solving with Structured Planning | Brian Skelly

Speaker 1: So, a little bit more about myself. When I was growing up, I spent some time with my godfather as a child. He was a West Point graduate, and was a Special Forces Officer, so career Army Officer, retired as a Colonel about 20 years ago or so, and just a really high speed guy. And he was always very intentional about sharing with me what his experiences were, lessons he had learned, and making sure that myself and my cousins understood how we could take his lessons learned and apply it to our lives. And one of the items, one of those lessons learned that I carry with me all the time is the idea of a force multiplier. And it's a common thing for folks in the Special Operations community to reference. And the way he had delivered this lesson learned to me was to talk about his commanding officer. When he had graduated from Special Forces Assessment and Selection back in 1976, the commanding officer at the time was Charlie Beckwith for Group five. And at the graduation, this is not a direct quote, but it's kind of along those lines. And he said," You men are now force multipliers. Your training, experiences, force of will, and character will consistently translate into abilities that are many times more efficient and effective compared to other men in the military. Not only are you more efficient and effective, every resource at your disposal from here on out, and every team you're on, will inherently become a force multiplier as well." Really powerful. What we're talking about here is someone who can take your everyday resource, whatever that might be: people, money, doesn't matter, and make it really effective, really do something with a resource that other people just can't. And with that understanding now, I'll kind of dive into asymmetric problem solving. So, here again, one of the big things, always make sure you understand your force multipliers when you're trying to address a problem. At its core, we are talking about identifying solutions and prioritizing those that provide the greatest impact using the least amount of resource, time, et cetera. And a key tenant of this is reducing or eliminating any indirect or cascading impacts to users or business as it applies to us. And back to some of the things that my uncle and my godfather had taught me, he had shared with me this strategy that was used during the Gulf War. And it was based on a study from World War II, a US air campaign. And this study identified that," Okay, yeah. We're going to go bomb German railroads. They can't use them. Make sure they can't get their supplies out, missiles, bombs, food, whatever it might be." Right? Spent hundreds of flight hours, bombs, the risk. And the study identified," Hey, we spent all this money, all the people, the bombs, and we could have just done that with 10 to 20 targeted strikes. We just had to pick bridges or junctions or something along those lines, and we didn't need to create the mess that we created." The reason it was a mess was because they hadn't really considered second and third order effects, or indirect and cascading effects. So, the direct objective there was," Hey, let's make sure the Germans can't get supplies to where they need to get them to." The indirect would be," Okay, now that we've done that and we've won the war, now we need to start getting supplies out to our troops, civilians, et cetera. Can't do it." Cascading impact is because you can't get those supplies out, maybe your men and women in uniform can't address problems on their end, it could create other problems for civilians, et cetera. So a really key piece of this is always making sure to understand that," Okay, you may have primary objective, and your solution may meet that, but you also need to evaluate as you're going through it. Okay. Well, once we implement this, are we going to be able to check some more boxes? Are we going to be able to understand what indirect and cascading impacts there are going to be?" We here are not in the military. We are in finance. We're not invading any countries, so what we're talking about is for planning solutions, making sure that you are using the people and tools at your disposal, money, time, to create solutions and implement solutions that will address your user's needs and not create headaches down the line for yourself or your users. Simple problem solving process everyone's aware of, first step, always identify your problem. Sometimes, pretty much always, you can frame it with," I need to do something, I need to know something, but I don't have this, or I don't know how to do this." Once you've identified the problem, now you can start stepping through," Okay, what are my constraints? What's the information I know? What's the information I don't know? And what do I need to go get that's available?" And it's within this second step that you want to make sure you're applying that force multiplier tenet.

Speaker 2: Yeah.

Speaker 1: What do I have at my disposal that I can rely on to give me great impact for the amount of time or resource that's going to be used? Once you've gotten through that, now you want to make sure you understand the constraints that you're working with. The information you identify that you know, right? That's what do I have? And now, this third step is what don't I have? What am I going against? What do I have to work within? Once you've gotten through those first three pieces, now you can start working with your team and say," Okay, here are the four or five potential solutions we have. And now we want to identify, okay, what is the optimal solution here? How do we address everything we need to address and leave time, money, people, available to do other value added work?" So, I'll step you through now what Manhattan went through, and it had to do with resource borrowing and lending, which I'll walk you through in a second. But stating the problem, pretty simply, it was, we were in Anaplan. How do we take the logic and some of the lessons learned from Anaplan and bring it into Planful? And how do we do that within the system and resource constraints that we have? So, now we'll talk through some of the force multipliers, the knowns, unknowns, and constraints. So, our force multipliers at the time were the Planful experts, obvious one, key shout out here for Will Leonard. He was instrumental in this whole process. My FP& A team, Andrew and Tanner, are sitting right there, really picked up Planful really quickly, and became forced multipliers in it very quickly as well. And then, one thing we identified that we thought was a little unique was," Hey, we have unused dimensions within our hierarchies. Could we do something with that?" And lastly, we had some budget available to us, just in case throwing money at the problem could get something done. So now, okay, we know what force multipliers are there. What can we leverage? What do we have to work with now? So, I know we know the logic for the business that they use for borrowing and lending. We know the mechanics that drive results on the P& L for revenue and intercompany cost. I know what improvements were requested by the leaders as we were transitioning from one system to another. And we also were able to identify some of the past failures and limitations within the broader process. And then lastly, of course, we know what Planful's structured planning capabilities are and what their architecture is, and what resources we have available on that front. The constraints were resources. We had a limited implementation team, Planful experts and hours, so we know that's about all we can use. And we only had so much money left. I can't just write a check and say," Here's a million dollars. I'll get whatever I need." We had the time constraint as we were transitioning away from Anaplan. We needed to remain aware that our budget season was going to be starting soon, and we needed to be able to have our users test, and we needed to ensure that we had addressed all of our core issues in the system. System capabilities, so not necessarily saying that Planful restricted us, more so here just saying the solution needs to work with Planful. You can't do something outside of that system. It needs to be able to be translated to financials. One of the really big things for us was workforce plan and security. When you're talking about resource borrowing and lending, one of the things that you always need to separate out is an individual's compensation versus how much the average person costs to borrow, and how much time do they have available? Two very different things, and nobody needs to see... If I want to borrow a resource, I don't need to see what that person makes. So that was one of the really big constraints that we had to keep in the back of our mind as we were doing this. Lastly, the solution has to directly and indirectly serve our various stakeholders. So we have internal leadership, FP& A, our CFO, the rest of our C- suite, and our board of directors. So I'll step through the real- world example here. So in general, for those of you who may not have a services component to your business, when you have a project, let's say here, in this example, it's in the US, there's a team of maybe five people. They can address 10,000 hours of work a year. That project may require an additional 800 hours, let's say. Okay? And they know that they don't have the headcount for it. They need to go out to other areas of the business who may have some availability and say," Hey, I need two or three folks to come and help on this implementation. Can you afford us that time?" So they're sending a request to another geography or department, and then that department has to say," Yeah, I have it available or I don't." So request and approval, and once those two pieces are kind of hashed out, the next step is simply using transfer pricing to identify what an intercompany cost is, so you can come back to your financials. So as a resource books their hours on a project, I think for us, it's Salesforce, they've booked it, we can now generate a dollar per hour cost via transfer pricing to say," Okay, if it's four hours and$ 10 an hour, that department is going to get$ 40 cost." Same thing, whatever billable hours they've generated, now I can assign revenue to that borrowed resource as well. And once I have all of that, now I can effectively communicate margin on that project to the business leaders. So now that we kind of know everything going into talking about solutions, what does the solution need to do? What do I need to touch on? So, the real- world logic needs to be available in the Planful solution. I need to make sure nobody's over, under borrowing. So if somebody has, let's say, India has four folks who are available, and the US requests five, we need to make sure that doesn't happen, because then we're going to find out later on that they weren't able to staff a project. Same thing with the under borrowing. We don't want folks to have headcounts sitting on the beach not being productive. We also need a solution that will empower our leaders to be collaborative and make decentralized decisions between different geographies or departments. And lastly, and one of the most important, making sure we balance security with data transparency and reporting. So, we kind of sat down the implementation team. This was actually during the pandemic, so everything was Zoom. And we kind of talked through what we thought three solutions were, talked through what we thought it would take, and any issues we saw with these solutions. So our first solution was to just use statistical accounts, track borrowing and lending within the existing hierarchy and dimensions. The problem with this is it wasn't going to give us the reporting visibility that the leaders need in order to understand their margin and more importantly, availability and all that. They needed to be able to see what was happening and the statistical accounts very straightforward. It wasn't going to cut it, so we said," Okay, that one's gone." And again, there was the security issue. If we need somebody to see what's available, in that scenario, we're going to have to have access to compensation information. The second solution was still statistical accounts, but we were going to marry it to our geographies and departments. And this looked really good at first. It was a lot of work. That was the one thing we kind of had to swallow at first. 192 stat accounts, fine, we can make that. But then how do we manage the process? And is it going to tow that line of security but still allow good reporting? No. It wasn't going to do that. It was a resource problem and a security problem. So we said," Okay, that one's gone." And our last solution was discussed among the team. And it was," Hey, we have this extra hierarchy. It's not being used. Unless you guys have a plan, could we use that? And we started looking at it. We're like," Okay, this might do something." So we looked at our normal finance hierarchy and said," Okay, we have geography. We have department. If we want to manage security, we're going to have to create some kind of hybrid of geography department and resource availability." And we started stepping through in it, and we said," Okay, well, this is checking all the boxes all of a sudden. The logic can be there. We can build in checks and balances for borrowing and lending. Folks can see data that allows them to make smart decisions. And lastly, we weren't risking security issues or reporting." So it kind of checked all the boxes, and we said," All right, let's game this out." So what did this look like? Our first step, obviously, create the dimension. And I'll kind of show you what all this looks like. Create your input templates on the request side, the approval side. And then within that, we need to say," Okay, well, all of that's there. Can we track cost, revenue, margin? And ultimately, are we getting results that make sense?" And so, what we did is said," Okay, well, let's go into our finance hierarchy. That's where we'll start. And we're going to create some new dimension called resource departments." We categorize those resources into the various areas of our business that might do borrowing and lending. So try to be a little forward thinking about it, saying," Hey, maybe in the future, there are a couple areas that could do borrowing and lending, even though right now those folks don't." This piece was the key point to managing the security, because we could give everybody access to resource availability without having that person see another geography or another department's workforce planning information. As I said, we grouped those resources, so as we were bringing the data in, instead of having compensation items mapped to a resource department, we created this one kind of stat account that said," Okay, if you're going to bring it into your normal geography and department, for any given headcount, if it's within one of these areas or departments, training, Cloud, CSO, PSO, you're going to put a one for each headcount that is in a department that can be borrowed." So it was kind of a really novel way to look at this, and at first we weren't sure if this was going to work. We were like," Eh, this looks like it sounds really fishy. I don't know if it's really going to balance everything we need." So we started stepping through it. We said," Okay, now we have it in the finance hierarchy. We think we have that logic. How are we going to do this for budget, because this is really what we need to use?" And this is where we kind of said," Okay, the marriage of geography department and resource, we can assign everyone the view that they need, give them the access to the data, and they don't see what they need." It was kind of our little security miracle all of a sudden. And within that segment properties, you see right down there on the bottom right, that resource department popped up, and this is how we were able to manage this. So, once we had the infrastructure in place, now it's just about creating the templates and testing it with our users. So here we're looking at, let's say the US wants to borrow from India, so we created a template that said," Okay, go in, tell that department what you would like to borrow." And in a second, I'll show you what the other template looks like for India. And one of the key pieces we wanted to kind of call out here was that over and under borrowing we mentioned earlier, making sure somebody couldn't submit a request for a headcount that wasn't there or that any user wasn't just throwing 9, 000 employees and waiting to get borrowed and just leaving them in there. For those of you who know this, on an input template within structured planning, you can't save that template if there's an error. It will not let you do it. So we created logic that said," Hey, if you are over borrowing, we want to throw an error at the user. It'll identify for them they can't submit that information. It's bad data and you need to fix it." Within that, this approval role is set up. This is where we manage the security. So we were giving somebody access and we said," Okay, here's all the different areas that you're going to be allowed to see." But down here, there's resource approval, so even though they're maybe only in India, or maybe they're only in the US, who do we want them to have approval access to? Where are they going to make the request, and where are they going to go and approve? And this is where we were able to get around the security and reporting issue. So, once we had kind of set all of that up, we said," Okay, well, the request has been made. Nobody is seeing data they don't need to see. How's it going to get approved?" Really easy. Joe Schmo or Jane Doe goes in, they see that somebody in the US requested, I think here, we just used dummy data, we said four resources. They go in, they say," Okay, yep. I'm going to approve each one of these." It has to be that amount. They can approve less, but they can't approve more, or else it errors out. Again, one of these pieces, making sure we can do the reporting, allow the agility that Grand Holleran and talked about yesterday. Business leaders need to be agile. They need to be able to make these decisions quickly. How do we give them reporting so that they can make those decentralized decisions without running everything up the flag pole and figuring it out afterwards? And here, what we've identified for someone was," Hey, look. You have 24 extra heads in March, and 46 by the end of the year. And in October, it's at 52. You've got to smooth this out. You can't have all this extra cost sitting on the P& L." So that was one of the really big changes that the business never had before. They were never able in Anaplan, the way it was set up, they were not able to go in and easily run a report to say," Oh wow. This is really bad planning. I need to fix it." And then, one of the key requests we had gotten from our business leaders was," I want to be able to track my revenue. I want to see where my margin's coming from. How do I see what my team here in the US is driving, in terms of a return on the revenue versus when I borrow somebody from India or Europe or Asia? What is their margin?" And it was just transformative for them. They had never had this before, and now all of a sudden, they're able to track the contribution by country and by department. It was very, very impactful for our leadership. So, we looked at all this, got it implemented. We said," Okay, let's go do our UAT." Users loved it. They said it was amazing. They'd never had it before. And most importantly, from our perspective, that security box was checked. So, why does all of this matter? By stepping through this process, by identifying where we had force multipliers, leveraging Will, the Planful Implementation Team, leveraging the guys on my team, they just really did a great job. And what it resulted in was fewer budget iterations, where we might have, let's say five or six rounds, by the second or third round, we were pretty much done. It was just corporate adjustments after that. It was pretty cool all of a sudden. What all of this translated into for our team was about 30% of our time back during the budget. We weren't spending our time trying to create manual reporting from Anaplan, and then trying to validate it. And so, we were doing value add analysis for the leadership, for our C- suite, for our board of directors. And most importantly, because of all of these things, because we had the security, our leadership trusted the budget. They saw what we did, they got it. Leaders of these areas that do borrowing and lending were going to our leadership and saying," Hey, the FP& A guys nailed it. We can see all the margin. We know where it's coming from. We know where it's going. It's great." And that was a really key piece, because it had bought of course the good will, but more importantly, it gives us the flexibility later on to say," Hey, look at what we just did when we were working within Planful for three or four months. We're a year on now, here's the new stuff we want to do, and here's why it's going to matter to you." And that's what we're kind of doing right now, is looking at things and saying," Hey, we can do even more with this." So, kind of bring this all back together, the things I want you guys to walk away with here today, as far as asymmetric problem solving goes and using it within Planful. So always make sure you understand your force multipliers, who's going to be that resource, or what is that resource going to be to get you a really big return, really outsized impact relative to the effort put in? Make sure you step through a problem- solving process. Don't just start gaming things out willy nilly. And once you've gone through that process, now you want to evaluate what options are available to you, and choose the one that is going to optimize impact versus effort. And then lastly, don't forget to check through that last piece of," Okay, I've done my primary objective. What are these indirect and cascading impacts I see down the road? How do I address it now?" That's it. So any questions? Nope?

Speaker 3: Did you guys work with Anaplan to apply that goal?

Speaker 1: We did. Yeah.

Speaker 3: What did you not like about Anaplan?

Speaker 1: Sorry?

Speaker 3: What are some things you didn't like about Anaplan?

Speaker 1: We didn't like the reporting. That was one thing we always really struggled with. So, Anaplan was a good solution from the perspective of... If you had somebody who could build in it, it can be a very powerful tool. What we found as a team was getting somebody up to speed as an expert was difficult in Anaplan. In Planful, it wasn't. It was very straightforward. As I said, two of the guys on my team just picked it up really, really quickly and started creating these value- added solutions. Anything else? Okay. Cool. Well, thank you everyone for coming, and I appreciate your time.