Copilot ਤੁਹਾਡੀ ਗੜਬੜ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ: Richard Harbridge [MVP] ਨਾਲ AI ਲਈ Microsoft 365 ਦਾ ਆਧੁਨਿਕੀਕਰਨ

Microsoft 365 Copilot ਕਿਸੇ ਸਾਫ਼-ਸੁਥਰੇ Microsoft 365 tenant ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਉਸ ਵਾਤਾਵਰਣ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਜੋ ਸੰਸਥਾਵਾਂ ਸਾਲਾਂ ਤੋਂ ਬਣਾਉਂਦੀਆਂ ਆ ਰਹੀਆਂ ਹਨ — ਜਿਸ ਵਿੱਚ SharePoint sites, Teams, OneDrive ਸਮੱਗਰੀ, ਡੁਪਲੀਕੇਟ ਦਸਤਾਵੇਜ਼, ਪੁਰਾਣੇ migrations, guest accounts, ਅਸੰਗਤ permissions, ਭੁੱਲੇ ਹੋਏ workspaces, ਟੁੱਟੇ ਹੋਏ ownership ਮਾਡਲ ਅਤੇ ਅਜਿਹੀ ਸਮੱਗਰੀ ਸ਼ਾਮਲ ਹੈ ਜਿਸਦੀ ਸਾਲਾਂ ਤੋਂ ਕਿਸੇ ਨੇ ਸਮੀਖਿਆ ਨਹੀਂ ਕੀਤੀ।

ਰਵਾਇਤੀ Microsoft 365 ਪ੍ਰਬੰਧਨ ਵਿੱਚ, ਇਸ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦਾ ਬਹੁਤ ਸਾਰਾ ਹਿੱਸਾ ਮੁਕਾਬਲਤਨ ਲੁਕਿਆ ਰਹਿ ਸਕਦਾ ਸੀ। AI ਇਹ ਸਥਿਤੀ ਬਦਲ ਦਿੰਦਾ ਹੈ।

M365.FM ਦੇ ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, Mirko Peters ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ Richard Harbridge ਨਾਲ, ਜੋ Microsoft MVP ਅਤੇ ShareGate ਵਿੱਚ ਉਦਯੋਗ ਸਲਾਹਕਾਰ ਹਨ, ਇਸ ਬਾਰੇ ਕਿ AI ਲਈ ਤਿਆਰੀ ਮੂਲ ਰੂਪ ਵਿੱਚ Microsoft 365 ਆਧੁਨਿਕੀਕਰਨ ਅਤੇ governance ਨਾਲ ਕਿਉਂ ਜੁੜੀ ਹੋਈ ਹੈ।

ਗੱਲਬਾਤ ਇਸ ਸਵਾਲ ਤੋਂ ਅੱਗੇ ਜਾਂਦੀ ਹੈ ਕਿ Copilot ਕਿਵੇਂ ਤੈਨਾਤ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਬਜਾਏ ਇੱਕ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੁੰਦੀ ਹੈ: ਅਸੀਂ AI ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੇ Microsoft 365 ਵਾਤਾਵਰਣ ਤੱਕ ਪਹੁੰਚ ਦੇ ਰਹੇ ਹਾਂ?

COPILOT ਗੜਬੜ ਪੈਦਾ ਨਹੀਂ ਕਰਦਾ — ਇਹ ਉਸਨੂੰ ਵਧਾਉਂਦਾ ਹੈ

ਇਸ ਗੱਲਬਾਤ ਦਾ ਇੱਕ ਕੇਂਦਰੀ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ Microsoft Copilot ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਬਿਲਕੁਲ ਨਵੀਆਂ governance ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਇਸਦੀ ਬਜਾਏ, AI ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਅਤੇ ਗੰਭੀਰ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਸੰਸਥਾਵਾਂ ਨੇ permissions, sharing, workspace ਬਣਾਉਣ, ownership, migrations, ਬਾਹਰੀ ਪਹੁੰਚ, ਨਾ-ਸਰਗਰਮ ਸਮੱਗਰੀ ਅਤੇ collaboration ਬਾਰੇ ਸਾਲਾਂ ਦੇ ਫੈਸਲੇ ਇਕੱਠੇ ਕੀਤੇ ਹੋਏ ਹਨ।

