management information system - wordpress.com · management information system a management...

1

Management Information System

A management information system (MIS) is a subset of the overall internal controls of a business

covering the application of people, documents, technologies, and procedures by management

accountants to solve business problems such as costing a product, service or a business-wide

strategy. Management information systems are distinct from regular information systems in that they

are used to analyze other information systems applied in operational activities in the organization.

Academically, the term is commonly used to refer to the group of information management methods

tied to the automation or support of human decision making, e.g. Decision Support Systems, Expert

systems, and Executive information systems.

It has been describe as, "MIS 'lives' in the space that intersects technology and business. MIS

combines tech with business to get people the information they need to do their jobs

better/faster/smarter. Information is the lifeblood of all organizations - now more than ever. MIS

professionals work as systems analysts, project managers, systems administrators, etc.,

communicating directly with staff and management across the organization."

Overview

At the start, in businesses and other organizations, internal reporting was made manually and only

periodically, as a by-product of the accounting system and with some additional statistics, and gave

limited and delayed information on management performance.

In their infancy, business computers were used for the practical business of computing the payroll and

keeping track of accounts payable and accounts receivable. As applications were developed that

provided managers with information about sales, inventories, and other data that would help in

managing the enterprise, the term "MIS" arose to describe these kinds of applications. Today, the term is used broadly in a number of contexts and includes (but is not limited to): decision support

systems, resource and people management applications, project management and database retrieval

application.

Definition

An 'MIS' is a planned system of the collecting, processing, storing and disseminating data in the form

of information needed to carry out the functions of management. In a way it is a documented report

of the activities those were planned and executed. According to Philip Kotler "A marketing information

system consists of people, equipment, and procedures to gather, sort, analyze, evaluate, and

distribute needed, timely, and accurate information to marketing decision makers."

The terms MIS and information system are often confused. Information systems include systems that

are not intended for decision making. The area of study called MIS is sometimes referred to, in a

restrictive sense, as information technology management. That area of study should not be confused

with computer science. IT service management is a practitioner-focused discipline. MIS has also some

differences with Enterprise Resource Planning (ERP) as ERP incorporates elements that are not

necessarily focused on decision support.

Professor Allen S. Lee states that "...research in the information systems field examines more than

the technological system, or just the social system, or even the two side by side; in addition, it

investigates the phenomena that emerge when the two interact."

The term enterprise architecture refers to many things. Like architecture in general, it can refer to a

description, a process or a profession.

Management Information System (MIS) - www.viplavkambli.com

http://www.neteffect.in/

2

To some, "enterprise architecture" refers either to the structure of a business, or the documents and

diagrams that describe that structure. To others, "enterprise architecture" refers to the business

methods that seek to understand and document that structure. A third use of "enterprise architecture"

is a reference to a business team that uses EA methods to produce architectural descriptions of the

structure of an enterprise.

A formal definition of the structure of an enterprise comes from the MIT Center for Information

Systems Research:

Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm‘s operating model.

Enterprise Architecture describes enterprise applications and systems with their relationships to

enterprise business goals.

It is often said that the architecture of an enterprise exists, whether it is described explicitly or not.

This makes sense if you regard the architecture as existing in the system itself, rather than in a

description of it. Certainly, the business practice of enterprise architecture has emerged to make the

system structures explicit in abstract architecture descriptions. Practitioners are called "enterprise

architects."

Methods and Frameworks

Enterprise architects use various business methods and tools to understand and document the

structure of an enterprise. In doing so, they produce documents and models, together called artifacts.

These artifacts describe the logical organization of business strategies, metrics, business capabilities,

business processes, information resources, business systems, and networking infrastructure within

the enterprise.

A complete collection of these artifacts, sufficient to describe the enterprise in useful ways, could be considered an ‗enterprise‘ level architectural description, or an enterprise architecture, for short. This

is the definition of enterprise architecture implied by the popular TOGAF architectural framework.

An enterprise architecture framework is a collection of tools, process models, and guidance used by architects to assist in the production of organization-specific architectural descriptions. See the related

article on enterprise architecture frameworks for further information.

Enterprise Architecture Areas of Practice

Many enterprise architecture frameworks break down the practice of developing artifacts into four

practice areas. This allows the enterprise to be described from four important viewpoints. By taking

this approach, enterprise architects can assure their business stakeholders that they have provided

sufficient information for effective decision making.

These practice areas are

1. Business:

1. Strategy maps, goals, corporate policies, Operating Model

2. Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models

3. Business processes

4. Organization cycles, periods and timing



3

5. Suppliers of hardware, software, and services

2. Information:

1. Metadata - data that describes your enterprise data elements

2. Data models: conceptual, logical, and physical

3. Applications:

1. Application software inventories and diagrams

2. Interfaces between applications - that is: events, messages and data flows

3. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the

organization

4. Technology:

1. Hardware, platforms, and hosting: servers, and where they are kept

2. Local and wide area networks, Internet connectivity diagrams

3. Operating System

4. Infrastructure software: Application servers, DBMS

5. Programming Languages, etc..

Using an Enterprise Architecture

The primary purpose of describing the architecture of an enterprise is to improve the effectiveness or

efficiency of the business itself. This includes innovations in the structure of an organization, the

centralization or federation of business processes, the quality and timeliness of business information,

or ensuring that money spent on information technology (IT) can be justified.

There are many different ways to use this information to improve the functioning of a business. One

method, described in the popular TOGAF architectural framework, is to develop an architectural vision, which is a description of the business that represents a ―target‖ or ―future state‖ goal. Once

this vision is well understood, a set of intermediate steps are created that illustrate the process of changing from the present situation to the target. These intermediate steps are called ―transitional

architectures‖ by TOGAF. Similar methods have been described in other enterprise architecture

frameworks.

The Growing Use of Enterprise Architecture

Documenting the architecture of enterprises is becoming a common practice within the U.S. Federal

Government in the context of the Capital Planning and Investment Control (CPIC) process. The

Federal Enterprise Architecture (FEA) reference models serve as a framework to guide Federal

agencies in the development of their architectures. Companies such as Independence Blue Cross,

Intel and Volkswagen AG have also applied enterprise architecture to improve their business

architectures as well as to improve business performance and productivity.

Relationship to other disciplines

Enterprise architecture has become a key component of the information technology governance

process in many organizations. These companies have implemented a formal enterprise architecture

process as part of their IT management strategy. While this may imply that enterprise architecture is



4

closely tied to IT, it should be viewed in the broader context of business optimization in that it

addresses business architecture, performance management and process architecture as well as more

technical subjects. Depending on the organization, enterprise architecture teams may also be

responsible for some aspects of performance engineering, IT portfolio management and metadata

management.

An Enterprise Architecture Framework (EA Framework) is a framework for an Enterprise Architecture,

