紙からシステムへ在庫システム導入事例 中編
okahiro
前編では、システム化の依頼をして頂いたお客様の状況などをお話ししました。
話をしてわかったお客様の悩みは、
- 扱う商品数を増やしたい
- 商品数に比例して作業時間が増える
- 帳簿のスペースを減らしたい
でした。
中編では、実際にシステム化に取り掛かるまでを書いて行きます。
4. 要件定義
私はお客様から状況をヒアリングして、どのようなアプローチが行えるか一度持ち帰ることにしました。
私たちはお客様からヒアリングした内容を元に、システムに必要な機能を考えます。
システム開発の世界ではこの工程を要件定義と言います。
必要な機能を列挙すると
- 商品情報
- 商品検索
- 在庫状況
- 出荷処理
- 入庫処理
- 在庫高計算
- 全部のデータを管理するデータベース
ヒアリング内容は網羅できていますね。
機能別にどのようなことができるか簡単に考え、
機能ごとの画面構成とデータの連携方法をおおざっぱに考えました。
簡単にとかおおざっぱにとか言うと適当な会社か？と思われるかもしれませんが、
要件定義ではあくまで必要な機能を考える工程です。
どのように作っていくかは次の設計と言う工程で行います。
加えて機能ごとに見積を行い、システムのテストと紙からデータへの移行プランを別で見積へ計上し
要件定義を完了させました。
5.要件定義の確認
後日、作成した実現案(※1)をお客様に見て頂きました。
内容は概ね合意で問題ありませんでした。
しかし、予算の都合もあるので金額と内容を他社と比較検討していただくこととなりました。
(※1)本来、要件定義の成果物は要件定義書が作成されます。
しかし、今回は要件定義前から契約が済んでいるわけではないので、
実現案と言う形で提案書を作成しました。
6.検討の結果
他社との比較の時点で金額は低かったようですが、お客様はもっと安価でシステム化をしたいと要望されました。
そもそも、お客様は在庫システムのパッケージソフトを何種類か試してみたようですが、
業務の流れにはマッチしなくやりたいことが実現できなかったそうです。
パッケージソフトは比較的価格を抑えて導入することができます。
しかし、システム開発の様に個別でカスタマイズは不可能か別料金になります(※2)。
そのため、自分の会社に合ったシステム開発に踏み切ることになったのです。
(※2)パッケージソフトの批判ではありません。双方メリット・デメリットがあります。
何やら雲行きが怪しくなりました。
値切られるのか？提案通り見積額に同意してもらえるのか？
そんな所で、中編はここまでにします。
次回は実際にシステム化に取り掛かるところを書いて行きたいと思います。
Follow me!
