BUSINESS SYSTEMS PLANNING (BSP)

BSP is a highly structured approach to enterprise analysis that focuses on data, the flow of data, and the data repositories, leading to the development of an IS architecture based on the data analysis. The methodology was originally developed for its own internal use by IBM and later became a successful commercial product (IBM, 1984).

BSP utilizes a top-down approach with bottom-up implementation of a process designed to translate the organization's business strategy to IS strategy. (IBM, 1984) Because of the importance of top management involvement with the process, an assessment of top management's commitment is conducted before beginning the process.

Once top management is on board with the project, a project team is selected from the organization's management, which usually includes both business and IS professionals.

The project team's first tasks are to identify and set goals and objectives for the organization, and to establish the scope of the project.

Following the initial steps of preparing and starting the BSP analysis, ten additional steps are undertaken to complete the BSP process:

1.     Define the business process: the resulting output is a list of all business processes, a description of each, and the identification of key processes.

2.     Define business data: identify entities and group their data into data classes.

3.     Define information architecture: relate the business processes to the data classes.

4.     Analyze current systems support: identify the existing organizations, business processes, IS applications, and data files, to detect voids or redundancies.

5.     Interview executives: a critical aspect of the top-down approach, this step validates the work of the project team, determines the objectives, defines the problems, ascertains IS needs and calculates their value.

6.     Define fidings and conclusions: analyze problems and their relationships to the business processes, establish priorities for IS support, and thereby alleviate the problems.

7.     Determine architecture priorities: development and implementation takes time, this step determines the importance of each IS initiative.

8.     Review information resource management: define the environment in which the information architecture is to be developed, implemented, and operated efficiently and effectively.

 Develop recommendations: assist management in their decisions regarding the follow-on activities.

Report results: present the final results to top management. (IBM, 1984)

Read more »

ENDS/MEANS (E/M) ANALYSIS

Ends/means analysis was developed by Wetherbe and Davis at the MIS Research Center at the University of Minnesota. It can be used to determine information requirements at the organizational, functional, or individual manager level. (Wethtrbe, 1988) (Wetherbe and Davis 1982).

This methodology is based upon general systems theory and focuses first on the outputs (goods, services, and information) called ends, which are generated by each organizational process. The methodology then defines the inputs and processes termed means, which are used to accomplish the ends. The ends from one process are the means to some other process. One example is an inventory process that provides budget information for other processes, or a marketing process that provides products to customer processes.

Ends/means analysis is primarily concerned with the effectiveness and efficiency of generating outputs from processes. Effectiveness is the degree to which the outputs from a process fill the input criteria of the other processes. Efficiency is the amount of resources used to accomplish a given end result, compared to the minimum amount of resources actually required to accomplish the same result.

The ends/means analysis model provides two types of information, effectiveness and efficiency. Effectiveness information is based upon what constitutes output effectiveness or what feedback is needed to evaluate this effectiveness. Efficiency information is based upon what constitutes input and transformation efficiency or what feedback is needed to evaluate this efficiency.

Wetherbe (1988) gives an example of an inventory manager who specified these information requirements during an ends/means analysis:

Ends specification: The outputs, or end result, of the inventory management function is an inventory kept as low as possible with an acceptable level of availability.

Means specification: The inputs and processes to accomplish the ends are the following: forecasts of future needs, amounts on hand and on order, items that are obsolete or in unusable condition, safety stock policy, demand variations, cost of ordering and holding inventory, cost of items, and stockouts.

In this example the efficiency measures needed for inventory management are: the number and cost of orders placed, cost of holding inventory, and loss from disposal of obsolete or unusable inventory. Efficiency will depend on the cost to attain a given level of effectiveness. Effectiveness measures needed for inventory management in this example are the number and seriousness of stockouts. (Wetherbe, 1988)

This methodology has been used in a wide range of organizational settings with positive results. Information requirements determined by this methodology are usually more extensive than those generated using other methodologies. The problem with most information planning tools is that they usually result in an IS that provides more efficiency-oriented information than effectiveness-oriented information. While most would agree that it is more important to be effective than to be efficient, ends/means analysis brings out effectiveness information requirements as well. These requirements are typically interdepartmental, making this methodology especially useful for a database planning effort.

This method focuses on improving the organization's efficiency by means of information systems suited to its processes, but does not examine their suitability for the organization's goals.

Read more »

BUYGRID Model of Industrial Buying

In 1967, the Canadian, American and Israeli marketing researchers, Robinson, Faris and Wind, introduced the buygrid framework as a generic conceptual model for buying processes of organisations. They saw industrial buying not as single events, but as organisational decision-making processes where multiple individuals decide on a purchase. Their framework consists of a matrix of buyclasses and buyphases.

