プログラマの思索

Redmineを事務処理の申請承認ワークフローに使えるか、考えたことをラフなメモ書き。

【参考】
RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索

【1】事務処理の申請承認ワークフローは簡単な仕組みなのだから、Redmineのワークフロー管理機能とチケット管理機能でほとんど実現できるのではないか、と思ってしまいがちだ。
実際、つい10年くらい前までは、LotusNotesで簡易なワークフロー管理は実現できていた。

例えば、見積書の作成・承認、旅費申請、事務用品の購買申請、他部署への作業依頼などがあるだろう。
しかし、業務を詳細にヒヤリングして分析してみると、意外に複雑だったりする。
特に、古い大企業や古いメーカーほど、縦に長い組織階層とサイロ型組織、昔ながらの業務に引きずられて、申請承認フローがものすごく複雑になりがちだ。

特に、組織構成がしっかりしすぎている大企業ほど、部署間の連携が難しいので、申請承認フローが必要になってくる。

旅費・経費・事務の申請承認フローを対象に、Redmineの機能にどれだけフィットできるか、フィットギャップ分析をしてみる。
以下は、思いついた評価項目を並べただけ。

【2】申請書

【2-1】普通は、業務で使う帳票を元に、チケットの項目に当てはめれば良い。
出張旅費精算書、経理申請書、見積書の申請書など、既にExcelの帳票を元に、データモデリングの技法を使って洗い出せば良い。
おそらく殆どの項目は、Redmineのカスタムフィールドで実現できるだろう。

【2-2】但し、例外の仕様もある。
ある欄は、申請者は記入できず、総務部や経理部が記入できる仕様にする、など、ステータスやロールによって、項目の表示・更新制御が必要な場合がある。
特に、お金に関する承認欄は、経理部長や総務部長が最終承認ないしコメントが必須だから、改ざんされてはいけない。

Redmineでは、ワークフロー設定画面で、チケットの各項目をロールごとに必須入力・ReadOnlyなどに設定できる。
また、「チケット作成者に追加で許可する遷移」「チケット担当者に追加で許可する遷移」など、チケットの作成者や担当者ごとにステータスの遷移を分ける機能もある。

この仕様はRedmineでカバーできるだろう。

【3】ワークフロー

申請承認の単純なワークフローならば、Redmineのワークフロー機能で十分だろう。
しかし、市販のワークフロー製品のように、複雑なワークフロー機能はRedmineでは実現できない。
例えば、下記のような機能があるが、Redmineで実現するのはカスタマイズが必要になるだろう。

1)ビジネスルールによる分岐
出張旅費精算や経費申請では、3万円以上は課長決裁、20万円以上は部長決裁などのルールがある。
つまり、申請金額というカスタムフィールドの値に応じて、承認ルートが課長や部長に増える仕様が必要。

Redmineのワークフロー機能にはそんな機能がないので、分岐が発生するパターン分のワークフローを作らなければならない。

2)根回し

申請・処理した案件の情報を、申請者・処理者が任意のユーザに通知する機能。
普通は、申請に対し、承認者全員が承認しなければ通過できない制約条件を課す。
よくある例は、ある予算稟議は、すべての部門の部長の承認が必須、みたいな例。

3)投票

申請に対し、複数の承認者のうち、ある一定数以上が承認したら、フローを通過する制約。
事例が思いつかないけれど、こういう機能が欲しい会社もあるみたい。

4)相談

承認者が承認する前に、別のユーザに申請チケットの情報提供やアドバイスを求めて、コメントさせる機能。
普通は、相談している行為自体は、他の人から見られないようにする機能になっている。

この機能は、ある特定のユーザグループだけがRedmineのプライベートチケットでやり取りできるようにして、申請チケットに関連づければいいだろう。

Redmineに関する課題と展望: プログラマの思索

5)代理申請・代理承認

例えば、長期出張で不在の課長の代わりに、部長や別の課長が代理承認する。
あるいは、客先に長期駐在の社員に対し、課長が代わりに申請する。

Redmineには代行ログインの機能がないので無理だろう。

6)一括申請・一括承認

