What do you get when you blend a software engineering project with a Service Design (SD) team? Initially, some awkward conversations around why the hell you are here. Having worked on both sides of the fence as an SAP SuccessFactors Consultant at Accenture, and a Service Designer at Deloitte Digital, I would like to share some of my experiences around this cross disciplinary approach to ERP Implementations. In 2019 ERP optimisation is a baseline requirement; efficiency around business processes, resources and data is a prerequisite. However, arguably the most important resource in this decade are your employees, and an increase in shareholder value should not be at the cost of your human capital. So where should your focus lie, business optimisation or employee engagement? This dilemma brings me to the introduction of Service Design meets SAP, an evolving love story.
Firstly, for anyone who is unsure about either SAP ERP or Service Design and the value that they bring, here is a quick overview:
Enterprise Resource Planning (ERP) essentially integrates and streamlines processes across HR, finance, supply, marketing etc., facilitating the flow of information between all of these functions in a single data base so that departments can easily share information and collaborate. Companies implement ERP software solutions to enhance business operations and increase customer response. I apologise for any SAP readers who feel offended by this extremely high-level summary.
Service Design is about analysing a service, and designing that service based on the customers’ needs. The focus is to simultaneously define the customer journey interaction and the corresponding business processes that drive this element of the service. This holistic approach drives the ethos that services should be designed to deliver a unified and efficient system as opposed to a “step-by-step” disjointed experience. It can be used to improve an existing service or build a new one, and the “customer” can be an employee, a member of the public, the government, really any form of end-user.
Then Service Design met SAP. It wasn’t quite like when Harry met Sally, however the cross-pollination of ERP and SD methodologies is arguably essential to the development of both practices. Software products are maturing, it’s no secret. Businesses are now not only focused on the economic outputs of ERP, they care about the way the employees interact with the product. Service Design shines that spotlight on seamless employee and customer experiences via personas, customer journey maps, and service blueprints, however this front end/back end strategy doesn’t instantly provide a change solution. Both SD and SAP are trying to improve the productivity and quality of services, but from very different, and increasingly complementary lenses.
The first blended learning for the two practices is around personas – what does it mean and how do we do it together?
Traditionally before launching into the design of an SAP system the SAP team would define all of the technical employee “roles” that will use SAP, outlining their permissions and views with the software. When Service Design came along, they made it clear that before diving into technical permissions, a deep understanding of your SAP users is fundamental to creating exceptional software.
The definition of a human-centric persona is a fictional character that represents a group of end-users with similar needs, goals and pains. Personas are built through end-user interviews and contextual enquiry, where designers can observe and understand how end users currently interact with a service/product. A persona is a way of communicating employee behaviours and needs, informing system requirements. By developing a human-centric persona before a technical persona in the design process, you are ensuring that you know the scope of the problem before designing the solution.
(I appreciate this persona is not software focused, I just really like the style)
The second blended learning for SAP and SD is around design workshops.
Design workshops within both practices serve the purpose of defining an end-to-end process, in order to outline the requirements or capabilities that are needed to deliver that process. The SD workshop approach focuses upon empathising with end users, gathering their needs, ideating around service solutions, before building a service blueprint to meet these needs. The SAP approach flips this flow on its head. SAP likes to start with a review of the end-to-end software process, and then asks end users will this work for you or will this require customisation? There are pros and cons with both style of requirements gathering, however a blended approach brings out the benefits of each.
By kicking off a design workshop by empathising with the employee needs and pains around SAP, we can immediately gather insights and prioritise requirements for the product. Armed with this knowledge, we can then progress into a demonstration of the software where we can align our employee needs with the capabilities of this product. This combined approach drives employee-centricity yet also the development of a tangible product. Often the fear with developing an “art of the possible” service blueprint is that nothing comes from it, and a lot of money and time can be spent on a large diagram of post-it notes.
I have chosen to focus on the Design phase within the SAP x SD romance, however throughout the 5 stages of any SAP implementation there are clear benefits that derive from a cross-disciplinary affair. Having worked on both sides I understand the potential limitations that art-of-the-possible Service Design or pure out-of-the box SAP can impose on a consulting project, and I urge software designers and service designers to collaborate more in the future. Design plays a significant role in creating SAP products, let’s shift the effort to understanding what people want before spending millions on implementing these products.