ServiceNow導入・構築におけるアーキテクチャ・プロセス検討例

# 1.はじめに、略歴
本記事では、ServiceNowのアーキテクチャやプロセスに関する資料を紹介しつつ、当該資料を用いてOOTBとのマッピング例について述べていきたいと思います。

1社目：SIerにて人事給与パッケージの導入・構築に7年従事。
       アプリケーション開発からインフラ構築まで全般を担当。
2社目：SIerにてServiceNowの導入・構築に従事。
 　　　　ITSM/ITOM/HRSD/AppEngine関連PJにPMとして参画。(HRSDが1番長いです)
　　　　OrlandあたりからServiceNowに関わり始めてます。(約3年)
# 2.対象読者
・プリセールス、営業
・プロジェクトマネージャー
・アーキテクト担当
・開発者（どちらかというと上流寄り）
※ServiceNow経験者が望ましいですが、初心者にもServiceNowの理解を助ける資料があるということを知って頂ければと思います。
# 3.背景・課題
本記事を書いたきっかけや背景・課題を何点か述べていきます。

### (1)新規プロダクトに対するキャッチアップの難しさ
提案活動等において、新規プロダクト（例えばリリースされて日が浅いSPO、WSD、ESG等）に対するキャッチアップを早めるための工夫が必要でした。
特に、以下の要素について知りたかったのですが、ServiceNowに携わり始めた当初の頃は実機検証しながら全体観のイメージを膨らませるなどの苦労がありました。
・製品コンセプト
・業務フロー
・E-R図
・機能概要

DOCSだと詳細については記載されているのですが、ドキュメントの構成上、全体観を把握することが難しく、DOCSで詳細を調査しつつも実機検証で全体観のイメージを作り上げていかないといけなかったため、理解に手間がかかっていました。

### (2)カスタマイズするかどうかの判断・影響見極めの難しさ（≒OOTBを活かすことの難しさ）
OOTBを活かすといいつつも、OOTBってどんなことができるの？という点についての説明や、ServiceNowの得意領域を踏まえた上での業務設計に対する難しさはどんなプロダクトであれあると思います。
過去の経験例においては、ServiceNowと他システムの役割分担(SoE,SoRの区別)が不適切なために、ServiceNowに独自マスタ、独自ビジネスロジックを組んでしまって不具合の原因となるような場面に遭遇してきました。（特に、金額計算のような業務的にデリケートな要件を対処するのは辛かった・・・。）
※とは言いつつ、自分自身もSoE,SoRに関する区別をどうすべきなのかは未だ模索中…。

1社目の経験でも、アプリケーション基盤の構築・最新化（ServiceNowにおけるバージョンアップに相当）も担当していて、全体に対する影響を早期に見立てないといけない場面が多々ありました。
そういった場面において、全体観を把握しておくことで、不具合発生時の原因切り分けや影響予想を素早くできるようになった経験からも、アプリケーション全体の構成要素を理解した上で日々の構築を進めることが重要だととらえています。

### (3)新任者への教育、育成における難しさ
ServiceNowの機能が広範な故に全体像をつかむのが難しく、そのために新任者向けへの説明もまずプロジェクトで関わりそうな部分だけをつぎはぎでレクチャー・ハンズオンで勉強するしか育成していく手立てが無かった状況でした。
ServiceNowの基礎に関する研修は勿論ありましたが、基本的な部分についての理解はできる一方で、ServiceNowの全体観を把握しながら、各プロダクトの概観から詳細な機能までを素早く理解していくための手段が必要だと考えていました。

# 4.解決策・考察の過程
これらの課題のうち、本記事では(1),(2)の解決に役立つ資料として、Engagement Architecture Blueprint, Product Architecture Blueplint, Process Guideを紹介しつつ、活用例を紹介していきたいと思います。

＊各資料について
・Engagement Architecture Blueprint[^1]とは、ServiceNowがIT領域以外のインダストリー領域に拡大していった際に、プロダクトの概観がわかりにくくなる問題から書き起こされた資料。ServiceNowのほぼ全てのプロダクトをそれぞれのレイヤーごとに区別し、アーキテクト図として起こされた。
・Product Architecture Blueprint[^2][^3]とは、各プロダクトにおける製品コンセプトや機能概要等が記載されている資料。Now Create上でプロダクトまたは機能別に公開されている。
・Process Guide[^4][^5][^6]は、各プロダクトにおける業務フローの概要やアクター（対応するロール含む）、データモデル等が記載されている資料。こちらもNow Createにて公開されている。

＊想定ユースケース
    顧客から商品の注文を受け付け、注文された商品が存在する場合は所定のケース管理に従い、顧客から注文された商品の納入を行う。

