ERP拡張型ネットショップの売上が他店より圧倒的に伸びる7つの理由


ネットショップことぼぎ
Reiwaバージョン - 売れていく理由

既製品を受注して販売するだけの単機能ネットショップは、存在の意味を失いつつある。 それどころか、企業の生産効率を奪う足かせですらある。 「ネットショップ」と呼んで、全体のシステムと切り離し、別物のように扱うことすらナンセンスと気づきべきである。



理由その1
オムニチャネル対応

オムニチャネルとは──実店舗やネットショップ、カタログやDM、テレビや雑誌、SNSなど、あらゆる販売チャネルや流通チャネルを連携させてシステムを統合し、ひとつでも多くのプロセスで顧客との接点をつくりだすことによって、多様化する購買パターンや心理を理解し、カスタマロイヤリティの最大化を図る取り組みのこと。「オムニ」は「あらゆる」「すべての」の意味をあらわし、「チャネル」は「経路」「場」「手段」である。

オモニチャネルは、
複数のチャネルについて、
受注管理や在庫管理、顧客管理などをすべて統合管理できている状態。
これ大事。
統合されていないものをバラバラに管理することが、
あなたのアタマを疲弊させ、社員さんたちからやり甲斐を奪う。
エムトーンが受託開発するネットショップ「ことほぎ」は、
すべてを一元化しうるシステム。
なぜなら、ネットショップに必要な機能は、
ERPの拡張機能にすぎず、すべてはERPに内包されている
アタマをすっきりさせ、理想的な効率化を実現するカギはERPにしかない。
ウェブ上で顧客が商品をカゴに入れるというアクションも、
飲食店で店員が注文をきいてハンディ端末でオーダーをエントリーするというアクションも、
全体データベースからみれば受注データが発生したという意味で同じこと。
商品を倉庫の棚から出して納品書と入れて梱包し、
送り状を貼って出荷するというアクションも、
飲食店のレジで精算してレシートを発行するというアクションも、
全体データベースからみれば受注データが消し込まれて売上データが発生したという意味で同じこと。
ここが理解できなければ脳が樹海。
データの混乱で業務の停滞を招きなくなければ、
ネットも地べたも、小売だけでなく卸も、在庫も、入出金管理からの会計も、
すべてのデータが統合されている状態にこだわってみてはどうだろうか。
あなたの会社は、現在も将来的にも、
自社サイトの単独ショップだけで商売を成り立たせるつもりではないはずだ。
一元化の鬼、エムトーンがお手伝いします。

【超絶に重要】データベース相関図


理由その2
顧客データで差がつく根拠

先ほどのオモニチャネルの話をさらに理解してもらうために、
たとえば顧客管理について考えてみよう。
あなたの会社は地べたでリアルな店舗を複数展開し、
1号店と2号店のあいだは車で10分ほどの距離。
さらにネットショップも運営しているとする。
1号店で商品Aを買った顧客が、
その数分後にネットで商品Bを購入しようとした。
あなたの会社では顧客の購入金額に応じてポイントを発行しているが、
商品Aを買った時点で付与されたポイントが、
ただちにネットショップで使えるようになってますかという話。
顧客データベースが、
地べたのリアル店舗とネットショップで分離されていては、
ここに時間差が生じます。
だから、
リアル店舗のポスレジと、ネットショップの一元化による一体的運用が大切。
「ネットショップことほぎ」は、
リアル店舗のポスレジ「ぽす乃助」と一元化されていて一体。
もともと一体のものに便宜上の名前を別々につけて、
別々に扱える商品として販売しているだけ。
「ことほぎ」は、ネットショップとしての機能は当然ひととおり備えているが、 すべてはERPの一部として内包されており、企業経営全体の管理を司る統合データベースと分離されているわけではない。 ただ、説明のための便宜上、商品名をつけて別物のように見せかけているにすぎない。 当然、基幹系ERPが備えるすべてのバックオフィス機能と一体的な運用がなされることになり、 売上、送料、値引き、クーポン、その他すべてのデータが会計上の仕訳データとして決算まで一気通貫で処理される。 この特長が「ことほぎ」最大の利点であり、そこが腑に落ちさえすれば、あなたは戦う前から大きなアドバンテージを市場で得ることになる。

中核ERPとその周辺アプリケーション


理由その3
利益率アップにまで貢献するのは?