複数の案件を一括で申請したり、一括承認する機能。
例えば、経理部長が月末に、複数の部署の社員の出張旅費を一括承認して精算する場合があるだろう。
すると、大企業の経理部では、数件レベルではなく、数十件、数百件を一括で承認処理したいケースが出てくる。

Redmineでは、チケット一覧で右クリックすれば、ステータスを一括変更できる機能があるので代用できるだろう。

7)動的承認

「動的承認」とは、申請(処理開始)後に、特定のフロー上の処理対象者の追加、もしくは削除などを設定することができる機能。
つまり、申請した後で、承認者を動的に追加・削除出来る機能。
大企業では、動的承認を使いたい状況もあるらしい。

【3-1】但し、Redmineのワークフローに分岐やロジックを追加するプラグインredmine_custom_workflowsを使えば、上記の機能はほぼ実現可能だろう。
たとえば、稟議申請の金額によって、承認者を部長と社長で分ける、といったロジックは上記プラグインで簡単に実現できるだろう。

Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索

anteo/redmine_custom_workflows: Allows to create custom workflows for Redmine

【追記】
管理者が他人に成りすますことができるプラグインがあったので、代行ログインも実現可能かな。

alpcrimea/redmine-spectator-plugin: Redmine plugin to change user after login

【4】メール通知

申請や承認行為をしたら、関係者にメールで通知する。
さらに、できれば、督促メールも出す機能も欲しい。

Redmineでは、チケット更新のイベントで通知メールを出せる。
また、rakeコマンドでリマインダーメールを送信する機能があるので、例えば、期日3日前とか、期日遅れのチケットがあればリマインダーメールを自動送信すればいいだろう。

RedmineReminderEmails - Redmine

【5】集計

申請状況や承認状況を日次・月次・部署別などで色々集計したい。
例えば、旅費の精算が多い部署、経費の無駄が多い部署などを特定して、経理部が把握したい。
あるいは、部署ごとの申請状況に応じて、ワークフローシステムの運用保守費用を部署ごとに分担する場合もあるので、集計結果は費用負担に直結する場合もある。

Redmineでは、チケット集計機能はいくらでも追加できるし、簡単にカスタマイズできる。
但し、リアルタイムな集計に過ぎないので、バッチ処理を組んで、日次・月次で集計結果を保持する仕組みを作った方がいいだろう。
その場合、MySQLのテーブルに直接アクセスする方法が取られるだろう。

【6】認証

普通の大企業では、シングルサインオンや外部認証の仕組みがあるので、それを流用したい。
IDやPWを一元管理したい動機がある。

RedmineにはLDAP認証やOpenID認証の機能があるらしいので、多分実現できるはず。

LDAP認証 ? Redmine Guide 日本語訳

RedmineでOpenID連携: プログラマの思索

【追記】
Redmineのユーザマスタを既に運用中で、その後でLDAPへ移行する場合の事例があった。
参考になる。

[ REDMINE ] 運用中の Redmine のユーザアカウントを Active Directoryと認証連携する | LEAP ARROWS | Developer Blog

【7】マスタ登録

ワークフローシステムを動かすには、ユーザマスタや組織マスタなど各種マスタを事前登録しなければ使えない。
普通は、インポート・エクスポートする機能を持っている。

Redmineの場合、ユーザ一括登録のプラグインはVer3.0で下記が対応しているらしい。

shrkw/redmine_user_import

チケットの一括登録は、下記のプラグインがある。

zh/redmine_importer

Redmineチケット★一括★の詳細情報 : Vector ソフトを探す！

RedmineはREST APIがあり、かなり使える品質なので、マスタ登録に使ったほうが良いだろうと思う。

【8】組織階層

大企業になるほど、ピラミッド型の組織階層を持ち、申請承認ルートが複雑になる。
申請書の金額が高いほど、部長決裁や社長決裁の案件も増えてくる。

組織階層の仕様では、いくつか気を付けるべきポイントがある。

