অগোছালো ছাড়া Slack অনুরোধকে একটি অভ্যন্তরীণ পণ্যে রূপান্তর করুন

কেন পুনরাবৃত্ত Slack অনুরোধ সমস্যায় পরিণত হয়

কয়েকটি Slack অনুরোধ বড় কোনো ব্যাপার মনে হয় না। তারপর একই প্রশ্নগুলো প্রতিদিন দেখাতে শুরু করে: “আপনি কি অ্যাক্সেস দিতে পারবেন?” “আপনি কি এই রিপোর্টটা ঠিক করতে পারবেন?” “আপনি কি একটি নতুন ওয়ার্কস্পেস তৈরি করবেন?” যা দ্রুত সাহায্য মনে হচ্ছিল, তা এক ধরনের অনানুষ্ঠানিক সিস্টেমে পরিণত হয় যার কোনো কাঠামো নেই।

প্রথম সমস্যা হলো ছড়িয়ে পড়া। অনুরোধগুলো DM, টিম চ্যানেল, প্রাইভেট গ্রুপ এবং সাইড থ্রেডে আসে। কিছুতে প্রসঙ্গ থাকে, কিছুতে নেই। কেউ কেউ মনে হয় দেখেছিল কিন্তু মনে নেই কোথা থেকে বা কেউ সেটি গ্রহণ করেছে কিনা। কাজ হারিয়ে যায় কারণ এটি কোনো এক পরিষ্কার কিউতে ঢোকে না।

দ্বিতীয় সমস্যা হলো তথ্যের অভাব। মানুষ দ্রুত জিজ্ঞাসা করে, প্রায়ই তখনও জানে না কোন তথ্যটি গুরুত্বপূর্ণ। ফলে কাজটি করে যে ব্যক্তিকে করতে হবে তাকে মৌলিক বিষয়গুলো জিজ্ঞাসা করতে হয় — কাকে অ্যাক্সেস লাগবে, কোন সিস্টেম জড়িত, বা কখন পরিবর্তনটি দরকার। পাঁচ মিনিটের কাজ লম্বা বার্তালাপে পরিণত হয়।

তাত্ক্ষণিকতা এটা আরও খারাপ করে। সবচেয়ে জোরালো মেসেজটি সামনে চলে আসে, যদিও তা সবচেয়ে গুরুত্বপূর্ণ নাও হতে পারে। নীরব কিন্তু গুরুত্বপূর্ণ অনুরোধগুলো পেছনে পড়ে যায়। সময়ের সাথে টিমটি অগ্রাধিকারের ভিত্তিতে কাজ করা বন্ধ করে দেয় এবং শেষ যারা সবচেয়ে চাপ দেয় তাদের প্রতিক্রিয়ায় চলে যায়।

তারপর আছে স্ট্যাটাস। শেয়ার্ড কিউ না থাকলে সাধারণ প্রশ্নগুলোও জটিল হয়ে পড়ে:

• এই অনুরোধের মালিক কে?
• এটা অপেক্ষমাণ, প্রক্রিয়াধীন, না সম্পন্ন?
• এটা অন্য কোথাও আগে থেকেই হ্যান্ডেল করা হয়েছে কি না?
• এই সপ্তাহে একই ধরনের কতগুলো অনুরোধ এসেছে?

দৃষ্টিভঙ্গির অভাবটি পুনরাবৃত্ত কাজ, বিলম্ব এবং উভয়পক্ষেরই হতাশা সৃষ্টি করে। রিকোয়েস্টকারী অনাদর মনে করে। রিকোয়েস্ট হ্যান্ডল করা টিম পুরো দিন ব্যাহত মনে করে। যা চ্যাটের সমস্যা মনে হয়, আসলে সেটি ওয়ার্কফ্লো সমস্যা।

বারবার আসা অনুরোধগুলো খুঁজে বের করুন

সেই অনুরোধগুলো দিয়ে শুরু করুন যা বারবার আসে। আন্দাজ করবেন না। গত দুই থেকে চার সপ্তাহের আসল মেসেজগুলো পর্যালোচনা করুন এবং মানুষ আসলে কী চেয়েছিল তা দেখুন।

একটি সংক্ষিপ্ত রিভিউ উইন্ডো সাধারণত যথেষ্ট। এটি প্রতি সপ্তাহে ঘটে যাওয়া অনুরোধগুলো দেখায় এবং পুরনো ব্যতিক্রমগুলি টেনে আনে না যা আর প্রাসঙ্গিক নয়।

মেসেজ স্ক্যান করার সময় অনুরোধগুলো টাইপভিত্তিতে গ্রুপ করুন। নিখুঁত ক্যাটেগরি দরকার নেই। আপনাকে যা দরকার তা হলো কার্যকরভাবে দেখতে পারা কী পুনরাবৃত্তি হচ্ছে: অ্যাক্সেস অনুরোধ, রিপোর্ট আহরণ, অনুমোদন চেক, ছোট ডেটা আপডেট, নতুন ওয়ার্কস্পেস সেটআপ ইত্যাদি।

