予算管理システムは、『汎用性の高いものだ』という社会的認知があると感じています。これはある意味正しいですが、別の意味では正しくありません。
予算管理システムもパッケージ製品である以上、開発者は一定の『標準業務』を想定し、システムを設計しています。この『標準業務』に合致する使い方をすることが、パッケージを利用して最大の効果を発揮できると言って良いでしょう。逆に『標準業務』に合致しない場合には、無理な設計を施すことで、保守性や性能等に悪影響を及ぼすこともあります。
予算管理システム導入の成否は、パッケージの得意・不得意を見極め、得意な方法を採用することが非常に重要になります。
しかし、実際には、『汎用性が高い』⇒『何でもできる』という発想で、不得意な点に目を向けずに要件定義、設計を行ってしまうケースが少なくありません。
私自身も、導入経験の中で、パッケージの得意を活かして効果を出せた!という場合もあれば、かなり無理な設計をしてしまった(レスポンス懸念、運用メンテナンスの煩雑さ)という場合もあります。
予算管理システムの多くは、Excel(もしくはExcelライクな)インターフェースを採用し、DBもお客様ごとに拡張が可能です。画面とDBさえ用意すれば、入力⇒集計⇒出力 という基本的な動作を行うことが比較的容易にできてしまいます。
この『できる』という点が曲者だと思っています。
例えば、何か要件を提示した際、同じ「できます」の中にも以下のようなニュアンスが含まれているはずです。
「できます(他社事例もあり、標準機能を使用し効率化が期待できる!)」
「できます(標準の仕様では無理なのでマスタを一つ増やしてメンテナンスしてもらえれば・・・)」
「できます(色々な設定を組み合わせればできるけど、複雑になるためユーザ自身でメンテしていくことは不可になりそうだ。大丈夫かな・・・)」
ある程度の優秀な導入ベンダーであれば、曖昧な部分をしっかりと説明し、代替案を提示してくることも多いです。しっかりと良案を議論するのは当たり前だと思われるかもしれませんが、業務的な要件をシステムの制約で外すという選択は通常取りづらいため、要件定義時にはできることにしてしまうケースも多いです。
しかし、このまま進んだ場合、どれほどの影響があるのか、代替案での業務も可能なのではないか、真摯に議論する姿勢が必要です。「この要件は提案の段階から見せているはずだ」という主張で議論を打ち切ってしまうのは、自らの首を絞めることになりかねません。システムを選定した責任は会社側にもありますから、発生した課題に真摯に向き合うことが重要です。
要件定義の中で、提示された要件のままだとレスポンスが非常に遅くなる懸念が発生しました。予算管理システムの得意なレイアウトの入力画面とDBに変更すれば改善が見込める、という代案を提示したところ、最初は抵抗がありましたが、議論を重ねた結果、了承を頂きました。
当初の要件とは異なる入力画面で構築を行うこととし、周辺システムとのデータ連携時にデータを加工頂ける(お客様作業)というかたちで実現をしました。
無事に導入を迎えたときには、レスポンスも優秀で、エンドユーザーからも非常に使いやすくなったと高い評価を頂き、継続して安心してご利用頂けるシステムを構築することができました。
不得意な使い方をばっさりとやめて、得意なやり方を採用したことが成功の要因になったと考えています。
本来はシステム選定時にパッケージ製品の得意・不得意を理解すべきではありますが、短い選定期間の中で、それを100%理解することは不可能です。要件定義や設計の中で発生した課題に対して、真摯に検討することは当然とし、その判断のポイントの一つとして、システムの得意・不得意を把握し、得意な方法を採用するという考え方が、システム導入の成否を分ける上で重要になると考えます。
【RPA開発Tips】Excel操作に強くなる テクニック編
【RPA開発Tips】Excel操作に強くなる 応用編
【RPA開発Tips】Excel操作に強くなる1 基礎編
【RPA開発Tips】ワイルドカードを活用しよう
【RPA開発Tips】いまさらだけれどWinActorフローティングライセンスとは?
【RPA開発Tips】いまさらだけれどWinActor Manager on Cloudとは?
【RPA開発Tips】ファイル操作に強くなる 後編
【RPA開発Tips】ファイル操作に強くなる 前編
【RPA開発Tips】エラーに強くなる(後編)
【RPA開発Tips】エラーに強くなる(前編)
SAP導入、悩むユーザー部門:「ゆるふわ要件定義」を防ぐ対策3点