![見出し画像](https://assets.st-note.com/production/uploads/images/91164182/rectangle_large_type_2_67a54905b42a89962922e6ad6c221dcb.png?width=1200)
わが社のkintone事情という話をしてきました。
先日、キンスキ松井さんのyoutubeチャンネル「kintone活用情報ch キンスキ」において行われたキンスキライブにゲスト出演し、
「わが社のkintone事情」というテーマでお話をさせていただきました。
その資料を残しておきます。
この話をしようとした背景
この話をしようと思ったのは、自分が話したいというより、
私がkintoneユーザー一人一人にどんなアプリを作ってどんな活用をしているか聞いてみたいと思っていたからです。
①アプリの使用状況
業務別・用途別アプリ
![](https://assets.st-note.com/img/1653638467183-0Xf097Uaxn.png?width=1200)
申請関係、報告書関係
申請や報告書をプロセス管理を使用して申請~承認、提出~確認の流れを作っています。
弊社は少人数で組織も少ないので、プロセス管理は簡単にすることを心がけています。
勤怠管理
打刻はほかのサービスのデータをインポートしていて、
早出残業、宿日直、弁当発注など数個のアプリをkrewDataのフローで集計し、出勤簿と会計ソフトへのインポートデータを作成しています。
社内Wiki・経営関係・マスターアプリ・総務経理
それぞれのスペースを作って運用しています。
マスターアプリも、ヒョウケイさん時代は似たようなマスタが複数存在してるときもありましたので、kintone化することでマスターの整理整頓ができました。
きったんスペース
きったんスペースは非公開で、公開前や試作のアプリがたくさんあります。
アプリのスペース間の移動ができるようになったことで、アプリの作り始めは誰にも見せないようにこのスペースで、できあれば各所に移動するということができるのでありがたいです。
用途別に分けてみてもアプリの数は多くなっていきますし、
アプリの所属自体はスペースに分けて運用していますが、利用者がなるべく少ないクリックで目的のアプリにたどり着けるように、1軍のアプリはポータルのお知らせ画面にアイコン付きでリンクを貼っています。
皆様がどんなポータルにしているかもとても興味ありますね。
ワークフローの中でのアプリ構成
![](https://assets.st-note.com/img/1653654490969-bzETqDVIIx.png?width=1200)
ある一連の業務の流れを書き出してみました。
・営業活動を経て注文をいただき、
・在庫確認や製造スケジュールの管理が行われます。
・在庫があるものは出荷指図書を出力し、出荷されていきます。
・在庫がないものは原料を発注し、
・入荷後製造・品質試験ののち入庫処理が行われ、
・出荷指図につながります。
・入荷や出荷後は売上・仕入処理・請求・支払・回収につながっていきます。
一連の業務の流れを把握したうえで、そこにアプリを当て込んでいくとこうなっています。
![](https://assets.st-note.com/img/1653654538255-C8uuMrcRAf.png?width=1200)
営業部門
営業の引合から見積受注に至るまでは顧客管理アプリで管理しています。
製造、品質管理部門
受注してから在庫引当、出荷指図を出し、出荷するまでを一元管理するアプリを作りました。これは以前noteにも書いたことがあり、今は順調に運用できているので満足しています。
製造後の製品の入庫、出庫アプリを合わせて在庫表アプリを作成しています。
出荷指図を出す際に出来上がった在庫表から在庫が引き当てられるようにできており、在庫引当を行うと在庫表にも反映されます。
在庫表を作成するアプリについて、一度Twitterで「入庫出庫でアプリを分ける必要があるか」と聞かれたことがあります。
分けている理由の一つに、今後製造工程のkintone化ができたことを想定すると分けた方がいいと考えていて、また、入庫入力担当と出庫入力担当者が違うことも分けている理由の一つです。
在庫のないものに関しては原料を発注し、製造することになりますが、ここでは入荷予定アプリというのがあります。
このアプリができた背景としては、私が製造現場のころ、原料の入荷予定が現場には知らされなかったんです。
原料はトン単位で入荷するため、例えば25キロ入りの樽が2トンなら80本一度に入ってくることになります。
現場作業者は入荷作業をするために作業の手を止めなくてはならず、
入荷があると分かっていればそういう段取りで作業できるのですが、
入荷を知らずに作業していて不意に手を止められるのが嫌だったので、
第一段階として週末に回覧される製造スケジュールに入荷予定を入れてもらうことにしました。
それでもスケジュール回覧段階では予定のなかったものが入ってくることもありますので、kintone化し、ポータルのお知らせ画面に「本日の入荷予定」として一覧を表示させることで毎朝確認できるようにしました。
経理部門
出荷指図書というものを売上のエビデンスとして売り上げの処理をしていきます。
その売上データをもとにkrewDataを使って商品別、取引先別、直送先別、などの売上集計表を作成しています。
仕入に関しては、買掛金の管理を販売管理ソフトからkintoneに移しました。
これも締め作業ではkrewDataで仕入先マスタから支払方法を引っぱってきて支払先、支払日、支払方法がわかるアプリを作成、支払後は債権管理アプリに転記して資金繰りの調整を行います。
最終的には仕訳データを作成して会計ソフトにインポートする流れになります。
このワークフローの中で、改善したい点が2つあります。
②今後の課題と改善計画
顧客管理からの連携
![](https://assets.st-note.com/img/1653654966381-bmGJXU4Bes.png?width=1200)
現在顧客管理アプリは独立してしまっています。
残念ポイントとして
・フィールド構成も顧客名がベタ打ち
・文字列複数行一つのフィールドにどんどん入力されていく
これを改善するための案として、
![](https://assets.st-note.com/img/1653655170319-TILxJFQMyX.png?width=1200)
・「案件管理」「見積管理」のアプリを作り、
1案件1レコードで運用して「顧客管理」アプリに関連レコードで表示するかたちで顧客管理を行うようにする。
・顧客名のベタ打ちをやめてマスターアプリから顧客コード等でルックアップするような方式に替えて表記ゆれを防止。
・案件から見積、受注管理へアプリアクションでコピーできるような構成にすることで、入力ミスや効率化を狙う。
こうして顧客管理一つに情報盛り込むよりも、案件・見積で分けることでアプリの構造もシンプルで済みます。
特にシステム慣れできていない人にはその方がいのかもしれません。
こういうアプリの構成にすることでワークフローに乗せたアプリ構成ができるかなと考えています。
発注のストックと仕入管理への連携
先日こんなツイートをしました。
![](https://assets.st-note.com/img/1653655206599-se40PCbfN4.png?width=1200)
![](https://assets.st-note.com/img/1653655347859-FjDytT4vzL.png?width=1200)
今回の課題は
・発注担当者が発注データを残していないため過去の発注履歴の検索ができないこと、
・発注担当者が発注して終わり、受入担当者はただ受け入れるだけ、その後の納品書や請求書のチェックを経理がするという流れになっていて、入荷予定と納品書が違うとか日報と納品書が違うから再度チェックするという作業が発生することがある。
もう少し各担当者が責任もってある程度のことはしてもらいたいなと思ってるところです。
![](https://assets.st-note.com/img/1653655469500-DgQfRgkK7b.png?width=1200)
改善のポイントとしては、発注してからの一連の流れのなかで、
・発注データはストックしておく必要があるので発注データをストックするアプリ(できれば発注書の出力まで)を作成。
・仕入を登録(これはここから入荷や在庫管理に繋げたい)、伝票チェックするようなアプリを作るかプロセス管理(発注済み→入荷済み→伝票済み)などを使って、発注担当者が発注して終わりではなくその後の入庫や伝票チェックまでする流れを作る。
これを完成させて、アプリをもとにした新たなワークフローを作っていきたいというのがこの改善目的になります。
まだ頭の中にある段階なので、現場担当者が使いやすいようにそれぞれアプリを作成するのかプロセス管理を使うのか、担当者と話し合いをして、
もう一度どうすれば一番kintoneを生かせるのかというところから考えていくつもりです。
業務改善とSIGNPOST
![](https://assets.st-note.com/img/1653655884634-7RaCyWbpm2.png?width=1200)
kintone界隈の方にはおなじみのkintoneSIGNPOST。
業務改善を進めていくために考え方やコツを体系的・網羅的にまとめたコンテンツであり、いわば道しるべのようなものです。
最後になぜSIGNPOSTの話をしたかというと、
僕自身全部SIGNPOSTを意識して改善に取り組んでいるわけではないですが、自分の中で描いている業務改善マインドとkintoneSIGNPOSTがリンクするというか、無意識にやっていたことや考えがSIGNPOSTのなかではっきり言葉になっていることがあります。
気づいたかたもいらっしゃるかと思いますが、今回のこれまでの話の中でSIGNPOSTの内容が出てきています。
![](https://assets.st-note.com/img/1653657676099-shgmeQeFIY.png?width=1200)
kintoneに限らず業務改善職の方にとっては、道しるべとして困ったり迷ったりしたときはSIGNPOSTを参考にすることは方向性の確認のためにも重要だな思っています。
ちなみに私にが大切にしていることは0-00です。
kintoneはkintone、業務改善のための手段の一つなんだというのが僕の考えです。
改善目的とkintoneの特性を理解したうえで、どのようにkintoneを使っていくかを見極めることが一番大事だと思っています。
今回の改善計画にしても、
ワークフローに合わせてアプリを作っていく
kintoneに合わせてワークフローを作っていく
という別方向からの改善アプローチになっています。
この双方からアプローチできるのがkintoneの強みではあるのですが、
一方で「どっちが正解なのか」といつも悩んでしまいます。
業務改善の流れの中でどこにどのようにkintoneを位置づけるのか、ということを考えて方向性を決めることが改善の入り口としてとても重要だと思っています。
もちろん総合的に見てkintoneを選択しないという判断をすることもあります。
目的に応じて手段を選ぶ、ツール選択ができる知識とスキルを身につけないといけないなと思っています。
最後に
がわが社のkintone事情というテーマで書いてきました。
kintone導入間もない方、運用に迷っている方、また1人管理者で悩んでる方にとって、本当に少しでも参考になれば光栄です。
今後もTwitterやnoteでアウトプットを続けていきたいと思っていますので、
色々な方と交流を持てたらなと思っております。
最後までお読みいただきありがとうございました。