ত্রৈমাসিক পর্যালোচনা ও QBR পেজের জন্য সরবরাহকারী স্কোরকার্ড অ্যাপ

কেন সরবরাহকারী রিভিউগুলো স্প্রেডশীট বিশৃঙ্খলায় বদলে যায়

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

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

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

এই রিভিউগুলো সাধারণত বিভিন্ন অগ্রাধিকারসহ একাধিক স্টেকহোল্ডার জড়িত করে। Procurement মূলত মূল্য, শর্ত এবং ঝুঁকি নিয়ে চিন্তা করে। Operations অন-টাইম ডেলিভারি এবং লিড টাইম নিয়ে যত্নবান। Quality ত্রুটি, রিটার্ন, এবং সংশোধনী কার্যক্রম দেখবে। Finance মূল্য পরিবর্তন, ক্রেডিট, এবং পূর্বাভাসের প্রভাব ট্র্যাক করে।

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

আপনি প্রতি কোয়ার্টারে কী মাপে তা নির্ধারণ করুন

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

আপনার সরবরাহকারীর তালিকা দিয়ে শুরু করুন। প্রতিটি সরবরাহকারীকে একটি ইউনিক ভেন্ডর আইডি দিন যা কখনো বদলাবে না, এমনকি যদি সরবরাহকারীর নাম বদলে যায় (উদাহরণ: "ACME Manufacturing" বনাম "ACME Mfg")। এই এক সিদ্ধান্ত ডুপ্লিকেট রোধ করে এবং প্রতিবার সঠিক ইতিহাস টানা সহজ করে।

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

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

তারপর প্রতিটি মেট্রিকের জন্য মালিকানা এবং সোর্স-অফ-ট্রুথ নির্ধারণ করুন। একটি স্কোরকার্ড তখনই বিশ্বাসযোগ্য যখন প্রতিটি সংখ্যার জন্য একটি স্পষ্ট মালিক এবং স্পষ্ট উৎস থাকে।

• OTD: Logistics কর্তৃক মালিকানাধীন, ক্যারিয়ার ট্র্যাকিং বা রিসিভিং সিস্টেম থেকে সোর্স।
• ত্রুটিসমূহ: Quality কর্তৃক মালিকানাধীন, ইনস্পেকশন লগ বা রিটার্ন সিস্টেম থেকে সোর্স।
• মূল্য পরিবর্তন: Procurement/Finance কর্তৃক মালিকানাধীন, PO ইতিহাস এবং ইনভয়েস থেকে সোর্স।
• ভেন্ডর মাস্টার ডেটা: Procurement কর্তৃক মালিকানাধীন, ERP বা ভেন্ডর ডেটাবেস থেকে সোর্স।

উদাহরণ: যদি OTD রিসিভিং টাইমস্ট্যাম্প থেকে আসে কিন্তু Logistics শিপ ডেট রিপোর্ট করে, আপনি তবু OTD ট্র্যাক করতে পারবেন। কেবল একটি সংজ্ঞা (ডেলিভারি তারিখ বা রিসিপ্ট তারিখ) বেছে নিতে হবে এবং প্রতিটি সরবরাহকারীর জন্য প্রতিটি কোয়ার্টারে সেটি বজায় রাখতে হবে।

মেট্রিকগুলো স্পষ্ট ভাষায় সংজ্ঞায়িত করুন (যাতে সবাই একমত হয়)

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

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

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

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

ভবিষ্যৎ বিতর্ক রোধ করতে, প্রতিটি মেট্রিকের জন্য মৌলিক তথ্য ধারণ করুন: একটি এক-ওই বাক্যের সংজ্ঞা এবং সঠিক উৎস (PO, ইনভয়েস, ইনস্পেকশন লগ), গণনার নিয়ম (আংশিকতা এবং ক্রেডিট সহ), কোয়ার্টার অ্যাসাইনমেন্টের জন্য কার্যকর-তারিখ নিয়ম, ব্যতিক্রমের জন্য একটি স্পষ্ট মালিক, এবং প্রমাণসহ সংক্ষিপ্ত প্রসঙ্গ নোট।

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

