एक वित्तीय संगठन में बीए के सही संचालन के बारे में

कुछ समय पहले, मैंने मौजूदा और कुछ हद तक थक चुके मास्टर ऑफ़ इंजीनियरिंग इंजीनियरिंग के लिए एक अतिरिक्त शिक्षा प्राप्त करने का फैसला किया। चुने हुए स्कूल में प्रवेश के लिए मुझे कई निबंध तैयार करने पड़े। उन पर चिंतन करते हुए, मैंने आवश्यक 400 शब्दों को पार कर लिया, और इसलिए कि यह गायब नहीं हुआ, मैंने उन्हें ठीक करने और यहां पोस्ट करने का फैसला किया।

निबंध के लिए विषय मेरे काम से संबंधित हैं, इसलिए मैं नीचे व्यापार विश्लेषण के कुछ पहलुओं पर चर्चा करूंगा । मुझे उम्मीद है कि किसी को दिलचस्पी होगी।

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

इस लेख में, मैं आपको बताना चाहूंगा कि "सही विश्लेषक" को क्या करना चाहिए । मेरी तरह, हाँ।

शुरू करने के लिए, मैं शायद सहमत हूं कि विश्लेषक की हमेशा आवश्यकता नहीं होती है । यदि आप एक ऐसे क्षेत्र में एक छोटी परियोजना कर रहे हैं जहाँ आप अच्छी तरह से वाकिफ हैं, या यदि आपकी छोटी सी टीम और आपकी उंगलियों पर एक निश्चित "विशेषज्ञ" है, तो आप शायद हमारी मदद के बिना कर सकते हैं।

अन्य मामलों में - उदाहरण के लिए, यदि आप एक निश्चित बड़े सिस्टम को रीमॉडेल कर रहे हैं, या उस क्षेत्र में कुछ नया निर्माण कर रहे हैं जहाँ आप काफी विशेषज्ञ नहीं हैं, तो विश्लेषक की मदद आवश्यक है ।

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

कुछ साल पहले मैंने एक चुस्त प्रोजेक्ट में एक विश्लेषक की भूमिका के बारे में लिखा था। अब मैं थोड़ा कम चुस्त, लेकिन अधिक वित्तीय परियोजना पर काम करता हूं - तेल और इसके डेरिवेटिव बेचने वाली सबसे बड़ी कंपनियों में से एक, साथ ही साथ धातु और अन्य उपकरण।

कंपनी 20 से अधिक वर्षों से बाजार में है, और इसकी स्थापना के बाद से अविश्वसनीय रूप से बढ़ी है। जैसा कि अक्सर ऐसी कंपनियों में होता है, विभिन्न कार्यों के लिए सिस्टम का एक गुच्छा यहां तलाक हो गया है - जैसे कि रिकॉर्डिंग ट्रेडों के लिए एक प्रणाली, जोखिम प्रणाली, लेखा प्रणाली और रिपोर्टिंग सिस्टम। कंपनी के पास प्रत्येक फ़ंक्शन के लिए कम से कम 2 सिस्टम हैं, और कुछ मामलों में 8-12 सिस्टम हैं। अक्सर सिस्टम को साझा फ़ोल्डर में कुछ एक्सेल, कुछ पूर्व-मैक्रोज़ और स्क्रिप्ट द्वारा एक साथ सरेस से जोड़ा जाता है, कुछ संग्रहीत प्रक्रियाओं को कुछ स्व-निर्मित प्रोग्राम द्वारा बुलाया जाता है।

मुझे व्युत्पन्न वित्तीय साधनों - वायदा, स्वैप, विकल्प और सूची के नीचे व्यापार करने वालों के लिए स्थिति और जोखिम के प्रबंधन के लिए प्रणाली का रीमेक करने के लिए कहा गया था।

नीचे मैंने विभिन्न प्रकार की गतिविधियों का वर्णन किया है जो मैं इस परियोजना के लिए करता हूं।

* दायरा निर्धारित करें

जैसा कि मैंने ऊपर वर्णित किया है, कंपनी के पास प्रत्येक फ़ंक्शन के लिए एक से अधिक सिस्टम हैं। इनमें से कुछ प्रणालियों को आईटी द्वारा समर्थित किया जाता है, इसलिए उन्हें पहचानना, अलग करना और फिर से तैयार करना अपेक्षाकृत आसान है। मेरे लिए मुख्य समस्या एक्सल, और स्व-निर्मित घटक और मैक्रो के सभी प्रकार हैं जो व्यापारियों और जोखिमों का उपयोग करते हैं।

उपयोगकर्ता के साथ लगभग हर संपर्क के परिणामस्वरूप, यह पता चलता है कि आधिकारिक सिस्टम कुछ फ़ंक्शन के लिए पर्याप्त नहीं हैं - या तो रिपोर्ट गलत प्रारूप में है, फिर इकाइयां गलत हैं, फिर गलत मॉडल का उपयोग किया जाता है या व्यापार का समर्थन नहीं किया जाता है। प्रत्येक ऐसे दुर्भाग्य का समाधान दिए गए उपयोगकर्ता के तकनीकी ज्ञान या किसी ऐसे व्यक्ति की उपस्थिति के आधार पर किया जाता है, जिसके लिए व्यापारी उसकी अनुमति को लटका सकता है। सबसे अधिक, समस्या का समाधान कुछ एक्सेल है जो शिथिल रूप से एक साथ चिपके हुए हैं, कभी-कभी कुछ अन्य स्थानीय पुस्तकालय या डेटाबेस ...

