इंजीनियरिंग के क्षेत्रों में, आप कितनी बार खुद को "विक्रेता" होने के लिए कहते हैं, और आपकी प्रतिक्रिया क्या है? [बन्द है]


12

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

मैं इस बारे में थोड़ा अजीब महसूस करता हूं क्योंकि एक तरफ मैं समझ सकता हूं कि, एक इंजीनियर के रूप में, मैंने इस कौशल का सम्मान नहीं किया है। हालाँकि, दूसरी ओर मुझे लगभग ऐसा लगता है कि यह एक ऐसा कौशल है जिसकी मुझे उम्मीद है; निर्णय लेने वालों ने पहले ही कहा है, "लागू हो जाओ", लेकिन जब मैं लागू करने जाता हूं, तो जिन लोगों के साथ मैं साझीदारी करने वाला हूं, वे प्रगति में बाधाएं डालते हैं।

मैं सोच रहा हूं कि दूसरे इससे कैसे निपटते हैं।

जवाबों:


11

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

1. प्रबंधन का औचित्य

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

क्या 'अच्छा' वास्तव में कंपनी की व्यावसायिक रणनीति पर निर्भर करता है क्योंकि पिछले दो उदाहरणों पर प्रकाश डाला गया है जो एक तकनीकी दृष्टिकोण से विपरीत हैं, लेकिन दोनों को अलग-अलग व्यावसायिक रणनीतियों के तहत फायदेमंद माना जा सकता है।

यदि आप अपनी कंपनी की व्यावसायिक रणनीति को पसंद या असहमत नहीं करते हैं, तो अपना खुद का व्यवसाय छोड़ें और अपना व्यवसाय शुरू करें और अपने ग्राहकों के साथ बेहतर व्यवहार करें। या कम से कम आप यह समझना शुरू कर सकते हैं कि तकनीकी रूप से शानदार होने के बावजूद आपके विचारों को क्यों नहीं अपनाया जाता है।

2. इंजीनियरों को उचित ठहराना

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

उदाहरण

मैं एक वास्तविक दुनिया उदाहरण का उपयोग करूँगा जिसे मुझे हाल ही में समझाने के लिए निपटना पड़ा। यह एक सॉफ्टवेयर कंपनी से है, लेकिन किसी भी इंजीनियरिंग स्थिति के लिए लागू है।

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

इंजीनियर इस दृष्टिकोण से सहमत होने के लिए संघर्ष कर रहे थे जब तक कि मैंने उन्हें समझाया कि 80% राजस्व एक बाजार से आ रहा था, और वहां प्रतिस्पर्धा भी अधिक भयंकर थी, इसलिए व्यवसाय की रणनीति केवल एक टीम को इस बाजार पर ध्यान केंद्रित करने के लिए थी, बिना दूसरे बाजार का समर्थन करने के लिए कोई विचार ताकि वे जल्दी से आगे बढ़ सकें और प्रतियोगिता से आगे रह सकें। द्वितीयक बाजार अभी भी शोषण करने और बढ़ने के लायक था, इसलिए दूसरी टीम उस पर ध्यान केंद्रित करेगी। यह हमें दी गई रणनीति है, यह वह समस्या है जिसे हमें हल करने की आवश्यकता है, न कि एकल-उत्पाद बनाने की अन्य समस्या।

निष्कर्ष

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


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

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

6

इस संदर्भ में "सेल्समैनशिप" का अर्थ है "प्रतिरोध पर काबू पाने में सक्षम होना।"

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

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

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


2

मुझे लगता है कि अक्सर ग्राहक परिवर्तन (आंतरिक या बाहरी ग्राहकों) के लिए प्रतिरोधी होते हैं, और यहां तक ​​कि जब वे सहमत होते हैं कि तकनीकी रूप से कुछ अच्छा लगता है / एक अच्छा समाधान प्रतीत होता है, तो वे अपनी मौजूदा प्रक्रिया या उत्पाद को जाने नहीं देना चाहते हैं। (क्यों? क्योंकि यही हमने हमेशा किया है)

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

