SC運営管理業務の標準化とは

SC運営管理業務は幅が広い。

SC運営管理業務の日常業務を列挙してみると

①テナントとのコミュニケーションからテナント営業のサポート
②SC全体の販促、来店される顧客への安全管理からサービス業務
③SC施設のメンテナンス業務（設備、清掃）
④SC施設の安全保全(防災、警備）
⑤テナントへの売上・請求精算業務
など多岐にわたる

この多岐にわたる業務を横断的な発想で標準化できる具体的なことは何か?


標準化前の業務状況

①から④の業務では管理規則などで規程されている各種の申請書・連絡文書があり、この文書により記録され業務が進行される。
⑤については、比較的小規模な商業施設に多く見受けられる業務でEXCELを使用してテナント請求精算がおこなわれていることである。

現状では、申請書・連絡文書は手書きであるがため記入者の書き方や、記入方法の違いがある。
テナント請求精算ではEXCEL利用であるがため作成者により計算方法の違いや若干のフォーム・レイアウトの違いがあり、過去データの保管・保存方法も作成者により違いが発生し、担当者が変わった場合に引き継ぎなどに時間がかかるか、作り直しが発生する。


標準化する意義と課題

標準化とは、だれが行ってもほぼ同様な内容で統一化されていることをいう。
そのためには、業務のルール化を詳細にわたって行いルールに基づいて業務遂行することになるわけであるが、実務でルールをみながら業務遂行できることは現実的な解決策ではない。


標準化の手段(方法）


１．①から④は其々の業務から発生する書類の管理であり、リアルタイムに情報を発信し、かつリアルタイムに情報を検索活用できるグループウェアを導入することにより情報の統一性が可能となる。
２．⑤についてはPCによるEXCELではなくシステム化をおこなうことにより、担当者が変わった場合でも売上管理から家賃請求精算方法に影響がなく業務そのものが一律化する。


標準化の功罪


標準化により業務の統一化が達成された場合は、例外事項ごとに対応しにくいことが発生しうる。
例外事項に対してその時々の応じた対応が数多くなれば、標準化・統一化が崩れるからである。
システムも同様で、システムは業務を画一的、均一的に処理する。
そのことにより、業務をシステム化することにより標準化ができるのである。
例外事項対策については、システム導入前に現業務を分析し想定される例外事項を整理し、例外事項そのものも標準化することが必要である。
その他まれに発生するような例外事項については、システム外で処理する判断が必要になる。


最後に

上記SC運営業務の標準化システムとして

WebSCマネジメントシステム　と　SCWAE テナント管理システム　が　小規模商業施設から大規模商業施設まで稼働していることをつけくわえたい。


http://www.sccube.co.jp/

SCの売上管理の問題点

【誤った売上管理の意味】

ショッピングセンターの売上管理については、家賃形態に売上歩合があればテナントの売上収集をし、固定家賃があれば全く売上管理は行わないという商業施設がある。

単純に、テナントの売上管理は歩合家賃があるから行なうという発想である。

特にガッカリさせられることは、新規のSC開発において売上管理をするのは手間でコストがかかるから出店契約は全て固定家賃でという発想である。

おそらく、SCの開発は収支だけでものごとを考えているのであろう。

これは、全く本末転倒の話である。
収支を気にするのであればこそ、SCの売上状況を把握することがマーケティング戦略であり収支を改善する基本となるのである。
また、一日に数千の売上データを処理するわけでもないので手間がかかるほどではない。


【本来の売上管理の意味】

１．ショッピングセンターを構成するテナントは互いに補完して、ショツピングセンターの魅力を作っていくものである。
２．ショツピングセンターの全体の売上は、いわば船の羅針盤と同じと考えて運営管理の舵取りを行なうものである。
３．出店しているテナントはいかに売上を確保してあげていくかがもっとも重要なことであり、出店しているSCの集客戦略や他SCとの差別化戦略でテナントの経営状態にまで大きく影響していると言っても過言ではないのである。
４．SCを所有している会社、また管理する会社は大きな責任を自覚する必要がある。

それでは、売上管理はどうするかということであるが
これも、実際に行なっているSCをみると様々な対応が見受けられる。

【過剰な売上チェック】

もっとも多く見受けられるのは、売上監視型の管理である。
それは、精算ジャーナルを添付した売上報告書に、レジのドロア（現金などが入っている)の内容を全て記入させているパターンである。

例えば、総売上、控除売上（消費税、箱ﾀ代、内金などなど)、純売上（家賃対象売上)、
現金、掛け売上、クレジット、金券　現金の調整内容（つり銭違い、誤打、一時支払いなど)、現金の金種、金券の金種までをことこまかに、テナントに記入させて、それを大変な時間と人手をかけて再チェックしていることである。
まるで、自社の売上金管理の様である。自社の売上であれば経理勘定に現金在高や掛売り勘定などに記載して財務管理につながるので、当然のことである。

