ग्राहक की दुनिया बदल गई - हम इसे कैसे संभालते हैं?

Question

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

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

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

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

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

कोई विचार?

Comments

नीचे महान प्रतिक्रियाओं के अलावा, आपको विरोधियों से आपको डेटा का एक उदाहरण प्रदान करने के लिए कहना चाहिए जो उन्हें लगता है कि समर्थित नहीं है। फिर उन्हें (और निर्णय लेने वालों को) दिखाने के लिए डेटा परिवर्तित करें कि वे गलत हैं।

— जेक बर्जर

Answer 1

आपकी टीम को उनके लिए डेटा रूपांतरण करने की आवश्यकता है। आपको वास्तव में पहली बार में उनके लिए यह करना चाहिए था।

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

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

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

वे यदि चाहें तो अपनी टीम का भुगतान कर सकते हैं, और यदि वे चाहें, तो वे आपको शुरू करने के लिए भुगतान कर सकते हैं, लेकिन किसी तरह के समझौते के बिना अनावश्यक चक्रों को बर्बाद न करें। खासकर यदि आप समय-सीमित या निश्चित-लागत अनुबंध पर हैं, तो यह स्थिति मृत्यु है।

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

यदि आपको मैन्युअल रूप से डेटा रूपांतरण करने के लिए न्यूनतम-मजदूरी डेटा प्रविष्टि दासों की एक जोड़ी को किराए पर लेना है - तो करें। परिणाम को अपने हाथों में रखने के लिए कुछ भी ।

Comments

"आपको संदेह हो सकता है कि उनमें से कुछ सक्रिय रूप से अपनी नौकरी की सुरक्षा पर कब्जा करने के लिए आपके खिलाफ काम कर रहे हैं" +1, मैंने अक्सर TOO से पहले यह देखा है।

— maple_shaft

+1 "आपको वास्तव में पहली बार में उनके लिए यह करना चाहिए था" सबसे अधिक आप विरासत टीम से पूछ सकते हैं कि आप अपने डेटा को एक ऐसे रूप में निर्यात कर सकते हैं जिस पर आप कब्जा कर सकते हैं, डेटा का पुनर्गठन आपकी जिम्मेदारी है। दुर्भाग्य से नीचे की रेखा यह है कि आप उस डेटा को अपने सिस्टम में प्राप्त करें। बेस्ट ऑफ लक मेट।

— बाइनरी वॉरियर

@Aaronaught - हमने कुछ बातों पर आंतरिक रूप से बहुत चर्चा की है ("इसे स्वयं करना चाहिए था") - निश्चित रूप से, हमेशा से 20/20 की याद आती है। उत्तर के लिए धन्यवाद (और साथ ही हर किसी ने उत्तर दिया)। यह निश्चित रूप से एक सबक सीखा है।

— कैच

@ कैचप्स: मैंने जो आरोप लगाया है, उसके लिए माफी माँगता हूँ; बेशक, यह दृष्टि से बोलना आसान है और यह एक ऐसी गलती है जिसे कोई भी नई टीम कर सकती है, खासकर जब से ग्राहकों में काम की रोशनी पैदा करने की प्रवृत्ति होती है और यह मान लेते हैं कि यह बहुत आसान है। संप्रेषित करने के लिए मतलब मैं उस जगह में इस तरह के एक दल / प्रक्रिया के बिना आगे बढ़ने था है आम तौर पर एक गलती है, और एक संभावना है कि जरूरतों को सही करने की।

— एरोन

@ कैचअप: यह एकमात्र वास्तविक उत्तर है। बस उनकी टीम से संपर्क करें, डेटा का भौतिक डंप प्राप्त करें और रूपांतरण स्वयं करें। आप इसे करने के लिए एक आदमी या दो ऑनसाइट भी लगा सकते हैं।

— NotMe

Answer 2

वे बिलों का भुगतान करने वाले होते हैं इसलिए अंत में आपको उन्हें वही देना होगा जो वे माँग रहे हैं भले ही यह सबसे अच्छा समाधान और एक कदम पीछे नहीं होगा।

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

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

नैतिक है, ग्राहकों की चिंताओं को पूरी तरह से खारिज न करें। उनकी बातों को गंभीरता से लें और स्वयं से पूछें कि क्या आप जो समाधान प्रदान कर रहे हैं, वह सभी हितधारकों की जरूरतों को पूरा करता है।

Answer 3

उन्हें लगता है कि नई प्रणाली डेटा प्रदान नहीं करती है जो पुरानी प्रणाली ने किया था (जब यह वास्तव में करता है)।

आप इस बहुत गंभीरता से लेना चाहिए ..

फिर:

1) आश्वासन प्रबंधन तुम विरासत लोगों के साथ काम कर रहे हैं वहाँ सभी चिंताओं को हल करने के लिए।

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

यदि आप वहां की चिंताओं से सहमत हैं तो:

3) फिर एक समाधान का प्रस्ताव, समाधान के विरासत टीमों इनपुट \ सत्यापन प्राप्त करें।

4) सुधारात्मक उपायों के साथ आगे बढ़ें।

यदि आप पूरी तरह से विरासत के लोगों से असहमत हैं, और मानते हैं कि वे चिंता का विषय हैं तो मान्य नहीं हैं:

3) एक्सप्रेस ने उसी भाषा का उपयोग करते हुए प्रबंधन के लिए चिंता व्यक्त की है जो लिगेसी दोस्तों ने कहा था कि यह सही है। और प्रबंधन ने तय किया है कि आपको इससे संबंधित नहीं होना चाहिए या नहीं।

"विरासत लोग डरते हैं कि XXX, मुझे YYY की वजह से इसकी समस्या पर यकीन नहीं है। क्या वे इस चिंता में सही हैं?"

Answer 4

मैं सुझाव देता हूं कि एक बड़ी घबराहट वाली स्मूथिंग ईमेल, सभी को न केवल उनके प्रबंधन से जुड़े। इसे कम और बिंदु पर रखें।
2 अंक:

1) हम एक बैठक / फोन कॉल पर आपकी चिंताओं को दूर कर सकते हैं (एक बार प्रस्ताव करें)

2) हमें सिस्टम पर पूरा भरोसा है क्योंकि यह अतिरिक्त बदलावों की परेशानी और खर्च के बिना है

ऐसा लगता है कि आपके पास उनकी चिंताओं की एक सूची है और आप बैठक में उन्हें बिंदु से नीचे जा सकते हैं। आपको बस घबराहट को रोकने की जरूरत है, उन्हें थोड़ा ठंडा होने दें, और फिर उन्हें सच्चाई से मारो। यहां तक ​​कि नए डेटा के लिए पुराने डेटा के मानचित्रण के साथ आने और मदद करने की पेशकश करें। यदि वे अभी भी बदलाव की मांग करते हैं ... तो यह उनका पैसा है।

Answer 5

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

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

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

Answer 6

नए सिस्टम के लिए पुराने डेटा के माइग्रेशन का समर्थन करने के लिए अपने ग्राहक के आईटी कर्मचारियों से परामर्श करें। नए डेटा प्रारूप को समझने वाली आपकी फर्म से किसी को शारीरिक रूप से बस वहां जाना चाहिए और आईटी लोगों को प्रवास करने में मदद करनी चाहिए।

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