Research Report

UNIVERSITATEA POLITEHNICA BUCURETI

FACULTATEA DE AUTOMATIC I CALCULATOAREDEPARTAMENTUL CALCULATOARE

PROIECT DE DIZERTAIECompetitive Intelligence si Business IntelligenceCoordonator tiinific:

Prof. Cristian Popescu

Absolvent:

Dana Razvan Nicolae

BUCURETI

Februarie 2016Table of Contents

11. Introducere

12. Nevoia de Business Intelligence si Competitive Intelligence

23. Analiza diagnostic BI

23.1. Urmarirea defectelor

23.1.1. Descriere

33.1.2. Scopul si metrici utilizate

43.2. Urmarirea rezultatelor din testare

43.2.1. Descriere

53.2.2. Scopul si metrici utilizate

83.3. Urmarirea integrarii continue

83.3.1. Descriere

93.3.2. Scopul si metrici utilizate

93.4. Urmarirea sistemului de versionare

93.4.1. Descriere

103.4.2. Scopul si metrici utilizate

113.5. Diagnostic

124. Analiza diagnostic CI

124.1. Analiza SWOT

124.1.1. Puncte tari

134.1.2. Puncte slabe

144.1.3. Oportunitati

144.1.4. Amenintari

144.2. Analiza Cele Cinci Forte a lui Porter

144.2.1. Amenintarea adusa de noi competitori

154.2.2. Intensitatea competitiei

164.2.3. Puterea de influenta a furnizorilor

164.2.4. Puterea de influenta a clientilor

164.2.5. Produse substitut

174.3. Diagnostic

1. IntroducereIn aceasta lucrare voi ncerca sa analizez factorii care intra in componenta proceselor de Business Intelligence si Competitive Intelligence din cadrul firmei Misys, ce are ca activitate principala dezvoltarea solutiilor software in domeniul financiar. Daca ne uitam la o definitie simplificata a BI, deducem faptul ca este pur si simplu o modalitate de a analiza si optimiza structura interna a unei companii prin utilizarea unor programe speciale. Pe de alta parte, CI este procesul de a aduna si analiza informatii pentru a avea o intelegere mai buna asupra industriei si a competitiei,Profitul si competivititatea sunt doua obiective pe care orice companie le urmareste dintotdeauna. Astfel, putem spune ca intr-o oarecare masura, orice companie este obisnuita pana la un anumit nivel cu procesele de BI si CI. Totusi, in ziua de astazi tehnologia este mai accesibila, ceea ce inseamna ca pana si o intreprindere de mici dimensiuni va colecta un volum foarte mare de informatii.

Volumul colectat de date nu mai poate fi memorat pur si simplu, iar pe langa dimensiunea acestuia se mai poate identifica un factor crucial, si anume relevanta informatiei. Nu orice bucata de informatie este valoroasa, iar acest lucru trebuie controlat rigid, deoarece in caz contrar se pot risipi o multime de resurse pentru o analiza deloc esentiala la golurile companiei.

Astfel a aparut o necesitate pentru automatizarea procesului, pentru definirea unor reguli si pentru audit. Aceste lucruri sunt posibile prin aplicatii dedicate care, configurate dupa un set de metrici definite corect necesita o interactiune umana cat mai mica, si livreaza solutii cat mai inteligente.2. Nevoia de Business Intelligence si Competitive IntelligenceOdata cu aparitia si evolutia internetului, accesul la date a devenit foarte facil si la indemana oricui. Acest lucru inseamna ca banii nu mai reprezinta cel mai important factor in stabilirea dominantei dintre companii. Internetul a devenit o piata de desfacere unde exista sanse egale atat pentru companii mici, cat si pentru companii multinationale de succes.Cu un numar atat de mare de jucatori pe piata, competitia a atins un punct culminant, iar informatia a devenit cea mai de pret posesie. Acest lucru este vizibil in toata lumea, indiferent de domeniul de activitate sau de industrie.In prezent, domeniul financiar se afla intr-o competitie ce creste exponential pe zi ce trece. Acest lucru este ingreunat de pasul rapid cu care se modifica sau apar noi cerinte de reglementare aferente cu activitatea desfasurata. Este din ce in ce mai greu pentru aceste companii sa tina pasul cu ultimele schimbari si totodata sa nu ramana in urma competitiei. Uitandu-ne la situatia bancilor, putem descoperi ca exista o varietate mare de servicii oferite de care beneficiaza clienti de toate tipurile; de la persoane fizice, la organizatii de stat si chiar si alte companii. [1]In functie de clientul in cauza, pot interveni reglementari suplimentare ce trebuiesc consolidate. Anumite servicii sunt strict legate de stabilitatea financiara a companiei, iar acest lucru implica adoptarea unor solutii inteligente pentru a putea face fata. Ca in orice alta afacere, relatia cu clientul este foarte importanta, de aceea respectarea valorilor setate de catre companie sunt necesare pentru a castiga un posibil client. Dinamica dintre banca si client este diferita fata de alte industrii, iar acest lucru se datoreaza faptului ca fiecare client reprezinta o investitie ce trebuie analizata cu grija si urmarita pe tot parcursul contractului.Din aceste criterii se poate observa cat de mare este cantitatea de informatie necesara pentru a putea faca fata in sistemul financiar. Gestiunea informatiei este extrem de vitala in procesul de dezvoltare al companiei, iar monitorizarea ei nu este deloc un o activitate usoara. Filtrarea informatiilor dupa relevanta poate fi un proces foarte lent, care poate duce chiar la paralizarea intregii activitati.3. Analiza diagnostic BIAceasta analiza constituie o evaluare tehnica asupra componentelor majore ce intra in compozitia procesului de Business Intelligence din cadrul companiei. Va descrie practici, implementari si modul de evaluare a performantelor pe baza lor. In finalul analizei voi nota cateva remarci.3.1. Urmarirea defectelor

