Monday, November 9, 2009

Factors influencing Banking Software Implementation Model (Big Bang/ Phase Wise Implementation)

As a Business Analyst/Testing Consultant who has worked for several Implementations, I often receive queries from my clients asking which is the best Software Implementation Technique available. Is it Big Bang or Phased Implementation. As far as Software Implementation and testing are concerned it is a very risky area of Software Development. Because there are so many internal and external risk factors involved in it.

Software Implementation or Software Adoption deals with the transfer (conversion) between an old system to a target system in an organization. So if a Bank/company works with an old software system, it may want to use a new system which is more efficient, has more work capacity etc. So then a new system needs to be adopted, where after it can be used.

There are several types of adoption that can be used to implement a system. The types ‘big bang’, ‘parallel adoption’ and ‘phased adoption’ form the main types that are used to adopt a system. The big bang relates to the cosmological theory (Big bang) where the start of the cosmos happened at one moment in time. This is also the case with the big bang adoption type where the new system is adopted on one date. In case of parallel adoption the old and the new system are running parallel so all the users can get used to the new system, but still can do their work using the old system. Phased adoption means that the adoption will happen in several phases, so after each phase the system is a little closer to be fully adopted by the organization.

When it comes to the world's most complex Software Implementations like Core Banking Software Implementation which has been linked to several upstream and downstream interfaces, it is really critical to do a meticulous planning from all the sides like stakeholders, developers, testers and other consultants. The other aspect to be considered here is, whether it is a New Implementation or it is a Replacement of a legacy system. If it is going to be new implementation everything will be from the scratch having a base model of the application. But if it is going to be the replacement there are several important aspects to be considered like Gap Analysis for the legacy and replacement system, right from mapping of appropriate fields from the legacy to replaced system, and Data Migration from legacy to replacement, accounting, Local and Global Compliance Reporting and the Replacement System's Integrity with the various existing interfaces has to be analysed in breadth and depth.

The other critical area to be concentrated is whether the implementation has to be done in a single country along with all the branches or it is for multiple countries. I prefer go in for big bang implementation, if it is done in a single country only. If the Implementation has to be done in several countries it has to be done phase-wise as the base model of a country can be re-modified to an other country's country specific requirement and the best practiced approach learning in one country can also be used for another country.

The adoption type or software implementation type has to be defined in front of the adoption phase and will be chosen based on the goals to be achieved and on the type of system to be implemented. The three types of adoption, Big Bang, parallel adoption and phased adoption, are ranging from an instant switch to a strategy where users progressively start using the new system over a certain period of time (can be weeks, months or even years).

The actual selection is done by prioritizing the goals to be achieved and then matching a strategy against it (Eason, 1988). Eason defines the following goals:

Possible existence of needed “critical mass” to make the system work.
If a large critical mass is needed for the system to work a big bang strategy might seem the answer. (Rogers, 1995)

Need for risk control, if risk is involved.
Minimizing risk to operation of the organization is key. Parallel and phased introduction might control this risk.

Need for facilitation of the change.
The organization has to be ready for the changeover. Socio-technical preparations such as training sessions and ready-made scenarios must be clear.

Pace of change over
The speed of in which the organization is changing over to the new system.

Local design needs
The system might be adjusted to the users needs. In this the chosen strategy must provide the opportunity to do so.

The actual selection of adoption type depends on far more factors then these goals, but they create a window to choose one of the types. Other criteria are called variables (Gallivan, 1996). Gallivan suggests that the appropriate adoption types depends on:

Innovativeness of the individuals
Attributes of the ones that are to adopt the innovation/system

The type of innovation
Is it a process or product innovation?

Attributes of the innovation itself
Preparedness, communicability and divisibility

The implementation complexity.
How complex is the implementation or what is its extent?

These variables are of a higher level then the criteria of Eason and should be handled as such. Based on table 1 and on the mentioned higher level variables by Gallivan, one can make a selection of an appropriate strategy to choose.