Richard ਇਸ ਇਕੱਠ ਨੂੰ "sprawl" ਦੇ ਸੰਕਲਪ ਰਾਹੀਂ ਬਿਆਨ ਕਰਦੇ ਹਨ।

Sprawl ਆਪਣੇ ਆਪ ਵਿੱਚ ਆਪਣੇ ਆਪ ਬੁਰਾ ਨਹੀਂ ਹੈ। Teams, SharePoint sites ਅਤੇ ਹੋਰ ਸਰੋਤਾਂ ਦੀ ਵਧਦੀ ਗਿਣਤੀ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਹੋ ਸਕਦੀ ਹੈ ਕਿ ਲੋਕ Microsoft 365 ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਅਪਣਾ ਰਹੇ ਹਨ।

ਸਮੱਸਿਆ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਵਾਧਾ ਸੰਸਥਾ ਦੀ ਉਸਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਹੁੰਦਾ ਹੈ।

ਅਸਥਾਈ permissions ਸਥਾਈ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਪੁਰਾਣੀਆਂ collaboration ਥਾਵਾਂ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦੀਆਂ ਹਨ। Ownership ਬਦਲ ਜਾਂਦੀ ਹੈ। ਕਾਰੋਬਾਰੀ ਢਾਂਚੇ ਬਦਲਦੇ ਹਨ। ਸਮੱਗਰੀ ਆਨਲਾਈਨ ਰਹਿੰਦੀ ਹੈ ਭਾਵੇਂ ਉਸਦਾ ਮੂਲ ਉਦੇਸ਼ ਖਤਮ ਹੋ ਚੁੱਕਾ ਹੋਵੇ।

ਫਿਰ Copilot ਇਸ ਮੌਜੂਦਾ ਵਾਤਾਵਰਣ ਦੇ ਉੱਪਰ ਕੰਮ ਕਰਦਾ ਹੈ।

MICROSOFT 365 SPRAWL ਸਿਰਫ਼ TEAMS ਅਤੇ SHAREPOINT ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ

ਜਦੋਂ ਲੋਕ "Microsoft 365 sprawl" ਸੁਣਦੇ ਹਨ, ਤਾਂ ਉਹ ਅਕਸਰ ਤੁਰੰਤ ਬਹੁਤ ਸਾਰੀਆਂ Teams ਜਾਂ SharePoint sites ਬਾਰੇ ਸੋਚਦੇ ਹਨ।

ਪਰ Richard ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ sprawl ਬਹੁ-ਆਯਾਮੀ ਹੈ।

ਸੰਸਥਾਵਾਂ workspace sprawl, permission ਅਤੇ access sprawl, ownership ਸਮੱਸਿਆਵਾਂ, ਨਾ-ਸਰਗਰਮ ਸਰੋਤਾਂ, lifecycle ਸਮੱਸਿਆਵਾਂ, ਪ੍ਰਬੰਧਕੀ ਜਟਿਲਤਾ, conditional access sprawl ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ integration ਅਤੇ connector sprawl ਦਾ ਅਨੁਭਵ ਕਰ ਸਕਦੀਆਂ ਹਨ।

AI ਦਾ ਉਭਾਰ ਇੱਕ ਹੋਰ ਆਯਾਮ ਜੋੜਦਾ ਹੈ।

Microsoft 365 ਵਾਤਾਵਰਣ ਵੱਧ ਤੋਂ ਵੱਧ ਡੇਟਾ, ਐਪਲੀਕੇਸ਼ਨਾਂ, AI ਸਿਸਟਮਾਂ ਅਤੇ agents ਨੂੰ ਜੋੜਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੰਸਥਾਵਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ workloads ਤੋਂ ਅੱਗੇ ਸੋਚਣਾ ਪਵੇਗਾ ਅਤੇ Microsoft 365 ਨੂੰ ਇੱਕ ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਈਕੋਸਿਸਟਮ ਵਜੋਂ ਵੇਖਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪਵੇਗਾ।

