I am not thinking of actual physical robots here like the ones building cars in a Toyota plant, though that would be a very interesting topic in itself. Rather, I would like to share some experiences I had in building software robots of the RPA fame at an organisation which is at the start of the process excellence journey with or without robots.
This is a very interesting experiment – given that we have some debates going on concerning the right way to chose in a such a situation.
Do we have to implement pure Lean first, as advocated by the purists and of course most all traditional lean consultancies? There is a famous lean percept saying that automatized waste is still waste, maybe even worse then non-automatized waste. This would mean, that we should postpone implementing RPA until the processes are optimized and waste mostly eliminated, then run a RPA initiative to gain the best of both worlds, lean sleek processes that also run in the most part automatically with the help of SW robots.
There is an alternative way to look at this situation, of course. You might say, that applying lean to a crusty old process that resisted optimization for many years is a waste of effort. Just pick the parts that let themselves to automatization, implement robots there and reap the benefits. Naturally, this will be the view of the RPA vendors. No other expertise is needed then the one to implement robots in the particular platform and benefits will start pouring in in a few weeks after the end of the implementation without any need to worry about obscure things like “cultural change” or “value streams”.
I am in a particular position having been both a SW developer and a lean consultant for basically the same (long) amount of time. Still, having had my share of failures and successes in process improvement (and software development) I am naturally leaning towards the second view – implement the robots quickly and either get the benefits or quickly discover the mistakes we made in the process. This is , funnily enough, the view people have, who tried to apply lean principles (or just common sense) to software development and came up with the Agile methodology in the 90-ies.
So, to come to the real story, I showed up at the organization in question, for one week of voluntary work (they are a well – known NGO) to start with them on the path of robotic process automation. I was very much focused on getting at least one robot to be functional and useful by the end of the week – being naïve and hopelessly optimistic, as most developers, I actually promised 5. I also completely neglected any preparation work, such as creating process maps and value streams – this time on purpose – thinking that we could not make a process map at the level of each keypress and mouse-click the way I needed for the robot and also because my receiving organization would not have had the time to prepare such maps even at higher levels of detail.
The first hurdle I hit was to find the first (and as turned out, only) process step to automatize. Here a detailed process landscape and process maps would have helped but lacking those we picked , sensibly enough, something where the process worker was available and what was deemed sufficiently important by the team (but, of course, during the robot development process we did have doubts, whether we picked the right choice or not but by then it was too late to change.)
The second hurdle was that I completely underestimated the impact of a non-standard environment in which the robot had to work. As an NGO, they had several IT solutions, all delivered by enthusiasts or volunteers, that were well suited for human operators, who will never care about windows tags and such, but a lot less standardised in behaviour then a system that would have used standard windows components. This made the development work a lot more strenuous as I had no way of knowing whether some trick I needed will even be possible within this framework, like going through a list of push-buttons and clicking them automatically in a given order. On the other hand, this is exactly where an RPA system becomes so much better than any traditional macro – and we hear often that RPA is nothing BUT a better developed macro. Well, that part of “better developed” and the possibility to manipulate windows descriptors, may be a small step as programming development goes, but it is huge step for an implementer, who is faced with an unknown system with poorly (or not at all) specified interfaces and a tight deadline. The RPA paradigm means in theses case the difference between “impossible” and “tough but doable”.
So, not without some hassle and way later than what I planned, I managed to build something what was, as I thought, a working and useful robot. Then, of course, came the third hurdle: it turned out that the process, as described by the colleague I was working with on the specification of the robot, was by no means the only way or even the accepted way of working on that process step. In short – my robot turned out to be not useful at all before the team worked out the right way of making that step. So, this is where, you could think, the lack of applying correct Lean methods came back to bite us. Had we had a Lean workshop first , we would have discovered the discrepancies and the lack of standard work before wasting time on the robot, and we would have fixed the problem BEFORE we started programming . Well ….. – this is true in a way. In an ideal world the procedure should definitely have been like this –running a Lean Workshop, building a process map, agreeing on standard work, implementing the robot with the standard version.
But, I have my doubts. We do not live in this ideal world and NGOs in particular do not have the time and money, and the motivation either, to spend a lot of time building process maps. The colleagues I was talking to honestly believed that they have only one standard way of doing the process I tried to automatize. Not because they were ignorants, but because they have many other priorities and as long as the process functions they have better ways of spending their time (and overtime – I basically did not see an 8 hour day during the time I was with them). Building the robot changes the optics – suddenly the process we are looking at will be performed by a mindless entity, which will not have the intelligence to discover and correct deviations from the standard . It will definitely build chaos instead, so, if we want (must) apply robots, we must make sure that these deviations will not happen anymore.
But his means that the strong motivation to look at processes and to standardize them comes AFTER the first robots were built –
It is in my opinion next to impossible to infuse this motivation as long as humans perform even the most boring process steps as well.
So, was my work for a week a failure – I do not think so. We all learned – and the company I worked for definitely learned that robots will only be as good as the standardization of the process steps we apply robots to. As a Toyota manager I had the chance to interview once stubbornly repeated – “No standard, no improvement”. This is even more true and important in the new era of Lean Robots than it used to be.
Now, to close – did I learn that we need a complete Lean Transformation before we implement robots? No, I still do not believe that. However, being careful pays off. I would still build a robot first, but I would emphasize a lot more (as befitting any Agile methodology) that we are building the version 0 only – the first, minimally useful product. THAT I would try to build even faster than I did it in this case. The moment this version is ready, the reality of what a robot can and will do hits home with the team – and then our users, customers and developers will get a lot of legitimate objections and errors discovered which., with any luck, will ensure that the next version will be something almost useful, but will certainly generate a new wave of tests, objections and such and so the cycle will move on to something legitimately useful. I strongly believe that this is the practical way of going forward with RPA – building more and more useful robots and learning at each step of the way.