【第２章】人事情報システム導入の進め方 その６
［ 掲載日 ］2013/06/14
［ 掲載日 ］2013/06/14
- 第６話 導入開発フェーズ（その１）
- まず「パッケージ」についてですが、選択したパッケージあるいは選択したベンダーの推奨するパッケージの特性によって、 導入の手続きがかなり変わってきます。人事給与システムにはいくつかの分類がありますが、 導入する企業の規模や期待する機能によって選択されます。
- 大規模企業では、全社でＥＲＰ（エンタープライズ・リソース・プランニング）パッケージの人事給与システムを選択したり、 中小企業では給与計算のみのパッケージを導入します。従ってそれぞれ選択したパッケージによって、 導入の際に行われる作業は異なってきます。アイコンをクリックするだけでインストールができ、 簡単なスイッチの選択だけで動いてしますものもあれば、膨大なエンジニアやコンサルタントを使って、 １年以上かけて導入のプロジェクトを行うもののあります。金額的にも数十億円から数万円まで千差万別です。
- これは私見ですが、会計（経理事務」を行うアプリケーションよりバリエーションが多く、 お金もかかってしまうことが多いように思います。 勿論、簡単な給与体系で給与支払いを主な仕事としている場合には複雑な要素が入り込む余地は少ないと思います。 ただ、会計が制度会計の実施を主な目的としているのに対して、単なる給与計算ではない「人事管理」を主な目的とする場合、 企業毎に人事管理に対する思い入れが異なることが大きな原因です。特にＥＲＰパッケージのようなアプリケーションを導入する場合、 会計管理の数倍の費用がかかってしまったなどの例もあり、いろいろな問題のタネになることもあります。
- さて前置きはこれくらいにして実際の導入に関わるプロセスを見ていきましょう。 パッケージと手組のシステム（開発）導入の違いを考えた場合、最も大きな違いは、手組はまったくの白紙から作り出しますが、 パッケージはすでにシステムが存在することです。一から作るより効率的にシステムが導入できる所以ではありますが、 システムの導入法に違いがでます。
- １）手組開発の場合の導入手順
- 一から開発する場合、特に人事給与システムだからという違いはなく、一般のシステム開発と導入の方法論は同じです。つまり、
- ・要件定義
・概要設計
・基本設計
・詳細設計
・プログラム開発
・単体テスト
・結合テスト
・システムテスト
・運用テスト
・稼働／運用開始 - の手順でシステムを作っていきます。ただ、情報システム的にいうと、ウォーターフォール（滝の流れのような）と言われる、 仕様（機能や性能）を決めて、あとはどんどん作って完成にもっていく方法と、作ってはユーザにみせ、意見を交わしながら、 つまり修正を加えて完成に近づけていくプロトタイピングという手法をとるか等のバリエーションはあります。 設計にはパッケージにはないデータベースやネットワークの設計といったかなり熟練した技能が必要な作業フェーズがあります。 下手な技術者が作ると「百年の不作」といった状況に陥ることも覚悟しなければなりません。 でも技術者なら一度は挑戦したいものです。
- ２）パッケージの導入手順
- さてパッケージの導入の場合は、要件定義は同じですが、その後のステップは異なるものになります。 すでにシステムが存在する、という一点において、パッケージ導入の場合は異なる導入手法で作業を行います。
- ・要件定義
・ソリューション開発
・プロトタイピング（１回～３回）
－設定データ準備
－パッケージ環境構築
－インプリメンテーション（パラメータ設定）
－ギャップ分析
－評価
－設定修正 ・統合テスト
・移行本番 - すでに企画フェーズなどでは「あるべき姿」が議論され、当社としてはこういう人事給与システムを必要としている、 という目標ができています。要件定義ではそれをシステムを評価する切り口でまとめていきますが、 「導入するシステム」としての形が現れてきます。ここで１）の手組の場合は、 粛々とその目標に向かって構築を進めていけばよろしい訳ですが、パッケージは「すでに存在」しているのです。 そこで「比較」という作業が出てきます。「フィットギャップ」（適応している・していない）の作業です。
- 簡単にいえば、ここで「適応している」機能についてはそのまま使えば良く、適応していない機能についてどうするかを考えていけば良いのです。 多くのパッケージベンダーはこの適応している機能が多い、ということが自社パッケージの競争力優位であると信じて凌ぎを削っています。 １００％適応している場合、どうなるかといえば、インストール（システムがコンピュータ上で使える状態にすること）が終了して、 自社の給与体系等を登録し社員を登録すればすぐ使えてしまうということになります。
- 給与はともかく、人事管理はなかなかそうは問屋が卸さず、ここでいろいろな作業を行うことになります。 つまり「ギャップ」についてどう処理するかが導入プロジェクトの「キモ」になるのです。
- ３）ギャップの処理
- 「パッケージは既に存在している」と申し上げましたが、 それだからこそ、効率的に導入ができる訳ですが、逆に構想しているシステムとは開きも出るという訳です。 このギャップの対処方法は以下の３つです。
- 【作る】
- ない機能なら作れば良い、というのが安直な考え方です。 もちろん条件なしの場合はストレートに正解になるのですが、次のような問題がでます。
- ・お金がかかる
→当たり前ですが、パッケージの値段以外に作る費用が必要になります。
・時間がかかる
→十分な導入期間があれば結構ですが、スケジュールが詰まっている場合には困ります。
・保守が大変
→製品についてはパッケージベンダーが保証するものの、勝手に作ったものまでは面倒みませんと言った具合。 - また作り方ですが、製品に手を入れて修正してしまう（カスタマイズ）方法と情報の連絡通路を確保した上で製品の外側に作る（アドオン開発）方法があります。 カスタマイズについては、製品とは違ったものになるので、パッケージベンダーの支援は受けられません。 一から作ったものと同じになります。一方、アドオン開発は、情報の連絡通路に工夫をすれば、 製品と共存して使っていける状況を作り出すことができます。
- この作るという解決法ですが、パッケージベンダーが不足する機能は大丈夫、当社で作ってあげます、 という甘い言葉をかける場合がありますが、タイミングや機能に問題があります。 つまり機能が他社でも使えるかどうかによって対応が変わりますので、 十分な検討が必要だと思います。 いろいろな要素をベンダーに一任するのはリスクが大きいと思いますがどうでしょう。
- 【仕事のやり方を変える】
- つまりはＢＰＲ（ビジネス・プロセス・リエンジニアリング）です。 ＢＰＲには、仕事を、（廃止する）（移管する）（縮小する）などの選択肢がありますが、 不足している機能が世の中の人事部と比較して特異なものなのかどうかを見定めた上でＢＰＲをしようとする姿勢です。 この部分は従来のシステム開発と大きく違う部分であり、コンサルタントが必要になる所以です。
- 「ＢＰＲには、システムの導入体制とは異なるパワーが必要となってきます。 それは社員の意識を変えたり、制度を変えたりと人間に関わる作業を行うからです。昨今はシステムを入れ換えるのを機会に、 様々な業務改革を行う例が増えており、「チェンジマネジメント」と呼ばれるコンサルテーションの分野も出てきています。 人事給与などのシステムは、勤怠管理や身上異動届けのような社員が全員関わる機能もありますので、 こういった業務改革の機会と捉えている経営者も多くなりました。 ただシステムエンジニアだけでは安直に実行できるものではないので、注意も必要です。
- 【他のやり方を考える】
- システムに機能がないからといって、 作ったり仕事をやめてしまったりする他に方法がないのかどうかよく考えることが重要です。
- 最近の情報システムは、ＯＡツールとの連携がよくできるようになっています。 システム導入以前の会社は、エクセルなどで業務処理を行っていますが、こういう小回りの効くツールを使うのもひとつの方法です。 情報の精度確保などの注意点はありますが、システムの整合性や全体の機能に影響しないように、 パッケージをよく知る技術者と相談の上、妥協点を見いだすのも良い方法です。
- また、まとまった機能であれば、その業務をやるための独立したソフトウェアを検討するのも良いかもしれません。 特に最近では「通勤手当」の管理や社宅管理専門ノソフトウェアなど、 「ソリューション」パックと呼ばれるものも登場しています。
- これら３つの方法ですが、ただひとつだけで押し切るのではなく、３つの解決法を組み合わせて、 最適な解決法を見いだしていくことが、ギャップ解消作業の重要なポイントです。
- ご覧のように、パッケージを導入するということは一から作りあげるシステム開発プロジェクトとは 違う機能が要求されることがご理解頂けるでしょう。