কাগজের ফর্ম মোবাইল অ্যাপে স্থানান্তর করুন: একটি বাস্তব পরিকল্পনা

অ্যাপ দিয়ে নয়, প্রক্রিয়া দিয়ে শুরু করুন

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

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

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

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

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

এমন একটি ঘন ঘন ব্যবহৃত ফর্ম দিয়ে শুরু করুন, যাতে দেরি বা অসম্পূর্ণ তথ্য সত্যিকারের সমস্যা তৈরি করে। প্রথম দলটি দৈনন্দিন পরিস্থিতিতে প্রক্রিয়াটি সফলভাবে চালাতে পারলে অ্যাপটি আরও ফর্ম ও দলকে সমর্থন করতে পারবে।

ফর্ম সংগ্রহ করুন এবং বর্তমান কাজের ধারা ম্যাপ করুন

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

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

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

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

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

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

সরকারি পদ্ধতির বদলে মানুষ বাস্তবে কী করে, সেদিকে নজর দিন। এই সৎ চিত্রই কাগজের ফর্ম মোবাইল অ্যাপে স্থানান্তরের বাস্তব সূচনা দেয়।

পুনর্নির্মাণের আগে প্রতিটি ফিল্ড যাচাই করুন

কাগজের ফর্মে এমন তথ্যও থাকতে পারে, যা কেউ ব্যবহার করে না। কোনো একটি ঘটনার পর দল একটি ঘর যোগ করে, তারপর সেটি বছরের পর বছর থেকে যায়। ফোনে নেওয়ার সময় সেই জঞ্জালও কপি না করে বাদ দেওয়ার সুযোগ নিন।

একটি অডিট শিটে প্রতিটি ফিল্ডের তালিকা করুন। প্রশ্ন, বর্তমান উত্তর দেওয়ার ধরন, কে পূরণ করে, কে পড়ে এবং উত্তর দেওয়ার পর কী হয়, সব লিখুন। এতে অস্পষ্ট, পুনরাবৃত্তি এবং অব্যবহৃত প্রশ্ন সহজে ধরা পড়বে।

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

কেউ উত্তরটি পরীক্ষা না করলে বা তথ্যটি অন্যত্র থাকলে ফিল্ড বাদ দিন। অ্যাপ লগ-ইন করা ব্যবহারকারীর নাম নিজে রেকর্ড করলে প্রতিটি কাগজে টেকনিশিয়ানের নাম আবার চাওয়ার দরকার নেই।

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

অডিটে সহজ স্ট্যাটাস ব্যবহার করুন:

• কেউ উত্তর দিয়ে কাজ বা সিদ্ধান্ত নিলে ফিল্ড রাখুন।
• ভাষা বা ইনপুটের ধরন উন্নত করা দরকার হলে পরিবর্তন করুন।
• অন্য ফিল্ডে একই তথ্য থাকলে একত্র করুন।
• কেউ উত্তর ব্যবহার না করলে বাদ দিন।

«আমরা সব সময়ই জিজ্ঞেস করেছি» কোনো প্রশ্ন রাখার কারণ নয়। ছোট ফর্ম মাঠে কম সময় নেয় এবং কর্মীরা তা বেশি যত্ন নিয়ে পূরণ করেন। যারা ফর্ম পূরণ করেন এবং যারা পর্যালোচনা করেন, উভয়ের সঙ্গে চূড়ান্ত ফিল্ড তালিকায় একমত হন।

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

কাগজের প্রশ্নকে মোবাইল ইনপুটে রূপ দিন

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

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

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

উত্তরের সঙ্গে মানানসই নিয়ন্ত্রণ বেছে নিন:

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

লেবেলকে সরাসরি প্রশ্ন বা কাজের নির্দেশ হিসেবে লিখুন। প্রত্যেকে ID জানলে «Equipment ID» যথেষ্ট। নতুন কর্মীদের জন্য «লেবেলে লেখা equipment ID লিখুন» আরও পরিষ্কার। সহায়ক লেখা ছোট রাখুন এবং ফিল্ডের পাশে দিন।

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