একটি সাধারণ শীটই যথেষ্ট। প্রতিটি অনুরোধের জন্য নোট করুন:

• কী চাওয়া হয়েছে
• সেই ধরনের অনুরোধ কতবার দেখা গেছে
• সাধারণত কে অনুরোধ করে
• সাধারণত কে সেটি হ্যান্ডেল করে

শেষটি অনেক দলের চেয়ে বেশি গুরুত্বপূর্ণ। যদি একই কয়েকজনই একই অনুরোধ বারবার পূরণ করে, তবে আপনার কাছে ইতিমধ্যে একটি অভ্যন্তরীণ পণ্যের খসড়া থাকতে পারে। আপনি দেখতে পারবেন জ্ঞান কোথায় থাকে, দেরি কোথায় হয়, এবং কোন প্রক্রিয়া এক ব্যক্তির উপর খুব বেশি নির্ভরশীল।

নকশা দ্রুত চোখে পড়ে। সেলস বারবার ফাইন্যান্সকে একই প্রাইসিং এক্সসেপশন চাইতে পারে। নতুন কর্মীরা বারবার IT-কে একই অ্যাপ পারমিশনের জন্য মেসেজ করতে পারে। ম্যানেজাররা অপসকে প্রতি সপ্তাহের স্ট্যাটাস আপডেট একই ভিন্ন ভাষায় চাইতে পারে।

এখনই বিরল এজ কেসগুলো বাদ দিন। যদি কোনো অনুরোধ মাসে একবার এসেছে এবং বিশেষ হ্যান্ডলিং লাগেছিল, তা এখনই ছেড়ে দিন। লক্ষ্য হলো সাধারণ, বোরিং, বর্ণনাযোগ্য কাজ খুঁজে পাওয়া। সেটি হলো শুরু করার সবচেয়ে ভাল জায়গা, কারণ পুনরাবৃত্ত অনুরোধগুলো মানकीকরণ সহজ, পরিমাপ সহজ এবং একটি পরিষ্কার ইনটেক প্রক্রিয়ার থেকে সবচেয়ে বেশি লাভবান হওয়ার সম্ভাবনা বেশি।

একটি ছোট প্রথম কেস বেছে নিন

অপ্রয়োজনীয়ভাবে বড় কিছু নিয়ে শুরু করবেন না। সেরা প্রথম কেসটি কোম্পানির সবচেয়ে জোরালো সমস্যা নয়; বরং সেটাই যে বারবার ঘটে, কয়েকটি স্পষ্ট ধাপ অনুসরণ করে, এবং এমন একটি ফলাফল দিয়ে শেষ হয় যা সবাই একমত হতে পারে।

একটি শক্ত প্রথম পছন্দ সাধারণত একটি সরল অনুমোদন পথ আছে। একজন ব্যক্তি কিছু অনুরোধ করে, একজন ব্যক্তি তা যাচাই করে, এবং একজন ব্যক্তি সেটা শেষ করে। যদি পাঁচটি টিমকে ঝাঁপিয়ে পড়তে হয়, তখন আপনি এখনও একটি পরিষ্কার রিকোয়েস্ট ফ্লো তৈরি করছেন না; আপনি কেবল একটি জটিল প্রক্রিয়া ম্যাপ করছেন।

ফলাফল এক বাক্যে বর্ণনা করার চেষ্টা করুন। যদি বাক্যটি অস্পষ্ট লাগে, অনুরোধটি সম্ভবত খুব বিস্তৃত।

“একটি টিমের জন্য একটি নতুন শেয়ার্ড ইনবক্স অনুমোদন এবং তৈরি করুন” একটি ভাল শুরু। “আমাদের গ্রাহক যোগাযোগ উন্নত করতে সাহায্য করুন” নয়। প্রথমটির একটি স্পষ্ট শেষ আছে; দ্বিতীয়টি দশটি ভিন্ন জিনিস বুঝাতে পারে।

একটি অনুরোধ টাইপ সাধারণত ছোট হলে:

• এটি একটি স্পষ্ট শুরু এবং শেষ আছে
• প্রায়ই একই ধরনের বিস্তারিত প্রয়োজন
• অনুমোদন সীমিত এবং পূর্বানুমেয়
• সফলতা এক বাক্যে বোঝানো যায়

একবার আপনি কেস বেছে নিলে, দেখার জন্য একটি মাত্র মেট্রিক নির্ধারণ করুন। সহজ রাখুন। অপেক্ষার সময় শুরু করার জন্য ভালো কারণ; সবাই এটা বুঝে। যদি বড় সমস্যা ভুলিভ্রান্তি হয়, তাহলে পুনরায় কাজ ট্র্যাক করুন—উদাহরণস্বরূপ, কতবার টিমকে অনুপস্থিত তথ্যের জন্য ফিরে যেতে হয়েছে।

