অ্যাসেট রেজিস্টার অ্যাপ দিয়ে ডিপ্রিসিয়েশন ও ডিসপোজাল অনুমোদন ট্র্যাক করুন

কেন টিমগুলোর একটি কর্মপ্রবাহসহ অ্যাসেট রেজিস্টার দরকার

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

একটি উপযুক্ত অ্যাসেট রেজিস্টার অ্যাপ সেই দুইটি বড় ফাঁক পূরণ করে যা স্প্রেডশিট তৈরি করে: ইতিহাস এবং জবাবদিহিতা। প্রত্যেক অ্যাসেটের একক রেকর্ড থাকা উচিত স্পষ্ট স্ট্যাটাস (in service, in repair, missing, disposed), পরিচিত কাস্টোডিয়ান, এবং ট্রেসযোগ্য পরিবর্তনসহ। যখন কেউ লোকেশন, খরচ, বা ব্যবহারের আয়ু আপডেট করে, আপনি দেখতে পাবেন কে কখন পরিবর্তন করেছে।

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

টিম সাধারণত তখনই এই সন্ধানে যায় যখন এই ধরনের ট্রিগার আসে:

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

ফাইন্যান্স পরিষ্কার ডিপ্রিসিয়েশন ও ক্লোজ পায়, IT ও সুবিধা লোকেশন ও অ্যাসাইনমেন্ট ট্র্যাকিং পায়, এবং অপস এ আনকমন সারপ্রাইজ কম পায়।

আপনার অ্যাসেট রেজিস্টারে কি সংরক্ষণ করবেন (এবং কি ছেড়ে দেবেন)

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

স্পষ্ট অ্যাসেট পরিচয় দিয়ে শুরু করুন: একটি অ্যাসেট ট্যাগ বা সিরিয়াল নম্বর (বা উভয়), একটি সংক্ষিপ্ত নাম যেটা সবাই চিনবে ("Dell Latitude 5440"), একটি ক্যাটেগরি, এবং বেসিক ভেন্ডর বিবরণ। ক্রয় তারিখ ও ক্রয় মূল্য যোগ করুন, কারণ এই ফিল্ডগুলো বেশিরভাগ ডিপ্রিসিয়েশন মেথড ও রিপোর্টকে খাওয়ায়।

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

লোকেশন যথেষ্ট পরিমিত হওয়া উচিত যাতে আইটেম দ্রুত খুঁজে পাওয়া যায়, কিন্তু এতটা বিস্তারিত না যে এটি বিরক্তিকর হয়ে পড়ে। বাস্তবসম্মত সেটআপ হচ্ছে সাইট, বিল্ডিং, রুম, এবং একটি সহজ সাব-লোকেশন যেমন শেলফ বা ক্যাবিনেট। হ্যান্ডঅফের জন্য একটি in-transit স্ট্যাটাসও রাখুন যেমন "IT stockroom -> Finance office" যাতে একটি অ্যাসেট কেবল সরার কারণে কখনো "missing" না হয়।

অধিকাংশ টিম একটি ছোট কোর সেট ফিল্ড দিয়ে ভালো কাজ করে:

• পরিচয়: ট্যাগ/সিরিয়াল, নাম, ক্যাটেগরি, ভেন্ডর
• ফাইন্যান্স: ক্রয় তারিখ, খরচ, ডিপ্রিসিয়েশন শুরু তারিখ
• মালিকানা: কস্টোডিয়ান, ডিপার্টমেন্ট, কস্ট সেন্টার, ম্যানেজার
• লোকেশন: সাইট, বিল্ডিং, রুম, সাব-লোকেশন, ইন-ট্রানজিট ফ্ল্যাগ
• লাইফসাইকেল: অর্ডার করা, ইন সার্ভিস, মেরামতাধীন, ডিসপোজড

অ্যাটাচমেন্ট রেকর্ডের কাছে রাখুন: ইনভয়েস, লেবেলের ছবি, ওয়্যারেন্টি ডকুমেন্ট, সার্ভিস রিপোর্ট। খুব কমই আপ-টু-ডেট থাকা "দৃষ্টিনন্দন" ফিল্ডগুলো (পূর্ণ স্পেকশীট, লম্বা ফ্রি-টেক্সট ইতিহাস, ম্যানুয়াল ডিপ্রিসিয়েশন ক্যালকুলেশন) এড়িয়ে চলুন। যদি অতিরিক্ত বিস্তারিত দরকার হয়, সেটি স্ট্রাকচার্ড নোট বা অ্যাটাচমেন্ট হিসেবে ক্যাপচার করুন যাতে পাঠযোগ্য ও অডিটযোগ্য থাকে।

