スモールビジネスのIT日誌

• (2011-10-14 06:59:10)

平均処理件数

現在の当社の1日の注文件数は平均40件。月間千件強で推移中。

季節要因で、毎年同じ時期に一時的に盛り上がる商売は多い。当社の場合はこの季節。現在100件くらいはあるだろうか。多い日は200件くらいの日も続く。これは今まであまりなかった数字。

突発的処理件数による負荷テスト

毎日40件の注文を処理しているシステムに、200件の処理をさせると、ちょっとした負荷テストになる。これはおもしろい。

どこまで耐えられるか部分的なテストはできても、実際の受注から発送、その後のサポートまでトータルなテストはできないので非常によい経験になる。

第一印象は処理時間を要するもののシステム自体は何ら問題なく稼働していること。たぶん、1日あたり千件くらいの処理でもシステムは破綻しないと判断している。

人手への負担

ところが、取り込み処理は途端に遅くなる。原因は人手で行う例外処理。現状、例外処理は「10分/件」と見積もっている。

・例外処理処理時間・・・10分/件
・例外処理発生件数・・・10%
・40件の例外処理処理時間・・・10分 x 4 = 40分
・200件の例外処理処理時間・・・10分 x 20 = 200分(約3時間)

例外処理はメールや電話での確認作業や顧客対応なども含まれるため10分では利かないこともあるが、簡単なものもあるため平均して5〜10分が実績といったところか。

結果的に「200件の全取り込み作業は4時間」という状況である。なおかつ見落としやミスの発生率が高くなっており、破綻していないシステムも改善の必要性を強く感じる。

負担軽減のためのシステム改善

負荷テストの結果、見えてきた改善項目(おもにAccess)：

・クレジット決済マッチングの処理の改善(システムの完成度が低いため手作業によるマッチングがまだ多い)

・与信チェックプログラムの改善(DCountやDLookup関数を使用してきたが、遅すぎる)

・保留中顧客の識別対策

・重複注文の検出・同梱処理プログラム(重複注文の検出が弱く、人手に依存していた)

・キャンセルルールの改正(運用規則の改正)

・お届け日の規制(現状、自由テキストから選択方式に)

・沖縄向け発送アラート(「沖縄ラベル」添付をより確実・スムーズに)

・コンビニ用紙アラート(ピッキング担当者用にコンビニ用紙同梱を知らせるアラート)

・注文主と届け先が違う場合の決済方法をクレジットのみに固定(不正行為防止)

・半角問題(Accessのフィールドをバイナリ型に変更し、半角のまま保存を試みるが失敗。保留中)

・メール便かつ日時指定の無効化(メール便は日時指定ができない内容の説明を目立つように入れているが、読まない人が多いため対策が必要)

・プリンタージャム(どうしようもない)

・個別メッセージラベル・アラート(ピッキング担当者用に明細書に記載のこと)

・Amazon発送通知の自動化(現在は手入力)

・消込プログラムの改良(ExcelVBA。完成度が高くない)