Org Chart vs. Organizational Structure: ਫ਼ਰਕ ਕੀ ਹੈ?

ਦਸ leaders ਨੂੰ ਇੱਕ org chart ਅਤੇ ਇੱਕ organizational structure ਵਿਚਕਾਰ ਫ਼ਰਕ ਪੁੱਛੋ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਠਹਿਰ ਜਾਣਗੇ। ਇਹ ਦੋਵੇਂ ਸ਼ਬਦ ਇੱਕ-ਦੂਜੇ ਦੇ ਬਦਲੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ — "ਆਓ org chart ਦੁਬਾਰਾ ਬਣਾਈਏ" ਦਾ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ ਹੁੰਦਾ ਹੈ "ਆਓ ਬਦਲੀਏ ਕਿ ਅਸੀਂ ਕਿਵੇਂ organized ਹਾਂ।" ਪਰ ਇਹ ਇੱਕੋ ਚੀਜ਼ ਨਹੀਂ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿਚਕਾਰਲਾ ਪਾੜਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ reorganizations ਚੁੱਪ-ਚਾਪ ਫ਼ੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ।

ਇੱਕ org chart ਇੱਕ ਤਸਵੀਰ ਹੈ। ਇੱਕ organizational structure ਉਹ system ਹੈ ਜਿਸ ਨੂੰ ਉਹ ਤਸਵੀਰ ਬਿਆਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ। ਤੁਸੀਂ ਤਸਵੀਰ ਨੂੰ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਦੁਬਾਰਾ ਖਿੱਚ ਸਕਦੇ ਹੋ; system ਬਦਲਣ ਵਿੱਚ ਮਹੀਨੇ ਲੱਗਦੇ ਹਨ। ਇੱਕ ਨੂੰ ਦੂਜਾ ਸਮਝ ਲੈਣਾ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਕੰਪਨੀਆਂ ਇੱਕ "reorg" ਦਾ ਐਲਾਨ ਕਰਦੀਆਂ ਹਨ, ਕੁਝ boxes ਇੱਧਰ-ਉੱਧਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ।

ਇੱਕ reorg ਜਿਸ ਨੇ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ

ਇੱਕ founder ਨੇ ਸਾਨੂੰ ਉਸ reorg ਬਾਰੇ ਦੱਸਿਆ ਜਿਸ 'ਤੇ ਉਹ ਸਭ ਤੋਂ ਮਾਣ ਕਰਦੇ ਸਨ — ਜਦੋਂ ਤੱਕ ਉਹ ਕੰਮ ਨਾ ਆਇਆ। ਉਨ੍ਹਾਂ ਨੇ ਇੱਕ ਵੀਕਐਂਡ org chart ਦੁਬਾਰਾ ਖਿੱਚਣ ਵਿੱਚ ਲਾਇਆ: ਸਾਫ਼-ਸੁਥਰੀਆਂ reporting lines, ਦੋ ਨਵੇਂ team leads, ਤਰਤੀਬਵਾਰ boxes। ਉਨ੍ਹਾਂ ਨੇ ਸੋਮਵਾਰ ਇਸ ਦਾ ਐਲਾਨ ਕੀਤਾ। "ਤਿੰਨ ਮਹੀਨੇ ਬਾਅਦ," ਉਨ੍ਹਾਂ ਨੇ ਮੰਨਿਆ, "ਉਹੀ ਤਿੰਨ ਫ਼ੈਸਲੇ ਹਾਲੇ ਵੀ ਮੇਰੇ ਮੇਜ਼ 'ਤੇ ਆ ਰਹੇ ਸਨ, ਨਵੇਂ leads ਹਾਲੇ ਵੀ ਹਰ ਚੀਜ਼ ਮੇਰੇ ਨਾਲ ਜਾਂਚ ਰਹੇ ਸਨ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਇੱਕੋ ਚੀਜ਼ ਜੋ ਬਦਲੀ ਸੀ ਉਹ ਇਹ ਸੀ ਕਿ ਲੋਕ ਆਪਣੇ titles ਬਾਰੇ ਉਲਝਣ ਵਿੱਚ ਸਨ।" ਉਨ੍ਹਾਂ ਨੇ ਤਸਵੀਰ update ਕੀਤੀ ਸੀ। Structure — ਜੋ ਅਸਲ ਵਿੱਚ ਫ਼ੈਸਲਾ ਕਰਦਾ ਸੀ — ਠੀਕ ਉੱਥੇ ਹੀ ਸੀ ਜਿੱਥੋਂ ਸ਼ੁਰੂ ਹੋਈ ਸੀ।