Urmarirea defectelor este un proces utilizat in software engineering pentru monitorizarea si gestionarea defectelor logate intr-un produs, de la aparitia acestora si pana la rezolvarea lor. Nevoia pentru un asemenea proces este cu atat mai evidenta intr-un proiect de mari dimensiuni la care lucreaza multiple echipe, cel mai probabil din locatii diferite. Utilizarea unui sistem dedicat de urmarire a defectelor este un aspect vital pentru orice organizatie.

3.1.1. DescriereCea mai importanta componenta a unui sistem de urmarire a defectelor este baza de date in care sunt salvate caracteristicile defectelor. Fiecare defect contine un reporter, persoana de contact pentru orice aspect al defectului, si un asignee care conduce investigatia si se angajeaza sa il rezolve. Caracteristicile cele mai importante sunt urmatoarele: Prioritatea

Asignee

Reporter

Versiunea afectata

Root cause ( Originea defectului)

Alte caracteristici includ data logarii defectului, descrierea defectului si pasii de replicare.In ciclul de viata al unui defect, acesta se poate afla in urmatoarele stari:

Unassigned Nu exista o persoana care sa investigheze defectul. Open Defectul are un asignee, dar inca nu s-a inceput investigatia. In Progress Defectul este in curs de rezolvare. Need Precision Sunt necesare mai multe informatii de la reporter. Resolved Marcheaza faptul ca a fost identificata o eroare in produsul software si a fost remediata. Closed Marcheaza faptul ca defectul nu este cauzat de o eroare de dezvoltare ci de configurare/utilizare incorecta.3.1.2. Scopul si metrici utilizateScopul urmarit prin acest tip de masurare este obtinerea unui numar redus al defectelor si minimizarea recurentelor aceluiasi defect in iteratiile urmatoare ale procesului de dezvoltare. Acest lucru se obtine prin extragerea de informatii din defectele anterioare si stabilirea unor metrici corecte. Astfel sunt introduse urmatoarele metrici de estimare a progresului curent :

Numarul total de defecte deschise.Reflecta stadiul curent in cadrul proiectului. O scadere in numarul total al defectelor indica apropierea fata scopul propus. Numarul defectelor de severitate ridicata ( High si Critical).Pentru a obtine o informatie viabila de imbunatatire a procesului, se analizeaza impreuna cu clasificarea defectelor pe echipele carora apartin; Front Office, Middle Office, Back Office, Accounting, Architecture. Astfel se pot izola zonele cu probleme ce pot ingreuna progresul proiectului. Numarul de defecte noi / redeschise si inchise in iteratia curenta.Cele doua atribute sunt plotate pe un grafic pentru a reflecta progresul curent. Cele doua linii plotate ar trebui sa convearga pentru a marca eliminarea defectelor. Pe baza graficul se poate identifica trendul curent; daca se observa o crestere continua iar liniile nu converg atunci exista o descoperire continua de buguri.

Fig. Raport defecte Root causeSe urmareste descoperirea unor factori alarmanti ce pot semnifica ineficienta sau lipsa de comunicare. Spre exemplu, un numar foarte mare de defecte ce au ca root cause Programming error poate semnifica faptul ca departamentul de dezvoltare sunt slab pregatite si ofera performante slabe. Reducerea greselilor de programare prin angajarea unor persoane calificate poate reduce numarul de defecte descoperite mai tarziu.3.2. Urmarirea rezultatelor din testare

Rezultatele obtinute in urma etapei de testare automata pot fi analizate pentru a obtine informatii valoroase. Valorile identificate in urma procesului pot servi la imbunatatirea rezultatelor viitoare prin identificarea punctelor slabe si repararea sau optimizarea lor.3.2.1. DescriereUn bun punct de pornire pentru evaluarea rezultatelor se refera la definirea unui set de date multidimensional, compus din posibilele configuratii pe care va fi testat produsul. Etapa de testare este una elaborata, astfel se vor efectua multiple runde de testare. Un exemplu de astfel de set de date poate fi vazut in figura de mai jos:

Fig.3. Configuratii de testareIn primele doua runde se efectueaza un test complet ce examineaza structura programului si deriva date de test din logica codului. Sunt analizate toate caile de decizie atat din cadrul modulelor cat si din integrarea multiplelor module sau subsisteme. In ultimele doua runde este redusa dimensiunea procesului de testare prin selectia anumitor pathuri din fluxul de decizie al programului. Pentru fiecare runda de testare se aloca dintr-un repository o suita de teste, fiecare suita fiind compusa dintr-un numar de cazuri de test.

