「PayPal ボタン」の制作ワークフロー

「PayPal の『今すぐ購入』ボタンを作って！」

今や個人でも簡単に『オンライン販売』ができる。「画像」だろうが、「訪問サービス」だろうが、あらゆる製品サービスに対して『購入ボタン』を作成し、ホームページに設置する事ができる。しかも「3～4％」+「40円 (or $0.30 USD)」の手数料を差し引かれるだけだ。

具体的には、販売者は 『PayPal』 にログインし、『製品とサービス (Product & Services)』メニューから『ウェブ ペイメント スタンダード (Website Payments Standard)』に行き、ボタン種類を選択するだけで、ボタンづくりを始められる。（PayPal のまわしもの？）

1. 単一商品販売 (Single items)
2. ショッピングカート (Multiple items)
3. 定期的な自動支払い (Automated payments)

しかし、
しかししかし、
組織内の誰しもが『今すぐ購入ボタン』を作れる状況は、あまり望ましくない。ボタンの命名規則（PayPal 側に保存される）や、ボタン設定の統一感も図りたい。

[PayPalボタン作成依頼フロー]

「トップの即決事項」と「稟議ワークフローの結果」を一元管理

「パソコンを買う」、「人を雇う」。。。
実際のところ『トップダウン』で即決される事もあれば、『ボトムアップ』に決裁される事もある。どちらが良いと言うものではない。しかし『トップダウン決定』も『ボトムアップ決裁』も、どちらも組織としての決定情報として一元記録したいものだ。

以下の業務プロセス定義は、（起案者はさておき）、最終的な決定者、決定時刻、決定内容が、同じフォーマットで記録できる「意思決定プロセス」の事例だ。組織としての決定は、ここに流れたプロセスを参照すれば良い。ここでは「トップダウンで即決された事」を、さも「ボトムアップで決定された」かのように記録するような事はしない。

このクラウド時代にあって「組織としての決定データ」を電子化すべきは当然だが、この事例の様に「組織としての決定フロー」を複数想定しておくことも、組織機動性担保の観点で重要だと言える。

＃稟議書を『紙』で保存していたのでは、「過去の決定」を検索する事すらままならない。


ちなみに、、、
日本には、ボトムアップ型の意思決定記録フォーマットとして、「稟議(RINGI)」と言う仕組みがある。

社内規程で定められた起案責任者によって立案され、多人数の同意を得てから、決裁者が決裁する。例えば『大規模な広告』を出稿する際には、起案責任者は大規模広告が必要な理由や広告出稿の概要を書いた文書を作成し、それぞれの広告費の見積書を沿えて提出する。実際、その稟議書が決裁者に辿り着くまでに相当な時間と手間がかかってしまう。

しかし違う観点から見れば、決裁する時点で

• 本当に『大規模な広告』にする必要があるのか？
• もっと『大規模な広告』にする必要があるのではないか？
• その広告に伴う『リスク』に対応できているか？
• その広告によって得られる『効果』は正しく予想されているか？

と言った議論は十分に尽くされているとも言える。すなわち、決裁後の広告出稿作業は、驚くほど迅速かつ円滑に進められる。多くの場合、トップ自らが広告出稿作業について指示する必要はない。
日本企業の中で根強く支持され、今後もしぶとく(?)生き残るであろう仕組みだ。

[調達決裁ワークフロー]

翻訳ワークフローは「社内SNS」と連携させるべきだ

ワークフローシステムは「デスクワーカー」と相性が良い。
例えば、多くの時間をパソコンと向き合う『翻訳者』とは、実に相性が良い。

以下は、主にWebコンテンツを想定した『翻訳ワークフロー』だ。
日本語原稿を投入すれと英語とスペイン語が出来上がってくる仕組み??だ!?! ある程度運用すれば、徐々に原稿量とその所要時間の相関が見えてくる。

[翻訳ワークフロー]

[社内SNSの様子]

