ワークフローサンプル: ホームページ更新

ラベル ホームページ更新 の投稿を表示しています。すべての投稿を表示

ラベル ホームページ更新 の投稿を表示しています。すべての投稿を表示

業務：アイコン作成やポスター制作など

新しい業務プロセス定義で、社内からの「依頼」を一元的に管理できるようになった。

マーケティング部でのデザイン案件、製品開発部でのデザイン案件、営業部でのデザイン案件、、、そんな依頼を「チーム」として効率よく対処できるようになった。また、デザイナ同士がお互いの制作物に興味を持つようになり、各デザイナのスキルアップにも寄与していると思う。

※参照：「第574話：プロセス改善物語（SaaSベンダー編１）」、「第575話：プロセス改善物語（SaaSベンダー編２）」

課題：納品スケジュールが守れないケースも

ただ、それでも、「納期」に間に合わなくなるケースが発生している。

たとえば、「急ぎの依頼」が入ると「通常の依頼」があおりを受けてしまうのだ。特に「新サービスのリリース」「新しいキャンペーンの準備」といった大きなプロジェクトが動きはじめると、様々な「急ぎの依頼」が発生する。結果として「締切に融通が利く通常の案件達」が納期に間に合わなくなってしまう。

外部リソースを活用するなどしてでも「制作スケジュールを守れるデザインチーム」でありたい。

[デザイン依頼対応プロセス]

続きを読む »

業務：デザイン制作

社内から次々と「依頼」が舞い込んでくるデザインチーム。
デザイン制作の「依頼フォーム」（ワークフローの開始工程）を整備したことで、以前より安定して依頼をこなせるようになってきた。（参照：「第574話：プロセス改善物語（SaaSベンダー編１）」）
自動開始イベント（メッセージ開始イベント）も用意したので、『デザイン依頼対応プロセス』が「サブプロセス」として利用されるケースも増えてきた。つまり販売部門や製造部門の業務プロセス図（メインプロセス）に「呼び出しイベント」と「待ち受けイベント」が配置かれ、業務プロセス間の連携が API POST 通信によって自動化されるようになった。（←要は「依頼案件タイトル」や「依頼仕事の作業詳細」といったデータでプロセスが開始され、作業完了と同時に「デザイン報告テキスト」と「成果物ファイル」といったデータが戻される）
さらに「サブプロセス」を呼び出すメインプロセスのサンプルも社内提示したので、今後、様々な部門におけるデザイン業務が『デザイン依頼対応プロセス』に集約されていくハズだ。

課題：スキルアップしない

デザイナごとに「担当案件の数」や「担当総額」が可視化されるようになった。また、ベテランデザイン達が「窓口担当者」として「作業担当者」の作業進捗をコントロールするようになったので、若手デザイナが「ノーチェック納品」（誰もチェックしない納品）してしまうことも無くなった。しかし、デザインは本来、「品質」こそが命だ。この業務プロセスのままでは、社内の満足度が下がっていくような気がする。もう少し、チーム全体として実力を伸ばしていけるような業務プロセスにならないものだろうか？　せっかく「デザイン依頼対応プロセス」として独立性を高めているのだから、単に数をこなすためだけの業務プロセスではなく、スキルアップにつながる仕組みを考えたい。

[デザイン依頼]

[デザイン依頼対応プロセス（レビューあり）]

続きを読む »

業務：デザイン業務

デザインチームの業務は多岐に及ぶ。

たとえば、「SaaS製品内のアイコン」の変更や追加といった小さな案件もあれば、「新しいSaaS機能」のインターフェース開発といった大きな案件もある。
ただ…、それ以外にも、セールスチームが書いた「導入事例記事」をWeb掲載するという案件が発生したり、さらにそれをチラシ制作するという案件が発生したりする。はたまた、マーケチームの「展示会」企画にあわせて、Webコンテンツを制作案件が発生したり、ポスター制作したり…。

つまるところ、全社から「手伝ってラブコールを受け続けるチーム」と言っても良い。

課題：受け身な案件の効率化