Oricare din cele patru platforme de testare reprezinta cate o iteratie din cadrul unei runde. Rezultatele obtinute din fiecare iteratie sunt analizate pentru a determina diferentele de functionalitate intre diversele platforme. Aceste rezultate sunt de asemenea utilizate pentru a determina pragul de performanta atins pentru fiecare platforma, si stabilirea daca aceste valori sunt acceptabile.Pentru a obtine un set de date cat mai usor de analizat se vor efectua doua tipuri de testari dupa cum urmeaza: Regression testingAcest tip de testare urmareste detectarea defectelor noi sau recurente in functionalitatea existenta, ce ar putea sa apara datorita unor modificari precum fixuri sau imbunatatiri aduse functionalitatii. Scopul regression testing este de a asigura faptul ca posibilele modificari propagate nu au introdus noi defecte.

Defectele pot sa apara daca o modificare asupra unei parti din software afecteaza alte parti ale software-ului. O metoda comuna de testare include rularea unor teste completate anterior, iar pe baza rezultatelor se poate verifica daca comportamentul programului s-a modificat, sau daca au reaparut defecte rezolvate anterior. Performance testingEfectuarea testarii de performanta urmareste sa evalueze modul in care produsul se comporta din punct de vedere al stabilitatii si al timpului de raspuns. Cele doua caracteristici sunt verificate riguros, folosind diferite metode de testare si evaluate prin metrici specifice. Stabilitatea aplicatiei este verificata prin intermediul testelor de tip Load testing si Soak testing.Load testing reprezinta unul din cele mai simple teste de evaluare a performantei. Se efectueaza pentru a observa comportamentul aplicatiei in cazul unui load estimat. Acest lucru se realizeaza prin logarea concurenta a unui numar de utilizatori ce efectueaza anumite operatii critice si monitorizarea duratiilor si a utilizarii de memorie.Soak testing reprezinta un test de induranta prin care aplicatia este supusa unei incarcari mari pe o perioada extinsa de timp. In acest timp este monitorizata utilizarea memoriei pentru a detecta posibile leak-uri de memorie. Acest tip de test ajuta la identificarea degradarilor de performanta prin compararea timpilor de raspuns obtinuti de-alungul rularii cu timpii obtinuti la inceputul testului.

3.2.2. Scopul si metrici utilizateScopul este de a verifica constant calitatea produsului pentru a putea stabili daca este pregatit pentru release. Pentru implinirea scopului, fiecare tip de testare efectuata este evaluata folosind un set de metrici, iar pe baza rezulatelor se determina daca criteriile de release sunt indeplinite.Criteriile principale ce trebuiesc satisfacute pentru a putea considera produsul gata pentru release sunt : Validarea tuturor functionalitatilor

Trecerea tuturor testelor din Regression testing

Finalizarea testelor de performanta si obtinerea unor rezultate acceptabileIn plan secundar, urmatoarele criterii considerate sunt fie independente de etapa de testare, fie pot fi validate aplicand o marja mai larga de erori Inchiderea tuturor defectelor de prioritate High si Critical

Disponibilitatea documentatiei

Pentru alinierea cu obiectivul principal este nevoie de un rezultat palpabil, vizual cu care se poate valida stadiul actual. Astfel, la nivelul cel mai inalt se defineste urmatoare metrica, dependenta de rezultatele intermediare, ce indeplineste obiectivul:

Progresul estimat / Progresul curentEste modelat printr-un grafic ce contine setul de valori aferent celor doua atribute. O tendinta de convergenta intre cele doua linii indica apropierea fata de scopul propus.

Fig. Raport progres estimat / curentSuccesul testarii de tip Regression este stabilit pe baza urmatoarelor metrici: Numarul total de scripturi de testare

Numarul de scripturi de test trecute

Numarul de scripturi de test picate

Un test picat semnifica existenta unei probleme in aplicatie pentru care s-a creat un defect pentru urmarire. Numarul de scripturi de test neterminateUn test neterminat semnifica faptul ca nu a reusit sa fie executat datorita problemelor legate de platforma/fisiere externe/utilitare de tip 3rd party.

Fig. Regression testing

Pentru performance testing este nevoie de un pas suplimentar, si anume crearea unor KPI (key performance indicator). Stabilirea acestor KPI formeaza ajuta la definirea unei baze fata de care se compara si valideaza rezultatele testelor de performanta.

Fiecare KPI

Este identificat prin :

Un scenariu/functionalitate/caz de business de testat

Cazuri de test asociate cu scenariul

Un target pentru fiecare caz de test sau pentru intreg scenariul

Este modelat dupa caracteristicile:

S.M.A.R.T : Specific, Measurable, Achievable, Relevant, Time bounded

Trebuie definit ca cerinta in JIRA

Trebuie sa fie definit pentru o platforma specifica

Trebuie sa contina cazuri de test cat mai detaliate, pentru a evita aparitia discrepantelor intre cerinte si implementare

Un exemplu concret de definire a unui KPI arata astfel :

Caz de business

BC1: Performanta server de procesare real time RTF

Cazuri de test

BC1-TC1: 1 utilizator: 10 cereri de calcul consecutiveBC1-TC2: 1 utilizator: 20 cereri de calcul consecutive

