2016年2月27日土曜日

ITILファンデーション 4.サービスデザイン

□サービスデザイン
サービスストラテジで明確にした要件をもとにITサービスの設計を行うこと

デザインする時に考慮すべきこと
機能性(ITサービスの機能・品質)
リソース(費用・スタッフ)
スケジュール(期間

4つのP
  • 人(People):プロセスを実現するのに必要な役割、人材像を明確化し、必要なスキル向上のためのトレーニング計画を策定し実践する。
  • プロセス(Processes):プロセス改善の目的(ビジョン)を明確化し、改善プロジェクト体制を構築し、 ITIL®のグッドプラクティスとのベンチマーキングにより改善課題を明確化して、作業フロー、手順書、重要業績評価指標(KPI:Key Perfomance Indicator)などを設計する。
  • 製品・技術(Products):プロセスの効率的な実行、作業負荷軽減、自動化による作業ミス削減のために、適切なツールを活用する。
  • パートナー(Partners):定型的な監視作業をアウトソーシングすることにより、作業負荷を軽減し、本来注力すべきシステム改善企画作業を推進する。
サービスデザインの5つの側面
サービスデザインでの設計対象のこと
・サービス
・サービスを管理するシステム、サービスポートフォリオ
・技術アーキテクチャ
・プロセスの活動、役割、責任
・測定方法と測定基準

サービスデザインパッケージ(SDP)
設計活動の成果物のドキュメント一式
・要件:事業要件、サービスの活用方法や場所 サービスの事業窓口
・設計:サービスの機能要件、サービスレベル要件、運用管理要件
・サービスライフサイクル計画:サービス移行の計画、運用戦略)

サービス自動化
サービスプロセスを自動化すること
《目的》
・サービス品質の改善
・ばらつきの減少による有用性、保証の改善
・コスト削減

自動化をするにあたり意識することとして
・自動化する前にサービス・プロセスの簡略化
・活動の流れ、作業分担を明確にする
・システムやプロセスとユーザの接点を少なくする(簡単なUI)
・単純・日常的でもないタスクとやり取りの自動化は急がない

□デザインコーディネーションとは
デザイン活動が円滑に進むように調整すること。

デザインコーディネーションプロセス
・サービスデザイン段階全体に関連する活動
複数のITサービスを新規に開発したり変更したりする場合に、適切な設計業務が行えるようにリソースと能力を調整する
①方針と方法の定義、維持
②設計のリソースと能力の計画
③設計活動の調整
④設計に関するリスクと課題の管理
⑤サービスデザインの改善

・個々の設計に関連する活動
個々の設計活動で、すべての要件が設計内容に反映されるようにする
①個々の設計の計画
コストやスケジュールの計画を立てる

②個々の設計の調整
関係者のスケジュール調整や顧客との要件の合意

③個々の設計のモニタ
後工程で手戻りが発生しないように
・合意した方法に従っているか
・他の設計活動と整合性があるか
・事業達成目標を支援する包括的な設計になっているか

④設計のレビュー、サービスデザインパッケージの引き継ぎ
・設計活動が方針や標準に従っているか
・すべての要件が満たされているか

□サービスカタログ管理
サービスカタログとは提供中/提供の承認がされているITサービスの情報が格納されているDBや文書

サービスカタログには
・事業/顧客サービスカタログ
顧客向けのサービスの詳細をまとめたサービスカタログ

門\部門営業1課営業2課営業3課人事総務広報購買
人事オンライン               
受発注業務1  
受発注業務2  
Webポータル     
電子メール   
ヘルプデスク   
・技術/支援サービスカタログ
全ての支援サービスの詳細をまとめたサービスカタログ


□サービスレベル管理
顧客と合意したレベルでITサービスが提供されているかを管理する
「サービスレベルアグリーメント ITIL」の画像検索結果

・サービスレベル要件(SLR)
 ITサービスへの顧客の要件のこと
サービスレベルアグリーメントの顧客との交渉時に使用される

・サービスレベルアグリーメント(SLA)
サービスプロバイダと顧客の間で交わされる合意

