Slepi.NET

System Analysis is a phase in SDLC, in which the process of gathering information about the current system (called the As-Is system), identifying and analyzing its strengths and weaknesses, is conducted. Expected deliverable of this analysis phase is a conceptual/logical design of the new system (called the To-Be system) which will be built (in the next phase - design phase) based on the requirements. Note that the term As-Is system here refers to any existing system whether it's computerized or not, thus it's not necessarily be about an installation of software packages or certain computer applications.

The basic process of system analysis covers three steps:

• Understanding the As-Is system. Two common situations found in this step are the computerized and non-computerized As-Is system. For computerized As-Is system, System Analyst can review the documentation from previous system development that built the system or even interactively use the system (if permitted) as user of that system to have in-depth knowledge about the system. For a non-computerized system, the System Analyst is expected to gain information from users through some sessions of interviews, group meetings, or questionnaires.
• Identifying possible improvements. Once the existing system has been understood, the next step is to find and identify possible improvements that can be implemented in the As-Is system. For a quite complex business process, a System Analyst might get some assistances from one or more Business Analysts, as this step requires both technology and business skills. Some techniques have been developed for conducting successful improvements identification, such as root cause analysis and business process benchmarking.
• Developing the conceptual design of the To-Be system. The final step of system analysis is to make a conceptual design of the To-Be system that will be proposed to the project sponsor. The conceptual design outlines improvements that can be benefited from the new system out of the old one, presented (usually) as a set of behavioral and structural models of the new system. Several conceptual designs may be proposed as alternatives.

SDLC defines three fundamental strategies for system analysis, each strategy is not likely better than others but rather more suitable for certain type of projects or system requirements. It is the responsibility of a System Analyst to choose the most appropriate strategy for the project. All three strategies have the similarity in that they all cover all three processes described above. For a relatively complex system, it is common to complete the process in an iterative manner, going forth and back repeatedly in order to make better analysis.

The three fundamental strategies for system analysis are Business Process Automation (BPA), Business Process Improvement (BPI), and Business Process Reengineering (BPR).

Business Process Automation (BPA)

BPA tries to make minimal changes to the existing business process, and provides a system that makes the process works more efficiently.

Historically, it's named Business Process Automation because, back to the past days of the dawn of the computer era, there were many projects initiated to make systems that automate non-computerized (manual) works such as book-loan system in a library or student-enrollment application in a university.

The word automate sounds more enthusiastic those days, but less appropriate today as BPA can (and often) be applied to existing computerized systems (that perhaps automate something already) as well. But it's not more than a matter of terminology whatsoever, the key point here is that automating processes leads to improved efficiency of users, by speeding-up and/or simplifying their works.

• Understanding the As-Is system

  BPA consumes a considerably much time and effort in this step of understanding the As-Is system because the To-Be system will still use the existing business process. The new system will do essentially the same things as the As-Is system, but in better ways. Every activity in the process should be noticed and documented in details to be accommodated in the new system. Information gathering conducted by a series interviews with users of the As-Is system, as well by observation of the As-Is system in operation, and analysis of the current system's documentation.

• Identifying possible improvements

  Using BPA, most possible improvements that can be made are usually come from problems that are existed in the current As-Is system. There are two general techniques to identify possible improvements in BPA:

  1. Problem Analysis

     It is probably the simplest and most straightforward technique, the System Analyst usually tries to identify problems that the users experienced and then tries to fix them. The nature of this technique tends to be more problem-solving rather than system-improving, and the final system changes made are relatively small and far from radical, and hardly can give significant economical or monetary improvements.

  2. Root-cause Analysis

     Similar to Problem Analysis technique, Root-cause Analysis also focuses on solving problems that are existed in the As-Is system. But unlike in Problem Analysis, in Root-cause Analysis, System Analyst makes an in-depth observation and analysis of the problems. Root-cause Analysis gives more attention to the true problems (what caused the problems / root cause of the problems) rather than only to the symptoms of the problems.

     System Analyst starts by discussing any problems with the users of the system, and then make a list out of them prioritizing which problem is more crucial or important. Using the list, they track all possible causes for each problem recursively until they meet all possible root causes of every problem. The works for solution or improvement then follows, starts from the easiest root-cause problem. If one possible root-cause problem is identified to have caused more than one problems, it should be investigated first as there is a good chance of that particular root-cause is the true problem influencing the symptom problems.

