消費税がもたらした大いなるムダ

消費税がもたらした大いなるムダ

  日本に消費税が導入された年は1989年、平成元年です。消費税は平成とともに始まったのです。

 

 その平成も来年4月で終わります。巡り合わせでしょうか? 新しい元号になった年の10月に消費税は10%になり、複数税率(軽減税率8%)がはじめて導入されます。

 

 消費税は、日本中に大いなるムダをもたらしました。

 

 導入されてから30年経った今でも、クライアント先で「そんなことやっているのですか! それはムダですから、やめましょう」とアドバイスすることが絶えません。

 

 どのようなムダが発生しているのか?

 

 経費などのスポット精算であれば、請求書が届いてから支払申請します。仕入先の請求金額が1,000円であれば1,000円を、消費税の端数処理の違いで999円だったら999円と書くだけですので、特に問題はありません。

 

 これに対して、継続取引や発注書を出す購買取引は違います。経費のように請求書が届いてから処理していては、取引量が多すぎるので事務作業が大変です。

 

 ですから、商品が納品された時点(サービスなら終了した時点)で、発注データを活用して仕入処理します。そして、請求書が来てから、自社で仕入処理した買掛金と請求金額を確認します。

 

 この突合作業でよく問題になるのが“違算”です。自社のシステムの買掛金と請求金額が異なる明細は何なのか? それを調査します。

 

 違算が起きる原因は大きく5つです。「商品違い」「数量違い」「単価違い」「入荷日違い」「返品処理もれ」です。当社にまちがいがあれば自社の仕入を修正し、仕入先にまちがいがあればその部分は支払いません。

 

 しかし、消費税が導入されると、自社と仕入先との消費税差額を“第6の違算”とする処理が横行しました。

 

 消費税の1円未満の端数処理方法は、切捨て、切上げ、四捨五入などがあり、会社ごとに決めることができます。

 

 ですから、自社が採用した端数処理によって買掛金が999円であれば、仕入先の請求金額が1,000円だろうとも999円で払えばよいわけです。消費税端数の違いは、買掛金を必ずしも修正するものではありません。

 

 それなのに、購買担当者が人海戦術で毎月、請求書11枚の1円や2円をシステムで修正していくわけですから、これは大いなるムダです。

 

 さらに、あるシステム会社は「各仕入先が採用する消費税の端数処理方法を仕入先マスタに登録し、買掛金を調整計算できる機能をつくったことがあります!」と得意満面にPRしてきました。

 

 思わず私は「泣けるぜ・・・」と心の中でつぶやきました。

 

 消費税が導入された30年間、どれだけの人件費とシステム開発費が日本中でムダに使われたのか? 今度の複数税率でさらなるムダが生まれないよう祈るばかりです。

