AI ਐਪਾਂ ਲਈ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ

ਕਿਉਂ ਅਸਪੱਸ਼ਟ ਨਿਯਮ ਅਣਭਰੋਸੇਯੋਗ ਐਪ ਬਣਾਉਂਦੇ ਹਨ

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

ਜੇ ਇਹ ਨਿਯਮ ਧੁੰਦਲੇ ਹੋਣ, ਐਪ ਨੂੰ ਫਿਰ ਵੀ ਇੱਕ ਰਾਹ ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ। ਸਿਰਫ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਇਹ ਉਹੀ ਰਾਹ ਨਹੀਂ ਲਏਗਾ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਸੀ।

ਉਦਾਹਰਨ ਲਈ ਨਿਯਮ ਲਓ: "ਵੱਡੇ ਖਰਚੇ ਮੈਨੇਜਰ ਦੀ ਮਨਜ਼ੂਰੀ ਲੋੜਦੇ ਹਨ।" ਇੱਕ ਵਿਅਕਤੀ ਸੋਚ ਸਕਦਾ ਹੈ ਇਹ ਸਪੱਸ਼ਟ ਲੱਗਦਾ ਹੈ। ਇੱਕ ਬਣਾਉਣ ਵਾਲਾ (builder) ਨਹੀਂ। ਵੱਡਾ ਕੀ ਹੈ: $500, $5,000 ਜਾਂ ਟੀਮ ਬਜਟ ਤੋਂ ਉੱਪਰ ਦੀ ਕੋਈ ਵੀ ਰਕਮ? ਕਿਸ ਮੈਨੇਜਰ: ਡਾਇਰੈਕਟ ਮੈਨੇਜਰ, ਡਿਪਾਰਟਮੈਂਟ ਹੈਡ ਜਾਂ ਫਾਇਨੈਂਸ? ਜੇ ਕਿਸੇ ਨੇ 2 ਦਿਨ ਵਿੱਚ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਬੇਨਤੀ ਰੁਕੀ ਰਹੇਗੀ, ਖਤਮ ਹੋ ਜਾਵੇਗੀ ਜਾਂ ਕਿਸੇ ਹੋਰ ਕੋਲ ਚਲੀ ਜਾਵੇਗੀ?

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

ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਖੇਤਰਾਂ ਵਿੱਚ ਦਰਸਤੀ ਹਨ:

• ਗਣਨਾਵਾਂ ਜਿਹੜੀਆਂ ਵਿਵਰਣ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਗੋਲਾਈ, ਟੈਕਸ, ਛੂਟ ਜਾਂ ਤਾਰੀਖ-ਸੀਮਾਵਾਂ
• ਐਕਸਪਸ਼ਨਾਂ ਜੋ ਹਰ ਕੋਈ ਮੰਨ ਲੈਂਦਾ ਹੈ ਪਰ ਕਿਸੇ ਨੇ ਲਿਖੀਆਂ ਨਹੀਂ
• ਅਪ੍ਰੂਵਲ ਕਦਮ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਕੋਈ ਨਿਯਤ ਮਾਲਕ, ਕ੍ਰਮ ਜਾਂ ਬੈਕਅਪ ਨਹੀਂ

ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ ਸਮੱਸਿਆ ਦਿਖਾਂਦੀ ਹੈ। ਇੱਕ ਫਾਉਂਡਰ ਇੱਕ ਅੰਦਰੂਨੀ ਖਰਚਾ ਐਪ Koder.ai ਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਲਿਖਦਾ ਹੈ, "ਯਾਤਰਾ ਖਰਚੇ ਵਾਪਸ ਕੀਤੇ ਜਾਣਗੇ ਜਦ ਤੱਕ ਉਹ ਅਨੌਖੇ ਨਹੀਂ ਲੱਗਦੇ।" ਇਹ ਸੁਣਨ ਵਿੱਚ ਵਾਜ਼ਬ ਲੱਗਦਾ ਹੈ, ਪਰ ਐਪ ਕੋਲ ਇਹ ਅਨੋਖਾ ਬੇਹਤਰ ਜਾਣਚਣ ਦਾ ਕੋਈ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਇੱਕ ਕਰਮਚਾਰੀ ਦੀ ਟੈਕਸੀ ਮਨਜ਼ੂਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਹੋਰ ਇਕ ਨਾਲ-ਬਣਦੇ ਬਿਲ ਰੋਕ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿਉਂ।

ਭਰੋਸੇਯੋਗ ਵਿਹਾਰ ਉਹ ਨਿਯਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਹਰ ਵਾਰੀ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਪਾਲਨਾ ਕੀਤੀ ਜਾ ਸਕੇ। "ਵੱਡਾ", "ਤੁਰੰਤ" ਅਤੇ "ਖਾਸ ਕੇਸ" ਵਰਗੇ ਸ਼ਬਦਾਂ ਨੂੰ ਇਨ੍ਹਾ ਸਥਾਨਾਂ, ਸ਼ਰਤਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਨਾਲ ਬਦਲੋ ਜਿਹੜੇ ਸਟੀਕ ਹੋਣ। ਜੇ ਦੋ ਵੱਖ-ਵੱਖ ਲੋਕ ਉਹੀ ਨਿਯਮ ਇੱਕੋ ਜਿਹਾ ਲਗਾਉਂਦੇ ਹਨ, ਤਾਂ ਐਪ ਵੀ ਜ਼ਿਆਦਾ ਇੱਕਸਾਰ ਨਤੀਜੇ ਦੇਵੇਗਾ।

ਇੱਕ ਸਪੱਸ਼ਟ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ

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

ਇੱਕ ਵਧੀਆ ਨਿਯਮ ਉਚਾਰਨ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਟੀਮ ਤੋਂ ਬਾਹਰ ਵਾਲਾ ਕੋਈ ਵਿਅਕਤੀ ਇਸਨੂੰ ਤੁਹਾਡੀ ਅੰਦਰੂਨੀ ਸ਼ਾਰਟਹੈਂਡ ਬਗੈਰ ਸਮਝ ਸਕੇ। "ਫਾਸਟ-ਟ੍ਰੈਕ", "ਸਟੈਂਡਰਡ ਕੇਸ" ਜਾਂ "ਮੈਨੇਜਰ ਸਾਇਨ-ਆਫ" ਵਰਗੇ ਸ਼ਬਦਾਂ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਨਾਲ ਬਦਲੋ ਜੋ ਠੀਕ ਦੱਸੇ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਸਪੱਸ਼ਟ ਨਿਯਮ ਚਾਰ ਮੂਲ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ:

• ਕੌਣ ਫੈਸਲਾ ਕਰਦਾ ਜਾਂ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ?
• ਨਿਯਮ ਕਦੋਂ lagu ਹੁੰਦਾ ਹੈ?
• ਐਪ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ?
• ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ?