BC1-TC3: 2 utilizatori: 20 cereri de calcul consecutiveBC1-TC4: 5 utilizatori: 20 cereri de calcul consecutive

Target

Timp de rulare cel putin la fel de bun ca in versiunea anterioaraO data ce baza testelor de performanta este construita, atentia se indreapta asupra metricilor de evaluare a rezultatelor dupa cum urmeaza: Delta timp rulareIndicator de performanta pentru a stabili timpul de raspuns a versiunii curente comparativ cu versiunea anterioara. Este necesar de fiecare data cand sunt aduse modificari la nivelul arhitecturii de la o versiune la alta. Dimensiunea setului de dateClasifica timpul de raspuns al operatiilor critice in functie de marimea setului de date utilizat.

Timpul total de rulare

Masura de comparatie a aplicatiilor intre versiuni si platforme diferite.3.3. Urmarirea integrarii continueIntegrarea continua in domeniul software engineering implementeaza continuu procese de aplicare a controlului calitatii, realizate frecvent. Scopul integrarii continue este de a imbunatati calitatea produsului software si de a reduce timpul necesar livrarii acestuia.3.3.1. Descriere

Componenta principala intr-un proces de integrare continua o reprezinta compilarea periodica si construirea unui branch al proiectului. Procesul este in stransa legatura cu restul componentelor de BI precum testarea continua si sistemul de versionare. Exista numeroase practici ce implementeaza integrarea continua, fiecare dintre acestea fiind modelata dupa nevoile companiei.Datorita numarului mare de dezvoltatori din cadrul companiei, in fiecare zi exista zeci sau chiar sute de copii a codului de baza. Fiecare dezvoltator aduce modificari codului de baza intr-o copie locala si personala. Atunci cand functionalitatea a fost modificata, se va efectua un commit al codului schimbat in repository central, pe baza caruia s-a efectuat copia initiala. Astfel, exista un numar mare de tranzactii efectuate in fiecare zi.Un proiect de dimensiuni foarte mari necesita o durata de timp indelungata pentru a compila, datorita modulelor dependente. Durata de compilare a codului si numarul de tranzactii frecvente au generat urmatoarea abordare de integrare: Nightly builds

Reprezinta compilarea codului sursa in mod automat, o data pe zi. Este programat sa ruleze in afara orelor de lucru, deoarece este mai putin probabil sa existe modificari ale codului sursa in timpul compilarii. Este utilizata o masina neutra pentru compilare, care nu este folosita de catre niciun dezvoltator.Rezultatele build-ului sunt verificate de catre echipa de integrare urmatoarea zi. Prioritatea acestora este de a asigura ca procesul de compilare nu a fost stricat de catre modificarile efectuate (break the build). Exista de altfel posibilitatea ca build-ul sa fie stricat datorita update-urilor de sistem ce au afectat utilitarele necesare compilarii. In cazul in care commit-ul efectuat de catre un dezvoltator a generat un build break, atunci este datoria acestuia de a investiga problema imediat ce a fost notificat. Freeze levelsDaca dupa un break de build nu se reuseste rezolvarea problemelor de catre dezvoltatorii in cauza se recurge la setarea unui nivel de inghetare a codului. In functie de numarul erorilor se poate seta unul din cele cinci niveluri. Freeze level 5 este cel mai critic, nu permite niciun nou commit in codul sursa indiferent de nivelul ierarhic al dezvoltatorului. Pentru restul nivelurilor exista un numar limitat de persoane ce pot inca modifica codul sursa, iar in anumite cazuri se poate obtine un freeze bypass pentru a putea efectua un commit.3.3.2. Scopul si metrici utilizateUrmarirea rezultatelor obtinute in urma compilarilor are ca scop obtinerea de informatii cu privinta la complexitatea proiectului si nivelul de maturitate al acestuia. Se doreste de altfel obtinerea unui proces cat mai rapid si direct in cadrul livrarii finale.Obiectivul imediat al acestei evaluari este identificarea cauzelor comune pentru compilarile esuate si estimarea pierderilor pe durata perioadei de mentenanta. Prin urmare sunt necesare urmatoarele metrici :

Starea build-uluiPentru fiecare platforma este indicat daca ultima incercare de compilare a fost realizata cu succes sau a esuat. Dezvoltatorii care au generat erorileDaca un numar mare de erori provine din cadrul unei anumite echipe poate insemna faptul ca este nevoie de o restructurare a codului.

Numarul de compilari pe ziReprezinta numarul total de incercari de reparare a build-ului. Un numar foarte ridicat poate indica o performanta slaba sau o neintelegere a cerintelor. Timpul necesar reparariiDurata totala de timp de la stricarea build-ului si pana la obtinerea unui build finalizat cu succes. Factor pentru estimarea costului de mentenanta.3.4. Urmarirea sistemului de versionareSistemele de versionare sunt utilizate in software engineering pentru a urmari si a obtine control asupra modificarilor aduse codului sursa. De-alungul ciclului de viata al dezvoltarii software, este normal sa existe multiple versiuni ale produsului in locatii diferite, si in echipe de dezvoltare diferite. Un sistem de versionare este necesar datorita nevoii de testare a produsului software pe versiuni diferite, cu scopul de a localiza si rezolva defecte. 3.4.1. Descriere

