川崎重工グループ様

百数十社のグループ会社を持つ川崎重工グループでは、従来、グループ関連子会社向けにほぼ“手作り”のクライアント／サーバ（C/S）型基幹業務ソフトを展開。
この旧基幹業務ソフトの運用保守は、グループの情報システム子会社が行っていました。
しかし、旧基幹業務ソフトの導入から約10年、以下の問題点が露呈し始めました。

• 法改正対応等の負荷増大
• プログラム改修時のクライアントPCへのメンテナンスの煩雑さ
• 新規クライアントPC導入時の設定
• 最新OSへの対応等

これらの問題に対応するため、旧基幹業務ソフトに替わる次期システムの検討を開始しました。

グループの情報システム子会社が中心となって、以下の基準で調査を実施しました。

• グループ関連子会社へ展開し易いこと（各社にとってメリットを享受できる）
• 自分達が責任を持って運用保守できること

結果、次世代の中心的な情報基盤となるであろう完全WEB型のアーキテクチャを保持するGRANDITの採用に至り、具体的な展開プランの討議が始まりました。

旧基幹業務ソフトが“手作り”であったため、法改正の都度、プログラムを改修する作業（法改正の状況監視から、法改正決定後には内容調査・対応方法検討・改修・検証・適用）が発生し、自社で対応しなければなりませんでした。
プログラム言語が複数混在していたり、改修に改修を重ねていたりして、法改正に対応する工数は増加する一方で、技術者の確保も困難になってきました。
情報システム子会社では、そのための保守要員や開発要員を専門に抱えていました。

法改正によるプログラム改修は、GRANDIT開発元であるGRANDITが保障しています。これは、パッケージのメリットのひとつであり、従前の“手作り”ソフトと比べると、法改正対応等に対する負荷は激減し、対応も迅速に行えるようになりました。
今後の国際会計基準（IFRS）への対応や、消費税率変更等にも充分対応していけるものと考えています。

旧基幹業務ソフトがクライアント／サーバ（C/S）型であったため、法改正等の際にクライアントPCに対して設定（プログラムの配信）をしなければならないというメンテナンスの煩雑さがありました。新規PC導入時も、同様です。
会社によっては、自ら作業をすることが難しく、情報システム子会社がオンサイト作業として請け負うこともしていました。そのため、スピーディーな対応も難しい状況でした。

GRANDITは、完全WEB型なので、プログラム配信する必要がなく、サーバ側に最新のプログラムを適用するだけで済みます。
各関連子会社にとっても、インストールや設定といった作業から開放され、情報システム子会社にとっても、オンサイトで作業をするといったこともなくなりました。

旧基幹業務ソフトが“手作り”であったため、最新OSへの対応も自社で対応していかなければならず、保守の限界が見えてきました。データベースについても同様で、最新のバージョンに対応できず、サポート切れとなってきました。
特にクライアントＰＣにおいては、新しいOSのバージョンへの対応ができず、一般の人は新しいＰＣへ更改できても、担当者のＰＣだけは古いままといった状況も発生していました。

GRANDITがMicrosoft準拠であることから、OSやデータベースやＩＥが新しいバージョンになっても、GRANDIT開発元であるGRANDITが対応を保障していますので、安心して利用できています。
また、純国産パッケージということで、日本の商習慣にもマッチしているというメリットもあります。

旧基幹業務ソフトでは、上記の保守・運用に関わる作業や、システム維持に多大な工数が掛かっていました。日常の問合せ対応やオンサイトでのサポート等も加わって、各関連会社にとって、保守費用に関してかなりのコストをかけていました。

オンサイトでのサポートや作業がなくなり、これらの問題が最小限の工数で抑えられるようになり、保守に関するTCOの削減に貢献できました。

１サーバを複数社で共用している（下図ソリューションのイメージ図参照）ので、情報セキュリティを強化したい

セキュリティ機能を開発することで対応するのではなく、アカウント管理、承認管理、ログ管理といったGRANDITの標準機能と、サーバ側のAD認証を合わせて、標準のままで実現できました。

限られた期間と予算での内部統制対応に迫られていました。

内部統制機能を開発することで対応することなく、アカウント管理、ログ管理、ワークフロー、承認機能、伝票の履歴管理等、GRANDITが標準で備えている機能で対応できました。

会社によって導入モジュール数が異なりますが、１社当たりおよそ半年から１年です。
グループ全体としては、足掛け5年で、現在１６社が本番稼動（他2社導入作業中）しております。

