まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

発注アプリの導入は教育・医療でどう違う?承認と物品管理から選ぶ手順

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 発注アプリで変わるのは主に入力・承認・送信の記録で、在庫確認と納品確認の作業や取引先の納期は残ります。
  • 教育機関では公費・私費の区分と設置者の規則による承認経路、医療機関では標準コードでの物品の識別と情報の扱いが分かれ目になります。
  • 医療機関は、厚生労働省の医療情報システムの安全管理に関するガイドラインの最新版で、該当する編を情報システムの担当と確かめます。
  • 四つの形態は順位ではなく、取引先の対応と承認経路の再現を中心に、自組織の条件で比べます。
  • 試行は品目と部署を絞り、導入前と同じ数え方の指標と条件付きの切り替え期限を決めてから広げます。

50代後半の日本人男性がタブレットへの入力をしている場面

発注の記録が散らばると、どこで何が起きるか

電話で頼んだはずの消耗品が、別の職員からもFAXで注文されていた。
承認者が席を外していて、注文が止まったままになっていた。
こうした場面で手間とミスの元になっているのは、誰がいつ何を頼んだかを後から追えないことです。
発注アプリでまず変えられるのは、注文の記録・承認・取引先への送信を一か所にまとめることです。
取引先の在庫や納期は変わりません。
選ぶ前に、承認経路、取引先の受付方法、情報の取り扱いを自組織の規程で確かめます。
医療機関では、物品の識別と医療情報システムの指針も確かめます。
そのうえで品目と部署を絞って試すのが、教育でも医療でも進め方の軸になります。

入力・承認・送信・在庫確認・納品確認のどこで詰まるか

発注の困りごとは「発注が面倒」とひとまとめに語られがちです。
ただ、手間とミスが出る場所は工程ごとに違います。
ここでは、消耗品・備品・材料を取引先へ注文する業務を、入力、承認、取引先への送信、在庫確認、納品確認の五つに分けて考えます。
教材や印刷物の制作を外部へ頼む発注は、仕様の取り決めや検収の考え方が別になります。
そのため、ここでは物品の注文を前提にします。

入力は、現場の職員が必要な物を書き出す段階です。
紙の発注票、口頭での依頼、メールと形式が混ざると、品名の書き方がそろいません。
たとえば同じ使い捨て手袋でも、ある人はサイズだけを書き、別の人は型番を書くとします。
この場合、事務担当は取引先のカタログと照らし合わせ、正しい品番に直してから転記することになります。
入力の段階で起きているのは、この読み替えと転記の手間です。

承認は、頼んでよいかを判断する人が注文を見て決める段階です。
紙の発注票が承認者の机に置かれたままだったり、メールが他の連絡に埋もれたりすると、注文はそこで止まります。
現場の職員は承認されたかどうかが分からないため、事務担当に電話で尋ねます。
事務担当も把握していなければ、承認者に確かめに行きます。
承認待ちの時間に加えて、状況を確かめる往復が生まれています。

取引先への送信は、承認された注文を取引先へ届ける段階です。
取引先によって、電話、FAX、メール、取引先のWeb画面と受付方法が違います。
そのため、送ったかどうかの記録は、送信した担当者の手元にしか残らないことがあります。
担当者が休んだ日に「あの注文はどうなったか」と聞かれても、ほかの誰も答えられません。

在庫確認は、頼む前後に手元にどれだけあるか、ほかの人が既に頼んでいないかを確かめる段階です。
ここが抜けると、同じ物が重ねて届きます。
納品確認は、届いた物を注文内容と照らし合わせる段階です。
照合の元になる注文の記録が紙・FAXの控え・メールに分かれていると、届いた箱がどの注文の分かを探すことになります。
一部が届いていないことにも気づきにくくなります。

自分の現場に当てはめるときは、最近困った出来事を一つずつ思い出し、どの工程で起きたかを書き出してみてください。
重複は在庫確認と記録、承認待ちは承認、発注漏れは送信と納品確認で起きていることが多いはずです。
工程が分かると、次に考える「アプリが効くかどうか」の答えが変わります。

アプリが効く部分と効かない部分

