請求書発行の仕事は「経理」か、「営業」か

請求書発行の仕事は「経理」か、「営業」か

pixta_14299515_S

 企業において、請求書の発行はとても大切な仕事です。請求書をきちんと出さないと、得意先から代金を回収できないからです。

 

 もし仕入先から請求書が届かなかったら、あなたの会社でも社内手続上、支払いができないはずです。請求書は、漏れなく正確に、適切なタイミングで出す必要があります。

 

 また、請求書の発行はリスクとも隣合わせです。誰でも簡単に発行できるようだと、架空の請求書をねつ造され、売上金を横領されるケースがあります。そのため、請求書発行は、請求印の使用者限定、オリジナルな請求書用紙の活用、請求書の連番管理、再発行の原則禁止等、厳格な管理で不正が起きないようにします。

 

 創業時や企業規模が小さい頃、請求書発行はたいがい管理部門が行います。それは厳格性、正確性だけが理由ではありません。営業担当者に営業に専念してもらうためです。営業部に営業事務を置く余裕がないので、管理部が営業事務を兼務して請求書発行している面もあります。

 

 さらに、会計も理由の一つです。売上の計上基準は“検収基準”か“出荷基準”です。しかし、販売管理や在庫管理システムが構築されていないと、検収や出荷のタイミングで売上計上するのは手間がかかります。請求書発行と同時に会計処理するほうが楽です。経理が一緒に処理する形になりやすいのです。

 

 しかし、企業が一定規模になると、経理部の請求書発行では業務が煩雑になったり、問題が発生したりします。

 

 例えば、請求書の記載間違い。社員数が20~30名だと、経理担当者と営業担当者の机の距離は近く、自然と営業情報が入ってきていたでしょう。何か疑問点があっても、すぐに声がけできました。

 

 それが社員数100名ともなると、営業部と経理部のフロアーが別になることも少なくありません。営業情報は遮断され、営業から経理へ事務的なメールや紙の“請求書発行依頼”が回覧されるだけです。従前よりはミスが発生しやすくなります。

 

 そうなると、今度は「営業担当者が請求書を確認すべき」となり、営業部(請求書発行依頼)→経理部(請求書発行)→営業部(請求書内容確認)という流れになります。日数はかかる上、営業担当者の負担軽減の趣旨からも遠ざかります。

 

 一方で、経理も問題を抱えています。営業から提出される“請求書発行依頼”に不備があるのです。営業が請求依頼そのものを忘れたり、内容に間違いがあったりします。経理がその都度「請求書を出し忘れていませんか?」「この金額はおかしくないですか?」と確認していると切りがありません。

 

 結局、経理は経理で営業とは別に、売上に関する契約書や書類のコピーを手許に持ち始め、請求書発行(売上計上)の予定を独自に管理します。営業と経理による請求業務の2重管理です。営業は経理のフォローを当たり前に感じ、自己責任の意識がいつまでたっても芽生えません。

 

 売上高が増えれば、このやり方ではいずれ業務が破綻します。システムの新規開発や更新を機に、売上計上のあり方、請求業務のプロセスを一から見直します。

 

 その際、請求書発行の仕事は“経理”が良いのか、それとも“営業”が良いのか、というテーマが度々出ます。答えは、企業規模、IT化の状況、ビジネスの形態、組織によっても異なり、一概には言えません。

 

 ただ、企業が成長し、IT化が進めば、いずれは営業の仕事にならざるを負えません。営業担当者がやるか、営業事務がやるかの違いはありますが、それが全社最適化の方向性です。

10年に一度のチャンスを逃すな!システムの更新

