கணினி அனுபவங்கள் 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 வருடமாகியும் அமுலாக்கம் செய்ய இயலவில்லை.'

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

தொடரும்

வங்கிகளில் கணினி - 3

Technorati Tags: கணினி அனுபவங்கள்

 

வங்கி பரிவர்த்தனைகளை (transactions) வரவு(Receipts or Credits), பற்று (Payment or Debits) என இருவகைகளாக பிரிக்கலாம்.

வாடிக்கையாளர் செலுத்தும் பணம் அவர்களுடைய கணக்கில் வரவு வைப்பது மற்றும் அவர்களுக்கு வழங்கும் பணத்தை அவர்களுடைய கணக்கில் பற்று வைப்பது. இதை ரொக்க பரிவர்த்தனைகள் (Cash transactions) என்பர். வரவு வைக்கப்படும் கணக்குகள் வைப்பு நிதி (fixed deposits) சேமிப்பு கணக்கு (Savings accounts), வர்த்தக கணக்கு (Current Accounts), தனிநபர் மற்றும் நிறுவனங்களின் கணக்கு என பலவகைக் கணக்குகள் உள்ளன. இவற்றை அந்த காலத்தில் திட்டங்கள் என்றோம். இப்போது அவற்றையே நாகரீகமாக Products என்கிறோம். முன்பு Mobilisation of resources என்றதை இப்போது Selling of Products என்கிறோம். இத்திட்டங்கள் சேமிப்பு திட்டங்கள் (Deposit or Saving Products), கடன் திட்டங்கள் (Loan Products) என்று இருவகைப்படுத்தப்பட்டுள்ளன.  இவற்றின் எண்ணிக்கை வங்கிகளை பொருத்து மாறும். எங்களுடையதை போன்ற தனியார் வங்கிகளில் ஐம்பது திட்டங்கள் இருந்தன என்றால் அரசுடமையாக்கப்பட்ட வங்கிகளில் நூற்றுக்கும் மேற்பட்ட திட்டங்கள் இருந்தன.

இத்தகைய திட்டங்களின் கீழ் நடைபெறும் பரிவர்த்தனைகளை கணினிமயமாக்க முனைந்தபோது அவற்றை தனித்தனி Modules ஆக பிரித்து அதுவரை கைப்பட (Manually) செய்த அலுவல்களை (Processes) கணினி மூலமாக செய்வதற்கு ஏதுவாக வகைப்படுத்த வேண்டியிருந்தது. முன்பு சேமிப்பு திட்டங்களின் கீழ் இருந்த வைப்பு நிதி திட்டங்கள், சேமிப்பு நிதி கணக்குகள், வர்த்தக கணக்குகள் என ஒவ்வொரு திட்டத்தின் கீழ் நடைபெறும் பரிவர்த்தனைகளையும் பதிவு செய்ய (record) பிரத்தியேகமாக புத்தகங்கள் (Ledgers) இருந்தன. அத்தகைய புத்தகங்களே பிறகு கணினிமயமாக்கம் அறிமுகப்படுத்தப்பட்டபோது moduleகளாக வடிவமைக்கப்பட்டன.

இவை Deposit Modules, Loan Modules, DD Module, என பட்டியல் நீண்டுக்கொண்டே போய் முன்பு தேவைப்பட்ட புத்தகங்களின் எண்ணிக்கையை விட Moduleகளின் எண்ணிக்கை கூடியது. இன்றைய மத்திய வர்த்தக மென்பொருள் எனப்படும் Centralised or Core Banking Solutioனுள் நூற்றுக்கும் மேற்பட்ட moduleகள் உள்ளன என்றால் மிகையாகாது.

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