発注アプリが直接変えるのは、記録の置き場所です。
入力の形式がそろい、承認の状態が画面で見え、いつ誰が取引先へ送ったかが残ります。
前の工程でいえば、入力・承認・送信の三つがアプリの効く範囲の中心です。
品名をあらかじめ登録した一覧から選ぶ形にすれば、事務担当が品番へ読み替える転記も減ります。

在庫確認と納品確認は、アプリを入れても人の作業が残ります。
在庫数を記録する機能があったとしても、誰かが棚を数えて入力しなければ、画面の数字は現物とずれていきます。
納品確認でも、届いた箱を開けて中身を照合するのは人です。
アプリで変わるのは、照合するときに見る注文の記録が一か所にまとまることです。
探す手間は減りますが、確認そのものはなくなりません。

取引先の納期や欠品も、アプリでは変わりません。
注文が早く届いても、取引先の出荷が遅ければ、物が届く日は同じです。
ここへの期待がずれたまま導入すると、使い始めてから「アプリにしても変わらない」という評価になりがちです。

裏返すと、困りごとが承認待ちや重複に集中しているなら、アプリの効く範囲と重なっています。
困りごとの中心が欠品や納期の遅れなら、先に取引先との取り決めや発注のタイミングを見直す方が近道です。
どちらの困りごとが多いかは、前の書き出しで見えてきます。

教育機関と医療機関で、承認と物品の性質はどう違うか

教育:公費・私費と発注権限

学校では、同じ文房具でも、設置者の予算である公費で買う物と、保護者から集めた私費で買う物があります。
この二つは会計が分かれています。
どちらの予算から支出するかによって、承認する人や記録を残す帳簿が変わります。
前の工程でいえば、承認と記録の段階で教育機関ならではの分岐が生まれます。

誰がどこまで発注してよいか、つまり発注権限は、学校が自由に決められるものではありません。
公立学校なら設置者である自治体の契約に関する規則や、学校予算の執行に関する定めに従います。
私立学校なら学校法人の経理規程に従います。
金額によって見積もりの取り方や契約の手続きを変える定めがあるかどうか、その線引きがどこにあるかは設置者ごとに異なります。
そのため、一般的な金額を目安として当てはめることはできません。

この違いは、アプリに求める条件へそのまま現れます。
一つの注文を公費・私費のどちらで処理するかを入力の段階で区別できること。
予算区分によって承認する人を変えられること。
規則で決まっている権限の段階を、アプリの承認経路として再現できること。
区別ができないアプリでは、注文をまとめて記録できても、事務担当が後から帳簿ごとに振り分け直す転記が残ります。

医療:物品の識別と医療情報の扱い

医療機関で扱う物品には、診療材料や衛生材料など、名前が似ていても規格の違いが取り違えにつながる物が含まれます。
そのため、品名ではなく標準コードで物品を見分けられるかどうかが、教育機関よりも重い条件になります。
アプリ側で確かめたいのは、標準コードに対応した品目マスタを持てるかどうかです。
品目マスタとは、取り扱う品目の名前・規格・取引先などを登録した台帳のことです。
既に院内で物品管理の台帳を使っているなら、そのコードとアプリのコードをそろえられるかも分かれ目になります。

もう一つの軸が、医療情報の扱いです。
厚生労働省は「医療情報システムの安全管理に関するガイドライン」を公開しており、掲載ページでは第7.0版が中心で、概説編・経営管理編・企画管理編・システム運用編・保守委託機関編が掲載されています1。
同じページでは、医療機関等に対して、医療情報システムの取扱いにおいて本ガイドラインを遵守するよう求めています1。

発注アプリがこの指針とどこまで関わるかは、注文に何を載せるかで変わります。
物品名と数量だけを扱うのであれば、医療情報との接点は小さくなります。
一方、患者ごとの材料の使用と注文を結び付けたり、電子カルテや院内の物品管理システムとつないだりすると、医療情報システムの一部として検討する必要が出てきます。
外部のサービスを使う場合に何が求められるかは、指針の該当する編の記述で確かめることになります。

