戦略性とGAPの大小でパッケーシソフトウェアの対応方針を決定する

独自のICT活用を内製化で対応することで競争優位を高めていく、
このようなことを目指す企業が増えてきているように感じています。
過去の戦略的アウトソーシングの反省から、
少なくとも、
ICT戦略策定からベンダーへ丸投げする企業は、皆無になってきていると感じています。


一方、それでも、独自性が必要とされないシステム化領域も多く存在します。
また、独自税を追及する前に、先ずは他社レベルへのキャッチアップを目指す必要がある企業も存在します。

そのような場合には、SaaSやパッケージソフトの活用が有効であると考えます。
内部で一から検討して構築するよりも、
他社で利用済みの汎用的な仕組みを導入する方が、手軽でリスクも小さく、そこそこのレベルで業務を行うことが可能となります。


以下、パッケージ利用を検討する例ですが、

例えば、基幹業務システムの場合、
独自開発をするか、パッケージを利用するか、
つまり、とことんこだわるか、出来合いのものを利用するか、判断が必要となります。
それは、業務ごとに濃淡があり、その業務個々に見て検討した結果で判断する必要があると、私は考えています。

その業務ごとにどのように判断していくか、についてですが、
定量的な判断は難しく、合議で決定していくしかない、と私は考えています。
トップダウンで、との話も聞きますが、
ある程度の規模になると、
経営トップが十分な情報や検討された案も無い状態で判断する、ということは非常に難しく危うい、と私は考えます。

そこで、一旦、業務ごとに業務の責任者に検討いただく必要があります。
その時、業務の戦略性とGAPの大小の二軸で検討されますことを、お勧めします。


戦略性が高く、パッケージと業務のGAPが大きい場合、
それは、独自開発もしくはアドオン開発で対応していく範囲となります。
GAPのために、戦略を犠牲にすることは、大きなリスクになります。

戦略性が高く、パッケージと業務のGAPが小さい場合、
その影響度で判断する必要があります。
独自開発またはカスタマイズで対応する方向と、業務上の工夫や見直しで検討する方向が考えられます。

戦略性は低く、パッケージと業務のGAPが小さい場合、
パッケージの標準機能を利用することになります。
例えば、給与体系に一部特殊な面があり、しかしそれは過去の単なる名残であり、且つパッケージでは対応できない場合などにおいては、
パッケージで対応可能なよう、給与体系の修正を行います。

戦略性が低く、パッケージと業務のGAPが大きい場合、
少し悩ましい状況になります。
原則は、業務をパッケージに合わせて且つ影響を抑える方向で、業務の見直しを図ります。
その過程で、軽微なカスタマイズが必要と判断される場合には、そのカスタマイズも検討することになります。

そして以上の情報から総合的に必要メンバーによる合議で検討し、
システムの構成、つまりパッケージの適用範囲とスクラッチ開発やアドオン開発の実施範囲を総合的に検討し決定していきます。
その際、もちろんシステムのQCDの観点も加えることになります。

構想策定フェーズの予算化

3月決算の企業の場合、
企業規模やマネジメントのレベルによりますが、
11月ごろから、次年度の予算の検討に着手されていると思います。
ICTについても、例年と異なる対応が必要な場合には、その予算を検討されていると思います。

また、中長期的な観点から、予算を検討する場合があります。
ICTにおいては、何等かのシステム刷新が必要な時には、予算を大枠で認識合わせされることと思います。

私は、その予算策定時における金額の算出に、いろいろ悩む場合があります。


システム化の構想を策定するご支援をする場合、

全く新たなシステム化である場合は、
　　・類似システムでの経験からの予算感
　　・期待効果からの許容コスト

リプレースの場合は、
　　・過去の構築価格、機能追加・改修時の価格からの予算感
　　・トータル的なICT予算についての、業界や従業員規模から見た妥当性、許容度

などで検討します。
しかし、やはり、予算化段階であっても、
選定候補となるベンダーからの価格情報はほしいところです。


しかし、既存ベンダーからの情報が参考にならない場合、
例えば、
既存ベンダーではノウハウ等が不足する戦略的な新規サブシステム構築の場合、
既存ベンダーからのスイッチを視野に入れた既存システムのリプレースの場合、
などにおいては、
他ベンダーから価格情報を取得することになります。

その際、
要求事項をある程度の精度で伝えないと、参考にならない価格が出されてくるケースが多々あります。

必要最低限で且つタリフ化されている範囲のみの価格の提示、
リスクを大きく見過ぎた非現実的な価格のの提示、
などが、それに該当します。
最近、ベンダー側が概算価格の提示により慎重になっている傾向も見受けられます。


その上で、システム化構想時には、やはり妥当な予算を提示する必要があります。
繰り返しになりますが、
その際には、選定候補となるベンダーからの価格情報は是非ともほしいところです。
よって、
　　・より具体化した要求事項を提示して価格を再提示してもらう
　　・ベンダーにヒアリングをして、現実的な価格感を把握する
などの対応を経て、
他の事項と合わせて総合的に判断し、予算額を提示・提案することになります。

ICT超上流工程には十分なリソースと時間をかける

手軽なパッケージソフトやクラウドサービスのおかげで、
試してみて導入する、というICT活用が増えてきていると感じています。

私も実際に、システム分野によってではありますが、そのようなご支援をさせていただく機会があります。
情報共有を目的としたICTなどにはさまざまなSaaSがあり、
それらは試行実施期間があったり、１ヶ月単位や日割りの課金体系であったりなど、
試して導入することで、ICT導入の有効性を十分に事前確認した上で導入することができます。
本当に、嬉しい（？）時代となりました。


