クラウドの有用性とは

システムイベントは色々な分野に細分化し、蛸壺状態に陥る危険性を孕みながらも活況を呈しております。それぞれが深化する過程で、少々のへそまがりが革命的なイノベーション(あまり意味はわかりません)を起こすのではないかなんて淡い期待も。リーマン予想と原子核のエネルギー間隔みたいなものです。

あるクラウドイベントにて懐かしいお客さんにお会いしました。私が例によってERP会計導入していた頃の喫煙室仲間であり、情報システム部の若手でした。彼は自分で中堅の責任感を持ちつつ、今後について悩んでいる「若造」(彼の言葉)でありました。当時のお話から。

「私は今までメインフレーム上のシステムを細かくメンテナンスしてました。気軽にメンテする必要がない・できないERPが入った後は何をしたらよいのでしょうか」

この人は相変わらず熱い、ゆっくり煙草を吸う雰囲気ではない。しかし、高レベルの悩みであり、ERPの存在意義にも関わる大問題である。究極の目標の「既製品・メンテフリー」となった時、「私たちは不要になるのか」である。

「あなたは今までメインフレーム上から、営業部なり各部署の要望からデータ抽出・整理して渡していました。渡した相手方は何かしらのデータ分析をしていたようです。ERPには必要な(またはそれ以上の)情報が網羅されています。システムのお守りで手が空いた分を、そのデータ分析側に割いたらいいかもしれません。やることはいっぱいあります。」

当時は「BI」なんて単語もなく、セオリーもなく、とにかくSQLをぶん投げて試行錯誤する感じでしたが、彼もOracleーSQLなりPL/SQLなり自習して、何かが見えたようです。

そんな彼が久しぶりに会い、

「クラウドの本番稼働後の品質・柔軟性は皆似たようなもので、一長一短です。それより導入作業に有用な気がします。当時あなた方(導入側)は業者の開発環境と弊社開発機環境の同期に手間をかけていましたし、何よりも大量のテストデータや移行データ流し込みの時だけリソースを増やせたり・・・」

話は尽きません、相変わらず喫煙室は熱いままです。

(推敲していませんので、徐々に更新します)

勘定科目残高再集計とは

以前別の製品を導入した時に、「勘定科目残高再集計」というメニューがあり、他の若手メンバーは「トランザクションと残高がずれるなんて有り得ない」とその有用性に疑問を呈していました。

昔はマシンのリソースに限界があり、リカバリ手段として用意していたもので、BaanやLNにも同じ機能が用意されています。

通常の運用としては、経理仕訳伝票を起票し、責任者の承認を経て元帳に転記します。その時のデータの流れとしては、仮伝票データが元帳データに転記され、同時に勘定科目残高データに加算され、親勘定科目残高データに積み上がります。

昨今のハードウエア性能は格段に向上し、処理リソース不足に悩まされる場面は減りました。しかし「夜間ジョブスケジュールがずれ込み重い処理とかちあってしまった」「伝票承認データ件数が多すぎる」等により、伝票承認処理にリソース不足が生じる可能性はゼロではありません。

このとき、意図的に「勘定科目残高データ加算」処理を中断し、同時に「元帳データ転記」処理を守ります。

そして、リソースが充分かつ伝票入力時間外にリカバリ処理を流すというものです。このリカバリ処理は毎日流す必要はないと思いますが、保険的な意味合いで定期的に流す運用とします。

(推敲していませんので、徐々に更新します)

ERPベンダの脅威とは

国際展示場の「ものづくり」イベントに参加した時の話です。

知り合いの方から頂いた招待状にて参加し、お目当てはITエリア。生産管理システムの中小ソフトウエアハウスブースを、良い商材はないか、今後に繋がるアイデイアはないか、下心を腰に携えていざ参戦。

某社生産管理システムブースにて説明を受ける。「年次計画を月次計画にばらして週次・日次そしてパー割り・・・」「ボトルネック工程、クリテイカル資材、リードタイム・・・」やはり生産計画は抜かりない、工程管理も見やすい。この業界は成熟している。などと関心していたら、ふと気になるメニューが。

