DBAs and the ITIL Framework

  • Comments posted to this topic are about the item DBAs and the ITIL Framework

  • I'm going to have another more detailed read through of this when I have more time, but I'd endorse everything that John says. I'm currently trying to get our ITIL team to implement some of this in our management tool for all of the databases that I manage. We're not there yet and our ITIL / Service Management tool isn't configured to make implementing this easy - but we will get there.

    I loathe performance reviews now because I have to spend hours documenting what I've achieved for every review, so automating the collection of that information and integrating with the management reporting my manager does will make life much easier!;-)

  • Thanks for the endorsement. It is a tough job keeping up with events without doing catch-up at review time.

    John.

  • We're doing this with Sysaid's ITSM solution. We have workflows in place for new customizations to our ERP system, feature requests, bug reports, patch installations, refreshing dev and pilot instances, as well as general IT helpdesk, infrastructure, asset tracking, monitoring, etc.

    It's made a huge difference in our ability to stay on top of our workload, even though we're a small team. (4 people in the entire department.)

  • We use ManageEngine's ServiceDesk Plus; however there are other tools that rock. Sysaid is one. OTRS is free and has a good ITSM module.

  • ITIL works, chaos doesn't.

    If you want to alienate either clients or business users ignore ITIL and just do releases any old how and never have a post-mortem when events reoccur.

    Too often the phrase agile is used to say that the ITIL process (or any process) doesn't need to be followed. To my understanding agile doesn't prohibit ITIL.

  • Yet Another DBA (10/27/2015)


    ITIL works, chaos doesn't.

    If you want to alienate either clients or business users ignore ITIL and just do releases any old how and never have a post-mortem when events reoccur.

    Too often the phrase agile is used to say that the ITIL process (or any process) doesn't need to be followed. To my understanding agile doesn't prohibit ITIL.

    Good thoughts.

  • ITIL: The Information Technology Infrastructure Library. Most DBA out there have heard of ITIL;

    I'm not sure this concept is ready to be referred to as an acronym.

    Having a change management system that you reliably apply is extremely important. The acronym de-jour, less so.

    412-977-3526 call/text

  • robert.sterbal 56890 (10/27/2015)


    ITIL: The Information Technology Infrastructure Library. Most DBA out there have heard of ITIL;

    I'm not sure this concept is ready to be referred to as an acronym.

    Having a change management system that you reliably apply is extremely important. The acronym de-jour, less so.

    Couldn't agree more.

  • Now I'm really motivated to take ITIL Certification.

  • Yet Another DBA (10/27/2015)


    ITIL works, chaos doesn't.

    If you want to alienate either clients or business users ignore ITIL and just do releases any old how and never have a post-mortem when events reoccur.

    Too often the phrase agile is used to say that the ITIL process (or any process) doesn't need to be followed. To my understanding agile doesn't prohibit ITIL.

    I couldn't agree more!

    Thanks

    John.

  • I was first introduced to ITIL about 10+ years ago.  I was, at first, extremely skeptical and agree with the article's comment that "it looks like a lot of bureaucracy".  By following ITIL's guidelines  (and doing a little picking-and-choosing of what guidelines to follow and what not to) I was able to expand both my team's ability to perform work (and cost of that work) and keep management apprised of what work was being performed (without adding to my workload).  

    A caveat here: to get to that point it took me several weeks of writing documents while performing my up-till-then usual day-to-day tasks.  This made for about 2 months work of 6-7 day work weeks with, on average, 15-18 hour work days.  However after that initial period I rarely had work days that lasted longer than 9 hours (unless there was an emergency).  I should also point out that there was no one else available who could assist me in my work AND I had been transferred into the department without knowledge of the 2 month deadline to get ITIL up-and-running for my team.

    I have introduced this concept to every company since that I have worked for.  Whenever I could convince the management, the improvements were always readily apparent after initial setup.  The teams/management I couldn't always pointed to the "extra effort" it would take to setup.

    Just my 2 cents...

Viewing 12 posts - 1 through 11 (of 11 total)

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