|
SE735 - Data and Document Representation
& Processing |
|
Lecture 5 - Describing What Businesses Do and How They Do It |
Businesses
and Patterns
·
At the most abstract level all businesses (or
"enterprises," so that we can include governmental, educational,
military, and non-profit "businesses") follow the same pattern
·
Businesses share common external influences,
especially those in the same industry
·
They also share common internal influences
and goals
·
Some resistance to using patterns arises from
the need for a business to differentiate itself from competitors, but few
companies have the market dominance or true innovations to divert from patterns
in significant ways
Model
and Pattern Abstraction and Granularity
·
Recurring patterns in structures or processes
are visible in abstract models but invisible in the concrete, real-world
objects and functions that the model describes
·
Models can also be expressed at different
levels of granularity
o
Business model or organizational patterns:
marketplace, auction, supply chain, build to order, drop shipment, vendor
managed inventory, etc.
o
Business process patterns:
procurement, payment, shipment, reconciliation, etc.
o
Business information patterns:
catalog, purchase order, invoice, etc. and the components they contain for
party, time, location, measurement, etc.
Business
Organization Patterns
·
Organization charts, facilities maps
·
"Organization of business unit"
patterns
· Business Models
Business
Models
A business model
·
is the story of what a business does and how
it makes money doing it
·
Who are the customers?
·
What do the customer’s value?
·
How does the business deliver this value to
customers at a price they will pay and at a sustainable cost?
So the generic
business model pattern has two parts:
·
Making something or preparing to deliver
something that customers value
·
Finding the customer, transacting to create
the sale or relationship, delivering the value
Types of Business Model Patterns
·
Classifications for measuring
economic activity (e.g., NAICS)
·
Frameworks for understanding the
adoption and impact of IT, migration to "self-service" or
"web-based services"
·
Frameworks for understanding the
financial performance of different kinds of economic activity
MIT
"Business Model Archetypes"
·
Extensive research on business model and
business processes has been conducted by Tom Malone and others at MIT Sloan
School
·
An innovative part of this research program
is empirical study of what businesses actually do and the relative performance
or effectiveness of different business models
·
A fundamental challenge was how to classify
business activity to support this kind of analysis
o
What is the business model -- what types of
rights are being sold?
o
What kind of asset is involved?
Four
Types of Business Models
·
Creators --
design what they sell
·
Distributors --
buys something from a creator and then sells it
·
"Landlords" --
sells the right to use, but not own some asset
·
Brokers --
match potential sellers and buyers
Four
Types of Assets
·
Physical --
durable and nondurable goods
·
Financial --
cash, stocks, bonds, insurance
·
Intangible --
intellectual property, knowledge, goodwill, brand image
·
Human -- time and labor
Business Models X Assets: The Archtypes
This is
interactive at http://process.mit.edu/Info/eModels.asp
·
The
table below shows a matrix of what rights are being sold by what asset is being
sold.
o
This
typology shows 16 possible models that we call Business Model Archetypes (BMA).
o
While
all of the models are logically possible, some are not as common as others and
at least two (Human Trader and Human Creator) are currently illegal or there
are serious ethical issues.
·
Clicking
on the type of right will bring you to the entry in the process handbook.
o
The
bolded models have some examples in the handbook.
|
What is being sold? |
Asset Type |
||||
|
Financial
|
Physical
|
Intellectual
|
Human
|
||
|
Asset
Right |
Ownership–Significant
Transformation (Creator) |
||||
|
Ownership–Limited Transformation |
|||||
|
Use (Landlord) |
|||||
|
Matching (Broker) |
|||||
What
Businesses Do
Distribution of Business Model Archetypes
·
Percent = Percent of total sample revenue in Business Model Archetype
·
Number = Number of firms with any revenue in Business Model Archetype
What
Business Models Are Most Profitable
"Component"
Business Models
·
An emerging conceptual pattern of business
organization "factors" what businesses do into modularized or
specialized functions
·
"What components do" is defined in
abstract, technology-independent terms so we don't have to care about the
computer, operating system, or software application that performs the function
·
This level of abstraction reduces integration
and communication costs between components and is the essence of service
orientation
·
An emphasis on business model / business
process / information exchange patterns facilities component reuse / reassembly
into new combinations: virtual enterprises, composite services, etc.
The
Federal Enterprise Architecture
·
The US Government consists of a bewildering
number of departments, agencies, programs, and other organizational entities
that do not "interoperate" well because of legacy technology,
processes, policies, and politics
·
The FEA BRM is an ambitious attempt to
improve how the US Government "does business" by taking a
cross-agency perspective on products, services, and processes
·
By identifying and reducing redundant
capabilities, activities, and infrastructure, the government hopes to improve
its delivery of products and services to its "customers" and more
tightly link decisions about budgets and initiatives to measurable benefits
The
Federal Government -- "As-Is"
The
Federal Government -- "To-Be"
"Reference
Model"
·
A reference model is a special kind of model
-- based on a small number of unifying concepts and may be used as a basis for
education and explaining standards to a non-specialist
·
Typically a hierarchical and abstract
framework for understanding significant relationships among the entities of
some environment, and for the development of consistent standards or
specifications supporting that environment.
·
A reference model is not directly tied to any
standards, technologies or other concrete implementation details, but it does
seek to provide a common semantics that can be used unambiguously across and between
different implementations
·
It is generally NOT specific enough to build
anything with
FEA
Reference Models
FEA
Business Reference Model
The
Supply Chain
·
A supply chain is an aggregated and
end-to-end view of the buy-side and sell-side relationships of an enterprise
·
A supply chain is the network of facilities
and distribution capabilities an enterprise uses to:
o
"Source" (or "procure")
raw materials (chemicals, ores, grains, ...) or components
o
Transform the materials or assemble the
components into products
o
Deliver the products to customers (indirectly
through distributors or stores or directly to the purchaser)
Supply Chain - Conceptual Model
Design
Goals for Supply Chains
·
Especially for direct goods that are inputs
to manufacturing processes, the things that businesses buy need to get to
specified places at specified times in specified quantities according to
manufacturing plans and sales forecasts.
o The
right stuff in the right amount at the right time in the right place
·
Get as close to zero inventory THAT YOU OWN
without ever losing a sale or having to shut down the assembly line
Supply Chain Operations Reference Model (SCOR)
The
Supply Chain Council
·
was established in 1996 to
develop a standard process reference model for communicating supply-chain
management practices across companies called SCOR that:
o
provides a common supply-chain
framework with standard terminology
o
defines common metrics with
associated benchmarks and best practices
o
serves as a common model for
evaluating, positioning, and implementing
o
supply-chain application software
·
Put another way, SCOR is designed
to provide discipline and advice to a firm trying to answer questions about its
supply chain design
Process Reference Model in SCOR
The SCOR Model
·
Five essential supply chain processes (Plan,
Source, Make, Deliver, Return)
·
Different
supply chain models for different industries and partner configurations can be
created from the same standard process vocabulary
SCOR Model Decomposition
The
Build to Order Pattern
·
BTO is simple in concept, but complex in
execution, requiring competencies in product design, process engineering, and
supply chain management
·
Requires more modular design to enable
configurability and concurrent assembly of sub-components
·
Often used in conjunction with
"just-in-time" pattern whose goal is minimizing inventory by having
suppliers deliver their raw materials or components to a manufacturing location
"just in time" for them to be used
·
Building to order instead of forecast means a
lot less inventory so the rapid obsolescence of components is less harmful
SCOR "Sourced Stocked
Product"
What We Learn From SCOR
·
Every firm in a supply chain has
the same problems to solve
·
Every process is a customer of
the previous one and a supplier to the next
·
The model also distinguishes three patterns for "making"
things: make-to-stock, make-to-order, engineer-to-order
Summary:
Technical Requirements for Successful Supply Chain Collaboration
·
Can our systems exchange information?
·
Can our systems understand the information
they get from each other?
Summary:
Non-Technical Requirements for Successful Supply Chain Collaboration
·
Can our firms and people talk to each other?
·
Do we have a common vocabulary or reference
model (like SCOR or RosettaNet) so we can understand
each other's roles in the patterns we are trying to follow?
·
Do we have executive sponsorship that
encourages us to talk with each other about how to be more efficient and
effective in our supply chain?
·
Do we trust each other?
The
Information Supply Chain
·
The flow of materials and goods in a supply
chain is accompanied by information about it
·
But information about supply chain activities
and processes is increasingly separated from the physical flow of materials and
goods, and for information-based services there is no physical stuff
·
Information also flows in the opposite
direction from the customer, retailers, and distributors back into the supply
chain – this is also called the DEMAND CHAIN
·
The information supply chain has become
especially important because increased global competition and better informed
customers are forcing forms to shift from forecast to demand (i.e. customer)
driven business models
Information
Supply chain vs. Physical Supply Chain
·
Information
can flow qualitatively faster than materials and goods, which might spend weeks
in trucks, trains, or shipping containers moving around the world.
·
Information
may flow in the opposite direction of the materials and goods, moving from
customers and retailers back toward distributors, manufacturers, and their
suppliers.
·
Information can go many places at
once so that supply chain participants can know about inventories, locations,
sales, and so on without having to witness them.
Design
Issues for the Information Supply Chain
·
What information is exchanged?
·
Which entities in the supply chain are able
to exchange information?
·
What is the frequency of this information
exchange
"Document
Automation" or STP Pattern
·
Many business processes can be described as
"moving information around"
·
At each step information might be added to
the input document or a new document might be created that contains most of the
input document's content
·
However, even though the end-to-end process
might span multiple departments (or companies), the business applications (run
by separate departments) may not have been designed to share information with
each other
·
Clerical functions can usually be totally
automated
·
Processes carried out by knowledge workers
can often be partially automated
Typical
Characteristics of Document Automation Efforts
·
Create documents with templates or via guided
assembly (aka "wizards")
·
Minimize manual intervention via rule-based
routing, access control, exception handling
·
Concurrent process re-engineering
·
Documents are regenerated when source
information changes
·
End-to-end perspective to maximize content
reuse
·
Standard content components and processes
Buzzwords
in the "Middle"
·
The Internet has been a disruptive force on
many traditional business model patterns, particularly in the value chain
activities of supply and demand chain management
·
Disintermediation –
cut out the middleman
·
{re} Intermediation –
introduce new middleman
Patterns
in the "Middle"
·
Marketplaces and Auctions
·
Bring together sellers (or their catalogs)
·
Bring together buyers
·
Match buyers and sellers
·
Provide critical mass and infrastructure for
other service providers
Marketplace
- Physical Model
Istanbul’s Grand Bazaar
Marketplace
- Conceptual Model
Glushko & McGrath's
definition:
·
A "market
maker" or "market operator"
·
Participating
businesses
·
The services these
businesses provide to each other
·
The messages and
documents that are exchanged to request and perform the services
E-Business
Architectures (Albrecht et al)
Rosetta
Net
·
RosettaNet is
a non-profit consortium aimed at establishing standard processes for the
sharing of business information (B2B).
·
RosettaNet is
a consortium of major Computer and Consumer Electronics, Electronic Components,
Semiconductor Manufacturing, Telecommunications and Logistics companies working
to create and implement industry-wide, open e-business process standards
·
The RosettaNet
standard is based on XML and defines message guidelines, interfaces for
business processes, and implementation frameworks for interactions between
companies.
o
Mostly addressed is the supply chain area, but
also manufacturing, product and material data and service processes are in
scope.
Rosetta
Net -- Three Level Hierarchy
To classify PIPs, RosettaNet divides the entire supply chain domain into
clusters, segments, PIPs, activities, and actions.
Partner Interface Processes (PIP)
The following elements make up a
PIP:
- Trading
partner business roles (for example, buyer and seller)
- Business
activities between the roles
- Type,
content, and sequence of business documents
- Constraints
for interactions (time, security, authentication, and performance)
- Structure
and content of business documents, including DTDs that describe message
guidelines
- Message
Types:
The
following example represents an order management PIP: Rosetta Net -- PIP 3A4
1. Clusters 3: Order Management
1.1.1 Segment A: Quote and Order
Entry
1.1.1 PIP 3A4: Manage Purchase Order
1.1.1.1 Activity Create Purchase
Order
1.1.1.1.1 Action: Purchase Order
Request
The
following figure shows PIP interaction:
Document
Automation and Straight Through Processing (STP)
·
A great deal of what
businesses do involves abstract activities that can be described in terms of
the movement of information
·
Sometimes the
activities are so abstract that the only tangible things involved are artifacts
that record the information.
·
These kinds of
business processes follow the related patterns of document automation
and straight through processing (STP).
Key
characteristics or subgoals that define the STP pattern
·
They
emphasize more efficient creation of the initial document or documents through
the use of templates for different document types or guided assembly of a
custom document from components.
·
They
seek to minimize manual intervention as the documents flow from process to
process by transforming information for reuse in different contexts and by
using business rules to automate routing, access control, and exception
handling.
·
They
seek not just to automate existing processes, which would be akin to creating
roads by paving cow paths, but to refine or reengineer them, possibly by
adopting industry best practices or reference models.
·
They
view documents as dynamic rather than static, automatically propagating changed
information into the processing pipeline so that it is current and available
when needed.
·
They
take an end-to-end perspective that maximizes reuse and minimizes redundancy by
extracting any sharable models or rules and making them available from a single
logical repository.
·
They
emphasize XML standards for information and process models because those
standards facilitate the other five subgoals.
Document
Interchange
The Context of Document Exchange
Electronic Data Interchange (EDI) and XMLification
·
EDI was developed to automate the exchange of
structured information in transactional documents such as orders, invoices, and
payments between business applications. Initially these exchanges took place
over dedicated leased telephone lines or over private networks in a batch
store-and-forward fashion
·
EDI took hold in the 1980s and 1990s and is
widely used to automate routine document exchange transactions between
established trading partners, especially in direct procurement and in the
demand chains for CPG sector ("Consumer Packaged Goods")
·
The ANSI ASC X12 U.S. standards and
Guidelines for Trade Data Interchange (GTDI) European standards began to emerge
at this time, followed shortly by the ISO 9735 (UN/EDIFACT) standard developed
by the United Nations to consolidate numerous national EDI standards
·
After XML's emergence in the late 1990s, many
standards efforts have arisen to evolve document and process standards encoded
in EDI syntaxes to XML
·
EDI isn't dead, but XMLification
is inevitable because EDI's implementation and recurring costs are vastly
higher than those for XML-based information systems
*
X12 EDI Message Fragment
ISA*00* *00* *08*JCPenny111 *ZZ*test22222
*971107*1220*U*00302*112240001*1*P*@
GS*PO*test111111*test22222*19971107*1220*123456789*X*003042
ST*850*4567
BEG*00*NE*10117564**19990105
REF*ZI*11
REF*1V*97-0049393
PER*OD*Chris Smith*EM*csmith@supplyworks.com
PER*RE*Tom Gerry*TE*617-861-7900x1567
DTM*074*19990120*1806
N1*BE*SupplyWorks*91*FFF
N1*BY*SupplyWorks*91*ABC1235
N1*EY*Chris Smith*92*csmith1
N2*Room 208C*SupplyWorks Corporate
N3*57 Bedford Street*Building 2
N4*Lexington*MA*02173
N1*ST*SupplyWorks*ZZ*SW1
N1*SE*EC Office Supplies*1*98629321
N2*Purchase Department
N3*123 Main Street
N4*NY*NY*03417
PO1*1*24*EA*1.86**UI*999999922234
TXI*TX*9.41
PO1*2*12*CA*25.67**UI*999999955567
TXI*TX*4.51
CTT*2*42
SE*24*4567
GE*1*123456789
IEA*1*112240001
EDIFACT
Message Fragment
*
XML Message Fragment
http://docs.oasis-open.org/ubl/os-UBL-2.0/xml/UBL-Order-2.0-Example.xml
<cac:OrderLine>
<cbc:Note>this
is an illustrative order line</cbc:Note>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:SalesOrderID>A</cbc:SalesOrderID>
<cbc:LineStatusCode>NoStatus</cbc:LineStatusCode>
<cbc:Quantity
unitCode="KG">100</cbc:Quantity>
<cbc:LineExtensionAmount
currencyID="GBP">100.00</cbc:LineExtensionAmount>
<cbc:TotalTaxAmount
currencyID="GBP">17.50</cbc:TotalTaxAmount>
<cac:Price>
<cbc:PriceAmount
currencyID="GBP">100.00</cbc:PriceAmount>
<cbc:BaseQuantity
unitCode="KG">1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Description>Acme
beeswax</cbc:Description>
<cbc:Name>beeswax</cbc:Name>
<cac:BuyersItemIdentification>
<cbc:ID>6578489</cbc:ID>
</cac:BuyersItemIdentification>
<cac:SellersItemIdentification>
<cbc:ID>17589683</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
Why
Encode A New Vocabulary in XML and Not EDI
(XML) Vocabularies
·
The most accessible information pattern
resources are XML vocabularies (or "schemas" or "tag sets")
·
A vocabulary is a set of elements and attributes
and the rules by which they combine
·
Linguists shudder at this definition because
it conflates the vocabulary and the grammar
·
XML purists call these
"applications" of XML but this conflicts with the more common usage
of that word to mean "software application"
*
The Need for Controlled Vocabularies
·
There is no one good access term or name for
most objects or concepts. The idea of an "obvious,
"self-evident," or "natural" term is a myth
·
The words people use to describe things or
concepts are "embodied" in their context and experiences... so they
are often different or even "bad" with respect to the words used by
others
·
What would "good" words be like?
·
Where would they come from?
·
How do you get people to use them?
Why XML Vocabularies Exist
Vocabularies
must exist because:
·
There is no
predefined set of tags
·
And since there is no
predefined tag set, there can't be any predefined semantics
·
Semantics are defined
in the schema and its documentation about what the elements and attributes mean
·
So using XML without
a (documented) schema makes little sense
Why Vocabularies Are Desirable
Vocabularies are
desirable
·
because people want to have a set of tags
that is customized to their problem or industry so that they can take full
advantage of XML
·
A good vocabulary represents a significant
investment in defining a domain, identifying its key semantic components, and
specifying the constraints and rules governing the combination and reuse of
those components
·
A good vocabulary is a reference model for the
domain that facilitates communication between enterprises operating within it
Vertical
and Horizontal Vocabularies
Vertical:
·
Particular industry or vertical market
·
Detailed product semantics
·
Specialized process semantics
·
Sometimes called "domain-specific"
languages
Horizontal
·
Concepts
that are common to all (or a large number of) vocabularies
Creating
Vertical XML Vocabularies – Worst Practices
·
Turn proprietary APIs into XML vocabularies
by wrapping "<" and ">" around the names of methods
that set and return values
·
Turn proprietary database schemas into XML
vocabularies by wrapping "<" and ">" around the names
that define the structure of a record or object
·
Turn existing EDI messages into XML by
automated conversion, using the delimiters for segments, composites, and
elements as "handles" for content
*
Creating
Vertical XML Vocabularies – Better Practices
Turn existing EDI messages into XML
·
Analyze EDI messages to identify the
"syntax-neutral" conceptual models they contain
·
Encode these conceptual models in XML
If no vocabulary exists:
·
Identify current and potential uses of the
vocabulary
·
Analyze existing documents and information
sources (with EDI, identify "syntax-neutral" models of message
content)
·
Design conceptual models that satisfy the
requirements in a feasible way
·
Encode the models in XML schemas
XML
and Metcalfe's Law
·
The value of a language depends on how many
people (or computers) understand it
·
How do you encourage and enable others to understand
your language?
o
Standardization Approach 1: "Understand
my language or I won't do business with you"
o Standardization
Approach 2: "Excuse me, here's my language, would
you like to do business with me?"
Information Aggregations
·
Information aggregations occur where documents or data from numerous sources
are brought together to create a consolidated information resource that is more
valuable than the sum of the sources.
o
In enterprise contexts this composite resource is typically called a data warehouse or data mart.
·
An alternative approach is to create a virtual repository or
virtual catalog in which the
metadata from each source is aggregated into the composite resource, not the
content itself.
·
Another information composition pattern is syndication, the
consolidation and distribution of information products
Conceptual Views of Business
Information
·
Conceptual views are
more challenging to develop than physical ones
·
The ebXML initiative, launched in 1999 as a joint venture of
EDI and XML standards organizations, was the first serious attempt to create
conceptual views of business information that could be used in document
implementation models in any syntax.
o The resulting document exchanges would be interoperable
because of their common semantic foundations called the core components
·
The Universal Business
Language (UBL) effort began in late 2001 with the extremely ambitious goals of
building on the ebXML core components, synthesizing
the leading XML and EDI vocabularies for business, and creating standard
business documents that would be nonproprietary and royalty free.
Views of Business Architecture
Physical Views of Business
Architecture
·
A description of a system and its components as a physical model is a
systems architecture.
·
A system’s architecture describes a business in terms of its computing
platforms, operating systems, databases, and software applications.
Technology Platforms and Infrastructure
·
Sometimes the business architecture of an enterprise is characterized in
terms of its dominant software architectures or technology suppliers; this is
often called its platform.
·
Physical system architectures are often depicted using deployment
diagrams that show the key information repositories (e.g. databases), computing
resources (server farms), and dedicated communications links and networks
needed to move data and documents around.
Integration Architectures and Patterns
·
Integration
is defined as the controlled sharing of data and business processes between any
connected applications or data sources Web Services
·
Integration
approaches that depend on implementation details or other characteristics at
the physical level are said to be tightly
coupled.
·
Tight
coupling is used to exchange data at high transaction rates
·
Loose
coupling is necessary for integration across enterprise boundaries because
interfaces might change
Web Services
·
A web service is
defined as a platform-independent implementation of functionality that conforms
to published specifications for:
o the XML documents it sends and receives as its public
interfaces (for example, the Web Service Description Language or the ebXML CPPP)
o the messaging protocol used to send and receive XML
documents through those interfaces (for example, SOAP or ebMS)
o a
searchable directory of services (for example, a UDDI or an ebXML
Registry).
·
Because they can wrap
a hodgepodge of legacy technologies and hide proprietary data models and
protocols with XML document interfaces, web services provide a layer of
abstraction and enable a more loosely-coupled integration approach than
previous integration technologies.
Conceptual Views of Business
Architecture
·
A logical architecture can portray the boundaries or interconnections
among business systems and represent the extent to which systems are
centralized or distributed within an enterprise.
·
Architectural patterns reflect different requirements for system
communication or integration.
·
An architectural description can reveal the extent and direction of
information exchanged between systems.
·
It can also identify systems that are isolated islands or silos of
functionality because they can’t easily exchange information with other ones.
·
At the top of the conceptual model hierarchy are
what IBM calls the Business Patterns,
which describe at the most conceptual level the ways in which users and
businesses interact with information.
·
There are four Business Patterns:
1.
Self-Service (also known as “user-to-business” or B2C)
2.
Collaboration (also known as “user-to-user” or C2C)
3.
Information Aggregation (also known as “user-to-data”)
4.
Extended Enterprise (also known as “business-to-business” or B2B).
·
These basic Business Patterns can be combined to create more complex
patterns.
Conceptual Views of Integration Architecture
·
It is preferable for many of the participants in a business relationship
to take a technology-independent and conceptual view of the integration
architecture and focus on the more abstract goal of interoperability.
·
Interoperability means that the recipient can extract the required
information from the sender’s document even if the sender’s implementation is
not immediately compatible with the recipient’s business systems
·
Interoperability is a more abstract goal than integration
Service-Oriented Architectures
·
An abstract view of
services in a business architecture that considers everything a business does
as (potentially) realized by business service components that are combined and
recombined as needed.
·
A SOA perspective
drives a business to ask strategic questions like these as it systematically
structures its business capabilities as self-contained resources or processes:
•
What patterns of
service combination are required to meet our business objectives?
•
How can we design
what each service does so that as a set they will be sufficient and flexible
enough as business conditions change?
•
Which of these
services can we “carve out” of existing applications by changing their
implementations or APIs?
•
Which services should
we build ourselves, and which should we obtain from others?
•
Should we offer any
of our services to other firms?