見出し画像

運用とベンダー調整を任せたら、情報システム部の仕事はどう変わったのか｜支援実績

【公式】株式会社ディーシステム

月曜の朝、利用部門から連絡が入ります。

「画面が開かない」
「月次処理が進まない」
「新しく入った社員のアカウントが使えない」
「先週から、同じ問い合わせが何度も来ている」

情報システム部は内容を聞き、影響を確認し、関係するベンダーへ連絡します。

ネットワークの会社。業務システムの会社。端末を管理する会社。クラウドサービスの窓口。セキュリティ担当。場合によっては、利用部門の責任者にも確認しなければなりません。

それぞれから返ってくる説明を整理し、何が起きているのか、誰が次に動くのか、業務へどの程度の影響があるのかを伝える。

一つの問い合わせが終わる頃には、次の相談が来ています。

新しいシステムの導入検討。予算の見直し。端末の更新。セキュリティ対策。業務部門からの改善要望。ベンダー契約の更新。

どれも後回しにはできません。

ただ、こうした対応に追われるうちに、情報システム部が本来時間を使うべき仕事が後ろへ押し出されることがあります。

事業の変化に対して、次に何を整えるべきかを考えること。利用部門ごとに分かれている業務やデータを見直すこと。新しい技術を導入する前に、どの業務で使い、誰が確認し、どこで止めるかを決めること。障害や問い合わせから、次に直すべき運用を見つけること。

情報システム部が忙しい理由は、仕事の量だけではありません。

判断が必要な仕事と、定型的に回せる仕事と、複数の関係者をつなぐ仕事が、一つの窓口へ集まり続けているからです。

そのため、人が足りなくなると、「運用を外部へ出そう」という話になります。

ただし、作業を外へ渡すだけでは、情報システム部の負荷は思ったほど減りません。

問い合わせの受付を委託しても、判断が必要な案件は戻ってくる。障害対応を外部へ任せても、利用部門への説明や優先順位の決定は残る。ベンダーを増やせば専門性は得られても、全体を見ながら調整する人がいなければ、情報システム部は以前より忙しくなることさえあります。

外部化を考えるときに問うべきなのは、「どの作業を渡すか」だけではありません。

情報システム部が自ら持つべき判断は何か。外部パートナーに任せることで、どの仕事を安定させ、どの情報を見えるようにするのか。そして、情報システム部の時間をどこへ戻したいのか。

そこまで決めて初めて、アウトソーシングは人手不足への一時的な対応ではなくなります。


情報システム部の時間は、ベンダー調整だけで消えていく

システムが増えるほど、関係する会社も増えます。

基幹システム。会計や販売管理などの業務アプリケーション。ネットワーク。端末。クラウドサービス。ID管理。セキュリティ製品。データ連携基盤。

導入時期も、契約条件も、問い合わせ窓口も異なります。

利用者から「使えない」と連絡があったとき、原因がすぐに分かるとは限りません。

端末の設定なのか。ネットワークなのか。アカウントの権限なのか。アプリケーションそのものなのか。データ連携が止まっているのか。あるいは、利用部門の業務ルールや操作方法に関わることなのか。

情報システム部は、利用者の説明を聞き、必要な情報を整理し、関係する会社へ伝えます。返答を受け取り、追加で確認し、利用部門へ説明し、解決までの進捗を追います。

こうした調整は、不要な仕事ではありません。

複数の専門会社が関わる以上、全体を見ながらつなぐ役割は必ず必要です。

問題は、その調整だけで一日が終わる状態です。

問い合わせの内容を分析する時間がない。似たトラブルが他のシステムでも起きていないかを見る余裕がない。ベンダーの対応品質を比較する材料がない。契約上の役割と、実際に現場で起きている対応のずれを整理できない。

情報システム部が、会社全体のITを良くする部門ではなく、各所からの連絡を受け取って振り分ける窓口になってしまいます。

利用部門にとって、何でも相談できる窓口は必要です。

ただ、情報システム部が個別の依頼を受け続けるだけでは、同じ問題が繰り返されます。

ベンダーが増えること自体が問題なのではありません。

誰が全体を見ているのか。各社の役割が、実際の障害や変更の場面で機能しているのか。似た問い合わせがどこで増えているのか。利用部門が困っていることを、個別の対応で終わらせず改善テーマへ戻せているのか。

そこを見なければ、対応件数だけが増え、運用は少しも良くなりません。

外部へ任せるべきなのは、単なる受付や連絡の代行ではない

「問い合わせ対応を外部に出す」
「資産管理を委託する」
「ベンダー管理を任せる」

こうした言葉だけでは、何が変わるのかが見えにくいものです。

外部化の対象を作業単位だけで考えると、顧客側には調整と判断が残ります。

