電子的な作業手順書を作ることで、「変更に柔軟に対応」できること、できないこと

あ、そうそう、先ほどのブログに書き忘れたんですけど、

電子的な作業手順書をつくると、大幅変更しやすくなるとかいたけど、
ビジネスモデルが変更不可能なように、データ構造を切ってしまうと、変更できです。

データ構造によって、仕様の変更範囲っていうのは、規定されます。

---

つまりですね、電子的な作業手順書を作るというのは、こんなかんじですよね。

・はじめに、「こういうモノがきたら（あるいはすべてのものに対してでもいいんだけど）」これらの処理を行うという、作業手順を登録する
　→これを、作業手順の雛形と申しましょうか

・実際のものが着たら、そのモノを判断し、そのモノにひもづいている作業手順の雛形をもとに、作業手順書を作成する

・作業手順書にかかれたものを、実行していく
　→途中、書き換えもありえる。

---

でも、これで、変更が柔軟になるのは、作業手順、あるいは、作業だけです。

　データ自体を柔軟にしているわけではないので、個々の作業は、相変わらず、データ構造の規制はうけます。
　たとえば、「流通SCM共通プラットフォーム」においては、たしか、仕入れ商品と仕入れ元は、１対１対応で決まっています（ある商品を仕入れるのに、複数の仕入先から仕入れることを想定していない。もちろん、違う商品なら、違う仕入先はありえる）。

　作業手順書を使っても、この仕入先と商品が１対１対応という構造は変わらないので、複数仕入れの商品は、このままでは、取り扱えません。

　そういう意味で、データ構造の組み換えに対して、柔軟に扱えるわけではありません
　（まあ、データ構造が変わるって言うのは、大きな問題なんだけどね）

　そうそう、データ構造に関する話題で、ちょっと書きたい話があるので、それは、またこんど（今回の話とは、かなり違う内容なので）

流通と印刷業にみる、モノによって処理が違う＆仕様大幅変更ありうる場合の対処法

　昨日のブログに書いた、


ビジネスプロセス制御機能：前述のパターンの組み合わせによるビジネスプロセスを定
義可能で、そのプロセスに従ってデータのやり取りを実行します。

に対しての

・説明＆この方法を利用するといいシステム
　　　・モノによって処理が違ったり、
　　　・対処しながら処理が変わったり、
　　　・仕様が朝令暮改（朝礼朝改？）で大幅変更する場合など

・メリット

・昨日のブログの最後に書いた「こういう標準化は、営業的に問題があるぞ」の意味

を、説明したいと思います。

---

■■説明

　世の中には、モノによって、処理内容が違う（というか、処理内容が決まる）というものがあります。
　その上、はじめに、どういう処理にするか、決められない場合があります。

　たとえば、ＡＤＳＬのサービスを行うプロバイダのシステムを考えます。ウィリアムのいたずらのようにＡＤＳＬの移転をするとすると、

　　　・ＡＤＳＬ回線が引けるかどうか、引けて、移転ならそのままだけど
　　　・もし、引けない場合、光回線が入っていたとき、お客さんが光を望んだ場合
　　　　　　→光回線サービスに変更になる。
　　　・引けるけど、お客さんは、その回線を、移転でなく、新設している
　　　　　　→新設コースに移行して手続き
　　　・ＡＤＳＬ回線は、実は引けなかった
　　　　　　→契約解除

　など、状況によって、商品プラン自体が変わってしまい（ＡＤＳＬ移設、ＡＤＳＬ新規、光回線）作業内容が決められないなんてとき、

　印刷業だと、Ａ機，Ｂ機どちらでも印刷可能なものをＡという印刷機で印刷しようとしているとき、Ａ機でなければ、印刷できないものが入ってきてしまった場合、（でＢ機はあいている）Ｂ機で印刷する。

