The lack of multiple program registration meant the RSC couldn’t handle a new client.
The Retail Service Center is a web app for submitting and managing point of sales data from retailers for compliance with trade programs. The app services two personas; the Retail Service Center (RSC) Representative and the Retailer. The RSC Rep manages multiple retailer accounts which include, onboarding of new retailer organizations and users, enrolling retailers into trade programs, and following up with Retailers to ensure that the data submitted is complete and error-free. The Retailer uses the app to send their data and check to see if their submissions have any errors. Once the data is submitted and passes the initial checks, it is released to the MSA’s matching system for cleansing after which it is released to the manufacturer client. Manufacturers used this data for analytics.
The intention of the app was to be able to handle data submissions for multiple manufacturer programs. However, to ensure we met a deadline for the pilot client some of the vital parts needed for multi-tenancy were not included. The most significant losses were being able to register retailers in multiple manufacturer programs and the automation of file certification & data validation. In the RSC file certification is making sure the files sent adhere to the program format, and data validation is making sure the data has been properly cleaned and is releasable to a manufacturer. MSA would be unable to handle another RSC client until these issues get fixed.
TEAM MEMBERS
John DeGore: Senior UX Designer, Robin Levy: Junior UX Designer
A lack of clarity about how much manual was required almost worsened things.
The Product Owner wanted to make multi-tenancy, being able to register multiple programs, happen ASAP but was looking to create band-aid solutions to make it work. The RSC Lead, the lead engineer, and I recognized that these short-term shortcuts would take more time to develop than the Product Owner was anticipating, and didn’t solve some of the bigger underlying problems of how much manual work, that should be automated, was being done. More manual work would be needed if these solutions got enacted. The result of this increase in manual work would lead to a huge quality control problem. Spending time on short-term solutions would divert vital resources that should be devoted to developing the automation needed to handle multi-tenancy. I along with another UX designer, Robin Levy, developed current state models to show where the inefficiencies were, and how the proposed solution wouldn’t help.
Being able to add a manufacturer organization to the RSC wouldn’t be successful without the architecture needed to support it.
One of the proposed solutions was to add the ability for an RSC Rep to create a manufacturer organization account and users inside the RSC. Having these were a part of the original plan, but the pilot client didn’t want it. So it was not developed. The Product Owner thought that adding this feature to the RSC would make it easier to add new manufacturer programs. They didn't realize that a manufacturer program would need a set of business rules developed and added to the system for there to be any value for a manufacturer user in the RSC. Adding a new manufacturer program would entail a multiple team effort.
I facilitated multiple collaborative sessions to develop a service blueprint for adding a new manufacturer to the RSC. A total of 8 different teams participated. I had each team write on sticky notes what tasks they knew they would have to complete to stand up another manufacturer. Then we worked together to put them in chronological order. The collaborative sessions were enough to info to show the Product Owner how much work was needed to add a new manufacturer, and they pulled back to reassess and develop a new plan. So, I only needed to create a high-level service blueprint using what we learned in the collaborative sessions.
A sample of the posts from the collaborative sessions.
Service Blueprint Draft for adding a new Manufacturer to the Retail Service Center
A poorly designed process leads to bad data getting sent to the client.
Both the file certification and the data validation checks for a data files submitted by retailers were manually completed. An RSC Rep was responsible for completing the file certifications, which meant manually viewing the submitted file and working with the retailer and potentially a client representative to alleviate any problems including data quality and format issues. Certification only had to occur for the initial data submission. After that, all the data quality checks got handled by the business analyst (BA). The BA would look at every submission. If there were any issues they would have to work with a client representative who would reach out to the retailer. After a submission was validated, the BA would have to inform an engineer that the data could get sent to the client. These processes didn’t work well, and a lot of poor quality data was getting sent to the client.
The issue was that after certification the data would automatically be released to the matching system. Certification only happened for the initial submission; this meant every submission afterward would be automatically released to matching. This lead to a lot of bad data getting into the matching system, and it created more work for the BA who had to try and fix it after the fact.
Adding more manual work would not solve the problem. Automation was needed.
The proposed solution for fixing the release of bad data into matching was to add a second manual check for the RSC rep. The second part was to create a BA user account, so they didn’t have to reach out the engineer anymore and could say the submission was ready for release through the RSC. The new check for the RSC rep would mean having to review every submission, which would increase their workload to an unmanageable point. Both of these solutions to would require a lot of development, and they were still highly error prone.
Automation was the solution needed, and to prove it, we made current state task models of the process. The development of the current state task models took longer than expected. We learned that client relations team played a larger role than anyone thought. Another huge finding was that everyone was managing statuses through shared excel sheets. Managing the certification and validation statuses through shared excel sheets was chaotic and would only get worse if another manufacturer program got added. The current state task models helped the RSC Lead prove to the Product Owner that focusing on automation instead of the new checks would be a more valuable use of resources.
Flow Chart of the Tasks involved n Business Analyst's Validation Process
Senior Software Engineer Creates Live Data File
Business Analyst Validates File Submissions
Client Relations Rep Validates File Submissions
Client Relations Rep Informs Retail Service Center of Data Issues
Retail Service Center Lead Assigns Operations Request To Retail Service Center Reps
Retail Service Center Lead Monitors Open Operation Requests
Retail Service Center Rep Processes Operation Request For Single Retailer Account
Retail Service Center Rep Processes Operation Request for Multiple Retailer Accounts
Retail Service Center Rep Fills Out Escalation Report
Client Relations Rep Contacts The Manufacturer Program Rep
Post Project Assessment
What went well?
The RSC was built in 3 months with a lot metaphorical tape holding it together. The RSC Lead and lead engineer knew about all the tape but were unable to communicate just how bad it was to the Product Owner. User experience research and modeling were able to bridge that gap and provide the Product Owner with better insights into those issues. This lead to resources getting realigned and focused on more sustainable solutions.
What could have been different?
I think some the Product Owner’s lack of knowledge was because there was no documentation around how the system worked. The initial release was on a tight deadline, but after that initial release documentation for how the system works should have been developed.
What’s next?
We avoided some potentially costly problems, but the interface still needs to be updated to handle multiple manufacturer programs. So an update to the interfaces needs to be designed and for when the engineers are ready to implement. Also, educating Product Owners about the value of documenting workflow.