চুক্তি ইনটেক অ্যাপ: লিগ্যাল টিমের জন্য একটি ব্যবহারিক নকশা

চুক্তির অনুরোধ দেরি হয় কেন

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

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

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

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

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

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

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

মানুষ ও হ্যান্ডঅফের মানচিত্র তৈরি করুন

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

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

অনুরোধকারীর তথ্য লিগ্যাল পর্যালোচনার তথ্য থেকে আলাদা রাখুন। অনুরোধকারীরা ব্যবসায়িক তথ্য দেবেন, যেমন কোম্পানির নাম, চুক্তির ধরন, কাঙ্ক্ষিত স্বাক্ষরের তারিখ, চুক্তির মালিক, মূল্য এবং অপর পক্ষের খসড়া। লিগ্যাল নির্ধারিত পর্যালোচক, ধারার উদ্বেগ, ঝুঁকির মাত্রা, আলোচনার নোট এবং অনুমোদনের সিদ্ধান্ত রেকর্ড করবে।

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

প্রত্যেকের কাজ অনুযায়ী অ্যাক্সেস দিন:

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

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

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

মানুষ সহজে পূরণ করতে পারে এমন ফর্ম তৈরি করুন

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

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

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

প্রয়োজনীয় ফিল্ডের সংখ্যা যুক্তিসঙ্গত রাখুন

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

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

একটি সাধারণ চুক্তির অনুরোধ ফর্মে থাকতে পারে:

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

লিগ্যাল পরিভাষা নয়, ব্যবসায়িক প্রয়োজন জানতে চান

বেশিরভাগ অনুরোধকারী তাদের ব্যবসায়িক প্রয়োজন বোঝেন, কিন্তু দায়বদ্ধতার সীমা বা ডেটা প্রসেসিং অ্যাডেন্ডামের মতো শব্দ জানেন না। সহজ প্রশ্ন ব্যবহার করুন। চুক্তিতে ব্যক্তিগত তথ্য, গোপনীয় তথ্য, অর্থপ্রদানের অঙ্গীকার, মেধাস্বত্ব, স্বয়ংক্রিয় নবায়ন বা দেশের বাইরে কাজ জড়িত কি না, তা জিজ্ঞেস করুন।

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

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

ধারার প্রয়োজন পরিষ্কারভাবে রেকর্ড করুন

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

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

উদাহরণ হিসেবে, একজন সেলস ম্যানেজার পেমেন্টের শর্ত পরিবর্তনের অনুরোধ করে লিখতে পারেন: «গ্রাহকের ক্রয় নীতিতে Net 30 অনুমোদিত নয়, তাই Net 60 দরকার।» লিগ্যাল তখন কাঙ্ক্ষিত ফলাফল ও ব্যবসায়িক কারণ দুটোই দেখতে পায়।

শুধু পরিবর্তন নয়, কারণও জিজ্ঞেস করুন

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

সহজ প্রশ্ন ব্যবহার করুন: «এই ধারাটি কেন পরিবর্তন করা দরকার?» যুক্তিসঙ্গত অক্ষরসীমা পুরো ইমেইল থ্রেড পেস্ট না করে দরকারি ব্যাখ্যা দিতে উৎসাহিত করে।

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

নিয়মিত পছন্দ ও ব্যতিক্রম আলাদা রাখুন

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

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

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

পর্যালোচনার স্ট্যাটাস সহজে অনুসরণযোগ্য করুন

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

দলের বাস্তব প্রক্রিয়ার সঙ্গে মেলে এমন অল্প কয়েকটি ধাপ ব্যবহার করুন। বেশি লেবেল আপডেট কঠিন করে, কিন্তু পরিষ্কার করে না। একটি কার্যকর ক্রম হতে পারে:

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

অনুরোধ আসার সঙ্গে সঙ্গে একজন লিগ্যাল মালিক নির্ধারণ করুন। সেই ব্যক্তি সব কাজ নিজে করবেন না, কিন্তু অনুরোধটি এগিয়ে রাখবেন। কোনো অপারেশনস ম্যানেজার সোমবার ভেন্ডর চুক্তি জমা দিলে এবং ইনটেক কো-অর্ডিনেটর সেটি লিগ্যালের Priya-কে দিলে, ম্যানেজার সাধারণ «লিগ্যাল টিম» স্ট্যাটাসের বদলে একজন নির্দিষ্ট মালিক দেখতে পাবেন।

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

অনুরোধের পাতায় বর্তমান ধাপ ও পরবর্তী পদক্ষেপ পাশাপাশি রাখুন। «পর্যালোচনাধীন - Priya ডেটা প্রসেসিংয়ের শর্ত যাচাই করছেন» «খোলা»র চেয়ে পরিষ্কার। ব্যবসায়িক দলকে দায়বদ্ধতার অবস্থান অনুমোদন করতে হলে সরাসরি লিখুন: «ব্যবসায়িক অনুমোদনের অপেক্ষায় - প্রস্তাবিত দায়সীমা গ্রহণযোগ্য কি না নিশ্চিত করুন।»

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

ধাপে ধাপে ওয়ার্কফ্লো তৈরি করুন

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

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