　しかし、Ｂ機で印刷するには、Ａ機とインクの色合いが違うため、単純にデータを流すというわけにはいかず、変換工程が入る、などのように、状況によって（上記の場合、機会の空き状況）によって、作業内容が変更になるようなときがある。

　さらに、ベンチャーなんかだと、ビジネスを朝礼朝改（朝令暮改よりひどい。言ったそばから違うことをいいだす）で組み替えるなどということも、ありえなくもない。
　それに対応するには、仕様の大幅変更が続いてしまう。

---

　こんなとき、システムを、「Ａの処理をやったらＢ，Ｂの処理をやったらＣ」というふうに、固定的に組めない。こういうときのテクニックとして、

・作業指示書を作成する
・作業指示書をもとに、コントローラーがプログラムを起動する
・モノによって、状況によって、作業指示書を書き換える

というようにする方法がある。

　印刷業の、プレス工程（編集のあと、実際に印刷する工程）では、この（デジタルの）作業指示書が、標準化されていて、ジョブチケットと、呼ばれていた（現在は、名前が変わっていると思う。ＤＴＰエキスパートの更新試験で出てきた気がするが、わすれた）

　「流通SCM共通プラットフォーム」の場合には、上記の作業指示が、ビジネスプロセス、そのコントローラーが、ビジネスプロセス制御機能ということになると思います。　

---

　具体的には、こんなかんじです。

・まず、「こういうものがきたら、こういう処理を行う」という「もの」と、「作業手順（処理パターン）」の組み合わせを（ＤＢなどに）登録します。

・画面などから、モノを処理するように指示がコントローラーに来ると、コントローラーは
１．まず、もらったモノがなにか判断し、
２．そのモノの作業指示（書）は作成されているかどうかを（ＤＢから）調べます
３．（あ）作業指示（書）がある場合、
　　　３－（あ）－１．その作業指示書をみて、現在の処理ステータスを知ります。
　　　３－（あ）－２．指示書と現在のステータスから、次の処理を決定して実行します
　　　　　　　（たいてい、作業指示書の次の項目をやらせるけどね）
　　　３－（あ）－３．処理した結果を、作業指示書に反映させます
　　　　　　　　正常なら、そこまでの処理終わったよステータスに
　　　　　　　　異常なた、エラーだよステータスに
　　　　　　　　ぜーんぜん違うことをやらせたい場合、作業指示書を書き換える
　　（い）作業指示書がない場合
　　　　　　　登録内容をもとに、作業指示書を作成します
　　　　　　　一番はじめの作業をします。これ以降は、３－（あ）へ、

４．作業指示書のすべての作業が終了したら、おしまいです。

プログラムでかかないと、わかりにくいっすね。
こんど、書こうかな。。

---

■■　メリット

　このやりかただと、ビジネスモデルを組み替える程度の仕様変更は、作業手順を登録するＤＢの内容を変えるだけなので、簡単に出来ます。

　そして、モノによって、使う作業手順（リスト）を切り替えれば、モノをみてから、作業手順を作り出すことも可能です。処理結果によって、作業手順を書き換えることも可能です。

　つまり、プログラムを作る時点では、どのような処理をするか、きまっていなくても、動く直前までに、作業手順が登録してあれば、ＯＫです。
　さらに、登録してある作業手順を変更すれば、ぜんぜん別のプログラムにできます。

　さらに、登録内容ですが、起動するプログラムのクラス名にして、起動するプログラムは、作業全体から継承され、起動するメソッドは、全部共通にすると、作業手順をみて、リフレクションを使って、起動させることが出来、こうなると、リンクする必要もなくなってきます。

　プログラムについていえば、新規の部分だけ作ればいいので、楽です。

---

■■　営業的な問題
　ということで、この方法、よさそうなのですが、営業的には、問題があります。

　１つは、起動されるプログラムを提供する人すべてが、このやり方を理解し、賛同してもらえないとできないこと。

　仕様変更が、あまりないシステムの場合、このように、（電子的な）作業指示書を作るのは手間がかかるし、面倒です。わかりにくいです。

