Photo by Unsplash, Darya Karaliova
Pythonで注文書PDFの読み取りできるようしたい！の巻、久々の続編です。
(何してるの？というかたは、こちらをお読みください。→ 3/5の記事)
今回は技術的なお話はありません。私の脳内環境を整理したいだけの記事です。🙇
100％自分のための記事でしかございません。
要件定義の前提を今一度考える
弊部署の取引先は2桁におさまるくらいなのです。
寡占状態が進んでいる業界だからです。業界ベスト○までの取引先が、販売実績の80％-90％くらいを占めています。(体感ですが。)
ちなみに、医薬品のメーカー・卸は「JD-NET」(ジェイディーネット)という受発注・仕切書データなどを交換するサービスがあります。
決められたルールにのっとり、注文データや注文を受け、出荷しましたよというお知らせを電子的にやり取りする仕組みです。
現在弊社の受発注データのほぼ80％程度はJD-NET経由で受け取っています。
JD-NET経由の受発注データは、直接基幹システムに取り込むことで入力が完了します。つまり、人の手で入力する必要はありません。そのため、入力チェックもほぼ不要です。
残り20％がFAX経由で受け取っています。
これらは特殊な製品であり、事前にエンドユーザを把握したいということもあり、取引先に対して、FAX経由でのご注文をお願いしています。JD-NETの受発注データでは細かい指定はできません。製品○個を注文します、といったざっくりした注文が前提です。
製品の性質、JD-NETの性能により、「20％」のFAX経由のご注文は、はJD-NET注文に置き換わることはありません。
それどころかこの「20％」の実績が弊部署存続のカギを握るようです。今後はこの「20％」注文に関わる製品をメインで伸ばしていこうという方針だからです。
さらに、弊部署は年齢構成上、今後人材の流出が進みます。そして、業績がよくないため流出した分の補充はありません。
何しろお金を稼ぐ仕事をする営業担当者、営業担当者を助ける製品担当者がいなくなっても、補充は一切ないのです。
受注担当のような、地味な業務はまっったく問題視されていません。そんなわけで、こちらの人材不足は何も考慮されません。
そんな中、受注のお仕事をお手伝いしてもらっている2名のかたのうち、1名が3月末で退職されます。
FAX経由のご注文を入力後、入力者ともう1名がチェックをするという体制で仕事を進めています。受注のお仕事をお手伝いいただくかたは1名いればOKです。ただし、その1名も休暇を取ることもあるでしょうし、体調が悪くなることもあります。
そうなったときどうするの？！
という問題がふってわいたため、Pythonで注文書PDFの読み取りできるようしたい！ということになりました。
ちょっと寄り道をしてしまいました。
背景事情もよく考えることが必要なので、今、入力しながら、FAX経由のご注文がなくなることはない、むしろ増えるだろうと考えると、入力チェックを人ありきとする考え方を変えたほうがいいと思うのです。
さらに驚愕の事実(大げさやけど)
複数人の目でチェックをすれば安心、という考え方が部署内では根強くあります。
でも残念ながら、ちがうちがうそうじゃない。
ふだんの受注入力において「まちがい」発覚のパターンは次のものがあります。
①入力者が入力途中で気付く
②入力者が入力チェックをして気付く
③②の後、別の人が入力チェックをして気付く
④③の後、入力者が念のためチェックをして気付く
実は①から④の中でいちばん多いのは④なのです。
受注入力の仕事をするようになってからのいちばんの驚きは、人間の認知能力の不思議さです。
だれかがまちがう → 別の人も同じ個所でまちがう
という現象がよく起きることです。
人の異動もあり、現在受注担当者は私1人です。そこで別の部署のかたに入力チェックをお手伝いいただくことになりました。
私が入力、チェックをした上で、お手伝いいただくかたに、入力チェックを依頼しました。「まちがいなし」で2度目の入力チェックが終わり、書類が戻ってきます。
でも何気に気になり、再度入力チェックをすると、まちがいがあることに気付いて、冷や汗を1リットルくらいかいたことがありました。
1度あることは2度、3度ある可能性は高いですよね。
そこで、入力チェックは、①自分チェック → ②自分以外のかたチェック → ③再度自分チェックの3ステップで実施することにしています。
まちがいの連鎖は、いったいどういうメカニズムなのでしょうね。すごい興味があります。
学術的には非常に興味深い内容なのですが、お仕事として考えた場合、とても悩ましい問題です。😞
1バイト文字が主役なので、機械におまかせ向けではないか
医薬品は「統一商品コード」という数字だけで構成される商品コードにより、認識されます。
FAX経由のご注文の場合、統一商品コードと商品名(名称)が記載されています。
どうしても人は解読しやすいほう、つまり、商品名(名称)を見てしまいがちです。
しかし、FAXの文字はつぶれていたりしがちです。その上、名称だけを見ると判断を誤りそうな製品が多くあるのです。
そこで、統一商品コードで判断することがいちばん正確です。つまり、統一商品コードと商品名をひもづけられるようにする・・・となると、まちがいがないようにひもづけないといけません。他にも、数量の誤りもあります。
受注入力で必要な要素は、①取引先(ご注文者)、②製品の種類、③数量 です。
最低この3つさえ、正確に取得できれば、弊部署の受注入力作業の95％くらいは完了です。
②は統一商品コード＝数字ですし、③は数字であることはいうまでもありません。
①は3/13の記事にも書きましたが、電話番号を使います。電話番号は数字、こちらも基本は1バイト文字です。
1バイト文字が主役なので、これはむしろ人より機械にがんばっていただくほうがいいのではないのか。まさに適材適所ですよ。
えらい長々書きましたが、なぜPythonでわざわざプログラムを作ろうとするのか、ということをじっくり考えてみました。
ブログ：1177
コメント