ਇਹੀ ਪੂਰਾ ਸਬਕ ਇੱਕ ਕਹਾਣੀ ਵਿੱਚ ਹੈ। chart ਨੂੰ ਦੁਬਾਰਾ ਖਿੱਚਣਾ ਤਬਦੀਲੀ ਵਰਗਾ ਲੱਗਾ ਪਰ ਕੁਝ ਨਹੀਂ ਦਿੱਤਾ, ਕਿਉਂਕਿ chart ਕਦੇ ਉਹ ਚੀਜ਼ ਸੀ ਹੀ ਨਹੀਂ ਜੋ ਕੰਪਨੀ ਨੂੰ ਰੋਕ ਰਹੀ ਸੀ।

ਸੰਖੇਪ ਜਵਾਬ

• Organizational structure ਇਹ ਹੈ ਕਿ ਕਿਸੇ ਕੰਪਨੀ ਦਾ ਕੰਮ, authority, ਅਤੇ ਜਾਣਕਾਰੀ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਤਰਤੀਬ ਦਿੱਤੇ ਗਏ ਹਨ — ਕੌਣ ਕੀ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ, ਕੌਣ ਕਿਸ ਚੀਜ਼ ਲਈ ਜਵਾਬਦੇਹ ਹੈ, teams ਕਿਵੇਂ coordinate ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਫ਼ੈਸਲੇ ਤੇ ਜਾਣਕਾਰੀ ਕਿਵੇਂ ਵਹਿੰਦੇ ਹਨ।
• ਇੱਕ org chart ਉਸ structure ਦੇ ਇੱਕ ਟੁਕੜੇ ਦੀ ਇੱਕ visual ਪੇਸ਼ਕਾਰੀ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ reporting lines। ਇਹ ਇੱਕ ਨਕਸ਼ਾ ਹੈ, ਇਲਾਕਾ ਨਹੀਂ।

Structure ਉਹ operating model ਹੈ। chart ਉਸ ਦੇ ਇੱਕ ਹਿੱਸੇ ਦਾ ਇੱਕ snapshot ਹੈ।

ਇੱਕ organizational structure ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

Structure ਕੰਪਨੀ ਦਾ operating system ਹੈ: ਜ਼ਿਆਦਾਤਰ-ਅਣਦਿਖ ਪ੍ਰਬੰਧਾਂ ਦਾ ਉਹ ਸਮੂਹ ਜੋ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ scale 'ਤੇ ਕੰਮ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਦੇ ਕਈ ਪਹਿਲੂ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਇੱਕ ਆਮ org chart ਦਿਖਾਉਂਦਾ ਹੈ:

• Grouping (departmentation) — ਲੋਕ units ਵਿੱਚ ਕਿਵੇਂ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: function, product, customer segment, geography, ਜਾਂ ਇੱਕ hybrid ਮੁਤਾਬਕ।
• Reporting lines — ਕੌਣ ਕਿਸ ਨੂੰ report ਕਰਦਾ ਹੈ। ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ chart ਆਮ ਤੌਰ 'ਤੇ ਫੜਦਾ ਹੈ।
• Decision rights — ਕੌਣ ਅਸਲ ਵਿੱਚ ਕੀ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ: ਕੌਣ ਇੱਕ hire ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ contract 'ਤੇ ਦਸਤਖ਼ਤ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ project ਖ਼ਤਮ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ price ਤੈਅ ਕਰ ਸਕਦਾ ਹੈ। ਅਕਸਰ reporting line ਵਰਗਾ ਨਹੀਂ ਹੁੰਦਾ।
• Span of control — ਹਰ manager ਨੂੰ ਕਿੰਨੇ ਲੋਕ report ਕਰਦੇ ਹਨ, ਜੋ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ teams ਕੋਲ ਕਿੰਨੀ ਅਸਲ autonomy ਹੈ।
• Accountability — ਜਦੋਂ ਕੋਈ ਚੀਜ਼ ਸਫ਼ਲ ਜਾਂ ਅਸਫ਼ਲ ਹੁੰਦੀ ਹੈ ਤਾਂ ਨਤੀਜੇ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ।
• Coordination mechanisms — ਉਹ meetings, rituals, ਸਾਂਝੇ metrics, ਅਤੇ processes ਜੋ ਵੱਖ-ਵੱਖ teams ਨੂੰ ਇੱਕ ਕੰਪਨੀ ਵਜੋਂ ਕੰਮ ਕਰਨ ਦਿੰਦੇ ਹਨ।

ਇੱਕ reporting line ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਸੇ ਦਾ manager ਕੌਣ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਫ਼ੈਸਲੇ ਕੌਣ ਕਰਦਾ ਹੈ, ਨਤੀਜੇ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਜਾਂ ਦੋ teams ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ aligned ਹੁੰਦੀਆਂ ਹਨ। ਇਹ structure ਦਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਕੋਈ chart ਨਹੀਂ ਦਿਖਾ ਸਕਦਾ।

ਇੱਕੋ ਜਿਹੇ org charts ਵਾਲੀਆਂ ਦੋ ਕੰਪਨੀਆਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਚੱਲ ਸਕਦੀਆਂ ਹਨ — ਇੱਕ ਜਿੱਥੇ managers ਕੋਲ ਅਸਲ authority ਹੈ, ਇੱਕ ਜਿੱਥੇ ਹਰ ਫ਼ੈਸਲਾ founder ਵੱਲ ਜਾਂਦਾ ਹੈ। ਇੱਕੋ ਤਸਵੀਰ, ਉਲਟ systems। ਇਹ organizational design ਵਿੱਚ ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਥਾਪਿਤ ਨੁਕਤਾ ਹੈ: ਇੱਕ organization ਦੀ ਅਸਲ structure ਉਸ ਦੇ decision rights ਅਤੇ accountabilities ਵਿੱਚ ਵਸਦੀ ਹੈ, ਨਾ ਕਿ ਇਸ ਦੇ reporting diagram ਵਿੱਚ।

ਇੱਕ org chart ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

ਇੱਕ org chart ਇੱਕ communication tool ਹੈ। ਇਸ ਦਾ ਕੰਮ structure ਦੇ ਇੱਕ ਪਹਿਲੂ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਪੜ੍ਹਨ-ਯੋਗ ਬਣਾਉਣਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ "ਕੌਣ ਕਿਸ ਨੂੰ report ਕਰਦਾ ਹੈ।" ਇੱਕ ਚੰਗਾ chart ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦਿੰਦਾ ਹੈ: ਇਸ team ਨੂੰ ਕੌਣ ਚਲਾਉਂਦਾ ਹੈ? ਮੈਂ ਕਿਸ ਵੱਲ escalate ਕਰਾਂ? ਉਹ department ਕਿੰਨਾ ਵੱਡਾ ਹੈ? ਇਹ ਕੀਮਤੀ ਹੈ। ਪਰ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਰਹੋ ਕਿ ਇੱਕ chart ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਕੀ ਲੁਕਾਉਂਦਾ ਹੈ:

ਇਹ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ

• ਰਸਮੀ reporting ਰਿਸ਼ਤੇ
• hierarchy ਦੀ ਸ਼ਕਲ (ਉੱਚੀ vs. ਸਮਤਲ)
• Team ਦੇ ਆਕਾਰ ਅਤੇ groupings
• seniority ਦਾ ਇੱਕ ਮੋਟਾ ਅੰਦਾਜ਼ਾ

