大金を使いシステム開発を依頼したがなぜ思う成果が出ない？
他業務との連携がうまくいかないのはなぜ？
陥りやすい基本契約のわな！

特集１／システム開発編

特集２／電子カルテ（Dynamics）

特集３／RsBaseサポート

特集4／ビジュアルな患者サービス向上

資料請求

電子カルテでの弊社の役割

TOP頁へ

１．大金をはたいて開発依頼を出したのに新しいシステムはなぜ軌道に乗らないのだろうか？

激動の世の中。業務改善し、コスト削減、売上UPへの人、物、金のシフトを考え、システム開発依頼しても、なかなかうまくいきません。なぜなら、御社では、あたりまえになっている業務手順程、システム要求仕様に計上漏れされることがよくあります。またオーダアプリケーションは人間対人間の打ち合わせの結果が成果物になってきます。システムエンジニアと打ち合わせが合う、合わない、その人(お互い)の得意、不得意も影響してきます。お客様の部門担当者と話す場合、その部門においては、詳細なことまで要求がでます。他部門は詳細内容がでないことが多いです。その場合は、担当チームを作るか、その部門だけから始めるのも１つの選択肢です。

２．では、どうしたら御社の意向とシステムエンジニアが意識あわせできるか？

一番大事なのが、御社の打ち合わせ担当チームの構成です。御社の儲けの構成を理解していて、現場の問題点を理解していて、どこを改善すれば少なくともこれぐらい利益増、コスト減が見込める。と言える人をメンバーに入れてください。次がシステムエンジニアの能力です。まず、システムエンジニアが一般的な業務知識を持っているかを判断してください。システムエンジニアはIT技術の習得のためには時間を割いて勉強しますが、一般的な業務知識は勉強する余裕、機会がないのです。例えば、売上管理の話をしているときに、そのシステムに必要な勘定科目の仕訳の話をしてみてください。仕入-買掛、売掛-売上、普通預金-売掛、買掛-普通預金、これでいくら儲かったでしょうか？という感じです。この程度の仕訳がわかっているシステムエンジニアであれば、話を進める価値はあります。わかっていなかったら、説明してください。これで御社担当者が、システムエンジニアは自社業務をよく理解していってる！と肌で感じるのであれば、システム開発を依頼しても大丈夫でしょう。肌で感じなかったら、システム開発を依頼しても出来上がりは、あまり期待できないでしょう。儲けのわからないシステムエンジニアに仕事を依頼して儲かるシステムになりますか？ましてや、月次、損益、固定費、変動費、損益分岐の話など、なかなかできないでしょう。

３．陥りやすい基本契約のわな