• Developing the conceptual design of the To-Be system

  With BPA, the To-Be system tends to have many similarities to As-Is system in terms of general data structures and business processes. The principal differences lie usually on the way business processes are being conducted and on the form of data presented to users, i.e. a computerized sales report displayed on screen rather than on manual files. The To-Be system aims to add more efficiency values out of the As-Is system.

  In general, business processes and data structures can be simply copied from the As-Is system, and no further business process or data structure improvements made.

Business Process Improvement (BPI)

BPI tries to improve efficiency and effectiveness by making some slight and/or moderate changes to the system. The To-Be system is expected to introduce new business values that change what users usually do to make them work more effectively, in addition to efficiency benefits.

• Understanding the As-Is system

  Like in BPA, BPI consumes much times and efforts to have good understandings of the As-Is system. The interactivities from system users is also a vital part in helping System Analyst understands As-Is system, thus System Analyst is encouraged to make sessions of interview with users, and dig through existing system documentation as well.

• Identifying possible improvements

  One key point that distinguishes BPI from BPA is that BPI focusing on improvements of the business processes, not just making fixes to every problems. In addition to user interviews, it is good to conduct a thorough discussion between System Analyst and Business Analyst who understands how and for what goals current business process existed is.

  BPA techniques, Problem and Root-caused Analysis, can still be applied in BPI. However identifying improvements sometimes often requires more powerful techniques. There are four known techniques can be used in BPI, two of them focus on internal factors of the organization (Duration Analysis and Activity-based Costing), and the other two focus on external factors of the organization (Formal Benchmarking and Informal Benchmarking).

  1. Duration Analysis

     Duration Analysis is a technique to identify improvements in the area of time efficiency. The goal is to identify certain process that runs too slow than it should, and then System Analyst analyzes any possible changes that can be applied to make it consumes less time. Old proverb says Time is money, and this is what Duration Analysis tries to achieve.

     Duration Analysis technique can be applied by examining the total amount of time the As-Is system takes to process a certain type of business process. System Analyst then breaks that business process into several sub processes, examines how long each process takes to complete its tasks. If one sub process is identified to consume significantly great amount of time compared to the overall time, it is likely that sub process needs some improvements.

     Imagine a document approval workflow application; the document to be approved may travel from one desk to another in the sequential manner. The document can not be forwarded to a manager if it hasn't been approved by one of his/her in-department staff for example. Problem can arise when a staff if too lazy to frequently check what has entered his/her desk, the document will unnecessarily be wasted for some period of times. In such situation, improvement can be made to the system by adding a notification feature whenever a document enters someone desk and becomes his/her responsibility to process it. Further improvement could be in the form of fallback mechanism, the document should be moved to another person (who is the original person's delegate, for instance) if the document has already sat in someone's desk without any action taken for certain period of time.

     Even better if the System Analyst can recognize an opportunity to do process integration or parallelization. Process integration involves changing the business process so that fewer people work on the business process. In the workflow application above, process integration can be applied by cutting the number of desks the document should travel up to the final approval.

     Process parallelization involves changing the system so that several steps can be processes at the same time. Both process integration and parallelization likely requires retraining of the staff, due to the business process changes exposed by the method.

  2. Activity-based Costing

     Activity-based Costing is conceptually a simple technique. System Analyst just simply examines the cost required for a system to conduct certain process. He/she then tries to make improvements out of it.

  3. Informal Benchmarking

     Informal Benchmarking is to study how other similar organizations perform a business process. It deals usually with customer-related processes, where the System Analyst (often with Business Analyst) visit other organization as customers to learn how that organization runs a business process, and if possible find possible improvements that can be applied to their own organization.

  4. Formal Benchmarking

     Formal Benchmarking is the most thorough and expensive benchmarking strategy. It's involves establishing formal relation-/partnership with other organizations, whether they are in the same or different industries. Many companies from third world countries such as mine, Indonesia, are very eager when it comes to regional formal benchmarking.

     The company sends one or more its competent staffs to conduct formal benchmarking to a country where it's considered has more advanced techniques in doing certain business processes.

     As it involves formal relationship, some terms and conditions might be applied to both organizations regarding the benchmarking.