সহজবোধ্য ডিপ্রিসিয়েশন সেটআপ

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

উপযোগী আয়ু (useful life) হচ্ছে আপনি কতদিন একটি অ্যাসেট ব্যবহার করবেন বলে আশা করেন (উদাহরণ: ল্যাপটপের জন্য 3 বছর, মেশিনের জন্য 7 বছর)। স্যালভেজ ভ্যালু হচ্ছে শেষ অবস্থায় আপনি কোন মূল্য আশা করছেন (কম-মুল্যের আইটেমের জন্য প্রায়শই $0)। শুরু তারিখ হচ্ছে কখন ডিপ্রিসিয়েশন শুরু হবে—সাধারণত ইন-সার্ভিস তারিখ, পারচেজ অর্ডার নয়।

অধিকাংশ টিমের জন্য দুটো মেথডই যথেষ্ট:

• স্ট্রেইট-লাইন: প্রতিমাসে একই খরচ।
• ডিক্লাইনিং ব্যালান্স: শুরুতে বেশি, পরে কম।

আংশিক মাস মানুষকে ভ্রান্ত করে। একটি নিয়ম বেছে নিন এবং তা ধারাবাহিক রাখুন: হয়ই সেই মাসে শুরু করুন যখন অ্যাসেট ইন-সার্ভিস হয় (দিন অনুসারে প্রো-রেট), অথবা পরের পূর্ণ মাস থেকে শুরু করুন। মধ্য-বার্ষিক ক্রয়ের ক্ষেত্রে শুরু তারিখ অনুসরণ করুন এবং রিপোর্টিংয়ে বছরভিত্তিক সারসংক্ষেপ দেখান।

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

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

একটি অ্যাপে ডিপ্রিসিয়েশন স্কেজুল কিভাবে কাজ করে

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

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

একটি সহজ প্যাটার্ন যা নির্ভরযোগ্য থাকে:

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

মাসিক পোস্টিং একটি পুনরাবৃত্ত জব হয়: অ্যাপ চেক করে কোন অ্যাসেটগুলোর পোস্টিং নির্ধারিত, একটি ডিপ্রিসিয়েশন এন্ট্রি (তারিখ, পরিমাণ, পিরিয়ড, ব্যবহারকারী বা সিস্টেম) তৈরি করে, totals আপডেট করে, এবং তারপর সেই পিরিয়ড লক করে।

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

ডিসপোজাল রিকোয়েস্ট ও অনুমোদন, শুরু থেকে শেষ পর্যন্ত

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

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

বাস্তবসম্মত একটি এন্ড-টু-এন্ড ফ্লো দেখতে কিছুটা এ রকম:

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

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

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

ভূমিকা, অনুমতি, ও অনুমোদন নিয়ম

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

অধিকাংশ টিম নিম্নলিখিত ভূমিকা দিয়ে বেস কাভার করতে পারে:

• Requester: ট্রান্সফার ও ডিসপোজাল রিকোয়েস্ট জমা করেন
• Custodian: দৈনন্দিন বিবরণ আপডেট রাখে (লোকেশন, অ্যাসাইনড ইউজার, অবস্থা)
• Approver: ডিসপোজাল ও উচ্চ-প্রভাব পরিবর্তন অনুমোদন করেন
• Finance admin: খরচ, ডিপ্রিসিয়েশন ইনপুট, ও পোস্টিং ডেট পরিচালনা করেন
• Auditor (read-only): সব দেখবেন কিন্তু কিছুই পরিবর্তন করবেন না

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

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

দায়বিভাজন গুরুত্বপূর্ণ: যে ব্যক্তি ডিসপোজাল রিকোয়েস্ট করেছেন তিনি কখনোই চূড়ান্ত অনুমোদক হওয়া উচিত নয়। একটি সাধারণ ধারা হচ্ছে: requester -> custodian confirmation -> finance review -> final approver। এমনকি যদি একজন ব্যক্তিই দুইটি ভূমিকা বহন করেন, অ্যাপটি তাদের নিজেদের রিকোয়েস্ট অনুমোদন করার থেকে ব্লক করা উচিত।

