こんにちは
支援屋@高橋です。

現在、オープンソース導入実験プロジェクトは前々回に書いたようにタスク分岐点にたっている情況です。そして徐々に迷走を始めている。迷走の原因ははっきりしてます。プロジェクトの最初に実施しなければならないタスク「プロジェクト定義」をこんな感じで軽く受け流そうとしたのが悪かった。↓
0.計画
導入のスケジュールとか評価方法とか評価基準を決めて、仮定となるビジネスプロセスを定義して...かなり膨大な記事をかかないといけなさそうです。こればっかを記事にしてると全然つまらないのでこの過程で作成した文書は関わる導入プロセスの記事にバラバラにして混ぜ込むかたちで掲載していこうかと

計画自体は自分自身描いていたつもりだったのですがさすが人間の記憶装置 揮発性が激しすぎ!ゴールのイメージがその日その日で変わっていくのです。これでは次に何をするのか?都度都度かわってしまいます。そしてこんがらがる。プロジェクトは進むべき道を見失い迷走する。そしてオワタ\(^o^)/となる。間違いない。
なので覚悟を決めてプロジェクト定義を形にするべく、今回から記事にします。あくまでもかる〜くですけど。(←
今回はまずは目次だけ
    オープンソースERP導入実験プロジェクト プロジェクト定義 目次
  • 目標
  • 位置づけ
  • 範囲
  • 導入メソッド
  • 体制と予算
  • 業務プロセス定義
  • 実行計画
  • 管理方針
  • 成功要因


これはQAD社の導入メソッドQ-ADVANTAGEをベースに支援屋@高橋が低予算プロジェクト用にアレンジときのプロジェクト定義書目次です(記憶だけに頼っているので正確ではないかも)。(Implexのほうが方法論としては洗練されていて捨てがたいけど残念ながらこっちでのプロジェクト管理経験がないので選択しなかったです)
本来のプロジェクト定義書ならばコンテンツ一つ一つが膨大な量になるのですがそんな時間はないので今回はあくまでも方向を見失わないことだけに注力して最小限度の労力で作ろうかと思います。期限目標は1日。

できるかー!


同時進行でこっちもやってます↓
支援屋 ver2 バージョンアップ作業中