ソフトウェア “技術力を活かすための”業務知識がシステムエンジニアに必要なわけ
システムエンジニアには技術力を活かすための業務知識が必要である。優秀なベテランのシステムエンジニアでも業務知識が不足していたために性能を改善することができなかった。例え、業務知識があってもシステムズエンジニアリングに活かせなければ宝の持ち腐れになる。
雑記帳
ソフトウェア RPA RPAの投資対効果を最大化するなら夜間自動実行がお薦め！
RPAはパソコンの操作を自動化するツールで、WebサイトやExcel、基幹システムなど人が操作して行う事務作業を記憶させて、代わりにやってくれるソフトウェアロボット。これの効果を最大化するには、夜間自動実行がお薦め！人がやっていたら数日かかる作業が一晩で完了できる。
DX 巧者は変革を推進するも争わず。論破よりアイデアで解決の道を探る
業務プロセスを変革しようとすると抵抗勢力との争いが生じるのは良くある話かもしれないが、巧者は争わなくとも変革を推進することができるもの。 相手を論破して従わせても、決して良い結果にはならない。それよりは、多くの選択肢、アイデアを抽出して解決の道を探る。
DX VUCA時代のDX人材リスクに備える！
VUCA時代はDX人材に対する人的リスクが高い。必要な質や量がコロコロ大きく変わったり、不確実であったり、複雑化したり、曖昧であったり。このリスクに備えるには、平常心が重要である。常にVUCAを意識して、特定のDX人材に偏ったり、固執しないようにすること。
雑記帳 変革するために最初は逃げ道も必要、半強制の全員参加はハイリスク
DXによる変革では一部のデジタル人材だけでなく、あらゆる業務部門の担当者全員が取り組むことを要求される全社的な活動として進められることが少なくない。しかし、最初から全方位で変革から逃げられないような状況に追い込むのは、返って強い抵抗を生むことになる。
DX 製造DX-個別受注生産の利益率向上は、できるだけ新図を起こさないこと
顧客の要求に対して、いかに新図を起こさずに対応するか。 これは個別受注生産メーカにおける大きな課題の一つだ。 新図を起こせば、設計コストだけでなく、調達コストや生産準備、製造コスト、アフターサービスなど 製品のライフサイクル全体に渡ってコス...
DX 設計変更のあるべき姿とは! PLM本来の使い方が鍵
設計者は部品の手配生産状況を把握してから設計変更を出すべきか否か。どちらも一長一短あり、どちらが正解とも言い難い。様々な設計変更に画一的なルールや組織、仕組みで対応するには限界がある。解決策としてPLM本来の使い方が鍵になる。
DX 業務プロセスの高度化において、チェック要件（ビジネスルール）こそ重要な現場ノウハウ
業務プロセスの高度化において、自社の強みや差別化になるのは現場の経験から得たノウハウではないだろうか。成功や失敗の経験から、「こうすれば上手くいく」という現場ノウハウはとても重要なものだ。この現場ノウハウは業務フローなどには表れない、チェック要件などになる。
ワークフロー ワークフローの変更は慎重に！簡単ツールの落とし穴
いまどきのワークフローは変更を行うのがとても簡単だ。簡単だから、と出された変更要望を次々に取り込んで変更するのは最善の策とは言えない。変更が簡単にできるとしても、その目的や変更コストに見合うだけのメリットがあるかなどをしっかりと確認し、変更をしなくても運用で目的を達成できるのが最善の策である。
レガシシステム レガシシステムの刷新に乗じて、周辺システムとの接続をシステム連携ツールで再生する
レガシシステムの刷新では、どうしても中心となる基幹システムに意識が集中しがち。しかし、古くなって死んでしまったかのような周辺システムも、レガシシステムの刷新と言う大義名分に乗じてしっかりと再生する必要がある。場合によっては再接続ではなく、周辺システムも刷新する好機になる。