এই প্রথম কেসটিকে সবকিছু প্রমাণ করতে হবে না। এটা কেবল দেখাবে যে একটি কাঠামোবদ্ধ ইনটেক প্রক্রিয়া ছড়িয়ে থাকা Slack মেসেজের চেয়ে ভালো। যদি ছোট সংস্করণ কাজ করে, আপনার কাছে বাস্তব ডেটা, কম মতামত, এবং পরে অটোমেশন করার সহজ পথ থাকবে।

একটি পরিষ্কার কিউ তৈরি করুন

প্রথম সমাধানটি সহজ: মানুষের জন্য একটি ফ্রন্ট ডোর দিন। তাদের অনুমান করতে হবে না DM পাঠাবেন, টিম চ্যানেলে পোস্ট করবেন, না কিংবা যে কেউ ফ্রি দেখায় তাকে ট্যাগ করবেন। একটি ফর্ম, একটি ইনটেক চ্যানেল, বা একটি রিকোয়েস্ট ইনবক্সই যথেষ্ট। টুলটির চেয়ে ধারাবাহিকতাই বেশি গুরুত্বপূর্ণ।

কিউটি প্রতিবার একই মৌলিক বিবরণ চাইবে। সংক্ষিপ্ত রাখুন, কিন্তু কার্যকর: অনুরোধকারী কী চায়, কেন দরকার, কখন দরকার, এবং অনুমোদন প্রয়োজন হলে কে অনুমোদন করবে। যখন এই বিবরণগুলো অনুপস্থিত থাকে, তখন আবারই ব্যাক-এন্ড-ফোর্থ শুরু হয়।

স্ট্যাটাস লেবেলগুলোও কাজে লাগে, কিন্তু কেবল যদি সেগুলো সাধারণ এবং স্পষ্ট হয়। বেশিরভাগ টিমের জটিল সিস্টেমের প্রয়োজন নেই। তারা কেবল জানতে চায় কী হচ্ছে:

• নতুন
• তথ্য দরকার
• প্রক্রিয়াধীন
• অনুমোদনের অপেক্ষায়
• সম্পন্ন

সহজ শব্দ ব্যবহার করুন যাতে কেউ কিউ এক নজরে বুঝতে পারে। যদি কোনো অনুরোধ খুব লম্বা সময় ধরে বসে থাকে, স্ট্যাটাসটি কারণ স্পষ্ট করে বলুক।

ততটাই গুরুত্বপূর্ণ, কিউ ট্রায়েজ করার জন্য একজন ব্যক্তি বা একজন টিম নিয়োগ করুন। এর মানে তারা সব কাজ করবে এমন নয়; এর মানে তারা প্রথম প্রতিক্রিয়ার মালিক হবে, চেক করবে অনুরোধটি সম্পূর্ণ কি না, এবং সেটিকে সঠিক জায়গায় রুট করবে। একটি পরিষ্কার মালিক ছাড়া, শেয়ার করা কিউ দ্রুত এমন একটি স্তূপে পরিণত হয় যার জন্য কেউ দায়বদ্ধ বোধ করে না।

একটি ভাল পরীক্ষা: যদি আগামীকাল একটি নতুন কর্মী যোগদানের পরে এসেছে, তিনি কি কোনো জিজ্ঞাসা না করেই একটি অনুরোধ জমা দিতে পারতেন কি কোথায় পাঠাতে হবে বা কী অন্তর্ভুক্ত করতে হবে তা না জিজ্ঞেস করে? যদি উত্তর না হয়, তাহলে অটোমেশন করার আগে সেটি ঠিক করুন। একটা অগোছালো ইনটেক প্রক্রিয়া শুধুমাত্র দ্রুত হয় অগোছালোভাবেই যদি আপনি এটিকে অটোমেট করেন।

প্রথমে ম্যানুয়ালি চালান

অটোমেট করার আগে, এক বা দুই সপ্তাহ ম্যানুয়ালি প্রক্রিয়াটি চালান। এটি দেখায় বাস্তব অনুরোধগুলো কেমন, মানুষ কোথায় আটকে যায়, এবং কোন অংশগুলো আসলে সিস্টেমে পরিণত করা উপযোগী।

একটি ইনটেক ফরম দিয়ে শুরু করুন। এটি ছোট একটা ফর্ম, পিন করা টেমপ্লেট বা একটি স্ট্যান্ডার্ড Slack মেসেজ হতে পারে যা মানুষ কপি করে পূরণ করে। যা জরুরি তা হলো ধারাবাহিকতা: অনুরোধকারীর নাম, তারা কী চায়, কেন দরকার, সময়সীমা, এবং অনুমোদন যদি প্রয়োজন।