जहाँ तक सहायक सलाह है, मुझे लगता है कि मैं आपके लिए एक बुनियादी शुरुआती बिंदु के रूप में मार्केटिंग, या प्रेरक बोलने पर एक अच्छी पुस्तक ढूंढना चाहता हूं, क्योंकि यह नहीं लगता है कि यह समस्या आपके तकनीकी समाधान में निहित है।


2

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

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

मैं निम्नलिखित जोड़ना चाहता हूं जो मुझे लगता है कि अभी तक उल्लेख नहीं किया गया है:

प्रभावित विषयों के संबंध में समय

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

संभव समाधान शामिल हो सकते हैं:

  • अपने सहकर्मियों को पचाने और अपने विचार के प्रभाव को समझने के लिए प्रोजेक्ट में पहले अपने विचार के लिए धक्का दें
  • अपने विचार को अपनी टीम की बोली का हिस्सा बनाएं (आपका विचार टीम के लिए अगला प्रोजेक्ट जीत सकता है)
  • क्या परियोजना को प्रभावित करने का अवसर है?
  • विचार करें कि यह इस परियोजना में नहीं हो सकता है। तत्काल परियोजना के संदर्भ के बाहर सहकर्मियों को विचार समझाने के लिए अपना समय लें। सुनो, सवाल पूछें, प्रतिरोध के कारणों को समझने की कोशिश करें (@TomAu और @jhabbot द्वारा पहले से ही चर्चा किए गए अच्छे कारण नहीं हो सकते हैं)।

भागीदार विषयों के पुनर्परिभाषित प्रभाव

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

अपने संदर्भ में डिजाइन प्रक्रिया को समझना

परियोजना के लिए कौन भुगतान करता है? विशिष्ट विचार से किसे लाभ होता है? डिजाइन, निष्पादन, संचालन, चरण आउट के दौरान किसे प्रभावित किया जाता है? क्या परियोजना कार्यक्रम या बजट (ग्राहकों और / या किसी भी विषय से जुड़े) के लिए निहितार्थ हैं यदि आपका विचार लिया जाता है? क्या विशेष रीसर्च की आवश्यकता है? क्या यह किसी को अप्रचलित बनाता है?

अपने एक विचार पर और इस एक सहयोगी पर अटक मत जाओ जो आपको अपनी बिक्री में सुधार करने के लिए कहता रहता है

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

यदि आप इस एक प्रमुख व्यक्ति को मना नहीं सकते हैं, तो किसी अन्य को ढूंढें या किसी अन्य की प्रतीक्षा करें। इस दौरान पूछते रहें कि "सेल्समैनशिप" से उनका क्या मतलब है, अगर उनके पास इसके लिए एक अच्छा उदाहरण है, तो वे आपसे क्या उम्मीद करेंगे, अगर वे आपको एक संरक्षक मिल सकते हैं या यदि वे आपको खुद को सलाह दे सकते हैं। इन सवालों के प्रति उनकी प्रतिक्रिया भी आपको उनकी प्रेरणा और सोच को समझने में मदद कर सकती है।


1

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

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


1

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

इंजीनियरिंग डिजाइन टीम के सदस्य से अपील करने वाले व्यापक इंजीनियरिंग विश्लेषण डेटा के साथ एक प्रस्तुति हमेशा इंजीनियरिंग टीम के सदस्यों के निर्माण या संचालन के लिए अपील नहीं करती है। ऐसे मामलों में इंजीनियरिंग विश्लेषण डेटा को टोन करना और इंजीनियरिंग विभागों के निर्माण या संचालन के लाभों को उजागर करना एक अच्छा विचार है।

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

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

अंत में "हां में हां मिलना: समझौता किए बिना समझौता करना" और "दोस्तों को कैसे जीतें लोग प्रभावित होते हैं " बताए गए प्रश्नों की चिंताओं को दूर करने में मदद करने के लिए बहुत अच्छी किताबें हैं

संदर्भ:

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.