கணினி அனுபவங்கள் 4

வங்கிகளில் அந்தக் காலத்தில் பயன்படுத்தப்பட்டு வந்த Legacy மென்பொருளில் இன்றைய மென்பொருளில் உள்ள GUI (Graphic User Interface) இல்லாததும் ஒரு பெருங்குறையாகவே கருதப்பட்டது.

வண்ணப் பெட்டியிலும் (Colour Monitor) கருப்பு வெள்ளை நிறத்தில் இருந்ததுடன் திரை முழுவதும் வலம் (navigate) வர முழுக்க, முழுக்க Keyboardயே சார்ந்திருக்க வேண்டியிருந்தது. இதனால் திரையில் நமக்கு தேவையான fieldஐ தெரிவு செய்து விவரங்களை (Data) பதிவு செய்ய
'நுழை' (Enter) அல்லது 'Tab' பொத்தானையோ பயன்படுத்த வேண்டியிருந்தது. அது எத்தனை சிரமம் என்பது அந்த மென்பொருளை தினமும் ஏழு, எட்டு மணி நேரம் பயன்படுத்தியவர்களுக்கு மட்டுமே தெரியும். உதாரணத்திற்கு நாம் திரையில் கீழ் வரிசையில் அமைந்திருக்கும் (பதினெட்டாம்) fieldல் ஒரு விவரத்தை பதிவு செய்ய பதினேழு முறை Enter பொத்தானை அழுத்த வேண்டியிருக்கும். இதனாலேயே கிளையில் இருந்த பல குமாஸ்தாக்களும் வாடிக்கையாளர்கள் சம்பந்தப்பட்ட விவரங்களை முழுமையாக பதிவு செய்வதை தவிர்த்தனர். இதன் விளைவு வாடிக்கையாளர்களுடைய முழுமையான விவரங்கள்
அதற்கென வடிவமைக்கப்பட்டிருந்த Mastersல் இருந்ததில்லை. ஆகவே வங்கி அலுவல்களில் பெரும்பாலான விழுக்காடு கணினிமயமாக்கப்பட்டும் வாடிக்கையாளர் பற்றிய விவரங்கள் அடங்கிய புத்தகங்களை (Registers) வைத்திருக்க வேண்டியிருந்தது. இது ஒரு பெரிய
குறைபாடாக இருந்தது.

இன்னொரு குறை விவரங்களை பதிவு செய்யும் fieldகளில் validation இல்லாதது. இதன் முக்கியத்துவத்தத மென்பொருளை வடிவமைக்கும் கணினியாளர்கள் எந்த அளவுக்கு உணர்ந்திருக்கிறார்கள் என்பது இன்றும் புரியாத புதிராகவே இருக்கிறது. உதாரணத்திற்கு சேமிப்பு கணக்கு வாடிக்கையாளர் ஒருவர் பணியாளர் (Employee) என அதற்குரிய இடத்தில் (activity code) பதிவு செய்துவிட்டால் அவருடைய பிறந்த நாளை பதிவு
செய்யும் இடத்தில் (Date of Birth field) அவர் ஒரு Minor என பதிவு செய்ய மென்பொருள் அனுமதிக்கலாகாது. ஏனெனில் மைனர் வயதில் இருக்கும் ஒருவரை பணிக்கு அமர்த்துவது சட்டப்படி குற்றம். மேலும் ஒருவர் பணியாளர் என்று databaseல் இருக்கும்போது அவரையே வேறொரு இடத்தில் வர்த்தகம் செய்பவர் (Business) என்றும் மென்பொருள் ஏற்றுக்கொள்ளலாகாது. இப்படி திரையிலுள்ள ஒவ்வொரு
fieldம் validate செய்யப்படவேண்டும். ஆனால் இன்று மிகப்பிரபலமாகவுள்ள பல மென்பொருட்களிலும் இத்தகைய validationகள் இருப்பதில்லை.