ਇਹ ਢਾਂਚਾ ਨਿਯਮ ਨੂੰ ਅਸਲ ਵਿਹਾਰ ਨਾਲ ਜੋੜਦਾ ਹੈ। "ਵੱਡੇ ਆਰਡਰਾਂ ਨੂੰ ਰਿਵਿਊ ਦੀ ਲੋੜ ਹੈ" ਲਿਖਣ ਦੇ ਬਦਲੇ, ਲਿਖੋ: "ਜੇ ਆਰਡਰ $5,000 ਤੋਂ ਉੱਪਰ ਹੈ, ਤਾਂ ਸੇਲਜ਼ ਮੈਨੇਜਰ ਨੂੰ ਇਸਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਲਾਜ਼ਮੀ ਹੈ।" ਇੱਕ ਵਾਕ, ਇੱਕ ਫੈਸਲਾ, ਇੱਕ ਨਤੀਜਾ।

ਇਕੋ ਸਬੰਧਤ ਨਿਯਮਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਵੀ ਮਦਦਗਾਰ ਹੈ। ਅਪ੍ਰੂਵਲ ਨਿਯਮ ਆਪਣਾ ਖ਼ੁਦ ਦਾ ਹੋਵੇ। ਈਮੇਲ ਭੇਜਣ ਦਾ ਨਿਯਮ ਵੱਖਰਾ ਹੋਵੇ। ਸ਼ਿਪਮੈਂਟ ਰੋਕਣ ਦਾ ਨਿਯਮ ਵੀ ਵੱਖਰਾ ਹੋਵੇ। ਇਸ ਨਾਲ ਹਰ ਨਿਯਮ ਟੈਸਟ, ਅਪਡੇਟ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

ਫਰਕ ਆਸਾਨੀ ਨਾਲ ਦੇਖਣ ਯੋਗ ਹੈ:

"ਪ੍ਰੀਮੀਅਮ ਗ੍ਰਾਹਕਾਂ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਸੇਵਾ ਮਿਲਦੀ ਹੈ" ਧੁੰਦਲਾ ਹੈ।

"ਜੇ ਗ੍ਰਾਹਕ ਕੋਲ ਪ੍ਰੀਮੀਅਮ ਪਲਾਨ ਹੈ, ਤਾਂ ਟਿਕਟ ਬਣਦੇ ਸਮੇਂ ਸਪੋਰਟ ਰਿਕਵੇਸਟ ਨੂੰ High Priority ਵਜੋਂ ਨਿਸ਼ਾਨ ਲਾਇਆ ਜਾਵੇ" ਸਪੱਸ਼ਟ ਹੈ।

ਦੂਜਾ ਵਰਜਨ ਟ੍ਰਿਗਰ, ਸ਼ਰਤ ਅਤੇ ਐਪ ਅੰਦਰ ਬਦਲਾਅ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਇਹ ਬਣਾਉਣ ਵਾਲੇ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਭਰੋਸੇਯੋਗ ਵਿਹਾਰ ਕਿਵੇਂ ਦਿਸਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਐਸੀ ਭਾਸ਼ਾ ਬਹੁਤ ਫਰਕ ਪਾਉਂਦੀ ਹੈ। ਸਪੱਸ਼ਟ ਨਿਯਮਾਂ ਨੂੰ ਕਾਨੂੰਨੀ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਨਹੀਂ; ਉਹਨਾਂ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ, ਇਕ ਸਮੇਂ ਇਕ خیال ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਆਉਣ ਵਾਲਾ ਉਮੀਦਯੋਗ ਨਤੀਜਾ ਚਾਹੀਦਾ ਹੈ।

ਗਣਨਾਵਾਂ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਣਾ

ਗਣਨਾਵਾਂ ਅਕਸਰ ਸਧਾਰਨ ਲੱਗਦੀਆਂ ਹਨ ਜੀਸ ਵੇلے ਕਿਸੇ ਨੇ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਤਾਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਤਨੀ ਵਿਵਰਣ ਦੀ ਲੋੜ ਹੈ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਧਾਰਨ ਵਾਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਪੱਸ਼ਟ ਤਾਂਰ ਤੇ ਦੱਸੇ ਕਿ ਐਪ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ।

ਇੱਕ ਵਧੀਆ ਨਿਯਮ ਇਹੇ ਲਗਦਾ ਹੈ: "ਰੀਇੰਬਰਸਮੈਂਟ ਦੀ ਰਕਮ ਮਨਜ਼ੂਰ ਕੀਤੇ ਗਏ ਮੀਲਾਂ × ਮਾਈਲੇਜ ਰੇਟ ਦੇ ਬਰਾਬਰ ਹੋਵੇਗੀ।" ਇਹ "ਯਾਤਰਾ ਭੁਗਤਾਨ ਨਿਕਾਲੋ" ਜਾਂ "ਸਟੈਂਡਰਡ ਰੀਇੰਬਰਸਮੈਂਟ ਲਗਾਓ" ਤੋਂ ਕਾਫ਼ੀ ਸਪੱਸ਼ਟ ਹੈ।

ਉਸ ਪਹਿਲੇ ਵਾਕ ਤੋਂ ਬਾਅਦ, ਹਰ ਇਨਪੁਟ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿਓ ਜੋ ਐਪ ਵਰਤੇਗਾ। ਇੰਨਾ ਵਕਤਾਂ ਜ਼ਿਆਦਾ ਵਿਆਖਿਆ ਕੇ ਬਿਨਾਂ ਕਣੀ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਨਾ ਪਏ।

ਹਰ ਗਣਨਾ ਲਈ ਕੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਲੋੜੀਦਾ ਹੈ

ਹਰ ਗਣਨਾ ਲਈ, ਲਿਖੋ:

• ਇਨਪੁਟ, ਸਧਾਰਨ ਨਾਮ ਅਤੇ ਯੂਨਿਟਾਂ ਦੇ ਨਾਲ
• ਹਰ ਦਰਸ਼ਤ ਕੀਥੋਂ ਆਉਂਦਾ ਹੈ
• ਗੋਲਾਈ ਦੇ ਨਿਯਮ
• ਕੋਈ ਘੱਟਤਮ ਜਾਂ ਵੱਧਤਮ ਰਕਮ
• ਜੇ ਕੋਈ ਮੁੱਲ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਛੋਟੇ ਵੇਰਵੇ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। "ਅਖੀਰੀ ਰਕਮ ਨੂੰ 2 ਦਸ਼ਮਲਵ ਸਥਾਨਾਂ ਤੱਕ ਗੋਲ ਕਰੋ" ਨਤੀਜਾ ਵੱਖਰਾ ਦਿੰਦਾ ਹੈ ਬਜਾਏ ਹਰ ਲਾਈਨ ਆਈਟਮ ਨੂੰ ਪਹਿਲਾਂ ਗੋਲ ਕਰਨ ਦੇ। ਜੇ ਇੱਕ ਕੈਪ ਹੈ, ਤਾਂ ਦੱਸੋ ਕਿ ਐਪ ਉਸ ਕੈਪ 'ਤੇ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਚੇਤਾਵਨੀ ਦਿਖਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਨਿਯਮ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ: "ਯਾਤਰਾ ਰੀਇੰਬਰਸਮੈਂਟ = ਮਨਜ਼ੂਰ ਕੀਤੇ ਗਏ ਮੀਲ × $0.67। ਅਖੀਰੀ ਰਕਮ ਨੂੰ 2 ਦਸ਼ਮਲਵ ਸਥਾਨ ਤੱਕ ਗੋਲ ਕਰੋ। ਪ੍ਰਤੀ ਟ੍ਰਿਪ ਵੱਧ ਤੋਂ ਵੱਧ ਰੀਇੰਬਰਸਮੈਂਟ $300 ਹੈ। ਜੇ ਮਨਜ਼ੂਰ ਕੀਤੇ ਗਏ ਮੀਲ ਖਾਲੀ ਹਨ, ਤਾਂ ਰਕਮ ਦੀ ਗਣਨਾ ਨਾ ਕਰੋ। ਬੇਨਤੀ ਨੂੰ ਅਧੂਰਾ ਨਿਸ਼ਾਨ ਲਗਾਓ ਅਤੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਮੀਲ ਦਰਜ ਕਰਨ ਲਈ ਕਹੋ।"

ਫਿਰ ਇੱਕ ਜਾਂ ਦੋ ਕੰਮ ਕੀਤੇ ਉਦਾਹਰਨਾਂ ਜੋੜੋ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਅਸਲੀ ਅੰਕੜੇ ਹੋਣ। ਉਦਾਹਰਨਾਂ ਥਿਓਰੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਖਾਮੀਆਂ ਬਿਆਨ ਕਰਦੀਆਂ ਹਨ।

ਉਦਾਹਰਨ 1: "ਜੇ ਮਨਜ਼ੂਰ ਮੀਲ 120 ਹੈ, ਰੀਇੰਬਰਸਮੈਂਟ 120 × $0.67 = $80.40 ਹੈ। ਕਿਉਂਕਿ ਇਹ $300 ਕੈਪ ਤੋਂ ਘੱਟ ਹੈ, ਅਖੀਰੀ ਰਕਮ $80.40 ਹੈ।"

ਉਦਾਹਰਨ 2: "ਜੇ ਮਨਜ਼ੂਰ ਮੀਲ 500 ਹੈ, ਰੀਇੰਬਰਸਮੈਂਟ 500 × $0.67 = $335.00 ਹੈ। ਕਿਉਂਕਿ ਵੱਧ ਤੋਂ ਵੱਧ $300 ਹੈ, ਅਖੀਰੀ ਰਕਮ $300.00 ਹੈ।"

ਇਹ ਅੰਦਾਜ਼ਾ ਲੋਕਾਂ ਲਈ ਸਮੀਖਿਆ ਕਰਨਾ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਬਣਾਉਣ ਵਾਲੇ ਲਈ ਐਪ ਵਿਹਾਰ ਵਿੱਚ ਬਦਲਣਾ ਵੀ ਆਸਾਨ ਹੈ।

ਅਸਪਸ਼ਟਤਾ ਬਿਨਾਂ ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਫੜਨਾ

ਜ਼ਿਆਦਾਤਰ ਐਪ ਮੁੱਖ ਨਿਯਮ 'ਤੇ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਐਜ ਕੇਸਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੀ ਹੈ।

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

ਐਕਸਪਸ਼ਨਾਂ ਲਿਖਣ ਦਾ ਇੱਕ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ ਛੋਟੇ if-then ਨਿਯਮ ਵਰਤਣਾ। ਹਰ ਇਕ ਨੂੰ ਇੱਕ ਹਾਲਤ ਅਤੇ ਇੱਕ ਨਤੀਜੇ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ।

• ਜੇ ਖਰਚ $100 ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਆਟੋ-ਅਪ੍ਰੂਵ ਕਰੋ।
• ਜੇ ਖਰਚ $100 ਤੋਂ ਘੱਟ ਹੈ ਪਰ 30 ਦਿਨਾਂ ਤੋਂ ਬਾਅਦ ਦਰਜ ਕੀਤੀ ਗਈ ਹੈ, ਤਾਂ ਮੈਨੁਅਲ ਰਿਵਿਊ ਲਈ ਭੇਜੋ।
• ਜੇ ਕਰਮਚਾਰੀ ਏਗਜ਼ਿਕਿਊਟਿਵ ਟੀਮ ਵਿੱਚ ਹੈ, ਤਾਂ $100 ਸੀਮਾ ਛੱਡੋ ਅਤੇ ਫਾਇਨੈਂਸ ਕੋਲ ਰਸਤੇ ਕਰੋ।
• ਜੇ ਫਾਇਨੈਂਸ ਐਡਮਿਨ ਦਾਅਵੇ ਨੂੰ ਤੁਰੰਤ (urgent) ਮਾਰਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਮੈਨੁਅਲ ਓਵਰਰਾਈਡ ਲਾਗੂ ਹੋਵੇ ਅਤੇ ਦਾਅਵਾ ਕਤਾਰ ਦੇ ਸਿਰੇ 'ਤੇ ਆ ਜਾਵੇ।

ਇਹ ਫ਼ਾਰਮੈਟ ਛੁਪੀ ਹੋਈ ਲੋਜਿਕ ਨੂੰ ਦਿਖਾਵੇਗਾ। ਇਹ ਤੁਹਾਨੂੰ ਓਵਰਲੈਪਾਂ ਨੂੰ ਦੋਸ਼ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਵੇਖਣ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰੇਗਾ।

ਉਹਨਾ ਹੀ-important, ਦੱਸੋ ਕਿ ਜਦੋਂ ਦੋ ਨਿਯਮ ਟਕਰਾਅ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿਹੜਾ ਜਿੱਤਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ: "ਜੇ ਛੁੱਟੀਆਂ (holiday) ਬਲੈਕਆਉਟ ਨਿਯਮ ਗ੍ਰਾਹਕ ਛੂਟ ਨਿਯਮ ਨਾਲ ਟਕਰਾਅ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਲੈਕਆਉਟ ਨਿਯਮ ਜਿੱਤਦਾ ਹੈ।"

