• 締切済み

OBC勘定奉行の汎用仕訳データ受入処理の所要時間

OBC勘定奉行は業務用パッケイジソフトのベストセラーであり、コストパフォーマンスの良さから弊社でも15年近くバージョンアップアップを行いながら使い続けて参りました。 ところが、マイクロソフトのSQLサーバー2005のサポート終了を理由に、勘定奉行21シリーズは2014年4月末でサポート終了となり、強制的にi8シリーズへの移行を与儀なくされました。 このバージョンアップアップに伴い、データベースの構造が変更され、結果として次のように「汎用仕訳データ受入処理」の所要時間が倍増となり、この機能を使用してきた弊社にとっては、事前のアナウンスも無い寝耳に水のシステムの改悪となっています。    伝票枚数 11,000枚 行数 27,000件    サーバースペック  CPU:Xeon E5-207(4コア/2 20GHz/10MBキャッシュ)  MEM:8GM :   所要時間 21シリーズ : 約21分   i8シリーズ : 約44分 コンピュータの世界ではスピードアップは使命であり、この結果を開発発売元のOBC様に提示し改善を申し入れましたが、有効な回答は未だに得られません。 そこで、止むを得ずハードディスクよりアクセス性能が格段に良いSSDを購入しSQLサーバー及び勘定奉行をSSDにインストールし実行しましたが、ほとんど改善効果は有りませんでした。 期末にはデータ件数も倍増するので、処理時間も1時間半を要してしまい、苦慮しています。 勘定奉行をお使いのシステム部門の方で、何か有効な手段をご存知な方がおられたらご教示願います。 又どうしても改善が出来ない時には他社パッケイジに乗り換えるために、この製品の返品(約100万円)及び移行費用(約300~500万円)のOBCへの請求が可能かどうか(勝訴出来るか)を教えて頂きたく、お願い申し上げます。

みんなの回答

  • don_go
  • ベストアンサー率31% (336/1059)
回答No.3

>コンピュータの世界ではスピードアップは >使命であり 残念ながら、そうでは有りません。 むしろ、機能を追加すればするほどスピード が遅くなるのが当たり前です。 遅くなる原因としては 1)入力項目や各種区分データ整合性チェック 、セキュリティチェック等の機能を追加した 事により、その分遅くなった。 #このぐらいなら許容範囲内で済むと考えた(?) 2)データベース変更で「汎用仕訳データ受入 処理」時に更新するテーブルが増えた。 3)データ数の限界値近くでのパフォーマンス (性能)テストが不十分だった。 (改善要求の優先度が低かった(?)) #開発用PCは、運用PCよりも実行及び開発に #必要な大容量のメモリを実装していたりCPU #の性能が高い場合があるので、運用PC(特に #古い機種)上での性能テストが不十分だった。 4)プログラマが下手だった(プログラムミス)。 等がありますが(ざっと思いついた分) SSDにしても改善しなかったというので、1)が とりあえず第一候補。 >有効な回答は未だに得られません。 明らかなプログラムミスでない限り早期回答 は困難です。 #他ユーザーで同様な症状(苦情)が出てない #場合も同様(再現性が無い場合)

hama-toshi
質問者

補足

早々に回答いただき有難うございます。 補足させていただきます。 >#他ユーザーで同様な症状(苦情)が出てない場合も同様(再現性が無い場合)   サポートセンターに問い合わせした時、及び営業マンに申し入れた時、弊社以外からも指摘がある事を  認識しておりました、

  • lv4u
  • ベストアンサー率27% (1862/6715)
回答No.2

No.1さんの回答にありますが、「伝票枚数 11,000枚 行数 27,000件」程度の処理で、21分とか44分ってのは、あまりにも時間がかかり過ぎではないでしょうか? どの部分に時間がかかっているのか、きちんと調査されたほうがいいように思います。 OBCは、技術提携しているソフトハウスもあると思いますので、OBCからそういう企業を紹介して調べてもらったらどうでしょうか? (私は、OBCのカスタム開発が必要なとき、OBCに技術研修を受けに行き、カスタマイズに必要な技術情報を契約後に公開してもらったことがあります。残念ながら、私は当時の企業は退社してしまい、情報は得られませんけど・・・) なお、裁判をしても、私も負けると思います。

hama-toshi
質問者

補足

早々に回答いただき有難うございました。 補足させていただきます。 >No.1さんの回答にありますが、「伝票枚数 11,000枚 行数 27,000件」程度の処理で、21分とか44分ってのは、あまりにも時間がかかり過ぎではないでしょうか?  OBC様での内部テストの処理時間を確認したところ、21,000件のデータで約24分との事でした。 これを27、000件に単純に換算すると、約30分となります。 >どの部分に時間がかかっているのか、きちんと調査されたほうがいいように思います。 OBCは、技術提携しているソフトハウスもあると思いますので、OBCからそういう企業を紹介して調べてもらったらどうでしょうか?  OBC様パッケイジソフトの処理時間が増加したのは、OBC様が解決すべき問題で、弊社が提携ソフトハウスに調査依頼する問題ではないと思いますが。 >なお、裁判をしても、私も負けると思います。  処理時間が倍増=処理性能半減 泣き寝入りしなければならないのでしょうか!?

  • seble
  • ベストアンサー率27% (4041/14683)
回答No.1

99.99%負けます。 汎用処理にそんな時間かかりましたっけ?1万件まではやった事ありませんが。 どうしてもなら、古いバージョンも同居させ(OSも別に必要かもしれませんが) そちらで勘定データに変換し、さらに新しいバージョンへ変換する方が早いかもしれません。 また、伝票数が多いので処理時間も仕方ないのかもしれません。SSDというよりCPUの問題です。 汎用データはテキストですから、数万件程度の読み込みに時間がかかるはずありません。読んだあとの処理に時間がかかっているのでしょう。8GMというメモリは分かりませんが、8GBなら不足は無いのでしょう、たぶん。 あと3つぐらい載せたら早くなるかも? 大番頭の方が良かったと思いますけどね。もう動かないしな。

hama-toshi
質問者

補足

早々に回答いただき有難うございいます。 補足させていただきます。 >99.99%負けます。 処理時間が2倍になったという事は、性能が半分になった商品を提供され、損害を被る訳ですが、それを甘んじて受け入れなければならないのでしょうか!? >古いバージョンも同居させ、そちらで勘定データに変換し、さらに新しいバージョンへ変換する方が早いかもしれません。  古いバージョンのデータを新バージョンへ変換するのに、同じ27,000件のデータ で50分程度かかるので有効では有りません。 >SSDというよりCPUの問題です  タスクマネージャーでのCPUの使用率は30%以下です。 >8GMというメモリは分かりませんが、8GBなら不足は無いのでしょう  仰せのとうり8GMは8GBの間違いでした。 >大番頭の方が良かったと思いますけどね。もう動かないしな。  他社パッケイジに乗り換えも検討したいのですが、損害賠償訴訟で勝算が立たないとです。

関連するQ&A