which defines, how to organize the structure and views associated with an Enterprise Architecture.

Overview

The three components of the enterprise architecture framework are:

* Views : provide the mechanisms for communicating information about the relationships that are important in the architecture

* Methods : provide the discipline to gather and organize the data and construct the views in a way

that helps insure integrity, accuracy and completeness

* Training/Experience : support the application of method and use of tools

Because the discipline of Enterprise engineering and Enterprise Architecture is so broad, and because

enterprises can be large and complex, the models associated with the discipline also tend to be large

and complex. To manage this scale and complexity, an Architecture Framework provides tools and

methods that can bring the task into focus and allow valuable artifacts to be produced when they are

most needed.

Architecture Frameworks are commonly used in Information technology and Information system

governance. An organization may wish to mandate that certain models be produced before a system

design can be approved. Similarly, they may wish to specify certain views be used in the

documentation of procured systems - the U.S. Department of Defense stipulates that specific DoDAF

views be provided by equipment suppliers for capital project above a certain value.

History

Impression of Enterprise Architecture Frameworks evolution (1987-2003). On the left: The Zachman

Framework 1987, NIST Enterprise Architecture 1989, EAP 1992, TISAF 1997, FEAF 1999 and TEAF

2000. On the right: POSIX, TAFIM, JTA, JTAA, TOGAF 1995, DoD TRM and C4ISR 1996, and DoDAF

2003.

Enterprise Architecture started with the Zachman Framework in 1987. Another early implementation

of an Enterprise Architecture framework was the "Technical Architecture Framework for Information

Management" (TAFIM). The first draft of TAFIM was completed in 1991 with the TAFIM Technical

Reference Model (TAFIM TRM). This technical reference model wanted to use open systems and new

technologies available in the commercial market, to develop a DoD-wide application. The TOGAF TRM

was originally derived from the Technical Architecture Framework for Information Management

(TAFIM), which in turn was derived from the IEEE model 1003.0 or POSIX Open System Environment:

a standard to construct an information processing system, including consumers, system integrators,

application developers, system providers, and procurement agencies.

In recent years, it has become apparent that a key benefit to be gained from Enterprise architecture

is the ability to support decision making in changing businesses. Because Enterprise Architecture

brings together business models (e.g. process models, organizational charts, etc.) and technical

models (e.g. systems architectures, data models, state diagrams, etc.) it is possible to trace the

impact of organizational change on the systems, and also the business impact of changes to the



5

systems.

As this benefit has emerged, many frameworks such as DoDAF, MODAF, or AGATE have adopted a

standard meta model which defines the critical architectural elements and the dependencies between

them. Applications based on these models can then query the underlying architectural information,

providing a simple and strong mechanism for tracing strategies to organizational and technological

impacts.

EA Framework topics

Persons who have ever remodeled their home, know how important building codes, blueprints, and

city or county inspections are to successfully complete the project. The architect operates within a

"framework" of building codes, preparing blueprints for each phase of the project, from the structural

changes to the size and layout of the rooms. Detailed drawings specify plumbing, electrical, and

building construction information for the entire structure. Enterprise Architecture works in a similar

manner.

An architecture framework for Information Technology (IT) affects every aspect of the enterprise. An

Enterprise Architecture framework is similar to building codes that ensure the building is soundly

constructed. The IT governance bodies and procedures serve as the city and county inspectors for

building improvement projects. Frameworks contain models and standards that will be used to

develop IT architecture descriptions. The architecture description is the blueprint.

Architecture domain

Example of the Federal Enterprise Architecture, which has defined five architectural layers.

In the context of the creation of enterprise architecture it is common, according to Péter Bernus

(2005), to recognise three or four types of architecture, each corresponding to its particulair

architecture domain. Examples of such domains are:

* Business architecture,

* Information systems architecture, often subdivided into

o Data architecture, and

o Application architecture,

* and Technical architecture.

Architectural domains are a structuring criterion for a collection of architecture products. They should

not be confused with the application domain of the framework as such.

Layers of the Enterprise Architecture

Layers of the Enterprise Architecture.

Contemporary federal guidance suggests thinking about ―layers‖ of the enterprise architecture:

* Business processes and activities

* Applications such as custom or off-the-shelf software tools

* Data that must be collected, organized, safeguarded, and distributed

* Technology such as computer systems and telephone networks



6

The Architecture Domains follow a pattern of decomposition as one goes from top to the bottom of the

framework. The ownership can be divided into 4 broad categories: planner's view, owner's view,

designer's view and developer's view in this order. All the views are mostly hierarchical in nature. For

business view the planner and owner's level is typically called the value chains (which are descriptive

by nature). The designer's view of business is also known as the analytical view and there are various

standards for modeling this view. One mostly commonly used modeling standard is the Business Process Modeling Notation (BPMN). The designer's view typically represents the execution level which

uses standards like Business Process Execution Language (BPEL).

The Application and Technology Domains (which are not to be confused with business domains) are

characterized by domain capabilities and domain services. The capabilities are supported by the

services. The application services are also referred in Service-oriented architecture (SOA). The

technical services are typically supported by software products.

The data view starts with the data classes which can be decomposed into data subjects which can be

further decomposed into data entities. The basic data model type which is most commonly used is

called ERD (Entity Relationship Diagrams, see Entity-relationship model). The Class, subject and

entity forms a hierarchical view of data. Enterprises do have millions of instances of data entities.

View model

A view model is a framework, which defines the set of views or approaches to be used in systems

analysis or the construction of an enterprise architecture.

Since the early 1990‘s there have been a number of efforts to define standard approaches for describing

and analyzing system architectures. Many of the recent Enterprise Architecture frameworks have

some kind of set of views defined, but these sets are not always called "view models".

Types of Enterprise Architecture framework

Open Source or Consortia-developed frameworks

* EABOK (The Guide to the Enterprise Architecture Body of Knowledge) - an U.S. Federal-funded

guide to EA in the context of legislative and strategic business requirements.

* Generalised Enterprise Reference Architecture and Methodology

* IDEAS Group - a four-nation effort to develop a common ontology for architecture interoperability

* RM-ODP - the Reference Model of Open Distributed Processing (ITU-T Rec. X.901-X.904 |

ISO/IEC 10746) defines an enterprise architecture framework for structuring the specifications of

open distributed systems.

* TOGAF - the Open Group Architecture Framework - a widely used framework including an

Architectural Development Method and standards for describing various types of architecture.

Commercial frameworks

* Integrated Architecture Framework (IAF) - from Capgemini company

* CLEAR Framework for Enterprise Architecture - Atos Origin's Enterprise Architecture Framework

* OBASHI - the OBASHI Business & IT methodology and framework

* Information FrameWork (IFW) - conceived by Roger Evernden in 1996



7