確かにデザインチームが愛されていることは事実だ。
しかし、直接部門である「製品開発部門」や「営業販売部門」が日ごろ主体的に動いているのと比べると、やっていることは地味と言わざるを得ない。たとえて言えば、小売店にある「ラッピングコーナー」みたいなものか？　日々、社内のアウトプットに対して「お化粧」をし続けるのだ。そして、気がつけば「受け身の姿勢」がしみついてしまう。

これがもし建築の世界であれば、、、むしろ「意匠系」が主体的に動き、エンジニア集団である「構造系」や「環境系」が受け身になるところなのに。。。と、ボヤいたところで「社内からのラブコール」が無くなる訳ではない。まずはこの「受け身仕事」を手際よくこなすことを考えたい。（経理担当だって、人事担当だって、情シス担当だって、、、「受け身仕事」を華麗にサバいているのだから…）

[デザイン依頼対応プロセス]

続きを読む »

業務：Web記事制作

記事の執筆ワークフローを変えた。（第571話：プロセス改善物語（Webメディア編１）、第572話：プロセス改善物語（Webメディア編２）、参照）

これで「記事」の品質を高めるとともに、「ライター」さん達のスキルアップにもつながるフローになった、、、様に思う。

いずれにせよ、『仮タイトルの設定』に始まり『Web記事の掲載』というアウトプットに至る一連の「記事制作フロー」がスムーズに回るようになった。「進捗を確認しに行く」や「レビューを督促しに行く」といった無駄なコミュニケーションも、すっかりなくなったといえる。

編集長：季節連載などの企画を立ち上げる
編集者：個別記事の仮タイトルを決める
ライター：記事を執筆する

編集長・編集者・ライターのそれぞれが、本来の役割に没頭できるようになったという表現の方が正しいのかも知れない。（もっとも、「手直し」や「教育的指導」が完全に無くなったワケではないが…）

課題：ネタ切れ問題

一方で、「記事制作フロー」へのインプットである『仮タイトル』について、その品質が議論されるようになった。

つまり、（これはオウンドメディアにとっての永遠の課題なのかも知れないが）、毎日の『仮タイトル』の設定にネタ切れ感が漂うケースがあるのだ。「似たような記事を最近書いたような…」「これは流石に誰も読まないんでわ…」など。

この際、記事のアイデア（仮タイトルの案）や連載企画のアイデアについて、社内から提案できるようにしたい。アイデアが沢山溜まっていれば、編集者や編集長の助けになるに違いない。そして『仮タイトル』の設定クオリティも高まるハズだ。

[記事アイデア受付プロセス]

続きを読む »

業務：校閲・校正

記事の校閲に「他のライター」も参加させる業務フローに変えた。（第571話：プロセス改善物語（Webメディア編１）、参照）

「誤字・脱字」や「名称まちがい・日付まちがい」といった『ミスの修正指摘』もさることながら、、、「起承転結についての意見」や「見出しやタイトルについての対案」といった『スキルアップにも通じるコメント』が、ライター同士で行われるようになった。

「編集者」は校閲やライター指導に費やしていた時間が減り、「新しい特集」について考えたり、「勉強会」を開催したりする時間が持てるようになった。

ちなみにその「勉強会」では、現実に発生した校正例が報告される。たとえば、「決済日」はお客さんが入金した日で「決裁日」は上司が判断した日ですねーとか、、、"過去" を償うことが「補償」で "未来" を約束することが「保証」で "砦" （障壁/障子）を築いて守り続けることが「保障」ですねー、国家や保険会社による安全保障・社会保障・生活保障といったケースでしか使われませんねー、、、といったディスカッションが行われている。地道なスキルアップこそ「生産性向上」だ。

課題：長時間の滞留

しかし「ライター」からすれば、他人記事の校閲という業務が増えたことよりも、差し戻し修正しなければならないタイミングも増えたことが問題だったりする。

特に新人ライターの場合、複数の記事が同時に『2x.記事修正』の工程に舞い戻ってくる、といったケースも発生してしまうようになった。そして、そういったケースには「他のライターが書いた記事を校閲する時間」が取れなくなるという事態になる。。。