まとめると、教育機関では「どの予算で、誰が承認するか」が分かれ目になります。
医療機関では「頼んだ物を取り違えずに識別し、その情報をどこで扱うか」が分かれ目になります。
同じ発注アプリでも、教育では承認の段階、医療では入力と記録の段階で条件が厳しくなる、という違いです。

比べる点 教育機関 医療機関
条件が厳しくなる工程 承認と記録(予算区分ごとの振り分け) 入力と記録(物品の識別と情報の扱い)
承認を決めるもの 自治体の契約規則や学校法人の経理規程 院内の規程と物品管理の役割分担
物品で気をつけること 公費・私費の取り違え 規格の取り違え(標準コードでの識別)
情報の扱いで見るもの 個人情報の取扱いに関する規程 医療情報システムの安全管理に関するガイドラインの該当編
主な確認先 規則の所管部署・法人事務局 情報システム管理者・物品管理担当・委託事業者
物品発注の五つの工程と、各工程で出やすい困りごと
入力、承認、取引先への送信、在庫確認、納品確認の順に並べ、各工程で起きやすい困りごとを添えた工程図1入力読み替えと転記の手間2承認承認者のところで止まる3取引先への送信送った記録が担当者の手元にしか残らない4在庫確認同じ物が重ねて届く5納品確認照合の元が分かれ、未着に気づきにくい

▼ 図の内容を文字で読む
  1. 入力(読み替えと転記の手間)
  2. 承認(承認者のところで止まる)
  3. 取引先への送信(送った記録が担当者の手元にしか残らない)
  4. 在庫確認(同じ物が重ねて届く)
  5. 納品確認(照合の元が分かれ、未着に気づきにくい)

発注アプリで解ける範囲と解けない範囲

機能を確認する質問項目

ここまでで、アプリが効くのは記録・承認・送信の部分であり、その条件が教育と医療で分かれることが見えてきました。
次は、候補のアプリが自分の条件を満たすかどうかを見分ける段階です。
製品紹介に並ぶ機能の名前は、同じ言葉でも中身が違うことがあります。
「承認機能あり」と書かれていても、一段階だけなのか、金額や予算区分で経路を分けられるのかは、紹介文からは読み取れません。
そこで、機能の有無ではなく、自分の現場の場面を当てはめた質問の形にして提供元に尋ねます。

一つ目は承認の段階数です。
何段階まで承認を重ねられるか、金額や予算区分によって経路を分けられるか、承認者が不在のときに代わりの人へ回せるかを聞きます。
学校なら公費と私費で承認者が違う場面、医療機関なら部署の責任者のあとに物品管理の担当が確認する場面を、たとえとして伝えると答えが具体的になります。

二つ目は取引先への送信方法です。
アプリで作った注文が、どの形で取引先に届くのかを確かめます。
取引先も同じサービスに登録する必要があるのか、メールやFAXの形で送れるのか、印刷して手で送るのか。
この答えによって、導入の前に取引先へ何を頼まなければならないかが変わります。

三つ目は品目マスタの持ち方です。
品目を誰が登録し、取引先の品番や価格が変わったときに誰が更新するのかを聞きます。
医療機関では、標準コードを登録できる欄があるかもここで確かめます。
マスタが古いままだと、現場は画面で選んだ品目が本当に今も買えるのかを電話で確かめるようになり、記録をまとめた意味が薄れます。

四つ目は履歴の残り方です。
誰がいつ入力し、承認し、送信したかが残るか。
注文を変更・取り消したときに、元の内容も残るか。
会計の処理や監査のときに使える形で記録を書き出せるか。
規程で記録の保存を求められている場合、この答えが紙の控えを残すかどうかの判断にもつながります。

答えを聞くときは、「できる」かどうかだけで終わらせず、「どういう手順でできるか」まで尋ねてください。
設定を変えればできることもあれば、追加の契約や開発が必要なこともあります。
料金も、どの機能をどこまで使うかで変わるため、見積もりを頼む前提としてこの質問の答えをそろえておくと、提供元ごとの見積もりを同じ条件で比べやすくなります。