Governance ਨੂੰ ਹੁਣ ਕੇਵਲ "SharePoint governance" ਜਾਂ "Teams governance" ਵਜੋਂ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ।

MICROSOFT 365 GOVERNANCE ਵਿੱਚ ਭਰੋਸੇ ਦਾ ਪਾੜਾ

Richard ShareGate ਦੀ ਖੋਜ ਤੋਂ ਇੱਕ ਖਾਸ ਦਿਲਚਸਪ ਨਤੀਜਾ ਸਾਂਝਾ ਕਰਦੇ ਹਨ।

IT ਲੀਡਰਾਂ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਹਿੱਸਾ ਆਪਣੇ Microsoft 365 governance ਵਿੱਚ ਬਹੁਤ ਭਰੋਸਾ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ਫਿਰ ਵੀ, ਉਨ੍ਹਾਂ ਹੀ ਸੰਸਥਾਵਾਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਦੱਸਦਾ ਹੈ ਕਿ Copilot ਨੇ ਅਜਿਹੀ ਸਮੱਗਰੀ ਸਾਹਮਣੇ ਲਿਆਂਦੀ ਹੈ ਜੋ ਯੂਜ਼ਰ ਸ਼ਾਇਦ ਲੱਭ ਹੀ ਨਾ ਸਕਦੇ — ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸ਼ੱਕ ਹੈ ਕਿ ਅਜਿਹਾ ਹੋਇਆ ਹੈ ਪਰ ਉਹ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਨਹੀਂ ਜਾਣਦੇ।

ਇਹ governance ਨਿਯੰਤਰਣਾਂ ਦੇ ਉਪਲਬਧ ਹੋਣ ਅਤੇ ਲਗਾਤਾਰ ਸ਼ਾਸਿਤ ਵਾਤਾਵਰਣ ਹੋਣ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਫ਼ਰਕ ਦਰਸਾਉਂਦਾ ਹੈ।

ਕੇਵਲ policies, configuration ਵਿਕਲਪ ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਨਿਯੰਤਰਣ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ ਕਿ ਸੰਸਥਾ ਆਪਣੀ ਮੌਜੂਦਾ Microsoft 365 ਸਥਿਤੀ ਨੂੰ ਸਮਝਦੀ ਹੈ।

AI ਇਸ ਪਾੜੇ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦਾ ਹੈ।

ਕੀ Microsoft ਨੇ collaboration ਨੂੰ ਬਹੁਤ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ?

Microsoft Teams, SharePoint ਅਤੇ OneDrive ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਸਫਲ ਹਨ ਕਿਉਂਕਿ Microsoft ਨੇ collaboration ਨੂੰ ਬੇਹੱਦ ਆਸਾਨ ਬਣਾਇਆ ਹੈ।

ਪਰ ਆਸਾਨ collaboration ਵਧੇਰੇ ਸਰੋਤ ਬਣਾਉਣਾ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।

ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਸੰਸਥਾਵਾਂ ਵੱਲੋਂ ਅਪਣਾਇਆ ਗਿਆ ਇੱਕ ਜਵਾਬ workspace ਬਣਾਉਣ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਰਿਹਾ ਹੈ। Richard ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਕੇਵਲ ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਹੱਲ ਨਹੀਂ ਕਰਦਾ।

ਅੱਜ ਬਣਾਇਆ ਗਿਆ ਇੱਕ workspace ਛੇ ਮਹੀਨਿਆਂ, ਇੱਕ ਸਾਲ ਜਾਂ ਦੋ ਸਾਲਾਂ ਬਾਅਦ ਬਿਲਕੁਲ ਵੱਖਰੇ ਉਦੇਸ਼ ਦੀ ਸੇਵਾ ਕਰ ਸਕਦਾ ਹੈ।

