I've been having a discussion on a mailing list about the EQC data breech. The really funny bit is that I've only really heard about it from the mailing list but I understand it involves spreadsheets and email.
The prevailing opinion in the I.T. community is that I.T. have to be more responsive in providing the right tools for business processes. Something that I agree with wholeheartedly BUT I think it also fails on one very important point.
If a process isn't identified as a business process, and is instead seen as a "one off" (which just happens to happen again), then there's still a risk. So we're into the realms of the missing piece. The piece that we're oh so very guilty of forgetting. That is, people. If people are your biggest risk, they're also the first line of defence. Socialising the importance of particular data is always going to be far more important than the systems put into place.
Yet another reason why an I.T. person should be working with their users.
I responded to an email about systems in the classroom for keeping devices going. Of course this was pure Nevyn bait. I couldn't help but respond. It formed another thought in my head (admittedly, it's been kicking around in my head for a long time).
If I.T. support is such an expense, and those in support aren't entirely happy doing support (userfriendly was based on it and there have been horror stories since I've been using computers. This site covers this area fairly well too as does the show "The I.T. Crowd"), and those getting the support are feeling the technician's frustration as well as getting frustrated themselves, then perhaps we should be looking at things very differently. What this looks like to me is what we've been using for Manaiakalani.
Users are given admin rights to their own machines. Vital information is stored via network - preferably with tools that work to the businesses needs (i.e. out of the box is right out the window and instead solutions are designed around how that business operates) meaning that those business processes are captured and enforced via technical means but shouldn't leave the user wanting for more (though contingencies need to be put in place for adding functionality and how that functionality is realised i.e. should users be able to copy and paste data into a spreadsheet?). A quick fallback position is established (i.e. reimaging a machine to a consistent operating environment - those the consistent needs to be unenforced).
This frees up those technicians to do other things - coming up with sustainable solutions, working with users to capture needs more effectively (needs capture is done amazingly badly at the moment), working to create more sane defaults and the tools to manage larger scale deployments and businesses etc.
While I don't believe it would result in lesser expense, I think it would lead to less frustrated people and more value for money...