うーむ、『3.一次校閲』には締切日時を設定し、その締切日時をもって強制的に次工程に進捗させる、、、つまり滞留を許さない、ようにした方が良いと思うに至った。

[記事の校閲フロー-打ち切り有り]

続きを読む »

業務：サイト記事の作成

いくつかのWebメディア発行会社では「記事の校閲」が実践されているようだ。

それは「医療サイト」や「ファッションサイト」といった商業ベースの『まとめ系サイト』（キュレーションサイト）に限らず、自社事業関連情報を発信する『オウンドメディア』でも、記事の「信頼性」高める努力が払われているらしい。

ウチでも、

「編集長」が季節連載などの企画を立ち上げ
「編集者」が個別記事の仮タイトルを決め、
「ライター」が記事を執筆し
「編集者」がチェックし、
「Webデザイナ」が記事や写真を掲載する

という流れ（ワークフロー）の中で「編集者」が「記事の校閲っぽいこと」をしてはいる。しかし「全ての発信情報に間違いはない」と断言できる体制ではない。

課題：一次草稿の品質

色々と議論はあったが、まずは「ライターさんのスキルアップ」を考えることにした。特に編集者から何度も「差し戻し」を食らっているライターさんを何とかしてあげたい。

スキルアップの方法はイロイロと考えられるが、ウチでは「ライター自身も他のライターが書いた記事を校閲する」という方針を立ててみた。やや荒療治ではあるが、「人の振り見て我が振り直せ」とでも言えば良いのだろうか、、、いずれにせよ、日ごろから他のライターが書いた記事を見ることで自分自身の反省すべき点に気づいてもらう、という作戦だ。

副次効果的そして中長期的に「編集者」が感じている校閲の負担感も下がると思う。

[記事の校閲フロー]

続きを読む »

業務：マルチタスク正社員への情報共有

「深夜のフロント業務」、「朝のチェックアウト対応」、そして「チェックアウトされた客室の清掃」。。。

ワークフローで社内情報を可視化することで、正社員が様々な業務を「掛け持ち」できるようになってきた（マルチタスクオペレーション）。すなわち、夜勤担当からチェックアウト担当に「宿泊客からクレーム苦情を頂いた」という情報が共有され、またチェックアウト担当から客室清掃担当に対して「宿泊客がチェックアウトした」という情報がスムーズに共有される。

結果、パートやアルバイトへの依存度が高かった「夜勤フロント」や「客室清掃」にも、かなり正社員が参加できるようになった。そして同時に、（想定外の展開として）、パートやアルバイトが「正社員として働ける道が開けてきた」という現象も現れてきた。

＜正社員の勤務シフト例＞

早番（7時間労働、8時間拘束）
遅番（7時間労働、8時間拘束）
夜勤（12時間労働、13時間拘束：2日勤務相当）

課題：なおも発生する手待ち時間

しかし、特に深夜時間帯においては、どうしても「手待ち時間」（てまちじかん）が発生する。

正社員が「夜勤」にも積極参加するなら、深夜帯においても「何か生産的な業務」を引き受けられるようにしたい。そこで、BPM コンサルタントとも相談し、今度は「スタッフブログの発信」に挑戦することにした。（期待する「マルチスキル度」高すぎ？、という不安もある）

ちなみに、ホテル館内の「見回り業務」をもっと念入りに行えばよい、という意見もあった。だが「不必要なまでの丁寧さ」を追及することは「生産性向上」とは言えない。すでに行われている「定時見回り」で、安全面は十分担保されていると思う。

[ブログ執筆投稿フロー]

続きを読む »

アナリティクスいわく「○×工務店さんが困ってマス!?」

前々回記事と前回記事では、「先週のWebアクセス動向」が社内通知される（ほぼ無人の）ワークフローを紹介しました。

この業務プロセスが運用されれば、社員は毎週月曜日の朝、「Google Analytics Reporting API」を通じて得られた最新情報について、メールで確認できるようになります。その結果、日々の「サポート業務」や「セールス業務」は、より効率良いものになるでしょう。

