社内の大規模システムの入ったハード(サーバ+クライアント端末数十台)を

入れ替え、ソフトもバージョンアップします。

現在の社内には大規模システム導入の経験者がまったくいないため、
段取りがまったくわかりません。
(現在発注をかける直前段階です)

もちろんシステム業者にある程度任せっぱなしでもOKでしょうけど、
無知ながらも社内情シスとしては、業者にある程度突っ込みをいれたり
確認をいれながら、こちらが優位な状態で工程を進めていきたいと考えます。

そこで、導入準備段階~導入日~導入後において
「ここはきちんと確認しといたほうがいい」といったアドバイスや
システム業者は当日どのように動くかなどイメージが沸くように教えて頂けますでしょうか。
アバウトな質問で申し訳ありませんが宜しくお願いします。
できるだけ幅広い回答をお待ちしています。

回答の条件
  • 1人5回まで
  • 登録:
  • 終了:2011/07/31 09:16:42
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:Baku7770 No.4

回答回数2832ベストアンサー獲得回数181

ポイント75pt

 #a1です。ご丁寧なコメントありがとうございました。

 医療システムのコンバージョンということでしたら、状況はさらに複雑です。まず、業者側の体制をしっかりさせて下さい。大手のSIに在籍していましたが、医療のシステムはパッケージの開発元、ハードウェアの製造業者が複雑に絡み合っています。そのため責任の所在が曖昧となりがちですので、業者側に連携を取れるような体制の確立を要求してください。

 

 作業開始前からエンドユーザの参画を手配してください。今回機能改善は特にしないとのことですが、画面の見た目、操作性やレスポンスなどテスト段階での意見をちゃんと拾えるようにしてください。特にカルテや各種マスターのコンバートがちゃんと行われているかの最終確認はユーザ責任です。人員はあらかじめ確保しておきましょう。

 移行において、多分リースとの兼ね合いがあると想像しますが、OSやアプリの違い、アップグレードの適用などでトラブルが発生するのは常識と考え、スケジュールには余裕を持たせてください。最終的には何とでもなることが多いですが、無駄なエネルギーを浪費しないような手配をあらかじめしておいたほうが良いでしょう。リース会社を変更する場合は特にです。

 次にネットワークの多重化を業者が提案してきたとのことですが、これまでどれだけトラブルが発生したのでしょう?現場はどう対処して来たのでしょうか?確認が必要です。

 ネットワークを二重化しようが、事故が起きる時は起こります。業者が二重化することでそれへの対処法のための設備を外そうなどと言ってきたのならそれは断るべきです。二重化することで両方のネットワークの確認といった作業が増えるはずです。

 ある時片方を切ってしまった。もう一方が生きているのでそれに気が付かなかった。しばらくして残りの片方も切れてしまった。なんてことになればどうなるでしょう。それなりのチェックはできるように提案してきたのなら良いのでしょうが。

 最後に、導入後のサポート体制も確認しておいてください。サービスマンは何分で駆けつけてくれるのかなど確認しなければならないことは沢山あります。

その他の回答3件)

id:Baku7770 No.1

回答回数2832ベストアンサー獲得回数181

ポイント75pt

 システムがカバーしている業務と、特にソフトウェアを中心としたシステム構成を新旧共に記述してもらわないと、ちゃんとした回答はできません。

 そのため、一般論です。

 まず、

>無知ながらも社内情シスとしては、業者にある程度突っ込みをいれたり

>確認をいれながら、こちらが優位な状態で工程を進めていきたいと考えます。

とありますが、多くの失敗事例の中でも多いのがこの考えに基づくものです。

 無知なら、エンドユーザからの協力をも求めるべきでしょう。

 特に、現行システムの問題点や改善要望などについてのヒアリングは必ず行ってください。中堅企業での業務システムの運用を見ていると、手作業などでの対処が日常業務として行われていることが多々ありますので、これを機会に見直しを加えてください。

 また、テスト工程でのエンドユーザの参画は必須です。そのためにも早い段階から協力を求めるべきでしょう。

 二番目は予備予算の確保です。上記とも関連しますが、意外とコンバージョンでは想定外の事態が発生します。DBMSにしろ開発言語にしろバージョンが異なることで不具合が発生するものです。そういった場合、業者から追加費用を要求されることがあります。また、コンバージョンに伴って改善を行う場合にも後から追加費用を請求されます。業者からの追加費用の請求に対し、迅速に対応できるよう経営層への根回しなど事前に行っておいてください。

 三番目は社内体制特に業者との窓口の明確化、想定外の事象に対する費用負担はどちらが負担するのかなど二番目に挙げた追加費用の抑制への事前策となります。例えば経理部長が介入してきて結局グチャグチャにかき回しただけというのもよくある話しです。