ワークフロー内でインターネットFAXを送信予約

建設業や製造業、あるいはB2Cビジネスにおいて、FAXはマダマダ現役だ。
ここでは、「ワークフロー内の業務文書」を、インターネット経由で自動的に FAX
送信する仕組みを紹介したい。何と言っても、FAX送信側のペーパレス（Paperless）が実現する。加えて、送信日時や送信データなど、FAX送信に関わる全ての情報が自動的に記録される様になる！
（業務効率化指標もカンタン可視化）

何やらカッコイイ話に聞こえるが、しかし冷静に考えてみれば、今日2012年、「2001年宇宙の旅」どころか「2010年宇宙の旅」すら終わっているハズのこの時代に、

1. 「複合機で印刷」して、
2. その紙をまた「その複合機でスキャンFAX送信」する

などと言うナンセンス極まりない作業手順が撲滅されていないこと自体がマズイ。さぁカイゼンだ！

[Internet FAX Outbound]

接待交際費を「損金処理」する唯一の方法

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

確かに、

• 「経済的利益に対して、所得税課税ができないよぉ～」とか、
• 「無駄支出が多い会社の法人税が減るのは、公平ぢゃな～い！」とか、

と言った統治者の論理には一応の説得力がある。

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

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

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

具体的には、その計算や捕捉が極めて困難な直接税である「所得税」(負担者と納税者が同じ)を廃止し、決済の自動化率の高い間接税に重点を置く方向性を示してほしい。（荒鼻息）

• a. 決済事務が効率化され、かつ冗費を抑制したい公共料金への間接課税（電気・水道等）
• b. ギャンブルや風俗の合法化と相応の間接課税
• c. 酒・たばこ・ガソリン等の嗜好品への間接税の強化

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

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

公式 Facebook ページへの投稿ルーティーン

例えば「Facebookマーケティング」などの業務は、イチイチ業務規定なんて作ってられない。そんなマニュアル、作り終わった頃には、Facebookの仕様自体が変わっている。文字だらけの規程やマニュアルなんかやめて、いっそ業務フロー図（BPMN）そのものを業務規定とみなせば、スグに運用に入れるだろう。（取締役会の議論も早く済む）

ちなみに、公式 Facebook ページへの投稿は「メール」でも可能だ。ワークフローの途中でメールを自動送信さる仕組みを設定しておけば、「必要な手続き」を経た原稿がミスなく自動投稿される。（画像添付もイケル！）

[Facebookページ投稿]

業務マニュアルを作るより、入力フォームにこだわれ！

「ワークフロー・システム」と「業務マニュアル」は表裏一体だ。改めて説明するまでもなく、両者には密接な関係があり、切り離せるものではない。換言すれば『「業務マニュアル」を具現化したものが「ワークフロー・システム」』とも言える。

ワークフロー・システムの構築を検討する人から「業務マニュアルを先に作るべきか？」と言う質問を受ける事がある。結論から言って「同時」に作ればよい。すなわち

『フロー図』と『入力フォーム』を印刷するだけで、業務マニュアルになる状態

が望ましい。

もっとも一連の作業従事者が、多様な母国語圏の人で構成される場合には、色々と工夫が必要だ。典型的な業務フローは「翻訳作業」だ。以下の翻訳フローは、『フォームの画面構成』と『簡単な英単語』だけで業務の進め方を表現している。こうなると別途『マニュアル』は、作るだけ野暮だ。

[翻訳フロー(＋サイト更新)]

専門会社に提案を要求するワークフロー

販売促進のための販促品や記念品は「アイデア勝負」だ。何処かで見かけたノベルティではインパクトに欠ける。

そんな場合には、やっぱりプロに提案してもらうのが良い。社内の「無知」を集めるより、社外の「プロ」に聞いた方が早い。…と考えた時点で『ノベルティ制作フロー』には「社外のプロ」が関与する事になる。