তারপর দিনজোড়ায় প্রতিক্রিয়া জানার পরিবর্তে নির্দিষ্ট সময়ে কিউ চেক করুন। উদাহরণস্বরূপ, সকাল ১০টা এবং দুপুর ৩টায় কিউ রিভিউ করুন। এটি ফোকাস রক্ষা করে এবং টিমকে শেখায় যে রিকোয়েস্টগুলো কোনো র‌্যান্ডম পিং নয়, একটি প্রক্রিয়ার মধ্য দিয়ে যায়।

প্রতিবার একই পথ ব্যবহার করুন:

• অনুরোধ পড়ুন এবং নিশ্চিত করুন প্রয়োজনীয় বিবরণ আছে
• একবারে একটি রিপ্লাই-এ অনুপস্থিত তথ্য চান, পাঁচবার নয়
• কাজটি সম্পন্ন করুন বা সঠিক মালিকের কাছে পাঠান
• সম্পন্ন হিসেবে চিহ্নিত করুন এবং কত সময় লেগেছে নোট করুন

কাজ চালানোর সময় আপনি প্রকৃতপক্ষে যে ধাপগুলো নেন সেগুলো লিখে রাখুন। সহজ রাখুন। যদি আপনি সর্বদা ম্যানেজার অনুমোদন যাচাই করেন, এক টুল থেকে অন্যটিতে ডেটা কপি করেন, বা একই ফলো-আপ প্রশ্ন করেন, তাহলে সেগুলো নোট করুন। এই পুনরাবৃত্ত কাজগুলোই পরবর্তী উন্নত ওয়ার্কফ্লোর কাঁচামাল।

সহজ ভাষায় ঘর্ষণ ট্র্যাক করুন। অনুপস্থিত বিবরণ, অনুমোদন বিলম্ব, অস্পষ্ট মালিকানা, এবং বারবার যেসব প্রশ্ন আসে সেগুলো নোট করুন। কয়েকটা ব্যাচের পর প্যাটার্নগুলো দ্রুত দেখা যায়।

আপনি যখন ধাপগুলো পরিবর্তন কমাচ্ছে তা দেখতে পাবেন, তখনই অটোমেশন করার সময় এসেছে। যদি বেশিরভাগ অনুরোধ একই পথে চলে, আপনি এমন কিছুই পাচ্ছেন যা চারপাশে নির্মাণ করার জন্য যথেষ্ট স্থিতিশীল। এর আগে ম্যানুয়াল কাজ বিফলে যায় না—এটাই শেখার উপায়।

পুনরাবৃত্ত সিদ্ধান্তগুলোকে সরল নিয়মে পরিণত করুন

যদি একই অনুরোধ বারবার আসে, তার পেছনের সিদ্ধান্ত শুধুমাত্র এক ব্যক্তির মাথায় থাকা উচিত নয়। প্রতিবার আপনি যে চেকগুলো করেন সেগুলো লিখে ফেলুন, যেই ক্রমে আপনি সেগুলো ব্যবহার করেন। সেটি একটি অভ্যাসকে অন্য কেউ অনুসরণ করতে পারা একটি প্রক্রিয়ায় পরিণত করে।

সেই প্রশ্নগুলো দিয়ে শুরু করুন যা ফলাফল পরিবর্তন করে। অনুরোধটি সম্পূর্ণ কি? ব্যক্তির অনুমোদন আছে কি? ডেডলাইন অনবোর্ডিং, পে-রোল, না কি গ্রাহক কাজের সাথে যুক্ত? এই চেকগুলো যদি বেশিরভাগ অনুরোধে ঘটে থাকে, তবে সেগুলো নিয়ম সেটে রাখা উচিত।

নিয়মগুলো সংগঠিত করার সহজ উপায় হলো আলাদা করা:

• কাজ শুরু করার আগে থাকা আবশ্যক বিবরণ
• থাকা ভাল কিন্তু বাধা না দেওয়া বিবরণ
• সিদ্ধান্ত-চেক যেমন অনুমোদন, অগ্রাধিকার, মালিক, এবং ডিউ তারিখ
• ঝুঁকি ফ্ল্যাগ যেমন অ্যাক্সেস লেভেল, খরচ, সিকিউরিটি, বা গ্রাহক প্রভাব

এটি ইনটেক প্রক্রিয়াকে ক্ষুদ্র ঘাটতিতে আটকে যেতে থেকে রক্ষা করে। যদি একজন ম্যানেজার একটি সহায়ক বিবরণ ভুলে যায় কিন্তু কর্মী, টিম এবং অ্যাক্সেস লেভেল উল্লেখ করে, তাহলে অনুরোধটি সম্ভবত এগোনো যায়।

পরের ধাপে, আপনি সবচেয়ে সাধারণ আউটকামের জন্য স্ট্যান্ডার্ড রিপ্লাই লিখুন। সাধারণত এটাই মানে—অনুমোদিত, তথ্য অনুপস্থিত, ভুল চ্যানেল, ডুপ্লিকেট অনুরোধ, বা রিভিউ দরকার। প্রতিটি রিপ্লাই সংক্ষিপ্ত এবং নির্দিষ্ট রাখুন যাতে লোকেরা জানে পরের ধাপ কী হবে।