購買・販売・会計・・・。「何ですか、これは」思わず口にすると「専門ではないんですけど、客先での要望をまとめて、カバーしていない部分をちょこちょこ造ってみました」と軽い回答。中身を見てみると、まだ特殊なケースをカバーし切れていないものの、実用に耐えそうなクオリテイである。「これはERPですね」との問いに「まだERPを名乗るレベルでは・・・」との謙虚な回答。

他にもアプローチ方向は違うものの、似た業者が見受けられました。みなJAVA系のウオーターフォール開発に長けた業者であり、その開発スピードには目を見張るものがあります。製品標準機能に取り込むことにも迷いがなさそうです。

「うちは純粋ERP製品です」に胡座をかいていると、このような勢力に足元をすくわれかねません。コンペで誰も知らない業者が「一番GAPが少ないが、ERPとは名乗っていない」という番狂わせが現実味を帯び、脅威を目の当たりにしました。

でも、一番興味をそそったのは「アルミ削り出しアンコールワット」でしたが。

(推敲していませんので、徐々に更新します)

取引タイプとは

見慣れない単語ですが、このお話をします。貴社の運用において例えば、購買入庫伝票や売上計上伝票と決算修正伝票はごっちゃにしていないはずで、何かしらの区分が存在するはずです。例えば伝票の色であったり、何かしらのコードかもしれません。

取引タイプとは伝票の発生元を判別するための伝票区分と読替えることができます。

購買入庫時の債務伝票・棚卸資産増加伝票。

販売出荷時の売上原価伝票。売上高計上伝票・債権伝票。

製造完了時の製造原価においては、材料費部分、労務費部分、経費部分、原価差異、その他。

経理部においては、他部門から毎月届く経理仕訳取込、月例経費振込手入力、支払伝票、その他。

枚挙にいとまはありませんが、それらを「取引タイプ」という伝票区分で3ケタ英数コードにて分類することができます。先に説明した会計統合においても、細かく割付・判別できます。そして、この「取引タイプ」は業務業態そのものであり、日常運用において毎月のように増えるものではないため、細かすぎて破たんする心配も少ないです。

会計統合なり債権債務仕訳において、(求める水準の精度の)マスタ完成し本番運用したとしても、意図しない勘定科目残高が発生することがあります。膨大な元帳データを片っ端から当たる前に、この「取引タイプ」のルール付けがしっかりしていれば、比較的短時間に「このマスタがおかしい、マスタ修正しよう」「この取引が変だ、見直すべきか」といったトレース・分析・判断が可能です。

現在の業務運用において、「誤差の拾い出しが大変」「もっと細かくトレースできれば」云々といった不都合があれば、「伝票分類がどこまで細かければよいか」を認識、整理しておくだけで、ERP導入負荷は格段に軽くなります。

(推敲していませんので、徐々に更新します)

 

取引通貨とは

通貨マスタには3ケタ英数の通貨コードとともに、通貨レート発効決算日、通貨レートを保持できます。これは他社製品にも相当する機能があると思われます。

ですので、同じ通貨のUSDに対してもUS1、US2等、メインの通貨レート以外にも任意の通貨レートを保持できます。こうして、通貨レート予約にも対応できます。

また、債券、債務、振替伝票にも通貨情報を保持しております。その中身は「取引通貨、参照通貨、自国通貨」毎に「取引金額、(取引時)通貨レート」といったもので、参照通貨、自国通貨はあらかじめパラメタ設定します。

決算等で各取引の為替レート洗い替えを行うと、為替差額分の経理伝票を起票し、履歴・残高保持し、その後の入出金時には正しく消込を行います。IFRSではこの通貨別取引残高を要求されますが、十分対応できています。

自社の取引でどのような通貨が使用・運用されているか、為替レートはいつ、どのタイミングで更新しているかを認識、整理しておくだけで、ERP導入負荷は格段に軽くなります。

(推敲していませんので、徐々に更新します)

中央請求とは

Baanの初期製品では、色々なモジュールで債権データを生成できました。しかし、そのままでは煩雑なため、「債権発生元を統合した」という意味で「中央請求」という名称の機能が造られ、今に至ります。