あの頃はレコードが普通だったよね

  先日、小田和正さんが新曲を出したので、久しぶりにCDショップに行きました。いつもはiTunesでダウンロードしますが、ファンとしてはやはり現物がほしいので、今回はCDを買ったしだいです。

 

 わたしが子供のころは、音楽と言えばカセットテープかレコードでした。高校時代は、よく学校帰りに友達と貸しレコード店に行ったものです。

 

 好きなレコードを借りて、自宅でカセットテープに落とす。レコードを返してまた借りる。そんな繰り返しでした。

 

 それがいまやインターネット配信で、クラウド環境に曲をストックする時代なのですから、「おじさんはついていけないよ」と言いたくなります。

 

 システムもそうです。

 

 1980年代、オフィスのパソコンはNECPC9800シリーズが全盛期でした。それに合わせ、小さなソフトハウスが数多く生まれ、PC9800用の実用ソフトやゲームソフトが、いろいろ発売されています。

 

 わたしの実家は地方の建設業で、母が経理で苦労していました。そこで、パソコン雑誌で、会計と工事台帳を管理できる建設業用ソフトを探して、それを使うよう勧めてみました。

 

 最初は大変だったのですが、そのソフトハウスは建設業専門で、パソコンに不慣れな中小企業に丁寧なアフタフォローをしてくれました。

 

 無事にソフトが稼働し、使い始めてしばらくすると、「紙の帳簿からパソコンの帳簿になって転記作業がなくなり、とても楽になった」と母に感謝してもらえました。

 

 今にして思えば、これがわたしの初めてのシステムコンサルで、いまの原点なのかもしれません。

 

 システムの世界は、長らく(スタンドアローン)パソコンでの「一人・単一業務」の時代が続きます。

 

 その後、ネットワーク環境が普及し、クライアント・サーバー型で複数人が同時に同一システムにアクセスできるようになります。「複数人・単一業務」は、部門の業務効率を上げるのに役立ちました。“部門システム”の時代です。

 

 さらに、システムは進化します。“ERP・全社統合システム”時代です。システム間でデータを連携したり、マスタを共通化したりすることで、システムは「複数人・複数業務」となりました。これにより部門だけでなく全社の業務効率が上がります。

 

 このように、時代と共にシステムは拡張・変化しましたが、今もそれについていけない企業が少なくありません。

 

 部門システムの思考を引きずっているがために、全社統合システムの機能を生かし切れていなかったり、カスタマイズを増やし過ぎたり、導入に失敗したりしているのです。

 

 将来を考えれば、「当社は時代についていけないよ」と泣きごとは言ってられません。部門システムの考え方をリセットして、全社システム構築のための新しい思考を身に着ける必要があります。

 

 4月に発刊したSBAレポート『なぜ経営危機を招く業務システムができてしまうのか!~失敗と成功をわける境界線~』では、このあたりを詳しく解説しています。ぜひお読み下さい(本日のコラムは宣伝でした~)。

そのカスタマイズ費用は誰が負担すべきか?

  先日、要件定義の打合せで、システム会社の担当者から、次のように言われました。

 

 「この機能は、どの会社さんもカスタマイズしていますよ」

 

 担当者本人は、特に悪気はなかったと思います。しかし、この発言は、事と次第によっては、物議をかもしだす問題発言です。いったい何が悪かったのか?

 

 パッケージシステムは既製品です。パッケージの機能と自社の求める仕様が100%合うなんてことは、まずありません。

 

 ですから、合わない部分は、会社が運用を工夫したり、がまんしたりして使います。どうしても無理なところは、費用をかけてパッケージを改修します。

 

 一方で、最初からカスタマイズを前提にしている機能もあります。会社によって求めるものが違い過ぎるので、最初から十分につくっていないのです。たとえば、帳表などです。

 

 そのような場合は、最初の見積金額に帳表のカスタマイズ費用を含むのが普通です。費用がかかるのがわかっているのに、当初の見積もりに入れなかったとしたら、それは信義則に反します。

 

 もしパッケージとして標準機能を持っているのに、「どの会社もカスタマイズする」となれば、話は変わってきます。

 

 たとえば、債権管理システムで明細消込する標準機能はあるが、消込画面には明細番号と金額しか表示されないとしたらどうでしょう? 商品名や売上計上日などの追加情報がないと、実際の消込作業をすることはできません。

 

 その業務を普通にやるのに大きな支障が出るのであれば、パッケージが持つ標準機能そのものに問題がある可能性があります。問題がある機能を会社側が費用負担して、カスタマイズするのは筋違いです。

 

 冒頭の発言は、自らパッケージの機能に問題があることを示唆したと、捉えられかねないから問題発言だったわけです。

 

 標準機能のままだと普通の運用では使えない。同等クラスの他社パッケージと比べて明らかに劣っている。フィット&ギャップ分析で、そのような仕様が見つかった際は、きちんとパッケージベンダーと話し合いましょう。

 

 パッケージと自社の「適合度」とパッケージの標準機能の「完成度」は異なるものです。

 

 適合しない部分のカスタマイズ費用は会社側が負担すべきですが、完成度が低い機能を改良する費用は、パッケージベンダーが持つのが正しいあり方です。

 

 そうは言っても、ベンダーが100%費用負担してくれるケースは少ないですが、ベンダーと会社で費用が折半になるだけでも、開発コストは抑えられます。

トップページ > 2018年 > 5月

ページの先頭へ ページの先頭へ戻る


特定商取引法に基づく表記

Copyright © Mitsuru Nakagawa CPA office