Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

ddick
  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent melbourne.pm.org meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Monday June 04, 2007
09:16 PM

When to automate business functions

[ #33427 ]

Managers should (and mostly do) love automating stuff via computer programs. Less human intervention means less potential screw ups. This means more accurate reporting, which makes the managers life much easier. They can then drive a business with confidence. Unfortunately, whether to automate needs some consideration.

This entry serves as a temporary spot for some thoughts on how to decide that automation is the thing to do.

Firstly, if the ideal program was available tomorrow (off the shelf purchase), how much work would it save and how much work would it create upfront and on-going?

  • Does the manager have a really accurate view of what the staff do (New automation could slow them down)
  • Training requirements (support && operations)

This should produce the first rough number to help with purchase/development costs.

Off the shelf tech?

  • Hostage to vendors whims, release cycles and priorities (have to make do with what you have, and what you are going to discover)

In-House Development?

  • Time taken to produce a non-trivial program
  • Eliminating the edge cases

Secondly, automation can be a straight jacket. Once you are committed to a piece of tech, it's hard to move away. If the tech contains your business processes, changing anything will have another cost associated with it.

If business/legal requirements are liable to change (australian superannunation for example) every piece of automation will require work when a change comes through. If a vendor goes bust or retires the piece of tech, there is big trouble. Introducing new systems or retiring old ones also means data migration and systems integration, neither of which are famous for being cheap.

So the cost of migrating to and from the new technology need to be evaluated. A common line of thought is that buying from microsoft/ibm/sun means that the vendor will not go under, so this "futureproofs" the technology. Three words. Visual Basic 6.

Finally, the technology needs to have some sort of end of life timeframe associated with it. This may well be forever, but it's a good thing to keep in mind. Historically, how often has the company radically changed course? Introduction of computers, entirely new legal/business frameworks due to overseas expansion, business is bought/sold, etc. Most businesses have these sort of events happen a few times.

So, now, hopefully, you know what it would cost to procure the tech, install it, mantain it, remove it, how long you're planning on getting a benefit and how much that benefit is.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.