* Zachman Framework - an architecture framework, based on the work of John Zachman at IBM in

the 1980s.

Defense industry frameworks

* DoDAF - the US Department of Defense Architecture Framework

* MODAF - the UK Ministry of Defence Architecture Framework

* NATO Architecture Framework

* AGATE - the France DGA Architecture Framework

Government frameworks

* Government Enterprise Architecture (GEA) - a common framework legislated for use by

departments of the Queensland Government

* FDIC Enterprise Architecture Framework

* Federal Enterprise Architecture Framework (FEAF) - a framework produced by the Office of

Management and Budget for use within the U.S. Government

* NIST Enterprise Architecture Model

* Treasury Enterprise Architecture Framework (TEAF) - a framework for treasury, published by the

US Department of the Treasury in July 2000.

Enterprise Architecture Planning (EAP) in Enterprise Architecture is the planning process of defining

architectures for the use of information in support of the business and the plan for implementing

those architectures.

Overview

One of the earlier professional practitioners in the field of system architecture Steven H. Spewak in 1998 defined Enterprise Architecture Planning (EAP) as "the process of defining architectures for the

use of information in support of the business and the plan for implementing those architectures."

Spewak‘s approach to EAP is similar to that taken by DOE in that the business mission is the primary

driver. That is followed by the data required to satisfy the mission, followed by the applications that

are built using that data, and finally by the technology to implement the applications.

This hierarchy of activity is represented in the figure above, in which the layers are implemented in

order, from top to bottom. Based on the Business Systems Planning (BSP) approach developed by

John Zachman, EAP takes a data-centric approach to architecture planning to provide data quality,

access to data, adaptability to changing requirements, data interoperability and sharing, and cost

containment. This view counters the more traditional view that applications should be defined before

data needs are determined or provided for.

EAP topics

Zachman framework

EAP defines the blueprint for subsequent design and implementation and it places the

planning/defining stages into a framework. It does not explain how to define the top two rows of the

Zachman Framework in detail but for the sake of the planning exercise, abbreviates the analysis. The

Zachman Framework provides the broad context for the description of the architecture layers, while

EAP focuses on planning and managing the process of establishing the business alignment of the



8

architectures.

EAP is planning that focuses on the development of matrixes for comparing and analyzing data,

applications, and technology. Most important, EAP produces an implementation plan. Within the

Federal Enterprise Architecture, EAP will be completed segment enterprise by segment enterprise. The

results of these efforts may be of Governmentwide value; therefore, as each segment completes EAP,

the results will be published on the ArchitecturePlus web site.

EAP components

Enterprise Architecture Planning model consists of four levels:

* Layer 1 - getting started : This layer leads to producing an EAP workplan and stresses the

necessity of high-level management commitment to support and resource the subsequent six

components (or steps) of the process. It consists of Planning Initiation, which covers in general,

decisions on which methodology to use, who should be involved, what other support is required, and

what toolset will be used.

* Layer 2 - where we are today : This layer provides a baseline for defining the eventual

architecture and the long-range migration plan. It consists of:

* Business process modeling, the compilation of a knowledge base about the business functions

and the information used in conducting and supporting the various business processes, and

* Current Systems and Technology, the definition of current application systems and supporting

technology platforms.

* Layer 3 - the vision of where we want to be : The arrows delineate the basic definition process

flow: data architecture, applications architecture, and technology architecture. It consists of:

* Data Architecture - Definition of the major kinds of data needed to support the business.

* Applications Architecture - Definition of the major kinds of applications needed to manage that

data and support the business functions.

* Technology Architecture - Definition of the technology platforms needed to support the applications that manage the data and support the business functions.

* Layer 4 - how we plan to get there : This consists of the Implementation / Migration Plans -

Definition of the sequence for implementing applications, a schedule for implementation, a

cost/benefit analysis, and a clear path for migration.

EAP methodology

The Enterprise Architecture Planning (EAP) methodology is beneficial to understanding the further

definition of the Federal Enterprise Architecture Framework at level IV. EAP is a how to approach for

creating the top two rows of the Zachman Framework, Planner and Owner. The design of systems

begins in the third row, outside the scope of EAP.

EAP focuses on defining what data, applications, and technology architectures are appropriate for and

support the overall enterprise. Exhibit 6 shows the seven components (or steps) of EAP for defining

these architectures and the related migration plan. The seven components are in the shape of a

wedding cake, with each layer representing a different focus of each major task (or step).

Applications



9

Spewak approach to Federal Enterprise Architecture has helped organizations with modeling, business

strategy planning, process improvement, data warehousing, and various support systems designs,

data administration standards, object-oriented and information engineering methodologies, and

project management.

Enterprise Life Cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the

enterprise over time by incorporating new business processes, new technology, and new capabilities,

as well as maintenance and disposition of existing elements of the enterprise.

Overview

The enterprise life cycle is a concept in Enterprise Architecture (EA). The Enterprise Architecture

process is closely related to other processes, such enterprise engineering and program management

cycle, more commonly known as the Systems Development Life Cycle. This concept aids in the

implementation of an Enterprise Architecture, and the Capital Planning and Investment Control (CPIC)

process that selects, controls, and evaluates investments. Overlying these processes are human

capital management and information security management. When these processes work together

effectively, the enterprise can effectively manage information technology as a strategic resource and

business process enabler. When these processes are properly synchronized, systems migrate

efficiently from legacy technology environments through evolutionary and incremental developments,

and the Agency is able to demonstrate its return on investment. The figure on top illustrates the

interaction of the dynamic and interactive cycles as they would occur over time.

The Enterprise Life Cycle is the basis for most Enterprise Integration Architectures being proposed

today. The relationship between these representation and those used expressly for enterprise

integretion is extensively shown in Arturo Molina's (1998) "Handbook of Life Cycle Engineering: Concepts, Models, and Technologies".

Enterprise Life Cycle topics

Enterprise Architecture Process

Enterprise Architecture Process.

As a prerequisite to the development of every enterprise architecture, each Agency should establish

the need to develop an EA and formulate a strategy that includes the definition of a vision, objectives,

and principles. The figure shows a representation of the EA process. Executive buy-in and support

should be established and an architectural team created within the organization. The team defines an

approach and process tailored to Agency needs. The architecture team implements the process to

build both the baseline and target EAs. The architecture team also generates a sequencing plan for the transition of systems, applications, and associated business practices predicated upon a detailed

gap analysis. The architecture is employed in the CPIC and the enterprise engineering and program management processes via prioritized, incremental projects and the insertion of emerging new

technologies. Lastly, the architectures are maintained through a continuous modification to reflect the

Agency's current baseline and target business practices, organizational goals, visions, technology, and

infrastructure.

Architecture Life Cycle

DoDAF Architecture Life Cycle.

The figure depicts the life of the architecture as it evolves and shows the process that the architecture