確認する項目 提供元への質問 答えで分かること
承認の段階数 何段階まで、金額や予算区分で経路を分けられるか、不在時に代わりへ回せるか 規程の承認経路をそのまま再現できるか
取引先への送信方法 取引先の登録が必要か、メールやFAXの形で送れるか 導入前に取引先へ頼むことの量
品目マスタの持ち方 誰が登録・更新するか、標準コードの欄があるか 現場が品目を迷わず選べる状態を保てるか
履歴の残り方 入力・承認・送信・変更の記録が残り、書き出せるか 会計や監査で紙の控えが必要かどうか
発注アプリで変わる部分と変わらない部分(模式図)
入力・承認・送信は記録が整い、在庫確認と納品確認は人の作業が残り、取引先の納期や欠品は変わらないことを三つに分けた図入力・承認・送信は記録が整い、在庫確認と納品確認は人の作業が残り、取引先の納期や欠品は変わらないことを三つに分けた図アプリで変わる入力の形式がそろう承認の状態が画面で見えるいつ誰が取引先へ送ったかが残る人の作業が残る棚を数えて在庫数を入力する届いた箱を開けて中身を照合するアプリでは変わらない取引先の納期取引先の欠品

▼ 図の内容を文字で読む
  • アプリで変わる
    • 入力の形式がそろう
    • 承認の状態が画面で見える
    • いつ誰が取引先へ送ったかが残る
  • 人の作業が残る
    • 棚を数えて在庫数を入力する
    • 届いた箱を開けて中身を照合する
  • アプリでは変わらない
    • 取引先の納期
    • 取引先の欠品

取引先提供のWeb発注・汎用サービス・既存システム拡張・自作の選び方

同じ軸での比較表

発注アプリと呼ばれるものには、大きく分けて四つの形があります。
取引先が用意しているWeb発注の画面を使う形。
複数の取引先への注文に使える汎用の発注・購買サービスを契約する形。
既に使っている会計や物品管理のシステムに発注の機能を足す形。
表計算ソフトなどで自分たちで仕組みを作る形です。
どれが優れているという順位はなく、前の節までに整理した困りごとと条件に照らして比べます。

取引先が提供するWeb発注の画面は、取引先が少数に集中している組織なら、使い始めやすい選択肢です。
ただし、この画面は本来、注文を受ける取引先の側の都合で作られています。
取引先が多い組織では、画面が取引先ごとに分かれ、注文の記録も取引先の数だけ散らばります。
組織内の承認経路を再現できるとも限らないため、承認は紙やメールで別に回すことになる場合があります。
記録を一か所にまとめたいという目的からは、離れやすい形です。

汎用のサービスは、複数の取引先への注文を一か所にまとめやすい形です。
その代わり、取引先側がどう受け取るかがつなぎ目になります。
承認の段階数や情報の扱いは提供元の仕様によって違うため、前の節の質問への答えがそのまま判断材料になります。

既存システムの拡張は、会計や物品管理と同じ台帳を使えれば、注文の記録を帳簿や在庫の台帳へ書き写す転記を減らせる可能性がある形です。
一方で、拡張できる範囲と改修の費用・期間は、元のシステムの提供元や委託事業者の対応に左右されます。
医療機関で、拡張する元のシステムが医療情報システムに当たる場合は、指針を確かめる範囲もそのまま広がります。

自作は、規程に合わせて細かく作り込め、小さく始めやすい形です。
ただし保守を担うのは作った職員や部署になります。
その人が異動すると、誰も直せない仕組みが残ることがあります。
誰がいつ記録を書き換えたかを残す仕組みや、閲覧できる人を限る設定も、自分たちで用意しなければなりません。
試行の段階で業務の流れを確かめる道具として使い、本格的な運用は別の形へ移す、という使い分けも考えられます。

表を見て判断が分かれるのは、主に「取引先の対応」と「承認経路の再現」の二つの軸です。
困りごとが承認待ちにあるなら承認経路を再現できるかを、重複や漏れにあるなら複数の取引先への注文を一か所で見られるかを重く見ます。
医療機関ではこれに情報管理の軸が加わり、教育機関では予算区分の振り分けが承認経路の軸に含まれます。

