ServiceNow導入事例 宮越　信吾 [email protected]

本日のアジェンダ ● 過去の導入事例おさらい ● 過去の導入事例からの “その後” ● これから取り組んでいこうとしていること ● まとめ

過去の導入事例おさらい

Informatica Cloud ERPを中心とした社内システムの現在(概要) 業務系(基幹) ServiceNow ● ポータル ● workflow ● task管理 Workday ● ERP Salesforce ● SFA ● CRM WorkCloud ● 勤怠 ● 給与 ● ESS 情報系システム G Suite Slack Groupad ● 社内SNS GHE システム連携 Zapier 認証基盤 Active Directory : データの流れ 凡例

課題 1. 近年の急成長でIT部門の組織整備と同時にITインフラの改革が求められていた 2. サービスデスクで使用していたExcelベースの管理台帳を本格的にデータベース化 したかった 3. サービスデスクでは、問い合わせの窓口や方式がバラバラであり、作業も属人化し やすく厳密な管理が難しかった https://www.servicenow.co.jp/content/dam/servicenow-assets/public/ja-jp/doc-type/resource-center/case-study/cookpad.pdf 過去事例の課題ふりかえり

1. ServiceNowやWorkdayの導入など、Globalにスケールできるための仕組みを 構築する基礎固めを行った 2. PCやディスプレイ、携帯端末などの管理台帳をServiceNowへ移行 a. CMDBを利用しDB化 b. ServiceNowのUserと紐付けた 3. 問い合わせ経路をServiceNowに一本化することですべての問い合わせがチ ケット管理される状態となった a. Slackとの連携で日常のコミュニケーションの一部として浸透 b. 定形依頼についてはServiceCatalog化 いかにして課題を解決したのか

● この3つを組み合わせて実現している ○ ServiceNowのOOTB(IT Service Mgmt v2) ○ Business Rule ○ Rest Message ■ Slackとの連携 ● Slackとの連携について掘り下げてみようと思います ○ ServiceNowのimplementationついては釈迦に説法ですよね。。。 つまるところは

Slack連携の掘り下げ ● このフェーズでは「いかにしてSlack連携と連携するか」がPOINTだった ○ Slackからのチケット起票 ○ ServiceNowからSlackへの通知 ● 日常のコミュニケーションがSlackを中心に行われる中で ○ 日々のコミュニケーションに “なじませる” ○ 問い合わせや対応が可視化され、チーム内で状況が把握できる ○ 承認依頼やコメントがDMで通知され情報がpushされる状態 ■ メールは “埋もれ” て “見落とす” もの ■ ServiceNowを常に確認する人は居ない

● SlackのUserをServiceNowに取り込む ○ ServiceNowのUserとSlackのUserを紐付ける必要がある ○ Scheduled Jobsを設定しDailyでSlackのAPIからUserを取得 ● SlackからServiceNowのIncident Ticketを起票できるようにする ○ SlackのOutgoing WebhookとServiceNowのScriptedAPIの組み合わせ ● ServiceNowからSlackへ通知 ○ Channelへ通知するのはIncoming Webhook ○ DMで通知するのは Slack Bot Business Rule、Script Include、Rest Messageを組み合わせて実現している Slack連携を実現した方法

SlackからのUser取得連携概要 Slack users.list A P I ServiceNow Scheduled Job ①Slackの 　User情報を取得 ②SlackのUser情報を 　ServiceNowへ取込 Slack User管理テーブル SlackのUser ID Slackの team(workspace)ID ServiceNowのUser Slackに登録のある Email String String Reference(sys_user) String テーブル実装の一部抜粋 ②の取込処理では、 emailをkeyとしてupsertしている