項目説明  
可用性サービス時間ユーザーが受けるサービス提供時間ただし、 メンテナンス時間 は除く24時間365日
サービス稼働率(サービス提供時間−停止時間)÷サービス提供時間100[%]99.7%
障害回復時間(MTTR)障害を検知 した時間から、障害が回復してユーザーがサービスを受けれるまでの時間1時間を越えないこと
障害通知時間障害が発生してから、ユーザーに障害が発生したことを通知するまでの時間30分を超えないこと
パフォーマンス応答時間一定時間(1時間)内の全トランザクションの95%が含まれる応答時間3秒以内(非ピーク時)5秒以内(ピーク時)
保全性データ・ログの保全性システム上のデータベース、ログの保持期間ログ7日間データベース31日間
を定義する。

サービスプロバイダはサービスが運用中も常にSLAの基準を満たしているかモニタリングを行い、必要であればサービス改善計画(SIP)を提出する

・サービスベースのSLA
単一のサービスを規定し、そのサービスを利用する全ての顧客を対象とするSLA
・顧客ベースのSLA
特定の顧客グループとその顧客が使用する全てのサービスを対象とする

・マルチレベルSLA
SLAを階層構造で管理したSLA
e)企業レベル→顧客レベル→サービスレベル

・オペレーショナルアグリーメント(OLA)
ITサービスプロバイダ内の他の部署と交わされる合意

・外部委託契約(UC Underpinning Contract)
ITサービスプロバイダと外部サプライやの間で交わされる契約

・サービスレビュー
サービスの達成度や翌期の課題を顧客と定期的に確認するミーティング

・サービス改善計画 SIP
プロセス・ITサービスに対する改善を実施する為の正式な計画のこと

・サービスレベルアグリーメントモニタリングチャート SLAMチャート
SLAが達成できているかをモニタリングする為の技法

SLA Monitoring Chart

<SLA状況一覧>
  ・SLA違反   
  ・警告レベル 
  ・SLA達成   
<日付別/サービスカタログ別に表示>
図5 SLAMチャート例

・サービスレベルマネージャ
SLA,OLAの文書化に責任を持つ。並びにSLAが満たされているか監視する

□キャパシティ管理
費用を最小限に抑えつつ、ビジネスのニーズを満たすのに十分なリソースを用意すること

・リソースとコストのバランス
・需要と供給のバランス

キャパシティ計画
SLAやITサービスの将来の要件からどの程度のITリソースが必要になるかを予測、計画すること
→ITリソースの投資計画

キャパシティ管理のサブプロセス
・事業キャパシティ管理
将来の事業要件の把握を行う

・サービスキャパシティ管理
現在のITサービスで使用されているリソースと使用状況を収集・記録・分析

・コンポーネントキャパシティ管理
ITインフラストラクチャを構成するコンポーネントのキャパシティ、CPU使用率、メモリ使用量収集、記録、分析する
《コンポーネントキャパシティの測定項目 例》
  • CPU使用率
  • メモリ使用率トランザクション・タイプごとのプロセッサ比率
  • IOレートとデバイス使用率
  • 待ち行列の長さ
  • ディスク使用率
  • トランザクションレート
  • 応答時間
  • バッチ処理時間
  • データベースの利用
  • インデックスの利用ヒット率
  • 同時ユーザ数
  • ネットワークトラフィック量

□ITサービス継続性管理
 ITサービスに深刻な影響を与える可能性があるリスクを管理する。
→災害時でもすぐにビジネスを復旧できるような計画策定

・事業継続性計画 Business Continuity Plan
ビジネスプロセス中断後にビジネスプロッスを回復する為に必要なステップを定義した計画

・事業継続性管理 Business Continuity Management
事業に深刻なインパクト与える可能性があるリスクを管理する

・ビジネスインパクト分析
サービスが中断することによる事業へのインパクトを定量化すること
→復旧すべきサービスの優先順位を決定することができる

・リスクアセスメント
事業のリスク(+/-関係なく不確実性のあるもの)を識別して脆弱性を評価すること

・リスク分析
リスクの識別と評価、コストに見合ったリスクへの適切な対応策を特定

・リスク軽減手段
把握したリスクを軽減させる計画を立てる

・復旧オプション
サービスの中断に対応するための戦略。
システム復旧のための戦略として、
手作業のワークアラウンド
相互協定、段階的復旧(コールドスタンバイ)
中間的復旧(ウォームスタンバイ)
高速復旧(ホットスタンバイ)、即時的復旧(ホットスタンバイ)

に整理される

