একটি ব্যবহারিক ডেটা রিটেনশন ও লিগ্যাল হোল ওয়ার্কফ্লো শিখুন যা মুছে ফেলার সময়সূচিকে অডিট চাহিদার সঙ্গে মিলায়, যাতে সারাজীবন ডেটা রাখার বদলে আপনি অনুগমন প্রমাণ করতে পারেন।
অধিকাংশ টিম একমত যে অনাবশ্যক হলে ডেটা মুছে ফেলা উচিত। এতে ঝুঁকি কমে, স্টোরেজ কমে এবং গোপনীয়তা নিয়ম মেনে চলা সহজ হয়। সমস্যা দেখা দেয় যখন কেউ প্রশ্ন করে, “আপনি কী প্রমাণ করতে পারবেন কী ঘটেছিল?” সেই প্রশ্ন আসতে পারে অডিটর, গ্রাহক অভিযোগ বা মামলায়।
একটি শক্তিশালী ডেটা রিটেনশন লিগ্যাল হোল ওয়ার্কফ্লো একটি জটিল টেনশন সমাধান করে: সময়মতো মুছে ফেলুন, কিন্তু বেসিক ডেটা না থাকলেও সিদ্ধান্ত, অ্যাক্সেস এবং কর্মকাণ্ড দেখাতে সক্ষম হন।
রিটেনশন হল কোনো ডেটা ক্যাটেগরিকে ব্যবসায়িক বা আইনগত কারণে কতক্ষণ রাখা হবে। ডিলিশন হল সেই সময় শেষ হলে আপনি কী করবেন — কপি ও ব্যাকআপ সহ মুছে ফেলা নির্দিষ্ট সময়সীমার মধ্যে। লিগ্যাল হোল হল নির্দিষ্ট রেকর্ডগুলোর জন্য মুছে ফেলা সাময়িকভাবে বন্ধ রাখা, কারণ কোনো বিবাদ, তদন্ত বা নিয়ম সেটি সংরক্ষণ করতে বলে।
“প্রমাণ রাখা” সবসময় পুরো ডেটা সখ্যা রেখে দেয়া নয়। প্রায়ই এর মানে হল এমন ছোট, নিরাপদ প্রমাণ রেখে দেওয়া যা অডিট সমর্থন করে কিন্তু মূল ব্যক্তিগত ডেটা পুনরায় তৈরি করে না। উদাহরণস্বরূপ, আপনি রাখতে পারেন:
লক্ষ্য হল একটি পুনরাবৃত্তিযোগ্য প্রক্রিয়া যা সিদ্ধান্ত নেয় কী মুছে যাবে, কী থামানো হবে, এবং কী হালকা ওজনের অডিট আর্টিফ্যাক্ট রাখা হবে।
এই নির্দেশিকা অপারেশনাল; আইনি পরামর্শ নয়। রিটেনশন পিরিয়ড এবং হোল ট্রিগারগুলোকে আপনার কেয়ারিং কনসাল্ট্যান্টদের সঙ্গে পর্যালোচনা করে শিল্প-বিধির সাথে মিলিয়ে নিন।
আপনি যদি জানেন না কী রাখছেন, পরিষ্কার মুছে ফেলার সময়সূচি বা লিগ্যাল হোল চালানো কঠিন। সংগ্রহিত ডেটার ধরণ তালিকা করে শুরু করুন, তারপর প্রতিটি সিস্টেম তালিকাভুক্ত করুন যেখানে সেগুলো সংরক্ষিত বা কপি করা হয়।
“ডাটাবেস” ছাড়াও ভাবুন। কাস্টমার প্রোফাইল আপনার অ্যাপ ডাটাবেসে থাকতে পারে, কিন্তু একই বিবরণ সাপোর্ট টিকেট, ইমেইল থ্রেড, চ্যাট টুল, এক্সপোর্ট করা স্প্রেডশীট বা ফাইল অ্যাটাচমেন্টে থাকতে পারে। লগ, ব্যাকআপ এবং অ্যানালিটিক্স প্রায়ই অতিরিক্ত কপি রাখে যেগুলো মানুষ ভুলে যায়।
একটি সহজ উপায় হল প্রতিটি ডেটাসেট লিখে সেটা সম্পর্কে তিনটি প্রশ্নের উত্তর দেওয়া: এটি কোথায় তৈরি হয়, কোথায় কপি করা হয়, এবং কে এটি মুছতে পারে।
আপাতত সেই উৎসগুলোর উপর ফোকাস করুন যেগুলো পরে বিস্ময় সৃষ্টি করে:
প্রতিটি জায়গায় একসঙ্গে এক মতাভিন্ন আচরণ দরকার নয়। নির্ধারণ করুন ওয়ার্কফ্লো এখন কী কভার করে এবং পরে কী যোগ করা হবে।
একটি ব্যবহারিক প্রথম স্কোপ সাধারণত সেই সিস্টেমগুলোকে অন্তর্ভুক্ত করে যা আপনি নিয়ন্ত্রণ করেন (যেখানে আপনি সময়মতো মুছে ফেলতে পারেন), সেই সিস্টেমগুলো যেগুলোকে লিগ্যাল হোলে খোঁজা হবে, এবং সেই সিস্টেমগুলো যেগুলো ডিলিশনের পরে কেবলমাত্র অডিট প্রমাণ রাখে।
কোনটি আউট-অফ-স্কোপ তাও লিখে রাখুন (উদাহরণ: ল্যাপটপে ব্যক্তি-স্বত্বাভিমুখ নোট)। সেই ফাঁকগুলোঠাই থেকে সাধারণত “সবকিছু চিরকাল রাখি” মনোভাব শুরু হয়।
ভুল বোঝাবুঝি প্রায়ই আসে যখন একেই শব্দ বিভিন্ন অর্থে ব্যবহার করা হয়। আগে থেকেই সংজ্ঞায় একমত হন যাতে ওয়ার্কফ্লো চালানো এবং রক্ষা করা সহজ হয়।
রিটেনশন সময়সূচি একটি প্রশ্নের উত্তর দেয়: প্রতিটি ডেটা টাইপ কতক্ষণ রাখবো? এটি সাধারণত আইন, চুক্তি বা ব্যবসায়িক প্রয়োজন অনুযায়ী নির্ধারিত। এটি স্পষ্ট হওয়া উচিত (উদাহরণ: সাপোর্ট টিকেট ২ বছর, ইনভয়েস ৭ বছর, অ্যাপ্লিকেশনের লগ ৩০ দিন)।
ডিলিশন সময়সূচি হল এক্সিকিউশন প্ল্যান। এটি উত্তর দেয়: কখন ডিলিশন হবে এবং কীভাবে চলবে? কিছু টিম নাইটলি ব্যাচে মুছে ফেলে, অন্যরা রোলিং ভিত্তিতে মুছে ফেলে, এবং অনেকেই ইভেন্ট-ভিত্তিক ডিলিশন ব্যবহার করে (যেমন “অ্যাকাউন্ট ক্লোজের ৩০ দিন পরে”)। রিটেনশন সময়সূচি হল নিয়ম; ডিলিশন সময়সূচি হল সেই নিয়ম প্রয়োগের রুটিন।
লিগ্যাল হোল হল একটি নির্দিষ্ট মামলা, অভিযোগ, তদন্ত বা মামলা সম্পর্কিত মুছে ফেলা স্থগিত করার একটি টার্গেটেড পদ্ধতি। এটি স্কোপ (কোন ব্যক্তি, অ্যাকাউন্ট, সিস্টেম বা তারিখ সীমা প্রযোজ্য) এবং মালিকানা (কে অনুমোদন করেছে) অন্তর্ভুক্ত করে। লিগ্যাল হোল মানে সব জায়গায় মুছে ফেলা বন্ধ করা নয়; বরং শুধু প্রভাবিত রেকর্ডগুলোর জন্য মুছে ফেলা থামানো।
অডিট প্রয়োজনীয়তা হল যা আপনাকে পরে দেখাতে হবে: কে কী করেছে, কখন হয়েছে, এবং কেন তা অনুমোদিত ছিল। অডিট সাধারণত প্রতিটি রেকর্ড চিরকাল রাখার চেয়ে একটি নিয়ন্ত্রিত, ধারাবাহিক প্রক্রিয়ার প্রমাণ দেখতে বেশি আগ্রহী।
ভাষাটি সহজ রাখুন:
একটি রিটেনশন সময়সূচি ব্যর্থ হয় যখন এটি আইন বইয়ের মত পড়ে বা কেউ জানে না কে কী সিদ্ধান্ত নেয়। প্রতিটি ডেটা টাইপের জন্য লিখে রাখুন কেন রাখছেন, কতক্ষণ রাখছেন, কী শুরু করে ঘড়ি, এবং কে নিয়মের মালিক।
ডেটা গ্রুপ করুন ব্যবসায়িক উদ্দেশ্যে অনুযায়ী, সিস্টেমের অবস্থানের উপর নয়। “ইনভয়েস” একটি স্পষ্ট ক্যাটেগরি, “টেবিল X-এর সারি” থেকে। ক্যাটেগরিগুলোর সংখ্যা সীমিত রাখুন যাতে ব্যস্ত কেউ দ্রুত স্ক্যান করতে পারে।
মালিকানা স্পষ্ট করুন। ফাইন্যান্স অনুমান করবে না সাপোর্টকে কি দরকার, সাপোর্ট HR নিয়ম নির্ধারণ করবে না। প্রতিটি ক্যাটেগরির জন্য একটি মালিক দিন যিনি পরিবর্তন অনুমোদন করবেন এবং প্রশ্নের উত্তর দেবেন।
ট্রিগারগুলো সময়ের মতোই গুরুত্বপূর্ণ। “৭ বছর” অর্থহীন যদি না আপনি নির্দিষ্ট করেন কখন তা শুরু হবে: অ্যাকাউন্ট ক্লোজ, চুক্তি শেষ, শেষ লগইন, শেষ পেমেন্ট, শেষ টিকেট আপডেট। সম্ভব হলে প্রতি ক্যাটেগরির জন্য একটিই ট্রিগার বেছে নিন।
অবশেষে, ব্যতিক্রমগুলো স্পষ্টভাবে লিখুন। এগুলোই মুছে ফেলা থামায়: বিবাদ, চার্জব্যাক, তদন্ত, এবং অ্যাক্টিভ লিগ্যাল হোল। যদি ব্যতিক্রম অস্পষ্ট হয়, মানুষ সবকিছুই ব্যতিক্রম ভাববে।
এই সহজ টেবিল ফর্ম্যাট অনেক টিম বাস্তবে ব্যবহার করে:
| ডেটা ক্যাটেগরি | ব্যবসায়িক উদ্দেশ্য | রিটেনশন পিরিয়ড | ট্রিগার (ঘড়ি শুরু) | মালিক | ব্যতিক্রম (মুছে ফেলা থামান) |
|---|---|---|---|---|---|
| কাস্টমার ইনভয়েস | কর ও হিসাবরক্ষণ | ৭ বছর | ইনভয়েস পেইড/ইস্যু | ফাইন্যান্স | ট্যাক্স অডিট নোটিশ, বিবাদ |
| সাপোর্ট টিকেট | কাস্টমার সার্ভিস ইতিহাস | ২৪ মাস | টিকেট ক্লোজ | সাপোর্ট | খোলা বিবাদ, ফ্রড রিভিউ |
| ইউজার অ্যাকাউন্ট প্রোফাইল | সেবা প্রদান | ৩০ দিন | অ্যাকাউন্ট ক্লোজ | প্রোডাক্ট | অ্যাক্টিভ লিগ্যাল হোল, চার্জব্যাক উইন্ডো |
| অ্যাক্সেস লগ | সিকিউরিটি মনিটরিং | ৯০ দিন | লগ তৈরি | সিকিউরিটি/IT | ইনসিডেন্ট তদন্ত |
একটি ভালো ডেটা রিটেনশন লিগাল হোল ওয়ার্কফ্লোর উদ্দেশ্য একটাই: ডিফল্ট হিসেবে সময়মতো মুছে ফেলা, কিন্তু শুধুমাত্র সেই রেকর্ডগুলো থামানো যা সংরক্ষণ করতে হবে। সবচেয়ে নির্ভরযোগ্য পদ্ধতি হল রিটেনশন, ডিলিশন এবং হোলকে আলাদা ইভেন্ট হিসাবে দেখা এবং এদের জন্য একটি সাধারণ অডিট লগ রাখা।
রিটেনশন রুল তৈরি বা আপডেট করুন (মালিক সহ)। ডেটাসেট, কারণ (চুক্তি, কর, সাপোর্ট) এবং রিটেনশন পিরিয়ড নির্ধারণ করুন। কে অনুমোদন করেছে এবং কার্যকর তারিখ ক্যাপচার করুন।
নির্দিষ্ট স্কোপসহ ডিলিশন জব চালান। রুলগুলোকে স্বয়ংক্রিয় জবে রূপান্তর করুন যা নির্দিষ্ট ফিল্ড, টেবিল, ফাইল এবং সার্চ ইনডেক্স ডিলিট বা অ্যানোনিমাইজ করে। আপনার সংস্থায় “মুছে ফেলা” মানে কি (হার্ড ডিলিট, সফট ডিলিট বা অপরিবর্তনীয় অ্যানোনিমাইজেশন) এবং কোন সিস্টেম অন্তর্ভুক্ত তা স্পষ্ট করুন।
লিগ্যাল হোল লাগান (শুধু প্রাসঙ্গিক অংশ ফ্রিজ করুন)। কোনো বিবাদ, তদন্ত বা রেগুলেটর অনুরোধ এলে একটি হোল রেকর্ড তৈরি করুন যা একটি ব্যক্তি, অ্যাকাউন্ট, কেস আইডি, তারিখ পরিসীমা এবং ডেটা টাইপ টার্গেট করে। ডিলিশন জবকে কেবল মিল থাকা রেকর্ডগুলোই স্কিপ করতে হবে, পুরো ডাটাবেস নয়।
হোল মুক্ত করুন (তারপর নিরাপদে ডিলিশন আবার চালান)। লিগ্যাল নিশ্চিত করলে হোল শেষ চিহ্নিত করুন। ডিলিশন আবার চালানোর আগে স্কোপ সঠিক কিনা এবং কোনো নতুন হোল ওভারল্যাপ নেই কি না তা নিশ্চিত করুন।
প্রতিটি কর্ম লগ করুন। রিটেনশন পরিবর্তন, ডিলিশন রান, হোল বসানো, হোল মুক্ত করা এবং ম্যানুয়াল ব্যতিক্রম সবই লগ করুন। প্রতিটি এন্ট্রি-তে টাইমস্ট্যাম্প, অভিনেতা, অনুমোদনকারী, স্কোপ এবং আউটকাম (সফল বা ব্যর্থ) থাকা উচিত।
অনুমোদনই যেখানে ওয়ার্কফ্লো সাধারণত ভেঙে যায়। ভূমিকা পরিষ্কার রাখুন:
উদাহরণ: একটি সাপোর্ট ম্যানেজার চ্যাট ট্রান্সক্রিপ্টের রিটেনশন ২৪ মাস থেকে ১২ মাসে বদলানোর সিদ্ধান্ত নেন অনুমোদনের পরে। সাপ্তাহিক ডিলিশন জব ১২ মাসের বেশি পুরনো ট্রান্সক্রিপ্টগুলো মুছে দেয়। দুই মাস পরে লিগ্যাল একজন গ্রাহকের বিরুদ্ধে বিবাদে হোল বসায়, তাই কেবল ওই গ্রাহকের ট্রান্সক্রিপ্টগুলো ফ্রিজ হয়; বাকিরা নির্ধারিত সময়মতো মুছে যায়।
একটি লিগাল হোল কেবল প্রাসঙ্গিক রেকর্ডগুলোই থামানো উচিত, নির্দিষ্ট সময় পর্যন্ত। যদি হোল হয়ে যায় “সবকিছুই থামান”, আপনি খরচ, ঝুঁকি এবং বিভ্রান্তি তৈরি করেন।
স্কোপ দিয়ে শুরু করুন। একটি হোল নির্দিষ্ট ব্যবহারকারী, অর্ডার, সাপোর্ট টিকেট, প্রকল্প, মেইলবক্স, ফোল্ডার বা তারিখ পরিসীমায় সীমাবদ্ধ হতে পারে যেমন “মার্চ ১ থেকে এপ্রিল ১৫ পর্যন্ত মেসেজ”। যত সংকীর্ণ স্কোপ হবে, তত সহজে রক্ষা করা যাবে এবং তত কম ডেটা রাখতে হবে।
আকস্মিক মুছে ফেলা প্রতিরোধ করতে হোল মেশিন-পঠনযোগ্য করুন। সাধারণত এর মানে প্রতিটি রেকর্ডে একটি হোল ফ্ল্যাগ এবং হোল আইডি রাখা (বা কেস বা অর্ডার অবজেক্টে) যাতে ডিলিশন জবের একটি কঠিন নিয়ম থাকে: যদি HoldActive = true হয় তবে ডিলিশন স্কিপ করুন এবং লগ করুন যে এটি হোলের কারণে স্কিপ হয়েছে।
হোল শুরু হওয়ার পরে নতুন ডেটা একটি সাধারণ ফাঁদ। শুরুতেই সিদ্ধান্ত নিন হোলটি হবে:
বিবাদের ক্ষেত্রে, অনগোয়িং হোল প্রায়ই নিরাপদ—উদাহরণ: “কেস চলতে থাকা অবস্থায় গ্রাহক X-এর নতুন টিকেটগুলিও”।
দুইটি ঘড়ি ভাবুন। রিটেনশন ঘড়ি নির্ধারণ করে কখন ডেটা ডিলিটের যোগ্য হবে। হোল ঘড়ি নির্ধারণ করে এখন ডিলিশন অনুমোদিত কি না। রিটেনশন পিছনে ধরে বাড়তে থাকে, কিন্তু হোল চূড়ান্ত ডিলিট অ্যাকশন ব্লক করে। হোল শেষ হলে, রিটেনশন পেরিয়ে থাকা আইটেমগুলো অবিলম্বে যোগ্য হবে।
হোল ডকুমেন্ট করার সময় যথেষ্ট লিখুন “কেন” বোঝানোর জন্য কিন্তু অতিরিক্ত তথ্য শেয়ার করবেন না। সংক্ষিপ্ত রাখুন: অনুরোধকারী, তারিখ, স্কোপ এবং সাদাসিধে কারণ যেমন “বিলিং বিবাদ” বা “চাকরির দাবি”।
অডিটর সাধারণত মুছে ফেলা ডেটা নিজেই চান না। তারা প্রমাণ চান যে আপনার প্রক্রিয়া নিয়ন্ত্রিত ছিল: কে সিদ্ধান্ত নিয়েছে, কী মুছে ফেলা হয়েছে, কখন হয়েছে এবং কেন তা অনুমোদিত ছিল।
ডিলিশন ইভেন্টগুলোকে আর্থিক লেনদেনের মতো লগ করুন। রেকর্ডটি কয়েক মাস পরে এমন প্রশ্নেও বোধগম্য থাকা উচিত, এমনকি টিমে না থাকা কাউকে দেখালেও।
প্রতিটি ডিলিশন (বা অ্যানোনিমাইজেশন) ইভেন্টের জন্য মৌলিক বিষয়গুলো ক্যাপচার করুন:
অপারেশনাল প্রমাণও রাখুন যে জব রান করেছে এবং সম্পন্ন হয়েছে, কন্টেন্ট না রেখে:
“ব্যাকআপে কপি রেখে দিন” মানসিকতা এড়াতে পুরো রেকর্ড অডিট ডাটাবেসে কপি না করুন। সেটি একটি দ্বিতীয় সিস্টেম তৈরি করে যাকে আপনাকেও মুছে যেতে হবে।
অডিট লগগুলোর জন্য একটি স্পষ্ট রিটেনশন পিরিয়ড ও অ্যাক্সেস নিয়ম রাখুন। অনেক টিম বিস্তারিত লগ ১২ থেকে ২৪ মাস রাখে, তারপর প্রয়োজনে একটি ছোট মাসিক সারাংশ বেশি সময় রেখে দেয়। অ্যাক্সেস সীমাবদ্ধ রাখুন (সিকিউরিটি, কমপ্লায়েন্স এবং কয়েকজন অ্যাডমিন) এবং লগের অ্যাক্সেসও লগ করুন।
অডিট সহজ করতে, কয়েকটি সরল রিপোর্ট প্রস্তুত করুন যা দ্রুত তৈরি করা যায়: একটি মাসিক ডিলিশন সারাংশ, একটি ব্যতিক্রম তালিকা (অ্যাকটিভ হোল, ব্লকড জব, অনসোলভড ব্যর্থতা), এবং শীর্ষ ডিলিশন কারণের ব্রেকডাউন।
উদাহরণ: যদি জুলাই মাসে ১,২৪০টি ক্লোজড অ্যাকাউন্ট মুছে ফেলা হয়, আপনার প্রমাণ হতে পারে একটি জব রান রেকর্ড যা দেখায় কে রান অনুমোদন করেছে, ব্যবহৃত রিটেনশন রুল, গণনা, কমপ্লিশন স্ট্যাটাস, এবং ১২টি অ্যাকাউন্টের ব্যতিক্রম তালিকা যেগুলো অ্যাকটিভ লিগ্যাল হোলের কারণে ব্লক ছিল।
অধিকাংশ রিটেনশন প্রোগ্রাম ব্যর্থ হয় একটি কারণে: যখন কিছু ঝুঁকিপূর্ণ মনে হয়, মানুষ মুছে ফেলা বন্ধ করে দেয়। তারপর “অস্থায়ী” ব্যতিক্রমগুলো জমে যায় যতক্ষণ না কিছুই আর যায় না।
একটি বড় ব্লাইন্ড স্পট হল ব্যাকআপ, রেপ্লিকা এবং আর্কাইভ স্টোরেজ। টিমগুলো প্রধান রেকর্ড মুছে ফেলে কিন্তু স্ন্যাপশট বা রিড রেপ্লিকায় পুরোনো কপি ভুলে যায়। আপনার নীতিতে স্পষ্ট করুন “মুছে ফেলা” মানে কী: প্রায়শই এর মানে হলো প্রডাকশন কপি দ্রুত মুছে ফেলা এবং ব্যাকআপগুলো আলাদা, নির্দিষ্ট টাইমলাইন অনুসারে পুরোনো হয়ে যাওয়া।
আরেকটি ব্যর্থতা হল পুরো সিস্টেমে “তোড়ে” লিগ্যাল হোল বসানো। এটি অনান্য ডেটা ফ্রিজ করে এবং প্রতিটি ভবিষ্যতের ডিলিশনকে বিপজ্জনক করে তোলে। হোলগুলোকে নির্দিষ্ট ব্যক্তি, তারিখ সীমা, রেকর্ড টাইপ এবং সেই সিস্টেমগুলোর মধ্যে সীমাবদ্ধ করুন যেগুলো সত্যিই প্রাসঙ্গিক ডেটা রাখে।
মালিকানা ফাঁকও স্থায়ী হোলের কারণ হয়। যদি কেউ হোল অনুমোদন, ডকুমেন্ট এবং রিলিজ করার জন্য দায়ী না থাকে, তা কখনও শেষ হবে না। হোলগুলোকে একটি নিয়ন্ত্রিত পরিবর্তন হিসেবে বিবেচনা করুন এবং নামযুক্ত ভূমিকা দিন।
এক্সপোর্ট হল নীরব রিটেনশন কিলার। আপনি অ্যাপে ডেটা মুছে ফেলতে পারেন এবং তবুও তা চিরকাল স্প্রেডশীট, ইমেইল অ্যাটাচমেন্ট, শেয়ারড ড্রাইভ বা অ্যাড-হক BI এক্সট্র্যাক্টে বেঁচে থাকতে পারে।
কয়েকটি ব্যবহারিক সমাধান “সব কিছু রাখা” আচরণ রোধ করে:
লগিং একটি ভারসাম্যহীন কাজ: কম হলে আপনি প্রক্রিয়া প্রমাণ করতে পারবেন না; বেশি হলে আপনার লগই নিজেই একটি নতুন গোপনীয়তা সমস্যা হয়ে দাঁড়াবে।
বাস্তবে একটি ডিলিশন সময়সূচিতে ভরসা করার আগে একটি “আপনি কি প্রমাণ করতে পারবেন” টেস্ট চালান। ওয়ার্কফ্লোটি সবচেয়ে দুর্বল হ্যান্ডঅফ যতটা শক্তিশালী নিজের মতোই: অনুপস্থিত মালিক, নীরব ব্যাকআপ, বা ভুল কিছু মুছে ফেলা করা জব।
প্রক্রিয়াটি ব্যবহার করবে এমন লোকজন (লিগ্যাল, সিকিউরিটি, IT, এবং ডেটার ব্যবসায়িক মালিক) নিয়ে একটি ছোট টেবিলটপ অনুশীলন চালান।
যদি কোনো আইটেম উত্তর দিতে কষ্ট হয়, নিয়মিতভাবে কড়া করে নিন আগে এটি রেগুলেটর, অডিটর বা কোর্ট দ্বারা পরীক্ষিত হওয়ার আগে।
একটি বাস্তব ডেটা অবজেক্ট (উদাহরণ: কাস্টমার প্রোফাইল) বেছে নিন এবং এটির পুরো পথ অনুসরণ করুন: কোথায় তৈরি হয়, কোথায় কপি হয়, এবং কিভাবে মুছে ফেলা হয়। তারপর একটি কেস আইডি-সম্পৃক্ত লিগ্যাল হোল রাখুন, একটি ডিলিশন জব চালান, হোল মুক্ত করুন, এবং আবার ডিলিশন চালান। রিপোর্ট সংরক্ষণ করুন এবং পরীক্ষা করুন সেটি কি আপনার টিমের বাইরে কারো দ্বারা পড়ার উপযোগী।
একজন গ্রাহক ১ মার্চে তাদের অ্যাকাউন্ট বন্ধ করেন। আপনার নীতি বলে: প্রোফাইল ডেটা ৩০ দিন পরে মুছে ফেলা হবে, সাপোর্ট কথোপকথন ৯০ দিন পরে মুছে যাবে, এবং ইনভয়েস ৭ বছর রাখা হবে (কর ও আর্থিক নিয়ম প্রায়শই এটি দাবি করে)।
২০ এপ্রিল একই গ্রাহক ফেব্রুয়ারির একটি ইনভয়েস নিয়ে বিলিং বিতর্ক জমা দেন। এখানে ওয়ার্কফ্লোটি স্পষ্টভাবে কাজ করা উচিত, ভয়ঙ্কর নয়।
আপনি একই সময়ে দুটি কাজ করবেন। আপনি সম্পর্কহীন সবকিছুর জন্য সাধারণ ডিলিশন চালিয়ে রাখবেন। একই সঙ্গে আপনি বিতর্ক প্রমাণ করার জন্য ছোট একটি রেকর্ড সেটে লিগ্যাল হোল বসাবেন।
সময়সূচি অনুযায়ী মুছে ফেলা হবে এমন জিনিসগুলোর মধ্যে থাকতে পারে: মার্কেটিং পছন্দ, বিলিংয়ের সাথে সম্পর্কিত নয় এমন পুরনো চ্যাট, আপনার অ্যানালিটিক্স উইন্ডোর বাইরে পণ্য ব্যবহারের ইভেন্ট, এবং অন্তর্ভুক্ত নোট যা বিলিং সিদ্ধান্তের অংশ নয়।
যা আপনি প্রমাণ হিসেবে রাখবেন এবং হোল লাগাবেন:
হোলটি টার্গেটেড হওয়া উচিত: কেবল ইনভয়েস এবং সম্পর্কিত সাপোর্ট টিকেট। গ্রাহকের পুরো অ্যাকাউন্ট যদি না লাগে তবে সেটি ফ্রিজ করা উচিত নয়।
বিবাদ সমাধান হলে, হোল মুক্ত করুন, ফলাফল লিখে রাখুন (অনুমোদিত, প্রত্যাখ্যাত, আংশিক রিফান্ড), এবং ধরে রাখা আইটেমগুলোর জন্য কোন মুশকিল ছিল তা মিটে গেলে মুছে ফেলার কাজ পুনরায় চালান।
একজন অডিটরের প্রশ্ন সাধারণত মৌলিক: কী মুছে ফেলা হয়েছে, কেন, এবং কিভাবে আপনি বিবাদী রেকর্ডগুলোর মুছে ফেলা রোধ করেছেন। আপনার কাছে থাকা উচিত রিটেনশন রুলগুলো, হোল শুরু ও শেষের তারিখ, ধরে রাখা রেকর্ড আইডি-র তালিকা, এবং ইভেন্ট ট্রেইল যা দেখায় অন্য সবকিছু সময়মতো মুছে ফেলা হয়েছে।
একটি রিটেনশন নীতি তখনই কাজ করে যখন তা রুটিন কাজ হয়ে ওঠে। ছোট থেকে শুরু করুন, প্রমাণ করুন, তারপর বাড়ান। একটি ডেটা টাইপ বেছে নিন (উদাহরণ: সাপোর্ট টিকেট), একটি সিস্টেম এবং একটি রিপোর্ট যা দেখায় কী মুছে ফেলা হয়েছে, কী ধরে রাখা হয়েছে, এবং কেন।
২ থেকে ৪ সপ্তাহ একটি ছোট পাইলট চালান এবং ঘর্ষণ খুঁজুন: অস্পষ্ট মালিক, অনুপস্থিত অনুমোদন, এবং দেরিতে আসা হোল অনুরোধ। সেগুলো ঠিক করে নিন তারপর পরবর্তী সিস্টেমে প্রসারিত করুন।
একটি রোলআউট পরিকল্পনা যা চাপের মধ্যে টিকিয়ে রাখে:
হোল পদ্ধতিটা এত সংক্ষিপ্ত রাখুন যে মানুষ তা ব্যবহার করবে। এক পৃষ্ঠা যথেষ্ট যদি এতে উত্তর থাকে: কে হোল অনুরোধ করতে পারে, কে অনুমোদন করে, কী থাকতে হবে (স্কোপ, কারণ, শুরু তারিখ), এবং শেষে কী ঘটে।
হোলগুলো ডিফল্টভাবে খুলে থাকা যাবেনা। রিমাইন্ডার যোগ করুন যা সিদ্ধান্ত নিতে বাধ্য করে: হোল নবায়ন করুন কারণসহ, সংকীর্ণ করুন, বা বন্ধ করুন।
যদি আপনি ইমেইল ও স্প্রেডশীট দিয়ে অনুমোদন, অডিট লগ এবং ডিলিশন রান পরিচালনা করেন, তবে ওয়ার্কফ্লোকে একটি অভ্যন্তরীণ অ্যাপে রাখা বিবেচনা করুন যাতে প্রক্রিয়া ধারাবাহিক হয়। অনেক দল কখনো কখনো এই ধরনের রিটেনশন-এবং-হোল ট্র্যাকার AppMaster-এ নির্মাণ করে যাতে রুল, হোল এবং অডিট লগ এক জায়গায় থাকে এবং ডিলিশন জবগুলো নির্ভরযোগ্যভাবে হোল থাকা রেকর্ডগুলো স্কিপ করে অন্য সবকিছু পরিষ্কার করে।
১০ মার্চ, ২০২৬
8 মিনিট
০৮ মার্চ, ২০২৬8 মিনিট
০৭ মার্চ, ২০২৬11 মিনিটবিনামূল্যের পরিকল্পনা সহ অ্যাপমাস্টারের সাথে পরীক্ষা করুন।
আপনি যখন প্রস্তুত হবেন তখন আপনি সঠিক সদস্যতা বেছে নিতে পারেন৷
