企業の財務状態の把握の自動化について相談させてください。
・スタンダードコース利用
・プラグインは無料のもののみ利用許可
(実現するために有料のものも検討していただける可能性はあります)
・JavaScriptは属人化防止のため利用不可
取引先と取引をする際に財務状態を把握したうえで取引を開始しております。
営業担当者が集める情報としてはこの内容になります。
①信用情報(帝国データバンク、東京商工リサーチ)
②久しぶりに取引を再開する場合は過去の取引履歴の確認
(回収時の遅延情報等)
③訪問または他の取引先からの情報
④与信限度額の設定(その金額内での取引)
⑤取引条件の決定
⑥信用保険の利用検討
財務状態の把握は倒産や回収時の遅延が増えているためです。
現状、④⑤に関しては営業担当者任せになっています。
④は販売したい金額を与信限度額にしたいということで販売予定額が
与信限度額として申請されてきますが
実際に取引先に支払い能力がない場合もあります。
この場合は減額承認されます。
逆に財務状態の良い取引先にはもっと与信限度額を上げてもいいという場合も
あるかと思います。
④の与信限度額を超えて販売すると社内の与信管理をしている部署より指摘が来ますので
その限度額内で取引する決まりです。
いつでも与信限度額の増額の申請はできる状況になっておりますが
申請をするのが手間という理由で、取引先に支払い能力があるにも関わらず
増額申請されないこともあります。
その場合、与信限度額を超えた分は信用保険を利用するという営業担当もいます。
担当営業が強気の場合は⑥の信用保険を利用をせずに取引をす(または前金取引)
慎重派は⑥の利用が多い状態となっております。
現状の状態での弊社の課題は下記の2つです。
・信用保険の利用額が上がり続けている
・倒産の可能性ある取引先に信用保険を利用せず取引すること
営業個人の判断をやめて与信限度額を自動で出せないか?と与信管理の部署にて
考えております。
営業担当者が集める情報の現状
①信用情報:kintoneに調査票依頼アプリに調査票があるので
取引先の評点を数値化できる
②取引再開:過去の取引は基幹システムで確認できます
③④訪問、与信限度額の設定:kintoneに④の与信限度額申請
アプリがあり③の内容が記載されています
⑤取引条件:基幹システムより書き出し、kintoneの
取引先マスタにCSVに読み込みしています
⑥信用保険:kintoneの信用保険利用申請アプリに
これまで利用した信用保険の利用額の情報があります。
色々な場所に情報はあるのですが、
この情報をもとに取引先の与信限度額を自動で表示させ
信用保険の利用有無の判断を自動化させることはできるのでしょうか?
与信関係のアプリは関連レコードで確認できる状況にはあります。
自動化させることで信用保険料を2割ほど削減できるのでは
ないか?との意見があります。
有料のプラグインは現状利用の許可が下りていませんが
この内容を実現させるために必要なプラグインがあるようでしたら
検討していただける可能性があります。
すべてkintoneでまかなえなくても、CSVで書き出して
何かほかの方法でできることはあるのでしょうか?
kintoneの事例に与信管理についての記事は見つけられませんでしたので
皆様の会社で似たような取り組みをされている方や良いアイデアが
ありましたらご教示いただきたいです。
ミュートしたユーザーの投稿です。
投稿を表示お疲れ様です。
データ管理としては、「販売予定額が与信限度額として申請」の部分について、販売予定額と与信限度額は分けたほうが良い気がします。
また、システムと連携しているようですので、「現在の借入額(見込みでもOK)」を持ってこれるのであれば、与信計算には必要になりそうな気がします。
アプリ自体は、リアルタイム性を要求されないのであれば、「仕様」さえ固まればkintoneでも効率化できる可能性はありそうです。
(ローン計算的な作業が必要なのであれば、他の方も仰っているように、計算をするためのプラグインが必要になるかもしれません)
ここから先はkintoneではない話になりますが、「現状では誰が困っているか?」「今のやり方を変えるには、誰にコストがかかり、誰のメリットになるのか」「コストがかかる(変化を嫌がる人)を動かすにはどうすればよいのか」を関係者で少し整理して、必要となる部署のキーパーソンを早めに巻き込んだほうが良いと思います。
文章を見るに、質問者さんは、他部署に対して強い権限を行使したり、影響を与えられる立場には無いようですので、システムの具合案を他部署の皆さんに提示するよりも、周りを巻き込んで味方を増やしてみんなで仕組みを考えることが大切かと感じました。
(もし、組織に直接的に影響を与えられる立場にないのであれば、目的の部署に近いところに賛同者を作るのが有効?)
ミュートしたユーザーの投稿です。
投稿を表示こんにちは。
コメント含めざっくり読みましたが
をやりたい、ということで良いでしょうか。
であれば、krewDataで定期的に各アプリから数値を収集・計算し、
結果を与信限度額を管理しているアプリに書き込むのが良いと考えます。
krewData(スケジュール実行)
https://krew.mescius.jp/products/krewdata.htm
ミュートしたユーザーの投稿です。
投稿を表示ご返信ありがとうございます。
①の情報は自動化できるのですね。
これについては営業より調査依頼が来たものを与信管理の部署が調査票を取得し
調査票をみて企業分析したコメントを書き込み、営業へ通知を送っているので
今のところこの内容で運用していく予定です。
自動化したいということになりましたら、参考にさせていただきます。
私のご相談文が長く申し訳ないのですが自動化したい内容としては下記になります。
①~⑥の内容をまとめることは可能なのでしょうか?
プラグインについてのご意見ありがとうございます。
現在はkintoneのアプリ製作をできる担当者は部署ごとにいるのですが
私ともう1名以外はアプリ製作を勉強中のため、単体のアプリは作成可能ですが
連携のアプリを作成することが難しい状態です。
標準機能を使いこなせていない状態でのJavaScriptを導入してしまうと
「管理部に頼めばなんでも作ってくれる」状態になってしまい導入していない状態です。
プラグインは導入済みのプラグイン一覧のアプリを作成済みで
利用方法はリンクでアクセスすると、どなたでも利用可能な状態となっております。
最近、ある部署の担当者が退職されて、すでにその部署で作成されたアプリが
その部署で管理されず管理部がアプリを管理することになりました。
理由はその部署の誰も利用しているアプリの構成が分からないのと、
その部署で覚えようと思えるほどkintoneのことを好きな社員がいないためです。
費用としては、JavaScriptは個人の勉強コストのみでまかなえてとても魅力的なのですが
管理部が抱えるアプリが増えるとキャパオーバーしますので、現状は弊社は
JavaScriptは利用できない状況となっております。
Seai777さんのような技術を持った方が社内に複数人いれば、個人の負担が減るので
話は変わってくるのですが、弊社では難しそうです。
弊社のkintoneの全体のレベルが上がってきましたら、JavaScriptの導入も
検討できるようになる可能性がありますので、現在はJavaScriptは時期尚早という状況です。
利用できるようになれば、可能性は広がりますよね。
ミュートしたユーザーの投稿です。
投稿を表示課題のお答えできてませんでしたね🙇🏻
与信限度額算出に必要なパラメータは(手法はどうあれ)全て取得し、kintone化されているようなので、「パラメータを使って”与信限度額を立てる式の確立”」ができれば自動化は全然可能と思います。
(公式があればそれを充て込めばよいし、御社独自の運用も式に盛り込んでいけばいいだけだと…)
基本機能に無い関数が必要な場合は…即、相応のプラグインなどの出番になっちゃいそうですがね💦
ちなみに、CSV書き出し⇒Excelで計算するにしても、計算式の確立は要るかと。
また、書き出し(+書き戻し)の自動化には、相応のプラグインかcli-kintone などを使ったカスタマイズで実現可能と思います。
考え方のご提示のみですみません🙇🏻
ミュートしたユーザーの投稿です。
投稿を表示①について…自動化できます!
手動でやる時は、
1.帝国データバンク、東京商工リサーチなどのページにアクセスし、
2.公の企業番号などで対象企業を検索し、
3.所望の情報が載っているページを開いて、
4.欲しい信用数値を調査票に転記する。
とやっていると思います。(他にプロセスがあるのなら、適宜挿入していってください。)
この手動手順を要件(プログラムのフロー)と見立て、カスタマイズで自動化するわけです。
Webページから所望の信用数値を抽出するには、「スクレイピング」という手法を採るのが一般的ですが、抽出用APIが用意されていれば、それを利用する方が断然楽ですね。
モカさんの場合は、「任意のWebページにアクセスして、対象企業の信用数値をスクレイピングや抽出用APIで抽出する」プラグインを探すことになるかと思います。
信用数値の抽出さえできれば、調査票への転記は既存(?)のプラグインでいくらでも可能かと。
で、
とのことですが、俗人化の要素には「開発言語(コード)の可読性・理解しやすさ」の他に、「要件(処理フロー)定義やそういうフローにした背景や思想の引継ぎ」も同じくらいの割合で存在すると考えています。
要は、「プラグインにしたからといって、俗人化要素が無くなるわけではない。」ということです。
ですので、「俗人化」を理由に直接カスタマイズを排除するのはチョット違うと思います。
適当なプラグインが見つからない/使用プラグインではできないことを補完する ときなどには直接カスタマイズは有効ですし、単純な動作であれば、他の使わない機能も入った有料プラグインを使うより、直接カスタマイズした方がタダなので費用対効果は優位 みたいなことが言えますしね。
ご参考になれば幸いです。