ஆகவே ஒரு வங்கியின் அனைத்து அலுவல்களையும் கணினிமயமாக்குவது ஒருசில அதிகாரிகளை மட்டுமே கொண்ட குழுவால் சாத்தியமில்லை. இப்போதும் கூட ஒரு கிளைக்கு தேவையான நூற்றுக்கணக்கான moduleகளையும் முடித்து ஒரு முழுமையான மென்பொருளை அறிமுகப்படுத்த குறைந்தபட்சம் மூன்றாண்டுகள் தேவைப்படுகிறது. அத்தகைய மென்பொருளும் கூட அதன் முழுமையை அடைய மேலும் இரண்டு, மூன்று ஆண்டுகள் தேவைப்படும்.  எனக்கு மிகவும் தெரிந்த வங்கியின் கணினி இலாக்கா தலைவர் சமீபத்தில் கூறியது இது: 'பெரிய கம்பெனின்னு பேரு. CBS introduce பண்ணி ஆறு வருசத்துக்கு மேல ஆச்சி. இன்னமும் version change பண்றப்ப run time error வருது. கேட்டா அதான் உடனே வந்து சரி செஞ்சி குடுத்துடறமேன்னு சொல்றாங்க. கோடி கணக்குல கொட்டியும் இதான் நிலமை.'

உண்மைதான்.

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

இதில் என்னைப் போன்ற வங்கி மேலாளர்களுக்கு மிகப் பெரிய தலைவலியாக இருந்தது குமாஸ்தாக்களின் அலுவல்களை மேற்பார்வையிடுவது. இதை Maker-Checker அலுவல் என்போம். அதாவது Maker எனப்படும் குமாஸ்தா கணக்கு புத்தகங்களில் பதிவு செய்யும் (enter) பரிவர்த்தனைகளை (transactions) அவை சரியான கணக்கில்தான் ஏற்றப்பட்டுள்ளதா என்பதை சரிபார்ப்பது.

எங்களுடைய வங்கியில் தயாரிக்கப்பட்ட மென்பொருள் clipper மொழியில் தயாரிக்கப்பட்டிருந்ததால் அதில் screen transfer வசதி இருக்கவில்லை. அதாவது ஒரு குமாஸ்தா ஒரு பரிவர்த்தனையை (transaction) முடித்ததும் அந்த திரையை மேலதிகாரியின் கணினிக்கு மாற்றி அவருடைய ஒப்புதலை பெற முடிந்ததில்லை. ஆகவே ஒவ்வொரு பரிவர்த்தனைக்கும் அவர் குமாஸ்தாவின் இருக்கையை நெருங்கி அவர் பதிவு செய்திருந்த பரிவர்த்தனையை சரிபார்த்து தன்னுடைய user id மற்றும் பாஸ்வேர்டை பயன்படுத்தி ஒப்புதலை அளிக்க வேண்டியிருந்தது.

ஒவ்வொரு முறையும் இவ்வாறு செய்வது நடைமுறையில் சாத்தியமில்லை என்பதால் பெரும்பாலான அதிகாரிகள் தங்களுடைய user id மற்றும் passwordஐ குமாஸ்தாக்களிடமே கொடுத்துவிடுவார்கள். ஆக மேக்கர்-செக்கர் இருவருமே ஒருவரேதான்! இதன் விளைவு? குமாஸ்தா ஏதாவது தவறு இழைத்திருக்கும் பட்சத்தில் அது உடனே கண்டுபிடிக்கக் கூடிய வாய்ப்பு இல்லாமல் போனது.

அன்றைய அலுவல்கள் அனைத்தும் முடிந்து இறுதி அறிக்கைகள் (Day end reports) கிடைத்தபிறகே அதிகாரிகளால் அன்றைய பரிவர்த்தனைகளை சரிபார்க்கும் நிலை இருந்தது! பல வருடங்களுக்குப் பிறகே குமாஸ்தாக்கள் பதிவு செய்யும் பரிவர்த்தனைகளை வேறொரு இடைக்கால கோப்பில்/அட்டவணையில் (file/table) பதிவு செய்து அதை அதிகாரிகள் தங்களுடைய கணினியில் பார்வையிட்டு ஒவ்வொரு பரிவர்த்தனைக்கும் ஒப்புதல் அளிக்கும் முறை வந்தது.

இத்துடன் இன்னும் பல சிக்கல்கள் இருந்தன....