Componenta ce sta la baza unui sistem de versionare este depozitul central. Acesta functioneaza dupa o relatie de tip client-server. Depozitul central poate fi accesat intr-un singur loc, de catre mai multi clienti simultan. Toate modificarile si actiunile efectuat in cadrul sistemului trebuie sa treaca prin acest depozit.Toate fisierele trecute prin depozitul central sunt inregistrate, iar astfel se pot vizualiza modificarile efectuate de catre alti dezvoltatori, se poate reveni la o versiune anterioara a fiserului si se pot corecta greseli. Fiecare actiune asupra unui fisier va genera un timestamp, ce marcheaza data si ora la care a fost efectuata, si persoana responsabila. Acest lucru va permite in anumite situatii tragerea la raspundere si nerepudierea.Principiul de functionare este relativ simplu; fiecare dezvoltator isi creaza un spatiu de lucru bazat pe versiunea dorita si apoi il populeaza cu fisierele de interes. Modificarile fisierelor nu se vor reflecta automat in depozitul central deoarece acestea nu reprezinta decat o copie. Pentru a fi incluse in codul sursa din depozit este nevoie de efectuarea unei tranzactii numite commit.Fiecare tranzactie efectuata contine urmatoarele informatii:

Data si ora

Numar unic al tranzactiei

Nume dezvoltator Nume fisere modificate

Pentru fiecare fisier, numarul reviziei

ID defect asociat (daca este cazul)

In cazul in care doi sau mai multi dezvoltatori au efectuat modificari asupra aceluiasi fisier, atunci se poate ajunge la un conflict in momentul in care se face commit. Acest conflict poate fi rezolvat fie prin retragerea modificarilor de catre un dezvoltator, fie prin unirea celor doua versiuni a fisierului. De cele mai multe ori unirea se efectueaza automat de catre sistemul de versionare. Daca nu s-a reusit, atunci dezvoltatorul care a facut commit ultimul va trebui sa rezolve suprapunerea manual.3.4.2. Scopul si metrici utilizateScopul acestei masurari este de a optimiza efortul de lucru prin reducerea la minim a greselilor si a neintelegerilor cerintelor. Rezultatele obtinute sunt vitale in descoperirea greselilor cele mai comune, si in analiza performantelor dezvoltatorilor.Metrici relevante pentru aceasta analiza sunt urmatoarele: Numarul total de tranzactiiPrezinta un sumar despre activitatea dezvoltatorilor, in general fiecare tranzactie semnifica fie rezolvarea unui defect, fie adaugarea unei noi functionalitati.

Numarul fisierelor modificate per tranzactieUrmarirea acestei valori poate oferi informatii utile despre structura proiectului. Se poate forma o idee de ansamblu asupra dependintelor dintre modulele produsului software. Acest lucru este important deoarece poate indica un design ineficient din punct de vedere logic al structurii codului. Numarul de linii de cod modificate per tranzactieNumarul de linii de cod poate indica in general cantitatea de efort necesara pentru a efectua o modificare. Daca o functionalitate simpla a cerut o cantitate mare de efort, atunci acest lucru indica o structura slaba a codului sau a mediului de dezvoltare. In caz contrar, daca o functionalitate complexa a cerut un efort minim, poate indica faptul ca problema nu a fost rezolvata de la radacina, ci doar solutionata temporar.3.5. Diagnostic

Analiza tehnica a elementelor majore de Business Intelligence a ajutat la formarea unor precizari cu privire la aspectele mai importante sau interesante ale procesului, si la alcatuirea unor recomandari. Misys are la dispozitia sa o suita de instrumente avansate de analiza, care formeaza bazele unui framework matur de dezvoltare. Fiecare etapa din procesul de dezvoltare este documentata si audiata pentru a asista echipa de management in evaluarea si implementarea deciziilor. Un aspect foarte important este considerat de catre diferitele nivele de procesare a datelor colectate, si transformarea acestora in atribute actionabile precum metrici de evaluare. Fiecare nivel are un impact asupra celui imediat urmator. Se recomanda definirea unor metrici mai relevante la activitatea desfasurata. Metrici bune sunt definite pentru a se alinia la golurile companiei si trebuie sa reflecte acest lucru. Pentru alegerea unor metrici este necesara prezenta unui specialist in echipa. Acestea trebuie sa fie strategice, operationale sau tactice. Spre exemplu, evaluarea performantelor unui dezvoltator pe baza liniilor de cod scrise nu este o metrica foarte buna, sau este cel putin incompleta. Automatizarea activitatilor pe cat posibil va reduce cantitatea de timp necesara completarii lor, si cel mai important, minimizeaza interventia constanta a omului. Pentru a obtine un nivel de automatizare mai ridicat in cadrul unor etape ce impun o sarcina repetitiva sau predictiva, se pot folosi aplicatii dedicate. Acest lucru implica desigur costuri suplimentare, deci trebuie gasita o solutie cat mai profitabila, fie prin utilizarea resurselor umane pentru aceste activitati, fie cumpararea unor licente comerciale.4. Analiza diagnostic CIProcesul de Competitive Intelligence este mult mai abstract si se bazeaza pe monitorizarea apropiata a pietei si a competitorilor. Se poate spune ca CI se bazeaza pe cunoastere, astfel este greu de cuantificat si masurat sub aceeasi evaluare aplicata in cadrul BI. Pentru aceasta analiza diagnostic voi alege o evaluare mai mult economico-manageriala pe baza careia voi oferi niste recomandari.4.1. Analiza SWOTPrimul pas pentru a evalua practica curenta de Competitive Intelligence este cautarea factorilor care stabilesc un avantaj asupra celorlalti competitori. Pentru aceasta analiza voi parcurge doua etape ce vor analiza pe rand mediul intern, respectiv cel extern. In prima etapa voi evalua performantele firmei sub forma unor puncte tari si slabe, prin masurarea potentialului intern si material. In cea de a doua etapa, voi identifica oportunitatile si amenintarile de mediu ce pot influenta activitatea firmei.2011201220132014