たとえば、問い合わせ窓口を設けても、一次対応者が内容を記録して別の担当へ回すだけなら、情報システム部の負荷は大きく変わりません。

利用者は問い合わせ先が変わっただけで、複雑な案件は最終的に情シスへ戻ってくる。情報システム部は回答を確認し、ベンダーへ追加の質問をし、利用部門へ説明することになります。

必要なのは、問い合わせを受け取ることではありません。

内容を整理し、優先度を判断し、誰が対応すべきかを見極め、対応状況を追い、繰り返される問題を改善テーマへつなげることです。

同じことは、資産管理でも起きます。

端末やアカウントを台帳で管理するだけでは、入社・異動・退職のたびに漏れが起きます。情報システム部に確認が集中し、利用部門は必要なタイミングで使える状態にならない。

外部パートナーが担うべきなのは、台帳を更新することだけではありません。

申請から承認、設定、利用開始、回収、廃棄までの流れを見直し、どこで確認が滞るのか、誰の判断が必要なのか、例外がどこで発生しやすいのかを明らかにすることです。

運用代行は、定型作業を引き受けることです。

トータルアウトソーシングは、定型作業、問い合わせ、障害対応、資産管理、ベンダー調整をつなぎ、情報システム部が判断しやすい状態をつくることです。

この違いを曖昧にしたまま外部化を始めると、顧客側は「任せたのに忙しい」と感じます。

VMOは、ベンダーを管理するためだけの役割ではない

複数のベンダーと契約している企業では、VMOという言葉が使われることがあります。

VMOはVendor Management Officeの略です。

言葉だけを見ると、ベンダーを管理し、契約を守らせるための役割に見えるかもしれません。

しかし、期限を確認し、報告書を集め、各社へ連絡するだけでは、情報システム部の代わりに事務を行っているだけです。

VMOに求められるのは、各ベンダーの説明をそのまま並べることではありません。

顧客の業務にどのような影響が出ているのか。今、誰が何を判断する必要があるのか。対応が遅れている理由は何か。ベンダーごとに品質や報告内容にばらつきがないか。

こうしたことを、顧客の立場で整理することです。

障害が起きたとき、ネットワークの会社はネットワークに問題がないと説明する。アプリケーションの会社は、システム上のエラーは確認できないと説明する。端末を管理する会社は、端末側の設定を確認していると説明する。

それぞれの説明は間違っていないかもしれません。

ただ、利用部門から見れば、「結局、いつ復旧するのか」「自分たちは何をすればよいのか」「業務への影響はどこまで続くのか」が分からないままです。

情報システム部が本当に必要としているのは、各社の担当範囲を説明する人ではありません。

情報をつなぎ、現時点で分かっていることと分かっていないことを分け、次の確認先を決め、顧客へ説明できる形に整える人です。

平時にも、VMOの仕事はあります。

対応時間が長引きやすい問い合わせは何か。再発している障害はあるか。定例報告の数字は、現場の困りごととつながっているか。契約上の役割と、実際に顧客側が負担している仕事にずれはないか。

こうした確認を続けることで、問題が大きくなってから初めて気づく状態を減らせます。

VMOは、ベンダーを厳しく管理するための役割ではありません。

情報システム部が、個別の会社とのやり取りに埋もれず、全体の優先順位を判断できるようにする役割です。

問い合わせは、利用者が止まっている場所を知る入口になる

パスワードを忘れた。画面が表示されない。申請方法が分からない。帳票が出力できない。権限が付与されていない。

問い合わせは、一件ずつ見れば小さな依頼です。

ただ、同じ種類の問い合わせが繰り返されるなら、そこには別の問題が隠れています。

マニュアルが現場に合っていない。業務ルールが変わったのに周知されていない。利用者が必要な情報にたどり着けない。画面の使い方と実際の業務が合っていない。新人や異動者が増え、教育が追いついていない。

問い合わせ件数を減らすことだけを目的にすると、利用者が問い合わせしにくくなっただけ、という状態も起こり得ます。

見るべきなのは件数ではありません。

どの業務で困りごとが起きているのか。どの部門に同じ質問が集中しているのか。自己解決できる情報はあるのか。回答しても同じ問い合わせが戻るのはなぜか。

こうしたことを継続的に見なければ、問い合わせ対応は受付作業のままです。

外部パートナーが問い合わせを受ける場合も、単に件数を報告するだけでは足りません。

問い合わせの傾向を整理し、利用部門の困りごとを分類し、改善候補を挙げる。FAQやマニュアルを直すだけでは解決しないものは、業務部門やシステム担当へ戻す。

その流れがあれば、問い合わせは運用の末端にある仕事ではなくなります。

現場の不便さや業務ルールの曖昧さを、最も早く捉える入口になります。

障害対応は、復旧したかどうかだけでは判断できない

