 |
 |
| 実施要領＜短期導入ケース＞ |
|
| ■ |
現状分析 |
|
| ・ |
改革対象となる現状分析に、無駄な工数をかけません。 |
| ・ |
現状を詳細に把握することより、あるべき姿のイメージ作りに工数を使います。 |
| ・ |
プロジェクト提案書で、経営課題・実施すべき戦略・ITソリューションについて必ず経営者と合意をします。 |
| ・ |
システム営業担当者が提案書を作成するのではなく、ITソリューションコンサルタントが作成します。 |
|
|
| ■ |
プロジェクトの編成 |
|
| ・ |
社内を、作る人（プロジェクトチーム）・要求するだけの人（ユーザー）に分けません。 |
| ・ |
プロジェクト実施チームとは別に支援チームを編成し、関係者が一丸となってプロジェクトを推進します。 |
|
|
| ■ |
設計・開発・プロトタイピング |
|
| ・ |
『大掛かりな制度改革・業務改革を実施してからシステム導入』というアプローチを取りません。 |
| ・ |
まず、システムを導入して器を作り、走りながら改革を進めます。 |
| ・ |
最初に実行する改革は、システムをスムーズに導入するのに必要最小限なものだけにします。 |
|
|
| ■ |
テストデータの作成 |
|
| ・ |
ユーザーは、検証用データを開発前に必ず作成します。 |
| ・ |
ユーザーは、検証用データを作成できないもの『検証できないもの』を開発要求しません。 |
|
|
| ■ |
システムテスト |
|
| ・ |
システム担当者に任せっぱなしにしません。 |
| ・ |
ユーザーがイニシアティブを取って、実施します。 |
| ・ |
ユーザーの検証工数を捻出する為に、部門内の業務シフトや他部門の経験者の支援体制を作ります。 |
|
|
| ■ |
本稼動 |
|
| ・ |
『ともかくカットオーバーして、フォローアップすればよい』というアプローチを取りません。 |
| ・ |
どの水準の品質であれば本稼動に踏み切るか、事前に設定して置きます。 |
|