BILANT

ACTIVE IMOBILIZATE1,938,5471,548,8462,607,2597,767,701

ACTIVE CIRCULANTE10,071,76819,346,88822,020,52219,174,474

Stocuri0000

Creante9,712,08519,068,36220,177,14818,171,074

Casa si conturi359,683278,5261,843,3741,003,400

CAPITALURI PROPRII8,476,42917,638,61310,578,2088,229,513

Capital Social200200200200

DATORII3,533,8863,656,11213,050,63718,003,612

CONT PROF SI PIERD

Cifra de afaceri43,527,45256,008,21549,427,27159,303,896

Venituri totale45,585,55659,365,56853,600,84160,636,553

Cheltuieli totale35,459,90738,237,51042,601,23762,985,248

Profit/Pierdere Brut10,125,64921,128,05810,999,604-2,348,695

Profit/Pierdere Net8,463,16617,625,3509,239,595-2,348,695

Tabel 1. Bilant si cont de profit si pierderi Misys Romania4.1.1. Puncte tari Experienta in domeniu si un business diversificatMisys a fost fondata in anul 1979 ca si furnizor de sisteme informatice catre brokeri de asigurare din Londra. De-alungul anilor a cumparat numeroase firme si solutii software bancare si a devenit un lider global in serviciile financiare. Misys ofera solutii de banking, lending, treasury, capital markets, investment management si enterprise risk. In prezent Misys are mai mult de 2,000 de clienti in peste 130 de tari.

Baza de clienti de top

Solutiile Misys sunt utilizate de catre numeroase institutii financiare globale ce sunt lideri pe sectorul lor. Printre acestea se numara nu mai putin de 8 din primele 10 banci din lume, precum Banca Chinei, Banca Nationala a Australiei si ING. Prezenta mare in sectorul TCM (Treasury and Capital Markets)Misys are o acoperire mare in sectorul TCM prin produsele FusionCapital precum Global Components, Kondor, Opics, Summit si Sophis. Atunci cand Misys a cumparat Sophis cererea in sectorul TCM a crescut cu 50%, iar Misys a devenit lider cu aproximativ o treime din piata. Forta de munca (Misys Romania)Misys pune importanta pe valorile companiei, iar acest lucru se reflecta in cadrul angajatilor. Criteriile de selectionare sunt destul de mari, si nu doar din punct de vedere tehnic, ci si al calitatilor soft. Astfel se poate implica faptul ca forta de munca este alcatuita din oameni calificati si cu ambitie personala ce ajuta la indeplinirea obiectivelor comune. In ultimii ani a crescut numarul de angajati, ajungand la aproximativ 430 de angajati in prezent. Indicatori de profitabilitate (Misys Romania)Cifra de afaceri curenta este mai mare decat media sectorului de activitate, iar rata de crestere se incadreaza in cea a industriei. Indicatori de solvabilitate (Misys Romania)Gradul de acoperire a dobanzii este mai mare decat media industriei. Profitul din activitatea curenta a firmei acopera foarte bine dobanzile la imprumuturi, iar firma are suficiente resurse financiare pentru rambursarea datoriilor.Gradul total de indatorare este egal comparativ cu media industriei. Firma are capitaluri proprii care permit mentinerea unui echilibru financiar.4.1.2. Puncte slabe

CompetitiaCand vine vorba de dezvoltarea software-ului la comanda (orientat pe client), competitia este foarte mare, inclusiv in sectorul financiar. Cresterea utilizarii canalelor digitale in randul consumatorilor alaturi de schimbarea frecventa a cerintelor, a dus la o crestere a asteptarilor din partea clientilor privind calitatea serviciilor. Indicatori de profitabilitate (Misys Romania)Marja profitului net a simtit o scadere semnificativa in ultimii ani, ajungand chiar pe pierdere. Acest lucru poate indica o competivitate scazuta. Indicatori de solvabilitate (Misys Romania)Gradul de acoperire a datoriilor este semnificativ mai mic decat cel al industriei. Profitul din activitatea curenta a firmei acopera intr-o masura mica datoriile totale. Indicatori de lichiditate (Misys Romania)Activele circulante ale firmei nu acopera plata datoriilor pe termen scurt. Rata curenta indica faptul ca firma a acumulat prea multe datorii. Lichiditatile firmei clienti, conturi curente, casa, sunt la un nivel scazut si pot indica probleme de lichiditate pe termen scurt.4.1.3. Oportunitati Fidelitatea clientilorIn cadrul produselor software orientate pe client, feedbackul este foarte important. Colaborarea stransa cu clientul in perioada de dezvoltare va rezulta intr-o relatie de incredere mai stransa cu acesta. Prin stabilirea unei relatii de incredere se poate asigura o baza de clienti fideli, care poate mai departe sa deschida noi porti de dezvoltare a firmei prin colaborare continua sau recomandare. Extinderea serviciilor