ਇਹ ਕੀ ਲੁਕਾਉਂਦਾ ਹੈ

• ਫ਼ੈਸਲੇ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਲਏ ਜਾਂਦੇ ਹਨ
• ਉਹ ਅਣਰਸਮੀ networks ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਵਾਉਣ ਲਈ ਵਰਤਦੇ ਹਨ
• teams lines ਦੇ ਪਾਰ ਕਿਵੇਂ coordinate ਕਰਦੀਆਂ ਹਨ
• ਜਦੋਂ ਕੰਮ ਕਈ boxes ਵਿੱਚ ਫੈਲਿਆ ਹੋਵੇ ਤਾਂ accountability
• ਕੀ structure ਉਸ ਨਾਲ ਮੇਲ ਵੀ ਖਾਂਦੀ ਹੈ ਜਿਵੇਂ ਕੰਪਨੀ ਚੱਲਦੀ ਹੈ

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਇੱਕ chart ਬਿਲਕੁਲ ਤਰਤੀਬਵਾਰ ਦਿਖ ਸਕਦਾ ਹੈ ਜਦਕਿ ਇਸ ਦੇ ਹੇਠਲਾ organization ਇੱਕ ਗੜਬੜ ਹੋਵੇ — ਅਤੇ ਕਿਉਂ ਇੱਕ ਥੋੜ੍ਹਾ ਗੜਬੜ chart ਅਜਿਹੀ ਕੰਪਨੀ ਉੱਤੇ ਬੈਠ ਸਕਦਾ ਹੈ ਜੋ ਬਹੁਤ ਵਧੀਆ ਚੱਲਦੀ ਹੈ।

ਨਾਲੋ-ਨਾਲ

ਇੱਕੋ chart, ਵੱਖਰੀਆਂ structures

ਇੱਥੇ ਪ੍ਰਚਲਿਤ ਸੋਚ ਦੇ ਉਲਟ ਹਿੱਸਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ reorgs ਖੁੰਝਾ ਦਿੰਦੀਆਂ ਹਨ: ਇੱਕੋ boxes-ਅਤੇ-lines chart ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀਆਂ structures ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰ ਸਕਦਾ ਹੈ। ਆਮ ਕਿਸਮਾਂ —

• Functional — discipline ਮੁਤਾਬਕ grouped (ਸਾਰੇ engineers ਇਕੱਠੇ)। ਕੁਸ਼ਲ ਅਤੇ ਸਪੱਸ਼ਟ, ਪਰ cross-functional ਕੰਮ ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ coordination ਚਾਹੀਦੀ ਹੈ।
• Divisional — product, market, ਜਾਂ region ਮੁਤਾਬਕ grouped, ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ functions ਨਾਲ। ਤੇਜ਼ ਅਤੇ ਜ਼ਿਆਦਾ autonomous, ਪਰ ਮਿਹਨਤ duplicate ਕਰਦਾ ਹੈ ਅਤੇ culture ਨੂੰ ਖੰਡਿਤ ਕਰ ਸਕਦਾ ਹੈ।
• Matrix — ਲੋਕ ਦੋ axes ਨਾਲ report ਕਰਦੇ ਹਨ (ਜਿਵੇਂ, ਇੱਕ function ਅਤੇ ਇੱਕ product)। ਜਟਿਲ ਕੰਮ ਲਈ ਤਾਕਤਵਰ, ਪਰ decision rights ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਨਹੀਂ ਤਾਂ ਇਹ gridlock ਪੈਦਾ ਕਰਦਾ ਹੈ।
• Flat / flatarchy — ਥੋੜ੍ਹੀਆਂ ਪਰਤਾਂ, ਚੌੜੇ spans, ਬਹੁਤ autonomy। ਸ਼ੁਰੂ ਵਿੱਚ ਤੇਜ਼; ਜਿਉਂ-ਜਿਉਂ headcount ਚੜ੍ਹਦੀ ਹੈ coordination ਔਖੀ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ।
• Network / team-of-teams — ਛੋਟੀਆਂ autonomous units ਜੋ ਸਾਂਝੇ goals ਦੁਆਲੇ coordinate ਕਰਦੀਆਂ ਹਨ। ਲਚਕਦਾਰ, ਪਰ ਮਜ਼ਬੂਤ ਸਾਂਝੇ culture ਅਤੇ principles 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ।

— ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ charts ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ matrix ਅਤੇ ਇੱਕ functional org ਅਕਸਰ ਕਾਗ਼ਜ਼ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ। ਫ਼ਰਕ decision rights ਅਤੇ accountability ਵਿੱਚ ਵਸਦਾ ਹੈ: structure, ਨਾ ਕਿ ਤਸਵੀਰ।

ਦੋਵਾਂ ਨੂੰ ਰਲਗੱਡ ਕਰਨਾ ਮਹਿੰਗਾ ਕਿਉਂ ਹੈ

ਜਦੋਂ leaders chart ਨੂੰ structure ਮੰਨਦੇ ਹਨ, ਤਾਂ ਅੰਦਾਜ਼ੇ-ਯੋਗ ਅਸਫ਼ਲਤਾਵਾਂ ਆਉਂਦੀਆਂ ਹਨ:

1. ਅਜਿਹੀਆਂ reorgs ਜੋ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀਆਂ — boxes ਹਿੱਲਦੇ ਹਨ, titles ਬਦਲਦੇ ਹਨ, ਇੱਕ ਨਵਾਂ chart ਆਉਂਦਾ ਹੈ, ਪਰ decision rights ਅਤੇ accountability ਆਪਣੀ ਥਾਂ ਰਹਿੰਦੇ ਹਨ। (ਸਾਡੇ founder ਦੀ ਵੀਕਐਂਡ reorg।)
2. ਲੁਕੇ ਹੋਏ bottlenecks — chart ਕਹਿੰਦਾ ਹੈ ਕਿ ਇੱਕ manager ਇੱਕ team ਦਾ ਮਾਲਕ ਹੈ, ਪਰ ਹਰ ਅਸਲ ਫ਼ੈਸਲਾ ਹਾਲੇ ਵੀ founder ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਕੁਝ ਵੀ ਸੌਂਪਿਆ ਨਹੀਂ ਗਿਆ ਸੀ।
3. Accountability ਦੇ ਪਾੜੇ — ਜੋ ਕੰਮ ਕਈ boxes ਵਿੱਚ ਫੈਲਿਆ ਹੈ ਉਸ ਦਾ ਕੋਈ ਸਪੱਸ਼ਟ ਮਾਲਕ ਨਹੀਂ, ਕਿਉਂਕਿ chart ਸਿਰਫ਼ ਖੜ੍ਹੀਆਂ lines ਬਿਆਨ ਕਰਦਾ ਹੈ, ਖਿਤਿਜੀ ownership ਨਹੀਂ।
4. Structure debt — chart update ਹੋ ਜਾਂਦਾ ਹੈ; ਲੋਕਾਂ ਦੇ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ। ਸਮੇਂ ਨਾਲ ਤਸਵੀਰ ਅਤੇ ਹਕੀਕਤ ਇੰਨੀ ਦੂਰ ਖਿਸਕ ਜਾਂਦੇ ਹਨ ਕਿ chart ਸਰਗਰਮੀ ਨਾਲ ਗੁਮਰਾਹ ਕਰਨ ਵਾਲਾ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਸ ਨੂੰ ਸਹੀ ਕਿਵੇਂ ਕਰੀਏ

ਪਹਿਲਾਂ structure design ਕਰੋ, ਫਿਰ chart ਨੂੰ ਉਸ ਨੂੰ ਬਿਆਨ ਕਰਨ ਦਿਓ — ਉਲਟਾ ਨਹੀਂ:

