基幹業務システム保守について | 情シスのお仕事（2019年度改訂版）

今回の「情シスのお仕事」は基幹業務システムを取り上げます。
改めて「情シスのお仕事」で取り上げる弊社情シスの業務範囲を貼っておきます。
各業務を紹介する記事のリンクになっているのであわせて見ていってください。

ブログの更新頻度の落ちたこの半年くらい、基幹業務システムの更新作業をやっていました。会計や簿記の知識を覚えたり、実際に稼働してみて気付く運用や設定、システム側の不備等、なんやかや苦戦しましたが、なんとか安定運用に漕ぎつけました。

よく基幹システムの更新は企業にとって10年に１度の大事業などと言われますが、「2025年の崖」でも「10年一昔前の基幹システム使い続けてたら崖から落ちちゃうよ」と注意喚起されている最中、弊社も御多分に漏れずクラウドERP導入にかじを切りました。

↓↓「2025年の崖」って何？という方はこちらをどうぞ↓↓

ERP導入に関する話はそれだけで数回分の記事になりそうです。ただ詳細に説明しようとすると事業形態や業務内容がモロに出てしまうし、逆にそれを出さずに話すとひどく抽象的な話になってしまうので、紹介の仕方をもうちょっと考えようと思います。

基幹業務＝ヒト・モノ・カネを管理する業務

毎度のことながら、「基幹業務とは何か？」「ERPとは何か？」という話からしていきます。
「基幹業務」という言葉も概念も目新しいものではありませんが、業種業態によって対象とするものが違うはずなのにどこに行っても「基幹業務」という呼ばれ方をする不思議な業務です。簡単に言うと「ヒト・モノ・カネの管理をする業務」ですが、それではあまりにざっくりしすぎているので、それぞれ区切って内容を見ていきたいと思います。

モノを作って売れるようにするための管理

第一次産業から第三次産業に至るまで、経済活動の根幹は「モノを作って売ること」です。
生産や製造を伴う業種の場合、直接的に製品を作っていますが、サービス業であっても商品やサービス、労働力を仕入れて自社サービス＝モノとしてパッケージングして売っています。

モノを作るのに全くの無から産み出せることはほぼありません。物理的なモノをほぼ必要としない知識集約型の第四次産業であったとしても、情報やサービスなどを集約する必要があります。モノを作るための材料を集めるために「仕入」の仕事があります。仕入はさらに「見積」「発注」「納品仕入」「支払」に細分化できます。
仕入が集める材料は部材や装置だけではなく、外部の労働力リソース（外注発注、アルバイト・パート等）や他のサービス（システム動作環境としてのパブリック・クラウド等）である場合もあります。

材料が集まったらそこからモノを作る「生産」のプロセスがはじまります。生産は単純に言えば「いかに早く正確に大量に作れるか」、厳密には「正しい需要予測に基づいた生産量を、いかに各工程のリードタイムなく作り出すことができるか」を管理するプロセスです。
そのためこのプロセスには、必要なタイミングで必要な材料を揃えるための「仕入」や、需要予測のための「販売」「在庫管理」などの要素が関係してきます。その上で工程毎の稼働率やミスロスの割合等を検査し、生産現場を効率的・効果的に稼働させるのです。

生産したものは売れるまでの間保管しておかなければいけません。所謂「在庫管理」のプロセスです。在庫数が正しく把握できていないと、出荷に必要な商品点数が確保できず機会損失に繋がります。前述の通り在庫数に基づいた生産数の指示が必要になります。また在庫はバランスシートでは資産に分類されますから会計帳簿上も正しい数値の管理が必要です。

ここまでのプロセスで売るためのモノが準備できました。あとは実際にモノが売れた時の「販売」のプロセスになります。販売も「受注」「在庫引当」「出荷・配送」「売上」「入金管理」などに細分化することができます。

尚、一般的な販売管理と定義が異なる部分もありますが、区分があまり細かくなりすぎないように受発注管理も含めて全て販売管理として纏めています。