இப்போது இத்துறையில் முன்னனியில் நிற்கும் நிறுவனங்கள் தயாரிக்கும் மென்பொருளிலேயே இந்த குறை இன்றும் உள்ளது என்றால் அன்று அடிப்படை பயிற்சி ஏதும் இல்லாமல் தாங்களாகவே மென்பொருளை தயாரிப்பில் ஈடுபட்டவர்களுடைய மென்பொருளில் இத்தகைய குறைபாடுகள் இருந்ததில் வியப்பில்லையே.

இதன் விளைவாக தகவல் களத்தில் (Database) இருந்து எந்த ஒரு பயனுள்ள அறிக்கைகளையும் தயாரிக்க முடியாத நிலை. ஆக, அன்று புழக்கத்திலிருந்த மென்பொருள் ஒரு கிளையின் அன்றாட அலுவல்களான பணம் செலுத்துதல், பட்டுவாடா செய்தல் போன்ற அடிப்படை
அலுவல்களுக்கு மட்டுமே பயன்படக்கூடிய ஒரு மென்பொருளாக இருந்து வந்தது.

ஆனால் வருடங்கள் செல்ல, செல்ல எங்களுடைய வங்கியில் புழக்கத்தில் இருந்த மென்பொருளின் தரம் உயர்ந்தது என்னவோ உண்மை. அதாவது
இலாக்காவில் புதிய, மென்பொருள் தயாரிப்பில் அடிப்படை பயிற்சி பெற்ற கணினியாளர்கள் சேர்க்கப்பட்டப் பிறகு. ஆனால் இது வேறொரு புதிய தலைவலியை கொண்டுவந்தது.

இந்த காலக்கட்டத்தில் நான் பதவி உயர்வு பெற்று எங்கள் வங்கியின் பயிற்சி கல்லூரியின் (Training College) முதல்வராக அமர்த்தப்பட்டேன். கல்லூரியில் நடந்த பயிற்சி வகுப்புகளில் கணிசமான விழுக்காடு கணினி பயிற்சி வகுப்புகளாக இருந்தது. அதுவரை ஒரு கிளை மேலாளர் கோணத்தில் வங்கியின் மென்பொருளை அணுகி வந்த நான் கணினி பயிற்சி எடுக்க வந்த கணினி இலாக்கா அதிகாரிகளுடன் நெருங்கிப்பழக ஆரம்பித்தேன்.

எனக்கு வகுப்புகள் இல்லாத சமயங்களில் என்னுடைய கணினியில் மென்பொருளின் source codeஐ பெற்று படிக்க ஆரம்பித்தேன். ஆனால் ஒரு தயாரிப்பாளர் கோணத்திலிருந்து அணுகாமல் ஒரு பயனாளரின் (user) கோணத்திலிருந்தே அணுக ஆரம்பித்தேன். ஆகவே நான் கிளையில் இருந்தபோது குறைகளாக நான் கணித்திருந்தவற்றை சரிசெய்யும் நோக்கத்தில் எனக்கு மனதில்பட்டவற்றை குறித்துக்கொள்ள ஆரம்பித்தேன்.

நான் குறித்து வைத்திருந்தவற்றை இலாக்கா அதிகாரிகளிடம் காண்பித்தபோது சீனியர் அதிகாரிகள் பலரும் ஏதாவது சாக்குபோக்கு சொல்லி தங்களுடைய வாதத்தை முன்வைப்பதிலேயே (அதாவது சாக்குபோக்கு) குறியாயிருந்தனர். ஆனால் சமீபத்தில் இலாக்காவில் சேர்க்கப்பட்ட அதிகாரிகள் நான் குறித்துவைத்திருந்தவற்றுள் பெரும்பாலானவற்றை ஏற்றுக்கொண்டதுடன், 'நீங்க சொல்றது சரிதான் சார். நாங்களும் இதுமாதிரி ஒரு ரிப்போர்ட்
ப்ரிப்பேர் பண்ணி வச்சிருக்கோம். ஆனா இத டிசைன் பண்ண யாருமே எங்க அப்சர்வேஷன ஒத்துக்க மாட்டேங்கறாங்க.' என்றனர் உண்மையான ஆதங்கத்துடன்.

