ਐਂਟਰਪ੍ਰਾਈਜ਼ AI (Enterprise AI) ਬਦਲ ਗਿਆ ਹੈ। ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਮਨਾਉਣਾ ਵੀ ਇੱਕ ਵੱਡੀ ਜੰਗ ਵਰਗਾ ਸੀ। ਹੁਣ ਬਜਟ ਮੌਜੂਦ ਹਨ। ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਹਰੀ ਝੰਡੀ ਮਿਲ ਰਹੀ ਹੈ। ਰੋਡਮੈਪਸ 'ਤੇ ਯੂਜ਼ ਕੇਸਾਂ (use cases) ਦੀ ਭਰਮਾਰ ਹੋ ਰਹੀ ਹੈ। ਫਿਰ ਵੀ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਮਹਿੰਗੇ ਪ੍ਰਯੋਗਾਂ ਵਜੋਂ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ ਕਾਰੋਬਾਰ ਦੇ ਚੱਲਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ। ਮਾਡਲ ਠੀਕ ਹਨ। ਸਮੱਸਿਆ ਬਾਕੀ ਸਭ ਕੁਝ ਹੈ।

ਜਿੱਥੇ ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ

ਹਰ ਕੋਈ ਡੈਮੋ (demo) ਨੂੰ ਪਸੰਦ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਟੋਟਾਈਪ (prototype) ਬੇਮਿਸਾਲ ਸ਼ੁੱਧਤਾ ਨਾਲ ਚਰਨ (churn) ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ। ਬੋਰਡ ਸਹਿਮਤੀ ਦਿੰਦਾ ਹੈ। ਫੰਡ ਮਿਲਦੇ ਹਨ। ਫਿਰ ਚੁੱਪ ਛਾ ਜਾਂਦੀ ਹੈ। ਪ੍ਰੂਫ ਆਫ ਕੰਸੈਪਟ (proof of concept) ਨੂੰ ਮਨਜ਼ੂਰੀ ਮਿਲ ਜਾਂਦੀ ਹੈ, ਪਰ ਤਰੱਕੀ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਕੀ ਹੋਇਆ?

ਬਿਜ਼ਨਸ ਟੀਮਾਂ ਡੈਸ਼ਬੋਰਡ ਵੱਲ ਦੇਖਦੀਆਂ ਹਨ ਪਰ ਇਹ ਸਮਝ ਨਹੀਂ ਪਾ ਸਕਦੀਆਂ ਕਿ ਇਹ ਉਹਨਾਂ ਦੇ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਕਾਜ (workflow) ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਉਹ ਡਾਟਾ ਪਾਈਪਲਾਈਨ (data pipeline) ਜਿਸਨੇ ਮਾਡਲ ਨੂੰ ਡਾਟਾ ਦਿੱਤਾ, ਇੱਕ ਵਾਰੀ ਦਾ ਮੈਨੂਅਲ ਐਕਸਟ੍ਰੈਕਟ (manual extract) ਸੀ ਜਿਸਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ ਸੀ। ਮਿਧਿਆਤ (compliance) ਦੇ ਨਿਯਮ ਵਿਚਕਾਰ ਹੀ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਸਿਸਟਮ ਸਾਫ਼ ਇਨਪੁੱਟਸ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜੋ CRM ਨੇ ਕਦੇ ਨਹੀਂ ਦਿੱਤੇ। AI ਇੱਕ ਨੋਟਬੁੱਕ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਸੰਸਥਾ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ।

ਇਹ ਡਿਲੀਵਰੀ ਦੀ ਅਸਫਲਤਾ ਹੈ। ਇੱਕ ਮਾਡਲ ਜੋ 95 ਫੀਸਦੀ ਸ਼ੁੱਧਤਾ (accuracy) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਸ਼ਾਇਦ ਹੈਕਾਥਨ (hackathon) ਜਿੱਤ ਸਕਦਾ ਹੈ। ਪਰ ਜੇਕਰ ਬਾਕੀ ਪੰਜ ਫੀਸਦੀ ਆਡਿਟ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਜਾਂ ਸੁਰੱਖਿਆ ਉਲੰਘਣਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ, ਤਾਂ ਆਪਰੇਸ਼ਨ ਇਸਨੂੰ ਬੰਦ ਕਰ ਦੇਣਗੇ। ਇੰਜੀਨੀਅਰ ਤਕਨੀਕੀ ਪ੍ਰਾਪਤੀਆਂ ਦਾ ਜਸ਼ਨ ਮਨਾਉਂਦੇ ਹਨ। ਬਿਜ਼ਨਸ ਯੂਨਿਟ ਅਜਿਹੇ ਨਤੀਜਿਆਂ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ ਜੋ ਕਦੇ ਆਉਂਦੇ ਹੀ ਨਹੀਂ। ਇਹਨਾਂ ਦੋਵਾਂ ਵਿਚਕਾਰਲੀ ਦੂਰੀ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੋਜੈਕਟ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ।

