ব্যবসায়িক অ্যাপের ডেটাবেসে অনাথ রেকর্ড এড়ানোর উপায়

অনাথ রেকর্ড কীভাবে দৈনন্দিন সমস্যা তৈরি করে

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

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

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

এর বাস্তব প্রভাবগুলো হলো:

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

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

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

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

প্রতিটি রেকর্ডে মালিকানা বলতে কী বোঝায় তা ঠিক করুন

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

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

রেকর্ড তৈরি করেছেন যিনি, তিনিই বর্তমান মালিক, এমন ধারণা করবেন না। একজন সমন্বয়কারী কোনো ইভেন্টের পর লিড যোগ করতে পারেন, কিন্তু ফলো-আপের দায়িত্ব থাকতে পারে বিক্রয় প্রতিনিধির। ইতিহাস গুরুত্বপূর্ণ হলে দুটি আলাদা ঘর রাখুন: «তৈরি করেছেন» ঘরটি কে রেকর্ড ঢুকিয়েছেন তা দেখাবে, আর «বর্তমান মালিক» ঘরটি এখন কার কাজ তা দেখাবে।

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

যৌথ মালিকানারও সীমা থাকা দরকার। «বিক্রয় ও সাপোর্ট» ধরনের লেবেল নমনীয় মনে হলেও দুই দলই অন্য দলের অপেক্ষায় থাকতে পারে। একাধিক ব্যক্তি রেকর্ড দেখতে, সম্পাদনা করতে বা এতে অবদান রাখতে পারলেও পরবর্তী কাজের জন্য একজন ব্যক্তি বা একটি টিমকে দায়ী করুন।

ঘরের পাশে সহজ ভাষায় সংজ্ঞাটি লিখুন। যেমন: «বর্তমান মালিক হলেন সেই ব্যক্তি, যিনি গ্রাহকের সঙ্গে পরবর্তী যোগাযোগের জন্য দায়ী।» এতে নির্মাতারা পরিষ্কার নিয়ম পান এবং কর্মীরা একইভাবে কাজ বরাদ্দ করতে পারেন।

ব্যবসায়িক অ্যাপ ডেটাবেস ডিজাইনে মালিকানা এমন একটি সম্পর্ক, যার যাচাই দরকার। অ্যাপের নিষ্ক্রিয় কর্মীকে মালিক হিসেবে বেছে নেওয়া বন্ধ করা উচিত এবং কোনো টিমে সক্রিয় সদস্য না থাকলে বিকল্প মালিক দেখানো উচিত। AppMaster-এর Data Designer-এ এই সম্পর্কগুলো মডেল করা যায় এবং Business Process-এর মাধ্যমে রেকর্ড তৈরি বা আপডেটের সময় একই নিয়ম প্রয়োগ করা যায়।

স্ক্রিন তৈরির আগে সম্পর্কের মানচিত্র তৈরি করুন

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

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

কাজের ডেটা ও রেফারেন্স ডেটা আলাদা রাখুন

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

একটি টিকিট কোনো পণ্য বিভাগের দিকে নির্দেশ করতে পারে, কিন্তু বিভাগটি টিকিটের মালিক নয়। প্রশাসক কোনো বিভাগ সরিয়ে দিলে সংশ্লিষ্ট টিকিটগুলোর জন্য নতুন বিভাগ বেছে নিতে বলা উচিত। টিকিটগুলো যেন সঙ্গে সঙ্গে মুছে না যায়।

প্রতিটি সম্পর্ক সহজ ভাষায় লিখে রাখুন:

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

কোথায় খালি মান গ্রহণযোগ্য তা ঠিক করুন

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

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

মানচিত্র ঠিকমতো কাজ করছে নিশ্চিত হওয়ার পর স্ক্রিন তৈরি করুন। তখন ফর্মে প্রয়োজনীয় ঘর বাধ্যতামূলক করা, অপ্রাসঙ্গিক বিকল্প লুকানো এবং পরে যার সন্ধান পাওয়া যাবে না এমন রেকর্ড তৈরি বন্ধ করা সহজ হবে।