ধাপে ধাপে: ডাটা মডেল ও বেসিক স্ক্রিন বানান

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

প্রথম ভার্সনের জন্য পাঁচটি ফোকাসড টেবিলই পর্যাপ্ত:

• Assets (ট্যাগ/সিরিয়াল, নাম, ক্যাটেগরি, ক্রয় তারিখ, খরচ, ইন-সার্ভিস তারিখ, বর্তমান লোকেশন, কস্টোডিয়ান, স্ট্যাটাস)
• Locations (সাইট, বিল্ডিং, রুম, কস্ট সেন্টার, সক্রিয় ফ্ল্যাগ)
• Depreciation Schedules (মেথড, উপযোগী আয়ু, শুরু তারিখ, স্যালভেজ ভ্যালু, ফ্রিকোয়েন্সি, স্ট্যাটাস)
• Depreciation Entries (পিরিয়ড, পরিমাণ, পোস্টেড তারিখ, পোস্ট করেছে কে, অ্যাসেট ও স্কেজুল রেফারেন্স)
• Disposal Requests (কারণ, অনুরোধের তারিখ, অনুরোধকারী, প্রস্তাবিত ডিসপোজাল তারিখ, স্ট্যাটাস, অ্যাটাচমেন্ট ফিল্ড)

স্ট্যাটাসগুলো সেই ধাপগুলো প্রতিফলিত করুন যা আপনি বাস্তবে প্রয়োজন মনে করেন। অ্যাসেটের জন্য একটি সিম্পল সেট ভালোভাবে কাজ করে: Draft, In Service, Disposal Pending, Disposed। ডিসপোজাল রিকোয়েস্টের জন্য: Requested, Approved, Rejected, Completed। কে কখন স্ট্যাটাস বদলিয়েছে তা সংরক্ষণ করুন।

প্রতিদিন মানুষ যে স্ক্রিনগুলো ব্যবহার করে সেগুলো মিনিimum বানান: দ্রুত ফিল্টারসহ একটি অ্যাসেট তালিকা, ট্যাবসহ অ্যাসেট ডিটেইল পেজ (info, depreciation, history), অ্যাড/এডিট অ্যাসেট, লোকেশন পরিবর্তনের ফর্ম যা লোকেশন ইতিহাস রেকর্ড করে, এবং ডিসপোজাল রিকোয়েস্ট ফর্ম।

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

ধাপে ধাপে: ডিপ্রিসিয়েশন ও রুটিং অটোমেট করুন

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

মাসিক ডিপ্রিসিয়েশন অটোমেট করুন (ডুপ্লিকেট ছাড়া)

মাসের প্রথম দিনে (অথবা শেষ রাতে) চলার জন্য একটি মাসিক জব দিয়ে শুরু করুন। এটিকে আইডেম্পোটেন্ট করুন যাতে এটি দুইবার নিরাপদে চলতে পারে—প্রতিটি অ্যাসেট ও পিরিয়ডের জন্য এন্ট্রি আগে থেকেই আছে কি না চেক করে নতুন না করলে না তৈরি করবে।

বাস্তবসম্মত ফ্লো:

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

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

রুল ও নোটিফিকেশনসহ ডিসপোজাল রিকোয়েস্ট রুট করুন

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

• কম বুক ভ্যালু: শুধুই ম্যানেজার অনুমোদন
• IT সরঞ্জাম: IT অ্যাডমিনের অনুমোদন যোগ করুন
• লিজকৃত অ্যাসেট: চূড়ান্ত অনুমোদনের আগে ফাইন্যান্স রিভিউ করুন
• ডেটা-বহনকারী ডিভাইস: সিকিউরিটি সাইন-অফ প্রয়োজন

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

পরবর্তীতে প্রয়োজন হবে এমন রিপোর্ট ও অডিট ট্রেইল

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

যে রিপোর্টগুলো মানুষ সত্যিই খুলবে

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

• লোকেশন অনুযায়ী অ্যাসেট তালিকা (অ্যাসাইনড ওনারের সহ)
• ডিসপোজড অ্যাসেট (ডিসপোজাল পদ্ধতি, অনুমোদক, চূড়ান্ত তারিখ সহ)
• ট্যাগ নেই বা পাঠযোগ্য না এমন অ্যাসেট
• ইন-সার্ভিস অ্যাসেট কিন্তু ডিপ্রিসিয়েশন সেটআপ নেই
• এক্সসেপশন (খালি লোকেশন, অজানা ক্যাটেগরি, ইনঅ্যাক্টিভ ভেন্ডর)

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