システム開発会社も、御社全ての業務フローを聞いてから、要求仕様を作成し、工数、見積提出し、金額の合意が得られないのでは、割があわないので、大筋のシステムの話（１０日から３０日の業務フローヒアリング）で、提案書、概算見積を掲示し、基本契約を結んでくれと言ってきます。この後、詳細打ち合わせ、設計に入るわけですが、実際にふろしき（システム詳細内容）を開けてみると、見積工数と業務依頼が大きくかけはなれていることが多いです。どうしてこのようなことになるのでしょうか？１つは、仕様の詰めの甘さです。どこから甘くなるのでしょうか？業務を理解できないシステムエンジニアと理解したと思う発注側の意識のずれです。またシステムエンジニアに完全に業務を理解させることは、ヒアリング時点では不可能です。現場に入り一緒に仕事をすればＩＴスキルはあるので、どうあるべきかを考えるのは非常に早いですが、それがないままでの打ち合わせなので、ずれがでるのはあたりまえだと思ってください。お互いがずれた認識のまま進んでいく原因は基本的な目標があいまいなことも関連します。目標が掲げてあれば、ずれも少ないのでしょう。ですから、目的は非常に重要です。原価管理なのか、原価削減なのか、そのためどういう根拠でそうなるのか、という具合です。業務の焼き直しの場合は、特に激しく、以前と同じ操作性を現場は要求します。経営者は、新たな区分などを作り、日次での原価把握、在庫の評価など、更に詳細なリアルタイムな管理が出来るのではないかと夢を膨らませます。ですから、システム打ち合わせは、現場とTOPとが両方入っているのが望ましいのです。社長様の考えるのと現場の考えは、逆であることが非常に多いからです。このような状況で基本契約を結んでもお互いが不幸になることが多いです。基本契約の前に、部分的な契約を弊社は提案します。明らかに導入のメリットが見えて、システム的にもクローズするところで一度、仕様を分けての契約です。例えば、一番めんどくさい業務をコンピュータ化する。もしくは、一番簡単なところから手をつける。もしくは、コスト構造が明らかに下がる点からシステム化する。という具合です。リスクを最小にとり、確実に進んでいくのも１つの選択肢です。
間違っても全社システムの基本契約を行わない方が得策です。少しずつ確実に規模を拡張していくのが得策です。全社システム仕様では、大きな仕様そのものは、もうその時点でずれまくってます。これで合意し、長い時間をかけて開発し、導入し、運用がうまくいかない。ここを変更してくれ、こんな意味ではない、とギクシャクしてきます。また、それは、仕様に無い、追加で頂かないと人は動かせない、という現場が実は、とても多いです。泣く泣く改造費を払うか、長い事かけたシステムを捨てるかの選択を迫られます。これは絶対に避けるべきです。
またあの会社に頼んだから大丈夫だ。は絶対にあてになりません。制作にかかわっているのは人対人ですから。打ち合わせ時点でのシステムエンジニアと意気投合できなければ、大きな看板に頼んでも一緒です。また、大きな看板はコスト体質が大きいので割高になりがちです。また、大きな看板には下請けがいます。お互い仕事が常に安定していれば直請けで作成しますが、どの業界も人件費のリスク分散を行うためにこのような体質はどうしても出てきます。これもコスト増大体質に貢献することにつながりますが。

４．既存システムの連携がうまく動けば安く済む？

各企業も現在では、財務、給与などのパッケージソフトは導入済みと思います。不思議と財務会計、給与計算はパッケージでうまく軌道に乗ります。ここに、販売管理、見積、原価、在庫などを導入すると突然うまく動かなくなります。しかし、各パッケージも他のシステムのデータ、及びデータの集計結果が読み込めるように努力はしてあります。しかし、マニュアルを開けば、業務内容の専門用語、コンピュータの専門用語のオンパレードで両方を理解できないと把握できず、よって、できない、と結論ずけてしまうケースもあります。この業務コンサルを行いうまく連携できれば、ローコストで省力化に貢献できます。さらに、ここへの集計（串刺し）を意識して、システム開発を行えば、御社独自の業務フローでも企業会計への連携が可能になります。既存システムを生かし、最小の追加コスト、ローリスクで少しずつ、システム連携を模索する方法もあります。ここで忘れてはならないのが、既存パッケージが変るケースです。変るのを前提に考えておくことは非常に重要です。このように既存システムと御社ニーズを組み合わせるだけでも膨大な時間、知識を要求されます。この調査を行う段階で業務コンサル契約を締結していただきます。

５．既存システムの調整が不可能ならば、足りない機能のシステム開発を考える。

現行の業務があり、既存のシステムがあり、どういう組み合わせでも難しい場合、足りない機能を作りこむための第一ステップに踏み出します。ここからが、システム開発契約になります。すべての機能を盛り込むのは、お互いリスクが高いわけです。御社の業務のわずらわしい箇所からスタートさせるのも選択肢の１つです。まずそこを軌道に乗せ、現場、経営のストレスを減らし、ステップアップしていくのをお勧めします。

６．第１システム開発の検証を行う。