চূড়ান্ত করার আগে বাস্তব ফোনে ফর্ম পরীক্ষা করুন। ডেস্কটপে ভালো দেখা একটি ফিল্ড মাঠে সংকীর্ণ বা বিভ্রান্তিকর লাগতে পারে।

বাস্তব পরিস্থিতিতে অফলাইন কাজের পরিকল্পনা করুন

বেসমেন্ট, গ্রামীণ সাইট, গুদাম ও বড় ভবনে ফিল্ড কর্মীরা প্রায়ই সিগন্যাল হারান। Wi-Fi ছাড়া কাজ না করা ফর্ম প্রথম কঠিন দিনেই মানুষকে কাগজে ফিরিয়ে দেবে। ফিল্ড ফর্ম ডিজিটাল করার আগেই অফলাইন আচরণ ঠিক করুন।

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

ডিভাইসে কী থাকবে ঠিক করুন

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

অস্পষ্ট স্ট্যাটাস ব্যবহার করবেন না। «সিঙ্কের অপেক্ষায় ৩টি ফর্ম» বার্তাটি ফিল্ড কর্মী ও সুপারভাইজার উভয়কেই পরিস্থিতি বোঝায়। আপলোডের অপেক্ষায় থাকা ফর্ম সম্পাদনা করা যাবে কি না, তাও জানাতে হবে।

প্রথম দল যে ফোন ও স্থানে কাজ করবে, সেগুলোতেই পরীক্ষা করুন:

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

সংযোগ ফিরে এলে সময়, ছবি, স্বাক্ষর ও duplicate record পরীক্ষা করুন। বিরোধও পরীক্ষা করুন। একজন কর্মী অফলাইনে ফর্ম বদলানোর সময় ম্যানেজার অন্যত্র একই রেকর্ড বদলাতে পারেন। অ্যাপ দুই সংস্করণ রাখবে, কর্মীকে বেছে নিতে বলবে, নাকি ম্যানেজারকে নিয়ন্ত্রণ দেবে, তা ঠিক করুন।

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

ডিভাইস সমস্যার প্রস্তুতি নিন

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

সংবেদনশীল তথ্যের নিয়ম নির্ধারণ করুন। screen lock বাধ্যতামূলক করুন, ফোন হারালে অ্যাক্সেস বন্ধ করুন এবং না-পাঠানো ফর্ম কতদিন ফোনে থাকবে তা ঠিক করুন। বাস্তব কর্মস্থলে সংক্ষিপ্ত অফলাইন পরীক্ষা ডেস্কে ধরা না পড়া সমস্যা প্রকাশ করবে।

প্রথম দলের সঙ্গে পাইলট চালান

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

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

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

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

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

একটি সহজ feedback sheet ব্যবহার করুন। প্রতিটি সমস্যার জন্য ফিল্ড, কাজ, ব্যবহারকারীর প্রত্যাশা এবং আপনার পরিকল্পিত পরিবর্তন লিখুন। প্রতিদিন সকালে কয়েকজন পরিদর্শক একই অবস্থান টাইপ করলে text box-এর বদলে সংরক্ষিত site list বা prefilled value দিন।

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

প্রক্রিয়া নতুন থাকতেই প্রশিক্ষণ দিন

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

মানুষ যে কাজ করবে, সেগুলোতেই প্রশিক্ষণ সীমিত রাখুন। নতুন অ্যাপ নিয়ে দীর্ঘ presentation-এর চেয়ে ২০ মিনিটের demonstration ও হাতে-কলমে অনুশীলন বেশি কার্যকর।

প্রত্যেককে একা একটি practice form পূরণ করতে দিন। বাস্তব তথ্য ও একটি নির্দিষ্ট সমস্যা রাখুন, যেমন সিগন্যাল না থাকা বা বাধ্যতামূলক ফিল্ড ফাঁকা থাকা। ফলাফল সঙ্গে সঙ্গে দেখলে মানুষ দ্রুত শেখে এবং প্রশ্ন করতে পারে।

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

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

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