ফর্ম রেকর্ড সংরক্ষণ করার পর রাউটিং নিয়ম তৈরি করুন। চুক্তির ধরন, চুক্তির মূল্য, ব্যবসায়িক বিভাগ, অঞ্চল এবং ঝুঁকির মাত্রা সাধারণত সঠিক ব্যক্তির কাছে কাজ পাঠানোর জন্য যথেষ্ট। একটি NDA সাধারণ লিগ্যাল কিউতে যেতে পারে, আর উচ্চমূল্যের ভেন্ডর চুক্তি কমার্শিয়াল কাউন্সেল ও প্রোকিউরমেন্টের কাছে যেতে পারে।

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

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

চালুর আগে বাস্তবসম্মত অনুরোধ পুরো পথে চালান:

• সম্পূর্ণ তথ্যসহ একটি সাধারণ NDA
• একাধিক ধারায় পরিবর্তন দরকার এমন একটি ভেন্ডর চুক্তি
• কাছাকাছি সময়সীমার একটি জরুরি বিক্রয় চুক্তি
• অনুপস্থিত সংযুক্তি বা অস্পষ্ট ব্যবসায়িক মালিকসহ একটি অনুরোধ
• লিগ্যাল ও ফাইন্যান্স দু’দলের অনুমোদন দরকার এমন একটি চুক্তি

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

প্রথমে সাধারণ পথ নিয়ে চালু করুন। দল অ্যাপ ব্যবহার শুরু করার পর কোথায় অনুরোধ ধীর হয় তা দেখে বিরল ব্যতিক্রম যোগ করুন।

উদাহরণ: একটি ভেন্ডর চুক্তির অনুরোধ

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

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

অ্যাপটি LA-1842 অনুরোধ তৈরি করে, সময়ের রেকর্ড যোগ করে এবং স্ট্যাটাস «জমা দেওয়া» নির্ধারণ করে। সেলস ম্যানেজার দেখতে পান যে লিগ্যাল এখনও কাজ শুরু করেনি। লিগ্যাল দল একই রেকর্ডে ব্যবসায়িক প্রেক্ষাপট, চাওয়া ধারার পরিবর্তন, খসড়া এবং সময়সীমা পায়।

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

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

একটি টার্নঅ্যারাউন্ড রিপোর্ট দেখাতে পারে যে LA-1842 ১০ জুন জমা পড়ে ১৪ জুন সম্পন্ন হয়েছে, মোট চার কর্মদিবসে। অনুপস্থিত অ্যাডেন্ডামের জন্য অপেক্ষায় কত সময় গেছে, তাও দেখানো যায়। এতে লিগ্যালের পর্যালোচনার সময় এবং অসম্পূর্ণ অনুরোধের কারণে হওয়া দেরি আলাদা করা যায়।

টার্নঅ্যারাউন্ড সময়ের রিপোর্ট তৈরি করুন

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

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

প্রতিটি অনুরোধ প্রতিটি স্ট্যাটাসে কত সময় কাটায়, তা রেকর্ড করুন, যেমন:

• বাছাইয়ের অপেক্ষায় জমা দেওয়া
• লিগ্যাল পর্যালোচকের কাছে নির্ধারিত
• ব্যবসায়িক তথ্য বা নথির অপেক্ষায়
• লিগ্যাল পর্যালোচনাধীন
• অনুরোধকারীর কাছে ফেরত বা স্বাক্ষরের জন্য প্রস্তুত

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

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

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

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

সাধারণ সেটআপের ভুল

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

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

মুক্ত লেখার ফিল্ড আরেকটি সমস্যা তৈরি করে। একজন দল «NDA», অন্য দল «non disclosure» এবং তৃতীয় দল «confidentiality form» লিখতে পারে। ফলে একই কাজ কয়েকটি লেবেলে ভাগ হয়ে যায়। চুক্তির ধরন, অনুরোধের কারণ, অগ্রাধিকার এবং চুক্তি পর্যালোচনার স্ট্যাটাসের জন্য নিয়ন্ত্রিত তালিকা ব্যবহার করুন। সত্যিকারের ব্যতিক্রমের জন্য সংক্ষিপ্ত ব্যাখ্যার ফিল্ডসহ «অন্যান্য» রাখুন।

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

সময়সীমা ও কাজের চাপ মিলিয়ে দেখুন

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

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

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

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

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

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

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

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

ব্যবহারিক স্ট্যাটাসের তালিকা হতে পারে:

• নতুন অনুরোধ
• লিগ্যালের কাছে নির্ধারিত
• অনুরোধকারীর অপেক্ষায়
• লিগ্যাল পর্যালোচনাধীন
• স্বাক্ষরের জন্য প্রস্তুত

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

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

পরবর্তী পদক্ষেপ বেছে নিন

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

প্রথম সংস্করণটি এমন তথ্যকে কেন্দ্র করে তৈরি করুন যা পর্যালোচকের প্রাথমিক সিদ্ধান্তের জন্য দরকার: অনুরোধকারী, ব্যবসায়িক মালিক, অপর পক্ষ, চুক্তির ধরন, কাঙ্ক্ষিত স্বাক্ষরের তারিখ, মূল্য, অঞ্চল এবং ধারার অনুরোধ। ঐচ্ছিক ফিল্ড কম রাখুন। দীর্ঘ চুক্তির অনুরোধ ফর্ম মানুষকে আবার ইমেইলে ফিরিয়ে দিতে পারে।

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

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

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

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

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