Monthly Archives: 8月 2017

「システム発注から導入までを成功させる90の鉄則」第14回(8/29)

Posted on by 0 comment

参加者 今井(読み手)、青木(記)
範囲 pp.220-239

第4章 ユーザー教育~システム本稼働までのルール

  • 4-3 新システムの稼働判定会議を開催し全社的に判断する
    • RULE83 稼働判定はプロジェクトマネージャーの責任で進める
  • 4-4 万全な準備で本番稼働を迎える
    • RULE84 初回稼働時は考えうる全てのチェックを行う
    • RULE85 本番障害は軽率な対応を行わない
    • RULE86 社内原因の本番障害は再発防止を考える

第5章 システム運用/保守のルール

  • 5-1 システムの開発体制から保守体制へスムーズに引き継ぐ
    • RULE87 社内引き継ぎの前に体制を明確にする
    • RULE88 保守メンバーを交えて課題をたな卸しする
    • RULE89 ベンダーと積み残しの最終確認を行う

「システム発注から導入までを成功させる90の鉄則」第13回(8/25)

Posted on by 0 comment

参加者 青木(読み手)、今井(記)
範囲 pp.208-219

第4章 ユーザー教育~システム本稼働までのルール

  • 4-2 システムを実際に使うユーザーを味方につける
    • RULE78 業務説明が先,システム操作が後
    • RULE79 システム操作説明会のリハーサルは必ず行う
  • 4-3 新システムの稼働判定会議を開催し全社的に判断する
    • RULE80 システム稼働判定は自社主導で必ず行う
    • RULE81 稼働判定表はこう作る
    • p.217 図6
      図見出しに「本番稼働判定表のイメージ」とあるが、Rule82と合わせてみると、「稼働判定表のイメージ」で、並行稼働なしのときはこの表が本番稼働判定に、並行稼働ありのときは、この表が並行稼働判定に使用されるようだ。
    • RULE82 並行稼働後の稼働判定表はこう作る

「システム発注から導入までを成功させる90の鉄則」第12回(8/22)

Posted on by 0 comment

参加者 今井(読み手)、青木(記)
範囲 pp.186-207

第3章 ユーザー受入テスト~システム検収までのルール

  • 3-4 ITベンダーへのアプローチを工夫し品質を引き上げる
    • RULE71 事前にベンダーテスト結果を確認する
    • RULE72 スクラッチ開発は品質報告書を要求する
    • RULE73 その遅延は本当にベンダーのせいか

第4章 ユーザー教育~システム本稼働までのルール

  • 4-1 マニュアルを作成し混乱と不満を最小限に抑える
    • RULE74 マニュアルは2種類ある
    • RULE75 マニュアルは誰が作るのか
    • RULE76 業務マニュアルは大勢で作らない
  • 4-2 システムを実際に使うユーザーを味方につける
    • RULE77 説明会で良いイメージを持ってもらう

「システム発注から導入までを成功させる90の鉄則」第11回(8/8)

Posted on by 0 comment

参加者 青木(読み手)、今井(記)
範囲 pp.170-185

第3章 ユーザー受入テスト~システム検収までのルール

  • 3-2 納品されたシステムを自社責任で徹底的に検証する
    • RULE64 現新比較テストは全件で行ってこそ意味がある
    • RULE65 現新比較テストをExcelで行う方法
    • RULE66 合わない理由を徹底的にトレースする
    • RULE67 検収を遅らせるとLose-Loseになる
  • 3-3 システム障害を主体的に管理することで致命傷を防ぐ
    • RULE68 受入テストの障害管理表は自社が管理する
    • RULE69 障害管理表はこう作る
      • p.182 図12
        項目「重要度」の説明で、「優先度「高」の場合」と、重要度と優先度が同じ意味で使用されている。本来重要度と優先度は別のもの。
      • p.183 図13
        対応にどのくらいかかかっているとか、どのくらい状態が変わっていないかだとか、だれに聞けばよいかなどは重要だと思うので、起票日付や起票者、更新者名はほしい。
    • RULE70 障害管理表のボールが止まっていないか

「システム発注から導入までを成功させる90の鉄則」第10回(8/4)

Posted on by 0 comment

参加者 今井(読み手)、青木(記)
範囲 pp.150-169

第3章 ユーザー受入テスト~システム検収までのルール

  • 3-1 システム検証の前にプロジェクト計画の仕切り直しをする
    • RULE56 本物の管理者かどうかはWBSの扱いでわかる
    • RULE57 管理者も仕様から逃げない
  • 3-2 納品されたシステムを自社責任で徹底的に検証する
    • RULE58 受入テストをカオスにしないために
    • RULE59 受入テストは4種類で計画する
    • RULE60 機能確認テスト項目書はこう作る
    • RULE61 システム間連携テスト項目書はこう作る
    • RULE62 シナリオテスト項目書はこう作る
    • RULE63 シナリオテストはコーディネートするもの

「システム発注から導入までを成功させる90の鉄則」第9回(8/1)

Posted on by 0 comment

参加者 青木(読み手)、今井(記)
範囲 pp.134-149

第2章 プロジェクト立ち上げ~要件定義までのルール

  • 2-3 自社の課題解決力で進捗を加速させる
    • RULE51 課題管理表はこう作る
    • RULE52 課題管理は進捗を聞くだけでは意味がない
      • p.134
        課題管理表には、自分が担当している課題がすぐにわかるように、担当者(現在誰がボールを持っているか)の欄と日付は欲しい。
  • 2-4 マスターデータは自社の生死を分かつ
    • RULE53 マスターデータの手入力は最後の手段とする
    • RULE54 マスターデータは全件テストする

第3章 ユーザー受入テスト~システム検収までのルール

  • 3-1 システム検証の前にプロジェクト計画の仕切り直しをする
    • RULE55 下流工程の役割分担表で仕切り直しをする