description supports in the development, analysis, and evolution of the implemented architecture. In

this illustration, the Operational View is used to drive the requirements that are evaluated against the

Systems View. Operational deficiencies are derived from the analysis, and viable candidates are



10

identified. These candidates can take the form of either materiel or non- materiel solutions and are

modeled back into the Operational and Systems Views of the architecture.

The architecture is re-analyzed, and the process continues until the operational deficiencies are

minimized. The final sets of viable candidates are assessed for operational viability. Based on the results of the assessments, design changes are made and submitted for inclusion into the budgeting process. This process of developing, analyzing, and modifying continues throughout the architecture‘s

life cycle.

Enterprise Life Cycle activities

An Enterprise Life Cycle integrates the management, business, and engineering life cycle processes

that span the enterprise to align its business and IT activities. Enterprise Life Cycle refers generally to an organization‘s approach for managing activities and making decisions during ongoing refreshment of

business and technical practices to support its enterprise mission. These activities include investment

management, project definition, configuration management, accountability, and guidance for systems

development according to a System Development Life Cycle (SDLC). The Enterprise Life Cycle applies

to enterprise-wide planning activities and decision making. By contrast, a System Development Life

Cycle generally refers to practices for building individual systems. Determining what systems to build

is an enterprise-level decision.

The figure on the right depicts notional activities of an Enterprise Life Cycle methodology. Within the

context of this document, Enterprise Life Cycle does not refer to a specific methodology or a specific

bureau‘s approach. Each organization needs to follow a documented Enterprise Life Cycle methodology

appropriate to its size, the complexity of its enterprise, and the scope of its needs.

Enterprise Performance Life Cycle

The Enterprise Performance Life Cycle (EPLC) encompasses the major business functions executed

under the Office of the Chief Information Officer (CIO), and in particular shows at a high level the

relationship among the different business functions and both the general order and the iterative

nature of their execution. The placement of enterprise architecture in the center of the EPLC

conceptual diagram, shown in the figure, reflects the supporting and enabling role that enterprise

architecture serves for the major business functions in the Enterprise Performance Life Cycle.

The Enterprise Architecture (EA) Program explicitly considers the information needs of the Enterprise

Performance Life Cycle (EPLC) processes in developing and enhancing the EA Framework, collecting

and populating data in the EA Repository, and developing views, reports, and analytical tools that can

be used to facilitate the execution of the EPLC processes. The EPLC conceptual diagram in the figure

provides a Departmental perspective of key business functions. The EPLC is also relevant from an

individual investment or project perspective, as each new investment passes through each phase of

the EPLC. The investment-level perspective is detailed in the an Enterprise Performance Life Cycle

Framework.

The Technology Life Cycle (TLC) is an important tool. The diagram to the right illustrates the typical

life-cycle of a manufacturing process or production system from the stages of its initial conception to

its culmination as either a technique or procedure of common practice or to its demise. The Y-axis of

the diagram shows the business gain to the proprietor of the technology while the X-axis traces its

lifetime. Some technologies, such as steel, paper or cement manufacturing, have a long lifespan (with

minor variations in technology incorporated with time) whilst in other cases, such as electronic or

digital devices/processes, or in pharmaceutical technologies, the lifespan may be quite short.

It is to be noted that the TLC associated with a product or technological service is different from Product Life Cycle (PLC) dealt with in Product Life Cycle Management. The latter is concerned with the



11

life of a product in the market-place in respect of timing of introduction, marketing measures and