ਸੀਮਾਵਾਂ ਬਾਰੇ ਬਹੁਤ ਸਪੱਸ਼ਟ ਹੋਵੋ। ਤਾਰਿੱਖਾਂ, ਯੂਜ਼ਰ ਕਿਸਮਾਂ, ਸਥਾਨ, ਖਾਤਾ ਹਾਲਤ ਅਤੇ ਮੈਨੁਅਲ ਓਵਰਰਾਈਡ ਅਕਸਰ ਨਤੀਜੇ ਬਦਲ ਦਿੰਦੇ ਹਨ। "ਦੇਰੀ ਨਾਲ ਸਬਮਿਟ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਲੋੜੇ" ਦੀ ਬਜਾਏ ਲਿਖੋ: "ਜੇ ਇਕ ਬੇਨਤੀ ਸਮੱਗਮ ਤੋਂ ਬਾਅਦ 14 ਕੈਲੰਡਰ ਦਿਨਾਂ ਵਿੱਚ ਸਬਮਿਟ ਕੀਤੀ ਗਈ ਹੈ, ਤਾਂ ਮੈਨੇਜਰ ਦੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਹੈ।"

ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਹਰ ਐਕਸਪਸ਼ਨ 'ਤੇ ਐਪ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਦਿਖਾਏਗੀ। ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਫੈਸਲੇ 'ਤੇ ਹੀ ਰੁਕਦਾ ਨਹੀਂ। ਇਹ ਸੁਨੇਹਾ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ "Submitted after 14 days. Manager approval required" ਜਾਂ "Manual override applied by finance admin." (ਸੁਨੇਹੇ ਨੂੰ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਦਿਓ)।

ਜਦੋਂ ਐਕਸਪਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੇ ਹੁੰਦੇ ਹਨ, ਤਦ ਅਨੌਖੇ ਕੇਸ ਆਮ ਤੇ ਜਾਂਚਯੋਗ ਵਿਹਾਰ ਬਣ ਜਾਂਦੇ ਹਨ।

ਅਪ੍ਰੂਵਲ ਲੋਜਿਕ ਨੂੰ ਕਦਮ-ਬਾਈ-ਕਦਮ ਵੇਰਵਾ ਕਰਨਾ

ਅਪ੍ਰੂਵਲ ਲੋਜਿਕ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰਤੀਬ وار ਫੈਸਲਿਆਂ ਵਜੋਂ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਧੁੰਦਲੀ ਨੀਤੀ ਵਜੋਂ। ਹਰ ਕਦਮ ਪੱਚੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਕੌਣ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ, ਕਿਸ trigger 'ਤੇ ਉਹ ਰਿਵਿਊ ਕਰੇਗਾ, ਕਿਹੜੀਆਂ ਸੀਮਾਵਾਂ ਲਾਗੂ ਹਨ, ਉਹਨਾਂ ਕੋਲ ਕਿੰਨਾ ਸਮਾਂ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਹ ਫੈਸਲਾ ਲੈਂਦਾ ਹੈ ਤਾਂ ਬੇਨਤੀ ਦੀ ਸਥਿਤੀ ਕੀ ਹੁੰਦੀ ਹੈ।

ਰੋਲ ਦਾ ਨਾਮ ਦੱਸ ਕੇ ਸ਼ੁਰੂ ਕਰੋ, ਸਿਰਫ ਟੀਮ ਨਹੀਂ। "ਫਾਇਨੈਂਸ ਵੱਡੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਰਿਵਿਊ ਕਰਦਾ ਹੈ" ਦੀ ਥਾਂ ਲਿਖੋ: "Finance Manager $5,000 ਤੋਂ ਉੱਪਰ ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਨੂੰ ਮਨਜ਼ੂਰ, ਰੱਦ ਜਾਂ ਵਾਪਸ ਭੇਜ ਸਕਦਾ ਹੈ।" ਇਸ ਨਾਲ ਅਨਿਸ਼ਚਿਤਤਾ ਦੂਰ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਵਰਤਾਰੂ ਬਨਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

ਫਿਰ ਹਰ ਕਦਮ ਲਈ ਟ੍ਰਿਗਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਟ੍ਰਿਗਰ ਉਹ ਸ਼ਰਤ ਹੈ ਜੋ ਬੇਨਤੀ ਨੂੰ ਅੱਗੇ ਭੇਜਦੀ ਹੈ। ਇਹ ਰਕਮ, ਵਿਭਾਗ, ਰਿਸਕ ਲੈਵਲ, ਬੇਨਤੀ ਦੀ ਕਿਸਮ ਜਾਂ ਇਨ੍ਹਾਂ ਦਾ ਮਿਲਾਪ ਹੋ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ:

• ਜੇ ਬੇਨਤੀ $500 ਤੋਂ ਘੱਟ ਹੈ ਤਾਂ ਟੀਮ ਲੀਡ ਇਸਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ।
• ਜੇ ਬੇਨਤੀ $500 ਤੋਂ $5,000 ਦਰਮਿਆਨ ਹੈ ਤਾਂ ਟੀਮ ਲੀਡ ਦੀ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ ਡਿਪਾਰਟਮੈਂਟ ਮੈਨੇਜਰ ਰਿਵਿਊ ਕਰੇਗਾ।
• ਜੇ ਬੇਨਤੀ $5,000 ਤੋਂ ਵੱਧ ਹੈ ਤਾਂ ਡਿਪਾਰਟਮੈਂਟ ਮੈਨੇਜਰ ਦੀ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ ਫਾਇਨੈਂਸ ਰਿਵਿਊ ਕਰੇਗਾ।
• ਜੇ ਬੇਨਤੀ ਨੂੰ High Risk ਮਾਰਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਆਖਰੀ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ compliance ਨੂੰ ਰਿਵਿਊ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।

ਥਰੈਸ਼ਹੋਲਡਾਂ ਨੂੰ ਸਠਿਕ ਸਰਹੱਦਾਂ సహਿਤ ਬਤਾਓ। "ਵੱਡਾ" ਜਾਂ "ਸੰਵੇਦਨਸ਼ੀਲ" ਨਾ ਕਹੋ; ਕਹੋ "$5,000 ਤੋਂ ਉਪਰ", "Sales ਵਿਭਾਗ ਤੋਂ", ਜਾਂ "ਰਿਸਕ ਸਕੋਰ 8 ਜਾਂ ਉਸ ਤੋਂ ਵੱਧ"। ਜੇ ਦੋ thresholds ਇੱਕੋ ਸਮੇਂ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ, ਤਾਂ ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਜਿੱਤੇਗਾ। ਉਦਾਹਰਨ: "High risk ਹਮੇਸ਼ਾਂ compliance ਕੋਲ ਜਾਂਦਾ ਹੈ, ਭਾਵੇਂ ਰਕਮ ਘੱਟ ਹੋਵੇ।"