উদাহরণস্বরূপ, প্রতিবার নতুন করে উত্তর লিখার পরিবর্তে ব্যবহার করুন: “অনুমোদিত। অ্যাক্সেস আজ সেট করা হবে” বা “শুরু করার আগে একটি অতিরিক্ত তথ্য দরকার: ম্যানেজার অনুমোদন।”

প্রতিটি ধাপই নিয়ম হওয়া উচিত নয়। যেখানে মানুষের বিচার দরকার সেখানে মানুষ রাখুন: ব্যতিক্রম, সংবেদনশীল অ্যাক্সেস, অস্বাভাবিক ডেডলাইন, বা নীতিভঙ্গকারী অনুরোধগুলোতে মানুষের বিবেচনা থাকা দরকার। ভাল নিয়ম মানুষকে প্রক্রিয়া থেকে বাদ দেয় না; এটি অনাবশ্যক বার্তা-বার্তা কমায়।

একটি বাস্তব উদাহরণ: নতুন কর্মীর অ্যাক্সেস

নিউ হায়ার অ্যাক্সেস প্রায়ই প্রথম অভ্যন্তরীণ পণ্যের জন্য সেরা। প্রায় সব কোম্পানিই এটি পরিচালনা করে, ধাপগুলো পুনরাবৃত্তি হয়, এবং প্রথম দিনে কিছু না পাওয়ার খরচ স্পষ্ট।

পুরনো সংস্করণ কেমন: একজন ম্যানেজার Slack-এ মেসেজ করে, “Sam সোমবার স্টার্ট করছে। তাকে সেটআপ করতে পারবেন?” তারপর তিনটি ভিন্ন টিম ফলো-আপ প্রশ্ন করে, কেউ এক সিস্টেম ভুলে যায়, এবং Sam প্রথম সকালে অ্যাক্সেসের জন্য অপেক্ষা করে সময় কাটায়।

ভাল সেটআপ শুরু হয় একটি পরিষ্কার কিউ থেকে। ম্যানেজার প্রতিবার একই জায়গায় রিকোয়েস্ট জমা দেয়, এবং ফর্ম শুধুমাত্র প্রয়োজনীয় বিবরণ চায়: ভূমিকা, শুরু তারিখ, এবং কোন সিস্টেমগুলোর প্রয়োজন।

এই ছোট পরিবর্তনটি দুইটি কাজ করে: এটি ব্যাক-এন্ড-ফোর্থ সরিয়ে দেয় যা সবাইকে ধীর করে, এবং এটি একটি পরিষ্কার রেকর্ড তৈরি করে যে কী অনুরোধ করা হয়েছিল এবং কখন।

স্ট্যান্ডার্ড ভূমিকার জন্য পথটি সবচেয়ে ভালভাবে বোরিং হওয়া উচিত। যদি অনুরোধটি সেলস রিপ, ডিজাইনার, বা সাপোর্ট এজেন্টের জন্য হয়, একই অনুমোদন ও অ্যাক্সেস প্যাকেজ প্রতিবার একই ধাপে যেতে পারে। উদাহরণস্বরূপ:

• সেলস পায় CRM, ইমেইল, ক্যালেন্ডার, এবং কল টুল
• ডিজাইন পায় ডিজাইন সফটওয়্যার, শেয়ার্ড ড্রাইভ, এবং প্রজেক্ট টুল
• সাপোর্ট পায় হেল্পডেস্ক অ্যাক্সেস, অভ্যন্তরীণ ডকস, এবং টিম চ্যাট চ্যানেল

এটাই যখন প্রক্রিয়াটি অনুরোধ নয়, একটি পণ্যের মতো বোধ হয়। মানুষ জানে কোথায় সাবমিট করতে হবে, কী তথ্য প্রয়োজন, এবং সাধারণত কত সময় লাগে।

প্রতিটি অনুরোধ স্বয়ংক্রিয় হওয়ার দরকার নেই। টেম্পোরারি কন্ট্রাক্টর, ক্রস-টিম ভূমিকা, এবং সংবেদনশীল সিস্টেমে অ্যাক্সেস হলে মানুষের মালিক থাকা ভাল। যদি বেশিরভাগ অনুরোধ একই পথ অনুসরণ করে এবং শুধুমাত্র ব্যতিক্রমগুলোর জন্য বিশেষ হ্যান্ডলিং লাগে, তাহলে আপনি আরও উন্নত করার জন্য প্রস্তুত।

ওয়ার্কফ্লো স্থিতিশীল হলে অটোমেশন যোগ করুন

