【第２章】人事情報システム導入の進め方 その８
［ 掲載日 ］2013/12/03
［ 掲載日 ］2013/12/03
- 今回は、要件定義とパッケージの持つ機能との差分、ギャップについてです。
- このギャップについてどう対処するかが、パッケージアプローチの要諦です。『ない機能は作る』などと簡単に言ってはいけません。 特に人事給与は企業にとって大事なシステムではありますが、その特異性によって競争力に大きな違いがでることは稀です。 業界でもトップを行く企業が他ではみられない特殊な制度とその支援システムを持っていることには興味が沸きますが、 そう多い例ではないでしょう。人事の戦略性とは希少なシステムを持つことではなく、企業戦略に必要な人材を持っているとか、 絶妙なタイミングで調達配置することができるとか、システムではなくその運用にかかっていると思われるからです。 確かに良い道具を持っていることは理想ですが、道具は道具でしかないことをよくお分かりではないですか。
- 第８話 導入開発フェーズ（その３）
- ４）ギャップ
- 一般のシステム開発のプロジェクトと異なり、パッケージアプローチは「モノ」があるのが大きな違いと、前回でもお話ししました。 導入したい、或いはすべきシステムの形を「あるべき姿」とか言いますが、導入フェーズ前に、 要件定義で作られたシステムの目標とパッケージを比較するところから始めます。 ここでその比較を行った結果ハッキリしてくるのが「ギャップ」と呼ばれる「差分」です。
- 「差分（ギャップ）」は埋められるべきものですが、どう飛び越えるか埋めるかについては、いくつか方法があります。 その方法論を駆使してギャップを乗り越えていく手伝いをするのが「コンサルタント」の大きな役目です。 コンサルタントの要件としては、パッケージを知っている、人事給与の仕事をしっている、情報システムを知っている、 の３つのポイントが必要ですが、それはこれらの要素を使ってプロジェクトの舵取りをしていくからです。
- ギャップの要素の多くは「機能」といわれる「仕事をこなす能力」です。 機能は情報システムにおいては、データの網羅性であったり、業務プロセスを実現するアプリケーションであったりします。 端的にいえば、人事異動を行うための人事異動を支援する様々な業務処理要件があるか、例えば異動要員を抽出する機能であったり、 辞令を作成する機能であったり、社員の履歴に異動情報を格納する機能であったりする訳です。
- ５）ギャップ対処法
- システム開発ではもともと白紙から作る訳ですから、要件全部がギャップになります。その機能を作る作らないの判断は、 「あるべき姿」に定義されているかどうか、つまり必要としているか否かです。システム開発は、 作成された瞬間は要件定義とできたものは１００％重なっていることになります。 しかしパッケージアプローチの場合は、それがズレている訳で、必要としていない部分もあることになります。 不必要なものまで備わっているが、必要としている機能がない、という状況がズレが生じている状況です。
- ギャップの対処法は以下の３つに集約されます。
- ⅰ）仕事をやり方自体を変えて、機能を使わなくて良いようにする
ⅱ）機能を別の方法で補う
ⅲ）機能を追加で開発する - コンサルタントは、企業の状況をみて様々な制約などを勘案して、どれが最も適当かを企業に進言していきます。 従って、企業ごとにどれが良いかは異なるものであり、一概にはいえません。 ではそれぞれの方法について見ていきましょう。
- ６）いわゆるＢＰＲ
- 業務の情報システムを導入するということは、業務を見直す良い機会であるとする考え方があります。 業務改革が先かシステムを導入することが先かといえば、システムが実態の業務を反映し支援することを考えれば、 おのずと答えが見えるはずですが、実際のケースではなかなかうまくいきません。これは、システムを導入する目的に関わることなので、 ここでは多くは述べませんが、これを機会にという動機では大きくＢＰＲ（ビジネスプロセスリエンジニアリング）を行う事に期待はできないでしょう。 ＢＰＲはそう簡単にはできないからです。
- ＢＰＲをギャップの解消策にすることは、いうは易く行うは難しで、なかなか難しいことです。 同時にＢＰＲのプロジェクトを平行的に行うことが必要になると思います。それは、ＢＰＲ案を作ってギャップを埋めるデザインをしても、 実際をそれをインプリ（導入）するのはユーザであるからです。 従って、主役であるユーザが中心とするプロジェクトを起動させることが必要です。
- はじめからこれを大きな要素として人事情報システムを導入するのであれば、当然、 システムの導入プロジェクトと同時にＢＰＲのプロジェクトが平行して動いているはずで、 これなくして「ＢＰＲでギャップを解消していきましょう」とする提案をすることはあり得ません。 仕事を変える提案をすることは簡単ですが、変えるのは大変なことです。
- しかしながら、情報システムを導入するというこは難しくいうと「構造化する」ということですから、 無駄が多く精度の悪い仕事のやり方をそのまま踏襲するというのも考えものです。システム化とは業務のやり方を固定化することでもあるので、 ある意味では悪い仕事のやり方をそのまま固定化してしまうことにもつながりかねません。 パッケージは、少なくとも理屈に合わない仕事のやり方をコンピュータに載せるということも考えにくいので、 現行の仕事のやり方とシステムの持つやり方とにギャップがある場合は、現状の仕事が本当に良いのかくらいは再考するという姿勢があっても良いでしょう。 よく「ベストプラクティス」という言葉がありますが、ベストかどうかはともかく、 見直しのチャンスであることは確かです。
- ７）他のソリューション（解決法）で補う
- パッケージの機能に考えている業務がない場合で、仕事のやり方を変えることも適当でない場合は、 どうにかしてその仕事ができるようなことをかんがえなければなりません。 この場合、究極の解決法である「システムを追加開発する」という選択をするのは簡単ですが、中間の解決法があり、 それが他のやり方を考えるというものです。例えば、ＯＡツールなどで業務を行うことなどです。 システム化ほどではないけれどある程度の効率化に繋がります。また、追加開発より負荷が少ない、例えば安価な小システムを導入する等のことも考えられます。 またその部分だけをソリューション化したシステムを採用する等の方策も考えられます。 人事給与でいえば、通勤手当の処理や社宅管理のシステム、 貸付金のシステム等は統合人事システムの機能では弱い部分をカバーするソリューションが出回っています。
- また帳票系のシステムは、ペーパーレスの方向性を取る企業も多いため、パッケージが弱い部分と言われてきました。 クエリー（条件検索）機能でデータベースから情報を取り出して、表計算ソフトのエクセル等に情報を引き継ぐ形式のソフトウェアを活用して、 帳票プログラムの開発を回避するなどの方策も考えられてきました。
- お金を湯水のように使える企業はともかく、工夫次第で追加開発を避ける手だてはあります。コンサルタントと他社の例などを研究して、 コストコンシャス（経費を意識した）なシステム化を心がけて下さい。
- ８）機能を追加開発する
- パッケージは、ユーザが要求する機能をすべて持っていることが理想ですが、いろいろな意味でそれは不可能なことです。 およそ必要な機能の１００％に近いメニューを持っているというパッケージベンダーがありますが、宣伝であると理解しておくほうが良いでしょう。 「カバーしています」というのはその通りかもしれませんが、「フィットしている」とは異なります。 その機能があっても、個別の企業が望むものそのものであるという保証はありません。
- 従って、『「ギャップ」というものはいつもあるのだ』という心構えで臨むことが大事です。 機能をそのパッケージと同じ土俵で整備することを、追加開発といいますが、それをパッケージベンダーが 「製品として整えてあげます」という約束をする場合があります。大きな影響力のある企業向けの甘言であることが多いのですが、 その場合は契約をすることが大切です。 機能開発はそのベンダーの都合によることが多く、優先順位はハッキリしないことが多いからです。 通常の企業には、そんなに甘い期待はできないですね。
- 追加開発は、パッケージそのものを修正することは最近稀になりました。これを「モディファイ」とか「カスタマイズ」とか呼びますが、 本体は人事給与のシステムであれば「税制の改定」や「社会保険の改正」などで修正プログラムをかけることが多く、 パッケージ本体を修正してしまうと、こういった改修ができなくなってしまいます。従って、介在プログラムを使って、 本体の外側にシステムを作る「アドオン開発」を推奨する例が多くなっています。つまり不足する機能を代替するシステム開発を行って、 本体のデータと連絡をしながら全体的に機能する形を整えるのです。
- 追加開発プロジェクトは、本体のパラメータと言われる機能を決めるスイッチを決めていく導入チームとは異なる体制を組むのが普通です。 しかしシステムが完成した後は、本体のパッケージと連動してキチッと動く検証を行うことになります。 この部分が大きいと、パッケージ導入プロジェクトなのか、システム開発のプロジェクトなのか見分けが着かなくなりますが、 本体の導入とシステム開発との整合性をとるプロジェクトマネジメントが必要なことは当然のことです。