The BUYCLASSES are:

1. New Tasks

The first-time buyer seeks a wide variety of information to explore alternative purchasing solutions to his organisational problem. The greater the cost or perceived risks related to the purchase, the greater the need for information and the larger the number of participants in the buying centre.

2. Modified Rebuy

The buyer wants to replace a product the organisation uses. The decision making may involve plans to modify the product specifications, prices, terms or suppliers as when managers of the company believe that such a change will enhance quality or reduce cost. In such circumstances, the buying centre proved to require fewer participants and allow for a quicker decision process than in a new task buyclass.

3. Straight Rebuy

The buyer routinely reorders a product with no modifications. The buyer retains the supplier as long as the level of satisfaction with the delivery, quality and price is maintained. New suppliers are considered only when these conditions change. The challenge for the new supplier is to offer better conditions or draw the buyer's attention to greater benefits than in the current offering.

Based on field research, Robinson, Faris and Wind divided the buyer purchase process into eight sequential, distinct but interrelated BUYPHASES:

1.      recognition of the organisational problem or need;

2.      determination of the characteristics of the item and the quantity needed;

3.      description of the characteristics of the item and the quantity needed;

4.      search for and qualification of potential sources;

5.      acquisition and analysis of proposals;

6.      evaluation of the proposals and selection of suppliers;

7.      selection of an order routine;

8.      Performance feedback and evaluation.

The most complex buying situations occur in the upper left quadrant of the buygrid matrix where the largest number of decision makers and buying influences are involved. A new task that occurs in the problem recognition phase (1) is generally the most difficult for management.

The buying process can vary from highly formalised to an approximation depending on the nature of the buying organisation, the size of the deal and the buying situation.

The relationship between the buyer and seller is initiated in phases 1 and 2. Assessing the buyer's needs and determining gaps between the current and desired situation is important. Buyers need assistance in forming realistic perceptions of both the current and the desired situation. Need gaps create the motive behind any purchase.

The relationship needs to be developed during phases 3 to 7. A sales person must be aware that a buyer not only has functional needs, but psychological, social, knowledge and situational needs as well. These components should be addressed in meetings in order to obtain commitment. The purchase can be a one-time transaction of a repetitive nature. When there are multiple deliveries, the supplier and buyer must agree on an order routine.

As buyphases are completed, the process of 'creeping commitment' occurs and reduces the likelihood of new suppliers gaining access to the buying situation.

During the performance feedback and evaluation phase, the relationship between the seller and buyer can develop into a longer term engagement. Buyer loyalty and customer satisfaction are primarily determined by the sales activities during this last phase.

Pros:

1. The major implication of Robinson, Faris and Wind's research is that industrial buying behaviour depends more on the buying situation than on the type of product.
2. The model explains the likely interaction between buyer and seller activities given the purchase needs of an organisation. It helps sales personnel deliver the correct message at the right time. Suppliers need to fill out this matrix for their firm's specific situation. For each cell in the matrix (buy situation and buy phase), the following questions must be answered: 1. Is this combination of situation and phase relevant? 2. Which organisation members influence this purchase decision? 3. What are the used performance indicators? 4. What are the information sources?
3. The buying side of the model can be used for both consumer and business related buying processes. It applies to all purchase situations.
4. The model is based on the observation that buyer's expectations and behaviour change according to whether the purchase is new, a modified rebuy or a straight rebuy.
5. The model can provide the basis for a formal selection process (e.g. request for information and request for proposal).
6. The buygrid framework proved its worth to the scientific community as one of the few industrial marketing models.

Cons:

1. The organisational buying model focuses mainly on products and not on services.
2. A shortcoming of the organizational buying approach is the negligence the supplier's side and the influence this party wields on the customer's organisational decision process.
3. The model neglects the importance of acquisition in sales processes.

Read more »

Database Management System

Database is a collection of related data and data is a collection of facts and figures that can be processed to produce information.

Mostly data represents recordable facts. Data aids in producing information, which is based on facts. For example, if we have data about marks obtained by all students, we can then conclude about toppers and average marks.

A database management system stores data in such a way that it becomes easier to retrieve, manipulate, and produce information.

Characteristics

Traditionally, data was organized in file formats. DBMS was a new concept then, and all the research was done to make it overcome the deficiencies in traditional style of data management. A modern DBMS has the following characteristics −

·        Real-world entity − A modern DBMS is more realistic and uses real-world entities to design its architecture. It uses the behavior and attributes too. For example, a school database may use students as an entity and their age as an attribute.

