 |
||||||||||||||||||||||
|
||||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||||
|
||||||||||||||||||||||
| Cerveza開発以前の受発注システム | ||||||||||||||||||||||
|
Cervezaが動きはじめたのは1999年からだが、それ以前にメインフレームの端末エミュレータを利用した受発注システムが社内で動いていた。この時の考え方が今でも一部Cervezaの中に生きている。 |
||||||||||||||||||||||
| 受発注システムは止められない | ||||||||||||||||||||||
|
ニユートーキヨーでは、1992年頃にチェーン運営の効率化を目指し外食向け総合システムのテスト稼働をはじめた。外食で管理すべき重点課題は「売上」「勤怠」「仕入」であることから、売上分析システム／勤怠管理システム／食品物流システムの3つがその対象としてCOBOLで開発され、メインフレームの端末エミュレータ上で動いていた。しかし、1995年頃には売上分析システム／勤怠管理システムは利用されなくなった。 この理由について、テストシステムの完成度を上げられなかったことも理由の1つであるが、システムをどのように営業や利益に結びつけているかという方法論が十分でなかったことも大きかった。しかし不十分なシステムでありながら、受発注システムだけは継続稼動していた。前者の2つのシステム（売上分析システム／勤怠管理システム）と違い、受発注システムには仕入れ先という社外とのつながりがあったために、簡単に止めることができなかったのである。 |
||||||||||||||||||||||
| パッケージソフトウェアの著作権の問題 | ||||||||||||||||||||||
|
メインフレームのエミュレータ端末を使ったオンラインシステムには様々な限界があった。ユーザインターフェースの馴染みが悪いこと、動作速度が十分でなく、店舗での入力処理の負担が大きいことなどが問題になっていたのである。このためきちんとシステムを作り直す必要があった。 しかし、当時にメインフレームを離れるための選択肢はクライアント/サーバシステムとするのが一般的だった。しかし、ニユートーキヨーはこの開発手法に馴れていなかったので、自社開発には自信が持てなかった。そこで、パッケージソフトを検討することにした。多くのパッケージベンダーと話をしたが、いくつかの点でどのパッケージも不都合があったのである。
表1：国内外のパッケージの比較 当時整理した資料をひっくり返すと、上記のような表がでてきた。これらの問題点にも増して一番気になったのは、「パッケージソフトウェアの著作権は、カスタマイズ部分も含めてベンダーの物」だったことである。ビジネスモデル特許の件なども考えると、ユーザの業務知識はパッケージベンダーに独占されてしまうリスクがあったのだ。 |
||||||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
-
-
連載
