基幹システム開発とは、販売管理や在庫管理、会計といった企業の中核業務を担う仕組みを、自社の業務に合わせて構築する取り組みです。ただし、手法や進め方の選択を誤ると、業務に合わないシステムを長期間使い続ける結果になりかねません。
本記事では、開発手法の違いから進め方、費用の考え方、開発会社の選び方までを、基幹システムの刷新を検討する流通・小売業のご担当者に向けて解説します。自社の進め方を組み立てる材料としてお使いください。
基幹システムの刷新・導入なら
流通業向け基幹システム「基幹船」
- 700名以上のエンジニアによる幅広い対応
- オフショア開発により低コストでのカスタマイズを実現
- 多彩なシステムと連携可能
目次
基幹システム開発とは
基幹システムの開発は、既製の製品をそのまま使う導入とは違い、どこまで自社の業務に合わせて作り込むかを発注側が決められる点に特徴があります。標準機能に業務を寄せるのか、自社の手順を優先して作り込むのかという判断が、費用と期間の両方を左右します。
基幹システムで管理する対象となる業務は業種によってさまざまです。流通・小売業であれば発注や仕入、在庫、棚卸、買掛支払が中心となり、製造業では生産管理が加わります。
基幹システムの種類や業務システムとの違いについては、基幹システムの種類は6つ！代表的なシステムを一覧表で紹介しますもあわせてご覧ください。
基幹システム開発の主な手法
基幹システムの作り方は大きく3つに分かれ、どれを選ぶかで業務への適合度も費用も変わってきます。
- フルスクラッチ開発
- パッケージ導入とカスタマイズ
- ベースシステムを活かすセミオーダー開発
| 比較軸 | フルスクラッチ開発 | パッケージ導入とカスタマイズ | セミオーダー開発 |
| 業務適合度 | 高い | 標準機能に業務を合わせる部分が残る | 高い |
| 初期費用 | 高い | 抑えやすい | 中程度 |
| 開発期間 | 長い | 短い | 中程度 |
| 拡張性 | 設計次第 | 製品の仕様に依存 | 追加開発で対応しやすい |
| ベンダー依存 | 設計書とソースを自社で保有できる | 製品提供元に依存しやすい | 契約条件により変わる |
フルスクラッチ開発
フルスクラッチ開発は、既存の製品を使わずゼロから設計して構築する手法です。自社の業務ルールをそのまま形にできるため、他社にはない商流や独自の値引きルールをもつ企業に向いています。
デメリットとしては開発期間と費用負担が大きくなることです。要件が固まりきらないままに着手すると、開発途中の仕様変更が積み重なり見積もりを大きく超えることがあります。そのため、着手前に業務の要件を文書化できる体制があるかどうかを確認しておきましょう。
パッケージ導入とカスタマイズ
パッケージ導入は、すでに完成した製品を導入し、足りない部分だけをカスタマイズやアドオンで補う手法です。標準機能で業務の大半をまかなえる企業であれば、短期間かつ低コストで稼働まで持っていけます。
注意したいのは、カスタマイズを重ねるほど当初の利点が薄れる点です。改修が積み上がると保守費用が上がり、製品のバージョンアップにも追従しにくくなります。そのため、選定段階で自社の業務が標準機能にどこまで収まるかを検証し、収まらない部分の量を把握しておきましょう。
ベースシステムを活かすセミオーダー開発
自社独自の業務と一般的な業務が混在しているなら、セミオーダー開発を検討してみましょう。共通基盤にあたる部分は既存のシステムを流用し、競争力の源泉となる業務だけを個別に開発して組み合わせる手法です。
会計や人事は標準的でありながら、発注や特売の運用だけが各社固有という流通・小売業と相性の良い手法です。ゼロから作る範囲を絞れるため、フルスクラッチより費用を抑えつつ、パッケージでは届かない業務要件に対応できます。
基幹システムの刷新・導入なら
流通業向け基幹システム「基幹船」
- 700名以上のエンジニアによる幅広い対応
- オフショア開発により低コストでのカスタマイズを実現
- 多彩なシステムと連携可能
基幹システム開発の進め方
開発の成否は着手前の準備で大きく決まるため、社内で進めるべき工程を順に押さえていきましょう。
- 現行業務を棚卸しして課題を言語化する
- 要件定義とRFPで機能と非機能の両方を固める
- データ移行と並行稼働を計画する
現行業務を棚卸しして課題を言語化する
まず、現行業務の流れを部門ごとに書き出し、どこに手間や誤りが生じているかを整理しましょう。ベンダーへ相談する前にこの作業を済ませておくと、提案の精度が上がり、後戻りも減ります。
棚卸しの対象は、システム上の処理だけではありません。表計算ソフトでの補完作業、紙の帳票、担当者だけが知っている例外処理まで洗い出します。たとえば、特定の取引先だけ締め日が違うといった運用は、書き出さない限り要件から漏れてしまう部分です。
要件定義とRFPで機能と非機能の両方を固める
次に、洗い出した課題をもとに要件定義をおこない、RFPとして文書化してベンダーへ渡します。RFPには、必要な機能一覧に加えて、連携先のシステム、希望する稼働時期、予算の目安を記載しておくと、各社の提案を同じ土俵で比較できます。
見落としが起きやすいのは非機能要件のほうです。同時に何人が使うのか、月末の締め処理にどれだけの時間を許容できるのか、障害時にどこまで復旧できればよいのかを数値で示しておきましょう。
データ移行と並行稼働を計画する
開発と並行して、現行システムのデータをどう移すかを早い段階で決めておきましょう。長年運用してきたマスタには重複した商品コードや使われていない取引先が残っているケースが多く、移行前のクレンジングに想定以上の時間がかかります。
切り替え当日にすべてを入れ替える方式は、業務停止のリスクが高い進め方です。新旧のシステムを一定期間並行して動かし、数字が一致するかを確認したうえで本稼働へ移す方式が安全です。工程ごとに必要な期間の目安は、基幹システムの入れ替えにかかる期間は？フェーズ別の目安と成功のポイントを解説でも解説しています。
基幹システム開発の費用を左右する要素
基幹システムの開発費用は、同じ業務を扱う場合でも条件によって大きく変わります。見積を比べる前に、金額を動かす要素を把握しておきましょう。
- カスタマイズする業務の範囲と件数
- 連携する外部システムの数
- 移行するデータの量と状態
- 保守運用まで含めた総額
なかでも影響が大きいのはカスタマイズの範囲です。標準機能から離れるほど設計とテストの工数が増え、稼働後の改修費用にも上乗せされます。一式いくらという見積ではなく、工程ごとの工数と単価を開示してもらい、どこに費用が集中しているかを確認してください。
判断は初期費用だけでおこなわないようにしましょう。基幹システムは10年前後使い続ける前提の投資であり、年間の保守費用やライセンス費用を含めた総額で比べる必要があります。
流通・小売業の基幹システム開発で押さえたい要件
流通・小売業には他業種にない商習慣があり、汎用的な製品では扱いきれない処理が数多く存在します。要件定義の段階で落としやすい項目を4つ取り上げます。
- 特売と売価・原価の予約管理
- 店間移動・廃棄・棚卸の処理
- 買掛の請求照合と違算通知
- 店舗で使う端末の操作性
特売と売価・原価の予約管理
特売を扱う企業は、売価と原価を将来日付で予約できる仕組みを要件に入れておきましょう。チラシの企画は数週間前から動くため、切り替え日を指定して価格を登録し、当日に自動で反映される機能がないと、担当者が早朝に手作業で更新する運用になってしまいます。
また、予約の単位も確認しておきたい項目で、全店一律なのか、店舗や地域ごとに変えられるのかで運用の自由度が変わります。企画の取り消しや期間の延長も頻繁に発生するため、登録済みの内容を一括で修正できるかを見ておきましょう。
店間移動・廃棄・棚卸の処理
複数店舗を運営しているなら、店間移動と廃棄の処理を要件から外さないようにしましょう。売れ行きの差を店舗間の在庫移動で吸収する運用は流通業では日常的でありながら、汎用的な在庫管理の仕組みでは申請と承認の流れまで用意されていない場合があります。
廃棄やロスの扱いも同様です。賞味期限切れや売れ残りによる廃棄を、経費振替や在庫調整と区別して記録できないと、粗利の実態がつかめなくなります。棚卸についても、閉店後に一斉におこなう方式だけでなく、営業しながら区画ごとに進める方式へ対応しているかを確かめておきましょう。
買掛の請求照合と違算通知
卸との取引が多い企業は、買掛の照合を自動化できるかを要件に加えましょう。仕入伝票と取引先からの請求書を突き合わせる作業は件数が多く、手作業では月末に担当者が集中して対応する状況になりがちです。
自動照合の価値は、差異が出たときの扱いに表れます。金額が合わない伝票だけを違算として抽出し、担当者へ通知する仕組みがあれば、確認すべき対象が数件に絞られます。加えて、仕入の段階で欠品予定やリードタイム超過、納品エラーを検知できる仕組みも有効です。
店舗で使う端末の操作性
店舗で日々使う端末は、機能一覧に現れにくいものの現場の定着を左右します。専用のハンディターミナルは画面が小さく表示できる情報量が限られるため、発注や検品のたびに紙の帳票と見比べる運用が残りがちです。
タブレットを前提とした設計であれば、画面が広く一度に確認できる情報が増えます。さらに、欠品リストや発注の履歴を端末上で確認できるようになると、紙の出力とプリンターの管理をあわせて減らせます。このように、端末の調達費用も見積に含めて比較しておきましょう。
基幹システムの開発会社を選ぶポイント
基幹システムの開発では各社から見積もりと提案を受けますが、その内容の良し悪しの判断が難しいのが課題です。次の3点を軸に複数社を比べていきましょう。
- 同業種・同規模の開発実績があるか
- 要件定義から伴走できるか
- 運用保守とドキュメントの範囲が明確か
同業種・同規模の開発実績があるか
開発会社を選ぶときは、自社と近い業種と規模での実績があるかをまず確認しましょう。扱う店舗数やデータ量が自社と近い案件を手がけているかどうかも、性能面の見通しを立てるうえで役立ちます。流通・小売業の商習慣を知っている会社であれば、特売や店間移動といった要件を説明しなくても、要所を押さえた提案が出てきます。
実績は公式サイトの事例紹介で確認できるものの、記載されていない案件も多いため、商談の場で近い業態の経験を直接聞いてみてください。
要件定義から伴走できるか
社内に情報システム部門がない企業ほど、要件定義の段階から一緒に整理してくれる会社を選びましょう。現行業務の棚卸しやRFPの作成を支援するサービスを用意している会社であれば、何から手をつければよいかわからない状態からでも進められます。
商談では、担当者が業務側の質問にどこまで踏み込んで答えるかを見てください。技術の説明に終始せず、業務のどこが変わり誰の作業が減るのかを語れる担当者であれば、開発中の認識のずれも起きにくくなります。
失敗の要因については、基幹システムの入れ替え失敗事例と原因！企業が陥りがちな5つの落とし穴と対策でも詳しく取り上げています。
運用保守とドキュメントの範囲が明確か
契約前に、稼働後の運用保守でどこまで対応してもらえるかを書面で確認しておきましょう。障害対応の受付時間、法改正への追従、機能追加の扱いが契約に含まれるかどうかで、稼働後の負担は大きく変わります。
万が一書類が残らないまま引き渡されると、社内で仕様を追えなくなり、改修のたびに同じ会社へ依頼せざるを得なくなります。
設計書やテスト仕様書、操作マニュアルが納品物に含まれるかも、同じタイミングで詰めておきたい部分です。
基幹システム開発に関するよくある質問
検討を進めるなかでご相談の多い疑問をまとめました。判断の材料としてお役立てください。
基幹システムの開発期間はどのくらいかかりますか
システムの規模や既存システムとの連携の複雑さによりますが、数か月から1年程度を見込む案件が多いです。カスタマイズの範囲が広い場合や、拠点ごとに段階的に展開する場合はさらに長引きます。
パッケージとフルスクラッチはどちらを選ぶべきですか
パッケージとフルスクラッチのどちらが向いているかは、自社の業務がどこまで標準的かで判断が分かれます。会計や人事のように業界共通の業務が中心であればパッケージ、独自の商流が競争力になっているならフルスクラッチやセミオーダーが向いています。すべてを一方に寄せる必要はなく、業務ごとに使い分ける組み立て方も可能です。
情報システム部門がなくても発注できますか
情報システム部門がなくても、基幹システム開発の発注は可能です。
ただし、業務の流れを説明してベンダーの質問に答えられる業務部門の担当者を、社内に立てておく必要があります。要件定義から支援する会社を選べば、専門知識がなくてもプロジェクトを進められます。
まとめ
基幹システム開発では、フルスクラッチ、パッケージのカスタマイズ、セミオーダーという3つの手法から自社に合うものを選ぶところが起点になります。判断の基準は、自社の業務がどこまで標準的で、どこからが独自の強みなのかをよく考えてから選びましょう。
基幹システム開発の進行では、現行業務の棚卸しと要件定義に時間をかけた案件ほど、後工程の手戻りが少なくなります。非機能要件やデータ移行の計画も早い段階で固めておきましょう。費用は初期の開発費だけでなく、保守運用まで含めた総額で比べてみてください。
流通・小売業では、特売の売価予約や店間移動、買掛の照合といった商習慣に根ざした要件が、汎用的な製品では扱いきれない場面も出てきます。ブライセンの流通業向け基幹システム「基幹船」は、発注から仕入、移動・廃棄、買掛・支払、棚卸までを標準で備え、タブレットを標準実装した基幹システムです。需要予測型自動発注のB-LuckスイートやCOOOLaとの連携にも対応しており、業務の広がりに合わせて拡張していけます。自社の商習慣に合った基幹システムをかなえましょう。
詳細はこちらまでお問い合わせください。
03-6264-7226