ਇਸਦੇ ਮਾਲਕ ਬਦਲ ਸਕਦੇ ਹਨ।

ਸੰਸਥਾ ਦੀ ਪੁਨਰਗਠਨ ਹੋ ਸਕਦੀ ਹੈ।

ਪ੍ਰੋਜੈਕਟ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ।

ਸਮੱਗਰੀ ਅਪ੍ਰਸੰਗਿਕ ਹੋ ਸਕਦੀ ਹੈ।

ਜਿਹੜੇ ਲੋਕ ਸ਼ੁਰੂ ਵਿੱਚ ਸਮਝਦੇ ਸਨ ਕਿ workspace ਕਿਉਂ ਮੌਜੂਦ ਸੀ, ਉਹ ਛੱਡ ਕੇ ਜਾ ਸਕਦੇ ਹਨ।

ਇਸ ਲਈ governance ਕੇਵਲ provisioning 'ਤੇ ਨਹੀਂ ਰੁਕ ਸਕਦਾ। ਸੰਸਥਾਵਾਂ ਨੂੰ lifecycle ਪ੍ਰਕਿਰਿਆਵਾਂ, ਸਮੀਖਿਆਵਾਂ, attestations ਅਤੇ ਅਜਿਹੇ ਸੰਕੇਤਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਲਗਾਤਾਰ ਨਿਰਧਾਰਤ ਕਰਨ ਕਿ ਸਰੋਤ ਅਜੇ ਵੀ ਢੁਕਵੇਂ ਹਨ ਜਾਂ ਨਹੀਂ।

GOVERNANCE ਨੂੰ ਲਗਾਤਾਰ ਬਣਨਾ ਪਵੇਗਾ

ਇੱਕ-ਵਾਰੀ ਦੀਆਂ cleanup ਪ੍ਰੋਜੈਕਟਾਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ।

ਕੋਈ ਸੰਸਥਾ Copilot ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਹੀਨਿਆਂ ਤੱਕ ਆਪਣੇ Microsoft 365 ਵਾਤਾਵਰਣ ਦੀ ਸਫ਼ਾਈ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਲਗਾਤਾਰ governance ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਸਮੱਸਿਆਵਾਂ ਹੌਲੀ-ਹੌਲੀ ਵਾਪਸ ਆ ਜਾਣਗੀਆਂ।

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੰਸਥਾਵਾਂ ਨੂੰ ownership, permissions, ਨਾ-ਸਰਗਰਮੀ, lifecycle ਪ੍ਰਬੰਧਨ, archiving ਅਤੇ retirement ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੁਹਰਾਉਣਯੋਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਲੋੜ ਹੈ।

ਉਦੇਸ਼ Microsoft 365 sprawl ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਨਾ ਨਹੀਂ ਹੈ।

ਇਹ ਅਣ-ਪ੍ਰਬੰਧਿਤ sprawl ਨੂੰ ਪ੍ਰਬੰਧਿਤ sprawl ਵਿੱਚ ਬਦਲਣਾ ਹੈ।

COPILOT ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਇੱਕ ਉਦਾਹਰਣ ਲਓ: 10,000 ਕਰਮਚਾਰੀਆਂ ਵਾਲਾ ਇੱਕ ਉੱਦਮ, ਹਜ਼ਾਰਾਂ Teams ਅਤੇ SharePoint sites, ਸਾਲਾਂ ਦੀ ਇਕੱਠੀ ਹੋਈ ਸਮੱਗਰੀ ਅਤੇ ਅਸੰਗਤ permissions।

ਇਸਨੂੰ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

Richard ਸੁਝਾਅ ਦਿੰਦੇ ਹਨ ਕਿ sprawl ਦੀਆਂ ਖਾਸ ਕਿਸਮਾਂ ਨੂੰ ਵੇਖਿਆ ਜਾਵੇ ਅਤੇ ਪਛਾਣਿਆ ਜਾਵੇ ਕਿ ਸੰਸਥਾ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਜੋਖਮ ਕਿੱਥੇ ਹੈ।

