संदर्भ की शर्तें कैसे विकसित करें। भाग 2. व्यवसाय प्रक्रियाओं का वर्णन करने के लिए एक लेखा प्रणाली और जानकारी के लिए आवश्यकताओं को इकट्ठा करते समय काम के प्रकार

लेख का पहला भाग "तकनीकी कार्य का विकास" यह क्या है, इसकी आवश्यकता क्यों है, कहां शुरू करना है और यह कैसा दिखेगा? " काफी रुचि पैदा हुई। अपने न्यूज़लेटर के अलावा, मैंने इसे प्रसिद्ध इन्फोस्टार्ट डेवलपर्स साइट पर प्रकाशित किया, जहां यह और भी अधिक रुचि पैदा हुई, जो अच्छी खबर है। जैसा कि वादा किया गया था, मैं एक सीक्वल लिख रहा हूं।

अच्छी तरह से सोचते हुए, मैंने फैसला किया कि यह योजनाबद्ध दूसरे भाग की सभी सामग्री को एक लेख में फिट करने के लिए फिर से काम नहीं करेगा, अन्यथा यह सिद्धांत में सबसे ऊपर होगा, जो पहले से ही कई पाठ्यपुस्तकों में लिखा गया है। लेकिन मैंने कार्य निर्धारित किया है ताकि इसे व्यवहार में लागू किया जा सके, इसलिए मैं अब भविष्य के लिए कोई योजना नहीं बनाऊंगा कि विषय के साथ समाप्त करने के लिए अभी भी कितने मुद्दों की आवश्यकता होगी। यह पाठकों की प्रतिक्रिया से प्रभावित होगा, इसलिए लिखो, शरमाओ मत!

इस अवसर को लेते हुए, मैं एक प्रश्न पूछना चाहता हूं: संदर्भ की शर्तों के विकास पर सेंट पीटर्सबर्ग में एक व्यावहारिक प्रशिक्षण संगोष्ठी आयोजित करना कितना दिलचस्प होगा? मिले होंगे, अनुभवों का आदान-प्रदान किया होगा। यदि ऐसी रुचि एकल नहीं है, तो मैं व्यवस्थित करने का वचन देता हूं।

चूंकि पाठक न केवल सॉफ्टवेयर विकास के क्षेत्र में विशेषज्ञ हैं, बल्कि विभिन्न स्तरों पर व्यावसायिक विश्लेषक और प्रबंधक भी हैं, मैं इस तरह से लिखने की कोशिश करूंगा जो सभी के लिए दिलचस्प हो।

इस भाग में, हम इस बारे में बात करेंगे कि आवश्यकताओं को इकट्ठा करने के चरण को कैसे व्यवस्थित किया जाए, इसमें क्या होना चाहिए और आप कौन से उपकरण का उपयोग कर सकते हैं। मैं दोहराता हूं कि व्यावसायिक प्रक्रियाओं का वर्णन करने के लिए चरणों के दृष्टिकोण से डेटा उद्यम के सर्वेक्षण के समान है।

जैसा कि आमतौर पर जीवन में होता है:

अधिकांश परियोजनाओं में यह कैसे होता है
चरणों	यह कैसे होता है
निर्णय, परियोजना होने के लिए किया जाता है!	यह स्पष्ट है कि खुशी का कारण है, खासकर यदि परियोजना बड़ी है, तो इसमें कुछ भी गलत नहीं है! मुख्य बात बहुत लंबे समय तक आनन्दित नहीं करना है, वास्तविक काम की शुरुआत में देरी करना, इस समय से अलग तरीके से जाना जाएगा।
हमने नेताओं के साथ बैठक की, परिणाम की उनकी दृष्टि के बारे में कुछ जानकारी एकत्र की।	आमतौर पर यह प्रक्रिया प्रबंधन के साथ कई बैठकों तक सीमित होती है, फिर विभागों के प्रमुखों के साथ। ग्राहक के हिस्से पर कुछ "आग्रह" करने के बाद, वे सामान्य योगों के रूप में तय किए जाते हैं। कभी-कभी मौजूदा दस्तावेज़ को इसमें जोड़ा जाता है (किसी ने एक बार सर्वेक्षण करने का प्रयास किया, मौजूदा नियमों पर दस्तावेज़, उपयोग की गई रिपोर्ट के रूप) आश्चर्यजनक रूप से, लेकिन उसके बाद, स्वचालन प्रणाली के अधिकांश कार्यान्वयनकर्ता खुशी से चिल्लाते हैं: "हाँ, हमारे सिस्टम में यह सब है! ठीक है, थोड़ा ट्वीक और सब कुछ काम करेगा। ” यह पूछे जाने पर कि क्या अंत उपयोगकर्ताओं के साथ सब कुछ काम करना चाहिए (या एक विशिष्ट प्रक्रिया कैसे की जाती है) पर चर्चा की जाए, तो उत्तर आमतौर पर नकारात्मक होता है। यह सुझाव दिया जाता है कि प्रबंधक अपने अधीनस्थों के लिए सब कुछ जानता है। लेकिन व्यर्थ में ... इसके पीछे बहुत सारे जाल और बाधाएं निहित हैं, और काम का वितरण एक बाधा कोर्स के साथ मैराथन में बदल सकता है। जैसा कि आप जानते हैं, यह एक सपाट सड़क पर मैराथन दौड़ने के लिए प्रथा है, और बाधाओं के साथ चलना कम दूरी पर ही संभव है (आप दौड़ नहीं सकते)।
दस्तावेजीकरण के काम के परिणाम	इसके बाद, काम के उद्देश्यों के आधार पर परिणामों का दस्तावेज़ीकरण शुरू होता है: यदि आपको संदर्भ की शर्तों को विकसित करने की आवश्यकता है , तो सलाहकार तैयार दस्तावेज़ टेम्पलेट पर प्राप्त जानकारी को बिखेरना शुरू कर देता है, ताकि यह सुंदर दिखे और बुनियादी आवश्यकताएं तय हो जाएं (जो कि प्रबंधन द्वारा आवाज उठाई गई हैं, अन्यथा वे नहीं हो सकते हैं) अनुमोदन)। यह समझते हुए कि इस तरह के संदर्भ की शर्तों का विशेष रूप से उपयोग नहीं किया जाता है और "रास्ते में" सब कुछ पता लगाना आवश्यक है, वह संदर्भ की शर्तों का मुख्य लक्ष्य अनुमोदन और अनुमोदन के लिए न्यूनतम समय निर्धारित करता है । और, यदि संभव हो तो, भविष्य के काम की लागत के अनुमानित अनुमान के लिए जानकारी (वैसे, महत्वपूर्ण भी)। यदि आपको व्यावसायिक प्रक्रियाओं का वर्णन करने की आवश्यकता है। अजीब तरह से पर्याप्त है, लेकिन अक्सर सभी पिछले चरण समान दिखते हैं, जैसा कि संदर्भ की शर्तों के विकास के साथ होता है। फर्क सिर्फ कागजी है। संभावित विकल्प हैं: सलाहकार मनमाने शब्दों में प्रक्रिया का वर्णन करते हैं या व्यावसायिक प्रक्रियाओं (नोटेशन) का वर्णन करने के लिए किसी भी नियम का उपयोग करते हैं। पहले मामले में, ऐसा दस्तावेज़ आश्चर्यजनक रूप से संदर्भ की शर्तों के समान है। यह भी होता है कि यदि आप शीर्षक पृष्ठ को प्रतिस्थापित करते हैं, तो आपको कोई अंतर नहीं दिखाई देगा। बाद के मामले में, जोर अक्सर वास्तविकता पर नहीं होता है, लेकिन "सही वर्णन" पर, अर्थात्। विवरण के नियमों का औपचारिक पालन। दुर्भाग्य से, दोनों विकल्प सबसे अच्छा अभ्यास नहीं हैं, जैसा कि बल्कि, वे एक औपचारिकता हैं, न कि कई लाभ।