ここまでのプロセスは製造業だと非常にわかりやすいと思います。それ以外の業種でも、全てのプロセスに該当しなくても一部分だけを切り取ればほぼ当てはめることができます。

サービス業でも仕入はあります。システム開発なんか生産そのものです。小売業に在庫管理は必須です。流通業は出荷・配送管理が命でしょう。「作ったものを売る」のが営業で、「モノを作って売れるようにする」のが基幹業務と考えて良いと思います。ただそれぞれの業種で該当するプロセスやそれに掛ける労力が異なるのです。

ERP＝基幹業務を一元管理する仕組み

「基幹業務」を担当するのは１人（１部署）ではない

基幹業務は業務範囲が広範囲に及び、複数の部門を横断して行われることが多いです。しかし仕入から販売までは一続きの流れの中で行われるため、前後の業務間のモノと情報の受け渡しが重要になります。

別々に管理していたら、いちいち問い合わせたりデータ授受したりしなければいけなくてまどろっこしい。それなら全部同じシステム上で管理してデータを共有すればいいじゃん！ということで一元管理するために提供されるシステムがERPなのです。

ヒト・カネも一元化できるが、話として分けます

ERPではモノだけではなく、カネやヒトも一元管理する場合がありますが、本稿ではカネを扱う財務会計やヒトを扱う人事給与は「バックオフィスシステム」という分類で分けています。

全てを一緒くたに説明しようとすると業務が多岐に渡りすぎて説明する分量が溢れかえってしまうこと、業務主体がライン系とスタッフ系で分かれており情シスとしての携わり方に違いがあることなどから別の分類に分けました。

ちなみにSE時代の私の担当業務領域はバックオフィス系業務だった、ということもこの分類を分けた理由の一つでもあります。

基幹業務システムに関する情シスの関与について

導入目的の訴求に尽きる

「基幹システム導入の話は別にする」と言いながら、現在のフェーズが導入直後ということもあり、運用保守はまだ「使い方を定着させる」の段階にあります。

導入時にも散々「ERPに業務を合わせる」「前提としてカスタマイズしない」と言ってきて、運用評価も仮稼働もやったけど「システムが例外的な業務に対応できない」という話は後を断ちません。

基本スタンスは「システムで対応できない例外業務なんてやめちまえ」「何こそこそローカル管理のExcel隠し持ってるんだよ」です（そういう言い方はしませんが）。
言い方を変えると「導入目的を訴求する」になります（随分乱暴な変え方ですが）。

ERPのメリットは「業務手順の標準化」「データの一元管理」です。極論を言ってしまえば「効率化」にならない場合もあります。
業務の属人化や複雑な業務手順を解体してERPパッケージの推奨する手順＝ERPを活用した場合に最も効率的な手順（某社がよく「ベストプラクティス」というヤツ）に業務手順を変えることで業務手順と掛かる時間を明らかにすること、全てのデータをERP内で管理することで様々な切り口でデータを加工・分析を、データがほしい人が自分で出力することができるようになることで導入効果は最大化できるというのが謳い文句です。

下手なカスタマイズを入れてしまい業務手順を温存してしまえば、次期更新時に要件を満たすソフトが無いどころか自分たちの要件をまともに伝えることすらできなくなり、安価で効率的な業務を提供してくれたり、定型的な検索統計や自由度の高いBIを備えた最新システムへの乗り換えなど夢のまた夢になってしまいます。そして現在の業務担当者がいなくなった途端ブラックボックス化された業務を誰も理解できずに業務の混乱・停滞、高生産性を実現した同業他社に淘汰されていくことになっていく、というのがノンカスタマイズでERPパッケージを導入しなければいけない理由です。

業務手順をきちんと文書化できて基幹システムに求める要件を漏れなく管理できていれば、「業務のブラックボックス化」が回避されている状態ですから、新システムを導入しなくてもERP導入の目的は60%くらい達成できていると言えるかもしれません。
不足機能のカスタマイズやデータの出力・分析などのアドオンを付けると次期システム更新時に同じ機能を求めれば割高にはなるかもしれませんが、不足している要件を別の方法でカバーしたり例外的な手順を作ることによるオーバーヘッドとトレードオフと考えることができるならば一概に非効率と決めつけられないかもしれません。