যেমন, দস্তানা পরে equipment ID টাইপ করতে পরিদর্শন দলের বেশি সময় লাগতে পারে। বাছাইযোগ্য তালিকা বা barcode scan সেই অসুবিধা দূর করতে পারে। কয়েকটি শিফটের পর পাইলট দলের সঙ্গে সংক্ষিপ্ত বৈঠক করে সুপারভাইজারদের প্রয়োজনের সঙ্গে কর্মীরা বাস্তবে যা দিতে পারেন, তা মিলিয়ে নিন।

যে ভুলগুলো অতিরিক্ত কাজ তৈরি করে

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

সঠিক পর্যালোচনার পর ৪০টি প্রশ্নের দৈনিক ফর্ম ১৮টি দরকারি ইনপুটে নেমে আসতে পারে। এতে মাঠের কাজ দ্রুত হয় এবং সুপারভাইজারদের কম খালি বা duplicate তথ্য দেখতে হয়।

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

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

পাইলট চলাকালে সহজ কাগজের fallback রাখুন। কখন সেটি ব্যবহার করতে হবে, সম্পূর্ণ পাতা কোথায় রাখতে হবে এবং পরে জরুরি কাগজের রেকর্ড কে লিখবে, তা জানান। নিয়ম না থাকলে কাগজ নীরবে দ্বিতীয় প্রক্রিয়া হয়ে conflicting data তৈরি করতে পারে।

চালুর আগে এই পরীক্ষা করুন

ফোনে ফর্ম সম্পূর্ণ দেখালেও প্রথম ব্যস্ত শিফটে ব্যর্থ হতে পারে। পুরো পথ পরীক্ষা করুন: কেউ ফর্ম খুলবে, দুর্বল reception-এ পূরণ করবে, জমা দেবে এবং সুপারভাইজার রেকর্ড খুঁজে ব্যবস্থা নেবেন।

কর্মীরা প্রতিদিন যে ডিভাইস ও কর্মস্থল ব্যবহার করেন, সেগুলো ব্যবহার করুন। অফিসের Wi-Fi বেসমেন্ট, গুদাম, গাড়ি বা দূরবর্তী সাইটের পরিস্থিতি পরীক্ষা করে না।

• প্রতিটি ফিল্ডের নির্দিষ্ট ব্যবসায়িক প্রয়োজন আছে।
• প্রতিটি ইনপুট উত্তরের সঙ্গে মানানসই, যেমন তারিখের জন্য date picker এবং মাপের জন্য number field।
• সিগন্যাল চলে গেলে ফর্ম কাজ সংরক্ষণ করে এবং সংযোগ ফিরলে একবার পাঠায়।
• পাইলট ব্যবহারকারীরা সাহায্য ছাড়াই রেকর্ড জমা, ভুল সংশোধন ও পুরোনো submission খুঁজে পেতে পারেন।
• সুপারভাইজাররা দ্রুত নতুন রেকর্ড দেখতে পারেন এবং কে review, follow-up ও সংরক্ষণ করবেন তা জানেন।

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

কাগজে অনানুষ্ঠানিকভাবে সামলানো exception পরীক্ষা করুন। দৈনিক পরিদর্শনে ব্যর্থ চেক জানানো, ছবি যোগ করা এবং সঠিক সুপারভাইজারকে সতর্ক করার ব্যবস্থা লাগতে পারে। স্বাভাবিক «pass» submission কাজের কেবল একটি অংশ।

চালুর আগে submission-এর পরের প্রতিটি ধাপের জন্য একজন owner নির্ধারণ করুন। একজন missing data দেখবেন, অন্যজন safety issue বা customer follow-up সামলাতে পারেন। দলের দরকার পরিষ্কার কাজ, নতুন রেকর্ডে ভরা একটি ফোল্ডার নয়।