Prepare an organization for adoption or change management:
In order to prepare the organization for the adoption of the new system, the changes that will take place need to be determined. This is necessary to be able to have a plan or an overview of the changeover, and can be done by creating requirements for the system. Once the management has determined the requirements in a report of determined changes, they need to agree upon them to be able to move on with the change-process. If there is no agreement, the management needs to discuss the requirements again and again until they do agree. If agreement is achieved and the agreement contract is signed, the organization can take further steps. So now the test-phase can be prepared, in which the validity of the data that will be used will be checked and in which trials will be held (Eason, 1988).

Even though both the implementation techniques are unique and best in a way it depends on the goals and structure of the Bank/Company which is involved in the Implementation. In a nutshell if the Bank/Company is large with huge number of branches, wants to minimise the risk and has to be implemented in several countries Phased Implementation is the best suited one and if the Bank/Company is small with less branches and it is working only in a single country big bang or parallel execution is the best suited method.

Note: The views expressed in this blog are my personal views and a collection of references from the books listed below. These views does not reflects any other aspect of Software Implementation.

References:
Eason, K. (1988) Information technology and organizational change, New York: Taylor and Francis
Gallivan, M.J., (1996) Strategies for implementing new software processes: An evaluation of a contingency framework, SIGCPR/SIGMIS ’96, Denver Colorado
Rogers, E.M. (1995), Diffusion of innovations, New York: Free Press

Oracle Flexcube Vs. Temenos T24 Core Banking Solution - Analyst Perspective

As Business Analyst/Test Consultant I have been working with my clients in various critical Core Banking Project Implementations. Where ever I travel the usual question posted to me from my clients in the process of selection or by the companies trying partner with Oracle Flexcube/T24 is, Which is the better product?.

It is difficult to decide or tell which is the best product unless you go through with your RFP. Both have their advantages and disadvantages. Both companies work differently. My advice also varies on the company/bank which is asking. In general I will summarise my differences as below,

As a Product....

1. Both are functionally rich
2. Oracle Flexcube has ability to define accounting events. T24 rather rigid in that.
3. T24 has ability to add local developments/ products without any dependency on the vendor, which is very HUGE advantage in the ever changing requirement. Oracle is rather rigid and you are at Oracle Flexcube's door step for every enhancement. (if you are a company and looking at services and implementation independent of the vendor then T24 is the way you need to go!!).
4. Flexcube is on oracle. earlier to t24 (known as Globus), the database wasjbase/universe. Currently there are oracle and db2 version. t24 is database independent. (Please note that t24 is yet to prove in Oracle and db2, with their latest release-{read as R7}, but Temenos has more experience with Oracle )

As a company,
1. From the consultants experience - Temenos seems to be more structured than Oracle Flexcube. Product release are more controlled and scheduled with temenos. One functionality done for a bank is defiantly available for other clients whereas Oracle Flexcube seems to have client specific versions.
2. Implementation from Oracle Flexcube seem to finish around an year, temenos manages to finish around 2years for a mid size bank (Temenos do have implementations which completed in 6 months). Temenos are trying to finish their implementation with in reasonable time with the help of the Model bank (this from my general experience and please come and challenge me !!).
3. for consultants - Working in iflex projects are very taxing and badlyplanned(they always plan 3 people work with one consultant), but they finish because of the sacrifices of the consultants. Temenos projects are generally well planned but get's generally delayed because of having a bunch of wrong consultants. t24 product can be implemented in 'n' number of ways and its success depends on having the right knowledgeable consultants.

In summary both products are good. Both have their own can of worms. From IT and functinal perspective t24 can scale up to the business requirements fast, but t24 is yet to prove with their latest offering from the technology front and performance front.

Temenos aim to make their money from the initial licence fee, plus an additional percentage (usually 21%) for annual maintenance.