ऊपर वर्णित के रूप में ऐसी प्रथा क्यों विकसित हुई है? सच कहूं तो मुझे नहीं पता। किसी से पूछो, कोई नहीं जानता। इसके अलावा, स्थिति बहुत जल्दी नहीं बदलती है, हालांकि वे लगातार चर्चा करते हैं, अनुभवों का आदान-प्रदान करते हैं, इस विषय पर किताबें लिखते हैं ... यह मुझे लगता है कि कारणों में से एक प्रासंगिक शिक्षा की निम्न गुणवत्ता है। यह इस तथ्य से भी प्रभावित हो सकता है कि कई विशेषज्ञ दूसरे व्यवसाय से सामान्य रूप से आते हैं, और व्यवहार में सब कुछ समझ लेते हैं, अर्थात्। उनका अनुभव उस वातावरण में बनता है जहां उन्हें मिला था। विश्वविद्यालयों का रवैया और वास्तविकता के करीब होने की उनकी इच्छा की कमी भी एक ज्ञात तथ्य है, लेकिन उनकी स्थिति कभी-कभी मुझे आश्चर्यचकित करती है। उदाहरण के लिए, मेरे पास एक मामला था जब एक स्नातक छात्र, एक प्रतिभाशाली विशेषज्ञ, 1 सी प्लेटफ़ॉर्म (अच्छा उद्योग विकास) पर एक थीसिस लिखना चाहता था, लेकिन विभाग में उसे बताया गया था कि विषय की परवाह किए बिना, यह एक "उत्कृष्ट" निशान पर भरोसा करना असंभव होगा, क्योंकि 1C तुच्छ प्रणाली। यहाँ बिंदु ऐसी राय की गंभीरता और निष्पक्षता नहीं है, लेकिन यह तथ्य कि शास्त्रीय प्रोग्रामिंग भाषा में एक आदिम कार्य को तुरंत "उत्कृष्ट" निशान के योग्य माना जाता था।

आइए उपरोक्त प्रक्रिया को अधिक व्यवस्थित दृष्टिकोण देने का प्रयास करें। तब वह कैसा दिख सकता है?



जैसा कि आप देख सकते हैं, प्रक्रिया एक प्रश्न के साथ समाप्त होती है, क्योंकि इस पर काम खत्म हो गया है और सबसे कठिन और सबसे व्यावहारिक शुरू हो जाएगा - वास्तविक जीवन में परिणाम की प्रयोज्यता को निर्धारित करेगा। ठीक उसी तरह जो पिछले काम के भाग्य का निर्धारण करेगा: या तो यह कोठरी (शेल्फ पर या कहीं और) जाएगा, या यह जानकारी का एक मूल्यवान स्रोत होगा। बेहतर अभी तक, अगर यह भविष्य की परियोजनाओं के लिए एक मॉडल बन जाता है।

मैं इस बात पर जोर देना चाहता हूं कि आरेख में अंतिम चरण तक (जहां सवाल है), कंपनी की गतिविधियों के बारे में जानकारी एकत्र करने का सामान्य सिद्धांत एक ही दिखता है, चाहे भविष्य में क्या किया जाए, व्यावसायिक प्रक्रियाओं का वर्णन करें या एक स्वचालित प्रणाली शुरू करें। हां, चरणों का क्रम समान है, लेकिन उनमें से कुछ पर उपयोग किए जाने वाले उपकरण भिन्न हो सकते हैं। हम निश्चित रूप से उस क्षण पर विचार करेंगे जब हम व्यक्तिगत चरणों के तरीकों और उपकरणों का अध्ययन करेंगे। हम इसे अलग-अलग लेखों में विस्तार से करेंगे, और अब हम केवल सबसे महत्वपूर्ण बात पर विचार करेंगे। आगे के चरण अलग-अलग होंगे और यह निर्धारित किया जाएगा कि परियोजना के लिए क्या आवश्यक है: व्यापार प्रक्रियाओं का वर्णन करना या लेखा प्रणाली को लागू करना।