②Incidentテーブルへ 　INSするためのGlideRecordを作成する Scripted REST APIs Slack User管理テーブル Slack Incident Mapping テーブル Incidentテーブルの項目との Mapping例 Incidentの項目 Requestの項目 参照テーブルの項目 category trigger_word Slack Incident Mappingテーブル.category caller user_id Slack User管理テーブル.ServiceNowのUser short description text 冒頭に含まれる”<@qqqqqqqqq>”はmentionなので Slack Incident Mappingテーブル.mention名で置換 SlackからのIncident Ticket起票連携概要 Slack @hd ServiceNow ①Slackの機能で 　ServiceNowへ連携 Incident テーブル outgoing webhooks @wp @legal ︙ { "channel_name": ["servicenow_dev"], "user_name": ["shingo-miyakoshi"], "team_domain": ["cookpad"], "team_id": ["Txxxxxxxxx"], "enterprise_id": ["Eyyyyyyyy"], "token": ["tttttttttttttttttttttttt"], "user_id": ["Wzzzzzzzz"], "trigger_word": ["<@qqqqqqqqq>"], "service_id": ["nnnnnnnnnnnn"], "text": ["<@qqqqqqqqq> test"], "channel_id": ["Cwwwwwwww"], "enterprise_name": ["Cookpad"], "timestamp": ["1569306772.002000"] } request.queryParamsを JSON.Stringifyしたもの mention名 channel ID mention ID category workspace名 通知先channel String String String Reference (choice) String String Slack Incident Mappingテーブル項目一例 ③IncidentテーブルへINSする

Slackへの通知連携概要 ServiceNow Business Rule Slack User管理テーブル Slack Incident Mapping テーブル Incident テーブル ①Update Rest Message Slack https://hooks.slack.com/services/ Slack User管理テーブルから CallerのSlackのUser IDを取得し CallerへDMを送信 Rest Message https://hooks.slack.com/services/ Slack Incident Mappingテーブルから 担当部門のchannel名を取得し Channelへ通知 endpointは同一

Slack連携実装要点 ● Script Includeへ再利用可能な処理を集約 ○ ServiceNowのUserからSlackのUserを取得処理 ○ Rest Messageの作成/送信処理 ○ 送信したいMessage BodyのBuild処理 ● 送信するトリガーはBusiness Rule ○ 基本的にはScript Includeの各処理を呼び出す役割 ○ MVCで言うとController的責務を持たせた

過去の導入事例からの “その後”

1. IT部門で解決した問題が他部門で未解決だった a. 依頼の仕方が部署や目的によってバラバラ b. メールでの承認 c. Taskがシステムで管理されておらず属人的 2. 活用のために様々なシステムとつなぎたい a. ServiceNowから各個別システムへつなぐと連携の見通しが悪い i. 個別連携の数が増える前に対処したい b. 単純なWebAPIでの実装における限界点 i. メンテナンスコスト ii. 実装時の対応速度(手軽さ) 1. 例えば: Google Spreadsheet 見えてきた課題

● バックオフィスが受けている定型依頼をServiceNowのCatalog item化 ○ 依頼窓口や承認経路をシステム化 ■ メールやslackでの依頼/承認だった ○ 各部門での対応taskをticket化 ■ ticket上でコミュニケーションが可能となった ● Catalog Item化した定形依頼の一例 ○ 捺印申請 ○ 個人情報取得系申請 ■ JP, Globalともに ○ 名刺作成依頼 ○ ノベルティ払い出し依頼 ○ 就業証明書作成依頼 IT部門で解決した問題が他部門で未解決だった

● 課題 ○ ServiceNowで承認された内容をGoogle Spreadsheetへ転記し、社内全 体で情報を共有できる状態としたい ○ ServiceNowからGoogle Spreadsheetへ転記する実装が厳しい ● 実現した方法 ○ Zapierと連携をすることで “無理やり” な実装をすることなく実現 ○ 連携ツールを用いることで連携先のAPIが変更となってもメンテナンスコスト を掛けずに対応できる 活用のために様々なシステムとつなぎたい

Zapierとの連携を実現した方法 ● Zapier側 ○ TriggerをWeb hookにする ■ 専用のURLが払い出される ○ 後続として実現したい連携を定義 ● ServiceNow側 ○ Business RuleとRest Messageを利用 Slack連携と同様に外部APIをCallすることで情報を送出し実現している