Oracle Flexcube target ILF, but also additional services revenues post implementation. Banks who prefer to take ownership of their systems favour Temenos; those who prefer to outsource IT favour Oracle Flexcube.

Functionality wise flexcube has a bit more advantage the T24 since all the major interfaces are packaged with product as a plug and play for example RTGS.But in T24 it comes as seperate interfaces. But the work culture in iflex implementation is very much taxing for consultants.

The big difference between the two companies is Temenos is "product" focused, while Oracle Flexcube is a "services" focused company.

Note: These are purely my personal views based on my work experience and knowledge of application implementation and does not reflect either Oracle Flexcube or Temenos T24 views in anyway.

Friday, November 6, 2009

Sub-prime crises - Lessons to be learnt

How Canada, Australia and India is not affected in the Sub-Prime Crises- Lessons to be learnt and the Current Solution to be taken:
Sub-prime crises, a shocking word not only to a financial world but to anyone throughout the world. Almost every part of the world is throughly shaken up by the Sub-prime Crises. But there are countries which remained unaffected by the crisis. There are certain lessons which has to be learnt from those countries.
First we can take the case of Canada. The canadian banks are able to manage and are able to effectively come out from the crisis. The reasons behind their success is:
1.Canada has a very different Mortgage Market Structure. All high-to-value loans has to be typically insured with a government agency or an agency with a government guarantee. This has cushioned the Canadian Banks and most of the loan loss are insured and the associated credit risk is mitigated.
2.On the capital side the quality of tier one capital is concenterated well and 75% of the tier one capital has to be in common shares, targets were set for 7% of tier one capital and 10% of total capital and most of the banks were well above it.
3. The Canadian Banking Supervisory authority OSFI's (Office of Superintendent of Financial Investigation) supervision model was unique compared to other Banking Supervisors and it focussed more solvency, meaning first to understand the financial condition of the bank and then to deal expeditously deal with the problems. Some of the regulators outsource onsite audits, but OSFI's (Office of Superintendent of Financial Investigation) directly employs 500 people for this.

OSFI's (Office of Superintendent of Financial Investigation) is considering to include a risk professional in the Board of Directors as there is no one in the top management who is well aware of the risk the organisation is prone to. This will be a very important step, because throughout the world the Management Board of the financial institutions will comprise a set of people who are in the industry for a long time and definitely they will not be a risk management professional.

The other important reason for the Financial Crisis is still the most of the banks in US are not fully compliant with the Basel II and most of the Canadian Banks had implemented it and they have better data to assess the risk involved. Gross leverage ratio for a Bank is available in Canada before the Basel II implemention itself and that has helped them. It is very difficult to measure the risk with 100% accuracy. So having a leverage ratio on top of risk based capital is an added measure.

Dynamic provisioning for the loan loss provisioning is still under the discussion of International Accounting Standards Board (IASB) and will also be implemented.

Second we can take the case of Australia and India. Why the Australian and Indian Banks remained unaffected by the crisis is the Australian and Indian banks did not make themselves vulnerable by handing out risky loans during the good times. The banking system soundly capitalized and it has only limited exposure to sub-prime related assets and it continues to record sound profitability and so has low levels of problem loans. The Reserve Bank of Australia and Reserve Bank of India has taken the right step in right from granting the loans, which was the seed of the whole eceonomic crises. In simple words prudence has been used in granting loans. Moreover most of the Indian Banks were State Controlled and had a limited exposure to the global market. This made the Indian Banks more safer in every aspect.

In a nutshell, the solution for the crisis lies behind the prudence in granting the loans even during the good times, effective risk monitoring, Risk Manager's Participation in Board of Directors and risk based decision making by qualified risk management professional and dynamic provisioning to be made for loan losses are the steps used by the Banks which remained unaffected during the economic crisis.

But it always better to have the principle " Prevention is always better than cure"

Note: The views and opinions expressed here are purely my personal views and does not reflect anything beyond that.