取引先が対応していない場合

比較の途中でよく出てくる悩みが、主要な取引先がWeb受付をしておらず、電話かFAXでしか注文を受けていないという状況です。
この場合、アプリを入れても、取引先への送信の段階で紙やFAXに戻ることになります。

それでも、組織の内側の入力・承認・記録は、アプリで一か所にまとめられます。
承認が済んだ注文をアプリから注文書として出力し、それをFAXやメールで送る使い方です。
このときに確かめたいのは、アプリが注文書を印刷やPDFの形で出せるかどうかと、送ったあとに「送信済み」と記録を付けられるかどうかです。
送信の記録を誰が付けるかを決めておかないと、送ったかどうかがまた担当者の記憶頼みになります。

取引先にも相談の余地があります。
メールでの受付ができないか、Web受付を始める予定はないか、注文書の書式をこちらでそろえてよいかを尋ねてみます。
取引先の担当者は、受け取った注文を自社の受注の仕組みへ入れ直しているかもしれません。
受け取り方が変われば、その作業も変わります。
そのため、こちらの都合で一方的に切り替えるのではなく、試行の期間は従来の方法と新しい方法の両方で受けてもらえるよう頼むのが現実的です。

取引先ごとに、どの受付方法に対応しているかを一覧にしておくと、形態の比較にも役立ちます。
Web受付に対応している取引先が多ければ汎用のサービスとつなぎやすく、FAXのみの取引先が多ければ、出力と送信記録の機能を重く見ることになります。

比べる軸 取引先提供のWeb発注 汎用サービス 既存システム拡張 自作
取引先の対応 取引先ごとに画面が分かれる 取引先側の受付方法とのつなぎ方を確認 提供元が対応する範囲による 送信は自分たちで行う
承認経路の再現 自組織の承認は別に管理が必要なことがある 提供元の仕様による 既存の承認と合わせられるか確認 規程に合わせて作れるが手間がかかる
既存システムとの連携 別管理になりやすい 連携方法を提供元に確認 同じ台帳を使える可能性がある 手作業でつなぐことが多い
情報管理 取引先の管理下に注文情報が残る 提供元との役割分担を確認 既存システムの管理の枠内で考える 権限や記録の保護を自分たちで用意
保守の担い手 取引先 提供元 既存システムの提供元・委託事業者 作った職員・部署
料金 取引先に確認 提供元に確認 提供元・委託事業者に確認 作る手間と保守の手間
教育機関と医療機関でアプリに求める条件の違い(模式図)
教育機関は公費・私費と承認経路、医療機関は標準コードと医療情報の扱い、両方に共通して規程で確かめることを分けて示した図教育機関は公費・私費と承認経路、医療機関は標準コードと医療情報の扱い、両方に共通して規程で確かめることを分けて示した図教育機関公費・私費のどちらで処理するかを入力で区別できる予算区分によって承認する人を変えられる規則で決まっている権限の段階を承認経路として再現できる医療機関標準コードに対応した品目マスタを持てる院内の物品管理の台帳とコードをそろえられる患者ごとの材料の使用や電子カルテとつなぐ場合は医療情報システムとして検討するどちらも規程で確かめる承認経路取引先の受付方法情報の取り扱い

▼ 図の内容を文字で読む
  • 教育機関
    • 公費・私費のどちらで処理するかを入力で区別できる
    • 予算区分によって承認する人を変えられる
    • 規則で決まっている権限の段階を承認経路として再現できる
  • 医療機関
    • 標準コードに対応した品目マスタを持てる
    • 院内の物品管理の台帳とコードをそろえられる
    • 患者ごとの材料の使用や電子カルテとつなぐ場合は医療情報システムとして検討する
  • どちらも規程で確かめる
    • 承認経路
    • 取引先の受付方法
    • 情報の取り扱い

導入前に確認する条件

教育側の確認先

教育機関で最初に確かめる相手は、発注のルールを決めている部署です。
公立学校なら、設置者である自治体の契約に関する規則や財務の規則、学校予算の執行に関する定めを所管する部署になります。
私立学校なら、学校法人の経理規程を所管する法人の事務局です。
尋ねることは、発注権限の範囲、金額による手続きの違い、アプリ上の承認を正式な決裁として扱えるか、記録をどの形でどれだけ保存するかです。