どんなに優秀な人たちが集まって、綿密に打ち合わせても、稼動させると、意図しない動きが、必ず出てきます。出てこないときの方が問題です。システムが動いてない可能性があるからです。そこで、最低でも１ヶ月から３ヶ月、及び年度更新までは、気が抜けないのが実情です。そこで、機能漏れなのか、プログラムの抜けなのか、誤動作なのかをしつこく検証し、手を入れていかないと、なかなか優秀と思えるシステムに変化してきません。一発で動かせるのは、ハードウェア関連のときのみです。ユーザアプリケーションの場合は、いろいろ起こります。ここでしっかり検証し、仕様のミスかプログラムのミスかを決めなければいけません。だからプログラム仕様書とか、要求定義書とかはこのころになると非常に重要になってきます。記載されてない場合、どのように対応するかも、契約時に決めておくほうが、お互いもめなくて済みます。ほとんどの場合が、「甲乙誠意をもってこれを解決する」というあまい表現で契約を交わしますが、何も無しでは、お互い不幸なだけです。検証は非常に重要です。コストもかかります。無事システム開発、検証が終わり現場でも軌道に乗ってきたと感じたら、最初の予定通りに業務フローが改善したかの検証も必要になります。検証方法は、多岐にわたりますが、最終手段は使い手へのアンケート集計が良いでしょうか。ここでうやむやのまま、さあ次の２次ステップだ。と拡張すると、本当は第１ステップで問題があるのに、ここを修復せずに先に進むと怪我もまた大きくなります。目的と検証作業はとても大事です。

７．次のステップへの決断

第１システム開発が無事に機能しているのが確認できれば、次のステップへの決断を行っても良いです。たとえば、在庫管理が問題で、システム導入後、コンピュータと倉庫の情報がぴったりと一致し、そのための人手もスムーズになっているのでしたら、販売との連携を考えるという感じです。販売がうまくいけば、原価、財務への転記が可能か？という具合に進めます。

８．ブラックボックスの有無

大規模なシステムになってくれば、いろいろなハードウェアとの連携も必要になってくるのが一般的です。例えば自動倉庫の機械を動かすなどです。ここまでくるとブラックボックスの有無がシステム上に無いか検証が必要になります。例えば、自動倉庫を動かす場合のプロトコルの公開、それを実現しているモジュールが、ブラックボックスになってないか等を検証します。これも、いざ、機種を変える（故障時、償却時）とき、切り分けが出来なくなっていると、システム変更及び機種にどの程度、コストがかかるか見えなくなるからです。財務会計のデータの転記にしてもそうです。ご使用のパッケージが合併、吸収により変ってしまった場合、新しいパッケージはデータコンバートは提供してくれますが、他のシステムからの連携までは、保証してくれません。例えば、販売管理よりデータをCSVファイルなどで、読み込むような場合、本当に今までと同じか、知っておかなければいけません。またCSVフォーマットを変えるだけで、読み込み可能になるか？等なかなか判断がつきませんが、ちょっとしたことで今までどおり行かなくなったりします。同業他社との競合で社内システムをUPさせるにしろブラックボックスの有無の把握は重要です。

９．保守契約へ

各ステップごとに検証後、無事動作しだすと、どうしても、保守契約が発生します。作成の工賃は頂いておりますが、上述のようにシステムは生き物です。変化に対応した情報武装企業にするには、それなりの要員が必要になります。貴社で対応可能だということでしたら、それは、それですばらしい体制です。

ホームページ上では公開できない「システム開発編」、のノウハウを全公開！

医師の作った２つのソフトを現場で使いこなすノウハウ、事前検討項目、現場でよく発生する問題等の情報を「電子カルテ(Dynamics)＋RsBase編」として全公開。

資料をご希望の方は、こちらよりご請求ください。

★既存システムの調査から

★既存システム連携を模索

★経営者と業務フローの協調

★ミニマム投資での業務遂行

★検証

★これをくり返す