13 ਅਗ 2025·8 ਮਿੰਟ
ਡੈਨਿਯਲ ਡਾਇਨਸ, UiPath, ਅਤੇ “ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਮੋਨਟਾਈਜ਼ ਕਰਨਾ
Daniel Dines ਅਤੇ UiPath ਨੇ “ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਇੱਕ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਕਿਵੇਂ ਪੈਕੇਜ ਕੀਤਾ: ਉਤਪਾਦ ਚੋਣਾਂ, ਗੋ-ਟੂ-ਮਾਰਕਿਟ ਚਾਲਾਂ, ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਟੋਮੇਸ਼ਨ ਖਰੀਦਦਾਰਾਂ ਲਈ ਸਬਕ।
Daniel Dines ਅਤੇ UiPath ਨੇ “ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਇੱਕ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਕਿਵੇਂ ਪੈਕੇਜ ਕੀਤਾ: ਉਤਪਾਦ ਚੋਣਾਂ, ਗੋ-ਟੂ-ਮਾਰਕਿਟ ਚਾਲਾਂ, ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਟੋਮੇਸ਼ਨ ਖਰੀਦਦਾਰਾਂ ਲਈ ਸਬਕ।
“ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਉਹ ਕੰਮ ਹੈ ਜਿਸ 'ਤੇ ਕੋਈ ਸ਼ੇਰ ਨਹੀਂ ਕਰਦਾ—ਪਰ ਹਰ ਵੱਡੀ ਕੰਪਨੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਰਹਿੰਦੀ ਹੈ। ਸੋਚੋ: ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਨਕਲ ਕਰਨਾ, ਇਨਵਾਇਸ ਨੂੰ ਖਰੀਦ ਆਰਡਰ ਨਾਲ ਮਿਲਾਉਣਾ, ਯੂਜਰ ਖਾਤੇ ਬਣਾਉਣਾ, ਸਪ੍ਰੈਡਸ਼ੀਟ ਅਪਡੇਟ ਕਰਨਾ, ਰੂਟੀਨ ਰਿਪੋਰਟ ਬਣਾਉਣਾ ਜਾਂ ਕਿਊ ਵਿੱਚ ਕੇਸਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣਾ। ਇਹ ਦੁਹਰਾਉਂਦਾ, ਨਿਯਮ-ਅਧਾਰਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਸੋਫਟਵੇਅਰ, ਨਵੇਂ SaaS ਟੂਲ, ਈਮੇਲ, PDF ਅਤੇ ਪੋਰਟਲਾਂ ਦੇ ਮਿਕਸ ਵਿੱਚ ਫੈਲਿਆ ਹੁੰਦਾ ਹੈ।
ਮਾਮਲਾ ਇਹ ਹੈ ਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੈਮਾਨੇ ਉੱਤੇ ਛੋਟੀਆਂ ਅਣੁਚਿੱਤੀਆਂ ਵੱਡੀਆਂ ਲਾਗਤਾਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਕਰਮਚਾਰੀ ਹਰ ਰੋਜ਼ ਕੁਝ ਮਿੰਟ (ਜਾਂ ਘੰਟੇ) ਪ੍ਰਕਿਰਿਆਦੀ “ਗਲੂ ਵਰਕ” ਵਿੱਚ ਲਾਂਬੇ ਸਮੇਂ ਬਿਤਾਉਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਗਤੀ, ਸਹੀਤਾ, ਕੰਪਲਾਇੰਸ ਅਤੇ ਮੋਰੇਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਟਾਸਕ ਸਿਸਟਮਾਂ ਦੇ ਵਿਚਕਾਰ ਬੈਠੇ ਹੁੰਦੇ ਹਨ, ਰਵਾਇਤੀ IT ਪ੍ਰੋਜੈਕਟ ਜੋ “ਪੂਰੇ ਵਰਕਫਲੋ ਨੂੰ ਠੀਕ ਕਰਨ” ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਕਸਰ ਧੀਮੇ, ਮਹਿੰਗੇ ਅਤੇ ਰਾਜਨੀਤਿਕ ਤੌਰ 'ਤੇ ਮੁਸ਼ਕਲ ਹੁੰਦੇ ਹਨ।
Daniel Dines ਉਹ ਉਦਯਮੀ ਹੈ ਜਿਸ ਨੇ UiPath ਦੀ ਸਥਾਪਨਾ ਕੀਤੀ—RPA (robotic process automation) ਵਿੱਚ ਇੱਕ ਮਸ਼ਹੂਰ ਕੰਪਨੀ। UiPath ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਸਾਰੇ ਬਿਜ਼ਨਸ ਸਿਸਟਮ ਬਦਲ दिए ਜਾਣ, ਬਲਕਿ ਲੋਕ ਜੋ ਸਿਸਟਮਾਂ ਦੇ ਅੰਦਰ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਵਿਚਕਾਰ ਕੀਂਦੇ ਹਨ ਉਹਨਾਂ ਦੇ ਦੁਹਰਾਉਂਦੇ ਕਦਮਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨਾ—ਅਕਸਰ ਜਿਸ ਤਰ੍ਹਾਂ ਇੱਕ ਯੂਜ਼ਰ ਕਲਿੱਕ, ਟਾਈਪ ਅਤੇ ਨੈਵੀਗੇਟ ਕਰਦਾ ਹੈ ਉਸੀ ਤਰ੍ਹਾਂ ਨਕਲ ਕਰ ਕੇ।
ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਆਮ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਦਰਦ ਲਈ ਯਥਾਰਥਵਾਦੀ ਬਣਾਇਆ: ਇੱਕ ਸੁੱਖੇ, ਮਾਪ-ਜੋਗ ਟਾਸਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਤੁਰੰਤ ਜਿੱਤ ਦਿਖਾਓ, ਫਿਰ ਫੈਲਾਓ। UiPath ਨੇ ਇਸ “ਰੋਜ਼ਮਰਾ ਦਾ ਕੰਮ ਗਾਇਬ ਕਰ ਦਿਓ” ਵਾਲੇ ਵਾਅਦੇ ਨੂੰ ਇੱਕ ਐਸੇ ਪ੍ਰੋਡਕਟ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜਿਸ ਲਈ ਬਜਟ ਨਿਭਾਇਆ ਜਾ ਸਕਦਾ ਸੀ।
ਇਹ ਕੋਈ “AI ਸਭ ਕੁਝ ਬਦਲ ਰਿਹਾ ਹੈ” ਵਾਲੀ ਹੋਰ ਵਧੀਕ ਗੱਲ ਨਹੀਂ ਹੈ। ਇਹ ਵੰਡ ਹੈ ਕਿ UiPath ਅਤੇ RPA ਨੇ ਗੈਰ-ਚਮਕਦਾਰ ਕੰਮ 'ਤੇ ਧਿਆਨ ਦੇ ਕੇ ਕਿਵੇਂ ਵਪਾਰਕ ਤੌਰ 'ਤੇ ਕਾਮਯਾਬੀ ਹਾਸਲ ਕੀਤੀ:\n
ਅੰਤ ਤੱਕ, ਤੁਹਾਨੂੰ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਵੇਗਾ ਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਟੋਮੇਸ਼ਨ ਕਿੱਥੇ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ, ਕਿੱਥੇ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੀ ਆਟੋਮੇਸ਼ਨ ਰਣਨੀਤੀ ਲਈ ਕਿਹੜੀਆਂ ਪ੍ਰਿੰਸੀਪਲ ਨਕਲ ਕਰਨਯੋਗ ਹਨ—ਭਲੇ ਹੀ ਤੁਸੀਂ UiPath ਵਰਤਦੇ ਹੋ ਜਾਂ ਨਹੀਂ।
ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਅਕਸਰ ਇਸ ਲਈ ਮੁਸ਼ਕਿਲ ਵਿੱਚ ਹੁੰਦੀਆਂ ਨਹੀਂ ਕਿ ਕੋਈ ਇਕ ਟਾਸਕ ਜਟਿਲ ਹੈ। ਮੁਸ਼ਕਲ ਇਸ ਲਈ ਹੁੰਦੀ ਹੈ ਕਿ ਹਜ਼ਾਰਾਂ “ਸਧਾਰਣ” ਟਾਸਕ ਟੀਮਾਂ, ਸਿਸਟਮਾਂ ਅਤੇ ਨਿਯਮਾਂ ਵਿੱਚ ਮਿਲਕੇ ਜੁੜੇ ਹੋਏ ਹਨ—ਅਤੇ ਇਹ ਮਿਲਾਉਣ ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਗੜਬੜ ਹੋਦੀ ਹੈ।
ਬਹੁਤ ਸਾਰਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਮ ਡੇਟਾ ਕਾਪੀ ਕਰਨ, ਜਾਂਚ ਕਰਨ ਅਤੇ ਦੁਬਾਰਾ ਦਰਜ ਕਰਨ ਦੇ ਆਸ-ਪਾਸ ਹੁੰਦਾ ਹੈ: ਈਮੇਲ ਤੋਂ ERP ਸਕ੍ਰੀਨ ਉੱਤੇ ਡੇਟਾ ਲਿਜਾਣਾ, PDF ਤੋਂ ਕਲੇਮ ਸਿਸਟਮ ਵਿੱਚ ਦਰਜ ਕਰਨਾ, ਸਪ੍ਰੈਡਸ਼ੀਟ ਤੋਂ CRM ਵਿੱਚ ਨਕਲ ਕਰਨਾ। ਹਰ ਕਦਮ ਛੋਟਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਵੇਲਿਊਮ ਵੱਡਾ ਹੁੰਦਾ ਹੈ।
ਹੈਂਡਆਫਸਤ ਇਸਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰਦੇ ਹਨ। ਇਕ ਵਿਅਕਤੀ “ਮੁਕੰਮਲ” ਕਰਦਾ ਹੈ ਤੇ ਈਮੇਲ ਭੇਜ ਦਿੰਦਾ ਜਾਂ ਸ਼ੇਅਰਡ ਫਾਇਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਲੈਂਦਾ—ਅਕਸਰ ਉਸ ਸੰਦਰਭ ਤੋਂ ਬਿਨਾਂ ਜੋ ਦੱਸਦਾ ਕਿ ਅਪਵਾਦ ਕਿਉਂ ਹੋਇਆ।
ਅਸਲੀ ਪ੍ਰਕਿਰਿਆਆਂ ਸਾਫ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਗਾਹਕ ਦਾ ਨਾਮ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਇਨਵਾਇਸ ਵਿੱਚ PO ਗੈਰਮੌਜੂਦ ਹੈ, ਫਾਰਮ ਝੁੱਕ ਕੇ ਸਕੈਨ ਹੋਇਆ, ਜਾਂ ਪਾਲਿਸੀ ਮੱਧ ਕੁਆਰਟਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਮਨੁੱਖ ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਇੰਪ੍ਰੋਵਾਈਜ਼ ਕਰਕੇ ਸੰਭਾਲਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਵੈਰੀਏਸ਼ਨ ਆਉਂਦੀ ਹੈ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਅਣੁਮਾਨਿਆ ਹੋਣੀ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ।
ਫਿਰ ਕੰਪਲਾਇੰਸ ਦਾ ਸਵਾਲ ਆਉਂਦਾ ਹੈ: ਆਡਿਟ ਟਰੇਲ, ਮਨਜ਼ੂਰੀਆਂ, ਐਕਸੈਸ ਕੰਟਰੋਲ, ਡਿਊਟੀਜ਼ ਦੀ ਵਿਭਾਜਨ। ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਜੋ “ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰੋ” ਜੁਝਦੀ ਸੀ, ਉਹ ਬਣ ਜਾਂਦੀ ਹੈ “ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰੋ, ਸਬੂਤ ਕੈਪਚਰ ਕਰੋ, ਸਾਈਨ-ਆਫ ਲਵੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਮਾਣ ਦਿਓ।”
ਡਿਲੇ ਚੁੱਪਚਾਪ ਵਧਦੇ ਹਨ। ਇੱਕ ਦੋ-ਮਿੰਟ ਦਾ ਟਾਸਕ ਜੋ ਹਫ਼ਤੇ ਵਿੱਚ 5,000 ਵਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਹ ਕਿਊ ਬਣ ਜਾਂਦਾ ਹੈ। ਕਿਊਜ਼ ਫਾਲੋ-ਅੱਪ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਫਾਲੋ-ਅੱਪ ਹੋਰ ਕੰਮ ਬਣਾਉਂਦੇ ਹਨ।
ਗਲਤੀਆਂ ਇੱਕ ਹੋਰ ਪਰਤ ਦਾ ਖਰਚ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਰੀਵਰਕ, ਗਾਹਕ ਅਸੰਤੁਸ਼ਟੀ, ਅਤੇ ਜਦੋਂ ਗਲਤ ਡੇਟਾ ਫਾਇਨੈਂਸ, ਸ਼ਿਪਿੰਗ ਜਾਂ ਰਿਪੋਰਟਿੰਗ ਤੱਕ ਪੁੱਜਦਾ ਹੈ ਤਾਂ ਡਾਊਨਸਟਰੀਮ ਫਿਕਸ।
ਅਤੇ ਮਨੁੱਖੀ ਲਾਗਤ ਆਉਂਦੀ ਹੈ: ਕਰਮਚਾਰੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਾਪੀ-ਪੇਸਟ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਸਕ੍ਰੀਨ ਬਦਲਦੇ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ, ਦੇਰੀ ਲਈ ਮਾਫ਼ੀ ਮੰਗਣੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ “ਪਰਕਿਰਿਆ ਸਮੱਸਿਆਵਾਂ” ਲਈ ਦੋਸ਼ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਉਹ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਭਲੇ ਹੀ ਇੱਕ ਟਾਸਕ ਦੁਹਰਾਉਂਦਾ ਹੋਵੇ, ਇਸਨੂੰ ਆਟੋਮੇਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ ਵਾਤਾਵਰਣ ਗੁੰਝਲਦਾਰ ਹੈ:
UiPath ਨੇ ਇਸ ਗੈਪ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ: ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨਲ ਘਰਘੰਟਾਂ ਜਿੱਥੇ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਣ enough ਹੈ ਕਿ ਉਹ ਸਟੈਂਡਰਡ ਕੀਤੇ ਜਾ ਸਕਣ, ਪਰ ਇੰਨਾ ਗੁੰਝਲਦਾਰ ਕਿ ਰਵਾਇਤੀ ਆਟੋਮੇਸ਼ਨ ਵਿਧੀਆਂ ਹਮੇਸ਼ਾ ਰੋਕਿਅਤੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
Robotic process automation (RPA) ਮੁਢਲੀ ਤੌਰ 'ਤੇ ਉਹ ਸੌਫਟਵੇਅਰ ਹੈ ਜੋ ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਐਪਾਂ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਵਰਤਦਾ ਹੈ ਜਿਵੇਂ ਇੱਕ ਆਦਮੀ ਕਰਦਾ ਹੈ—ਬਟਨਾਂ 'ਤੇ ਕਲਿੱਕ ਕਰਨਾ, ਕਾਪੀ-ਪੇਸਟ, ਲੌਗਇਨ, ਫਾਇਲਾਂ ਡਾਊਨਲੋਡ ਕਰਨਾ, ਤੇ ਫਾਰਮ ਭਰਨਾ।
ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਥਾਂ, ਇੱਕ RPA “ਰੋਬੋਟ” ਸਕਰੀਨ 'ਤੇ (ਜਾਂ ਪਿਛੋਕੜ ਵਿੱਚ) ਕਦਮਾਂ ਦੀ ਇੱਕ ਸੈਟ ਫਾਲੋ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਕੰਮ ਇੱਕ ਜਗ੍ਹਾ ਤੋਂ ਦੂਜੇ ਜਗ੍ਹਾ ਵੱਧ ਸਕੇ। ਸੋਚੋ: ਇੱਕ ਈਮੇਲ ਅਟੈਚਮੈਂਟ ਤੋਂ ਡੇਟਾ ਲੈਣਾ, ਇਸਨੂੰ ERP ਵਿੱਚ ਦਰਜ ਕਰਨਾ, ਫਿਰ CRM ਅਪਡੇਟ ਕਰਨਾ ਅਤੇ ਪੁਸ਼ਟੀ ਸੁਨੇਹਾ ਭੇਜਣਾ।
ਇਹ ਵਿਕਲਪ ਮਿਲਦੇ ਜੁਲਦੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ, ਪਰ ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਲਈ ਉਚਿਤ ਹਨ:
ਇਕ ਪ੍ਰਯੋਗੀ ਨਿਯਮ: ਜੇ ਪ੍ਰਕਿਰਿਆ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਕ੍ਰੀਨਾਂ ਦਰਮਿਆਨ ਜਾਣਕਾਰੀ ਹਿਲਾਉਣ ਦੀ ਹੈ ਤਾਂ RPA ਮਜ਼ਬੂਤ ਉਮੀਦਵਾਰ ਹੈ। ਜੇ ਇਸਨੂੰ ਇੱਕ ਦਾਇਮੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲੇਅਰ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ APIs ਜਾਂ ਕਸਟਮ ਡਿਵੈਲਪਮੈਂਟ ਅਕਸਰ ਵਧੀਆ ਨਿਵੇਸ਼ ਹੁੰਦੇ ਹਨ।
2025 ਵਿੱਚ ਇੱਕ ਉਪਯੋਗੀ ਨੁਆਂਸ: “ਕਸਟਮ ਸੌਫਟਵੇਅਰ” ਹਮੇਸ਼ਾਂ ਲੰਬੇ ਵਾਲ੍ਫਲੋ build ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ। Vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ ਕਿ Koder.ai ਟੀਮਾਂ ਨੂੰ ਸਹਾਇਤਾ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਹਲਕੇ ਇੰਟਰਨਲ ਟੂਲ (ਵੈੱਬ ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਪੈਨਲ, ਐਕਸਪਸ਼ਨ ਕਿਊ) ਬਣਾਉਣ—ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਡਿਪਲੋਏ ਅਤੇ ਹੋਸਟ ਕਰਨ ਜਾਂ ਜਦੋਂ IT ਲੈ ਲੈਂਦਾ ਹੈ ਤਾਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ। ਇਹ RPA ਨੂੰ ਉਸ ਗੁੰਝਲ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦਾ ਜੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਨੂੰ ਅਕਸਰ ਲੋੜੀਂਦਾ ਹੈ: ਚੰਗੇ ਇੰਟੇਕ ਫਾਰਮ, ਸਾਫ਼ ਐਕਸਪਸ਼ਨ ਵਰਕਫਲੋ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਵਿਜੀਬਿਲਿਟੀ।
RPA ਇਸ ਲਈ ਲੋਕਪ੍ਰਿਯ ਹੋਈ ਕਿ ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸੀ:\n
ਇਹ ਮਿਲਾਪ “ਬੋਰਿੰਗ” ਓਪਰੇਸ਼ਨਲ ਕੰਮ ਨੂੰ ਕੁੱਝ ਐਸਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਾਰ ਸਕਦੇ ਹੋ—ਅਤੇ ਮਾਪ ਸਕਦੇ ਹੋ।
UiPath ਦੀ ਸ਼ੁਰੂਆਤੀ ਰਫਤਾਰ ਸਿਰਫ਼ ਸਮਾਰਟ ਸੌਫਟਵੇਅਰ ਤੋਂ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਸਾਫ਼ ਨਜ਼ਰੀਆ ਵੀ ਸੀ, ਜਿਸ ਨੂੰ ਕੰਪਨੀ ਦੇ ਕੋ-ਫਾਊਂਡਰ Daniel Dines ਨੇ ਉਭਾਰਿਆ: ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਕੰਮ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਲੋਕਾਂ ਲਈ ਵਰਤੋਂਯੋਗ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇਕ ਨੁਹਥੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਨਾ ਦੇਖ ਕੇ, ਉਨਾਂ ਨੇ ਇੱਕ ਪ੍ਰੋਡਕਟ ਅਤੇ ਕੰਪਨੀ ਕਹਾਣੀ ਚਲਾਈ ਜੋ ਇਸਨੂੰ ਰੋਜ਼ਾਨਾ ਓਪਰੇਸ਼ਨ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗੀ ਸੰਦ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਏ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦਦਾਰ ਅਕਸਰ “RPA” ਨਹੀਂ ਚਾਹੁੰਦੇ। ਉਹ ਘੱਟ ਗਲਤੀਆਂ, ਤੇਜ਼ ਚੱਕਰ, ਸਾਫ਼ ਡੇਟਾ, ਅਤੇ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਕਾਪੀ-ਪੇਸਟ 'ਤੇ ਘੱਟ ਸਮਾਂ ਚਾਹੁੰਦੇ ਹਨ। Dines ਦਾ ਕੰਮ ਸੀ UiPath ਨੂੰ ਉਸ ਹਕੀਕਤ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖਣਾ—ਅਤੇ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਇਹ ਗੱਲ ਦੱਸਣਾ: ਪਹਿਲਾਂ ਦੁਹਰਾਉਂਦੇ ਕਦਮ ਆਟੋਮੇਟ ਕਰੋ, ਤਾਂਤ੍ਰਿਕ ਤੌਰ ਤੇ ਤੁਰੰਤ ਮੁਲ ਦਾ ਪਰਮਾਣ ਦਿਖਾਓ, ਅਤੇ ਫਿਰ ਫੈਲਾਉ।
ਇਹ ਕੇਂਦਰਿਤੀ ਧਿਆਨ ਅੰਦਰੋਨੀ (ਜੋ ਬਣਾਇਆ ਜਾਂਦਾ) ਅਤੇ ਬਾਹਰੋਨੀ (ਜੋ ਵੇਚਿਆ ਜਾਂਦਾ) ਦੋਹਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਜਦੋਂ ਸੁਨੇਹਾ ਇਹ ਹੁੰਦਾ ਹੈ “ਅਸਲ ਵਰਕਫਲੋ ਤੋਂ ਬਿਜ਼ੀਵਰਕ ਹਟਾਓ,” ਤਾਂ ਫਾਇਨੈਂਸ ਲੀਡ, HR ਮੈਨੇਜਰ, ਜਾਂ ਓਪਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰ ਲਈ ਹਾਂ ਕਹਿਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
UiPath ਨੇ ਕੁੱਲ ਸਿਸਟਮ ਪਰਿਵਰਤਨ ਦਾ ਵਾਅਦਾ ਕਰਕੇ ਜਿੱਤ ਨਹੀਂ ਹਾਸਲ ਕੀਤਾ। ਸ਼ੁਰੂਆਤੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਉਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦੇਂਦੀ ਸੀ ਜੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਨ: ਲੈਗੇਸੀ ਐਪ, ਸਪ੍ਰੈਡਸ਼ੀਟ, ਇੰਬਾਕਸ-ਚਲਤ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਤੇ ਫਰੈਗਮੈਂਟਡ ਮਨਜ਼ੂਰੀਆਂ।
ਵਾਅਦਾ ਸੀ ਸਧਾਰਨ: ਇੰਨਾਂ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਆਟੋਮੇਟ ਕਰੋ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲੇ।
ਇਹ “ਖਰੀਦਯੋਗ” ਵਿਚਾਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੰਪਨੀਆਂ ਦੇ ਬਦਲਾਅ ਅਪਨਾਉਣ ਦੇ ਢੰਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ:\n
ਇੱਕ ਸਾਫ਼ ਸ਼੍ਰੇਣੀ ਨੈਰੇਟਿਵ ਸੰਗੀਨਤਾ ਘਟਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਖਰੀਦਦਾਰ ਜਾਣਦੇ ਹਨ ਕਿ robotic process automation ਕੀ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ), ਉਹ ਇਸ ਲਈ ਬਜਟ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਸਟਾਫ ਰੱਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਵੈਂਡਰਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹਨ।
UiPath ਨੇ ਇੱਕ ਲਗਾਤਾਰ ਕਹਾਣੀ ਦੱਸਣ ਨਾਲ ਲਾਭ ਉਠਾਇਆ: RPA ਇੱਕ ਤਹ ਹੈ ਜੋ ਟੀਮਾਂ ਨੂੰ ਅਜੋਕੇ दिनਾਂ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵਧੀਯਾ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ—ਜਦਕਿ ਵਿਸ਼ਾਲ ਬਦਲਾਅ ਸਮੇਂ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਸਪਸ਼ਟਤਾ ਨੇ “ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਇੱਕ ਐਸਾ ਚੀਜ਼ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਜੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਖਰੀਦ ਸਕਦੇ, ਜਣੋ ਅਤੇ ਫੈਲਾਵ ਸਕਦੇ ਹਨ।
UiPath ਦਾ ਸਭ ਤੋਂ ਵਪਾਰਕ ਵਿਚਾਰ ਕੋਈ ਚਮਕਦਾਰ ਨਵਾਂ ਅਲਗੋਰਿਥਮ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਉਤਪਾਦ ਵਾਅਦਾ ਸੀ: ਤੁਸੀਂ ਇੱਕ ਐਂਡ-ਟੂ-ਐਂਡ ਬਿਜ਼ਨਸ ਪ੍ਰਕਿਰਿਆ ਆਟੋਮੇਟ ਕਰ ਸਕਦੇ ਹੋ ਭਾਵੇਂ ਉਹ ਗੰਦੇ ਟੂਲ ਬਾਊਂਡਰੀਆਂ ਨੂੰ ਲੰਘਦੀ ਹੋਵੇ।
ਇਹ ਮਥਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੀਆਂ “ਅਸਲ” ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਹੀ ਸਿਸਟਮ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੀਆਂ। ਇੱਕ ਕਲੇਮਜ਼ ਹੈਂਡਲਰ ਵਰਗਾ ਵਿਅਕਤੀ ਈਮੇਲ ਅਟੈਚਮੈਂਟ ਤੋਂ ਡੇਟਾ ਕਾਪੀ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ ਵੈੱਬ ਪੋਰਟਲ ਵਿੱਚ ਦਰਜ ਕਰਦਾ ਹੈ, ਮੇਨਫ੍ਰੇਮ ਸਕ੍ਰੀਨ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਸਪ੍ਰੈਡਸ਼ੀਟ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਫਿਰ CRM 'ਚ ਗਾਹਕ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ। UiPath ਨੇ ਉਸ ਪੂਰੇ ਚੇਨ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ, ਸਿਰਫ਼ API ਵਾਲੀਆਂ ਕਲੀਨ ਭਾਗਾਂ ਨੂੰ ਨਹੀਂ।
RPA ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਇਹ ਸੀ ਕਿ ਇਹ ਸਮਝਣਯੋਗ ਲੱਗਦਾ ਸੀ। ਇੱਕ ਦ੍ਰਿਸ਼ਮਾਨ ਵਰਕਫਲੋ ਬਿਲਡਰ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇਕ ਅਜਿਹੀ ਚੀਜ਼ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜੋ ਟੀਮਾਂ ਸਮੀਖਿਆ, ਚਰਚਾ ਅਤੇ ਸੁਧਾਰੀ ਸਕਦੀਆਂ ਹਨ: ਕਦਮ, ਫੈਸਲੇ, ਐਕਸਪਸ਼ਨ ਅਤੇ ਹੈਂਡਆਫਜ਼ ਸਭ ਦਿੱਖ ਮੋਹਰੀ 'ਤੇ ਹੁੰਦੇ ਹਨ।
ਬਿਜ਼ਨਸ ਯੂਜ਼ਰਾਂ ਲਈ ਇਹ “ਬਲੈਕ ਬਾਕਸ” ਅਹਿਸਾਸ ਘਟਾਉਂਦਾ ਹੈ। IT ਲਈ, ਇਹ ਇੱਕ ਸਾਂਝੀ ਆਰਟੀਫੈਕਟ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਉਹ ਗਵਰਨ ਕਰ ਸਕਦੇ ਹਨ—ਨਾਮਕਰਨ ਨਿਯਮ, ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕੰਪੋਨੈਂਟ, ਅਤੇ ਵਰਜਨਿੰਗ—ਪੂਰਾ ਕੋਡ ਸਿਰਫ਼ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀ ਹੈ।
ਆਟੋਮੇਸ਼ਨ ਤਦ ਹੀ ਮੁੱਲ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਨਿਯਮਤ ਤਰੀਕੇ ਨਾਲ ਚਲਦੀ ਹੈ। UiPath ਨੇ ਉਹਨਾਂ ਗੈਰ-ਚਮਕਦਾਰ ਫੀਚਰਾਂ 'ਚ ਭਾਰੀ ਨਿਵੇਸ਼ ਕੀਤਾ ਜੋ ਬੋਟਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ:
ਇਹ ਸਮਰੱਥਾਵਾਂ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਇੱਕ-ਬਾਰੀ ਮੈਕਰੋ ਵਾਂਗ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਓਪਰੇਸ਼ਨਲ ਸਿਸਟਮ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀਆਂ ਹਨ—ਕੋਈ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲ ਸਕਦੇ, ਮਾਪ ਸਕਦੇ, ਅਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਤੁਸੀਂ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਆਟੋਮੇਸ਼ਨ ਕੀ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਦੌਰਾਨ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਨਿਯੰਤਰਣਯੋਗ ਹੈ, ਤਾਂ ਮਨਜ਼ੂਰੀਆਂ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਉਹ ਮਿਲਾਪ—ਐਂਡ-ਟੂ-ਐਂਡ ਪਹੁੰਚ, ਦ੍ਰਿਸ਼ਮਾਨ ਸਪਸ਼ਟਤਾ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ-ਗਰੇਡ ਭਰੋਸੇਯੋਗਤਾ—ਉਹ ਹੈ ਜਿਸਨੇ “ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਇੱਕ ਐਸਾ ਉਤਪਾਦ ਸ਼੍ਰੇਣੀ ਬਣਾ ਦਿੱਤਾ ਜਿਸ ਉੱਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮਿਆਰੀਕਰਨ ਕਰ ਸਕਦੇ ਸਨ।
UiPath ਨੇ ਇੱਕ ਉਪਯੋਗੀ ਵੰਡ ਪ੍ਰਚਲਿਤ ਕੀਤੀ ਜੋ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਅਪਨਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀ ਸੀ: ਅਟੈਂਡੇਡ ਅਤੇ ਅਨਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ। ਇਹ ਦੋਨੋ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਸੰਸਥਾ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਢੰਗ ਨਾਲ ਫੈਲਦੇ ਹਨ, ਅਤੇ—ਇਕੱਠੇ—RPA ਨੂੰ ਇੱਕ ਨਿਸ਼ ਟੂਲ ਤੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਭਾਗਾਂ ਤੱਕ ਲੈ ਕੇ ਆਉਣ ਵਿੱਚ ਮੱਦਦ ਕੀਤੀ।
ਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਇੱਕ ਕਰਮਚਾਰੀ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਚਲਦੀ ਹੈ ਅਤੇ ਉਸ ਵਿਅਕਤੀ ਦੁਆਰਾ ਟਰਿਗਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸਨੂੰ ਸਮਰਥਕ ਆਟੋਮੇਸ਼ਨ ਸਮਝੋ ਜੋ ਕਿਸੇ ਵਰਕਫਲੋ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਟਰੋਲ ਲੈਣ ਦੇ।
ਇੱਕ ਕਸਟਮਰ ਸਰਵਿਸ ਪ੍ਰਤਿਨਿਧਿ ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ:\n
ਅਟੈਂਡੇਡ ਬੋਟ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਚੰਗੇ ਹਨ ਜਿੱਥੇ ਮਨੁੱਖ ਫੈਸਲੇ ਕਰਦੇ ਹਨ, ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ, ਜਾਂ ਕੰਪਲਾਇੰਸ ਲਈ ਲੂਪ ਵਿੱਚ ਰਹਿਣੇ ਲਾਜ਼ਮੀ ਹਨ।
ਅਨਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਪਿਛੋਕੜ ਵਿੱਚ ਸਰਵਰ (ਜਾਂ VM) 'ਤੇ ਚਲਦੀ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਮੌਜੂਦਗੀ ਦੇ। ਇਹ ਸ਼ੈਡਿਊਲਡ ਜਾਂ ਇਵੈਂਟ-ਚਲਿਤ ਹੁੰਦੀ ਹੈ—ਇੱਕ ਬੈਚ ਨੌਕਰੀ ਵਾਂਗ ਜੋ ਰਾਤ ਨੂੰ ਜਾਂ ਜਦੋਂ ਕੰਮ ਆਉਂਦਾ ਹੈ ਤਦ ਚੱਲ ਸਕਦੀ ਹੈ।
ਆਮ ਉਦਾਹਰਣਾਂ:
ਅਨਅਟੈਂਡੇਡ ਬੋਟ ਉਹਨਾਂ ਉਚ-ਵਾਲੀਅਮ, ਦੁਹਰਾਓ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਸ਼੍ਰੇਠ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਇਕਸਾਰਤਾ ਅਤੇ ਥਰਪੁੱਟ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
ਦੋ ਮੋਡ ਹੋਣ ਨਾਲ “ਸਭ-ਜਾ-ਨਾ-ਜਰੂਰੀ” ਰੂਹ ਘੱਟ ਹੋ ਗਈ। ਟੀਮਾਂ ਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ—ਛੋਟੀਆਂ ਜਿੱਤਾਂ ਜੋ ਫਰੰਟਲਾਈਨ ਸਟਾਫ ਨੂੰ ਤੁਰੰਤ ਫਾਇਦਾ ਦਿੰਦੀਆਂ—ਫਿਰ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਸਥਿਰ ਅਤੇ ਮਿਆਰੀਕ੍ਰਿਤ ਹੋ ਜਾਵੇ, ਤਦ ਅਨਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਵੱਲ ਵਧ ਸਕਦੀਆਂ।
ਇਸ ਰਾਹ ਨਾਲ ਜਿਹੜੇ ਲਾਭ ਹੋਏ ਉਹ ਇਹ ਸਨ ਕਿ ਸੇਲਜ਼, ਸਪੋਰਟ, HR ਅਤੇ ਓਪਰੇਸ਼ਨ ਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਅਪਨਾਉ ਸਕਦੇ ਬਿਨਾਂ IT ਬਦਲਾਅ ਦੀ ਉਡੀਕ ਕੀਤੇ, ਜਦਕਿ ਫਾਇਨੈਂਸ ਅਤੇ ਸ਼ੇਅਰਡ ਸਰਵਿਸਜ਼ ਅਨਅਟੈਂਡੇਡ ਬੋਟਾਂ ਨੂੰ ਵਾਲੀਅਮ ਅਤੇ ਮਾਪਯੋਗ ਸਮਾਂ-ਬਚਤ ਦੇ ਆਧਾਰ 'ਤੇ ਵਾਜਬੀ ਰੂਪ ਦੇ ਸਕਦੇ। ਇਕੱਠੇ, ਇਨ੍ਹਾਂ ਨੇ ਆਟੋਮੇਸ਼ਨ ਲਈ ਕਈ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਬਣਾਏ, ਜਿਸ ਨਾਲ RPA ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ ਵਰਤੋਂਯੋਗ ਮਹਿਸੂਸ ਹੋਇਆ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਟੋਮੇਸ਼ਨ ਅਕਸਰ ਇੱਕ ਵੱਡੇ ਫੈਸਲੇ ਨਾਲ ਨਹੀਂ ਖਰੀਦੀ ਜਾਂਦੀ। ਇਹ ਪਾਇਲਟ ਰਾਹੀਂ "ਹਾਸਿਲ" ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਇੱਕ ਛੋਟਾ, ਸਮਾਂ-ਬੱਧ ਪ੍ਰਯੋਗ ਜੋ ਸਟੇਕਹੋਲਡਰ ਚਲੁਣ-ਜਾਂਚ—ਪਰਕਿਰਿਆ ਮਾਲਕ, IT ਓਪਰੇਸ਼ਨ, ਸੁਰੱਖਿਆ, ਕੰਪਲਾਇੰਸ, ਅਤੇ ਅਕਸਰ ਪਰਚੇਜ਼ਿੰਗ—ਦੇ ਸਾਵਧਾਨ ਨਜ਼ਰ ਤੋਂ ਬਚਣਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਪਾਇਲਟ ਸਿਰਫ਼ “ਇੱਕ ਬੋਟ ਬਣਾਉਣਾ” ਹੀ ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਵਿੱਚ ਐਕਸੈਸ ਸਮੀਖਿਆ, ਕ੍ਰੈਡੈਂਸ਼ਲ ਹੈਂਡਲਿੰਗ, ਆਡਿਟ ਟਰੇਲ, ਐਕਸਪਸ਼ਨ ਰਾਉਟਿੰਗ, ਅਤੇ ਇਹ ਗੱਲ ਭੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਜਦੋਂ ਆਟੋਮੇਸ਼ਨ ਟੁਟੇ ਤਾਂ ਕੌਣ ਸਮਰਥਨ ਕਰੇਗਾ। ਭਾਵੇਂ ਇੱਕ ਸਧਾਰਣ ਵਰਕਫਲੋ ਵੀ ਇਹਨਾਂ ਸਵਾਲਾਂ ਨੂੰ ਜਨਮ ਦੇ ਸਕਦਾ ਹੈ: ਲੌਗ ਕਿੱਥੇ ਸਟੋਰ ਹੋਣਗੇ? ਕੌਣ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਬਦਲਾਅ ਕਰ ਸਕਦਾ ਹੈ? ਜੇ ਅਪਸਟਰੀਮ ਸਿਸਟਮ ਬਦਲ ਗਿਆ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?
ਜੋ ਟੀਮਾਂ ਸਕੇਲ ਕਰਦੀਆਂ ਹਨ ਉਹ ਪਾਇਲਟ ਨੂੰ ਇੱਕ ਮੀਨੀਚਰ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੋਇਮੈਂਟ ਦੀ ਤਰ੍ਹਾਂ ਲੈਂਦੀਆਂ ਹਨ—ਸਿਰਫ਼ ਘੱਟ ਸਕੋਪ ਨਾਲ।
ਸਭ ਤੋਂ ਵਧੀਆ ਪਾਇਲਟ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਚੁਣਦੇ ਹਨ ਜਿਹੜੀਆਂ ਦਰਦਨਾਕ ਅਤੇ ਮਾਪਯੋਗ ਨਤੀਜੇ ਦਿੰਦੀਆਂ ਹਨ: ਸਾਈਕਲ ਟਾਈਮ, ਗਲਤੀ ਦਰ, ਰੀਵਰਕ, ਜਾਂ ਸਟਾਫ ਘੰਟੇ ਜੋ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਪਾਇਲਟ ਇੱਕ ਅਸਲ ਟੀਮ ਲਈ ਰੋਜ਼ਾਨਾ ਦੀ ਨਿਰਾਸ਼ਾ ਹਟਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਡੈਸ਼ਬੋਰਡ ਮੈਟ੍ਰਿਕ ਤੋਂ ਵੱਧ ਕੁਝ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਅੰਦਰੂਨੀ ਵਿਸ਼ਵਾਸੀ ਲੋਕ।
ਉਹ ਚੈਂਪੀਅਨ ਤੁਹਾਡੇ ਲਈ ਵੰਡ ਚੈਨਲ ਬਣ ਜਾਂਦੇ ਹਨ। ਉਹ ਅਗਲੇ ਉਮੀਦਵਾਰ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਬਜਟ ਸਾਈਕਲ ਦੌਰਾਨ ਪ੍ਰੋਜੈਕਟ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ, ਅਤੇ ਪਾਸ ਵਾਲੀਆਂ ਟੀਮਾਂ ਨੂੰ ਭਾਗ ਲੈਣ ਲਈ ਉਤਸਾਹਿਤ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਵਿਰੋਧ।
ਗਲਤ ਪ੍ਰਕਿਰਿਆ ਚੁਣਨਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਰੁਕ ਜਾਵੇ। ਉੱਚ-ਵੈਰੀਅੰਸ ਟਾਸਕ, ਅਸਥਿਰ ਐਪਲੀਕੇਸ਼ਨ, ਜਾਂ ਸਿੰਥਿਆ ਗਿਆ ਗਿਆਨ ਵਾਲੇ ਵਰਕਫਲੋ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਅਣਿਭਰੋਸਾ ਲੱਗਣ ਵਾਲੇ ਬਣਾਉਂਦੇ ਹਨ।
ਅਸਪੱਸ਼ਟ ਮਾਲਕੀਅਤ ਚੁਪ-ਚਾਪ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਹੋਰ ਕਾਰਨ ਹੈ। ਜੇ ਗੋ-ਲਾਈਵ ਮਗਰੋਂ ਕੋਈ ਵੀ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ—ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਸੰਭਾਲਣ, ਨਿਯਮ ਅਪਡੇਟ ਕਰਨ, ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਨ—ਤਾਂ ਪਾਇਲਟ ਡੈਮੋ ਹੀ ਰਹਿ ਜਾਂਦਾ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਨਹੀਂ। ਸਫਲਤਾ ਘੋਸ਼ਣਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨਾਂ-ਨਿਰਧਾਰਤ ਪ੍ਰਕਿਰਿਆ ਮਾਲਕ ਅਤੇ ਸਮਰਥਨ ਮਾਡਲ ਤੈਅ ਕਰੋ।
UiPath ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ ਨਹੀਂ ਵੇਚਦਾ—ਉਸ ਨੇ ਇਹ ਵੀ ਨਾਂਮ ਦੇ ਕੇ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਇਹੀ ਸ਼੍ਰੇਣੀ ਨਿਰਮਾਣ ਦਾ ਮਤਲਬ ਹੈ: ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ, ਭਰੋਸੇਯੋਗ ਵਰਤਣ ਮਾਮਲੇ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਦਿਓ ਕਿ ਉਹ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਣ। ਇਨ੍ਹਾਂ ਦੇ ਬਿਨਾਂ, ਆਟੋਮੇਸ਼ਨ ਇੱਕ ਕਸਟਮ IT ਪ੍ਰੋਜੈਕਟ ਹੀ ਰਹਿ ਜਾਂਦਾ ਜੋ ਬਜਟ, ਵਾਜਬੀ ਠਹਿਰਾਉਣਾ, ਜਾਂ ਸਕੇਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।
ਸਟੈਂਡਰਡ ਸ਼ਬਦ ਜਿਵੇਂ ਬੋਟਸ, ਵਰਕਫ਼ਲੋਜ਼, ਅਤੇ ਆਰਕੇਸ्ट्रੇਸ਼ਨ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਜਾਣੂ ਬਣਾਉਂਦੇ ਹਨ—ਡਿਜ਼ਿਟਲ ਮਦਦਗਾਰ ਰੱਖਣ ਵਾਂਗ, ਨਾ ਕਿ ਇੱਕ ਖਤਰਨਾਕ ਇਕ-ਬਾਰੀ ਸਕ੍ਰਿਪਟ।
ਜਦੋਂ ਲੋਕ ਸਪਸ਼ਟ, ਦੁਹਰਾਉਣਯੋਗ ਸ਼ਬਦਾਂ ਵਿੱਚ ਆਪਣਾ ਕੰਮ ਵੇਰਣ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਡਰ ਘਟਦਾ ਹੈ: ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਜਾਣਦੀਆਂ ਹਨ ਕਿ ਕੀ ਸਮੀਖਿਆ ਕਰਨੀ ਹੈ, ਓਪਰੇਸ਼ਨ ਜਾਣਦਾ ਹੈ ਕਿ ਕੀ ਮਾਨੀਟਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਾਰੋਬਾਰੀ ਨੇਤਾ ਜਾਣਦੇ ਹਨ ਕਿ ਉਹ ਕਿਸ ਲਈ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹਨ।
ਇੱਕ ਸ਼੍ਰੇਣੀ ਨੂੰ ਖਰੀਦਦਾਰ ਦੀ ਚੈਕਲਿਸਟ ਚਾਹੀਦੀ ਹੈ। UiPath ਨੇ ਪ੍ਰਸ਼ਨ ਆਮ ਬਣਾਏ: ਕੀ ਅਸੀਂ ਬੋਟਸ ਨੂੰ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧ ਕਰ ਸਕਦੇ ਹਾਂ? ਜੇ ਕੋਈ ਐਪ ਬਦਲ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਅਸੀਂ ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਟਰੈਕ ਕਰਦੇ ਹਾਂ? ਇਹ ਮੁਲਾਂਕਣ ਮਾਪਦੰਡ RPA ਨੂੰ ਵੈਂਡਰਾਂ ਦਰਮਿਆਨ ਤੁਲਨਯੋਗ ਬਣਾਉਂਦੇ—ਅਤੇ ਪਰਚੇਜ਼ਿੰਗ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੇ।
ਗਾਹਕ ਕਹਾਣੀਆਂ “ਆਟੋਮੇਸ਼ਨ” ਨੂੰ ਇੱਕ ਅਮੂਨੇ ਭਰੋਸੇਯੋਗ ਵਾਅਦੇ ਤੋਂ ਪਹਿਲਾ-ਅਤੇ-ਬਾਅਦ ਦੀ ਠੋਸ ਮਿਸਾਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ: ਦਿਨਾਂ ਵਿੱਚ ਇਨਵਾਇਸ ਪ੍ਰੋਸੈਸਿੰਗ, ਬਿਨਾਂ ਮੈਨੂਅਲ ਕਾਪੀ-ਪੇਸਟ ਆਨਬੋਰਡਿੰਗ, ਰੀਕਨਸੀਲਏਸ਼ਨ ਵਿੱਚ ਘੱਟ ਗਲਤੀਆਂ।
ਟੈਮਪਲੇਟ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਕੰਪੋਨੈਂਟ ਵੀ ਮਹੱਤਵਪੂਰਨ ਸਨ। ਜਦੋਂ ਟੀਮਾਂ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਉਦਾਹਰਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ, RPA ਪਰਿਕਲਪਨਾ ਇੱਕ ਵਿਗਿਆਨੀਂ ਪ੍ਰਯੋਗਖਾਨੇ ਵਾਂਗ ਨਹੀਂ ਰਹਿ ਕੇ ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਅਭਿਆਸ ਬਣ ਜਾਂਦੀ—ਕੁਝ ਜੋ ਤੁਸੀਂ ਵਿਭਾਗ ਦਰ ਵਿਭਾਗ ਰੋਲਆਉਟ ਕਰ ਸਕਦੇ ਹੋ।
ਆਟੋਮੇਸ਼ਨ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅਪਨਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਇਹ ਆਸਾਨ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ—ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਰੁਕ੍ਹਦੀ ਹੈ ਜਦੋਂ ਇਹ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਜ਼ਿਆਦਾਤਰ ਗੰਭੀਰ RPA ਪ੍ਰੋਗਰਾਮ ਆਖ਼ਰਕਾਰ Center of Excellence (CoE) ਬਣਾਉਂਦੇ ਹਨ: ਇੱਕ ਛੋਟੀ ਟੀਮ ਜੋ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ, ਆਡੀਟਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਇਸਨੂੰ ਮਹੀਨਿਆਂ ਦੀ ਬਿਊਰੋਕ੍ਰੇਸੀ ਵਿੱਚ ਬਦਲਣ ਦੇ।
CoE ਸਿਰਫ਼ ਇੱਕ ਕਮੇਟੀ ਨਹੀਂ ਹੁੰਦਾ। ਅਮਲ ਵਿੱਚ, ਇਹ ਉਹ ਟੀਮ ਹੈ ਜੋ:
ਚੰਗੇ ਢੰਗ ਨਾਲ, CoE ਇੱਕ ਸੇਵਾ ਫੰਕਸ਼ਨ ਬਣ ਜਾਂਦਾ—ਘਸਨ ਘੱਟ ਕਰਕੇ ਟੀਮਾਂ ਨੂੰ ਐਸਾ ਕੁਝ ਜਾਰੀ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਜੋ ਹਰ ਤਿਮਾਹੀ 'ਚ ਟੁਟਦਾ ਨਹੀਂ।
ਗਵਰਨੈਂਸ ਅਧਿਕਾਰਤ ਸੁਣਦਾ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸਧਾਰਨ ਅਤੇ ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੁੰਦੀਆਂ ਹਨ:
ਇਹ ਰੱਖਵਾਲੀ ਲਕੀਰਾਂ ਆਟੋਮੇਸ਼ਨਾਂ ਨੂੰ ਐਸੇ ਲੁਕਾਏ ਹੋਏ ਨਿਰਭਰਤਾਵਾਂ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਦੇ ਲਈ ਬਣਾਏ ਨਾ ਰੱਖੇ ਜਾ ਸਕਣ।
ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਤੁਲਨ ਆਮ ਤੌਰ 'ਤੇ “ਕੇਂਦਰੀ ਸਟੈਂਡਰਡ, ਵਿਤਰਿਤ ਬਣਾਉਣਾ” ਹੁੰਦਾ ਹੈ। CoE ਪਲੇਟਫਾਰਮ, ਸੁਰੱਖਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨਿਯਮਾਂ ਦੀ ਮਾਲਕੀ ਰੱਖੋ। ਬਿਜ਼ਨਸ ਟੀਮਾਂ ਨੂੰ ਵਿਚਾਰ ਪੇਸ਼ ਕਰਨ, ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਆਟੋਮੇਸ਼ਨਾਂ ਨੂੰ ਵਿਕਸਿਤ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ—ਬਸ ਉਹ ਪਲੇਬੁੱਕ ਦੀ ਪਾਲਣਾ ਕਰਨ ਅਤੇ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਸਮੀਖਿਆ ਪਾਸ ਕਰਨ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਮਾਡਲ ਹੈ: ਬਿਜ਼ਨਸ ਵਿੱਚ ਨਾਗਰਿਕ ਡਿਵੈਲਪਰ, ਜਟਿਲ ਕੰਮ ਲਈ ਪ੍ਰੋਫੈਸ਼ਨਲ ਡਿਵੈਲਪਰ, CoE ਗਵਰਨੈਂਸ ਅਤੇ ਸਾਂਝੇ ਸਰੋਤਾਂ ਲਈ। ਇਹ ਢਾਂਚਾ ਰਫ਼ਤਾਰ ਨੂੰ ਉੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਆਡਿਟ, ਅਪਗ੍ਰੇਡ ਅਤੇ ਪੁਨਰਗਠਨ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਆਟੋਮੇਸ਼ਨ ਘੱਟ ਫੇਲ ਹੁੰਦਾ ਹੈ ਇਹ ਕਾਰਨ ਨਾਲ ਨਹੀਂ ਕਿ ਬੋਟ “ਬਟਨ ਤੇ ਨਹੀਂ ਕਲਿੱਕ ਕਰਦਾ” ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਕੋਈ ਵੀ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਇਹ ਸੁਰੱਖਿਅਤ, ਨਿਯੰਤਰਿਤ, ਅਤੇ ਸਹਾਇਤਾ-ਯੋਗ ਹੈ। ਜਦੋਂ ਕੋਈ RPA ਰੋਬੋਟ ਫਾਇਨੈਂਸ, HR, ਜਾਂ ਗਾਹਕ ਡੇਟਾ ਛੁਹਦਾ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਆ, ਐਕਸੈਸ ਕੰਟਰੋਲ, ਅਤੇ ਆਡਿਟੇਬਿਲਟੀ “ਚੰਗੇ ਹੋਣ” ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨਹੀਂ ਰਹਿੰਦੀਆਂ—ਇਹ ਪ੍ਰਵੇਸ਼ ਦੀ ਕੀਮਤ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਬੋਟ ਹਾਲ ਹੀ ਇੱਕ ਯੂਜ਼ਰ ਹੀ ਹੈ—ਸਿਰਫ਼ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਮਾਫ਼ ਕਰਨ ਵਾਲਾ। ਜੇ ਇਹ ਕੋਲ ਵਿਆਪਕ ਐਕਸੈਸ ਹੈ, ਤਾਂ ਇਹ ਵੱਡਾ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਇਹ ਪਾਸਵਰਡ ਸਾਂਝੇ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਸ਼ਨ ਦਾ ਉੱਤਰ ਨਹੀਂ ਦੇ ਸਕਦੇ: “ਉਸ ਭੁਗਤਾਨ ਨੂੰ ਕਿਸ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤਾ?” ਜਾਂ “ਕਿਹੜੀ ਪਛਾਣ ਨੇ ਇਸ ਰਿਕਾਰਡ ਨੂੰ ਛੀਆ?” ਆਡੀਟੇਬਿਲਟੀ ਉਹ ਹੈ ਜੋ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਖਤਰਨਾਕ ਸ਼ਾਰਟਕਟ ਤੋਂ ਇੱਕ ਐਸੀ ਚੀਜ਼ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ ਨੂੰ ਕੰਪਲਾਇੰਸ ਸਹਿ ਸਕਦੀ ਹੈ।
ਟੀਮਾਂ ਜਿਹੜੀਆਂ ਭਰੋਸੇਯੋਗ ਨਿਯੰਤਰਣ ਵਰਤਦੀਆਂ ਹਨ ਉਹਨਾਂ ਵਿੱਚ ਅਕਸਰ ਇਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਅੱਛੇ ਤਰੀਕੇ ਨਾਲ ਬਣਾਏ ਆਟੋਮੇਸ਼ਨ ਵੀ ਟੁਟਦੇ ਹਨ: ਇੱਕ ਐਪ UI ਬਦਲ ਜਾਂਦੀ ਹੈ, ਫਾਇਲ ਦੇਰੀ ਨਾਲ ਆਉਂਦੀ ਹੈ, ਸਿਸਟਮ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਓਪਰੇਸ਼ਨਲ ਤਿਆਰੀ ਮਤਲਬ ਨਿਯਤ ਤਿਉਰੀ, ਪੀਕ ਲੋਡ, ਅਤੇ ਫੇਲਿure ਲਈ ਯੋਜਨਾ ਬਣਾਉਣਾ ਹੈ।
ਮੁੱਖ ਲੋੜਾਂ:
ਜਿਹੜੀਆਂ ਟੀਮਾਂ ਬੋਟਸ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਸੇਵਾਵਾਂ ਵਾਂਗ ਸਲਵਟ ਕਰਦੀਆਂ ਹਨ (ਸੁਰੱਖਿਆ ਅਤੇ ਓਪਰੇਸ਼ਨ ਨਾਲ ਇਕਠੇ) ਉਹ ਕਾਮਯਾਬੀ ਦਾ ਸਮੂਹੀਕ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਨਦੀਆਂ ਹਨ; ਹੋਰ ਸਭ ਇੱਕ ਟੁੱਟਣ-ਭਰੋਪੇ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਢੇਰ ਬਣ ਜਾਂਦਾ ਹੈ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਵਿੱਚ ਆਟੋਮੇਸ਼ਨ ਤਦ ਹੀ “ਅਸਲ” ਬਣਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਬਜਟ ਮੀਟਿੰਗ ਵਿੱਚ ਇਸ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕੇ। ਚੰਗੀ ਖ਼ਬਰ: ਮੁੱਲ ਸਾਬਤ ਕਰਨ ਲਈ ਸ਼ਾਨਦਾਰ ਫਾਇਨੈਨਸ ਮਾਡਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇਕ ਦੁਹਰਾਉਣਯੋਗ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਨਤੀਜੇ ਦਿਖਾਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਓਪਰੇਟਰ ਅਤੇ ਐਗਜ਼ੈਕਟਿਵ ਦੋਹਾਂ ਮੰਨਣ।
ਚਾਰ ਬਾਸਕੇਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬੇਫੋਰ/ਆਫਟਰ ਬੇਸਲਾਈਨ ਸਪਸ਼ਟ ਰੱਖੋ:
ਇੱਕ ਪ੍ਰਯੋਗੀ ਫਾਰਮੂਲਾ: Value = (ਰਿਵਰਕ ਲਾਗਤ ਬਚਤ + ਤੇਜ਼ ਸਾਈਕਲਟਾਈਮ ਤੋਂ ਨਕਦੀ/ਰੈਵਿਨਿਊ ਪ੍ਰਭਾਵ + ਕਠੋਰ ਲਾਗਤ ਘਟਾਉ) − (ਲਾਇਸੈਂਸ + ਬਣਾਉਣ + ਚਲਾਉਣ ਖ਼ਰਚ)।
ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਹੈ “ਅਸੀਂ 2,000 ਘੰਟੇ ਬਚਾਏ” ਕਹਿ ਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਔਸਤ ਤਨਖ਼ਾਹ ਨਾਲ ਗੁਣਾ ਕਰ ਦੇਣਾ—ਬਿਨਾਂ ਪੁਨਰ-ਨਿਯੁਕਤੀ ਯੋਜਨਾ ਦੇ।
ਜੇ ਟੀਮ ਵੀ ਏਨਾ ਸਟਾਫ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਉਹ ਘੰਟੇ ਖ਼ਰਚ ਘਟਤ ਨਹੀਂ ਹਨ। ਫਿਰ ਵੀ ਇਹ ਮੁੱਲਵਾਨ ਹਨ, ਪਰ ਠੀਕ ਲੇਬਲ ਕਰੋ:
ਉਹ ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ ਗੇਮ ਕਰਨ ਲਈ ਮੁश्किल ਅਤੇ ਆਡੀਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੋਣ:
ਜਦੋਂ ਆਟੋਮੇਸ਼ਨ ਰਿਪੋਰਟਿੰਗ ਸਿੱਧਾ ਓਪਰੇਸ਼ਨ ਡੈਸ਼ਬੋਰਡز ਨਾਲ ਜੁੜਦੀ ਹੈ, ROI ਇੱਕ ਇੱਕ-ਵਾਰੀ ਕਹਾਣੀ ਤੋਂ ਮਹੀਨਾਵਾਰ ਹਕੀਕਤ ਬਣ ਜਾਂਦਾ ਹੈ।
UiPath ਦੀ ਕਹਾਣੀ ਯਾਦ ਦਿਵਾਉਂਦੀ ਹੈ ਕਿ “ਬੋਰਿੰਗ” ਕੰਮ ਅਕਸਰ ਇੱਥੇ ਪੈਸੇ ਹਨ—ਕਿਉਂਕਿ ਇਹ ਵਾਰੰਤਰਿਕ, ਮਾਪਯੋਗ, ਅਤੇ ਦਰਦਨਾਕ ਹੁੰਦਾ ਹੈ ਇਸ ਲਈ ਲੋਕ ਤਬਦੀਲੀ ਨੂੰ ਸਪਾਂਸਰ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਆਟੋਮੇਸ਼ਨ ਦੀ ਅਗਵਾਈ ਕਰ ਰਹੇ ਹੋ (ਜਾਂ ਆਟੋਮੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਖਰੀਦ ਰਹੇ ਹੋ), ਤਾਂ ਚਮਕਦਾਰ ਡੈਮੋਜ਼ ਨਾਲ ਘੱਟ, ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਨਿਰੀਗਾੜੀ 'ਤੇ ਜ਼ਿਆਦਾ ਧਿਆਨ ਦਿਓ।
ਉਹ ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸਦੇ ਨਿਯਮ ਸਾਫ਼, ਮਾਲਕ ਸਪਸ਼ਟ, ਅਤੇ ਵਾਲੀਅਮ ਉੱਚ ਹੋ। ਇਕ ਛੋਟੀ ਸੈਟ ਆਟੋਮੇਸ਼ਨਾਂ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਹ ਯਕੀਨ ਦਿਵਾਏ ਕਿ ਉਹ ਭਰੋਸੇਯੋਗ ਹਨ, ਫਿਰ ਹੀ ਤਦ ਹੀ ਫੈਲਾਓ।
ਅਲਸਾ: ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਓਪਰੇਟਿੰਗ ਮਾਡਲ ਸਮਝੋ, ਇੱਕ ਇਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ। ਜੇਤਿਆਰਾਂ pipeline ਬਣਾਉਂਦੇ ਹਨ (intake → build → test → run → improve) ਅਤੇ ਮੈਜ਼ਰਮੈਂਟ ਨੂੰ ਨਾਨ-ਨੈਗੋਸ਼ੀਏਬਲ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗੀ ਪੈਟਰਨ “ਹਾਈਬ੍ਰਿਡ ਸਟੈਕ” ਹੈ: ਜਿੱਥੇ UI ਅਤੇ ਗੰਦੇ ਹੈਂਡਆਫਜ਼ ਮਾਜੂਦ ਹੋ ਉਹਥੇ RPA ਵਰਤੋ, ਅਤੇ ਜਿੱਥੇ ਮਨੁੱਖਾਂ ਨੂੰ ਸਮੀਖਿਆ, ਮਨਜ਼ੂਰੀ, ਜਾਂ ਐਕਸਪਸ਼ਨ ਹੈਂਡਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਓਥੇ ਛੋਟੇ ਕਸਟਮ ਐਪ ਜੋੜੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਐਕਸਪਸ਼ਨ ਪੋਰਟਲ, ਇੱਕ ਰੀਕਨਸੀਲਏਸ਼ਨ ਡੈਸ਼ਬੋਰਡ, ਜਾਂ ਇੱਕ ਹਲਕਾ ਇੰਟੇਕ ਫਾਰਮ ਬਣਾਉਂਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਆਟੋਮੇਟਡ ਪ੍ਰਕਿਰਿਆ ਆਡੀਟਯੋਗ ਅਤੇ ਸਕੇਲਯੋਗ ਰਹੇ। Koder.ai ਵਰਗੇ ਟੂਲ ਉਹ ਲੇਅਰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਇੱਕ ਚੈਟ-ਕੇਂਦਰਤ ਯੋਜਨਾ ਤੋਂ React ਵੈੱਬ ਐਪ, Go ਬੈਕਏਂਡ, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ ਜਨਰੇਟ ਕਰਕੇ—ਜਦੋਂ ਵੀ ਜ਼ਰੂਰਤ ਹੋ IT ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ, ਡਿਪਲੋਯਮੈਂਟ/ਹੋਸਟਿੰਗ, ਅਤੇ ਰੋਲਬੈਕ ਸਨੈਪਸ਼ਾਟ ਦੇ ਨਾਲ ਨਿਯੰਤਰਣ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ।
ਹਰ ਨਵੀਂ ਆਟੋਮੇਸ਼ਨ ਮਨਜ਼ੂਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਵਰਤੋ:
ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਚੁਣੋ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਮਾਲਕ ਨਾਲ 30-ਮਿੰਟ ਦਾ ਵਰਕਸ਼ੌਪ ਕਰਕੇ ਚੈੱਕਲਿਸਟ ਚਲਾਓ। ਜੇ ਪਾਸ ਹੋ ਜਾਵੇ, ਤਾਂ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ 2–4 ਹਫ਼ਤੇ ਦੇ ਪਾਇਲਟ ਯੋਜਨਾ ਬਣਾਓ।
For more practical guidance, browse related articles.
“ਬੋਰਿੰਗ ਆਟੋਮੇਸ਼ਨ” ਉਹ ਦੋਹਰਾਉਂਦਾ, ਨਿਯਮ-ਅਧਾਰਿਤ “ਪਰਕਿਰਿਆ ਗਲੂ” ਕੰਮ ਹੈ ਜੋ ਸਿਸਟਮਾਂ ਦੇ ਵਿਚਕਾਰ ਬੈਠਦਾ ਹੈ—ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਨਾ, ਫੀਲਡਾਂ ਦੀ ਜਾਂਚ, ਖਾਤੇ ਬਣਾਉਣਾ, ਸਪ੍ਰੈਡਸ਼ੀਟ ਅਪਡੇਟ ਕਰਨਾ, ਰੋਜ਼ਾਨਾ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰਨਾ, ਅਤੇ ਇਨਾਂ ਆਈਟਮਾਂ ਨੂੰ ਕਿਊ ਵਿੱਚ ਅੱਗੇ ਵਧਾਉਣਾ।
ਇਹ ਵੱਡੇ ਕਾਰੋਬਾਰ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਬਣ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੈਮਾਨੇ 'ਤੇ ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਅਣਉੱਤਰੇ ਖਰਚਾਂ ਵੱਡੇ ਖਰਚਾਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਸਮਾਂ, ਗਲਤੀਆਂ, ਕੰਪਲਾਇੰਸ ਰਿਸਕ ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਦੀ ਮੋਰਾਲ ਉਤੇ ਪ੍ਰਭਾਵ।
RPA ਉਹ ਸੌਫਟਵੇਅਰ ਹੈ ਜੋ ਉਸੇ UI ਕਦਮਾਂ ਨੂੰ ਅਨੁਕਰਣ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਮਨੁੱਖ ਲੈਂਦਾ: ਲੌਗਿਨ, ਕਲਿੱਕ ਕਰਨਾ, ਟਾਈਪ ਕਰਨਾ, ਕਾਪੀ/ਪੇਸਟ, ਫਾਇਲਾਂ ਡਾਊਨਲੋਡ ਕਰਨਾ, ਅਤੇ ਫਾਰਮ ਭਰਨਾ।
ਨਵੀਂ ਸਿਸਟਮਾਂ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਇੱਕ RPA ਬੋਟ ਇੱਕ ਨਿਰਧਾਰਿਤ ਵਰਕਫਲੋ ਫੋਲੋ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਟੂਲਾਂ (ਈਮੇਲ, PDF, ਪੋਰਟਲ, ERP, CRM) ਦਰਮਿਆਨ ਜਾਣਕਾਰੀ ਨੂੰ ਮੂਵ ਕਰ ਸਕੇ ਅਤੇ ਰੁਟੀਨ ਫੈਸਲੇ ਅਤੇ ਕੁਝ ਤਾਂ-ਬਾਦਲੇ ਨੂੰ ਸੰਭਾਲ ਸਕੇ।
RPA ਚੁਣੋ ਜਦੋਂ ਕੰਮ ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਉਹਨਾਂ ਟੂਲਾਂ ਵਿਚਕਾਰ ਜਾਣਕਾਰੀ ਘੁਮਾਉਣ ਬਾਰੇ ਹੋਵੇ ਜੋ ਅਚਛੀ ਤਰ੍ਹਾਂ ਇੰਟੀਗਰੇਟ ਨਹੀਂ ਹੁੰਦੇ।
APIs ਚੁਣੋ ਜਦੋਂ ਸਿਸਟਮ ਭਰੋਸੇਯੋਗ, ਸਮਰਥਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਿੰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਥਿਰਤਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਚਾਹੀਦਾ ਹੋਵੇ।
ਕਸਟਮ ਸੌਫਟਵੇਅਰ ਚੁਣੋ ਜਦੋਂ ਵਰਕਫਲੋ ਉਤਨਾ ਰਣਨੀਤਿਕ ਹੋਵੇ ਕਿ ਉਸਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵੀਨੀਕਰਨ ਜ਼ਰੂਰੀ ਹੋਵੇ (ਨਵੇਂ ਉਤਪਾਦ ਲਛਣ, ਨਵਾਂ ਪ੍ਰਕਿਰਿਆ ਡਿਜ਼ਾਈਨ, ਜਾਂ ਜਟਿਲ ਲਾਜ਼ਿਕ ਜੋ UI 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦੀ)।
UiPath ਨੇ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਅਸਲੀ ਕਾਰੋਬਾਰੀ ਵਰਕਫਲੋਜ਼ ਲਈ ਅਮਲਯੋਗ ਬਣਾਈਆ:
ਇਹ ਮਿਲਾਪ ਨਾ-ਟੈਕਨੀਕਲ ਮਾਲਕਾਂ ਨੂੰ ਆਟੋਮੇਸ਼ਨ ਦੀ ਵਾਜਬੀ ਦਰਸਾਉਣਾ ਤੇ IT/ਸੁਰੱਖਿਆ ਨੂੰ ਗਵਰਨ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ।
ਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਵਰਤੋਂਕਾਰ ਦੇ ਡੈਸਕਟਾਪ 'ਤੇ ਚਲਦੀ ਹੈ ਅਤੇ ਵਰਕਰ ਦੇ ਟਰਿਗਰ ਨਾਲ ਚੱਲਦੀ ਹੈ—ਜਿੱਥੇ ਮਨੁੱਖ ਫੈਸਲੇ ਜਾਂ ਕੰਪਲਾਇੰਸ ਲਈ ਲੂਪ ਵਿੱਚ ਰਹਿਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ।
ਅਨਅਟੈਂਡੇਡ ਆਟੋਮੇਸ਼ਨ ਸਰਵਰਾਂ/VMs 'ਤੇ ਪਿਛੋਕੜ ਵਿੱਚ ਚਲਦੀ ਹੈ, ਸ਼ੈਡਿਊਲ ਜਾਂ ਇਵੈਂਟ-ਚਲਿਤ ਹੁੰਦੀ ਹੈ—ਉੱਚ ਵਧੇਰੇ-ਵਾਲੀਅਮ ਅਤੇ ਦੋਹਰਾਓ ਵਾਲੀਆਂ ਬੈਕ-ਆਫਿਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਵਧੀਆ।
ਅਕਸਰ ਅਪਨਾਉਣ ਦਾ ਰਾਹ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਅਦਮੀ-ਸਹਾਇਤਾ ਵਾਲੀਆਂ ਛੋਟੀਆਂ ਜਿੱਤਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ, ਅਤੇ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਸਥਿਰ ਹੋ ਜਾਵੇ ਤਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੈਕ-ਆਫਿਸ ਬੋਟ ਵੱਲ ਵਧਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਤਾਕਤਵਰ ਪਾਇਲਟ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਛੋਟੇ-ਪੈਮਾਨੇ ਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡਿਪਲੋਇਮੈਂਟ ਵਾਂਗ ਸਜੇ ਹੋਵੇ:
ਕਾਮਯਾਬੀ ਸਿਰਫ਼ “ਬੋਟ ਕੰਮ ਕਰਦਾ ਹੈ” ਨਾ ਹੋ ਕੇ “ਬੋਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਮਰਥਿਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ” ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ RPA ਈਨੀਸ਼ੀਏਟਿਵਸ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ:
ਜਦੋਂ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦਿਖਾ ਸਕਦਾ ਕਿ ਬੋਟ ਕਾਬੂ ਵਿੱਚ ਅਤੇ ਸਮਰਥਿਤ ਹੈ, ਤਾਂ ਉਮੀਦ ਨਹੀਂ ਕਿ ਇਹ ਇੱਕ ਕਾਰਜਕਾਰੀ ਪ੍ਰੋਗਰਾਮ ਬਣੇਗਾ।
CoE (Center of Excellence) ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਇਸਨੂੰ ਇੱਕ ਰੋਕੜ ਬਿਆਪਤ ਬਿਊਰੋਕ੍ਰੇਸੀ ਵਿੱਚ ਬਦਲਣ ਦੇ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ:
ਤਰਜੀਹੀ ਮਾਡਲ ਹੈ: ਕੇਂਦਰੀ ਸਟੈਂਡਰਡ, ਵਿਤਰਿਤ ਬਣਾਉਣਾ।
ਬੋਟ ਨੂੰ ਇੱਕ ਯੂਜ਼ਰ ਵਾਂਗ ਹੀ ਮਨੋ—ਪਰ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਮਾਫ਼ ਕਰਨ ਵਾਲਾ। ਜੇ ਬੋਟ ਕੋਲ ਵਿਆਪਕ ਐਕਸੈਸ ਹੈ ਤਾਂ ਵੱਡਾ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ। ਕਿੱਤਾਂ ਸੁਰੱਖਿਆ ਅਤੇ ਨਿਗਰਾਨੀ ਜੋ ਟੀਮਾਂ ਭਰੋਸਾ ਕਰਦੀਆਂ ਹਨ:
ਸਧਾਰਣ, ਪਰ ਡਿਫੈਂਡਬਲ ਮਾਪਦੰਡ ਵਰਤੋ:
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਫਾਰਮੂਲਾ: Value = (ਰਿਵਰਕ ਲਾਗਤ ਬਚਤ + ਤੇਜ਼ ਸਾਈਕਲਟਾਈਮ ਦਾ ਨਕਦੀ/ਰੈਵਿਨਿਊ ਪ੍ਰਭਾਵ + ਸਖਤ ਲਾਗਤ ਘਟਾ) − (ਲਾਇਸੈਂਸ + ਬਣਾਉਣ + ਚਲਾਉਣ ਦੀ ਲਾਗਤ)
ਸੁਰੱਖਿਆ ਅਤੇ ਆਡੀਟਾਂਬੇਲਟੀ ਅਕਸਰ ਉਹ 'ਦਰਵਾਜ਼ਾ ਹੈ' ਜਿਸ 'ਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਿਹੜੀਆਂ ਫਾਇਨੈਂਸ, HR ਜਾਂ ਗਾਹਕ ਡੇਟਾ ਨੂੰ ਛੁਹਦੀਆਂ ਹਨ, घुस ਸਕਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ: “2,000 ਘੰਟੇ ਬਚੇ” ਨੂੰ ਸਲੈਰੀ ਨਾਲ ਗੁਣਾ ਕਰਨਾ ਬਿਨਾਂ ਪੁਨਰਤਖਕੀ ਯੋਜਨਾ ਦੇ—ਜੋ ਅਕਸਰ.capacity ਹੋਂਦੇ ਹਨ, ਖ਼ਰਚ ਨਹੀਂ।