অটোমেশন সবচেয়ে বেশি সাহায্য করে যখন কাজটি ইতিমধ্যেই একটি স্পষ্ট প্যাটার্ন অনুসরণ করে। যদি টিমটি এখনও ধাপ পরিবর্তন করছে, মালিকানা নিয়ে তর্ক করছে, বা প্রতিটি অনুরোধ পৃথকভাবে হ্যান্ডল করছে, অটোমেশন কেবল সেই বিভ্রান্তিকে স্থায়ী করে দেবে।

একটি সহজ নিয়ম: ম্যানুয়ালি প্রক্রিয়াটি চালান যতক্ষণ না মানুষ প্রতিবার একইভাবে এটি বর্ণনা করতে পারে। যখন ফ্লোটি বোরিং, পূর্বানুমেয়, এবং শেখাতে সহজ মনে হয়, তখন সাধারণত এটি অটোমেশনের জন্য প্রস্তুত।

নিরাপদ অংশগুলো দিয়ে শুরু করুন

প্রথম যে জিনিসগুলো অটোমেট করা উচিত তা হলো নিম্ন-ঝুঁকির কাজগুলো যেগুলো সময় নষ্ট করে কিন্তু বিচার-বিবেচনা দাবি করে না। রিকোয়েস্ট ওয়ার্কফ্লোরে সাধারণত এর মানে হল রিমাইন্ডার, নিশ্চিতকরণ, এবং স্ট্যাটাস আপডেট।

কেউ রিকোয়েস্ট সাবমিট করলে সিস্টেম রসীদ পাঠাতে পারে, প্রত্যাশিত টার্নঅ্যারাউন্ড টাইম উল্লেখ করতে পারে, এবং অনুরোধ যখন নতুন থেকে প্রক্রিয়াধীন, অথবা সম্পন্ন এ যায় তখন আপডেট পোস্ট করতে পারে। এতে ফলো-আপ মেসেজগুলো সেভ হয় কিন্তু সিদ্ধান্ত গ্রহণের উপায় বদলে যায় না।

ভালো প্রাথমিক অটোমেশনে প্রায়শই থাকে:

• রিকোয়েস্ট গ্রহণের নিশ্চিতকরণ
• ডিউ ডেট কাছাকাছি এলে মালিককে রিমাইন্ডার
• একটি শেয়ার্ড জায়গায় রিকোয়েস্ট স্ট্যাটাস আপডেট করা
• যখন অতিরিক্ত বিস্তারিত দরকার তখন একটি বার্তা পাঠানো

রাউটিং পরে করুন। যদি অনুরোধগুলো এখনও মানুষের মধ্যে লাফিয়ে বেড়ায়, বা টিম মালিকানা ঘুরে বেড়ায়, স্বয়ংক্রিয় রাউটিং বেশি ক্লিনআপ কাজ তৈরি করবে। ম্যানুয়াল পথ স্থিতিশীল না হলে অপেক্ষা করুন।

শুরুর দিন থেকেই একটি ম্যানুয়াল ওভাররাইড রাখুন। কিছু অনুরোধ সর্বদা জটিল, জরুরি, বা অস্বাভাবিক হবে। মানুষকে নিয়ম থেকে বাইরো হয়ে সমস্যা ঠিক করার এবং অগ্রসর হওয়ার সহজ উপায় দরকার। যদি সিস্টেম ব্যতিক্রমসমূহ হ্যান্ডল করতে না পারে, ব্যবহারকারীরা এটি বিশ্বাস করতে বন্ধ করে দেবে।

আপনি অটোমেশন বাড়ানোর আগে ভুলগুলো দেখুন। ভুল রাউটিং, বিলম্ব, বা ভুল উত্তরে ক্লোজ করা অনুরোধগুলো কোথায় হয়েছে তা পর্যালোচনা করুন। ওই ভুলগুলো দেখায় কোথায় প্রক্রিয়া এখনও অস্পষ্ট। অটোমেশন এমন একটি ওয়ার্কফ্লোকে সমর্থন করা উচিত যা আগে থেকেই কাজ করে, নতুন কিছু আবিষ্কার করা নয়।

এড়ানোর মতো সাধারণ ভুল

অধিকাংশ টিম আটকে যায় কারণ অনুরোধগুলো খুব জটিল নয়, তারা আটকে যায় কারণ সবকিছু একসাথে ঠিক করার চেষ্টা করা হয়।

একটি সাধারণ ভুল হচ্ছে অতি দ্রুত বিস্তার করা। টিমগুলো অ্যাক্সেস রিকোয়েস্ট, ডিজাইন অনুরোধ, ক্রয় অনুমোদন, এবং বাগ রিপোর্ট সব এক প্রক্রিয়ায় মেশায়। এটা কার্যকর মনে হতে পারে, কিন্তু প্রতিটি অনুরোধ টাইপের আলাদা নিয়ম, মালিক, এবং সময়সীমা আছে।

