BA Bites - How Business Analysts Should Approach a Salesforce Implementation

Speaker A: Salesforce. It's one of those systems everyone's heard of, but few really understand until they get neck deep into an implementation. As business analysts, we often drop into the chaos of CRM transformation. Full of assumptions, conflicting requirements and a tech team eager to configure before the business even knows what it needs. The Better Business Analysis Institute presents the Better Business Analysis podcast with Kendra Walsh. Today we break down how a better BA approaches Salesforce implementation not as a systems analyst, but as a bridge between process people, product and project. Let's get into it. So number one is to understand the business problem, not the Salesforce product. Don't start with the objects and the fields and automation. Start with why Salesforce? What problem is the organization trying to solve? And that goes for Dynamics365. Also, often the issue is poor process, not poor tools. Maybe a sales team is missing targets. It's because the system visibility, there's process delays or there's unclear responsibilities. Number one, start with your stakeholder and process mapping. Identify the roles like sales, marketing, finance, IT and how they interact. Use Personas and process modeling from your BBA framework to visualize the current workflows and where Salesforce will actually touch the business. Capture pain points before doing any solution workshops. I've done a couple of Salesforce implementations actually back in the day and a lot of CRM implementations. And this goes for Dynamics 365 as well. But I consistently hear, uh, especially in the education space is that Salesforce is a disaster. And I uh, usually find two things. One, none of this upfront work was done by architecture. It big mistake. And the other thing is that they have customized the system so much that it's no longer Salesforce. So let's jump to number three. This is defining success in scope. So we talked about understanding the business problem, not the product stakeholder process mapping. And now we're talking about defining success in scope. It all happened first. Translate business outcomes into measurable objectives. We use smart goals for that. As we know as a BA you need to really ask this question. Are we implementing a CRM or are we transforming the way we manage customers? They're two different things. It's actually very difficult to do process improvement at the same time as doing system replacement. Define out of scope items early. Like integration with marketing automation maybe might come later. A lot of the CRM sweeps suites don't do marketing uh, that well. So they have to have add on products. You know, what are you integrating with then? Then this is slightly different to any other project because you have A platform, Right. There's number four. You elicitate requirements the Salesforce way. There is actually a way to do it around the system. So as long as you've done those three steps above, you're now okay to start looking at the context. Right. So you know, you can do requirements, uh, and throw them over the fence. But you know in this case where they've already purchased the CRM, that it's going to be sales. So there's no point in ignoring it. So you can't be agnostic at this point. So you can elicit requirements in the Salesforce way or the Dynamics way, depending on what it is. And just a slight tweak so we know the feature set right of the product. That means we have to change things. We can't just write, we want a new screen, um, to do X. You can actually become part of the problem if you're doing that. So use user stories with acceptance criteria. Normal. Right. But encourage examples like as a sales manager, I want to see my, see uh, my team's opportunity pipeline so I can forecast accurately. So you're validating the stories against Salesforce capabilities. Right. Does it already exist as a standard feature? Does it need customization or do we need to change our process? So this is a, uh, process I'm doing at the moment for another client where there is an existing platform that decided to buy and now it's gap analysis. You're not doing just uh, pure requirements. If a requirement can generally be met, a process that can generally be met, uh, by changing, tweaking. A few things that we do from a process point of view then that require, uh, we should accept the function in the system that's slightly different and I'll say that in a different way. So for example, say in your organization you talk about prospects and you have prospects and then suddenly they turn into orders. Well, every CRM system uses the same sequence. Which is best practice. You have a lead, a lead gets converted to an opportunity. You work the opportunity and it gets converted to an order. So whatever you're calling internally, if you're adapting a CRM system, Salesforce Dynamics HubSpot, whatever you need to use those entities don't customize the workflow. So you're changing your process. You might customize the screens, that's fine, but you should not customize that workflow. That is the best practice workflow for sales and marketing all over the world. Okay? Millions of people have done it. And so therefore Salesforce Dynamics HubSpot have created the systems around that workflow so that this is the tricky bit when working with systems, right? You've already got the system, so you need to manage expectations, you need to coach people. And the trick here is, is you use the out of the box entities, the out of the box screens as much as possible. And what you do though, right, uh, is that you say to your user community, where we are different, we can change the system. Now it's more than just that. And when they say, well, we're different, we're different to the how the system works, you say no. Does that difference create value for our customers? Is it unique to us? Is it ip? Is it creating a market difference for what we offer? Are we, you know, completely different for a good reason? And if there isn't a good reason, it's just because we work that way. Then you need to coach them and work alongside, um, IT change managers to say, we've adopted the product, we adopt the product and we tweak where we need to, okay, which is adapt. So if you validate your stories against Salesforce capabilities, you need to become the expert or use a functional consultant from the vendor side and do some mapping before you, you know, go out and define your requirements completely. You need to say, does it already exist as a standard feature? Right, and does it need to customize or is it, is it actually coding? Which is a, ah, whole different story. Number five, at the same time, you need to map current data sources and ownership. You need to find what gets migrated, cleaned and archived. And you need to ask the question, who owns customer data once Salesforce goes live? Is that the master of customer data? That whole data and uh, process integrity piece is massive, uh, from a technical delivery point of view, not just, uh, other aspects that complain to a project. Data migration to the CRM systems or any system when you're moving data, uh, becomes at least half the job. Okay? Change management's the other half. And really, I mean the doing the implementation is just like standard. But data migration can kill you in terms of effort. Okay, number six, configuration, not customization. And look, we use the word sometimes, um, we say customization just because it's a general kind of word we use. But there's a difference, uh, when it comes to these systems. When we say configuration and not customization, right? And this is until proven otherwise. So the whole point in Salesforce, the whole point in getting a Salesforce platform or a Dynamics platform is that you can configure the system. And what I mean by that is the super user can add fields without you having to go to a vendor without you having to write code. Okay, think about it as like these rapid development areas, but this is in a contained area. It's done very well. And I can do it in Salesforce and I can do it Dynamics and they're both similar and you can go on courses and a BA can do it, uh, in some ways. Right. I don't know if they should, but they can. So you um, can add fields because you need them, but you're not customizing, you're not writing code or changing the fundamental workflow under the system. Do you want to keep Salesforce as vanilla? We say, right, we're going back to vanilla or out of the box as possible. In the first phase. Do not. I, uh, would highly recommend in your first phase you do not customize Salesforce. You might configure it, but you don't customize it. And I wouldn't even do too many configurations. So as a business analyst you need to uh, um, kind of act as a governor of scope creep and technical gold plating. And the fact that you know, we want to do some wild ideas, park those until you've used the system in anger and you've changed your processes. And that leads me into testing and change management. So BA should help define the UAT scenarios, user acceptance, testing scenarios from real world processes. So you would like we said we're adopting some of the out of the box functionality to the processes. Um, how you would use the new system to do that. Maybe you've got a few steps you've added, uh, if you additional fields on the lead screen or the customer screen because you, you want to capture some uh, data that's not on the default um, screen. Usually you're turning things off these systems. You're actually, it's too, it's too big. So it's got too many fields. You're hiding those fields and you don't have to use those necessarily. Uh, you need to support comms and training plans and ensure that the business adopts Salesforce, not just installs it. Okay. And they understand how to use the base products. It's heaps of documentation. You can reuse a whole lot of documentation online, uh, and reuse that training material and just brand it for your organization. And remember that adoption metrics matter more than feature count. So how many people using it, logging in, using it, that's when you know that you can value. It's not around the fact that you have all these different pieces of functions that no one uses. So let's say you're implementing Salesforce into a gym, uh, franchise, right. The owner thinks they need Salesforce to track members better because they're using it as a membership management area, which does involve a few tweaks. A good BA starts by mapping how memberships, renewals and PT bookings flow today. Then only then do you find the real issues, right? The pain points, disconnected spreadsheets, missing follow ups. Know one place to view all this information. So Salesforce isn't the answer, it's enabler. Once the process is cleaned up, then you can go and put it into Salesforce and you adopt the features in Salesforce as much as possible, right? Maybe just relabel account to member. Right. Maybe there's account and maybe the contacts are members. That's all you do. Maybe you keep them as contacts and say. When we say contacts, we know that they're just people that interact. So you just. Purely vanilla Salesforce implementations can be brilliant opportunities for business analysts. It's actually very, very good because it's end to end, but only if you stay business first, not tool first. Your job isn't to configure Salesforce, it's to clarify the business change it's meant to support. Remember, people process, right? Just say platform in this case, always in that order. People process platform. This episode was actually inspired by one of our uh, learners on our course at the moment who's um, got a background in this area. I thought this triggered me to doing this course. Uh, shout out to uh, that person and I will see you next week. Sam.