id:kentaro_jpn

ご回答ありがとうございます。

大変参考になります。

今回のハード入れ替えは、機器類が単純に古くなっているからという理由で、

その機器類を入れ替えるに伴いOSをWindows7にしなくてはならず、

そうするとソフトウエアも7対応にバージョンアップしなければならないと

いう経緯です。

ちなみにソフトウエアというのは、病院の電子カルテと看護システムと医事システムという

どれも大規模であり、かつ3つは連動しているものです。

「仕方なくバージョンアップ」という感じなので、今回は特にユーザの改善要望などの

ヒアリングは行っていません。

機能もいくらか便利になる程度で、大きく業務フローが変わってくるところは

ないと思われます。

しかし発注直前になって、「ネットワークの2重化」や

「2重化しないにしろネットワーク機器は全て入れ替えるか」といった、

幅広いところまで決定する必要が生じてきて、知識がない分

不安が生じてきて質問した次第です。

2番目と3番目の件は非常に参考になりました。

他にも視野にいれておかねばいけないことがありましたら

お願いします。

2011/07/29 22:15:47
id:a-kuma3 No.2

回答回数4973ベストアンサー獲得回数2154

ポイント75pt

まずは、予算をきっちり決めることです。

契約後でも、あれこれ出てくるはずなので、本来、使える予算からある程度、余裕を見て、

少なめの数字を提示しておきましょう。

ベンダーがどこかは、敢えて聞きませんが、いわゆるソリューションを売り物にしたところでしょうか?

ソリューションを謳ってるなら、「この予算内で、ベストなソリューションを提示してくれ」という

姿勢で臨んで良いと思います。


多分、前のシステムとベンダーは同じだとは思うのですが、

運用の確認はしておいた方が良いと思います。

業務フローが、あまり変わらない、という想定であれば、今の運用がそのままできるかどうかを、

せめて、頻度が大きいところだけでも。


次に大事なのは、稼働後のサポートです。

多分、「パッケージ」という言い方をされてると思いますが、入れたらお終いじゃなくて、

稼働後のトラブルにどこまで対応するかをはっきり握っておきましょう。

多分、保守契約ということで、リプレースとは別契約のような気もしますが、

内容はきちんと確認してください。


入れ替え前に心配しても仕方ないかもしれませんが、気になるのは三つ。

  • Windows7 用のドライバは、まだまだ不安定なものが多い
  • 性能的な要件
  • データの引き継ぎ


業務用パッケージを入れる側としては、プリンタやスキャナのドライバの問題なんて、

うちの責任じゃない、というような逃げ方をされそう。


性能面については、なかなか契約書には出てこない項目なので、

稼動してみたら、機能は変わらないものの、劇遅みたいなことが無いとは言えません。


電子カルテですか?

それとも、オーダリング?

電子カルテだと、前のシステムのデータをどこまで使えるかが大事だと思います。

参照できるのは当然として、前のシステムで出たオーダを複写してオーダできるかどうかとか、

気になりますね。


RIS なんかは、そのままなんでしょうか?

契約内容に含まれてるとは思いますが、入れ替えないシステムと連携できることを保証するのが、

ベンダーなのか、病院側なのかは、はっきりさせておいた方が良いと思います。


システム切り替え時には、多少なりとも、システム停止を伴うと思いますが、

タイムテーブルを確認しておく方が良いでしょう。

事前に診察予約を新システムに入力しなきゃいけない、だとか、

病院側の作業もあるはずですし、タイムテーブルは、「日」単位になると思いますので。


ちょっと、とっちらかった回答ですが、参考になれば。

id:kentaro_jpn

ご回答ありがとうございます。

確かに「Windows7での実績は少ないが、とりあえず

今のところ問題は起こっていない」みたいなことは

システム業者も言っていました。

入替えるのは、電子カルテシステムと医事システムです。

オーダリングは入替えません。RISなども入替えません。