障害が起きたとき、最初に求められるのは復旧です。

何が起きているのかを確認する。影響範囲を把握する。利用部門へ連絡する。必要なベンダーと連携する。復旧の見通しを伝える。

ここまでは、どの企業でも行われます。

ただ、復旧した時点で終わりにすると、似た障害が別の形で起きることがあります。

なぜ早く気づけなかったのか。最初の連絡で必要な情報は揃っていたか。ベンダー間の連携は機能したか。利用部門への説明は適切だったか。誰がどのタイミングで判断するのかは明確だったか。

障害への対応には、技術的な原因確認だけでなく、日々の運用の見直しが含まれます。

ただし、すべての障害に大きな再発防止プロジェクトを立ち上げるべきだということではありません。

影響が小さく、再発の可能性も低いものまで重く扱えば、現場は再発防止の会議だけで疲弊します。

だからこそ、発生頻度、影響の大きさ、原因の再現性、他のシステムへの波及可能性、業務への影響を見ながら、どこまで対策を行うかを決める必要があります。

情報システム部だけで、その判断をし続けるのは難しいものです。

外部パートナーには、各ベンダーと連携して事実を集め、対応経緯を整理し、再発防止の選択肢を示す役割があります。

最終的に、どこまで投資し、どのリスクを許容するかを決めるのは顧客側です。

しかし、その判断に必要な情報が揃わなければ、情報システム部は毎回、限られた時間の中で判断を迫られます。

トータルアウトソーシングが目指すのは、障害を代わりに直すことだけではありません。

次に同じ問題が起きたとき、より早く気づけるようにすること。担当者が変わっても、必要な情報が残るようにすること。利用部門へ説明するときに、何が分かっていて何が未確認なのかを伝えられるようにすることです。

情報システム部に残すべきことは、作業ではなく判断である

アウトソーシングを進めるとき、「何を内製し、何を外部へ出すか」という二択で考えられがちです。

ただ、実際の仕事はそこまで単純に分けられません。

問い合わせを外部に任せても、利用部門との関係を理解していなければ優先度は判断できません。障害対応を委託しても、事業への影響や顧客対応の方針まで外部が決めるべきではありません。ベンダー管理を任せても、どのシステムに投資し、どのリスクを許容するかは、顧客自身が持つべき判断です。

情報システム部に残すべきなのは、経営と現場に近い場所でしか決められないことです。

どの業務を優先するのか。どこへ投資するのか。どのリスクを許容し、どこで止めるのか。利用部門との間に、どのような合意をつくるのか。既存システムをどう残し、何を変えるのか。

こうした判断まで外部へ渡してしまうと、情報システム部は短期的には楽になったように見えても、将来の選択肢を失います。

一方で、外部パートナーに任せるべきこともあります。

日々の定例・非定例作業を安定して回すこと。問い合わせや障害の情報を整理すること。ベンダー間の対応状況を追うこと。運用上の課題を見えるようにすること。必要な情報を揃え、顧客側が判断しやすい状態をつくること。

外部パートナーは、情報システム部の代わりに経営判断をする存在ではありません。

情報システム部が、より重要な判断をできる状態をつくる存在です。

トランジションを急ぐと、顧客側の負荷が一度増える

外部化を始めるとき、多くの企業が早く運用を移したいと考えます。

人手が足りない。既存の担当者が退職する。システムが増えた。問い合わせが増えた。

急ぐ理由はあります。

ただ、既存の担当者やベンダーから新しい体制へ業務を引き継ぐ段階を急ぎすぎると、サービス開始後に顧客側への確認が集中します。

手順書があるから大丈夫とは限りません。

問い合わせ履歴、運用ルール、システム構成、契約内容、利用部門ごとの例外、月末や年度末だけ発生する処理。こうした情報が整理されていなければ、外部パートナーは判断できません。

特に難しいのは、文書化されていない経験です。

この部署からの依頼は、通常とは違う確認が必要になる。この障害は、まず特定の担当者へ連絡した方が早い。この帳票は月末だけ利用部門の確認が必要になる。

こうしたことは、日々の対応の中で積み上がり、個人の中に残りやすいものです。

業務一覧だけを渡しても、実際に問題が起きたときに必要な判断が渡っていなければ、外部パートナーは顧客側へ確認するしかありません。

結果として、情報システム部の負荷は一時的に増えます。

だからこそ、トランジションでは作業を移すだけでは足りません。

業務の優先順位。例外時の判断。連絡経路。ベンダーとの責任分界。障害時の初動。利用部門への説明方法。

どこまでを外部パートナーが判断し、どこから顧客側へ確認するのかを、実際の場面に沿って決めていく必要があります。

移管を早く終えることが目的ではありません。

顧客の業務を止めず、運用品質を落とさず、その後の改善につながる状態でサービスを始めることが目的です。