অডিট ট্রেইল যা রিভিউতে আপনাকে বাঁচাবে

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

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

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

উদাহরণ: একটি অ্যাসেট কেনা থেকে ডিসপোজাল পর্যন্ত

একটি নতুন ল্যাপটপ একটি নতুন হায়ারের জন্য এসেছে। কেউ ক্রয় তারিখ, সাপ্লায়ার, খরচ, ওয়ারেন্টি শেষের তারিখ, সিরিয়াল নম্বর, এবং প্রাথমিক লোকেশন (HQ - IT storage) সহ একটি অ্যাসেট রেকর্ড তৈরি করে। স্ট্যাটাস In Stock রাখা হয়।

নিয়োগের প্রথম দিনে IT ল্যাপটপটি Jordan-কে অ্যাসাইন করে। স্ট্যাটাস In Use-এ আপডেট হয়, কস্টোডিয়ান Jordan হয়, এবং লোকেশন HQ - 3rd floor-এ পরিবর্তন হয়। দুই মাস পরে Jordan অন্য অফিসে চলে গেলে লোকেশন আবার আপডেট করা হয়। প্রতিটি পরিবর্তন লগ হওয়ায় আপনি যেকোনো সময়ে দেখতে পারবেন ল্যাপটপটি কোন পয়েন্টে কোথায় ছিল।

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

এক বছর পরে, ল্যাপটপটি ভেঙে যায়। Jordan একটি ডিসপোজাল রিকোয়েস্ট জমা দেন এবং ক্ষতির ছবি ও IT-এর সংক্ষিপ্ত নোট সংযুক্ত করেন। অ্যাসেট স্ট্যাটাস Disposal Pending হয়, এবং রিকোয়েস্টটি অনুমোদনের জন্য রুট হয়।

অনুমোদনের পরে, ডিসপোজাল সম্পন্ন করা হয়: স্ট্যাটাস Disposed-এ পরিবর্তন, ডিসপোজাল তারিখ ও পদ্ধতি রেকর্ড করা, আয় বা ডিসপোজাল খরচ এন্ট্রি করা, এবং ডিপ্রিসিয়েশন স্বয়ংক্রিয়ভাবে বন্ধ।

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

প্রচলিত ভুল যা রিওয়ার্ক তৈরি করে

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

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

লোকেশন আরেকটি চুপচাপ সমস্যার উৎস। ফ্রি-টেক্সট ফ্লেক্সিবল মনে হয় ("2nd floor", "Second Floor", "Floor 2"), কিন্তু এটি রিপোর্টিং ভেঙে দেয় এবং লোকেশন ট্র্যাকিং অবিশ্বস্ত করে তোলে। কন্ট্রোলড লোকেশন তালিকা ব্যবহার করুন (প্রয়োজনে সাব-লোকেশন সহ) যাতে মুভগুলো ধারাবাহিক থাকে।

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

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

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

• কে ডিসপোজাল অনুরোধ করে?
• মানদণ্ড অনুযায়ী কে অনুমোদন করে?
• কে ফিজিকাল পিকআপ ও চূড়ান্ত রাইট-অফ নিশ্চিত করে?
• কেউ প্রত্যাখ্যান করলে কি হয়?
• কি প্রমাণ আবশ্যক?

দ্রুত চেকলিস্ট ও পরবর্তী ধাপ

কিছু মৌলিক বিষয় এক সংক্ষিপ্ত ওয়ার্কিং সেশনে (ফাইন্যান্স, অপারেশনস, এবং একটি অনুমোদনকারী) সম্মত করে নিন—এর পর রেজিস্টার লঞ্চের পরে সঠিক রাখা অনেক সহজ হয়।

চেকলিস্ট:

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

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

যদি আপনি হ্যান্ড-কোডিং ছাড়া তৈরি করতে চান, AppMaster (appmaster.io) একটি no-code প্ল্যাটফর্ম যা ডাটা মডেল, স্ক্রিন, এবং অনুমোদন ওয়ার্কফ্লো এক জায়গায় জেনারেট করে যাতে আপনি নীতির বদলে যাওয়া অনুযায়ী ফিল্ড ও রুটিং নিয়ম সহজে সামঞ্জস্য করতে পারেন।