＊前提
    ・本記事は各機能の実装より、アーキテクチャ設計に主眼を置いた記事となるため、カスタマイズの詳細な手法や実現可能性の検証については割愛とします。
    ・アーキテクチャを検討するにあたっては、Engagement Architecture Blueprint v4[^1]を参考にします。
    ・各プロダクトの全体像、機能概要については、Product Architecture Blueprint[^2][^3], Process Guide[^4][^5][^6]を参考にします。
    ・想定ユースケースに対する業務分析は省略します。
    ・図については当記事に記載はせず、該当箇所記載のページのみとします。
    ・環境については、PDI上に以下プラグインをインストールしています。(依存プラグイン省略)
    【プラグイン】Employee Center Pro, Sourcing and Procurement Operations, Shopping Hub

## (1)プロセス分解 
想定ユースケースを以下のようなプロセスに分解します。
a.社員がポータルサイトにアクセスする。
b.社員が商品を注文する。
c.購買担当者のリーダーが注文に対するアサインを行う。
d.財務担当者が承認を行う。
e.購買担当者が業者への発注を行う。
f.ERPへの連携を行う。
g.社員への納品を行う。

## (2)Engagement Architecture Blueprint, Product Architecture Blueprint, Process Guideとのマッピング

### a.Engagement Architecture Blueprintとのマッピング
Engagement Architecture Blueprint[^1]から、構成要素(アクター・構築対象)については以下がマッピングできると考えられます。
| Blueprint上の区分 | 対応するユースケース上の構成要素 |
|:-:|:-:|
| Internal Requesters | Employee(社員) |
| Engagement Layer | Employee Center |
|  Internal Fulfillment | Procurement - Procurement Cases, Sourcing and Purchase Requests |
|  Integration Rayer | Integration Hub |
|  System of Record | ERP(例：SAP) |

### b.Product Architecture Blueprint, Process Guideとのマッピング
Product Architecture BluePrint, Process Guideから以下箇所を参考にOOTBのプロセスを使えないか検討します。
SPO - Product Architecture Blueprint[^2] : P14-16,P21
SPO - Process Guide[^5] : P8 Purchasing Process Flow (Standard PR – Goods)
上記部分を確認したところ、概ね実現できそうではあるが、ERPとの連携定義や承認周りで一部コンフィグレーション・カスタマイズが必要そうと想定しました。
※これも検討した過程を書きたかったですが、別途改版できればと思います。

## 5.マッピングに基づくウォークスルー
※時間の都合上、4.(1).a-cのみとします。
（時間切れで力尽きました・・・、すみません。進展あれば書いてみますm(_ _)m）

### (1)社員からの商品注文を受け付け、商品が存在する場合は所定のフローに沿って商品の納品を行う。
   　a.社員がポータルサイトへアクセスする
    　　Employee Centerとメニューは揃っていそう。
      ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640094/55292d9d-2000-600a-daf4-20627c29a6ba.png)
      ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640094/b39df735-caa2-ba80-d32c-5d57918b318e.png)
      【余談】TaxonomyのTopic定義については業務に沿ってわかりやすくしようとすると悩みがち…。
    b.社員が商品を注文する
    購買に関するTopic並びにカタログは用意されていそう。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640094/56ea68fc-ad1a-9f9a-62d5-3bcfe47fadbd.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640094/9ea3c524-d9e9-8648-fa86-644a87f8202b.png)

c.購買担当者のリーダーが注文に対するアサインを行う。
Sourcing and Payment workspaceにて一連の業務が処理できそう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/640094/ac125fc8-b4bb-c4af-8323-7c429047b9dc.png)

# まとめ
時間の都合上、後半のまとめが雑になってしまいましたが、Product Architecture Blueprint, Process Guideを用いることで、業務フロー検討段階でのOOTBとのマッピング(たたき台)ができる一例を示してみました。上記資料以外にもNowCreateには有用な資料があるので是非一読して頂ければと思います。
DOCSだけでなくNowCreate等に掲載されているアーキテクチャやプロセス関連の資料も有効活用できると、日常のServiceNow導入・構築における活動も、俯瞰した目線で取り組めるようになり、違う目線で課題解決できる場面も増えていくのではないかと思います。
NowCreateに格納されている資料は英語が大半（全て？）ですが、読解できれば有用な資料だと思いますので、是非ServiceNowに携わっている人は活用いただければと思います。

# 参照
※一部資料については、ServiceNow Developerサイトでのアカウント登録が必要です。
[^1]: Engagement Architecture Blueprint v4
https://www.linkedin.com/pulse/engagement-architecture-blueprint-v4-tolga-tutel

[^2]: Employee Center - Product Architecture Blueprint
https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=de94f100dbcbc91072b78263059619d9&nc_source=copy_asset_link

[^3]: SPO - Product Architecture Blueprint
https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=ebd3bc4447a7e5982a090dcbd36d4374&nc_source=copy_asset_link

[^4]: Employee Center - Process Guide
https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=6831a25787a69d9024e0bb39dabb35fb&nc_source=copy_asset_link

[^5]: SPO - Process Guide
https://nowlearning.servicenow.com/nowcreate?id=nc_asset&asset_id=bfcde46a47b53d54db63fb25126d430e&nc_source=copy_asset_link