基幹システムに求める要件を正確に管理できる自信が無いのであれば、大人しくノンカスタマイズのERPパッケージに業務を合わせることに徹したほうが懸命でしょう。手順はERPパッケージが提示しているものの通りにすれば新たにドキュメンテーションを起こさなくても要件は文書化されている状態になります。
外部Excelで不足部分の運用をカバーというのも、適切な運用ドキュメントを残さなければ結局ブラックボックス化するという意味ではアドオンと大差はありません。

もはや基幹システム更新は10年に一度の大事業ではなく、より高度化されたシステムへ適時切換えていったり、常に高度化されたサービスへ自動的にバージョンアップされていくクラウドサービスを利用するものになっているのです。それを実現するためには、簡単にシステムを乗り換えられたり、自動バージョンアップの恩恵を受けられる手順への改変が必要になるのです。

データの一元管理についても、データ活用・分析というのは建前であり、一番の目的はデータの入れ方・出し方を全社同じ基準にすることで管理指標となる数値の取り方を部門毎で勝手に読み替えさせないことにあります。

「勝手に読み替えさせない」って、受注や売上の数字をごまかしているのか？と思われるかもしれませんが、故意かどうかは別として当たらずとも遠からずと言えます。

ERPで統合されていない状態の場合、財務諸表の各数値は各部門で管理している売上等の数値の合計と必ず一致しているとは限りません。年次で締まっても仕掛りなどにより厳密には一致しない場合もあり、数値の不一致の原因を探して拾い上げたり等を行ってようやくきれいになるといった具合だったりします。

財務諸表は会計帳簿から拾った数値の合計ですが、会計で管理している仕分を見るだけでは何の製品・案件でどれだけの売上がありどれだけ利益が出ているかを追うことは難しいです。仕入や売上の情報から仕分を見れば一致していますが、仕分は科目でまとまった数値なので仕入や売上を逆引きすることは困難です。

そうなると日々の仕入や売上の積み上げを追う必要があるのですが、月や期単位で見込みの数値を出そうとしてある程度確度が高いものを載せたりすることで、徐々に人の判断が入らないと作れないような数値に変質していきます。そして「人の判断」は基準が明文化されていなかったり部門毎に異なったりするので、結果的に出てくる数値は現状のありのままではない「勝手に読み替えられた」数値となってしまう、という仕組みなのです。作っている方は決してごまかすつもりではないのですが、求められる数字、例えば「月末時点での売上予測」と言われたときに、言った側も明確にどこまでの基準に達しているものを予測に含めるか曖昧だったり、「この辺り」みたいな感覚的な指標だったりしていることが多々あります。そうやって作られた数値が一人歩きしはじめてしまい、経営判断を誤らせることもあるのです。

そうした人の判断が入らないと作れない数値をシステム化することは不可能です。何故なら抽出する条件が明確ではないからです。データを全てシステムに入れて管理することで、人の判断を介さない、あるいは誰が作っても同じ基準でしか数値を作れない形にすることが「管理指標の統一」であり、本当の見える化と言えるでしょう。

現場のメリットを作る

ここまでの導入目的は「経営側のメリット」です。「担当者が辞めたら」なんて今の担当者には知ったことではありません。多かれ少なかれ現在の手順が変わることは現場にとって負担を強いることになります。それが結果的に業務負荷を減らせることになるとしても、覚えるまでのオーバーヘッドは避けられません。現場のメリットをきちんと作らないと、現場をスムーズに動かすことは難しいです。