নতুন রেকর্ডের জন্য নিয়ম তৈরি করুন

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

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

মানুষের বাস্তব কাজের ধরন অনুযায়ী নিয়ম ব্যবহার করুন:

• গ্রাহকের অঞ্চল বা পোস্টাল কোড অনুযায়ী অ্যাকাউন্ট বরাদ্দ করুন।
• বেছে নেওয়া পণ্য সামলানো টিমের কাছে অনুরোধ পাঠান।
• অফিস সময়ে নতুন টিকিট কিউতে পাঠান।
• যাঁর খোলা কাজ সবচেয়ে কম, পরবর্তী লিডটি তাঁকে দিন।
• ইমপোর্ট জমা দেওয়া কর্মী পর্যালোচনা না করা পর্যন্ত ইমপোর্ট করা রেকর্ড তাঁর কাছেই রাখুন।

বরাদ্দের কারণ সংরক্ষণ করুন। কোনো লিডে লেখা থাকতে পারে, «গ্রাহক Ontario বেছে নেওয়ায় North sales-এ বরাদ্দ করা হয়েছে।» এতে ম্যানেজার নিয়মটি ঠিকমতো কাজ করেছে কি না দেখতে পারেন এবং ভুল সংশোধনের সময় কর্মীরা কারণ বুঝতে পারেন। অনানুষ্ঠানিক মন্তব্য থেকে বরাদ্দের কারণ আলাদা রাখুন, যাতে পরে রিপোর্ট করা যায়।

সব রেকর্ড কোনো না কোনো নিয়মে পড়বে না। ফর্মে অবস্থান না থাকতে পারে, ইমপোর্টে অচেনা পণ্য কোড থাকতে পারে বা কিউর সবাই অনুপস্থিত থাকতে পারেন। এসব রেকর্ড মালিকহীন রাখবেন না। «বরাদ্দ দরকার» স্ট্যাটাসসহ পর্যবেক্ষণ করা ব্যতিক্রম কিউতে পাঠান এবং প্রতিটি কর্মদিবসে কিউটি দেখার দায়িত্ব নির্দিষ্ট টিমকে দিন।

রেকর্ড তৈরি হওয়ার একই প্রক্রিয়ার অংশ হিসেবে মালিকানা নিয়ম চালান। AppMaster-এ একটি ভিজ্যুয়াল Business Process রেকর্ড তৈরি করতে, মালিক বা কিউ বেছে নিতে, বরাদ্দের কারণ সংরক্ষণ করতে এবং দায়ী টিমকে জানাতে পারে। বৈধ মালিক নির্ধারণ বা ব্যতিক্রম কিউতে পাঠানো না হওয়া পর্যন্ত প্রক্রিয়াটি সম্পূর্ণ হওয়া উচিত নয়।

এতে অনুপস্থিত কাজ ও উত্তরহীন গ্রাহক অনুরোধ পরে পরিষ্কার করার সমস্যায় পরিণত হয় না।

কর্মী পরিবর্তনের জন্য পুনর্বণ্টনের নিয়ম লিখুন

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

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

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

একটি পুনর্বণ্টন নিয়মে উল্লেখ থাকা উচিত:

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

রেকর্ডের ইতিহাসে আগের মালিকের নাম রাখুন। বর্তমান মালিককে জানতে হতে পারে কে সর্বশেষ গ্রাহকের সঙ্গে কথা বলেছেন এবং ম্যানেজারের অডিট ট্রেইল দরকার হতে পারে। পুরোনো মান মুছে নতুন মান বসাবেন না। «দল বদলের কারণে ১২ জুন Maya Patel থেকে Jordan Lee-তে মালিকানা বদলেছে» ধরনের ইতিহাস বর্তমান দায়িত্বকে অস্পষ্ট না করেই প্রেক্ষাপট দেয়।

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

