アカウント名:
パスワード:
米国基準の変更に引きずられるのは困ると思うのは自然だと思います。
#1336825 [srad.jp]は、そういう話もあるけど、別の問題もある、と指摘してるんだと思うよ。挙げられてたリンクの先 [nikkei.co.jp]には、
この仕様が合わないという問題は、国ごとの会計とかの制度の違いと、会社ごとの違いとの2つがあるのだと思う。国とか制度の違いだけなら、日本向けのパッケージを作れば流通しそうなものだが、なかなか流通しないところをみると、後者によるところも多いと考えざるを得ない。
とある。つまり、
外部から変更されるのを嫌うのです。
「しかし経営者とか経営スタイルが変わったとしても、システムを使う現場のやり方は変わらないのではないか」と聞くと、「それも一挙に変えてしまう、変えない従業員にはやめてもらうのだ」という返答だった。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
どっちもどっちだなぁ (スコア:1, 興味深い)
あわせる気が無いというのもどうよ
パッケージソフト不毛の国・日本的ソフトウエア観(4) [nikkei.co.jp]
Re: (スコア:1, すばらしい洞察)
>あわせる気が無いというのもどうよ
米国会計基準にあわせた企業なら問題はないでしょうが
米国基準の変更に引きずられるのは困ると思うのは自然だと思います。
まあ、本当は自前で開発しろよ、と思ったりしますがね。
# 各業種とも、まずは自前で開発を行う力を持つ企業が出てきて
# 内部からデファクトスタンダード的なパッケージに仕上げるべきだと思うぞ。
Re: (スコア:4, 興味深い)
#1336825 [srad.jp]は、そういう話もあるけど、別の問題もある、と指摘してるんだと思うよ。挙げられてたリンクの先 [nikkei.co.jp]には、
とある。つまり、
Re: (スコア:2, 興味深い)
>この指摘が正しいとすると、
> # 各業種とも、まずは自前で開発を行う力を持つ企業が出てきて
> # 内部からデファクトスタンダード的なパッケージに仕上げるべきだと思うぞ。
>日本では、そんな風にやっても、デファクトスタンダードにはなり得ない、ということじゃないかな?
えーっと、そうなんです。
外部から変更されるのを嫌うのです。
なので、パッケージベンダは日本企業の我がままを聞いて
そのまま実装してしまい、コテコテの専用システムが出来上がるのです。
だから、内部から作らないとと思う訳です。
# まあただの自前システムにしない為には力量が必要ですが
# 今の業務をなるべく変えないでよ、というより
# 自分でいいものを作ろうと思って作らないと駄目、というただそれだけの当たり前の話なんですが。
Re:どっちもどっちだなぁ (スコア:3, 興味深い)
件のページ [nikkei.co.jp]には、米国のパッケージソフト販売会社の役員との問答として、 と書いてあります。下の人間は嫌う・嫌わないに係わらず、上の命令に従うのが米国流のようです。
#関東軍の暴走を止められなかった大本営、って言うか、企業統治とはなんぞや、って言うか。
Re:どっちもどっちだなぁ (スコア:2, 興味深い)
考慮漏れのによる稼動増を末端に「押し付けるから」嫌がられるんです。
システム側で問題解決するのと、末端の稼動増の費用を比べて、経営層に了解取ってらだと問題無いんですけどね。
そうすると、末端での対応にするにしても稼動増の理由説明が出来るから、人も増やせます。
全体見えてない状況で、業務フローの整理もせず、システム構築に走るばかを何度も見てますが、大体泥沼にはまって動かないシステムになるんだよなあ....。
Re: (スコア:0)
BPMが得意と謳っていて、実績あるコンサル会社でも入れれば良いんですけどね。
金さえ出せば、面倒な作業やってくれますから楽なものです。
(但し、それだけ全体の見通しが面倒な案件に限る)
>泥沼にはまって動かないシステムになる
今問題ないのに、わざわざ泥沼にはまる事はないと思いますが、
穴の開いたバケツで水を汲んでいるのに、変えようとしないのは、
やっぱり泥沼にはまっているのと同じ事ですからね。
逆に言うと
Re:どっちもどっちだなぁ (スコア:1, 興味深い)
大抵上は変更をなしにします。
つうか、変えましょうと言うのは主に現場だと思うが。