ਇੱਕ ਕੰਪਨੀ ਲਈ, ਇਹ access ਨਿਯੰਤਰਣ ਅਤੇ oversharing ਹੋ ਸਕਦਾ ਹੈ। ਦੂਜੀ ਲਈ, ਇਹ ਨਾ-ਸਰਗਰਮ ਸਮੱਗਰੀ ਅਤੇ lifecycle ਪ੍ਰਬੰਧਨ ਹੋ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਸੰਸਥਾ ਲਈ, privileged identities ਜਾਂ ਪ੍ਰਬੰਧਕੀ ਪ੍ਰਬੰਧਨ ਵੱਡੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ।

Microsoft 365 governance ਨੂੰ ਇੱਕ ਵੱਡੇ ਸਫ਼ਾਈ ਅਭਿਆਨ ਵਜੋਂ ਲੈਣ ਦੀ ਬਜਾਏ, ਸੰਸਥਾਵਾਂ ਸਮੱਸਿਆ ਨੂੰ ਮਾਪਣਯੋਗ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਵੰਡ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਖੇਤਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦੀਆਂ ਹਨ ਜਿੱਥੇ ਸੁਧਾਰ ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ।

COPILOT ਅਪਣਾਉਣਾ ਟੀਮ-ਅਧਾਰਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਗੱਲਬਾਤ ਇੱਕ ਰਵਾਇਤੀ Microsoft ਤਕਨਾਲੋਜੀ ਅਪਣਾਉਣ ਦੇ ਮਾਡਲ ਨੂੰ ਵੀ ਚੁਣੌਤੀ ਦਿੰਦੀ ਹੈ।

ਸੰਸਥਾਵਾਂ ਅਕਸਰ ਨਵੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਵੰਡੇ ਹੋਏ champions ਰਾਹੀਂ ਤੈਨਾਤ ਕਰਦੀਆਂ ਹਨ।

Richard ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ Copilot ਨੂੰ ਵਧੇਰੇ ਟੀਮ-ਕੇਂਦ੍ਰਿਤ ਅਪਣਾਉਣ ਦੇ ਮਾਡਲ ਤੋਂ ਲਾਭ ਹੁੰਦਾ ਹੈ।

ਸੰਸਥਾ ਭਰ ਵਿੱਚ ਬੇਸੰਬੰਧੀ champions ਵਿੱਚ ਥੋੜ੍ਹੀਆਂ ਲਾਇਸੈਂਸਾਂ ਵੰਡਣ ਦੀ ਬਜਾਏ, ਕੰਪਨੀਆਂ ਟੀਮਾਂ ਨੂੰ AI ਸਮਰੱਥਾਵਾਂ ਨਾਲ ਭਰਪੂਰ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਲੋਕ ਮਿਲ ਕੇ ਸਿੱਖਣ, ਸਾਂਝੇ ਅਭਿਆਸ ਵਿਕਸਿਤ ਕਰਨ ਅਤੇ Copilot ਨੂੰ ਸਹਿਯੋਗੀ ਕੰਮ ਦੇ ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨ।

AI ਅਪਣਾਉਣਾ ਕੇਵਲ ਵਿਅਕਤੀਆਂ ਨੂੰ ਇੱਕ ਹੋਰ ਉਤਪਾਦਕਤਾ ਸਾਧਨ ਦੇਣ ਬਾਰੇ ਨਹੀਂ ਹੈ।

ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਟੀਮਾਂ ਇਕੱਠੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

MICROSOFT 365 ਜੋਖਮ ਨੂੰ ਮਾਪਣਯੋਗ ਬਣਾਉਣਾ

Governance ਪਹਿਲਕਦਮੀਆਂ ਅਕਸਰ ਇਸ ਲਈ ਸੰਘਰਸ਼ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦਾ ਮੁੱਲ ਕਾਰੋਬਾਰੀ ਲੀਡਰਾਂ ਨੂੰ ਸਮਝਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।

