ブタメロン🐖💻

知識に飢えたらプライベートでやれば良いし 元々がブラックじゃなきゃ普通に定時で帰れるし 悪い所の二つ目は 会社でもそないに人権ないことかw

情報システム部は良いぞぉ 良いところ ・納期意識低い ・ちょっと知識ありゃ神格化 ・企業依存の収入 悪いところ ・業務理解できないとだめ ・要コミュ力 ・エンジニア界隈で人権なし

要は数重金だけ連携したら成り立つのではと

生産管理をERPから切り離すなら、品目コード変換って必要ない可能性ある？ ①販売管理側で主材料払出 ②生産管理側で仕掛を受入 ③生産管理側で仕掛を払出 ②販売管理側で製品で受入 品目マスタ変換地獄から解放される気が 🤔

まとめると 作ることが目的化したドキュメント はやめましょうという話でした

具体例:運用可能な課題管理 課題No,起票日,起票者,タイトル,課題内容,回答期限,回答者\指名,対応内容,完了日,完了ステータス,備考/リンク

ドキュメントの話 上手くいかないプロジェクト程、無駄なドキュメント作りがち。 ・要件と要件定義書の内容に乖離発生 ・各管理台帳の形骸化や分散 ・証票ペタペタ>>テスト内容でテスト漏れ などなど ドキュメントは本来の意味と作成・管理工数を想定してフォーマット考えれ

② 　6/1 購買フロー確認 　6/6 販売フロー確認 これは間でネクストアクション決まってないとユーザーがついてこない。 次には進むが要件乖離につながる。 最後まとめて業務フロー渡した時にユーザーは「これなんだっけ？」となるし聞いた奴も忘れちゃってるとか起きる。

ダメな例 ① 　隔週で購買の打ち合わせしましょう これだと2回目に支払のフローに入ってしまったり 個別最適の話になりかなり散らかる。 上手く行ってたら“話する事ないね”で終わる

打ち合わせの話 上手く行かないプロジェクトは 会議と会議の間に成果物の進捗やネクストアクションが考慮されていない。 良い例 6/1 購買の業務確認 6/6 購買の業務フロー確認 になっていれば明確に6/2〜6/5に業務フローを6/1の内容を元に作る事がわかる

むしろいきなりエンジニアって敷居高すぎて無理ゲーだと思います(小声

未経験でエンジニア志望者はプログラマーに憧れがちですが、開発は要件整理、設計、テスト、移行、運用など工程が山ほどあります。 「業務を理解して要件に落とし込める」だけで価値がある。 何を学ぶかより、自分が理解しやすい分野を見つけてそれ以外の強みが言語化出来ればきっと挑戦出来ます🐖

テーブル仕様固めるフェーズだなー。 全体機能は決まってるのにMVPのスコープははっきりしない。 なやむぜぃ

そして結局ERPの割に拡張性も無ければ 大して新旧システム比較で効率化もされない

事象

ERPは綺麗なプロダクト少ないとおもう。 シンプルかつ自由度高い設計ができたら国内で人気出そう。 例えば、商品コード。 単純にカラム10個くらい用意して好きにエイリアス決めて発注時にプライマリ自動発行とか。 作り込むのではなく、標準で個別最適対応可能なスライムみてぇなERP作りてぇな