やっぱり生産性のカギはシステム

やっぱり生産性のカギはシステム

 先週の土曜、たまたまテレビを見ていると、「陣屋」という単語が聴こえてきました。

 

 陣屋と言えば、鶴巻温泉の老舗旅館です。将棋の名人戦や王座戦など数々のタイトル戦が行われています。対局の時に特別に用意される「陣屋カレー」は有名で、いつかは食べてみたいです。

 

 テレビ番組の内容は、陣屋の経営改革の話でした。10年前にサラリーマンをしていた息子夫婦が事業にたずさわってみると、最初は経営状態や生産性の悪さに愕然としたそうです。

 

 紙ベースの予約台帳や顧客台帳。ノートやメモの文化だったのでしょう。そして、スタッフの情報共有もれ。

 

 宿泊業ですから、食事の献立をふくめ、お客さんの細かなリクエストや注意事項があるはずです。口頭やメモ中心だと、現場の段取りが悪くなったり、お客さんの満足度も低くなったりしてしまいます。

 

 また、このような状況では、売上や人件費、材料費などの原価を把握するのに、時間がかかっていたことでしょう。もしかしたら支払いや決算の時にならないと、わからなかったのかもしれません。

 

 そこで、お二人が取り組んだのは徹底したIT化でした。スタッフにはタブレットを持たせ、すべての情報はデータ化し、共有・蓄積させていました。

 

 さらに玄関には監視カメラが着いていて、車両ナンバーを読み取り、どのお客さんがご到着したかまでも把握し、スタッフや調理などに瞬時に伝達するしくみは、感心しました。

 

 これにより従業員は3分の1の数で回るようになり、昨年からは週休3日を実現したそうです。

 

 実際、ここまでの仕組みをつくるのには、並大抵の苦労ではなかったはずです。女将さんは「最初の3年間はトライアンドエラーの連続でした」と語っています。

 

 紙からタブレットへの変更は、慣れない人にとってはものすごい抵抗もあるでしょう。古参のスタッフからは「私に辞めろ、ということですか?」と泣きつかれたこともあったとか。

 

 これを乗り切れたのは、その当時お二人が30代と若かったからということと、もう一つ理由があると思いました。それは、入力(インプット)・出力(アウトプット)を徹底的に現場が使いやすいように工夫したことです。

 

 タブレットは音声入力・ペン入力でできるほか、その入力フォームやマスタは相当研究したのではないかと思います。

 

 また、視認性を考えて、調理場やフロントには大型モニターが置いてありましたし、関係スタッフにアラートや通知が即時にいく仕組みがある感じでした。

 

 システムが現場で使えるか否かは、究極のところI/O周りがいかにストレスフリーか、ということにつきます。毎日使うシステムだからこそ、何年も試行錯誤して改良をつづけたのでしょう。

 

 この陣屋が独自開発したシステムは、旅館やホテルに270社以上に販売されているそうです。もし陣屋に泊まりにいくことがあったら、カレーだけでなくシステムの運用状況も見たいですね。

医者の不養生とIT会社の・・・

  「医者の不養生(ふようじょう)」ということわざがあります。コトバンクによると、その意味は「人に養生を勧める医者が、自分は健康に注意しないこと。正しいとわかっていながら自分では実行しないことのたとえ」です。

 

 私の個人的な見解ですが、これと似たことに「IT会社の非効率」があると思っています。

 

 IT会社と言えば、「ITリテラシーが高く、社内業務の効率化・生産性にも強くこだわっている」と思われるでしょう。しかし、私は独立してからずっと企業の仕組みを立て直す仕事をしていますが、思いのほか相談や依頼が多いのが、設立10年にも満たないIT系の会社です。

 

 それはなぜか? そのようなIT会社には2つの大きな共通点があります。

 

 

 工場を有する製造業、店舗展開する小売業や飲食業などが成長するためには、設備投資がかかせません。

 

 工場を新設するにしても、物件を借りて店舗をつくるにしても、それなりに時間もお金もかかりますし、設備投資したからといっても、そのリターン(回収)には上限があります。

 

 一方、IT系の事業は、重厚な設備投資が必要ありません。サーバーすら今は従量制で借りる時代です。基本的に身軽です。さらに、リターンには上限がありません。大ヒットすれば爆発的に売上が上がります。

 

 IT系の会社は成長スピードが速すぎて、社内の仕組みを整える時間がないのです。

 

 

 驚くかもしれませんが、IT系の会社は情報システム部門が無かったり、組織があったとしても、パソコンやサーバーなどのハード保守が主業務だったりします。

 

 理由としては、ITの本業のほうで、たくさんのシステムエンジニアやプログラマーを抱えているので、社内の業務のちょっとしたことなら、社内エンジニアに頼むことが日常化しているからです。

 

 しかし、彼らは業務システムのプロではありません。会社全体のシステム計画を考える立場でもありません。どうしてもその場しのぎの形で、部分的にシステム対応することになります。

 

 

 その結果、企業規模に見合う適切な業務システムが構築されないまま時が過ぎてしまいます。

 

 業務のIT化が進んでいないので、社内の書類は紙媒体が多く、一方でIT系らしく様々なアプリやチャットを利用してるため、必要な情報を集めるのにはコピー&ペーストばかりになってしまいます。

 

 そのため、管理部は日々のオペレーションに追われて、決算・開示に十分なリソースを確保できません。担当者は残業が続き、ミスも多くなり、最後は体調を崩す人すらでてきます。

 

 そして、どうにもならなくなって弊所にお越しいただく、というパターンが多いのです。

 

 医者の不養生とならないよう、IT会社は早めに業務のしくみ化を実行しましょう。

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

  日本に消費税が導入された年は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