何故このようなやり方をしているのかお話しを訊ねると

次の二つの売上チェックを行っている。
１.テナントの現金在高を管理してあげるのは、“テナントサービスの一環”であるという答えが返ってくるか、テナントが売上報告を過少に報告することをけん制するためということである。

2.提出されたクレジット・金券を正しくレジ登録を行っているかをレジ精算ジャーナルと報告書の照合を行い、もしレジ登録とクレジットがあわない場合にはテナントにレジ登録が誤っているのか、クレジット入力が誤っているかまで確認して訂正をさせるため。


テナントにすれば大きなお世話である。
デベロッパーが１円まであわせてくれるから、現場のレジ担当と本社の経理はそのまま事務処理するかというと、そんなことはないのである。
また、テナントの売上報告の過少報告という問題であれば、レジ精算ジャーナルそのものを疑わなければならない、それを解決するためであれば、キャッシャーを派遣する以外に手はないのである。

どちらにしても、大変にナンセンスなことであり、テナントのレジ精算そのものを疑えば歩合家賃制度は存在できないのである。

大事なことは、テナントの売上状況を短期ではなく長期的に見ていくことである。

SCオーナーの必要なことは、テナントの家賃対象売上が間違いなく報告されているかが必要なことであって、テナントのレジのドロアの中までの内容までは必要はないのである。

リスクと責任について

デベロッパーがレジ登録と現金・クレジット・金券・掛け売上の照合モレがあった場合には、その責任はデベロッパーにあるのだろうか。
デベロッパーは、レジ精算ジャーナルの家賃対象売上と提出されたクレジット伝票の受け渡しについて責任はあるが、クレジットと現金などのいりくり違い、クレジットの金額違いまでは責任の取りようがない。
責任のない照合作業をおこなっていることはコストの無駄であり、リスクも大きい。

レジ登録とドロア内の現金・クレジットが一致しないことは、テナント企業ないの問題であって、デベロッパーの問題ではないのである。


照合作業コストについて

この照合作業のコストは、ビジネス的に例えれば
1円の売上をえるために、100円のコストをかけていることと同じといえる。


ただし、委託販売、消化仕入れ契約の店舗の場合は、当然に売上総額、ドロア内の現金、掛売り、金券は、当座勘定の中に含まれるので１円たりともあわせることが必要である。


賃貸しているテナントは、委託販売でもなければ消化仕入れでもなく、単に出店契約で売上に対する歩合家賃の契約が中心であることを付け加えたい。


【売上管理のあり方】

１．出店契約書、売上管理規定に記載されている純売上が正しく報告されているかのチェック業務は精算ジャーナルとの照合チェックだけで充分である。
２．SC全体・テナントの売上動向を中長期的に把握して、テナント指導や不振テナントの早期発見を行なうことが大切である。
３．販売促進、テナントミックス計画を行なうにあたって、売上動向情報は重要なファクターである。

このような意味で、たとえSCを構成するテナントの家賃形態が全店固定家賃であったとしても、SCの売上によって戦略を作っていくことが必要であるから、正しい売上管理をおこなっていくことが大切である。

次回は売上分析システムについてご紹介したい。


http://www.sccube.co.jp/

ショッピングセンターシステムのリプレース