ただ、もう少し欲を言えば、「Analytics に無い情報」も併記しておいてもらいたいものです。つまり、

先週火曜日、プレスリリースを配信した
先週木曜日、ユーザ向けセミナーを実施した（○×工務店さんも居た！）

もしこういった Analytics に無い情報も併記されていれば、「流入の多いリンク元」や「特定の顧客が調べているページ」といった動向情報について、もっと深い理解・洞察が可能となるかも知れません。

カレンダー情報も API 取得

以下の業務プロセス定義は、社内カレンダー『広報予定およおび出展予定』（Google Calendar）に書き込まれているイベント（先週分）が、通知メールの文頭に付加される仕組みです。

これにより、通知メールを受ける社員達は、「Webアクセスに影響を及ぼしたかもしれない関連情報」についても、同時に確認することが可能となります。

[自社サイト運用状況報告プロセス３]

続きを読む »

人気ページのランキング

前回記事では、『Google Analytics Reporting API』との自動通信によって「週次レポート」が自動的に生成される方法を紹介しました。

ポイントは、

ディメンジョン： ga:hostname, ga:pagePath, ga:pageTitle
メトリックス(指標)： ga:pageviews, ga:sessions

というルールで集計データを自動取得する自動工程（サービス工程Addon）です。

この工程では「沢山アクセスを得たWebページのリスト」が複数行テキストとしてまとめられます。もし「フィルタ」に『ga:pagePath=~/blog/』の様な設定をすれば「blog フォルダ以下のWebページ」を対象としたランキングも自動的に取得することが可能です。

これらの文章が挿入された通知メールは、マーケティング・チームにとって非常に有用な情報となるでしょう。

他にも数万パターンの集計方法

しかし Google Analytics のデータは、もっと他の角度からも集計したい所です。

前回例では、上述の「3つのディメンジョン」と「2つのメトリックス」でランキング集計されましたが、Google Analytics には他にも約260のディメンジョンと約230のメトリックスが存在しています。つまり、組み合わせを変えることによって、多種多様な集計が可能となります。

たとえば、サイトコンテンツの視点（『行動(BEHAVIOR)』）だけでなく、『ユーザー(AUDIENCE)』や『集客(ACQUISITION)』の視点で集計すれば、「どんな人がアクセスしているのか？」や「どんなサイトから誘導されてきたのか？」といった情報も抽出できるハズです。

参考：ディメンジョン名とメトリックス名

[自社サイト運用状況報告プロセス２]

続きを読む »

分析ツールなのか、集計ツールなのか

Web 業界に関わる人であれば、誰でも『Google Analytics』の存在を知っています。

改めて説明するまでもありませんが、『Google Analytics』（グーグル・アナリティクス）とは、自社サイトのアクセス数や訪問者数などが分かるサービスで、「人気ページ」や「不人気ページ」を確認したり、「ネット広告の投資効果」を確認したりと、「その道の人」には無くてはならないツールとなっています。

しかし一方で、多くの人にとっては「多機能すぎるツール」とも言えます。

見たい情報を表示するための操作は、多機能であるが故に複雑な手順を踏むことになります。たとえば「社内週報」を作るために毎週『Google Analytics』にログインしているような方でも、ごく一部の機能しか使わないのが実情です。そこで、毎回の作業を効率化すべく『カスタムレポート』（ダッシュボード）や『カスタムアラート』（メール通知）を使っている人も少なくありません。

今週も集計値に異常なし！

以下の業務プロセス定義は、週次で行われる「自社サイト運用状況報告プロセス」です。

毎週月曜日の朝には、「Google Analytics の集計データがプリセットされた報告文草稿」が用意されます。したがって、マーケティング担当者は一言コメントを入力するだけで全社への報告を完了させることが可能です。特段の変化が発生していない限り『Google Analytics』にログインする必要がありません。

[自社サイト運用状況報告プロセス]

続きを読む »

「現場の業務プロセスが見えない」？

2016年秋、日本では『キュレーション・メディア』による「パクり行為」が大きく報道されている。