AppMaster-এর Data Designer-এ বর্তমান মালিক, আগের মালিক, হস্তান্তরের কারণ, অগ্রাধিকার ও পর্যালোচনার সময়সীমা মডেল করা যায়। কোনো কর্মীর স্ট্যাটাস বদলালে Business Process যোগ্য রেকর্ড সরিয়ে দিতে এবং ম্যানেজারের জন্য পর্যালোচনার কাজ তৈরি করতে পারে। এতে নিয়মটি শুধু হ্যান্ডওভার স্প্রেডশিটে নয়, অ্যাপের মধ্যেই থাকে।

নীরবে মুছে না দিয়ে আর্কাইভের ব্যবস্থা বেছে নিন

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

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

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

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

নিষ্ক্রিয় রেকর্ডকে সত্যিই নিষ্ক্রিয় করুন

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

সীমিত কিছু নিয়ন্ত্রিত কাজ অনুমোদন করুন:

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

সাধারণত ম্যানেজার বা প্রশাসকের ঠিক করা উচিত কে রেকর্ড পুনরুদ্ধার করতে পারবেন।

সংরক্ষণকাল নির্ধারণ করুন

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

AppMaster-এ Data Designer ব্যবহার করে Active, Closed এবং Archived-এর মতো স্ট্যাটাস মডেল করা যায়। Business Process নিয়ম সম্পাদনা বন্ধ করতে এবং দৈনন্দিন স্ক্রিন থেকে আর্কাইভ ডেটা লুকাতে পারে। এভাবে লিখিত নীতি অ্যাপের নিয়মিত আচরণে পরিণত হয়।

ব্যতিক্রমের জন্য এসকেলেশন পথ তৈরি করুন

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

«মালিকহীন গ্রাহক রেকর্ড» বা «মালিকানা পর্যালোচনা» নামে একটি নির্দিষ্ট ব্যতিক্রম কিউ তৈরি করুন। বৈধ মালিকহীন প্রতিটি রেকর্ড স্বয়ংক্রিয়ভাবে সেখানে পাঠান। এমন সাধারণ ইনবক্স এড়িয়ে চলুন, যা সবাই দেখতে পান কিন্তু কেউ নিজের দায়িত্ব মনে করেন না।

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

ঝুঁকি অনুযায়ী সময়সীমা দিন

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

উদাহরণ:

• মালিকহীন জরুরি সাপোর্ট কেস সঙ্গে সঙ্গে কিউতে পাঠান এবং ৩০ মিনিট পর কর্তব্যরত ম্যানেজারকে সতর্ক করুন।
• সক্রিয় মালিকহীন বিক্রয় সুযোগ পরবর্তী কর্মদিবসে পর্যালোচনা করুন।
• অসম্পূর্ণ ইমপোর্ট করা রেকর্ড পাঁচ কর্মদিবসের মধ্যে দেখুন।
• অ্যাকাউন্ট ম্যানেজার চলে যাওয়া অ্যাকাউন্টে পরবর্তী পরিকল্পিত গ্রাহক যোগাযোগের আগেই পুনর্বণ্টনের চিহ্ন দিন।

সময়সীমা পেরোলে নির্দিষ্ট ম্যানেজারকে জানান। তিনি কাজ না করলে নির্ধারিত সময় পর দ্বিতীয় ব্যক্তি বা টিমের কাছে পাঠান। ধাপ কম রাখুন, কারণ দীর্ঘ অনুমোদনের সিঁড়িতে গ্রাহক অপেক্ষা করেন।

ভুল বরাদ্দ জানানো সহজ করুন

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

AppMaster-এ Data Designer-এ স্ট্যাটাস ও মালিকের ঘর দিয়ে কিউ মডেল করা যায়। Business Process সময়সীমা নির্ধারণ করে ইমেইল, SMS বা Telegram বিজ্ঞপ্তি পাঠাতে পারে। কর্মীরা অ্যাপ থেকেই সমস্যা জানাবেন এবং প্রক্রিয়াটি সঠিক পর্যালোচনাকারীর কাছে পাঠাবে।

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

উদাহরণ: একজন বিক্রয় প্রতিনিধি প্রতিষ্ঠান ছাড়ছেন

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

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

