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

支援屋が今 抱えているプロジェクト(どれもこれもお金にならないプロジェクトですが)がスタックしちゃってかれこれたちます。

プロジェクトマネージャーとして、ここはなんとか手を打たなければならない状況かと思われます。(一応 気合を入れるとかの手は打ってあるんですがこれだけでは能無しプロマネの典型です。)

プロジェクト全体がスタックしている状況には必ず原因となる事象が存在するはずです。何か各タスクを遂行するにあたって障壁となる事象が。これを見つけ出してその障壁事象を取り除く。これが王道です。

もうひとつ。プロジェクトをスタックさせる理由。これはプロジェクト計画に誤りがある場合。これが原因になっている場合はプロジェクトメンバーがいくらアクセルを踏み込んでもタイヤは空回りするばかりでプロジェクトは前に進みません。だってエンジン出力をタイヤに伝える経路に問題があるわけですから。

今回の場合、どうなのか?

どうやら後者のようです。(すいません。プロジェクト計画をまだ公開していないのでなにがなにやらわからないかもしれませんが)

今回のオープンソース導入実験プロジェクトはテクニカルインストレーションの後、プロジェクトが迷走し始めたのでプロジェクト定義からやり直して と再計画したのですが、これでもまだスタックしてる。プロジェクト定義が現実的なものにならないんですね。いろいろ原因らしきものを探っていくと 「公開する定義書だからかっこ悪いのはダメ」とか「経営改革をするためのツールなんだからもっと経営者視点に立って」とか「先進技術を推進する役割も担っているんだからもっと技術的に深いところを」とか かなり無茶な意見があって手が止まっていたんだなと思います。結論は背伸びしすぎ。

所詮、かっこつけてもしょーがない。無茶な背伸びしても無理は無理。すこーしだけ背伸びする姿勢は己を成長させるためには必ずしなければいけないことなのですが、背伸びし過ぎは身を滅ぼしますね。

それともうひとつの原因、おそらく最大の原因は「敵を知る」を怠っていたこと。テクニカルインストレーションができたことで敵を完全制圧したって勘違いしたこと。(別に完全制圧した気になってたんじゃないんだけど驕っていたのは確かかも)
ERPの本質はテクニカルじゃなくってビジネスでしょーに。業務機能ですよ。どんな業務に適用できるのかを知ること。これが肝心。テクニカルも含め他のことも大事なんだけど業務機能がどうなっているのかを知ることこそがERPを扱う上でのセオリーでしょうに。

なのでテコ入れしました。
新しいタスクを新設しました。
仕事 増えます。

新しいタスクは「メンバートレーニング Adempiereの機能」です。
タスクの目的はプロジェクトメンバーがAdempiereの業務機能を一通り理解すること。これをすることによってターゲットとなる顧客の業務とのギャップも見えるし代替ソリューションも考えやすくなる。なのでこのタスクには全員でかかる。時間は許す限り使う。到達レベルは..Adempiereでできる業務とできない業務をそらんじられること。
以上!

さっそくトレーニング開始しました。
支援屋ver2 Adempiereの紹介 ここで成果がわかります。

さてさて テコ入れの効果はありますことやら?