ここで紹介するノベルティ制作ワークフローでは、マーケティング部の担当者が数量やテーマなどの要望を設定するところから始まる(タスク『1.要望設定』)。「社外のプロ」（ノベルティ販売会社）は、その要望にかなう提案書(GoogleDocs等)を作成し、そのURLを書き込む(タスク『2.質問／提案』)仕組みだ。

[ノベルティ制作フロー]

Google Apps を使いこなそう！

Google Docs のWebフォームで「キャンペーン申込」を受け付けたい！
クラウド時代の今、実によくある話だ。「Google Apps」のWebフォームを利用するケースも多い。Google Sites と組み合わせる人もいるだろう。実に簡単に「公開フォーム」を作成できる。 そして驚くほどカスタマイズできる。しかも「集計」だってリアルタイムだ。何と言ってもタダ(無料)で使えるのもイイ！

しかし、単に受け付けるだけでは満足できなくなる。すなわち「クイックレスポンス」だ。例えば、(1)受付完了メールを送る、(2)関連資料を郵送する、(3)各エリア担当営業に申込情報を渡す…。そんなワークフローを実現したくなる。されど Google Apps には、ワークフロー機能が無い

そこで登場するのが Google Apps とダイナミックに連携できるワークフロー、、、そう「Questetra BPM Suite」だ！ コチラも無料でも使える。 これで複数人で効率良く、しかも迅速に対応できるようになる！！

[申込受付対応フロー＿営業対応地域選択]

「次のプレスリリースは何が予定されているの？」を可視化

「プレス原稿の作成フロー？？」
「オレの代わりは居ないし、ナカナカ人には伝えられない仕事なんだよ・・・！」

どれだけ会社規模が大きくなっても、「たった一人が担当している仕事」の１つや２つは存在する。しかし、その様な「一子相伝の秘められたプロセス」であっても、業務フロー定義を諦めるべきではない。少なくとも、『各案件がどの進捗にあるのか』を明らかにするだけでも、大きなメリットがある。

以下のワークフローは『プレスニュース原稿の作成フロー』の概略工程を定義したものだ。情報収集や裏づけなどの細かいタスクは気にせず、大きな流れだけを定義している。

＜各タスク名＞
0.NEWSアイデア提案、1.NEWSネタ熟成、1a. 助言対応、2.NEWS草稿執筆、2a. 助言対応、3.配信代行サービス登録、4.Webサイト アップ、5.効果測定、6.意見感想投稿

[プレスニュース原稿の作成 : 「2.NEWS草稿執筆」画面]

Webフォーム入力に連携する資料請求対応ワークフロー

「≪資料請求≫の受付」は、B2Bビジネスに限らず、B2Cビジネスにおいても、有効なマーケティング手法だ。場合によっては、外部に委託するタスク（BPO）もあるだろう。いずれにせよ≪見込顧客の満足≫を得られるスピードで対応したいものだ。

Webフォームで受け付けたデータは『メッセージ開始イベント』（手紙アイコン付の細丸アイコン）にて、ワークフローに取り込まれる。

＜各タスク名＞
0. 例外エントリ対応、1.重複等チェック、1b. 事務質問対応、2.重要顧客対応、3.郵送処理、3b. 郵送質問対応

[資料請求対応 : 「3.郵送処理」画面]

「御礼メール」と「来店勧誘メール」でCRMサイクル！

優良顧客に対しては、一人ひとり丁寧なメールを書きたい。でも・・・、いつ誰がどんなメールを送ったんだか？
そんなお悩みを抱える、自動車ディーラーさん、美容室理髪店さん、歯医者さんは、クラウド型ワークフロー製品を試してみてはどうか。効率よく『顧客ステータス』を管理できる様になるかも知れない。


＜各タスク名＞
0.新規顧客登録、1.次回来店勧誘文、2.来店日記録、3.勧誘文

[来店勧誘-御礼メール送信：「2.来店日記録」画面]

