ফিল্ড ইস্যু রিপোর্টিং অ্যাপ: ক্রুদের জন্য একটি বাস্তব পরিকল্পনা

ফিল্ড রিপোর্ট দেরিতে আসে বা অসম্পূর্ণ থাকে কেন

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

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

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

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

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

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

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

প্রতিটি রিপোর্টে কী দরকার তা ঠিক করুন

একজন ক্রু সদস্যের এক মিনিটের মধ্যে ব্যবহারযোগ্য রিপোর্ট জমা দিতে পারা উচিত। এমন অল্প কিছু তথ্য দিয়ে শুরু করুন, যা দেখে কেউ সমস্যাটি বুঝতে, সেটি খুঁজে পেতে এবং কে ব্যবস্থা নেবে তা ঠিক করতে পারে।

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

সাইটে থাকা ব্যক্তি যা জানেন, প্রথম রিপোর্টটি সেদিকেই সীমিত রাখুন:

• দৃশ্যমান প্রমাণ কাজে লাগলে ছবি বা ভিডিও
• পরিচিত ও সংক্ষিপ্ত তালিকা থেকে ইস্যুর ধরন
• ফোনের মাধ্যমে ধরা লোকেশন, সঙ্গে তা সংশোধনের সুযোগ
• «নতুন» বা «পর্যালোচনা দরকার» এর মতো প্রাথমিক স্ট্যাটাস
• ঐচ্ছিক নোট

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

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

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

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

দ্রুত ব্যবহারের জন্য রিপোর্ট স্ক্রিন ডিজাইন করুন

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

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

প্রথম স্ক্রিনে চারটি কাজেই গুরুত্ব দিন:

• ছবি যোগ করা বা তোলা
• ইস্যুর ধরন বেছে নেওয়া
• বর্তমান স্ট্যাটাস সেট করা
• রিপোর্ট জমা দেওয়া বা ড্রাফট হিসেবে সংরক্ষণ করা

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

নোট গুরুত্বপূর্ণ, তবে এগুলো মূল কাজগুলোর নিচে রাখুন এবং ঐচ্ছিক করুন। «প্রয়োজনে বিস্তারিত যোগ করুন» ধরনের নির্দেশনা বড় বাধ্যতামূলক টেক্সট বক্সের চেয়ে ভালো। ছবির ব্যাখ্যা দরকার হলে কেউ «গেট ৩-এর কাছে পানি লিক করছে» লিখে দ্রুত এগিয়ে যেতে পারেন।

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

AppMaster-এর ভিজ্যুয়াল UI builders ও business logic tools দিয়ে দলগুলো এ ধরনের মোবাইল ইন্টারফেস তৈরি করতে পারে। তারা একটি সংক্ষিপ্ত রিপোর্ট ফর্ম বানিয়ে ছবি ও স্ট্যাটাস পরিবর্তনকে একই ইস্যু রেকর্ডের সঙ্গে যুক্ত করতে পারে, তারপর বাস্তব পরিবেশে ক্রুরা ব্যবহার করার পর স্ক্রিনটি বদলাতে পারে।

অতিরিক্ত কাজ ছাড়াই লোকেশন সংগ্রহ করুন

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

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

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

প্রয়োজন হলে মানচিত্রের পয়েন্টের চেয়ে বেশি তথ্য সংরক্ষণ করুন: লোকেশনের উৎস, সংগ্রহের সময়, নির্বাচিত সাইট এবং ছোট একটি লোকেশন নোট। «উত্তর লোডিং বে» একটি বড় সম্পত্তির মাঝখানে থাকা পিনের চেয়ে বেশি কার্যকর।

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

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

অফলাইন ড্রাফটকে ওয়ার্কফ্লোর অংশ করুন

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

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

আপলোডের অবস্থা সহজে বোঝান

প্রতিটি রিপোর্ট কোথায় আছে তা বোঝাতে সাধারণ লেবেল ব্যবহার করুন:

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

হোম স্ক্রিনে একটি ছোট সংখ্যাও সাহায্য করে। «আপলোডের অপেক্ষায় ৩টি» দেখলে নির্ভরযোগ্য নেটওয়ার্ক থাকা সাইট ছাড়ার আগে ক্রু মনে করতে পারেন।

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

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

ইস্যুর ধরন ও স্ট্যাটাস আপডেট সেট করুন

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

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

বড় ক্যাটালগ এড়িয়ে চলুন। ২৫টি ধরন স্ক্রল করতে হলে মানুষ কাছাকাছি অপশন বেছে নেবে বা রিপোর্ট দেরি করবে। শুরুতে পাঁচ থেকে দশটি ধরন সাধারণত যথেষ্ট কাঠামো দেয়। «অন্যান্য» রাখলে একটি ছোট নোট চাইুন, যাতে তালিকার ঘাটতি বোঝা যায়।

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

স্ট্যাটাসের তালিকা ছোট রাখুন:

• নতুন: রিপোর্টটি পর্যালোচনা দরকার
• দায়িত্ব দেওয়া হয়েছে: পরবর্তী কাজের দায়িত্ব কারও কাছে আছে
• কাজ চলছে: কাজ শুরু হয়েছে
• সমাধান হয়েছে: ক্রু কাজ সম্পন্ন করেছে
• বন্ধ: সুপারভাইজার ফলাফল পরীক্ষা করেছেন

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

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

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

একটি সহজ ক্রু রিপোর্টিং দৃশ্য

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

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

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

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

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

যে ভুলগুলো ক্রুর কাজ ধীর করে

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

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

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

সংরক্ষণকে দৃশ্যমান কাজ হিসেবে দেখান

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

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

বাস্তব ফিল্ড পরিস্থিতিতে পরীক্ষা করুন

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

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

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

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

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

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

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

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

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

ছোট একটি কার্যকর সংস্করণ দিয়ে শুরু করুন

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

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

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

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

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

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

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