この中で迷いやすいのが、電子的な承認の扱いです。
アプリの画面で承認しても、規程が紙の決裁や押印を前提にしていると、結局は紙の決裁書も作ることになります。
そうなると、記録は一か所にまとまるどころか、紙とアプリの二重になります。
規程の改正が必要なのか、今の規程の解釈で足りるのかを、導入の前に所管部署へ聞いておくと、試行が始まってから止まることを避けられます。

私費の扱いも、公費とは別に確かめます。
私費の会計は、学校ごとの内規で取り扱いを定めている場合があり、承認する人も帳簿も公費とは違います。
アプリに私費の注文も載せるかどうかは、この内規を確かめてから決めることになります。
あわせて、配達先や注文者として児童生徒や保護者の名前が載るかどうかも見ておきます。
外部のサービスに個人の情報が載るのであれば、学校の個人情報の取り扱いに関する規程に照らして判断します。

医療側の確認先

医療機関では、確かめる相手が大きく三つに分かれます。
院内の情報システムを管理する担当、物品の購買や管理を担う担当、そして既存システムの保守を委託している事業者です。

情報システムの担当には、発注アプリを医療情報システムとして扱うかどうか、院内の運用管理の規程とどう関わるか、指針のどの編を見る必要があるかを尋ねます。
指針はこれまで版が改められてきました。
以前に読んだ版の記憶に頼らず、最新版が掲載されている厚生労働省のページで確かめることが大切です1。
外部のサービスの提供者や委託事業者との役割分担に関わる内容は、保守委託機関編を含めて該当する編を担当者と一緒に読み、具体的な要件を記述で確かめます1。

物品管理の担当には、標準コードと品目マスタの整合を尋ねます。
既存の物品管理の台帳とアプリの品目マスタを、どのコードで突き合わせるか。
新しい品目が増えたときに、どちらの台帳に先に登録するか。
ここが決まっていないと、同じ物品が二つの台帳で別のコードを持つことになり、取り違えを防ぐための識別がかえって混乱のもとになります。

委託事業者には、既存システムとつなげられるかどうかと、つなげる場合に費用の見積もりに何が必要かを尋ねます。
取引先には、教育機関と同じく受付方法と注文書の書式、試行期間に従来の方法と並行して受けてもらえるかを確かめます。

確かめること 教育機関の確認先 医療機関の確認先
発注権限と承認経路 契約規則・会計規程の所管部署(私立は法人事務局) 物品の購買・管理の担当
電子承認と記録の保存 契約規則・会計規程の所管部署 情報システムの管理担当
情報の扱い 個人情報の取り扱いの所管部署 情報システムの管理担当(指針の該当編)
品目と識別 事務担当(予算区分ごとの品目) 物品の購買・管理の担当(標準コードと品目マスタ)
既存システムとの連携 会計システムの担当 既存システムの委託事業者
受付方法と並行期間 取引先 取引先
困りごとの中心ごとに重く見る比較の軸(模式図)
承認待ちが中心なら承認経路の再現、重複や漏れが中心なら複数の取引先の注文を一か所で見られるか、医療機関では情報管理の軸が加わることを示した図承認待ちが中心なら承認経路の再現、重複や漏れが中心なら複数の取引先の注文を一か所で見られるか、医療機関では情報管理の軸が加わることを示した図承認待ちが中心承認経路を再現できるか教育機関では予算区分の振り分けも承認経路に含める重複や漏れが中心複数の取引先への注文を一か所で見られるか医療機関で加わる軸情報管理の軸

▼ 図の内容を文字で読む
  • 承認待ちが中心
    • 承認経路を再現できるか
    • 教育機関では予算区分の振り分けも承認経路に含める
  • 重複や漏れが中心
    • 複数の取引先への注文を一か所で見られるか
  • 医療機関で加わる軸
    • 情報管理の軸

小さく始めて定着させる手順

対象を絞る

