ITIL® Service Design
Description: www.gogotraining.com, 877-546-4446 Course Description GogoTraining is an ITIL® accredited ATO and this course fulfills all requirements to sit for your exam. This ITIL® online training course covers the lifecycle aspects of Service Design from a managerial/supervisory perspective, including – Service Design principles, activities and technology considerations. This ITIL® training also gives an overview – not the detail – of the Service Design Processes. Additionally the course considers the interfaces between Service Design and the other stages of the ITIL Service Lifecycle. ITIL® Service Design builds on the general principles covered in the ITIL® Foundation course. www.gogotraining.com, 877-546-4446
Very good question! Known Error Records (KERs) could be part of the Problem Record (PR), but could also be separate records (KERs)! If part of PR than stored in Configuration Management System. If separate records (KERs) then stored in Service Knowledge Management System (SKMS). So roughly: information/knowledge stored in SKMS, dynamic records stored in CMS, and static resource data stored in CMDB. Optimally everything is integrated and linked to and with each other.
Are LINKS (metadata) from Incident Records, Problem records and Known Error Records part and parcel of Configuration Management Database?
Please verify my understanding. Thank for your eye opening YT presentations
You say “like” alot.
It’s still a lot more positive than using the word “hate” a lot – LOL
Respond to this video…Yes, the Incident and Problem Management teams should have READ access to the CMDB, so they can link new Incidents and Problems to CI records. However, changing CI records should not be the responsibility of Incident or Problem Management. Updating CI records is a SACM responsibility. Of course certain activities can be delegated from SACM to other processes, but SACM will remain accountable!
Q1: Configuration management system has access through links to incident records, configuration management records and known error records, because records are created by Incident Management and problem management teams (problem record, known error record)? Please verify
Hi IslBeeBach:
Please verify my understanding about records.
Configuration Management System actually provides links (metadata) to records (Incident, Problem, Known Error)?
Incident (Incident Records) & problem management teams (Problem & Known Error Records) logs into Configuration Management System (CMS) to manage & use their records?
Please verify
Sure, I mean everything I say/write (well, mostly….
). Sorry for responding a bit late to your questions, CSU is literally drowning me in work, so I can’t always answer immediately, but your questions are valuable to support the understanding of the ITSM community. Ciao, IsleBeeBach
ITIL v3: You can raise a known error record at any moment in time, even if no workaround or solution to the error is available (typically used as a communication means). ITIL v2: You can only raise a known error record when you have either identified a workaround or a solution to the error. Personally I prefer the ITIL v2 approach, as it will push people to keep looking, rather than raising “empty” known error records. So, ITIL v2 and v3 are quite different in their approach!
Yes, the CMS includes the Incidents and Problems and these should be linked to each other as well as linked to CMDB data (CMDB), Known Error Records (SKMS) and for example various Release Management records (CMS). The idea is to keep the system fully integrated, open and flexible.
It’sa all about who is accountable/responsible for what type of records. You don’t want John of the Streets to modify CI data without approval. Hence, it makes sense to draw logical borderlines on who can add/modify/delete various CI, Incident, Problem, KER, Change, etc. records. Optimally all these records should still be linked and you really want one integrated database, rather than a whole bunch of loosely connected databases
Keep asking questions okay!
Do you really mean it? Thanks any away!