வங்கிகளில் கணினி - 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) பதிவு செய்து அதை அதிகாரிகள் தங்களுடைய கணினியில் பார்வையிட்டு ஒவ்வொரு பரிவர்த்தனைக்கும் ஒப்புதல் அளிக்கும் முறை வந்தது.

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

தொடரும்...