রিপোর্টিং সহজ করে এমন ডেটা মডেল

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

আপনি যেগুলো ইতিমধ্যেই ডিল করেন সেগুলোর সাথে মিল রেখে একটি ছোট সেট কোর রেকর্ড দিয়ে শুরু করুন: Vendors, POs or Shipments, Inspections or Defects, Price Changes, এবং Review Periods।

কাঁচা ইভেন্টগুলোকে ত্রৈমাসিক সারাংশ থেকে আলাদা রাখুন।

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

এই বিভাজন আপনাকে দেরিতে ডেটা এলে পুনঃগণনা করার সুযোগ দেয় ইতিহাস পুনরায় লেখার পরিবর্তে।

প্রমাণ সংরক্ষণ করুন, কেবল স্কোর নয়। প্রতিটি ইভেন্টের জন্য সেই তথ্য ধরে রাখুন যা QBR মিটিংয়ে সংখ্যাটি রক্ষা করতে দরকার হবে: তারিখ, পরিমাণ, পার্ট নম্বর, এবং একটি ডকুমেন্ট রেফারেন্স (ইনভয়েস নম্বর, রিসিভিং রিপোর্ট আইডি, ইনস্পেকশন রেকর্ড আইডি)। কেউ যদি জিজ্ঞেস করে, "কোনটি চালান দেরি ছিল?", আপনি ফাইল খুঁটতে হয় না—উত্তর দিতে পারবেন।

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

অতিরিক্ত কাজ ছাড়াই ডেটা কিভাবে সংগ্রহ করবেন

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

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

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

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

ধাপে ধাপে: ত্রৈমাসিক স্কোরগুলি স্বয়ংক্রিয়ভাবে কিভাবে গণনা করবেন

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

একটি সহজ স্কোরিং ফ্লো যা ধারাবাহিক থাকে

1. কোয়ার্টার রেকর্ড তৈরি করুন এবং তারিখগুলো লক করুন। "Q1 2026" (অথবা সমতুল্য) এন্ট্রি যোগ করুন একটি স্টার্ট ওএন্ড ডেট সহ। রিভিউ শুরু হলে রেঞ্জ লক করে দিন যাতে দেরি এডিট ফলাফল বদলে না দেয়।

2. চালান থেকে অন-টাইম ডেলিভারি গণনা করুন। ঐ তারিখ সীমার মধ্যে সব চালান টানুন। প্রতিশ্রুত তারিখ বনাম গ্রহণের তারিখ তুলনা করুন। অন-টাইম শতাংশ এবং কাঁচা গণনাগুলো সংরক্ষণ করুন।

3. ত্রুটি ইভেন্ট থেকে ত্রুটি হার গণনা করুন। ঐ কোয়ার্টারের জন্য সরবরাহকারীর সাথে সংযুক্ত ত্রুটি ইভেন্টগুলো টানুন। একটি সংজ্ঞা বেছে নিন (উদাহরণ: 1,000 ইউনিট প্রতি ত্রুটি, অথবা ত্রুটিযুক্ত চালানের শতাংশ)। হার এবং মোট ত্রুটি গণনা সংরক্ষণ করুন।

4. বেসলাইনের বিরুদ্ধে মূল্য পরিবর্তন সারসংক্ষেপ করুন। আপনার বেসলাইন মূল্য (চুক্তির তালিকা বা গত কোয়ার্টারের গড়) তুলনা করুন কোয়ার্টারে আসা ইনভয়েস লাইনের প্রকৃত মূল্যের সাথে। গড় শতাংশ পরিবর্তন এবং পরিবর্তন হওয়া আইটেমের সংখ্যা সংরক্ষণ করুন।