business costs. The technology underlying the product (which,say, for instance is a uniquely 'flavored

tea') may be quite marginal but the process of creating and managing its life as a branded product

will be very different.

The technology life cycle is concerned with the time and cost of developing the technology, the

timeline of recovering cost and modes of making the technology yield a profit proportionate to the

costs and risks involved. The TLC may, further, be protected during its cycle with patents and

trademark seeking to lengthen the cycle and to maximize the profit from it.

The 'product' of the technology may just be a commodity such as the polyethylene plastic or a

sophisticated product like the ICs used in a smartphone.

It is important to note that the development of a competitive product or process can have a major

effect on the lifespan of the technology, making it shorter. Equally, the loss of patent rights through litigation, or loss of its secret elements (if any) through leakages also work to reduce its lifespan.

Thus, it is apparent that the 'management' of the TLC is an important aspect of technology

development.

The Four Phases of the Technology Life Cycle-

Referring to the diagram above, the TLC may be seen as comprised of four phases:

(a) the research and development (R&D) phase (sometimes called the "bleeding edge") when

incomes from inputs are negative and where the prospects of failure are high

(b) the ascent phase when out-of-pocket costs have been recovered and the technology begins

to gather strength by going beyond some Point A on the TLC (sometimes called the "leading edge")

(c) the maturity phase when gain is high and stable, the region , going into saturation, marked

by M, and

(d) the decline (or decay phase), after a Point D, of reducing fortunes and utility of the

technology.

Licensing Options

In current world trends, with TLCs shortening due to competition and rapid innovation, a technology

becomes technically licensable at all points of the TLC, whereas earlier, it was licensed only when it

was past its maturity stage.

Large corporations develop technology for their own benefit and not with the objective of licensing.

The tendency to license out technology only appears when there is a threat to the life of the TLC

(business gain) as discussed later.

Licensing in the R&D phase

There are always smaller firms (SMEs) who are inadequately situated to finance the development of

innovative R&D in the post-research and early technology phases. By sharing incipient technology

under certain conditions, substantial risk financing can come from third parties. This is a form of

quasi-licensing which takes different formats.

Even large corporates may not wish to bear all costs of development in areas of significant and high

risk (e.g aircraft development) and may seek means of spreading it to the stage that proof-of-concept

is obtained.



12

In the case of small and medium firms, entities such as venture capitalists ('angels'), can enter the

scene and help to materialize technologies. Venture capitalists accept both the costs and uncertainties

of R&D, and that of market acceptance, in reward for high returns when the technology proves itself.

Apart from finance, they may provide networking, management and marketing support. Venture

capital connotes financial as well as human capital.

Large firms may opt for Joint R&D or work in a consortium for the early phase of development. Such

vehicles are called strategic alliances - strategic partnerships.

With both venture capital funding and strategic (research) alliances, when business gains begin to

neutralize development costs (the TLC crosses the X-axis), the ownership of the technology starts to

undergo change.

In the case of smaller firms, venture capitalists help clients enter the stockmarket for obtaining

substantially larger funds for development, maturation of technology, product promotion and to meet

marketing costs. A major route is through Initial Public Offering (IPO) which invite risk funding by the

public for potential high gain. At the same time, the IPOs enable venture capitalists to attempt to

recover expenditures already incurred by them through part sale of the stock pre-alloted to them

(subsequent to the listing of the stock on the stock exchange). When the IPO is fully subscribed, the

assisted enterprise becomes a corporation and can more easily obtain bank loans, etc if needed.

Strategic alliance partners, allied on research, pursue separate paths of development with the

incipient technology of common origin but pool their accomplishments through instruments such as

'cross-licensing'. Generally, contractual provisions among the members of the consortium allow a

member to exercise the option of independent pusuit after joint consultation; in which case the optee

owns all subsequent development.

Licensing in the Ascent Phase

The ascent stage of the technology usually refers to some point above Point A in the TLC diagram but

actually it commences when the R&D portion of the TLC curve inflects (only that the cashflow is

negative and unremunerative to Point A). The ascent is the strongest phase of the TLC because it is

here that the technology is superior to alternatives and can command premium profit or gain. The

slope and duration of the ascent depends on competing technologies entering the domain, although

they may not be as successful in that period. Strongly patented technology extends the duration

period.

The TLC begins to flatten out (the region shown as M) when equivalent or challenging technologies

come into the competitive space and begin to eat away marketshare.

Till this stage is reached, the technology-owning firm would tend to exclusively enjoy its profitability,

preferring not to license it. If an overseas opportunity does present itself, the firm would prefer to set

up a controlled subsidiary rather than license a third party.

Licensing in the Maturity Phase

The maturity phase of the technology is a period of stable and remunerative income but its

competitive viability can persist over the larger timeframe marked by its 'vital life'. However, there

may be a tendency to license out the technology to a third-parties during this stage to lower risk of

decline in profitability (or competitivity) and to expand financial opportunity.

The exercise of this option is, generally, inferior to seeking participatory exploitation; in other words,

engagement in joint-venture, typically in regions where the technology would be in the ascent



13

phase,as say, a developing country. In addition to providing financial opportunity it allows the

technology-owner a degree of control over its use. Gain flows from the two streams of investment-

based and royalty incomes. Further, the vital life of the technology is enhanced in such strategy.

Licensing in the Decline Phase

After reaching a point such as D in the above diagram, the earnings from the technology begin to decline rather rapidly. To prolong the life cycle, owners of technology might try to license it out at

some point L when it can still be attractive to firms in other markets. This, then, traces the

lengthening path, LL'. Further, since the decline is the result of competing rising technologies in this

space, licenses may be attracted to the general lower cost of the older technology (than what

prevailed during its vital life).

Licenses obtained in this phase are 'straight licenses'. They are free of direct control from the owner of the technology (as would otherwise apply,say, in the case of a joint-venture). Further, there may

be fewer restrictions placed on the licensee in the employment of the technology.

The utility, viability, and thus the cost of straight-licenses depends on the estimated 'balance life' of

the technology. For instance, should the key patent on the technology have expired, or would expire

in a short while, the residual viability of the technology may be limited, although balance life may be

governed by other criteria viz. knowhow which could have a longer life if properly protected.

It is important to note that the license has no way of knowing the stage at which the prime, and competing technologies, are on their TLCs. It would, of course, be evident to competing licensor firms,

and to the originator, from the growth, saturation or decline of the profitability of their operations.

The license may, however, be able to approximate the stage by vigorously negotiating with the

licensor and competitors to determine costs and licensing terms. A lower cost, or easier terms, may

imply a declining technology.

In any case, access to technology in the decline phase is a large risk that the licensee accepts. (In a

joint-venture this risk is substantially reduced by licensor sharing it). Sometimes, financial guarantees

from the licensor may work to reduce such risk and can be negotiated.

There are instances when, even though the technology declines to becoming a technique, it may still

contain important knowledge or experience which the licensee firm cannot learn of without help from

the originator. This is often the form that technical service and technical assistance contracts take

(encountered often in developing country contracts). Alternatively, consulting agencies may fill this

role.

Business performance management (BPM) (or Corporate performance management, Enterprise

performance management, Operational performance management, Business performance

optimization) consists of a set of processes that help organizations optimize their business

performance. It provides a framework for organizing, automating and analyzing business

methodologies, metrics, processes and systems that drive business performance.

Some commentators[who?] see BPM as the next generation of business intelligence (BI). BPM helps

businesses make efficient use of their financial, human, material and other resources.

In the past[update], owners have sought to drive strategy down and across their organizations, they

have struggled to transform strategies into actionable metrics and they have grappled with meaningful analysis to expose the cause-and-effect relationships that, if understood, could give

profitable insight to their operational decision-makers.



14

Corporate performance management (CPM) software and methods allow a systematic, integrated

approach that links enterprise strategy to core processes and activities. "Running by the numbers"

now means something: planning, budgeting, analysis and reporting can give the measurements that

empower management decisions.

History

Reference to non-business performance management occurs in Sun Tzu's The Art of War. Sun Tzu

claims that to succeed in war, one should have full knowledge of one's own strengths and weaknesses

and full knowledge of one's enemy's strengths and weaknesses. Lack of either one might result in

defeat. A certain school of thought[which?] draws parallels between the challenges in business and

those of war, specifically:

* collecting data - both internal and external

* discerning patterns and meaning in the data (analyzing)

* responding to the resultant information

Prior to the start of the Information Age in the late 20th century, businesses sometimes took the

trouble to laboriously collect data from non-automated sources. As they lacked computing resources

to properly analyze the data, they often made commercial decisions primarily on the basis of intuition.

As businesses started automating more and more systems, more and more data became available.

However, collection remained a challenge due to a lack of infrastructure for data exchange or due to

incompatibilities between systems. Reports on the data gathered sometimes took months to generate.

Such reports allowed informed long-term strategic decision-making. However, short-term tactical

decision-making often continued to rely on intuition.

Increasing standards, automation, and technologies have led to vast amounts of data becoming

available. Data warehouse technologies have set up repositories to store this data. Improved ETL and

Enterprise Application Integration tools have increased the speedy collecting of data. OLAP reporting

technologies have allowed faster generation of new reports which analyze the data. Business

intelligence has now become the art of sieving through large amounts of data, extracting useful

information and turning that information into actionable knowledge.

In 1989 Howard Dresner, a research analyst at Gartner, popularized "Business Intelligence" as an

umbrella term to describe a set of concepts and methods to improve business decision-making by

using fact-based support systems. Performance Management builds on a foundation of BI, but marries

it to the planning and control cycle of the enterprise - with enterprise planning, consolidation and

modeling capabilities.

Use of the term "BPM" can cause confusion with "Business Process Management", and many[who?]

have started[when?] using terms like "Corporate Performance Management" or "Enterprise

Performance Management".

Definition and scope

Business performance management consists of a set of management and analytic processes,

supported by technology, that enable businesses to define strategic goals and then measure and

manage performance against those goals. Core BPM processes include financial and operational

planning, consolidation and reporting, business modeling, analysis, and monitoring of key

performance indicators linked to strategy.

BPM involves consolidation of data from various sources, querying, and analysis of the data, and

putting the results into practice.



15

BPM enhances processes by creating better feedback loops. Continuous and real-time reviews can

help to identify and eliminate problems before they grow. BPM's forecasting abilities help companies

take corrective action in time to meet earnings projections. Forecasting is characterized by a high

degree of predictability which is put into good use to answer what-if scenarios.

BPM can help in risk analysis and in predicting outcomes of merger and acquisition scenarios and in

planning to overcome potential problems.

BPM provides key performance indicators (KPIs) that help companies monitor efficiency of projects

and employees against operational targets.

Methodologies

Various methodologies for implementing BPM exist. The discipline gives companies a top-down

framework by which to align planning and execution, strategy and tactics, and business unit and

enterprise objectives. Reactions may include the Six Sigma strategy, balanced scorecard, activity-

based costing (ABC), Total Quality Management, economic value-add, and integrated strategic

measurement.

The balanced scorecard is the most widely adoptedperformance management methodology.

Methodologies on their own cannot deliver a full solution to an enterprise's CPM needs. Many pure

methodology implementations fail to deliver the anticipated benefits due to lack of integration with

the fundamental CPM processes.

Metrics / Key Performance Indicators

For business data analysis to become a useful tool, an enterprise must understand its goals and objectives– essentially, it must know the desired direction of progress. To help with this analysis,

someone[who?] prescribes key performance indicators (KPIs) to assess the present state of the

businessand to prescribe a course of action.

Metrics and KPIs are critical in prioritization what has to be measured.The methodology used helps in

determining the metrics to be used by the organization. Managerial folk-wisdom says that one cannot

manage what cannot be measured. Identifying the key metrics and determining how they are to be

measured helps the organizations to monitor performance across the board without getting deluged

by a surfeit of data; a scenario plaguing most companies

More and more[weasel words] organizations have started to make data available more rapidly. In the

past[update], some data only became available after a month or two, which did not help managers

react swiftly enough. Recently[update], banks have tried to make data available at shorter intervals

and have reduced delays. For example, for businesses which have higher operational/credit risk

loading (for example, credit cards and "wealth management"), a large multi-national bank makes KPI-

related data available weekly, and sometimes offers a daily analysis of numbers. It also provides real-

time dashboards. Data can become available within 24 hours, given automation and the use of IT

systems.

Most of the time, BPM simply means use of several financial/non-financial metrics/key performance

indicators to assess the present state of a business and to prescribe a course of action.

Some of the areas from which top management analysis could gain knowledge by using BPM may

include:



16

1. customer-related numbers:

1. new customers acquired

2. status of existing customers

3. attrition of customers (including breakup by reason for attrition)

2. turnover generated by segments of the customers - possibly using demographic filters

3. outstanding balances held by segments of customers and terms of payment - possibly using

demographic filters

4. collection of bad debts within customer relationships

5. demographic analysis of individuals (potential customers) applying to become customers, and the

levels of approval, rejections and pending numbers

6. delinquency analysis of customers behind on payments

7. profitability of customers by demographic segments and segmentation of customers by

profitability

8. campaign management

9. realtime dashboard on key operational metrics

1. overall equipment effectiveness

10. clickstream analysis on a website

11. key product portfolio trackers

12. marketing channel analysis

13. sales data analysis by product segments

14. callcenter metrics

The above list more or less describes what a bank might monitor, but could also refer to a telephone

company or similar service-sector company.

Items of generic importance might include:

1. consistent and correct KPI-related data providing insights into operational aspects of a company

2. timely availability of KPI-related data

3. KPIs designed to directly reflect the efficiency and effectiveness of a business

4. information presented in a format which aids decision-making for management and decision- makers

5. ability to discern patterns or trends from organized information

BPM integrates the company's processes with CRM or ERP. Companies should become better able to

gauge customer satisfaction, control customer trends and influence shareholder value.



17

Application software types

People working in business intelligence have developed tools that ease the work, especially when the

intelligence task involves gathering and analyzing large amounts of unstructured data.

Tool categories commonly used for business performance management include:

* OLAP — online analytical processing, sometimes simply called "analytics" (based on dimensional analysis and the so-called "hypercube" or "cube")

* scorecarding, dashboarding and data visualization

* data warehouses

* document warehouses

* text mining

* DM — data mining

* BPO — business performance optimisation

* EIS — executive information systems

* DSS — decision support systems

* MIS — management information systems

* SEMS — strategic enterprise management software

* business dashboards

Design and implementation

Issues when implementing a BPM program might include:

* goal-alignment queries: one must firstdetermine the short- and medium-term purpose of the

program. What strategic goal(s) of the organization will be addressed by the program? What

organizational mission/vision does it relate to? A hypothesis needs to be crafted that details how this

initiative will eventually improve results / performance (i.e. a strategy map).

* baseline queries: current information-gathering competency needs assessing. Do we have the

capability to monitor important sources of information? What data is being collected and how is it

being stored? What are the statistical parameters of this data, e.g., how much random variation does

it contain? Is this being measured?

* cost and risk queries: someone should estimate the financial consequences of a new BI initiative.

It is necessary to assess the cost of the present operations and the increase in costs associated with

the BPM initiative. What is the risk that the initiative will fail? This risk assessment should be

converted into a financial metric and included in the planning.

* customer and stakeholder queries: determine who will benefit from the initiative and who will

pay. Who has a stake in the current procedure? What kinds of customers / stakeholders will benefit

directly from this initiative? Who will benefit indirectly? What quantitative / qualitative benefits follow?

Is the specified initiative the best way to increase satisfaction for all kinds of customers, or is there a

better way? How will customer benefits be monitored? What about employees, shareholders, and

distribution channel members?



18

* metrics-related queries: information requirements need operationalization into clearly defined

metrics. One must decide what metrics to use for each piece of information being gathered. Are these

the best metrics? How do we know that? How many metrics need to be tracked? If this is a large

number (it usually is), what kind of system can track them? Are the metrics standardized, so they can

be benchmarked against performance in other organizations? What are the industry standard metrics

available?

* measurement methodology-related queries: one should establish a methodology or a procedure

to determine the best (or acceptable) way of measuring the required metrics. What methods will be

used, and how frequently will data be collected? Are there any industry standards for this? Is this the

best way to do the measurements? How do we know that?

* results-related queries: someone should monitor the BPM program to ensure that it meets

objectives. Adjustments in the programme may be necessary. The program should be tested for

accuracy, reliability, and validity. How can it be demonstrated that the BI initiative, and not something

else, contributed to a change in results? How much of the change was probably random?

Integrated business planning (IBP) refers to the technologies, applications and processes of

connecting the planning function across the enterprise to improve organizational alignment and

financial performance. IBP accurately represents a holistic model of the company in order to link

strategic planning and operational planning with financial planning.

By deploying a single model across the enterprise and leveraging the organization‘s information

assets, corporate executives, business unit heads and planning managers use IBP to evaluate plans

and activities based on the true economic impact of each consideration.

History of IBP

The roots of IBP date back to 1996 where Dr. Robert Whitehair, working at the University of

Massachusetts, developed technology for capturing and exploiting expert knowledge. Dr. Whitehair

worked in close collaboration with several colleagues, including Professor Igor Budyachevsky of the

Russian Academy of Science, to develop a technology now called COR (Constraint Oriented

Reasoning). COR technology was used to capture expert knowledge; then embed it in applications

that allow users to leverage it through a natural language interface.

Using grant funding from corporate giants such as Chase, DuPont, General Electric,

PricewaterhouseCoopers, Shell and the Williams Company, Dr. Whitehair captured expert knowledge

from numerous disciplines and introduced an application for business analysis that empowered

decision makers.

Components of IBP

As illustrated right, planning is integrated across the enterprise, which enables decision makers to

identify the activities that deliver the greatest financial impact across the company.

Recent developments and successes in the areas of business intelligence and performance management are accelerating the adoption of integrated business planning. While IBP has been a

vision for many years; the technology required for modeling, optimization and scaling was non-

existent. Dr. Robert C. Whitehair of River Logic, considered to be the father of IBP, used constraint-

oriented reasoning (COR) and knowledge-based rules engines to generate mathematical

representations of planning constraints and variables; thereby making IBP a reality.

Dr. Whitehair, working in collaboration with scientists in the U.S. and the Russian Academy of

Science, solved the problem of scaling real-life situations in mathematical equivalents. Today, IBP

software easily runs thousands of analyses of a mathematical representation of ~1,000,000



19

equations, each in excess of 1,000,000 variables, in a typical solve.

In broad terms, the use of mathematical representations and extensive knowledge bases enable users

to build the massive, multivariable models required for Integrated Business Planning.

Analyses

Companies use IBP to translate insight into financial impact by providing analyses such as:Identification of top financial (profit) drivers

* Answers to ―what-if‖ questions

* Simulation

* Optimization to any variable or ratio, including balance sheet, profitability, NPV, cash flow, etc

* Intelligent sensitivity analysis

* Modeling infeasibilities

* Understanding of unique performance driver relationships

* Opportunity costs and marginal economic value.

Benefits

IBP transforms planning into a decisive competitive advantage by:

* Providing an integrated planning platform across marketing, operations and finance

* Generating a holistic understanding of performance drivers

* Quantifying the financial impact and interdependencies across planning alternatives

* Optimizing strategic planning and resource allocation

* Balancing sales and operations planning for profitability

* Quantifying financial risk

* Increasing business flexibility

IBP Applications

IBP has been used to successfully model and integrate the planning efforts in a number of

applications, including:

* Product profitability

* Customer profitability

* Capital expenditures

* Manufacturing operations

* Supply chain

* Business processes (human and information-based)

* Business policy



20

* Market demand curves

* Competitive strategy

Business process modeling (BPM) in systems engineering and software engineering is the activity of

representing processes of an enterprise, so that the current process may be analyzed and improved in

future. BPM is typically performed by business analysts and managers who are seeking to improve

process efficiency and quality. The process improvements identified by BPM may or may not require

Information Technology involvement, although that is a common driver for the need to model a

business process, by creating a process master.

Change management programs are typically involved to put the improved business processes into

practice. With advances in technology from large platform vendors, the vision of BPM models

becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to

reality every day.

Overview

Business process modeling plays an important role in the business process management (BPM)

discipline. Since both business process modeling and business process management share the same

abbreviation (BPM), these activities are sometimes confused with each other.

BPM addresses the process aspects of a business architecture, leading to an all encompassing

enterprise architecture. The relationships of a business processes in the context of the rest of the

enterprise systems (e.g., data architecture, organizational structure, strategies, etc.) create greater capabilities when analyzing and planning enterprise changes. For example, during a corporate merger

it is important to understand the processes of both companies in detail so that management can

correctly and efficiently identify and eliminate redundancies in operations.

The graphical representation of business process information has proven effective for presenting it to

business stakeholders, including business analysts and system developers. Visual modeling languages

used to represent business processes include Business Process Modeling Notation (BPMN) and the Unified Modeling Language (UML).

Business process modeling has always been a key aspect of business process reengineering (BPR) and

continuous improvement approaches, such as Six Sigma. For routine business activities, BPM tools

such as Provision, Intalio, K2 [blackpearl], Axway, Lombardi, Holosofx, Holocentric Modeler and TIBCO are used in order to represent a business process, to run a simulation of the process and for communication purposes. For innovative, adaptive, collaborative human work the techniques of

human interaction management are required.

History

The classic business process modeling methodologies such as the flow chart, functional flow block

diagram, data flow diagram, control flow diagram, Gantt chart, PERT diagram, and IDEF have

emerged all over the 20th century: The Gantt chart around 1900, the flow charts in the 1920s,

Functional Flow Block Diagram and PERT in the 1950s, Data Flow Diagrams and IDEF in the 1970s.

IDEF0 is probably the most common technique of traditional business process modeling. These represent just a fraction of the methodologies used over the years to document business processes.

Methods from the new millennium here are Unified Modeling Language and the Business Process

Modeling Notation. The term "business process modeling" itself was coined in the 1960s in the field of

systems engineering. S. Williams in 1967 published the article "Business Process Modeling Improves

Administrative Control." His idea was that techniques for obtaining a better understanding of physical

control systems could be used in a similar way for business processes. August Wilhelm-Scheer is

regarded as founding the modern Business Process Modeling software industry with the development



21

of the Y-model and the founding of IDS Scheer in the 1980s.

In the 1990s the term "process" became a new productivity paradigm. Companies were encouraged

to think in "processes" instead of "functions" and "procedures". Process thinking looks horizontally

through the company for inducing improvement and measurement. Traditional function modeling

methods failed to measure and support improvement in cross-function activities, and their tools can depict the complexity and dependency. As complexity grows these cross-functional activities had

increased in number and importance. The focus on processes has been described as business process

redesign, business process innovation apart from several nicknames, all aiming at improving

processes across the traditional functions that comprise a company.

Around the same time (early 1990s) in the field of software engineering the term "business process

modeling" was coined as opposed to software process modeling, much more oriented towards the state of the practice. Earlier and new modeling techniques to capture business processes were now

called "business process modeling languages." In the Object Oriented approach, it was considered to

be an essential step in the specification of Business Application Systems. Business process modeling

became the base of new methodologies, that for example also supported data collection, data flow

analysis, process flow diagrams and reporting facilities. Around 1995 the first visually oriented tool for

business process modeling and implementation were being presented.

BPM topics

Business model

Business model design template: Nine building blocks and their relationships, Osterwalder 2004

A business model is a framework for creating economic, social, and/or other forms of value. The term

business model' is thus used for a broad range of informal and formal descriptions to represent core

aspects of a business, including purpose, offerings, strategies, infrastructure, organizational

structures, trading practices, and operational processes and policies.

In the most basic sense, a business model is the method of doing business by which a company can sustain itself. That is, generate revenue. The business model spells-out how a company makes money

by specifying where it is positioned in the value chain.

Business process

A business process is a collection of related, structured activities or tasks that produce a specific

service or product (serve a particular goal) for a particular customer or customers. There are three

main types of business processes:

1. Management processes, the processes that govern the operation of a system. Typical

management processes include "Corporate Governance" and "Strategic Management".

2. Operational processes, processes that constitute the core business and create the primary value

stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales.

3. Supporting processes, which support the core processes. Examples include Accounting,

Recruitment, Technical support.

A business process can be decomposed into several sub-processes, which have their own attributes,

but also contribute to achieving the goal of the super-process. The analysis of business processes

typically includes the mapping of processes and sub-processes down to activity level. A business

process model is a model of one or more business processes, and defines the ways in which

operations are carried out to accomplish the intended objectives of an organization. Such a model

remains an abstraction and depends on the intended use of the model. It can describe the workflow or

Management Information System (MIS) -

www.viplavkambli.com


22

the integration between business processes. It can be constructed in multiple levels.

A workflow is a depiction of a sequence of operations, declared as work of a person, work of a simple

or complex mechanism, work of a group of persons, work of an organization of staff, or machines.

Workflow may be seen as any abstraction of real work, segregated in workshare, work split or

whatever types of ordering. For control purposes, workflow may be a view on real work under a

chosen aspect.

Business process modeling tools

Business process modeling tools provide business users with the ability to model their business

processes, implement and execute those models, and refine the models based on as-executed data.

As a result, business process modeling tools can provide transparency into business processes, as well

as the centralization of corporate business process models and execution metrics.

Modeling and simulation

Modeling and simulation functionality allows for pre-execution ―what-if‖ modeling and simulation.

Post-execution optimization is available based on the analysis of actual as-performed metrics.

Business process modeling diagrams are:

* Use case diagrams created by Ivar Jacobson, 1992. Currently integrated in the UML

* Activity diagrams, also currently adopted by UML

Some business process modeling techniques are:

* Business Process Modeling Notation (BPMN)

* Cognition enhanced Natural language Information Analysis Method (CogNIAM)

* Extended Business Modeling Language (xBML)

* Event-driven process chain (EPC)

* IDEF0 used since early 1990s

* Unified Modeling Language (UML), extensions for business process such as Eriksson-Penker's

Programming languages tools for BPM

BPM suite software provides programming interfaces (web services, application program interfaces

(APIs)) which allow enterprise applications to be built to leverage the BPM engine.

Programming languages that are being introduced for BPM include:

* Architecture of Integrated Information Systems (ARIS) supports EPC,

* Business Process Execution Language (BPEL),

* Web Services Choreography Description Language (WS-CDL).

* XML Process Definition Language (XPDL),

Other technologies related to business process modeling include model-driven architecture and

service-oriented architecture.



23

Business reference model

Example of the US Federal Government Business Reference Model.

A business reference model is a reference model, concentrating on the functional and organizational

aspects of an enterprise, service organization or government agency. In general a reference model is

a model of something that embodies the basic goal or idea of something and can then be looked at as

a reference for various purposes. A business reference model is a means to describe the business

operations of an organization, independent of the organizational structure that perform them. Other

types of business reference model can also depict the relationship between the business processes, business functions, and the business area‘s business reference model. These reference model can be

constructed in layers, and offer a foundation for the analysis of service components, technology, data,

and performance.

The most familiar business reference model is the Business Reference Model of the US Federal

Government. That model is a function-driven framework for describing the business operations of the

Federal Government independent of the agencies that perform them. The Business Reference Model

provides an organized, hierarchical construct for describing the day-to-day business operations of the

Federal government. While many models exist for describing organizations - organizational charts,

location maps, etc. - this model presents the business using a functionally driven approach.

Business process integration

Example of the interaction between business process and data models.A business model, which may

be considered an elaboration of a business process model, typically shows business data and business

organizations as well as business processes. By showing business processes and their information

flows a business model allows business stakeholders to define, understand, and validate their business enterprise. The data model part of the business model shows how business information is

stored, which is useful for developing software code. See the figure on the right for an example of the

interaction between business process models and data models.

Usually a business model is created after conducting an interview, which is part of the business

analysis process. The interview consists of a facilitator asking a series of questions to extract

information about the subject business process. The interviewer is referred to as a facilitator to

emphasize that it is the participants, not the facilitator, who provide the business process information.

Although the facilitator should have some knowledge of the subject business process, but this is not as important as her mastery of a pragmatic and rigorous method interviewing business experts. The

method is important because for most enterprises a team of facilitators is needed to collect

information across the enterprise, and the findings of all the interviewers must be compiled and

integrated once completed.

Business models are developed as defining either the current state of the process, in which case the

final product is called the "as is" snapshot model, or a concept of what the process should become,

resulting in a "to be" model. By comparing and contrasting "as is" and "to be" models the business

analysts can determine if the existing business processes and information systems are sound and only

need minor modifications, or if reengineering is required to correct problems or improve efficiency.

Consequently, business process modeling and subsequent analysis can be used to fundamentally

reshape the way an enterprise conducts its operations.

Business process reengineering

Business Process Reengineering Cycle.



24

Business process reengineering (BPR) is an approach aiming at improvements by means of elevating

efficiency and effectiveness of the processes that exist within and across organizations. The key to

business process reengineering is for organizations to look at their business processes from a "clean

slate" perspective and determine how they can best construct these processes to improve how they

conduct business.

Business process reengineering (BPR) began as a private sector technique to help organizations fundamentally rethink how they do their work in order to dramatically improve customer service, cut

operational costs, and become world-class competitors. A key stimulus for reengineering has been the

continuing development and deployment of sophisticated information systems and networks. Leading

organizations are becoming bolder in using this technology to support innovative business processes,

rather than refining current ways of doing work.

Business process management

Business process management is a field of management focused on aligning organizations with the

wants and needs of clients. It is a holistic management approachthat promotes business effectiveness

and efficiency while striving for innovation, flexibility and integration with technology. As organizations

strive for attainment of their objectives, business process management attempts to continuously improve processes - the process to define, measure and improve your processes – a "process

optimization" process.



management information system - wordpress.com · management information system a management...

Documents