आइए देखें कि आप कंपनी के बारे में जानकारी एकत्र करने के लिए दृष्टिकोण को कैसे पुनर्गठित कर सकते हैं।

काम के अधिक सक्षम संगठन के साथ ऐसा कैसे हो सकता है
चरणों	यह कैसे होता है
निर्णय, परियोजना होने के लिए किया जाता है!	पहले विकल्प के बारे में यहां कुछ भी नहीं बदला, किसी ने भावनाओं को रद्द नहीं किया
हमने नेताओं के साथ बैठक की, परिणाम की उनकी दृष्टि के बारे में कुछ जानकारी एकत्र की।	यह कदम भी बना हुआ है, और इसका बहुत महत्व है। लेकिन प्रबंधकों और मालिकों के साथ पहली बैठक (या कई बैठकें) का मुख्य उद्देश्य एक-दूसरे को जानना है। लोगों और कंपनी के साथ सबसे पहले परिचित होना। इस तरह की आम बैठकों में दिए गए लक्ष्य और इच्छाएं बहुत अलग हो सकती हैं, जिनमें शानदार भी शामिल हैं। उन सभी को, निश्चित रूप से सुना जाएगा, लेकिन इस तथ्य पर नहीं कि उन्हें लागू किया जाएगा। कंपनी के व्यवसाय में एक गहरी विसर्जन के साथ, अन्य लक्ष्य दिखाई देंगे और पिछले वाले खारिज कर दिए जाएंगे। मेरा मतलब है कि प्रारंभिक बैठकों से स्पष्ट लक्ष्यों को तैयार करना असंभव है, इस सब के लिए सावधानीपूर्वक अध्ययन की आवश्यकता होगी। ऐसी बैठकों में, मालिकों और शीर्ष अधिकारियों से सभी संदेशों को रेखांकित करना आवश्यक है ताकि आप तब उन पर वापस लौट सकें और चर्चा कर सकें जब पर्याप्त जानकारी एकत्र की गई हो। यहां तक ​​कि एक साधारण सी आवश्यकता भी अवास्तविक या बहुत श्रमसाध्य हो सकती है।
ग्राहक और ठेकेदार से एक कार्यकारी समूह का गठन, भूमिकाओं का वितरण	यह तय करना आवश्यक है कि ग्राहक की तरफ से और ठेकेदार से परियोजना पर काम कौन करेगा। इस चरण की स्पष्ट सादगी के बावजूद, इसकी बहुत बड़ी भूमिका है। यदि आप स्पष्ट रूप से रिकॉर्ड नहीं करते हैं कि किसके लिए जिम्मेदार है, तो कार्य के कार्यान्वयन के दौरान आप भ्रम के जोखिम को चलाते हैं। यदि आपके भाग के लिए आप हमेशा अपनी टीम में भूमिकाएँ निर्दिष्ट कर सकते हैं, तो ग्राहक को इससे समस्या हो सकती है। आपको क्या ध्यान देना चाहिए: भविष्य में जो लोग कम से कम किसी भी तरह से परिणाम को अपनाने को प्रभावित करेंगे, उन्हें ग्राहक के कार्य समूह का हिस्सा होना चाहिए। यदि हम उस स्थिति को अनुमति देते हैं कि जब काम पूरा हो जाता है, तो ग्राहक के कर्मचारी जो लक्ष्य निर्धारित करने और आवश्यकताओं की पहचान करने के लिए काम में भाग नहीं लेते हैं, वे जुड़ जाएंगे, फिर समस्याओं की गारंटी होगी यहां तक ​​कि ऐसी बेतुकी स्थिति भी संभव है कि सब कुछ आवश्यकतानुसार न हो जाए। मेरे व्यवहार में, मुझे एक से अधिक बार ऐसी स्थिति का सामना करना पड़ा है। इसलिए, यदि आप कोई ग्राहक नहीं, बल्कि ग्राहक समूह का काम करते हैं, तो आप अपनी सुरक्षा कर सकते हैं। कार्य की स्वीकृति में भाग ले सकते हैं । और सबसे अच्छा, इसे अनुबंध की शर्तों (अनुबंध या परियोजना के चार्टर) में निर्धारित करने के लिए। मुझे याद है कि इस तरह का एक मामला था: एक बड़ी परियोजना में, संस्थापक ने इस प्रक्रिया में शामिल होने का फैसला किया (मुझे पता नहीं क्यों, यह देखना उबाऊ हो गया) और एक बैठक में भाग लिया जिसमें बिलिंग ग्राहकों के मुद्दे पर चर्चा की गई थी। उन्हें यह जानकर आश्चर्य हुआ कि एक बिक्री प्रबंधक एक ग्राहक को बिल देता है। उनकी प्रस्तुति में, एकाउंटेंट को चालान करना चाहिए, और कुछ नहीं। लेकिन वास्तव में, लेखाकार को पता नहीं था कि क्या चल रहा है, और प्रबंधक इस तरह से काम करने की कल्पना नहीं कर सकता है, अगर आप हर खर्च पर एकाउंटेंट को चलाते हैं। नतीजतन, हमने बहुत समय खो दिया, लेकिन कुछ भी नहीं बदला, प्रबंधक ने अभी भी बिल किया। और संस्थापक अपनी राय में बने रहे, लेकिन अब इस प्रक्रिया में हस्तक्षेप नहीं किया। उसी चरण में, परियोजना के चार्टर को विकसित करने की सलाह दी जाती है, जिसमें प्रतिभागियों की भूमिकाओं को ठीक करने के लिए, संचार के क्रम, विनियमन और रिपोर्टिंग की संरचना, साथ ही साथ अन्य सभी चीजें जो चार्टर में निर्धारित की जानी चाहिए। परियोजना के चार्टर का विकास फिर से एक अलग मुद्दा है।
कार्य विधियों और उपकरणों में परियोजना टीम का प्रशिक्षण, कार्य नियमों का समन्वय, प्रलेखन के प्रकार और संरचना	सबसे पहले, प्रोजेक्ट टीम को यह समझाने की आवश्यकता है कि चार्टर में जो कुछ भी लिखा गया है, उसे व्यवहार में कैसे लागू किया जाएगा। दूसरे, ग्राहक की परियोजना टीम को उन कार्य विधियों में प्रशिक्षित किया जाना चाहिए जिन्हें आप बाद के सभी चरणों में उपयोग करना चाहते हैं। नमूनों पर विचार करने के लिए, उपयोग किए जाने वाले दस्तावेजों के स्वरूपों पर चर्चा करना समझ में आता है। यदि मॉडल या व्यावसायिक प्रक्रियाओं का वर्णन करने के लिए कोई नियम लागू किया जाता है, तो इन नियमों पर चर्चा की जानी चाहिए ताकि वे समझने योग्य हों।
पूछताछ	प्रश्न मंच कंपनी के बारे में जानकारी का एक काफी विश्वसनीय टुकड़ा प्राप्त करने के लिए एक अपेक्षाकृत त्वरित तरीका देता है। इस तरह की जानकारी की गुणवत्ता तीन कारकों द्वारा निर्धारित की जाएगी: सबसे पहले, जिस तरह से आपने ग्राहक की डिज़ाइन टीम को प्रशिक्षित किया है। उन्हें स्पष्ट रूप से समझना चाहिए कि प्रश्नावली प्रक्रिया कैसे चल रही है और सभी प्रतिभागियों को जानकारी देने में सक्षम है। प्रश्नावली का बहुत ही रूप। प्रश्नावली स्पष्ट होनी चाहिए। यह सलाह दी जाती है कि प्रश्नावली को भरने के लिए निर्देश हों। और भी बेहतर है अगर भरने का एक उदाहरण है। प्रतिभागियों की रचना। आपको प्रतिभागियों की संरचना का सही चयन करना होगा। यदि हम खुद को केवल प्रबंधकों तक सीमित रखते हैं, तो विश्वसनीय जानकारी एकत्र करने से काम नहीं चलेगा। मैं प्रश्नावली में सभी को शामिल करने की सलाह देता हूं जो भविष्य में अंतिम परिणामों का उपयोगकर्ता होगा। उदाहरण के लिए, यदि यह एक स्वचालित प्रणाली की शुरूआत की बात आती है, तो यह सभी के लिए लायक है जो एक उपयोगकर्ता होगा। ऐसे मामले हैं जब एक स्थिति के 10 कर्मचारियों में से एक ऐसा है जो कुछ विशेष कार्य करता है जो कि शेष 9 में से कोई भी नहीं जानता है (उदाहरण के लिए, प्रबंधन के लिए एक विशेष रिपोर्ट तैयार करता है)। यदि हम कर्तव्यों के आगे पुनर्वितरण या नौकरी के विवरण के विकास के बारे में बात कर रहे हैं, तो आपको भी ऐसा ही करना चाहिए। मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि स्वचालित प्रणाली के बाद के कार्यान्वयन के लिए प्रश्नावली पद्धति या सही मामले में व्यावसायिक प्रक्रियाओं का वर्णन अलग है। बेशक, प्रश्नावली की संरचना समान हो सकती है, लेकिन यह सबसे अच्छा विकल्प नहीं है। जब हम व्यावसायिक प्रक्रियाओं का वर्णन करते हैं, तो प्रश्नावली आमतौर पर प्रकृति में अधिक सामान्य होती हैं, क्योंकि यह ठीक से ज्ञात नहीं है कि क्या सामना करना पड़ेगा। यदि हम एक विशिष्ट स्वचालित प्रणाली के कार्यान्वयन के बारे में बात कर रहे हैं, तो प्रश्नावली के लिए बेहतर है कि इस प्रणाली की विशेषताओं को ध्यान में रखा जाए। इस दृष्टिकोण के साथ, आप तुरंत सिस्टम के सभी बाधाओं को पहचान सकते हैं जो उद्यम के लिए उपयुक्त नहीं हैं। एक नियम के रूप में, तैयार सिस्टम को लागू करने के तरीकों में इस तरह के प्रश्नावली की उपलब्धता शामिल है। इस तरह के प्रश्नावली को लेखांकन के विशिष्ट क्षेत्रों (उदाहरण के लिए, आदेश, बिक्री, मूल्य निर्धारण के लिए लेखांकन), या विशिष्ट पदों (वित्तीय निदेशक, उदाहरण के लिए) के लिए विकसित किया जा सकता है। प्रश्नों की रचना उसी के बारे में है।
पोल	व्यक्तिगत प्रक्रियाओं की विशेषताओं का पता लगाने के लिए विशेषज्ञों के साथ एक सर्वेक्षण एक मौखिक साक्षात्कार है। सर्वेक्षण को व्यवस्थित करना आवश्यक है ताकि यह सिर्फ "मिले, बात" न करे, लेकिन अधिक संगठित हो। इसके लिए, एक तथाकथित सर्वेक्षण योजना तैयार करना आवश्यक है। इसमें प्रश्नावली के उन हिस्सों को शामिल किया जा सकता है जो आपके पास प्रश्न हैं, अन्य प्रोफाइल की जानकारी के विपरीत है या जानकारी को सतही रूप से प्रस्तुत किया गया है। केवल व्यक्तिगत अनुभव से प्रश्न जोड़ना उचित है। उत्तर बिना किसी असफलता के दिए जाने चाहिए। आदर्श यदि आप ऑडियो रिकॉर्ड करने के लिए सहमत हैं। उसी चरण में, किसी को दस्तावेज़ प्रवाह पर प्रदान की गई जानकारी की पूर्णता का पालन करना चाहिए (प्राथमिक दस्तावेजों और विभिन्न रिपोर्टों के दोनों रूप)
प्रमुख व्यावसायिक प्रक्रियाओं या स्वचालन के क्षेत्रों पर प्रकाश डालें	प्रश्नावली और सर्वेक्षण के बाद, यह यथोचित माना जा सकता है कि प्रमुख व्यावसायिक प्रक्रियाओं की पहचान के बारे में निष्कर्ष निकालने के लिए पर्याप्त जानकारी है। वास्तव में, यह न केवल प्रमुख व्यावसायिक प्रक्रियाओं को एकल करने के लिए संभव है, बल्कि लगभग सब कुछ (यदि प्रतिभागियों की रचना सही ढंग से चुनी गई थी)। व्यावसायिक प्रक्रियाओं को उजागर करने का मुद्दा पूरी तरह से अलग और कठिन विषय है। यहां सीखना मुश्किल है और मुख्य रूप से अनुभव द्वारा विकसित किया गया है। चयनित व्यावसायिक प्रक्रियाओं से एक सूची (क्लासिफायरियर) बनानी चाहिए। फिर निर्णय करना संभव होगा, उनमें से किस पर अधिक गहराई से जांच की जानी चाहिए, जो कि नहीं हैं, और प्राथमिकता के लिए भी।
मुख्य प्रणाली आवश्यकताओं, लक्ष्यों, परियोजना की सफलता के मापदंड, विस्तृत अध्ययन के लिए प्रक्रियाओं का गठन	इस चरण तक, कंपनी की गतिविधियों के बारे में सभी प्राथमिक जानकारी एकत्र की जानी चाहिए, संकलित व्यावसायिक प्रक्रियाओं की एक सूची। अब लक्ष्यों पर लौटने के लिए, उन्हें निर्दिष्ट करें, यदि आवश्यक हो, तो कंपनी के शीर्ष अधिकारियों के साथ चर्चा करें। लक्ष्य बनाते समय, विशिष्ट संकेतकों को ध्यान में रखा जाना चाहिए, जिस पर पहुंचने पर हम परियोजना को सफल मानेंगे। यदि हम एक स्वचालित प्रणाली के कार्यान्वयन के बारे में बात कर रहे हैं, तो एक अलग सूची प्रमुख उपयोगकर्ताओं से सिस्टम आवश्यकताओं को उजागर कर सकती है। मैं इसे एक अलग तालिका के रूप में करता हूं, जहां सभी आवश्यकताओं को सबसिस्टम द्वारा समूहीकृत किया जाता है, प्रत्येक आवश्यकता के लिए, आवश्यकता के लेखक, शब्दांकन और प्राथमिकता का संकेत दिया जाता है। इस जानकारी का उपयोग सिस्टम परिनियोजन योजना (व्यक्तिगत सबसिस्टम के कार्यान्वयन का अनुक्रम), और साथ ही सिस्टम के आगे विकास के प्रस्तावों के लिए किया जा सकता है (यदि वर्तमान परियोजना में अलग सबसिस्टम को शुरू करने की योजना नहीं है)। यदि व्यावसायिक प्रक्रियाओं का वर्णन करना आवश्यक है, तो निर्णय उन प्रक्रियाओं के बारे में किया जाता है जिनकी जांच अधिक विस्तार से करने की आवश्यकता है।

