Assessment of an Enterprise-Level Business System

Assessment of an Enterprise-Level Business System Leon Kilpatrick Assessment of an Enterprise-Level Business System This paper addresses relevant considerations for the assessment of an enterprise-level business system and starts with a discussion of which information-gathering methods can be used in analyzing the requirements for such a system. This is followed by a synopsis of business process mapping methods that should be used in analysis activities along with a discussion of which business process mapping tools should be used in documenting the analysis.

Next, the paper tackles the problem of how the analyst can determine if these methods and tools were effective in understanding the requirements and end with an explanation of how prototyping tools could be used to confirm these requirements. INFORMATION-GATHERING METHODS Relevant data must be obtained that can assist in helping assess the need, potential and effectiveness of an Enterprise-Level Business System. One of the most tested ways of gathering information for analysis is in the form of data obtained through survey.

Such data can be collected by e-mail, telephone or online. Web surveys offer some real advantages over the more conventional approaches with the most obvious advantages being speed and low cost. However there are some drawbacks to the survey approach. For one you must be extremely careful about what questions you ask and how you ask them. In order to alleviate biases you may want to ask close ended questions that require a yes/no type of response. In those instances where you want to obtain objective opinions, an open-ended format may be better suited.

It is important that the questions be devised to be as impartial as possible in order to prevent stake owner bias or having the results come to a preconceived conclusion. Another survey drawback consideration concerns the amount of respondents that will actually respond to the survey. It will go a long ways towards getting a high response rate if upper-management mandates that response to the survey is mandatory. Participation could then be tracked through some type of list, with reminders being sent out periodically to those who have not yet completed the survey.

Another proven information gathering method is the interview. Interviews can be accomplished as either personal one-on-one types of interviews or with groups of people or departments. One-on-one interviews are great for those instances where you may have people who do like to talk in groups, but they can be very time consuming. For those instances in which time is of the essence a group setting may be more practical, but may not produce as much information as that which is divulged in the personal interview.

A third method of information gathering concerns analyzing the standard operating procedures (SOP) of the process under review. This can be easily accomplished by obtaining best practices, screen shots, and personal observation of the processes and eliminates a lot of the personal biases that may result from the survey or interview methods. However, it must be noted that even though SOP’s are the approved method of performing a task, they may not always be indicative of the way in which the task is actually performed.

This is why personal observation is important. It helps to determine just how closely the SOP’s are being followed or if other methods are being employed. In his white paper entitled Joint Application Development (JAD) for Requirements Collection and Management, Alan Cline states that Joint Application Development (JAD) is a technique that allows the development, management, and customer groups to work together to build a product. In essence the JAD group meets until all pertinent issues have been discussed and the needed information is collected (Cline, 2000).

In an e-JAD meeting specialized software is used over a computer network that enables the participants to send their contributions and suggestions to each other. This approach would best serve businesses that have operating entities in various locations. Key factors that must be taken into consideration to ensure that the information obtained during the JAD session is gathered successfully are that JAD sessions are extremely structured so they must be carefully planned.

Open ended questions should be utilized in order to ignite the open and frank discussion that is characteristic of JAD. It is my opinion that no one method is more accurate than any other method in gathering the required information. The best method of all may be a combination of them all: Surveys, interviews, SOP interpretations, JAD, and personal observation of how a process is accomplished. The biggest consideration during this process should be which method will work best to in obtaining the desired information needed to perform a proper analysis.

BUSINESS PROCESS MAPPING METHODS Business process mapping refers to activities involved in defining exactly what a business entity does, who is responsible, to what standard a process should be completed and how the success of a business process can be determined (Deming, 1982). Since there are several business process mapping methods, the biggest consideration once again should be which method will work best in obtaining the desired information needed to perform a proper analysis.

The two most common business process mapping methods are the flow chart and the Hieratical process flow diagram. Other methods include the Process Profile Work Sheet, and Work Flow Surveys. The flow chart is best for representing the simple layout of the process flow by offering a more detailed diagram of a single process while the Hieratical process flow diagram is best utilized in showing the origination process and more accurately captures the overall process flow.

