第５３回ＩＢＭユーザー論文 コベルコビジネスサポートでの業務改革の取り組み すぎむら ゆうき 杉村 勇樹 ［略 歴］ ２００８年 コベルコビジネスサポート株式会社入社 現在 業務管理部 課長 システム経験年数 １２年 おおとう ともひさ 大藤 智久 ［略 歴］ ２００２年 コベルコシステム株式会社入社 現在 ＳＯ本部第１サービス部 システム経験年数 １２年 わだ のぶとし 和田 信敏 １９９２年 コベルコシステム株式会社入社 現在 技術・品質統括部 システム経験年数 ２６年 原稿量 本文 １２，３００字 要約 １，２００字 図表 １２枚 1 第５３回ＩＢＭユーザー論文 ＜要 約＞ コベルコビジネスサポート株式会社は、神戸製鋼所グループで、総務系・人事系のアウトソーシン グを受け持っている。神戸製鋼所グループ内での会社の統廃合もあり、現在の会社は、結果として 5 社が統合された会社組織として運営されている。 会社統合により、総務系・人事系のアウトソーシングから、在庫を持つグッズ販売、広告・展示会・ 事務所移転などのプロジェクト、給与事務の代行、旅行業など、事業形態は多岐に至るようになった。 統合はされたものの、実際の業務はもともとの会社の業務プロセスでおこなわれており、現業部門で の業務の統合は遅れていたのが実情である。 基幹システムは、一般に市販されている、販売・購買管理システム、会計システムを利用してきた。 利用実態としては、データ領域をもともとの会社毎に分割していたため、マスターデータの統合はお こなってこなかった。事業によって、受注からの入力であったり、売上からの入力であったりとシス テム利用は多種多様な状態であった。また、売上をそのまま会計システムに入力することもあり、シ ステムが業務プロセスを統制しているとは言えない状況であった。 神戸製鋼所グループでのクラウド推進もあり、会計システムはプライベートクラウド利用のシステ ムに移行した。販売管理システムについても、クラウドの推進、また将来の消費税改定に向けた取り 組みとして更新計画を立てている。ただ、現状の業務プロセスをそのままシステム化しても業務の効 率化はおこなえない。経営管理の視点でも、現在の人手による集計作業が改善されるとは考えにくい 状況であった。アドオン開発により導入コストが増大することも懸念された。 このような状況を回避すべく、全社視点での業務改革は必須であると考えた。販売・購買管理シス テムの導入に合わせて、業務改革の計画を立てたのである。同じ神戸製鋼所グループ会社のコベルコ システムに今回の業務改革の目的について説明した。コベルコシステムと共同で業務改革をおこなう ことになった。 こういった業務改革には、ERP が利用されることが多いという説明を受け、ERP 導入も検討した。 ただ、コスト面での検討から ERP 導入は難しいとの結論に達した。神戸製鋼所のプライベートクラウ ドで利用できるパッケージを利用することで業務改革プロジェクトは進んでいる。 業務改革はシステムのみで決まるものではないと考え、コベルコシステムの担当者にはこのことを 伝えた。汎用パッケージシステムを利用した業務改革・システム導入をおこなうことにした。 本編では、私たちがおこなっている業務改革の方法・プロセスを解説している。当初は各部門の理 解も低かったが、徐々に理解が進んできた。大規模なパッケージ更新が前提でなくとも業務改革が進 んでいる事例として参考にしていただきたいと考えている。私共と同じような事業環境で、業務改革 をおこないたい方々に役に立てば幸いである。 2 第５３回ＩＢＭユーザー論文 目 次 1.はじめに ............................................................................. 4 2.業務改革の背景 ....................................................................... 4 2.1 コベルコビジネスサポートの概要 ..................................................... 4 2.2 業務プロセスと基幹システムの状況 ................................................... 4 2.3 業務改革の必要性 ................................................................... 5 3.事前準備 ............................................................................. 6 3.1 業務改革のゴール・手法の検討 ....................................................... 6 4. 検討プロジェクト開始にあたって ...................................................... 8 4.1 プロジェクトの進め方・スケジュール ................................................. 8 4.2 各部門からのメンバー選出 ........................................................... 9 5.プロジェクトの開始 .................................................................. 10 5.1 現状ヒアリングと差異の認識 ........................................................ 10 5.2 課題認識 .......................................................................... 11 5.3 マスターコード調査 ................................................................ 12 5.4 新業務フロー構築に向けて .......................................................... 13 6.課題解決の方向性と全社業務フロー構築 ................................................ 13 6.1 課題解決の検討 .................................................................... 13 6.2 全社業務フロー案の決定 ............................................................ 14 7.新業務の確定から最終報告まで ........................................................ 16 7.1 各部門とのディスカッション ........................................................ 16 7.2 ディスカッション結果 .............................................................. 16 7.3 最終報告会 ........................................................................ 16 8.実現性の検討 ........................................................................ 17 8.1 デモの実施 ........................................................................ 17 9.まとめ .............................................................................. 19 3 第５３回ＩＢＭユーザー論文 1.はじめに 近年、業改改革には ERP(Enterprise Resource Planning)が利用されることが多くなってきた。ERP では、販売、購買、在庫、生産、出荷の各業務から会計システムへと情報が連携されている。また、 最近では各業界での業務プロセスも組み込まれるなど進化しており、企業で業務プロセスを再構築す るには非常に有効なツールとなってきた。業務改革では、一般的に、部門間での業務の廃止や統合・ 共通化により標準化を重視するものと、企業の独自性を出し、競争力を強化するため、差別化を重視 するものに分けられる。標準化については ERP が持っている業務プロセスを利用し、差別化部分につ いてよりリソースを割いて改革をおこなう考え方である。 ただ、ERP については、それなりの費用もかかるため、 （利用が広がってはきているものの）中堅企 業では利用できない会社が多い実情もある。本編では、システムの検討、業務改革の方法、プロジェ クトの進め方について、コベルコビジネスサポートのケースを説明・解説している。コベルコビジネ スサポートは、業務改革が必要な状況にあり、ERP 導入と一般的な販売・購買管理システムと会計シ ステムの導入を検討した。現在も業務改革プロジェクトは進行中であるが、コベルコビジネスサポー トと同様に業務改革が必要な会社に役に立つことを祈りつつ、本編を寄稿する。 2.業務改革の背景 2.1 コベルコビジネスサポートの概要 コベルコビジネスサポート株式会社（売上 82 億円（2013 年度）、従業員 163 名（2014 年 6 月現在）） は、1983 年に神鋼トラベルサービス株式会社として創業した。2002 年 7 月に 「神鋼トラベルサービ ス(株)」 、 「コベルコオフィスサービス(株)」 、 「(株)コベルコピ一アールセンター」 が統合して現 在のコベルコビジネスサポートが発足した。 その後、 2011 年に(株)コベルコパーソネル、2013 年に(株) ドキュメントサービスなども統合されてきた。売上 82 億円（2013 年度）、従業員 163 名（2014 年 6 月現在）の会社である。 事業内容としては、①神戸製鋼所向けの総務系・人事系事務のアウトソーシング、②事務所用品・ コベルコグッズなどの調達・販売業務、③広告・展示会・事務所移転などのプロジェクト事業、④給 与事務のアウトソーシング、⑤旅行業などをおこなっている。 2.2 業務プロセスと基幹システムの状況 組織としては、本社機能のほか、一部事業での再編はおこなわれているものの、旧組織をベースに した部門で構成されている。従って、業務プロセスは旧組織の色彩が強いのが実態である。また、部 門によっては神戸と東京での業務プロセスに違いがあることもわかっていた（図 1 参照） 。 4 第５３回ＩＢＭユーザー論文 業務プロセスの差異状況 差 異 オフィスサービス部 パーソネルサービス部 ＰＲサービス部 神戸 神戸 神戸 東京 東京 図１ 業務プロセスの差異について 基幹システムは、会計システムの他、販売・購買管理システムを使っている。ただ、利用はデータ 領域を分割し、マスター情報は部門別で運用している状況である。会社として統一した取引先コード を持っていないため、同じ得意先でも違うコードを持っており、得意先別の売上は人による集計作業 が必要である。また、利用部門によって、受注から入力していたり、請求から入力していたりなど、 パッケージの利用に差があることもわかっていた。現在利用しているパッケージにも多くの機能が装 備されているが、利用されている機能は、販売系では、受注管理、請求管理、売上・回収管理、購買 系では、在庫管理、発注・納期管理・支払・債務管理である。ただ、すべての部門がこれらの機能を 利用しているわけではなく、限られた業務でのパッケージの利用となっている。 また、入金業務などはパッケージ機能では現行業務に合わないことから、Web 系のシステムを開発 し利用している状況である（図２参照） 。 パッケージ機能の利用状況 引合/見積 受注管理 納期・出納管理 請求管理 売上・回収管理 入金管理システム （外付けWeb系システム） 在庫管理 発注・納期管理 受領・検収 支払・債務管理 経費支払システム （神戸製鋼所システム） 上記は、パッケージ機能としては提供されているもので、 部分を利用している。 図２ パッケージの利用状況 2.3 業務改革の必要性 神戸製鋼所グループ企業で会計パッケージのクラウド化を推進していること、消費税の段階的な引 き上げへの対応もあり、コベルコビジネスサポートでも、会計システム、販売管理システム、購買管 理システムの入れ替えが計画されている。会計システムについては、他のシステムに先立って、2014 年 4 月より新システムでの運用を開始した。 業務プロセス的にも、統合前の会社でのオペレーションが色濃く残っており、本社機能は統合され たが、管理メッシュが統合されているとは言い難い状況である。マスターのコード体系が違うことも あり、人が各部門の状況に合わせて管理資料を作成している。各部門でのシステムの利用がまちまち であることから、システムによるガバナンスも弱い状況となっている。営業系の決裁についても、会 社規程は守られているものの、受注・売上などの決裁のタイミングは各部門での運用となっている。 購買での発注・検収業務も監査的側面でガバナンスの強化が求められている。 5 第５３回ＩＢＭユーザー論文 このように、日常業務のプロセス面からも、システム更新の面からも、また、会社の風土・求心力 の面からも業務改革が必要と感じている。コベルコビジネスサポートはこの数年、着実に業績を伸ば してきており、さらなる発展のためには、会社が一体となっての各事業に取り組み、コスト競争力の 強化をおこなう必要がある。そのためにも業務改革が必要な状況であった。 3.事前準備 3.1 業務改革のゴール・手法の検討 今回はパッケージ導入も大きな柱ではあるが、業務改革に主眼を置いたシステム導入にしたいと考 えている。今回の改革は、業務管理部主幹ではあるが、各部門と一体となっておこなわなければなら ない。このことを情報システムでのパートナーであるコベルコシステムに伝えプロジェクトを立ち上 げることにした。 コベルコシステム株式会社（従業員 1065 名（2014 年 4 月現在）、売上高 350 億円（2013 年））は、 システムインテグレーターとして、神戸製鋼所および神戸製鋼所グループ企業での情報システムの導 入から保守・運用を担当している。今回、会計のシステム導入を共同でおこなったことから、販売・ 購買管理のシステム導入も共同でおこなう予定である。 業務改革の方法論を話し合う際、コベルコシステムから ERP についての説明を受けた。何度かのデ ィスカッションの末、事前検討として ERP について調査をおこなうことにした。調査してわかったこ とは、ERP は情報連携がすぐれているということだった。お金の情報は受注→売上→請求→入金と連 携されており、また、物の情報も購買→在庫→受注→出荷と連携している。お金の情報は会計伝票と して会計システムにつながっている。物と金の詳細情報も管理会計のデータとして流れていく。さら に魅力的だったのは業界テンプレートで、特にコベルコビジネスサポートでは、プロジェクト系の案 件管理、業績管理に苦労しており、ERP のテンプレートを活用すればこういた悩みも解決できそうに 感じた。ERP についてはもう少し詳しく調査することになった。 ERP の調査からは、業務改革の視点として、①業務プロセスの確立、②情報基盤の整備・確立が重 要であることを学んだ。業務プロセスについては、汎用の販売・購買管理システムは、販売と購買が 密接に連携していないものも多く、伝票処理がおもな目的のため、一部機能のみを利用できる構造に なっているものが多い。コベルコビジネスサポートでも、一部機能のみを利用していたため、同じ部 門で同じ事業内容あっても、神戸と東京で業務プロセス、システムの利用方法が違っていた。また、 プロジェクト案件では販売・購買管理システムはプロジェクト管理のためにはほとんど利用されてい ない実態も認識していた。情報基盤として考えてみても、マスターのコードが各部門で異なっていた り、システムへのデータ入力が受注から、あるいは売上からといったことでデータ精度が悪くなって いたりいた。現状を考えた場合、ERP の調査でいくつか重要なことを学んだ。 ERP の調査はもう少し進めるものの、今回は ERP に頼り過ぎずに業務改革をおこなう必要があると 考えた。コベルコビジネスサポートとしての業務プロセスの確立は、決裁などでのガバナンス強化は 考えられるが、利用部門が自主的に業務プロセスを確立して、部門として運用を維持していく必要が ある。従って、組織的なバックアップを取れる体制づくりが必要である。また、情報基盤の整備の観 点からは、データ領域の統合とコード体系の統一は必須であるものの、データ領域を分けることで業 6 第５３回ＩＢＭユーザー論文 務処理を円滑におこなってきたこともあり、システムの操作性の面からもバックアップが必要と考え た。利用部門が無理のないオペレーションできるよう、システムの利用方法も提案していくことにし た。 今回取り組む業務改革のゴールとして、以下の内容を掲げることにした。 ①コベルコビジネスサポートとしての業務プロセスの構築（集約化、簡素化） ②会社を支える情報基盤の構築（コード統一、データ領域統合、システム利用の標準化） ③業務プロセス維持・情報基盤維持のための組織的バックアップ体制の構築 また、前述の通り、特に ERP による業務プロセス管理を利用できないことも考えなければならず、 推進のために、特に以下のことに注意することにした。 ①部門横断での推進体制の構築 今回の業務改革は、会社としての業務プロセス、管理体系を構築するものであり、部門を横断して の取り組みとなる。現状の業務プロセスから新しい全社業務プロセスを構築するということは、現行 の業務プロセスを廃止したり統合したりする必要が出てくる。また、プロセス上に新たな業務が追加 されることもある。こういったことの判断がおこなえ、各部門を代表するメンバーのアサインが必要 と判断した。 ②経営者層からのタイムリーなメッセージ 今回の取り組みは業務プロセスを直接扱うものであり、ボトムアップ的な手法が必要と考えている。 ただ、最終的には全社視点の改革であり、経営に貢献するものである。全社的な推進力を維持するた めにも経営者層からのメッセージを得ることも重要と考えた。 ③システムサポート 新たな業務プロセスを構築するということは、システムを初めての利用するエンドユーザーも出て くる。現在のシステム利用とは違った使い方になることも考えられる。また、現在の販売・購買シス テムについても機能面で不足している部分について外付けのシステムを利用している。例えば、入金 の消し込みは、振り込み単位と消し込みをおこなう部門を一致させるために開発したシステムがある。 また、神戸製鋼所との出納業務のために開発したシステムも利用している。そのためにも導入するシ ステムは、操作面でも新業務プロセスに耐えられるものにすることが必要と考えた。これらのことま とめると、図３のようになる。大方針を決めることで、今後発生するさまざまな問題を検討する際、 方向を見失わないようにしようと考えたのである。 7 第５３回ＩＢＭユーザー論文 業務改革の目的と改革プロセスについて 業務改革の目的 会社一体オペレーションでの競争力強化 ・競争力をささえる経営・業務指標の精度向上 業務改革での取り組み ①コベルコビジネスサポートとしての業務プロセスの構築（集約化、簡素化） ②会社を支える情報基盤の構築（コード統一、データ領域統合、システム利用の標準化） ③業務プロセス維持・情報基盤維持のための組織的バックアップ体制の構築 成功のために特に気をつけること 各部横断での推進体制の構築 経営者層からのタイムリーなメッセージ 会社としての業務プロセスを定義し維持するために は各部門より意思決定できるメンバーを出してもら うことが必要 業務改革推進には具体的な取り組みはボトムアッ プで、方針はトップダウンでおこなうことが必要 システムサポート 情報基盤の提供の他、新たに業務プロセスをサポートする 操作性にも十分配慮が必要 図３ 業務改革の目的と改革プロセスについて 4. 検討プロジェクト開始にあたって 4.1 プロジェクトの進め方・スケジュール 各部門からのメンバー選出に先立ち、各ラインに今回の活動について説明が必要であった。説明を おこなうにあたり、プロジェクトの進め方を整理した。検討プロセスとしては、現状確認からおこな うことにした。業務管理部として、業務プロセスの概要については認識しているが、詳細部分、また、 各部門の問題認識など理解していない部分もあり、現状認識のプロセスは必要と考えた。その際、各 部門、各拠点での業務プロセスについても差異の確認をおこなうことにした。 現状確認後は、新たな業務プロセスの構築になるが、全社視点での業務プロセスとなるため、まず は本社側から案を提示することにした。新業務プロセスの確定には、社内ルールの改定などの業務要 件の見直しとサポートするシステム要件の検討が必要と考えた。これらの討議を各部とおこなう計画 を立てた（図４参照） 。 業務改革検討のプロセス ヒアリング 【差異】 部門内（神戸・東京・グループ）、部 門間での差異を確認 差異の解消方法を検討 ・システム対応 ・業務対応 【課題】 差異の解決に必要な課題の認識 【課題】 経営管理上、業務統制上解決が 必要な課題の認識 ディスカッション① ディスカッション② 業務の基本パターンの 提示・討議 業務の基本パターンの確認 業務改革ポイントの討議 （受注、発注、入金） 課題の解決方法を検討 ・業務ルール ・業務プロセス ・システムサポート 管理プロセスの討議 （見積書、決裁、損益管理） 図４ 業務改革検討のプロセス 8 →新業務フロー（基本パターン） 業務要件の確認、 規定見直しの方向性の確認 →業務要件 システム要件の確認 →システム要件 第５３回ＩＢＭユーザー論文 活動期間についても検討をおこなった。パッケージの導入期間などを考えた場合、今回の活動は、 3 ケ月程度で完了させた方がいいと考えた。コベルコシステムの担当者とも話をして、一般的な検討 期間であることを確認した。現業部門との話の他、キックオフ、中間報告、最終報告などのイベント・ 報告会もスケジュールに加えることが必要と考えた。 スケジュール 2014年 1 7 ７月 14 主要マイルストーン 21 28 4 ８月 11 18 25 1 8 中間報告会 キックオフ ９月 15 22 29 最終確認 6 １０月 13 20 27 最終報告会 概要ヒヤリング システムヒヤリング 業 務 プ ロ セ ス 共 通 コ ー ド 基本業務確認 集約パターン作成 集約パターン説明 業務変更、 システム要件整理 業務変更内容の確認 コード一覧整理、 影響範囲調査 新コード体系検討 影響検討、規定検討 図５ スケジュール ERP については継続して調査はおこなっていた。ただ、どこかの段階で、ERP ベースでいくのか、 汎用パケージベースでいくのか結論を出さなければならないことも理解していた。ERP の調査は対象 となるパッケージ選定を主におこなっていた。デモを中心にパッケージ選定をおこなった。各社との ヒアリングベースでの導入費用とデモでの業種対応からこの段階で 1 社に絞り込んでいた。実際の画 面を見た印象として、ERP の画面は業務の流れで構成されているのに対し、汎用パッケージでは伝票 イメージで画面がつくられているような印象を受けた。最終判断の時期を検討したが、現状ヒアリン グの段階では結論を出す必要があると考えた。 4.2 各部門からのメンバー選出 今回は、部門横断でのプロジェクトとなることから、メンバーの選出は慎重におこなうことにした。 実際に各部からメンバーを選出してもらう前に、部長会で今回の活動について連絡し、理解を求める ことにした。実際に報告してみると、 「システム刷新のプロジェクト」で「各部からシステム要件を 出せばいい」と考えているライン長が多いことがわかった。実際、業務プロセスは各部で考えてきた こともあり、会計システムの刷新、販売・購買システムの刷新と全社的な業務プロセスの見直し・構 築との関係が理解しにくいものであった。各ラインに対しては継続して業務改革の必要性を説明して いくことにした。並行して、業務管理部長の名前でメンバー選定を依頼することにした。推進責任者 は業務管理部で置くことになった。各部からは３～４名のグループリーダー、業務担当者を選出して もらった（図６参照）。結果として、今回の活動に合ったメンバーを選出してもらうことができた。 全体のスケジュールが確定し、検討メンバーの選出もおこなえたのでプロジェクトを開始することが できる状態になった。 9 第５３回ＩＢＭユーザー論文 推進体制 プロジェクトオーナー 業務管理部部長 プロジェクトマネージャー コベルコシステム責任者 業務管理部課長 プロジェクト推進チーム 業務プロセスチーム 業務管理部課長 部員３名 PRサービス部 オフィスサービス部 パーソネルサービス部 ツーリスト部（コード統合） コベルコシステム実施者 図６ 推進体制 5.プロジェクトの開始 5.1 現状ヒアリングと差異の認識 キックオフ会議を実施し、プロジェクトは開始した。現状ヒアリングは、各部門、各拠点に分けて 実施した。毎回出席者が違うこともあり、今回のプロジェクトの目的・ゴールについても説明をその 都度おこなった。当初は、 「現行のシステムの利用状況について評価されるのではないか」、また、「新 システムへの要望を今のうちに伝えよう」という雰囲気があった。今回のプロジェクトの意味とスケ ジュールについて説明し、現行の業務プロセス、システムの利用方法、業務管理方法について事実を 確認していった。 ヒアリングを進めていくと、同じ部門でも、神戸-東京、グループ、取扱サービス（商品）、コベル コビジネスサポートへの統合時期などで業務が違っていることがわかった。オフィスサービス部の例 でも取扱サービス（商品）の違いで業務プロセスが違っていた。 オフィスサービスの例でいえば、さらに、 ・マスターデータ管理（商品コード、顧客コード） ・受注の認識とシステムへの入力タイミング ・税区分（内税、外税） ・在庫管理 ・実費精算の方法 ・検収方法（請求書ベースまたは支払通知書ベース） ・支払システム（パッケージまたは神戸製鋼所グループシステム） などの違いがあることがわかった。差異については、取扱サービス（商品）での大きな違いを業務フ ローで（図７参照）現し、さらに細分化させている要素については個別に管理していくことにした。 10 第５３回ＩＢＭユーザー論文 業務プロセス（現状） 業務委託系 販売業務 引合／見積 マニュアル 半期 受注管理 契約交渉 納期・出荷管理 請求管理 契約 都度 経費集計 受注 販売・債権債務 請求書発行 見積・契約管理 購買業務 売上・回収管理 在庫管理 発注・納期管理 マニュアル 受領・検収 入金処理 支払・債務管理 経費集計 発注 購買・KREPAS 支払依頼 物品販売系 引合／見積 販売業務 マニュアル 引合 受注管理 納期・出荷管理 請求管理 発注・納期管理 受領・検収 受注 販売・債権債務 請求書発行 見積・契約管理 購買業務 売上・回収管理 マニュアル 見積 在庫管理 入金処理 支払・債務管理 在庫確認 購買・KREPAS 発注 支払依頼 プロジェクト系 引合／見積 販売業務 マニュアル 納期・出荷管理 見積交渉 請求管理 売上・回収管理 費用集計 受注 販売・債権債務 購買業務 受注管理 請求書発行 見積・契約管理 マニュアル 在庫管理 発注・納期管理 見積収集 受領・検収 入金処理 支払・債務管理 費用集計 発注 購買・KREPAS 支払依頼 図７ オフィスサービス部でのサービス別業務フロー 5.2 課題認識 予想より多くの業務プロセスが存在し、部門・拠点・商品サービスでの差異が大きいことも確認で きた。差異は属人的なことに起因しているものも多く、課題とは分離して認識することにした。差異 の解消には業務ルールの見直しが必要なものもあり、それらは課題として認識した。差異解消、課題 解決のアプローチは、図８のように考えた。 ①【差異】各部門でのグループ・拠点で違いのあるもの 同じ部門の中で、グループ、拠点によって、おもに属人的な原因で業務プロセスの差異が発生して いるもの 例：顧客情報管理は、グループによって改廃時期が違っている 商品の税区分の内税・外税の利用方法が違っている 11 第５３回ＩＢＭユーザー論文 支払処理を汎用パッケージ、神戸製鋼所システムの両方でおこなっている このような内容のものは、新業務フロー時に統一するよう計画することにした。システムサポート としては、操作教育を充実させることなどが考えられる。 ②【課題】差異の解決に必要なもの 差異を解決するために、業務ルールの見直し・徹底が必要なもの、また、システム機能の見直しが 必要なもの 例：受注入力のタイミングが拠点で違っている 入金消し込みが、入金単位の関係で、汎用パッケージと外付けシステムが使われている 受注入力のタイミングについては、業務管理マニュアルの見直し、入金消し込みについては、シス テム機能の再確認が必要となる。これらのことを解決する目処を立てて、新業務フローを提案するこ とにした。 ③【課題】経営管理上、業務統制上解決が必要なもの 差異とは別に、経営管理上、また業務統制上、解決しなければならない問題があり、今回の検討に 含めることとした。 例：見積書など会社としてノウハウの共有をおこなうべきものが個人管理されている 受注決裁など、実施はされているもののタイミングが統一できていない 損益管理で案件別と月別に明確な区別がない 上記内容のものは、社内コンセンサスを得なければならないものもあり、実施タイミングをすぐに 決められないものもある。優先順位をつけて、今回のシステム刷新で実施するものについては、業務 の見直しとシステム機能調査をおこなうことにした。 課題認識と検討の方向性 【差異】 ①各部で、グループ・神戸・東 京で違いのあるもの 差異の解決方法を検討 ・システム対応 ・業務対応 部門間での差異を確認 【課題】 ②差異の解決に必要なもの 解決方法の検討 ・システム対応 ・業務対応 【課題】 ③経営管理上、業務統制上 解決が必要なもの 解決方法の検討 ・業務ルール ・業務プロセス 図８ 集約フローの決定 課題認識と検討の方向性 5.3 マスターコード調査 マスターコードについて、並行して調査をおこなった。事前認識の通り、部門・拠点で違うコード 体系で運用されていた（表１参照） 。データ領域を分けて運用していることもあり、マスターコード の登録・改廃は各担当者にまかされていた。新規登録などの申請ルールはあるが、内容は違っていた。 また、特にデータ削除について統一のルールがないために、ある部門ではデータ数が多くなっていた。 担当者ベースでは、データの改廃をおこなう時間的な余裕がなく、困っている状況だった。こういっ 12 第５３回ＩＢＭユーザー論文 た意味からも会社としての登録・改廃ルールの構築が必要と思われた。 表１ マスターコード一覧 部門 得意先コード 仕入先コード オフィスサービス部 DS）5桁（東京は7桁）、OS）4 桁のコード体系理 ・神鋼本体・グループ会社・ その他と分類 ・神鋼本体は事業所毎 DS）5桁 OS）4桁 ・神鋼本体・グループ会社・ その他と分類 パーソネルサービス部 4桁 ・コベルコシステムなど少数 4桁 4桁 ・連結決算用のコードにて登 会社を管理 ・組織グループ・拠点毎に採 ・利用するコードの大半は業 録 番 務受託料 ＰＲサービス部 4桁 ・神鋼本体・グループ会社・ その他・個人を管理 5桁 ・五十音順にコード採番 ・JOB No単位に採番 ・仕事内容内コードにて業務 概要レベルの分類を表現 7桁 ・明確な採番ルールなし ・神鋼本体は各部門毎（整理 No毎）の採番 7桁 1桁 ・顧客マスタとして、得意先・ ・ツーリスト部内の業務グ 仕入先と併せて管理 ルーブ単位に採番 ・法人種別フラグ（仕入先）に て、仕入先情報として特定 6桁 ・旅行手配商品毎に採番 ツーリスト部 部署コード 商品コード DS）8桁（東京は7桁）、OS）4 桁 ・取引商品毎に採番 ・OSは税込でマスタ管理 5.4 新業務フロー構築に向けて 現状調査が終了し、課題について解決方法を見出す段階になってきた。ERP を利用した業務改革を おこなうのか、汎用パッケージを利用するのかを決めなければならない。ERP を利用した場合、ERP の業務プロセスについて、より調査して新業務フローを構築する必要がある。汎用パッケージを利用 する場合、業務プロセスをパッケージだけで統制することは難しく、また、パッケージが持つ機能も 若干劣ることを考えると、実現性について、より検討が必要で、定着化についても十分考慮しなけれ ばならない。 デモも何度か見て、機能的な違いは理解できたので、最終的には導入費用での判断を考えていた。 正式な見積りは要件も決まっていないことから依頼することが難しいと考え、過去実績を紹介いただ くようお願いした。結果としては、 「ERP 導入は難しい」という判断を下した。決めたことで、ERP に 頼らない業務改革を実感した。 6.課題解決の方向性と全社業務フロー構築 6.1 課題解決の検討 プロジェクト推進チームでの検討が始まった。ヒアリングの際、問題・課題と認識したものを表形 式で一覧にした。その問題・課題について、差異、課題に分け、各自が検討の方向性について記述し ていった。検討の方向性としては、 「今回のシステム刷新で対応すべき」「業務管理マニュアルの整備 が必要」 「コンセンサスを得るためにディスカッションが必要」「システムで対応できるか調査する」 などのものであった。また、検討の方向性について、①業務で対応するもの、②システムで対応する もの、③業務・システムの両方で対応するもの、に分類していった。 チーム内で問題・課題を検討していく中で、現状認識と解決の方向性についてコンセンサスができ ていった。 ①販売・購買管理システムの機能を最大限に生かす 会計システムにつなぐため、売上からの入力はなされているが、受注情報の入力は一部のみであっ 13 第５３回ＩＢＭユーザー論文 た。汎用パッケージの機能も十分に生かしきれていないことがわかった。明細管理などは個人でおこ なわれており、販売・購買管理システムに入力するためのデータ管理も多く存在していた。受注～請 求～売上～入金の一連の業務でシステムの利用を推進し、全社業務プロセスの定着を推進していくこ とで一致した。 ②会社としてのノウハウの共有をおこなう 会社としての知的財産の一つである見積り情報について、個人での管理となっていることがわかっ た。特にプロジェクト案件では、見積り情報から進捗管理の方法は会社としての重要なノウハウであ り、蓄積と共有が必要ということで一致した。 ③ガバナンスを強化する 見積決裁、受注決裁などは、おこなわれてはいるものの、タイミングなどは統一されているとは言 えない状況であった。また、在庫管理についても一部はシステム外で管理し、決算時に実地棚卸をし ているものもあった。ガバナンスの強化は必須であることを確認した。 ④システム利用基準をつくる 販売・購買システム以外に入金管理システム、経費支払システムの利用もおこなっていた。これら のシステムは重複した機能を持っており、利用する基準が曖昧であった。そのために業務プロセスが 複数存在することになっていた。特に入金管理システムについては廃止する方向で検討していくこと で一致した。 ⑤経営管理情報を提供する 販売・購買システムへの入力がまちまちであること、マスターコードが違っていることの理由によ り、経営管理のための情報は手作業での集計となっていた。手作業での集計は残るとしても、基礎と なる情報はシステムから簡単に取り出せるようにする方向で検討することになった。 6.2 全社業務フロー案の決定 問題・課題を検討し、もともとの業務改革の目的に合わせた時、各部門に提示する業務フローは、 “業務委託” 、 “物品販売” “プロジェクト”の 3 つを基本にすることにした（図９参照）。商品・サー ビスでは、大きくはこのカテゴリーに集約できると考えたからである。業務フローとは別に、見積り、 受注、請求、入金など個別に話し合わなければならない業務もあった。これらの資料を作成し、中間 報告会、各部門とのディスカッションの準備を進めた。 14 第５３回ＩＢＭユーザー論文 新業務プロセス 業務委託 販売業務 マニュアル 販売管理 システム 購買業務 マニュアル SA-010 引合／見積 OR-040 受注管理 OR-050 納期管理 OR-060 出荷管理 契約交渉 見積交渉 OR-070 請求管理 OR-080 売上管理 OR-090 回収管理 費用集計 表計算 契約・受注 検収受領 売上 請求書発行 入金処理 月次 見積管理 ・契約管理 在庫管理 発注管理 ・納期管理 見積収集 受領・検収 支払・債務管理 費用集計 発注 表計算 購買管理 システム 発注 検収（請求書） 支払依頼 在庫登録・払出 物品販売 販売業務 マニュアル 販売管理 システム 購買業務 SA-010 引合／見積 OR-040 受注管理 OR-050 納期管理 OR-060 出荷管理 OR-070 請求管理 OR-080 売上管理 OR-090 回収管理 見積交渉 見積交渉 受注 売上 請求書発行 入金処理 月次/都度 見積管理 ・契約管理 在庫管理 発注管理 ・納期管理 受領・検収 支払・債務管理 マニュアル 見積収集 購買管理 システム 在庫確認・払出 在庫確認 在庫登録 出荷 検収（検収書・ 請求書） 発注 支払依頼 プロジェクト 販売業務 SA-010 引合／見積 OR-040 受注管理 OR-050 納期管理 OR-060 出荷管理 OR-070 請求管理 OR-080 売上管理 OR-090 回収管理 マニュアル 見積交渉 販売管理 システム 購買業務 マニュアル 購買管理 システム 見積交渉 プロジェクト 番号登録 受注 見積管理 ・契約管理 在庫管理 検収受領 発注管理 ・納期管理 売上 請求書発行 入金処理 月次/都度 受領・検収 支払・債務管理 見積収集 発注 図９ 新業務フロー 15 検収（請求書） 支払依頼 第５３回ＩＢＭユーザー論文 7.新業務の確定から最終報告まで 7.1 各部門とのディスカッション 中間報告会では、現状業務、課題認識、検討の方向性などを報告した。今回のプロジェクトのゴー ルも再度説明し、今後の予定について連絡した。 新業務のディスカッションは、各部 1 ケ所でおこなうことにした。拠点間の差異をなくすこともあ り、face-to-face の方が TV 会議よりすぐれていると判断した。準備した資料で、①問題・課題の認 識と解決の方向性、②業務プロセス（3 パターン）に集約していきたいこと、③各業務で変更点、に ついて説明した。 7.2 ディスカッション結果 各部とのディスカッションでは、推進チームが提案する業務改革について、方向性について異論は 出なかった。「見積書の管理を新システムでおこないたい」など積極的な意見も出た。ただ、これま でシステムではおこなってこなかった業務については、「イメージがつかない」という声も多く聞か れた。また、各担当者が工夫しておこなってきた業務については、「新しいシステムを利用した場合 どのようになるのか」という質問も多かった。各部からのメンバーは新業務フローでの業務を意識し 始めており、システムを使った実現性の検証は必須であると考えた。ここまで進めてきて、“総論賛 成。各論反対。 ”の状態になることは大きな懸念事項だった。今回の検討フェーズ後にすぐに実現性 検証のデモをおこなうことを決めた。 また、新業務フローで業務をおこなうにあたり、業務管理マニュアルなどの会社規程の見直しが必 要な事項もあった。会社規程の見直しについては分化会のタスクを発足させることにした。また、各 種決裁について、システムの利用しガバナンスを強化することにした。今回、特に新業務プロセスを 定着させるためには、会社規程の見直しと決裁による業務プロセス管理は必須であると考えた。汎用 パッケージの利用ということで、このフェーズ後もこれらのことには非常に注意を払いながら業務改 革を進めていった。 7.3 最終報告会 業務改革は継続するものの検討プロジェクトとしては、一旦、最終報告を出すこととなった。最終 報告書には以下の内容で報告会を開催した。 ①検討の経緯 ②問題・課題の認識 ③改革の方向性 ④新業務フロー ⑤主な業務変更点・業務要件 ⑥システム要件 ⑦今後のスケジュール 推進チームとしては、 “③改革の方向性”については特に強調したいと考えていた（図１０参照）。今 回のフェーズによって業務改革について具体的にイメージできるようになった。方向性については特 に社内での認知が上がるよう継続して発信していくべきと考えた。 16 第５３回ＩＢＭユーザー論文 改革の方向性 １．会社として一貫性のある業務プロセスの構築 会社として統一した、一貫性のある業務プロセスを構築するためには、①基本業務フローを集約し、②部門内・部門間差異を解消す ることが重要です。差異の大きかった受注入力からの販売仕入システムの利用、データ領域の統合は必須要件です。 ２．コンプライアンスを重視した業務遂行 現在は、コンプライアンスを重視した経営が求められております。コンプライアンス・プロセスを含んだ業務プロセスの構築が必要で す。販売仕入システム導入の際に、見積書・受注段階決裁の強化、在庫品管理の強化を組み込みます。 ３．販売管理精度向上による経営貢献 会社経営には、“経営状況の見える化”が必要です。受注状況をタイムリーに更新し、売上の推移を分析することで、経営層の意思 決定に貢献することが可能です。また、損益管理をタイムリーにおこなえる仕組づくりを推進し、その精度向上に貢献します。 ４．知識・ノウハウの共有化をはかる基盤の構築 事業継続・発展のためには会社として知識・ノウハウを蓄積し、共有していく必要があります。販売仕入システムの導入にともない、 知識・ノウハウの蓄積・共有化を推進していきます。具体的には見積情報の共有からおこなっていきます。 図１０ 改革の方向性 情報基盤の要であるマスターコードについても報告をおこなった。神戸製鋼所グループでも連結決 算の高度化を目的に取引先コードの整理をおこなっており、利用できるコードは利用することにした。 表２ 新マスターコード体系 コード 方針 得意先コード 神鋼グループ標準取引先コードを適用する 仕入先コード 神鋼グループ標準取引先コードを適用する 部署コード 4桁の部署コードとして、新規設定する 商品コード 10桁の商品コードとして、新規設定する。 ※１ 旅行業システムは6桁定義となるため、 旅行業の商品コードは統合しない ※２ 仕入先の商品コードを流用する取引の 場合は、右記体系を適用しない コード体系 1 2 3 4 5 会社コード ２ 部コード １ ２ 部コード ３ 7 8 9 事業所コード 0～9,A～Z １ 6 10 自由採番 0～9,A～Z ４ グループコード ３ ４ 5 6 7 8 9 10 任意採番 8.実現性の検討 8.1 デモの実施 各部とのディスカッションの際に決定したデモを実施することになった。決定した新業務フローに ついて、汎用パッケージシステムを実際に操作し、実現性を確認してもらうことを目的とした。 デモを実施するにあたり、①開催準備における考慮点、②デモシナリオにおける考慮点について細 心の注意を払い推進した。 ①開催準備における考慮点 ・より短期間で実現性を確認できるよう、現行業務でのシステム登録経験有無に関わらず、今回のプ 17 第５３回ＩＢＭユーザー論文 ロジェクト主旨を把握した各部門メンバーを参加対象として選定した。また、詳細な操作や画面表示 内容等については、システム導入局面で議論する前提であることをデモ開始前に伝達した。これらの ことより、デモがスムーズに進行されるよう配慮した。 ・システムを初めて利用するエンドユーザーも参加対象者となる為、より簡単にイメージを把握して もらうことを念頭に置いた。決定した全社業務フローをベースとした、より業務に近いデモ実施シナ リオが必要になる。そのため、汎用パッケージシステムのベンダーではなく、これまでの業務改革検 討を共に実施したコベルコシステムへデモ開催を依頼した。 ②デモシナリオ作成における考慮点 課題認識した業務について、より具体的なデータを用い実業務の流れを考慮した操作を実現するシ ナリオ作成に注力した。下記三点については特に時間をかけてデモを実施した。 ＜入金消し込み業務＞ 業務フロー検討時より、既存システムと同様の入金消し込み業務は、銀行の入金データを加工しな ければ実施できないことが判明していた。銀行からの入金データを加工することで、汎用パッケージ システムで既存業務と同手順で実行できるので、デモをおこなう際、加工したイメージのデータを準 備した。汎用パッケージシステムへのデータアップロードから、実際の入金消し込みまでの一連の流 れを確認できるシナリオを作成した。 ＜見積・受注決裁業務＞ 決裁に関しては、規程は存在しているもののシステムによる制約が存在しなかったため、完全に順 守できている状況ではなかった。汎用パッケージシステム導入に際し、決裁機能を活用することで決 裁業務を強化する方向で検討していた。デモ実施時は、実際の見積・受注データおよび、データ入力 者・承認者情報を準備し、伝票起票→承認の流れを実現した。また、決裁済・未決裁状態での見積書・ 注文書出力や後続の売上・仕入計上処理の状況を確認できるようにし、決裁者不在の状況でも影響な く業務遂行できることを確認できるシナリオを作成した。 ＜損益管理業務＞ 業務報告の際、各部が詳細な損益情報を確認するため、データ加工業務が少なからず発生していた。 汎用パッケージシステムの損益管理機能を活用することで、より精緻でかつ効率的な損益管理の実現 を確認してもらう必要があった。そのため、各伝票入力の際に、案件番号や、商品区分といった損益 管理を意識した入力をおこなうことを考えた。また、各種内訳表出力や、集計表出力時に、実業務を 意識した出力条件を指定した帳票出力処理を実施するシナリオを作成した。 上記①、②を考慮することで、決定した全社業務フローの実現性を確認することができた。システ ムを初めて利用するメンバーにおいても、既存業務との変更が極小化されていることへの理解が進ん だ。結果として、新システム利用についての懸念は少なくなったと感じている。また、後続の汎用パ ッケージシステム導入局面での検討事項や、現行業務の事前調査事項の観点についても再認識できた。 18 第５３回ＩＢＭユーザー論文 9.まとめ 今回、システム要件のヒアリングからではなく、会社としての業務のあり方についてディスカッシ ョンすることからプロジェクトをスタートさせた。ERP の良さも認識しながら、汎用パッケージを利 用した業務改革を模索した。業務改革がなぜ必要なのか、また、経営に貢献できる情報基盤は何なの かということについて、検討メンバーと話を進めてきた。その結果、業務改革の必要性と方向性につ いては社内でのコンセンサスは高まった。また、実現性の検証をおこなうことで、ユーザー部門の懸 念もある程度払拭することができた。 その後の、システムの要件定義では、今回の活動でシステム要件となったものに注力できている。 ただ、業務改革プロジェクトはまだ進行中である。業務ルールについてもまだ検討中のものも存在す る。 さらに重要なことは、検討メンバーで決めた業務プロセス、情報基盤について定着させることであ る。このことを考えると、まだ、業務改革は緒に就いたばかりである。今後も業務改革を進めるには いくつもの課題が出てくることが予想される。その時には今回の活動での大方針に立ち返り、推進し ていく決意である。 19
© Copyright 2024 Paperzz