Piata economica poate evolua in mod favorabil ducand astfel la descoperirea unor posibili clienti ce ar beneficia de serviciile Misys. Exista de altfel tari inca in dezvoltare, care odata ajunse intr-un punct stabil economic cu o industrie dezvoltata, pot apela la servicii financiare. Achizitii noiIstoria companiei arata un numar de achizitii de companii, cea mai recenta fiind CCS (Custom Credit Systems). Combinatia dintre CCS si Misys a rezultat in cea mai cuprinzatoare solutie de imprumuturi comerciale global. Viitoare achizitii pot prezenta noi oportunitati de dezvoltare.4.1.4. Amenintari

Reguli impuse de guvernGuvernul poate aplica legi noi din diverse motive, precum planificarea economiei, remedierea unui declin in market sau pentru beneficiile unor parti politice. Sectorul financiar este intr-o schimbare constanta, fiind o tinta pentru reglementari frecvente. Datorii suveraneO alta cauza de amenintare poate fi cauzata de o criza cauza de inabilitatea unei tari de a-si plati datoriile publice. Acest lucru se poate intampla in cazul in care o tara ajunge la un nivel de indatorare foarte ridicat si sufera de o dezvoltare economica lenta. Spre exemplu, criza Europeana recenta de indatorare are inca consecinte in sectorul bancar. Numeroase banci Europene au acumulat sume de bani mari de datorii suverane, unele din acestea intrand chiar in insolventa sau in faliment.

4.2. Analiza Cele Cinci Forte a lui PorterIn aceasta etapa voi efectua o analiza a industriei de activitate pentru a observa cat de profitabila este pozitia curenta a companiei si pentru a determina gradul de competivitate. In cadrul acestei analize ma voi uita la cele cinci forte ce au impact asupra competivitatii trei forte de competivitate pe orizontala: produse substitut, potentiali concurenti, intensitatea rivalitatii si doua forte de competivitate pe verticala: puterea de influenta a furnizorilor si puterea de influenta a clientilor.4.2.1. Amenintarea adusa de noi competitoriGradul de amenintare a potentialilor concurenti este indicat de catre nivelul de dificultate de a intra in industrie. Pentru fiecare industrie exista un set de bariere, iar cu cat acestea sunt mai joase cu atat mai mare este amenintarea cauzata de noi competitori. Identificarea brandului

In industria software, identitatea brandului nu are un impact foarte puternic asupra alegerii deciziei unor potentiali clienti. Acest lucru se datoreaza faptului ca produsele si serviciile din acest sector sunt orientate pe client, astfel cerintele clientilor nu se modifica o data cu renumele brandului. Astfel, bariera de intrare pentru noi competitori din acest punct de vedere este joasa. Capital de investitiiNecesitatea unui capital de investitii initial este relativ mica in cadrul industriei software deoarece activitatea in acest domeniu este bazata pe proprietate intelectuala. In anumite situatii poate fi nevoie de un capital consistent pentru departamentele de marketing si research and development, in cazul in care singura modalitate de a intra pe piata este la o scara larga. Sectorul financiarDesi industria software prezinta un risc mare pentru noi competitori, in sectorul financiar aceasta probabilitate este mai redusa din diverse motive: reglementarile existente care pot afecta business-ul, cerintele clientilor exista de obicei o relatie de incredere deja stabilita cu companiile deja stabilite pe piata.FactoriImpact puternicImpact mediuImpact slab

Identificarea branduluiX

Capitalul de investitiiX

Sectorul financiarX

Tabel 2. Amenintarea de noi competitori

4.2.2. Intensitatea competitiei Numarul de competitoriMisys furnizeaza un portofoliu divers de servicii, astfel voi imparti companiile rivale in functie de subsectiunea de activitate pe care se axeaza. Voi selecta companii aflate in top 100 realizat de catre FinTech Rankings : Activitate bancara: FIS, Fiserv, SunGard, Jack Henry & Associates, Tata Consultancy Services Limited (TCS), Temenos Investitii: TCS, Cognizant Technology Solutions, DST Systems, Syntel

Procesari de tranzactii si plati: FIS, Fiserv, NCR Corporation, Total Systems Services (TSYS)

Risk: FIS, SAS Institute, Equifax, CoreLogic, D+H, SunGard TCM: Murex, Nucleus Software, TAS Group Cel mai apropiat competitor, cu o acoperire in majoritatea sectoarelor de activitate este FIS, amplasat momentan pe locul 1 in topul companiilor de software financiar efectuat de catre FinTech Rankings. FIS este inregistrat pe locul 426 in lista de Fortune 500, si isi furnizeaza serviciile catre 14,000 institutii in peste 110 tari. Acest lucru semnifica faptul ca proiectele sunt impartite intre companii, iar profitul este si el impartit. Rata de crestere a industriei