தொடரும்...

வங்கிகளில் கணினி - 2

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

அரையாண்டு, ஆண்டு இறுதி காலங்கள் வந்துவிட்டால் கேட்கவே வேண்டாம். அப்போதெல்லாம் டிசம்பர் மாதம் வந்துவிட்டால் (வங்கிகளின் ஆண்டு ஜனவரி-டிசம்பர் ஆக இருந்த காலம் அது) முதல் தேதியிலிருந்தே வங்கி ஊழியர்கள் அன்றாட அலுவல்களுடன் ஆண்டு இறுதி அலுவல்களை துவக்கினால் மட்டுமே டிசம்பர் 30ம் தேதிக்குள் ஆண்டு இறுதி அலுவல்களை ஒரளவுக்காவது முடிக்க முடியும். டிசம்பர் 30 மற்றும் 31ம் தேதிகளில் வீட்டிற்கு செல்வது என்பதே அபூர்வம்தான். கிளைகளில் பணியாற்றும் குமாஸ்தாக்களுக்கு அந்த ஒரு மாதகாலத்தில் இத்தனை மணி நேரம் ஒவர் டைம் அளிக்க வேண்டும் என்று நிர்ணயித்துவிடுவதும் உண்டு. ஆனால் என்னைப் போன்ற மேலாளர்களுக்கோ அல்லது துணை அதிகாரிகளுக்கோ Closing allowance என்று ரூ.250 லிருந்து ரூ.500/- வரை கொடுத்துவிட்டு தினம் ஒன்றுக்கு பதினைந்து மணி நேரத்திற்கு மேல்  உலுக்கி எடுத்துவிடுவார்கள்.

ஆனாலும் ஆண்டு இறுதி முடிந்து உள் மற்றும் வெளி தணிக்கையாளர்கள் (Internal and External Auditors) கணக்குகளை தணிக்கை செய்து கிளையிலுள்ள அனைத்து கணக்குகளிலும் பற்று மற்றும் வரவு வைத்த வட்டி சரியானதுதான் என்று கூறும் வரை பல இரவுகளில் உறக்கத்தை இழக்க வேண்டியிருக்கும். ஏதாவது ஒருசில கணக்குகளில் வட்டி பற்று வைத்தது குறைவு என்று கண்டுபிடிக்கப்பட்டு அதற்கு முன்பு அந்த கணக்கு முடிக்கப்பட்டிருக்கும் சூழலில் வங்கிக்கு ஏற்பட்ட வட்டி இழப்பை சம்பந்தப்பட்ட அதிகாரி மற்றும் மேலாளரிடமிருந்து வசூலிக்கவும் வங்கிகள் தயங்காது.

ஆகவே இத்தகைய அலுவல்கள் கணினிமயமாக்கப்படவேண்டும் என்பதை அப்போது கிளைகளில் பணியாற்றிய என்னைப் போன்ற அதிகாரிகள் அதாவது Banking Officers முன்வந்ததில் வியப்பில்லை. ஆனால் அவர்களில் எவருமே முறைப்படி மென்பொருட்களை வடிவமைக்கவோ (Design) அல்லது தயாரிக்கவோ (Develop) பயின்றவர்கள் அல்ல. வங்கி அலுவல்களுக்குப் பிறகு கையில் கிடைத்த புத்தகங்களை படித்தோ அல்லது அப்போது இதற்கென்று புற்றீசல் போன்று துவக்கப்பட்டிருந்த பயிற்சி அமைப்புகளில் (Training Institutes) சேர்ந்தோ பயின்றவர்களாகத்தான் இருந்தார்கள். இத்தகையோரை ஓரிடத்தில் சேர்த்து துவக்கப்பட்டவைதான் கணினி இலாக்காக்கள். பெரும்பாலான வங்கிகளில் இந்த இலாக்காவை Data Processing Centre என்று குறிப்பிட்டிருந்தனர். கணினி இலாக்கா என்ற பெயர் வந்ததே இரண்டாயிரம் ஆண்டுக்குப் பிறகுதான். இதற்கு எங்களுடைய வங்கியும் விதிவிலக்கல்ல.

