On
The Museum of Curiosities on BBC4 radio one of the topics last week was ‘What
do you consciously do repeatedly which is stupid?’ One of the examples they
gave was a cleaner who cleaned the same lift twenty-five times in a single day.
He thought it was a different room on each floor!
Undoubtedly
funny but I’m not sure it answered the question because surely he wasn’t
conscious of the stupid action. It got me wondering about what I do repeatedly
that is stupid.
Figure 1
|
This
is clearly stupid. Not only is it time consuming performing all the manual
steps when the complete process could be automated, but it is very disruptive
to other activities, we have to drop everything and import the data when the email
arrives unexpectedly. And that’s only considering the impact on us, the client
emails the file and then has to wait an unknown amount of time for their data
to appear in the system – our support person might be on a tea break, in a
meeting or on holiday.
Last
week I was sat in a presentation given by the head of development at Lotus F1
and he showed a slide of his development team with their feet up reading books.
The caption on the slide said ‘Only ever employ lazy developers.’ Obviously the
picture didn’t reflect the sentiments of this expression.
I’ve
come across this suggestion a few times in the past, most recently in a
presentation by our CIO where he was talking about encouraging the business to ‘Automate
the Norm’. It’s the same thing, in other words you don’t want your developers
spending time performing manual processes when they could spend a little effort
up front to automate them and free themselves from the task in the future – not
so that they can put their feet up and read but perform some other more
productive tasks.
One
of my other colleagues illustrated this very nicely on his blog a few years ago
with the graph shown in figure 1. I’ve changed the labels to match what I’m
talking about here.
The
key to success with this graph is deciding at what point to write an automation
process, they aren’t always simple things to write and sometimes they require
ongoing maintenance (the graph doesn’t reflect this) so writing one before the
first manual iteration is probably not a good idea. Personally I put it off
until I get fed-up of doing it manually.
The
other thing that needs to be considered when creating the automation process is
what tools to use. If we want to introduce ‘Automate the Norm’ as a principle
in our IS team we need to ensure we have some design patterns and the
appropriate tools for the job.
If
we consider the data import example, SQL Server Integration Services (SSIS) is
pretty good at doing that but if the file of data is uploaded on a website by
one of our clients then getting an SSIS package to process the data and return
the results to the user is difficult. If the client is emailing the data file
to a shared inbox the task is even more difficult, I assume Biztalk could be
used in this instance but it’s not readily available (i.e. licenced) to everybody
in the team.
There
is one other wrinkle to creating automated processes to save time, lots of
people in our business are consultants and they charge the client by the hour,
if we automate the manual processes that they perform we reduce the number of
hours they can charge which affects our profit. This is an old fashioned
non-client centric mentality which thankfully we are slowly getting away from.
Now
what stupid things do I do repeatedly?