そもそも「情報を整理する行為」は価値のある作業であり、誰でも整理記事を投稿できる「情報共有サイト」（キュレーション・プラットフォーム）も価値ある存在と言える。しかし、サイト運営会社（東証一部上場企業）自身がクラウドソーシングを通じて記事を量産し、そのアウトソースの中で「パクり」をマニュアル化していた実態が明るみになったのだ。

キュレーション記事の制作プロセス

たしかに、

"当社は、この記事の情報及びこの情報を用いて行う利用者の判断について、正確性、完全性、有益性、特定目的への適合性、その他一切について責任を負うものではありません。"

という免責注記はあった。しかし、当のサイトが「健康や命に関わる記事」を集める情報共有サイトであったため、「著作権侵害」というよりもむしろ「モラル」が問われた形だ。そして、結果としてCEOが「記事制作のプロセスに問題がある」と謝罪する状況になったのだ。

◇DeNAプレス：CEOからのお詫びとご説明

"他サイトからの文言の転用を推奨していると捉えられかねない点がございました。この点について、私自身、モラルに反していないという考えを持つことができませんでした。（中略）。自分自身として心の底から自信の持てるプロセスを構築していくことを約束します。"

真実かどうかは知る由もないが、おそらくは「本当に業務プロセスが見えていなかった」のだろう。（と信じたい）。では、運営会社が責任をもって記事を書く必要がある場合、どのような業務プロセスを構築すれば良かったのだろうか？

[記事作成プロセス]

続きを読む »

「翻訳した文章、チーム内で共有したいな」

たしかに「メール共有」も悪くない。翻訳作業の完了と同時に、自動的にチームML（メーリングリスト）に送信される設定にしておけば、素早く翻訳文をチーム共有できるだろう。誤訳やブラッシュアップについてのフィードバックを得られる可能性もある。

しかし、受信した人が「指摘したい」と思った時に「メールでの返信」になってしまうのは、うれしくない。今どき、社内の情報交換は「社内SNS」がメインだ。

以下のワークフロー定義では、翻訳作業完了と同時に、社内SNSである［オープンチャット］に自動投稿される仕組みとなっている。クオリティの高い翻訳文に、素早く「いいね」することも可能となる。

[翻訳プロセス-OpenChat投稿]

続きを読む »

多言語で説明されている取扱説明文
Webサイトの原稿（HTML）
ソースコード

そんな原稿制作フローであれば、（「文字数」だけでなく）、「ハッシュ値」も自動記録される仕組みにしておきたい。

ハッシュ値とは、データに対する「要約文字列」（メッセージダイジェスト）だ。「指紋」（フィンガープリント）と呼ばれることもある。要するに、どんなデータからでも瞬時に「32個の16進数文字」（MD5方式の場合）が出力でき、１文字のデータ改竄ですら簡単に検証できるようになる。（詳しくは Wikipedia あたりを参考にしていただきたい）

以下のワークフローでは「ハッシュ値取得（MD5）」および「ハッシュ値取得（SHA256）」という［自動工程］（サービスタスク）が使われている。どちらも［アドオンXML］によって機能拡張しておけば利用可能だ。（Questetra BPM Suite v11.1, 2016年9月初旬リリース？）

[翻訳プロセス-ハッシュ値]

続きを読む »

この業務に必要な自動工程アイコン、、、欲しー！

業務プロセスを設計（モデリング）していると、さまざま処理を「自動化」したくなるものだ。

2016年8月末にもリリースされるクラウド型ワークフロー『Questetra BPM Suite』（v11.1）では、自動工程アイコンを追加で利用できるようになる。具体的には、パッケージ化された［アドオンXML］を入手し、機能追加ファイル（プロセスモデルファイル）としてインポートすることで、オリジナルの自動工程アイコンが利用できるようになる仕組みだ。

その［アドオンXML］は、多くの場合、

Questetra社のサイトからダウンロードする
サードパーティ各社から提供を受ける

と言った形で入手するだろう。しかし［アドオンXML］と言う表現からも容易に想像できるように「自作」する事も可能となっている。

