How I automated my job?
Updated: Sep 24
“Practice what you preach or change your speech!"
I started in the knowledge work automation business as a Robotic Process Automation Solution Consultant in 2016. RPA wasn't a thing yet and I did not have that many peers. My job was to understand and find manual and repetitive actions, patterns, activities in office work, and build a business case for automating those using RPA. In the end, it was about finding manual activities that do not add value to the company.
I did this for many years even though my role changed towards managing teams and leading sales initiatives. But still, I loved to be out there, learning how people work, what kind of daily problems they face and what kind of routines they have.
I loved my job as it provided a holistic view of how people work on computers. I think that there hasn't been a more fitting role than being an RPA Solution Consultant to understand that before. It's a mixture of process development, new technology evaluation, and development of the way of working.
What I hated in my job was what most analysts do as a main part of their job, but is an essential precondition to analysis: data gathering.
If we take a single technology, let's say RPA. Then running an assessment workshop for a 50+ head department taking a couple of weeks calendar time. 80% of the content would however consist of understanding what is happening in that department. In a short time, you will land on the department floor and people there expect you to talk to them using the business vocabulary they are used to. And trust me, it’s not always financial and accounting departments, but also engineering departments for technical publications or spare part ordering processes.
As an analyst, you gather all information that you can get in your hands - like time registration data, process charts, and roles and responsibility descriptions. Sometimes you get a few documents which are in foreign languages or even cyrillic. If you’re lucky, there is a nice drawing. At least there is something you understand.
Then you start building your analysis - based on what is available for you. You ask questions, observe, document, and follow. The hardest thing is always to ask volumes or numbers of activities or tasks, because people don't know those. Typically, ballpark estimates are much off from actuals, but that's okay. The longer you work as a business analyst, you start to understand that people do not think of their work as a process or in transaction volumes. They just work on their daily tasks.
After a while, you start thinking about what is manual in the work you do. Typically business analyst work consists of activities where:
30% is data gathering, cleaning, and processing
30% is about analyzing that data and placing that into context
20% is building further your understanding about what is happening and trying to verify your earlier findings and hypotheses on the office floor
15% is evaluating automation opportunities and technology options based on findings
5% is final reporting and conclusion
Then it hits you. 15% of your work is value-adding, while 85% is just manual data gathering, processing, reporting, and calculations. Maybe that technology evaluation is also automatable?
Even though I have worked in a different role for several years, it hit me so hard that I had to solve this problem. I don't even know how much the world is spending on getting insights about their office work and tasks, but it must be billions.
That’s why we developed Workfellow.ai to automate my job and to free time from all business analysts to more meaningful work. Automating the manual parts of business analysis is both a relief and a huge opportunity for business analysts: getting direct to the evaluation phase saves lots of time and lifts the business analyst role to a solution maker.
Clips by Icons8