デザイン×FDEで業務を改善
現場の業務を一緒に改善するチーム

その
本当に必要ですか?

FDE思考 × デザイン思考 で根本を改善します

新しいSaaSや仕組みの導入で、
現場の業務が煩雑化・定着しないなんてことありませんか?

名刺管理、在庫管理、顧客管理、タスク管理など
導入したSaaSが多すぎる

・こんなことありませんか?

「特化したSaaSの複数導入でコストアップ。その割に営業利益は伸びが悪い。」
「再現性のある仕組みを導入したつもりが、定着率が低く習慣化に困っている。」
「個別の業務でSaaSを導入しているが、紐付けができておらず二重管理をしている。」
「部署ごとで導入しているSaaSが異なることで、部所間の連携がアナログ。」など

複数のSaaS画面と重複した顧客資料、請求書を前に悩み、同僚から紙の資料を受け取る担当者
は

FDE思考 × デザイン思考で
本当に必要な仕組みを
根本的に解決します

FDEによる支援とは

FDE思考 × デザイン思考とは?

FDE思考 = 現場がしたいと思う業務改善の実現
デザイン思考 = 皆が使いやすいと思うモノの実現
FDE思考
= 現場がしたいと思う業務改善の実現
デザイン思考
= 皆が使いやすいと思うモノの実現

FDE(Forward Deployed Engineer)は、顧客の現場に入り、課題の整理からシステムの実装・運用改善まで関わるエンジニアの役割です。脱SaaSでは、この考え方とUI/UXデザインを組み合わせ、現場で使い続けられる仕組みを整えます。

01 / WHAT “FDE”?

FDEは業務の根本的変革のこと。

Forward Deployed Engineer(フォワード・デプロイド・エンジニア)の略称で、現場を深く知る人間がエンジニアの発想やAIを活用し、業務の進め方そのものを根底から変革する考え方です。

FDEは業務の根本的変革のこと。

02 / FDE ALONE ISN’T ENOUGH.

FDEができても、
定着しなければ意味がない。

システムが作れても、それが一貫性のあるものなのか?社員の年齢、性別、 リテラシーに合ったデザイン(設計)になっているのかが重要です。会社として一貫性のあるシステムを構造化し、アウトプットすることで、無意識の定着を促す。そのためにデザイン思考が不可欠です。

FDEができても、
定着しなければ意味がない。

03 / CONSISTENCY

ルールやフローを排除する必要がなくなります。

現状、企業文化や、社内で大切にしていたルールに沿わないのもは、SaaSに置き換える時にルールを改正するか、現状維持をすることが多いです。今あるもの形やルールは脈々と受け継がれてきた大切な習慣だったりもします。そういった今ある大切な形は極力残しながら、業務の推進を促します。そんために「FDE思考」と「デザイン思考」どちらも必要なのです。

ルールやフローを排除する必要がなくなります。

04 / A ONE-OF-A-KIND SYSTEM

唯一無二の業務システムを
時代に沿った形で築き上げる。

目まぐるしい時代の中で、 古いシステムを永遠を使い続けるのも、新しいシステムを導入するのも、 どちらもコストが嵩張りますし、エラーの原因になります。その時代にあった会社独自の唯一無二のシステムを構築し築き上げていくことで再現性のあるシステムが実現します。

唯一無二の業務システムを
時代に沿った形で築き上げる。

実現するまでのロードマップ

まずは現場理解から実装へ。
小さな業務から、使える形にする。

現状のシステムやそれに付随する業務を細かく確認し、
ヒューマンエラーになりやすい点や、手作業による処理、 二重管理業務になっている点などを抽出します。

01 / DISCOVER

現場を見る

実際の画面と手順を確認。手入力・待ち時間・例外処理を見つけます。
ヒューマエラーに繋がる箇所や、属人的になっている業務なども確認します。

現場を見る

02 / DESIGN

業務を設計する

必要な情報、人の判断、自動化する工程を分けます。
特にヒューマンエラーの発生しやすい箇所や、属人的な工程、二重管理業務となっている部分は細分化し、 誰が、いつ、どのように判断するのが最適かを重点に抽出します。

業務を設計する

03 / BUILD

小さく実装する

大きく改善するのではなく、小さなタスク、業務の単位から改善を実装。既存のツールなどは一旦使用しながら、徐々に脱SaaSの方向へシフトします。

小さく実装する

04 / IMPROVE

使われ方を測る

