ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち
ディーシステムは、顧客現場で何を支援してきたのか。プロジェクト実績から見る仕事のかたち
ERP、IT運用、情報システム部支援、製薬業界のヘルプデスク、システム導入。
ディーシステムが関わってきた領域を並べると、支援範囲はある程度伝わるかもしれません。
ただ、サービス名や技術領域だけを見ても、顧客の現場で実際にどのような役割を担っているのかまでは、なかなか見えにくいですよね。
プロジェクトによって、扱う業務やシステムは異なります。
問い合わせ対応を支援する案件もあれば、基幹システムの統合、情報システム部門の業務整理、複数ベンダーとの調整、移転に伴うシステム導入を扱う案件もあります。
一見すると、それぞれ別の仕事です。
でも、実際の仕事を追っていくと、そこには共通する役割があるんです。
問い合わせへ答えて終わるのではなく、対応の中で得た情報を、次の担当者が使える知識へ変える。
システムを導入して終わるのではなく、稼働後に誰がどのように使い続けるのかまで整理する。
顧客部門、情報システム部、ベンダー、開発担当、運用担当の間にある情報と役割を整理し、それぞれが次の仕事へ進める状態をつくる。
この記事では、現在公開しているプロジェクト実績を、顧客現場で起きていた課題から案内します。
自社の状況に近いものがあるか、現場の様子を思い浮かべながらご覧ください。
現場知識を、次の担当者が使える形で残したい
製薬業界向けのヘルプデスクでは、問い合わせへ回答するために、ITの知識だけでなく、利用者の業務や過去の対応を確認する必要があります。
同じような問い合わせが来るたびに、担当者が過去のメールや記録を探し、経験者へ確認する。
こうした状態が続くと、対応に必要な知識が、いつまでも個人の記憶に残り続けてしまいます。
このプロジェクトでは、問い合わせ履歴を単なる対応記録として保存するのではなく、次の担当者が利用できる形へ整理しました。
何を確認し、どの情報を基に回答したのか。
同じような問い合わせが来たとき、どの資料へ戻ればよいのか。
回答内容だけでなく、その前に行った確認や判断まで残すことで、過去の対応を次の仕事へ使いやすくしているんです。
ナレッジが整理されていれば、新しい担当者も、最初から経験者へすべてを聞く必要はありません。
まずは過去の記録を確認し、今回の問い合わせとの違いを整理する。そのうえで、必要な点を相談できるようになります。
問い合わせ対応に必要な業務知識や判断が個人に依存している場合は、こちらの実績が近い内容です。
問い合わせ対応を、現場で使える知識へ。製薬ヘルプデスクのナレッジ整備｜支援実績
基幹システムと、周辺業務の接続を整理したい
基幹システムの統合は、新しいシステムが動いた時点で終わるとは限りません。
部門や拠点によって業務手順が異なれば、同じ機能を使っていても、必要なデータや確認方法は変わります。
基幹システムを統合した後にも、周辺システムとの連携、統合対象外の業務、例外処理、稼働後の運用が残るんです。
このプロジェクトでは、部門や拠点ごとの業務差異を確認し、システム上で吸収する部分と、運用で対応する部分を整理しました。
データはどこから入り、どこへ渡るのか。
周辺システムとの接続では、どの情報を受け渡すのか。
対象外となる処理は、誰がどの手順で行うのか。
障害やデータ差異が起きたときには、どこから確認するのか。
技術的にデータを連携できることと、利用部門が業務を継続できることは、同じではありません。
システム同士がつながっていても、利用者が次に何をすればよいのか分からなければ、実際の業務は進みませんよね。
業務、データ、周辺システム、運用担当の間にある条件を整理し、稼働後に誰が何を確認するのかまで残す。
そこまで含めて、統合プロジェクトの仕事になります。
複数の業務やシステムが関わる統合、データ連携、移行後の運用を整理したい場合は、こちらの実績をご覧ください。
基幹システム統合で、業務と周辺システムの接続をどう整理するか｜支援実績
情報システム部に集中している仕事を整理したい
情報システム部には、社内からの問い合わせ、障害対応、アカウントや端末に関する依頼、複数ベンダーとの調整など、多くの仕事が集まります。
一件ずつ対応できていたとしても、日々の確認や連絡に時間を取られ続ければ、システム企画や業務改善、将来のIT投資を考える時間は確保しにくくなります。
外部へ問い合わせ対応を任せても、判断やベンダー調整が情報システム部へ戻り続けている。
そんな状態では、業務を外へ出したはずなのに、思ったほど負荷が減らないこともありますよね。
必要なのは、業務を外へ出すことだけではありません。
どの対応を外部へ任せるのか
どの判断を顧客側に残すのか
誰がベンダーへ調査を依頼するのか
課題、期限、次の行動を誰が管理するのか
問い合わせや障害から得た情報を、どう改善へ戻すのか
こうした役割を整理する必要があります。
この支援では、問い合わせや障害への対応を引き受けるだけでなく、ベンダー連携、課題管理、期限、次の行動まで整理します。
目的は、情報システム部がすべての対応を手放すことではありません。
社内に残すべき判断と、外部へ任せられる業務を分け、顧客側の担当者が企画や改善へ時間を使いやすい状態をつくることなんです。
情報システム部の業務範囲や、外部との役割分担を見直したい場合は、こちらの記事が近い内容です。
情報システム部は、何を外部に任せるべきか。運用代行では終わらないトータルアウトソーシング
複数のベンダーを横断して管理したい
複数のベンダーが関わる環境では、各社が自分の担当範囲を完了していても、顧客の問題が解決しているとは限りません。
情報が別々の報告書に分かれている。
課題の担当者や期限が決まっていない。
責任範囲の境界で調査が止まっている。
各ベンダーから回答は届いているものの、顧客側が次に何を判断すべきか整理されていない。
こうした状態では、ベンダーとの契約が増えるほど、顧客側の確認や調整も増えていきます。
必要なのは、各ベンダーから届いた情報を、そのまま別の相手へ転送することではないんです。
発生している事象、影響範囲、確認済みの内容、未確認事項、次に必要な調査を整理する。
さらに、課題ごとに担当者、判断者、期限、次の行動を結びつけます。
複数ベンダーの間に残る情報、課題、責任を整理し、情報システム部が次の判断へ進める状態をつくる。
それがVMOの役割です。
ベンダー管理や運用移管、複数社を横断した課題管理を見直したい場合は、こちらの記事で詳しく紹介しています。
複数ベンダーを、誰が束ねるのか。VMOの役割とPMOとの違い
変更が続くシステム導入を、止めずに進めたい
本社移転に合わせて進めていた入退室システムの導入では、プロジェクトの途中で、移転日やシステムへの要望が複数回変わりました。
条件が一つ変わると、その部分だけを直せばよいように思えるかもしれません。
でも実際には、変更の影響は設定内容だけにとどまらないんです。
ベンダーの作業、サーバーの設置、インフラ条件、検証の順番、関係者の確認予定まで、影響する範囲を整理し直す必要がありました。
また、プロジェクトに必要な情報を、誰か一人がすべて持っていたわけでもありません。
製品の仕様は、システムベンダーが把握しています。
サーバーや基盤の条件は、インフラ担当が確認しています。
本社移転全体の日程や利用者への影響は、顧客側の担当者が見ています。
それぞれが持つ情報が違うからこそ、集めてつなぐ役割が必要になります。
異なる立場の担当者から情報を集め、変更によって何が影響を受けるのかを整理し、次に誰が何を判断するのかを明確にする。
変更が続く状況でも、関係者が次の作業へ進める状態をつくることが、このプロジェクトで必要になった推進力でした。
システム導入の途中で要件や日程が変わり、複数の担当者との調整が必要になっている場合は、こちらの実績が近い内容です。
本社移転の日程が変わった。入退室システム導入を止めなかった「推進力」｜支援実績
プロジェクトに共通する、ディーシステムの役割
ここまで紹介したプロジェクトでは、扱った業務も技術も異なります。
製薬業界の問い合わせ対応。
基幹システムと周辺システムの統合。
情報システム部の業務整理。
複数ベンダーの管理。
本社移転に伴うシステム導入。
サービス名だけで並べれば、別々の仕事に見えますよね。
でも、顧客現場で担った役割には、いくつかの共通点があります。
目の前の作業だけでなく、その背景を確認する
ディーシステムの支援は、依頼された作業を完了するところだけを見ません。
問い合わせへ回答するときには、なぜ同じ問い合わせが続くのかを確認します。
システム統合では、データを接続できたかだけでなく、稼働後にどの業務や例外が残るのかを確認します。
障害をベンダーへ依頼するときには、連絡を送るだけでなく、相手が調査を始められる情報をそろえます。
システム導入の条件が変わったときには、変更された内容だけでなく、その変更によって誰の作業や判断が影響を受けるのかを整理します。
目の前の作業だけを見ると、一件の問い合わせ対応や、一つの設定変更に見えるかもしれません。
でも、その作業が発生した背景と、その前後にある仕事まで見ることで、個別の対応を次の改善へつなげやすくなるんです。
業務とシステムの間にある条件を整理する
技術的に実行できることが、そのまま業務として実施できるとは限りません。
システム上で処理できても、権限、承認、実施時間、関連データへの影響を確認しなければ、本番運用へ載せられないことがあります。
基幹システムからデータを連携できても、周辺業務との条件が合っていなければ、利用者の仕事は進みません。
「システムではできるのに、業務では使えない」という状態が起きるのは、この間にある条件が整理されていないからかもしれません。
ディーシステムが確認するのは、「業務」と「システム」という二つの大きな分類だけではありません。
データ、権限、手順、例外、運用時間、完了条件、関係部門を一つずつ確認します。
そうして、技術上の処理を、顧客の仕事として実施できる形へ変えていきます。
複数の関係者が、次に動ける状態をつくる
プロジェクトが止まる理由は、技術的な問題だけとは限りません。
顧客部門、情報システム部、利用部門、開発ベンダー、保守ベンダー、運用担当の間で、
誰が確認するのか。
誰が判断するのか。
誰の回答を待っているのか。
次に誰が動くのか。
こうしたことが曖昧なために、仕事が進まない場合もあります。
情報自体はそろっているのに、次の行動が決まらない。プロジェクトでは、そんな場面もあるんですよね。
関係者から受け取った情報をそのまま転送するのではなく、現在何が起き、どこまで確認され、次に何が必要なのかを整理する。
それぞれの担当者が、自分の判断や作業へ進める状態をつくることも、プロジェクトを支える仕事です。
知識と判断を、次の担当者へ残す
一度対応した仕事が、担当者個人の経験に残ったままでは、次の担当者が同じ調査を繰り返します。
問い合わせ履歴やFAQ。
作業手順と例外条件。
テスト結果と影響範囲。
運用ルール。
課題管理。
エスカレーション条件。
こうした情報を残す目的は、文書の数を増やすことではありません。
別の担当者が過去の対応を確認し、今回との違いを判断したうえで、次の行動へ進める状態をつくることです。
記録があっても、何を見ればよいのか分からなければ、実際の仕事では使いにくいですよね。
回答や作業結果だけでなく、どのように確認し、どの条件で判断したのかまで残す。
知識と判断がチームに残れば、特定の経験者へ毎回確認する仕事を減らせます。
経験者自身も、同じ説明を繰り返すのではなく、例外対応や改善へ時間を使いやすくなります。
長期支援は、同じ仕事を続けることではない
ディーシステムには、製薬業界を中心に、約30年にわたって支援が続いてきた顧客があります。
ただし、同じ契約、同じ体制、同じ仕事を、そのまま続けてきたわけではありません。
顧客の組織や担当者が変わる。
商流や契約が変わる。
利用するシステムが変わる。
現場から求められる役割が変わる。
長く続いていると聞くと、同じ仕事を安定して続けてきたように見えるかもしれません。
実際には、変化のたびに現在の課題を確認し、必要な仕事と役割をつなぎ直してきたんです。
個別のプロジェクトだけでなく、変化の中で支援がどのように続いてきたのかは、こちらの記事で紹介しています。
約30年続いたのではない。変化のたびに役割をつなぎ直してきた
自社の課題に近い実績が見つからない場合
実際の現場では、問題が一つのサービス名に収まるとは限りません。
ERP導入後の運用が属人化し、問い合わせが情報システム部へ集中している。
複数のベンダーが関わっているものの、誰が次に動くのか見えにくい。
問い合わせ履歴は残っているが、次の担当者が使える知識になっていない。
システム導入を進めている途中で要件や日程が変わり、関係者の調整が止まっている。
いくつもの問題が重なっていると、「どのサービスを依頼すればよいのか」から迷ってしまいますよね。
このような場合、最初から依頼するサービス名を決める必要はありません。
現在どの業務が止まっているのか。
誰へ負荷が集中しているのか。
どの関係者の間で、情報や判断が滞っているのか。
過去の対応や判断は、どこに残っているのか。
こうした現場の状態を確認するところから、必要な支援範囲を整理できます。
ディーシステムのプロジェクトに共通するのは、目の前の作業を代行して終わることではありません。
業務、システム、人、ベンダーの間にある情報と役割を整理し、顧客現場が次の運用、改善、企画へ進める状態をつくることです。
自社の課題に近い支援を整理するために
ERPや基幹システムの導入後運用、情報システム部の負荷、複数ベンダーの管理、製薬業務の問い合わせやナレッジ、システム導入の進行など、課題が複数の領域にまたがる場合は、特定のサービスだけでは整理しにくいことがあります。
ディーシステムでは、現在どの業務が止まり、誰へ負荷が集中し、どの関係者との間で調整が必要になっているのかを確認するところから、支援内容を整理します。
自社の課題に近い実績が見つからない場合も、現在の運用や体制からご相談ください。