以下のワークフローは、前回記事で紹介した『翻訳プロセス』にある［スクリプト工程］を、自作の［自動工程］に置き換えたものだ。

[翻訳プロセス-アドオン]

続きを読む »

A. 翻訳前の原稿
B. 翻訳後の原稿

それらの「文字数」を自動的に記録しておきたい。

たしかに「人間が文字数をカウントしなければならない」なら絶対ヤラナイ作業だが、「ワークフローシステムが自動的に数えてくれる」なら記録として残しておこうと思う。。。

クラウド型ワークフロー『Questetra BPM Suite』の場合、以下に列挙したような自動処理であれば、自動工程アイコンが予め組み込まれているので、簡単に業務プロセスに追加することができる。

文字列Aと文字列Bを結合する（M227）
数値Aと数値Bを足す（M227）
文字列を台紙 PDF に挿入された PDF を生成する（M228）
ファイルを Google Drive に保存する（M229）

しかし、この「文字数を数える」の例の様な作業を自動化するには、［スクリプト工程］（スクリプトタスク）（M230）と呼ばれる万能型の自動工程を配置し、そのプロパティとしてのスクリプト（ECMA-Script/JavaScript）をセットする必要があった。（Ver. 11.0 時点）

[翻訳プロセス]

続きを読む »

特定の「業務データ」を加工したい。
特定の「業務データ」のデータ型を変換したい。
特定の「業務データ」のプロパティとしての文字数を取得したい。

基本的な話として、「ワークフローシステム」は業務データの「受け渡し」を自動化する。ただ「受け渡し」だけでなく、「作業そのもの」についても出来る範囲で自動化（無人化）したいものだ。特に「機械的な作業」であれば尚更。。。

クラウド型ワークフロー『Questetra BPM Suite』の場合、

文字列Aと文字列Bを結合する（M227）
数値Aと数値Bを足す（M227）
文字列を台紙 PDF に挿入された PDF を生成する（M228）
ファイルを Google Drive に保存する（M229）

と言った作業であれば、最初から組み込まれている自動工程でサーバサイド処理させることができる。しかし、少しでも「オリジナリティが高い作業」となれば、そうも行かない。

たとえば、以下のワークフローにある『文字数カウンタ』は、上流工程で入力された文字列型データＸについて、（サーバサイドにて）、その文字数を数え、数値型データＹに格納させる自動工程だ。こういった場合には［スクリプト工程］（スクリプトタスク）（M230）と呼ばれる万能工程を配置し、スクリプト（ECMA-Script/JavaScript）をセットする必要がある。（Ver. 11.0 時点では…）

[文字数カウンタ]

続きを読む »

日常業務は「共有パスワード」だらけ。。。

ルータを置けば「管理者パスワード」を設定する。ネットプリントに申し込めば「法人アカウント」を登録する。スキャナを買っただけでも「ユーザ登録」が必要となる。幼い日から「絶対にパスワードは他人に教えてはなりません」と教わって大人になったのに、、、現実の大人の世界には「組織内で共有（共用）せざるをえないパスワード」が沢山あるじゃないか！！　（そして会社のファイルサーバには、門外不出の秘密ファイルが。。。）

以下のワークフローは「共有パスワード」を管理する業務プロセスだ。

組織用の「パスワードマネージャ」と言っても良い。社員からのリクエストがあった際、その10分後にパスワードが自動開示される仕組みだ。誰が・いつ・どのパスワードを利用したか、すべて自動的に記録されるようになる。（加えて管理者側の「パスワード変更」も記録されるようになる）

[共有パスワード問合]

続きを読む »

「イラスト」や「4コマ漫画」を多用したい。

たとえば、ホームページ・チラシ・提案書などにイラストやマンガを活用すれば、直観的に情報を伝えることができるようになるだろう。時には「1枚のイラスト」が「100行の文章」よりも多くの情報を伝えるケースすらある。（百聞は一見に如かず？）。事実、「コミュニケーション・ロス」を減らすイラストやマンガは、ビジネスにおいても会社案内資料や会社ホームページなど幅広く活用されるようになった。（特に世界中にマンガ文化を発信している日本には、マンガ人材が豊富だ。）