□可用性管理
ITサービスの可用性に関するSLA目標値を満たす為にサービスを最適化、改善していくこと
・コンポーネント可用性
サービスを構成するサーバやアプリケーションなどの可用性

・サービス可用性
サービスそのものの可用性

可用性
サービス・コンポーネント・構成アイテムが必要とされた時に合意された機能を実行する能力のこと

     合意済みサービス時間ー停止時間
可用性= ーーーーーーーーーーーーーーーー ×100%
      合意済みサービス時間

信頼性
サービス・コンポーネント・構成アイテムが中断せずにどれだけ長く合意された機能を実行できるか示す指標のこと(どの程度故障しにくいか示す)

信頼性の指標は2つある
・平均サービスインシデント間隔 障害が発生する時間の平均
            使用可能な時間
信頼性(MTBSI(時間))=ーーーーーーーーーーーー
             中断回数
・平均故障間隔 合意済みの機能を中断なく実行できる時間の平均
          使用可能な時間ー総停止時間
信頼性(MTBF(時間))=ーーーーーーーーーーーー
             中断回数
保守性
障害発生後、どれくらい迅速かつ効果的に通常の稼働状態に回復できるかを示す指標

           総停止時間
保守性(MTRS)=ーーーーーーーーーーー
          サービス中断回数

各指標の関係性

サービス性
サードパーティサプライヤを信頼性、保守性、可用性を総合して構成サービスを評価すること

重要事業機能(Vital Business Function)
ITサービスが関わるビジネスプロセスの中で最も重要な機能を表したもの

拡張版インシデントライフサイクル
検出・診断・修理・復旧・回復の段階がある。
インシデントインパクトを増大させたすべての要因を把握し、インパクトをコントロール、低減させる方法を計画するときに使用する
ダウンタイムを減少させるために、各フロー毎のダウンタイムの計測などを行う


□情報セキュリティ管理
組織の資産、情報、データ及びITサービスの機密性、完全性、可用性が事業部門と合意したニーズに対応しているようにする

可用性・機密性・完全性を考慮して管理することを意味する。(バランスが大切!!)

機密性 情報を知る権限を持つ人だけに公開されている
完全性 情報が完全かつ正確で、許可されていない修正から保護されている
可用性 必要とするときに、情報を入手および利用可能なこと
「情報セキュリティのCIA」の画像検索結果

情報セキュリティ方針
情報セキュリティに対してどのように組織が取り組むかまとめたもの
一般的に
アクセスコントロール方針
パスワードコントロール方針
ウイルス対策方針
リモートアクセス方針
ITサービス、情報コンポーネントへのサプライやのアクセスに関する方針
を含める

情報セキュリティマネジメントシステム Information Security Management System
情報セキュリティ管理の目標を達成するための枠組み

□サプライヤ管理
サプライヤから投資に見合う価値を取得すること

サプライヤの分類
戦略的サプライヤ 戦略的機密情報を共有
戦術的サプライヤ 重要な商業活動でやりとりがある
運用上のサプライヤ 運用中のサービスの供給でやりとりがある 
コモディティサプライヤ 比較的容易にだいたい可能

契約
複数の当事者間における、法的な拘束力のある合意のこと

サプライヤ及び契約管理システム SCMIS
サプライヤの管理に使用される一連のツール、データおよび情報のこと

管理するもの
・各サプライヤが提供するサービス、製品の詳細、関連する構成アイテムの情報
・サプライヤとの契約内容

ITサービスの提供戦略 ソーシング戦略
アウトソーシング I
Tサービスに必要なリソースを外部から調達する
インソーシング  
ITサービスに必要なリソースを社内から調達する
コソーシング   
ITサービスに必要なリソースを外部と社内から調達する
パートナーシップ 
ITサービスに必要なリソースを外部から調達する
アプリケーション・サービス供給 
ASPが提供するアプリケーションを協定を結んで提供
ビジネスプロセス・アウトソーシング 
コストの安い地域にビジネスプロセスや機能をアウトソーシング
ナレッジプロセス・アウトソーシング
専門能力が必要なビジネスプロセスや機能をアウトソーシング
クラウド
需要に応じてクラウドサービスプロバイダにアウトソーシングする。

費用対効果とナレッジの蓄積、スピード感のバランスが大事




0 件のコメント:

コメントを投稿