The Cure for What Ails Your Remedy
Information Technology Service Management (ITSM) is, in a nutshell, an approach to managing everything in the IT lifecycle as a service, as opposed to just assets and technology. Most enterprises end up with huge ITSM systems (think BMC Remedy, HP ServiceCenter, CA Intellicenter, or ServiceNow). There are a few ITSM suites out there that can deliver the framework and required core capabilities for your environment; but your enterprise also has a lot of unique requirements, and that means a lot of customization in your ITSM systems. And, just like ERP systems, the ITSM customizations aren’t only upfront, but are constantly ongoing. The necessary evil of customizations brings about immense pain that manifests itself in production outages due to insufficient test cycles; exorbitant project costs; and crumbling RTO and RPO.
- Insufficient Environments – Everybody shares one instance. Perhaps just one non-Prod instance total. (Again, I know this from direct experience). This results in everyone waiting in line to do their work and the release process is always dependent on the last person finishing their tasks before the next stage can commence. (It can’t go to staging until the last QA engineer is finished). And when I say everyone, I mean Break/Fix, Dev, Training, etc. I can only personally name a few places where I have seen more than two non-production environments (total of three ITSM environments).
- Inadequate Data – The data in the non-prod environment(s) is often synthetic and seldom contains real data (usually the Calbro Services data + some synthetic transactions). And, if it does contain real data, it is a subset and almost never refreshed. ITSM environments can be huge! Having to copy and move that much data becomes a very labor intensive task. On top of that, ITSM systems, by nature, contain the most sacred details of your enterprise: Product Serial Numbers, Asset locations, Fleet info, Vendor contracts, Service Level Agreements, Employee SSN’s, Birthdays, Dependent information, Salary Info, etc. No CIO/CSO I know wants multiple copies of that data around.
- Inefficient Processes – How long does it take you to spin up a new ITSM environment? How long does it take you to back out of a failed patch? How long does it take you to restore or reset the environment? How long does it take you refresh your break/fix instance with production data when an issue arises? What about Friday at 4:30 PM? For any of those questions, can you describe the process? My guess is that if you are a Remedy manager, developer, or tester, your answer (days, weeks, months) would be far different than the answer of your sysadmin, dba, or storage guy (minutes or hours). Why? Because your process likely starts with, “I file a ticket…” and includes statements like “I then have to wait for …. And then I have to wait for… (*n)…and then finally…..” The sysadmins, dbas, and storage guys are awesome, but the process inherently is slow, even if the individual actions are fast.
Recent Comments