ワークフローシステムの類型
前回、「ワークフローシステム導入のメリット」として、弊社における導入前の姿（個人的思い出中心）と導入後の姿を対比させた形で、その有用性について紹介させていただきました。
今回は「ワークフローシステムの類型」について書かせていただきます。
・ワークフローシステムの類型（俺流）
一般的にワークフローと聞いてイメージが湧きやすい業務としては、「経費精算」「見積承認」「社内稟議」などが挙げられると思います。
何かしら販売している部門・部署がある規模の会社組織ですと、上記3つのワークフローは業務として存在していると思います。
「ワークフローといえば日報管理だろ、いい加減にしろ」という方もいらっしゃると思いますが、ワークフローの類型を考えるときにわかりやすい例ですのでそういうことにしておいて頂けると幸甚です。
また、はじめにお断りしておきますが、以下で定義する類型とその名前については全部「俺流」です。もっとバッチリなネーミングをして頂ける方、別の類型で考えている方などいらっしゃいましたら、是非コメントをお願いします。
■経費精算 →特定業務特化型
経費精算に関するソリューションは実にいろいろリリースされていますが、その特徴は名前の通り、経費精算に特化した機能をもっていることです。
特化した機能とはすなわち、その業務フロー用の便利機能です。
経費精算システムであれば
・申請者側が絶対欲しい機能として「路線検索からの運賃参照と登録」
・処理をする経理側で欲しい機能として「会計システム用連携データ作成」
がそれにあたります。
最近ではカードリーダーを使って交通系ICの蓄積情報を読み取ったりする機能もあったりします。尚、カード側のデータ明細数のストック制限があったりするのでズボラな人には向かなかったりします。
このような一芸を突き詰めたものを、自分は「特定業務特化型」のワークフローシステムと定義しています。
解決課題が「交通費の精算が面倒くさいので何とかしたい」とかの場合、最も効果を発揮するシステムです。
■見積承認 →別システムの一部機能型
見積承認をもらった後、全然違う金額で売上（主に下方修正）を計上して上司に怒られたことのある人、いませんか？
見積承認というワークフローは、業務としてそれ単体では完結しません。
失注・受注の判断があり、目出度く受注した場合、納品→売上→請求→回収というところまでその内容は（普通なら）転用されます。
販売管理業務のライフサイクル中でデータの整合性をとりつつ、入力負荷を低減するため安いパッケージソフトでも大体ついているのが見積の機能です。
また、見積は日報系のシステムとの組み合わせで「見込あるある詐欺」が起きないようにリードの段階で管理される場合もあります。
このように、単体では完結しない＆前後のデータに整合性が求められる別システムの一部の機能としてワークフローが実装されているものを、自分は「別システムの一部機能型」のワークフローシステムと定義しています。（「そのまんまじゃねぇか」という突っ込みはなしで。）
見積管理機能は販売管理パッケージには大体ついていますが会社なりの独自項目・要件により改修を行う場合、見積の後に続く処理すべてを改修しなければならなくなる場合が多く、泣く泣く断念するケースがあります。
また、見積データ自体は月次決算などの処理に基本的に無関係なデータになるため、適当に入力して放置しても処理上問題なかったりします。そのため、ゴミデータが増えがちで、このような状況についてシステム管理を行う側としては、「いまいちスッキリせず気持ち悪い」と思ったりします。
運用にもよりますが、上記のような理由から販売管理など他の種類のシステムを選定する際に「うまくフィットして使えたらラッキー」という位置づけです。
■社内稟議 →汎用型
ところで、「稟議」の読み方について、慣用読みとしては「りんぎ」ですが正式な読み方は「ひんぎ」であることはあまり知られていません。斯様な知識を持たない状態で「ひんぎしょ」と正しく発音されている方に出会った場合、文脈から「稟議書」であることは類推できると思いますが、気になってしまい話が全く入ってこない事態に陥るところでしたね。いやぁ、教えることができて良かったです。
社内稟議など、なにかしら会社なりの独自性やこだわりがあるワークフローに用いられるのが前回記事で紹介したシステムです。
特徴を表すと「フォーム／項目／承認ルートを自由にレイアウトできて多種多様な要件をそれひとつで実現できる」というものになります。自分は「汎用型」と定義しています。
汎用=無難、という意味合いで特化型と区別しています。
製品・サービスによっては年々、接続可能なインターフェースやアドインが増加するものなので、欲しいサービスとのつなぎを実装することで「無難に」を排して全部のせ的なものを作ることも可能になっていたりします。そのため、要件範囲を自社でメンテできる場合、「もう、こいつだけでいいんじゃないか」となる可能性があるシステムです。
・で、どの型を選べばいいのか
「別システムの一部機能型」については、文字通り「ついている機能」なので、検討対象がそもそも本体側のシステムになります。随伴物目当てでシステムを導入する方はいないと思いますので、こちらは一旦置いておきます。
そうなると、特定業務特化型vs汎用型の構図になります。
前述の通り特定業務特化型のカバー範囲のみが要求機能となる場合には、特定業務特化型を選択するのがベターです。
いろんなワークフローを実現したい状況でも、要求機能がすべて明らかな場合にどうするか？このあたりから少し選定に悩みはじめます。
特定業務特化型をそれぞれ探して導入するか、汎用ワークフローを利用して自分で開発するか。こちらの判断にあたる評価軸として、自分は「関連機能の充実度による使いやすさvs操作体系の統一による使いやすさ」を置いて評価します。必然、実現したいワークフローの数が多くなると操作体系の統一メリットが出てきやすくなります。システム管理部門側ではメンテナンススキルの習得がひとつで済むというメリットがありますが、結構大事なポイントだと思っています。
なぜかというと
●スキル習得が容易になることで、複数の対応要員を用意することが簡単になる
↓
●社内サポート体制が充実する
↓
●質問がしやすくなるのでユーザーが結果的に使いやすくなる
という非機能的メリットが得られやすくなるからです。
特定業務特化型の中には、シンプルな汎用ワークフローが作れるものも結構あります。
「じゃあ、特定業務特化型でよくね？」と思う方、いらっしゃると思います。
これについては、会社ごとにハマる場合とハマらない場合があります。
この件については別の論点があり、長くなりそうなので次回へ続く。。。ということで。
長文閲覧お疲れ様でした！
●前回の記事
●次回の記事
三ッ輪ホールディングス株式会社 社長室 マスダ
2001年に三ッ輪産業入社。
現場での事務／営業を経て、LPガス定期保安点検システム／サービス開発を契機に情報システム部に転属。
社内基幹系システムのオープン化、BIツール・グループウェア・ワークフローシステム・SFA・GIS・電気事業者向けCIS他新規システム導入案件を主導。
現在、三ッ輪ホールディングス社長室所属。システム運用に片足を入れながらIT／非IT両面について社内意思決定をサポート。