- サービス
バーコードを使用した勤怠実績管理事例
給与計算ソフトにデータを連係
このシステムの概要 バーコードを使用することで、直接入力が不要な勤怠実績管理システムです(...
Excel専門|マクロ+システム開発で業務改善
業種 | |
---|---|
利用規模 | |
用途 | |
解決した問題 |
業務概要 | 見積書を何種類か提示後、その内の1つが商談成立対象。 ところが、その後納品までに変更があり、請求時に値引きが求められる。 このため、納品書、請求書の作成時に人海戦術で大わらわとなる。 |
---|---|
課題 | 基本的には見積もり時の情報を使うにもかかわらず、一部変更があるために、毎回全てを手入力している。 このため、時間がかかるだけでなく、転記ミスが生じ、顧客への信用問題となっている。 |
対策 | 原則として、見積もり時の情報を使い回すことで、転記そのものを不要とする(転記を自動化、しない)。 途中の変更履歴が残せるようにすることで、従前できたことは実現できるようにする。 |
複数の顧客で共通の課題として戴いた相談ですが、見積もり時と納品時、請求時で、それぞれ内容が異なる業界において、納品書・請求書の作成が自動化できるかどうか、というテーマです。
見積もりと全く異なる内容で請求を出すことはまずないので、内容の大半は見積もり時の情報を使い回すのですが、建設業界や情報システム開発業界のように、途中で要望が変更/追加になるのが半ば常識の業界では、納品(引き渡し)時の内容がすでに見積もり時から変わっているのが常識です。
また、納入後も要望や不備への対策などがあるため、納品時と請求内容も変わることが少なくありません。
また、卸売業や製造業では、請求時に端数分の値引きが求められることがあり、例えば1000円単位で切り捨てを行うことがあります。
このように、見積書の内容を転記すれば請求書になる、わけではない場合、はやりの「ノンコード/ローコード」ツールでは、対応が難しくなります。
当社の手がけた事例では、いずれもステータス(状態)が遷移すると捉え、同じ内容の体裁だけを、見積→納品→請求のように進めていく、という考え方に基づき、モデル化しています。
こうすることで、途中で追記や変更があっても、オリジナルからの継承性が維持され、どのタイミングでどのように変わったかを追うことができます。
実は、こうした仕組みは、Excelだけで、「ノンコード/ローコード」で実現することが可能です。例外ルールが少なければ、1週間~2週間程度で、各社固有ルールを反映した請求業務支援ツールが実現可能です。
単に請求書を自動作成するだけであれば、効果も限定的です。
一般的には、月単位で請求書を送ります。そのためには、集計のしくみが必要です。
はやりのクラウドサービス的に行う場合、SharepointやTeamsと組み合わせることで、特定領域にUploadした見積/請求データを集計することもできますが、わかりやすさで言えば「特定フォルダにあるファイルを全て集計」する方式でしょう。このやり方であれば、1日か2日程度で集計可能です(標準化されている場合)。
請求書を出すと、多くの企業では経理部門に控えを渡しているはずです。経理部門では、これを基に売掛金の仕訳を起こし、入金があれば消し込んで、未収を検出しています。
これも当社の顧客事例ですが、少なからぬ割合で、会計ソフト用に売掛金の仕訳データを自動作成し、経理部門ではファイルを読ませるだけで、再入力を無くしています。
条件によっては、こうした一連の流れをタイマー起動で深夜に自動実行しており、翌日には全社で売掛見込情報が共有されるようになっています。
ここまで実現できれば、「DX」といえそうです。
最近ブームとなっている「DX」は、「Digital Transformationの略」だそうですが、略になっていないので、余計に意味不明です。
DXを簡単に表現すると
ということになります。
ここで重要なのは、目的が「③競争力を向上させる」ことであって、DX自体が目的化しかねない中、留意が必要です。
もちろん、「①デジタル技術」を十分に理解できていなければ、活用できるはずもありません。
多くの企業では、DXそのもの(場合によっては、デジタル技術導入そのもの)が目的となっているようです。
DXが目的化してしまうと、
1.他社も導入している(であろう)、クラウドサービスを導入する | 提供社がなくなる、他社と合併、バージョンアップ・・・→ 今のサービスが停止 |
2.自社のパソコン・サーバで行っていることを、クラウド化する | ルータが故障/回線不調時に、利用不能 / 毎月高額な利用料が発生 |
3.とにかく、何でも自動化しようとする | 例外に対応できない / 設定内容がブラックボックスで、メンテナンスできない |
:
といったことが起こり、「③競争力を向上させる」どころか、クラウドサービス依存が高まり、ネットに接続できないと業務が止まってしまったり、しくみがわかる社員がいないと変更できなくなったり・・・と、目的と逆の事態を招きかねません。
大抵の場合、「請求書の転記作業を自動化したい」というご相談を戴きますが、前述のような例外対応が求められるからこそ、自動化が進まないのであって、単純に自動化してしまうと、例外に対応できなくなってしまいます。
とはいえ、月初に残業が発生したり、作業ミスで誤請求につながっていたり、という課題が生じている以上、なんとかしなければなりません。
方針としては、国の機関であるIPAでも、「業務改善よりも業務改革」としている通り、発想を転換する必要があります。
そんな時には、原点に遡って考えるのが効果的です。
国税庁の課税売上等に関する事務処理指針に基づき、請求書には以下の項目を必ず記載する必要があります。
請求書発行者: | 氏名または名称、住所 |
取引年月日: | 商品の引渡し日または役務の提供日 |
取引内容: | 商品の名称または役務の内容、数量 |
取引金額: | 対価の額、消費税額 |
請求書の交付を受ける事業者: | 氏名または名称、住所 |
請求されなければ、支払われませんし、根拠や金額について請求先と認識が合わなければ、支払いに応じてもらえません。
請求書を受け取った側では、請求の根拠として保管が法的に求められており、一定の情報を含むことが求められます。
別の言い方をすれば、目的に叶えば、体裁はどうでもよいのです。
そもそもの話として、請求処理が省力化されたとして、競争力の向上につながるのでしょうか?
「風が吹けば桶屋が儲かる」的に無理矢理解釈すれば、競争力は向上するかもしれませんが、実際のところ、単なる省力化でしかありません。
省力化はコストダウンであり、競争力は売上/利益の向上ですから、まるで違う概念です。
請求書の発行は営業部内のケースが多く、このため同じ部署で作成する見積書→納品書→請求書の流れがつながって見えます。
ところで、請求書は発行すれば、必ず入金されるわけではありませんし、入金されない限り売上として計上することもできません。
こうした認識をしているのは、実は経理部門であり、請求を出した段階で売掛金として認識し、入金が確認できて初めて売上として処理をします。
俗に「黒字倒産」といわれる、「帳簿上は黒字なのに、手元現金がなくて決済不能に陥る」事態を回避するには、資金繰り(キャッシュフロー)の管理が必要です。
このためには、売掛と現金化するタイミングを正確に把握しておく必要があり、大きな投資/仕入などの際の意思決定に重要な役割を果たします。
このように、他部署が行っている前後の業務にも目を向けていくと、他にも「①デジタル技術を活用」すべき対象が浮かび上がります。
当社の事例では、請求書を発行するタイミングで、会計ソフト用の売掛仕訳データを作成したり、入金(振込・でんさい・クレジットカード等)の支援機能につなげたり、という広がりを見せることが少なくありません。
いずれの業務においても、例外的な事象が発生した場合に、どのように対処するかを想定しておくことが肝要です。
例えば、入金時に振込手数料分が差し引かれるケースは小売業では日常茶飯ですし、1桁間違えて振り込まれることも年に1度くらいはあるでしょう。
これが、「全自動」になっていると、こうした例外を吸収できず、それこそ機械的な対応でエラーにされかねません。
当社が得意とするExcelを使った実装では、一度Excelシートの上に展開して「見える化」した上で、例外があれば手で介入できる余地を残しておくので、大抵の例外には対応できます。
たまたま見かけたクラウドサービスがよさそうに見えても、他にももっとよいものがあるかもしれません。
すでに導入している場合でも、それが現状のベストの選択肢か、他に代案はないか、といった視点での見直しが有効です。
今やっている手順を、そのまま自動化しても、業務プロセスの変革にはつながりません。
別のやり方がないか、発想を変えて、それこそ対象範囲の見直しから行うべきです。
当社では、匿名で電話相談に応じています。
電話口なので、現状のお困りごとを聞いた範囲でお答えできる内容となりますが、5~10分ほどで約半数の方が「方針が見えてきたので、自力で再検討してみる」との感触を得ています。