When automated processes break down in the modern enterprise, who gets the blame - is it the internet security software??

The IT department, of course, with you, the CIO, called on the carpet to explain, without lapsing into the required technical detail, all your sins to people who don't really care why or who could understand even if they did, but simply want somewhere to place the blame.

Is this right and proper, though? Aside from all the various intricacies that accompany most technology breakdowns, should IT really bear the responsibility for all these processes... the number of which are being automated slowly increasing each year as technology evolves and improves?

Nick Malik argues that it should not be so, and I agree.

Nick's argument is fairly specific to process modeling, but it seems to me that it applies more broadly than that. In Nick's modeling scheme, processes which become automated are nonetheless to be represented as belonging to the department which was originally responsible for them... not the IT department, which probably doesn't have the core expertise to do the work itself anyway, just the technical knowledge and skills to automate it.

It had not occurred to me until I read his post how many of the most basic inequities in IT/business relations comes back to this basic misunderstanding over where ultimate responsibility for process lies. IT is perpetually under the gun to provide more functions to the business, only to find itself stung for trying to help when it suddenly is blamed for problems with the process.

It's long been a tenet of mine that IT should provide tools and support to the business units, not to attempt to replace them wholesale, but I had never made the leap to insisting that the business unit originating the automation or service requests retain ultimate responsibility for them. It's only appropriate, after all, that IT be held accountable for maintaining those technical systems which only it is capable of running... you can't hold business to account for functions it has no expertise performing. But what you can do is structure the reporting and running of automated systems so that IT doesn't wind up bearing the whole burden after they've been put in place. Designing systems so that they can be monitored by the business unit, and divorcing the full function from the automation component of the process as Nick suggests, might go a considerable ways toward getting the IT department out of the doghouse in many organizations.