ਤੁਹਾਨੂੰ ਇੱਕ timeout ਨਿਯਮ ਵੀ ਲੋੜੀਂਦਾ ਹੈ। ਜੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਐਪ ਹਮੇਸ਼ਾਂ ਲਈ ਅਟਕੀ ਨਹੀਂ ਰਹਿ ਸਕਦੀ। ਦੱਸੋ ਕਿ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ 48 ਘੰਟੇ ਜਾਂ 3 ਕਾਰੋਬਾਰੀ ਦਿਨ। ਬੇਨਤੀ ਨੂੰ ਅਪ੍ਰੂਵਲਰ ਦੇ ਮੈਨੇਜਰ ਕੋਲ ਇਤਲਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਬੈਕਅਪ ਅਪ੍ਰੂਵਰ ਨੂੰ ਤੌਰ-ਤਰਤੀਬ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਜਾਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕੈਂਸਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਆਖਿਰਕਾਰ, ਹਰ ਫੈਸਲੇ ਤੋਂ ਬਾਅਦ ਸਥਿਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਲੇਬਲ ਛੋਟੇ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ:

• Approved: ਬੇਨਤੀ ਅੱਗੇ ਵਧਦੀ ਜਾਂ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।
• Rejected: ਬੇਨਤੀ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹੋਰ ਕਾਰਵਾਈ ਨਹੀਂ ਹੁੰਦੀ।
• Sent back: ਬੇਨਤੀਆਰ ਨੂੰ ਸੋਧ ਕਰਕੇ ਮੁੜ ਭੇਜਣਾ ਪਵੇਗਾ।
• Escalated: ਬੇਨਤੀ ਬੈਕਅਪ ਜਾਂ ਉੱਚ ਅਧਿਕਾਰ ਵਾਲੇ ਕੋਲ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।

ਜਦੋਂ ਅਪ੍ਰੂਵਲ ਲੋਜਿਕ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਬਣਾਉਣ ਵਾਲੇ ਕੋਲ ਅੰਦਾਜ਼ਾ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਵਰਕਫਲੋਅ ਕਾਫੀ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਟੈਮਪਲੇਟ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਉਂਦੇ ਰਹਿ ਸਕਦੇ ਹੋ

ਜੇ ਤੁਸੀਂ ਲਗਾਤਾਰ ਵਿਹਾਰ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹਰ ਨਿਯਮ ਨੂੰ ਇਕੋ ਹੀ ਆਕਾਰ ਦਿਓ। ਮਿਲੇ-ਝੁਲੇ ਲਿਖਣ ਦੇ ਅੰਦਾਜ਼ ਅਕਸਰ ਮਿਲੇ-ਝੁਲੇ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਣ ਫਾਰਮੇਟ ਜ਼ਿਆਦਾ ਕੇਸਾਂ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: trigger, conditions, action, result. ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖਣ ਲਈ ਛੋਟਾ ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੇ ਦੁਆਰਾ ਬਾਅਦ ਵਿੱਚ ਸਮੀਖਿਆ ਲਈ ਕਾਫ਼ੀ ਸਪੱਸ਼ਟ ਹੈ।

ਇੱਕ ਨਿਯਮ, ਇੱਕ ਇਕਾਈ ਵਰਤੋਂ

ਹਰ ਨਿਯਮ ਨੂੰ ਆਪਣੀ ਲਾਈਨ, ਕਾਰਡ ਜਾਂ ਬਲਾਕ 'ਤੇ ਰੱਖੋ। ਕਈ ਵਿਚਾਰ ਇੱਕ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਨਾ ਪੈੱਕ ਕਰੋ। ਜੇ ਇੱਕ ਨਿਯਮ ਇੱਕੋ ਵਾਰੀ ਕੀਮਤ ਨਿਰਧਾਰਣ, ਅਪ੍ਰੂਵਲ ਅਤੇ ਐਕਸਪਸ਼ਨ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਟੈਸਟ ਕਰਨ ਲਈ ਔਖਾ ਅਤੇ ਗਲਤ ਪੜ੍ਹਨ ਲਈ ਆਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਟੈਮਪਲੇਟ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

ਤੁਹਾਨੂੰ ਹਰ ਵਾਰ ਹਰ ਫੀਲਡ ਦੀ ਲੋੜ ਨਹੀਂ। ਪਰ ਇਕੋ ਕ੍ਰਮ ਰੱਖਣ ਨਾਲ ਲੋਕ ਨਿਯਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹਨ।

ਉਦਾਹਰਨ ਲਈ:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

ਗੌਰ ਕਰੋ ਕਿ ਉਦਾਹਰਨ ਨਿਯਮ ਦੇ ਹੇਠਾਂ ਹੈ, ਨਿ

ਉਸਦੇ ਅੰਦਰ ਨਹੀਂ। ਇਸ ਨਾਲ ਨਿਯਮ ਸਾਫ਼ ਰਹਿੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਸਿਰਫ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਨਿਯਮ ਕਿਵੇਂ ਵਰਤੋਂ ਵਿੱਚ ਆਏਗਾ।

ਅਨੁਮਾਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਚਿੰਨ੍ਹਾਂ ਕਰੋ ਬਜਾਏ ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਕ ਵਿੱਚ ਛੁਪਾਉਣ ਦੇ। "Assumption" ਜਾਂ "Needs confirmation" ਵਰਗਾ ਇੱਕ ਨੋਟ ਖੁੱਲ੍ਹੇ ਸਵਾਲਾਂ ਨੂੰ ਉਸ ਸਮੇਂ ਪ੍ਰੀ-ਬਿਲਡ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ ਆਪਣੀ ਭਾਸ਼ਾ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ। ਹਮੇਸ਼ਾਂ ਟ੍ਰਿਗਰਾਂ ਨੂੰ "When" ਨਾਲ, ਸ਼ਰਤਾਂ ਨੂੰ "If" ਨਾਲ, ਅਤੇ ਕਾਰਵਾਈਆਂ ਨੂੰ "Then" ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਛੋਟਾ ਪੈਟਰਨ ਗਲਤਫਹਿਮੀਆਂ ਘਟਾਉਂਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਨਿਯਮਾਂ ਨੂੰ ਐਪ ਲੌਜਿਕ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।

ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਭਲੀ-ਭਾਂਤੀ ਕੰਮ ਕਰਦਾ ਹੈ: ਕੀ ਕੋਈ ਇਸ ਨਿਯਮ ਨੂੰ ਟੈਸਟ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਕੋਈ ਇਸਨੂੰ ਗਲਤ ਸਮਝ ਸਕਦਾ ਹੈ? ਜੇ ਪਹਿਲੇ ਦਾ ਜਵਾਬ ਨਹੀਂ ਹੈ ਜਾਂ ਦੂਜੇ ਦਾ ਹਾਂ, ਤਾਂ ਸ਼ਬਦਾਵਲੀ ਤਿੱਖੀ ਕਰੋ।

