「製造」と「営業」の対立の先に

「製造」と「営業」の対立の先に

pixta_13286768_S

 製造業にとって「製造部」と「営業部」の関係は重要です。両者の意思疎通が悪いと、仕様変更の連絡が届かなったり、顧客への追加請求が漏れたりします。また、双方が意地を張り合うと見積時の納期や価格で折り合えず、とれる仕事も失注してしまいます。

 

 製造と営業が対立しやすい要素に、営業から製造へ生産手配する際の「社内価格」があります。社内価格とは、営業部と製造部との間の取引価格であり、営業部は社内価格を「見積原価」として使い、製造部は「生産高」として利用します。

 

 社内価格は、社内に需要と供給の論理を持ち込みます。営業部は社内価格が安いほうがよく、製造部は高いほうがよいわけです。このような社内の競争原理の有用性は、稲盛氏のアメーバ経営(チーム別採算管理)にも述べられています。社内価格の仕組みは、正しく機能すれば業績に貢献するはずです。

 

 ただし、それには部門間の駆け引きや製販の力関係ではなく、全社的に見て適切な社内価格を設定できるかどうかにかかっています。

 

 一例として、工場を2つ持つ製造業の社内価格を考えてみましょう。A工場は築30年以上経過した建物、B工場は新築だとします。A工場の減価償却費の負担はほぼゼロですが、B工場はかなりの金額です。同製品を同数生産した場合、A工場の原価は低く、B工場は高くなります。

 

 もし社内価格を工場別に設定すると、A工場の社内価格はB工場よりずっと安くなります。営業の手配はA工場に集中し、B工場は新築にも関わらず閑古鳥が鳴くでしょう。

 

 では、A工場とB工場の原価を足して2で割った、AB共通の社内価格にしたらどうなるでしょうか。

 

 A工場のみの安い社内価格だった時には、市場競争力がありました。しかし、B工場ができたことで、B工場の減価償却費分だけ社内価格はアップします。社内価格と外注価格を比べて外注価格のほうが安いと、営業は社内工場へは手配せず、外注先に発注します。そのほうが営業部として利益が残るからです。

 

 「会社全体の利益より部門利益が優先される状況はまずい」と、A工場のみの時の社内価格に戻したとします。そうすると、今度は製造部で不満が溜まります。B工場の減価償却費分、赤字が出るからです。

 

 さらに、これは会社の体力も低下させます。営業が安売りを続けているので、B工場の建物分の投資がいつまでも回収できません。

 

 全社的な観点で見れば、営業部のミッションは「少しでも高く売ること」、製造部は「少しでも生産性を上げること」です。社内価格を社内利益の奪い合いに使っているようでは、対立構造は変わりません。

 

 社内価格は、市場価格や自社の生産能力を踏まえ、製販が協調して検討すべきものです。大切なのは、お互いの主張や考え方を正しく理解し、その上で共通の利益を考えることです。

 

 そのためには、部門の業績評価と社内価格を切り離す、あるいは社内価格も含めた評価基準の複数化も検討すべきでしょう。

セグメント情報は目的適合性が大切

pixta_9577483_S

 企業情報の大半は、セグメントされています。“得意先別”の売上一覧表、“商品グル―プ別”の販売数量、“部門別”や“店舗別”の損益計算書など。「経営報告資料でセグメンテーション(細分化)されていないものはない」と言っても過言ではないかもしれません。

 

 なぜ、企業情報はセグメントされるのか。それは、一つの大きな情報の塊だと見えないことでも、同じ種類の情報にグルーピングして小分けしてみると、色々なことがわかるからです。それを基準にして経営判断したり、対策を具体的に指示したりすることができます。

 

 セグメント情報はとても有用な情報です。しかし、その用途や使い方を間違うと、逆効果になることもあります。

 

 たとえば、店舗の業績管理に使う「店舗別の損益計算書」。一見、店長の人事評価にも使えそうですが、それをそのまま使うと、おそらく店長達から不平不満が出てきます。

 

 「うちの店舗は駅前にあるから、家賃が高い。それなのに無駄に広い事務所、1台だけの中途半端な駐車場等、売上にあまり役立っていないスペースがある。これを家賃として全額負担させられるのはたまらない」

 

 「うちの店舗は地方にあるから、社員の単身赴任者が多い。借上社宅とか、毎週末の帰宅費用とかの負担がある。首都圏の店長と比較されるのは不公平だ」等、店長達から「これを調整すべき」「この費用は控除しろ」との意見が出てくるのです。

 

 そこで店長の意見を取り入れた「店舗別の調整損益計算書」をつくります。今度は店長の人事評価は公平となりましたが、調整がバイアスとなり店舗毎の経営実態からは遠ざかります。

 

 もし、調整損益計算書を店舗別の採算管理に使うと大変です。極端な話、店舗の単身赴任者コストを本社に一部振替えた調整損益計算書を見て、「地方店舗の利益が出ているから地方出店を増やそう」とか、間違った経営判断を誘発してしまいます。

 

 このように、タイトルに「店舗別」とあるからと言って、その中身が情報の利用目的に合致しているかどうかは別問題です。セグメント情報と内容を整理する際は、2つの軸・用途で考えるのがお薦めです。

 

 1つは“商品軸”で採算管理が目的です。階層は下から「商品・サービス」「商品・サービスのグループ」「部門・店舗・営業所」「事業部」「会社」で、商品からビジネスユニットまで展開します。真実性が求められ、売上高・売上総利益(粗利)・営業利益・貢献利益等が中心です。

 

 もう1つは“組織軸”です。個人や役職者の人事評価が目的で、階層は下から「社員」「チーム」「部長・店長・営業所長」「事業部長」「役員」で、公平性が求められます。売上高対前年比等の目標達成や管理可能利益が中心となります。

 

 事例では、異なる軸なのに同じ「店舗別の損益計算書」を使おうとしたからおかしくなったのです。経営の両輪である「人」と「業績」の管理。目的にあったセグメント情報を活用しましょう。