これまで、以下のように一通りの導入形態を経験しました。

• 経理モジュールのみからスモールスタートし、2次としてモジュールを追加導入
  （モジュールの段階導入順序は様々）
• 導入時期によりバージョンが異なりましたが、順次バージョンアップを実施
  （現在、全ての関連子会社で、同一バージョンを利用）
• グループ内事業再編で、いくつかの子会社に分散していた事業が１社へ集約
  （集約した会社は当該事業セグメントが拡大、集約された会社は消失）
• 関連子会社同士が合併
• ある事業セグメントを分社化

全モジュールの中から各社が利用したいものを選択して順次導入していく形を取りました。
現在では、経理・債権・債務・販売・調達在庫・経費・人事・給与の各モジュール、延べ75モジュールが利用中です。

グループ共通として必須と位置付けた機能は、情報システム子会社が展開に先駆けて開発しましたが、帳票系・出力系では各社個別の要求を完全には避けれないと考えました。
そこで、帳票テンプレートを採用し、個別原価管理モジュールの帳票やデータ出力の開発に加えて、各社個別の帳票系・出力系要望を、帳票テンプレートのエンジンで開発することにしました。

以下の連携を考慮しました。

• 連携決算用で利用しているDIVAへの連携
• 健康保険組合との情報連携
• グループ保険会社への情報連携
• グループ金融会社へのファクタリング関連データの連携

川崎重工本社の財務経理や情報企画と打合せを実施。グループ全体で共通して使用できるマスタと、必須業務の機能を整理しました。

連結決算を意識してグループで共通で使用する勘定科目や取引先のマスタ整備を実施。
グループで共通した業務である個別原価管理については、アドオンモジュールとして開発。その他、グループ全体として必要な機能をいくつか追加開発し、テンプレートとしました。

テンプレート化した勘定科目や取引先のマスタ、個別原価管理アドオンモジュール等の種々開発した機能を利用することで、導入がスムーズにいきました。

できるだけ標準の機能を使用するというポリシーで導入。各社個別の要求を全て開発で実現するのではなく、GAPの部分を標準機能でどうやったら業務が回るかを、お客様と一緒に考えます。開発部分が少なければ、法改正対応やバージョンアップといった時に、対応し易くなります。

要件定義、導入支援、運用支援といった各フェーズにおける進め方や納品物を予め定義。それに則って導入作業を実施し、必要に応じて見直すというPDCAサイクルを回しながら進めました。

業種業態の影響をあまり受けない給与モジュールや、業種業態の似た子会社をまとめて作業（GRANDITの説明等）することにより、コスト削減に貢献することができました。

初期導入費用を利用料形式で分割することができるようにし、選択できるようにしました。

ハードウェア等の資産は、情報システム子会社資産として一括購入し、利用各社で共同利用形態を取ることで、各関連子会社にはハードウェアを購入いただくことなく、各関連子会社が負担する一時費用を大幅に抑えることができました。ハードウェアのサイジングも、初期段階から5年後10年後を見越してリッチな構成とせず、必要最小限のサイジングでスタート。サーバのリソース等は、データセンター側で常に監視しており、都度最適な環境・サイジングとなるよう、見直しを継続中です。

グループ展開を考えていらっしゃる会社様に対して、親会社を含めた推進者と事前に打合せさせていただき、グループで共通で利用できるものをまず整理することから始めさせていただきます。これ自体がノウハウであり、短期導入手法となります。

上記で決めさせていただくのは、グループで共通して使用するマスタ、グループで共通の必須機能です。
これらが決まると、これらは、そのグループに対してのテンプレートとなります。

一方で、帳票テンプレートについては、他社適用はもちろん、SVFを利用した環境で帳票開発のノウハウが、業種に関係なく横展開可能と考えています。

同業他社に横展開できると考えられる機能を以下に列挙します。

• 個別原価管理アドオンモジュール（原価をプロジェクト単位で仕訳データより集計）
• 支払申請伝票を１伝票で複数の部門やプロジェクトを入力できるように変更
• 回収消込の画面にプロジェクトを表示させ、プロジェクトで検索してプロジェクト単位で回収消込できるように変更
• グループ金融会社と調整しながら、ファクタリング機能の追加

以上の結果、短期導入かつコスト削減が可能となりました。このような事前調整から導入に対する方法論（導入手法）は、業種に関係なく横展開可能と考えています。