What The Best Batsman In Cricket Teaches Us About RPA

Like most Americans, I know almost nothing about the game of cricket. In fact, the first time I watched a match, it was unintelligible to me. I've come along since then, and while I don't fully understand cricket, at least it doesn't seem made up as a goof on us Yanks to me anymore.

In learning about the game, though, I came across an interesting tidbit that I think has important parallels to succeeding with robotic process automation (RPA), and I thought I'd write it up.

Bradman the greatest

One of the best batsmen ever to play the game of cricket was an Australian named Sir Donald Bradman. Bradman was a master of a format called "Test cricket," which is a particularly grueling form of the game where a match is played over the course of as many as five days. (For those not familiar with cricket, the term "test" might be synonymous with "trial" or "pilot", implying something quick and easy. But in the context of cricket, test means a test of the competitors' endurance. This is just one of a thousand things I found confusing about this amazing game.)

Source

To give you an indication of exactly how dominant Bradman was compared to his peers, his career batting average was 99.94 runs over a career that lasted 20 years. The player in the number two spot has 61.87 runs, not quite 62% of Bradman's.

To accomplish this, Bradman's strategy was insultingly simple: hit the ball, on the ground, where there weren't any defenders. This is usually enough to get to the next wicket, for a run. Then, do it over, and over, and over again.

Knocking it

This is where the lesson for an RPA program comes in. Success in our field comes from consistent, unwavering, relentless performance. Don't swing for the fences. Hit ground balls, enough to put points on the board, then set your sights on the next one, and the one after that. Consistent. Unwavering. Relentless.

Do you have an automation opportunity with large benefits, but it will take nine months to build? Skip it or break it up into much smaller chunks that can be delivered incrementally. Better yet, work on something that can get to production sooner. Sort your automation opportunity list by level of effort, not benefits. I promise, the benefits you'll end up with will be far greater than what you'll get with a "swing for the fences" mentality.

I propose a rule: the most bots wins (MBW). Don't build anything unprofitable but focus on what you can get into production fast.

What works today won’t always work tomorrow

Bradman's technique was so effective that his team's biggest rival, England, developed an entirely new bowling tactic to defeat it. The new form was essentially, 'throw the ball at the guy.' And it led to such ill feeling between teams, that eventually the rules of the game had to be changed to discourage the practice. After initially being stumped by this obstacle, Bradman eventually evolved his technique to handle the new aggressive tactic. Similar evolutions are evident throughout his career, as he adjusted to different fielding styles, and even to his declining athletic ability as he aged.

In RPA, our 'opponents' are changing technology, technical debt, the disappearance of low-hanging fruit, and increasing expectations from our stakeholders. We must recognize the changes in the landscape and be responsive them.

Are you running into diminishing returns sending business analysts into your lines of business (LOBs) to find automation opportunities? Migrate to a citizen-led strategy for that LOB instead.

Is there a new SAP® rollout that will be retiring several of your robots? Insinuate yourself into the design process of that new rollout to determine where the next generation of bots will come from and make it easier to respond to the business in the future. Core system upgrades are a wonderful opportunity to retire bots, but they are often outdated by the time they are released. Giving the business the agility to handle that is the reason RPA practices exist.

Perhaps more than any other technical discipline, RPA punishes those who quit striving.

Protecting our legacy

Bradman's final at-bat (they call them "innings") holds one additional lesson for us.

On August 14, 1948, Bradman came in to bat for the last time to an emotional farewell and a standing ovation in London. He was facing a bowler (that's cricket for "pitcher") named Eric Hollies, who wasn't even born the first time Bradman played a professional match. This was Bradman's 70th innings, and he was four runs shy of the 7,000 he would need to average 100 runs for his career. Hollies' second ball bounced past Bradman and into the wicket, and Bradman's career was over, ending in a "duck". The man averaged over 100 runs per innings for 19.999 years, and then his final innings drops him below 100. Devastating.

The lesson is this. We are going to fail every once in a while. In fact, the whole premise of MBW is that we want to put ourselves into a position to have failures that we get to learn from, trusting in the end that we'll come out way ahead.

MBW: Most bots wins

It's more than just a good idea. MBW is part of the operating system of the fully automated enterprise™.

Read next: