その業務フロー本当に必要ですか？
と、セミナー講師やコンサルにキラキラした目で語りかけられても、どうも気分がスッキリしない。
「すべての業務ツールをServiceNowに集約すれば、データが集まり業務フローは標準化され、コスト削減とシステム改善のスピードアップに繋がる」もちろん言ってる事は分かる。そりゃそうだ、けど・・・そんな皆さんこんにちは。
※この記事はNTTコムウェア Advent Calendar 2022 16日目の記事です。
https://qiita.com/advent-calendar/2022/nttcomware
NTTコムウェアのKoDAMAと申します、上から下まで色々やってきたThe SIerです。（以下SIerポエム度が高いので実装の方法関係はQiitaに集う先駆者の知恵を借りたりTokyoやUtahで差分にぶつかってから考えてください）
ここではグローバルなシステムが（受け止めやすい）分かりやすい業務フローについて考えます。
さぁ、僕ら担当者級はまずは足元から固めていきましょう。
ServiceNowの日本版TOPページにも書いてある通り、これは業務フローが大事なシステムです。（※ワークフローとフローはServiceNow上で違う話とか、色々ややこしい話とは別に、業務フローの話です）
素晴らしいエクスペリエンスの背後には、優れたワークフローがあります。すべてのワークフローの礎となる Now Platform® は、企業全体の人、機能、システムを結びつけます。
https://www.servicenow.com/jp/
前提として私はSaaSや業務標準化が好きです、それが成立すれば、理想論としてはお金的にも時間的にも無駄から開放されると信じています。
さて本題です。システム側にとって分かりやすい業務フローとは？その導入のためには何が必要でしょうか？
今日のテーマ
1. 分かりやすい業務フローに変えるのは誰？
2. 分かりやすい業務フローの為にあるライセンス形態
3. 分かりやすい業務フローがOOTBとは限らない
１．業務フローを変えられる人
経理？人事？問合せ管理？全ての既存業務に一番最適なのは大小不満はあれども既存システムです。担当者がその業務を遂行する上で、力技運用を含め何とかなるようには出来ています。ServiceNowの導入を検討するような会社であれば尚更そうでしょう。そして、世の中の既存の業務システムは大きく分けてこの2つと言われがちです。(あくまで私見です)
- 長らく都度最適の増築を繰り返して巨大化したハ○ルの動く城のようなシステム
- "スーパーマクロのエクセル"or "長年のノウハウで繁忙期さえも対応可能な代えの効かない担当者"が、システム外で何とかしてるシステム
どちらにも未来はありません、変革が必要です。しかし業務は回っています。
ここで大事なのは、錦の御旗を明らかにして、既存"現場から変革への支援"を得る事です。何が錦の御旗なのかは多くの人が胸に手を当てればそこに答えが絶対にあります。
回っている業務を変えるための手間、これを前向きに対応して貰うには、その人にとっても上司にとっても拠り所となる錦の御旗が大切です。それができれば”システムが分かりやすい業務フロー”導入への最初の大きな一歩が進みます。
※現場が全員泣きながら導入する、現場の支援を得られない”新システム”は遅かれ早かれ破綻するでしょう。
つまり、システムが分かりやすい業務フローとは、その開発導入を共に乗り越える業務実施者の仲間、業務フローを変えられる人がそばに居てこそ見えるものです。赤木キャプテン1人と小暮君だけじゃチームも実力を発揮できません（THE FIRST SLAM DUNKを先日見ました）
２．ライセンス形態が後押ししてくれる
ServiceNowのライセンス費用についてカスタム見積もりでケースバイケース以上の詳しい情報があまりインターネットで見かけません（私のググり方が下手じゃない限り）。
しかし、どんなライセンス契約にするにしても、ServiceNow App Engineを用いるのであれば、基本はリクエスター（Requester）が沢山いて、承認者や全てを司る（Fulfiller）権限があり、誰もが何もかもできる権限を乱用してライセンス契約するにはそれなりの費用がかかると思われます。（解釈が違っていたらServiceNowさんすみません…！それは本来の使い方じゃないと理解してます）
日本でも同一労働同一賃金の話がありますが、グローバルなSaaSの権限管理や、それに伴うライセンス形態はそうしたスパッとした制度に基づいています。古き良き日本にある、組織によって役職の権限が違ったり、人に紐づいて続く承認ルールなんて考慮されません。
特異な権限（ロール）を考慮すればするほど、誰でも何でもできるほどシステムはややこしくなります、これはServiceNowに限った話ではありません。
その場合どうすればいいか？ServiceNow導入を契機にシンプルにするしかないのです、タフな交渉になるかもしれません。ITIL準拠が何なのか詳しくは分からないかもしれません。しかし、このライセンス形態を利用して、積み重ねられた複雑な権限管理をできる限り取っ払っていきましょう！
その先には確実に"システムが分かりやすい業務フロー"が待っています。
３．シンプルにOOTBで使えば、業務フローが分かりやすくなるとは限らない
「Out-of-the-Box（箱から出したままの状態）」通称OOTBがグローバルなSaaSを使うにあたっての理想とされています。
特にやろうとすれば、カスタマイズとjavaの力で何でもできるはできるServiceNowにおいては、年2回のメジャーVerUPへの追随が必要な点もふまえて、既存システムに近づけるためにあれこれ実装し過ぎないのが重要と言われています。
例えば、最も分かりやすいのは 「例外パターンや準正常パターンをあれこれ実装しない」 ことです。ServiceNowのローコード開発であれ分岐を多くすればUI上に大量の分岐が見えるだけです。
正常パターンの処理とそのデータの蓄積と活用、業務フローの標準化に尽力し、それ以外は記事欄運用なり人手なりにする整理も大切です。今後の維持運用や追加開発のスピード感と費用のためにも、最小限のカスタマイズに収めておくことが大事です。
しかしそんな綺麗事だけでは業務は回りません！ （飛び交う現場からの拍手喝采）!!
OOTBじゃないところがあってもいいんです！全てがシンプルである必要はありません、だってシステムですから。全てをシンプルにしようとすると、システムなのに仕事が増えたり、簡単そうな処理が螺旋階段のように続く逆にややこしい何かが生まれてしまいます。SaaSだからOOTBだ！と肩肘張らない事も大切です。複雑な処理ではOOTBを捨てる。但し、カスタマイズはできる限りそこに集中させる、そうでないところではできる限りOOTBで頑張る。頑張るところと頑張らないところにメリハリをつけましょう。
その先には確実に"システムが分かりやすい業務フロー"が待っています。
（ちなみに、ServiceNowは既存業務にありがちな、RDBにSQLでデータ抽出したファイルで運用を回す、というあるあるの業務と徒手空拳の状況では相性が必ずしも良くはない点には注意ください。参照、ビュー、性能、などなど工夫が必要なので事前検討が必要です。例えば↓
弊社2021年アドカレより、Service NowのAPIからデータ抽出した話）
システムが分かりやすい業務フローの答え
"システムが分かりやすい業務フロー"の答えを全く書かずにここまできてしまいました、申し訳ありません。
そして重ねてお詫びです、その万能な答えはここにはありません。
既存システムの利用者が味方となり、ライセンス形態の効率的な活用を考慮し、OOTBにできるだけ近いアプリを作ろうとしてる、そんな開発者の頭の中には、実はその答えがおぼろげにでも見えているはずです。
煙に巻くような結びでごめんなさい。ただ少なくとも上記１，２，３を実際に行えば、ServiceNowの導入の成功に近づくはずです。
あるいは、きっとどこかにあるだろう、もっと素敵なプラクティスをご存じな方は、是非そのノウハウをこのような場で共有をお願いします！
それでは、長文にお付き合い頂きありがとうございました。