ショッピングセンターのシステムは、百貨店、スーパーなどの大型小売業のシステムとは全く違う。
また、不動産賃貸業のテナント管理システムとも異にする。

その仕組みは、ショッピングセンターに入居する店舗の売上報告管理から賃料請求とクレジット決済システムがメインとなっている。

その構成は、テナントに設置するクレジット端末またはクレジット機能を内蔵したレジとそれを統合しクレジット会社から決済を受信するサーバーそしてテナント売上管理・賃料請求管理システムを搭載するサーバーで成り立つ。

ほかに、リアルタイムにポイントサービスを行っていればポイント管理サーバと顧客データ管理サーバーが必要となる。

店舗に設置する端末システムから、事務処理システムまでを運用していくうちに環境の変化によりシステムは陳腐化していくことから、システムリプレースが必要となる。

■リプレースのねらいとして

・システム経費をダウンさせつつ、業務をさらに効率化する。
・ＳＣの運営管理を見直して業務のクオリティを向上させる。
・システム利用範囲を拡大させてＳＣの売上増加に貢献する。

という前向きな改革を行っていくのである。

■リプレースの現状

しかし、多くのＳＣはシステムリプレースの動機は残念ながら前向きな発想ではない。
導入しているサーバー、端末などの老朽化により保守期限となることからリプレース行うというだけにとどまり
システムリプレースをきっかけに、業務の見直しを行わないのである。
それは、今までの業務をそのまま踏襲するだけになり、運営管理の発展と進歩は見られないことになる。
また、システムコストはリプレースのたびに増加するだけではなく時代に取り残されてしまい企業競争力は低下していく。


業務運用を見直さずにシステム追加、変更を行うことは
システムの形を複雑化し、
事務処理を効率的に行うはずのものが、処理の停滞、業務時間の延長などが起こって、
何のためのシステムかわからない状態となっているケースが多々見られる。


■リプレースの検討要素

システムリプレースにあたって考慮すべき点は多々存在するが基本的な要点は３点に絞られる。

第一にシステム対象としている事柄は、有効に機能しているか。
　機能していない場合はその原因は何か、またその事柄は本当に必要なものか。

第二にシステムで保存しているデータは有効に利用されているか。
　無駄なデータはシステムを複雑化し業務を増やす。

第三にシステムの投資と利用効果はバランスしているか。
　システム過剰投資はないか。

■事例としてよくあるケース


①システムベンダーから、システムの機能の説明を受けて多機能のシステムを導入するケースが最も多く見られる。

導入した機能を使いこなすには、導入前の準備と日々の運用にかかってくる。
また、コストも高くなる。

②先を見すぎたシステムの導入

先を見すぎて、現在では使わないシステムまで用意してしまうことである。
いわば、考えすぎの導入である。
今の段階の技術で、将来必要であろうから作りこんでしまうことである。このことは、システムの過剰投資につながることが多い。
ＩＴは日進月歩で、進化しまた変化していくので３年以上先のことは、そのときに対応していく考えかたで導入することが適切である。

③システムに対しての過剰な期待

これもよくあるケースである。
たとえば、店内案内のためのデータ（テナントの商品情報、施設のイベント情報）と広告宣伝の情報をデータベースという言葉で、すべて一元管理できるだろうという考え方である。
それは、データ名は同じでも、用途・更新のタイミング・情報の質・内容が違うのである。
もし、一元管理を行えば其々の用途目的に沿わないため結局、システムのための業務が増加してしまう。
このことは、システムを使わなくなるかシステムのための仕事を行うかのどちらかを意味する。

もうひとつは、全ての事柄をシステム化しすぎる場合もある。
システム化をして利用するより、人手で対応したほうが効率的な場合もあることを忘れてはならない。


④システムへの無関心と低い評価

③の真逆のケースである。
システムで瞬時に行えることでも、昔ながらの手処理で人手を使っているケースである。
たとえば、インターネットバンクで一括振込みできるのに手書きで振込み依頼書を書いて銀行の窓口から振り込むこと。

いずれにしても、システムを正しく認識して利用していかないということは、会社にとって大変な損失を与えていることである。