• ਕੰਮ ਅਤੇ strategy ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਕੰਪਨੀ ਨੂੰ ਕਿਸ ਚੀਜ਼ ਵਿੱਚ ਚੰਗਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? ਕਿਹੜੇ ਫ਼ੈਸਲੇ ਤੇਜ਼ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ? ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ group ਕਰੀਏ ਅਤੇ authority ਕਿੱਥੇ ਬੈਠਣੀ ਚਾਹੀਦੀ ਹੈ।
• Decision rights ਅਤੇ accountability ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਜੋ roles ਮਾਅਨੇ ਰੱਖਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਲਿਖੋ ਕਿ ਕੌਣ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ, ਕਿਸ ਦੀ ਸਲਾਹ ਲਈ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਇਹੀ ਅਸਲ structure ਹੈ।
• ਫਿਰ chart ਖਿੱਚੋ ਉਸ ਦੇ ਇੱਕ ਈਮਾਨਦਾਰ ਸਾਰ ਵਜੋਂ — ਅਤੇ ਜਿਵੇਂ ਹਕੀਕਤ ਬਦਲਦੀ ਹੈ ਇਸ ਨੂੰ update ਰੱਖੋ, ਤਾਂ ਜੋ ਇਹ ਕਦੇ ਇੱਕ ਦਿਲਾਸਾ ਦੇਣ ਵਾਲੀ ਕਲਪਨਾ ਨਾ ਬਣੇ।

ਆਪਣੇ-ਆਪ ਨੂੰ ਪੁੱਛੋ

• ਤੁਹਾਡੇ ਤਿੰਨ ਸਭ ਤੋਂ ਅਹਿਮ ਵਾਰ-ਵਾਰ ਆਉਣ ਵਾਲੇ ਫ਼ੈਸਲਿਆਂ ਲਈ, ਕੀ ਹਰ ਕੋਈ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੌਣ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ?
• ਜੇ ਤੁਸੀਂ ਕੱਲ੍ਹ ਆਪਣਾ org chart ਦੁਬਾਰਾ ਖਿੱਚੋ, ਕੀ ਫ਼ੈਸਲੇ ਕਿਵੇਂ ਲਏ ਜਾਂਦੇ ਹਨ ਉਸ ਬਾਰੇ ਕੁਝ ਵੀ ਬਦਲੇਗਾ?
• ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਕਿੱਥੇ boxes ਵਿਚਕਾਰ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਮਾਲਕ ਦੇ ਡਿੱਗਦਾ ਹੈ?
• ਕੀ ਤੁਹਾਡਾ chart ਬਿਆਨ ਕਰਦਾ ਹੈ ਕਿ ਕੰਪਨੀ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਚੱਲਦੀ ਹੈ — ਜਾਂ ਜਿਵੇਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਚੱਲੇ?

ਮੁੱਖ ਗੱਲ

Chart structure ਤੋਂ ਹੇਠਾਂ (downstream) ਹੈ। Structure ਨੂੰ ਸਹੀ ਕਰੋ — grouping, decision rights, accountability, coordination — ਅਤੇ org chart ਆਪਣਾ ਖ਼ਿਆਲ ਆਪ ਰੱਖ ਲੈਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਗ਼ਲਤ ਕਰੋ, ਅਤੇ ਦੁਨੀਆ ਦਾ ਸਭ ਤੋਂ ਸੋਹਣਾ chart ਵੀ ਤੁਹਾਨੂੰ ਨਹੀਂ ਬਚਾਏਗਾ। ਅਸਪੱਸ਼ਟ decision rights ਉੱਤੇ ਇੱਕ ਸੁੰਦਰ diagram organizational ਆਤਮ-ਧੋਖੇ ਦੇ ਸਭ ਤੋਂ ਆਮ ਰੂਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: ਇਹ ਸਪੱਸ਼ਟਤਾ ਵਰਗਾ ਦਿਖਦਾ ਹੈ ਅਤੇ ਹਫੜਾ-ਦਫੜੀ ਵਾਂਗ ਵਿਹਾਰ ਕਰਦਾ ਹੈ।