【「会計システムをカスタマイズすること」、「自社製作すること」の注意点】 [会計・経理・税務]
会社の規模や業種、管理会計への姿勢の違いなどから会社で利用する会計システムも変わります。
会計ソフト単体で運用するケース、販売管理ソフト・仕入/経費管理ソフト・減価償却ソフト・給与計算ソフトなどと連携させるケース、連結決算を組む、税務計算と連動する、いろいろなパターンがあります。
また規模の大小、周辺ソフトの連携の如何を問わず、完全な汎用品で運用するケース、一部をカスタマイズしたり、連携部分を自社開発するケース、一から自社開発するケース、いろいろあります。
私は転職したお蔭で会計事務所で提供するソフト、会計事務所の顧客企業が利用するソフト、そして企業会計でも複数の会社の会計システムに携わる機会がありました。
自社に合うシステムを模索している会社も多いです。
またシステムベンダーは業務効率化や戦略的データのより良い収集法を提案して市場を競っています。
今日は、その中で汎用品とカスタマイズ、自社製作の会計システムについてお伝えしたいと思います。
ここでいう自社製作とは完全な自社のためのオーダー品を作らせるという意味です。
私は汎用品、完全自社作成のシステム、いずれでも実務を経験しています。
また汎用品+カスタマイズプログラムによる運用も経験しています。
メンテナンスや立ち上げも経験しています。
そのなかでとても強く感じることは、会計システムを自社製作したり、カスタマイズすることは、とても覚悟が要ること、だということです。
市販品って確かに使い勝手が悪いって部分もあるかもしれません。
それはどうしてもユーザーを絞り過ぎてしまうと汎用品になりませんから、『万人受け』する造りになっていたり、コストパフォーマンスを優先したりしていることも理由のひとつだと思います。
また会計情報を見たい人って自分流じゃないと気が済まないってことも多いので、そういう意見に引きずられるとどうしてもカスタマイズが必要になったり、「いっそのこと専用システムを導入しよう!」なんてことにもなります。
でもカスタマイズをしたり、自社製作って、まず作るのにとてもエネルギーが要ります。
特に経理部門しか触らない会計システム単体ならまだしも入力者が他部門も巻き込むような基幹システムを作るなんてことになると、そりゃぁもう大変です。
それぞれに自分の業務に対する 『思い』 があり、一言でいえば、 『わがまま』 を言い出すものです。
それを「ひとつの形にまとめあげる」というのは大変な苦労です。
いわゆる『要件定義』と言われる作業ですが大抵責任者になった人はまずここで、「やらなきゃよかった、こんなこと」って思ったりします。
弱気な責任者だと、なんとか各部署が言っている要望を満たそうと努力するため、あれもこれもと欲張って細かな要望を積み重ねていきます。
そうするとシステムベンダーからは高額な見積もりが出てきて当初の予算を軽く超えてしまい頭を抱えることになります。
高いお金を払って「一体、何をしたかったんだっけ?」なんて、当初の目的を見失っていたりします。
まぁ、それでも予算に見合う形になんとか落ち着けて実際のシステム設計に入ってみると気づかなかった不都合が発生したりして、またそれの解決策に頭を悩ませたり、不整合チェックをしてくれって言われて膨大なデータや仕様に目を通す羽目になったり…。
そんな関門を潜り抜けやっとのことで完成の日の目を見ると、今度は利用者全員にシステムの概要説明から運用のこまごましたマニュアルの周知徹底まで『自社製作』しなければなりません。
もう、この段階で効率化とかなんだとかよりも、『とにかく無事、設定した目標の稼働開始日までに運用が開始できればいい』なんて気持ちになっています。
そして試験運用が始まると今度はあちこちから、「ここが使いづらい」とか「こんなはずじゃない」なんてクレームの火の手が上がり火消しにやっきになります。
しかも当初予定していない数字上のエラーなんか見つかった日には目も当てられません。
システムベンダーに『定義通り作っているので問題ありません』なんて言われてしまうと反論できなかったり…。
「とにかくこれをこうして欲しい」なんて簡単に言ったら「では、あと1千万円かかりますが、宜しいでしょうか?」なんて言われたり。
社内にシステム的なセンスもあって基幹業務に精通している人がいると、うまくいくのかもしれませんが、なかなか「居そうで居ない」のがこういう人です。
システムベンダーさんでも業務に精通している経験豊富な人が担当なら予防的な提案をしてくれてトントン拍子にいくのかもしれませんが、私はそういう経験ありません。
私自身がここで言う「素晴らしい人」であれば良かったのですが、残念ながら…(^_^;))
それでもなんとか試験運用も乗り切り、いざ本稼働開始!
ようやくほっとしていると、いろいろな外的要因などで変更を余儀なくされるケースがあります。
そうするとプログラムの書き換えなどが発生し規模は立ち上げ時ほどではないにしろ同じような工程を経なければならずメンテナンスが面倒です。
しかもシステムベンダーさん側も担当者しかわからないため、「何かあったとき」の問い合わせに不自由することもあります。
汎用品なら「サポートダイヤル」みたいなのが用意されているケースもありますが、カスタマイズ品にはその様なサービスが期待できません。
汎用品は「使い勝手が今までの業務に合っていない」という理由で敬遠されることも多いかもしれませんが、私は「汎用品に業務を合わせる」くらいが良いと思っています。
営業とか開発ならいざしらず、事務部門にそんなに『独創性』を求めなくてもいいと思います。
もちろん事務部門だって創意工夫で業務効率を追求したりすることは大事なことですが、システムで何でも解決しようとすると逆にその「システム」を適切に運用するために「手間」を掛けることになってしまい、「あれ?今までよりも人、多くなってない?」なんてことにも…。
ちなみに私が一番怖いと思っていること。
社内にちょっと器用な人がいて、アクセスかなんかでちょっとしたシステム作っちゃって、結構、重要業務をそのシステム任せになっているようなケースです。
きちんとした組織で動いているシステム部門であればまだ良いですが、システム部門の「〇〇さん製」みたいなシステムは厄介です。
その人がいなくなったら誰も仕組みが分からない、壊れたりエラーが発生してもどうしようもない、なんてことになったら本当に最悪です。
ロジックがわかる人が何人もいるような、それこそ「社内汎用品」にまでなっていればいいのですが「自作ソフト」は本当に怖いです。
1万人以上いる社員の給与計算ソフトを自作でやっていた会社にいて、つくづく思いました。
「ヤバいな、これ」って。
わたし、ベンダーさんの業務妨害をしようというわけではありません。
ただ、きちんとした体制と準備期間を十分に設けないと思った効果が得られないばかりか、手間がかかってコストもかかって大変ですよってことがお伝えしたかっただけです。
今までで一番最悪だったのは、定義づけまで他の人がやっていたものを諸事情があって試験運用あたりからバトンタッチしたケースです。
もうほとんど何も検討されておらず軌道に乗せるのに1年くらいかかりました。
バグばかりで毎月経理の締めが期限内に終わるか「冷や汗もの」でした。
ほぼ毎月、何かしら新手のエラーが発生しその対応のために徹夜をする羽目になったりしました。
定義づけの段階で中途半端な分業制で全体がわかる人が仕切らなかったこととじっくり検討せずに突っ走った結果だったのかなって思いますが、本当にこうなると始末に負えないです。
なんか、愚痴っぽくなってしまったので、この辺で…。
【小規模企業の経理マンの方に贈る「会計ソフトって何がいい?」】
【勘定科目と経理マン】
【経理マンが勘定科目基準を作る練習をする方法】
会計ソフト単体で運用するケース、販売管理ソフト・仕入/経費管理ソフト・減価償却ソフト・給与計算ソフトなどと連携させるケース、連結決算を組む、税務計算と連動する、いろいろなパターンがあります。
また規模の大小、周辺ソフトの連携の如何を問わず、完全な汎用品で運用するケース、一部をカスタマイズしたり、連携部分を自社開発するケース、一から自社開発するケース、いろいろあります。
私は転職したお蔭で会計事務所で提供するソフト、会計事務所の顧客企業が利用するソフト、そして企業会計でも複数の会社の会計システムに携わる機会がありました。
自社に合うシステムを模索している会社も多いです。
またシステムベンダーは業務効率化や戦略的データのより良い収集法を提案して市場を競っています。
今日は、その中で汎用品とカスタマイズ、自社製作の会計システムについてお伝えしたいと思います。
ここでいう自社製作とは完全な自社のためのオーダー品を作らせるという意味です。
私は汎用品、完全自社作成のシステム、いずれでも実務を経験しています。
また汎用品+カスタマイズプログラムによる運用も経験しています。
メンテナンスや立ち上げも経験しています。
そのなかでとても強く感じることは、会計システムを自社製作したり、カスタマイズすることは、とても覚悟が要ること、だということです。
市販品って確かに使い勝手が悪いって部分もあるかもしれません。
それはどうしてもユーザーを絞り過ぎてしまうと汎用品になりませんから、『万人受け』する造りになっていたり、コストパフォーマンスを優先したりしていることも理由のひとつだと思います。
また会計情報を見たい人って自分流じゃないと気が済まないってことも多いので、そういう意見に引きずられるとどうしてもカスタマイズが必要になったり、「いっそのこと専用システムを導入しよう!」なんてことにもなります。
でもカスタマイズをしたり、自社製作って、まず作るのにとてもエネルギーが要ります。
特に経理部門しか触らない会計システム単体ならまだしも入力者が他部門も巻き込むような基幹システムを作るなんてことになると、そりゃぁもう大変です。
それぞれに自分の業務に対する 『思い』 があり、一言でいえば、 『わがまま』 を言い出すものです。
それを「ひとつの形にまとめあげる」というのは大変な苦労です。
いわゆる『要件定義』と言われる作業ですが大抵責任者になった人はまずここで、「やらなきゃよかった、こんなこと」って思ったりします。
弱気な責任者だと、なんとか各部署が言っている要望を満たそうと努力するため、あれもこれもと欲張って細かな要望を積み重ねていきます。
そうするとシステムベンダーからは高額な見積もりが出てきて当初の予算を軽く超えてしまい頭を抱えることになります。
高いお金を払って「一体、何をしたかったんだっけ?」なんて、当初の目的を見失っていたりします。
まぁ、それでも予算に見合う形になんとか落ち着けて実際のシステム設計に入ってみると気づかなかった不都合が発生したりして、またそれの解決策に頭を悩ませたり、不整合チェックをしてくれって言われて膨大なデータや仕様に目を通す羽目になったり…。
そんな関門を潜り抜けやっとのことで完成の日の目を見ると、今度は利用者全員にシステムの概要説明から運用のこまごましたマニュアルの周知徹底まで『自社製作』しなければなりません。
もう、この段階で効率化とかなんだとかよりも、『とにかく無事、設定した目標の稼働開始日までに運用が開始できればいい』なんて気持ちになっています。
そして試験運用が始まると今度はあちこちから、「ここが使いづらい」とか「こんなはずじゃない」なんてクレームの火の手が上がり火消しにやっきになります。
しかも当初予定していない数字上のエラーなんか見つかった日には目も当てられません。
システムベンダーに『定義通り作っているので問題ありません』なんて言われてしまうと反論できなかったり…。
「とにかくこれをこうして欲しい」なんて簡単に言ったら「では、あと1千万円かかりますが、宜しいでしょうか?」なんて言われたり。
社内にシステム的なセンスもあって基幹業務に精通している人がいると、うまくいくのかもしれませんが、なかなか「居そうで居ない」のがこういう人です。
システムベンダーさんでも業務に精通している経験豊富な人が担当なら予防的な提案をしてくれてトントン拍子にいくのかもしれませんが、私はそういう経験ありません。
私自身がここで言う「素晴らしい人」であれば良かったのですが、残念ながら…(^_^;))
それでもなんとか試験運用も乗り切り、いざ本稼働開始!
ようやくほっとしていると、いろいろな外的要因などで変更を余儀なくされるケースがあります。
そうするとプログラムの書き換えなどが発生し規模は立ち上げ時ほどではないにしろ同じような工程を経なければならずメンテナンスが面倒です。
しかもシステムベンダーさん側も担当者しかわからないため、「何かあったとき」の問い合わせに不自由することもあります。
汎用品なら「サポートダイヤル」みたいなのが用意されているケースもありますが、カスタマイズ品にはその様なサービスが期待できません。
汎用品は「使い勝手が今までの業務に合っていない」という理由で敬遠されることも多いかもしれませんが、私は「汎用品に業務を合わせる」くらいが良いと思っています。
営業とか開発ならいざしらず、事務部門にそんなに『独創性』を求めなくてもいいと思います。
もちろん事務部門だって創意工夫で業務効率を追求したりすることは大事なことですが、システムで何でも解決しようとすると逆にその「システム」を適切に運用するために「手間」を掛けることになってしまい、「あれ?今までよりも人、多くなってない?」なんてことにも…。
ちなみに私が一番怖いと思っていること。
社内にちょっと器用な人がいて、アクセスかなんかでちょっとしたシステム作っちゃって、結構、重要業務をそのシステム任せになっているようなケースです。
きちんとした組織で動いているシステム部門であればまだ良いですが、システム部門の「〇〇さん製」みたいなシステムは厄介です。
その人がいなくなったら誰も仕組みが分からない、壊れたりエラーが発生してもどうしようもない、なんてことになったら本当に最悪です。
ロジックがわかる人が何人もいるような、それこそ「社内汎用品」にまでなっていればいいのですが「自作ソフト」は本当に怖いです。
1万人以上いる社員の給与計算ソフトを自作でやっていた会社にいて、つくづく思いました。
「ヤバいな、これ」って。
わたし、ベンダーさんの業務妨害をしようというわけではありません。
ただ、きちんとした体制と準備期間を十分に設けないと思った効果が得られないばかりか、手間がかかってコストもかかって大変ですよってことがお伝えしたかっただけです。
今までで一番最悪だったのは、定義づけまで他の人がやっていたものを諸事情があって試験運用あたりからバトンタッチしたケースです。
もうほとんど何も検討されておらず軌道に乗せるのに1年くらいかかりました。
バグばかりで毎月経理の締めが期限内に終わるか「冷や汗もの」でした。
ほぼ毎月、何かしら新手のエラーが発生しその対応のために徹夜をする羽目になったりしました。
定義づけの段階で中途半端な分業制で全体がわかる人が仕切らなかったこととじっくり検討せずに突っ走った結果だったのかなって思いますが、本当にこうなると始末に負えないです。
なんか、愚痴っぽくなってしまったので、この辺で…。
【小規模企業の経理マンの方に贈る「会計ソフトって何がいい?」】
【勘定科目と経理マン】
【経理マンが勘定科目基準を作る練習をする方法】
スポンサーリンク
スポンサーリンク