CaFeterria

私はSAPの導入PJに参画しており、FMのチームに所属しています。

FMは「予算管理」の機能です。

『予算管理はCOを利用すればよい』と考える人もいると思います。

FMは予算の管理・執行を担います。

特に使用可能額の上限を定め、その範囲内でのみ支出可能とすることが出来る点は特徴的です。

例えば、上限が100万円の場合、100万円を超過した支出はブロックすることが可能です。

一方、COは組織内部の収益・費用の分析と管理を担います。

「どの部門が利益に貢献しているのか」など、経営分析に焦点を当てています。

FM導入時の大事な点を2つ紹介します。

1つ目は「予算管理ルールの明確化」です。
FMはルールベースで動くため、予算チェックタイミングや予算超過時の動作（エラー/警告/許可）などのルールを定める必要があります。

2つ目は「他モジュールの理解」です。
「予算管理」という特性上、FMは他モジュールと密接に連動するので、FMの担当者がFI,MM等の知識を持っていることで効果的な導入が可能です。

FMとCOと両立させることで、予算管理と経営分析の両方が実現可能であり、「予算統制とコスト管理」や「中長期的な予算計画・経営計画の改善」などに役立てられると思っています。

【投稿担当：R.M.】

私は現在システム導入PJ支援に携わっており、このPJではアジャイル開発手法を取り入れてシステム開発を行っています。

また開発の際は、業務に必要な最低限の機能に絞り込み優先順位を付けてリリースするスモールスタート方式を採用しており、なるべく短サイクルで要件定義～リリースまでできるようにしています。

この開発手法の良いところは、短期リリースかつ毎回リリースする機能範囲が限定的なため、都度ユーザーから具体的なフィードバックをもらえ、迅速に改善要望対応ができることです。

実際に利用後すぐに、「通常業務パターンとは別に、特定のイベント時においては業務担当者が変わる別の業務パターンが発生するため、そのパターンにも対応できる機能を実装して欲しい」と言った要望があり、業務影響が出る前に対応することができました。

特にシステム導入PJの経験が少ないユーザーの場合、要件定義からシステムリリースが短期間である方が業務とシステム機能の紐づきを容易にイメージでき、PJとしての達成感も得られるため、アジャイル開発の方が向いていると感じました。

【投稿担当：K.I.】

私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

【投稿担当：G.F.】

打合せの度に印刷される資料、積み上がった書類に埋もれた机。ペーパーレス業務の浸透が進んでいない企業には、従来の仕事のやり方とのギャップや、そもそもやり方を変える事それ自体への抵抗等、様々な理由があり変革が困難と言われていますが、本当にそうでしょうか。

例えば、経理部門の日次業務の一つである伝票と証憑の突合確認では、審査の品質を維持しつつある程度のスピードで処理する必要があり、証憑の確認に際しての“見やすさ”は重要な要素です。

そんな中で単純にペーパーレスの推進だけを掲げても、ひとつのPC画面でウィンドウを切り替えたり分割しての作業となり、かえって業務効率が低下しかねません。

だからといってペーパーレス化が不可能というわけではなく、例えば上のケースではサブモニターを用いることで紙印刷した場合の文書の見やすさに近づける等、対策は考えられます。適切な支援を行うことでペーパーレス化は十分に実現可能であると考えます。

【投稿担当：W.K.】

最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

（詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚）

要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

【投稿担当：C.I.】

例えばデータ連携テストをする際、連携元システム、EAI、連携先システムと、システムごとに担当者を配置する体制がセオリーかなと思います。

しかし、セオリー通りでは上手くいかないこともあります。

私もセオリー通りの体制でデータ連携テストを実施し、なかなか解消されないエラーに四苦八苦する経験をしました。
EAI内のマッピングが複雑化・ブラックボックス化する中、連携元システム担当としてEAIの仕様を深く理解しないままテストを進めた結果、EAI側でエラー発生時に主体的に原因究明できず、EAIチーム任せとなり解決に時間を要してしまったのです。

もし体制として、システムを跨いで横断的な確認を行う担当者がいれば、上記のような苦労は無かったかと思います。

しかし実際はそのような担当者は不在でした。
テストをスムーズに進めるためには、担当システムを飛び越えて仕様理解を深める等、こうした体制の不備を姿勢でカバーしていくことが大切だなと感じました。

※EAI：複数の異なるシステムを連携させ、データやプロセスを統合する仕組み、またはそのツールのこと

【投稿担当：T.O.】

皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

特に10～20年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

【投稿担当：T.N.】

近年はITリソースの逼迫に伴い、

システムベンダに提案を依頼しても辞退されるケースが増えています。

私自身、プロジェクトの中でベンダの提案辞退を受け、

候補が限定された状況で選定を行った経験があります。

その経験からベンダに提案を依頼する際は、

「要件を具体化する」

「要件に優先度を付け、優先度が低い要件は代替案を提示する」

「提案前に直接重要な要件とその実装イメージのすり合わせを行う」など

ベンダが正しくプロジェクトのリスクを評価できる情報を伝えることが、

重要だと身をもって認識しました。

【投稿担当：S.K.】

新システムの導入や業務プロセスの再設計を行ううえで、

「現状分析」は不可欠であるとはよく言われることではありますが、

私自身、コンサルティングを通じて、日々その重要性を痛感させられています。

現状分析によって問題点・改善点を網羅的に明確化することは勿論重要です。

しかし、現状分析を通じて組織風土や業界の慣例、業務の複雑性・特異性に繋がる背景を理解することも、また、重要な一面であり、変革への現場の抵抗感など、取り組みの難易度を左右する要素の見極めに繋がります。

こういった側面にも注力しておけば、

より実現性の高いアプローチを選択できたはずだと省みることも少なからずあり、

その度に「未来の成功のために、現在に向き合う時間を惜しむべきではない」と、

自身に言い聞かせています。

【投稿担当：K.T.】