Natalie Hanson End-user or business stakeholder?
[This is a modified version of a post I made internally on SAP’s Lean Transformation blog. I’ve removed a few of the details about sales compensation, the process diagram, and the system screenshots.]
One of the significant challenges we face in the User Experience work we do at SAP is working with business stakeholders who really feel that they know the end-users whom they represent in governing bodies, and that they can speak on behalf of those end-users. While in some cases that might be the case, I would argue that it’s the exception rather than the rule. If you read my earlier post on Lean concepts of Voice of the Customer, I embedded a link to a Venn diagram depicting People, Process, Technology, where User Experience represents people.
But, you say, “Business stakeholders are people too!” And you’re not wrong, except that in the context of a business transformation project, the stakeholder represents the interest of the business, not necessarily that of the end-user. These do not have to be mutually exclusive, but in the case that there is a conflict of interest, it remains critical to ensure that the Voice of the Customer / User is brought directly to the project team for prioritization on equal footing wtih busienss and technical requirements.
What I’d like to do with the remainder of this post is provide a project-specific example that demonstrates the difference between user requirements and business requirements, and show how – in many cases and with the right commitment – both can be addressed in a meaningful and effective way.
The End User’s Problem
In 2005, I spent about 100 hours shadowing Large Enterprise Account Exectives (LE AEs, or sales people) at SAP. I saw them doing a lot of things, but I also saw them not doing a lot of things too. For example, I know that most of these guys make a lot of money, but I never saw anything that showed how they tracked their anticipated commissions, and I wasn’t aware that the company provided them with any tools to do so. So I started asking informal questions, to find out what they were doing to track their commissions. What I learned is that it was (understandably!) something they cared a lot about, but that our business systems at the time didn’t enable particularly well. In order to track the status of a commission, sales people often made phone calls into our Finance department – the Commissions group, Accounts Receivable, Treasury, and so on. One of the big challenges they faced is that each Sales Order (SO) might have multiple invoices associated with it, for example one is an SAP product (net 30 days), another a partner product on SAP paper (net 60 days), and so on. Therefore, the commissions check for each Sales Order was likewise distributed. Since the reps didn’t always know the detailed payment terms for each product they sold, they found it challenging to keep track of when their commission was going to be paid out.
Furthermore, the reps told us, a portion of their commissions checks were withheld for Customer Satisfaction, payable only if their region achieved the targets. But at the time, the reps were only afforded visibility into the satisfaction of their own customers, so they were frustrated because they had no way of knowing if they would receive the last part of their commissions payout or not.
My curiosity piqued, I worked with a few business stakeholders and end-users to diagram the business processes associated with Commissions – a real participatory design exercise, where salespeople whiteboarded the processes with us! One of the big take-aways for me was how little of the overall process was system-based. We built a process diagram in MS Visio, and then did an overlay to indicate area where the process step(s) had to occur in an SAP system. This approach provided visibility into which elements of the process need to be represented in a User Interface (UI).
The Business Problem
As an outcome of these explorations, I also held a number of discussions with employees in the Finance organization. I learned that the Commissions posed challenges for them, too. Account Executives (understandably eager for their commissions payouts) were making phone numerous phone calls and creating additional work for the Finance team.
At the same time, the Chief Finance Officer was focused on reducing the time it takes customers to pay SAP invoices. By providing visibility into upcoming or past due invoices, the business could make Account Executives at least partly responsible for ensuring the customer pays in a timely fashion. To be clear, visibility into invoices is not something the sales people necessarily wanted! The individuals I spoke to were concerned that administrative-type conversations with clients might detract from their ability to focus on the business strategy and value selling. However, the sales managers (VPs) felt that visibility into open invoices was key, both for themselves and their salespeople. In fact, some of the VPs I spoke to specifically asked for more transparency into open or late invoices. For example, I learned that SAP typically sends out maintenance invoices at the beginning of Q4, and that that payment is due before year-end. When a customer doesn’t pay the invoice in a timely way, it’s usually an indication that they are unhappy with the software or some aspect of their relationship with SAP. In other words, it’s an indicator of overall health of the relationship between the two companies. Further visibility into invoices by the saleforce would help to ensure that SAP could more proactively manage customer satisfaction – something that sales people do care about because (among other things) their compensation is tied to it.
The Outcome
Based on these and other findings, I recommended that we provide a sales (both rep and VP view) view into the Commissions system. I collected detailed business requirements, wrote a business case that demonstrated value to both Sales Operations and Finance, secured sponsorship, and ran a project to introduce a Commissions tab into the Sales & Marketing Workspace in the Corporate Portal, which is still in use today. The key elements of the UI include:
- A Dashboard that lists all invoices, along with the associated due date and commissions payout date. The invoices are organized in a hierarchy starting with the CRM Opportunity (as named by the rep), as well as the associated Sales Order(s) and Invoice(s).
- A list of past due and/or upcoming invoices.
- A snapshot of regional customer satisfaction targets and attainment (updated quarterly).
- Status of quota and Winners’ Circle attainment.
This solution has provided productivity and process improvements for both the field and finance organizations – a win-win! To come back to the original intent of this post, then, the perspective of both the end-user and the business stakeholder needs to be considered within the project context. Our task in User Experience is to ensure that the voice of the customer (in this case SAP employees) is an integral part of the process and related system improvements that are planned as part of our transformation journey inside of SAP.
Natalie Hanson 