ВЪВЕЖДАНЕ НА АВТОМАТИЗИРАНИ СИСТЕМИ ЗА БАНКИРАНЕ
А. Десето, АКБ "РОСЕСТБАНК" Проблеми на внедряването на интегрирана автоматизирана система в контекста на текущата банкова технология
Запознаване с банката
История на избора на банкова система
През 1994 г. в България вече има известни фирми, които разработват софтуер за банки, като ASOFT, DIASOFT, PROGRAMBANK, Inversion, R-Style и др., имащи няколко десетки и дори стотици инсталации на техния софтуер в различни банки в България. Освен това в Толиати имаше местна фирма "Инфолада", която успешно представи своите програми в "АвтоВАЗбанк", "Ладабанк".
Като се има предвид, че нашата банка беше почти "нулева" по отношение на автоматизацията, започнахме да полагаме усилия да променим ситуацията.
Необходимостта от такива промени се увеличи значително през 1995 г. В Толиати най-голямата банка, AvtoVAZbank, започна да изпитва финансови затруднения, някои банки фалираха. Клиентите отидоха в Rosestbank, която в тези трудни условия, благодарение на мъдрото управление на банката, продължи само да укрепва финансовото си състояние. Банката насочи дейността си към големи промишлени предприятия: АвтоВАЗ АД, ТоАЗ АД, Самаранефтегаз АД, Магнитогорски железодобивни заводи, както и средни и малки предприятия, чийто брой достигна повече от 3000.
Банката рязко увеличи документооборота, който става все по-труден за обработка без автоматизирана банкова система.
Към средата на лятото на 1995 г. банката разполага с екип от специалисти, състоящ се от програмисти, администратори на бази данни, мрежови администратори, инженери по електроника, специалисти по телекомуникации и комуникации.
През всичките тези месеци непрекъснато се работи както по "възпитанието" на персонала на банката - какво е това"автоматизирана банкова система" и как се различава от програмата, например - "Банков оперативен ден", както и избор на автоматизирана система.
През 1995 г. посетих московски фирми, които разработваха софтуер за банки: ASOFT, DIASOFT, PROGRAMBANK, Inversion, Banking Systems. Софтуерът на тези компании по това време е реализиран главно на езика Clipper, Clarion, C, Pascal или с помощта на мениджъра на записи Btrieve и дори имат собствен производствен инструментариум за разработването на СУБД ATLANTIS (компанията Banking Systems). Всички тези продукти бяха внедрени в архитектурата на файловия сървър. От фирми ми казаха, че банковите системи, базирани на мултиплатформени СУБД (ORACLE, INFORMIX, INGRES, SyBASE), работещи с операционна система UNIX в архитектура клиент-сървър, трябва да се появят на пазара през втората половина на 1995 г.
Етап I - Проектиране; II етап - Разработване на проекта: III етап - Реализация.
Договорът беше структуриран по такъв начин, че първо компанията ще направи проект на Информационната банкова система, след което ще бъде взето решение за продължаване на работата по проекта.
В рамките на 1,5 месеца специалистите на компанията, съвместно с банковите специалисти, разработиха Основния проект - "Автоматизация на банковата дейност на ROSESTBANK" - в 4 тома.
Общи проблеми при внедряването на софтуер за банкови системи
Разбиране от ръководството на банката
Един от важните фактори за успешното внедряване на банкови системи е разбирането от ръководството на банката, че банката не се нуждае от програми, а от система, която ще включва системни програми, приложни програми, компютри, комуникационно оборудване, комуникационни линии, технология на работа и организационнибанкова структура. Тогава има възможност за появата на автоматизирана банкова система в банката.
Кой управлява процеса на създаване и внедряване на банковата система?
В зората на "ерата на ASU" академик В.М. Глушков формулира „Принципа на първия мениджър: цялата работа по създаването и внедряването на автоматизирана система за управление на предприятието трябва да се ръководи и контролира пряко от неговия първи ръководител“ и „онези предприятия, където първият ръководител третира автоматизираната система за управление формално и не контролира хода на нейното внедряване, обикновено не получават нищо от автоматизираната система за управление, с изключение на главоболия и ненужни разходи.“
Статутът на ръководителя, отговорен за създаването на банковата система, трябва да бъде доста висок. Основната му задача, за която е поканен да работи в банката, е да автоматизира дейността на цялата банка, а не да пише две програми за кредитния отдел и три програми за фондовия отдел.
Статутът му не трябва да бъде по-нисък от началник на отдел, а още по-добре - вицепрезидент.
Доста често срещано и катастрофално погрешно мнение е, че ръководителят на отдела за автоматизация трябва да докладва на главния счетоводител. Аргументацията на привържениците на този подход е следната: какво е компютър? Изчислителна машина. А къде е най-калкулираният в банката? Точно така, счетоводство.
Седалище на отдел Автоматизация
Разбирането от ръководството на банката за мястото на отдела за автоматизация в организационната структура на банката може да спести много проблеми.
Цитат от списанието: „Идеалният подход за автоматизиране на работата на банката би бил такъв, че преди регистрацията на банката и началото на нейната практическа дейност, да се създаде специално звено, подчинено пряко на първия управител или на висшия управителен орган на банката, накойто отговаря за избора, придобиването и внедряването на ABS. Същевременно на подобно поделение се дава правомощието да участва в определянето на стратегията за развитие на банката, нейната структура и функции, с право на глас."
Идеалният подход никога не се намира на практика. Често ръководството (отделът) за автоматизация се разглежда от ръководството на банката като спомагателно, осигуряващо звено. Това значително намалява ефективността на внедряването на системата, тъй като единици, които имат равен или по-висок статус в сравнение със статуса на единицата, която отговаря за тази работа, получават възможност да игнорират инструкции, които не им отговарят. Последствията могат да бъдат, без преувеличение, катастрофални, тъй като цялата технология може да бъде разрушена. Като минимум графикът за изпълнение ще се забави поради необходимостта от постоянно разрешаване на дребни конфликти.
Много е важно отделът, отговарящ за автоматизирането на работата на банката, не само да има навременна и достоверна информация за насоките на развитие на банката и намеренията на нейното ръководство, но и да може да влияе върху формирането на тези насоки и намерения.“
Състав на отдела за автоматизация
Проблемът тук е, че всяка банка би искала да има само двама или трима програмисти, които да правят всичко, от което се нуждае банката. Но това не се случва. Не е лесно да убедите банковия мениджмънт, че съвременната автоматизирана банкова система изисква както системни програмисти (познания по UNIX), така и приложни програмисти (познания по INFORMIX), и комуникационни специалисти (познания по TCP/IP, и администратори на бази данни, и мрежови администратори.
Кой избира системата?
Изборът на система трябва да бъде оставен на ръководителя на отдела, отговарящ за автоматизацията.Той е отговорен за това. Той трябва да успее да убеди ръководството на банката и да обоснове своя избор.
Кои банкови системи да избера?
Дълго време на страниците на различни компютърни вестници и списания имаше спорове: кой трябва да развива банковите системи?
Някои твърдяха, че това трябва да се направи от програмисти, наети в персонала на банката. Други твърдяха, че специални фирми за разработка трябва да направят това и след това да копират техния софтуер в различни банки.
Струва ми се, че тук не може да има универсални препоръки. Всяка банка трябва да избере своя собствена пътека, най-подходящата за нея, и да удари "очото на бика" - да получи резултата.
Поехме по пътя на съвместно проектиране и развитие на банковата система с чуждестранна компания IBC, която вече има опит в разработването и внедряването на 4-то поколение ABS в България (SVKB Bank, VUB Bank, Самара).
Какво е предимството тук според нас?
Банката не е необходимо да създава голям брой звена за автоматизация. Необходимо е наличието на малък, но добре обучен персонал от специалисти, достатъчен за поддържане и развитие на системата.
Защо с чужда компания, а не с българска?
По-горе споменах, че много български фирми обявиха в средата на 1995 г. появата на нови системи на нови платформи в архитектурата "клиент-сървър". Наистина на изложенията бяха демонстрирани някои подсистеми от новите системи. Но не видяхме завършени системи.
Има и още един важен фактор в полза на нашия избор. Схванахме идеята, че новите системи се създават чрез прехвърляне на старата декларация за проблема на нова платформа с пренаписване на софтуер върху нов инструментариум. И ни беше страхче качеството на такива системи ще бъде ниско в смисъл на целостта на системата. Пример е фактът, че ФОРС беше една от първите, които разбраха това и сега се занимават с адаптиране на чуждата система на една от банките от Близкия изток.
Програми, работни станции, пакетиран софтуер
Посочих този елемент като проблем при внедряването на интегрирани банкови системи. Обяснявам защо.
Банката, като правило, винаги вече има някакъв софтуер. Това са или програми на банков програмист, или закупени работни станции, или цели софтуерни пакети (системни модули), които работят в локална мрежа с файлов сървър. Те могат да бъдат написани на различни езици. При внедряване на интегрирана система възниква проблем с прехвърлянето на информация към нова база данни. Изисква се да напишете всякакви конвертори, да намерите програмисти по региони, които са продали програмите си на банката, да ги помолите да добавят нещо към своите програми и . заплащане за работа.
Друг проблем създават потребителите на системата. Те вече са свикнали да работят със съществуващ софтуер. И тук идваме с друга система. Формите на екрана са различни, интерфейсът, както изглежда на потребителите, не е "приятелски". И тогава започва отхвърлянето на нови средства, което не е лесно за преодоляване.
Какво е на първо място - структура или технология? Каруца или кон?
Проблемът тук е, че много банкови служители имат идеята, че трябва да автоматизираме работата на конкретен служител. Инсталирахме програми в един отдел, след което трябва да се преместим в друг отдел и да предоставим на всички програми и там.
Аргументът тук е следният: всеки служител заема своето място в отдела, отделът е включен в организационната структура на банката. Ако един отдел напр.пасивни операции, повече от други носят приходи на банката, така че трябва да започнете автоматизацията си с него. А не от счетоводството, където само смятат и правят отчети. В счетоводния отдел можете да поставите в краен случай още няколко работници и те ще преброят всичко. Дълго обясняваме, че ние не автоматизираме работни места, не структурата, а технологията на банката (технологичните процеси). Ние не изработваме работни станции, а интегрирана автоматизирана банкова система с разпределена обработка на данни, породени от клонове и филиали на банката. Ето защо възниква проблемът - да се докаже, че структурата след автоматизацията може да се промени, тя вече е вторична по отношение на технологията и се наслагва върху нея. Конят винаги е отпред, а каруцата е зад него.
Програмист и дизайнер. Борбата на идеите за системата
Много е добре банката да разполага с добър екип от програмисти с еднакво мислене. Често се случва един програмист да предпочете езика за програмиране Clipper, друг Delphi. Те вече са усвоили всеки един от езиците си, написали са много програми, преди да започнат работа по договора за внедряване на базовата система "PROBANK". Системата PROBANK е внедрена на INFORMIX 4GL. Сблъскахме се с такъв проблем, че програмистите на банката биха предпочели други инструменти за разработка на приложения, но не и 4GL. Появиха се много по-модерни инструменти за разработка - това е продуктът INFORMIX - NewEra, това е SuperNova, появиха се и бяха налични различни CASE инструменти. Но факт е, че нашият етап на развитие не започна от нулата, а с въвеждането на базовата система PROBANK с корекции по време на самия проект, тъй като тя вече изисква промени поради постоянни инструкции отгоре (различни инструкции от Централната банка на България). Спрете работа, напр.касиери на операционната зала на рублата, за разработването на нов проект - вече нямаше смисъл.
Тук имаше проблем с идеята за банковата система на български програмист и чуждестранен системен дизайнер, които проектираха системата като цяло и която беше внедрена на един инструментариум. Български програмист, който не се интересува от срокове, условия на договора, би искал да преработи всичко по свой собствен начин, на удобен за него език, тъй като е свикнал да прави свои собствени програми, софтуерни пакети, "кутийни" банкови системи.
Срокът за изпълнение е особен проблем. Бяхме изправени пред факта, че по време на процеса на внедряване постоянно трябваше да правим добавки, промени и изтривания в софтуера. Това се дължи на различни нормативни документи, като указания и заповеди на Централната банка на България. Голям брой промени изискват желанието на потребителите да направят по-"приятелски" интерфейс. Наистина бяха необходими много промени, тъй като от подготовката на проекта имаше промени в технологията на банката (някои технологични процеси се появиха или изчезнаха). При тези условия е практически невъзможно да се спазят предварително определените срокове за внедряване на системата.
Това е най-основният проблем за хората, ангажирани и отговорни за създаването на модерна интегрирана автоматизирана банкова система в банката. Но ние знаем, че нямаме връщане назад, нашата банка няма да се върне към „кутийните” банкови системи.
Пожелавам на колегите здраве и успехи в нашия труден, все още недобре разбран в България, но интересен бизнес на автоматизирането на български банки.