オービック情報システムセミナー2016年夏 講演のお知らせ

 6月17日(金)、オービック様の情報システムセミナー2016年夏【東京会場】で、中川が講演することとなりましたので、お知らせいたします。

 

●セミナータイトル

 『お金をドブに捨てないシステム開発の教科書』の著者が語る!
 経営の視点が投資効果を上げる!システム構想のケーススタディ

 

●日時

 2016年6月17日(金)9時30分~11時00分

 

●場所

 東京都中央区京橋2-4-15 オービックビル
 オービックコミュニケーションプラザ

 

●内容

 システム開発は「全て情報システム部にお任せ」「ノータッチ」という人も少なくありません。しかし、売上や利益に貢献するシステムをつくるためには、現場 業務だけでなく経営の思考や着想が不可欠です。当セミナーは、経営者や経営幹部をはじめ、企業システムに関係する全ての方(情報システム、経営企画、経理 部など)を対象に、”投資効果を上げるシステム”をつくるための経営の視点とは「どういう発想」で「どこに着目」すればよいのかを、ケーススタディを交えて解説します。

 

 詳しくは主催者様のセミナーページをご覧下さい。

社内で契約書が氾濫する理由

pixta_14295100_S

 よく見かける社内光景の一つに“契約書の氾濫”があります。色々な人たちがそれぞれ同じ契約書をコピーしてファイリングしているのです。

 

 営業担当者は、自分の案件の取引内容を確認するため、一部コピーして保管します。営業事務の担当者は請求書を発行するため、経理部は売上計上のタイミングや売上予定金額を知るためです。最後に総務部は原本保管とは別に予備としてコピーします。

 

 なぜ、このような状態の会社が多くなってきたのか。その理由は経営環境の変化にあります。

 

 第1に、日本も契約社会化が一段と進みました。米国ほどではないにせよ、契約書の種類や分量が増えています。取引に当たっては取引内容や条件が詳細に規定されるようになり、個人情報保護・秘密保持・反社会的勢力の排除等の追加の関連条文や契約も当たり前になりました。

 

 第2に、商取引が多様化しました。単純な商品や製品の販売では、取引を始める前に諸条件を定型化した「基本契約」を締結し、それを前提にした発注書(ないしは電話注文)で取引成立です。

 

 しかし、個々の取引で諸条件が異なる場合や、そもそも定型化しづらいビジネスモデルについては「基本契約」を締結せず、取引の都度「個別契約」を締結します。取引が個別契約形態だと、企業の契約書は格段に増えます。

 

 第3に、内部統制制度の厳格化です。上場企業の内部統制報告制度(J-SOX法)や、不正防止のための内部体制の整備で、業務のリスク低減が求められました。請求書の発行もれ、売上の計上もれや金額間違い。これらを防止するのに、手っ取り早く強力な手続きが「契約書による確認」だったのです。

 

 このように経営環境が変化し、契約書の重要性や利用頻度が増えてきているのに、多くの企業では契約書に関する業務が変わらないままでいます。その結果、「皆が契約書をコピーし、自分のデスクに分厚い契約書ファイルを保管する」という、何とも非効率でムダな状態が生まれています。

 

 では、どのようにすれば良いのか。

 

 1つは契約書の電子化・共有化です。社内の利用者や確認事項が増えているのですから、必要なタイミングで閲覧できるようにします。

 

 たとえば、文書管理システム。文書管理システムとは、社内の電子化文書(紙をスキャンした画像文書)、電子文書(Word、PDFで作成された文書)を一元管理できるシステムです。主な機能としては、ライブラリ機能、バージョン管理機能、属性管理、検索機能、配布・共有機能、アクセス管理機能等があります。

 

 このようなシステムを前提に、新しく契約書の作成・管理・閲覧ルールを定めて運用できれば、契約書の重複管理を減らし、検索も容易となります。さらに、ワークフローの稟議申請とリンクさせたり、提案書をナレッジ化したりなど、ほかにも効果を期待できます。

 

 もう1つの方法は、「契約書」ではなく「契約情報」の電子化・共有化です。増大した契約内容のうち、業務に必要な契約情報だけをデータベース化します。

 

 本来ならば、このような役割は販売管理システムや債権管理システムが担っています。受注案件毎の取引条件・出荷予定日・金額、得意先の基本情報・入金条件等。受注から売上の計上、入金消し込みまでを管理できる仕様のはずです。

 

 しかし、諸条件が多様化してイレギュラー処理やシステム外管理が増えてくると、各担当者は契約書のコピーを手許に置き始めます。販売管理や債権管理システムを改良して、複雑な条件でも処理できるようになれば、契約書の氾濫は沈静化します。ただし、高機能化には費用対効果の話もありますので、その点は注意も必要です。

 

 契約書の氾濫は、経営環境が変化しているのに業務プロセスが変化していない典型的な事例です。仕組みの不適合はムダの発生だけでなく、業績にも悪影響を及ぼします。ビジネスや状況の変化を正しく把握して、経営や業務の仕組みを改善していくことが大切です。