ネットショップことほぎを開発した株式会社エムトーンは、
会社設立から20年間は、いっさい宣伝広告費を使わなかった。
そのため異常に利益率が高く、
万年無借金で万年黒字体質をいまなお堅持している。
グーグルのアルゴリズムを的確に理解し、
狙ったキーワードで常に検索上位に表示させることができたために、
リスティング広告をはじめとする宣伝の必要がなかった。
クライアント企業にもムダな宣伝広告費をかけさせない
理想的で常識破りなコンサルティングができる。
必然的に利益率は劇的に改善する。
令和時代には、同じ広告でもSNS広告の重要性が高まり、
ランディングページへの顧客誘導、YouTube動画の活用、LINE@とメルマガの併用による発信‥‥等々、
タイムリーなマーケティング施策には正解がない。
これはもうショップ機能のスペックがどうのこうのいう次元ではないのだ。
すべての戦略はは統合的にトータルに組まれるべきであり、
コーポレートサイト制作と、ショップ機能を分離して考えてはいけない。
少し専門的な話になるが、
ショップ部分ではない、静的なHTMLページにでさえ、
一元化データベースから取り出したあらゆる情報をリアルタイムに表示することが可能だ。
品切れ情報、担当者の不在状況、営業日時によって左右されるお届け日時、時価‥‥等々、
顧客に知らせてあげたら喜ばれる情報を、
ホームページのどのページのどの位置にでも表示することができる。
これがことほぎReiwaバージョン ショップ構築とホームページ制作を、
バラバラの別問題だと考えていたとしたら、
すでにかなりのプロフィットロスを生んでしまったと考えたほうがいい。
理由その4
平成15年から続く安定運用実績

兵庫県明石市、
明石のりを販売する鍵庄さんのネットショップをERP拡張型「ことほぎ」でテコ入れしたのは平成15年(西暦2003年)。
いまでこそERPだ、オムニチャネルだ、という着想は珍しいものではなくなってきたが、
当時はクラウドという言葉もまだない。
ERPをネットショップに拡張し、
実店舗のポスレジとも一体的に運用する技術はどこにもなかった。
日本で初めての取り組みであり、
稼働実績も過去にひとつもなかったが、
それがもっとも美しいデータ一元管理の理想形であることはハッキリ見えていた。
2010年、経済産業省の実施する 「中小企業IT経営力大賞」という顕彰制度で、
鍵庄さんは優秀賞、開発元の当社は特別賞を受賞した。



以来、
平成時代が終わる2019年4月末の時点までで、
鍵庄さんのネットショップ売上は常に右肩上がりの横綱相撲。
実店舗、ネット、卸、電話、ファックス、外商、を、 完全に一元化するシステムは、この間、いちどもモデルチェンジを必要とせず、
当初1店舗だった実店舗は3店舗に拡大、 年末年始の大売り出しではレジ7台をクラウドに直結してなお長蛇の列という大盛況、 自社ビルが建つほどまで企業成長に貢献し続けている。
ことほぎ、
第1号の事例で、いまなお圧倒的な成功事例。
時代は平成から令和へと移っても、
情報一元化という観点で鍵庄さんのシステムを抜く鮮やかな成功事例がまだ生まれないので、
ここで他の事例を紹介する必要性を感じない次第です。

中小企業IT入門マガジンで紹介された鍵庄さんの事例。
※画像をクリックするとPDF版が開きます


経済産業省「受賞企業の横顔」に紹介された鍵庄さんの事例。
※画像をクリックするとPDF版が開きます


理由その5
需要喚起に必須のメルマガスタンド機能

一定期間お買い上げがない顧客のみに送るとか、
あるいはその反対に、
1年以内に3回以上お買い上げのある上得意を抽出するとか、
累計金額でランク付けして送信内容を変えるとか、
きめ細かいコントロールが朝メシ前。
一般にステップメールと呼ばれる、
定型のメルマガ文章セットを、
あらかじめプログラムされた決まった日時に計画的に配信する機能も実装している。
いわゆるメルマガスタンドと呼ばれる機能まで、
はじめから内包しているのだ。
メルマガ送信にかぎらず、
郵便でカタログやキャンペーン案内を送る際にも、
同じ検索機能が使える。
開封率を調べるテクニックや、
スパムメール処理されることを防ぐ対策など、
専門的なコンサルティングも任せていただきたい。
需要が落ちこむ、いわゆる閑散期に、
安直に価格を下げたり送料を割引するのではなく、
ポイントダブルキャンペーンなどの積極策をタイムリーに告知して、
合理的に購買意欲を喚起できる。
それが戦略的情報発信である。

理由その6
圧倒的に緻密な在庫管理