மென்பொருள் வடிவமைப்பதிலும் அதை தயாரிப்பதிலும் (Designers and developers) ஈடுபட்டுள்ள பல கணினியாளர்கள் இன்றும் இத்தகைய போக்கைத்தான் கடைபிடிக்கின்றனர் என்பதுதான் துரதிர்ஷ்டம்.

பயனாளர்கள் மென்பொருளின் தரத்தை மேம்படுத்தவே தாங்கள் காணும் குறைகளை எடுத்துரைக்கின்றனர் என்பதை பல கணினியாளர்கள் உணர்வதில்லை.

சரி. இனி முந்தைய இடுகையில் நம் நண்பர் சிவா அவர்கள் எழுப்பியுள்ள வாதங்களை பார்ப்போம்.

முதலாவது வங்கி அலுவல்கள் எல்லா வங்கிகளுக்குமே பொருந்துமா?

அடிப்படையாக பார்த்தால் சிவா அவர்கள் சொல்வதுபோல, Accounts Register, Scroll Books, Subsidiary Books and the General Ledger எல்லாமே எல்லா வங்கிகளிலும் ஒன்றுதான். அதாவது பரிவர்த்தனைகளை Accounting செய்யும் முறை.

ஆனால் அவற்றை அணுகும் முறை அதாவது எப்படி ஒவ்வொரு சேமிப்பு மற்றும் கடன் திட்டங்களும் (Deposit & Loan Products) எப்படி வடிவமைக்கப்படுகின்றன என்பதும் அதன் சட்ட திட்டங்கள் என்பதும் வங்கிக்கு வங்கி மாறுபடும்.

எங்களுடையதைப் போன்ற வங்கிகளில் எல்லா திட்டங்களும் எல்லாருக்கும் பொருந்தும். அதாவது கணக்குகள் திட்டங்களின் கீழ் மட்டுமே துவக்கப்படுகின்றன. அதாவது தனிநபர் திட்டங்கள், நிறுவன திட்டங்கள் என பிரிக்கப்படுவதில்லை. ஆனால் பல புதிய வங்கிகளில் இவை Private or Personal Banking, Corporate or Wholesale Banking, Retail Banking, Investment Banking, என பலவகைகளில் பிரிக்கப்பட்டு விற்கப்படுகின்றன.
ஆகவேதான் ஒரு வங்கிக்கு வடிவமைக்கப்படும் மென்பொருள் எல்லா வங்கிகளுக்கும் பொருந்துவதில்லை.

இரண்டாவது ரிசர்வ் வங்கி ஏன் எல்லா வங்கிகளுக்கும் பொருந்தும் வகையில் ஒரு மென்பொருளை வடிவமைக்கக் கூடாது.

இதை அதிகம் வெளிச்சம் போட்டு சொன்னால் சரிவராது. ஏனெனில் வங்கியில் பணிபுரியும் ஒருவர் ரிசர்வ் வங்கியின் செயல்பாட்டைக் குறைகூறலாகாது என்பது அடிப்படை நியதி!!

ஆனால் ஒன்று மட்டும் கூறலாம். ரிசர்வ் வங்கிக்கு வர்த்தகத்தை (Commercial Banking) பற்றி முழுமையாக தெரிந்திருக்க வாய்ப்பில்லை. ஆகவே அவர்களால் நிச்சயம் ஒரு முழுமையான, நாட்டின் அனைத்து வங்கிகளுக்கும் ஏதுவான ஒரு மென்பொருளை வடிவமைக்கவோ, அல்லது வேறொரு மென்பொருள் நிறுவனத்துடன் கூட்டாக தயாரிக்கவோ நிச்சயம் முடியாது.