確認が済んで形態の候補が決まっても、いきなり全部署・全品目をアプリへ移すのはおすすめしません。
品目マスタの登録、承認経路の設定、取引先との調整が一度に重なり、現場は慣れる前に「紙の方が早い」と元の方法へ戻りがちだからです。
一度戻った現場に再びアプリを使ってもらうのは、最初に使ってもらうより難しくなります。

対象の絞り方には、いくつかの考え方があります。
重複や承認待ちといった困りごとが実際に起きている品目。
注文の回数が多く、品名をそろえやすい消耗品。
取引先が少数に限られている品目。
新しい方法を試すことに協力的な部署。
医療機関では、規格の取り違えの影響が大きい材料はいきなり対象にせず、識別が単純な物品から始め、品目マスタとコードの突き合わせ方を確かめてから広げる進め方もあります。

何品目、何部署から始めればよいかに、どこにでも当てはまる数はありません。
目安になるのは、試行を担当する人が品目マスタの登録と更新を自分で管理しきれる範囲であることです。
もう一つは、承認者が一人か少人数で済み、承認経路の設定で迷わない範囲であることです。

運用ルールと切り替え期限

試行を始める前に、誰が入力するか、誰が承認し、不在のときは誰が代わるか、誰が取引先への送信と送信済みの記録を担うかを決めます。
急ぎの注文の扱いも決めておきます。
医療機関では、急を要する物品を電話で頼まざるを得ない場面も考えられます。
その場合に、後からアプリへ記録を入れる人と、いつまでに入れるかを決めておけば、例外の注文も記録から漏れずに済みます。

紙・FAX・電話との切り替え期限も決めておきます。
期限がないと、慣れた方法がいつまでも残り、記録はまた二か所に分かれます。
ただ、期限をカレンダーだけで決めると、取引先の受付が整っていないのに切り替える、ということが起こります。
次に述べる指標が落ち着いたか、取引先の受付が整ったか、規程上の決裁の扱いが確定したかを条件にし、その条件がそろう見込みの時期を期限として置くのが実際的です。

並行期間には、特有の落とし穴があります。
同じ注文を紙とアプリの両方で出すと、それ自体が重複発注の原因になります。
並行期間中は、「アプリで出した注文は紙では出さない」「紙で出した注文は送信担当が後からアプリに記録する」のように、どちらで出したかの決まりをはっきりさせておきます。

見直しの指標

試行の効果を見る指標は、外部の調査の数字ではなく、自分たちで数えられるものにします。
重複発注の件数、承認を待っていた日数、注文の状況についての問い合わせの件数などです。
大切なのは、導入する前に、同じ数え方で今の状態を数えておくことです。
前と後を同じ物差しで比べられなければ、アプリで何が変わったのかが分かりません。

指標は、最初に分けた工程と結び付けて読みます。
重複の件数は在庫確認と記録、承認待ちの日数は承認、問い合わせの件数は記録の見え方に対応します。
数字が思うように動かないときは、どの工程の問題かに戻って考えます。
たとえば問い合わせが減らない場合、現場の職員が自分の注文の承認状況を画面で見られる設定になっているかを確かめます。
見られない設定なら、記録は一か所にあっても、現場から見れば以前と同じく分からない状態のままです。

指標が落ち着き、品目マスタの更新が担当者の手で回っていることを確かめたら、次の品目や部署へ対象を広げます。
広げるたびに、承認経路の設定と取引先の受付方法を改めて確かめ、同じ数え方で指標を見直します。
この繰り返しで、記録がまとまる範囲を少しずつ広げていきます。

取引先がFAXでしか受け付けない場合の注文の流れ
アプリで入力と承認を済ませ、注文書として出力し、FAXやメールで送り、送信済みの記録を付ける四つの手順を並べた図1アプリで入力・承認する2注文書として出力する3FAXやメールで送る4送信済みの記録を付ける

▼ 図の内容を文字で読む
  1. アプリで入力・承認する
  2. 注文書として出力する
  3. FAXやメールで送る
  4. 送信済みの記録を付ける