ਟ੍ਰਾਂਸਲੇਸ਼ਨ ਗੈਪ (The Translation Gap)

ਇਸਨੂੰ ਜੋ ਵੀ ਕਹਿਣਾ ਚਾਹੋ ਕਹੋ। ਐਗਜ਼ੀਕਿਊਟਿਵਜ਼ (Executives) ਰੈਵੇਨਿਊ ਵਾਧਾ ਜਾਂ ਲਾਗਤ ਵਿੱਚ ਕਮੀ ਚਾਹੁੰਦੇ ਹਨ। ਆਪਰੇਸ਼ਨਜ਼ (Operations) ਬਿਨਾਂ ਕਿਸੇ ਉਲਝਣ ਦੇ ਤੇਜ਼ੀ ਚਾਹੁੰਦੇ ਹਨ। ਡਾਟਾ ਟੀਮਾਂ ਅਜਿਹੇ ਸਕੀਮਾ (schemas) ਚਾਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਮਝ ਆਉਣ ਵਾਲੇ ਹੋਣ। ਇੰਜੀਨੀਅਰ ਅਪਟਾਈਮ (uptime) ਅਤੇ ਸਾਫ਼ APIs ਚਾਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇੱਛਾ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ।

ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ, ਤਾਂ ਹਰ ਸਮੂਹ ਕਿਸੇ ਵੱਖਰੀ ਚੀਜ਼ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਇੰਜੀਨੀਅਰ ਸ਼ਾਇਦ ਇੱਕ ਪ੍ਰੈਡਿਕਸ਼ਨ ਐਂਡਪੁਆਇੰਟ (prediction endpoint) ਤੋਂ ਲੇਟੈਂਸੀ (latency) ਘਟਾਉਣ ਲਈ ਹਫ਼ਤਿਆਂ ਬਿਤਾ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸੇਲਜ਼ ਟੀਮ ਅਜੇ ਵੀ ਸਭ ਕੁਝ ਐਕਸਲ (Excel) ਵਿੱਚ ਐਕਸਪੋਰਟ ਕਰ ਰਹੀ ਹੈ ਕਿਉਂਕਿ UI ਉਹਨਾਂ ਨੂੰ ਉਲਝਾਉਂਦਾ ਹੈ। ਇੱਕ ਡਾਟਾ ਸਾਇੰਟਿਸਟ AUC ਦੇ ਚੌਥੇ ਦਸ਼ਮਲਵ (decimal place) ਬਾਰੇ ਚਿੰਤਤ ਹੋ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਵੇਅਰਹਾਊਸ ਟੀਮ ਛੇ ਮਹੀਨਿਆਂ ਤੋਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡ ਵਿੱਚ 'nulls' ਲੌਗ ਕਰ ਰਹੀ ਹੈ। ਕੋਈ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਉਹ ਬੱਸ ਵੱਖਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਬੋਲ ਰਹੇ ਹਨ।

ਇਹ ਮਿਸਅਲਾਈਨਮੈਂਟ (misalignment) ਹੀ ਉਹ ਸਭ ਤੋਂ ਵੱਡਾ ਕਾਰਨ ਹੈ ਜਿਸ ਕਰਕੇ ਪਾਇਲਟ ਫੇਜ਼ ਤੋਂ ਬਾਅਦ AI ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ GPU ਦੀ ਘਾਟ ਨਹੀਂ ਹੈ। ਇਹ PhDs ਦੀ ਕਮੀ ਨਹੀਂ ਹੈ। ਇਹ ਉਸ ਵਿਅਕਤੀ ਦੀ ਅਣਹੋਂਦ ਹੈ ਜੋ ਇਹਨਾਂ ਸਮੂਹਾਂ ਦੇ ਵਿਚਕਾਰ ਬੈਠ ਕੇ ਇੱਕ ਸਾਂਝੀ ਅਸਲੀਅਤ ਬਣਾ ਸਕੇ।

ਫਾਰਵਰਡ ਡਿਪਲੌਇਡ ਇੰਜੀਨੀਅਰ (Forward Deployed Engineers) ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ

ਫਾਰਵਰਡ ਡਿਪਲੌਇਡ ਇੰਜੀਨੀਅਰ (FDEs) ਉਹੀ ਪੁਲ ਹਨ। ਉਹ ਤੁਹਾਡੇ ਡਾਟਾ ਸਾਇੰਟਿਸਟਾਂ ਜਾਂ ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ। ਉਹ ਬਿਜ਼ਨਸ, ਇੰਜੀਨੀਅਰਿੰਗ, ਡਾਟਾ ਅਤੇ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਦੇ ਵਿਚਕਾਰ ਕੰਮ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਸੰਗਠਨਾਤਮਕ ਰਗੜ (organizational friction) ਨੂੰ ਸੁਧਾਰਿਆ ਜਾ ਸਕੇ ਜੋ ਤਕਨਾਲੋਜੀ ਦੇ ਲਾਂਚ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਸਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ।

ਜਦੋਂ ਇੱਕ FDE ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਕਦਮ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਅਸੁਖਾਵਾਂ ਸਵਾਲ ਪੁੱਛਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਦਾ ਹੈ। ਇਸ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਸਫਲ ਮੰਗਲਵਾਰ ਦੀ ਸਵੇਰ ਕਿਹੋ ਜਿਹੀ ਹੁੰਦੀ ਹੈ? ਕਿਹੜੇ ਤਿੰਨ ਲੇਗਸੀ ਸਿਸਟਮ (legacy systems) ਅਸਲ ਵਿੱਚ ਇਸ ਡਾਟਾ ਸਟ੍ਰੀਮ ਨੂੰ ਫੀਡ ਕਰਦੇ ਹਨ? ਜੇਕਰ ਮਾਡਲ ਗਲਤ ਹੋਵੇ ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ? ਉਹ ਜਵਾਬਾਂ ਨੂੰ ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਟੀਮਾਂ ਗਲਤ ਹੱਲ ਬਣਾਉਣ ਵਿੱਚ ਮਹੀਨੇ ਬਰਬਾਦ ਨਾ ਕਰਨ।

ਇੱਕ ਆਮ ਐਂਗੇਜਮੈਂਟ (engagement) 'ਤੇ, ਇੱਕ FDE:

  • ਅਸਪਸ਼ਟ ਹੁਕਮਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸਟੇਕਹੋਲਡਰਾਂ (stakeholders) ਨਾਲ ਟੀਚਿਆਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰੇਗਾ
  • ਉਹਨਾਂ ਰੁਕਾਵਟਾਂ (bottlenecks) ਨੂੰ ਲੱਭਣ ਲਈ ਪ੍ਰਕਿਰਿਆ ਦੇ ਕੰਮਕਾਜ ਨੂੰ ਨੇੜਿਓਂ ਦੇਖੇਗਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕੋਈ Jira ਟਿਕਟ ਨਹੀਂ ਫੜ ਸਕਦੀ
  • ਉਹਨਾਂ ਡਾਟਾ ਨਿਰਭਰਤਾਵਾਂ (data dependencies) ਦੀ ਪਛਾਣ ਕਰੇਗਾ ਜੋ ਮੌਜੂਦਾ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਰਹਿ ਗਈਆਂ ਹਨ
  • ਉਹਨਾਂ ਲੋੜਾਂ ਨੂੰ ਠੋਸ ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲੇਗਾ
  • ਅਨੁਮਾਨਾਂ ਦੀ ਜਲਦੀ ਪੁਸ਼ਟੀ ਕਰੇਗਾ, ਅਕਸਰ ਉਸ ਆਪਰੇਸ਼ਨ ਟੀਮ ਨਾਲ ਕਾਲ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਕੇ ਜੋ ਇਸਦਾ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰੇਗੀ

FDEs ਸਿਰਫ਼