全社システム2 組織構造の整理

大企業と呼ばれる会社では、数多くの部署が存在します。

本社管理部門は、どこの会社も役割としてはほぼ同じです。
戦略性の有無、力関係、企業文化の特色など個性があると思いますが、基本的な役割としては人事、経理、法務、監査、財務、総務、情シスといった部署の区分けと分担が行われています。
(役割がほぼ各社共通だからこそ、この分野のERPパッケージは適合率が高い)

これに対し、事業部門は複雑です。
事業の多角化を行っていなければ、シンプルな職能別組織(機能別組織)のままですが、一般的に大企業は多彩な事業を展開しています。

複数事業に対応した組織構造は、独立採算型の組織(事業部制、社内カンパニー制、社外カンパニー制)、マトリクス組織、マトリクスから独自アレンジした組織、に大別できます。
私の限定的な知識では、事業部制をお使いの企業が多いように思います。

これら組織構造、結局のところはヒト、モノ、カネの権限をどう管理するか、の違いです。
どのような意思決定、どのような決済ルートとなっているかで、事業活動の効率、機動力に直結します。

「社員が一丸となって協力し、同じベクトルで全力を出し、総合力を発揮する」
そんな都合の良いことは夢物語だとは、言うまでもありません。
組織は人の集まりであって、人は感情の生き物です。出世(評価)の欲、人の好き嫌いを始め、様々な思いが交錯しています。

必然的に、過度な自己顕示や、足の引っ張り合い、自部署への利益誘導などが残念ながら発生しますので、その負の面を少しでも抑制するため、そして機動力を高めるため、組織構造のデザインが見直され続けます。

SEは、組織構造(オトナの事情)に口を出すわけではありません。
が、理解はしておくべきです。
採用されている組織構造という事実を踏まえ、システムの企画起案、設計開発、展開に加味していきます。

例えば、システム化の予算を確保するための構図。
例えば、業務上のデータフロー全体をデザインするための前提。
例えば、人間系&システム支援の組合せで効果を最大化するためのシナリオ検討。
例えば、データアクセス権(他の事業部に開示する/しない、等々)の設計。
例えば、システムテスト、運用テストの計画、実施において、「何を以ってヨシとするか」の判断。
例えば、事前説明会、運用検討会、操作説明会などを実施する対象部署、必要回数などの計画。

これらは全て、組織軸を抜きに考えていくと、目を閉じてボールを投げるようなものです。
「言われた通りにやります」というスタンスや立場の人はともかく、システム成功に導く当事者の1人であるならば、必須の考慮事項と考えます。


システムエンジニアランキング

シェアする

  • このエントリーをはてなブックマークに追加

フォローする