28 நவம்பர் 2007

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

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

தொடரும்

4 கருத்துகள்:

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

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

    <= ஆனால் டெமோவுக்கு வருகின்ற மார்க்கெட்டிங் ஆசாமிகள்
    'மொட்டைத்தலையிலகூட முடிய வளர்க்கலாம்.' என்பதுபோல் தங்களுடைய மென்பொருளைப் பற்றி அளப்பார்கள். ==>
    இது மென்பொருளுக்கு மட்டுமல்ல எல்லா வியாபாரத்துக்குமே பொருந்தும்.
    என்னிடம் ஒரு வங்கியின் மேலாளர் என்னுடைய பொது சேம நல நிதியிலிருந்து பணத்தை எடுத்து அந்த வங்கி புதிதாக ஆரம்பித்துள்ள பங்கு முதலீட்டுடன் கூடிய "ஓயுவூதிய நிதியில்" போட வேண்டுமாம்.அவருடைய நிர்ப்பந்தம் அவருக்கு.

    <==
    மென்பொருளை தெரிவு செய்யும் சமயத்தில் எங்களை கலந்தாலோசிக்கவில்லை என்கிற ஆதங்கம்தான் மென்பொருளை ==>

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

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

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

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

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

    பதிலளிநீக்கு
  2. வாங்க சிவா,

    எல்லாம் பட்ஜெட் மற்றும் நிர்ணயிக்கப்பட்ட கால அளவுக்குள் முடிக்க வேண்டும் என்ற கட்டாயம்தான்.//

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

    அபராதம் கான்ட்ராக்டில் போடுங்கள்.அப்புறம் பாருங்கள் நடக்கிறதா இல்லையா என்று.//

    இதனால் என்ன பயன்? அபராதத்தை செலுத்திவிட்டு தங்கள் வழியில் செல்லவும் இன்று சில நிறுவனங்கள் தயாராக உள்ளனவே!

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

    இது இன்றும் பல நிறுவனங்களில் (வங்கிகள் என்று கொள்ளவும்) நிலவும் அக்கிரமம்.

    மேலும் தவறே இல்லாத மென்பொருள் என்ற ஒன்று இருக்காது என்பது என் எண்ணம்.//

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

    பதிலளிநீக்கு