　なので、反対されてしまいます。

　印刷業の場合は、adobeという影響力の値良い会社が旗振り役でやったから、出来たんだと思います。

　一般の企業のシステム開発でやった場合、システムはきれいにまとまるのですが、ＳＥさんに（理屈を）理解してもらうのが、難しかったでした（私のケースの場合。なんで、結局やんなかった）

　ということで、今日書いた内容も、みんなに理解してもらえたか、ちょっち不安。

個人情報保護のためのデータ入力法（結果として効率アップ？）と、その問題点？？

　最近、データ入力で、個人情報保護をするために、分解して入力することってありますよね（まあ、そのほうが、作業効率もいいんですけどね。）

　つまり、こーんな、用紙があったら

＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　お客様番号｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　フリガナ　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　氏名　　　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　住所　　　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　ＴＥＬ　　｜　　　　　｜ＦＡＸ｜　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋

　これを、全部渡したら、入力した人に、この人の、個人情報がばれちゃいます。

　そこで、

（１）この用紙をスキャナーで読み込む
　　→自動的に読み込んでくれる装置なんかだと、便利便利だよね。

（２）そのイメージデータをもとに、部分部分に切る
　　→これは、たぶん、プログラムで、やるんだと思うけど、スキャンした

　　　イメージファイルを

（あ）お客様番号
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　お客様番号｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋

のファイルと

（い）名前
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　フリガナ　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　氏名　　　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
のファイルと

（う）住所
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　住所　　　｜　　　　　　　　　　　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
のファイルと

（え）電話番号
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
｜　　ＴＥＬ　　｜　　　　　｜ＦＡＸ｜　　　　　　　｜
＋－－－－－－－－－－－－－－－－－－－－－－－－－＋
のファイルにわける。

ファイル名などから、（あ）、（い）、（う）、（え）の関係はわかるようにする
（たとえば、
（あ）をimg0001_a.jpg,
（い）をimg0001_i.jpg,
（う）をimg0001_u.jpg,
（え）をimg0001_e.jpg,
とするとか）

　読み取り開始位置にマークをつけ、プログラムで、そのマークが現れたら、そこから、何センチ～何センチまでを切り取り、ファイルに保存というようにする。

（３）こうして、部分ごとに入力してもらい、

（４）最後に、ファイル名などを元にデータを合成する。

---

こうすると、

・入力した人は、部分部分しか入力していないので、個人情報がわからない

・用紙が、自動的にスキャンでき、分割ソフトがあるばあい、ファイル分割までが自動化
　できるうえ、入力者のところに、紙を渡さないですむので、
　かさばらない、紙の送料がかからない。

・入力者も、おなじようなものを入力するので、早く入力できる。
　とくに、お客様番号のような、数字しか入力しない場合、テンキーだけで入力できる。

などなど、いろんなメリットがあるといわれています。

　ウィリアムのいたずらも、「これは、もっとも！」と思い、大賛成なのですが、

　うーん、こまったバカが、ここに一人います
　こいつです（「ガス口座振替で大失敗！編」のほう）

　このバカのように、訂正して、欄外にかかれてしまうと、このやり方、こまりますよね。
　（訂正内容を範囲外に書かれると、文字が切れたり、読めない）

　そういう場合は、入力しないでおいてもらい、あとで、まとめて誰かが、そこを（全体の紙をみながら）入力するって言うことになるんだろうけど。。。

　ここの指示を明確にしておかないと、文字が切れているのに、適当に想像で入力された場合、１と６なんかで、ちょっと問題になるかも。。。

　と、今、お客様番号を間違えて書いて（ばか＝ウィリアムのいたずら）思った。

　ちなみに、だからといって、上記のやり方が、問題になるほどではありません。
　バカは、そんなにいないだろうし。。（ただ、訂正されている場合、無理に入れるなという指示は必要＆それをフォローする体制も必要かと感じた）