கிளை அதிகாரிகள் தாங்களாகவே முன்வந்து மென்பொருளில் இறங்கியதற்கு வேறு ஒரு காரணமும் இருந்தது. அதாவது inner agenda என்பதுபோன்ற காரணம். சாதாரணமாக கிளை அதிகாரிகள் மூன்று வருடங்களுக்கு மேல் ஒரே ஊரில் பணியாற்ற முடிவதில்லை. ஒரே ஊரில் இருக்க வேண்டும் என்றால் வங்கியின் மத்திய அலுவலகத்தில் இருந்த சில முக்கிய இலாக்காக்களில் பணியாற்றி இவர்கள் இல்லையென்றால் பணிகள் ஸ்தம்பித்துபோய்விடும் என்பதுபோன்ற ஒரு மாயையை ஏற்படுத்த வேண்டும். இதில் அக்கவுண்ட்ஸ், க்ரெடிட் இலாக்காக்களை விட்டால் இந்த டேட்டா ப்ராசசிங் இலாக்காதான் மிக முக்கியமான இலாக்காவாக இருந்தது. மென்பொருள் தயாரிப்பது என்பது அத்தனை இலகுவான விஷயம் இல்லையே. ஆகவே இந்த அதிகாரிகளுக்கு பயங்கர தட்டுப்பாடு இருந்த காலம் அது. தலைமை அலுவலகம் அமைந்திருந்த நகரம் மற்றும் அதற்கு மிகவும் அருகாமையிலுள்ள நகரங்களைச் சார்ந்த அதிகாரிகள் தங்களுடைய சொந்த ஊரிலோ அல்லது அதற்கு மிக அருகாமையிலோ தொடர்ந்து பணியாற்ற கணினி இலாக்கா ஒரு வரப்பிரசாதமாக இருந்தது.

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

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

ஒரு மென்பொருள் தயாரிப்பில் இறங்குவதற்கு முன்பு அவற்றின் தேவைகளைக் குறித்து ஆய்வு செய்து (Requirement Study) சம்பந்தப்பட்ட மென்பொருளை பயன்படுத்துபவர்களுடன் (Users) கலந்தாலோசித்து தயாரிக்கப்படும் SRS அறிக்கைகளின் முக்கியத்துவத்தை இந்த கத்துக்குட்டி அதிகாரிகள் உணர்ந்திருக்கவில்லை.

மேலும் இத்தகைய அதிகாரிகளில் பெரும்பாலானோர் கிளைகளில் பணியாற்றியவர்கள் என்பதால் கிளைகளில் பணியாற்றுபவர்களுக்கு என்ன தேவை என்பதை மற்றவர்களிடம் கேட்டு தெரிந்துக்கொள்ள தேவையில்லை என்றும் இதற்கென பிரத்தியேகமாக ஒரு அறிக்கை தயாரித்து மேலதிகாரிகளின் பார்வைக்கு சமர்ப்பிக்க தேவையில்லை என்றும் நினைத்தனர். 'நாம SRS Document தயாரிச்சி அனுப்புனாலும் அத படிச்சி புரிஞ்சிக்கப் போறதில்ல. அப்புறம் எதுக்கு வீண் வேலை.' என்றும் நினைத்திருக்கலாம்.

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

தொடரும்...

Technorati Tags: கணினி அனுபவங்கள்

வங்கிகளில் கணினி - என் அனுபவம் 1

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

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

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

மான்யுவல் (Manual) ஆப்பரேஷன் என்ற சூழலிலிருந்து முற்றிலும் கணினி மயமாக்கப்பட்ட ஆட்டோமேட்டட் (Automated) சூழலுக்கு மாறும் சமயத்தில் வங்கி ஊழியர்கள் சந்திக்க நேர்ந்த சிரமங்கள் கொஞ்சநஞ்சமல்ல.

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

