अपने एसओपी को फ़ारमैट करना (Formatting Your SOP) अपना एसओपी लिखना सफलता और शुद्धता सुनिश्चित करना
एसओपी लिखने का कोई सही और ग़लत तरीका नहीं होता। हालांकि, शायद फ़ारमैटिंग गाइडलाइंस के लिए आपकी कंपनी के पास अनेक एसओपी होंगे, जिसमें वह आउटलाइन दी हुई होगी, जो आपकी कंपनी को पसंद हो। यदि ऐसा हो, तब पहले से मौजूद एसओपी को टेम्पलेट की तरह इस्तेमाल करिए। अगर ऐसा नहीं है, तब आपके पास कुछ ऑप्शंस हैं:   सरल स्टेप्स वाला फ़ारमैट: यह उन मामूली प्रोसीजर्स के लिए है जो छोटे होते हैं, जिनके संभावित परिणाम कम, और बहुत हद तक मुद्दे पर होते हैं। ज़रूरी डॉक्युमेंटेशन और सुरक्षा गाइडलाइंस के अलावा, यह बस सीधे सादे वाक्यों की एक बुलेट लिस्ट है जिसमें पाठक को बताते हैं कि क्या करना चाहिए।  हायरार्किकल (hierarchical ) स्टेप्स वाला फ़ारमैट: यह आम तौर पर लंबे प्रोसीजर्स के लिए होता है – जिसमें दस से अधिक स्टेप्स होते हैं, कुछ निर्णय लिए जाने होते हैं, एक्स्प्लेनेशन और टर्मिनोलोजी का इस्तेमाल होता है। यह मुख्य स्टेप्स की एक सूची होती है जिसमें एक निश्चित ऑर्डर में सब स्टेप्स बताए गए होते हैं।  फ़्लोचार्ट फ़ारमैट: अगर प्रोसीजर किसी नक्शे की तरह होता है जिसमें असंख्य संभावित नतीजे हो सकते हैं, शायद फ़्लोचार्ट ही सबसे बढ़िया तरीका होगा। आपको इस फ़ारमैट को तब चुनना चाहिए जब कि परिणामों को पहले से बता पाना हमेशा संभव न हो। अपने एसओपी लिखने से पहले ये तीन मुख्य मुद्दे ध्यान में रखे जाने चाहिए:   आपके पाठकों की पहले की नौलेज। क्या वे आपके ऑर्गनाइज़ेशन और उसके प्रोसीजर्स के बारे में पहले से जानते हैं? क्या उन्हें उसकी टर्मिनोलोजी मालूम है? आपकी भाषा को पाठक की नौलेज और उसकी समझ से मैच करना चाहिए।  आपके पाठक की भाषा क्षमता। क्या ऐसी कोई संभावना है कि वे लोग जिन्हें आपकी भाषा नहीं आती है वे आपके एसओपी पढ़ेंगे? यदि ऐसा है, तब टिप्पणियों के साथ बहुत से चित्र और डायग्राम शामिल करना एक अच्छी बात हो सकती है।  पाठक समूह का आकार। अगर अनेक लोग आपके एसओपी एक ही समय में पढ़ेंगे, तब डॉकयुमेंट को किसी नाटक में होने वाली बातचीत की तरह रखना अच्छा होगा: यूज़र 1 यह काम पूरा करेगा, जिसके बाद यूज़र 2 करेगा, वगैरह वगैरह। इस प्रकार हर पाठक यह समझ सकेगा कि उस सुचारु रूप से चलने वाली मशीन के ऑपरेशन में उसका हिस्सा क्या है। ज्ञान को ध्यान में रखिए: इसका मतलब केवल यह है: क्या आप ही वह व्यक्ति हैं जिसे इसको लिखना चाहिए? क्या आपको पता है कि इस प्रोसेस से क्या नतीजा मिलेगा? इसमें गड़बड़ी कैसे हो सकती है? इसे सुरक्षित कैसे बनाएँ? अगर आप यह सब नहीं जानते हैं, तब बेहतर होगा कि आप इसे किसी और को करने दें। बुरी तरह से लिखे – या उससे भी बुरा, कि ग़लत एसओपी, न केवल उत्पादकता कम कर देंगे और ऑर्गनाइज़ेशन को असफल करेंगे, बल्कि ये तो असुरक्षित भी हो सकते हैं और आपकी टीम से ले कर एनवायरनमेंट तक को नुकसान पहुंचा सकते हैं। संक्षेप में कहें, तो ये एक ऐसा रिस्क है जिसे आपको नहीं लेना चाहिए। यदि यह एक ऐसा प्रोजेक्ट है जो आपको असाइन (assign) किया गया है तथा आपको लगता है कि आप इसे पूरा करने के लिए मजबूर (या बाध्य) हैं तब उनसे सहायता मांगने में मत हिचकिचाइए जो इस प्रोसेस को प्रतिदिन पूरा करते हैं। अगर आप ऐसे लोगों के लिए एसओपी लिख या अपडेट कर रहे होंगे जिन्हें प्रोटोकॉल, टर्मिनोलोजी वगैरह का पता होगा, और जो बस उस एक संक्षिप्त और छोटे एसओपी से लाभ उठा सकते हैं, जो कि मूल रूप से एक चेकलिस्ट ही होगी, तब आप उसे शॉर्ट-फ़ॉर्म में लिख सकते हैं। मूल उद्देश्य और प्रासंगिक जानकारी (तिथि, लेखक, आईडी# वगैरह) के अलावा, यह तो बस स्टेप्स की एक छोटी लिस्ट होती है। जब कोई डिटेल और एक्स्प्लेनेशन देने की आवश्यकता न हो, तब इसे करने का यही तरीका है। ज़ाहिर तो यह है कि आपके ऑर्गनाइज़ेशन में एक प्रोसीजर होता है जिसे बार-बार दोहराया जाता रहता है। मगर क्या ऐसी कोई वजह है जिसके कारण यह एसओपी विशेष उपयोगी होगा? क्या इसमें सुरक्षा पर स्ट्रेस (stress) करने की ज़रूरत है? कंप्लायन्स (compliance) उपाय? क्या उसे नियमित, दिन प्रति दिन की ट्रेनिंग के लिए इस्तेमाल किया जाएगा? ये कुछ कारण हैं कि आपकी टीम की सफलता के लिए एसओपी क्यों आवश्यक है:  कंप्लायन्स स्टैंडर्ड के अनुपालन को सुनिश्चित करने के लिए उत्पादन आवश्यकताओं की वृद्धि के लिए सुनिश्चित करने के लिए कि प्रोसीजर का एनवायरनमेंट पर कोई बुरा प्रभाव नहीं पड़ता हो सुरक्षा सुनिश्चित करने के लिए सुनिश्चित करने के लिए कि सब कुछ शिड्यूल के अनुसार हो निर्माण में असफलताओं से बचने के लिए ट्रेनिंग डॉकयुमेंट की तरह यदि आपको पता हो कि आपके एसओपी को किस पर ज़ोर देना चाहिए, तब उन पॉइंट्स को ध्यान में रख कर अपने लिखने को स्ट्रक्चर देना आसान हो जाएगा। और यह देखना भी आसान हो जाएगा कि आपका एसओपी कितना महत्वपूर्ण है। आम तौर पर, टेक्निकल एसओपी में प्रोसीजर के अलावा चार और एलिमेंट्स (elements) होंगे:   टाइटल पेज इसमें शामिल होंगे 1) प्रोसीजर का टाइटल, 2) एसओपी आइडेंटिफिकेशन नंबर, 3) इशू या रिवीज़न की तिथि, 4) उस एजेंसी/डिवीज़न/ब्रांच का नाम जिस पर एसओपी लागू होगा, और 5) जिन्होंने एसओपी बनाया और एप्रूव किया उनका हस्ताक्षर। यदि सूचना स्पष्ट हो, तब आप जैसे भी चाहें उसे फ़ारमैट कर सकते हैं।  टेबल ऑफ कंटेंट्स संदर्भ की सुविधा के लिए यह तभी ज़रूरी होगा जब एसओपी काफ़ी बड़ा हो। यहाँ पर आपको एक सीधी सादी स्टैंडर्ड रूपरेखा मिलेगी।  क्वालिटी आश्वासन/क्वालिटी नियंत्रण वह प्रोसीजर अच्छा नहीं होता जिसे चेक नहीं किया जा सकता। आवश्यक सामग्री और डिटेल्स दीजिये ताकि पाठक सुनिश्चित कर सके कि उसे वांछित परिणाम मिले हैं। इसमें परफ़ोर्मेंस इवैल्यूएशन सैंपल जैसे, अन्य डॉकयुमेंट शामिल हो भी सकते हैं और नहीं भी हो सकते हैं।  संदर्भ सभी साइट किए गए और महत्वपूर्ण संदर्भ लिस्ट करना सुनिश्चित करें। अगर आप किन्हीं अन्य एसओपी का संदर्भ दे रहे हों, तब अपेंडिक्स में आवश्यक जानकारी एंक्लोज करना सुनिश्चित करें। आपके ऑर्गनाइज़ेशन का इससे भिन्न प्रोटोकॉल हो सकता है। अगर पहले से मौजूद ऐसे एसओपी हों जिनका आप संदर्भ ले सकें, तब इस स्ट्रक्चर को छोड़ दीजिये और जो पहले से मौजूद है, उसी पर कायम रहिए। स्कोप तथा उपयोगिता। दूसरे शब्दों में प्रोसेस का उद्देश्य, उसकी सीमाएं, तथा उसका इस्तेमाल कैसे होता है यह बताइये। इसमें स्टैंडर्ड, रेगुलेटरी ज़रूरतें, रोल तथा ज़िम्मेदारियाँ, तथा इनपुट और आउटपुट शामिल करिए।  मेथोडोलोजी तथा प्रोसीजर्स। मुख्य बात यह है – सभी स्टेप्स को आवश्यक डिटेल्स के साथ सूचीबद्ध करिए, जिसमें आवश्यक इक्विपमेंट्स भी शामिल हों। सीक्वेंस के प्रोसीजर और निर्णय लेने के फ़ैक्टर्स भी कवर करिए। "क्या होगा जबकि" तथा संभावित हस्तक्षेप या सुरक्षा विचारों का भी ध्यान रखिए।  टर्मिनोलोजी का स्पष्टीकरण। सभी ऐसे एक्रोनिम (acronym), एब्रिविएशन्स (abbreviations), और सभी फ़्रेज़ेस जो आम तौर पर इस्तेमाल नहीं होते उनके बारे में बताइये।  स्वास्थ्य और सुरक्षा चेतावनियाँ। इसे अपने सेक्शन में लिखा जाना चाहिए और उन स्टेप्स के साथ भी जहां इनकी संभावना हो। इस सेक्शन को नज़रअंदाज़ मत करिए।  इक्विपमेंट और सप्लाइज़। जो भी चाहिए और जब भी, उसकी पूरी सूची, इक्विपमेंट कहाँ मिलेंगे, इक्विपमेंट का स्टैंडर्ड क्या होगा, वगैरह।  चेतावनियाँ और हस्तक्षेप। मूलतः, एक ट्रबलशूटिंग सेक्शन। कवर करिए कि क्या गड़बड़ हो सकता है, किसका ध्यान रखना है, और क्या है जो अंतिम, आदर्श प्रोडक्ट में हस्तक्षेप कर सकता है।  अपने एसओपी को बहुत अधिक शब्दों वाला और उलझाने वाला होने से बचाने के लिए, और आसानी से संदर्भ पाने के लिए इन सभी टॉपिक्स को अलग सेक्शन्स (जिन्हें आम तौर पर संख्याओं या अक्षरों से दिखाया जाता है) में रखिए। यह किसी भी तरह से पूर्ण सूची नहीं है; यह तो प्रोसीजरल आइसबर्ग की बस टिप मात्र है। आपका ऑर्गनाइज़ेशन शायद ऐसा कोई अन्य पक्ष भी बता सकता है जिन पर ध्यान देने की ज़रूरत हो। संभावना यही है कि आपके पाठक इसे मनोरंजन के लिए नहीं पढ़ रहे होंगे। आप इसे छोटा और स्पष्ट ही रखना चाहेंगे – अन्यथा उनका ध्यान भटक सकता है या उन्हें यह डॉकयुमेंट मुश्किल और कठिनाई से समझ में आने वाला लगेगा। सामान्यतः, अपने वाक्यों को जितना हो सके उतना छोटा रखिए।   यह है एक बुरा उदाहरण: इस्तेमाल करने से पहले सुनिश्चित करिए कि एयर शैफ्ट्स में से धूल झाड़ दी जाए।  यह है एक अच्छा उदाहरण: इस्तेमाल से पहले सभी एयर शैफ्ट्स को वैक्यूयम कर दीजिये। आम तौर पर "आप" का इस्तेमाल मत करिए। उसका बस इशारा होना चाहिए। एक्टिव वॉइस में बात करिए और अपने वाक्यों को कमांड वर्ब्स से शुरू करिए। आप शायद यह तो बिलकुल नहीं करना चाहेंगे कि ऐसा एसओपी लिखें जो अशुद्ध हो। आप अपनी टीम की सुरक्षा, एफ़िकेसी (efficacy), और समय का जोखिम उठा रहे हैं और एक स्थापित प्रोसेस को ले कर उस पर बिलकुल ध्यान नहीं दे रहे हैं – जिसे आपके टीममेट थोड़ा अपमानजनक समझ सकते हैं। अगर आवश्यकता हो, सवाल अवश्य पूछिये! आप इसे सही ही करना चाहेंगे। बेशक, अगर आपको नहीं मालूम हो, तो सभी रोल और जिम्मेदारियों को कवर करते हुये, अनेक सोर्सेज़ से पूछिये। हो सकता है कि एक टीम सदस्य स्टैंडर्ड ऑपरेटिंग प्रोसीजर का पालन नहीं करता हो या दूसरा काम के किसी एक ही हिस्से में शामिल रहता हो। यदि कोई एक या दो स्टेप्स ऐसे हों जो कि खास तौर से डरावने हों, तब पाठकों के लिए किसी प्रकार के चार्ट या डायग्राम बना कर उन्हें आसान बना दीजिये। इससे पढ़ना आसान हो जाता है और दिमाग़ को भी सारी बात समझने की तकलीफ़ नहीं उठानी पड़ती। और आपके लिए वह अधिक पूर्ण और बढ़िया लिखा हुआ लगेगा। इनका इस्तेमाल अपने एसओपी की लंबाई बढ़ाने के लिए मत करिए; केवल तभी करिए जबकि यह आवश्यक हो या आप भाषा के किसी गैप को भरने का प्रयास कर रहे हों। आपका एसओपी शायद अनेक एसओपी में से एक होगा-जिसके कारण, आशा है कि आपके ऑर्गनाइज़ेशन में एक तरह का बड़ा डेटाबेस होगा जिसमें एक निश्चित रेफेरेंस सिस्टम में सब कुछ कैटलॉग किया होगा। आपका एसओपी इस रेफेरेंस सिस्टम का एक भाग है, इसलिए उसे खोजे जाने के लिए किसी प्रकार का कोड भी दिया जाना चाहिए। यहीं पर नोटेशन की ज़रूरत पड़ती है। हर पेज पर दाएँ ऊपरी कोने पर (अधिकांश फ़ारमैट में) एक शॉर्ट टाइटल या आईडी#, रिवीज़न नंबर, तिथि और "पेज # ऑफ #" होना चाहिए। आपके ऑर्गनाइज़ेशन की पसंद के आधार पर, आपको फ़ुटनोट (या इनको फुटनोट में रखने) की ज़रूरत हो भी सकती है और नहीं भी हो सकती है। यदि आप अपने प्रोसीजर को टेस्ट नहीं करना चाहते हैं, उसका मतलब है कि आपने शायद उसे ठीक से नहीं लिखा है। प्रोसेस की सीमित जानकारी वाले किसी व्यक्ति (या किसी ऐसे व्यक्ति से जो आम आदमी का प्रतिनिधित्व कर सके) को अपने एसओपी से गाइड होने दीजिये। उन्हें क्या परेशानियाँ आईं? अगर आईं, तो उनका निवारण करिए और आवश्यक सुधार करिए।  सबसे अच्छा तो यह होगा कि आप कुछ लोगों को अपना एसओपी टेस्ट करने दें। अलग अलग लोगों की अलग अलग समस्याएँ होंगी, जिसके कारण विविध प्रतिक्रियाएँ (आशा है, उपयोगी) मिल सकेंगी। प्रोसीजर को किसी ऐसे पर टेस्ट कराएं जिसने वह सब पहले कभी न किया हो। जिस किसी के पास भी पहले से जानकारी होगी वह काम पूरा करने के लिए अपने ज्ञान पर भरोसा करेगा, आपके काम पर नहीं, जिससे उद्देश्य पूरा नहीं होगा। आखिरकार, इससे वास्तव में कोई अंतर नहीं पड़ता कि आपके बॉस एसओपी के बारे में क्या सोचते हैं। उसका महत्व केवल उनके लिए है जो वास्तव में वह काम करते हैं। इसलिए अपना काम उच्चाधिकारियों को देने से पहले, काम को उन्हें दिखाइए जो उस काम को करते हैं (या करेंगे)। वे लोग उसके बारे में क्या सोचते हैं? उन्हें काम में शामिल होने की अनुमति देने से उन्हें लगेगा कि वे उस प्रोसेस के हिस्से हैं और इससे उनके द्वारा, इस एसओपी, जिस पर आप काम कर रहे हैं, उसे स्वीकारने की संभावना बढ़ जाएगी। और बेशक उनके पास कुछ बढ़िया विचार होंगे ही! जब टीम आपको आगे बढ्ने की अनुमति दे दे, तब उसे अपने एड्वाइज़र्स को भेज दीजिये। असली कंटेन्ट पर तो उनके इनपुट की संभावना कम ही है, मगर वे आपको बता देंगे कि क्या वह फ़ारमैटिंग आवश्यकताओं को पूरा करता है, क्या आपसे कुछ छूट गया है, और उसे आधिकारिक और सिस्टम में इनपुट करने का प्रोटोकॉल क्या है।  एप्रूवल की ऑडिट ट्रेल सुनिश्चित करने के लिए एसओपी को एप्रूवल के लिए डॉकयुमेंट मैनेजमेंट सिस्टम का इस्तेमाल करके भेजिये। यह प्रत्येक ऑर्गनाइज़ेशन में अलग तरह से होगा। मूलतः, आप चाहते हैं कि सब कुछ गाइडलाइंस और रेगुलेशन्स के अनुसार ही हो। हस्ताक्षरों की आवश्यकता होगी और अधिकांश ऑर्गनाइज़ेशनों में आजकल इलेक्ट्रोनिक हस्ताक्षर स्वीकार करने में कोई समस्या नहीं होती है। इसके लिए हो सकता है कि प्रभावित कर्मचारियों के लिए प्रशिक्षण कार्यक्रम चलाये जाएँ (जैसे कि क्लास रूम ट्रेनिंग, कंप्यूटर आधारित ट्रेनिंग आदि) या शायद बाथरूम में उसके पर्चे टाँगे जाएँगे। जो भी हो, अपने काम को बाहर फैलाने दीजिये! आपने उसके लिए मेहनत की है। अब पहचान का समय है! सुनिश्चित करिए कि आपका एसओपी ताज़ा रहे। अगर वह कभी आउटडेटेड हो जाये, तब उसे अपडेट करिए, अपडेट्स को फिर से एप्रूव और डॉकयुमेंट करवाइए, और जैसे ज़रूरी हो एसओपी को फिर से बंटवाइए। आपकी टीम की सुरक्षा, उत्पादकता और सफलता उसी पर आधारित है।
अपना फ़ारमैट चुनिये: अपने पाठकों को ध्यान में रखिए: अपने तय करिए कि एसओपी लंबा होगा या संक्षिप्त: अपने एसओपी के उद्देश्य का ध्यान रखिए: आवश्यक सामग्री कवर की जाए: प्रोसीजर के लिए, सुनिश्चित करिए कि आप निम्न को कवर करें: अपने लेखन को संक्षिप्त और पढ़ने में आसान बनाए रखिए: यदि ज़रूरी हो, तो जो लोग उस प्रोसेस में शामिल हों उनका इंटरव्यू करिए कि वे काम कैसे करते हैं: टेक्स्ट के बड़े हिस्सों को डायग्राम और फ़्लोचार्ट्स में बाँट दीजिये: सुनिश्चित करिए कि प्रत्येक पेज पर कंट्रोल डॉकयुमेंट नोटेशन हो: प्रोसीजर को टेस्ट करिए: एसओपी उनसे रिव्यू करवाइए जो वास्तव में वह प्रोसीजर करते हैं: अपने एसओपी को अपने एड्वाइज़र्स और क्वालिटी अश्युरेंस टीम द्वारा रिव्यू कराइए: एक बार एप्रूव हो जाने के बाद, अपने एसओपी को लागू करना शुरू करिए:
https://www.wikihow.com/Write-a-Standard-Operating-Procedure https://www.wikihow.com/Write-a-Standard-Operating-Procedure https://www.wikihow.com/Write-a-Standard-Operating-Procedure
Formatting Your SOP Writing Your SOP Ensuring Success and Accuracy