ServiceNow Workflow Business Rule Rest Message 処理の流れ Webhook 処理 Connector Zapier API 処理 連携先システム Zapierを用いることでの実装上のメリット ● Webhookへデータを渡す方法は検証済み ○ 都度検証は必要なし ● Zapier提供コネクタを使用 ○ 品質やメンテナンスは Zapierの責務 Zapierの1つのworkflowはZapと呼び、Zapは一覧される

これからの取り組み予定

現在顕在化している課題 1. 社内で問い合わせの共有ができない a. ServiceNowのライセンスが超えられない壁となっている i. Requester と Fulfillerの考え方 2. Slack連携が独自実装のためメンテナンスコストが高い a. 導入当時はSlack連携が存在しなかったため独自実装となっている 3. Globalへの本格展開 a. 一部問い合わせはServiceCatalogによって実現されている b. 問い合わせやCatalog Itemの数など日本同様に広げていく必要がある

● Now Platform App Engineでの独自実装 ○ これまでのIncidentテーブル運用の知見を元に “CKPD INC”テーブル(仮)を実装し、全社員で情報共有できる Platformを目指す ■ CKPD INCテーブルはOOTBの Incidentテーブルを参考にする想定 ● Unrestricted Userモデルの活用 ○ 独自実装したテーブルにおいては全社員Fulfiller状態 社内で問い合わせの共有

Now Platformでの実装(想定) カラム名 type 用途 備考 Number String チケット番号 自動発番 Short Description String 問い合わせ内容 Assign To Reference(sys_user) 担当者 Assignment Group Reference(sys_user_group) 担当グループ(部門) Category String(choice) カテゴリ ACLの制御で使用 Caller Reference(sys_user) 依頼者 State Integer(choice) ステータス Slack Channel String 任意の通知用channel名 Share True/False 共有する(True: 共有) ACLの制御で使用 Watch List List(sys_user) 共有したい人 ACLの制御で使用 CKPD INC テーブル (Tableを作成すると自動的に付与されるカラムは除く )

Slack連携 ● Integration Hubの使用 ○ Slack Spokeでの通知を検証しているがいくつの疑問(個人の主観です) ■ 複数のworkspaceへ通知することは想定されていないのでは？ ■ 追加された “Additional Comment” を取得できない？ ○ Slackからticketの起票は出来無さそう ■ あくまでの “通知” の為に存在している模様 ■ 実現するためにはNow Actionsの使用？ ■ 独自実装での運用を続ける可能性も

Globalへの本格導入 ● 問い合わせ対応 ○ 日本でServiceNow導入前の状況と酷似している ■ Slackやメールなど問い合わせ経路が定まっていない ■ そもそもticket管理されていない ● 定形依頼 ○ こちらもやはり問い合わせと同様の状況

まとめ

● Business RuleとRest Messageの活用が肝になる ● IT部門で実現したCatalog ItemやWorkflowは他部門へも横展開できる ○ 承認フローのシステム化やTaskの可視化は大切 ● Rest Messageを用いた個別システムへの連携も善し悪しがあるので、 ServiceNowと各システムの間に連携ツールを置くことも考慮 ○ 個別連携が増えたときの見通しの悪さ ○ 実装速度やメンテナンス ● Now Platformを活かすことで、ServiceNowの可能性はもっと広がる 本日お話した要点

運用体制 ● 日常運用 ○ 1名 ● Catalog Itemや機能の追加 ○ 1名 ● バージョンアップ対応 ○ 1名 ● Globalや関連会社対応 ○ 1名 取り組みたい課題 >>>> (物理的な意味の)手 ServiceNowの運用に係る総人数 1名 4名 社内の様々な業務課題を理解しシステムへの落とし込みや業務プロセスそのものの改善までを 総合的に共に進めることのできる仲間を募集しています

We're hiring