ਉਦਾਹਰਨ: ਇੱਕ ਖਰਚਾ ਅਪ੍ਰੂਵਲ ਐਪ

ਇੱਕ ਕਰਮਚਾਰੀ ਖਰਚਾ ਐਪ ਚੰਗੀ ਜਗ੍ਹਾ ਹੈ ਕਿਉਂਕਿ ਨੀਤੀ ਪਰਿਚਿਤ ਹੈ ਅਤੇ ਐਜ ਕੇਸ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ। ਕਰਮਚਾਰੀ ਭੋਜਨ, ਟੈਕਸੀ, ਹੋਟਲ ਅਤੇ ਛੋਟੇ ਕਲਾਇਟ ਖ਼ਰਚੇ ਦਾਅਵਾ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਹਰ ਦਾਅਵੇ ਦੀ ਹੱਦ, ਐਕਸਪਸ਼ਨ ਅਤੇ ਅਪ੍ਰੂਵਲ ਕਦਮ ਹੁੰਦੇ ਹਨ। ਇਹ ਠੀਕ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿੱਥੇ ਸਧਾਰਨ ਭਾਸ਼ਾ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ।

ਨਮੂਨਾ ਨੀਤੀ

ਭੋਜਨ ਨਿਯਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ: ਕਰਮਚਾਰੀ ਆਮ ਕੰਮਕਾਜ ਵਾਲੇ ਦਿਨਾਂ ਵਿੱਚ ਪ੍ਰਤੀ ਦਿਨ $40 ਤੱਕ ਭੋਜਨ ਦਾ ਦਾਅਵਾ ਕਰ ਸਕਦੇ ਹਨ। ਐਪ ਇੱਕੋ ਤਾਰੀਖ ਲਈ ਸਾਰੇ ਭੋਜਨ ਰਸੀਦਾਂ ਦਾ ਕੁੱਲ ਨਿਕਾਲੇ ਅਤੇ ਉਸ ਕੁੱਲ ਦੀ ਤੁਲਨਾ ਦੈਨੀ ਹੱਦ ਨਾਲ ਕਰੇ, ਨਾ ਕਿ ਹਰ ਰਸੀਦ ਨੂੰ ਅਲੱਗ-ਅਲੱਗ।

ਜੇ ਕਰਮਚਾਰੀ ਨੇ ਮੰਗਲਵਾਰ ਨੂੰ $12 ਨਾਸ਼ਤਾ ਅਤੇ $22 ਦੋਪਹਰ ਦਾ ਖਾਣਾ ਖਰਚਿਆ, ਤਾਂ ਕੁੱਲ $34 ਹੋਏਗਾ ਅਤੇ ਦਾਅਵਾ ਮਨਜ਼ੂਰ ਹੋ ਜਾਵੇਗਾ। ਜੇ ਉਨ੍ਹਾਂ ਨੇ ਉਸੇ ਦਿਨ $15 ਰਾਤ ਦੇ ਖ਼ਰਚੇ ਵੀ ਜੋੜੇ, ਤਾਂ ਕੁੱਲ $49 ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਐਪ ਨੇ ਦਾਅਵੇ ਨੂੰ ਹੱਦ ਤੋਂ ਉੱਪਰ ਦੇ ਨਿਸ਼ਾਨ ਨਾਲ ਮਾਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਹੁਣ ਇੱਕ ਐਕਸਪਸ਼ਨ ਜ਼ਿਆਦ ਕਰੋ। ਜੇ ਭੋਜਨ ਮਨਜ਼ੂਰ ਕੀਤੀ ਕਾਰੋਬਾਰੀ ਯਾਤਰਾ ਦੌਰਾਨ ਹੋਈ ਜਾਂ ਕਿਸੇ ਕਲਾਇਟ ਮੀਟਿੰਗ ਦੌਰਾਨ ਹੋਈ, ਤਾਂ ਦੈਨੀ ਭੋਜਨ ਦੀ ਹੱਦ $75 ਤੱਕ ਵਧ ਜਾਂਦੀ ਹੈ। ਇਹ ਐਕਸਪਸ਼ਨ ਸਿਰਫ ਤਦ ਹੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਰਮਚਾਰੀ Travel day = Yes ਜਾਂ Client meeting = Yes ਚੁਣਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟੀ ਨੋਟ ਵਿੱਚ ਕਲਾਇਟ ਦਾ ਨਾਮ ਜਾਂ ਯਾਤਰਾ ਦਾ ਉਦੇਸ਼ ਦਿੰਦਾ ਹੈ।

ਇਹ ਧੁੰਦਲੀ ਲਫ਼ਜ਼ਾਂ ਜਿਵੇਂ "ਖਾਸ ਕੇਸ ਮਨਜ਼ੂਰ ਹੋ ਸਕਦੇ ਹਨ" ਨਾਲੋਂ ਵਧ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਹੈ ਕਿਉਂਕਿ ਐਕਸਪਸ਼ਨ ਸਪੱਸ਼ਟ ਸ਼ਰਤਾਂ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ।

ਅਪ੍ਰੂਵਲ ਕਦਮ

ਅਪ੍ਰੂਵਲ ਲੋਜਿਕ ਇਸੇ ਤਰ੍ਹਾਂ ਸਧਾਰਨ ਰਹਿ ਸਕਦਾ ਹੈ:

• $100 ਤੋਂ ਘੱਟ ਦਾਅਵੇ ਕਰਮਚਾਰੀ ਦੇ ਮੈਨੇਜਰ ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
• $100 ਤੋਂ $500 ਤੱਕ ਦੇ ਦਾਅਵੇ ਲਈ ਮੈਨੇਜਰ ਦੀ ਮਨਜ਼ੂਰੀ, ਫਿਰ ਫਾਇਨੈਂਸ ਦੀ ਮਨਜ਼ੂਰੀ ਲੋੜੀਂਦੀ ਹੈ।
• $500 ਤੋਂ ਉੱਪਰ ਦੇ ਦਾਅਵੇ ਲਈ ਮੈਨੇਜਰ, ਫਾਇਨੈਂਸ ਅਤੇ ਡਿਪਾਰਟਮੈਂਟ ਹੈਡ ਤੱਕ ਦੀ ਮਨਜ਼ੂਰੀ ਲੋੜੀਂਦੀ ਹੈ।
• ਕੋਈ ਵੀ ਦਾਅਵਾ ਜੋ "travel" ਮਾਰਕ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਭਾਵੇਂ ਰਕਮ $100 ਤੋਂ ਘੱਟ ਹੋਵੇ, ਫਾਇਨੈਂਸ ਦੀ ਸਮੀਖਿਆ ਲੋੜੇਗਾ।

