過去の『業務データ』も新システムに「引っ越し」たい。
SIerさん達に嫌われている「マイグレーション」って奴だ。Questetra を利用するお客様からも、しばしば問い合わせがある。

しかし、、、
そもそもワークフローシステムでは、各工程(各タスク)の『処理をした日付』が大事なのであって、最終成果物としての『業務データ』だけを引っ越しても、あまり意味がない。そう、ホントは『業務データ』の引っ越しなんてやらない方が良い・・・(などと、ソッケナイことを書くと、夜道で後ろから刺されるので真面目に答えよう)

どうしてもワークフローの『業務データ』を移行したい場合には「データを流し込むクチ」を作るのが良い。具体的な例として、前回掲載の記事『BPMNを「日報」で学ぶ』で示す。以下のワークフロー定義は前掲の定義(ワークフロー図)と一見して同じだが、何やら不思議な開始ポイントが1つ追記されている。

[日報フロー(業務記録)]

「BPMN を見て業務を理解するのは簡単だけど、いざ書くのは難しい。」
(BPMN:Business Process Model and Notation)

確かに難しい。しかし一方で『業務フローのあるべき姿』を考えられる立場にいなければ永遠に書けない。
  • 日常業務で何件発生するのか、決算期には何件くらい増えるのか?
  • 誰が処理すべきか、何人で処理すべきか。。。
どうしても最後には、業務の流れに対する知識が必要不可欠だ。むしろ『IT知識』は不問だ。

では、どうすれば社内に BPMN を浸透させることができる? それは、日常の単純な業務を BPMN で書く事から始めてもらうしかない。もしあなたが毎日日報を書いている/書かせているなら、日報フローがオススメだ。

[日報フロー]

最近の業務フロー表記は、分かりやすい。(BPMN:Business Process Model and Notation)
何と言っても「誰でも初見で【業務の流れ】を理解できる」のが魅力だ。事実上の「世界標準」と言うのもイイ。

だが一方で、、、
現場で働く従業員も議論に参加でき、【業務フロー】の「あるべき姿」に熱い議論が交わされるようになった。結果としてプロセスオーナー達は、その調整能力が試される事態になっている。ま、本来のシゴトだから仕方がないのだが、『ビジネスプロセスモデリングの鉄則』あたりを読んで、まずは知識武装をしてもらいたい。そう、、、BPMN は「ディスカッション・ツール」でもあるのだ。

さて、、、
組織稟議(意思決定)フローにおいて、決裁者自身が決裁前に承認者を追加できるようにしたい、と言う要望があった。稟議規程上(業務ルール上)は回す必要が無くても案件内容を考慮すれば回すべき人、はしばしば存在する。日本語で「根回し」と言うヤツだ。。。さて、どうする?

[稟議フロー]

『交際費』を「単純に損金として算入できる国」は、むしろ珍しい。日本でも原則として、税務上の「損金」とはならない。

確かに、
  • 「経済的利益に対して、所得税課税ができないよぉ~」とか、
  • 「無駄支出が多い会社の法人税が減るのは、公平ぢゃな~い!」とか、
と言った統治者の論理には一応の説得力がある。

しかし、『交際費かどうかの判断』がメンドウだったり、延いては『税額算出が複雑』になったりと、必ずしも合理的な制度であるとは言えない。

参考)主要国における交際費の税務上の取扱い (財務省/2011年1月)
http://www.mof.go.jp/tax_policy/summary/corporation/080.htm

業務プロセス管理(BPM)の視点で言えば、社内に流れるプロセスがスムーズに回る様にするために、社内の制度を単純化することは決して珍しい事ではない。私見ながら、ITによる事務処理の省力化を目指し、「ITが代行しやすい制度」に変えていく、と言う方向性は、国家運営にこそ適用してもらいたいものだ。すなわち、税制の大幅な単純化は今こそ推進して欲しい。(鼻息)

具体的には、その計算や捕捉が極めて困難な直接税である「所得税」(負担者と納税者が同じ)を廃止し、決済の自動化率の高い間接税に重点を置く方向性を示してほしい。(荒鼻息)
  • a. 決済事務が効率化され、かつ冗費を抑制したい公共料金への間接課税(電気・水道等)
  • b. ギャンブルや風俗の合法化と相応の間接課税
  • c. 酒・たばこ・ガソリン等の嗜好品への間接税の強化

(あ、、、業務テンプレートの紹介につなげがたい流れ。。。)
ここでは「接待交際費」の多くを何とか損金算入させるべく、社員が「接待交際費」を行う前に申請させ、必要に応じて支出レクチャーを行うワークフローを例示する。

[接待交際費の事前事後申請]

無線LANは、最初の設定はメンドウだが便利だ。

「WEP廃止とWPA化」、「MACアドレス制限」、「SSIDステルス化」、「複数のSSID運用」、「無線LANアクセス制御」、、なんだか難しい話が次々と出てくるが、それでも BYOD は『時代の流れ』だ。

※ BYOD: ビーワイオーディー/ Bring Your Own Device /私物端末の持込

このクラウド時代、「情報端末」は何時でも何処からでも「情報システム」を利用できて当然。閉鎖的な通信ネットワークで「情報システム」を守る、と言うだけの発想では、クラウド・テクノロジーを活かしきれない。

Android、iPhone、iPad、Nintendo(?)、PSP(!?)…。

# 念のために書いておくが、「高度なセキュリティが求められる情報システム」の場合は、特定の部屋からしかアクセスできない(セキュリティ・ゾーンの設定)等のポリシーがあって良い。

まずは、「MACアドレス制限」のための申請フローを確立したい。
いつ誰がどんな端末の接続申請して、いつ誰が承認し、いつ誰が設定したのか?
当然ながら「紙」や「メール」で申請を受け付けていたのでは話にならない。検索性も乏しければ、入力の手間やミスが心配だ。「情報端末の情報」をワークフローに入力させ、必要に応じて差し戻す業務プロセスを構築しよう。

※ Media Access Control address

[無線LANへの接続申請]