You may run your own business, or work for a company where you are in a position of responsibility for helping the company run more smoothly, efficiently, or to be more productive. This responsibility includes identifying and evaluating software which will contribute to this cause.

You use a variety of software tools, but they are not integrated in a manner that supports efficiency. Some information is duplicated, and keeping separate systems in sync is problematic, leading to errors and/or significant effort to keep them up to date. Functions you wish you had, and know you need, are not available.

If you’ve come across and invested in a specific ‘vertical market’ application, again you find that this tool is not effectively integrated with other tools you use. Perhaps the specialized software has a rigid work flow or methodologies that you must adapt that do not fit how you prefer to conduct your business. Perhaps the specialized tool has way more features than you need, and it is hard, or impossible to work around the limitations, or how the product requires you to work.

Your first, and correct inclination is to find and procure an existing software product that meets your needs. An existing solution offers a way to leverage the cost of development for a complex tool. If the cost, feature-set and methodology provided in the specialized tool meets your requirements, this is the way to go. The alternative would be a custom built solution, or customization of an existing system to meet your exacting requirements.

This is where Systems Analysis can make a contribution — in understanding and documenting the ‘features’ important to your business, so that options you are considering can be evaluated, and the most appropriate solution secured or perhaps created from scratch.

The things you do to accomplish your business objectives constitute your business system. This includes human interactions and procedures, paper forms, computer applications, reports, the office hardware you choose, the way you connect to the Internet, etc. Anything you do that contributes to the running of your business.

You may be well served by a number of these tools and methods, and less so by others, but together they are the 'system' that allows your business to function.

If you own a business and believe that improving your processes and systems will benefit your bottom line, then you should consider having Business Systems Analysis performed for your operations. The analysis and design process can be simple or extensive, depending on your business objectives, your intentions for a new system and your budget.

The process of Business Systems Analysis involves identifying problems, opportunities, and your business objectives as a first step. Your current system is then analyzed with these in mind and requirements for a revised system are collected. Findings and alternatives arising from the analysis are then presented to management for direction and decisions. A new system is designed based on the input of the decision makers. If required, a custom application may be detailed and developed, documented and tested. The new system would then be implemented and then evaluated by end users. Over time, ongoing maintenance may be performed on the new system and upgrades implemented.

Not all analysis need be conducted at a high level of detail. Analysis and design need not be a long, drawn-out process. If an organization knows the specific area of the business they want improved, then the analysis and design might be as simple as identifying appropriate off-the-shelf alternatives and comparing them to one another based on documented requirements. How your business approaches this is variable based on your focus and intentions.

Analyzing your business systems for potential improvement begins with gaining an understanding of what you do and what methods you currently utilize to deliver your product(s) and/or service(s). In addition, clearly stated objectives help to refine the desired outcome of an analysis. Analysis will focus on identified issues or processes, based on the experience and recommendations of employees and managers and the approval of executives.

We look at the ‘who’ (people involved); ‘what’ (business activity); ‘where’ (work environment); ‘when’ (timing/sequence); and ‘how ‘(current procedures) of the selected areas of your business. In addition to this, we want to understand why business is currently conducted in this manner, and what challenges or shortfalls exist.

Interviews with managers, executives and employees may be conducted and their comments, issues, and desires for improvements documented. Questionnaires may be developed and distributed, and their results collated. Important processes may be documented, step-by-step, with flow-charts and/or in writing. Current reports may be reviewed; new reports may be detailed. Paper forms may be gathered and examined. Staff interactions with clients and/or processes may be observed.

Once we understand and have documented the system and issues we will examine, the analysis process can begin. In this phase we focus on what doesn’t work, and/or what could work better. We take the input of your staff, scrutinize each identified issue and document requirements that will form the basis for evaluating the current and proposed system. We then identify opportunities for improvement, and examine how they could increase productivity or efficiency.

In many cases, more than one possible solution or alternative may be presented. Where multiple alternatives exist, there are usually details regarding cost, implementation, and impact that assist in making decisions about which is the most appropriate. The Analyst may prepare recommendations based on the requirements and objectives of the organization.

The result of the above effort is usually a feasibility report, which is a summary of the information gathered, an estimate of the scope of the project, and presentation of alternative solutions for consideration. Review and discussion of the document should lead to a commitment to the issues to be addressed and the chosen alternative for responding to those issues. Decision makers within the organization should be able to plan and commit to improvements in the system based on their response to this document.

The feasibility report can be responded to in many ways. The scope of the project could be expanded or contracted. Management could come to the conclusion that no changes are desired at this time, or that only a select number of items will be respond to. This is the point at which organizational decisions and commitments must be made regarding how to proceed.

Designing the improved system

Once decisions have been made about the issues to be addressed and alternative solutions have been identified, these are consolidated into a description of the proposed new system.

The proposed new system might require the development of custom software like a database. It may only require that new forms or procedures be created, or some combination of possible solutions. The goal is to meet business objectives and to address the issues identified.

If the System Proposal calls for new procedures, forms, etc. then any specific details not previously identified must be fleshed out, and documentation created, reviewed and approved.

The scope of the project will dictate how to proceed from this point. If the System Proposal identifies an off-the-shelf software product then the design will be relatively fixed and we can move on to the implementation phase. It should be noted that for most established fields, off-the-shelf software could meet 80 – 95% of the needs of an organization, and this option should be considered before committing to a custom application development project.

If custom application development is required, the System Proposal must be converted into a form that communicates the requirements of the application to programmers in a non-ambiguous way. Data entry procedures, the user interface, reports, control and backup procedures, and the data structure of the application must be defined such that no critical detail is left out, or left to the interpretation of a programmer who may not be intimately aware of the needs of the organization. The results of this level of detailed application description  may contain input and output layouts, file specifications, processing details, decision trees or tables, data flow diagrams, a system flowchart, and any legacy code that can be used as a starting point. The analyst may require additional tools to communicate an accurate description of the logic and business rules of the application to programmer(s).

Again, the level of detail provided here will depend on the scope of the project and executive direction received. Large, complex development projects may require significant details prior to beginning programming. More simple applications, or applications that evolve over the course of time, or that may be developed based on existing systems, could conceivably require no more than the statement of goals, objectives, and requirements contained in a System Proposal. As long as the owner of the system is aware of the trade-off between the level of detail and the short and long-term costs involved, the design process can be adjusted accordingly.

If custom application development is required, the analyst must communicate with the programmer continuously to field questions and insure accurate interpretation of the application specifications. Programmers may perform walk-throughs with analysts regarding functionality, and some evolution of the application can be expected during development.

The analyst also works with users to produce appropriate documentation and procedure manuals for the new system.

A crucial component of the application development process is testing. Testing confirms that the application works as specified, and can be conducted by programmers, or by programmers and the Systems Analyst once the application can accommodate this interaction. User testing is another critical step, as the behavior of users may not be predictable, and uncover problems not identified by attempts of staff to identify and test all use case scenarios.

Implementing the new system involves user training, the successful conversion of data from the old system to the new, upgrading and/or installing any needed equipment to support the system, and bringing the new system on-line.

Although evaluation should be taking place in every phase of analysis and design, users often cannot predict what issues will arise until the new system has been implemented. This is often the first opportunity users have to experience the application as a whole, and thus to critique what and how the application performs in relation to their expectations and experience. Implementing the new solution should include ongoing user evaluation.

Maintaining the new system involves an ongoing cycle in response to the need for bug fixes, hardware/software updates, business system process changes and implementing additional features requested by users or management.