契約更改の案内が届き、見積の金額を見て社内がざわつく。情シスは「利用者は増えていないはずだ」と言い、経理は「去年より高い理由を説明してほしい」と言い、購買は値引きの交渉に入る。そして交渉のテーブルに、自社が何をどれだけ使っているのかを説明できる資料が一枚も出てこない。ライセンスの整理は価格交渉から始めるものではなく、誰がどの権限を持ち、そのうち何が実際に使われているかを数えるところから始まる。 数えずに交渉へ入ると、相手が出した前提をそのまま受け入れて値引き幅だけを争うことになる。値引きは一度きりだが、前提のズレは毎年効き続ける。
ライセンスの過不足は、名簿でなく利用ログでしか分からない
棚卸しをやろうとすると、最初に出てくるのは人事の在籍名簿と情シスが管理するユーザー一覧である。突き合わせれば、退職者のIDが残っているといった分かりやすい漏れは見つかる。しかしそこで終わると、金額に効く部分には届かない。
理由は、名簿が「持っているかどうか」しか写さないからだ。ライセンスの種別は、その人がどの操作までできるかで段階が分かれている。段階の呼称と定義は契約と時期によって変わるので、ここでは呼称を追わない。重要なのは、広い権限を持つ人の大半が実際には狭い操作しかしていない、という事実のほうだ。
これを見るには利用ログを取るしかない。誰がいつどのトランザクションを実行したかの記録を、少なくとも一年分。月次でしか動かない人と、期末や年次にしか動かない人を取りこぼさないためだ。三か月のログで「使っていない」と判定して権限を落とすと、決算期に業務が止まる。棚卸しの精度は、ログの期間で決まる。
ズレは四つの型で出る
ログと権限を突き合わせると、ズレは次の四つに分類できる。分類しておくと、対処の担当も期限も分かれる。
| 型 | 現れ方 | 見つけ方 | 対処 |
|---|---|---|---|
| 使っていない | 退職者・異動者・PJ要員の権限が残る | 人事マスタとユーザー一覧の照合 | 削除。人事異動と連動する手続きを作る |
| 重すぎる | 年数回しか使わない人に広い権限が当たる | 1年分の利用ログと権限範囲の突合 | 種別の見直しと業務の代替手段 |
| 軽すぎる | 暫定で借りた権限や共有IDの操作が常態化 | ログ上の操作と割当権限の不一致 | 是正。統制の問題として扱う |
| 人が操作していない | 外部連携でSAP内に文書が作られる | インターフェース一覧とジョブ実行記録 | 契約書の該当条項と突き合わせる |
三つ目の「軽すぎる」型を、金額の話に混ぜないことが大事だ。本来必要な権限を持たない人が共有IDや他人のIDで操作している状態は、ライセンスの適正化以前に職務分掌の問題である。棚卸しでこれが出てきたら、コスト削減の議題から切り離す。混ぜると、費用を下げる提案と統制を強める提案が同じ表の中で衝突し、どちらも進まなくなる（SAPの権限設計とSoD（職務分掌）｜内部統制を仕組みで担保する）。
一つ目の「使っていない」型は、見つけるのは簡単だが再発を止めるのが難しい。人が辞めたときにIDを消す手続きはたいていあるが、異動したときに前の部署の権限を落とす手続きは無い会社が多い。一度きれいにしても翌年の異動で元に戻る。人事の異動情報とつなぐところまでやらないと、毎年同じ作業を繰り返す（SAPのマスタデータを稼働後に劣化させない｜登録権限とオーナーシップの決め方）。
人が操作していない経路の課金は、インターフェース一覧から辿る
四つ目の型が最も見落とされる。人のライセンスはユーザー一覧という形で必ず存在するが、外部システムからの連携は一覧を見ても姿が見えない。
稼働から年数の経った環境では、人が画面から入力する文書より、他システムから流れ込んで作られる文書のほうが多いことは珍しくない。販売管理からの受注、経費精算からの仕訳、購買サイトからの発注、給与システムからの人件費、EDIで届く出荷指図。どれも連携用のIDで動いており、そのIDは一つか二つしかない。人数で数えると小さく見える。
一方で契約の側には、人が直接操作しない経路でSAPの中に文書が作られる利用をどう数えるかという、別の考え方が置かれていることがある。デジタルアクセスという言葉はこの領域を指す。ただし対象となる文書の種類も、数え方も、既存の契約からどう扱われるかも、契約の内容と締結の時期によって条件が変わる。ここを一般論の記事や社内の伝聞で判断するのが最も危ない。自社の契約書の該当条項を実物で開いて確認する。 以下の工程も、その確認を前提に組む。
インターフェース一覧は導入時に必ず作られている成果物だが、稼働後の追加分が反映されていない。数年経った環境では当初の一覧に無い連携が動いており、しかも作った担当が既にいない。だから棚卸しでは設計書を信じず、稼働中のジョブと受信ファイルを実行記録から拾い、一本ずつ「何が、どこから、どれだけ、何の文書を作っているか」を埋め直す（SAPとサブシステムの連携設計｜販売・購買・経費・給与でデータが合わなくなる境目）。
この作業には副産物もある。使われていない連携、二重に取り込んでいる経路、誰も見ていないのに毎晩転送し続けているデータが同時に見つかる。この一覧はそのまま、IT費用を事業別に配賦する基礎資料にもなる（IT費用・クラウド費用の管理会計｜情シス予算を事業別の採算に返す）。
棚卸しはこの順で回す
工程は五つで、順番に意味がある。前の工程の出力が次の入力になるからだ。
五工程目を最後に置くのは、契約書を先に読むと、その区分に合わせて現状を歪めて数えてしまうからだ。先に使われ方を素直に写し取り、その後で契約の定義に当てる。この順番なら、定義と実態が合っていない箇所がはっきり残る。そこが交渉で持ち出す論点になる。工程全体はログが取れている前提で三か月前後。取れていなければ取得開始から数えるので、半年前という目安は「ログがある会社」の下限だと考えたほうがよい。
導入時のどの判断が、数年後の課金として跳ね返るか
課金は更改のタイミングで初めて話題になるが、金額を決めている条件の多くは導入時に決まっている。
| 導入時の判断 | 数年後に効いてくること | 表に出てくる時期 |
|---|---|---|
| 権限ロールを職種でなく個人単位で作った | 異動のたびに権限が増え、棚卸しが毎年重くなる | 二年目以降、毎年 |
| 連携を都度の個別開発で追加していった | 一覧が実態と乖離し、棚卸しが作り直しになる | 三年目以降 |
| 参照だけの利用者にも入力権限を付与した | 見直しの余地が大きいのに誰も気づかない | 更改のたび |
| 連携の追加時に経路の記録を残さなかった | 何がどれだけ文書を作るかを実物から数え直す | 更改の直前 |
| 利用ログの保存期間を短く設定した | 根拠が作れず、相手の前提をそのまま受け入れる | 更改の直前 |
最後の行は地味だが効く。ログの保存期間は稼働直後に容量の観点だけで決められがちで、短く設定していると更改の半年前に始めても一年分が手元に無い。この一行が数年後の交渉力を左右する。権限ロールも同じ構造で、職種や業務単位で設計しておけば異動は付け替えで済むが、個人単位で積み上げると権限は増える方向にしか動かない。
更改の前に確定させておく項目を、まとめて置く。
- ① ユーザーIDごとの権限ロールと契約上の種別の一覧（現状をそのまま写す）
- ② 直近1年分の利用ログに基づく、IDごとの実際の操作範囲
- ③ 人事マスタと照合した、削除・変更が必要なIDの本数
- ④ 実物から作り直したインターフェース一覧（何が・どこから・どの頻度で・何の文書を作るか）
- ⑤ 使われていないことが確認できた連携の本数と、停止の可否
- ⑥ 自社の契約書の該当条項の写し（伝聞・他社事例で代用しない）
- ⑦ 次回に向けた、ログ保存期間と権限付与手続きの是正案
七番目を入れているのは、棚卸しを一回きりにしないためだ。見つかるズレの多くは手続きが無いことに由来しており、直さなければ次の更改でまた最初からやることになる。運用に落とすところまでが完了条件だ。
交渉の前に、自社の使われ方を数え切る
ライセンスと連携の課金は、相手が出した前提の上でしか議論できないと思われがちだ。しかし前提を作っているのは自社の使われ方であり、それを数えられるのは自社しかいない。順番は動かない。まず利用ログを取り始める。次に権限ロールと利用実態を突き合わせ、人事マスタで在籍と所属を照合し、インターフェース一覧を実物から作り直す。最後に契約書の条項に当てて過不足を判定する。ここまで終えていれば、交渉は値引き幅の争いでなく実態に基づく整理の議論になる。そして棚卸しの重さは、導入時の権限設計と連携の作り方で決まっている。稼働後にじわじわ効いてくる費目は、どれも同じ場所に根がある（SAPの年間保守料に見合う価値を出す｜標準機能の更新に追従する会社としない会社、SAP以外のERPという選択肢｜自社の規模でSAPが過剰になる分岐点）。作り切る順番は、ログの取得設定を変える一手から始まる。