ITILは、手順を増やすためのものではない

問い合わせ、障害、変更、資産管理、ベンダー対応は、現場では別々の仕事として扱われがちです。

しかし、ITILの考え方では、これらを切り離された作業としてではなく、利用部門へ安定したサービスを届けるためにつながった活動として捉えます。

問い合わせが増えているなら、受付担当の人数だけが問題とは限りません。

変更時の周知が足りないのかもしれない。マニュアルが現場に合っていないのかもしれない。利用部門の業務ルールにばらつきがあるのかもしれない。

障害が起きたなら、復旧手順だけを見るのではありません。

検知は遅くなかったか。連絡は適切だったか。似た問題が他にないか。変更管理やナレッジの扱いに問題はなかったか。

ITILは、報告書や会議を増やすための考え方ではありません。

日々の問い合わせや障害から得た情報を、次の改善や意思決定へ戻せるようにするための見方です。

外部パートナーがITILの用語を知っているだけでは十分ではありません。

顧客の運用の中で、どの情報を残すべきか。どの会議で何を確認すべきか。どの数字を見れば、利用者の困りごとや運用品質の変化に気づけるのか。

そこまで顧客と一緒に決めることで、ITILは現場で使えるものになります。

外部化の目的は、人を減らすことではない

アウトソーシングには、コスト削減のイメージがあります。

標準化によって作業時間を減らす。役割分担を見直す。対応品質をそろえる。こうしたことは、もちろん大切です。

ただし、コストだけを目的にすると、外部化はうまくいきません。

単価の低さだけで委託先を選び、必要な確認や改善まで削ってしまう。顧客側に残すべき判断が曖昧なまま、担当者の経験だけで運用を続ける。外部パートナーへ依頼した内容を、顧客側が把握できなくなる。

短期的な支出は下がっても、数年後にシステムや運用を見直そうとしたとき、何を比較し、何を変えればよいかが分からなくなります。

外部化の目的は、顧客側の役割をなくすことではありません。

情報システム部が持つべき判断を明確にし、それ以外の仕事を安定して回し、日々の運用から得られる情報を次の改善へ戻すことです。

情報システム部が、問い合わせやベンダー調整に追われるだけでなく、事業や現場の変化に向き合う時間を取り戻す。

そのために、何を自ら持ち、何を外部パートナーと分担するのかを設計する。

トータルアウトソーシングは、単に人を置き換えるための仕組みではありません。

情報システム部を、会社の次の企画と判断へ近づけるための仕組みです。

ディーシステムのプロジェクト実績

ディーシステムでは、製薬ヘルプデスク、基幹システム統合、情報システム部支援、クラウド移行後の運用など、顧客現場で担ってきた役割と、支援によって生まれた変化を紹介しています。

ほかのプロジェクト実績は、こちらの案内記事からご覧いただけます。

▶ ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち

情報システム部の運用と役割分担を見直したい方へ

問い合わせ対応や障害対応を外部へ任せても、判断やベンダー調整が情報システム部へ戻り続ける状態では、部門の負荷は十分に減りません。

どの業務を外部へ任せるのかだけでなく、どの判断を自社に残すのか。問い合わせや障害から得た情報を、どのように改善へ戻すのか。複数のベンダーを誰が横断して管理するのか。

こうした役割分担を、実際の運用に沿って設計する必要があります。

ディーシステムでは、問い合わせ対応、障害対応、資産管理、ベンダー管理、VMO、運用改善を切り離さず、情報システム部が判断に使える情報を整えるトータルアウトソーシングを支援しています。

日々の対応に追われ、本来取り組むべき企画や改善に時間を使えていない。運用を外部化しているものの、自社側の調整負荷が減っていない。複数のベンダーを横断して管理する体制を見直したい。

このような課題がある方は、ご相談ください。

【情報システム部の運用・外部化について相談する】

次に読む記事

複数ベンダーを、誰が横断して管理するのか

情報システム部の負荷は、問い合わせ対応や障害対応だけから生まれるものではありません。

複数ベンダーの報告を整理し、課題ごとに担当者、期限、次の行動を結びつける役割も必要です。VMOの役割と、PMOとの違いを紹介します。

ディーシステムのほかの支援実績を見る

ディーシステムでは、情報システム部門の支援のほか、製薬ヘルプデスクのナレッジ整備、基幹システム統合、複数ベンダーの管理、システム導入支援などにも関わっています。

顧客現場でどのような課題を受け取り、どのような役割を担ってきたのかを、プロジェクト実績から紹介します。

長期支援では、役割はどのように変わるのか

長期的な支援は、同じ業務を続けることではありません。

顧客の組織、契約、システム、求められる役割が変わるたびに、必要な仕事を考え直し、支援をつなぎ直してきた過程を紹介します。