When starting this particular project, the project team debated which methodology to use. On the outset, we looked at it as a traditional project. The team consisted of seasoned project managers used to setting up and using PIDs. We had the budget, the scope and the resources. In other words; all set for a traditional waterfall approach using Prince2. However, the brief hinted at a bit of process re-engineering and software development which pointed in the Agile direction.
The client brief
To deliver a project involving programming a robot to access SAP at regular intervals, download 4 reports for more than 20 European subsidiaries (normally done by an outsourced Service Center in Eastern Europe) and then uploading them to a proprietary system using SQL server.
The benefits to the client would be a cost and efficiency savings with improved quality and accuracy.
The client is a multinational company with several well-known brands. We worked with the consumer electronics division with a large distribution network in Europe.
It was the client’s first implementation of an RPA solution and their management team was following it closely.
The European HQ near London had outsourced some of its back end processes to a Shared Service Center (SSC) run by a Business Process Outsourcing company (BPO) in Eastern Europe. The outsourcing had taken place recently and there were still processes being ‘ironed out’.
The robotic automation project involved automating 4 processes involving SAP BI. A number of reports for European subsidiaries had to be manually downloaded into a specific folder, then uploaded to a proprietary SQL system for further report handling and manipulation.
After being uploaded the reports were to be deleted from the folder due to their size. Processes meant that the SAP reports had to be downloaded at night time so that managers could peruse the reports the next day. The reports varied in size but not in format or data.
The old process was to download these reports during the day and then supply it to the managers the next day. This had previously engaged 3-4 employees in the SSC, though not on a full-time basis.
Thus: rule bound, regular, non-subjective work carried out by a user – perfect for Robot Process Automation.
Two methods – two approaches
As this project turned out to be part process development, part process re-engineering, the waterfall methodology might be too cumbersome and the agile methodology too fluid.
Using a traditional waterfall methodology, we would have used Prince 2 principles, initiating the project with a Project Initiation Document (PID). In the PID the roles, responsibilities, quality criteria etc. would have been defined. The project would have been run by one project manager who’d have resources and a pre-defined budget with set quality criteria from the outset. Any change in specifications or requirements would be noted would have been put to a steering committee.
Using Agile we would have started with a kick-off together with the client, then moved into sprint planning. The sprint planning would have been followed by programming of the desktop robot. It was to be followed by testing and a demo (the working robot). If, after the test, the robot was deemed stable enough, it would be deployed. This is usually iterated until it has been signed off by the client.
We opted to use the Agile methodology. Dividing the work into distinct packets enabled us to take stock at regular intervals. Changes or new requirements were noted and added to the next sprint. Over a period of 4 weeks, we had 5 sprints, each being iterative on the previous sprint.
The client was satisfied as new requirements were added and these could be accommodated in the next sprint. An added benefit was that it enabled us to learn and develop how the Robotic process automation interacted with SAP.
Programming was done during the week, with daily scrum meetings, leaving a version of the Robot which was tested at regular intervals to verify it was consistently completing the required process. SAP login, access and download proved to be surmountable.
Compare this to a waterfall approach where testing would be done at the very end, possibly compromising outcome and where new requirements would have jeopardised the project triangle.
Learning points using the Agile methodology
- Unlike the waterfall model, the agile model consciously limits the planning required to get started with the project. Agile assumes that requirements change in a dynamic environment.
- New or changing requirements were discussed during the daily scrum meetings. These were implemented at a low cost (in developer and tester time) because of the frequency of incremental changes. Each sprint provides for this.
- Having and discussing options in the daily scrum provided the ability to postpone important decisions until more reliable data became available. Thus, the project moved forward without reaching a sudden standstill due to missed or failed toll gate decisions.
Impact & insights when using Agile
In this project, Robotic Process Automation was not simply replacing people with process re-engineering – it results in process improvements.
Agile is not a panacea. Each client is different and so is each project. In this case, we were lucky to have a dedicated team and a communicative client who provided a clear steer on the outcome and bought into the Agile methodology.
Richard Ahl PhD is Program Manager at Clancarty Consulting Ltd based in London