今回は、ITサービスマネジメントツールを使用した際に、サプライヤや協力会社との情報連携とアクセス制限を両立させる方法について取り上げたいと思います。
設計
インシデント管理や問題管理を行う中で、自社内でも役割が異なるチームや協力会社の方、外部のサプライヤの方と情報連携したい範囲と公開したくない範囲があるかと思います。そういった場合、以下のような流れで設計を考えていきます。
①必要な役割
登場人物や役割について確認を行います。
②プロセスフロー
登場人物や役割を考慮しながら、プロセスフローを検討します。
③役割単位での各プロセスのアクセス権限
登場人物や役割に対して、各プロセス単位でアクセス権限を与える
④役割単位での各プロセスレコードのアクセス権限
登場人物や役割に対して、アクセス権を与えたプロセスで、条件によってレコード単位でアクセス権限を与える必要があるか検討します。
例：とあるお客様の設計
ここで、あるお客様の設計を簡略化してご紹介させていただきます。
①必要な役割
- ＯＡサポート ：ＯＡ系のインシデントの受付、対応。
- 業務システムサポート ：業務システム系のインシデントの受付、一次対応。
- 保守チーム ：業務システム系の二次対応。全てのインシデントの確認と、問題の起票。
- 開発チーム ：問題の対応。
- サプライヤ ：業務システム系の問い合わせ先。
②プロセスフロー
＜OA系＞
- OAサポートで受付し、対応する。
＜業務システム系＞
- 業務システムサポートで受付し、一次対応する。
- 各サプライヤへの問い合わせがある場合は、問い合わせを行う。
- 場合によって保守チームにエスカレーションを行う。
- 必要に応じ、保守チームは問題にエスカレーションを行う。
- 開発チームは、問題の対応を行う。
図1．プロセスフロー
③必要な役割に対するプロセス単位でのアクセス権限を検討
- 問題管理 ：OAサポートにはアクセスさせない。
- インシデント管理 ：サプライヤには編集権限は与えない。
④必要な役割に対するレコード単位でのアクセス権限を検討
- インシデント管理 ：各サプライヤには関与するレコードのみ参照権限を与える。
図2．アクセス権限
このように検討していき、「図1．プロセスフロー」のように、サプライヤAのアクセス権限は、以下のようになりました。
- サプライヤAに依頼された内容のみ編集可能（ピンク）
- サプライヤAに依頼された内容に紐づくインシデントのみ参照可能（水色）
- 問題やサプライヤAに依頼されていない内容、サプライヤAに依頼された内容に紐づいていないインシデントは参照不可（灰色）
最後に
当たり前のことではありますが、登場人物の役割とどこまで情報開示をした方が良いか、情報開示してはいけないかをよく検討し、設計していきましょう。
情報を一元管理し効率化を高めると共に、機密情報を保守することが可能になります。