時間・利用率・修正率を定期的に計測し、その都度次の改善アクションを提示します。定着しなければ意味がない。現場で続く運用へ随時改善します。

使われ方を測る

USECASE

いつもの仕事が根本的に変わった事例

実際に支援して変わった参考事例です。

具体例 01 / EC運営と卸売業の両立

株式会社A

業種:小売・卸売業
所在地:東京

導入にかかった期間
6ヶ月

お困りごと・・・

  1. 発注 > 入荷 > 検品 > 出荷 > 棚卸しそれぞれのセクションで、在庫のずれが発生することが多々ある。
  2. 検品方法と出荷時の梱包方法がルールを決めても徐々に属人化(それぞれがやりやすい方法)に変わっていき品質が一定に保てない。
  3. 人員の増減によるOJTのコストが高く、出荷ミスなどのヒューマンエラーが多い。

条件・・・

  1. パソコンが苦手、もしくは使えない人が倉庫のスタッフに一定いるので、その人たちでも業務が遂行できるようにしたい。
  2. 追加のSaaSなどを導入する費用は捻出したくない。今あるツールを駆使して、 エラーやコミュニケーションコストを減らして欲しい。
  3. 運用が簡単かつ、属人的判断が極力不要な形になるようにしたい。人の手が必要でも基準値に基づいた判断を現場でできるようにしたい。

解決内容(一部抜粋)

01GASの導入
課題
調べてみると、ECと卸売の発注数、発送先、発送伝票などを個別に都度マクロを作成していた。一つの工数が抜けてしまうと、その時点で差異が生まれエラーにつながっていたことがわかった。
解決方法
全てのエクセルによる表データは、マクロを使用せずに必要なデータだけを収集してGASでワンクリック処理ができるようにした。
結果
ヒューマンエラーはゼロになり、業務工数は80%削減した。また、OJTも「必要なデータを手順通りに収集してクリックするだけ」としたため、初日から実働可能な状態となった。
02検品方法に「わからない」を追加
課題
検品の手順書があったものの、実際の検品基準とはずれているものだった。基準に充てはならない、現場で判断のつかないものをが多く、その基準が曖昧なまま進行し、在庫の仕分けが煩雑化していた。
解決方法
検品の手順をStep by Stepで細分化し、商品の種類で大きく共通化。その傘下に個別具体の各フローの分岐を構築。検品結果はそのフローの分岐により「A」「B」「不良」に分らるようにした。その分岐に該当しないレアケースの場合は「わからない」として別管理する。不良かどうかと判断するのは本社の人間とし、本社の人間がそのレアケースの発生率を集計、新たに検品フローに追加する判断をする。「わからない」の確認は月1回決まった日に実行する。
結果
現場で判断できる領域が拡大し、現場が自走できる範囲が20%から70%となった。
また、「わからない」判断の制度の向上にも繋がり、本社と倉庫の一体感が強化され、コミュニケーションの質が向上が見受けられた。
03あえてエラーなる仕組みを設ける
課題
業務が忙しくなると、本来踏むべきフローを現場判断でスキップして進めていることが判明。
納期は死守しなければならないが、やることも大きという板挟み状態で発生していたトラブル。今までは倉庫のスタッフの一つ一つの作業の進め方のスピード強化と意識を正すというやり方に執着していた。
解決方法
商品には固有のコードを入荷の検品時に添付し、商品発送の場合は、該当商品をピックアップしたら個別にコードのスキャナを通さなければならないという形にした。これにより、個別具体での発注に対するリソースとリードタイムが概ね正確に算出できるようになる。また、納品書の作成は、コードの読み込み数と紐づくため、発注書との差異があった場合に納品書を生成できないような使用とした。
結果
発注書、ピックアップ、梱包、最終出荷前でそれぞれ数量のチェックを踏んでいたが、ピックアップと最終出荷前(念の為)にチェックを集約。また、発注〜発送までのリードタイムが概ね算出できるようななったことにより、倉庫と本社間でのリードタイムの認識誤差が解消され、適切なリードタイムを発送先にも打診できるようになった。ヒューマンエラーはほぼゼロになり、リードタイムも、約50%削減された。

具体例 02 / ダンススタジオ

株式会社A

業種:サービス業
所在地:東京

導入にかかった期間
1.5ヶ月

お困りごと・・・

  1. インストラクターの給与処理をシンプルにしたい。オーナーしか処理の手順がわからない。
  2. 各インストラクターには、稼働した日に日報を手書きで提出してもらっており、その内容をエクセルで手入力している。
  3. 特別なワークショップや、メインインストラクターの休みによる代行レッスンなどは給与計算が異なるので、それぞれ日報を確認しながら手作業で計算している。