ਗੱਲਬਾਤ ShareGate ਦੇ Risk Radar ਦੀ ਪੜਚੋਲ ਕਰਦੀ ਹੈ, ਜੋ ਸੰਸਥਾਵਾਂ ਨੂੰ Microsoft 365 sprawl ਦੀਆਂ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ, ਬੈਂਚਮਾਰਕਾਂ ਨਾਲ ਪਰਿਪੱਕਤਾ ਦੀ ਤੁਲਨਾ ਕਰਨ ਅਤੇ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਕਿਹੜੇ ਖੇਤਰਾਂ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਪਹੁੰਚ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ governance ਜੋਖਮ ਨੂੰ ਵਿੱਤੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਬਦਲਣਾ ਹੈ।

ਸਿਰਫ਼ "ਸਾਨੂੰ ਬਿਹਤਰ governance ਚਾਹੀਦਾ ਹੈ" ਕਹਿਣ ਦੀ ਬਜਾਏ, IT ਟੀਮਾਂ ਸੁਧਾਰਾਂ ਨੂੰ ਅਣ-ਪ੍ਰਬੰਧਿਤ ਜੋਖਮ ਦੀ ਸੰਭਾਵਿਤ ਲਾਗਤ ਨਾਲ ਜੋੜ ਸਕਦੀਆਂ ਹਨ।

ਇਹ Microsoft 365 ਆਧੁਨਿਕੀਕਰਨ ਅਤੇ governance ਨੂੰ ਇੱਕ ਹੋਰ ਪ੍ਰਬੰਧਕੀ IT ਪ੍ਰੋਜੈਕਟ ਦੀ ਬਜਾਏ ਇੱਕ ਕਾਰੋਬਾਰੀ ਨਿਵੇਸ਼ ਵਜੋਂ ਪੇਸ਼ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

AI ਏਜੰਟ governance ਨੂੰ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਬਣਾਉਂਦੇ ਹਨ

Copilot ਕਹਾਣੀ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਹੈ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਸੰਸਥਾਵਾਂ ਹੋਰ AI agents ਬਣਾਉਣਾ ਅਤੇ ਤੈਨਾਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, governance ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਜਾਂਦਾ ਹੈ।

Agents ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਉਹ tools, ਡੇਟਾ ਅਤੇ ਹੋਰ ਸਿਸਟਮਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਦੀ ਮਾਲਕੀ ਅਸਪਸ਼ਟ ਹੋ ਸਕਦੀ ਹੈ। Permissions ਵਿਕਸਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਸੰਸਥਾਵਾਂ ਨੂੰ ਆਖਰਕਾਰ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ agent lifecycle ਪ੍ਰਬੰਧਨ ਨਾਲ ਨਜਿੱਠਣਾ ਪਵੇਗਾ।

ਇੱਕ agent ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ?

ਉਸਦੀ ਸਮੀਖਿਆ ਕੌਣ ਕਰਦਾ ਹੈ?

ਉਹ ਕਿਹੜੇ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ?

ਜਦੋਂ ਉਸਦਾ ਮੂਲ ਮਾਲਕ ਛੱਡ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਕਦੋਂ ਕਿਸੇ agent ਨੂੰ ਸੇਵਾਮੁਕਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਕਦੋਂ ਕਈ agents ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਇਹ ਸਵਾਲ ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਹਨ ਜੋ ਸੰਸਥਾਵਾਂ ਨੂੰ Teams, SharePoint sites ਅਤੇ ਹੋਰ Microsoft 365 ਸਰੋਤਾਂ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਆਉਂਦੀਆਂ ਹਨ — ਸਿਵਾਏ ਇਸ ਦੇ ਕਿ AI ਗਤੀ ਅਤੇ ਪ੍ਰਭਾਵ ਦੋਵੇਂ ਵਧਾ ਦਿੰਦਾ ਹੈ।