Jacka ( 2002), states that the Process Profile Work Sheet includes such information as the process owner, the trigger events (beginning and ending), inputs, outputs, and, the objectives, risks, key controls, and measures of success. Work Flow Surveys are completed by individuals actually working on the process and request from them a list of tasks — including inputs and outputs — which they perform in support of the process ( Interviewing and Mapping , para. 3). There are a host of tools available on the open market to aid in business process mapping that are more than acceptable for documenting analysis.

Two of the most used are Microsoft Project and Microsoft Visio. Microsoft Project is a project management software program developed and sold by Microsoft which is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads (Microsoft, 2010). Microsoft Visio is a commercial diagramming program for Microsoft Windows that uses vector graphics to create diagrams (Microsoft, 2010). ANALYST UNDERSTANDING OF REQUIREMENTS

One of the quickest ways for an analyst to determine if he has a complete understanding of the requirements would to observe how easily understood and how well received his preliminary reports are by both the stake holders and the proposed users of the system. The analyst’s ability to effectively communicate those requirements to others is of utmost importance and reflects the analyst complete understanding of not only the requirements but also the way in which that those requirements can best be presented to said stake holders and users.

Another method to determine if the analyst has an understanding of the requirements would be based on feedback from departmental managers on whether or not their needs have been properly addressed with an appropriate solution. Such feedback will go a long ways in determining just how well the analyst understands the needs and requirements of each department. Prototyping Tools Used To Confirm Requirements Prototyping tools that could be used to confirm the requirements would be flow-charts, walk-throughs, desk checks, unit test, and integration tests.

Key to any prototype tool would be something that can be developed quickly using available application development tools. The prototype should be repeatedly refined until it is acceptable for all users. While prototyping is a useful method of allowing an end user to develop small software applications, its real power is as a development tool to help analysts and users finalize the various interfaces and functions of a large business system. Prototyping tools should implement a skeleton or a prototype of the actual system with a focus on input (i. e. user interface) and output (i. e. , screen displays and reports generated with dummy data). The idea is to demonstrate the system functionality as soon as possible to the users and to get their feedback on the prototype. A flow chart allows an analyst to imitate data on a diagram and perform a virtual walk-through of a selected process and is very useful in determining if a process is correct or incorrect. A walk-through is an all-inclusive analysis of something that includes all the significant components, but does not necessarily include specific details.

A walk-through may be an evaluation method, a review in the form of a report, or an activity that imitates another one. Desk checking is typically used as a way to confirm the logic of computer programs algorithm but can also be use to check the logic of a proposed process, ensuring that there are no mistakes present. The process is done manually without computer assistance. To perform a desk check, an analyst prints out a schematic of the process and goes over it manually, line by line. Desk-check results are documented on a table for easy reference. The able typically has a condition which is either true or false and an input/output column, which shows the end results ( Lynch, 1999-2011). The goal of unit testing is to isolate each part of the process and show that the individual parts are correct. A unit test provides a strict, written procedure that the process must satisfy. As a result, it affords several benefits such as facilitating change, simplifying integration and finding problems early in the development cycle. The purpose of integration testing is to verify performance, functional, and reliability requirements of processes as a group.

These groups of units are put through their processes using Black box testing, grouped into larger aggregates with success and error cases being simulated via appropriate data inputs. In conclusion I have found that there are many areas that are relevant to the assessment of an enterprise-level business system. A successful assessment will be composed of a variety of methods whose biggest consideration should be which method will work best in obtaining the desired information needed to perform a proper analysis. References Cline, A. (2000). Joint Application Development (JAD) for Requirements Collection and Management.

Retrieved June 14, 2010 from http://www. carolla. com/wp-jad. htm. Deming, W. E. (1982), Out of the Crisis, Cambridge University Press, Cambridge Jacka, J. M. (2002). The Four Steps of Business Process Mapping. SmartPros. Retrieved from http://www. pro2net. com/x33396. xml Microsoft. (2010). Microsoft Project 2010. Retrieved from http://www. microsoft. com/project/en/us/product-information. aspx Microsoft. (2010). Microsoft Visio 2010. Retrieved from http://office. microsoft. com/en-us/visio/ Lynch, W. (1999-2011). What is Desk Checking. eHow. Retrieved from http://www. ehow. com/facts_5941523_desk-checking_. html