私の中では「ただのバージョンアップ」というのが頭にあって、

「過去のデータが修正できるか?」といった問題や、

「RISとの連携が保証されるか」というところまでは全く考えていませんでした。

単にバージョンアップといっても、データベース設計からガラリと変わる

こともあるでしょうから、やはり「過去データ(移行データ)修正可能か」

など細かい確認も必要というでしょうか。

プリンタ類はWindows7に合わせて全て入替えなので問題ないと思われます。が

確かにその他の周辺機器(スキャナ)については考えていませんでした。

こうして突き詰めていくと、いろいろありますね。

大変参考になりました。

病院システム複数の連携の部分がいまいち見えていないところが

私の不安の一番大きなところかも知れません。

ところで「ハード入れ替え+ソフトバージョンアップ」の場合は、

一般的な新システム導入時のような

「一度現地でテスト環境を作る⇒現地データをテスト環境へデータ移行⇒ユーザが数日間システム検証⇒本番環境へデータ移行⇒稼動」

といった、テスト的なことは一切ないということになるのでしょうか?

2011/07/30 13:55:39
id:a-kuma3 No.3

回答回数4973ベストアンサー獲得回数2154

ポイント75pt

ところで「ハード入れ替え+ソフトバージョンアップ」の場合は、

一般的な新システム導入時のような

「一度現地でテスト環境を作る⇒現地データをテスト環境へデータ移行⇒ユーザが数日間システム検証⇒本番環境へデータ移行⇒稼動」

といった、テスト的なことは一切ないということになるのでしょうか?

ぼくが知ってる範囲の電子カルテシステムでは、

バージョンアップだろうが、新規に構築だろうが、テスト系と本番系の2系統作るのが当たり前です。

医事と RIS も、ふつう2系統作ると思います。

これより小さい規模の部門だと、予算に応じて、テスト系を作ったり、作らなかったり、だと思います。


それに、ユーザの検証期間が無いのは、あり得ないと思います。

パッケージのバージョンアップが無くったって、実施した方が良いです。

ユーザ側にとっては負荷がかかる作業ですが、

問題の検出が稼動前と後、というよりは、検収前と後で、

ベンダーの対応は全然違いますから。

id:Baku7770 No.4

回答回数2832ベストアンサー獲得回数181ここでベストアンサー

ポイント75pt

 #a1です。ご丁寧なコメントありがとうございました。

 医療システムのコンバージョンということでしたら、状況はさらに複雑です。まず、業者側の体制をしっかりさせて下さい。大手のSIに在籍していましたが、医療のシステムはパッケージの開発元、ハードウェアの製造業者が複雑に絡み合っています。そのため責任の所在が曖昧となりがちですので、業者側に連携を取れるような体制の確立を要求してください。

 

 作業開始前からエンドユーザの参画を手配してください。今回機能改善は特にしないとのことですが、画面の見た目、操作性やレスポンスなどテスト段階での意見をちゃんと拾えるようにしてください。特にカルテや各種マスターのコンバートがちゃんと行われているかの最終確認はユーザ責任です。人員はあらかじめ確保しておきましょう。

 移行において、多分リースとの兼ね合いがあると想像しますが、OSやアプリの違い、アップグレードの適用などでトラブルが発生するのは常識と考え、スケジュールには余裕を持たせてください。最終的には何とでもなることが多いですが、無駄なエネルギーを浪費しないような手配をあらかじめしておいたほうが良いでしょう。リース会社を変更する場合は特にです。

 次にネットワークの多重化を業者が提案してきたとのことですが、これまでどれだけトラブルが発生したのでしょう?現場はどう対処して来たのでしょうか?確認が必要です。

 ネットワークを二重化しようが、事故が起きる時は起こります。業者が二重化することでそれへの対処法のための設備を外そうなどと言ってきたのならそれは断るべきです。二重化することで両方のネットワークの確認といった作業が増えるはずです。

 ある時片方を切ってしまった。もう一方が生きているのでそれに気が付かなかった。しばらくして残りの片方も切れてしまった。なんてことになればどうなるでしょう。それなりのチェックはできるように提案してきたのなら良いのでしょうが。

 最後に、導入後のサポート体制も確認しておいてください。サービスマンは何分で駆けつけてくれるのかなど確認しなければならないことは沢山あります。

コメントはまだありません

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません