ਮੈਨੁਅਲ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ ਸਾਫਟਵੇਅਰ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਰੀਮਾਈੰਡਰਾਂ ਜਾਂ ਨਿਯਮਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਟੇਟਸ, ਮਾਲਕ, ਡੈਡਲਾਈਨ ਅਤੇ ਛੂਟਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਲੈਂਦੇ ਹੋ।
ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਛੋਟੀ ਅਤੇ ਗੈਰ-ਔਪਚਾਰਿਕ ਹੁੰਦੀ ਹੈ, ਈਮੇਲ ਮਨਜ਼ੂਰੀਆਂ ਵਾਸਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਦੂਜਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੰਮ ਅੱਗੇ ਵਧਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਹੋਰ ਲੋਕ ਸ਼ਾਮਲ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਸਮੱਸਿਆਆਂ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲੀ ਸਮੱਸਿਆ ਦ੍ਰਿਸ਼ਟੀਭੰਗ ਦੀ ਹੈ। ਮਨਜ਼ੂਰੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨਿਊਜ਼ਲੇਟਰ, ਕੈਲੰਡਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਦਿਨਚਰਿਆ ਦੇ ਸੁਨੇਹਿਆਂ ਦੇ ਬਗਲ ਵਿੱਚ ਬੈਠ ਜਾਣਦੀਆਂ ਹਨ। ਕੋਈ ਬੰਦਾ ਬਾਅਦ ਵਿੱਚ ਵੇਖਣ ਦਾ ਸੋਚਦਾ ਹੈ ਤੇ ਫਿਰ ਉਹ ਈਨਬਾਕਸ ਵਿੱਚੋਂ ਡਿੱਗ ਕੇ ਗੁੰਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਅਗਲੀ ਸਮੱਸਿਆ ਵਰਜ਼ਨ ਦੀ ਭ੍ਰਮ ਹੈ। ਇਕ ਵਿਅਕਤੀ ਮੂਲ ਧਾਗੇ ਨੂੰ ਜਵਾਬ ਦੇਂਦਾ ਹੈ, ਦੂਜਾ ਸੰਸ਼ੋਧਿਤ ਸੰਲਗਨ ਅੱਗੇ ਵੱਧਾਉਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੋਈ ਪੁਰਾਣੀ ਨਕਲ ਮਨਜ਼ੂਰ ਕਰ ਲੈਂਦਾ ਹੈ। ਕੁੱਝ ਦੌਰਾਂ ਮਗਰੋਂ ਕਿਸੇ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਤਾ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਕਿਹੜੀ ਫਾਈਲ, ਕੀਮਤ ਜਾਂ ਸ਼ਬਦਾਵਲੀ ਅਜੇ ਵਰਤਮਾਨ ਹੈ।
ਮਿਲਕੀਅਤ ਵੀ ਅਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ। ਜੇ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਫਾਇਨੈਂਸ, ਲੀਗਲ ਅਤੇ ਟੀਮ ਲੀਡ ਦੀ ਸਲਾਹ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜਦੋਂ ਇਹ ਰੁਕਦੀ ਹੈ ਤਾਂ ਜਵਾਬਦੇਹ ਕੌਣ ਹੈ? ਈਮੇਲ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ ਤੇ ਅਸਪਸ਼ਟ ਰਹਿੰਦਾ ਹੈ। ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਕੋਈ ਹੋਰ ਇਸ ਨੂੰ ਦੇਖ ਰਿਹਾ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
ਮਾਮਲੇ ਹੋਰ ਬਿਗੜ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਬੰਦਾ ਦਫ਼ਤਰ ਤੋਂ ਬਾਹਰ ਹੋਵੇ ਜਾਂ ਰਾਹ ਵਿੱਚ ਬਦਲਾਅ ਆ ਜਾਂਦਾ ਹੋਵੇ ਜਿਵੇਂ ਰਕਮ, ਖਤਰਾ ਜਾਂ ਗਾਹਕ ਦੀ ਕਿਸਮ ਦੇ ਅਧਾਰ ‘ਤੇ। ਇਹ ਛੂਟ ਅਕਸਰ ਲੋਕਾਂ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਵੱਸਦੀਆਂ ਹਨ ਨਾ ਕਿ ਸਾਂਝੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ। ਇਸ ਨਾਲ ਮਨਜ਼ੂਰੀ ਰਾਹ ਦੀ ਭਵਿੱਖ ਵਾਣੀ ਮੁਸ਼ਕਲ ਅਤੇ ਟ੍ਰੈਕ ਕਰਨਾ ਹੋਰ ਵੀ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਸਦੀ ਲਾਗਤ ਕੁਝ ਦੇਰ ਵਾਲੇ ਜਵਾਬਾਂ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਦੇਰੀ ਦੀਆਂ ਵਜ੍ਹਾਂ ਕਾਰਜ ਖਰੀਦ, ਠੇਕੇ, ਲਾਂਚ, ਭਰਤੀ ਦੇ ਫੈਸਲੇ ਅਤੇ ਗਾਹਕ ਕੰਮ ਰੁਕ ਸਕਦੇ ਹਨ। ਟੀਮਾਂ ਅਪਡੇਟ ਲੱਭਣ ਵਿੱਚ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ ਨਾ ਕਿ ਖ਼ੁਦ ਕੰਮ ਕਰਨ ਵਿੱਚ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ ਸਮੱਸਿਆ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ। ਸੇਲਜ਼ ਡਿਸਕਾਊਂਟ ਦੀ ਬੇਨਤੀ ਮੈਨੇਜਰ ਨੂੰ ਈਮੇਲ ਨਾਲ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਫਾਇਨੈਂਸ ਨੂੰ ਅੱਗੇ ਭੇਜ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਫਾਇਨੈਂਸ ਇੱਕ ਸੋਧੀ ਗਿਣਤੀ ਮੰਗਦਾ ਹੈ, ਪਰ ਰਿਪ ਨੇ ਸਿਰਫ ਇੱਕ ਧਾਗਾ ਅਪਡੇਟ ਕੀਤਾ। ਮੈਨੇਜਰ ਪਿਛਲੇ ਵਰਜ਼ਨ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਦਿੰਦਾ ਹੈ, ਫਾਇਨੈਂਸ ਪੁਸ਼ਟੀ ਦੀ ਉਡੀਕ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਗਾਹਕ ਨੂੰ ਦੋ ਦਿਨ ਤੱਕ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਮਿਲਦੀ।
ਇਸੇ ਕਾਰਨ ਟੀਮਾਂ ਮੈਨੁਅਲ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ ਸਾਫਟਵੇਅਰ ਵੱਲ ਦৃষ্টি ਘੁਮਾਉਂਦੀਆਂ ਹਨ। ਅਸਲ ਸਮੱਸਿਆ ਸਿਰਫ਼ ਗਤੀ ਨਹੀਂ ਹੁੰਦੀ। ਈਮੇਲ ਸਟੇਟਸ, ਮਾਲਕੀ, ਡੈਡਲਾਈਨ ਅਤੇ ਛੂਟਾਂ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟ ਨਹੀਂ ਜਾਂਦਾ।
ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਕੁਝ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਮੌਜੂਦਾ ਸਮੇਂ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਚੱਲਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਕਦਮ ਛੱਡ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਸੰਭਵਤ: ਈਮੇਲ ਦੀ ਗੜਬੜ ਨੂੰ ਨਵੇਂ ਟੂਲ ਵਿੱਚ ਨਕਲ ਕਰ ਲਵੋਗੇ, ਨਾ ਕਿ ਉਸਨੂੰ ਠੀਕ ਕਰੋਗੇ।
ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਹਰ ਮਨਜ਼ੂਰੀ ਫਲੋ ਇਕੱਠੇ ਨਹੀਂ ਲਿਆਓ। ਉਸ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚੁਣੋ ਜੋ ਵਾਰੰ ਵਾਰ ਹੁੰਦੀ ਹੈ, ਦੇਰੀ ਕਰਦੀ ਹੈ ਜਾਂ ਸਭ ਤੋਂ ਵੱਧ ਫਾਲੋ-ਅਪ ਬਣਾਉਂਦੀ ਹੈ, ਜਿਵੇਂ ਖਰੀਦ ਬੇਨਤੀਆਂ, ਸਮੱਗਰੀ ਸਾਈਨ-ਆਫ, ਡਿਸਕਾਊਂਟ ਮਨਜ਼ੂਰੀਆਂ ਜਾਂ ਐਕਸੈਸ ਬੇਨਤੀਆਂ।
ਫਿਰ ਕੁਝ ਅਸਲ ਉਦਾਹਰਨਾਂ ਵੇਖੋ। 3–5 ਹਾਲੀਆ ਈਮੇਲ ਥ੍ਰੈਡ ਆਮ ਤੌਰ ਤੇ ਪੈਟਰਨ ਦਿਖਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਅਸਲ ਕੇਸ ਵਰਤੋਂ, ਯਾਦਦਾਸ਼ਤ ਤੇ ਆਧਾਰਿਤ ਨਹੀਂ। ਲੋਕ ਛੋਟੇ ਹੱਥ-ਅਦਾਂ-ਪ੍ਰਦਾਨ, ਸਾਈਡ ਜਵਾਬ ਅਤੇ ਆਖਰੀ ਸਮੇਂ ਦੀਆਂ ਛੂਟਾਂ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।
ਉਹ ਉਦਾਹਰਨਾਂ ਵੇਖਦਿਆਂ, ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਮੁੱਢਲੀਆਂ ਚੀਜ਼ਾਂ ਕੈਪਚਰ ਕਰੋ:
ਇਸਦੇ ਨਾਲ ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਹਰ ਕਦਮ ਨੂੰ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਮੈਨੇਜਰ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਜਟ ਰਕਮ, ਵੇਂਡਰ ਦਾ ਨਾਮ ਅਤੇ ਮੰਗੀ ਮਿਤੀ ਚਾਹੀਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਉਹ ਜਾਣਕਾਰੀ ਅਕਸਰ ਗਾਇਬ ਰਹਿੰਦੀ ਹੈ ਤਾਂ ਦੇਰੀ ਅਸਲ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਬਲਕਿ ਬੇਨਤੀ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਡੈਡਲਾਈਨ ਵੀ ਨਕਸ਼ੇ ਵਿੱਚ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਲਿਖੋ ਕਿ ਹਰ ਕਦਮ ਨੂੰ ਕਿੰਨਾ ਸਮਾਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਿ ਤੇਜ਼ ਬੇਨਤੀਆਂ ਵੱਖਰੇ ਰਾਹ ਫੋਲੋ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ। ਛੂਟ ਨਿਯਮ ਵੀ ਇੱਕਠੇ ਲਿਖੋ। ਸ਼ਾਇਦ ਇੱਕ ਨਿਰਧਾਰਿਤ ਰਕਮ ਤੋਂ ਵੱਧ ਮਨਜ਼ੂਰੀ ਫਾਇਨੈਂਸ ਨੂੰ ਜਾਵੇ। ਸ਼ਾਇਦ ਮੁੱਖ ਮਾਲਕ ਗੈਰਹਾਜ਼ਰ ਹੋਣ 'ਤੇ ਬੈਕਅਪ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਅੱਗੇ ਆ ਜਾਵੇ।
ਸਾਰੀ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਪੰਨੇ 'ਤੇ ਉਹਨਾਂ ਸ਼ਬਦਾਂ ਨਾਲ ਰੱਖੋ ਜੋ ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੇ ਹਨ। ਲਿਖੋ 'Finance checks the amount' ਜਾਂ 'Manager asks for missing details' ਵਰਗਾ — ਨਾ ਕਿ ਕੁਝ ਆਬਸਟ੍ਰੈਕਟ ਅਤੇ ਸਿਸਟਮ-ਨੁਮਾ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਏਹ ਹੈ ਕਿ ਲੋਕ ਇਸਨੂੰ ਪਛਾਣ ਸਕਣ, ਨਾ ਕਿ ਇੱਕ ਸੁੰਦਰ ਡਾਇਗ੍ਰਾਮ ਜੋ ਸਿਰਫ਼ ਦਿੱਖ ਵਿੱਚ ਚੰਗਾ ਲੱਗੇ।
ਜਦੋਂ ਉਹਨਾਂ ਲੋਕਾਂ ਜੋ ਕੰਮ ਕਰਦੇ ਹਨ ਕਹਿਣ ਕਿ 'ਹਾਂ, ਇਹ ਅਸਲ ਵਿੱਚ ਅਜੇਹੀ ਹੀ ਹੁੰਦਾ ਹੈ', ਤਾਂ ਤੁਹਾਡਾ ਨਕਸ਼ਾ ਤਿਆਰ ਹੈ।
ਇੱਕ ਵਧੀਆ ਸਟੇਟਸ ਸੂਚੀ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਟੈਸਟ ਪਾਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਜੇ ਦੋ ਲੋਕ ਇੱਕੋ ਬੇਨਤੀ ਪੜ੍ਹਦੇ ਹਨ ਤਾਂ ਉਹ ਇੱਕੋ ਨਤੀਜੇ ਤੇ ਪਹੁੰਚਣ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ।
ਇਸ ਲਈ ਮੈਨੁਅਲ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ ਸਾਫਟਵੇਅਰ ਛੋਟੀ, ਸਪਸ਼ਟ ਸਟੇਟਸ ਸੂਚੀ ਨਾਲ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਨੂੰ ਦੱਸ ਸਿਗਰੇਟਾਂ ਲਈ ਦਹਾਂ ਲੇਬਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਐਸੇ ਲੇਬਲ ਚਾਹੀਦੇ ਹਨ ਜੋ ਦੱਸਣ ਕਿ ਬੇਨਤੀ ਅੱਜ ਕਿੱਥੇ ਖੜੀ ਹੈ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਸ਼ੁਰੂਆਤੀ ਸੁਝਾਅ ਇੰਝ ਲੱਗ ਸਕਦਾ ਹੈ:
ਹਰ ਸਟੇਟਸ ਦਾ ਇੱਕ ਸਹੀ ਅਰਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Waiting for approval ਦਾ ਮਤਲਬ ਹੈ ਬੇਨਤੀ ਤਿਆਰ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਸਮੀਖਿਆ ਕਰਨੀ ਹੈ। Needs changes ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਹਜੇ ਮਨਜ਼ੂਰ ਨਹੀਂ ਹੋਈ ਪਰ ਸੋਧ ਕੇ ਮੁੜ ਆ ਸਕਦੀ ਹੈ। Rejected ਦਾ ਮਤਲਬ ਹੈ ਬੇਨਤੀ ਰੁਕੀ ਰਹਿੰਦੀ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਨਿਯਮ ਉਹਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣ ਦੀ ਆਗਿਆ ਨਾ ਦੇਵੇ।
ਗਲਤਫਹਮੀ ਉਸ ਵੇਲੇ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਕਰੀਬ-ਕਰੀਬ ਇੱਕੋ ਜਿਹੇ ਲੇਬਲ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜਿਵੇਂ Pending, In review, Under review, ਅਤੇ Awaiting sign-off। ਸਿਸਟਮ ਲਈ ਇਹ ਵੱਖਰੇ ਹਨ, ਪਰ ਲੋਕਾਂ ਲਈ ਇਹ ਅਕਸਰ ਇੱਕੋ ਹੀ ਹੁੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਰਿਪੋਰਟਿੰਗ ਗੜਬੜੀ, ਅਸਪਸ਼ਟ ਹੈਂਡਆਫ ਅਤੇ ਵਧੇਰੇ ਸਵਾਲ ਹੁੰਦੇ ਹਨ।
ਜੇਕਰ ਕਿਸੇ ਸਟੇਟਸ ਨੂੰ ਲੰਬੀ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਉਸਦਾ ਨਾਮ ਬਦਲ ਦਿਓ। ਵਧੀਆ ਲੇਬਲ ਲਿਸਟ, ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਮੋਬਾਈਲ ਸਕਰੀਨ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਲੋਕਨਾਂ ਨੂੰ ਰਿਕਾਰਡ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਸਮਝ ਆ ਜਾਵੇ।
ਸਟੇਟਸ ਨੂੰ ਮਾਲਕੀ ਤੋਂ ਵੱਖਰਾ ਰੱਖਣਾ ਵੀ ਸਮਝਦਾਰ ਹੈ। Waiting for approval ਆਮ ਤੌਰ ਤੇ With finance ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। ਪਹਿਲਾ ਸਥਿਤੀ ਦੱਸਦਾ ਹੈ; ਦੂਜਾ ਸਥਿਤੀ ਅਤੇ ਮੌਜੂਦਾ ਸਮੀਖਿਆਕਾਰ ਦੋਹਾਂ ਮਿਲਾ ਦਿੰਦਾ ਹੈ।
ਛੋਟੀ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਲੋੜ ਪਏ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਕੋਈ ਨਵਾਂ ਸਟੇਟਸ ਜੋੜੋ।
ਜੇ ਕਿਸੇ ਕਦਮ ਦਾ ਮਾਲਕ 'ਟੀਮ' ਰਹੇ ਬਿਨਾਂ ਕਿਸੇ ਵਿਅਕਤੀ ਦੇ, ਤਾਂ ਵਰਕਫਲੋ ਤੇਜ਼ੀ ਨਾਲ ਟੁਟ ਜਾਂਦਾ ਹੈ। ਹਰ ਪੜਾਅ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਮਾਲਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਵਿਅਕਤੀ ਹੋਰਾਂ ਤੋਂ ਫੀਡਬੈਕ ਲੈ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਨਾਮ ਜਾਂ ਇਕ ਨਿਰਧਾਰਿਤ ਰੋਲ ਜ਼ਿੰਮੇਵਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਬੇਨਤੀ ਅੱਗੇ ਵਧਾਵੇ।
ਇਹ ਈਮੇਲ ਚੇਨ ਤੋਂ ਸੌਫਟਵੇਅਰ ਵੱਲ ਜਾਣ ਵੇਲੇ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਈਮੇਲ ਵਿੱਚ ਲੋਕ ਆਦਤਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ — ਕੋਈ ਧਾਗਾ ਵੇਖ ਲੈਂਦਾ ਹੈ, ਕਿਸੇ ਨੂੰ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਜਾਂ ਅਗਲੇ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲੇ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। ਸੌਫਟਵੇਅਰ ਉਸ ਤਰ੍ਹਾਂ ਦੀ ਅੰਦਾਜ਼ ਤੀਹਰੇ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਹਰ ਕਦਮ ਲਈ ਚਾਰ ਸਧਾਰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ:
ਹੈਂਡਆਫ ਵੀ ਇੱਕੋ ਤਰ੍ਹਾਂ ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਮੈਨੇਜਰ ਮਨਜ਼ੂਰ ਕਰਦਾ ਅਤੇ ਫਿਰ ਫਾਇਨੈਂਸ ਦੀ ਜਾਂਚ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਵਰਕਫਲੋ ਵਿੱਚ ਸਿੱਧਾ ਇਹ ਲਿਖੋ। ਕਿੱਸੇ ਪਾਸੇ 'send to finance' ਇੱਕ ਧੁੰਦਲਾ ਨਿਰਦੇਸ਼ ਹੈ ਜੇ ਸਿਸਟਮ ਨੂੰ ਪਤਾ ਨਾ ਹੋਵੇ ਕਿ ਕਿਹੜਾ ਵਿਅਕਤੀ ਜਾਂ ਰੋਲ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰੇਗਾ।
ਇੱਕ ਸਧਾਰਣ ਉਪਕਰਣ ਬੇਨਤੀ ਲਵੋ। ਇਹ ਕਰਮਚਾਰੀ ਦੇ ਮੈਨੇਜਰ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਜੇ ਖ਼ਰਚ ਨਿਰਧਾਰਿਤ ਰਕਮ ਤੋਂ ਵੱਧ ਹੋਵੇ ਤਾਂ ਇਹ ਫਾਇਨੈਂਸ ਦੇ ਕੋਲ ਜਾਂਦੀ ਹੈ। ਜੇ ਫਾਇਨੈਂਸ ਦਾ ਮਾਲਕ ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ ਤਾਂ ਇੱਕ ਬੈਕਅਪ ਕੰਟਰੋਲਰ ਇੱਕ ਕਾਰੋਬਾਰੀ ਦਿਨ ਬਾਅਦ ਕੰਮ ਸੰਭਾਲ ਲੈਂਦਾ। ਜੇ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਨੇ ਗਲਤੀ ਕੀਤੀ ਹੈ ਤਾਂ ਸਿਰਫ ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਅਤੇ ਪਹਿਲਾ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਹੀ ਇਸਨੂੰ ਮੁੜ ਖੋਲ੍ਹ ਸਕਦੇ ਹਨ। ਜੇ ਬੇਨਤੀ ਦੀ ਲੋੜ ਖਤਮ ਹੋ ਗਈ ਤਾਂ ਸਿਰਫ ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਜਾਂ ਵਿਭਾਗ ਮੈਨੇਜਰ ਹੀ ਇਸਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹਨ।
ਇਹ ਨਿਯਮ ਸਕਤਰ ਤੇ ਕਠੋਰ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਆਮ ਗੜਬੜੀਆਂ ਰੋਕਦੇ ਹਨ: ਰੁਕੇ ਹੋਏ ਬੇਨਤੀ, ਡੁਪਲਿਕੇਟ ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਲੰਬੇ ਫ਼ਾਸਲੇ ਜਿੱਥੇ ਹਰ ਕੋਈ ਸੋਚਦਾ ਹੈ ਕਿ ਕੋਈ ਹੋਰ ਜਵਾਬਦੇਹ ਹੈ।
ਜਦ ਇੱਕ ਸਾਰਥਕ ਡੈਡਲਾਈਨ ਸਾਰੀ ਬੇਨਤੀ ਲਈ ਇਕੱਲਾ ਹੀ ਹੋਵੇ ਤਾਂ ਵਰਕਫਲੋ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਹਰ ਪੜਾਅ ਲਈ ਆਪਣਾ ਡਿਊ ਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਟੀਮਾਂ ਵੇਖ ਸਕਣ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਖਰਚ ਹੋ ਰਿਹਾ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਮੈਨੇਜਰ ਦੀ ਸਮੀਖਿਆ ਲਈ ਇੱਕ ਕਾਰੋਬਾਰੀ ਦਿਨ, ਫਾਇਨੈਂਸ ਲਈ ਦੋ ਦਿਨ ਅਤੇ ਲੀਗਲ ਲਈ ਤਿੰਨ ਦਿਨ ਰੱਖੇ ਜਾ ਸਕਦੇ ਹਨ। ਜਿਆਦਾਤਰ ਹਾਲਤਾਂ ਵਿੱਚ ਘੜੀ ਉਸ ਵੇਲੇ ਚਲਣੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਉਸ ਸਟੇਟਸ ਵਿੱਚ ਐਂਟਰ ਕਰਦੀ ਹੈ, ਨਾ ਕਿ ਜਦ ਪਹਿਲੀ ਈਮੇਲ ਭੇਜੀ ਗਈ ਸੀ। ਇਸ ਨਾਲ ਓਵਰਡਿਊ ਕੰਮ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ।
ਆਪਣੇ ਆਟੋਮੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਮੁੱਢਲੇ ਨੁਕਤੇ ਤੈਅ ਕਰੋ:
ਜਦ ਡੈਡਲਾਈਨ ਲੰਘ ਜਾਵੇ, ਤਦ ਅਗਲਾ ਕਦਮ ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰੋ। ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਆਮ ਤੌਰ ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ: ਇੱਕ ਰੀਮਾਈੰਡਰ ਭੇਜੋ, ਫਿਰ ਕੁਝ ਨਾ ਹੋਣ 'ਤੇ ਬੈਕਅਪ ਮਾਲਕ ਜਾਂ ਟੀਮ ਲੀਡ ਨੂੰ ਐਸਕਲੇਟ ਕਰੋ। ਓਵਰਡਿਊ ਕੰਮ ਨੂੰ ਇੱਕੋ ਸਟੇਟਸ ਵਿੱਚ ਬਿਨਾਂ ਕਾਰਵਾਈ ਦੇ ਨਾ ਛੱਡੋ।
ਤੇਜ਼ ਬੇਨਤੀਆਂ ਲਈ ਵੱਖਰਾ ਪਥ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਇਹ ਤنگ ਰੱਖੋ। ਜੇ ਹਰ ਚੀਜ਼ ਨੂੰ urgent ਕਹਿ ਸਕਦੇ ਹੋ ਤਾਂ ਇਹ ਲੇਬਲ ਬੇਕਾਰ ਹੋ ਜਾਵੇਗਾ। ਇਸਨੂੰ ਕੁਝ ਸਪਸ਼ਟ ਮਾਮਲਿਆਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ, ਜਿਵੇਂ ਗਾਹਕ-ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਜਾਂ ਕੰਪਲਾਇੰਸ ਦੀਆਂ ਮੁਹੱਤਵਪੂਰਨ ਮਿਤੀਆਂ।
ਛੂਟ ਨਿਯਮ ਵੀ ਉਹਨੇ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਬੇਨਤੀ ਵਿੱਚ ਜਾਣਕਾਰੀ ਘੱਟ ਹੈ, ਤਾਂ ਉਸਨੂੰ Waiting for requester ਵਰਗੇ ਸਟੇਟਸ 'ਤੇ ਲਿਜਾਓ ਅਤੇ ਟਾਈਮਰ ਰੋਕ ਦਿਓ। ਜੇ ਕੋਈ ਚੀਜ਼ ਨੀਤੀ ਤੋਂ ਬਾਹਰ ਹੈ ਤਾਂ ਉਸਨੂੰ ਨਾਮਤੱਥ ਅਪروਵਰ ਕੋਲ ਰਾਹ ਦਿਓ, ਨਾ ਕਿ ਲੋਕਾਂ ਨੂੰ ਈਮੇਲ ਵਿੱਚ ਬੇਰੁਕਹੀ ਛੱਡ ਦਿਓ।
ਇੱਕ ਸਧਾਰਣ ਖਰੀਦ ਬੇਨਤੀ ਉਦਾਹਰਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਕਿੰਨਾ ਅਹੰਕਾਰ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਫਾਇਨੈਂਸ ਨੂੰ ਬੇਨਤੀ ਮਿਲਦੀ ਹੈ ਪਰ ਵੇਂਡਰ ਕੋਟ ਨਹੀਂ ਹੈ। ਬਿਨਾਂ ਨਿਯਮ ਦੇ, ਫਾਇਨੈਂਸ ਦੀ ਡੈਡਲਾਈਨ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਉਲਝ ਜਾਂਦਾ ਹੈ। ਨਿਯਮ ਹੋਣ ਤੇ ਬੇਨਤੀ Missing information 'ਤੇ ਚਲੀ ਜਾਂਦੀ ਹੈ, ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਐਕਟਿਵ ਮਾਲਕ ਬਣਦਾ ਹੈ ਅਤੇ ਡੈਡਲਾਈਨ ਤਬ ਤੱਕ ਰੁਕ ਜਾਂਦੀ ਹੈ ਜਦ ਤੱਕ ਕੋਟ ਨਾ ਮਿਲੇ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਨਵੇਂ ਲੈਪਟਾਪ ਲਈ ਖਰੀਦ ਬੇਨਤੀ। ਇੱਕ ਕਰਮਚਾਰੀ ਫਾਰਮ ਭਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਆਈਟਮ, ਕੀਮਤ, ਕਾਰਨ ਅਤੇ ਲੋੜੀਦੀ ਮਿਤੀ ਹੁੰਦੀ ਹੈ। ਵਰਕਫਲੋ ਨੂੰ ਜਿਆਦਾ ਜਟਿਲ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਮੂਲ ਸੰਸਕਰਨ ਇਹ ਸਟੇਟਸ ਵਰਤ ਸਕਦਾ ਹੈ:
ਬੇਨਤੀ Submitted ਹੋ ਕੇ ਮੈਨੇਜਰ ਕੋਲ ਜਾਂਦੀ ਹੈ। ਜੇ ਕਰਮਚਾਰੀ ਨੇ ਸਿਰਫ਼ 'laptop for new hire' ਲਿਖਿਆ ਅਤੇ ਬਜਟ ਕੋਡ ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਮੈਨੇਜਰ ਨੂੰ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ Needs more info ਤੇ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ ਨੂੰ ਵਾਪਸ ਭੇਜ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਰਮਚਾਰੀ ਮੁੜ ਲੋੜੀਦੀ ਜਾਣਕਾਰੀ ਜੋੜ ਕੇ ਦੁਬਾਰਾ ਸਬਮਿਟ ਕਰੇਗਾ।
ਜਦ ਬੇਨਤੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ, ਮੈਨੇਜਰ ਇਸਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਅਤੇ ਸਟੇਟਸ Manager approved ਕਰ ਦਿੰਦਾ ਹੈ। ਮਾਲਕੀ ਫਿਰ ਫਾਇਨੈਂਸ ਨੂੰ ਮਿਲਦੀ ਹੈ। ਫਾਇਨੈਂਸ ਬਜਟ, ਵੇਂਡਰ ਨਿਯਮ ਅਤੇ ਖ਼ਰਚ ਸੀਮਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇ ਸਭ ਕੁਝ ਠੀਕ ਹੋਏ ਤਾਂ ਸਟੇਟਸ Finance approved ਹੋ ਜਾਂਦਾ ਹੈ।
ਹੁਣ ਇੱਕ ਅਸਲ-ਜਹੀ ਛੂਟ ਜੋੜੋ: ਫਾਇਨੈਂਸ ਦਾ ਅਕਾਰੁਸ਼ੀਕ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਤਿੰਨ ਦਿਨ ਲਈ ਬਿਮਾਰ ਹੈ। ਜੇ ਇਹ ਨਿਯਮ ਪਹਿਲਾਂ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਤਾਂ ਬੇਨਤੀ ਉੱਥੇ ਹੀ ਰੁਕੀ ਰਹੇਗੀ। ਵਧੀਆ ਸੈਟਅਪ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਬੈਕਅਪ ਨਾਂ ਹੋਵੇਗਾ ਜੋ ਮਿਆਦ ਲੰਘਣ 'ਤੇ ਇਸਨੂੰ ਸੰਭਾਲ ਲਵੇਗਾ।
ਜਦ ਫਾਇਨੈਂਸ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਬੇਨਤੀ Completed ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਬਾਅਦ ਵਿੱਚ ਖਰੀਦ ਦੀ ਵੱਖਰੀ ਕਦਮ ਚਾਹੁੰਦੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਉਹ ਵੱਖਰਾ ਜੋੜ ਸਕਦੇ ਹੋ। ਪਹਿਲੀ ਸੰਸਕਰਨ ਸਧਾਰਣ ਹੀ ਰਹੇ।
ਸਭ ਤੋਂ ਵੱਡੀ ਗਲਤੀ ਈਮੇਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਹਦੀ ਹੀ ਅਵਲ-ਇਨ-ਪਲੱਸ ਸਿਸਟਮ ਵਿੱਚ ਨਕਲ ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ ਤੇ ਇਹ ਪੁਰਾਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਨਵੇਂ ਸਿਸਟਮ ਵਿੱਚ ਲਾਕ ਕਰ ਦਿੰਦਾ ਹੈ।
ਈਮੇਲ ਨਿੱਕੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ। ਲੋਕ ਸਿੱਡੇ ਧਾਗਿਆਂ ਵਿੱਚ ਚੀਜ਼ਾਂ ਸਮਝਾਉਂਦੇ ਹਨ, ਅਪਡੇਟ ਲੱਭਣ ਲਈ ਮੈਨੂੰਉਲ ਤਰੀਕੇ ਵਰਤਦੇ ਹਨ ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਬਿਨਾਂ ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਦੇ ਮਨਜ਼ੂਰ ਕਰ ਲੈਂਦੇ ਹਨ। ਜੇ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਬਿਨਾਂ ਤਬਦੀਲੀ ਦੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਤਾਂ ਗੜਬੜ ਦੂਰ ਨਹੀਂ ਹੁੰਦੀ — ਇਹ ਸਿਰਫ਼ ਵੱਖਰੀ ਥਾਂ ਤੇ ਦਿੱਖੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਹੋਰ ਆਮ ਗਲਤੀ ਜਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਸਥਾਰ ਜੋੜਣਾ ਹੈ। ਟੀਮਾਂ ਲੰਬੀ ਸਟੇਟਸ ਸੂਚੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਹਰ ਛੋਟੇ ਕਦਮ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਚਾਹੁੰਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ ਇਹ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪਾਲਣਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਜੇ ਇੱਕ ਬੇਨਤੀ ਨੂੰ pending review, under review, waiting for comments, sent back, resubmitted ਅਤੇ ready for sign-off ਵਰਗੇ ਬਹੁਤ ਸਾਰੇ ਲੇਬਲ ਮਿਲ ਜਾਂ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਿਹੜਾ ਲੇਬਲ ਵਰਤਣਾ ਹੈ।
ਉਹੀ ਗੱਲ APPROVERS ਲਈ ਵੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਪੰਜ ਲੋਕ ਸਿਰਫ਼ ਸੰਭਵ ਹੈਸ ਲਈ ਜੋੜ ਦਿੱਤੇ ਜਾਣ, ਤਾਂ ਕੰਮ ਸੁਸਤ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਨੂੰ ਪੂਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਮਹਿਸੂਸ ਨਹੀਂ ਹੁੰਦੀ।
ਕੁਝ ਚਿੱਤਾਵਨੀ ਨਿਸ਼ਾਨੀ ਲੱਭੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:
ਟੀਮਾਂ ਵੀ ਰੀਮਾਈੰਡਰ ਅਤੇ ਐਸਕਲੇਸ਼ਨ ਨੂੰ ਬੁਨਿਆਦੀ ਨਿਯਮਾਂ ਦੇ ਪੱਕੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿੰਦੇ ਹਨ। ਰੀਮਾਈੰਡਰ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮਦਦਦੇ ਹਨ ਜਦੋਂ ਸਿਸਟਮ ਪਹਿਲਾਂ ਜਾਣਦਾ ਹੋਵੇ ਕਿ ਕਿਸਨੂੰ ਦੇਰ ਹੋ ਰਹੀ ਹੈ, ਕੌਣ ਦੇਰ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਅੱਗੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ ਨਿਯਮ ਧੁੰਦਲੇ ਹਨ, ਤਾਂ ਰੀਮਾਈੰਡਰ ਹੋਰ ਸ਼ੋਰ ਹੀ ਬਣ ਜਾਂਦੇ ਹਨ।
ਹੋਰ ਇੱਕ ਗਲਤੀ ਹੈ ਛੂਟਾਂ ਨੂੰ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ। ਅਸਲ ਮਨਜ਼ੂਰੀ ਚੇਨ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਛੂਟ ਹੁੰਦੀਆਂ ਹਨ। ਕੋਈ ਗੈਰਹਾਜ਼ਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਬੇਨਤੀ urgent ਹੋ ਜਾਂਦੀ ਹੈ। ਫਾਰਮ ਅਧੂਰਾ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਰੱਦ ਕੀਤੀ ਚੀਜ਼ ਮੁੜ ਸੋਧ ਕੇ ਆਉਂਦੀ ਹੈ। ਜੇ ਇਹ ਸਥਿਤੀਆਂ ਪਹਿਲਾਂ ਨਿਯਤ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਤਾਂ ਲੋਕ ਪਹਿਲਾ ਅਜਿਹੇ ਵਕਤ ਉੱਤੇ ਈਮੇਲ ਵੱਲ ਮੁੜ ਜਾ ਰਹੇ ਹੋਣਗੇ।
ਦਿਨ ਇਕ ਤੇ ਸਧਾਰਨ, ਪੂਰਾ ਨਹੀਂ — ਇਹ ਸ਼ੁਰੂਆਤ ਲਈ ਵਧੀਆ ਨੀਤੀ ਹੈ। ਕਮਜ਼ੋਰ ਕਦਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ, ਸਟੇਟਸ ਘੱਟ ਰੱਖੋ, ਹਰ ਕਦਮ ਨੂੰ ਇੱਕ ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰੋ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਛੂਟਾਂ ਦੇ ਨਿਯਮ ਤੈਅ ਕਰੋ।
ਰਾਊਟਿੰਗ ਨਿਯਮ, ਰੀਮਾਈੰਡਰ ਜਾਂ ਐਸਕਲੇਸ਼ਨ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖੋ ਕਿ ਪ੍ਰਕਿਰਿਆ ਇੰਨੀ ਸਪਸ਼ਟ ਹੈ ਕਿ ਈਮੇਲ ਤੋਂ ਬਿਨਾਂ ਵੀ ਕੰਮ ਕਰ ਸਕੇ।
ਇੱਕ ਉਪਯੋਗੀ ਟੈਸਟ ਸਧਾਰਨ ਹੈ: ਕੀ ਇੱਕ ਮਿਆਰੀ ਬੇਨਤੀ ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਇੱਕ ਸਪਸ਼ਟ ਰਾਹ ਰਾਹੀ ਅਰੰਭ ਤੋਂ ਅੰਤ ਤੱਕ ਚੱਲ ਸਕਦੀ ਹੈ? ਜੇ ਨਹੀਂ, ਤਾਂ ਪਹਿਲਾਂ ਰਾਹ ਠੀਕ ਕਰੋ।
ਇਹ ਸਵਾਲ ਚਲਾਓ:
ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦੇ ਸਪਸ਼ਟ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਰੁਕ ਜਾਓ। ਸਾਫ਼ ਲੇਬਲ, ਸਪਸ਼ਟ ਮਾਲਕੀ ਅਤੇ ਲਿਖਤ ਛੂਟ ਦੇ ਨਿਯਮ ਹੋਰ ਕਲਿਕ ਅਤੇ ਉੱਤਮ ਆਟੋਮੇਸ਼ਨ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਬਚਾਉਂਦੇ ਹਨ।
ਇਸੀ ਲਈ ਬਹੁਤ ਸਾਰੀ ਟੀਮਾਂ ਸਧਾਰਨ ਡੌਕ ਜਾਂ ਵ੍ਹਾਈਟਬੋਰਡ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਦਾ ਖਾਕਾ ਬਣਾਉਂਦੀਆਂ ਹਨ ਪਹਿਲਾਂ। ਜੇ ਤੁਸੀਂ ਇਕ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਐਪ बना ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਇੱਕ ਵਰਤਣਯੋਗ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ Plain-language ਵਰਕਫਲੋ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਬਦਲਣ ਲਈ ਬਿਨਾਂ ਲੰਬੇ ਵਿਕਾਸ ਚੱਕਰ ਦੇ।
ਨਵੇਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰੇ ਕੰਪਨੀ ਵਿੱਚ ਇਕੱਠੇ ਰੋਲ ਆਉਟ ਨਾ ਕਰੋ। ਇੱਕ ਟੀਮ ਅਤੇ ਇੱਕ ਬੇਨਤੀ ਕਿਸਮ ਵਰਗਾ ਪਾਇਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਜਿਵੇਂ ਖਰੀਦ ਮਨਜ਼ੂਰੀਆਂ ਜਾਂ ਸਮੱਗਰੀ ਸਾਈਨ-ਆਫ। ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੈਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲਾਉਣ ਵਿੱਚ ਆਸਾਨੀ ਕਰਦਾ ਹੈ।
ਇਹੀ ਥਾਂ ਹੈ ਜਿਥੇ ਮੈਨੁਅਲ ਮਨਜ਼ੂਰੀ ਵਰਕਫਲੋ ਸਾਫਟਵੇਅਰ ਭਰੋਸਾ ਕਮਾਉਂਦਾ ਜਾਂ ਰੁਕਾਵਟ पैदा ਕਰਦਾ ਹੈ। ਜੇ ਲੋਕ ਹੱਕੀਕਤੀ ਬੇਨਤੀਆਂ ਈਮੇਲ ਨਾਲੋਂ ਘੱਟ ਗੜਬੜੀ ਨਾਲ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਅਪਣਾਉਣ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਐਸਾ ਫਲੋ ਚੁਣੋ ਜੋ ਪ੍ਰਯੋਗ ਲਈ ਕਾਫ਼ੀ ਵਾਰ ਹੁੰਦਾ ਹੋਵੇ, ਪਰ ਜ਼ਿਆਦਾ ਖ਼ਤਰਨਾਕ ਨਾ ਹੋਵੇ ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ ਇਸਨੂੰ ਬਦਲਣਾ ਪਏ। ਪਾਇਲਟ ਗਰੁੱਪ ਨੂੰ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਲਕਸ਼ਮਣ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ ਹੈ — ਲਕਸ਼ਮਣ ਇਹ ਹੈ ਕਿ ਜਦ ਪ੍ਰਕਿਰਿਆ ਛੋਟੀ ਹੈ ਤਾਂ ਅਣਚਾਹੇ ਹਿੱਸੇ ਲੱਭੇ ਜਾਣ।
ਪਾਇਲਟ ਦੌਰਾਨ ਦੇਖੋ ਕਿ ਲੋਕ ਕਿੱਥੇ ਸਿਸਟਮ ਛੱਡ ਕੇ ਹੱਥੋਂ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਇਹ ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਡਾ ਸੂਚਕ ਹੁੰਦਾ ਹੈ ਕਿ ਕੁਝ ਗੁੰਮ ਹੈ।
ਧਿਆਨ ਦਿਓ:
ਪਹਿਲੀਆਂ ਕੁਝ ਅਸਲ ਕੇਸਾਂ ਤੋਂ ਬਾਅਦ, ਵਧੀਆਂ ਫੀਚਰਾਂ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਮੂਲ ਗੱਲਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੋ। ਅਣਸਪਸ਼ਟ ਹੈਂਡਆਫ ਠੀਕ ਕਰੋ, ਸਟੇਟਸ ਦੇ ਨਾਮ ਸਧਾਰਨ ਕਰੋ ਅਤੇ ਡੈਡਲਾਈਨ ਅਸਲ ਕੰਮ ਅਨੁਸਾਰ ਢਾਲੋ। ਰਿਪੋਰਟਾਂ, ਐਸਕਲੇਸ਼ਨਾਂ ਅਤੇ ਵਾਧੂ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਉਸ ਸਮੇਂ ਤੱਕ ਰੱਖੋ ਜਦੋਂ ਕੋਰ ਫਲੋ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੇ।
ਸਧਾਰਨ ਸਮੀਖਿਆ ਚੱਕਰ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ। ਪਹਿਲੇ 5–10 ਬੇਨਤੀਆਂ ਦੇ ਬਾਅਦ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚੈੱਕ ਕਰੋ, ਫਿਰ ਦੋ ਹਫ਼ਤੇ ਬਾਅਦ ਫੇਰ। ਇੱਕ ਸਧਾਰਣ ਸਵਾਲ ਪੁੱਛੋ: ਲੋਕਾਂ ਨੂੰ ਹੁਣ ਵੀ ਕਿੱਥੇ ਇਕ ਵਰਕਅਰਾਊਂਡ ਦੀ ਲੋੜ ਪਈ?
ਜੇ ਤੁਸੀਂ ਇਕ ਅੰਦਰੂਨੀ ਮਨਜ਼ੂਰੀ ਟੂਲ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਟੈਸਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai Plain-language ਵਰਕਫਲੋ ਨੂੰ chat ਤੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਕੇ ਵਰਕਿੰਗ ਐਪ ਵਿੱਚ ਬਦਲਣ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਅਕਸਰ ਵੱਡੇ ਰੋਲ ਆਉਟ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੋਲ-ਆਉਟ ਅਕਸਰ ਉਦੇਸ਼ਾਂ ਅਨੁਸਾਰ ਆਮ ਅਤੇ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ। ਇਹ ਚੰਗੀ ਨਿਸ਼ਾਨੀ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ, ਕੌਣ ਮਾਲਕ ਹੈ ਅਤੇ ਜਦ ਕੁਝ ਆਮ ਰਾਹ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਖਾਂਦਾ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ।
ਜਦੋਂ ਮਨਜ਼ੂਰੀਆਂ ਵਿੱਚ ਇੱਕ ਜਾਂ ਦੋ ਲੋਕਾਂ ਤੋਂ ਵੱਧ ਸ਼ਾਮਲ ਹੋ ਜਾਣ ਜਾਂ ਡੈਡਲਾਈਨ ਮੁਹੱਤਵਪੂਰਨ ਹੋਣ ਜਾਂ ਬਾਰ-ਬਾਰ ਫਾਲੋ-ਅਪ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਦ ਈਮੇਲ ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਰਹਿੰਦਾ। ਜੇ ਲੋਕ ਅਜੇ ਵੀ ਸਥਿਤੀ ਪੁੱਛ ਰਹੇ ਹਨ, ਗਲਤ ਵਰਜ਼ਨ ਮਨਜ਼ੂਰ ਹੋ ਰਿਹਾ ਹੈ, ਜਾਂ ਬੇਨਤੀ ਇਨਬਾਕਸ ਵਿੱਚ ਗੁੰਮ ਹੋ ਰਹੀ ਹੈ, ਤਾਂ ਈਮੇਲ ਸਮਾਂ ਅਤੇ ਖ਼ਤਰੇ ਦੀ ਕੀਮਤ ਵਧਾ ਰਿਹਾ ਹੈ।
ਅੱਜ ਜਿੰਨੀ ਤਰ੍ਹਾਂ ਪ੍ਰਕਿਰਿਆ ਚੱਲਦੀ ਹੈ, ਉਸਦਾ ਨਕਸ਼ਾ ਬਣਾਓ। ਕੁਝ ਹਾਲੀਆ ਈਮੇਲ ਥ੍ਰੈਡ ਵੇਖੋ ਅਤੇ ਲਿਖੋ ਕਿ ਬੇਨਤੀ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਕੌਣ ਇਸ ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ, ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੈ, ਕਿੱਥੇ ਲੂਪ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਇਸ ਨਾਲ ਤੁਸੀਂ ਨਵੇਂ ਟੂਲ ਵਿੱਚ ਇਨਬਾਕਸ ਦੀ ਗੜਬੜ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ ਸਾਫ਼ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਂਦੇ ਹੋ।
ਛੋਟੇ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕ ਇਕ ਨਜ਼ਰ ਵਿੱਚ ਸਮਝ ਲੈਣ। ਬਹੁਤ ਵਾਰ 4–5 ਸਟੇਟਸ ਹੀ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ Draft, Waiting for approval, Approved, Rejected, ਅਤੇ Needs changes. ਜੇ ਦੋ ਲੇਬਲ ਲੱਗਦੇ ਹੀ ਇੱਕੋ ਵਰਗੇ ਹਨ, ਤਾਂ ਇੱਕ ਹਟਾ ਦਿਓ।
ਆਮ ਤੌਰ ਤੇ ਨਹੀਂ। ਸਟੇਟਸ ਨੂੰ ਬੇਨਤੀ ਦੀ ਸਥਿਤੀ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਕੌਣ ਕੋਲ ਹੈ। Waiting for approval ਵਰਗਾ ਲੇਬਲ With finance ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪਹਿਲਾ ਲੇਬਲ ਸਥਿਤੀ ਦੱਸਦਾ ਹੈ, ਨਾ ਕਿ ਮੌਜੂਦਾ ਸਮੀਖਿਆਕਾਰ।
ਹਰ ਕਦਮ ਲਈ ਇੱਕ ਸਾਫ਼ ਮਾਲਕ ਅਤੇ ਇੱਕ ਬੈਕਅਪ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਜੇ ਮੁੱਖ ਮਨਜ਼ੂਰ ਕਰਨ ਵਾਲਾ ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ ਤਾਂ ਬੈਕਅਪ ਇਕ ਸੀਧੀ ਨਿਯਮ ਅਨੁਸਾਰ ਕੰਮ ਸੌਂਪ ਦੇਵੇ — ਉਦਾਹਰਨ ਵਜੋਂ ਇੱਕ ਕਾਰੋਬਾਰੀ ਦਿਨ ਤੋਂ ਬਾਦ। ਇਹ ਬੇਨਤੀਆਂ ਨੂੰ ਰੁੱਕਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਹਰ ਪੜਾਅ ਲਈ ਅਲੱਗ ਡਿਊ ਡੇਟ ਰੱਖੋ — ਇੱਕ ਹੀ ਡੈਡਲਾਈਨ ਸਾਰੀ ਬੇਨਤੀ ਲਈ ਨਹੀਂ। ਘਰੈਬੰਦ ਵਿੱਚ, ਟਾਈਮਰ ਉਸ ਵੇਲੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਉਸ ਸਟੇਟਸ ਵਿੱਚ ਆਏ। ਜੇ ਡੈਡਲਾਈਨ ਲੰਘ ਜਾਵੇ ਤਾਂ ਪਹਿਲਾਂ ਇੱਕ ਰੀਮਾਈੰਡਰ, ਫਿਰ ਬੈਕਅਪ ਜਾਂ ਟੀਮ ਲੀਡ ਨੂੰ ਐਸਕਲੇਟ ਕਰਨ ਵਰਗਾ ਸਪਸ਼ਟ ਕੰਮ ਨਿਰਧਾਰਿਤ ਕਰੋ।
ਉਨਾਂ ਨੂੰ ਵਾਪਸ ਵਾਰਕਫਲੋ 'ਚ ਭੇਜੋ ਇੱਕ ਸਪਸ਼ਟ ਸਟੇਟਸ ਨਾਲ ਜਿਵੇਂ Needs more info ਜਾਂ Waiting for requester। ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਮੁੜ ਐਕਟਿਵ ਮਾਲਕ ਬਣੇ ਅਤੇ ਟਾਈਮਰ ਰੁਕ ਜਾਵੇ ਜਦ ਤੱਕ ਗੁਆਚੀ ਜਾਣਕਾਰੀ ਨਹੀਂ ਮਿਲਦੀ। ਇਹ ਸਾਈਡ ਈਮੇਲ ਦੇ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਤੋਂ ਵਧੀਆ ਹੈ।
ਨਹੀਂ — ਐਜੰਟ ਨੂੰ ਇਕ ਵੱਖਰਾ ਪਰ ਛੋਟਾ ਰਾਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਯਾਦ ਰੱਖੋ ਕਿ ਜੇ ਹਰ ਚੀਜ਼ urgent ਚਿੰਨ੍ਹਤ ਕੀਤੀ ਜਾ ਸਕੇ ਤਾਂ ਇਹ ਲੇਬਲ ਬੇਕਾਰ ਹੋ ਜਾਵੇਗਾ। ਸਿਰਫ਼ ਕੁਝ ਸਪਸ਼ਟ ਮਾਮਲੇ, ਜਿਵੇਂ ਗਾਹਕ ਪ੍ਰਭਾਵ ਜਾਂ ਕੰਪਲਾਇੰਸ ਡੈਡਲਾਈਨ, ਹੀ ਇਸ ਰਾਹ ਲਈ ਯੋਗ ਹੋਣ।
ਸਭ ਤੋਂ ਵੱਡੀ ਗਲਤੀ ਹੀ ਇਹ ਹੈ ਕਿ ਈਮੇਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਜਿਹਾ ਹੀ ਨਵੇਂ ਸਿਸਟਮ ਵਿੱਚ ਨਕਲ ਕਰ ਦੇਣਾ। ਹੋਰ ਆਮ ਗਲਤੀਆਂ: ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਟੇਟਸ, ਬਹੁਤ ਸਾਰੇ APPROVERS, ਸਪਸ਼ਟ ਮਾਲਕੀ ਨਾ ਹੋਣਾ ਅਤੇ uitzondering ਨੀਤੀਆਂ ਜੋ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਪਹਿਲੇ ਦਿਨ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਕਮਜ਼ੋਰ ਕਦਮਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।
ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚਲਾਓ — ਇੱਕ ਟੀਮ ਅਤੇ ਇੱਕ ਬੇਨਤੀ ਕਿਸਮ ਨਾਲ। ਇਸ ਤਰ੍ਹਾਂ ਮੁਸੀਬਤਾਂ ਫੈਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦੇਣਗੀਆਂ। ਮਕਸਦ ਹੀ ਨਹੀਂ ਹੋਣਾ ਕਿ ਪਹਿਲੇ ਦਿਨ ਸਭ ਕੁਝ ਪੂਰਾ ਹੋ ਜਾਵੇ; ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਛੋਟੀ ਹੋਵੇ ਤਾਂ ਅਣਛੁਏ ਸਮੱਸਿਆਵਾਂ ਮਿਲ ਜਾਣ।
