![技術語り-Tech Blog[JP]](https://blogger.googleusercontent.com/img/a/AVvXsEiYsL2e14T1O3H3pP9BUj4BxNQQDgWUK-pNhtt6X8syLNp1zvyRWOG_UEv_Gcanv4Nix1_-8MCZL02odSwi69Cbmp6WJeoNDX8f7GQSPH25NUW3dtNTkcGdKhA0sRemc7CD46aj4pMhd8WzzKViOuxBpGmZ5DaFru2sTTv9Jie9aXa98EppzJj1P3lUvyY=s175)
ITSM＋ITOMのDemo作成：
◆Demo画面
ITSM
①インシデント（社内問い合わせ）起票画面
②起票が自分のRequestとなる
③ヘルプデスクが一次受け
④ヘルプデスクが対応策を提示
⑤申請者が受け入れ
⑥解決
ITOM
①Macbookなどを含めた資産情報が管理対象である
②それ以外にも構成情報やサービスの一覧や詳細も管理対象となる。
システム監視マッピング図
例１：メールサーバ情報
インシデント例：メールサーバ異常といった時に上記図のような構成情報及びエラー情報（落ちているサーバ、異常のNW）を出すといったことは可能です。
例２；SAP FIに関するインストールやサーバ構成
③上記対応のReport
例１．資産情報のダッシュボード
例２．インシデント対応のダッシュボード
◆インシデント解決プロセス
- インシデント起票（Macbook）⇒ナレッジのレコメンド、起票された内容はMy Requestに入る
- インシデント受付：テンプレート文言、ユーザーアサイン、CI登録
- 既存ナレッジの添付と解決案の提案
- 起票者による受け入れコメント
- インシデントの解決
見せたい価値：ITSMプロセス、CI登録
◆ITOM
SAPの事例（他アプリケーション良いのがあれば）NWの事例
Dependency Map
サーバ構成が見れます。
QA
・インシデントの対応状況はどのように見れるのか？
⇒DashboardのIncident Managementを参照。期限切れ近くのインシデントやインシデントの標準解決時間を定義したSLAをもちいてService Managerの運用をサポートすること。
・自己解決率を向上させるナレッジはどういうことか？
⇒インシデントにナレッジを張り付けたり、よくうかがうインシデントは対応後にナレッジ記事化したりといった運用プロセスを作ること。あとはPortalの導線を整えること。
・Service Mappingのものはインシデントに紐づくか、また異常系は見えるか。
⇒Yes。DatadogでもAWS CloudwatchでもDynatraceでもあるいはローカルの情報でもいいですが、ログや異常値をServiceNowに送信できます。その情報をもとにインシデントを自動起票して、解決に導くオーケストレーションも可能です。作ろうと思えば。
当然作成時間はもらいますが、Figibilityといいますか、実現可能性はある作業です。