আরেকটি ভুল হলো সর্বত্র থেকে অনুরোধ গ্রহণ করা। যদি মানুষ DM, র‌্যান্ডম চ্যানেল, এবং গ্রুপ চ্যাটে জিজ্ঞাসা করতে পারে, কেউ না কেউ পরে বিস্তারিত খোঁজার জন্য শিকার হয়ে থাকবে।

অত্যন্ত শীঘ্রই অটোমেট করা আরেকটি ফাঁদ। যদি অনুমোদন এখনও কেস-নির্ভর বিচার নির্ভর করে, অটোমেশন কেবল খারাপ সিদ্ধান্তগুলোকে দ্রুত করে তুলবে। আর যখন স্ট্যাটাস অদৃশ্য থাকে, মানুষ আবারও জিজ্ঞাসা করে কারণ তারা বলতে পারে না অনুরোধটি দেখা গেছে, অনুমোদিত, না অবরুদ্ধ।

একটি সহজ উদাহরণ দেখায় কিভাবে সবকিছু ভেঙে পড়ে। ধরা যাক একটি নতুন কর্মী অ্যাপ অ্যাক্সেস, একটি ল্যাপটপ, এবং Slack চ্যানেল আমন্ত্রণ দরকার। যদি প্রতিটি অংশ আলাদা মেসেজে আসে, টিম কাজের আগেই অনুরোধ জোড়া লাগাতে বেশি সময় ব্যয় করবে। যদি অনুমোদনের নিয়মও অস্পষ্ট হয়, একটি অটোমেটেড ধাপ ভুল ব্যক্তিকে পাঠাতে পারে বা এমন কিছু অনুমোদন করতে পারে যা প্রথমে পর্যালোচনা করা উচিত ছিল।

সমাধান সাধারণত বোরিং, এবং সেটা ভাল লক্ষণ। একটি অনুরোধ টাইপ দিয়ে শুরু করুন। একটি ইনটেক পথ ব্যবহার করুন। প্রতিবার একই মুল তথ্য চাও। অনুমোদনের নিয়ম এমনভাবে সহজ রাখুন যাতে একটি নতুন সদস্য অনুমান না করে তা অনুসরণ করতে পারে।

ততটাই গুরুত্বপূর্ণ, অগ্রগতি পরিষ্কারভাবে দেখান। এমনকি একটি মৌলিক স্ট্যাটাস যেমন গ্রহণ, পর্যালোচনা, বা সম্পন্ন ফলো-আপ মেসেজ কমায় এবং আস্থা তৈরি করে।

যদি একটি প্রক্রিয়া এখনও ঘনঘন ব্যতিক্রম চায়, তা ভারী অটোমেশনের জন্য প্রস্তুত নয়। নিয়মগুলো আগে পরিষ্কার করুন। তারপর শুধুমাত্র প্রতিবার কাজগুলো যেগুলো একই রকম হয় সেগুলো অটোমেট করুন।

স্কেল করার আগে দ্রুত চেকলিস্ট

আরো টিম, আরও অনুরোধ টাইপ বা ভারী অটোমেশন যোগ করার আগে বিরতি নিয়ে বেসিকগুলো পরীক্ষা করুন। যে প্রক্রিয়াটি সেটি তৈরি করেছে তাদের জন্য কাজ করে তা সব সময় অন্যদের জন্যও সহজ হবে এমন নয়।

কিছু সরল বিষয় চেক করুন:

• কি একটি পুরো নতুন রিকোয়েস্টকারী সাহায্য ছাড়া সাবমিট করতে পারে, কোথায় শুরু করতে হবে বা কী লিখতে হবে না জিজ্ঞেস করে?
• কি আবশ্যক ক্ষেত্রগুলো সংক্ষিপ্ত, সাধারণ এবং কেবল যা সত্যিই দরকার ততটাই সীমাবদ্ধ?
• কি প্রতিটি স্ট্যাটাসের একটি স্পষ্ট মালিক আছে?
• যখন অনুরোধটি স্বাভাবিক পথে ফিট করে না, কি সেখানে একটি সহজ ব্যাকআপ রুট আছে?
• কি আপনি জানেন কোন ধাপটি ম্যানুয়াল রাখা উচিত কারণ সেটি এখনও বিচার দাবি করে?

প্রথমটি অনেক টিমের চেয়ে বেশি গুরুত্বপূর্ণ। যদি একটি নতুন কর্মী বা ব্যস্ত ম্যানেজার নিজে থেকেই প্রক্রিয়াটি অনুসরণ করতে না পারে, সিস্টেমটি বড় করার যোগ্য নয়। ওয়ার্কফ্লোটি এমনভাবে লাগতে হবে যেন সেটা প্রথমবার দেখলেও বোঝা যায়।

ইনটেক সংক্ষিপ্ত রাখুন। মানুষ একটি রিকোয়েস্ট প্রক্রিয়া ব্যবহার করতে অনেক বেশি প্রস্তুত থাকে যখন ফর্মটি স্পষ্ট, উপকারী বিবরণ চায় পরিবর্তে পাঁচটি অতিরিক্ত প্রশ্ন যা প্রায়ই গুরুত্বহীন।