一元化を表現するのに、
「連動」や「連携」という表現は実は適切ではない。
はじめから一体のデータベースだからだ。
しつこく言うが、
これはインポート、エクスポートのレベルではない。
同一サーバの同一データベース内で時間差なくクラウドで処理するので、
特に商品の在庫を把握する上で強みが発揮される。
圧倒的な差がつくと断言しよう。
あっちの数字とこっちの数字を突き合わせて、
足したり引いたりして、けっきょく在庫があるのかないのか。
そこにストレスがあるとしたら、
それを解消するしくみがばっちりここにある。
「楽天」「ヤフー」といった複数のモールにショップを出しているとすると、
あっちのデータをこっちへインポート‥‥という手順を踏まざるをえないため、
ある程度の時間差はやむをえないが、 それでも「ことほぎ」は、一箇所にデータを集約して一元的に処理するしくみが最強。
>いくつ在庫があるかわからん‥‥!
という難問を解決するためのベストなツールといえる。
ネットから注文が入ったとして、
受注の時点ではまだ実在庫は減ってない。
減ってないけど「受注残」というかたちで在庫が減る「見込み」が立った。
同様に、商品を発注した時点ではまだ実在庫は増えていないが、
手配済というかたちで在庫が補充される「見込み」が立っただけ。
つまり、
受注も発注も「見込み」の話なんだけれども、
実際に増減をともなう販売、仕入と並行して動いている。
在庫管理っていうのはこのように、
増えたり、
減ったり、
増えそうになったり、
減りそうになったり、

を、
えんえんと追いかけていく作業なので、
システムの思慮深さが、
天国と地獄の分かれ目になる。
理由その7
基幹システムの受託開発会社が提供

ネットショップを提供するベンダーには、
デザインに強いホームページ屋さんが、
あとからデータベース処理を勉強したっていうパターンがけっこうある。
つまり、
デザインが先でシステムが後。
当社はこれが反対で、
プログラミング畑から出たゴリゴリのシステム開発屋であり、
システムが先でデザインが後。
おもてより
表面上シロウトにはまったく区別がつかないが、
この順序がけっこう大事。
ネットショップを扱えるウェブデザイナーはたくさんいても、
彼らには実店舗のポスレジとオンラインの受発注を一体的に運用できるスキルはない。
システム開発とデザインではそれほど専門領域が異なる。
ネットだけで全社の物販が完結する業態ならピンと来ないかもしれないが、
実店舗があって、
地べたとネットと両方で同じ商品を扱うというケースを考えてみよう。
完ぺきにひとつのデータベースで、
商品マスタも、
顧客マスタも、
在庫も、
はじめからひとつ。
同一の業者にネットショップとポスレジを発注したらこれが実現するかというと、
そうはいかない。
システムが別々なら処理も二系統に分断されるのだが、
残念ながら情報処理のシロウトには見た目で区別がつかない。
どっちかの売上をCSVとかで書き出して、
インポートしてがっちゃんこして集計する‥‥みたいな、
もっちゃりした手順じゃなしに、
地べたの実店舗でレジ精算したら、
その瞬間、
いま増えたポイントでネットで買い物ができるというような共時性。
これを、ひとことで
一元化
という一語に集約してあらわしているのだが、
ここが「ことほぎ」の圧倒的な強みであり、
ふつうではわかりにくい他社とのちがい。
よその国のことまではわからないが、
ERPを丸ごとひとりで開発してしまえる狂気のプログラマが、
日本にただひとり存在する。
できないことがあると思うか?
≪おまけ≫
Reiwaバージョンで何が変わった?

専門の技術者でなければ、平成のことほぎと令和のことほぎ
ほとんど区別がつかない。
>そういえば‥‥
>なんとなく動きがスムーズになったのかな??

って程度で。

技術的なところまで理解する必要はまったくないが、
>新しい時代にあやかって縁起をかついで名前だけつけたんだろう
ではないので、ひとことだけ。
見た目には変わらなくても内部の技術は大きく異なっていて、
平成の後半までは普及していなかった新しい技術を大幅に取り入れ、
セキュリティの厳しさやシステム融合の柔軟さがますます求められる時代に対応している。
ちがいを専門用語でいうと──
Restfulであること
これによって、
ますますウェブサイト全体をデータベースと一体運用することが可能になった。
どこでもデータベース みたいに。
どのページからでも基幹系データベースにアクセスし、
必要なデータを必要なときに必要なだけ取り出し、
好きなページ上に表示させることができる。
平成時代は、
動くページと動かないページは役割がはっきりわかれていたので、
ここからあっちがショップで、ここからこっちはショップじゃない みたいに、
いわゆるホームページといわゆるネットショップは意識の上でも分離されていた。
もうそんな時代じゃない。
WordPressがどうのこうのという次元の話ではなくて、
基幹系データベースとのデータのやりとりの話。
ことほぎReiwaは、
一元化データベースとホームページを渾然一体と扱える技術基盤なのだ。
数字のいっさい、
会計,販売仕入,受発注,タイムカード,給与計算,在庫,ポスレジ,飲食店オーダーエントリ,顧客管理, 生産工程,業務日報‥‥その他もろもろを、1本で済ませる。
大胆に All in One なアプリ、
あります。