तो हमें सवाल मिला "आगे क्या है?"। आगे हम व्यापार प्रक्रियाओं का वर्णन करने और संदर्भ की शर्तों को अलग से विकसित करने के कार्यों पर विचार करेंगे। यह संयोग से नहीं है कि मैं इन कार्यों को समानांतर में मानता हूं। उनके बीच वास्तव में बहुत कुछ है, जिसे मैं प्रदर्शित करना चाहता हूं। सबसे पहले, व्यापार प्रक्रियाओं का वर्णन करने में वर्कफ़्लो पर विचार करें।

चरणों	क्या और कैसे करना है
एक व्यवसाय प्रक्रिया का चयन करें	पिछले चरणों में प्राप्त व्यावसायिक प्रक्रियाओं की सामान्य सूची से, हम विस्तृत अध्ययन के लिए एक (प्राथमिकता के आधार पर) सिंगल आउट करते हैं। बाकी के साथ, फिर हम वही करते हैं।
व्यापार प्रक्रिया का एक विस्तृत अध्ययन	- : , , , (, Excel), . , . , , ( , , )
/ - ()	. , , . , , , , . . , , . . , , . यानी , . , : , , , . , .
-	, , () . , , . , . , . (), .
-	, , -, , . , . , .. . , , - . , ( ), .
-	, , ( ), .
( ),	आगे के विकल्प संभव हैं: विचाराधीन प्रक्रियाओं का विश्लेषण और अनुकूलित किया जाएगा, नौकरी विवरण विकसित किए जाएंगे, व्यक्तिगत प्रक्रियाओं को स्वचालित करने की आवश्यकता पर निर्णय किए जाएंगे, आदि। यह एक अलग परियोजना भी हो सकती है: व्यापार प्रक्रियाओं का विवरण।

