2017.09.27
「当社は、仕入で買掛金の違算は出ません。」
財務調査などで、仕入業務について質問すると、このように回答する会社があります。
違算とは、会社が認識している買掛金と、仕入先の請求書の金額が異なる状態を言います。違算が発生する理由は、会社と仕入先との締め日の違い、どちらかの値引き、返品などの伝票処理もれ、商品の単価違い、数量違い、品違い等です。
このため、違算が出ない会社は、管理がしっかりした会社だと思われがちです。
たしかに、違算が出ないという会社の中には、事務周りや仕入先の指導が行き届いている会社もあります。しかし、大半はそうではありません。むしろ適度に違算が出ている会社より危険な業務体制であることが多いです。
一般的な仕入業務は「発注」「入荷」「検品」「仕入」「支払」の流れです。
入荷時に発注書と納品書を、検品時に納品書と商品現物を確認し、仕入を確定させ、買掛金の金額が決まります。そして、翌月に届いた請求書と帳簿の買掛金を確認して、支払いをします。
違算は、翌月に請求書と買掛金を突合したタイミングで現れます。そこで、前月の当社ないしは仕入先の処理間違いを見つけるわけです。もし会社に非がある場合は、当月で仕入（買掛金）の修正をかけます。
一方、違算が出ない会社の仕入プロセスは、「発注」「入荷」「検品」「支払」「仕入」の流れです。「支払」と「仕入」が逆転しています。
入荷・検品時には仕入を確定させず、翌月に仕入先の請求書が届き、支払を確定してから仕入計上、ないしは支払直前に仕入計上します。
つまり、違算が出ない会社は、仕入先の請求書を見てから仕入計上、買掛金の金額を決めています。だから、違算が出ないのも当たり前です。
では、なぜこのような処理が業務として危険なのか。
理由の１つめは、仕入先の求めた金額をそのまま支払っているからです。会社としてのあるべき買掛金（支払額）を持っていないので、請求どおりに支払っている可能性があります。
２つめは、発注と発注消込の問題です。請求ベースで仕入計上するのは、発注管理が弱くて納品ベースで仕入計上できないからです。発注管理の仕組みが悪いと、不要不急な商品の発注や重複発注が頻発します。
３つめは、月次決算が遅く、場合によっては月中で粗利（業績）を把握できていないからです。翌月の請求書をチェックして、ようやく仕入や在庫が固まり、前月の営業成績がわかるようでは、利益を追求するスピード経営はできません。
仕入で違算が出ないこと、それ自体は良いことですが、はなから違算が出ない仕組みでは、意味がありません。経営的に危険を内包しているので、仕入業務の見直しが必要です。
2017.09.20
業務やシステム、内部統制のしくみを考える上で、ヒューマンエラーをどのように防ぐかは、重要な話です。
よくある仕組みが「二重チェック」です。ヒューマンエラーを完全に防げないならば、エラーがある程度発生することは容認し、もう一人が確認することでエラーを防止する仕組みです。
たしかに二人が同時に間違える確率は大幅に低いので、二重チェックは効果が高い施策です。しかし、何にでも二重チェック化すると、緊張感が無くなり形骸化します。
また、二重チェックは手間がかかります。確認作業とはいえ、もう一人がすべてに目を通すわけですから、事務コストが上がります。システムによる確認もありますが、その場合は開発コストがかかります。
二重チェックは安易に多用すべきではなく、リスクが高いところに限定的に用いる手法だと言えます。
ヒューマンエラーを防ぐために大切なことは、事後的にエラーを防止するのではなく、エラーそのものの発生を抑える、無くすという思考です。
医療で言うと、病気を治す「治療」ではなく、病気にならない「予防」です。業務にも予防という思想を取り入れることで、エラーの発生率を大きく低減することができます。
具体的に言うと、エラーの多くは、特定の取引先や商品だけ違う処理をする、50回に1回に特別な処理が発生するなど、特殊な場面で発生します。不規則・不自然な動きが、ミスを誘うのです。
これは処理だけの話ではありません。普段と違う動作パターン、思考パターンも含みます。たとえば、システムの入力方法がここだけ順番が違う、単価×数量＝金額のところに何か係数掛けする、などの変則的な動きです。書類や帳表のレイアウト、取引条件や社内組織の場合もあります。
特に思考の流れは目に見えませんし、設計者の独自の癖が入りやすいと言えます。ですから、業務フローやシステムのＩ/Ｏ周りを考える際は、これらの不規則・特異点を減らすようにします。
これを最も具現化したのが、マイクロソフトのOffice製品やアップル製品群でしょう。各社の製品を何か使えば、他の製品もなんとなく使えたりします。機能やデザインが統一されているのに加え、思考や動作の流れが理にかなっているので、わかりやすいのです。
さらに、不規則や特異点の削減は、エラー防止だけでなく属人化を防ぐことにも役立ちます。業務の専門性が高くなくても特殊性が極まると、「A氏でないと、この業務はできない」となってしまいます。
動作の流れを統一したり、思考の流れを秩序化したりして、ぜひセンスが良い仕組みを心がけて下さい。
2017.09.13
全社プロジェクト（全社横断プロジェクト）は、職能別組織の中では解決できない経営課題を解決するのがミッションです。よくあるのが次期システムの検討、組織構造やビジネスルールの見直し、業務改革（BPR）などです。
これらは業績に与える影響が大きい上、難易度も高いです。なぜなら、課題を解決するために、考慮しなければならない要因が複数あるからです。
経営、システム、管理業務、現場業務、経理処理、支払処理・・・これらの実務に加え、予算や人の問題もからんできます。さらに、取引先、法律、商慣習などの外部要因もあります。
全社プロジェクトは、複数のパラメータを持つ、多次元連立方程式を解くが如しです。
では、どうすれば全社プロジェクトを成功に導くことができるのか？
まず、メンバーの意識を変えることが大事です。各部門から全社プロジェクトに集められたメンバーは、ともすると自分は部門の代表だと思っています。「部門の利益を守るために、しっかり主張するべきことは主張しないといけない」と。
全社プロジェクトは、利害調整の場ではありません。皆で知恵を出し合い、会社にとっての最適な対策・施策を出すのが目的です。ここを勘違いしている人がいる限り、議論はかみ合わなくなります。
次に大切なのが、メンバー全員が複数要素、多軸を理解することです。たとえば、経理部の人なら、専門の会計処理や支払処理だけでなく、経営・システム・現場業務などの知識や情報を把握します。
もちろん、経験もない分野を理解することは大変ですし、人によって理解度には濃淡があるでしょう。しかし、前述のとおり、全社プロジェクトは多次元連立方程式を解くことですから、重要な一次元が完全に未知なら、正しい回答にはたどり着けません。
ポイントは、すべての分野で高いレベルで精通する必要はなく、議論ができるくらいの知見と、その分野の勘どころを押さえることです。
多くの全社プロジェクトで、最初に「現行調査」というフェーズをやるのは、現状把握だけが目的ではなく、参加メンバーが門外漢の知見・情報を共有する場でもあるのです。
最後に大切なのは、この多次元連立方程式を一人では解かないことです。三人寄れば文殊の知恵と言いますが、メンバー全員で議論して最適解を見つけていきます。
そのために、ブレインストーミングという手法やマッピングソフトがあるわけです。理解度に濃淡があったとしても、多軸を理解したメンバー同士で話し合えば、自然と合理的な解に落ち着くものです。
ぜひ、これらを参考に全社プロジェクトを成功させて下さい。ビジネスリーダーが多軸を理解する一助になるよう、三位一体改革コラムを書き続けたいと思います。
2017.09.06
インターネットで検索すると、同じような業務をこなすパッケージシステムが、世の中には数多くあることがわかります。
手当り次第、パッケージベンダーとコンタクトを取り、製品の標準機能や適合性を詳しく調べていくことができれば良いですが、それは時間も費用もムダです。
最初の段階で、自社に合う有力な２、３製品に絞り込むことが必要です。
この絞り込み作業は非常に重要です。これを間違うと、選定作業が手戻りになったり、システム導入の失敗につながったりします。良い製品に当たりをつけることは、システム成功の隠れたカギなのです。
では、どのように当たりをつければ良いのか？
一番は、そのパッケージ製品を知っている人に聞くことです。製品サイトには色々と良いことが書かれているが、実際に導入して見てどうだったか？ もし生の声が聞けるなら、それが最高の判断材料です。
中堅企業の会計系パッケージであれば、有名どころはほとんど知っていますが、やはり知らないパッケージに遭遇すると、私もまず知っていそうな人を探します。システムは目に見えないものなので、口コミ情報は貴重です。
しかし、大概はそのような情報は入手できません。業種や分野ごとにパッケージが星の数ほどあるのですから、口コミ情報が取れないことが普通です。
そのような場合は、そのパッケージ製品がどれくらい売れているのかを調べます。パッケージ製品は、いろいろな会社で使われることで、機能や使い勝手が改善していきます。ですからシェアが高い製品には一定の信頼を置けます。
たとえば、富士キメラ総研の「ソフトウェアビジネス新市場」や「業種別ITソリューション市場」などを見ると、各主要分野の上位何社かはわかります。毎年、年度版（1冊15万円くらい）が出ますが、私も何年かに1回は買っています。
費用をかけたくないなら、製品サイトの閲覧数を調べます。「閲覧数が多い＝売れている」というわけではありませんが、検討の参考にはなります。
閲覧数の検証は、パッケージ製品より特にクラウド系の製品に有効で、デザインが洗練された見栄えするサイトでも、閲覧数が全然無くて、まだ普及していないことがわかったりします。
閲覧数を調べるには、WEBマーケティングのツールを利用します。私が使っているのはSimilarWebの無料版です。
これら口コミ、市場調査、閲覧数などの客観情報を優先しますが、パッケージ製品のサイトやパンフレットの掲載情報から読み解くことも大切です。
その際、重要なのは、このパッケージ製品がターゲットとしている企業規模は？ メインとなる業務は？ です。言い換えると、そのパッケージの基本コンセプト、そこがカッチリはまっていないと、あとで後悔することになります。
「何でもできる」「何でも高機能」「どの企業にも最適」という夢のようなパッケージは存在しません。ベンダーも商売なのですから、ある程度の美辞麗句と理解して、こちらも健全な消費者の目を持つことが大切です。