Industria software si a tehnologiilor IT a vazut o crestere constanta in ultimii ani. In Romania aceasta crestere a fost de 13%, aducand venituri de 2,42 miliarde de euro conform studiului Romanian Software and IT Services Industry realizat de catre Pierre Audoin Consultants. Aceasta rata de crestere este de cinci ori mai mare decat economia Romaniei. Nivelul de diferentiere

Produsele si serviciile software financiare nu ofera mare grad de diferentiere, astfel rivalitatea este ridicata. De altfe, companiile furnizeaza acelasi suport catre clienti, incluzand manual de utilizare si instalare si training.

Bariere de iesire

Costurile pentru a iesit din industria software sunt relativ scazute deoarece, in majoritatea cazurilor, cerintele capitalului initial sunt joase.FactoriImpact puternicImpact mediuImpact slab

Numarul de competitoriX

Rata crestere industrieX

Nivelul de diferentiereX

Bariere de iesireX

Tabel 3. Intensitatea competitiei4.2.3. Puterea de influenta a furnizorilorFurnizorii de internet, servere, statii de stocare, echipamente de birou si alte tehnologii nu detin o putere de influenta prea mare deoarece exista o sursa vasta de astfel de furnizori ce servesc industria software si IT.4.2.4. Puterea de influenta a clientilor Schimbarea produsului de catre clientIn aceasta industrie, clientii prefera in cele mai multe cazuri un produs personalizat dupa propriile cerinte. Astfel se implica o garantie de timp de durata mai lunga asupra utilizarii produsului. Prin urmare riscul ca un client sa schimbe produsul este scazut, deci costurile sunt mici. Numarul de clientiIn cazul in care exista putini clienti, deci cererea este mica iar oferta este mare, atunci puterea de influenta a clientului este mare. Cum clientii apeleaza la un produs software modificat dupa propriile nevoi, oferta va fi mica deoarece va implica o relatie one time purchase intre client si companie.4.2.5. Produse substitut Produse software piratateAcest lucru implica furtul produsului sub copyright fara aducerea la cunostinta a producatorului sau fara permisiunea acestuia. In cazul software-ului financiar acest risc este mic.4.3. DiagnosticPe baza evaluarii de mai sus, se pot remarca cateva aspecte importante in practica curenta de Competitive Intelligence.

Comparativ cu principalii sai competitori din sectorul software financiar, Misys detine o retea de business mai diversificata. A reusit sa identifice oportunitati in cadrul pietei si sa ocupe un segment de piata nisat. Treptat, compania s-a dezvoltat si a ajuns sa acopere o parte uriasa din aceasta industrie fragmentata, lucru care dovedeste experienta cumulata si gradul de cercetare atenta a pietei. Firma colaboreaza direct cu institutii financiare de top, ceea ce dovedeste o calitate buna a produselor si serviciilor furnizate. Astfel se valideaza calitatile departamentelor de Marketing si Research and Development. Situatia financiara raportata de Misys Romania la finalul anului 2014 poate indica anumite motive de ingrijorare. Aceasta poate fi o urmare a restructurarii firmei, pierderea unor proiecte / clienti sau o urmare a unor decizii nefavorabile de management.

Pentru a isi imbunatati pozitia competitiva sau pentru a ramane in cursa, Misys va trebui sa arate un bun management strategic si o gandire analitica. Industria de activitate este foarte susceptibila la schimbari, astfel trebuie sa fie la curent cu miscarile competitorilor la fiecare pas. Misys va trebui, ca si pana acum, sa inteleaga miscarea pe piata, si sa prezica anumite tendinte pentru a putea crea noi oportunitati. Acest lucru poate fi obtinut fie angajand o echipa calificata de analisti din exteriorul companiei, fie folosind resursele proprii. Trebuie avut in vedere si costul necesar in ambele situatii, si luarea unei decizi care sa beneficieze golurile companiei.BibliographyThe Bibliography title is written in B_Bibliography title, Calibri 12 pct, all caps, expanded spacing with 2 pt, centered.

References are numbered according to the order of their appearance in text. Text references are indicated by the number of the title between square brackets, such as [2].

Each bibliographic entry should mention: initial of the first name, family name, title, publishing house, place and year or periodical title, volume, number, year, initial and final pages. Authors names are written in italics (10 pct).

For Romanian books and articles a translation of the title will be inserted in parentheses.

[1] C. Soviany, Embedding Data and Task Parallelism in Image Processing Applications, PhD Thesis, Technische Universiteit Delft, 2003

[2] A. Mauthe, D. Hutchison, G. Coulson and S. Namuye, Multimedia Group Communications Towards New Services, in Distributed Systems Eng., vol. 3, no. 3, Sept. 1996, pp. 197-210

[3] V. I. Arnold, Metodele matematice ale mecanicii clasice (Mathematical models of classic mechanics), Editura tiinific i Enciclopedic, Bucureti, 1980[4] *** COSMOS/M Finite Element System, User Guide, 1995.