システム管理に関わるベーシック情報やトレンドをご案内します!
開発と運用の壁。これがさまざまな問題を生む。開発担当者は運用を考えずにシステムをリリースし、足りない部分は「運用でカバー」の一言で運用担当者にナントカさせようとする。そして、たいてい火を吹く。なぜなら、リリース間際に対処しようとしても付け焼き刃の属人的な対応しかできないからだ。この状況、運用も開発も、何よりシステムを使う顧客やユーザも幸せにしない。運用をデザインしよう。この連載では、運用を主体的にデザインし、価値あるITサービスを提供できる人材になるための視点や行動を考えます。
今回は(1)の「業務運用/システム運用定義」についてです。(クリックで拡大)
システムを導入すれば、ハイはいおしまい!
残念ながら、そう思っている人や組織はいまだに少なくありません。
「クラウドを使えばすべてがラクになる」「AIで何でもかなう」「RPAさえ入れれば、現行の業務をチャチャっと自動化できる」
組織長クラスでも、このようなIT万能説を信じている人がいます。その結果、導入検討段階で、あるいは最悪、システムの利用開始直前になって火を噴く。
「えっ、業務側(=ITシステムを使う人、ITサービスの管理主管部門など)でやる作業があるの?」
「変更対応?システムが自動でやってくれるんじゃないの?」
「バージョンアップってなんですか?」
このような考慮漏れにより、予算をとっていない、運用体制を確保していない。その結果、サービスレベルの低い仕組みができあがったり、どこかでタダ働きによるカバー(いわゆる「運用でカバー」が発生したり、ユーザに無駄な作業を発生させたりと、悲惨な状況を生みます。これではITシステムそのものの評価を下げてしまいます。ユーザもベンダも幸せにしません。
「ユーザのITリテラシーが低いのが悪い」
そう言ってしまえばそれまでですが、私たちITサービス提供者側もきちんと予防策を講じていく必要があるでしょう。
業務側がすべきこと、システムがすべきこと。この2つがあることを事前に理解してもらい、システム導入後の世界地図を描くナビゲートをしたいものです。
とりわけ、業務側が行う作業。すなわち、業務運用は意識からスッポリと抜け落ちてしまいがち。
いままでITシステムの導入や運用経験の少ないユーザであればなおのこと、ピンと来ない。ITに精通した人であっても、上流工程(企画や開発)にしか関わってこなかった人はイメージしにくい。よって、運用経験豊富な私たちが水先案内人になりましょう。
以下は業務運用項目の例です。全部で12項目挙げました。
■業務運用項目の例
(1)運用スケジュール管理
(2)データ/マスタメンテナンス
(3)ユーザ情報管理/権限管理
(4)構成管理/文書管理
(5)インシデント対応/問題対応
(6)ジョブメンテナンス
(7)リリース対応
(8)調達業務/課金請求
(9)イベント対応
(10)訓練/トレーニング
(11)コミュニケーション管理
(12)サービス報告
日次、週次、月次、四半期単位、決算時期など業務スケジュールに応じてシステムに対しておこなうべき作業を一覧化し、スケジュールに落とす。やり漏れがないよう管理する。
システムが管理するデータ(例:売り上げデータ、顧客セグメント別の収益)を抽出したり加工したりする。各種コードやマスタ(部署コード、取引先マスタなど)を整備してシステムに提供する。
システムを利用するユーザIDを発行/変更/無効化する。必要な権限を付与する/剝奪する。
エンドユーザの端末の機器情報、OSやブラウザのバージョン情報、IPアドレス、ソフトウェアライセンスのバージョンや期限情報の管理などを行う。
必要に応じて更新をエンドユーザに促す。
ITIL®でおなじみ、インシデント管理。問題管理。日々発生するインシデントに対応する。インシデントが再発しない/未然に防ぐ対策を検討して実施する。
システムで行う日次の夜間バッチ処理、オンラインのバッチ処理など、必要に応じて変更の判断をする。
(例:決算時期は処理対象のデータ量が増えるため、バッチ処理の開始時間をはやめる)
システムの変更や機能追加を行う際の業務影響を判断する。エンドユーザへの周知や教育(新機能の操作説明や問い合わせ対応など)などを計画して実施する。
必要な機器やライセンスを発注する。エンドユーザにシステム利用料を請求する。
組織変更(統廃合)、年度末、決算期、オフィスレイアウト変更など業務イベントを事前に察知して、必要な運用作業項目を定義し実施する。
災害やセキュリティインシデントを想定した、復旧訓練/切り替え訓練などの計画と実施。
エンドユーザへの日々のコミュニケーション(システム利用手続きの周知、よくあるお問い合わせの整備、システムの便利な使い方を知らせるなど)を計画して実施する。
システムの利用状況、運用作業の実施状況、インシデントの発生状況/対応状況、ヘルプデスクの対応状況など、測定項目を定義して⇒測定して⇒報告する/社内共有する。そこから改善検討につなげる。
これらの項目は、オンプレミス型のシステムでなくても、クラウドでも発生しますし、RPAなどを導入する上でも多かれ少なかれ求められます。
システム導入検討時、あるいは利用開始前に抜け漏れなく検討されているか?実施担当者が決まっているか?ほかに業務側としてすべき作業がないか?
あらかじめ確認しましょう。
また、「自動化できるものはないか?」「どうやったら効率化できるか?」
このような疑いの目を持って効率化も検討したいものです。
業務側ですべきこと=業務運用項目が定義できれば、おのずと「どんなスキルを持った人をアサインすればよいか?」あるいは「業務側の組織にどんなスキルが足りないか」が見えてきます。
例えば、「(11)コミュニケーション管理」が必要だとあらかじめ分かっていれば、Webデザインが得意な人やエンドユーザとのコミュニケーションが得意な人(ヘルプデスク経験者など)をチームにアサインすることができるでしょう。計画的に人をアサインし、計画的に人材育成を行うことができます。
ただ単にいまいる人を頭数だけそろえて、いきあたりばったりで対応していては限界があります。「運用でカバー」で、都度対応を繰り返していては生産性も上がりません。
ところで、業務もシステムも生き物です。常に変化します。変化、すなわちライフサイクルに応じた対応をしないといけません。
次回は、(2)ライフサイクルマネジメントを解説します。
運用をデザインできる人材は、これからの時代、間違いなく価値ある人材として活躍の場が広がります。
目指せ、運用デザイナー!
沢渡 あまね(さわたり あまね)
1975年生まれ。あまねキャリア工房 代表。業務改善・オフィスコミュニケーション改善士。
日産自動車、NTTデータ、大手製薬会社などを経て、2014年秋より現業。企業の業務プロセスやインターナルコミュニケーション改善の講演・コンサルティング・執筆活動などを行っている。NTTデータでは、ITサービスマネージャーとして社内外のサービスデスクやヘルプデスクの立ち上げ・運用・改善やビジネスプロセスアウトソーシングも手がける。
現在は複数の企業で「働き方見直しプロジェクト」「社内コミュニケーション活性化プロジェクト」「業務改善プロジェクト」のファシリテーター・アドバイザー、および新入社員・中堅社員・管理職の育成も行う。これまで指導した受講生は3,000名以上。趣味はダムめぐり。
【ホームページ】
あまねキャリア工房
【ブログ】
はたらきかた「プチ」改善業務改善娘
【主な著書】
「システムの問題地図」
「職場の問題地図」
「マネージャーの問題地図」
「新人ガール ITIL使って業務プロセス改善します!」
「新入社員と学ぶ オフィスの情報セキュリティ入門」(共著)
「ドラクエに学ぶ チームマネジメント」
第8回:環境セットアップ/風土醸成 | [2019年02月20日] |
第7回:付加価値向上 | [2019年01月23日] |
第6回:オペレーションマネジメント(その2) | [2018年12月19日] |
第5回:オペレーションマネジメント(その1) | [2018年11月21日] |
第4回:コミュニケーション設計 | [2018年10月24日] |
第3回:ライフサイクルマネジメント | [2018年09月19日] |
第2回:業務運用/システム運用定義 | [2018年08月23日] |
第1回:いま、運用をデザインできる人材が求められている | [2018年07月25日] |
未ログイン: ログインする
コメント: ログイン(会員登録)すると、コメントを書き込むことができます。