Nature of relationship between a business plan and an IS plan
by florenzie
Wednesday, January 6, 2010
A business plan is a formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals. It may also contain background information about the organization or team attempting to reach those goals.
Business planning is often conducted when:
* Starting a new venture (organization, product or service)
* Expanding a current organization, product or service
* Buying a current organization, product or service
* Working to improve the management of a current organization, product or service
There are a wide variety of formats for a business plan. The particular format and amount of content included in a plan depends on the complexity of the organization, product or service and on the demands of those who will use the business plan to make a decision, eg, an investor, funder, management, Board of Directors, etc.
Overall, the contents of a business plan typically aim to:
1. Describe the venture (new or current organization, product or service), often including its primary features, advantages and benefits
2. What the organization wants to do with it (buy it, expand it, etc.)
3. Justification that the plans are credible (eg, results of research that indicate the need for what the organization wants to do)
4. Marketing plans, including research results about how the venture will be marketed (eg, who the customers will be, any specific groups (or targets) of customers, why they need the venture (benefits they seek from the venture), how they will use the venture, what they will be willing to pay, how the venture will be advertised and promoted, etc.)
5. Staffing plans, including what expertise will be needed to build (sometimes included in business plans) and provide the venture on an ongoing basis
6. Management plans, including how the expertise will be organized, coordinated and led
7. Financial plans, including costs to build the venture (sometimes included in business plans), costs to operate the venture, expected revenue, budgets for each of the first several years into the future, when the venture might break-even (begin making more money overall than it has cost), etc.
8. Appendices (there are a wide variety of materials included in appendices, eg, description of the overall organization, its other products and/or services, its current staff, etc.)
Nonprofit readers might notice that a business plan is very similar to a well designed grant proposal. In addition to the above items, a grant proposal might include itemization of any deficits (when expected expenses exceed expected revenues), which indicates the need for funding from the particular funder to which the grant proposal is being submitted. Also, a break-even analysis usually isn't included in a grant proposal.
Quite often, an organization's business planners already know much of what will go into a business plan (this is true for strategic planning, too). However, development of the business plan greatly helps to clarify the organization's plans and ensure that key leaders are all "on the same script". Far more important than the plan document, is the planning process itself.
The business goals may be defined for for-profit or for non-profit organizations. For-profit business plans typically focus on financial goals, such as profit or creation of wealth. Non-profit and government agency business plans tend to focus on organizational mission which is the basis for their governmental status or their non-profit, tax-exempt status, respectively—although non-profits may also focus on optimizing revenue. In non-profit organizations, creative tensions may develop in the effort to balance mission with "margin" (or revenue). Business plans may also target changes in perception and branding by the customer, client, tax-payer, or larger community. A business plan having changes in perception and branding as its primary goals is called a marketing plan.
Business planning is usually conducted when starting a new organization or a new major venture, for example, new product, service or program. Essentially, a business plan is a combination of a marketing plan, strategic plan, operational/management plan and a financial plan. Far more important than the plan document, is the planning process itself.
Business planning usually includes a thorough examination of the idea for a new product/service, if there's really a market for it, who the competitors are, how the idea is uniquely positioned to be competitive and noticeable, how the idea will be produced to a product/service, how much it will cost, how it will be promoted, what overall goals must be accomplished, how the development and ongoing operations will be managed and what resources are needed (including money). As noted above, a business plan is a combination of a marketing plan, financial plan, strategic plan and a operational/management plan.
Business plans are decision-making tools. There is no fixed content for a business plan. Rather the content and format of the business plan is determined by the goals and audience. A business plan should contain whatever information is needed to decide whether or not to pursue a goal.
For example, a business plan for a non-profit might discuss the fit between the business plan and the organization’s mission. Banks are quite concerned about defaults, so a business plan for a bank loan will build a convincing case for the organization’s ability to repay the loan. Venture capitalists are primarily concerned about initial investment, feasibility, and exit valuation. A business plan for a project requiring equity financing will need to explain why current resources, upcoming growth opportunities, and sustainable competitive advantage will lead to a high exit valuation.
Preparing a business plan draws on a wide range of knowledge from many different business disciplines: finance, human resource management, intellectual property management, supply chain management, operations management, and marketing, among others.It can be helpful to view the business plan as a collection of sub-plans, one for each of the main business disciplines.
"... a good business plan can help to make a good business credible, understandable, and attractive to someone who is unfamiliar with the business. Writing a good business plan can’t guarantee success, but it can go a long way toward reducing the odds of failure."
Information Systems Plan
Rationale for an Information Systems Plan
Every year, $300-700 million dollar corporations spend about 5% of their gross income on information systems and their supports. That's from about $15,000,000 to $35,000,000! A significant part of those funds support enterprise databases, a philosophy of database system applications that enable corporations to research the past, control the present, and plan for the future.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all.
Many enterprises do not have model-based information systems development environments that allow system designers to see the benefits of rearranging an information systems development schedule. Consequently, the questions that cannot be answered include:
• What effect will there be on the overall schedule if an information system is purchased versus developed?
• At what point does it pay to hire an abnormal quantity of contract staff to advance a schedule?
• What is the long term benefit from 4GL versus 3GL?
• Is it better to generate 3GL than to generate/use a 4GL?
• What are the real costs of distributed software development over centralized development?
If these questions were transformed and applied to any other component of a business (e.g., accounting, manufacturing, distribution and marketing), and remained unanswered, that unit's manager would surely be fired!
We not only need answers to these questions NOW!, we also need them quickly, cost effectively, and in a form that they can be modeled and changed in response to unfolding realities. This paper provides a brief review of a successful 10-step strategy that answers these questions.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
This ad hoc information systems plan was possible only because all design and development was centralized, the only computer was a main-frame, and the past was acceptable prologue because budgets were ever increasing, schedules always slipping, and information was not yet part of the corporation's critical edge.
Well, today is different, really different! Budgets are decreasing, and slipped schedules are being cited as preventing business alternatives. Confounding the computing environment are different operating systems, DBMSs, development tools, telecommunications (LAN, WAN, Intra-, Inter-, and Extra-net), and distributed hard- and software.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring.
Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information.
Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.
Characteristics of a Quality ISP
A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
Timely
The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.
Usable
The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.
Maintainable
The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.
Quality
While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.
Reproducible
The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.
Whenever a proposal for the development of an ISP is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP is risked.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment
• Design
• Deployment
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned.
Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.
CONCLUSION:
Entrepreneurs and business managers are often so preoccupied with immediate issues that they lose sight of their ultimate objectives. That's why an Information System Plan, business reviews/plan or preparation of a strategic plan is a virtual necessity. This may not be a recipe for success, but without it a business is much more likely to fail. A sound plan should:
• Serve as a framework for decisions or for securing support/approval.
• Provide a basis for more detailed planning.
• Explain the business to others in order to inform, motivate & involve.
• Assist benchmarking & performance monitoring.
• Stimulate change and become building block for next plan.
A strategic plan should not be confused with a business plan. The former is likely to be a (very) short document whereas a business plan is usually a much more substantial and detailed document. A strategic plan can provide the foundation and frame work for a business plan.
A satisfactory strategic plan must be realistic and attainable so as to allow managers and entrepreneurs to think strategically and act operationally.
REFERENCES:
http://en.wikipedia.org/wiki/Business_plan
http://newton.uor.edu/Courses/SysAnaDes/planning.html
http://www.referenceforbusiness.com/encyclopedia/Bre-Cap/Business-Planning.htmll
http://en.wikipedia.org/wiki/Information_system
Business planning is often conducted when:
* Starting a new venture (organization, product or service)
* Expanding a current organization, product or service
* Buying a current organization, product or service
* Working to improve the management of a current organization, product or service
There are a wide variety of formats for a business plan. The particular format and amount of content included in a plan depends on the complexity of the organization, product or service and on the demands of those who will use the business plan to make a decision, eg, an investor, funder, management, Board of Directors, etc.
Overall, the contents of a business plan typically aim to:
1. Describe the venture (new or current organization, product or service), often including its primary features, advantages and benefits
2. What the organization wants to do with it (buy it, expand it, etc.)
3. Justification that the plans are credible (eg, results of research that indicate the need for what the organization wants to do)
4. Marketing plans, including research results about how the venture will be marketed (eg, who the customers will be, any specific groups (or targets) of customers, why they need the venture (benefits they seek from the venture), how they will use the venture, what they will be willing to pay, how the venture will be advertised and promoted, etc.)
5. Staffing plans, including what expertise will be needed to build (sometimes included in business plans) and provide the venture on an ongoing basis
6. Management plans, including how the expertise will be organized, coordinated and led
7. Financial plans, including costs to build the venture (sometimes included in business plans), costs to operate the venture, expected revenue, budgets for each of the first several years into the future, when the venture might break-even (begin making more money overall than it has cost), etc.
8. Appendices (there are a wide variety of materials included in appendices, eg, description of the overall organization, its other products and/or services, its current staff, etc.)
Nonprofit readers might notice that a business plan is very similar to a well designed grant proposal. In addition to the above items, a grant proposal might include itemization of any deficits (when expected expenses exceed expected revenues), which indicates the need for funding from the particular funder to which the grant proposal is being submitted. Also, a break-even analysis usually isn't included in a grant proposal.
Quite often, an organization's business planners already know much of what will go into a business plan (this is true for strategic planning, too). However, development of the business plan greatly helps to clarify the organization's plans and ensure that key leaders are all "on the same script". Far more important than the plan document, is the planning process itself.
The business goals may be defined for for-profit or for non-profit organizations. For-profit business plans typically focus on financial goals, such as profit or creation of wealth. Non-profit and government agency business plans tend to focus on organizational mission which is the basis for their governmental status or their non-profit, tax-exempt status, respectively—although non-profits may also focus on optimizing revenue. In non-profit organizations, creative tensions may develop in the effort to balance mission with "margin" (or revenue). Business plans may also target changes in perception and branding by the customer, client, tax-payer, or larger community. A business plan having changes in perception and branding as its primary goals is called a marketing plan.
Business planning is usually conducted when starting a new organization or a new major venture, for example, new product, service or program. Essentially, a business plan is a combination of a marketing plan, strategic plan, operational/management plan and a financial plan. Far more important than the plan document, is the planning process itself.
Business planning usually includes a thorough examination of the idea for a new product/service, if there's really a market for it, who the competitors are, how the idea is uniquely positioned to be competitive and noticeable, how the idea will be produced to a product/service, how much it will cost, how it will be promoted, what overall goals must be accomplished, how the development and ongoing operations will be managed and what resources are needed (including money). As noted above, a business plan is a combination of a marketing plan, financial plan, strategic plan and a operational/management plan.
Business plans are decision-making tools. There is no fixed content for a business plan. Rather the content and format of the business plan is determined by the goals and audience. A business plan should contain whatever information is needed to decide whether or not to pursue a goal.
For example, a business plan for a non-profit might discuss the fit between the business plan and the organization’s mission. Banks are quite concerned about defaults, so a business plan for a bank loan will build a convincing case for the organization’s ability to repay the loan. Venture capitalists are primarily concerned about initial investment, feasibility, and exit valuation. A business plan for a project requiring equity financing will need to explain why current resources, upcoming growth opportunities, and sustainable competitive advantage will lead to a high exit valuation.
Preparing a business plan draws on a wide range of knowledge from many different business disciplines: finance, human resource management, intellectual property management, supply chain management, operations management, and marketing, among others.It can be helpful to view the business plan as a collection of sub-plans, one for each of the main business disciplines.
"... a good business plan can help to make a good business credible, understandable, and attractive to someone who is unfamiliar with the business. Writing a good business plan can’t guarantee success, but it can go a long way toward reducing the odds of failure."
Information Systems Plan
Rationale for an Information Systems Plan
Every year, $300-700 million dollar corporations spend about 5% of their gross income on information systems and their supports. That's from about $15,000,000 to $35,000,000! A significant part of those funds support enterprise databases, a philosophy of database system applications that enable corporations to research the past, control the present, and plan for the future.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all.
Many enterprises do not have model-based information systems development environments that allow system designers to see the benefits of rearranging an information systems development schedule. Consequently, the questions that cannot be answered include:
• What effect will there be on the overall schedule if an information system is purchased versus developed?
• At what point does it pay to hire an abnormal quantity of contract staff to advance a schedule?
• What is the long term benefit from 4GL versus 3GL?
• Is it better to generate 3GL than to generate/use a 4GL?
• What are the real costs of distributed software development over centralized development?
If these questions were transformed and applied to any other component of a business (e.g., accounting, manufacturing, distribution and marketing), and remained unanswered, that unit's manager would surely be fired!
We not only need answers to these questions NOW!, we also need them quickly, cost effectively, and in a form that they can be modeled and changed in response to unfolding realities. This paper provides a brief review of a successful 10-step strategy that answers these questions.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
This ad hoc information systems plan was possible only because all design and development was centralized, the only computer was a main-frame, and the past was acceptable prologue because budgets were ever increasing, schedules always slipping, and information was not yet part of the corporation's critical edge.
Well, today is different, really different! Budgets are decreasing, and slipped schedules are being cited as preventing business alternatives. Confounding the computing environment are different operating systems, DBMSs, development tools, telecommunications (LAN, WAN, Intra-, Inter-, and Extra-net), and distributed hard- and software.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring.
Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information.
Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.
Characteristics of a Quality ISP
A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
Timely
The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.
Usable
The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.
Maintainable
The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.
Quality
While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.
Reproducible
The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.
Whenever a proposal for the development of an ISP is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP is risked.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment
• Design
• Deployment
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned.
Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.
CONCLUSION:
Entrepreneurs and business managers are often so preoccupied with immediate issues that they lose sight of their ultimate objectives. That's why an Information System Plan, business reviews/plan or preparation of a strategic plan is a virtual necessity. This may not be a recipe for success, but without it a business is much more likely to fail. A sound plan should:
• Serve as a framework for decisions or for securing support/approval.
• Provide a basis for more detailed planning.
• Explain the business to others in order to inform, motivate & involve.
• Assist benchmarking & performance monitoring.
• Stimulate change and become building block for next plan.
A strategic plan should not be confused with a business plan. The former is likely to be a (very) short document whereas a business plan is usually a much more substantial and detailed document. A strategic plan can provide the foundation and frame work for a business plan.
A satisfactory strategic plan must be realistic and attainable so as to allow managers and entrepreneurs to think strategically and act operationally.
REFERENCES:
http://en.wikipedia.org/wiki/Business_plan
http://newton.uor.edu/Courses/SysAnaDes/planning.html
http://www.referenceforbusiness.com/encyclopedia/Bre-Cap/Business-Planning.htmll
http://en.wikipedia.org/wiki/Information_system