マンガ制作の受託を行う会社や個人事業主に依頼するケースもあれば、マーケティング部門で直接雇用して、「イラスト」や「4コマ漫画」を制作するケースもある。（テレワークとも相性が良い業務といえる）。

もし、マンガ制作担当者を社内で雇用しているのなら、是非とも業務プロセスを標準化したい。

以下のワークフローは、マンガ制作フローだ。

標準プロセスに従って成果物を記録すれば、（つまり「メール」でのやり取りを控えれば）、組織として納期遅れを未然に防ぐことができ、またチームとして過去データを活用できるようになるだろう。「原作シナリオ」さえキッチリと供給できるようになれば、制作工程自体は１ページ１～２万円程度のコスト感で量産することも可能になる。（もちろんクオリティ／気合の入れ方によって大きく左右されるが）

※もちろんマンガ以外の様々な制作系フローにも転用できる

[マンガ制作フロー]

続きを読む »

マニュアル、プレスリリース、Webサイト。。。

翻訳仕事は様々な部署で発生する。確かに "一般的な翻訳" なら Out-sourcing や Crowd-sourcing も選択肢に入るが、"専門用語バリバリ" の文章は内製すべきと言える。（もしくは特定の翻訳依頼先に絞るべきと言える）

以下はシンプルな翻訳業務だ。

特筆すべきは、翻訳されるべき文章が "2段組み表示" の左側に表示され、翻訳文を右側の入力フォームに書きこめる点だ。特に短い原稿なら、Webブラウザだけで素早く処理できる。（ブラウザのスペルチェッカ―機能拡張も有用！）

また "いつ/誰が" といった基本的なワークフロー情報以外に、"作業量" (翻訳文の文字数)を自動計測している所も、非常に秀逸といえる。

[翻訳フロー]

続きを読む »

2014年も残すところ、あと数日。。。

今年も読者の皆さんに支えられ、何とか「毎週投稿」を実現する事ができました。このエントリーで2014年の52本目、通算で411本目（※）の業務プロセス提案になります。 Wokflow Sample 読者の皆様、、、特に「××なプロセスを書いてみて」とリクエストを下さった皆様(!)に、、、また投稿に対して「とっても参考になった」などのコメントや感想を下さった皆様(!!)に、この場を借りて御礼申し上げマス。

※ 2014年＝51本、2013年＝52本、2012年＝53本、2011年＝186本、2010年＝68本
※ 各記事に添付の業務サンプル [QAR] は１つ２つ、と言うコトで通算のサンプル数は約700本位になっています？？

振り返れば、、、特に当ブログの開設当初は、内外から「3日坊主」がウワサされていたモノです。まぁ確かに、中には大したことない業務プロセス提案も混ざってはいるのですが、、、いや、これからも、細く(?)、永く(!)、シブトく(!?!)、続けていこうと思っております。今後とも「叱咤激励」および「忌憚のないフィードバック」につき、宜しくお願いします。

◆2014年に、最も読まれた日本語記事

◆2014年に、最も読まれた英語記事（に対応する日本語記事）

Improving Your Accounts Payable Process in Steps (2011-05-13)

（買掛金プロセスを少しずつ改善する）

Reporting Each Client Visit Right After Returning to the Office (2011-02-15)

（往訪直後に「１件ずつ」の往訪報告フロー）

Visualization of Testing Process in Software Development (2010-12-20)

（ソフトウェア開発におけるテストフローを可視化する）

Workflow Across The Enterprise, From Quotation To Payment Confirmation (2011-06-05)

（企業をまたぐワークフロー、見積から入金確認まで）

Is Complaint Management Perfect for Training New Employees? (2011-04-01)

（クレーム対応は新人育成に最適？）

さて、、、
以下2014年最後のエントリーは、非常にシンプルな「Blog エントリー業務フロー」の御紹介です。

[Blog エントリ業務]

続きを読む »

登録: 投稿 ( Atom )