「そんなもの上長から業務指示を出せば済む話」かもしれませんが、現場がメリットを享受できないシステム導入で効果を得るのは困難です。上位者は言うだけでいいですが、情シスは一緒に新システムを動かしていかなければいけません。指揮命令系統の異なる情シスは不満と反発のはけ口になりやすいです。反感をかうことが嫌というのではなく、反感をかうことでシステム導入に支障をきたしてはいけないから、現場とも感覚を共有する必要があるのです。

前述したERP導入の目的は、コンサルやらベンダーが経営層を口説き落とすためのものです。現場がその方向と違う方を向かれても困りますが、どのように同じ方向を向かせればよいかが情シスの腕の見せ所でしょう。コンサルやベンダーより現場に近いとこにいて、業務内容・人間関係・性格まで様々なことを加味できるポジションなのですから。

業務の透明性を上げることのメリットとして考えられることとして「上長に現場の業務内容をきちんと理解させること」が挙げられます。生産などは工場長のような現場を知り尽くした管理者がいますが、仕入や販売などは上長が業務のスペシャリストとは限らない場合もあります。現場に長年いる担当者にお任せだったりするので、人によっては自由度があると感じるかもしれませんが、業務負荷もよくわからないので期日設定に無理がある指示を出されたり、業務に対する正当な評価受けられないことも考えられます。最悪の場合、バックオフィスに近い業務のためルーチンワークしかやらないコストセンターのような扱いをするような輩がくる可能性もあります。
業務の透明性を上げることは、そうした上司に「どのような業務を、どれくらいの労力をかけてやっているか、それがどれくらい重要なものなのか」を理解させることでもあります。もちろん自動的には理解されないですから、理解するように仕向ける、あるいは強制的に理解させる場を設けるといった方法を情シスがセッティングしてあげる必要がある場合もあります。

また管理指標を統一することで、経営指標となるデータの取得を上長から指示されて毎月毎月Excelと格闘していたのであれば、上長が自力でデータを出せる仕組みを提供して担当者の負荷を下げるという方法もあり、その実現のために情シスが動くこともあります。

情シス自身が数字を使いこなせ

こうした取り組みの中で、財務的な数値や会計の帳簿、経営指標のデータ等がキーワードになってきます。現場業務の理解と同時に、こうした数値に対しても感度を持っておくことも情シスにとって必要になってくでしょう。

どのようなデータが必要とされるのかわからないのでは「システムを活用するとこういうデータを出すことができる」という提案はできません。経営陣が欲しい数字は何か、管理職が欲しい数字は何か、イメージができるだけでなく自身で使いこなせるくらいの知識があれば対等に話を進めることができます。

情シスは「インフラやコーディングが好きだけど業務や経営に興味が薄いコストセンター」ではなく「経営や業務の話ができてシステムを使って課題を解決できる社内コンサルタント」になることで、情シスの地位を向上させ、自身のキャリアプランを形成し、市場価値を上げる道筋であると考えています。

インフラやコーディングが好きなだけならシステム屋でいたほうが技術的な研鑽も積めますし、より専門的な知識を得ることもできます。サービスを提供される側のユーザー企業にいるのに、技術で本職の人に勝てるわけがありません。
せっかくユーザー企業にいるのだから、経営に関わる全方位に首を突っ込むことができるメリットを活かすほうに舵を切らないと、たかだか社内での技術的優位だけに胡坐をかいていたらもっと優秀な中途社員が現れてあっという間に抜き去られていく可能性もあります。

もちろん情報システム部門ですから技術やテクノロジーに対する感度も必要です。こうして書くと「なんでも理解できるスーパーマンになんか、なれるわけないじゃん！」と思われるかもしれませんが、経営者はこれらの全てに対して責任を持たなければならず、それを情報技術でサポートするIT部門が「生産管理とかあんまよくわかんないんでERPの選定とかちょっと無理です」とか「Webとか専門外なんで広報宣伝に聞いてくれませんか？」では何のために存在しているのかわかりません。

業務部門のいいなりで好き勝手にシステムが乱立することを指をくわえて見ていたくないのなら、「自分ならこう思う」くらいはきちんと持っておく気概が必要ではないでしょうか。

>
>