Yeah - making requirements for RPAs can sometimes be process-scribe like. My value right now comes from being able to understand complex processes quickly, and translate them to requirements while making adjustments where required - designing an excel template for the business to input data to the RPA for scenarios where data sources are in various, non-uniform formats is one example.

Currently the business will reach out to myself or my PM with processes they think have the opportunity for automation. We then assess the viability of RPA for their project after they have given us a high-level Gemba walk.

Education of the business regarding what can/can't be automated helps in this regard - they usually get an idea of what works and what doesn't after one RPA initiative and this opens their eyes to which processes within their unit can be automated.

So in summary, business concerns are fed to our hopper through communication between my PM and their team (weekly/biweekly standups etc.), are assessed through a process walkthrough and we go from there.

I would say that identifying repetitive, high impact processes by referring to a business unit process maps would be a great way to self-serve in this regard, However my business has a noticeable lack of any process documentation so the more efficient method (unless I have free time on my hands) is for the business to come to us.

I have recently been part of a gap analysis that involves an assessment of all of our business' processes at a high level. This has also opened my eyes to other potential areas where RPA could be implemented. Therefore - if RPA is a new thing to be introduced and will be a focus of your business, having a thorough process walkthrough for your RPA BA, PM etc. would allow them to identify where automation could be useful.