Arhiva pentru Septembrie, 2009
Modele de outsourcing: Prim-contractor
Daca in numarul trecut ne-am concentrat asupra prezentarii generale a conceptului de outsourcing, tratand modelul multi-sourcing, astazi ne vom focusa pe un model descris de Gartner a avea un rol de stabilizare a pietei de outsourcing cu sanse de peste 70%, desi nici clientii si nici furnizorii nu vor pretinde acest rol drept unicul lor serviciu special. Modelul a fost adoptat in Europa in proportie de 30% pana in 2007.
Rolul prim-contractorului este acela de a acorda suport si a suplimenta capacitatile interne ale departamentului IT si ale departamentului de achizitii sau ca substitut pentru ele. Caracteristici principale:
• Se manifesta ca o entitate unica, de sine statatoare (furnizor extern sau client)
• Are responsabilitate end-to-end pentru integrarea sau administrarea serviciilor multiple pentru a determina o singura solutie sau intregul serviciu pentru client.
Modelul prin-contractor este recomandat de Gartner deoarece:
• Prezinta abilitatea de a administra sau integra furnizori multipli (produse, proiecte si servicii) pentru a determina o singura solutie sau serviciu pentru organizatia client;
• Este modelul principal de crestere in intervalul 2000-2010 pentru evolutia pietei serviciilor IT si reprezinta un element de maturizare major pentru companiile non-IT;
• Ar putea satisface nevoile de crestere ale business-ului prin calificari interne si pentru activitati suplimentare pentru care alte metode ar implica un timp indelungat si costuri suplimentare
• Este sustinut de abilitatea furnizorului de a construi structuri globale, end-to-end, cu scopuri/obiective multiple si mai multe verticale.
Citeste in continuare
Front-end-ul, ultima si prima reduta
Bancile exista pentru a face profit, deservindu-i pe clienti. Reteaua de distributie bancara este un element esential, asigurând acea nevoie de a fi acolo unde este clientul, cat mai aproape de el. Cum unitatea bancara este interfata fizica cu un client, aplicatia de front-end sau front-office, este interfata fizica a lucratorului bancar cu sistemul informatic al bancii, cu datele si informatiile despre client, tranzactii, produse.
Cum sistemele bancare sunt destul de vechi in general, nici aplicatiile de ghiseu bancar nu sunt prea noi. In acelasi timp, banca lanseaza canale alternative de distributie, Internet banking, Mobile banking etc, care sunt si ele o interfata catre aceleasi elemente, datele clientului. Daca prin aplicatia de Internet banking clientul isi vede doar datele proprii, prin aplicatia de frontend lucratorul bancar vede datele tuturor clientilor. Dar, diferenta este doar un multiplicator de volum, tipurile de date si informatii fiind aceleasi. Bineinteles, la ghiseu, prin aceeasi aplicatie (sau nu, în general nu), se desfasoara si operatiunile cash si alte tipuri de operatiuni care nu pot fi apelate prin Internet banking. Diferenta majora dintre aceste aplicatii este aceea de tehnologie si integrare. Daca Internet bankingul este o aplicatie apelând la tehnologii moderne, de tip Internet, aplicatiile de front-end sunt de obicei pe tehnologii vechi, greoaie, necesitând de fapt apelarea la mai multe aplicatii.
Daca “as-is”-ul este de multe ori difuz si neomogen, “to-be”-ul este destul de clar: un nivel unic de prezentare – ecranul folosit la ghiseu ar trebui sa fie similar cu cel folosit de alte canale de distributie, afisand aceleasi date, într-un mod unitar. Practic, doar drepturile celui care acceseaza aplicatia sa determine ce date sa se afiseze si ce operatiuni sa fie permise. Practic, logica aplicatiei de front-end sa recunoasca tipul terminalului care acceseaza (PC, smartphone, mobil etc), sa adapteze ecranul, sa identifice utilizatorul si sa îi afiseze doar operatiunile la care are dreptul. Acest “to-be” este destul de îndepartat pentru multe banci, din motive istorice si financiare. Majoritatea aplicatiilor de core-banking sunt vechi, fiecare având initial aplicatia proprie de front-end.
O banca foloseste multe aplicatii de core banking, una pentru retail, una pentru corporatii, una pentru trezorerie, una pentru procesare carduri, una pentru creditare samd. Fiecare vine cu un front-end propriu. Idealul este sa fie integrate într-o singura aplicatie. Acest lucru nu este posibil. Nu exista aplicatia unica buna la toate. Astfel, s-a inventat conceptul de arhitectura pe trei nivele în care se separa partea de core banking (unde se tin datele primare), de partea de logica de business si de partea de prezentare. Integrarea acelor multe aplicatii într-una singura, de fapt se realizeaza prin portalizarea functionalitatilor celorlalte.
Unele aplicatii însa nu se pot portaliza. Se va astepta atunci momentul înlocuirii.
Dar macar stim ca avem o ultima reduta, cea a unui front-end integrator. Intr-o banca se vor regasi atat frontend-ul vechi, de prima generatie, cat si cel nou , de ultima generatie, care vor coexista o perioada lunga. Acest lucru este posibil daca se aplica conceptul SOA (Service Oriented Architecture), care permite a reutiliza ce exista, a modulariza si a decupla.
Aplicatia de front-end, plecând de la o arhitectura bazata pe SOA, este destul de simpla. Partea complicata este cea de logica bancara. Nivelul intermediar, de middleware, trebuie sa sustina aceasta logica prin dezvoltarea unor “servicii “de tip web care sa apeleze obiecte de business decuplate. Aceasta logica de business trebuie sustinuta de un nivel de organizare superior, aparând nevoia existentei unui BPMS (Business Process Management System) profesionist.
Practic, specificatiile de business trebuie sa apartina businessului si sa se bazeze pe procesele de business. BPMS-ul trebuie doar sa traduca în limbaj informatic pentru a fi creata partea de logica de business care se implementeaza informatic. Deci, front-end-ul, nimic mai Simplu.
Articol publica in Market Watch in Septembrie 2009