Beyond Automation

  • I think I might agree on hiring. I continue to be amazed at some of the poor decision making I see about how you choose who to hire. Or how badly we miss in judging someone.

  • A few years ago, I was working for a company as an IT contractor for a business department. They had a few home-grown apps and I was improving/fixing them. There was a ton of work to do, so my manager decided to hire another consultant to do some of these other tasks. He had no IT experience and I could tell from my interview that he didn't really know what to ask people. I volunteered to sit in on the interviews and ask some questions.

    The first three people we interviewed really didn't know what they were doing and I told my manager that we'd need to interview some more people. His solution? He stopped asking me to sit in on the interviews. We hired someone who was marginally capable and when his project was due, he told us his laptop had "been stolen" the day before.

    He was fired, the work re-assigned back to me and we never tried to hire anyone else.

    --------------------------------------
    When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
    --------------------------------------
    It’s unpleasantly like being drunk.
    What’s so unpleasant about being drunk?
    You ask a glass of water. -- Douglas Adams

  • I am sure if we delve far enough into all of our processes, we could find some processes that just work better without automation. As mentioned - hiring is one of those things.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • I kept thinking about that word 'delay' and wonder if it's key to effective automation. If you press one button, or just rely on an overnight job, to execute a series of complex linked tasks you have to be damn sure there are no possible combinations/pathways that end in disaster. Which isn't to say this is not possible with a really good and well tested design. But there seem to be many situations where breaking up tasks into stages with a human sign off in between is safer. Even if you build your perfect foolproof system, someone in the future might input the wrong data, in the wrong way, or misunderstand the business logic. If no one eyeballs the output the problem could go unnoticed. More haste less speed sometimes I guess. So, given...

    - Tedious job 1

    - Tedious job 2

    - Tedious job 3

    I would be wary of...

    - All tedious jobs automated

    And prefer...

    - Automated job 1

    - Human check

    - Automated job 2

    - Human check

    - Automated job 3

    - Human check

    Remembering that during the automated jobs I can be planning that perfect system 🙂

  • Only problem there is that sometimes the "human check" part can involve almost as much work as just doing the job manually in the first place! Testing is actually one of those areas that I think *is* open to automation, anyway--there's a lot of drudge work in that which can be automated out.

  • True. I think I am assuming more of an eyeball for obvious 'daft' errors rather than a thorough systematic check. Perhaps the analogy is that of major disasters, like a plane crash. Several problems, maybe minor in their own right, stack up to cause a catastrophe. Putting a quick human check in at various key points might allow someone to pull the 'stop' handle.

  • In a way I think one of the critical things to remember when it comes to automating tasks is that quite often there are limitations to what you can reasonably do, and sometimes shoehorning the existing process into an automated solution is the wrong approach. With a long process there are some things which automate easily, while there may be elements that don't work so well. Of course you could automate those parts that are easy, and leave the remaining steps to be done manually, but you could also re-examine the difficult part and see if it could simply be changed. I've seen a few occasions where a process is done one way purely because it can be done manually, and it's easy to get into the mindset that it HAS to be done that way. That may be true, but sometimes the best solution may be to simply change the process to fit the automation. If you're lucky it will give you the exact same results, but at times you may decide that saving many hours of manual work is worth a slight reduction in results, especially where those results aren't necessarily very important to the business.

Viewing 7 posts - 16 through 21 (of 21 total)

You must be logged in to reply to this topic. Login to reply