先の説明で、「ロジ取引は会計統合をもって経理伝票に反映」と伝えましたが、それは舌足らずです。債権債務はその後のタスクの存在、それに伴う緊急性により、早急に会計部門に伝える必要があります。そのため、債権債務は会計統合とは別の仕組みを持ちます。このうち債権部分の「中央請求」のお話をします。

販売出荷を行うと、裏側でその情報が記録されますが、ここで会計統合に記録されるのは倉庫要件のBS資産減少情報のみです。その他の情報は中央請求処理で生成します。具体的には「売上原価、売上高、債権」です。それらを会計統合および会計債権管理モジュールに連携します。

もちろん、債権・入金業務にはイレギュラーは付き物で、それを吸収する仕組みも用意しています。会計側に渡った債権データは履歴構造を持ち、債権100万のうち、80万一部入金や、債務の10万と相殺したり、多彩なケースをカバーします。

「中央請求」処理は会計統合とは独立しているので、単独軽量にバッチ処理できます。お客様の要件により、昼間に流す運用も見受けられます。また、顧客を分類して小分けに流す運用も可能です。

(推敲していませんので、徐々に更新します)

自己請求とは

購買請求とは業者様から請求書が届いて初めて債務と認識すべきです。しかし、その運用を実現しようとすると、「あの納品はまだ検品が済んでない」「不良品があったんだが」色々面倒なやりとりが伴います。そのやりとりの時間経過により、契約上の支払日にインパクトを与えかねません。全体請求金額の数%に満たないやりとりのために多大な金額の資金繰りの心配はしたくありません。

ならば、「検収済数量・金額は保証します、数%の祖語は後日調整しましょう」というやりとりも意味を持ちましょう。

先の説明で、「ロジ取引は会計統合をもって経理伝票に反映」と伝えましたが、それは舌足らずです。債権債務はその後のタスクの存在、それに伴う緊急性により、早急に会計部門に伝える必要があります。そのため、債権債務は会計統合とは別の仕組みを持ちます。このうち債務部分の「自己請求」のお話をします。

「自己請求」は「Self  Billing Invoice」の直訳であり、同じ考え方は他製品にもあります。自社の購買入庫検収済を債務認識し、支払機能に連携するものです。

もちろん、債務・支払業務にはイレギュラーは付き物で、それを吸収する仕組みも用意しています。会計側に渡った債務データは履歴構造を持ち、債務100万のうち、80万一部支払や、債権の10万と相殺したり、多彩なケースをカバーします。

「自己請求」処理は会計統合とは独立しているので、単独軽量にバッチ処理できます。お客様の要件により、昼間に流す運用も見受けられます。また、業者様を分類して小分けに流す運用も可能です。

(推敲していませんので、徐々に更新します)

原価構成要素とは

製造原価明細の大項目として「物・労・経」と略されますが、それらを任意に細分化し、コードを付与したものを「原価構成要素」と呼びます。

製造モジュールの中で重要なマスタであることは言うまでもなく、別途解説した会計統合においても、製造原価を勘定科目変換する上で重要なキーになります。別の製造系ERP製品でも同じ考え方があります。ここでは会計側要件でそのお話をします。

まず「物」にあたる原材料および消耗品、貯蔵品、外注購買品、その他といったものですが、通常は会計側要件より製造側要件の方が細かく管理する場合が多いため、会計統合の要件としては比較的安心できる部分です。

次に「労」にあたる労務費部分ですが、会計側で発生した直接人件費・関連コストを全て表現しようとすると、恐ろしく煩雑になり、管理しきれなくなるため、適度な粗さが必要です。

最後に「経」にあたる「直接経費」「間接経費」です。

「直接経費」は機械減価償却費、工場光熱費、工場地代家賃、その他ですが、製造部門側でも重要な関心事であり、詳細な区分が要求されます。時間単価を算出・改訂する上でも貴重な参考データになります。会計統合の要件としては必要な粒度が確保しやすい部分です。

「間接経費」は間接部門人件費、間接部門経費等、製造部門が管理しきれないあらゆる要素が関連するため、その粒度は会計要件とならざるを得ません。製造現場においては機械時間単価として稼働時間で製造原価に付加させたり、倉庫付加費用といった方法で在庫評価額に付加させることもできます。