条件・・・

  1. インストラクターはPCを持っていない場合が多いので、スマホで完結する仕様にしたい。
  2. 手作業で計算しているのを自動処理にして、なおかつ源泉徴収の計算処理もスムーズに行いたい。
  3. オーナー自身もITリテラシーは高くはないので、レッスン枠やインストラクターの追加・削除は簡単に行えて、なおかつレッスン単価の個別の登録もできるようにしたい。

解決内容(一部抜粋)

01出退勤アプリの作成
課題
手作業による手間とそれを読み込む時間が大きくとられていた。なおかつ、記入漏れ、ミスなどもあり、その都度確認をして修正をオーナーが実施していた。
解決方法
レッスンのコマは月次でほぼ固定だったため、あらかじめレッスンのコマをDBで構築、また、そのコマにレギュラーで割り振られたインストラクターも事前に登録。インストラクターは出勤したタイミングで、 その時間のコマが表示され され、「出勤」ボタンを押すと記録されるwebアプリを作成した。代行の場合も同様の処理で完結するようにした。
結果
インストラクター自体の記入の手間はなくなり、入退室はスムーズになった。また、入室した時点で、その該当のコマが即時表示されるアプリなので、誤操作、ご入力もなく、スムーズな記録が可能となった。
02源泉徴収処理はe-taxにコピペできるリスト形式で表示される仕組み
課題
源泉徴収の金額計算は、合計の金額と人数をそん都度計算しなければならなかったため、計算ミスが発生しやすかった。また、01の課題と紐づくが、記入ミスなどがあると、余計に徴収してしまっているケースなどもあった。
解決方法
01で作成した出退勤アプリの導入により、各インストラクター別の給与の計算が簡素化された。これにより、源泉徴収の処理も同時に簡素化が実現。
e-taxのどこに何をコピーしたら良いかも一目瞭然のUIを設計。
結果
金額の間違えや、給与の計算をしたりしていた一連の業務が、1日かかっていたが30分で完了するようになった。
03PLを可視化し将来の対策を練られるように
課題
特別なワークショップ、 発表会前のイレギュラーな練習、スポットでのスタジオ利用など、 給与以外に発生する収支があったが、感覚で計算などもしていたため、将来的設計はほぼ皆無の状態だった。
解決方法
固定のレッスンでの料金やイントラクターの報酬額以外の収支の部分を明確化、箱ものビジネスなので、坪単価計算を入れ、利用する時間や機材に単価を設定し、利用の内容に応じて、支出(コスト)と料金(売上)が算出できるようにした。これにより、将来に予定されたPLの見通しがたち、運営に安定感が生まれた。
結果
その場しのぎな計画ではなく、半期〜1年を見越した財務状況を把握しつつ、堅実な計画のものを、投資もできるようになり見通しが明確化され、サービスの向上につながった。

FAQ

相談前によくあるご質問。

Q最初からシステムを作り直す必要がありますか?

ありません。現行ツールの設定や入力ルールの改善で解決する場合は、それを優先します。既存CRMや販売管理との連携可否を診断で確認します。

QFDEとは、どのような支援ですか?

Forward Deployed Engineeringの考え方を用い、担当者と業務を理解し、試作・実装・導入後の改善まで関わる支援です。本サービスは常時常駐を標準条件にしていません。

QFDEによる支援では、どこまで相談できますか?

現状の業務とツールの整理、システム連携の可否確認、画面(UI)の設計、実装、導入後の運用定着まで、段階ごとにご相談いただけます。どこまでを支援範囲とするかは、案件ごとに事前にすり合わせて合意します。常駐を前提とした支援ではありません。

Q診断後、必ず実装を依頼する必要がありますか?

ありません。診断と実装は別契約です。費用対効果や技術条件から、実装を見送る選択肢も提示します。

Qどこまで対応してくれますか?

スポットでの対応はもちろん、伴走支援をご希望の場合は細かい業務から上流までを一貫して、社内基盤の構築までを支援します。対応範囲は途中から切り替えていただいても構いません。

LET’S TALK

まず、ひとつの業務から。

営業報告、CRM、見積。
今の手順をお聞きし、診断が必要か一緒に整理します。

ご相談はこちら専用フォームで、資料請求とご相談を承ります。
担当者と業務改善について相談する様子