ਤੁਸੀਂ ਕੁਝ ਸਾਦੇ ਕੇਸਾਂ ਨਾਲ ਨਿਯਮ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ $36 ਦਾ ਭੋਜਨ ਦਾ ਦਾਅਵਾ ਆਮ ਕੰਮਕਾਜ ਵਾਲੇ ਦਿਨ 'ਤੇ ਰਸੀਦਾਂ ਨਾਲ ਮਨਜ਼ੂਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ $60 ਦਾ ਭੋਜਨ ਦਾ ਦਾਅਵਾ ਯਾਤਰਾ ਦਿਨ ਤੇ ਟ੍ਰੈਵਲ ਮਾਰਕ ਅਤੇ ਨੋਟ ਭਰੀ ਹੋਣ 'ਤੇ ਮਨਜ਼ੂਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ $60 ਦਾ ਦਾਅਵਾ ਆਮ ਦਿਨ ਤੇ ਰੱਦ ਜਾਂ ਸੋਧ ਲਈ ਵਾਪਸ ਭੇਜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ $650 ਹੋਟਲ ਦਾ ਦਾਅਵਾ ਤਿੰਨੋ ਅਪ੍ਰੂਵਲ ਕਦਮਾਂ ਵਿੱਚੋਂ ਲੰਘ ਕੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਲਕੜੀ-ਮੀਨ: ਨਿਯਮ ਨੂੰ ਹਰ ਵਾਰੀ ਟੈਸਟ ਕਰਨ 'ਤੇ ਇੱਕੋ ਹੀ ਨਤੀਜਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਖਰਾਬ ਨਤੀਜੇ ਲਿਆਉਂਦੀਆਂ ਹਨ

ਇੱਕ ਨਿਯਮ ਇੱਕ ਵਿਅਕਤੀ ਲਈ ਸਪੱਸ਼ਟ ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਬਣਾਉਣ ਵਾਲੇ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰ ਦੇਵੇ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦਸਤਾਵੇਜ਼ ਧੁੰਦਲਾ ਹੋਵੇ, ਇੱਕੋ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਕਈ ਵਿਚਾਰ ਪੈਕ ਕੀਤੇ ਹੋਣ ਜਾਂ ਵਾਕ-ਪ੍ਰਣਾਲੀ ਇੱਕ ਜਿਹੀ ਨਾ ਹੋਵੇ।

ਇੱਕ ਆਮ ਗਲਤੀ ਕਈ ਨਿਯਮਾਂ ਨੂੰ ਇੱਕ ਲੰਮੇ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਨਾੜ੍ਹ ਦੇਣਾ ਹੈ। ਉਦਾਹਰਨ: "ਮੈਨੇਜਰ ਯਾਤਰਾ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੁੱਲ ਉੱਚਾ ਨਹੀਂ, ਫਾਇਨੈਂਸ ਰਸੀਦਾਂ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਰੰਤ ਬੇਨਤੀਆਂ ਰਿਵਿਊ ਛੱਡ ਸਕਦੀਆਂ ਹਨ।" ਇਹ ਦਿੱਖਣ ਵਿੱਚ ਕੁਸ਼ਲ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਕਈ ਵੱਖ-ਵੱਖ ਫੈਸਲਿਆਂ ਨੂੰ ਛੁਪਾਉਂਦਾ ਹੈ। ਹਰ ਕਾਰਵਾਈ ਲਈ ਵੱਖਰਾ ਨਿਯਮ ਬਣਾਓ ਤਾਂ ਕਿ ਹਰ ਕਾਰਵਾਈ ਦਾ ਇੱਕ ਟ੍ਰਿਗਰ ਅਤੇ ਇੱਕ ਨਤੀਜਾ ਹੋਵੇ।

ਹੋਰ ਸਮੱਸਿਆ ਧੁੰਦਲੀ ਭਾਸ਼ਾ ਹੈ। "ਸਧਾਰਨ", "ਵੱਡਾ", "ਤੁਰੰਤ" ਜਾਂ "ਹਾਲੀਆ" ਵਰਗੇ ਸ਼ਬਦ तभी ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਹੋਣ। ਜੇ "ਵੱਡਾ ਖਰਚ" ਦਾ मतलब $2,000 ਤੋਂ ਉੱਪਰ ਹੋਣਾ ਹੈ, ਤਾਂ ਇਹ ਲਿਖੋ। ਜੇ "ਤੁਰੰਤ" ਦਾ ਮਤਲਬ 24 ਘੰਟੇ ਹੈ, ਤਾਂ ਇਹ ਨਿਸ਼ਚਿਤ ਕਰ ਦਿਓ।

ਗੁੰਮ ਡੇਟਾ ਵੀ ਇਕ ਵੱਡਾ ਸੋਰਸ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਖੁਸ਼ੀ ਦਾ ਰਾਹ ਦੱਸਦੀਆਂ ਹਨ ਅਤੇ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਅਧੂਰੇ ਜਾਂ ਗਲਤ ਡੇਟਾ 'ਤੇ ਕੀ ਕਰਨਾ ਹੈ। ਜੇ ਬੇਨਤੀ ਵਿੱਚ ਕੋਈ ਰਕਮ, ਕੋਈ ਵਿਭਾਗ ਜਾਂ ਕੋਈ ਰਸੀਦ ਨਹੀਂ, ਤਾਂ ਨਿਯਮ ਦੱਸੇ ਕਿ ਅੱਗੇ ਕੀ ਹੋਵੇ।

ਜੋ ਗਲਤੀਆਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹਨ:

• ਕਈ ਨਿਯਮ ਇਕ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਜੋੜ ਦੇਣਾ
• ਆਕਾਰ, ਸਮਾਂ ਜਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਲਈ ਅਪਰਿਭਾਸ਼ਿਤ ਸ਼ਬਦ ਵਰਤਣਾ
• ਗਲਤੀ ਕੇਸਾਂ ਅਤੇ ਗੁੰਮ ਫੀਲਡ ਭੁੱਲ ਜਾਣਾ
• ਆਖਰੀ ਮਨਜ਼ੂਰੀ ਅਧਿਕਾਰ ਨੂੰ ਅਸਪਸ਼ਟ ਛੱਡਣਾ
• ਆਧੇ ਰਸਤੇ ਵਿੱਚ ਇੱਕੋ ਚੀਜ਼ ਲਈ ਵੱਖ-ਵੱਖ ਨਾਮ ਵਰਤਣਾ