もちろん、これら時間単価、倉庫付加費用等をいくらにすべきかを算出するのは多大な労力を伴いますが、望む精度を確保できれば、そこから得られる恩恵も多大なものです。

これらの原価構成要素をキーに発生した標準単価、実際原価は「原材料⇒中間品⇒製品」へと積み上がり、製造原価明細上で詳細な分析が可能になります。

そして、この原価構成要素の粒度も正解はなく、その他原価関連マスタ検討作業も決して軽くはありません。(望む精度の)マスタ完成後にも原価管理に悩み、終わりはありませんが、その悩みは「格段に高次元の原価管理」であることは間違いありません。

(推敲していませんので、徐々に更新します)

 

会計統合処理とは

会計統合マスタが形になりましたら、ロジ取引を動かして、会計仕訳に変換します。ロジ取引データを会計統合データに渡すのですが、特に追加操作は必要ありません、ロジ取引の裏側で自動的に蓄積されます。

以下の流れになります。

ロジ取引発生(会計統合データ蓄積)

会計統合マッピング処理(仮仮経理伝票起票)

会計統合処理(仮経理伝票起票)

元帳転記(経理伝票承認)

まず「会計統合マッピング処理」ですが、ここでは統合取引マスタの変換ルールに従って勘定科目・各種補助科目・部門等を割り付けます。ここで変換エラーや意図しない仕訳を発見できれば、変換ルールを改訂し何回もリランできます。

次に「会計統合処理」ですが、ここでは「仮経理伝票」言い換えれば「経理部で日々手入力している未承認の経理伝票」と同様のモノを起票します。ここで変換エラーや意図しない仕訳を発見できれば、変換ルールを改訂し何回もリランできますが、赤黒の仮経理伝票が発生します。

最終的に「元帳転記」しますが、これは「会計統合」に限った機能ではなく、経理伝票共通の承認手続きです。

これらをふまえて「会計統合マッピング処理」の段階で変換エラーや意図しない仕訳を発見できれば手戻りも少なく理想的です。そのためには「会計統合処理」タイミングを遅らせる必要があります。あるお客様は1日の猶予を設けてエラー潰し・会計統合マスタ改訂をしていました。

この「会計統合処理」は比較的重い処理であり、他の夜間バッチ処理との処理スケジュールを考慮する場合があります。全件処理をする場合が多いですが、データ範囲を指定して細切れ処理もできます。

(推敲していませんので、徐々に更新します)

幻の会計機能 原価管理とは

過去にあるパートナー様から「チケット余ったから、なんか教育してよ」と少々無茶な依頼がありました。そのパートナー様は私がBaanに携わる遥か昔からのヘビーユーザーであり「普通の機能では絶対満足しない」とばかりにニッチな機能で臨みました。結果は半ば呆れながらも知識欲求を少しは満たしたようです。

標記機能はその一つです。

「原価管理」といえば一般的には企業運営の中核であり、心臓部です。それに該当する部分は製造モジュール内であり、会計統合経由で認識できる各種原価差異であります。

では、会計モジュール内の「原価管理」機能は何かと言いますと、各種原価時間レートの算出機能です。

標準原価計算や実際原価算出には、「1時間あたりの機械稼働コスト・労務費・間接経費」が必要になります。それら時間レートを算出する為に

「分母:累積機械稼働時間、累積労働時間、作業場面積、その他」

「分子:勘定科目(補助科目)別残高、その他」

をマスタ設定し、実データを基に算出、各種新レートに本番反映できるものです。

これに対し、パートナー様やお客様の反応は。

「レート算出はExcelでよいのでは」

「設定が面倒くさい」

「設定ミスで誤ったレートが不意に上書きされたら困る」

という否定的な反応に凹むものの、好意的なものもあり

「ヒューマンエラーの介入がExcelより格段に少ない」

「設定ミスをしても再現性があり、原因分析の労力が少ない」

この機能を作成した人々の労力が少しは報われ、一縷の望みが見えたような気がします。でも、私の知る限りでは導入運用実績がないのが悲しいところです。

(推敲していませんので、徐々に更新します)