＜プロセスデータ＞

• 件名＜氏名＞

▼顧客情報▼

• 文字型: ふりがな
• 日付型: 生年月日
• 文字型: 電話番号
• 文字型: 電話番号(副)
• 選択型: 性別(男性 / 女性 / 不明)
• 文字型: メールアドレス
• 文字型(複数2行): 住所
• 選択型: 優良顧客ランク(S / A / B / C / D)

▼来店誘導▼

• ユーザ型: 担当営業
• 日付型: 最新来店日
• 日付型: 次回来店誘導日
• 文字型(複数5行): 前回(初回)の来店御礼メール [タスク0、メッセージ開始イベント]
• 文字型(複数5行): 今回の来店誘導メール [タスク1、3]
• 文字型(複数5行): 今回の来店御礼メール [タスク2]

▼コントロール／カルテ▼

• 選択型: 制御(来店御礼メール送信＋次回誘導タスク予約 / 次回誘導タスク予約のみ / 優良顧客から削除) [タスク2]
• 掲示板型: 社内通信

ブログ発信は「社員当番制」で回せ

社内当番制のBlog発信。一般従業員が「執筆」する。多くは語るまい！！？
Blogへの投稿は『メッセージ送信中間イベント(メール)』によって自動投稿される。

＜各タスク名＞
1.指名、2.原稿執筆、3.依頼/投稿、4a.翻訳、4b.修正対応

[Blog投稿：「2.原稿執筆」画面]

プレスリリース配信後の掲載調査もキッチリ実施せよ

昨日は Questetra のプレスリリースの日だった。〔内容が気になる人はコチラ〕
基本的な情報の伝達経路は「情報発信者⇒マスメディア⇒一般大衆」なのだが、最近のプレスリリースでは「情報発信者⇒配信代行サービス⇒マスメディア⇒一般大衆」の流れが目立つ。すなわち、メディアの数が多くなった、プレスリリース文を一般大衆が直接読むケースがある、SEO対策にもなる、そもそもメディアが配信代行会社に依存しつつある、などが背景にあるようだ。


＜各タスク名＞
1.プレス配信文登録、2.配信会社通知、3.最終原稿確認、4.自社サイト登録

[プレス配信-効果測定：「1.プレス配信文登録」画面]

「イレギュラーな事態」の発生件数を計測しよう

「リマインダメールをモレなく送信するワークフロー」。
なるほど、「見学会」や「試乗会」への申込者様が、忘れずに参加して頂ける様に『前日などにメールを再送する』のは良いサービスだ。

ただ、どこの世の中でも「例外」と言うモノが存在する。どうしてもイベントに来れなくなったお客様、何かノッピキならない事情で御礼メールすら送れなくなったお客様…。

リマインダメールをモレなく送信するワークフロー

マンションや車の販売店は、あの手この手の「キャンペーン企画」を考えている。
「見学会」や「試乗会」なんて良くある話。その申込を如何に効率よく受け付け、イベント当日にちゃんと来させる事ができるか？　事務作業のミスやモレをゼロに！
すなわち、メール送信先を間違える事だけは避けたい。ただ、一人ひとりの参加者に対して、キッチリとメール文章を書きたい。

ホントに公正な「厳正なる抽選プロセス」

『１名様に世界一周旅行をプレゼント』の抽選なら、風車型の抽選マシーンを回して、大勢の面前でワイワイ楽しい抽選会を実施する。でも『100名様にiPadをプレゼント』となれば、そうも行かない。

まずは「厳正なる抽選」である事を、誰にでも説明できる様にしておきたい。例えば「コンピュータで自動抽選」と説明したところで、やはり「転記ミスはないの？」「２～３人で密室処理してたりしない？」など、小市民は何かと質問したくなる。
出来る事なら「社内不正の発生確率が低い」あるいは「ミスや手戻りが発生しない」、そんな業務手順を考えたい。