মালিকানা হলো যেখানে অনেক সিস্টেম ভেঙে পড়ে। “পর্যালোচনায়” বলতে ততটা বোঝা যায় না যতক্ষণ না একটি ব্যক্তি বা টিম আছে যে সেটিকে এগিয়ে নিয়ে যাবে। যদি কেউ একটি স্ট্যাটাসের মালিক না হয়, অনুরোধগুলো সেখানে আটকে থাকবে।

ব্যতিক্রমগুলোকেও যত্ন দরকার। সবসময়ই একটি অদ্ভুত কেস, জরুরি অনুরোধ, বা প্রেক্ষিতহীন ব্যক্তি থাকবে। এই কেসগুলোর জন্য একটি ব্যাকআপ পথ দিন যাতে তারা পুরো Slack কথোপকথনটিকে পুনরায় শুরু না করে।

এবং এখনও মানুষের সিদ্ধান্ত থাকা দরকার এমন ধাপগুলো রক্ষা করুন। খুব দ্রুত অটোমেশন চাপলে সাধারণত পুনরায় কাজ হয়, গতি নয়।

প্রক্রিয়াটিকে একটি বাস্তব পণ্য হিসেবে পরিণত করার পরবর্তী পদক্ষেপ

একবার ওয়ার্কফ্লো ম্যানুয়ালি কাজ করলে, সরাসরি কোনো বড় সিস্টেমে ঝাঁপ দিয়া দেবেন না। একটি কিউ এবং একটি পুনরাবৃত্ত অনুরোধ রাখুন, এবং সেই পথটিকে আগে ভালভাবে মসৃণ করুন। এটা recurring Slack কাজকে নির্ভরযোগ্য কিছুতে পরিণত করার নিরাপদ উপায়।

আপনি ইতিমধ্যেই যে রিকোয়েস্টগুলো পান সেগুলোকে গাইড হিসেবে ব্যবহার করুন। যদি মানুষ বারবার একই তথ্য বাদ দেয়, তার জন্য একটি ফিল্ড যোগ করুন। যদি রিভিউয়াররা একই সিদ্ধান্ত বারবার নিচ্ছে, সেই সিদ্ধান্তটিকে একটি সরল নিয়মে পরিণত করুন। প্রকৃত ট্রাফিক আপনাকে দেখায় কি প্রক্রিয়াতে থাকা উচিত এবং কি কেবল নয়েজ।

একটি ভাল পরবর্তী সংস্করণ সাধারণত কেবল কয়েকটি জিনিস যোগ করে:

• একটি আরও পরিষ্কার রিকোয়েস্ট ফর্ম
• স্ট্যাটাস আপডেট যা মানুষ Slack ছাড়াই দেখতে পারে
• সাধারণ কেসগুলোর জন্য মৌলিক অনুমোদন নিয়ম
• যখন অন্য টিমকে কাজ নিতে হবে তখন একটি সহজ হ্যান্ডঅফ
• কী চাওয়া হয়েছিল এবং কখন তা রেকর্ড করার একটি লঘু ইতিহাস

অটোমেশন ছোট টুকরোতে যোগ করুন। যদি অ্যাক্সেস রিকোয়েস্টগুলো সবসময় ম্যানেজার অনুমোদন আগে লাগে, ঐ ধাপটি অটোমেট করুন। যদি কিছু অনুরোধ এখনও বিচার দাবি করে, সেগুলো ম্যানুয়ালই রাখুন। লক্ষ্য সবকিছু অটোমেট করা নয়; লক্ষ্য হলো পুনরাবৃত্ত ধাপগুলো অপসারণ করা এবং ব্যতিক্রমগুলো দৃশ্যমান রাখা।

যদি ওয়ার্কফ্লো বাড়তে থাকে, তাহলে এটি সম্ভবত নিজের একটি অভ্যন্তরীণ অ্যাপের যোগ্য। Koder.ai-এর মতো টুলগুলো এখানে সাহায্য করতে পারে। টিমগুলো চ্যাট ব্যবহার করে প্রক্রিয়ার জন্য একটি সাধারণ ওয়েব, সার্ভার, বা মোবাইল অ্যাপ তৈরি করতে পারে, তারপর নতুন অনুরোধ প্যাটার্নগুলো দেখা দিলে সেটি পরিমার্জন করে, Slack-এ আরও কাজ বাড়ানো নয়।

সেরা অভ্যন্তরীণ পণ্যগুলো সাধারণত ছোটে শুরু করে: একটি কিউ, একটি রিকোয়েস্ট টাইপ, বাস্তব ব্যবহার, তারপর মনোযোগ সহকারে সম্প্রসারণ। এটা এক সপ্তাহে ধীর মনে হতে পারে, কিন্তু পরের বছরে অনেক দ্রুত ফল দেয়।