しかし、一方では、所謂ウオーターフォールモデル的な方法でICTを導入する機会も、以前として残っています。
大規模な基幹業務システムの刷新などのケーズです。

この場合、パッケージソフトの利用か、スクラッチ開発か、
そしてパッケージソフトを利用する場合は、どのパッケージを選定し、どの業務をどのようにパッケージに合わせるか、などなど、
いろいろ検討し決定すべき事項が多岐にわたります。
その際、自社の強みの業務は維持・強化し、他の業務はスリム化する視点が必要となります。
闇雲に、パッケージに全ての業務を合わせるのではなく、また逆に、何が何でも現状を踏襲する、という安易な考え方は避けるべきです。

つまり、システム化の構想、その構想に沿う要求定義、つまり超上流工程は、システム化を成功させる上で非常に重要です。
よって、超上流工程には、十分なリソース、例えば、適切な意思決定可能なメンバーの参加、十分な打ち合わせの準備・時間・回数が必要となります。

＜関連記事＞
　超上流工程（広義の要求定義）の基本プロセス（その1）
　超上流工程（広義の要求定義）の基本プロセス（その2）
　超上流工程（広義の要求定義）の基本プロセス（その3）

　超上流工程からシステム運用テストまでにおける考慮事項

バックオフィス業務はパッケージに合わせる

支払い・入金管理、債権・債務管理、経理処理、会計、給与事務などの業務は、
バックオフィス業務と呼ばれる場合があります。
営業・販売やサービスなど顧客対応をする部門を支援する業務との位置付けになります。

バックオフィス業務の効率化は、
過去は情報システム活用の大きなテーマでした。
現在もシステムを有効活用しながら効率化を図っている企業が多いと思います。
その効率化を図るため、
社内の情報システムが独特の進化をして、
所謂カユイとろに手が届くようなシステムになっている企業もあるかと思います。

しかし、最近のパッケージそふとは、
それらバックアフィヅ系業務の機能がかなり充実してきています。
自社と合わない面もあもしれませんが、使えないことはない、というパッケージソフトも多いと思います。

多少のギャップはあるかと思いますが、
私は、バクオフィス業務は、パッケージソフトを利用すべきであると考えます。

理由は、
先述のとおりそのままバックオフィス業務で利用可能なケースが多いと考えられることと、
それらバックオフィス業務は、競争他社との差別化による大きな競争優位の源泉になることが難しい、
と考えるからです。

バックオフィス業務の仕組み検討・構築をパッケジソフトウェアに委ねることで、
それらにトレンドとして必要となる対応をパッケージソフトウェアのバージョンアップで実現し、
また、より戦略的に重要な業務へのICT活用を検討するあらたｍ時間が生まれます。

基幹システム刷新の目的をシンプルに設定

古いアーキテクチャーのため、今後の継続性が難しい、
長期で利用し続ける過程で機能の追加や改修が積み重なり、システムが複雑化して改変が難しい、
など、
長期の利用が起因して、システムの刷新が必要となることがあります。

日本情報システム・ユーザー協会が実施した調査である、
「企業IT動向調査2012」では、
代表的な基幹系システムの寿命の全体平均では「14.6年」との記事が、過去見られました。
（ちなみに、2007年度の調査では13.8年でしたので、約5年間で寿命が約1年伸びたとも言えます。）


いずれにしましても、１０年、１５年経過しますと、
システムは刷新を検討する時期である、と捉えられると考えられます。
刷新する／しない　の結論は別にしまして、刷新すべきかどうかを検討する時期、と言えます。

その際、例えば基幹システムの場合には、
同一企業における刷新の経験・機会はそうそうあるものではなく、
且つ大規模投資となるため、
よって、今度のICTによる事業変革を検討する良い機会とも捉えられます。
私自身も、そのような視点から、基幹システムの刷新をご支援した経験が複数あります。


しかし、最近は、あまり難しく考えすぎない方が良いと、私は考えています。
私は、業種業態や基幹システムの範囲にもよりますが、
基幹システム自体は、企業の競争優位や顧客満足度を大幅に高める、という性質のICTではない、
と考えています。

逆の見方をしますと、基幹システム自体は、
他社よりも劣っているために経営の意思決定が遅れる、などという問題が解決していて、
あとは自社の独自性や強みを強化するICTと連携ができれば、
少なくとも中堅・中小企業においてはそれで十分なのではないか、と思うのです。
事業の変革テーマ自体に直結するソリューションは他ICTに委ねる、というイメージです。


よって、基幹システムの刷新時には、事業変革等の大きな目的を設定するより、

・その変革のスピードを妨げているシステムの複雑性や意思決定の遅れの解決
・他の戦略的なサブシステム等ICTとの連携の柔軟性の具備
・現在の強みの維持（基幹システム刷新によって強みを失わない）

を基本として、
現在の強みは維持しつつ、
事業変化のソリューション自体は他サブシステム等ICTに委ねられる基盤を整備することを、
基幹システム刷新時の目的として設定するべきである、
と、私は考えます。

全てを刷新する／しないを含めて、以上の観点でご検討されますことをお勧めいたします。


＜関連記事＞
　超上流工程（広義の要求定義）の基本プロセス（その1）
　超上流工程（広義の要求定義）の基本プロセス（その2）
　超上流工程（広義の要求定義）の基本プロセス（その3）

　要求定義と要件定義
　〔参考図書〕システム要求定義の基本　
　要求定義のポイントは成果物と作業の網羅性

　超上流工程からシステム運用テストまでにおける考慮事項