மூன்றாவது மென்பொருள் வாங்குவதற்ககு லஞ்சம் வாங்கினால் மென்பொருள் எப்படி சரியா வேலை செய்யும் என்கிற குற்றச்சாட்டு.

குடுக்கறவன் இருக்கறவரைக்கும் வாங்கறவனும் இருக்கத்தான செய்வான்? தங்களை 'புனிதர்கள்' என பறைசாற்றிக்கொள்ளும் பல முன்னனி நிறுவனங்களும் இத்தகைய தரக்குறைவான பேரங்களில் இறங்குவதுதான் துரதிர்ஷ்டம். சமீபத்தில் முன்னனி நிறுவனம் ஒன்று சம்பந்தப்பட்ட வங்கியின் இயக்குனர்கள் அனைவருக்கும் லேப்டாப் பரிசாக அளித்ததாம்!

அடுத்து 'ஒரு பிரிட்ஜ்,டிவி வாங்குவதற்க்கு எவ்வளவு மெனெக்கெடுகிறோம். ஒரு 4 கடையாவது ஏறி விலை விசாரித்து வாங்குகிறோமா இல்லையா? அதையே ஏன் கணிணி மயமாக்கலில் நாம் பின்பற்றவில்லை?'என்கிற கேள்வி.

எல்லா வங்கிகளுமே இன்று நாட்டில் முன்னனியில் உள்ள எல்லா நிறுவனங்களின் மென்பொருளை ஒருமுறையாவது டெமோ (Demo) பார்த்துவிட்டுத்தான் தங்களுக்கு தேவையான மென்பொருளை தெரிவு செய்ய வேண்டும் என்பது நியதி. அப்படித்தான் எல்லா வங்கிகளுமே செய்கின்றன. Multi Vendor Policy என்பது எல்லா வங்கிகளுக்கும் பொருந்தும். ஆனால் டெமோவுக்கு வருகின்ற மார்க்கெட்டிங் ஆசாமிகள் 'மொட்டைத்தலையிலகூட முடிய வளர்க்கலாம்.' என்பதுபோல் தங்களுடைய மென்பொருளைப் பற்றி அளப்பார்கள். இதற்கென்று தனியாக அதிகாரிகளைக் கொண்ட ஒரு கமிட்டி அமைக்க வேண்டும் என்பதும் நியதி. ஆனால் இதில் உயர் அதிகாரிகளே அங்கத்தினர்களாக இருப்பார்கள். இவர்களுக்கு கணினியைப் பற்றி அவ்வளவாக தெரிந்திருக்க வாய்ப்பில்லை. ஏன், அவர்களுடைய கிளைகளில் நடக்கும் அலுவல்களைப் பற்றியே அவர்களுக்கு முழுவதுமாக தெரிந்திருக்க வாய்பில்லை.
'
அடுத்து டிசிஎஸ்-ஐ மென்பொருள் தயாரிக்க அமர்த்தியது, 'ஒரு வருடதிற்குள் வேலையை முடித்துவிட வேண்டும் என்ற நிபந்தனையுடன். நிறுவனப் பணியாளர்களின் ஈடுபாடின்மையால் அங்கு வந்து தயாரித்த மென்பொருளை 2 வருடமாகியும் அமுலாக்கம் செய்ய இயலவில்லை.'

இதற்கு நான் மேலே குறிப்பிட்டிருந்த உயர் அதிகாரிகளின் போக்கே காரணம். மென்பொருளை தெரிவு செய்யும் சமயத்தில் எங்களை கலந்தாலோசிக்கவில்லை என்கிற ஆதங்கம்தான் மென்பொருளை அன்றாடம் பயன்படுத்தும் பணியாளர்களிடம் இத்தகைய மனப்பான்மையை ஏற்படுத்துகிறது.

தொடரும்