発注アプリを小さく始めて広げる手順
対象を絞る、運用ルールと切り替え期限を決める、指標を数えて比べる、対象を広げるの四つの手順を並べた図1対象を絞る2運用ルールと切り替え期限を決める3指標を数えて比べる4対象を広げる

▼ 図の内容を文字で読む
  1. 対象を絞る
  2. 運用ルールと切り替え期限を決める
  3. 指標を数えて比べる
  4. 対象を広げる

困りごとの工程と、規程や指針の条件が見えてきても、それをどの形態の条件に置き換えればよいかは組織の中だけでは判断しにくいためです。

整理した工程と確かめた条件をもとに、候補になる形態と、提供元に尋ねるべき点を一緒に確かめられます。無料相談で要件を整理する

要点の整理

困りごとの工程 重複・漏れ・承認待ちが、入力・承認・送信・在庫確認・納品確認のどこで起きているか
アプリの効く範囲 記録・承認・送信をまとめる。在庫や納期そのものは変わらない
教育の条件 公費・私費の区分と、設置者の規則にもとづく発注権限・承認経路
医療の条件 標準コードでの物品の識別と、医療情報システムの指針の最新版の該当編
形態の選び方 取引先の対応・承認経路の再現・既存連携・情報管理・保守の担い手で比べる
試行の進め方 品目と部署を絞り、切り替え期限と導入前から数えた指標で見直して広げる

試行の対象や切り替え期限、指標の数え方は、現場の負担と規程の両方を見ながら決める必要があり、最初の設計で定着が左右されるためです。 試行に向く品目と部署の絞り方、導入前に数えておく指標の組み立てを確かめられます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

取引先がWeb発注に対応していないとき、アプリは使えますか。

使えます。
組織の内側の入力・承認・記録をアプリにまとめ、承認が済んだ注文を注文書として出力し、FAXやメールで取引先へ送る使い方です。
このとき、アプリが注文書を印刷やPDFで出せるか、送ったあとに送信済みの記録を付けられるかを確かめてください。
送信の記録を誰が付けるかを決めておかないと、送ったかどうかがまた担当者の記憶頼みになります。

公費の物品と私費の物品を、同じアプリで扱ってよいですか。

一つにまとめられるかどうかは、アプリの機能と規程の両方で決まります。
注文ごとに公費・私費を区別でき、予算区分によって承認者を変えられ、帳簿ごとに記録を書き出せるなら、同じアプリで扱う選択肢があります。
私費の取り扱いは学校ごとの内規で定めている場合があるため、内規と所管部署の考えを先に確かめます。
区別ができないアプリであれば、私費は別の方法で管理する方が、後から帳簿へ振り分け直す転記を避けられます。

医療機関が外部の発注サービスを使うとき、医療情報システムの指針は関係しますか。

厚生労働省は、医療機関等に対して、医療情報システムの取扱いにおいて「医療情報システムの安全管理に関するガイドライン」を遵守するよう求めています1。
発注サービスがどこまで関わるかは、注文に載せる情報とつなぐシステムによって変わります。
物品名と数量だけなら接点は小さく、患者ごとの使用と結び付けたり電子カルテや物品管理システムとつないだりする場合は、医療情報システムの一部として検討が必要になります。
院内の情報システムの担当と一緒に、最新版の該当する編を確かめてください。

試行は何品目・何部署から始めるのがよいですか。

どこにでも当てはまる数はありません。
目安は、試行を担当する人が品目マスタの登録と更新を管理しきれる範囲で、承認者が一人か少人数で済む部署です。
困りごとが実際に起きていて、品名をそろえやすい消耗品から始めると、効果を数える対象としても扱いやすくなります。

紙やFAXを残す期間はどう決めればよいですか。

日数だけで決めるより、条件で決める方が戻りを防げます。
重複や承認待ちなどの指標が落ち着いたか、取引先の受付が整ったか、アプリ上の承認を正式な決裁として扱えると規程上確定したかを条件にします。
なお、注文の手段として紙やFAXをやめることと、規程で求められる記録の保存は別の話です。
過去の紙の記録をどれだけ保存するかは、所管部署の規程に従ってください。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:厚生労働省「医療情報システムの安全管理に関するガイドライン」(2026年)

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top