जोखिम प्रणाली को ध्यान में रखते हुए, प्रश्नों में से एक है " क्या नई प्रणाली को इस एक्सेल को बदलना चाहिए? "। सहमत - सवाल आसान नहीं है। एक ओर, यदि यह मौजूदा प्रणाली का दोष है, तो नए को इसे ध्यान में रखना चाहिए और इसे सही करना चाहिए। दूसरी ओर, व्यापारियों को एक्सेल से प्यार है और इसे कभी भी बंद न करें।

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

यहां मेरा काम सिस्टम की सीमा को खींचना है और यह सुनिश्चित करना है कि प्रोग्रामर से रिस्क ऑफिसर तक - इस प्रक्रिया में सभी प्रतिभागी इस लाइन से सहमत हों।

* व्यापारियों को समझें

कोई आश्चर्य नहीं - किसी को उपयोगकर्ताओं के व्यवसाय को समझना चाहिए । ईमानदारी से, हम और प्रोग्रामर बहुत स्मार्ट नहीं हैं, लेकिन व्यापारी प्रक्रियाओं और एक्सेल से निपटने के लिए पर्याप्त व्यस्त हैं।

मुझे याद है कि शुरुआत में एक व्यापारी ने मुझसे कहा था, "मेरे इस पैर के पिछले हिस्से में लंबा गामा है।" हाँ, और पैरों के बीच समाप्ति की तारीख।

यहां मेरा काम यह समझना है कि व्यापारी और अन्य व्यवसाय उपयोगकर्ता मुझे क्या बताते हैं, और उनकी आवश्यकताओं को एक ऐसी भाषा में अनुवाद करते हैं जिसे इंजीनियर समझते हैं। और वापस।

* प्राथमिकता दें

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

लेकिन व्यावसायिक दृष्टिकोण से भी प्राथमिकताएँ हैं । और अजीब तरह से पर्याप्त, वे अक्सर रहस्यमय और समझ से बाहर हैं।

जिस कंपनी में मैं काम करता हूं वह दुनिया भर में बिखरी हुई है। प्रत्येक क्षेत्र में कुछ विशेषताएं होती हैं - ट्रेडिंग उत्पाद, प्रक्रियाएं, रिपोर्टिंग और विनियमन का स्तर। तदनुसार, आपूर्ति को चरणों में तोड़ना बहुत तार्किक और बेहतर है।

मुझे लगातार इस सवाल का सामना करना पड़ रहा है - पहला कौन है ? क्या हमें पहले कोयले के विकल्प विकसित करने चाहिए, या विदेशी मुद्रा समर्थन को जोड़ना चाहिए? या शायद आपको निर्देशकों को रिपोर्ट भेजना शुरू करना चाहिए?

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

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

* प्रक्रियाओं को व्यवस्थित करें ताकि "सब कुछ काम करे"

यह एक दिलचस्प बिंदु है। सिस्टम में परिवर्तन अक्सर प्रक्रिया परिवर्तनों को प्रभावित करते हैं । कभी-कभी प्रक्रिया परिवर्तन काफी सरल होता है, सिस्टम को सीखते समय प्रक्रिया को बदला जा सकता है। हालांकि, प्रक्रिया परिवर्तन अक्सर कई विभागों को प्रभावित करते हैं, विभिन्न भौगोलिक स्थानों और समय क्षेत्रों में।

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

मुझे लगता है, और यहां आप इस बात से सहमत होंगे कि न तो प्रोग्रामर और न ही प्रोजेक्ट मैनेजर ऐसे टाइगोमोटिन से निपटना चाहेंगे।

* इंजीनियरों के लिए कलाकृतियां बनाएं

यहां मैं गहराई तक नहीं जाऊंगा - हर कोई विनिर्देशों, हमारे मामलों, कहानियों और अन्य कलाकृतियों से परिचित है।

* प्रदर्शन, प्रशिक्षण और यूएटी

पिछले नहीं बल्कि कम से कम, उत्पादन में प्रणाली डाल।

शुरुआत के लिए, आपको इसे उपयोगकर्ताओं को प्रदर्शित करना होगा। हमारी कंपनी में, यह एक श्रमसाध्य व्यवसाय है, और इसमें बहुत समय लगता है। तथ्य यह है कि मेरे व्यवसाय उपयोगकर्ता दुनिया के विभिन्न हिस्सों में रहने वाले लोगों में व्यस्त हैं, इसलिए प्रदर्शन आम तौर पर एक-पर-एक होते हैं, उस विशेष उपयोगकर्ता के लिए अनुकूलित होते हैं। मैं इस पर बिताए अपने मैन-महीनों की गणना करने की कोशिश भी नहीं कर रहा हूं ...

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

सबसे कठिन हिस्सा शायद यूएटी (उपयोगकर्ता स्वीकृति परीक्षण) है। यह तब होता है जब आपको एक व्यस्त व्यापारी को किराए की प्रणाली (स्प्रेड या अन्य) से एक नए और शानदार एक में स्थानांतरित करने की आवश्यकता होती है। और वह छुरा घोंपती है, सुसाइड नहीं करती है और जुटती नहीं है, और विश्लेषक यह पता लगाने की कोशिश कर रहा है कि सब कुछ पहले क्यों काम किया, और अब, जब वह क्लिक करता है - नहीं! यहाँ डेल्टा - ५.२ और वहाँ - ५. 5.2 - और निरंतर मैट्युकि के तहत तनाव के तहत आप यह पता लगाने की कोशिश करते हैं - कितना आवश्यक है?

और फिर, अंत में, उसे परीक्षण परिदृश्यों की एक सूची के साथ कागज का एक टुकड़ा तैयार करने और पर्ची करने की आवश्यकता है जहां व्यापारी को प्रत्येक आइटम पर "देखा, काम करता है" पर हस्ताक्षर करना होगा । मज़ा, सामान्य रूप में।

एनालिटिक्स पर कौन है?