முதல் நிலை அதிகாரிகள் ஐவரை மட்டும் வைத்துக்கொண்டு இரவும் பகலும், விடுமுறை நாட்களிலும் அமர்ந்து நேரம் காலம் பாராமல் அத்தனை விவரங்களையும் கண்னியில் தகவல்களத்தில் (database) ஏற்றியதை இப்போது நினைத்துப்பார்க்கவே மலைப்பாக உள்ளது.

ஆனால் ஒருமுறை பாடுபட்டு ஏற்றிவிட்டால் அதை காலாகாலத்துக்கும் பயன்படுத்த முடியும் அல்லது நம்முடைய தேவைகளுக்கேற்ப மிக எளிதாக மாற்றி அமைத்துவிடமுடியும், மேம்படுத்த முடியும் என்பதை அப்போது நானோ என்னுடைய துணை அதிகாரிகளோ உணரவில்லை.

அன்றுவரை ஒவ்வொரு மாதக்கடைசியிலும் ஒவ்வொரு கணக்கிலும் இருந்த மிகுதி (Balance) தொகையை வேறொரு புத்தகத்தில் குறித்து, கூட்டி அதன் கூட்டுத்தொகை கிளையின் பொது கணக்குப் புத்தகத்தில் (General Ledger) உள்ள கூட்டுத்தொகைக்கு சமமாக உள்ளதா என்பதை உறுதிபடுத்திக்கொள்வதற்குள் அடுத்த மாத இறுதி வந்துவிடும்.

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

அது மட்டுமா? ஒவ்வொரு கணக்கிலும் மூன்று மாத இடைவெளிகளில் வட்டித் தொகையை கணக்கிட்டு அதை ஒவ்வொரு கணக்கிலும் பற்று/வரவு வைத்து முடிப்பதற்கே இரண்டு மூன்று வாரங்கள் ஆகிவிடும். ஆனால் கணினி மயமாக்கப்பட்டதன் பிறகு கிளையிலுள்ள எல்லா வாடிக்கையாளர்களுடைய கணக்கிலும் அதனதற்குண்டான வட்டியை அரை மணியில் கணக்கிட்டு அந்தந்த கணக்கிலும் பற்று/வரவு வைத்து முடித்து உன்னுடைய கிளையின் மொத்த வட்டி வரவு/பற்று இதுதான் என்பதை அன்றைய மாத இறுதி நாளன்றே தெரிவித்துவிடும்!

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

ஆனால் இதிலும் சிக்கல்கள் இல்லாமல் இல்லை.

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

அன்றோ எங்களைப் போன்ற பெரும்பாலான வங்கிகளில் பணியாற்றிய ஒருசில அதிகாரிகள் தாங்களாகவே கற்று தயாரித்த மென்பொருட்களைத்தான் பயன்படுத்தி வந்தன. அவை பெரும்பாலும் அப்போது பழக்கத்தில் இருந்த Dbase, Foxpro, Informix, Cobol எனப்படும் மொழிகளிலேயே (Language) எழுதப்பட்டிருந்தன.

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

ஆனால் அன்றைய சூழலில் அதன் தாக்கத்தைப் பற்றி கவலைப்படாமல் அதிக பொருட்செலவில்லாமல் உருவாக்கப்பட்ட பல மென்பொருட்களில் இதுவும் ஒன்று. அன்றையே அத்தியாவசிய தேவைக்கு - அதாவது ஒரு கிளையில் நடைபெறும் அன்றாட பரிவர்த்தனைகளை (transaction) நடத்தி முடித்து நாளிறுதியில் (at the end of the day) கணக்கு முடிக்கும் வரை - அது பயன்பட்டது.

இதன் இயங்கு தளம் (OS) விண்டோஸ் அறிமுகமாகும் வரை பிரபலமாக இருந்த disc operated system எனப்படும் DOS. ஆகவே இந்த மென்பொருளை பயன்படுத்த ஒருவர் DOS கட்டளைகளை (commands) ஒரளவுக்காவது அறிந்திருக்க வேண்டும்.

இதில்தான் சிக்கலே....

தொடரும்..

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