SAP保守料のドタバタ

　日経コンピュータによれば、SAPは去年発表した保守料の値上げを見直して、一部ユーザでサービスの向上を計測して目標を達成したら値上げすると発表をしたらしい。
　ユーザは現在のサービスを保守料に見合うと評価しているのだろうか。まずは、ユーザが納得するレベルに料金を調整する必要がある。そして、ユーザごとにサービスレベルの目標と料金を決めるのが筋だ。
　さもなければ、一応はユーザが納得した現状を維持するしかない。
--------------------------
（注）SAPの地元ドイツでは、一方的な値上げは法的に許されていないとか。日本では許されると思いますか？

「泥棒資本主義」

　「泥棒資本主義」という言葉を聞いたことがある。初期の資本主義は、ルールが未整備で倫理も希薄で、儲かるならやりたい放題だという。
　資本主義が成熟すると、倫理も進歩する。たとえば携帯電話。新規契約で本体を安く売って、利用者を囲い込むやり方が問題とされて、乗り換えの敷居を下げた。
　ERPが普及した。利用企業は簡単には乗り換えられない。ここで一方的に保守料値上げを通告したＳＡＰ。一流企業の誇りはどうしたのだ。

コンプライアンス

　船場吉兆の「食べ残し使いまわし」事件。彼らのしたことは法律違反ではない。それにしても、一流料亭がここまでやるとは。「コンプライアンス」が法令遵守だけでないというひとつの事例だ。特に一流を名乗るなら、理想を追求しなければならない。
　ＳＡＰは保守料3割値上げを既存のユーザに一方的に通告。これはどうも契約違反ではないらしい。ＳＡＰは一流として恥ずかしくないの？
　ＳＡＰを信じた立場からはこんな悲しい話はない。

---------------
ＳＡＰの保守料値上げに関するプレス
　http://www.sap.com/japan/about/press/press.epx?pressid=9875
　非常に分かりにくいですが、「既存のお客様の移行スケジュール」が値上げについての説明です。移行しないという選択肢はないようです。
　この対応が法的に問題がある可能性はあると思います。独禁法とか。

　なお、この記事は旬を過ぎたら削除します。

リアルタイム経営のレポート

　経営が月次の世界からリアルタイムの世界に移ると、見る指標が変わる。
　自動車に例える。速度計、水温計、燃料計、積算距離計の中で月に1回だけ見て役に立つのはどれ？そう、積算距離計。月次の自動車には積算距離計しかいらない。
　では、リアルタイムの自動車の場合は積算距離計を常ににらむ？あるいは、横軸に時間、縦軸に積算距離をとった精緻なグラフ？そんなものは運転の役に立たない。全く別の計器がいる。他の3つがそれだ。

■久々の更新です。上の課題は、企業経営のケースではまだ答えが見つかっていません。TOCがヒントになりそうな気はしています。ご意見などいただければ幸いです。

「見える化」の意義

　営業マンの競争心を煽るために、営業部の部屋の壁に担当者別売上高グラフを貼るという話を聞く。
　本来の「見える化」は違う。方針・理念と中長期の目標と、年度予算や個人別目標を統合するために、それをシナリオにして壁に貼り、見せる。そして、目標と現実の乖離に早く気づくための担当別売上高グラフだ。
　さもないと、担当者は目先の仕事に追われる。目標を見失い、理念を忘れ、道を踏み外す。「見える化」は大事だと改めて思う。

プロマネを育てる

　システム部門でプロマネを育てるのは難しい。
　プログラムを作って欲しい利用部門と作ってあげたいシステム部門のプロジェクト、そんな経験ではプロマネに必要なリーダーシップは育たない。
　全体最適を志向するとき、業務の範囲は部門を超え、意見が対立する。そこで責任を引き受ければ、問題解決にリーダーシップを求められる。そのような環境ならプロマネが育つのだ。
　したがって、システム部門は全体最適を志向しなければならない。

情報システム投資の可否判断

　情報システム投資の可否をどう判断すべきか。難しいケースもあるが、合理化投資には判断基準がほしい。
　4年、5年で元が取れるというケースは企業の投資としては無意味だ。3年だとちょっと悩んでしまう人もいるだろう。2年だったらGOと言いたくなる。しかし、1年ぐらいを基準にすべきだと私は思う。1年で元が取れれば2年で捨てても悔いはない。仕事の進歩や環境の変化を前提にすれば、それ以上長く待つべきではないだろう。

たいていの仕事は変えられる

　「不易流行」という言葉がある。「不易」とは変わらないもの、「流行」とは変化するものだ。ところが、ビジネスプロセスの世界で「不易」を見極めるのは難しい。普通の人は、変えられることでも変えられないと思う。
　ERPでてこずるのがこれだ。今までの仕事の仕方にこだわらずに、素直にパッケージを当てはめてみよう。部分ではなんか変な感じのときもあるが、本当に問題なら明らかに分かる。明らかな問題だけを解決すればよい。

在庫管理は経理処理にあらず

　在庫管理のためのレポートとして受払表を最初に思い浮かべる人が多い。
　受払表とは、品目または品目分類ごとに前月末からの繰越、一か月分を集計した入庫と出庫、今月末の残高を表示したものだ。経理処理のためのレポートで、在庫評価や資金効率管理が目的ならこれでよいが、在庫が過大か過少か、安全在庫や調達ロットサイズをどうするか、今日はどれを手配すべきか、そんなことを受払表は語らない。在庫管理には受払表は無意味だ。

在庫管理、あなたならどうする？

　在庫管理は難しい。
　「残り2箱になったら、2箱を補充依頼する」という単純なケースでも、補充依頼をし忘れて在庫切れが起こる。担当者は他にも仕事をしていて、毎日在庫を数えていられない。在庫はいつの間にかなくなる。残り2箱になったらわかる仕組みが必要だ。
　そんな時、システム屋は在庫管理システムを作りたがる。その結果、たな卸し作業が必要になり、在庫は増加する。そんなことをしなくても解決できるはずだ。考えよう。