अब हम इस बात पर विचार करेंगे कि सूचना प्रणाली की आवश्यकताओं के अध्ययन के लिए दृष्टिकोण संदर्भ की शर्तों में उनके आगे के प्रतिबिंब के साथ कैसा दिखेगा

चरणों	क्या और कैसे करना है
एक व्यावसायिक आवश्यकता / स्वचालन क्षेत्र का चयन करें	स्वचालन के एक पूरे क्षेत्र की आवश्यकताओं के रूप में चयन (उदाहरण के लिए, "वेयरहाउस स्टॉक") का उपयोग अभ्यास में किया जाता है, हालांकि, यह आवश्यकताओं के विवरण का सबसे प्रभावी तरीका नहीं है। स्वचालन का क्षेत्र आवश्यकताओं का एक समूह है, और व्यक्तिगत रूप से उन पर विचार करना बेहतर है। उदाहरण के लिए, "गोदाम में सामग्री की प्राप्ति के लिए लेखांकन"
एक व्यावसायिक आवश्यकता का विस्तृत अध्ययन	- , (, ). « ». , - . 2 . , . , « +20%» . , , 2.
	यहाँ यह है! , . « – !» ? , . ? , , () , , . , , , . : , ? , , ? , , . क्या करें? ( « »), , . , ( , ), .. – . , , , , , - ( ). , , . .
	, . , .. . , , , , . , « », .
	? , , . , , . . . , . , « » . , . , ?-, , . -, (- ). , , . , , .