উদাহরণ: দৈনিক পরিদর্শন ফর্ম মোবাইলে আনা

একজন সাইট পরিদর্শক প্রতিদিন সকালে কাগজের safety checklist দিয়ে কাজ শুরু করেন। পুরোনো ফর্মে ২৮টি প্রশ্ন, স্বাক্ষরের লাইন এবং বড় notes box আছে। শিফট শেষে পরিদর্শক শিটটি সুপারভাইজারকে দেন। সুপারভাইজারকে প্রায়ই অনুপস্থিত তথ্যের জন্য খোঁজ করতে হয় বা হাতের লেখা বুঝতে হয়।

দলটি অন্যত্র থাকা তথ্যের পুনরাবৃত্তি করা আটটি প্রশ্ন বাদ দেয়। নিরাপত্তা, compliance ও follow-up কাজকে প্রভাবিত করে এমন প্রশ্ন রাখা হয়। sign-in করার পর মোবাইল ফর্মে পরিদর্শকের নাম, তারিখ ও সাইট নিজে পূরণ হয়। ফলে প্রতিদিন একই তথ্য লেখার দরকার থাকে না।

প্রতিটি চেকের জন্য পরিদর্শক «pass», «fail» বা «not applicable» বেছে নেন। «fail» নির্বাচন করলে ছবি ফিল্ড ও ছোট বিবরণ দেখা যায়। নিয়মিত চেক দ্রুত থাকে, আর সমস্যার রিপোর্টে maintenance দলের দরকারি তথ্য থাকে।

«লোডিং এলাকার কাছে রেলিং ঠিক করুন» ধরনের অস্পষ্ট নোটের বদলে পরিদর্শক ছবি নিতে, তালিকা থেকে এলাকা বেছে নিতে এবং লিখতে পারেন: «Bay 3-এ guardrail বাঁকা হয়ে forklift lane আটকে দিয়েছে।» রেকর্ডে সময় ও রিপোর্টকারী ব্যক্তির নামও থাকে।

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

পাইলটের মতামতে প্রথম সংস্করণ উন্নত হয়। দস্তানা পরলে notes field ব্যবহার কঠিন হওয়ায় দলটি preset issue category যোগ করে এবং বড় optional text field রাখে। সাধারণ চেকগুলোও ফর্মের ওপরে আনা হয়। এ ধরনের ছোট পরিবর্তনে tap কমে এবং দৈনন্দিন কাজ কম বিরক্তিকর হয়।

পাইলটের পর পরের ফর্ম বেছে নিন

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

পাইলটের মতো, কিন্তু একটি দরকারি পার্থক্যযুক্ত workflow বেছে নিন, যেমন ছবির প্রমাণ, ম্যানেজারের অনুমোদন বা follow-up task। এতে দল শূন্য থেকে শুরু না করে আগের শেখা কাজে লাগাতে পারে।

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

পাইলটের পর আরও এগোতে চাওয়া দলের জন্য AppMaster নো-কোড মোবাইল অ্যাপের পদ্ধতি দেয়। এর mobile UI builder, Data Designer এবং visual Business Process Editor হাতে লেখা কোড ছাড়াই ফর্ম ফিল্ড, routing, approvals ও alerts সমর্থন করতে পারে। অন্য দলকে দেওয়ার আগে বাস্তব iOS ও Android ডিভাইসে প্রতিটি workflow পরীক্ষা করুন।

প্রথম workflow নির্ভরযোগ্যভাবে কাজ না করা পর্যন্ত rollout ছোট রাখুন। পাইলটে দৈনিক equipment check থাকলে, কর্মীরা অফলাইনে check জমা দিতে, পরে record sync করতে এবং follow-up-এর দায়িত্ব কার তা দেখতে পারার পরেই maintenance request form যোগ করুন। নির্ভরযোগ্য মোবাইল ফর্ম মাইগ্রেশন পরিকল্পনা একবারে একটি প্রমাণিত workflow দিয়ে বড় হয়।