5. সামগ্রিক স্কোর গণনা করে সংরক্ষণ করুন। প্রতিটি মেট্রিককে 0-100 সাবস্কোরে রূপান্তর করুন, ওজন প্রয়োগ করুন (উদাহরণ: ডেলিভারি 50%, কোয়ালিটি 30%, মূল্য 20%), এবং চূড়ান্ত স্কোর ও ব্যবহৃত ওজন সংরক্ষণ করুন।

একবার ঐ মানগুলো প্রতি কোয়ার্টারে সংরক্ষিত হলে, আপনি দ্রুত QBR পেজ জেনারেট করতে পারবেন এবং প্রতিটি স্কোর ব্যাখ্যা করতে পারবে underlying রেকর্ডে ড্রিলডাউন করে।

এমন একটি QBR পেজ তৈরি করুন যা নিজেই আপডেট হয়

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

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

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

পেজটি স্বয়ংক্রিয় রাখার জন্য, সেটি সেভড কুয়েরি বা গণিতিত ক্ষেত্র থেকে তৈরি করুন, ম্যানুয়াল এডিট নয়। পেজটি Vendor এবং Quarter দ্বারা ফিল্টার করবে, সংরক্ষিত ত্রৈমাসিক ফলাফল টানবে, এবং প্রতিবার একই লজিক ব্যবহার করবে।

শেষে একটি Actions ব্লক রাখুন, কারণ স্কোর ছাড়া অ্যাকশন কেবল শোভা। একটি মালিক, ডিউ ডেট, স্টেটাস, এবং সংক্ষিপ্ত নোট যোগ করুন। উদাহরণ: "পার্ট A-র ত্রুটি কমানো: QA লিড, Feb 15, প্রক্রিয়াধীন, পরবর্তী কোয়ার্টারে নতুন ইনস্পেকশন স্টেপ যাচাই করুন।"

স্কোরকার্ডকে অবিশ্বস্ত করে এমন সাধারণ ফাঁদ

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

একটি সাধারণ সমস্যা হল মেট্রিক ডেফিনিশনকে মধ্য-কোয়ার্টারে বদলে ফেলা। যদি "অন-টাইম" "রিকোয়েস্টেড ডেটে পৌঁছানো" থেকে "কনফার্মড ডেটে পৌঁছানো" এ যায়, ট্রেন্ড লাইন গোলমাল হয়ে ওঠে। সংজ্ঞার সংস্করণ ট্র্যাক করুন, এবং পরিবর্তনগুলো কেবল পরবর্তী কোয়ার্টার থেকে প্রয়োগ করুন (বা উভয় সংস্করণ পাশাপাশি সংরক্ষণ করুন)।

আরেকটি ফাঁদ হল ত্রুটি হার হিসাব করার সময় ইউনিট মিশিয়ে ফেলা। একটি সরবরাহকারী লট, কেস, বা মিটার-এ পাঠালে তিনি ভাল বা মোটা দিক থেকে খারাপ দেখাতে পারেন নির্ভর করে আপনি কি দিয়ে ভাগ করছেন। যদি আপনি প্রতি 1,000 ইউনিটে ত্রুটি ট্র্যাক করেন, নিশ্চিত করুন "ইউনিট" সবসময় একই বোঝায়, এবং চালানে ইউনিট টাইপ সংরক্ষণ করুন।

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

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

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

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

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

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

তারপর নিশ্চিত করুন কোয়ার্টারের ভিতরে কোয়ালিটি এবং মূল্য তুলনীয়। ডিনোমিনেটর ছাড়া ত্রুটি এবং কার্যকর-তারিখ ছাড়া মূল্য পরিবর্তন দ্রুত আস্থা নষ্ট করে।

এই সংক্ষিপ্ত চেকলিস্টটি সবচেয়ে সাধারণ সমস্যাগুলো ধরতে সাহায্য করবে:

• Delivery: প্রতিটি চালান লাইনে একটি প্রয়োজনীয় তারিখ এবং একটি গ্রহণের তারিখ আছে (অথবা "এখনও গ্রহণ হয়নি").
• Defects: ত্রুটি গণনা একই পিরিয়ডের জন্য একটি স্পষ্ট ডিনোমিনেটরের সাথে যুক্ত।
• Cost: মূল্য পরিবর্তনের কার্যকর-তারিখ এবং একটি বেসলাইন মূল্য আছে।
• Spot-check: একটি সরবরাহকারী সোর্স রিপোর্টের সঙ্গে মিলান করে একটি রোলআপ নিশ্চিত করুন।
• Freeze the quarter: শেয়ার করার আগে পিরিয়ড লক করুন যাতে QBR পেজ পড়ার সময় সরে না যায়।

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

উদাহরণ দৃশ্য: এক সরবরাহকারী, এক কোয়ার্টার, স্পষ্ট সিদ্ধান্ত

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

Q3-এ সংখ্যাগুলো এইরকম দেখায়:

• OTD: 96% (Q2-এ 88% থেকে উন্নতি)
• ত্রুটি হার: 2.4% (Q2-এ 0.6% থেকে বেড়েছে)
• মূল্য পরিবর্তন: +3% (মধ্য-ত্রৈমাসিকে কার্যকর)

QBR পেজ এক ভিউতেই গল্পটি স্পষ্ট করে। OTD সবুজ, কিন্তু ত্রুটি সপ্তায় 5 থেকে স্পাইক করছে (যেটি পার্ট চেঞ্জ লগে নোটের ঠিক পরে)। মূল্য বৃদ্ধি ফ্ল্যাগ করা হয়েছে কারণ এটি গুণমানের কোনো মিল থাকা ছাড়াই ঘটেছে।

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

পরবর্তী ধাপ: পাইলট, উন্নতি, এবং এটিকে একটি সরল অ্যাপে পরিণত করুন

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

5 থেকে 10টি সরবরাহকারী এবং একটি পুর্ন ত্রৈমাসিক দিয়ে পাইলট করুন। সত্যিকারের ইনভয়েস, PO, ডেলিভারি নোট, এবং QA লগ ব্যবহার করুন। লক্ষ্য পরিপূর্ণতা নয়; লক্ষ্য হলো সমস্যাগুলো খুঁজে বের করা (অনুপস্থিত তারিখ, অস্পষ্ট ত্রুটি নিয়ম, বিতর্কিত মূল্য পরিবর্তন) যখন পরিসর ছোট।

একটি বাস্তবসম্মত রোলআউট প্ল্যান:

1. সহজ ভাষায় মেট্রিক ডেফিনিশনে একমত হন। প্রতিটি মেট্রিকের জন্য এক বাক্যের সংজ্ঞা লিখুন, প্লাস টাই-ব্রেকার নিয়ম।
2. এক কোয়ার্টার ইতিহাস ব্যাকফিল করুন। কেবল স্কোর গণনা করতে প্রয়োজনীয় ন্যূনতম ক্ষেত্রগুলোই প্রবেশ করান।
3. ডেটা পুল এবং গণনা অটোমেট করুন। একবার হিসাব করুন—প্রতিবার একইভাবে।
4. ভূমিকা এবং অনুমোদন যোগ করুন। কেউ ডেটা এন্টার করবে, কেউ যাচাই করবে, এবং কেউ প্রকাশ করবে।
5. নতুন পেজ ব্যবহার করে একটি QBR চালান। প্রথমে মেট্রিক, তারপর সিদ্ধান্ত ও কার্যক্রম।

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

যদি আপনি ভারী ইঞ্জিনিয়ারিং ছাড়াই এটি তৈরি করতে চান, AppMaster (appmaster.io) একটি বাস্তব সমাধান হতে পারে: আপনি PostgreSQL-এ ভেন্ডর ও ত্রৈমাসিক ফলাফল মডেল করতে পারবেন, ভিজ্যুয়ালি স্কোরিং লজিক তৈরি করতে পারবেন, এবং একই ডেটাসেট থেকে একটি ওয়েব QBR পেজ জেনারেট করতে পারবেন যাতে এটি প্রতিবার ধারাবাহিক থাকে।