要件定義で協力するのはユーザーかベンダーか

pixta_19262966_S

 システム開発プロジェクトのキックオフミーティングで、ベンダー側の何気ない発言が気になったことがあります。それは、「・・・・ですので、(ユーザー企業の)皆様におかれましては、ぜひご協力ください」と言うフレーズです。

 

 「ベンダーがユーザー企業に協力を求めるのは、当たり前だろう」と言われれば、そのとおりなのですが、なぜか引っかかったのです。

 

 システム開発は、ユーザー・ベンダーの双方の協力があってこそ成功します。この方の発言に他意はなく、とても良いあいさつでした。

 

 でも、これを聞いた瞬間、「会社側のメンバーが受け身になってしまうのではないか」と危惧したのです。紳士的でソフトな語り口。ベンダーにおまかせすれば、万事上手くいきそうな、そんな錯覚を覚えるような内容でした。

 

 システム開発は、大きく4つのプロセスで構成されています。「要件定義」「設計」「開発」「テスト」です。

 

 このうち、「要件定義」「テスト」はユーザー企業が主体となるフェーズです。実際、システム開発契約でも「要件定義」「テスト」は準委任契約、「設計」「開発」は請負契約と形態が異なるケースが多いです。

 

 準委任契約とは、かんたんに言うと、「ユーザー企業がやる「要件定義」や「テスト」を、システムのプロであるベンダーが応援します」という契約です。ベンダーは誠意をもって一生懸命やればよく、完成責任は問われません。

 

 一方、請負契約はベンダーが「設計」「開発」の完成義務を負う契約です。ユーザー企業の協力の有無に関係なく、ベンダーは責任を持って完成させないとなりません。

 

 話を元に戻すと、「要件定義」はユーザー企業に最終責任があります。ユーザー企業のプロジェクトメンバー自らが、責任を持って積極的にやらないと質の高い要件定義ができないのです。もし質が悪いと、開発の途中で「やっぱりこうしたい」と手戻りしたり、想定があまくて稼働後に運用に耐えられなかったりします。

 

 もちろんベンダーも要件定義が上手くいくように全力を尽くしてくれますが、それにも限界があります。やる気のない子供に無理に勉強を強いるような話です。勉強は自らがするものであり、他者には強制できません。

 

 だから、「検討する時間がない」「よくわからない」とか言って、要件定義に真剣に取り組まないユーザー企業には、ベンダーがミーティング議事録を作って「言いましたよね」「このように決まりましたよ」と言質を取るのです。

 

 しかし、それはベンダーの保険にすぎません。肝心のプロジェクトは失敗リスク(予算超過や稼働遅延)が著しく高まります。何の解決にもなっていないのです。

 

 要件定義で協力するのはユーザーかベンダーか。この問いの答えに「双方」と言えば聞こえは良いですが、私は「協力するのはベンダー、やるのはユーザー」と、はっきり言っておきたいです。ユーザー企業のプロジェクトメンバーひとりひとりが「自分達で考えないとならない」という自覚を持つことが大切です。

 

 ですから、最初のキックオフで、それぞれの役割や立場を明確に伝えておかないと、参加者が勘違いしてしまいます。「ぜひご協力ください」という言葉が悪いわけではなく、ユーザー企業に自覚を促したうえで、「双方協力しましょう」が良いのだと思います。

 

 ベンダーはユーザー企業から仕事をいただく立場です。そのため、得てして低姿勢になりがちですが、それが日本企業のシステムトラブルの遠因になっているのかもしれません。

 

 ユーザー企業はベンダーにあまやかされないように注意し、システム開発に対する正しい理解と責任感を持ちましょう。

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

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


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

Copyright © Mitsuru Nakagawa CPA office