一つは、組織変更の履歴を保持する仕組みがあった方が良い。
なぜなら、社長の思いつきで組織変更は頻繁に発生するため、組織変更の履歴や組織変更適用日などを持たないと、毎回組織マスタを洗い替えするリリース作業が発生してしまう。
マスタ洗い替えは、結構危険な作業だし、リリース作業中は業務を止めてしまうから影響が大きい。

2つ目は、組織階層は一つではなく、複数の非公式な階層構造があったり、正式ではないローカルな階層構造があったりする。
例えば、プロジェクト型の案件では、正式な部署の承認ルートを使わず、そのプロジェクト内の承認ルートを使う場合がある。

あるいは、地方の営業所では、部長以上がいないために内部で承認決裁できるように特別にローカルなルールを作っている場合がある。
あるいは、工場では、工場内の特定の業務やプロジェクト型の業務に対し、正式な組織階層ではなく、有識者による申請承認フローを使ったりしている。

Redmineには組織階層の概念がない。
敢えて言えば、ユーザに対し、カスタムフィールドで組織のロールを割り当てる事は可能。
しかし、本来の組織階層の仕様は実現できない。

【9】ロール

Redmineでは、ロールはいくらでも作れるので、ある程度は対応できる。
しかし、いくつかの仕様はRedmineでは実現できていない。

一つ目は、ある職務を兼務している人の考慮があるか否か。
例えば、新規事業の部署では、他の部署の部長が兼務したりする。
すると、同一の人が複数の役職を持つので、そういうワークフローの仕組みを実装できるか？
2つ目は、代理申請や代理承認。

【10】アーカイブ

出張旅費精算や経費申請は、大企業になると年間数十万件、数百万件までトランザクション量が発生する。
昨今は、海外の工場への出張なども多い。
すると、不要な申請データはアーカイブして、性能を落とさない仕掛けが必要になってくる。

普通のワークフローシステムでは、1年経った申請データは参照用スキーマへアーカイブしてデータ量を減らす。
あるいは、8年以上経った申請データは物理削除する機能もあったりする。

Redmineでは、不要なプロジェクトは、物理削除したり、書庫へアーカイブする機能もある。
あるいは、更新しないと判明したチケットは、参照用プロジェクトへ移動し、プロジェクト内の全文検索の性能を確保する運用もあるだろう。

【11】検索

ワークフローシステムでは、申請書の全文検索が結構重要。
しかし、年間数十万件、数百万件も申請データが発生すると、当然検索は遅くなる。

Redmineでは、全文検索はチケットが20万件までは問題なし。
それ以上は何らかの対策が必要。
@akahane92さんの資料が全て。

【12】帳票・CSV出力

日本企業は帳票にこだわる。
PDFのレイアウトや文字列が少しでも狂っていると、すぐに指摘が入る。

RedmineのPDF出力は、@naitohさんのおかげでほぼ問題ない品質になった。
チケット出力、チケット一覧の出力も問題ない。

ワークフローシステムの帳票出力で気になる機能は、電子承認だろう。
今までは、いくらワークフローシステムを使っていても、紙で印刷して、部長の押印が必要だった。
でも、電子印鑑でペーパーレス化するのが最近の流行。

【13】IT内部統制(J-SOX)

ワークフローシステムのデータは、普通はIT内部統制の対象になるだろう。
会計監査やシステム監査の対象になるから。
つまり、ワークフローシステムにあるデータは勝手に改ざんしてはいけないし、セキュリティも厳しく運用する必要がある。
Redmineに内部統制を適用した事例は@akahane92さんの資料がすごく参考になる。

RedmineはITソリューションの一つ～情報システム部門のタスク管理とIT全般統制 #RxTstudy: プログラマの思索

【14】まとめ
以上をまとめると、Redmineである程度はワークフローシステムを構築できる。
しかし、複雑な業務には対応しづらい。

でも、幸いな事に、RedmineはREST APIなどの外部接続のI/Fの品質がよく、DBの構造も綺麗なので、機能拡張のカスタマイズはさほど難しくないだろうと推測する。
Redmineを事務処理の申請承認ワークフローシステムとしてパッケージ製品として売り出す会社も出てくるかもしれない。