• Developing the conceptual design of the To-Be system

  Unlike in BPA, the To-Be system resulted by BPI experienced some business process changes. The changes may or may not require a significant rethinking or rework of the As-Is system. In BPI there are slight changes to the behavioral and structural models of the To-Be system compared to the As-Is system, and it might require to retrain the staff.

Business Process Reengineering (BPR)

BPR tries to achieve significant improvements of the system so that it gives more benefits in terms of both efficiency and effectiveness of business process, and is expected to give dramatic boost in cost-reduction and profit-generation of the organization. BPR is very time-consuming and risky as it requires radical changes to the business process, it is like throwing away all that are existed in the As-Is system and start all over again from the scratch in building the To-Be system. A special transformation plan should be made very carefully in order to conduct a successful BPR project.

• Understanding the As-Is system

  Due to the throw-away-the-As-Is-system nature of BPR, there is almost no need to try understanding the As-Is system as it will be replaced by the superior To-be system anyway. The only thing should be understood is what business process the As-Is essentially does, and build new behavioral and structural models that captures the general idea of the business process.

• Identifying possible improvements

  The key point of BPR is radical improvements, thus it requires completely rethinking and redesign of the business process. Something that couldn't be done without collaboration works between System Analyst, Business Analyst, and some important figures in the organization who play crucial roles, such as the owner and the managers, and even the commission board or the company stakeholders.

  Several techniques have been developed for BPR, and it is the job of the System Analyst to recommend which techniques should be used, and then discuss the chosen techniques with the project sponsor.

  1. Outcome Analysis

     A basic technique which tries to understand the outcome of the business process from the point of view of the customers. The team is encouraged to pretend as if they were the customers, to think what the customers really need and to think how the organization could enable customers to do.

     The product of the technique are usually an idea of what kind of products or services should be made, an analysis whether it will be accepted in the market or not, and other customer-related factors of the business process.

  2. Breaking Assumptions

     Using breaking assumptions technique, the team makes a list of business rules known about certain business process being reengineered. The team then systematically generates ideas about how to break every rule so that it could give benefits to the organization. It is a powerful technique to enrich the types of product or service a company could potentially provide to customers, as the breaking ideas are usually coming from real-life facts.

  3. Technology Analysis

     Technology Analysis is an effort to examine how certain technology could be applied to the business process so that it could give benefits. For example the use of Global Positioning System (GPS) could be applied in delivery service companies to provide delivery tracking feature for their customers (and possibly charge them more).

     Another example is how the messaging feature of enterprise technologies, such as Java EE and .NET, has enabled airlines company to provide online ticket reservation in a real-time base from many of their agents that are scattered all over the country with kilometers away.

  4. Activity Elimination

     Exactly what it sounds like, Activity Elimination is an effort to identify unnecessary activities in a business process. The team then examines them, and analyzes what's the effect if certain activity is taken out from the process. The team has to be careful and should have done an in-depth and thorough analysis before deciding to take that activity out of the process.

  5. Proxy Benchmarking

     It is similar to Informal Benchmarking technique described above, except that Proxy Benchmarking is done with different industry as the target of benchmarking. The team lists industries that have similar structures or conduct similar business process with the organization, learn about it, and then try to improve it to match the business process of the organization.

  6. Process Simplification

     Banking system is naturally a good area of Process Simplification technique to be applied. Banking system is a very complex enterprise system, and most of them are not refactored enough to make good performance. Refactoring complex system into several (isolated) sub system that does different business process can give a dramatic performance improvement of the overall system, which in turn provide better quality of the services.

• Developing the conceptual design of the To-Be system

  BPR results in a radical differences between the To-Be system and the As-Is system, in both behavioral and structural models of the system. It requires an extensive information gathering in developing the To-Be system. And as BPR exposes radical changes, there is a possibility to organization restructuring which might affect may employees. Subsequent training of the staffs is generally a must.

Strategy Characteristics

To sum up the three strategies for system analysis, it might be helpful to give attention to the table below, which gives a one-figure-covers-all description about the characteristic (potential business value, project cost, scopes of analysis, and project risk) of the three strategies.