·        Relation-based tables − DBMS allows entities and relations among them to form tables. A user can understand the architecture of a database just by looking at the table names.

·        Isolation of data and application − A database system is entirely different than its data. A database is an active entity, whereas data is said to be passive, on which the database works and organizes. DBMS also stores metadata, which is data about data, to ease its own process.

·        Less redundancy − DBMS follows the rules of normalization, which splits a relation when any of its attributes is having redundancy in values. Normalization is a mathematically rich and scientific process that reduces data redundancy.

·        Consistency − Consistency is a state where every relation in a database remains consistent. There exist methods and techniques, which can detect attempt of leaving database in inconsistent state. A DBMS can provide greater consistency as compared to earlier forms of data storing applications like file-processing systems.

·        Query Language − DBMS is equipped with query language, which makes it more efficient to retrieve and manipulate data. A user can apply as many and as different filtering options as required to retrieve a set of data. Traditionally it was not possible where file-processing system was used.

·        ACID Properties − DBMS follows the concepts of Atomicity, Consistency, Isolation, and Durability (normally shortened as ACID). These concepts are applied on transactions, which manipulate data in a database. ACID properties help the database stay healthy in multi-transactional environments and in case of failure.

·        Multiuser and Concurrent Access − DBMS supports multi-user environment and allows them to access and manipulate data in parallel. Though there are restrictions on transactions when users attempt to handle the same data item, but users are always unaware of them.

·        Multiple views − DBMS offers multiple views for different users. A user who is in the Sales department will have a different view of database than a person working in the Production department. This feature enables the users to have a concentrate view of the database according to their requirements.

·        Security − Features like multiple views offer security to some extent where users are unable to access data of other users and departments. DBMS offers methods to impose constraints while entering data into the database and retrieving the same at a later stage. DBMS offers many different levels of security features, which enables multiple users to have different views with different features. For example, a user in the Sales department cannot see the data that belongs to the Purchase department. Additionally, it can also be managed how much data of the Sales department should be displayed to the user. Since a DBMS is not saved on the disk as traditional file systems, it is very hard for miscreants to break the code.

Users

A typical DBMS has users with different rights and permissions who use it for different purposes. Some users retrieve data and some back it up. The users of a DBMS can be broadly categorized as follows −

·        Administrators − Administrators maintain the DBMS and are responsible for administrating the database. They are responsible to look after its usage and by whom it should be used. They create access profiles for users and apply limitations to maintain isolation and force security. Administrators also look after DBMS resources like system license, required tools, and other software and hardware related maintenance.

·        Designers − Designers are the group of people who actually work on the designing part of the database. They keep a close watch on what data should be kept and in what format. They identify and design the whole set of entities, relations, constraints, and views.

·        End Users − End users are those who actually reap the benefits of having a DBMS. End users can range from simple viewers who pay attention to the logs or market rates to sophisticated users such as business analysts.

DBMS - Architecture

---

The design of a DBMS depends on its architecture. It can be centralized or decentralized or hierarchical. The architecture of a DBMS can be seen as either single tier or multi-tier. An n-tier architecture divides the whole system into related but independent n modules, which can be independently modified, altered, changed, or replaced.

In 1-tier architecture, the DBMS is the only entity where the user directly sits on the DBMS and uses it. Any changes done here will directly be done on the DBMS itself. It does not provide handy tools for end-users. Database designers and programmers normally prefer to use single-tier architecture.

If the architecture of DBMS is 2-tier, then it must have an application through which the DBMS can be accessed. Programmers use 2-tier architecture where they access the DBMS by means of an application. Here the application tier is entirely independent of the database in terms of operation, design, and programming.

3-tier Architecture

A 3-tier architecture separates its tiers from each other based on the complexity of the users and how they use the data present in the database. It is the most widely used architecture to design a DBMS.

·        Database (Data) Tier − At this tier, the database resides along with its query processing languages. We also have the relations that define the data and their constraints at this level.

·        Application (Middle) Tier − At this tier reside the application server and the programs that access the database. For a user, this application tier presents an abstracted view of the database. End-users are unaware of any existence of the database beyond the application. At the other end, the database tier is not aware of any other user beyond the application tier. Hence, the application layer sits in the middle and acts as a mediator between the end-user and the database.

·        User (Presentation) Tier − End-users operate on this tier and they know nothing about any existence of the database beyond this layer. At this layer, multiple views of the database can be provided by the application. All views are generated by applications that reside in the application tier.

Multiple-tier database architecture is highly modifiable, as almost all its components are independent and can be changed independently.

Read more »