ਆਖਰੀ ਅਧਿਕਾਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਮੈਨੇਜਰ ਅਤੇ ਫਾਇਨੈਂਸ ਰਿਵਿਊਅਰ ਅਲੱਗ-ਅਲੱਗ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ, ਤਾਂ ਆਖਿਰ ਕੌਣ ਫੈਸਲਾ ਕਰੇਗਾ? ਜੇ ਕੋਈ ਆਖਰੀ ਕਦਮ ਨਹੀਂ ਰੱਖਿਆ, ਤਾਂ ਐਪ ਫਸ ਸਕਦੀ ਹੈ ਜਾਂ ਕੰਮ ਘੁੰਮ-ਫਿਰ ਕੇ ਜਾਵੇਗਾ।

ਸ਼ਬਦਾਂ ਦੇ ਬਦਲਾਅ ਚੁਪਕੇ-ਚੁਪਕੇ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ "request" ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿਚ ਉਸੇ ਚੀਜ਼ ਨੂੰ "submission" ਜਾਂ "ticket" ਕਹਿਣ ਲੱਗਦੇ ਹੋ, ਪੜ੍ਹਨ ਵਾਲਾ ਸੋਚ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਆਈਟਮ ਹਨ। ਇੱਕ ਸ਼ਬਦ ਚੁਣੋ ਅਤੇ ਪੂਰੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਉਹੀ ਵਰਤੋਂ ਕਰੋ।

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

ਬਿਲਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਸਕਰੀਨ, ਫਲੋ ਜਾਂ ਪ੍ਰੰਪਟਾਂ ਵਿੱਚ ਲਿਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਸਮੀਖਿਆ ਕਰੋ। ਇੱਕ ਛੋਟਾ ਚੈਕ ਹੁਣ ਘੰਟੇ ਦੀ ਮੁਰੰਮਤ ਬਚਾ ਸਕਦਾ ਹੈ।

ਹਰ ਨਿਯਮ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੋਵੇ। ਹਰ ਨਿਯਮ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜੇ 'ਤੇ ਖਤਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਹਾਂ ਜਾਂ ਨਹੀਂ, ਮਨਜ਼ੂਰੀ ਜਾਂ ਨਾਂ, ਫੀਸ ਲਾਗੂ ਕਰੋ ਜਾਂ ਨਾ ਲਾਗੂ ਕਰੋ। ਜੇ ਦੋ ਲੋਕ ਇੱਕੋ ਵਾਕ ਨੂੰ ਪੜ੍ਹ ਕੇ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ, ਤਾਂ ਨਿਯਮ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਹਰ ਗਣਨਾ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ। ਇਨਪੁਟਾਂ ਦੇ ਨਾਮ, ਫਾਰਮੂਲਾ ਅਤੇ ਕਦੋਂ ਗਣਨਾ ਹੋਵੇਗੀ - ਇਹ ਸਭ ਦਰਜ ਕਰੋ। ਗੋਲਾਈ, ਕਰੰਸੀ, ਤਾਰੀਖ ਹینڈਲਿੰਗ ਅਤੇ ਜੇ ਮੁੱਲ ਗਾਇਬ ਜਾਂ ਜ਼ੀਰੋ ਹੋਵੇ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ, ਇਹ ਸਭ ਲਿਖੋ।

ਐਕਸਪਸ਼ਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ। ਪਹਿਲਾਂ ਮੂਲ ਨਿਯਮ ਲਿਖੋ, ਫਿਰ ਵੱਖ-ਵੱਖ ਐਕਸਪਸ਼ਨ ਜੋੜੋ। ਮੁੱਖ ਖਰਚ ਹੱਦ ਨੂੰ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਕੇਸ ਵਿੱਚ ਛੁਪਾਉਣ ਨਾ ਦਿਉ।

ਪੂਰਾ ਅਪ੍ਰੂਵਲ ਰਸਤਾ ਨਕਸ਼ਾ ਬਣਾਓ। ਹਰ ਥਰੈਸ਼ਹੋਲਡ ਲਈ ਦੱਸੋ ਕਿ ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕੀ ਹੁੰਦਾ ਹੈ। ਸੀਮਾਵਾਂ ਬਾਰੇ ਵੀ ਸਹੀ-ਸਹੀ ਲਿਖੋ: ਕਿਆ ਨਿਯਮ $500 ਤੋਂ ਉੱਪਰ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਾਂ $500 ਤੇ ਸ਼ੁਰੂ?

ਫਿਰ ਨਵੇਂ-ਟੀਮਮੇਟ ਟੈਸਟ ਕਰੋ। ਨਿਯਮ ਨੂੰ ਕਿਸੇ ਨਵੇਂ ਸਦੱਸ ਨੂੰ ਦਿਓ ਜਿਸਨੇ ਪਹਿਲਾਂ ਇਸ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਅਤੇ ਪੁੱਛੋ ਕਿ ਉਹ ਆਪਣੀ ਭਾਸ਼ਾ ਵਿੱਚ ਇਹ ਵਾਪਸ ਸਮਝਾ ਸਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਜੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵਧੇਰੇ ਸੰਦਰਭ ਲੋੜੀਦਾ ਹੈ, ਤਾਂ ਨਿਯਮ ਅਜੇ ਵੀ ਬਹੁਤ ਧੁੰਦਲਾ ਹੈ।

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ ਕਿਉਂ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: "ਮੈਨੇਜਰ ਵੱਡੇ ਖਰਚੇ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ" ਸੁਣਨ ਵਿੱਚ ਸਪੱਸ਼ਟ ਲੱਗਦਾ ਹੈ ਪਰ ਕਿਸੇ ਨੇ ਪੁੱਛਿਆ ਕਿ $500 ਵੱਡਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਥੱਲੇ ਲਿਖੋ: "ਮੈਨੇਜਰ $500 ਤੋਂ ਉੱਪਰ ਦੇ ਖਰਚੇ ਮਨਜ਼ੂਰ ਕਰੇਗਾ। ਡਾਇਰੈਕਟਰ $2,000 ਤੋਂ ਉੱਪਰ ਦੇ ਖਰਚੇ ਮਨਜ਼ੂਰ ਕਰੇਗਾ। $500 ਜਾਂ ਉਸ ਤੋਂ ਘੱਟ ਖਰਚੇ ਆਟੋ-ਅਪ੍ਰੂਵ ਹੋਣਗੇ।" ਇਹ ਗ਼ਲਤੀਆਂ ਦੀ ਗੁੰਜਾਇਸ਼ ਕਾਫੀ ਘੱਟ ਕਰ ਦਿੰਦਾ ਹੈ।

ਨਿਯਮਾਂ ਨੂੰ ਕਾਰਯਕ ਐਪ ਵਿੱਚ ਬਦਲਣਾ

ਜਦ ਨਿਯਮ ਸਪੱਸ਼ਟ ਹੋ ਜਾ