संदर्भ की शर्तों के रूप में दस्तावेज़ीकरण आवश्यकताएं	पिछले चरणों में एकत्र की गई जानकारी सिर्फ वही होगी जो आवश्यकताओं के खंड में "तकनीकी असाइनमेंट" दस्तावेज़ के आधार पर शामिल की जानी चाहिए। इसलिए यह सब सही ढंग से प्रारूपित करना है।
परियोजना के उद्देश्यों के आधार पर आगे की कार्यवाही (या इसके अभाव)	विकास प्रक्रिया लंबे समय तक शुरू हो सकती है, परियोजना के लिए भागीदारों की तलाश, निविदा आदि, यह सब स्थिति पर निर्भर करता है।

हां, संदर्भ की शर्तों का विकास एक श्रम-गहन प्रक्रिया है और इसलिए, महंगा है। लेकिन अगर यह सही तरीके से किया जाता है, तो यह ग्राहक को अधूरी अपेक्षाओं से बचाता है। कॉन्ट्रैक्टर को वही करना पड़ता है जो ग्राहक को सौ बार एक ही चीज को रिड्यूस करने की आवश्यकता न हो। वैसे भी, यह पूरी परियोजना को पारदर्शिता देता है।

परिशिष्ट 1. ईपीसी अंकन में वर्णित व्यावसायिक प्रक्रिया।

परिशिष्ट 2. उपतंत्र "आदेश" का उपयोग करने का भिन्न रूप