【決定版】小売業の基幹システム開発を安心・安全・円滑に行う方法！
小売業の基幹システムを開発する際には、パッケージソフトをベースにすることが最適です。
しかし、パッケージソフトの良さを十二分に活かしながら自社業務のシステム化を実現するには、一般的なシステム開発の方法と大きな違いがあります。
本ブログでは、小売業基幹システム開発を安心・安全・円滑に行う方法を解説します。
どのような方法が小売業基幹システムの開発に適しているのか？
小売業の基幹システムを開発するに当たり、まず考慮すべき事項は”対象業種業態を限定したパッケージソフトをベースにすること”です。
小売業と言っても多岐にわたっているので、全ての業種業態に適用可能なパッケージソフトは存在しないと経験的に理解しています。
こちらでは、食品や日用品を主として扱う多店舗を本部でコントロールしている小売業、具体的に言えば、スーパーマーケット、ホームセンター、ディスカウントストア、ドラッグストア等の複数店舗を展開しているチェーンストアを想定して説明をします。
業界をリードしているチェーンストアは、店舗運営や管理業務等を標準化するようにしており、さらには単純化を進めているので、企業の独自部分が全体に占める割合は低いのです。
つまり、チェーンストアにおける勝ち組と負け組の違いは、標準化と単純化を愚直なほどしつこく押し進め、このレベルを高めることにより他社との差異化を実現した企業が勝ち組となり、現在のチェーンストアをリードしていると言えます。
したがって、小売業基幹システム開発においては、”店舗運営や管理業務等の標準化と単純化をシステムとして実現し、多数の稼働成功実績を持つパッケージソフトをベースに開発を進める方法”が適しています。
この方法を選択した場合は、具体的な画面を見て、実際の操作性を検討段階で確認ができるので、完成時にイメージが相違して稼働に困難をきたすことが軽微です。
また、実績数表や照会画面には同業他社の実データを表示することができる場合があり、計算結果や表示順等の具体的なイメージを事前に確認することができるので、システム開発において散見される発注者と作成者の思い違いによる問題発生も少ないのです。
さらには、業務フローや操作・運用マニュアルの雛形が既に作成済であるので、短期間で効率的に業務運用を決定でき、マニュアル等の必要資料の作成も短期間で行えます。
次に、開発手順としては『ウォーターフォール型』が良いでしょう。
小売業基幹システム開発では、発注や販売等の重要な機能を作成するため高い品質が要求されますし、中堅小売業の基幹システムのプロジェクト規模は大きくなります。
アジャイル型等を利用すると、プロジェクトのスケジュールが立てにくくなるのみならず、予算管理や開発要員の手配にも支障をきたすことが予想されます。
では、ウォーターフォール型を利用し、パッケージソフトをベースとした小売業基幹システム開発の具体的な手順はどうなるのでしょうか。
第一に、対象プロジェクトの進め方を対象メンバーが合意する必要があるので、プロジェクト計画書等を利用して以下の確認を行います。
この段階を経ることにより、プロジェクト途中における進め方の思い違いを防止することが可能です。
・目的やベースになるパッケージソフト
・カスタマイズや追加対象の範囲
・発注側と開発側の双方のプロジェクト体制やスケジュール
・各フェーズの内容や従事者、対象者
要件定義フェーズでは、パッケージソフトとのフィット・アンド・ギャップを行います。
出来る限りパッケージソフトの標準機能をそのまま利用する事を前提に、パッケージソフトの画面を見ながら打ち合せを行います。
この時は、手元に業務フローや想定運用マニュアルを用意して、自社の業務にフィットしない機能を洗い出し、どのような修正・追加を加えるかの詳細を議論しながら要件定義を進めます。
この時に作成する議事録をプロジェクトメンバーが確認して機能を確定していきます。
次の外部設計では、パッケージソフトの修正箇所や追加開発箇所の画面等の設計を作成し確認・確定します。
並行して、パッケージソフトと修正・追加部分のデータ項目とコード体系の確認と確定も行います。
利用者の立場から作成された人と情報システムのインターフェースが定義された外部設計フェーズでは、旧システムからの移行計画とハードウェア・ソフトウェア構成図も作成します。
次に内部設計に進みますが、その前に、根幹にかかわる手戻りがウォーターフォール型開発の重大な欠点ですので、要件定義や外部設計で定義された内容を発注者側の責任者と開発側の責任者との間で合意し、手戻りをしないようにしなければなりません。
この合意なく内部設計に進んでしまったために、プロジェクト全体の開発期間や費用に支障をきたして、プロジェクトの失敗をきたしてしまうケースがあるので、特に注意が必要です。
言葉を変えると「仕様凍結」を内外に宣言をしてからしかプロジェクトを次のフェーズに進めてはなりません。
内部設計フェーズでは、データベースや項目、プログラム等の開発時に必要な項目の名前が標準化されていなければなりません。
先に記述した様に、小売業基幹システム開発では、パッケージソフトをベースにするので、パッケージソフトの基準をプロジェクトの標準として、これを逸脱することなく設計書や仕様書、更にはテスト計画書を作成します。
内部設計フェーズに並行して、プログラム開発・単体テスト・ITa・ITbへと進みます。
そして、仕様書に基づいたテストデータを作成してシステムテストを実施します。
新システムを稼働するに当たり、稼働判定基準を作成する必要があります。システムテストに並行して旧システムから新システムへの移行手順を予め作成された手順書に従って進めると同時に、稼働後の業務担当者や操作員に対する研修を実施します。
稼働の可否を判断するには、システムテスト結果や移行状況、研修による理解度等を吟味して、上記の稼働判定基準に照らし合わせて最終判断をします。
・時代の流れを知る！電気代・物価高・人件費高騰、物流2024年問題…これからのスーパーマーケット ~難局への処方箋~
どのような人が小売業基幹システムの開発に適しているのか？
小売業基幹システム開発に携わるメンバーの中でも、開発側のシステムエンジニアに必要な資質について2点解説します。
1点目ですが、小売業基幹システム開発は、小売業の経営全般や店舗販売等業務運営に関わるシステムの開発ですので、プロジェクトに参画するシステムエンジニアは対象小売業の業務に精通していることが何よりも重要です。
小売業基幹システム草創期と比較して、対象範囲や技術レベルは多種多様になっており、難易度が上がってきているので、小売業基幹システム開発に携わっているシステムエンジニアは技術の学習を優先して、業務の変化を学習する時間を割かない傾向が見受けられます。
このような状況下においても、対象小売業の変化を深く観察し分析の上で判断を繰り返して、先進的な業務に精通したシステムエンジニアは存在しています。
業務に精通したシステムエンジニアがプロジェクトに携われば、要件定義フェーズにおいて発注者側が業務を事細かく説明したり、用語の解説をすることなく小売業基幹システム開発を実施できます。
さらに、このような学習を弛まなく継続しているシステムエンジニアは、同業他社の事例についても幅広く熟知しているので、パッケージソフトに対するカスタマイズや追加をすることなく、業務をパッケージソフトに合せる合理性を説き、結果としてコストや時間の削減に貢献する事が期待できます。
2点目は、テクノロジーつまり技術に関しても多くの情報を吸収し深い知識を持っていることです。
先にも記述しましたが、昨今の小売業基幹システム開発は技術の刷新が繰り返され、開発には高い技術が要求されます。
システム業界用語で上流工程と言われる要件定義や全体管理を専門で行うシステムエンジニアが存在し、彼らには高い技術力は不要に思われがちというよりも彼らがそのように思い込んで技術力不要論が横行しています。
しかし、クラウドの利用やERPとの連携が重要性を増しており、これらを扱うためにはシステムエンジニアの高い技術力が必要になります。
業務に精通し、小売業基幹システム開発に関連する高い技術力を有するシステムエンジニアをプロジェクトメンバーに多数配置可能であれば、期待以上の小売業基幹システム開発が夢ではありません。
小売業の基幹システム開発を安心・安全・円滑に行う方法 ～まとめ～
ここまで、小売業基幹システム開発について、方法（もの）とシステムエンジニア（ひと）について解説してきました。
適切な“もの”と“ひと”を選択すれば、自ずとコスト（かね）も最適化されると経験から理解されています。
つまり、多数の成功裏に稼働した実績を持つパッケージソフトをベースにウォーターフォール型で開発し、業務に精通した高い技術力を持つシステムエンジニアが携わるプロジェクトであることが、小売業基幹システムを安心・安全・円滑に開発するためには、欠くべからざることではないでしょうか。
株式会社テスクは、流通業向けの販売管理パッケージ開発を専
門のシステムベンダーです。
小売業向け基幹システム「CHAINS Z」、卸売業・メーカー向け基幹システム「GROWBS Ⅲ」を提供してます。
基幹システムの再構築をご検討の際は、お気軽にご連絡ください。