pixta_8300041_S

 

 あなたの企業では、基幹システムを何年ごとに更新していますか? 5年、10年、15年・・・。現行システムがいつから稼働したか調べてみると、思いのほか年数が経っていてビックリするかもしれません。

 

 基幹システム構築には、例えば、年商100億円の中堅企業で数億円かかります。構築期間も、次期システムの検討着手から安定稼働まで数年はかかります。

 

 企業の屋台骨を支えるシステムですから、当然システム開発の難易度も高く、どの企業も基幹システムを一度構築すると、追加修正開発を繰り返して、10年以上、できるかぎり長く利用しようとします。

 

 それでも、現行システムを永遠に使い続けることはできません。

 

 基幹システムのサーバーの耐用年数やリースの期限切れであれば、まだサーバーの載せ替えやリース期間の延長で対応できます。しかし、基幹システムを動かしているソフト(サーバーOSやミドルウェア)の保守切れや、開発言語の陳腐化ともなると物理的に限界です。

 

 また、変化の激しい現代では、10年も経てばビジネス環境が一変します。構築時には想定できなかった新しい業務や要望も、最初のうちは修正追加開発で何とか対応できますが、それらの数や範囲が増え続けると、ツギハギだらけの基幹システムは動くのがやっとのブラックボックスとなります。事実上の保守不能状態です。

 

 さらに、システムで対処できなくなった業務では、手作業、紙・Excelが横行し、システムとそれらの2重入力・3重管理が当たり前となります。業務は非効率の極みとなります。

 

 このように基幹システムの刷新時期が必ずやってくるわけですが、それは言い換えれば、10年に一度の業務改革のチャンスでもあります。

 

 今の時代、システムと業務は表裏一体です。システム更新と抱き合わせでないと、大胆な業務改革はできません。実際、基幹システムの更新に当たっては、どの経営者も業務改革を同時に指示します。

 

 しかし、現実は改革成功企業と失敗企業に分かれます。成功企業は次の10年の飛躍が約束されますが、失敗企業は逆に10年間のハンディを背負います。基幹システムの更新は、企業にとって重要なターニングポイントなのです。

 

 改革の成否の差はどこからくるのか。その答えは、経営者の頭の中にあります。失敗する企業の経営者は、基幹システムの更新を“システム開発7”:“業務改革3”と考えています。業務改革を唱えながらも、主体はシステム開発プロジェクトです。

 

 逆に、改革に成功する企業の経営者の考え方は、その比率が逆(3:7)です。基幹システムの更新は、業務改革のキッカケにすぎません。改革が目的であり、システム開発はその手段なのです。

 

 そう考えていくと、自然にプロジェクトは二つに分かれます。改革推進プロジェクト(システム構想プロジェクト)と、それを実現するシステム開発プロジェクトです。前者は経営企画部門・社長直轄の戦略チームが主体となり、後者は情報システム部門が中心となります。

 

 10年に一度の基幹システムの更新。この業務改革の最大のチャンスを生かすも殺すも経営者次第です。システム開発中心のプロジェクトに、業務改革も一緒にさせるやり方では到底うまくいきません。そのような体制では、経営者自身でさえ、改革達成に不安を覚えることでしょう。

 

 基幹システムの更新時期が近いうちに来るならば、まずは先行して業務改革プロジェクトを立ち上げるのが理想です。

システム開発で「◯◯はできますか?」は要注意

pixta_9378899_S

 システム開発では、ユーザー企業からITベンダーにたくさんの質問を投げかけますが、よくあるのが「◯◯はできますか?」と言う質問です。特に多いのが、発注前のベンダーや製品の選定段階、発注後の要件定義やフィット&ギャップ分析の時です。

 

 選定の際に、ITベンダーの営業担当者に聞けば、ユーザー企業のリクエストに「◯◯はできません」とは言いづらいものです。案件を受注したいので、大規模なカスタマイズ工数がかかり、本来は「できない」と言うべき機能であっても、「カスタマイズすれば、大丈夫です」とか「対応できます」と答えることが少なくありません。

 

 また、要件定義の時に、SEに「◯◯はできますか?」と聞くと、SEはユーザー企業の希望をできる限り叶えるのが自分たちの仕事だと考えていますから、真剣に受け止め、極力つくる方向で検討します。

 

 システム開発の怖いところは、もしお金と時間を無限に使えるなら、おそらく「開発できない機能はない」という点です。

 

 そのため、ユーザー企業が何の制約条件もなく、ただ「できるか・できないか」の二択を迫れば、それはベンダーの技術力を問うている話です。難しくても、「◯◯はできません」や「止めるべきです」とは言えず、「何とかします」あるいは「できなくはない」と言う回答になります。

 

 しかし、その時のベンダーの真意は、その機能は「作りたくない」、「作るのは止めておいた方がいい」というものです。きちんとその辺の事情・見解を伝えてくれる担当者もいれば、ユーザー企業の聞き心地の良いことしか言わない担当者もいます。

 

 さらに、日本人特有の曖昧さも加わり、ユーザー企業はシステム開発リスクを見誤ることになります。諸外国と比べ日本企業のシステム開発が失敗しやすいのは、こういう事も原因の一つなのでしょう。

 

 「◯◯はできますか?」と言う質問をする時は、目的(単なる事実・状況確認なのか、正式なユーザーとしての要望なのか)、必要度(必須か任意か、任意の場合は高中低くらいのレベル)、予算規模・開発期間も合わせて正確に伝えます。

 

 そして、ベンダーのYES・NOを丸呑みすることなく、具体的な点まで踏み込んで社内でも確認し、慎重に選定ないしは機能開発を判断します。

トップページ > 2016年 > 3月

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


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

Copyright © Mitsuru Nakagawa CPA office