খোলা কোট আগের প্রতিনিধির নয়, অ্যাকাউন্টের সঙ্গে সরবে। অ্যাকাউন্ট North territory lead-এর কাছে গেলে তার খোলা কোটও সেখানে যাবে। নতুন মালিক আগের প্রতিনিধির রেকর্ড খুঁজে না ঘেঁটে ডিলের ইতিহাস, যোগাযোগের তথ্য এবং পরবর্তী কাজ দেখতে পারবেন।

ড্রাফট কোটের নিয়ম আলাদা হওয়া দরকার। গ্রাহকের সঙ্গে যোগাযোগ, পরিকল্পিত ফলো-আপ বা সাম্প্রতিক আপডেট না থাকা ড্রাফট হয়তো আর কাজের যোগ্য নয়। ম্যানেজার সেটি মুছে না দিয়ে আর্কাইভ করতে পারেন। আর্কাইভ করা ড্রাফট রেফারেন্স হিসেবে থাকবে, কিন্তু সক্রিয় বিক্রয় তালিকা বা রিমাইন্ডার ভরাবে না।

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

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

লঞ্চের আগে মালিকানার নিয়ম পরীক্ষা করুন

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

সম্ভব হলে বাস্তবসম্মত ডেটার একটি কপি ব্যবহার করুন। বিভিন্ন ভূমিকার ব্যবহারকারী তৈরি করে সংশ্লিষ্ট রেকর্ড দিন, যেমন কনট্যাক্ট ও ডিলসহ একটি অ্যাকাউন্ট বা কাজ ও সংযুক্তিসহ একটি প্রজেক্ট। স্বাভাবিক কাজের পাশাপাশি অস্বাভাবিক পরিস্থিতিও পরীক্ষা করুন।

রেকর্ড অ্যাপে ঢোকার প্রতিটি পথ পরীক্ষা করুন

রেকর্ড শুধু মূল ফর্ম দিয়ে আসে না। কর্মীরা স্প্রেডশিট ইমপোর্ট করতে পারেন, ইন্টিগ্রেশন লিড যোগ করতে পারে বা রাতের স্বয়ংক্রিয় প্রক্রিয়া সাপোর্ট টিকিট তৈরি করতে পারে। প্রতিটি পথে মালিক দেওয়া বা যৌথ কিউতে পাঠানো হচ্ছে কি না নিশ্চিত করুন।

এই পরীক্ষাগুলো চালান:

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

বরাদ্দ করা বিক্রয় প্রতিনিধি ছাড়া ইমপোর্ট করা লিড খালি মালিক ঘরে পড়ে না থেকে সেলস কিউতে যাবে। খালি মালিকানা প্রায়ই ত্রুটি বার্তার চেয়ে কঠিনে চোখে পড়ে।

কর্মী পরিবর্তন ও বন্ধ কাজ অনুকরণ করুন

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

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

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

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

লঞ্চের আগে দ্রুত যাচাই

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

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

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

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

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

AppMaster-এ Business Process-এর মধ্যে এসব যাচাই তৈরি করে ডিপ্লয়মেন্টের আগে পরীক্ষা করুন। বৈধ মালিকহীন রেকর্ডের জন্য ব্যতিক্রম কিউ রাখুন এবং সেটি পরিষ্কার করার দায়িত্বে থাকা ব্যক্তির কাছে কিউর স্ট্যাটাস দৃশ্যমান করুন। কেউ না দেখলে কিউ শুধু সমস্যাটি আড়াল করে রাখে।

নিয়মগুলো ব্যবসায়িক অ্যাপে প্রয়োগ করুন

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

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

AppMaster হাতে অ্যাপ্লিকেশন কোড না লিখে এ ধরনের অভ্যন্তরীণ অ্যাপ তৈরিতে সাহায্য করে। Data Designer দিয়ে অ্যাকাউন্ট, কনট্যাক্ট, কাজ ও তাদের সম্পর্ক মডেল করুন। এরপর Business Process Editor দিয়ে পুনর্বণ্টনের অনুরোধ পাঠান, নতুন মালিক আছে কি না পরীক্ষা করুন এবং কোনো অনুরোধ বেশি সময় অপেক্ষা করলে ম্যানেজারকে জানান।

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

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

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

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