ユーザーが依存するサービスに名前を付ける
サービスの担当責任、ユーザー、重要性、サポート時間、依存関係、構成コンテキストを記録し、中断や需要の優先順位を決定する前に考慮する。サービスコンテキストのないチケットは忙しいように見えても、重要な成果が見えなくなる可能性がある。
ITサービス管理ソフトウェア
チームの運用に合わせられるITサービス管理ソフトウェア
サービス、インシデント、リクエスト、問題、変更、コミットメント、回復チェック、改善作業を1つの設定可能な運用基盤で実行します。
ライブワークスペースは、チケット一覧だけでなく、ITSMチェーン全体を表示します。サービスと構成のコンテキストから始め、正しいライフサイクルを通じて障害や要求を追跡し、完了を観察可能な成果に結びつけます。
5ユーザーまで無料。クレジットカードは不要です。
コードを書かずに、項目・ワークフロー・ダッシュボードを調整できます。 1,000以上のアプリテンプレートと活用例を見る
最初のビューはクロスサービスコマンドセンターです。各意思決定の背後にある専門家のライフサイクルを確認するためにタブを開きます。
ライブ接続されたサービス作業
所有意思決定と次の行動
確認済み復旧と履行の結果
多くのチケットリストではなく、まずサービスと成果から始める
すべての記録が異なる運用上の質問に答え、次のチームが行動するための十分なコンテキストを共有しているときに、ITSMは有用になる。
作業を適切なライフサイクルにルーティングする
予期しない中断はインシデントとして扱い、標準的な依頼はサービスリクエストとして扱い、繰り返される障害は問題として扱い、制御された本番変更は変更として扱う。記録は関連付けることができるが、それぞれの目的を崩すことはない。
価値の証拠に基づいてクローズする
インシデントは、エンジニアがステータスを変更しただけでは完了とはなりません。リクエストは、タスクが割り当てられただけでは完了とはなりません。復旧、ユーザー確認、履行証拠、および再開された結果は、終了前に常に見えるようにしておきましょう。
各引き継ぎには、必要なコンテキストと意思決定を与えましょう
同じサービスでも中断、リクエスト、変更、改善作業が発生することがありますが、各引き継ぎは一般的なプロセスをコピーするのではなく、目的を保持するべきです。
中断に対応する
症状と業務影響を記録し、責任者を割り当て、安全に調査し、既知の頻度でコミュニケーションを行い、サービスを復旧し、影響を受けたユーザーに対して使いやすさを確認します。
計画された需要を履行する
明確な要求を提示し、必要なデータのみを収集し、適格性を確認し、承認をルートし、履行手順を完了し、内部活動から推測するのではなく依頼者に結果を確認させます。
防止と改善
再発を問題としてグループ化し、既知のエラーと回避策を文書化し、適切な変更を承認し、その是正措置が単に別のタスクを閉じるだけでなく、運用結果を変更したことを検証します。
記録を隠すことなくリスクと改善を可視化します
ダッシュボードはリーダーが介入すべき箇所を判断するのに役立ち、かつ基礎となるサービス作業への経路を提供するべきです。
影響と時間によって優先順位を付ける
影響を受けるサービス、ユーザーへの影響、重大度、経過時間、目標リスク、老化、次に約束されたアクションを一緒に確認します。リーダーが支援が必要なケースを見つけられると、合計が有用になります。
作業量とパフォーマンスを分ける
リクエスト量、インシデント量、対応時間、解決時間、再発、再オープン、ユーザー確認は異なる問いに答えます。それらを一緒に確認し、便利な一つの指標を成功の定義に変えないでください。
チームにシステム改善を任せる
サービスオーナーは、サービスが成熟するにつれてフィールド、フロー、ダッシュボード、自動化を洗練させることができます。すべての改善が管理され、テストされ、作業を行う人々に理解可能であるとき、この短いフィードバックループは価値があります。
チームが決定を下す必要があるレコードを選択する
明確なインテーク質問は、インシデント、リクエスト、問題、および変更の記録が同じ作業を競合するのを防ぎます。
| 状況 | 主要な記録 | 完了の根拠 |
|---|---|---|
| サービスが利用できない、または低下している | 事件 | サービスが復旧し、利用が確認された |
| ユーザーが定義済みのサービスまたはアクセスを要求する | サービス依頼 | 提供が完了し、依頼者が確認する |
| 類似のインシデントが繰り返し発生する | 問題 / 既知のエラー | 原因または回避策が管理され、効果が確認される |
| 本番環境を変更する必要がある | 変更 | リスクが承認され、実装および検証が記録される |
なぜJODOOが適しているか
チームがサポートするサービスにITSMを合わせる
Jodooは、サービス所有者に接続された記録、設定可能なワークフロー、役割別ビュー、モバイルフォーム、自動化、およびダッシュボードを1つのコード不要ワークスペースで提供します。
その結果、すべてのチームに過剰なスイートを押し付けるのではなく、サービスとともに進化できる集中型ITSMワークスペースが得られます。各ライフサイクルを個別にモデル化する
インシデント、リクエスト、問題、変更、コミットメント、および検証に対して、それらを結びつけるサービスコンテキストを保持しながら必要なフィールドと状態を与えます。
システムを再構築せずにルールを変更します
認可されたサービスオーナーは、サービスモデルの変更に応じて、フォーム、ルーティング、承認、ターゲットロジック、および管理ビューを修正できます。
すべての測定を作業に戻します
サービスの健全性信号から、それを説明するインシデント、リクエスト、変更、オーナー、意思決定、または検証レコードに移動します。
適応可能なITSMレイヤーのためにJodooを選択してください
サービスレコードと人間の意思決定にプラットフォームを使用し、専門的な技術制御はそれ専用に構築されたシステムで維持します。
強力なJodooの適合
あなたのチームには、接続されたサービスライフサイクル、設定可能な権限とワークフロー、モバイルキャプチャ、そして認可された構築者が変更できる透明な管理ビューが必要です。
接続するシステム
監視、ID、エンドポイント、通信、財務、調達、探索ソースを権威あるものとして維持し、必要な信号をサービス作業に渡します。
完全なITSMスイートを選ぶべき時
起動時に詳細な探索、完全なCMDB、イベント相関、ページング、エンドポイント管理、リモートサポート、あるいは大規模な事前構築統合環境が必要な場合には、専門スイートを選択します。
システムを変更する前にサービスチームが尋ねる質問
ITサービス管理ソフトウェアには何が含まれるべきですか？
最低限、サービスと担当責任を可視化し、インシデントをリクエストや問題と区別し、変更を制御し、サービスコミットメントを管理し、通信と証拠を保存し、サービス所有者が対応可能な結果を報告する機能を備えている必要があります。
ITSMソフトウェアは大規模なIT部門だけのものですか？
いいえ。小規模チームでも、特にスプレッドシートや受信箱に責任が隠れている場合は、明確な共有運用モデルから利益を得ることがあります。まず、一貫して運用できるいくつかのライフサイクルから始め、次のコントロールによって実際の価値が生まれる場合にのみ拡張してください。
ITSMワークスペースは監視ツールとどのように接続しますか？
技術的な検出と診断は監視またはオブザーバビリティツールで行い、有用な信号とサービスコンテキストをJodooに送って、担当責任、コミュニケーション、回復確認、フォローアップに活用します。
サービスオーナーは開発者なしでITSMワークスペースを適応させることができますか？
はい。認可されたビルダーは、コードを書かずにサービスフィールド、ライフサイクルステップ、権限、オートメーション、ダッシュボードを変更でき、これらの変更を管理・テストしたままにすることができます。
小規模なITサービスチームはJodooの無料プランで始めることができますか？
はい。無料プランは最大5人のユーザーをサポートしており、クレジットカードは不要です。そのため、小規模なチームが、より広範な展開の前に実際のサービスワークフローをテストできます。
実際に動くアプリを見る
自分のものを適応する前に完全なITSM運用モデルを確認する
通常、保留、期限切れ、ブロック、回復、再開、確認済みの事例を確認し、それからチームがサポートするサービスに関する記録やワークフローを変更します。
ITSMワークスペースを探索する